Providing locality rules for radio-based networks

Abstract

Various embodiments for provisioning locality rules for radio-based networks are disclosed. In one embodiment, at least one locality rule associated with an organization is accessed. The locality rules require at least a subset of network traffic for the radio-based network to remain within a particular geographic area. The radio-based network includes a radio access network and an associated core network. A topology for the radio-based network is determined based at least in part on the locality rule. The radio-based network is provisioned or reconfigured for the organization such that the topology conforms to the at least one locality rule.

Description

[0001] This application is a divisional application of Chinese patent application number 2022800890561 (corresponding to PCT international application number PCT / US2022 / 080988), filed on December 6, 2022, entitled "Providing Locality Rules for Radio-Based Networks".

[0002] Cross-references to related applications

[0003] This application claims priority and benefit to U.S. Patent Application 17 / 544,817, filed December 7, 2021, entitled “Provisioning Radio-Based Networks with Locality Rules”. This application also claims priority and benefit to U.S. Patent Application 17 / 544,825, filed December 7, 2021, entitled “Locality-Based Network Slicing in Radio-Based Networks”. Both applications are incorporated herein by reference in their entirety. Background Technology

[0004] 5G is the fifth-generation technology standard for broadband cellular networks, and is planned to eventually replace the fourth-generation (4G) standard of Long Term Evolution (LTE). 5G technology will significantly increase bandwidth, thus expanding the cellular market beyond smartphones to provide last-mile connectivity for desktops, set-top boxes, laptops, Internet of Things (IoT) devices, and more. Some 5G cells may use spectrum similar to 4G, while others may use millimeter-wave spectrum. Millimeter-wave cells have relatively smaller coverage areas but significantly higher throughput than 4G. Attached Figure Description

[0005] Many aspects of this disclosure can be better understood by referring to the following figures and description. The components in the figures are not necessarily drawn to scale, but rather the emphasis is on clearly illustrating the principles of this disclosure. Furthermore, the same reference numerals in the figures designate corresponding portions throughout multiple views.

[0006] FIG. 1A This is a diagram illustrating examples of communication networks deployed and managed according to various implementation schemes of this disclosure.

[0007] FIG. 1B Examples of radio-based networks used on an organizational campus with multiple buildings and deployed according to various embodiments of this disclosure.

[0008] FIG. 2AExamples of networking environments including a cloud provider network and various provider underlying extensions of the cloud provider network, according to some embodiments of this disclosure, are shown, said networking environments being able to FIG. 1A It is used in various locations within the communication network.

[0009] FIG. 2B Some embodiments according to this disclosure are described. FIG. 1A Examples of the cellularization and geographical distribution of communication networks.

[0010] FIG. 3 Some embodiments according to this disclosure are shown. FIG. 2A Examples of networked environments, which include geographically dispersed provider underlying extensions.

[0011] FIG. 4 It is based on the various implementation schemes of this disclosure. FIG. 2A A schematic block diagram of a networked environment.

[0012] FIG. 5 This illustrates various embodiments of the present disclosure. FIG. 4 A flowchart illustrating an example of a function implemented as part of a radio-based network management service in a networked computing environment.

[0013] FIG. 6A , FIG. 6B and FIG. 7 This illustrates the implementation of various embodiments according to this disclosure in... FIG. 4 A flowchart illustrating examples of the functionality of various parts of a local orchestration service executed in a computing environment within a networked environment.

[0014] FIG. 8 Based on the various embodiments provided in this disclosure FIG. 4 A schematic block diagram illustrating an exemplary computing environment used in a networked environment. Detailed Implementation

[0015] This disclosure relates to implementing localization rules for network topologies in radio-based networks, such as 4G, 5G, and sixth-generation (6G) radio-based networks that are at least partially implemented using cloud provider network infrastructure. The radio-based network may include a radio access network (RAN) and an associated core network. The radio-based network can be deployed on behalf of customers using cloud provider network infrastructure in an at least partially automated manner. A customer may correspond to an organization or enterprise with a large number of users and user devices receiving services from the radio-based network. In some scenarios, the customer's radio-based network may be a private network limited to use only by the customer's devices. In other scenarios, the customer's radio-based network may be open to external users.

[0016] Customers located in a particular geographic region may have specific data locality requirements that restrict data access or data transfer to that geographic region. In some implementations, the geographic region can be a single jurisdiction. For example A country or state) or a group of jurisdictions For example (EU). This data locality requirement can be addressed by data sovereignty, export controls, and privacy regulations. For example Driven by the EU's General Data Protection Regulation (GDPR), security considerations, or other reasons. For example, operators of radio-based networks within a specific country may offer restricted services that allow users to call each other over secure lines that guarantee network traffic never leaves that specific country. To provide such a service, the entire network topology used for making calls (including communication links, data storage services, and network functions) would need to be located within that specific country.

[0017] Various embodiments of this disclosure introduce the automatic creation of radio-based networks or radio-based network slices that satisfy network topology locality rules. Network topology locality rules are rules that specify restrictions on the geographically locatable areas of the physical network infrastructure used to create radio-based networks or network slices. This disclosure enables customers to specify network topology locality rules for radio-based networks, network slices, or applications using radio-based networks, for example, via one or more APIs. Customers can specify all network traffic or certain types of network traffic (…). For example Voice calls, text messages, and / or data need to be kept within a specified geographic area. This service can automatically restrict the deployment of network functions that operate on this network traffic to a specified geographic area. In some cases, the specified geographic area may correspond to a region with predefined boundaries (…). For example Geographic regions can be defined by country, state, or ZIP code, while in other cases, customers can define geographic regions with arbitrary boundaries. For example(Company campus). Therefore, components of the radio-based network are automatically deployed and provisioned, ensuring that communication links, data storage, and network functions reside within a designated geographic area to support the customer's localization requirements. In some scenarios, parts of the core network are deployed on a cloud provider network with both internal and external resources within a designated geographic area. To meet the customer's localization requirements, resources within the designated geographic area of ​​the cloud provider network are selected for the customer's radio-based network or network slices.

[0018] Previous deployments of radio-based networks relied on manual deployment and configuration at every step of the process. This proved extremely time-consuming and expensive. Furthermore, in previous generations, the software was inherently tied to vendor-specific hardware, preventing customers from deploying alternative software. In contrast, for 5G, the hardware and software stacks are decoupled, allowing for greater flexibility and enabling components of radio-based networks to run on cloud provider infrastructure. Using a cloud distribution model for radio-based networks, such as 5G networks, facilitates handling network traffic from hundreds to billions of connected devices and compute-intensive applications, while delivering faster speeds, lower latency, and greater capacity compared to other types of networks.

[0019] Historically, enterprises have had to choose between performance and price when evaluating their enterprise connectivity solutions. Cellular networks can offer high performance, good indoor and outdoor coverage, and advanced Quality of Service (QoS) connectivity features, but dedicated cellular networks can be expensive and complex to manage. While Ethernet and Wi-Fi require less upfront investment and are easier to manage, enterprises often find them less reliable, require significant effort to achieve optimal coverage, and do not provide QoS features such as guaranteed bit rates, latency, and reliability.

[0020] The disclosed radio-based network services offer enterprises the best of both worlds: the performance, coverage, and QoS of carrier-grade cellular networks, and the ease and cost of deployment and operation associated with Wi-Fi. The services provide suitable hardware in various form factors that enterprises can deploy at their sites, integrated with software that runs the entire network, from small cell sites to internet distribution points. Enterprises can freely deploy various 5G devices and sensors across their operations (factory floors, warehouses, lobbies, and communication centers), managing these devices, registering users, and assigning QoS through a management console. Using the disclosed technology, customers can allocate a constant bit rate throughput to all their devices (e.g., cameras, sensors, or IoT devices), providing reliable low-latency connectivity for devices operating on the factory floor, and assigning broadband connectivity to all handheld devices. The services manage all the software needed to provide connectivity that meets specified constraints and requirements. This enables a completely new set of applications with stringent QoS or high IoT device density requirements that were traditionally impossible to run on Wi-Fi networks.

[0021] The disclosed services support multiple deployment scenarios. In a cloud-only deployment, the services provide a small radio cell that enterprise customers can place on-site, while network functions and other network software operate in the nearest cloud provider's availability zone or edge location (or one of several nearest cloud provider availability zones or edge locations). These cloud provider locations can be selected, at least in part, based on the network topology locality rules described herein. For enterprises wishing to deploy on-premises, the disclosed services provide cloud provider hardware, such as the underlying extensions described herein. In this mode, the network and applications remain on-premises, enabling the enterprise to securely store and process data that needs to remain on-premises. For example For reasons of regulatory compliance and safety and the like Furthermore, the disclosed services allow any computing and storage not used for running radio-based networks to run any local workload via the same APIs that customers can use to run workloads in traditional cloud provider regions. Advantageously, because of this, enterprises don't need to worry about overscaling and wasting capacity, as the services will enable any excess capacity to be used for local processing and will provision new hardware and software as network needs change. Additionally, the disclosed services provide application development APIs that expose and manage 5G capabilities such as QoS, allowing customers to build applications that fully utilize their network's latency and bandwidth capabilities without needing to understand the network details.

[0022] Additionally, the exposed services provide Private Zones for running native applications within the cloud provider's network. This Private Zone can connect to and become an effective part of a wider Regional Zone, allowing customers to manage the Private Zone using the same APIs and tools used within the cloud provider's network. Similar to Availability Zones, Virtual Private Network subnets can be assigned to Private Zones. APIs can be used to create subnets and assign them to any Zone a customer wishes to use, including Private Zones and other existing Zones. A management console provides a simplified process for creating Private Zones. Virtual machine instances and containers can be launched in Private Zones just as they would in Regional Zones. Customers can configure network gateways to define routes, assign IP addresses, set up Network Address Translation (NAT), and more. Autoscaling can be used to scale the capacity of virtual machine instances or containers according to the needs within the Private Zone. The same management and authentication APIs used within the cloud provider's network can be used within Private Zones. In some cases, cloud services available in Regional Zones can be accessed remotely from the Private Zone via a secure connection, eliminating the need to upgrade or modify on-premises deployments.

[0023] Various embodiments of this disclosure provide methods that allow customers to automatically order and deploy radio-based networks and associated core networks. Customers may include those wishing to establish radio-based networks for internal use. Example As This disclosure pertains to enterprises and organizations using dedicated 5G networks. Through various user interfaces, customers can specify their network planning or requirements (e.g., physical site layout and device / application types and quantities, as well as network topology locality rules), and the various components required for implementing a radio-based network can be automatically determined and provisioned for the customer. Hardware such as antennas, radio components, and computer servers can be pre-configured and shipped to the customer for their radio-based network. The process of installing pre-configured hardware is largely plug-and-play, and the radio-based network can be activated via a user interface or API. In addition to deploying radio-based networks (such as all or part of a new radio access network), various embodiments of this disclosure facilitate the modification and management of radio-based networks, including the deployment of pre-configured equipment for additional cells and the allocation of QoS constraints for specific devices or applications on their radio-based networks.

[0024] Various embodiments of this disclosure can also introduce the concepts of elastic and utility computing from cloud computing models into radio-based networks and associated core networks. For example, the disclosed techniques can run core and radio access network functions, along with associated control plane management functions, on cloud provider infrastructure, thereby creating cloud-native core networks and / or cloud-native radio access networks (RANs). In some implementations, such core and RAN network functions can be based on 3GPP specifications. By providing cloud-native radio-based networks, customers can dynamically scale their radio-based networks based on utilization, latency requirements, and / or other factors. In some cases, the hardware sent to customers includes sufficient capacity to run the radio-based network and other customer workloads. As That is Their application's program makes any capacity not intended for radio-based networks accessible to run workloads under a utility computing model. Advantageously, a customer's radio-based network can be scaled to this excess capacity as needed, for example, allowing increased hardware usage requirements for the radio-based network even before new physical hardware is provisioned for the customer. Customers can also configure thresholds to receive alerts related to radio-based network usage and excess capacity usage of their provisioned infrastructure, enabling more effective management of new infrastructure provisioning or deprovisioning of existing infrastructure based on their dynamic network and workload requirements.

[0025] Network slicing is a capability that enables the deployment and operation of multiple logical networks over a common physical network infrastructure in such a way that each logical network ( For example Network slices can be customized and sized to best meet a specific set of requirements. Typically, network slices are manually created and provided to a specific organization or business entity. According to this disclosure, a software application running on a radio-based network can issue an API request to a service to obtain network slices that satisfy a set of QoS constraints and / or network topology locality rules provided for the application. In response, the service can automatically provision such network slices for use by network traffic associated with the application. Network slices can reserve a certain number of different hardware resources ( For example The service can also manage such network slices at scale across a wide range of different software applications, for example, by provisioning “complementary” slices (which have complementary requirements across a different set of hardware components) on the same underlying hardware for more efficient resource utilization, or by over-provisioning slices based on predicted utilization that indicates all applicable QoS constraints can still be met.

[0026] As those skilled in the art will appreciate from this disclosure, certain embodiments may be able to achieve certain advantages, including some or all of the following: (1) improving the user experience by allowing an organization to deploy its own radio-based network in a highly automated, plug-and-play manner; (2) increasing the flexibility of a computer system by allowing computing hardware previously dedicated to network functions in a radio-based network and associated core network to be reused for other applications; (3) increasing the flexibility of a computer system by allowing computing hardware previously dedicated to a first radio-based network to be automatically reused for a second radio-based network (or reused between RAN and core network functions in the same radio-based network as needed); (4) improving the user experience when deploying a radio-based network by pre-configuring antennas, radios, and other hardware, thereby providing a plug-and-play installation experience; and (5) optimizing cell deployment. (6) Improve the performance and management of radio-based networks by monitoring performance metrics and adding, removing and reconfiguring cells as needed to maintain acceptable performance; (7) Improve the scalability and overall performance of radio-based networks by transferring network functions previously provided by proprietary hardware to virtual machine instances flexibly operated by cloud computing providers under a utility computing model; (8) Reduce latency in radio-based networks by transferring network functions to virtual machine instances running on the computing devices of cloud service providers at cell sites; (9) Improve the flexibility of communication networks by allowing the automatic determination of network topology for radio-based networks based at least in part on data locality requirements; (10) Improve the flexibility of communication networks by allowing the automatic determination of network topology for network slices of radio-based networks based at least in part on data locality requirements; and so on.

[0027] One of the benefits of this disclosure is the ability to deploy and link network functions together to deliver end-to-end services that meet specified constraints and requirements. According to this disclosure, network functions organized into microservices work together to provide end-to-end connectivity. One set of network functions is part of a radio network, operating in cellular towers and performing radio-to-IP conversion. Other network functions operate in large data centers, performing subscriber-related business logic and routing IP traffic to and from the Internet. For applications using new 5G features such as low-latency communication and reserved bandwidth, both types of network functions need to work together to properly schedule and reserve radio spectrum and perform real-time computing and data processing. The currently disclosed technology provides edge positioning hardware (described further below) that integrates with network functions operating across the entire network from cell sites to Internet breakpoints and orchestrates these network functions to meet required Quality of Service (QoS) constraints. This enables a new set of applications with stringent QoS requirements, ranging from factory-based Internet of Things (IoT) to augmented reality (AR), virtual reality (VR), game streaming, and autonomous navigation support for connected vehicles—applications previously impossible to run on mobile networks.

[0028] The described “Resilient 5G” service provides and manages all the hardware, software, and network functions required to build a network. In some implementations, network functions may be developed and managed by a cloud service provider; however, the described control plane can manage network functions from a range of providers, allowing customers to use a single set of APIs to invoke and manage their selection of network functions on their cloud infrastructure. The Resilient 5G service beneficially automates the creation of an end-to-end 5G network, from hardware to network functions, thereby reducing the time required to deploy the network and the operational costs of operating it. By providing APIs that expose network capabilities, the exposed Resilient 5G service enables applications to easily specify desired QoS as constraints and then deploy and link network functions together to deliver end-to-end services that meet the specified requirements, making it easy to build new applications.

[0029] This disclosure describes implementation schemes related to the creation and management of cloud-native 5G cores and / or cloud-native 5G RANs and associated control plane components. Cloud-native refers to a method of building and running applications that leverages the advantages of cloud computing distribution models, such as dynamic scalability, distributed computing, and high availability (including geographic distribution, redundancy, and failover). Cloud-native refers to how these applications are created and deployed to suit deployment in the public cloud. While cloud-native applications can (and often) run in the public cloud, they can also run in on-premises data centers. Some cloud-native applications can be containerized, for example, by packaging different parts, functions, or sub-units of the application into their own containers, which can be dynamically orchestrated to actively schedule and manage each part to optimize resource utilization. These containerized applications can be built using a microservices architecture to improve the overall agility and maintainability of the application.

[0030] In a microservices architecture, an application is arranged as a series of smaller sub-units (“microservices”) that can be deployed and scaled independently of each other and can communicate with each other over a network. These microservices are typically fine-grained because they have specific technical and functional granularity and often implement lightweight communication protocols. The application’s microservices can perform different functions, can be deployed independently, and can use different programming languages, databases, and hardware / software environments. Decomposing an application into smaller services improves application modularity, enables on-demand replacement of individual microservices, and parallelizes development by allowing teams to develop, deploy, and maintain their microservices independently of each other. In some examples, virtual machines, containers, or serverless functionalities can be used to deploy microservices. The disclosed core and RAN software can follow a microservices architecture such that the described radio-based network consists of independent sub-units that can be deployed and scaled on demand.

[0031] Turn now That is This illustration shows examples of a communication network 100 deployed and managed according to various embodiments of this disclosure. The communication network 100 includes a radio-based network 103, which may correspond to a cellular network such as a fourth-generation (4G) Long Term Evolution (LTE) network, a fifth-generation (5G) network, a 4G-5G hybrid core with 4G and 5G RAN, or another network providing wireless network access. The radio-based network 103 may be operated by a cloud service provider for a business, non-profit organization, school system, government entity, or other organization. Although referred to as a private network, the radio-based network 103 may use private network addresses or public network addresses in various embodiments.

[0032] Various deployments of the radio-based network 103 may include one or more of a core network and a RAN network, as well as a control plane for running the core and / or RAN networks on a cloud provider's infrastructure. As mentioned above, these components can be developed in a cloud-native manner, such as using a microservices architecture, enabling efficient scaling of traffic and transactions using centralized control and distributed processing. These components can be based on 3GPP specifications, following an application architecture that separates control plane and user plane processing (CUPS architecture).

[0033] Radio-based network 103 provides wireless network access to a plurality of wireless devices 106, which may be mobile devices or fixed-location devices. In various examples, wireless devices 106 may include smartphones, connected vehicles, IoT devices, sensors, machines (such as in manufacturing facilities), hotspots, and other devices. Such wireless devices 106 are sometimes referred to as user equipment (UE) or customer premises equipment (CPE).

[0034] The radio-based network 103 may include a radio access network (RAN) that provides wireless network access to multiple wireless devices 106 through multiple cells 109. Each cell 109 may be equipped with one or more antennas and one or more radio units that transmit and receive radio data signals to and from the wireless device 106. The antennas may be configured for one or more frequency bands, and the radio units may be frequency-agile or frequency-tunable. The antennas may be associated with specific gain or beamwidth to focus signals within a specific direction or azimuth range, potentially allowing frequency reuse in different directions. Furthermore, the antennas may be horizontally polarized, vertically polarized, or circularly polarized. In some examples, the radio units may utilize multiple-input multiple-output (MIMO) technology to transmit and receive signals. Thus, the RAN implements radio access technology to enable radio connectivity with the wireless device 106 and provides connectivity to the core network of the radio-based network. The components of the RAN include base stations and antennas covering a given physical area, as well as the core network components required to manage connectivity to the RAN.

[0035] Data traffic typically travels through multiple hops via Layer 3 routers ( For exampleThe 5G core network, consisting of a fiber optic transmission network (at the aggregation site) that routes traffic to the core network, is typically housed in one or more data centers. The core network typically aggregates data traffic from end devices, authenticates subscribers and devices, applies personalized policies, and manages device mobility before routing traffic to carrier services or the internet. For example, a 5G core can be decomposed into multiple microservice elements with separate control and user planes. The 5G core may include virtualized, software-based network functions (e.g., deployed as microservices) rather than physical network elements, and therefore can be instantiated within a multi-access edge computing (MEC) cloud infrastructure. The network functions of the core network may include user plane functions (UPF), access and mobility management functions (AMF), and session management functions (SMF), which will be described in more detail below. For data traffic destined for locations outside the communication network 100, the network functions typically include firewalls through which traffic can enter or leave the communication network 100 to reach external networks, such as the internet or cloud provider networks. Note that in some implementations, the communication network 100 may include sites that allow traffic to flow from further downstream of the core network (…). and the like Facilities that are accessed or exited at aggregation sites or radio-based networks (103).

[0036] UPF provides an interconnection point between mobile infrastructure and data networks (DN). FIG. 1B UPF performs encapsulation and decapsulation of the General Packet Radio Service (GPRS) tunneling transport protocol for the user plane (GTP-U). UPF also provides session anchors for providing mobility within the RAN, including sending one or more end-marked packets to the RAN base station. UPF also handles packet routing and forwarding, including directing traffic to specific data networks based on traffic matching filters. Another feature of UPF includes per-flow or per-application QoS processing, including transport-level packet marking for uplink (UL) and downlink (DL), and rate limiting. UPF can be implemented as a cloud-native network function using modern microservices approach, for example, it can be deployed within a serverless framework (by abstracting the underlying infrastructure on which code runs via managed services).

[0037] The AMF can receive connection and session information from the radio device 106 or the RAN and can handle connection and mobility management tasks. For example, the AMF can manage handover between base stations in the RAN. In some examples, by terminating certain RAN control plane and radio device 106 traffic, the AMF can be considered an access point for the 5G core. The AMF can also implement encryption and integrity protection algorithms.

[0038] SMF can handle session establishment and modification, such as by creating, updating, and deleting Protocol Data Unit (PDU) sessions and managing session contexts within a UPF. SMF can also implement Dynamic Host Configuration Protocol (DHCP) and IP Address Management (IPAM). SMF can be implemented as a cloud-native network function using modern microservices methodologies.

[0039] Various network functions of the radio-based network 103 can be deployed and implemented in the distributed computing device 112, which may correspond to a general-purpose computing device configured to perform network functions. For example, the distributed computing device 112 may run one or more virtual machine instances, which are configured to perform one or more services that perform network functions. In one embodiment, the distributed computing device 112 is a ruggedized machine deployed at each cell site.

[0040] In contrast, one or more centralized computing devices 115 can perform various network functions at a central site operated by the client. For example, the centralized computing device 115 may be located centrally in a client's premises in a well-equipped server room. The centralized computing device 115 may run one or more virtual machine instances, which are configured to perform one or more services that perform network functions.

[0041] In one or more embodiments, network traffic from radio-based network 103 is backhauled to one or more core computing devices 118, which may be located in one or more data centers remote from customer sites. Core computing devices 118 may also perform various network functions, including routing network traffic to and from network 121, which may correspond to the Internet and / or other external public or private networks. Core computing devices 118 may perform functions related to the management of communication network 100. FIG. 1B Billing, Mobility Management FIG. 2A And the functionality of relaying traffic between the communication network 100 and other networks.

[0042] Move to FIG. 1A Examples of radio-based networks 150 used and deployed according to various embodiments of this disclosure are shown in an organizational campus (such as premises of a company, school, or other organization) having multiple buildings 153. Although For example An example with multiple buildings is depicted, but it should be understood that the disclosed techniques can be similarly applied to any layout of the site, which may include one or more buildings and / or one or more outdoor spaces (such as stadiums or other outdoor venues).

[0043] The radio-based network 150 in this non-limiting example includes four cells 156a, 156b, 156c, and 156d to fully cover the organization's campus. Cells 156 may slightly overlap to provide extensive coverage within each building 153. Adjacent or overlapping cells 156 are configured to operate at non-interfering frequencies. For example, cell 156a may use frequency A, cell 156b may use frequency B, and cell 156c may use frequency C, all of which are distinct frequencies when the coverage areas of the respective cells 156a, 156b, and 156c overlap. However, cell 156d may use, for example, frequency A or B, because the coverage area of ​​cell 156d does not overlap with that of cells 156a or 156b.

[0044] It should be noted that, depending on usage or other network metrics, cell 156 may be added to or removed from radio-based network 150. In some cases, signal strength to cell 156 may be increased to reduce the number of cells 156, or signal strength to cell 156 may be decreased to increase the number of cells 156, while allowing spectrum reuse among cells 156. Additionally, computing capacity may be added within the geographical area of ​​an organization's campus or within a cloud provider's network to reduce latency, maintain security, and increase reliability of radio-based network 150 as needed. In some cases, the computing capacity of the software implementing radio-based network 150 may be largely or entirely provisioned in the cloud provider's network rather than at the customer's premises (such as in a regional data center of the cloud service provider). This software can implement various network functions, such as UPF, AMF, SMF, etc., which may correspond to core network functions, central unit network functions, and distributed unit network functions. Some network functions, such as distributed unit network functions, may be retained at the cell site.

[0045] For example Examples of networking environments 200, including a cloud provider network 203 and various provider underlying extensions of the cloud provider network, are shown according to some embodiments. These networking environments are compatible with… For example The communication network 100 is used in conjunction with local customer deployments. The cloud provider network 203 (sometimes simply referred to as the "cloud") refers to a network-accessible pool of computing resources (such as computing, storage, and networking resources, applications, and services), which can be virtualized or bare metal. The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to client commands. These resources can be dynamically provisioned and reconfigured to adapt to variable loads. Therefore, cloud computing can be viewed as a process using a publicly accessible network ( For example Applications that deliver services (such as the Internet and cellular communication networks) as well as the hardware and software in the data centers of cloud providers that provide those services.

[0046] Cloud provider network 203 can provide users with an on-demand, scalable computing platform via the network, for example, allowing users to have scalable "virtual computing devices" available for their use via computing servers (which provide computing instances via one or both of a central processing unit (CPU) and a graphics processing unit (GPU) optionally used with local storage devices) and block storage servers (which provide virtualized persistent block storage for specified computing instances). These virtual computing devices have the attributes of a personal computing device, including hardware (various types of processors, local memory, random access memory (RAM), hard disk and / or solid-state drive (SSD) storage devices), operating system options, networking capabilities, and pre-loaded application software. Each virtual computing device can also provide its console input and output (...). Example Virtualization (keyboard, monitor, and mouse). This virtualization allows users to connect to their virtual computing device using computer applications such as browsers, APIs, and software development kits (SDKs) to configure and use their virtual computing device just like a personal computing device. Unlike a personal computing device, which has a fixed amount of hardware resources available to the user, the hardware associated with a virtual computing device can be scaled up or down depending on the resources the user needs.

[0047] As indicated above, users can access various interfaces 206 via intermediate network 212. For example An API (Application Programming Interface) connects to virtualized computing devices and other cloud provider network resources and services 203, and configures and manages telecommunications networks such as 5G networks. An API refers to the interface and / or communication protocol between a client device 215 and a server, such that if a client issues a request in a predefined format, the client should receive a response in a specific format or cause a defined action to be initiated. In the context of a cloud provider network, an API provides a gateway for customers to access cloud infrastructure by allowing customers to obtain data from the cloud provider network or to cause actions within the cloud provider network, thereby enabling the development of applications that interact with resources and services hosted in the cloud provider network. APIs also enable different services within the cloud provider network to exchange data with each other. Users can choose to deploy their virtual computing systems to provide network-based services for their own use and / or for use by their customers or clients.

[0048] The cloud provider network 203 may include what is referred to as the underlying physical network. For example(Metal enclosures, cables, rack hardware). The underlying layer can be viewed as a network structure containing the physical hardware running the provider's network services. The underlying layer may be isolated from the rest of the cloud provider network 203; for example, it may not be possible to route from the underlying network address to addresses in the production network running the cloud provider's services, or to the customer network hosting customer resources.

[0049] Cloud provider network 203 may also include an overlay network of virtualized computing resources running on the underlying layer. In at least some implementations, management programs or other devices or processes on the network layer may use encapsulation protocol techniques to encapsulate and route network packets between client resource instances on different hosts within the provider network via the network layer. For example For example (Client IP packets). Encapsulation protocol technology can be used at the network layer to route encapsulated packets (also known as network layer packets) between endpoints at the network layer via overlay network paths or routes. Encapsulation protocol technology can be viewed as providing a virtual network topology overlayed at the network layer. Therefore, the structure of the overlay network can be determined based on ( For example This can be a virtual network, referred to as a Virtual Private Cloud (VPC), or a port / protocol firewall configuration, referred to as a security group, that routes network packets along the underlying network. A mapping service (not shown) coordinates the routing of these network packets. The mapping service can be a regional distributed lookup service that maps a combination of Internet Protocol (IP) overlays and network identifiers to the underlying IP, enabling distributed underlying computing devices to find out where to send packets.

[0050] For illustration purposes, each physical host device ( For example Compute servers, block storage servers, object storage servers, and control servers can have IP addresses in the underlying network. Hardware virtualization technology enables multiple operating systems to run concurrently on a host computer, for example, as virtual machines (VMs) on a compute server. A hypervisor or virtual machine monitor (VMM) on the host assigns host hardware resources among the various VMs and monitors their execution. Each VM can be assigned one or more IP addresses overlaying the network, and the VMM on the host is aware of the IP addresses of the VMs on the host. The VMM (and / or other devices or processes at the network layer) can use encapsulation protocol techniques to encapsulate network packets. For example(Client IP packets) and routed across virtualized resources on different hosts within the cloud provider network 203 via the network layer. Encapsulation protocol technology can be used at the network layer to route encapsulated packets between endpoints at the network layer via overlay network paths or routes. Encapsulation protocol technology can be viewed as providing a virtual network topology overlayed at the network layer. Encapsulation protocol technology may include a mapping service that maintains a mapping directory that overlays IP addresses (client IP packets) For example The IP address visible to the client is mapped to an underlying IP address (not visible to the client), which can be accessed by various processes on the cloud provider network 203 for routing packets between endpoints.

[0051] As shown in the figure, in various implementation schemes, the traffic and operations at the underlying layer of the cloud provider network can be broadly subdivided into two categories: control plane traffic carried on the logical control plane 218 and data plane operations carried on the logical data plane 221. While the data plane 221 represents the movement of user data through the distributed computing system, the control plane 218 represents the movement of control signals through the distributed computing system. The control plane 218 typically includes one or more control plane components or services distributed across and implemented by one or more control servers. Control plane traffic typically includes management operations such as establishing isolated virtual networks for various customers, monitoring resource utilization and health, identifying specific hosts or servers to start a requested compute instance, provisioning additional hardware as needed, etc. The data plane 221 includes customer resources implemented on the cloud provider network (…). For example (Compute instances, containers, block storage volumes, databases, file storage). Data plane traffic typically includes non-management operations, such as transferring data to and from client resources.

[0052] Control plane components are typically implemented on a separate set of servers from the data plane servers, and control plane traffic and data plane traffic can be sent over separate / different networks. In some implementations, control plane traffic and data plane traffic may be supported by different protocols. In some implementations, messages sent over the cloud provider network 203 ( For example (Grouping) includes flags used to indicate whether the traffic is control plane traffic or data plane traffic. In some implementations, the traffic payload can be examined to determine its type ( For example (Whether it's the control plane or the data plane). Other techniques are possible for differentiating traffic types.

[0053] As shown in the figure, data plane 221 may include one or more computing servers, which may be bare metal ( For exampleThese compute servers can be single tenants or can be virtualized by a hypervisor to run multiple VMs (sometimes referred to as "instances") or microVMs for one or more customers. These compute servers may support virtualized compute services (or "hardware virtualization services") of a cloud provider's network. Virtualized compute services may be part of control plane 218, allowing customers to access the virtualized compute services via interface 206. For example APIs issue commands to start and manage compute instances of their applications. For example Virtualized computing services can provide virtual computing instances with different computing and / or storage resources. In one implementation, each virtual computing instance may correspond to one of several instance types. Instance types may be characterized by their hardware type, computing resources (VMs, containers). For example The number, type, and configuration of CPUs or CPU cores), and memory resources ( For example Local storage capacity, type, and configuration), storage resources ( For example Locally accessible storage device capacity, type, and configuration), network resources ( For example (The characteristics of its network interface and / or network capabilities) and / or other suitable descriptive characteristics. Functionality can be selected using the instance type. For example The instance type is selected for the customer (at least in part) based on input from the customer. For example, the customer can choose an instance type from a set of predefined instance types. As another example, the customer can specify the expected resources and / or workload requirements for the instance type and the instance type selection functionality can be based on such specifications to select the instance type.

[0054] Data plane 221 may also include one or more block storage servers, which may include persistent storage devices for storing customer data volumes and software for managing these volumes. These block storage servers may support managed block storage services for cloud provider networks. The managed block storage service may be part of control plane 218, allowing customers to access the cloud via interface 206. For exampleThe API (Application Programming Interface) issues commands to create and manage volumes of applications running on compute instances. A block storage server comprises one or more servers on which data is stored as blocks. A block is a sequence of bytes or bits, typically containing a certain integer number of records, with a maximum length of block size. Block data is typically stored in a data buffer and read or written in whole blocks at a time. Generally, a volume can correspond to a logical collection of data, such as a set of data maintained on behalf of a user. A user volume consists of one or more blocks stored on a block storage server, and the user volume can be considered as a single hard drive ranging in size from, for example, 1 GB to 1 terabyte (TB) or larger. Although considered as a single hard drive, it should be understood that a volume can be stored as one or more virtualized devices implemented on one or more underlying physical host devices. A volume can be partitioned several times (…). For example (up to 16 times), where each partition is hosted on a different host. Volume data can be replicated across multiple devices within a cloud provider's network to provide multiple copies of the volume (where such copies can collectively represent the volume on the computing system). Volume replicas in a distributed computing system can beneficially provide automatic failover and recovery, for example, by allowing users access to a primary copy of the volume or a secondary copy of the volume synchronized with the primary copy at the block level, so that failure of the primary or secondary copy does not prevent access to volume information. The primary copy's role can be to facilitate reads and writes on the volume (sometimes referred to as "input / output operations" or simply "I / O operations") and propagate any writes to the secondary copy (preferably synchronously along the I / O path, but asynchronous replication can also be used). The secondary copy can be updated synchronously with the primary copy and provide a seamless transition during failover operations, whereby the secondary copy assumes the role of the primary copy, and the former primary copy is designated as the secondary copy or a new replacement secondary copy is provisioned. While some examples in this document discuss primary and secondary copies, it should be understood that a logical volume can include multiple secondary copies. Compute instances can virtualize their I / O to the volume via clients. The client indicates that it enables compute instances to connect to remote data volumes ( For example Instructions that execute I / O operations on a remote data volume (a data volume stored on a physically separate computing device accessed via a network) and on a remote data volume. Clients can access processing units (including computing instances) For example Implemented on the offload card of the server (CPU or GPU).

[0055] Data plane 221 may also include one or more object storage servers, which represent another type of storage device within a cloud provider network. The object storage server includes one or more servers on which data is stored as objects within resources called buckets and is available to support managed object storage services within the cloud provider network. Each object typically includes the stored data, variable metadata enabling the object storage server to analyze various capabilities of the stored object, and a globally unique identifier or key that can be used to retrieve the object. Each bucket is associated with a given user account. Customers can store many objects in their buckets as needed, can write, read, and delete objects in their buckets, and can control access to their buckets and the objects contained therein. Furthermore, in implementations with multiple different object storage service servers distributed across different regions described above, users can select the region (or multiple regions) of the storage bucket, for example, to optimize latency. Customers can use buckets to store various types of objects, including machine images that can be used to boot VMs, and snapshots representing point-in-time views of volume data.

[0056] The Provider Layer Extension 224 (“PSE”) provides the resources and services of the cloud provider network 203 within a separate network (such as a telecommunications network), thereby extending the functionality of the cloud provider network 203 to new locations. For example Due to communication delays with customer devices, legal compliance, and security concerns... For example (Related reasons). In some implementations, the PSE 224 can be configured to provide capacity for cloud-based workloads operating within a telecommunications network. In some implementations, the PSE 224 can be configured to provide core and / or RAN functions for a telecommunications network and can be configured with additional hardware ( For example (Radio access hardware). Some implementations can be configured to allow both, for example by allowing unused capacity from core and / or RAN functions to run cloud-based workloads.

[0057] As indicated, such provider underlying extension 224 may include provider underlying extension 227 for cloud provider network management. For example Formed by servers located in facilities managed by cloud providers that are separate from those facilities associated with cloud provider network 203, and communication service provider underlying extension 230 ( For example (Formed by servers associated with communication service provider facilities), and the underlying extension of the customer management provider 233 ( For example (Formed by servers located on-premises at customer or partner facilities), as well as other possible types of underlying extensions.

[0058] As illustrated in the exemplary provider underlying extension 224, provider underlying extension 224 may similarly include a logical separation between the control plane 236 and the data plane 239, which respectively extend the control plane 218 and data plane 221 of the cloud provider network 203. Provider underlying extension 224 may For example The cloud provider network operator pre-configures appropriate combinations of hardware, software, and / or firmware elements to support various types of compute-related resources and in a manner that reflects the experience of using the cloud provider network. For example, one or more provider underlying extension location servers may be provisioned by the cloud provider to be deployed within provider underlying extension 224. As described above, cloud provider network 203 can provide a set of predefined instance types, each with different types and quantities of underlying hardware resources. Various sizes of each instance type can also be provided. To enable customers to continue using the same instance types and sizes they use in the region within provider underlying extension 224, the servers can be heterogeneous servers. Heterogeneous servers can simultaneously support multiple instance sizes of the same type and can also be reconfigured to host any instance type supported by their underlying hardware resources. Reconfiguration of heterogeneous servers can occur instantly using the available capacity of the servers, i.e., while other VMs are still running and consuming additional capacity on the provider underlying extension location servers. This can improve the utilization of compute resources within the edge location by allowing for better packaging of running instances on the servers and provides a seamless experience regarding instance usage on cloud provider network 203 and provider underlying extension 227 managed by the cloud provider network.

[0059] The provider's underlying extension server can host one or more compute instances. A compute instance can be a VM, or a container that packages code and all its dependencies, allowing applications to run across compute environments. For exampleThis includes VMs and microVMs, which operate quickly and reliably. Additionally, the server can host one or more data volumes if needed by the customer. In the region of cloud provider network 203, such volumes can be hosted on dedicated block storage servers. However, due to the possibility of significantly smaller capacity at provider underlying extension 224 compared to the region, optimal utilization may not be provided if provider underlying extension 224 includes such dedicated block storage servers. Therefore, block storage services can be virtualized within provider underlying extension 224, allowing one of the VMs to run block storage software and store the volume's data. Similar to the operation of block storage services in the region of cloud provider network 203, volumes within provider underlying extension 224 can be replicated for persistence and availability. Volumes can be provisioned in their own isolated virtual network within provider underlying extension 224. Compute instances and any volumes together constitute the provider network data plane 221 extended to data plane 239 within provider underlying extension 224.

[0060] In some implementations, servers within provider underlying extension 224 may host certain local control plane components, such as those that enable provider underlying extension 224 to continue operating in the event of an interruption in the connection back to cloud provider network 203. Examples of such components include: a migration manager that can move compute instances between provider underlying extension servers if availability needs to be maintained; and a key value data store that indicates the location of volume replicas. However, the functionality of control plane 236 for provider underlying extension will generally remain in cloud provider network 203 to allow customers to utilize as much of the provider underlying extension's resource capacity as possible.

[0061] Migration managers can have a centralized coordination component running in a region, and a local controller running on a PSE server (and servers in the cloud provider's data center). When a migration is triggered, the centralized coordination component identifies the target edge location and / or target host, while the local controller coordinates data transfer between the source and target hosts. The described resource movement between hosts in different locations can take one of several forms of migration. Migration refers to moving virtual machine instances (and / or other resources) between hosts in a cloud computing network or between a host outside the cloud computing network and a host within the cloud. Different types of migration exist, including live migration and restart migration. During a restart migration, the customer experiences an interruption and effective power cycle of their virtual machine instances. For example, a control plane service can coordinate a restart migration workflow that involves tearing down the current domain on the origin host and then creating a new domain for the virtual machine instances on the new host. The instances are restarted by shutting down on the origin host and then restarting on the new host.

[0062] Live migration refers to moving running virtual machines or applications between different physical machines without significantly interrupting the availability of the virtual machines. For example The process involves virtual machine downtime that is imperceptible to end users. When the control plane performs a live migration workflow, it creates a new "inactive" domain associated with the instance, while the instance's original domain continues to operate as the "active" domain. The virtual machine's memory (including any state in memory of running applications), storage, and network connectivity are transferred from the original host with the active domain to the destination host with the inactive domain. During the transfer of memory contents to the destination host, the virtual machine may be briefly paused to prevent state changes. The control plane can transition an inactive domain to become an active domain and demote the original active domain to an inactive domain (sometimes called "flipping"), after which the inactive domain can be discarded.

[0063] Technologies used for various types of migration involve managing a critical phase: the time virtual machine instances are unavailable to clients, which should be kept as short as possible. This can be particularly challenging in currently disclosed migration technologies because resources are being moved between hosts in geographically separated locations connected by one or more intermediate network links. For live migration, disclosed technologies may dynamically determine which memory pages to pre-copy, for example, based on latency between locations, network bandwidth / usage patterns, and / or based on which memory pages the instance most frequently uses. For example (while the instance is still running on the source host) and to replicate later ( For example This refers to the amount of memory state data (after the instance begins running on the destination host). Furthermore, the specific time for transferring memory state data can be dynamically determined based on network conditions between locations. This analysis can be performed by a migration management component within the region or by a migration management component running locally at the source edge location. If the instance already has access to virtualized storage, both the source and destination domains can be attached to the storage device simultaneously, enabling uninterrupted access to its data during migration and in cases where a rollback to the source domain is required.

[0064] Server software running on Provider Underlying Extension 224 may be designed by the cloud provider to run on the cloud provider's underlying network, and the software may be able to create a private copy of the underlying network ("shadow underlying") within the edge location by running unmodified in Provider Underlying Extension 224 using a local network manager 242. The local network manager 242 may run on the Provider Underlying Extension 224 server and bridge the shadow underlying network with Provider Underlying Extension 224, for example, by acting as a Virtual Private Network (VPN) endpoint or an endpoint between Provider Underlying Extension 224 and proxies 245, 248 in the cloud provider network 203, and by implementing a mapping service (for traffic encapsulation and decapsulation) to associate data plane traffic (from data plane proxy 248) and control plane traffic (from control plane proxy 245) with appropriate servers. By implementing a local version of the provider network's underlying overlay mapping service, the local network manager 242 allows resources in Provider Underlying Extension 224 to communicate seamlessly with resources in the cloud provider network 203. In some implementations, a single local network manager 242 may perform these actions for all servers hosting compute instances in Provider Underlying Extension 224. In other implementations, each of the servers hosting the compute instances may have a dedicated local network manager 242. In a multi-rack edge location, inter-rack communication can be achieved through the local network manager 242, where the local network managers maintain open tunnels between each other.

[0065] The provider's underlying extension location can utilize secure networking tunnels through the provider's underlying extension 224 network to the cloud provider network 203, for example, to maintain the security of customer data when traversing the provider's underlying extension 224 network and any other intermediate networks (potentially including the public internet). Within the cloud provider network 203, these tunnels are comprised of isolated virtual networks (VINs). For example This consists of virtual infrastructure components including a control plane proxy 245, a data plane proxy 248, and an underlying network interface, all within the overlay network. These proxies 245 and 248 can be implemented as containers running on compute instances. In some implementations, each server in the underlying extension 224 location of the provider hosting the compute instances can utilize at least two tunnels: one for control plane traffic (…). For exampleThis includes CoAP (Coordinated Application Protocol) traffic, and a tunnel used to encapsulate data plane traffic. A connectivity manager (not shown) within the cloud provider network 203 manages their cloud provider network-side lifecycle, for example, by automatically provisioning these tunnels and their components as needed and maintaining them in a healthy operational state. In some implementations, a direct connection between the provider underlying extension 224 location and the cloud provider network 203 can be used for control and data plane communication. Compared to VPNs over other networks, a direct connection can provide constant bandwidth and more consistent network performance because its network path is relatively fixed and stable.

[0066] A control plane (CP) agent 245 can be provisioned in the cloud provider network 203 to represent a specific host in an edge location. The CP agent 245 acts as an intermediary between the control plane 218 in the cloud provider network 203 and the control plane 236 in the provider underlying extension 224. Specifically, the CP agent 245 provides the infrastructure for tunneling management API traffic destined for the provider underlying extension server from the region layer to the provider underlying extension 224. For example, the virtualized compute service of the cloud provider network 203 can issue commands to the VMM of the server in the provider underlying extension 224 to start compute instances. The CP agent 245 maintains a tunnel to the local network manager 242 of the provider underlying extension. For example (VPN). The software implemented in CP Proxy 245 ensures that only well-formed API traffic leaves and returns to the underlying layer. CP Proxy 245 provides a mechanism to expose remote servers on the cloud provider's underlying layer while still protecting the underlying security materials. For example The encryption key and security token do not leave the cloud provider network 203. The one-way control plane traffic tunnel imposed by the CP agent 245 also prevents any (potentially compromised) device from calling back to the underlying layer. The CP agent 245 can be instantiated one-to-one with a server at the provider's underlying extension 224, or may be able to manage control plane traffic for multiple servers in the same provider's underlying extension.

[0067] Data plane (DP) proxy 248 may also be provisioned in cloud provider network 203 to represent a specific server in provider underlying extension 224. DP proxy 248 acts as a shadow or anchor point for the server and can be used by services within cloud provider network 203 to monitor the health of the host (including its availability, used / idle compute and capacity, used / idle storage and capacity, and network bandwidth utilization / availability). DP proxy 248 also allows isolated virtual networks to cross provider underlying extension 224 and cloud provider network 203 by acting as proxies for servers in cloud provider network 203. Each DP proxy 248 can be implemented as a packet-forwarding compute instance or container. As shown, each DP proxy 248 can maintain a VPN tunnel with a local network manager 242 that manages traffic to the server represented by the DP proxy 248. The tunnel can be used to send data plane traffic between the provider underlying extension server and cloud provider network 203. Data plane traffic flowing between provider underlying extension 224 and cloud provider network 203 can be routed through a DP proxy 248 associated with provider underlying extension 224. For data plane traffic flowing from provider underlying extension 224 to cloud provider network 203, DP proxy 248 can receive the encapsulated data plane traffic, verify its correctness, and allow it into cloud provider network 203. DP proxy 248 can then forward the encapsulated traffic directly from cloud provider network 203 to provider underlying extension 224.

[0068] Local network manager 242 can provide secure network connectivity with agents 245, 248 established in cloud provider network 203. Once a connection is established between local network manager 242 and agents 245, 248, the customer can issue commands via interface 206 to instantiate (and / or perform other operations using) compute instances in a manner similar to how such commands would be issued to compute instances hosted within cloud provider network 203. From the customer's perspective, the customer can now seamlessly use local resources within the provider underlying extension (and resources located in cloud provider network 203, if needed). Compute instances hosted on servers at provider underlying extension 224 can communicate with electronic devices located on the same network, and, as needed, with other resources hosted in cloud provider network 203. Local gateway 251 can be implemented to provide provider underlying extension 224 with the network associated with said extension ( FIG. 1A Network connectivity between communication service provider networks (in the example of communication service provider network in the underlying extension 230 of communication service provider).

[0069] There may be situations where data needs to be transferred between the object storage service and the provider's underlying extension (PSE) 224. For example, the object storage service may store machine images used to launch VMs, as well as snapshots representing point-in-time backups of volumes. The object gateway can be provided on a PSE server or dedicated storage device and provides customers with configurable bucket-by-bucket caching of the contents of object storage buckets within its PSE 224 to minimize the impact of PSE region latency on customer workloads. The object gateway can also temporarily store snapshot data from snapshots of volumes within the PSE 224 and then synchronize it with the object server in the region, where possible. The object gateway can also store machine images specified by the customer for use within the PSE 224 or at the customer's premises. In some implementations, data within the PSE 224 can be encrypted with a unique key, and for security reasons, the cloud provider may restrict key sharing from the region to the PSE 224. Therefore, data exchanged between the object storage server and the object gateway can utilize encryption, decryption, and / or re-encryption to maintain secure boundaries regarding encryption keys or other sensitive data. The transformation intermediary can perform these operations and can create PSE buckets (on the object storage server) using PSE encryption keys to store snapshot data and machine image data.

[0070] In this manner, PSE 224 forms an edge location because it provides the resources and services of the cloud provider network 203 outside of the traditional cloud provider data center and closer to the customer's equipment. Edge locations, as referred to herein, can be structured in various ways. In some implementations, an edge location can be an extension of the underlying cloud provider network, including outside of the Availability Zone (AZ). FIG. 1A A near zone is a limited amount of capacity provided in a cloud provider's small data center or other facilities located near the customer's workload and potentially far from any availability zone. Such edge locations can be referred to as "far zones" (due to their distance from other availability zones) or "near zones" (due to their proximity to the customer's workload). Near zones can be connected to public, accessible networks such as the Internet in various ways, such as directly, via another network, or via a dedicated connection to the region. While near zones typically have more limited capacity compared to a region, in some cases, they can have considerable capacity, such as thousands or more racks.

[0071] In some implementations, the edge location can be an extension of the underlying cloud provider network, consisting of one or more servers located locally at the customer's or partner's facility, where such servers are connected via a network ( FIG. 1AThis type of underlying extension, located outside the cloud provider's network data center, communicates with a nearby availability zone or area of ​​the cloud provider's network (a publicly accessible network, such as the Internet). This extension can be referred to as an "outpost" of the cloud provider's network. Some outposts may be integrated into the communications network, for example, as multi-access edge computing (MEC) sites, whose physical infrastructure is distributed across telecommunications data centers, telecommunications aggregation sites, and / or telecommunications base stations within the telecommunications network. In a local example, the limited capacity of an outpost may be available only to customers who own the premises (and any other accounts permitted by the customer). In a telecommunications example, the limited capacity of an outpost may be available to multiple applications (such as those sending data to users on the telecommunications network) FIG. 1A Shared between (games, virtual reality applications, healthcare applications).

[0072] Edge locations may include data plane capacity that is at least partially controlled by the control plane of a nearby availability zone within the provider network. Therefore, an availability zone group may include a "parent" availability zone and zones belonging to that parent availability zone (…). For example Any "sub" edge location (at least partially controlled by its control surface). Certain limited control surface functionality ( For example Features requiring low-latency communication with customer resources, and / or features enabling edge locations to continue operating when disconnected from the parent availability zone, may also exist in some edge locations. Therefore, in the example above, an edge location refers to an extension of at least the data plane capacity located at the edge of the cloud provider's network, close to customer devices and / or workloads.

[0073] exist and the like In the example, distributed computing device 112 ( For example ), centralized computing device 115 ( FIG. 2B ) and core computing device 118 ( FIG. 1A This can be implemented as a provider underlying extension 224 for cloud provider network 203. The installation or location of the provider underlying extension 224 within communication network 100 may vary depending on the specific network topology or architecture of communication network 100. The provider underlying extension 224 can typically be connected to communication network 100 and can interrupt packet-based traffic (…). FIG. 2B (IP-based traffic) anywhere. Additionally, communication between a given provider underlying extension 224 and the cloud provider network 203 typically securely relays at least a portion of the communication network 100 ( FIG. 3 via secure tunnels, virtual private networks, and direct connections FIG. 2A ).

[0074] In 5G wireless network development, edge locations can be considered a possible implementation of Multi-Access Edge Computing (MEC). Such edge locations can connect to various points within the 5G network that provide interruption for data traffic as part of the User Plane Function (UPF). Older wireless networks can also include edge locations. For example, in a 3G wireless network, edge locations can connect to the packet-switched network portion of communication network 100, such as connecting to the Serving General Packet Radio Service Support Node (SGSN) or the Gateway General Packet Radio Service Support Node (GGSN). In a 4G wireless network, edge locations can connect to the Serving Gateway (SGW) or Packet Data Network Gateway (PGW) as part of the core network or Evolved Packet Core (EPC). In some implementations, traffic between the Provider Underlying Extension 224 and the Cloud Provider Network 203 can bypass communication network 100 without being routed through the core network.

[0075] In some implementations, the provider underlying extension 224 may connect to more than one communication network 100 associated with a given customer. For example, the provider underlying extension 224 may connect to both networks when two communication networks 100 of the given customer share or route traffic through a common point. For example, each customer may assign a portion of its network address space to the provider underlying extension, and the provider underlying extension may include a router or gateway that can distinguish traffic exchanged with each of the communication networks 100. For example, traffic destined for the provider underlying extension 224 from one network may have different destination IP addresses, source IP addresses, and / or virtual LAN (VLAN) tags compared to traffic received from another network. Traffic originating from the provider underlying extension and destined for one of the networks may similarly be encapsulated with appropriate VLAN tags, source IP addresses, and source IP addresses. For example (From the pool of addresses assigned from the destination network address space to the provider’s underlying extension) and the destination IP address.

[0076] For example Depicts a communication network 100 for providing highly available user plane functionality (UPF). Example Example 253 of the cellularization and geographic distribution of ) . In For exampleIn this configuration, user device 254 communicates with request router 255 to route the request to one of multiple control plane cells 257a and 257b. Each control plane cell 257 may include a network services API gateway 260, network slice configuration 262, network services monitoring functionality 264, site planning data 266 (including a description of the layout, device type, number of devices, etc., of customer site requirements), a network services / functional catalog 268, orchestration network functionality 270, and / or other components. Larger control planes can be divided into multiple cells to reduce the likelihood of large-scale errors affecting a wide range of customers, for example, by having one or more cells per customer, per network, or per independently operating area.

[0077] The Network Service / Function Catalog 268 is also known as the NF Repository Function (NRF). In a Service-Based Architecture (SBA) 5G network, control plane functions and a common data repository can be delivered through a set of interconnected network functions built using a microservices architecture. The NRF maintains a record of available NF instances and the services they support, allowing other NF instances to subscribe and be notified of registrations from NF instances of a given type. Thus, the NRF supports service discovery by receiving discovery requests from NF instances along with details of which NF instances support specific services. The Orchestration Network Function 270 can perform NF lifecycle management, including instantiation, outward / inward scaling, performance measurement, event association, and termination. The Network Function Orchestrator 270 can also load new NFs, manage migrations to new or updated versions of existing NFs, identify NF sets suitable for specific network slices or larger networks, and orchestrate NFs among different computing devices and sites constituting the radio-based network 103.

[0078] Control plane cell 257 can communicate with one or more cell sites 272, one or more customer local data centers 274, one or more local areas 276, and one or more regional areas 278. Cell site 272 includes computing hardware 280 that performs one or more distributed unit (DU) network functions 282. Customer local data center 274 includes computing hardware 283 that performs one or more DU or central unit (CU) network functions 284, a network controller, a UPF 286, one or more edge applications 287 corresponding to customer workloads, and / or other components.

[0079] This region 276 (which may be located in a data center operated by a cloud service provider) may perform one or more core network functions 288, such as AMF, SMF, Network Open Function (NEF) which securely exposes services and capabilities of other network functions, and Unified Data Management (UDM) functions that manage subscriber data used for authorization, registration, and mobility management. This region 276 may also perform UPF 286, metric processing services 289, and one or more edge applications 287.

[0080] The regional zone 278 (which may be located in a data center operated by a cloud service provider) may perform one or more core network functions 288; UPF 286; an operations support system (OSS) 290 that supports network management systems, service delivery, service implementation, service assurance, and customer service; an Internet Protocol Multimedia Subsystem (IMS) 291; a business support system (BSS) 292 that supports product management, customer management, revenue management, and / or order management; one or more portal applications 293, and / or other components.

[0081] In this example, the communication network 100 employs a cellular architecture to reduce the blast radius of individual components. At the top level, the control plane is located in multiple control plane cells 257 to prevent individual control plane failures from affecting all deployments.

[0082] Within each control plane cell 257, multiple redundant stacks can be provided, where the control plane offloads traffic to secondary stacks as needed. For example, cell site 272 can be configured to utilize the nearby local area 276 as its default core network. In the event of an outage in local area 276, the control plane can redirect cell site 272 to use a backup stack in regional area 278. Traffic typically routed from the Internet to local area 276 can be offloaded to endpoints in regional area 278. Each control plane cell 257 can implement a stateless architecture that shares a common session database across multiple sites, such as across availability zones or edge sites.

[0083] For example This illustrates, according to some implementation schemes, the underlying extensions of geographically dispersed providers 224 ( FIG. 1AAn exemplary cloud provider network 203 (or "edge location 303") is shown. As illustrated, the cloud provider network 203 may be formed as multiple regions 306, where a region is a separate geographical area in which the cloud provider has one or more data centers 309. Each region 306 may include two or more Availability Zones (AZs) interconnected via a dedicated high-speed network such as, for example, fiber optic communication connections. An Availability Zone is an isolated fault domain comprising one or more data center facilities that have separate power, separate networking, and separate cooling relative to other Availability Zones. Cloud providers may endeavor to position Availability Zones within a region, far enough apart that natural disasters, widespread power outages, or other unforeseen events do not cause more than one Availability Zone to go offline simultaneously. Customers can access the network via a publicly accessible network (...). For example Resources within the availability zone of a cloud provider's network (including the internet, cellular networks, and communication service provider networks) are connected to the cloud provider's network. A switching center (TC) is the primary backbone location linking customers to the cloud provider's network and can be shared with other network provider facilities. For example (Internet service providers, telecommunications providers). Each region can operate two or more TCs for redundancy. Region 306 is connected to a global network, which includes a private networking infrastructure connecting each region 306 to at least one other region. For example For example (Fiber optic connections controlled by the cloud service provider). The cloud provider network 203 can deliver content from external but networked points of presence (PoPs) to these regions 306 via edge locations 303 and regional edge caching servers. This partitioning and geographical distribution of computing hardware enables the cloud provider network 203 to provide customers with low-latency resource access globally with high fault tolerance and stability.

[0084] The number of edge locations 303 can be significantly higher than the number of regional data centers or availability zones. This widespread deployment of edge locations 303 can provide low-latency connectivity to the cloud for a much larger group of end-user devices (compared to those groups of end-user devices that happen to be very close to a regional data center). In some implementations, each edge location 303 may correspond to a portion of the cloud provider network 203. and the like (Parent availability zone or regional data center). This peering allows various components operating within the cloud provider network 203 to manage the computing resources of the edge location 303. In some cases, multiple edge locations 303 may be located in or installed in the same facility (parent availability zone or regional data center). FIG. 1A (a separate rack for the computer system) and managed by different zones or data centers to provide additional redundancy. It should be noted that although edge location 303 is generally described herein as being in a communications service provider network or a radio-based network 103 (… FIG. 3However, in some cases, such as when the cloud provider network facility is relatively close to the communication service provider facility, the edge location 303 may remain within the physical premises of the cloud provider network 203 while being connected to the communication service provider network via fiber optic or other network links.

[0085] Edge location 303 can be structured in several ways. In some implementations, edge location 303 can be an extension of the underlying cloud provider network, including outside of the Availability Zone. FIG. 4 Edge locations 303 offer limited capacity in small data centers of cloud providers or other facilities located near customer workloads and potentially far from any availability zone. Such edge locations 303 may be referred to as local regions (due to their more local or closer proximity to a group of users compared to traditional availability zones). Local regions can be connected to publicly accessible networks such as the Internet through various means, such as directly, via another network, or via a dedicated connection to region 306. While local regions typically have more limited capacity than region 306, in some cases, they can have considerable capacity, such as thousands or more racks. Some local regions may use infrastructure similar to that of a typical cloud provider data center, rather than the edge location 303 infrastructure described herein.

[0086] As indicated herein, the cloud provider network 203 may be configured as multiple regions 306, each region 306 representing a geographical area in which the cloud provider will cluster its data centers. Each region 306 may also include multiple interconnected regions via dedicated high-speed networks such as fiber optic communication connections. and the like Two or more Availability Zones (AZs). An AZ can provide an isolated fault domain comprising one or more data center facilities, which have separate power supplies, separate networking, and separate cooling relative to those data center facilities in another AZ. Preferably, the AZs within zone 306 are far enough apart that the same natural disaster (or other fault-inducing event) will not simultaneously affect or take down more than one AZ. Customers can access the service via a publicly accessible network (…). FIG. 2A (Internet, cellular communication networks) connect to the cloud provider's network in the AZ.

[0087] The parent of an edge location 303 as an Availability Zone (AZ) or Region 306 of a cloud provider network 203 can be based on a number of factors. One such parent factor is data sovereignty. For example, in order to retain data originating from a communication network 100 in a particular country, an edge location 303 deployed in that communication network 100 can serve as the parent of the AZ or Region 306 of that country. Another factor is service availability. For example, some edge locations 303 may have different hardware configurations, such as the presence of components, such as local non-volatile storage devices for customer data (…).Example Solid-state drives and graphics accelerators FIG. 1A Some Availability Zones (AZs) or Areas 306 may lack services that utilize these additional resources; therefore, an edge location can act as a parent to support AZs or Areas 306 that use these resources. Another factor is the latency between an AZ or Area 306 and an edge location 303. While deploying an edge location 303 in the communication network 100 has latency benefits, those benefits can be offset by the edge location 303 acting as a parent to a distant AZ or Area 306, introducing significant latency to traffic from the edge location 303 to the area. Therefore, an edge location 303 is often a parent to a nearby AZ or Area 306 (in terms of network latency).

[0088] In some implementations, a customer can configure one or more geographic regions 312 in one or more locality rules, enabling the customer's radio-based network 103 ( FIG. 3 The data in ) needs to be retained within the defined geographic region 312. For example For example As shown, example geographic region 312 includes a portion of two regions 306, which includes two data centers 309 and six edge locations 303, but excludes the two other edge locations 303 within region 306. In other words, regions 306, edge locations 303, and communication links outside geographic region 312 cannot be used to process, store, or route network traffic that needs to be kept within geographic region 312, such that the portion of this topology corresponding to one or more identified categories of network traffic processed by radio-based network 103 can be comprised of physical hardware located within geographic region 312. In other examples, geographic region 312 may include a single region 306, a portion of a single region 306, or more than two regions 306.

[0089] refer to FIG. 1A The diagram illustrates a networking environment 400 according to various implementation schemes. The networking environment 400 includes a computing environment 403, one or more client devices 406, one or more pre-deployed devices 409, a spectrum reservation service 410, and one or more radio-based networks 103 that communicate with each other via a network 412. The network 412 includes, for example, the Internet, an intranet, an extranet, a wide area network (WAN), a local area network (LAN), a wired network, a wireless network, a cable television network, a satellite network, or other suitable networks. and the like or any combination of two or more such networks.

[0090] Computing environment 403 may include, for example, server computers or any other system providing computing capacity. Optionally, computing environment 403 may employ multiple computing devices, which may be arranged, for example, in one or more server groups or computer groups or other arrangements. Such computing devices may be located in a single device or may be distributed across many different geographical locations. For example, computing environment 403 may include multiple computing devices, which together may include hosted computing resources, grid computing resources, and / or any other distributed computing arrangements. In some cases, computing environment 403 may correspond to elastic computing resources, where the allocated capacity of processing, networking, storage, or other computing-related resources may vary over time. For example, computing environment 403 may correspond to cloud provider network 203 ( and the like The utility-based computing model charges customers based on their computing resource usage.

[0091] In some implementations, computing environment 403 may correspond to a virtualized private network within a physical network, including For example For example Virtual machine instances that run on physical computing hardware via a hypervisor. These virtual machine instances and any containers running on them obtain network connectivity through virtualized network components enabled by physical network components such as routers and switches.

[0092] According to various implementation schemes, various applications and / or other functions can be executed in the computing environment 403. Furthermore, various data are stored in data storage areas 415 accessible to the computing environment 403. It is understood that data storage area 415 may represent multiple data storage areas 415. The data stored in the data storage areas 415 is associated, for example, with the operation of the various applications and / or functional entities described below.

[0093] The computing environment 403, as part of a cloud provider network offering utility computing services, includes computing devices 418 and other types of computing devices. Computing devices 418 may correspond to different types of computing devices 418 and may have different computing architectures. The computing architecture may differ due to the use of processors with different architectures, such as x86, x86_64, ARM, Scalable Processor Architecture (SPARC), PowerPC, etc. For example, some computing devices 418 may have x86 processors, while others may have ARM processors. Computing devices 418 may also differ in terms of available hardware resources, such as local storage, graphics processing units (GPUs), machine learning extensions, and other features.

[0094] Computing device 418 can have various forms of allocated computing capacity 421, which may include virtual machine (VM) instances, containers, serverless functions, and so on. VM instances can be instantiated from VM images. For this purpose, customers can specify that VM instances should be launched in a specific type of computing device 418, rather than in other types of computing devices 418. In various examples, a single VM instance may run on a specific computing device 418, or multiple VM instances may run on a specific computing device 418. Furthermore, a specific computing device 418 can run different types of VM instances, which can provide different amounts of available resources via the computing device 418. For example, some types of VM instances can provide more memory and processing power compared to other types of VM instances.

[0095] For example, components executing on computing environment 403 include radio-based network (RBN) management service 424, network slice allocation service 425, RBN hardware configuration service 427, RBN hardware deployment service 430, locality orchestration service 433, and other applications, services, processes, systems, engines, or functions not discussed in detail herein.

[0096] RBN management service 424 is executed to manage, configure, and monitor radio-based network 103 operated by the cloud service provider on behalf of the customer. To this end, RBN management service 424 can generate multiple user interfaces that allow the customer to order new radio-based networks 103, scale up or down existing radio-based networks 103, modify the operation of existing radio-based networks 103, and configure wireless devices 106 permitted to use radio-based networks 103. and the like ), provides statistics and metrics on the operation of radio-based network 103, reserves spectrum for a customer's private network via spectrum reservation service 410, and allows the customer to define one or more locality rules 434 and one or more geographic areas 312 to which the customer applies. For example For example, RBN management service 424 can generate one or more web pages, such as web pages, including a user interface. Furthermore, RBN management service 424 can support this functionality through an API that can be called by client application 436. In addition to facilitating user interaction, RBN management service 424 also implements the orchestration of deployment and configuration changes to radio-based network 103 and continuous monitoring of performance parameters. In some cases, RBN management service 424 can generate network plans 439 for clients based at least in part on client location specifications, automated site surveys by unmanned aerial vehicles, and / or other input parameters.

[0097] The network slice allocation service 425 performs network slice allocation to application and / or client devices 406 connected to the radio-based network 103 with an associated core network. As used herein, the term "network slice" refers to specific network traffic assigned one or more specific locality rules 434, prioritized according to one or more quality of service requirements, and / or provided with hardware capacity reservations for receiving, transmitting, or managing network traffic. Network sliced ​​network traffic can be identified at one or more network layers, such as the application layer (…). and the like Network slices can be allocated at the deep packet inspection (DPI) layer, session layer, transport layer, network layer, or data link layer. A network slice may be transient, or have a specific duration in terms of time or data volume, or may exist until it is released or canceled. The network slice allocation service 425 may support application programming interfaces (APIs) that can be invoked by applications on client devices 406 and / or backend services that interact with these applications to request that network slices be allocated, modified, or released. Although the network slice allocation service 425 allocates network slices on the radio-based network 103, there may be one or more devices coupled to the radio-based network 103 via one or more fixed or wired links, and the network slices determined by the network slice allocation service 425 may also be applicable to such devices.

[0098] To allocate network slices, network slice allocation service 425 can dynamically configure one or more network functions in radio-based network 103 to implement locality rules 434 and / or quality of service requirements for network traffic that meets the network slice definition. Note that network slices may have higher or lower priority than normal traffic, and may have corresponding costs that are higher or lower than normal usage costs. In some scenarios, network slice allocation service 425 can increase or decrease the computing capacity 421 allocated to network function workloads to meet specified quality of service requirements. For example, allocating more computing capacity 421 to a network function implementing a network slice can provide lower latency. In some implementations, network slice allocation service 425 can also reschedule network function workloads at different points in radio-based network 103 to meet quality of service requirements.

[0099] In some implementations, application developers or owners can specify the desired network slice configuration in an application template used to deploy a specific application in the cloud provider network 203, allowing the application to provide this information to the network slice allocation service 425 when making an API-based request for a network slice. In some implementations, the network slice allocation service 425 automatically determines one or more optimal network slices for a customer's application or their entire radio-based network 103. To do this, the network slice allocation service 425 can train one or more machine learning models to identify network slice configurations based on customer or cross-customer criteria. The machine learning models can then be used to identify the optimal network slice to allocate to a given device type or application that is determined to exist in the radio-based network 103. For example, the network slice allocation service 425 can receive detailed network information or automatically probe the radio-based network 103 to understand devices, applications, latency, usage patterns, etc. The network slice allocation service 425 can then feed this information to the machine learning model to automatically determine one or more network slices to optimize latency, bandwidth, reliability, or other metrics. These automatically determined network slices can then be automatically allocated by the network slice allocation service 425.

[0100] RBN hardware configuration service 427 is executed to implement configuration changes to the hardware implementing the radio-based network 103. The hardware may include radio units, antennas, VM instances or containers performing network functions, routers, switches, fiber optic terminal equipment, etc. For example, an antenna may be configured to operate at a specific frequency. A radio unit may be programmed to operate at a specific frequency, join a specific radio-based network 103, and backhaul traffic to a specific VM instance or container.

[0101] In some scenarios, RBN hardware configuration service 427 is executed to reconfigure hardware already existing in radio-based network 103. In other scenarios, RBN hardware configuration service 427 is executed to preconfigure groups of hardware to be deployed to existing or new radio-based network 103. For this purpose, RBN hardware configuration service 427 can implement configuration on one or more pre-deployment devices 409 temporarily connected to network 412 to facilitate pre-configuration before the pre-deployment devices 409 are shipped to customers for deployment in radio-based network 103.

[0102] RBN hardware deployment service 430 automates and deploys hardware to implement radio-based network 103. Based on network planning 439 submitted by or generated for a customer, RBN hardware deployment service 430 can arrange the procurement of hardware components required for implementing radio-based network 103. This may involve automatically ordering new equipment from vendors, retaining existing equipment in vendor inventory, or reallocating equipment already present at a customer site or other customer sites (where the equipment to be reallocated is no longer in use). In this regard, RBN hardware deployment service 430 can send instructions to customers to return unused equipment, which can then be directly sent to other customers for use in another deployment. In another scenario, RBN hardware deployment service 430 can send instructions to customers to move a device from a site where it is no longer in use to another site where it will be used. RBN hardware deployment service 430 can manage device connectivity to network 412 for pre-configuration as pre-deployment device 409. RBN hardware deployment service 430 can also arrange the delivery of equipment to customer locations, including multiple customer locations that may correspond to various cell sites.

[0103] The local orchestration service 433 is executed to enforce one or more local rules 434 configured for the customer regarding radio-based network 103 or network slices on radio-based network 103. In some implementations, the local orchestration service 433 may be executed when the RBN management service 424 is planning, creating, or provisioning radio-based network 103, such that all elements of radio-based network 103 (including network functions, data storage, cell equipment, and communication links) are within one or more geographic areas 312 as defined in the local rules 434. In other implementations, the local orchestration service 433 is executed when the network slice allocation service 425 allocates network slices in radio-based network 103 such that all elements implementing the network slices (including network functions, data storage, cell equipment, and communication links) are within one or more geographic areas 312 as defined in the local rules 434. When resources allocated to radio-based network 103 or network slices conforming to locality rule 434 are scaled, locality orchestration service 433 may also be performed to ensure that additional resources added to radio-based network 103 or network slices conform to locality rule 434. In some implementations, locality orchestration service 433 may create one or more gateways to connect restricted radio-based network 103 or restricted network slices to other segments of radio-based network 103 or the Internet, and then apply policy rules to limit and restrict network traffic, allowing clients to know and confirm where violations of locality rule 434 exist.

[0104] The data stored in data storage area 415 includes, for example, one or more network plans 439, one or more cellular topologies 442, one or more spectrum assignments 445, device data 448, one or more RBN metrics 451, customer billing data 454, radio unit configuration data 457, antenna configuration data 460, network function configuration data 463, one or more network function workloads 466, one or more customer workloads 469, data about one or more network slices 470 (including one or more QoS requirements 471 and one or more locality rules 434), one or more locality rules 434 and / or potentially other data.

[0105] Network planning 439 is a specification for the radio-based network 103 to be deployed for customers. For example, network planning 439 may include the locations, geographical areas 312 to be covered, the number of cells 109, etc. For example The network plan 439 may include device identification information and licenses, the expected maximum network latency, the expected bandwidth or network throughput for one or more types of devices, one or more quality of service parameters for the application or service, and / or other parameters that may be used to create the radio-based network 103. Customers may manually specify one or more of these parameters via a user interface. One or more parameters may be pre-populated as default parameters. In some cases, the network plan 439 may be generated for the customer based at least in part on automated site surveys using unmanned aerial vehicles. The parameter values ​​defining the network plan 439 may be used as the basis for cloud service providers to bill customers under a utility calculation model. For example, in a service level agreement (SLA), a customer may be charged more for lower latency targets and / or higher bandwidth targets, and may be charged per device, per cell, based on service geographic area 312, based on spectrum availability, etc. In some cases, the network plan 439 may include thresholds and reference parameters determined at least in part based on automated probing of the customer's existing private network.

[0106] Cellular topology 442 includes an arrangement of multiple cells 109 for a customer, taking into account spectrum reuse given the location of each cell 109. Cellular topology 442 can be automatically generated given a site survey. In some cases, the number of cells 109 in cellular topology 442 can be automatically determined based on the desired geographic area 312 to be covered, the availability of backhaul connections at each site, signal propagation, available spectrum, and / or other parameters. For radio-based network 103, cellular topology 442 can be developed to cover one or more buildings in an organizational campus, one or more schools in a school district, one or more buildings in a university or university system, and other areas. Cellular topology 442 can be determined such that cells 109 remain within one or more geographic areas 312 specified by locality rule 434.

[0107] Spectrum allocation 445 includes spectrum available for allocation to radio-based network 103 and spectrum currently allocated to radio-based network 103. Spectrum may include spectrum that is publicly accessible without restrictions, spectrum owned or leased by individual customers, spectrum owned or leased by providers, spectrum that is free to use but requires a reservation, etc.

[0108] Device data 448 corresponds to data describing the wireless device 106 permitted to connect to the radio-based network 103. This device data 448 includes the corresponding user, account information, billing information, data plan, permitted applications or uses, indication of whether the wireless device 106 is mobile or fixed, location, current cell, network address, and device identifier. and the like International Mobile Equipment Identity (IMEI) number, Equipment Serial Number (ESN), Media Access Control (MAC) address, Subscriber Identity Module (SIM) number and the like Device data 448 may comply with the data storage requirements in locality rule 434, such that device data 448 is required to be stored within one or more specific geographic regions 312.

[0109] RBN metric 451 includes various metrics or statistics indicating the performance or health status of the radio-based network 103. Such RBN metric 451 may include bandwidth metrics, packet drop metrics, signal strength metrics, latency metrics, etc. RBN metric 451 can be based on a per-device basis, a per-cell basis, or a per-customer basis. and the like Perform aggregation.

[0110] Customer billing data 454 specifies the charges incurred by a customer for the provider's operation of the radio-based network 103 for the customer. Charges may include fixed costs based on the equipment deployed to the customer and / or usage costs based on utilization determined by tracked usage metrics. In some cases, the customer may purchase the equipment upfront and may only need to pay for bandwidth or backend network costs. In other cases, the customer may not incur any upfront costs and may be charged only based on usage. By providing equipment to customers based on a utility calculation model, cloud service providers can select the optimal configuration of the equipment to meet the customer's target performance metrics while avoiding over-provisioning unnecessary hardware. Customer billing data 454 may comply with the data storage requirements in locality rule 434, requiring customer billing data 454 to be stored within one or more specific geographic regions 312.

[0111] The radio unit configuration data 457 can correspond to the configuration settings of the radio units deployed in the radio-based network 103. Such settings may include the frequency to be used, the protocol to be used, modulation parameters, bandwidth, network routing and / or backhaul configuration, etc.

[0112] Antenna configuration data 460 may correspond to antenna configuration settings, including the frequency to be used, azimuth angle, vertical or horizontal orientation, beam tilt, and / or other parameters that can be automatically controlled or manually controlled by instructing the user to install the antenna in a certain way or to make physical modifications to the antenna. FIG. 5 (Through controls on the motor and antenna connected to the network).

[0113] Network function configuration data 463 corresponds to configuration settings for configuring the operation of various network functions for the radio-based network 103. In various implementations, network functions may be deployed in VM instances or containers located in computing devices 418, situated at a cell site, customer aggregation site, or data center remote from customers. The location of network functions may be controlled at least in part by locality rules 434. Non-limiting examples of network functions may include access and mobility management functions, session management functions, user plane functions, policy control functions, authentication server functions, unified data management functions, application functions, network openness functions, network function repositories, network slice selection functions, and / or other functions. Network function workload 466 corresponds to a machine image, container, or function to be launched in the allocated computing capacity 421 to execute one or more network functions.

[0114] Customer workloads 469 correspond to customer machine images, containers, or functions that may be executed alongside or in place of network function workloads 466 in the allocated computing capacity 421. For example, customer workloads 469 may provide or support customer applications or services. In various examples, customer workloads 469 relate to factory automation, autonomous robots, augmented reality, virtual reality, design, monitoring, and so on.

[0115] Network slice 470 corresponds to a network traffic flow that has been specified for one or more locality rules 434 and / or one or more specific quality of service requirements 471. These flows may correspond to flows associated with a specific application executing on a specific client device 406, all network traffic from a specific client device 406, flows from all client devices 406 to a specific destination, flows from a specific client device 406 to a specific destination, or specific types of traffic (…). FIG. 5 Voice calls, video, text messages, general data FIG. 5 ) streams, etc. In one example, network slice 470 is identified by source port, source network address, destination port, destination network address, and / or other information. Network slice 470 may be valid for a specific time period or a specific amount of data, or network slice 470 may be valid until canceled or released. In one example, network slice 470 is allocated on demand for a specific application executing on client device 406. In some scenarios, network slice 470 has a specific cyclical validity period ( FIG. 4 (Every workday evening from midnight to 5 a.m.), or the quality of service requirements for network slices 470 471 may change based on the cycle time period, current cost level and / or other factors or events.

[0116] Service Quality Requirement 471 may correspond to minimum or maximum bandwidth, minimum or maximum latency, minimum or maximum reliability metrics, minimum or maximum signal strength, etc. Service Quality Requirement 471 may be associated with a corresponding cost level, which may include fixed components, usage-based components, and / or congestion-based components. For example, Service Quality Requirement 471 may be associated with a recurring monthly fixed cost, a cost per session or per megabyte, and / or a dynamic cost based on congestion at a cell site or a specific network link. In some cases, customers may choose Service Quality Requirement 471 to provide a high level of service. However, in other cases, customers may choose Service Quality Requirement 471 to provide a low-cost level but with reduced service quality at certain times or in certain aspects. For example, a customer may choose Service Quality Requirement 471 that allows for high throughput and other lower-priority throughput overnight to send backup data over the network at low cost.

[0117] Locality rule 434 is a customer-specified rule that ensures that at least a subset of network traffic on radio-based network 103 or network traffic on network slice 470 of radio-based network 103 for customer operations is kept within one or more specific geographic regions 312. Locality rule 434 may include identifiers of one or more geographic regions 312 with predefined boundaries, such as country, state, city, postal code, trade zone. FIG. 1A In some cases, locality rule 434 may include any defined geographic region 312 that may correspond to an organizational campus or other area, such as distance from a location, boundaries and limits, cells within a grid, etc. In addition to defining geographic region 312, locality rule 434 may specify the applicable time, event, or season; procedures for requesting and approving exemptions; the type or category of network traffic to which locality rule 434 applies; the users, devices, or applications to which locality rule 434 applies; and allow the use of network traffic or metadata outside geographic region 312. FIG. 4 Storing charge records outside geographic region 312 can be considered acceptable or unacceptable; and other parameters.

[0118] Client device 406 refers to a plurality of client devices 406 that can be coupled to network 412. Client device 406 may include, for example, a processor-based system, such as a computer system. Such a computer system may be embodied in the following forms: desktop computer, laptop computer, personal digital assistant, cellular phone, smartphone, set-top box, music player, network board, tablet computer system, game console, e-book reader, smartwatch, head-mounted display, voice interface device, or other device. Client device 406 may include a display, which includes, for example, one or more devices, such as a liquid crystal display (LCD), a gas plasma-based flat panel display, an organic light-emitting diode (OLED) display, an electrophoretic ink (E-ink) display, an LCD projector, or other types of display devices. FIG. 1A .

[0119] Client device 406 can be configured to execute various applications, such as client application 436 and / or other applications. Client application 436 can execute in client device 406, for example, to access network content provided by computing environment 403 and / or other servers, thereby presenting a user interface on a display. For this purpose, client application 436 may include, for example, a browser, a dedicated application, etc. FIG. 4 Furthermore, the user interface may include web pages and application screens. FIG. 4The client device 406 can be configured to execute applications other than the client application 436, such as, for example, email applications, social networking applications, word processors, spreadsheets, and / or other applications.

[0120] In some implementations, spectrum reservation service 410 provides spectrum reservation for a customer's private network. In one scenario, spectrum reservation service 410 is operated by an entity such as a third party to manage reservations and coexistence in publicly accessible spectrum. An example of such spectrum is the Citizens Broadband Radio Service (CBRS). In another scenario, spectrum reservation service 410 is operated by a telecommunications service provider to sell or sublicense portions of spectrum owned or licensed by the provider.

[0121] Next reference FIG. 4 The diagram illustrates a flowchart of an example of the operation of providing RBN management services 424 according to various implementation schemes. It can be understood that... FIG. 4 The flowchart only provides examples of many different types of functional layouts that can be used to implement parts of the RBN management service 424 as described herein. Alternatively, FIG. 1A The flowchart can be viewed as a depiction of the computing environment 403 according to one or more implementation schemes. FIG. 4 Examples of elements of the methods implemented in ).

[0122] Starting with box 503, RBN management service 424 generates RBN 103 for ordering or provisioning. FIG. 4 The user interface. For example, the user interface may include a method for specifying network planning 439 (…). FIG. 4 ) or network planning parameters 439. Such parameters may include, for example, the number of cells, customer locations or maps or site plans of the geographic area to be covered, target bandwidth, and information about wireless device 106 ( FIG. 2A This includes user information, target minimum latency, expected cost, and / or other parameters. The user interface may include components for uploading one or more data files containing this information. The user interface may be transmitted via network 412 (or other network data). FIG. 1A ) is sent to the client device 406 ( FIG. 4 The client application 436 executed in ) FIG. 1A ) Presentation. Optionally, the client application 436 may make one or more API calls to place orders with the provider or provision RBNs.

[0123] In box 506, RBN management service 424 receives a request to provision an RBN from the organization. For example, a user can submit a form or otherwise interact with the user interface to have the request submitted. Optionally, client application 436 can make one or more API calls to request RBN provisioning.

[0124] In box 507, RBN management service 424 can automatically initiate probing of an organization's existing private networks. For example, an organization may have existing networks such as wired, Ethernet, Wi-Fi, or other types of networks. Upon receiving appropriate security credentials and access to endpoints on the network, RBN management service 424 can automatically probe the network to determine customer needs for the new RBN 103 and the associated core network. For example, RBN management service 424 can automatically determine the number of user devices on the existing network, network bandwidth and request volume associated with various applications or services, existing latency observed for accessing various applications or services, reliability of existing systems, and so on. These observations can be used to set initial thresholds for latency, bandwidth, etc., in the RBN to be deployed.

[0125] In box 509, RBN management service 424 determines the network topology for RBN 103. For example, the network topology may be based at least in part on one or more locality rules 434 ( FIG. 1A The network topology may include cell 109 in RBN 103. FIG. 4 The arrangement of the RBN management service 424 can be determined to optimally cover one or more buildings of the organization. Both internal and external areas of the buildings can be covered as needed. This determination may include receiving information about the coverage area, including indoor and outdoor coverage areas, the number of devices to be connected, and the layout of physical network connections and power supplies. In this regard, the RBN management service 424 can determine the number of cells 109 based on network planning 439. Alternatively, given the customer areas and / or locations to be covered, the RBN management service 424 may automatically determine the optimal number of cells 109 based at least in part on parameters such as target latency, bandwidth, signal strength, and reliability. In one implementation, an unmanned aerial vehicle (UAV) can be used to conduct site surveys of the area to be covered, potentially recording signal strength to observe the state of the spectrum to determine available frequencies. The RBN management service 424 can record the cellular topology 442 ( FIG. 4 The deployment of cell 109 in RBN 103. In some scenarios, RBN management service 424 can use machine learning to determine the optimal deployment of cell 109 by deploying various deployments of RBN 103 and evaluating their performance. Over time, by observing these deployments, RBN management service 424 can learn which deployments perform better or worse than others and use these results to train a machine learning model.

[0126] In box 512, RBN management service 424 automatically reserves spectrum allocation for RBN 103. To this end, RBN management service 424 can automatically determine the available frequencies for cellular topology 442 from publicly available frequencies, customer-owned frequencies, and / or provider-owned frequencies. Frequency determination may take into account polarization, directivity, beam tilt, and / or other factors that may allow or interfere with frequency reuse. RBN management service 424 may record the reservation in spectrum allocation 445 (…). and the like In addition, RBN management service 424 can communicate with external services implementing the spectrum reservation system (such as spectrum reservation service 410) via network 412. FIG. 4 )) Communication to reserve and / or determine available frequencies.

[0127] In box 515, RBN management service 424 identifies the equipment required to implement RBN 103 based on the network topology conforming to locality rule 434. This may include antennas, radio units, and equipment for implementing provider underlying extensions 224. FIG. 4 The computing devices, cables, switches, routers, fiber optic termination devices, etc., are included. In some cases, the computing devices may be included in external units to be installed outside the customer's building. In some examples, such units may be standalone, except for power and network connections. In some scenarios, RBN Management Service 424 can use machine learning to determine the optimal device placement by deploying various arrangements of RBN 103 and evaluating their performance. Over time, by observing these deployments, RBN Management Service 424 can learn which arrangements perform better or worse than others and use these results to train machine learning models.

[0128] RBN management service 424 can also use machine learning to determine the optimal distribution of devices for each customer. For example, only in the data center core computing unit 118 ( FIG. 4 ) for running network function workloads for specific types of customers 466 ( FIG. 4 This might be meaningful for another type of customer, in distributed computing device 112 ( FIG. 6A ) or centralized computing device 115 ( FIG. 6A Running network function workload 466 at this location is likely optimal. Therefore, RBN management service 424 can determine that computing devices 112 or 115 should not be deployed, but rather a cloud-only deployment of the core computing device 118 is preferable.

[0129] In box 518, RBN management service 424 is accessed via RBN hardware deployment service 430. FIG. 6AInitiate the procurement of equipment for RBN 103. This may include automatically reserving equipment from the supplier’s existing inventory and / or issuing one or more equipment orders to one or more suppliers.

[0130] In box 521, RBN management service 424 enables RBN hardware configuration service 427 ( FIG. 4 Pre-configured one or more devices, such as computing devices, radio units, antennas, and routers for implementing network functions. FIG. 4 Such a device can be used as a pre-deployment device 409. FIG. 4 Connect to network 412. RBN hardware configuration service 427 uses radio unit configuration data 457. For example Antenna configuration data 460 ( and the like ) and network function configuration data 463 ( and the like To implement pre-configuration.

[0131] In box 522, RBN management service 424 can configure one or more network slices for radio-based network 103, which can provide differentiated quality of service (QoS) levels for different user devices, applications, or services. QoS levels can provide different latency, bandwidth / throughput, signal strength, reliability, and / or other service factors. For example, a customer may have a group of devices requiring very low latency, so RBN management service 424 can configure network slices to provide below-threshold latency for these devices. In another example, a first QoS level can be provided for a first application, and a second QoS level can be provided for a second application.

[0132] In box 524, RBN management service 424 enables RBN hardware deployment service 430 to deliver a device, including a pre-configured pre-deployment device 409, to the customer. Various instructions for installing the device can be transmitted to the customer via client application 436. After this, part of the operation of RBN management service 424 ends.

[0133] Go to FIG. 1A The diagram illustrates a flowchart of an example of the operation of providing a portion of the localized orchestration service 433 according to various implementation schemes. It should be understood that... For example The flowchart only provides examples of many different types of functional layouts that can be used to implement parts of the local orchestration service 433 as described in this document. Alternatively, and the like The flowchart can be viewed as depicting a computing environment 403 according to one or more implementation schemes. FIG. 8 Examples of elements of the methods implemented in ).

[0134] Starting with box 603, local orchestration service 433 is located on client device 406 (and the like The locality orchestration service 433 receives one or more locality rules 434 from the management user of the certified organization. In box 606, the locality orchestration service 433 receives one or more locality rules 434. and the like The specifications. For example, administrators can select or identify one or more predefined geographic regions 312 ( and the like Country, State, City, Postal Code FIG. 5 to FIG. 7 Alternatively, by using distance to a location, boundaries and limits, or cells on a grid. and the like To arbitrarily define a geographic region 312 to specify one or more geographic regions 312 ( FIG. 5 to FIG. 7 Users can also specify various parameters controlling the types of network traffic to which locality rule 434 applies, when and under what conditions locality rule 434 applies, exemption mechanisms, and which user records (). FIG. 5 to FIG. 7 Subscriber data, keys, text messages, voicemails, billing records FIG. 5 to FIG. 7 It will remain in geographic region 312, etc.

[0135] In box 609, the locality orchestration service 433 determines the locality for radio-based network 103 based at least in part on locality rules 434. and the like The network topology ensures that the elements of the radio-based network 103 are entirely within the geographic region 312. In some cases, the locality orchestration service 433 can access previously defined locality rules 434 or locality rules 434 pre-configured by the cloud provider rather than the organization.

[0136] This topology may include elements of a radio-based network 103, such as communication links ( and the like (Link between RAN and associated core network), provider underlying extension 224 ( For example ) or cloud provider network 203 ( ​ Other capacity on which network functions are performed or data or metadata is stored, cell 109 ( ​ Location and other elements. In some cases, users can provide topology specifications, such as Topology Orchestration Specification for Cloud Applications (TOSCA) or other formats, such as JavaScript Object Notation (JSON). In some implementations, the locality orchestration service 433 can also automatically generate topology specifications in this format. For example, locality rule 434 may require one or more identified categories of network traffic ( ​ Voice, video, text messages, and data are kept within a geographic region of 312.

[0137] In various implementations, the locality orchestration service 433 may select the location of cell 109 at least in part based on the location of cell 109 for deploying RBN 103 being within geographic region 312; select the location at least in part based on the location of provider underlying extension 224 for deploying cloud provider network 203 being within geographic region 312; and select the first region 306 from multiple regions 306 (or local region) of cloud provider network 203 at least in part based on the first region 306 for deploying at least a portion of the associated core network (compared to a second region 306 outside geographic region 312) being within geographic region 312. ​ (or local area); the specific communication link is selected at least in part based on the fact that the specific communication link used to connect the RAN and the associated core network 312 is entirely within the geographical area; the specific data storage service is selected at least in part based on the fact that the specific data storage service used to store the data records associated with RBN103 is within the specific geographical area 312; and so on.

[0138] In box 612, the locality orchestration service 433 initially provisiones a radio-based network 103 with a topology conforming to locality rule 434, or reconfigures an existing radio-based network 103 to have a conforming topology. The radio-based network 103 can be configured to enforce locality rule 434 using firewall rules, network access control lists, security groups, and / or other mechanisms to ensure that data does not leave the secure virtual private cloud network within the cloud provider network 203. The locality orchestration service 433 can also determine or verify that the generated topology conforms to locality rule 434. At least a portion of the radio-based network 103 is provisioned within the cloud provider network 203. After this, the operation of the locality orchestration service 433 terminates.

[0139] Go to ​ The diagram illustrates an example of the operation of providing another part of the localized orchestration service 433 according to various implementation schemes. It should be understood that... ​ The flowchart only provides examples of many different types of functional layouts that can be used to implement parts of the local orchestration service 433 as described in this document. Alternatively, ​ The flowchart can be viewed as depicting a computing environment 403 according to one or more implementation schemes. ​ Examples of elements of the methods implemented in ).

[0140] Starting with box 615, local orchestration service 433 or RBN 103 ( ​ Another component receives data from client device 406 via RBN 103. ​The data is sent by the RBN 103. Alternatively, the data can be sent to the client device 406 from another computing device, either internal or external to the RBN 103. This data may correspond to control plane data. ​ Device registration data, certification data ​ User plane data ​ Voice call data, text message data ​ Or a combination of both. In box 618, the locality orchestration service 433 determines that sending data to the destination would violate one or more locality rules 434 configured for RBN 103. ​ For example, the destination can be a specific geographic region 312 specified in locality rule 434. ​ Furthermore, locality rule 434 will be applied in other ways to the data type being sent. In another example, locality orchestration service 433 may determine that at least part of the route of data to its destination is outside a specific geographic region 312 or that the data will be processed in some way outside of a specific geographic region 312. If the data is inbound, the source may be outside of a specific geographic region 312, while the destination may be within a specific geographic region 312, thus violating locality rule 434 from the inbound direction.

[0141] In box 621, the locality orchestration service 433 performs one or more actions in response to determining that transmitting data to the destination would violate one or more locality rules 434. For example, the locality orchestration service 433 may block data transmission to the destination until an exemption for locality rule 434 is approved. In other examples, violating locality rule 434 may trigger a legitimate interception of data, cause throttling or slowing of data communication, disable throttling of data, generate notifications or log entries, and / or cause other actions to be performed. In some cases, a type of processing ( ​ Log recording, code conversion, interception ​ This is typically performed on network traffic that conforms to locality rule 434, but this processing is not performed on network traffic that does not conform to locality rule 434.

[0142] In box 622, the locality orchestration service 433 determines whether to request an exemption for locality rule 434. In some examples, in some or all cases, an exemption may be automatically approved in response to a detected resource constraint, which would otherwise prevent communication from proceeding. In other cases, one or more notifications for the exemption request are selectively sent according to a configured policy. If the locality orchestration service 433 determines that an exemption is requested, in box 624, the locality orchestration service 433 sends a notification of the exemption request for locality rule 434. In some cases, the locality orchestration service 433 may send the notification to the administrative user of the organization provisioned with RBN 103. In other cases, the user at client device 406 may be notified and able to approve the exemption request. In some cases, the data connection ( ​ Users at both ends of a voice call, text message, or other data exchange may require approval for an exemption.

[0143] In box 627, the local orchestration service 433 determines whether the required approval has been received. If the local orchestration service 433 receives approval for an exemption from the client device 406 or the client device 406 managing the user via a user interface or application programming interface (API), the local orchestration service 433 continues from box 627 to box 630. In box 630, the local orchestration service 433 continues to transmit data to the destination. Thereafter, part of the operation of the local orchestration service 433 ends. If no approval is received in box 627 or if no exemption is requested in box 622, part of the operation of the local orchestration service 433 also ends.

[0144] Next reference ​ The diagram illustrates an example of the operation of providing another part of the localized orchestration service 433 according to various implementation schemes. It should be understood that... ​ The flowchart only provides examples of many different types of functional layouts that can be used to implement parts of the local orchestration service 433 as described in this document. Alternatively, ​ The flowchart can be viewed as a depiction of the computing environment 403 according to one or more implementation schemes. ​ Examples of elements of the methods implemented in ).

[0145] Starting with box 703, local orchestration service 433 receives network slices 470 ( ​ Configure one or more locality rules 434 ( ​ The request to prepare network slice 470 may include a specific geographic area 312 for locality rule 434. ​The definition of ). In box 706, the locality orchestration service 433 uses the network slice allocation service 425 ( ​ This is used to provision network slice 470, enabling network slice 470 to utilize a topology that conforms to locality rule 434. For example, locality orchestration service 433 can deploy cloud provider network 203 within a specific geographic region 312. ​ One or more provider underlying extensions 224 () ​ The local orchestration service 433 can be configured with RBN 103 (). ​ ) to store data records related to network traffic of network slice 470 in a data storage service within geographic region 312. RBN103 may have one or more other network slices 470 that do not have locality rule 434 or have different locality rules 434.

[0146] In box 709, the locality orchestration service 433 receives network traffic sent via network slice 470. The locality orchestration service 433 can determine that the network traffic was sent via network slice 470 based on at least one of the following: the source application of the network traffic, the source client device of the network traffic, or a tag in the network traffic. In some cases, the network traffic may be sent to a destination outside the geographic area 312 specified in locality rule 434, in which case the network traffic may be blocked until an appropriate exemption is approved.

[0147] In box 712, the locality orchestration service 433 determines whether RBN 103 has resources that will conform to locality rule 434 when processing network traffic. In box 715, the locality orchestration service 433 assesses whether the resources are sufficient. ​ Meeting service quality requirements 471 ( ​ (threshold)

[0148] If resources are determined to be insufficient, the locality orchestration service 433 moves from box 715 to box 718 and increases the resources in geographic region 312 specified in locality rule 434. That is, the locality orchestration service 433 can scale the compute resources allocated to network slices 470 within geographic region 312. For example, the locality orchestration service 433 can allocate one or more additional instances of network functionality in a specific geographic region 312, or increase the capacity of communication links in a specific geographic region 312. ​ The local orchestration service 433 then proceeds to box 721. If the resources in geographic region 312 are determined to be sufficient, the local orchestration service 433 proceeds from box 715 to box 721.

[0149] In some cases, the local orchestration service 433 may not be able to scale resources within a specific geographic region 312. For example, the resource may be unavailable. In such scenarios, the local orchestration service 433 may drop the traffic, request an exemption for local rule 434, or automatically apply the exemption to local rule 434.

[0150] In box 721, if resources are sufficient or scaled to be sufficient, the locality orchestration service 433 takes action on network traffic to process network traffic in geographic region 312 that conforms to locality rule 434. For example, the locality orchestration service 433 may select a path for network traffic in RBN 103 to conform to locality rule 434. The locality orchestration service 433 may select a specific instance of the network function ( ​ AMF, SMF, UPF ​ The local orchestration service 433 processes network traffic by selecting a specific instance from multiple instances of network functions in RBN 103, at least in part, based on the fact that the specific instance is within a specific geographic area 312. The local orchestration service 433 can also select a specific base station or a group of base stations in the RAN, such that the base station is within the specific geographic area 312 and is used for network traffic. The local orchestration service 433 can also select a specific communication link between the RAN and the associated core network for a path, wherein the entire specific communication link is within the specific geographic area 312. After this, part of the operation of the local orchestration service 433 ends.

[0151] refer to ​ A schematic block diagram of a computing environment 403 according to an embodiment of the present disclosure is shown. The computing environment 403 includes one or more computing devices 800. Each computing device 800 includes at least one processor circuitry, for example, having a processor 803 and a memory 806, both coupled to a local interface 809. For this purpose, each computing device 800 may include, for example, at least one server computer or similar device. The local interface 809 may include, for example, a data bus with an accompanying address / control bus or other understandable bus structure.

[0152] The memory 806 stores data and several components that can be executed by the processor 803. Specifically, the following can be stored in the memory 806 and can be executed by the processor 803: RBN management service 424, network slice allocation service 425, RBN hardware configuration service 427, RBN hardware deployment service 430, local orchestration service 433, and potentially other applications. The memory 806 may also store data storage area 415 and other data. Furthermore, the operating system can be stored in the memory 806 and can be executed by the processor 803.

[0153] It should be understood that other applications may exist, stored in memory 806, and be executable by processor 803. Where any component discussed herein is implemented in software form, it may be implemented in any of a variety of programming languages, such as, for example, C, C++, C#, Objective-C, Java. ® JavaScript ® Perl, PHP, Visual Basic ® Python ® Ruby, Flash ® Or other programming languages.

[0154] Many software components are stored in memory 806 and can be executed by processor 803. In this respect, the term "executable" refers to a program file in a form that can ultimately be run by processor 803. Examples of executable programs can be, for example, a compiler that can be translated into machine code, the format of which can be loaded into the random access portion of memory 806 and executed by processor 803; source code, which can be expressed in a suitable format, such as object code that can be loaded into the random access portion of memory 806 and executed by processor 803; or source code, which can be interpreted by another executable program to generate instructions in the random access portion of memory 806 that will be executed by processor 803. ​ The executable program can be stored in any part or component of the memory 806, including, for example, random access memory (RAM), read-only memory (ROM), hard disk drive, solid-state drive, USB flash drive, memory card, optical disc, floppy disk, magnetic tape or other storage component such as optical disc (CD) or digital versatile optical disc (DVD).

[0155] Memory 806 is defined herein as including volatile and non-volatile memory and data storage components. Volatile components are those that do not retain data values ​​when power is off. Non-volatile components are those that retain data when power is off. Therefore, memory 806 may include, for example, random access memory (RAM), read-only memory (ROM), hard disk drive, solid-state drive, USB flash drive, memory card accessed via a memory card reader, floppy disk accessed via an associated floppy disk drive, optical disk accessed via an optical disk drive, magnetic tape accessed via a suitable magnetic tape drive, and / or other memory components, or any two or more combinations of these memory components. Furthermore, RAM may include, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM), and other such devices. ROM may include, for example, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other similar memory devices.

[0156] Furthermore, processor 803 can represent multiple processors 803 and / or multiple processor cores, while memory 806 can represent multiple memories 806 operating in parallel processing circuitry. In this case, local interface 809 can facilitate communication between any two of the multiple processors 803, between any processor 803 and any memory 806, or between any two memories 806. ​ A suitable network for communication. Local interface 809 may include additional systems designed to coordinate this communication, including, for example, performing load balancing. Processor 803 may be electrical or some other available architecture.

[0157] Although, as described above, the RBN management service 424, network slice allocation service 425, RBN hardware configuration service 427, RBN hardware deployment service 430, local orchestration service 433, and various other systems described herein can be implemented in software or by code executed by general-purpose hardware, alternatively, they can also be implemented in dedicated hardware or a combination of software / general-purpose and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine employing any one or a combination of various technologies. These technologies may include, but are not limited to, discrete logic circuits with logic gates for implementing various logical functions when one or more data signals are applied, application-specific integrated circuits (ASICs) with appropriate logic gates, field-programmable gate arrays (FPGAs), or other components. ​ Such techniques are generally well known to those skilled in the art, and therefore will not be described in detail here.

[0158] ​The flowchart illustrates the functionality and operation of the various parts of the RBN management service 424 and the locality orchestration service 433. If embodied in software, each block may represent a module, segment, or section of code, comprising program instructions for implementing specified logical functions. These program instructions may be embodied in source code, comprising human-readable statements written in a programming language, or machine code, comprising numerical instructions recognizable by a suitable execution system such as a processor 803 in a computer system or other system. The machine code may be derived from source code. ​ It's a converted version. In hardware, each block can represent a circuit or multiple interconnected circuits to implement a specified logical function.

[0159] although ​ The flowchart illustrates a specific execution order, but it is understood that the execution order may differ from the depicted order. For example, the execution order of two or more blocks may be shuffled relative to the order shown. Furthermore, ​ Two or more blocks shown consecutively can be executed simultaneously or partially simultaneously. Furthermore, in some implementations, ​ One or more of the blocks shown can be skipped or omitted. Additionally, this is for purposes such as enhancing utility, accounting, performance measurement, or providing troubleshooting assistance. ​ The purpose is to allow any number of counters, state variables, warning semaphores, or messages to be added to the logic flow described herein. It should be understood that all such variations are within the scope of this disclosure.

[0160] Furthermore, any logic or application program (including RBN management service 424, network slice allocation service 425, RBN hardware configuration service 427, RBN hardware deployment service 430, and locality orchestration service 433) described herein, including software or code, may be embodied in any non-transitory computer-readable medium for use by or in conjunction with an instruction execution system, such as a processor 803 in a computer system or other system. In this sense, logic may include, for example, statements comprising instructions and declarations that can be extracted from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application program described herein for use by or in conjunction with an instruction execution system.

[0161] Computer-readable media can include any of a number of physical media, such as, for example, magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media will include, but are not limited to, magnetic magnetic disks, magnetic hard disks, memory cards, solid-state drives, USB flash drives, or optical discs. Furthermore, computer-readable media can be random access memory (RAM), including, for example, static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). Additionally, computer-readable media can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other types of memory devices.

[0162] Furthermore, any logic or application described herein (including RBN management service 424, network slice allocation service 425, RBN hardware configuration service 427, RBN hardware deployment service 430, and locality orchestration service 433) can be implemented and structured in various ways. For example, one or more applications described herein may be implemented as modules or components of a single application. Furthermore, one or more applications described herein may execute in shared or separate computing devices or combinations thereof. For example, multiple applications described herein may execute in the same computing device 800, or in multiple computing devices 800 within the same computing environment 403.

[0163] Unless otherwise specified, extractive language such as the phrase "at least one of X, Y, or Z" should be understood in the context as commonly used to represent items or terms. ​ It can be X, Y, or Z, or any combination thereof. ​ (X, Y, and / or Z). Therefore, this disjunctive language is generally not intended and should not imply that any implementation requires the presence of at least one of X, at least one of Y, or at least one of Z, respectively.

[0164] The implementation of this disclosure can be described by at least the following terms: Clause 1. A system comprising: at least one computing device in a cloud provider network, the at least one computing device being configured to at least: receive a request to provision a radio-based network for an organization, the radio-based network including a radio access network and an associated core network, at least a portion of the associated core network to be provisioned in the cloud provider network; determine a topology for the radio-based network conforming to at least one locality rule, the at least one locality rule requiring one or more identified categories of network traffic for the radio-based network to remain within a specific geographic area, such that a portion of the topology corresponding to a portion of the radio-based network processing network traffic of the one or more identified categories is comprised of physical hardware located within the specific geographic area; and provision the radio-based network for the organization having the topology conforming to the at least one locality rule.

[0165] Clause 2. The system as described in Clause 1, wherein the at least one computing device is further configured to at least: receive specifications of the at least one locality rule from a client device associated with the organization; and receive any definition of the particular geographic region from the client device.

[0166] Clause 3. The system as described in Clauses 1 to 2, wherein the topology defines at least one communication link that is entirely within the specific geographical area between the radio access network and the associated core network.

[0167] Clause 4. A computer-implemented method comprising: accessing at least one locality rule associated with an organization, the at least one locality rule requiring that at least one subset of network traffic for a radio-based network remain within a specific geographic area, the radio-based network including a radio access network and an associated core network; determining a topology for the radio-based network based at least in part on the at least one locality rule; and provisioning or reconfiguring the radio-based network for the organization to make the topology conform to the at least one locality rule.

[0168] Clause 5. The computer-implemented method as described in Clause 4, further comprising receiving the at least one locality rule from a client device associated with the organization.

[0169] Clause 6. The computer-implemented method as described in Clauses 4 to 5, wherein determining the topology for the radio-based network based at least in part on the at least one locality rule further comprises: selecting a location for deploying the cell based at least in part on the cell of the radio access network being located within the specific geographic area.

[0170] Clause 7. The computer-implemented method as described in Clauses 4 to 6, wherein determining the topology for the radio-based network based at least in part on the at least one locality rule further comprises selecting the location based at least in part on the location of the provider underlying extension for deploying the cloud provider network within the specific geographic area.

[0171] Clause 8. The computer-implemented method as described in Clauses 4 to 7, wherein determining the topology for the radio-based network based at least in part on the at least one locality rule further comprises: selecting the first region based at least in part on a first region of a plurality of regions of a cloud provider network for deploying at least a portion of the associated core network within the specific geographic region, wherein at least a second region of the plurality of regions is outside the specific geographic region.

[0172] Clause 9. The computer-implemented method as described in Clauses 4 to 8, wherein determining the topology for the radio-based network based at least in part on the at least one locality rule further comprises: selecting the specific communication link at least in part based on the fact that the specific communication link used to connect the radio access network and the associated core network is entirely within the specific geographical area.

[0173] Clause 10. The computer-implemented method as described in Clauses 4 to 9, wherein determining the topology for the radio-based network based at least in part on the at least one locality rule further comprises: selecting the specific data storage service based at least in part on the specific geographic area of ​​the specific data storage service used to store data records associated with the radio-based network.

[0174] Clause 11. The computer-implemented method as described in Clauses 4 through 10, wherein the at least one locality rule requires one or more user records associated with the radio-based network to remain within the specific geographic area.

[0175] Clause 12. The computer-implemented method as described in Clauses 4 to 11, wherein the at least one locality rule requires one or more identified categories of the network traffic to remain within the specific geographic area, the one or more identified categories including at least one of: voice calls, text messages, or data.

[0176] Clause 13. The computer-implemented method as described in Clauses 4 to 12, further comprising receiving an arbitrary definition of the particular geographic region from a client device associated with the organization.

[0177] Clause 14. The computer-implemented method as described in Clauses 4 to 13, wherein the specific geographic region includes a plurality of designated geographic regions.

[0178] Clause 15. The computer-implemented method as described in Clauses 4 to 14, wherein the specific geographic area corresponds to at least one of the following: country, state, city, or postal code.

[0179] Clause 16. A computer-implemented method comprising: receiving data transmitted via a radio-based network for organizational operations, the radio-based network including a radio access network and an associated core network, the radio-based network implementing at least one locality rule requiring at least one subset of network traffic for the radio-based network to remain within a specific geographic area; determining that transmitting the data to a destination would violate the at least one locality rule; and performing one or more actions in response to determining that transmitting the data to the destination would violate the at least one locality rule.

[0180] Clause 17. A computer-implemented method as described in Clause 16, wherein the one or more actions include at least one of: preventing the data from being transmitted to the destination, causing the data to be lawfully intercepted, or causing the data to be throttled.

[0181] Clause 18. The computer-implemented method as described in Clauses 16 and 17, further comprising: sending a notification to a user; receiving from the user approval of an exemption for the at least one locality rule; and transmitting the data to the destination in response to the approval of the exemption for the at least one locality rule.

[0182] Clause 19. A computer-implemented method as described in Clauses 16 to 18, wherein determining that transmitting the data to the destination would violate the at least one locality rule further includes determining that the destination is outside the specific geographic area.

[0183] Clause 20. A computer-implemented method as described in Clauses 16 to 19, wherein determining that transmitting the data to the destination would violate the at least one locality rule further includes determining that at least a portion of the path of the data to the destination is outside the specific geographic area.

[0184] Clause 21. A system comprising: a radio-based network including a radio access network and an associated core network, at least a portion of the associated core network being provisioned in a cloud provider network; and at least one computing device in the cloud provider network, the at least one computing device being configured to at least: receive a request to provision a network slice in the radio-based network, the network slice being associated with at least one locality rule requiring data transmitted via the network slice to remain within a specific geographic area; provision the network slice in the radio-based network conforming to the at least one locality rule using physical hardware located within the specific geographic area; receive network traffic transmitted via the network slice; and process the network traffic in the radio-based network within the specific geographic area to conform to the at least one locality rule.

[0185] Clause 22. The system as described in Clause 21, wherein the at least one computing device is further configured to scale computing resources allocated to the network slices within the particular geographic region, at least in part, based on the utilization of the network slices.

[0186] Clause 23. The system as described in Clauses 21 to 22, wherein equipping the network slice in the radio-based network further includes deploying at least one provider underlying extension in the specific geographic area in response to the request.

[0187] Clause 24. The system as described in Clauses 21 to 23, wherein the request to prepare the network slice includes a definition of the specific geographic region.

[0188] Clause 25. The system as described in Clauses 21 to 24, wherein the at least one computing device is further configured to store at least the data records related to the network traffic in a data storage service within the specific geographic area.

[0189] Clause 26. A system as described in Clauses 21 to 25, wherein at least one other network slice in the radio-based network is not associated with the at least one locality rule.

[0190] Clause 27. The system as described in Clauses 21 to 26, wherein the at least one computing device is further configured to at least: receive additional network traffic sent via the network slice to a destination outside the specific geographic area; and block the transmission of the additional network traffic to the destination until an exemption to the at least one locality rule is approved.

[0191] Clause 28. A computer-implemented method comprising: receiving network traffic via a network slice in a radio-based network, the radio-based network including a radio access network and an associated core network, the network slice being associated with at least one locality rule requiring the network traffic to remain within a specific geographic area; determining that the radio-based network has resources that conform to the at least one locality rule; and taking action on the network traffic in the radio-based network to conform to the at least one locality rule.

[0192] Clause 29. The computer-implemented method as described in Clause 28, further comprising storing data records associated with network traffic within the specific geographic area to conform to the at least one locality rule.

[0193] Clause 30. The computer-implemented method as described in Clauses 28 to 29, further comprising: receiving other network traffic via the network slice in the radio-based network; determining that the radio-based network does not have the resources that conform to the at least one locality rule in order to route the other network traffic; and sending a notification indicating that an exemption from the at least one locality rule is required to route the other network traffic to a user device.

[0194] Clause 31. The computer-implemented method as described in Clauses 28 to 30, further comprising: receiving additional network traffic via different network slices in the radio-based network, the different network slices not associated with the at least one locality rule; and selecting different paths for the additional network traffic in the radio-based network, wherein the additional network traffic leaves the particular geographic area.

[0195] Clause 32. The computer-implemented method as described in Clauses 28 to 31 further includes determining, at least in part, that the network traffic is transmitted via the network slice based on at least one of the following: the source application of the network traffic, the source client device of the network traffic, or a tag in the network traffic.

[0196] Clause 33. The computer-implemented method as described in Clauses 28 to 32, wherein determining that the radio-based network has resources conforming to the at least one locality rule further includes allocating one or more additional resources to the radio-based network in the particular geographic area to conform to the at least one locality rule.

[0197] Clause 34. The computer-implemented method as described in Clauses 28 to 33, wherein taking action on network traffic in the radio-based network to conform to the at least one locality rule further includes selecting a specific communication link between the radio access network and the associated core network for path selection, wherein the entire specific communication link is located within the specific geographic area.

[0198] Clause 35. The computer-implemented method as described in Clauses 28 to 34, wherein taking action on network traffic in the radio-based network to conform to the at least one locality rule further includes selecting a specific instance of a network function to process the network traffic, the specific instance being selected from a plurality of instances of the network function in the radio-based network, at least in part based on the specific instance being located in the specific geographic region.

[0199] Clause 36. The computer-implemented method as described in Clause 35, wherein at least one other instance of the plurality of instances of the network function in the radio-based network is outside the specific geographic area.

[0200] Clause 37. A computer-implemented method comprising: receiving network traffic via a network slice in a radio-based network, the radio-based network including a radio access network and an associated core network, the network slice being associated with at least one locality rule requiring the network traffic to remain within a specific geographic area; determining that the capacity of a network function in the specific geographic area is insufficient to handle the network traffic; allocating one or more instances of the network function in the specific geographic area to increase the capacity; and having the one or more instances of the network function in the specific geographic area process the network traffic to conform to the at least one locality rule.

[0201] Clause 38. The computer-implemented method as described in Clause 37, wherein determining that the capacity of the network function in the particular geographic area is insufficient to handle the network traffic further comprises: determining, at least in part, based on the at least one locality rule, that the existing capacity of the network function in the radio-based network but outside the particular geographic area is not available to handle the network traffic.

[0202] Clause 39. The computer-implemented method as described in Clauses 37 to 38 further includes identifying the network slice based at least in part on at least one of the following: a source client device of the network traffic, a source application of the network traffic, or a tag in the network traffic.

[0203] Clause 40. The computer-implemented method as described in Clauses 37 to 39, further comprising: determining that the capacity of a communication link in the particular geographic area is insufficient to transmit the network traffic; increasing the capacity of the communication link; and transmitting the network traffic via the communication link in the particular geographic area to conform to the at least one locality rule.

[0204] It should be emphasized that the above embodiments of this disclosure are merely examples of possible implementations for the purpose of clearly understanding the principles of this disclosure. Many variations and modifications can be made to the above embodiments without departing substantially from the spirit and principles of this disclosure. All such modifications and variations are intended to be included within the scope of this disclosure and are protected by the appended claims.

Claims

1. A computer-implemented method, comprising: Network traffic is received via a network slice in a radio-based network, the radio-based network including a radio access network and an associated core network, the network slice being associated with at least one locality rule that requires the network traffic to remain within a specific geographic area; Determine that the radio-based network has resources that conform to at least one locality rule; Take action on a first portion of the network traffic in the radio-based network to conform to the at least one locality rule; Prevent the transmission of the second portion of the network traffic received via the network slice that violates at least one of the locality rules; Receive other network traffic via the network slice in the radio-based network; It is determined that the radio-based network does not have the resources that conform to the at least one locality rule in ordering the traffic from the other network; as well as A notification indicating the need for an exemption from at least one locality rule to route the other network traffic will be sent to the user device.

2. The computer-implemented method of claim 1 further includes storing data records associated with the network traffic within the specific geographic area to conform to the at least one locality rule.

3. The computer-implemented method as described in claim 1, further comprising: Other network traffic is received via different network slices in the radio-based network, and these different network slices are not associated with the at least one locality rule; as well as Different paths are selected for the other network traffic received via different network slices in the radio-based network, wherein the other network traffic received via the different network slices leaves the specific geographic area.

4. The computer-implemented method of claim 1, further comprising determining, at least in part, that the network traffic is transmitted via the network slice based on at least one of the following: the source application of the network traffic, the source client device of the network traffic, or a tag in the network traffic.

5. The computer-implemented method of claim 1, wherein determining that the radio-based network has resources conforming to the at least one locality rule further comprises allocating one or more additional resources to the radio-based network in the particular geographic area to conform to the at least one locality rule.

6. The computer-implemented method of claim 1, wherein taking action on the first portion of the network traffic in the radio-based network to conform to the at least one locality rule further comprises: For path selection, a specific communication link is chosen between the radio access network and the associated core network, wherein the entire specific communication link is located within the specific geographical area.

7. The computer-implemented method of claim 1, wherein taking action on the first portion of the network traffic in the radio-based network to conform to the at least one locality rule further comprises: A specific instance of a network function is selected to handle the network traffic, and the specific instance is selected from a plurality of instances of the network function in the radio-based network, at least in part based on the specific instance within the specific geographical area.

8. The computer-implemented method of claim 7, wherein at least one other instance of the plurality of instances of the network function in the radio-based network is outside the specific geographic area.

9. A system comprising: Radio-based networks, including radio access networks and associated core networks; as well as At least one computing device is configured to at least: Network traffic is received via a network slice in the radio-based network, the network slice being associated with at least one locality rule that requires the network traffic to remain within a specific geographic area; Determine that the radio-based network has resources that conform to at least one locality rule; Take action on a first portion of the network traffic in the radio-based network to conform to the at least one locality rule; Prevent the transmission of the second portion of the network traffic received via the network slice that violates at least one of the locality rules; Receive other network traffic sent via the network slice to destinations outside the specific geographic area; as well as Prevent the transmission of the other network traffic to the destination until an exemption for the at least one locality rule is approved.

10. The system of claim 9, wherein at least a portion of the associated core network is provisioned in a cloud provider network, and the at least one computing device is in the cloud provider network.

11. The system of claim 9, wherein the at least one computing device is further configured to at least: Receive a request to prepare the network slice; and By using physical hardware located within the specific geographical area, network slices conforming to at least one locality rule are configured in the radio-based network.

12. The system of claim 11, wherein configuring the network slice in the radio-based network further comprises deploying at least one provider underlying extension in the specific geographic area in response to the request.

13. The system of claim 9, wherein the at least one computing device is further configured to scale computing resources allocated to the network slices within the particular geographic region, at least in part based on the utilization of the network slices.

14. The system of claim 9, wherein the at least one computing device is further configured to store at least the data records related to the network traffic in a data storage service within the specific geographic area.

Images