Managing Network Slice Allocation

Abstract

This invention provides a system and method for managing the allocation of network slices. [Solution] The method includes the network slice allocation service receiving a request to allocate a network slice to a client application or client device, determining that the network slice is associated with the consumption of network-sensitive content, determining that quality of service requirement 1 is not met based on the current location of the content delivery service in the network, instantiating the content delivery service on the wireless network, and initiating the transfer of content to the content delivery service 426.

Description

Technical Field

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Patent Application entitled "MANAGING ASSIGNMENTS OF NETWORK SLICES", filed on December 10, 2020 and assigned Application No. 17 / 118,565, the entire content of which is incorporated herein by reference. Background Art

[0002] 5G is the fifth-generation technical standard for broadband cellular networks, and is ultimately planned to replace the fourth-generation (4G) Long-Term Evolution (LTE) standard. 5G technology will provide significantly increased bandwidth, thereby expanding the cellular market beyond smartphones to provide last-mile connectivity to devices such as desktops, set-top boxes, laptops, and Internet of Things (IoT) devices. Some 5G cells may use frequency spectra similar to those of 4G, while other 5G cells may use frequency spectra in the millimeter wave band. Although the service area of millimeter wave band cells is relatively small, they will provide much higher throughput than 4G.

[0003] Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, instead emphasis is placed on clearly illustrating the principles of the present disclosure. Furthermore, in the drawings, like reference numerals designate corresponding parts throughout the several views. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] [Figure 1] FIG. 1 is a diagram of an example communication network deployed and managed in accordance with various embodiments of the present disclosure. [Figure 2A]Examples of network environments, according to several embodiments of this disclosure, include a cloud provider network and further include various provider substrate extensions of the cloud provider network that can be used at various locations within the communication network shown in Figure 1. [Figure 2B] Figure 1 shows an example of cellularization and geographical distribution of a communication network to provide High Availability User Plane (UPF) functionality. [Figure 3] Figure 2A shows an example of a network environment including geographically distributed provider substrate extensions according to several embodiments of the present disclosure. [Figure 4] This is a schematic block diagram of the network environment shown in Figure 2A according to various embodiments of the present disclosure. [Figure 5] This flowchart shows an example of functionality implemented as part of a client application running on a client device in the network environment of Figure 4, according to various embodiments of this disclosure. [Figure 6] This flowchart shows examples of functionality implemented as part of a network slice allocation service running in a computing environment within the network environment of Figure 4, according to various embodiments of the present disclosure. [Figure 7] This flowchart shows examples of functionality implemented as part of a network slice allocation service running in a computing environment within the network environment of Figure 4, according to various embodiments of the present disclosure. [Figure 8] This schematic block diagram provides an example of a computing environment used in the network environment shown in Figure 4, according to various embodiments of the present disclosure. [Modes for carrying out the invention]

[0005] This disclosure relates to on-demand application-driven network slicing in wireless networks, including 4G and 5G wireless networks, or parts of such wireless networks, including wireless access networks (RANs) and associated core networks. Specifically, the disclosed wireless network management service enables applications to effectively program the network by controlling network functions and the infrastructure on which they run. Applications can select a set of required quality of service (QoS) parameters via an application programming interface (API), and the service orchestrates network functions and reserves the necessary resources from wireless to instance to ensure that the QoS service level agreement (SLA) is met during the session duration. Previous wireless network deployments relied on manual deployment and configuration at each step of the process, which proved to be extremely time-consuming and costly. Furthermore, in previous generations, software was inherently tied to vendor-specific hardware, preventing customers from deploying alternative software. In contrast, with 5G, hardware is decoupled from the software stack, increasing flexibility and allowing wireless network components to run on cloud provider infrastructure. By decoupling network functions from specific hardware, wireless networks and their associated core networks become easier to configure and dynamically reconfigure. Using a cloud-delivery model for wireless networks such as 5G networks can make it easier to handle network traffic from hundreds of thousands to billions of connected devices and computationally intensive applications while delivering faster, lower-latency, and higher-capacity than other types of networks.

[0006] Sharing limited resources has long been a problem in communication networks. Circuit-switched networks offer dedicated bandwidth and reliability, but they were expensive and inefficient. As a result, circuit-switched networks have largely been replaced by packet-switched networks, such as Internet Protocol (IP) based networks, which offer greater flexibility in resource sharing. However, packet-based networks are generally "best-effort" networks, meaning that when data packets are sent, there is no guarantee that they will actually be delivered to their destination. This may be acceptable for many network applications such as web browsing or email, but it may not be acceptable for other network applications such as video conferencing or sensors, which require or can function properly with minimal bandwidth or latency.

[0007] Various embodiments of this disclosure implement on-demand slicing of networks, such as wireless networks and associated core networks, to ensure quality of service for customers and their applications. In some embodiments, applications on client devices can request network slice allocations on demand via a service API. For example, a user of a video conferencing application can designate video conferencing as the highest priority, causing the application to request a sufficiently high-priority network slice for video conferencing, resulting in the video conferencing not being interrupted or affected by failures. By enabling each application to request on-demand network slices for each individual session, use cases become possible where customers can specify higher quality of service (QoS) for critical connections (e.g., machine control, important meetings or events) and lower QoS for other less critical connections.

[0008] In some embodiments, the network slice allocation service manages allocations within the network, including automatically scaling resources within the network dedicated to network functions. The network slice allocation service may also reduce network function latency by migrating network function workloads from one location to another within the network topology as needed to meet the quality of service requirements of the network slice. Conversely, the network slice allocation service may move network function workloads to the core network of the cloud provider network if they are required at the network edge to provide the requested quality of service.

[0009] In some embodiments, a content management service may operate in parallel with a network slice allocation service to ensure that content subject to quality-of-service requirements in a network slice is actually delivered in accordance with those requirements. To achieve this objective, the content management service may shift the operation of the content delivery network to different locations within the network to support quality-of-service requirements. For example, high-bitrate video content from the content delivery network may be proactively cached for users at the network edge to provide high quality of service. Such an approach may be beneficial when regular content delivery servers are accessible over congested backbone links or over public internet connections that do not provide high quality of service.

[0010] As those skilled in the art will understand in light of this disclosure, certain embodiments may achieve certain advantages, including some or all of the following: (1) improving the functionality of computer systems and networks by enabling applications to dynamically and on-demand request network slices with specific quality of service, thereby enabling applications to operate appropriately according to bandwidth and latency requirements; (2) improving the flexibility of computer systems and networks by enabling the dynamic and on-demand reconfiguration of network slices dedicated to applications or devices; (3) improving the functionality of computer systems and networks to meet quality of service requirements by shifting the workload of network functions to different locations within the wireless network; (4) improving the functionality of computer systems and networks to meet quality of service requirements by enabling computing resources dedicated to network functions to be scaled up or down as needed; (5) improving the functionality of computer systems and networks to meet quality of service requirements by shifting content delivery to different locations within the wireless network, and so on.

[0011] Among the benefits of this disclosure is the ability to deploy and cascade network functions to deliver an end-to-end service that delivers dynamically resized network slices to specific software applications based on 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 wireless network, operating within a base station and performing radio signal-to-IP conversion. Other network functions run in a large data center, executing subscriber-related business logic and routing IP traffic to and from the internet. For applications to utilize new 5G features such as low-latency communication and reserved bandwidth, both of these types of network functions must work together to properly schedule and reserve the radio spectrum and perform real-time computing and data processing. The techniques disclosed herein provide edge location hardware (described further below) integrated with network functions that run across the entire network, from cell sites to internet breakout, orchestrating the network functions to meet required QoS constraints. This enables a whole new set of applications with stringent QoS requirements that were previously impossible to run on mobile networks, ranging from factory-based IoT to augmented reality (AR), virtual reality (VR), game streaming, and autonomous navigation support for connected vehicles.

[0012] Network slicing is a feature that enables the deployment and operation of multiple logical networks on a common physical network infrastructure, allowing each logical network (i.e., network slice) to be customized and sized as needed to best meet a specific set of needs. Typically, network slices are created manually and provided to a specific organization or entity. According to this disclosure, a software application running on a wireless network can make an API request to a service to obtain a network slice that satisfies a set of QoS constraints provided to the application. In response, the service can automatically provision such a network slice for use with the network traffic associated with that application. A network slice can reserve a certain amount of different hardware resources (e.g., wireless resources, RAN, and core processing resources) across the network for use with the traffic associated with a particular application to achieve the desired QoS. The service can also manage such network slices across many different software applications at scale, for example, by provisioning "complementary" slices (with complementary needs between a set of different hardware components) on the same underlying hardware to utilize resources more efficiently, or by over-provisioning slices based on anticipated usage that indicates all applicable QoS constraints may still be met.

[0013] The described "Elastic 5G" service provides and manages all the hardware, software, and network functions necessary to build a network, and can dynamically create network slices and assign them to specific applications based on API requests and QoS parameters. In some embodiments, network functions may be developed and managed by a cloud provider, but the described control plane can manage network functions across various providers so that customers can invoke and manage selected network functions on the cloud infrastructure using a single set of APIs. The Elastic 5G service automates the creation of an end-to-end 5G network, from hardware to network functions, resulting in reduced deployment time and operational costs for network operation. By providing APIs that expose network functions, the disclosed Elastic 5G service allows applications to deploy and chain network functions to deliver end-to-end network slices that reflect the network characteristics requested by software applications, simply by specifying the required QoS as constraints. By automating the creation of network slices through application-driven API requests, the disclosed service can dynamically change network slices to respond to the changing demands of a wide range of applications running on the network.

[0014] This disclosure describes embodiments for creating and managing cloud-native 5G cores and / or cloud-native 5GRANs and associated control plane components. Cloud-native refers to an approach to building and running applications that leverage the benefits of cloud computing delivery models, including dynamic scalability, distributed computing, and high availability (including geographical distribution, redundancy, and failover). Cloud-native also refers to how these applications are created and deployed to be suitable for deployment in a public cloud. Cloud-native applications can (and often) run in a public cloud, but they can also run in on-premises data centers. Some cloud-native applications can be containerized, for example, by packaging different parts, functions, or subunits of an application into their own containers, which can then be dynamically orchestrated so that each part is actively scheduled and managed to optimize resource utilization. These containerized applications can be built using a microservices architecture to improve the overall agility and maintainability of the application. In a microservices architecture, an application is structured as a collection of smaller subunits ("microservices") that can be deployed and scaled independently of each other and communicate with one another over a network. These microservices typically have a specific technical and functional granularity and are often fine-grained because they implement lightweight communication protocols. Application microservices can perform different functions from one another, may be deployable independently, and may use different programming languages, databases, and hardware / software environments.Breaking down an application into smaller services beneficially improves its modularity, allowing individual microservices to be replaced as needed, and parallelizing development by enabling teams to develop, deploy, and maintain those microservices independently of each other. Microservices may be deployed using virtual machines, containers, or serverless capabilities, in some examples. The disclosed core and RAN software may follow a microservices architecture such that the described wireless network consists of independent subunits that can be deployed and scaled on demand.

[0015] Referring here to Figure 1, examples of a communications network 100 deployed and managed according to various embodiments of this disclosure are shown. The communications network 100 includes a radio 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 both 4G and 5G RAN, or another network providing wireless network access. The radio network 103 may be operated by a public communications provider or a cloud service provider of an enterprise or other organization. Various deployments of the radio network 103 may include one or more of the core network and RAN network, as well as a control plane for running the core network and / or RAN network on the cloud provider infrastructure. As described above, these components may be developed in a cloud-native manner, for example using a microservices architecture, so that centralized control and distributed processing are used to efficiently scale traffic and transactions. These components may be based on 3GPP® specifications by adhering to an application architecture (CUPS architecture) in which the processing of the control plane and user plane are separated.

[0016] The wireless network 103 may include a radio access network (RAN) that provides wireless network access to multiple wireless devices 106, which may be mobile devices or fixed-location devices. In various examples, wireless devices 106 may include devices such as smartphones, connected vehicles, Internet of Things (IoT) devices, sensors, machinery (such as in manufacturing facilities), and hotspots. Wireless devices 106 are sometimes referred to as user equipment (UE) or subscriber premises equipment (CPE).

[0017] The wireless network 103 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 for sending and receiving wireless data signals to and from the wireless devices 106. The antennas may be configured for one or more frequency bands, and the radio units may also be frequency-agile or frequency-adjustable. To concentrate signals in a particular direction or azimuth range, a specific gain or beamwidth may be associated with the antenna, which may allow for the reuse of frequencies in different directions. Furthermore, the antennas may be horizontally polarized, vertically polarized, or circularly polarized. In some examples, the radio units may transmit and receive signals using multiple-input multiple-output (MIMO) technology. Thus, the RAN implements the wireless access technology that enables wireless connectivity with the wireless devices 106 and provides connectivity to the core network of the wireless network. Components of the RAN include not only base stations and antennas covering a given physical area, but also the necessary core network items for managing connectivity to the RAN.

[0018] Data traffic is often routed to the core network via a fiber transport network consisting of multiple hops of Layer 3 routers (e.g., at aggregation sites). The core network is typically housed in one or more data centers. Typically, the core network aggregates data traffic from end devices, authenticates subscribers and devices, applies personalized policies, manages device mobility, and then routes the traffic to operator services or the internet. For example, a 5G core can be broken down into several microservice elements by separating the control plane and the user plane. Because a 5G core can include virtualized, software-based network functions (e.g., deployed as microservices) rather than physical network elements, it 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 are described in more detail below. For data traffic destined for locations outside the communication network 100, network functionality typically includes a firewall to external networks, such as the Internet or a cloud provider network, allowing traffic to enter and exit the communication network 100. It should be noted that in some embodiments, the communication network 100 may include equipment that allows traffic to enter and exit sites further downstream from the core network (e.g., aggregation sites or wireless networks 103).

[0019] The UPF is an interconnection point between mobile infrastructure and a data network (DN), that is, it provides encapsulation and decapsulation for the General Packet Radio Service (GPRS) Tunneling Protocol of the user plane (GTP-U). The UPF may also provide a session anchor point for providing mobility within the RAN, such as transmitting one or more end marker packets to a RAN base station. The UPF may also handle packet routing and forwarding, such as directing flows to a specific data network based on a traffic matching filter. Another function of the UPF includes per-flow or per-application QoS processing, such as transport-level packet marking and rate limiting for uplink (UL) and downlink (DL). The UPF can be implemented as a cloud-native network function using modern microservice techniques, and can be deployed, for example, in a serverless framework (which abstracts the underlying infrastructure on which code is executed via managed services).

[0020] The AMF may receive connection and session information from the wireless device 106 or the RAN, and may process connection and mobility management tasks. For example, the AMF may manage handover between base stations in the RAN. In some examples, the AMF may be regarded as an access point to the 5G core by terminating traffic of a specific RAN control plane and the wireless device 106. The AMF may also implement encryption and integrity protection algorithms.

[0021] The SMF may handle session establishment or modification, for example, by creating, updating and deleting a protocol data unit (PDU) session and managing a session context in the UPF. The SMF may also implement Dynamic Host Configuration Protocol (DHCP) and Internet Protocol Address Management (IPAM). The SMF may also be implemented as a cloud-native network function using modern microservice techniques.

[0022] Various network functions for implementing wireless network 103 may be deployed in distributed computing devices 112, which may correspond to general-purpose computing devices configured to execute network functions. For example, distributed computing devices 112 may run one or more virtual machine instances that are in turn configured to run one or more services that implement network functions. In one embodiment, distributed computing devices 112 are high-durability machines deployed at each cell site.

[0023] In contrast, one or more centralized computing devices 115 may perform various network functions at a customer-operated central site. For example, centralized computing devices 115 may be collectively located at a customer's premises within a conditioned server room. Centralized computing devices 115 may run one or more virtual machine instances that are in turn configured to run one or more services that implement network functions.

[0024] In one or more embodiments, network traffic from wireless network 103 is backhauled to one or more core computing devices 118, which may be located at one or more data centers remotely located from the customer's site. 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 management of communication network 100 (e.g., billing, mobility management, etc.) and transport functions for relaying traffic between communication network 100 and other networks.

[0025] Figure 2A shows an example of a network environment 200 that includes a cloud provider network 203 in several embodiments, and further includes various provider substrate extensions of the cloud provider network 203 that may be used in various locations within the communication network 100 of Figure 1. The cloud provider network 203 (sometimes simply referred to as the “cloud”) refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized or bare metal. The cloud may provide convenient on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources may be dynamically provisioned and reconfigured to adjust to fluctuating loads. Thus, cloud computing can be viewed as both applications delivered as a service over a publicly accessible network (e.g., the internet, a cellular communication network) and the hardware and software in the data centers of the cloud provider that provides those services.

[0026] The cloud provider network 203 can provide users with an on-demand, scalable computing platform over the network, allowing users to have scalable “virtual computing devices” at will, for example, through the use of compute servers (which provide compute instances with optional local storage via the use of either or both a central processing unit (CPU) and a graphics processing unit (GPU)) and block store servers (which provide virtualized persistent block storage to specified compute 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 disks, and / or solid-state drive (SSD) storage), a selected operating system, network capabilities, and preloaded application software. Each virtual computing device may also virtualize its console input / output (e.g., keyboard, display, and mouse). This virtualization allows users to configure and use their virtual computing devices as if they were personal computing devices by connecting to them using computer applications such as browsers, application programming interfaces (APIs), and software development kits (SDKs). Unlike personal computing devices, which have 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.

[0027] As described above, users can connect to virtualized computing devices and resources and services of other cloud provider networks 203 via intermediate networks 212 using various interfaces 206 (e.g., APIs). APIs refer to interfaces and / or communication protocols between client devices 215 and servers, such that when a client makes a request in a predefined format, the client must receive a response in a specific format or initiate a defined action. In a cloud provider network context, APIs provide a gateway 251 for customers to access the cloud infrastructure, enabling them to retrieve data from the cloud provider network 203 or perform actions within the cloud provider network 203, and enabling the development of applications that interact with resources and services hosted on the cloud provider network 203. APIs can also enable various services on the cloud provider network 203 to exchange data with each other. Users can choose to deploy their own virtual computing systems to provide network-based services for their own use and / or for their customers or clients.

[0028] The cloud provider network 203 may include a physical network called a substrate (e.g., sheet metal boxes, cables, rack hardware). The substrate can be considered a network fabric containing the physical hardware that runs the provider network's services. The substrate may be isolated from the rest of the cloud provider network 203, and it may be impossible, for example, to route from a substrate network address to an address in the production network running the cloud provider's services, or to a customer network hosting customer resources.

[0029] The cloud provider network 203 may also include an overlay network of virtualized computing resources running on the substrate. In at least some embodiments, a hypervisor or other device or process on the network substrate may use encapsulation protocol techniques to encapsulate and route network packets (e.g., client IP packets) on the network substrate between client resource instances on different hosts within the provider network. The encapsulation protocol techniques may be used on the network substrate to route the encapsulated packets (also called network substrate packets) between endpoints on the network substrate via overlay network paths or routes. The encapsulation protocol techniques can be thought of as providing a virtual network topology overlaid on the network substrate. Thus, network packets may be routed along the substrate network according to constructs within the overlay network (e.g., virtual networks which may be called virtual private clouds (VPCs), port / protocol firewall configurations which may be called security groups). A mapping service (not shown) may coordinate the routing of these network packets. The mapping service may also be a regional distributed lookup service that maps combinations of overlay Internet Protocol (IP) and network identifiers to substrate IPs, enabling distributed substrate computing devices to look up the destination of packets.

[0030] For example, each physical host device (e.g., compute server, block store server, object store server, control server) may have an IP address within the substrate network. Hardware virtualization technology can make it possible to run multiple operating systems simultaneously on a host computer, for example, as virtual machines (VMs) on a compute server. A hypervisor or virtual machine monitor (VMM) on the host allocates the host's hardware resources to various VMs on the host and monitors the VMs' execution. Each VM may be given one or more IP addresses within the overlay network, and the VMM on the host may be aware of the IP addresses of the VMs on the host. The VMM (and / or other devices or processes on the network substrate) may use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) on the network substrate between virtualized resources on different hosts within the cloud provider network 203. Encapsulation protocol technology may be used on the network substrate to route encapsulated packets between endpoints on the network substrate via overlay network paths or routes. Encapsulation protocol technology can be seen as providing a virtual network topology overlaid on a network substrate. Encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (e.g., IP addresses visible to the customer) to substrate IP addresses (IP addresses not visible to the customer), which can be accessed by various processes on the cloud provider network 203 to route packets between endpoints.

[0031] As illustrated, the traffic and operations of the cloud provider network substrate can be broadly subdivided into two categories in various embodiments: control plane traffic carried on the logical control plane 218 and data plane operations carried on the logical data plane 221. The data plane 221 represents the movement of user data through the distributed computing system, and the control plane 218 represents the movement of control signals through the distributed computing system. The control plane 218 generally includes one or more control plane components or services, distributed across one or more control servers and implemented by one or more control servers. Control plane traffic generally includes management operations such as establishing isolated virtual networks for various customers, monitoring resource usage and health, identifying specific hosts or servers on which requested compute instances are launched, and provisioning additional hardware as needed. The data plane 221 includes customer resources (e.g., compute instances, containers, block storage volumes, databases, file storage) implemented on the cloud provider network 203. Data plane traffic generally includes non-management operations such as data transfer to and from customer resources.

[0032] Control plane components are typically implemented on a separate set of servers from data plane servers and may be transmitted over separate, distinct networks from control plane traffic. In some embodiments, control plane traffic and data plane traffic may be supported by different protocols. In some embodiments, messages (e.g., packets) transmitted over the cloud provider network 203 include a flag indicating whether the traffic is control plane traffic or data plane traffic. In some embodiments, the traffic payload may be examined to determine its type (e.g., control plane or data plane). Other methods for distinguishing traffic types are also possible.

[0033] As illustrated, the data plane 221 may include one or more compute servers, which may be bare metal (e.g., single-tenant) or virtualized by a hypervisor to run multiple VMs (sometimes called “instances”) or microVMs for one or more customers. These compute servers may support the virtualized compute services (or “hardware virtualization services”) of the cloud provider network 203. The virtualized compute services may also be part of the control plane 218, enabling customers to issue commands via an interface 206 (e.g., an API) to launch and manage compute instances (e.g., VMs, containers) for their applications. The virtualized compute services may provide virtual compute instances with various compute and / or memory resources. In one embodiment, each virtual compute instance may correspond to one of several instance types. An instance type may be characterized by its hardware type, computing resources (e.g., number, type, and configuration of CPUs or CPU cores), memory resources (e.g., capacity, type, and configuration of local memory), storage resources (e.g., capacity, type, and configuration of locally accessible storage), network resources (e.g., characteristics of its network interface and / or network capabilities), and / or other appropriate descriptive characteristics. An instance type selection feature may be used to select an instance type for a customer, for example, based (at least partially) on customer input. For example, a customer may select an instance type from a predefined set of instance types. As another example, a customer may specify the desired resources for an instance type and / or the requirements of the workload the instance will run, and the instance type selection feature may select an instance type based on such specifications.

[0034] The data plane 221 may also include one or more block store servers, which may include persistent storage for storing volumes of customer data and software for managing these volumes. Such block store servers may support the managed block storage service of the cloud provider network 203. The managed block storage service is part of the control plane 218 and allows customers to create and manage volumes of applications running on compute instances by issuing commands via an interface 206 (e.g., an API). The block store server includes one or more servers where data is stored as blocks. A block is a sequence of bytes or bits and typically contains an integer number of records with a maximum length of the block size. Blocked data is typically stored in a data buffer, and the entire block is read or written 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. For example, a user volume, which can be treated as individual hard drives ranging in size from 1 GB to 1 terabyte (TB) or more, consists of one or more blocks stored on a block store server. It will be understood that, although treated as individual hard drives, a volume can be stored as one or more virtualization devices implemented on one or more underlying physical host devices. A volume may be partitioned a small number of times (e.g., up to 16 times), with each partition hosted by a different host. The data of a volume can be replicated across multiple devices within a cloud provider network to provide multiple replicas of the volume (such replicas may collectively represent the volume on the computing system).Volume replicas in distributed computing systems can be beneficial in that they can provide automatic failover and recovery, for example, by allowing users to access either a primary replica of the volume or a secondary replica of the volume synchronized with the primary replica at the block level, ensuring that access to the volume's information is not disrupted by a failure in either the primary or secondary replica. The role of the primary replica may be to facilitate reading and writing to the volume (sometimes called "input / output operations" or simply "I / O operations") and to reflect any writes to the secondary (sometimes using asynchronous replication, but preferably synchronously on the I / O path). The secondary replica can be updated synchronously with the primary replica and provide a seamless transition during failover operations, where the secondary replica takes over the role of the primary replica, the previous primary is designated as the secondary, or a new alternative secondary replica is provisioned. While the specific examples herein describe primary and secondary replicas, it will be understood that a logical volume can contain multiple secondary replicas. Compute instances may virtualize their I / O to the volume via clients. A client corresponds to an instruction that allows a compute instance to connect to a remote data volume (for example, a data volume stored on a physically separate computing device accessed over a network) and perform I / O operations on the remote data volume. A client may be implemented on an offload card of a server that contains the compute instance's processing unit (e.g., CPU or GPU).

[0035] The data plane 221 may also include one or more object store servers, which represent another type of storage within the cloud provider network 203. The object storage servers include one or more servers where data is stored as objects within resources called buckets, and may be used to support the managed object storage services of the cloud provider network 203. Each object typically includes the data it stores, a variable amount of metadata that enables various functions of the object storage server regarding the analysis 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. A customer can store any number of objects in their buckets, write, read, and delete objects in their buckets, and control access to their buckets and the objects they contain. Furthermore, in embodiments where several different object storage servers are distributed across different regions among the regions described above, a user can choose the region (or multiple regions) in which a bucket is stored, for example, to optimize latency. A customer can use buckets to store various types of objects, such as machine images that can be used to boot VMs, or snapshots representing a point-in-time view of data on a volume.

[0036] The Provider Substrate Extension 224 ("PSE") provides 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 a new location (for example, for reasons related to communication latency with customer devices, regulatory compliance, security, etc.). In some embodiments, the PSE 224 can be configured to provide capacity for cloud-based workloads running within the telecommunications network. In some embodiments, the PSE 224 can be configured to provide core and / or RAN functionality of the telecommunications network, and can be configured with additional hardware (e.g., radio access hardware). Some embodiments can be configured to enable both, for example, by making unused capacity available for running cloud-based workloads through core and / or RAN functionality.

[0037] As illustrated, such a provider substrate extension 224 may include, among other possible types of substrate extensions, a cloud provider network managed provider substrate extension 227 (e.g., formed by servers located in a cloud provider-managed facility separate from the one associated with the cloud provider network 203), a communications service provider managed provider substrate extension 230 (e.g., formed by servers associated with a communications service provider facility), and a customer managed provider substrate extension 233 (e.g., formed by servers located on-premises in a customer or partner facility).

[0038] As illustrated in the exemplary provider substrate extension 224, the provider substrate extension 224 may also include a logical separation between the control plane 236 and the data plane 239, extending the control plane 218 and the data plane 221 of the cloud provider network 203, respectively. The provider substrate extension 224 may be pre-configured, for example, by the cloud provider network operator to reflect the experience of using the cloud provider network 203 to do so, using an appropriate combination of hardware with software and / or firmware elements to support various types of computing-related resources. For example, one or more provider substrate extension location servers may be provisioned by the cloud provider for deployment within the provider substrate extension 224. As described above, the cloud provider network 203 may offer a set of predefined instance types, each having different types and amounts of underlying hardware resources. Each instance type may also be offered in various sizes. The servers may be heterogeneous servers so that customers can continue to use the same instance types and sizes in the provider substrate extension 224 that they are using in the region. Heterogeneous servers can simultaneously support multiple instance sizes of the same type and can be reconfigured to host any instance type supported by their underlying hardware resources. Reconfiguration of heterogeneous servers can be performed on the fly using the server's available capacity, that is, while other VMs are still running and consuming other capacity on the provider substrate extension location server.This improves the utilization of computing resources in edge locations by enabling better packing of instances running on servers, and also provides a seamless experience for using instances across the cloud provider network 203 and the cloud provider network managed provider substrate extension 227.

[0039] A provider substrate extension server may host one or more compute instances. These compute instances may be VMs or containers that package the code and all its dependencies, enabling the application to run quickly and reliably across the computing environment (including VMs and microVMs). Additionally, depending on customer preference, the server may host one or more data volumes. In a region of the cloud provider network 203, such volumes may be hosted on a dedicated blockstore server. However, because the capacity of a provider substrate extension 224 may be significantly smaller than that within a region, including such a dedicated blockstore server may not provide an optimal user experience. Therefore, the block storage service may be virtualized within the provider substrate extension 224, such that one of the VMs runs the blockstore software and stores the volume's data. Similar to the operation of the block storage service in a region of the cloud provider network 203, volumes within the provider substrate extension 224 may be replicated for durability and availability. Volumes may be provisioned within their own isolated virtual network within the provider substrate extension 224. Computation instances and any volumes collectively constitute a data plane extension 239 of the provider network data plane 221 within the provider substrate extension 224.

[0040] In some embodiments, servers within the provider substrate extension 224 may host certain local control plane components, such as components that enable the provider substrate extension 224 to continue functioning if the connection back to the cloud provider network 203 is interrupted. Examples of these components include a migration manager that can move compute instances between provider substrate extension servers as needed to maintain availability, and a key-value datastore that indicates the location of volume replicas. However, generally, the control plane 236 functionality of the provider substrate extension 224 remains with the cloud provider network 203 to allow customers to use as much of the provider substrate extension 224's resource capacity as possible.

[0041] A migration manager may have a centralized coordinating component running within a region, in addition to a local controller running on a PSE server (and a server in the cloud provider's data center). The centralized coordinating component can identify the target edge location and / or target host when a migration is triggered, and the local controller can coordinate data transfer between the source and target hosts. The described movement of resources between hosts in different locations can take one of several migration forms. A migration refers to moving virtual machine instances (and / or other resources) between hosts within a cloud computing network, or between a host outside the cloud computing network and a host in the cloud. There are various types of migrations, such as live migrations and reboot migrations. During a reboot migration, the customer experiences a shutdown and effective power-on of the virtual machine instances. For example, a control plane service may coordinate a reboot migration workflow that involves discarding the current domain on the original host and then creating a new domain for the virtual machine instances on the new host. The instances are rebooted by being shut down on the original host and started up again on the new host.

[0042] Live migration refers to the process of moving a running virtual machine or application between different physical machines without significantly compromising the virtual machine's availability (for example, without the virtual machine downtime being noticeable to end users). When the control plane executes a live migration workflow, it can create a new "inactive" domain associated with the instance, while the instance's original domain continues to run as the "active" domain. The virtual machine's memory (including any in-memory state of the running application), storage, and network connectivity are transferred from the original host with the active domain to the destination host with the inactive domain. The virtual machine may be briefly paused to prevent state changes while its memory contents are being transferred to the destination host. The control plane may migrate the inactive domain to become an active domain, demote the original active domain to an inactive domain (also known as "flipping"), and then discard the inactive domain.

[0043] Various types of migration methods involve managing the critical phase (the time when the customer cannot access the virtual machine instance), and this phase should be as short as possible. This management can be particularly challenging with currently disclosed migration methods, as resources are moved between hosts in geographically separated locations that may be connected via one or more intermediate networks. For live migrations, the disclosed methods can dynamically determine the amount of memory state data to copy beforehand (e.g., while the instance is still running on the source host) and afterward (e.g., after the instance has started running on the destination host), based on factors such as latency between locations, network bandwidth / usage patterns, and / or which memory pages are most frequently used by the instance. Furthermore, the specific time at which the memory state data is transferred can be dynamically determined based on the network conditions between locations. This analysis may be performed by a migration management component within a region or by a migration management component running locally at the source edge location. If the instance has access to virtualized storage, both the source and target domains can be attached to the storage simultaneously to allow uninterrupted access to that data during migration or if a rollback to the source domain is required.

[0044] Server software running on the provider substrate extension 224 may be designed by the cloud provider to run on the cloud provider substrate network, and this software may be able to run without modification within the provider substrate extension 224 by creating private replicas ("shadow substrates") of the substrate network within edge locations using local network managers 242. Local network managers 242 operate on the provider substrate extension 224 server and can bridge the shadow substrates to the provider substrate extension 224 network, for example, by acting as one or more virtual private network (VPN) endpoints between the provider substrate extension 224 and proxies 245, 248 in the cloud provider network 203, and by implementing mapping services (for traffic encapsulation and decapsulation) that associate data plane traffic (from data plane proxy 248) and control plane traffic (from control plane proxy 245) with the appropriate servers. By implementing a local version of the provider network's substrate overlay mapping service, the local network manager(s) 242 enables resources within the provider substrate extension(s) 224 to communicate seamlessly with resources within the cloud provider network(s) 203. In some embodiments, a single local network manager(s) 242 may perform these actions for all servers hosting compute instances within the provider substrate extension(s) 224. In other embodiments, each server hosting compute instances may have its own dedicated local network manager(s) 242.In a multi-rack edge location, local network managers maintain open tunnels with each other, allowing inter-rack communication to pass through local network manager 242.

[0045] Provider Substrate Extension locations can utilize secure network tunnels to the Cloud Provider Network 203 via the Provider Substrate Extension 224 network to maintain the security of customer data as it traverses the Provider Substrate Extension 224 network and other intermediate networks (which may include the public internet). Within the Cloud Provider Network 203, these tunnels consist of virtual infrastructure components including isolated virtual networks (e.g., within the overlay network), a control plane proxy 245, a data plane proxy 248, and a substrate network interface. Such proxies 245 and 248 may be implemented as containers running on compute instances. In some embodiments, each server in the Provider Substrate Extension 224 location hosting compute instances can utilize at least two tunnels: one for control plane traffic (e.g., Constrained Application Protocol (CoAP) traffic) and another for encapsulated data plane traffic. A connectivity manager (not shown) within the Cloud Provider Network 203 manages the Cloud Provider Network-side lifecycle of these tunnels and their components, for example, by automatically provisioning them as needed and maintaining them in a healthy operational state. In some embodiments, a direct connection between the provider substrate extension 224 location and the cloud provider network 203 may be used for control plane and data plane communications. Compared to VPNs over other networks, a direct connection can offer consistent bandwidth and more consistent network performance because its network path is relatively fixed and stable.

[0046] A control plane (CP) proxy 245 may be provisioned within the cloud provider network 203 to represent a specific host(s) at an edge location. The CP proxy 245 acts as an intermediary between the control plane 218 in the cloud provider network 203 and the control plane target in the control plane 236 of the provider substrate extension 224. In other words, the CP proxy 245 provides the infrastructure for tunneling management API traffic destined for the provider substrate extension server from the regional substrate to the provider substrate extension 224. For example, a virtualization computing service in the cloud provider network 203 might issue commands to the VMM of a server in the provider substrate extension 224 to start compute instances. The CP proxy 245 maintains a tunnel (e.g., VPN) to the local network manager 242 of the provider substrate extension 224. Software implemented within the CP proxy 245 ensures that only eligible API traffic leaves the substrate and returns to it. The CP proxy 245 provides a mechanism to expose remote servers on the cloud provider substrate while continuing to protect the substrate's security material (e.g., encryption keys, security tokens) from leaking out of the cloud provider network 203. The one-way control plane traffic tunnel imposed by the CP proxy 245 also prevents any (potentially compromised) device from calling back to the substrate. The CP proxy 245 may be instantiated one-to-one with a server in the provider substrate extension 224, or it may manage the control plane traffic of multiple servers within the same provider substrate extension.

[0047] A data plane (DP) proxy 248 may also be provisioned within the cloud provider network 203 to represent a specific server(s) within the provider substrate extension 224. The DP proxy 248 may act as a shadow or anchor for the server(s) and be used by services within the cloud provider network 203 to monitor host health (including availability, used / free compute and capacity, used / free storage and capacity, and network bandwidth usage / availability). The DP proxy 248 also acts as a proxy for the server(s) within the cloud provider network 203, enabling the isolated virtual network to extend between the provider substrate extension 224 and the cloud provider network 203. Each DP proxy 248 may be implemented as a packet forwarding compute instance or container. As illustrated, each DP proxy 248 can maintain a VPN tunnel with a local network manager 242 that manages traffic to the server(s) represented by the DP proxy 248. This tunnel can be used to transmit data plane traffic between the provider substrate extension server(s) and the cloud provider network 203. Data plane traffic flowing between the provider substrate extension 224 and the cloud provider network 203 can pass through the DP proxy 248 associated with that provider substrate extension 224. In the case of data plane traffic flowing from the provider substrate extension 224 to the cloud provider network 203, the DP proxy 248 may receive the encapsulated data plane traffic, verify its accuracy, and allow it to enter the cloud provider network 203. The DP proxy 248 can then forward the encapsulated traffic directly from the cloud provider network 203 to the provider substrate extension 224.

[0048] The local network manager(s) 242 can provide secure network connectivity to proxies 245, 248 established within the cloud provider network 203. After connectivity is established between the local network manager 242 and proxies 245, 248, the customer may issue such commands via interface 206 using the provider substrate extension resources in the same way that commands would be issued for compute instances hosted within the cloud provider network 203, in order to instantiate compute instances (and / or perform other operations using compute instances). From the customer's perspective, the customer can now seamlessly use local resources within the provider substrate extension 224 (and resources in the cloud provider network 203, if desired). Compute instances set up on the server in the provider substrate extension 224 may communicate with both electronic devices on the same network and other resources set up within the cloud provider network 203, as desired. A local gateway 251 may be implemented to provide network connectivity between the provider substrate extension 224 and the network to which the extension is coupled (for example, the communication service provider network in the example of the provider substrate extension 230).

[0049] In some situations, data transfer between the object storage service and the Provider Substrate Extension (PSE) 224 may be necessary. For example, the object storage service may store machine images used to boot VMs and snapshots representing point-in-time backups of volumes. The object gateway may provide customers with a configurable per-bucket cache of the contents of object storage buckets within the PSE 224, delivered on a PSE server or a specialized storage device, to minimize the impact of PSE region latency on customer workloads. The object gateway may also temporarily store snapshot data from snapshots of volumes within the PSE 224 and, where possible, synchronize it with object servers in the region. The object gateway may also store machine images designated by the customer for use within the PSE 224 or on the customer's premises. In some embodiments, data within the PSE 224 may be encrypted with a unique key, and the cloud provider may, for security reasons, restrict the sharing of keys from the region to the PSE 224. Therefore, data exchanged between the object store server and the object gateway may utilize encryption, decryption, and / or re-encryption to maintain security boundaries regarding encryption keys or other sensitive data. The conversion means can perform these operations, and a PSE bucket may be created (on the object store server) to store snapshot data and machine image data using the PSE encryption key.

[0050] As described above, the PSE224 forms an edge location in that it provides resources and services of the cloud provider network 203 to customer devices outside of traditional cloud provider data centers. The edge locations referred to herein can be structured in several ways. In some embodiments, an edge location may be an extension of the cloud provider network substrate, containing a limited amount of capacity provided outside of an availability zone (for example, within a small data center or other facility of the cloud provider, located near the customer workload and potentially far from any availability zone). Such an edge location may be called a “far zone” (because it is far from other availability zones) or a “near zone” (because it is close to the customer workload). Near zones may be connected to a publicly accessible network such as the internet in various ways, for example, directly, via another network, or via a private connection to a region. Typically, near zones have limited capacity compared to regions, but in some cases, near zones may have a considerable capacity, such as thousands of racks or more.

[0051] In some embodiments, the edge location may be an extension of the cloud provider network substrate formed by one or more servers located on-premises at a customer or partner facility, such servers(s) communicating with a nearby availability zone or region of the cloud provider network 203 via a network (e.g., a publicly accessible network such as the internet). This type of substrate extension located outside the cloud provider network data center is sometimes referred to as an “outpost” of the cloud provider network 203. Some outposts may be integrated into the communications network as multi-access edge computing (MEC) sites with physical infrastructure that extends across telecommunications data centers, telecommunications aggregation sites, and / or telecommunications base stations within the telecommunications network. In the on-premises example, the limited capacity of the outpost may be available only to the customer who owns the facility (and any other accounts authorized by the customer). In the telecommunications example, the limited capacity of the outpost may be shared among multiple applications (e.g., games, virtual reality applications, healthcare applications) that transmit data to users of the telecommunications network.

[0052] An edge location can include data plane capacity that is at least partially controlled by the control plane of an availability zone near the provider network. Thus, an availability zone group may include a “parent” availability zone and any “child” edge locations that are home to the parent availability zone (e.g., at least partially controlled by its control plane). Certain limited control plane functions (e.g., functions requiring low-latency communication with customer resources, and / or functions that enable the edge location to continue functioning when disconnected from the parent availability zone) may also be present at some edge locations. Therefore, in the above example, an edge location refers to at least an extension of data plane capacity located at the edge of the cloud provider network 203, closer to customer devices and / or workloads.

[0053] In the example in Figure 1, the distributed computing device 112 (Figure 1), the centralized computing device 115 (Figure 1), and the core computing device 118 (Figure 1) may be implemented as a provider substrate extension 224 of the cloud provider network 203. The installation or placement of the provider substrate extension 224 within the communication network 100 may vary depending on the specific network topology or architecture of the communication network 100. The provider substrate extension 224 can generally connect to anywhere the communication network 100 can generate packet-based traffic (e.g., IP-based traffic). Furthermore, communication between a given provider substrate extension 224 and the cloud provider network 203 typically traverses at least a portion of the communication network 100 securely (e.g., via a secure tunnel, virtual private network, direct connection, etc.).

[0054] In 5G wireless network development efforts, edge locations are sometimes considered as a potential implementation of Multi-Access Edge Computing (MEC). Such edge locations can connect to various points within the 5G network that provide data traffic breakout as part of the User Plane Function (UPF). Edge locations can also be incorporated into older wireless networks. For example, in a 3G wireless network, an edge location can connect to the packet-switched network portion of the communications network 100, such as a Serving General Purpose Packet Radio Service Support Node (SGSN) or a Gateway General Purpose Packet Radio Service Support Node (GGSN). In a 4G wireless network, an edge location can connect to a Serving Gateway (SGW) or Packet Data Network Gateway (PGW) as part of the core network or an Evolutionary Packet Core (EPC). In some embodiments, traffic between a provider substrate extension 224 and a cloud provider network 203 can be decoupled from the communications network 100 without being routed through the core network.

[0055] In some embodiments, the provider substrate extension 224 may connect to multiple communication networks associated with each customer. For example, if two communication networks of each customer share or route traffic through a common point, the provider substrate extension 224 may connect to both networks. For example, each customer may allocate a portion of its network address space to the provider substrate extension 224, and the provider substrate extension may include a router or gateway capable of distinguishing the traffic exchanged with each of the communication networks 100. For example, traffic destined for the provider substrate extension 224 from one network may have a different destination IP address, source IP address, and / or virtual local area network (VLAN) tag than traffic received from another network. Similarly, traffic destined for a destination in one of the networks from the provider substrate extension 224 can be encapsulated so as to have an appropriate VLAN tag, a source IP address (e.g., from a pool allocated to the provider substrate extension 224 from the destination network address space), and a destination IP address.

[0056] Figure 2B shows an example 253 of the cellularization and geographical distribution of a communications network 100 (Figure 1) for providing High Availability User Plane (UPF) functionality. In Figure 2B, a user device 254 communicates with a request router 255 to route requests to one of several control plane cells 257a and 257b. Each control plane cell 257 may include a network service API gateway 260, network slice configuration 262, network service monitoring functions 264, site planning data 266 (including layout, device types, device quantities, etc., describing customer site requirements), a network service / function catalog 268, orchestration functions 270, and / or other components. To reduce the possibility of large-scale errors affecting a wide range of customers, a large control plane may be divided into cells by providing one or more cells that operate independently, for example, per customer, per network, or per region.

[0057] The Network Services / Function Catalog 268 is also known as the NF Repository Function (NRF). In a Service-Based Architecture (SBA) 5G network, the control plane functions and the common data repository may be delivered via a set of interconnected network functions built using a microservices architecture. The NRF can maintain 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 can support service discovery by receiving discovery requests from NF instances and can specify which NF instances support particular services. The Network Function Orchestrator 270 may perform NF lifecycle management, including instantiation, scale-out / in, performance measurement, event correlation, and termination. The Network Function Orchestrator 270 may also onboard new NFs, manage migrations to new or updated versions of existing NFs, identify sets of NFs suitable for a particular network slice or larger network, and orchestrate NFs across various computing devices and sites that make up the wireless network 103.

[0058] The control plane cell 257 may communicate with one or more cell sites 272, one or more customer local data centers 274, one or more local zones 276, and one or more regional zones 278. The cell site 272 includes computing hardware 280 running one or more distributed unit (DU) network functions 282. The customer local data center 274 includes computing hardware 283 running 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.

[0059] Local zone 276 may be located within a data center operated by a cloud service provider and may run one or more core network functions 288, such as AMF, SMF, a network exposure function (NEF) that securely exposes the services and capabilities of other network functions, and an integrated data management (UDM) function that manages subscriber data for authorization, registration, and mobility management. Local zone 276 may also run UPF 286, a metric processing service 289, and one or more edge applications 287.

[0060] Regional Zone 278 may be located within a data center operated by a cloud service provider and may run one or more core network functions 288; UPF 286; an operational support system (OSS) 290 supporting network management, service delivery, service performance, service assurance, and customer care; an Internet Protocol Multimedia Subsystem (IMS) 291; a business support system (BSS) 292 supporting product management, customer management, revenue management, and / or order management; one or more portal applications 293, and / or other components.

[0061] In this example, the communication network 100 employs a cellular architecture to reduce the explosion radius of individual components. At the highest level, the control plane resides within multiple control plane cells 257 to prevent failures in individual control planes from affecting the entire deployment.

[0062] Within each control plane cell 257, there may be multiple redundant stacks with control planes that shift traffic to secondary stacks as needed. For example, cell site 272 may be configured to use the nearby local zone 276 as its default core network. If local zone 276 goes down, the control plane can redirect cell site 272 to use a backup stack in regional zone 278. Traffic that would normally be routed from the internet to local zone 276 may be shifted to an endpoint in regional zone 278. Each control plane cell 278 may implement a "stateless" architecture that shares a common session database across multiple sites (across availability zones or edge sites, for example).

[0063] Figure 3 shows an exemplary cloud provider network 203 including geographically distributed provider substrate extensions 224 (Figure 2A) (or “edge locations 303”) in several embodiments. 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) connected to each other via a private high-speed network, such as fiber optic connections. An availability zone refers to an isolated fault domain, including one or more data center facilities with separate power supplies, separate networks, and separate cooling from other availability zones. The cloud provider may endeavor to place availability zones within a region 306 far enough apart from each other to prevent multiple availability zones from going offline simultaneously due to natural disasters, large-scale power outages, or other unforeseen events. Customers can connect to resources within the availability zones of the cloud provider network 203 via publicly accessible networks (e.g., the internet, cellular communication networks, communication service provider networks). Transit Centers (TCs) are the primary backbone locations linking customers to the cloud provider network 203 and may be located in the same locations as other network provider facilities (e.g., Internet service providers, telecommunications providers). Each region 306 can operate two or more TCs for redundancy. Regions 306 are connected to a global network that includes a private network infrastructure (e.g., fiber connectivity controlled by the cloud service provider) connecting each region 306 to at least one other region. The cloud provider network 203 can deliver content from points of presence ("PoPs") located outside of these regions 306 but networked with them, via edge locations 303 and regional edge cache servers.This segmentation and geographical distribution of computing hardware enables the cloud provider network 203 to provide customers with global, low-latency resource access with a high degree of fault tolerance and stability.

[0064] The number of edge locations 303 can be much larger than the number of regional data centers or availability zones. Deploying edge locations 303 extensively in this way can provide low-latency connectivity to the cloud for a much larger group of end-user devices (compared to end-user devices that happen to be very close to regional data centers). In some embodiments, each edge location 303 may peer with a portion of the cloud provider network 203 (e.g., a parent availability zone or regional data center). Such 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 or installed in the same facility (e.g., separate racks of computer systems) and managed by different zones or data centers 309 to provide additional redundancy. In this specification, edge locations 303 are typically shown as being within the telecommunications service provider network or wireless network 103 (Figure 1). However, it should be noted that in some cases, such as when the cloud provider network facilities are relatively close to the telecommunications service provider facilities, edge locations 303 may remain within the physical premises of the cloud provider network 203 while being connected to the telecommunications service provider network via fiber or other network links.

[0065] Edge Location 303 can be structured in several ways. In some embodiments, Edge Location 303 may be an extension of the cloud provider network substrate containing a limited amount of capacity provided outside of an availability zone (for example, in a small data center or other facility of the cloud provider, located near customer workloads and potentially far from any availability zone). Such Edge Location 303 may be referred to as a local zone (because it is closer to local or user groups than traditional availability zones). A local zone may be connected to a publicly accessible network such as the internet in various ways, for example, directly, via another network, or via a private connection to Region 306. While local zones typically have limited capacity compared to Region 306, in some cases, a local zone may have a considerable capacity, such as thousands of racks or more. Some local zones may use infrastructure similar to a typical cloud provider data center instead of the Edge Location 303 infrastructure described herein.

[0066] As described herein, the cloud provider network 203 can be formed as several regions 306, each region 306 representing a geographical area where the cloud provider clusters data centers 309. Each region may further include multiple (e.g., two or more) Availability Zones (AZs) connected to one another via a private high-speed network, such as fiber optic communication connectivity. An AZ may provide an isolated fault domain, including one or more data center facilities with separate power supplies, separate networks, and separate cooling from other AZs. It is preferable that AZs within a region 306 be located in locations sufficiently far apart from each other so that the same natural disaster (or other event causing a failure) does not affect them or take multiple AZs offline simultaneously. Customers can connect to the AZs of the cloud provider network 203 via a publicly accessible network (such as the Internet or a cellular communication network).

[0067] The parenting of a given edge location 303 to an AZ or region 306 of the cloud provider network 203 can be based on several factors. One such parenting factor is data sovereignty. For example, to keep data originating from a country's communication network within that country, an edge location 303 deployed within that communication network can be parented to an AZ or region 306 within that country. Another factor is service availability. For example, some edge locations 303 may have different hardware configurations, such as the presence or absence of components like local non-volatile storage (e.g., solid-state drives) for customer data, or graphics accelerators. Some AZs or regions 306 may lack the services to leverage those additional resources, so the edge location may be parented to an AZ or region 306 that supports the use of those resources. Another factor is latency between the AZ or region 306 and the edge location 303. Deploying edge location 303 within a communications network offers latency benefits, but these benefits can be negated by parenting edge location 303 to a remote Availability Zone (AZ) or region 306, which introduces significant latency to the regional traffic of edge location 303. Therefore, edge location 303 is often parented to a nearby AZ or region 306 (in terms of network latency).

[0068] Referring to Figure 4, various embodiments of the network environment 400 are shown. The network environment 400 includes a computing environment 403, one or more client devices 406, one or more pre-deployed devices 409, and one or more wireless networks 103 that communicate with each other via network 412. Network 412 includes, for example, the Internet, intranet, extranet, wide area network (WAN), local area network (LAN), wired network, wireless network, cable network, satellite network, or other suitable network, or any combination of two or more such networks.

[0069] The computing environment 403 may include, for example, a server computer or any other system that provides computing capacity. Alternatively, the computing environment 403 may employ multiple computing devices that can be located in, for example, one or more server banks or computer banks or other arrangements. Such computing devices may be located in a single facility or may be distributed across many different geographical locations. For example, the computing environment 403 may include multiple computing devices that together comprise host computing resources, grid computing resources, and / or any other distributed computing arrangements. In some cases, the computing environment 403 may accommodate elastic computing resources whose allocated capacity for processing, networking, storage, or other computing-related resources may change over time. For example, the computing environment 403 may correspond to a cloud provider network 203 (Figure 2A), where customers are billed according to their use of computing resources based on a utility computing model.

[0070] In some embodiments, the computing environment 403 may correspond to a virtualized private network within a physical network, which may include virtual machine instances running on physical computing hardware, for example, by a hypervisor. The virtual machine instances and the containers running on these instances may be provided with network connectivity via virtualized network components made available by physical network components such as routers and switches.

[0071] Various applications and / or other functions may be executed in the computing environment 403 according to various embodiments. Various data are also stored in a data store 415 accessible to the computing environment 403. The data store 415 may represent multiple data stores 415, as can be understood. The data stored in the data store 415 is associated, for example, with the operation of various applications and / or functional entities described below.

[0072] The computing environment 403, as part of the cloud provider network 203 providing 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. Computing architectures may differ by utilizing processors with different architectures such as x86, x86_64, ARM, Scalable Processor Architecture (SPARC), and PowerPC. For example, one computing device 418 may have an x86 processor, while another computing device 418 may have an ARM processor. Computing devices 418 may also differ in available hardware resources, such as local storage, graphics processing units (GPUs), machine learning extensions, and other characteristics.

[0073] The allocated computing capacity 421 can correspond to virtual machine (VM) instances, containers, or serverless functions running on computing device 418. Virtual machine instances can be instantiated from virtual machine (VM) images. For this purpose, customers may specify that virtual machine instances should be launched within computing device 418 rather than on other types of computing devices 418. In various examples, a single VM instance may run alone on a particular computing device 418, or multiple VM instances may run on a particular computing device 418. Also, a particular computing device 418 can run different types of VM instances or containers, which can provide different amounts of resources available through computing device 418. For example, one type of VM instance or container may provide more memory and processing power than another type of VM instance or container.

[0074] Components running on the computing environment 403 include, for example, a network slice allocation service 425, a content delivery service 426, and other applications, services, processes, systems, engines, or functions not described in detail herein. The network slice allocation service 425 is performed to allocate network slices on demand to applications and / or client devices 406 connected to the RAN of the wireless network 103 having an associated core network. As used herein, the term “network slice” refers to a specific network traffic to which priority is assigned according to one or more quality of service requirements, and / or to which hardware capacity is reserved for receiving, transmitting, or managing network traffic. The network traffic of a network slice may be identified at one or more network layers, such as the application layer, session layer, transport layer, network layer, or data link layer (for example, by deep packet inspection). A network slice may be ephemeral, have a specific duration in terms of time or data volume, or exist until released or canceled. The network slice allocation service 425 may support an application programming interface (API) that can be invoked by applications on client devices 406 and / or backend services interacting with those applications to request the allocation, modification, or release of network slices. The network slice allocation service 427 allocates network slices on the wireless network 103, but there may be one or more devices coupled to the wireless network 103 via one or more fixed links or wired links, and the network slices determined by the network slice allocation service 427 may also be applicable to such devices.

[0075] To allocate network slices, the network slice allocation service 425 may dynamically configure one or more network functions within the wireless network 103 to implement quality of service requirements for network traffic that meet network slice specifications. It should be noted that network slices may have higher or lower priority than normal traffic and therefore may have higher or lower corresponding costs than normal usage costs. In some scenarios, the network slice allocation service 425 may 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 network functions that implement network slices may result in lower latency. In some embodiments, the network slice allocation service 425 may also relocate network function workloads at different points within the wireless network 103 to meet quality of service requirements. Furthermore, the network slice allocation service 425 may instantiate a content delivery service 426 to provide content 427 at different points within the wireless network 103 to meet quality of service requirements.

[0076] In some embodiments, an application developer or application owner can specify the required network slice configuration within an application template used to deploy a particular application within the cloud provider network 203, so that the application can provide this information to the network slice allocation service 427 when making API-based requests to the network slice. In some embodiments, the network slice allocation service 427 automatically determines one or more optimal network slices for a customer's application or the entire wireless network 103. To achieve this objective, the network slice allocation service 427 may train one or more machine learning models to recognize network slice configurations considering customer conditions or conditions across multiple customers. In this case, the machine learning models may be used to identify the optimal network slice to allocate to a given device type or application determined to be present within the wireless network 103. For example, the network slice allocation service 427 can receive detailed network information or automatically investigate the wireless network 103 to understand devices, applications, latency, usage patterns, etc. The network slice allocation service 427 can then provide this information to a machine learning model to automatically determine one or more network slices to optimize latency, bandwidth, reliability, or other metrics. These automatically determined network slices may then be automatically allocated by the network slice allocation service 427.

[0077] The content delivery service 426 operates from edge locations (collectively referred to as a content delivery network or CDN, such as the PoP and other edge locations 303 described herein) to deliver content 427 to applications running on client devices 406 coupled to the wireless network 103. In some embodiments, the content delivery service 426 proactively caches specific items of content 427 at the edge of the wireless network 103 or another location to meet the quality of service requirements of the network slice. The content 427 may be determined prior to any content consumption request by the customer, at least in part, based on the customer's account, which includes interests, consumption history, subscription status, browsing history, purchase history, and / or other information. In some scenarios, the content delivery service 426 may be self-hosted by the customer associated with the wireless network 103.

[0078] The data stored in the data store 415 may include, for example, one or more network plans 439, one or more cellular topologies 442, one or more spectrum allocations 445, device data 448, one or more RBN metrics 451, customer billing data 454, wireless 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, one or more network slices 470, and potentially other data.

[0079] Network Plan 439 is a specification for the wireless network 103 to be deployed for the customer. For example, Network Plan 439 may include the on-site locations or geographical areas to be covered, the number of cells, device identification information and authorization, desired maximum network latency, desired bandwidth or network throughput for one or more classes of devices, one or more quality of service parameters for an application or service, and / or other parameters that can be used to create the wireless network 103. The customer may manually specify one or more of these parameters via a user interface. One or more of the parameters may be pre-configured as default parameters. In some cases, Network Plan 439 may be generated for the customer based at least in part on an automated field survey using an unmanned aerial vehicle. The parameter values ​​defining Network Plan 439 may be used as a basis for billing the customer under a utility computing model. For example, in a Service Level Agreement (SLA), the customer may be billed a higher amount for lower latency targets and / or higher bandwidth targets, and the customer may be billed per device, per cell, based on the geographical area provided, spectrum availability, etc.

[0080] The cellular topology 442 includes a multi-cell arrangement for the customer, taking into account cell locations and, where possible, frequency spectrum reuse. The cellular topology 442 can be automatically generated by performing a site survey. In some cases, the number of cells in the cellular topology 442 can be automatically determined based on the desired geographical area to be covered, the availability of backhaul connectivity at various sites, signal propagation, available frequency spectrum, and / or other parameters.

[0081] Spectrum allocation 445 includes frequency spectrum available for allocation to wireless network 103 and frequency spectrum currently allocated to wireless network 103. Frequency spectrum may include spectrum that is publicly accessible without restriction, spectrum that is personally owned or leased by a customer, spectrum that is owned or leased by a provider, and spectrum that is free to use but requires reservation.

[0082] Device data 448 corresponds to data describing a wireless device 106 (Figure 1) that is authorized to connect to the wireless network 103. This device data 448 includes the corresponding user, account information, billing information, data plan, authorized application or use, an indication of whether the wireless device 106 is mobile or stationary, location, current cell, network address, and device identifier (e.g., International Mobile Device Identification (IMEI) number, Device Serial Number (ESN), Media Access Control (MAC) address, Subscriber Identification Module (SIM) number, etc.).

[0083] RBN metrics 451 include various metrics or statistics that indicate the performance or health of the wireless network 103. Such RBN metrics 451 may include bandwidth metrics, dropped packet metrics, signal strength metrics, delay metrics, etc. RBN metrics 451 may be aggregated per device, per cell, per customer, etc.

[0084] Customer billing data 454 specifies the charges that the customer should bear for the provider's operation of the wireless network 103 for the customer. These charges may include fixed costs based on the equipment deployed to the customer and / or usage-based charges. In some cases, the customer may have purchased the equipment upfront and only the cost of bandwidth or backend networking may be charged. In other cases, the customer may not have incurred any upfront costs and may be charged purely on usage. Because equipment is provided to the customer based on a utility computing model, the cloud service provider can select the optimal equipment configuration to meet the customer's target performance metrics while avoiding unnecessary over-provisioning of hardware.

[0085] The wireless unit configuration data 457 may correspond to the configuration settings of the wireless unit to be deployed in the wireless 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.

[0086] The 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 (e.g., by networked motors and control devices on the antenna), or other parameters that can be manually controlled by instructing the user to mount the antenna in a specific way or to make physical changes to the antenna.

[0087] Network function configuration data 463 corresponds to configuration settings that constitute the operation of various network functions of the wireless network 103. In various embodiments, network functions may be deployed on VM instances or containers located on computing devices 418 in a data center located at a cell site, customer aggregation site, or remotely from the customer. Non-exclusive examples of network functions may include access and mobility management functions, session management functions, user plane functions, policy control functions, authentication server functions, integrated data management functions, application functions, network publishing functions, network function repositories, network slice selection functions, and / or others. Network function workload 466 corresponds to a machine image, container, or function for running one or more network functions.

[0088] Customer workload 469 corresponds to a customer machine image, container, or function that can run as a VM instance or container, either in parallel with or instead of a network function VM instance or container. For example, customer workload 469 may provide or support a customer application or service.

[0089] A network slice 470 corresponds to a flow of network traffic specified for one or more specific quality of service requirements 471. The flow may correspond to a flow associated with a specific application running on a particular client device 406, all network traffic from a particular client device 406, a flow from all client devices 406 to a specific destination, or a flow from a particular client device 406 to a specific destination. For example, a network slice 470 is identified by a source port, source network address, destination port, destination network address, and / or other information. A network slice 470 may be valid for a specific period or a specific amount of data, or it may be valid until canceled or released. For example, a network slice 470 is allocated on demand for a specific application running on a client device 406. In some scenarios, a network slice 470 may have a specific recurring validity period (e.g., from midnight to 5am on weekdays each week), or the quality of service requirements 471 for a network slice 470 may change based on the recurring period, current cost level, and / or other factors or events.

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

[0091] The client device 406 represents a plurality of client devices 406 that can be connected to the network 412. The 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 form of a desktop computer, laptop computer, personal digital assistant, mobile phone, smartphone, set-top box, music player, webpad, tablet computer system, game console, e-reader, smartwatch, head-mounted display, voice interface device, or other device. The client device 406 may include a display comprising one or more devices such as a liquid crystal display (LCD), gas plasma-based flat panel display, organic light-emitting diode (OLED) display, electronic ink (E-ink) display, LCD projector, or other types of display devices.

[0092] The client device 406 may be configured to run various applications, such as the client application 436 and / or other applications. The client application 436 can be run within the client device 406 and, for example, by accessing network content provided by the computing environment 403 and / or other servers, a user interface on the display can be rendered. For this purpose, the client application 436 may include, for example, a browser, a dedicated application, and the user interface may include a network page, an application screen, and so on. In particular, the client application 436 may be configured to request a network slice 470 from the network slice allocation service 425 and specify one or more quality of service requirements 471 for the network slice 470. The client application 436 can then use the network slice 470 to communicate with one or more backend services, such as a content delivery service 426, a video conferencing service, a telephone service, a social networking service, a data backup service, and / or other types of backend services and / or destinations. In addition to the client application 436, the client device 406 may be configured to run applications such as an email application, a social networking application, a word processor, a spreadsheet, and / or other applications.

[0093] Referring next to Figure 5, a flowchart is shown illustrating an example of the operation of a portion of the client application 436 according to various embodiments. It will be understood that the flowchart in Figure 5 provides merely an example of many different types of functional arrangements that may be used to implement the operation of a portion of the client application 436 described herein. Instead, the flowchart in Figure 5 may be considered to illustrate an example of the elements of the method implemented within the client device 406 (Figure 4) according to one or more embodiments.

[0094] Starting from box 503, client application 436 determines to request the allocation of network slice 470 (Figure 4) on wireless network 103 (Figure 4), for example by calling a network slicing API. In some cases, client application 436 may render a user interface that allows the user to specifically request the allocation of network slice 470 and configure parameters corresponding to quality of service requirements 471 (Figure 4). For example, client application 436 may render a user interface that includes a slider to adjust between a low-latency, high-cost combination and a high-latency, low-cost combination. The user interface may also allow configuration of settings for bandwidth, reliability, network hop count, and / or other parameters related to network quality of service. In some embodiments, the network slice configuration may be specified by the application developer or owner and stored as part of an application template that can be used to launch the application within the wireless network. The network slice configuration may include settings such as rate limiting and network topology, as well as the required capacity of the underlying shared hardware resources of wireless network 103. This service can orchestrate and determine how to deploy only the network functions necessary to support a specific network slice. Network slice configurations can also include parameters related to scaling the network slice, allowing for dynamic adjustment of reserved resources based on the demands of a particular application. In this way, each application can receive a unique set of resources and network topology suited to its connectivity, speed, latency, and capacity needs.

[0095] In other scenarios, the client application 436 may determine to automatically request network slice 470. For example, network congestion may cause performance degradation in relation to an internal quality of service metric or requirement, and the client application 436 may be configured to request network slice 470 to mitigate this performance degradation. The user can also specify, via the user interface, the metrics that cause the client application 436 to automatically request network slice 470. For example, in a video conferencing application, the user may check a box that enables the request of network slice 470 to maintain the quality of the video conference.

[0096] In box 506, the client application 436 sends a request to allocate network slice 470 to the network slice allocation service 425 (Figure 4). The request may be sent directly to the network slice allocation service 425 or to an intermediate entity. The request may specify one or more quality of service requirements 471, such as latency, bandwidth, reliability, jitter, or other requirements. Requirements may be expressed as maximum, minimum, median, mean, or other threshold measures. Insofar as the quality of service requirement 471 is associated with a corresponding cost, the request may instead specify a target cost, such as a maximum cost, minimum cost, or the range the customer is willing to spend on quality of service dimensions such as bandwidth or latency, and the network will allocate the corresponding service level based on the price the customer is willing to pay. In some cases, network slice allocation may involve adding or reserving additional frequency spectra, which may incur costs. In such cases, the customer may, for example, bid on additional frequency spectra in the spot market for spectrum allocation.

[0097] Furthermore, the client application 436 may specify the duration of the network slice 470, which can correspond to a length of time, a data volume, or another measure, after which another network slice 470 or the default network slice 470 may become active. For example, the duration may correspond to an application session. If no duration is specified, the network slice 470 may remain active until it is released or canceled. Requests may also be sent to the network slice allocation service 425 via an application programming interface (API), and the customer and / or client application 436 may be required to provide one or more security certificates for authentication purposes. In some embodiments, requests may be sent to the network slice allocation service 425 not directly from the client application 436, but by a backend service interacting with the client application 436. For example, requests may be sent from a video conferencing service provider rather than from a video conferencing client application 436 running on client device 406.

[0098] In box 509, the client application 436 receives a network slice identifier token from the network slice allocation service 425 to identify network traffic that is subject to network slice 470 within the wireless network 103. For example, the client application 436 can insert the token into a packet or segment of data that is subject to network slice 470. In this way, the client application 436 can specify which network traffic should be routed through network slice 470 instead of default routing or another allocated network slice 470. In one embodiment, the network slice identifier token is an OAuth token. Alternatively, flow identification information (e.g., source port, source network address, specified port, destination address) may be provided to the network slice allocation service 425 to identify network traffic that is routed within network slice 470. In another example, all traffic from the client application 436 may be routed through network slice 470, as determined by deep packet inspection. In yet another example, network traffic from multiple client applications 436 or all client applications 436 on the client device 406 may be routed through the same network slice 470.

[0099] In box 512, client application 436 sends and / or receives data using the allocated network slice 470. In some scenarios, other client applications 436 on the same client device 406 continue to send or receive data without using the allocated network slice 470. For example, an email application may continue to use the default network connection instead of the network slice 470 allocated to the media player application. Also, client applications 436 may use different network slices 470 or the default network connection to send and / or receive other types of network traffic.

[0100] In box 515, the client application 436 determines whether to change the network slice 470. For example, a customer may request a different quality of service requirement 471, or the current quality of service requirement 471 may not be sufficient for the current usage of the client application 436. This difference could be an increase or decrease in the quality of service requirement 471. In some cases, the network slice 470 may be automatically scaled based on the network traffic observed within the network slice, or demand, in order to maintain the QoS requirements. If the client application 436 determines to change the network slice 470, the client application 436 moves from box 515 to box 518 and sends a request to change the network slice 470 to the network slice allocation service 425. For example, the request to change may be automatically sent by the client application 436 via an API. The client application 436 can then return to box 509 and receive the updated token.

[0101] If client application 436 determines that it will not change network slice 470, it moves from box 515 to box 521 and determines whether to release or cancel the current network slice 470. For example, the application session may have ended and network slice 470 is no longer needed. If client application 436 determines that it will release network slice 470, it moves from box 521 to box 524 and sends a request to release network slice 470 to the network slice allocation service 425. For example, the release request may be sent via an API. After that, client application 436's operation ends.

[0102] Moving on to Figure 6, a flowchart is shown illustrating an example of the operation of a portion of the network slice allocation service 425 according to various embodiments. It will be understood that the flowchart in Figure 6 provides merely an example of many different types of functional arrangements that may be used to implement some of the operations of the network slice allocation service 425 described herein. Alternatively, the flowchart in Figure 6 may be considered to illustrate an example of elements of the method implemented within the computing environment 403 (Figure 4) according to one or more embodiments.

[0103] Starting from box 603, the network slice allocation service 425 determines whether to allocate network slice 470 (Figure 4) or modify an existing network slice 470 on the wireless network 103 (Figure 4). The network slice allocation service 425 can manage network slices for multiple different wireless networks 103 for multiple customers. In one example, the network slice allocation service 425 receives API-based requests from a client application 436 (Figure 4) or client device 406 (Figure 4) to allocate or modify network slice 470. As described herein, the client application 426 may be a software application that communicates with other applications and / or end-user devices over the wireless network 103. Requests may be received directly from the client application 436 or from a backend service or other host communicating with the client application 436. Requests may include security credentials or other identifiers to authenticate the customer associated with the client application 436. This request specifies one or more quality of service requirements 471 (Figure 4) for network slice 470 and the potential cost that the customer is willing to pay to meet those requirements. In one example, network slice 470 is associated with a lower quality of service requirement 471 than the default connection over wireless network 103. In another example, network slice 470 is associated with a higher quality of service requirement 471 than the default connection over wireless network 103. The request may specify a duration based on time, data volume, or application behavior, and the network function(s) may be reconfigured to release network slice 470 when its duration is met.

[0104] In another example, the network slice allocation service 425 observes the configuration or conditions on the wireless network 103, at least in part on a machine learning model, to automatically determine whether to allocate or modify a network slice 470. In some cases, the network slice allocation service 425 may determine to pre-configure one or more network slices 470 for the new wireless network 103 to be deployed, based on the customer's previous network or expected usage parameters.

[0105] In box 606, the network slice allocation service 425 configures or reconfigures one or more network functions within the wireless network 103 to process data in network slice 470 in order to meet quality of service requirements 471. For example, the network slice allocation service 425 may configure a network function to process data with higher or lower priority to result in a lower or higher latency measure or other measure. In another example, the network slice allocation service 425 may configure a network function to prioritize data from an application up to a specified maximum bandwidth or a specified minimum latency. In one example, a client application 436, which is a game application, may have very low latency requirements. The network slice allocation service 425 may also make reservations on the underlying network hardware to ensure capacity for network slice 270. In some cases, the network slice allocation service 425 may allocate network capacity to network slice 270 in an oversubscribed manner so that the network capacity allocated to multiple network slices 270 may exceed the actual network hardware capacity. This may be done in response to determining the predictability of network capacity to meet QoS requirement 471 for network slice 270. Such predictions can be generated at least in part based on historical network traffic volumes, predicted future volumes, and other data.

[0106] It should be noted that network slice 470 can be configured for either a portion of the wireless network 103 or the entire wireless network 103. For example, if a given device has very low latency quality of service requirements and it is known that the device is in a fixed location within one cell 109 (Figure 1), then the network functionality associated with that cell 109 may be configured to implement network slice 470, and not the network functionality associated with other cells 109. In other words, network slice 470 can be enabled or disabled on a per-cell basis or based on another type of network subdivision (for example, in a region that is in one region 306 (Figure 3) but not in another region 306).

[0107] In box 609, the network slice allocation service 425 may increase or decrease the computing resources within the allocated computing capacity 421 (Figure 4) for network functions to meet the quality of service requirements 471 for network slice 470. For example, the network slice allocation service 425 may launch additional machine instances or containers to run the network functions of network slice 470, for example, to reduce latency and improve reliability. In other examples, the allocated computing capacity 421 for network functions may be scaled up, left unchanged, or scaled down. For example, if network slice 470 is configured with a higher latency value, the allocated computing capacity 421 for network functions may be over-provisioned and may be reduced without sacrificing the newly created quality of service requirements 471. Conversely, the network slice allocation service 425 may determine to terminate existing machine instances or containers if the modified network slice 470 does not require the capacity.

[0108] In box 612, the network slice allocation service 425 can transfer network functional workloads 466 (Figure 4) to allocated computing capacity 421 on different computing devices 418 (Figure 4) to meet quality of service requirements 471. For example, the network slice allocation service 425 can move network functional workloads 466 to edge locations such as cell sites or customer aggregation sites to improve latency or other quality of service measures. A cell site may be identified as a cell site currently in use by a client device 406, or one or more cell sites expected to be in use by a client device 406.

[0109] The forwarding of network function workloads 466 may involve relocating customer workloads 469 (Figure 4) of the requesting customer or other customers away from computing device 418, or, in some cases, reducing the allocated computing capacity 421 of computing device 418 to make space for network functions. In some cases, network function workloads 466 may be forwarded to the associated core network, away from the edge location. In box 615, the network slice allocation service 425 reserves space for quality of service requirements 471 for other network slices 470 with lower or higher quality of service requirements 471, and adjusts the processing priority of the newly allocated network slice 470 to meet them. Alternatively, it may reduce or increase the quality of service requirements 471 for other existing network slices 470.

[0110] In box 618, the network slice allocation service 425 can return a network slice identifier token to the customer via an API. The token can be used by the client device 406 and / or the client application 436 to specify network traffic for network slice 470. In box 621, the network slice allocation service 425 determines whether to release resources to the available resource pool. For example, if resources allocated to network slice 470 are scaled down, those resources may become available for allocation to other network slices 470 or for general network operation. The operation of that part of the network slice allocation service 425 then ends.

[0111] Referring to Figure 7, a flowchart is shown illustrating an example of the operation of another part of the network slice allocation service 425 according to various embodiments. It will be understood that the flowchart in Figure 7 provides merely an example of many different types of functional arrangements that may be used to implement some of the operations of the network slice allocation service 425 described herein. Alternatively, the flowchart in Figure 7 may be considered to illustrate an example of elements of the method implemented within the computing environment 403 (Figure 4) according to one or more embodiments.

[0112] Starting from box 703, the network slice allocation service 425 receives a request to allocate network slice 470 (Figure 4) to a client application 436 (Figure 4) or client device 406 (Figure 4). The request may be received directly from the client application 436 or from a backend service or other host communicating with the client application 436. The request may include security credentials or other identifiers to authenticate the customer associated with the client application 436. The request specifies one or more quality of service requirements 471 (Figure 4) for network slice 470. In one example, network slice 470 is associated with a lower quality of service requirement 471 than the default connection over the wireless network 103 (Figure 4). In another example, network slice 470 is associated with a higher quality of service requirement 471 than the default connection over the wireless network 103. The request may specify a duration in terms of period, application lifecycle, or data volume, and the network function(s) may be reconfigured to release network slice 470 when its duration is met.

[0113] In box 706, the network slice allocation service 425 determines that network slice 470 is associated with the consumption of network-sensitive content 427 (Figure 4). For example, a client application 436 requesting network slice 470 may be a video player application running on a smart TV or TV companion device. The content may be network-sensitive in that it may be susceptible to delays or packet drops and may require the transmission of relatively large amounts of data. Network problems may degrade the user experience when consuming the content, such as audio or video artifacts or pauses. Other examples of content include video streaming to other devices or for games or AR / VR applications. In box 709, the network slice allocation service 425 determines, based on the current location of the content delivery service 426 (Figure 4) in the network, that quality of service requirement 471 is not met. For example, content 427 may need to traverse a congested backbone communication link.

[0114] In box 712, the network slice allocation service 425 instantiates the content delivery service 426 on the wireless network 103. In one example, the content delivery service 426 is instantiated at an edge location such as a cell site or customer site. The network may also be prepared in a different way for the network slice 470, as described in boxes 606-618 of the flowchart in Figure 6. In some cases, computing capacity allocated to network functions may be released and reallocated to the content delivery service 426 as a priority, if it is optimal for meeting the quality of service requirement 471.

[0115] In box 715, the network slice allocation service 425 initiates the transfer of content 427 to the content delivery service 426. For example, the content delivery service 426 may be configured to predictively cache content from the primary content delivery service 426 for customers associated with network slice 470. Such predictive caching may be based on predictions using information associated with the customer's account, including content consumption history, purchase history, interests, favorite genres, watchlists, etc. Content 427 may be predictively cached during off-peak hours when backbone communication links are less congested. In one scenario, the transfer of content 427 is initiated in response to a determination that the consumption of content 427 does not meet quality of service requirements 471. Alternatively, content 427 is transferred before a client device 406, to which network slice 470 is provisioned, requests content 427. The operation of the network slice allocation service 425 then ends.

[0116] The example in Figure 7 refers to a content delivery service 426, but the network slice allocation service 425 may instantiate other types of endpoint services that support network communication with client devices 406. When network slice 470 is no longer needed, instantiated services such as the content delivery service 426 may be terminated, and / or content 427 may be discarded from the content delivery service 426.

[0117] Referring to Figure 8, 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, for example, at least one processor circuit having a processor 803 and memory 806, both of which are 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, as can be understood, include, for example, a data bus or other bus structure including an accompanying address / control bus.

[0118] The memory 806 stores both data and several components that can be executed by the processor 803. Specifically, the network slice allocation service 425, the content delivery service 426, and other potential applications are stored in the memory 806 and can be executed by the processor 803. The memory 806 may also store the data store 415 and other data. In addition, the operating system may be stored in the memory 806 and can be executed by the processor 803.

[0119] As can be understood, there may be other applications stored in memory 806 and executable by processor 803. If any of the components described herein are implemented in software form, any one of several programming languages ​​may be adopted, such as C, C++, C#, Objective-C, Java®, JavaScript®, Perl, PHP, Visual Basic®, Python®, Ruby, Flash®, or other programming languages.

[0120] Several software components are stored in memory 806 and are executable by processor 803. In this context, the term "executable" means a program file in a format that can ultimately be launched by processor 803. Examples of executable programs include, for example, compiled programs that can be loaded into the random access portion of memory 806 and converted into machine code in a format executable by processor 803; source code that can be loaded into the random access portion of memory 806 and expressed in an appropriate format such as object code executable by processor 803; or source code that can be interpreted by another executable program that generates instructions in the random access portion of memory 806 to be executed by processor 803. Executable programs can be stored in any part or component of memory 806, including, for example, random access memory (RAM), read-only memory (ROM), hard drives, solid-state drives, USB flash drives, memory cards, optical discs such as compact discs (CDs) or digital multipurpose discs (DVDs), floppy disks, magnetic tapes, or other memory components.

[0121] Memory 806 is defined herein as including both volatile and non-volatile memory and data storage components. Volatile components do not retain data values ​​when power is lost. Non-volatile components retain data when power is lost. Thus, memory 806 may include, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical disks accessed via an optical disk drive, magnetic tapes accessed via a suitable tape drive, and / or other memory components, or any combination of two or more of these memory components. In addition, 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.

[0122] Furthermore, the processor 803 may represent multiple processors 803 and / or multiple processor cores, and the memory 806 may represent multiple memory 806, each operating in a parallel processing circuit. In such a case, the local interface 809 may be a suitable network that facilitates communication between any two of the many processors 803, between any processor 803 and any of the memory 806, or between any two of the memory 806, etc. The local interface 809 may include additional systems designed to coordinate this communication, for example, including the implementation of load balancing. The processor 803 may have an electrical structure or some other available structure.

[0123] The network slice allocation service 425, content distribution service 426, and various other systems described herein may be embodied in software or code executed on general-purpose hardware, as described above, but alternatively, similar systems may be embodied in dedicated hardware or a combination of software / general-purpose hardware and dedicated hardware. When embodied in dedicated hardware, each can be implemented as a circuit or state machine using any one or a combination of a number of technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates to implement various logic functions when one or more data signals are applied, application-specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components. Such technologies are generally well known to those skilled in the art and are therefore not described in detail herein.

[0124] The flowcharts in Figures 5 to 7 illustrate the functionality and operation of some embodiments of the network slice allocation service 425 and the client application 436 (Figure 4). When embodied in software, each block may represent a module, segment, or portion of code containing program instructions to implement a specific logical function(s). Program instructions may be embodied in the form of source code containing human-readable instructions written in a programming language, or in the form of machine code containing numerical instructions recognizable by a suitable execution system such as a processor 803 in a computer system or other system. Machine code may be converted from source code, etc. When embodied in hardware, each block may represent a circuit or a number of interconnected circuits to implement a specific logical function(s).

[0125] The flowcharts in Figures 5 to 7 illustrate a specific execution order, but it should be understood that the execution order may differ from the order shown. For example, the execution order of two or more blocks may be rearranged. Also, two or more blocks shown consecutively in Figures 5 to 7 may be executed simultaneously or partially simultaneously. Furthermore, in some embodiments, one or more blocks shown in Figures 5 to 7 may be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages may be added to the logical flow described herein for purposes such as improving usefulness, explanation, performance measurement, or providing clues to problem solving. It should be understood that all such variations are within the scope of this disclosure.

[0126] Furthermore, any logic or application described herein, including the network slice allocation service 425 and the content distribution service 426, which comprises software or code, may be embodied in any non-temporary computer-readable medium used, for example, by an instruction execution system, such as a processor 803 in a computer system or other system, or in connection therewith. In this sense, the logic may include, for example, instruction statements, including instructions and declarations that are obtainable from the computer-readable medium and executable by the instruction execution system. In the context of this disclosure, “computer-readable medium” may be any medium used, or in connection therewith, that can contain, store, or hold the logic or application described herein.

[0127] Computer-readable media can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, magnetic tapes, magnetic floppy disks, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Computer-readable media may also 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). In addition, computer-readable media may 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.

[0128] Furthermore, any logic or application described herein, including the network slice allocation service 425 and the content delivery service 426, may be implemented and constructed in a variety of ways. For example, one or more applications described herein may be implemented as modules or components of a single application. In addition, one or more applications described herein may run on shared computing devices, separate computing devices, or a combination thereof. For example, multiple applications described herein may run on the same computing device 800, or on multiple computing devices 800 in the same computing environment 403.

[0129] Unless otherwise specified, disjunctive language such as the phrase "at least one of X, Y, or Z" is generally understood in context to indicate that an item, term, etc., may otherwise be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is not generally intended, and should not be intended, to imply that a particular embodiment requires the presence of at least one X, at least one Y, or at least one Z, respectively.

[0130] Embodiments of this disclosure may be described by one or more of the following clauses. Clause 1. A wireless network including a wireless access network and associated core networks, wherein an application utilizes network slices of the wireless network to transmit and / or receive network traffic; a network slice allocation service configured to dynamically change the network slices in response to application programming interface (API) requests from the application; and at least one computing device implementing the application, wherein the application is configured to determine that the network slice does not meet quality of service requirements, including at least one of minimum bandwidth requirements or minimum latency requirements; send a first API request to the network slice allocation service to reserve additional capacity of the network slice for the application in the wireless network, wherein the network slice provides the quality of service requirements; use the network slice to transmit and / or receive network traffic; determine that the network slice exceeds the quality of service requirements; and send a second API request to the network slice allocation service to release at least a portion of the capacity reserved for the network slice.

[0131] Clause 2. The system as described in Clause 1, wherein the application is configured to further obtain a token that identifies the network slice from the network slice allocation service, and one or more data packets transmitted using the network slice identify the network slice by the token.

[0132] Clause 3. The system described in Clauses 1-2, wherein the application is further configured to send or receive subsequent data using a default network connection instead of the network slice after sending the second API request.

[0133] Clause 4. Determining, via at least one computing device, that an application running on a particular computing device has quality of service requirements, wherein the particular computing device is connected to a communication network, Sending a request to the network slice allocation service via the at least one computing device to reserve a network slice having the quality of service requirements in the communication network, A method comprising transmitting data to and from the application using the network slice via the at least one computing device.

[0134] Clause 5. The method according to Clause 4, further comprising transmitting other data to and from another application running on the particular computing device via the at least one computing device without using the network slice.

[0135] Clause 6. The method of Clauses 4-5, further comprising determining the duration of the network slice via the at least one computing device, at least in part, based on the length of time the application has the quality of service requirements, wherein the request specifies the duration.

[0136] Clause 7. The duration is as described in Clause 6, corresponding to the session of the application.

[0137] Clause 8. The method according to Clauses 4-7, further comprising determining via the at least one computing device that the application no longer has quality of service requirements, and sending a subsequent request via the at least one computing device to the network slice allocation service to release the network slice.

[0138] Clause 9. The method according to Clauses 4-8, further comprising determining via the at least one computing device that the application has increased quality of service requirements, and via the at least one computing device sending a subsequent request to the network slice allocation service to modify the network slice to have the increased quality of service requirements.

[0139] Clause 10. The method according to Clauses 4-9, further comprising determining via the at least one computing device that the application has reduced quality of service requirements, and via the at least one computing device sending a subsequent request to the network slice allocation service to modify the network slice to have the reduced quality of service requirements.

[0140] The method according to Clause 11, further comprising determining via the at least one computing device that another application running on the particular computing device has different quality of service requirements, and sending a subsequent request via the at least one computing device to the network slice allocation service to reserve a different network slice for the application, wherein the different network slice is associated with lower quality of service requirements than the default network slice for the particular computing device.

[0141] Clause 12. The method described in Clauses 4-11, wherein the network slice is associated with a shorter latency than the default network slice.

[0142] Clause 13. The service quality requirements are as described in Clauses 4 to 12, including the minimum delay requirements for the application.

[0143] Clause 14. The service quality requirements are as described in Clauses 4 to 13, including the minimum bandwidth requirements for the application.

[0144] Clause 15. The method of Clauses 4-14, further comprising sending the request to the network slice allocation service to reserve the network slice from the application running on the particular computing device to the network slice allocation service via an application programming interface.

[0145] Clause 16. The method according to Clauses 4-15, further comprising sending the request to the network slice allocation service to reserve the network slice from a backend service of the application running on one or more servers to the network slice allocation service via an application programming interface.

[0146] Clause 17. A non-temporary computer-readable medium embodying an application executable within a computing device, wherein, when the application is executed, the computing device is instructed to: determine that a network slice in a wireless network does not meet the quality of service requirements of the application; and transmit a request to a network slice allocation service to reserve the network slice for the application in the wireless network, wherein the network slice provides the quality of service requirements; and transmit and receive data using the network slice. Clause 18. The non-temporary computer-readable medium according to Clause 17, wherein, when the application is executed, the computing device is instructed to transmit a subsequent request to the network slice allocation service to release the network slice.

[0147] Clause 19. The application, when executed, causes the computing device to further determine at least the duration of the network slice, wherein the duration is in hours or minutes or a data volume, and the request specifies the duration, in the non-temporary computer-readable media described in Clauses 17-18.

[0148] Clause 20. The application, when executed, causes the computing device to further determine the maximum latency of the network slice, and the request specifies the maximum latency in the non-transient computer-readable media as described in Clauses 17-19.

[0149] Clause 21. A wireless network including a wireless access network and associated core networks, wherein applications utilize each network slice of the wireless network to transmit and / or receive network traffic; and a network slice allocation service configured to receive an application programming interface (API) request from an application to allocate a network slice of the wireless network, wherein the request from the application specifies quality of service requirements for the network slice; and in response to the API request, identify a set of network functions from among a plurality of available network functions to process data transmitted through the network slice in such a way that the quality of service requirements for the network slice are met; and enable the application to use the network slice.

[0150] Clause 22. The network slice allocation service is further configured to increase the amount of computing resources that implement the set of network functions to satisfy the quality of service requirements of the network slice, as described in Clause 21.

[0151] Clause 23. The system as described in Clauses 21-22, wherein the network slice allocation service is further configured to transfer workloads for the set of network functions from a first computing device located at an edge location of the cloud provider network connected to at least a portion of the wireless network to a second computing device located at another edge location of the cloud provider network.

[0152] Clause 24. The network slice allocation service is further configured to manage multiple network slices associated with multiple different wireless networks of multiple customers, as described in Clauses 21-23.

[0153] Clause 25. The network slice allocation service is further configured to allocate network capacity to the network slices through oversubscriptions exceeding hardware capacity, at least in part, based on the predictable ability of the network slices to meet the quality of service requirements, as described in Clauses 21-24.

[0154] Clause 26. The network slice allocation service enables the application to use the network slice by generating an access token and returning the access token to the application, and the application uses the network slice by presenting the access token, as described in Clauses 21-25.

[0155] Clause 27. A method comprising receiving, via at least one computing device, a request to allocate a network slice in a wireless network having a wireless access network and an associated core network to an application connected to the wireless network, wherein the request specifies a set of quality-of-service constraints required for the network slice, and via at least one computing device, configuring a set of network functions in the wireless network to implement the network slice.

[0156] Clause 28. The method of Clause 27, wherein the network slice is associated with lower quality of service requirements than the default connection over the wireless network.

[0157] Clause 29. The method according to Clauses 27-28, wherein the network slice is associated with higher quality of service requirements than the default connection via the wireless network.

[0158] Clause 30. The method according to Clauses 27-29, wherein configuring the set of network functions further includes moving at least one network function workload from a first computing device to a second computing device via the at least one computing device in order to implement the network slice, wherein one of the first computing device and the second computing device is located in a data center and the other of the first computing device and the second computing device is located in a cell site.

[0159] Clause 31. The method according to Clauses 27-30, further comprising configuring the set of network functions to scale the amount of computing resources allocated to at least one network function workload via the at least one computing device in order to implement the network slice.

[0160] Clause 32. The method according to Clause 31, wherein scaling the amount of computing resources allocated to the at least one network function workload further includes increasing the number of virtual machine instances or containers running the at least one network function workload via the at least one computing device.

[0161] Clause 33. The method according to Clauses 27-32, further comprising configuring the set of network functions to prioritize data from the application through the at least one computing device, up to a specified maximum bandwidth or a specified minimum latency.

[0162] Clause 34. The method according to Clauses 27-33, wherein the request specifies a duration or amount of data within a period, and the method further comprises reconfiguring at least one network function workload in the wireless network via the at least one computing device when the duration for releasing the network slice has elapsed.

[0163] Clause 35. The method described in Clauses 27-34, wherein the request is received from the backend service associated with the application via an application programming interface (API) call made by the backend service.

[0164] Clause 36. A non-temporary computer-readable medium embodying a network slice allocation service executable within at least one computing device, the non-temporary computer-readable medium, which, when executed, causes the at least one computing device to determine to allocate a network slice to at least one application communicating over a wireless network, that the network slice has specified quality of service requirements, that configure at least one network function in the wireless network to process data transmitted over the network slice to satisfy the specified quality of service requirements of the network slice, and that scale the amount of computing resources implementing the at least one network function to satisfy the specified quality of service requirements of the network slice.

[0165] Clause 37. The network slice is the system described in Clause 36, which corresponds to all data transmitted from a client device on the wireless network to a destination.

[0166] Clause 38. The network slice corresponds to all data transmitted from a specific application running on a client device on the wireless network, as described in Clauses 36-37.

[0167] Clause 39. The System according to Clauses 36-38, wherein, when the network slice allocation service is performed, it causes at least one computing device to configure at least one network function in the wireless network to lower the priority of other data transmitted through another network slice so that the other network slice has a lower quality of service requirement than the specified quality of service requirement.

[0168] Clause 40. The network slice allocation service, when performed, causes the at least one computing device to transfer at least one workload of the at least one network function from a first computing device in a data center to a second computing device at a cell site in order to satisfy the specified quality of service requirements of the network slice, as described in Clauses 36-39.

[0169] Clause 41. A wireless network including a wireless access network and associated core networks, wherein applications utilize each network slice of the wireless network to transmit and / or receive network traffic; and a program configured to at least receive a request from an application running on a client device to provision a network slice in the wireless network, wherein the network slice has quality of service requirements for the application's session; determine that the application's operation requires the transfer of network-sensitive content over the network slice; determine that the network slice would fail to meet the quality of service requirements unless the network-sensitive content is provided at an edge location of the wireless network; and initiate the transfer of the network-sensitive content to a content delivery service at the edge location of the wireless network in order to satisfy the quality of service requirements of the network slice.

[0170] Clause 42. The system as described in Clause 41, wherein the edge location is an edge location of a cloud provider network connected to the equipment of the wireless access network.

[0171] Clause 43. The system according to Clauses 41-42, wherein the program, when executed, causes at least one computing device to increase the amount of computing resources in the wireless network that perform at least one network function for the network slice.

[0172] Clause 44. The system according to Clauses 41-43, wherein, when the program is executed, it causes the at least one computing device to discard at least further network-sensitive content from the content delivery service at the edge location when it determines that the network slice has been released.

[0173] Clause 45. A method comprising, in response to an Application Programming Interface (API) request, provisioning a network slice with quality of service requirements within a wireless network having a wireless access network and an associated core network via at least one computing device, and, in response to the API request, initiating the transfer of content to a content delivery service located at an edge location of the wireless network via the at least one computing device, in order to satisfy the quality of service requirements of the network slice.

[0174] Clause 46. The method of Clause 45, further comprising provisioning the network slice via the at least one computing device for a session of an application running on a device connected to the wireless network.

[0175] Clause 47. The method of Clauses 45-46, further comprising determining, via the at least one computing device, that the network connectivity from the endpoint of the network slice to the primary content delivery service does not meet the quality of service requirements, and invoking the content delivery service via the at least one computing device.

[0176] Clause 48. The method according to Clauses 45-47, further comprising determining via at least one computing device that consumption of the content via the network slice does not meet the quality of service requirements, and the transfer of the content is initiated in response to further determining that consumption of the content does not meet the quality of service requirements.

[0177] Clause 49. The method according to Clauses 45-48, further comprising reallocating computing capacity at the edge location from at least one network function of the wireless network to the content delivery service via the at least one computing device.

[0178] The method according to Clause 50, wherein reallocating the computing capacity at the edge location further comprises terminating a first machine instance configured to run the at least one network function on the computing device at the edge location via the at least one computing device, and initiating a second machine instance configured to host the content delivery service on the computing device at the edge location via the at least one computing device.

[0179] Clause 51. The method according to Clauses 45-50, further comprising configuring an application that uses the network slice via the at least one computing device to retrieve the content via the wireless network.

[0180] Clause 52. The method according to Clauses 45-51, further comprising transferring the content from the edge location to a client device connected via the wireless network, via the at least one computing device.

[0181] Clause 53. The method of Clauses 45-52, further comprising identifying the content on at least partly based on a prediction that the content will be consumed via the at least one computing device, wherein the prediction corresponds to an account associated with the network slice.

[0182] Clause 54. A non-temporary computer-readable medium embodying a network slice allocation service executable within at least one computing device, wherein, when the network slice allocation service is executed, the non-temporary computer-readable medium causes the at least one computing device to: receive a request to create a network slice that meets the quality of service requirements of an application running on a client device in a wireless network having at least a wireless access network and an associated core network; determine a service that the application will communicate using the network slice; and provision computing resources for the service in the wireless network to satisfy the quality of service requirements.

[0183] Clause 55. The network slice allocation service, when executed, causes further determination that the network slice will not meet the quality of service requirements unless it provisions at least the computing resources to at least one computing device, in the non-transient computer-readable medium described in Clause 54.

[0184] Clause 56. Provisioning the computing resources includes launching machine instances for the services, in the non-temporary computer-readable media described in Clauses 54-55.

[0185] Clause 57. The computing resources are provisioned for the duration of the network slice and released at the end of the network slice, in the non-transient computer-readable media described in Clauses 54-56.

[0186] Clause 58. At least a portion of the computing resources are provisioned in non-temporary computer-readable media as described in Clauses 54-57, provided that the client device is provisioned at a cell site to which the wireless network is connected.

[0187] Clause 59. At least a portion of the computing resources is provisioned in non-transient computer-readable media as described in Clauses 54-58, at one or more cell sites where the client device is expected to become connected to the wireless network.

[0188] Clause 60. The Services correspond to a content distribution service that provides content to the Application, and provisioning the computing resources further includes caching at least a portion of the content, as described in Clauses 54-59.

[0189] It should be emphasized that the embodiments described herein are merely possible examples of implementations described in order to clearly understand the principles of this disclosure. Many variations and modifications may be made to the embodiments described herein without substantially departing from the spirit and principles of this disclosure. All such modifications and variations are incorporated herein by reference and intended to be protected by the following claims.

Claims

1. A wireless network including a wireless access network and associated core networks, wherein applications utilize each network slice of the wireless network to transmit and / or receive network traffic, A network slice allocation service, and at least, Receiving an Application Programming Interface (API) request from an application in order to allocate a network slice of the wireless network, wherein the request from the application specifies the quality of service requirements for the network slice, In response to the API request, to process the data transmitted through the network slice in such a way as to satisfy the quality of service requirements of the network slice, to identify a set of network functions from among multiple available network functions, The application is made able to use the network slice, The network slice allocation service is configured to perform the following: A system equipped with these features.

2. The system according to claim 1, wherein the network slice allocation service is further configured to increase the amount of computing resources that implement the set of network functions so as to satisfy the quality of service requirements of the network slice.

3. The system according to claim 1, wherein the network slice allocation service is further configured to transfer workloads for the set of network functions from a first computing device located at an edge location of a cloud provider network connected to at least a portion of the wireless network to a second computing device located at another edge location of the cloud provider network.

4. The system according to claim 1, wherein the network slice allocation service is further configured to manage a plurality of network slices associated with a plurality of different wireless networks of a plurality of customers.

5. The system according to claim 1, wherein the network slice allocation service is further configured to allocate network capacity to the plurality of network slices through oversubscription exceeding hardware capacity, at least in part on the predictability of the plurality of network slices to satisfy the quality of service requirements.

6. To provision a network slice with quality of service requirements within a wireless network having a wireless access network and an associated core network via at least one computing device in response to an Application Programming Interface (API) request, In order to satisfy the quality of service requirements of the network slice, in response to the API request, initiate the transfer of content to the content delivery service located at the edge location of the wireless network via the at least one computing device, Methods that include...

7. The method according to claim 6, further comprising provisioning the network slice via the at least one computing device for a session of an application running on a device connected to the wireless network.

8. The process further includes determining, via at least one computing device, that the consumption of the content via the network slice does not meet the quality of service requirements. The method according to claim 6, wherein the transfer of the content is initiated in response to a determination that the consumption of the content does not meet the quality of service requirements.

9. The method according to claim 6, further comprising identifying the content on at least partly based on a prediction that the content will be consumed via the at least one computing device, wherein the prediction corresponds to an account associated with the network slice.

10. Determining whether an application running on a specific computing device has quality of service requirements, via at least one computing device, wherein the specific computing device is connected to a communication network, Sending a request to the network slice allocation service via the at least one computing device to reserve a network slice having the quality of service requirements in the communication network, To transmit data to and from the application using the network slice via the at least one computing device, Methods that include...

11. The method according to claim 10, further comprising transmitting other data to and from another application running on the particular computing device via the at least one computing device without using the network slice.

12. The process further includes determining the duration of the network slice via the at least one computing device, at least in part, based on the length of time the application has the quality of service requirements. The method according to claim 10, wherein the request specifies the duration.

13. Determining whether the application has modified quality of service requirements via at least one computing device, Sending a subsequent request to modify the network slice to have the modified quality of service requirements via at least one computing device to the network slice allocation service, The method according to claim 10, further comprising:

14. The method according to claim 10, wherein the quality of service requirement includes at least one of the minimum latency requirement for the application or the minimum bandwidth requirement for the application.

15. The method according to claim 10, further comprising sending the request to the network slice allocation service to reserve the network slice from a backend service of the application running on one or more servers to the network slice allocation service via an application programming interface.

Images