Managing network slice allocation

Abstract

Various embodiments are disclosed for managing the allocation of a network slice. In one embodiment, a request is received to allocate a network slice in a wireless network having a radio access network and an associated core network to an application connected to the wireless network. The request specifies a set of quality of service constraints required for the network slice. A set of network functions in the wireless network are configured to implement the network slice.

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 December 10, 2020, and assigned application serial number 17 / 118,565, which is incorporated herein by reference in its entirety. [Background technology]

[0002] 5G is the fifth-generation technology standard for broadband cellular networks and is planned to eventually replace the fourth-generation (4G) standard of Long-Term Evolution (LTE). 5G technology will offer significantly increased bandwidth, thereby expanding the cellular market beyond smartphones to provide last-mile connectivity to desktops, set-top boxes, laptops, Internet of Things (IoT) devices, and more. Some 5G cells may use frequency spectrum similar to 4G, while other 5G cells may use millimeter wave frequency spectrum. Millimeter wave cells have a relatively small coverage area but will offer 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, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. [Brief explanation of the drawings]

[0004] [Figure 1] 1 is a drawing of an example communications network deployed and managed in accordance with various embodiments of the present disclosure. [Figure 2A]1 illustrates an example of a network environment including a cloud provider network according to some embodiments of the present disclosure, and further including various provider substrate extensions of the cloud provider network that may be used at various locations within the communications network of FIG. [Figure 2B] 2 illustrates an example of cellularization and geographical distribution of the communication network of FIG. 1 to provide a highly available User Plane Function (UPF). [Figure 3] 2B illustrates an example of the network environment of FIG. 2A including geographically distributed provider substrate extensions, according to some embodiments of the present disclosure. [Figure 4] FIG. 2B is a schematic block diagram of the network environment of FIG. 2A in accordance with various embodiments of the present disclosure. [Figure 5] 5 is a flowchart illustrating an example of functionality implemented as part of a client application executing in a client device in the network environment of FIG. 4 according to various embodiments of the present disclosure. [Figure 6] 5 is a flowchart illustrating example functionality implemented as part of a network slice allocation service running in a computing environment within the network environment of FIG. 4 according to various embodiments of the present disclosure. [Figure 7] 5 is a flowchart illustrating example functionality implemented as part of a network slice allocation service running in a computing environment within the network environment of FIG. 4 according to various embodiments of the present disclosure. [Figure 8] 5 is a schematic block diagram providing an illustration of an example computing environment for use in the network environment of FIG. 4, in accordance with various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0005] The present disclosure relates to on-demand, application-driven network slicing in wireless networks, such as 4G and 5G wireless networks, or portions of such wireless networks, including radio access networks (RANs) and associated core networks. Specifically, by controlling network functions and the infrastructure on which they run, the disclosed wireless network management service enables applications to effectively program the network. 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 radio to instance, to ensure that QoS service level agreements (SLAs) are met for the duration of the session. Until now, deploying wireless networks relied on manual deployment and configuration at each step of the process, which proved to be extremely time-consuming and expensive. Furthermore, in previous generations, software was essentially tied to vendor-specific hardware, preventing customers from deploying alternative software. In contrast, 5G decouples the hardware from the software stack, allowing for greater flexibility and enabling wireless network components to run on cloud provider infrastructure. By decoupling network functions from specific hardware, wireless networks and their associated core networks become more easily configurable and dynamically reconfigurable. Using a cloud-delivered model for wireless networks, such as 5G networks, can make it easier to handle network traffic from hundreds or even billions of connected devices and computationally intensive applications, while delivering faster speeds, lower latency, and greater capacity than other types of networks.

[0006] Sharing limited resources has long been a problem in communications networks. Circuit-switched networks offered dedicated bandwidth and reliability, but 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 are more flexible with regard to resource sharing. However, packet-based networks are generally "best-effort" networks, meaning that they do not guarantee that a data packet will actually be delivered to its destination when it is sent. While this may be acceptable for many network applications, such as web browsing or email, it may not be acceptable for other network applications, such as videoconferencing or sensors, which require or can operate with minimal bandwidth or latency.

[0007] Various embodiments of the present disclosure implement on-demand slicing of networks, such as wireless networks and associated core networks, to guarantee quality of service to customers and their applications. In some embodiments, an application on a client device can request a network slice allocation on-demand via a service API. For example, a user of a video conferencing application can specify video conferencing as the highest priority, thereby ensuring that the application requests a high-priority network slice sufficient for the video conference so that the video conference is not interrupted or affected by a glitch. Enabling each application to request on-demand network slices for each individual session enables use cases in which 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 the network function. The network slice allocation service may also migrate the workload of a network function from one location in the network topology to another as needed to meet the quality of service requirements of the network slice, thereby reducing the latency of the network function. Conversely, the network slice allocation service may move the workload of a network function to the core network of the cloud provider network when it is needed at the edge of the network to provide the requested quality of service.

[0009] In some embodiments, the content management service can operate in parallel with the network slice allocation service to ensure that content subject to quality of service requirements in the network slice is actually delivered in accordance with those requirements. To this end, the content management service may migrate the operation of the content distribution network to different locations within the network to support the quality of service requirements. For example, high bitrate video content from the content distribution network may be predictively cached for users at the edge of the network to provide high quality of service. Such an approach may be beneficial when typical content distribution servers are accessible via congested backbone links or via public Internet connections that do not provide high quality of service.

[0010] As one skilled in the art will appreciate in light of this disclosure, certain embodiments may achieve certain advantages, including some or all of the following: (1) improving the capabilities of computer systems and networks by enabling applications to dynamically request network slices with specific qualities of service on demand, thereby enabling applications to operate appropriately according to bandwidth and latency requirements; (2) improving the flexibility of computer systems and networks by enabling dynamic reconfiguration of network slices dedicated to applications or devices on demand; (3) improving the ability of computer systems and networks to meet quality of service requirements by migrating network function workloads to different locations within a wireless network; (4) improving the ability 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; and (5) improving the ability of computer systems and networks to meet quality of service requirements by migrating content delivery to different locations within a wireless network.

[0011] Among the advantages of the present disclosure is the ability to deploy and chain network functions to deliver end-to-end services that deliver dynamically resized network slices to specific software applications based on their requirements. According to the present disclosure, network functions organized into microservices work together to provide end-to-end connectivity. One set of network functions is part of the wireless network, operating within base stations and performing radio signal to IP conversion. Other network functions run in large data centers that execute subscriber-related business logic and route IP traffic to and from the Internet. For applications to use the new features of 5G, such as low-latency communications and reserved bandwidth, both of these types of network functions must work together to properly schedule and reserve wireless spectrum and perform real-time computations and data processing. The techniques disclosed herein provide edge location hardware (described further below) integrated with network functions that run throughout the network, from cell sites to internet breakouts, to orchestrate the network functions to meet required QoS constraints. This enables an entirely new set of applications with stringent QoS requirements that were previously not possible to run over 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, such that each logical network (i.e., network slice) can be customized and sized to optimally meet a specific set of needs. Typically, network slices are manually created and provided to a specific organization or entity. According to the present 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 network traffic associated with that application. A network slice can reserve certain amounts of different hardware resources (e.g., radio resources, RAN, and core processing resources) across the network for use with traffic associated with a particular application so that the desired QoS can be achieved. The service can also scale and manage such network slices across multiple different software applications, for example, by provisioning “complementary” slices (having complementary needs across a set of different hardware components) on the same underlying hardware for more efficient resource utilization, or by over-provisioning slices based on predicted usage that indicates that all applicable QoS constraints can 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 and allocate network slices 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, allowing customers to invoke and manage selected network functions on their cloud infrastructure using a single set of APIs. The Elastic 5G service automates the creation of end-to-end 5G networks, from hardware to network functions, thereby reducing deployment time and operational costs for network operations. By providing APIs that expose network functions, the disclosed Elastic 5G service enables applications to simply specify the desired QoS as constraints, deploying and chaining network functions to deliver end-to-end network slices that reflect the network characteristics required by software applications. By automating the creation of network slices through application-driven API requests, the disclosed service can dynamically change network slices to meet the changing demands of a wide range of applications running on the network.

[0014] This disclosure describes embodiments related to creating and managing a cloud-native 5G core and / or cloud-native 5G RAN and associated control plane components. Cloud-native refers to an approach to building and running applications that leverage the benefits of the cloud computing delivery model, such as dynamic scalability, distributed computing, and high availability (including geographic distribution, redundancy, and failover). Cloud-native refers to the way these applications are written and deployed to make them suitable for deployment in the public cloud. Cloud-native applications can (and often do) run in the public cloud, but they can also run in on-premises data centers. Some cloud-native applications can be containerized, e.g., different parts, functions, or subunits of an application are packaged into their own containers, which can 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 arranged as a collection of smaller subunits ("microservices") that can be deployed and scaled independently of each other and can communicate with each other over a network. These microservices typically have a specific technical and functional granularity, often implementing lightweight communication protocols, making them fine-grained. An application's microservices can perform different functions, may be independently deployable, and may use different programming languages, databases, and hardware / software environments.Decomposing an application into smaller services beneficially increases the modularity of the application, allows individual microservices to be replaced as needed, and parallelizes development by allowing teams to develop, deploy, and maintain the microservices independently of each other. Microservices may, in some examples, be deployed using virtual machines, containers, or serverless functions. The disclosed core and RAN software may follow a microservices architecture such that the described wireless network is composed of independent subunits that can be deployed and scaled on demand.

[0015] Referring now to FIG. 1 , an example of a communications network 100 deployed and managed in accordance with various embodiments of the present disclosure is shown. The communications network 100 includes a wireless 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 wireless network 103 may be operated by a public communications provider or a cloud service provider for an enterprise or other organization. Various deployments of the wireless network 103 may include one or more of a core network and a RAN network, as well as a control plane for running the core network and / or the RAN network on the cloud provider infrastructure. As noted above, these components may be developed in a cloud-native manner, e.g., using a microservices architecture, such that centralized control and distributed processing are used to efficiently scale traffic and transactions. These components may be based on 3GPP specifications by following an application architecture with separated control and user plane processing (CUPS architecture).

[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, the wireless devices 106 may include devices such as smartphones, connected vehicles, Internet of Things (IoT) devices, sensors, machines (such as in a manufacturing facility), hotspots, etc. The wireless devices 106 may also be referred to as user equipment (UE) or customer premises equipment (CPE).

[0017] The wireless network 103 provides wireless network access to multiple wireless devices 106 through multiple cells 109. Each of the cells 109 may be equipped with one or more antennas and one or more radio units that transmit and receive 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 tunable. To focus signals in a particular direction or azimuth range, antennas may be associated with a particular gain or beamwidth, which may enable frequency reuse in different directions. Furthermore, antennas may be horizontally, vertically, or circularly polarized. In some examples, the radio units may transmit and receive signals utilizing multiple-input, multiple-output (MIMO) technology. Thus, the RAN implements radio access technologies that enable wireless connections with the wireless devices 106 and provides connectivity to the wireless network's core network. Components of the RAN include base stations and antennas covering a given physical area, as well as the necessary core network items for managing connections to the RAN.

[0018] Data traffic is often routed to the core network over 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, and manages device mobility before routing traffic to operator services or the Internet. For example, the 5G core can be decomposed into several microservice elements, separating the control plane and the user plane. Rather than physical network elements, the 5G core can include virtualized, software-based network functions (e.g., deployed as microservices) and thus can be instantiated within a multi-access edge computing (MEC) cloud infrastructure. Network functions in the core network can include a user plane function (UPF), an access and mobility management function (AMF), and a session management function (SMF), which are described in more detail below. For data traffic destined for locations external to communications network 100, network functions typically include firewalls to external networks, such as the Internet or cloud provider networks, through which traffic can enter and exit communications network 100. Note that in some embodiments, communications network 100 can include facilities that allow traffic to enter and exit sites further downstream from the core network (e.g., aggregation sites or wireless network 103).

[0019] The UPF provides the interconnection point between the mobile infrastructure and the data network (DN), i.e., General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) encapsulation and decapsulation. The UPF may also provide a session anchor point for providing mobility within the RAN, such as sending one or more end marker packets to the RAN base station. The UPF may also handle packet routing and forwarding, such as steering flows to specific data networks based on traffic match filters. Another function of the UPF includes per-flow or per-application QoS handling, such as uplink (UL) and downlink (DL) transport-level packet marking and rate limiting. The UPF can be implemented as a cloud-native network function using modern microservices techniques, for example, deployed within a serverless framework (which abstracts the underlying infrastructure on which code runs via managed services).

[0020] The AMF may receive connection and session information from the wireless device 106 or the RAN and may handle connection and mobility management tasks. For example, the AMF may manage handovers between base stations within the RAN. In some examples, the AMF may be considered an access point to the 5G core by terminating traffic for a particular RAN control plane and 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 Protocol Data Unit (PDU) sessions and managing session context within the UPF. The SMF may also implement Dynamic Host Configuration Protocol (DHCP) and IP Address Management (IPAM). The SMF may also be implemented as a cloud-native network function using modern microservices approaches.

[0022] Various network functions for implementing wireless network 103 may be deployed within distributed computing device 112, which may correspond to a general-purpose computing device configured to perform network functions. For example, distributed computing device 112 may run one or more virtual machine instances that are in turn configured to run one or more services that implement the network functions. In one embodiment, distributed computing device 112 is a ruggedized machine deployed at each cell site.

[0023] In contrast, one or more centralized computing devices 115 may perform various network functions at a central site operated by a customer. For example, the centralized computing devices 115 may be centrally located on the customer's premises in a coordinated server room. The 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 the 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 in one or more data centers located remotely from customer sites. Core computing devices 118 may also perform various network functions, including routing network traffic to and from network 121, which may correspond to the Internet and / or other external public or private networks. Core computing devices 118 may perform functions related to 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] FIG. 2A illustrates an example network environment 200, according to some embodiments, that includes a cloud provider network 203 and various provider substrate extensions of the cloud provider network 203 that may be used at various locations within the communications network 100 of FIG. 1 . The cloud provider network 203 (sometimes simply referred to as the “cloud”) refers to a network-accessible pool of computing resources (e.g., compute, storage, and networking resources, applications, and services), which may be virtualized or bare metal. A 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 services over publicly accessible networks (e.g., the Internet, cellular communications networks) and the hardware and software in the cloud provider's data centers that provide those services.

[0026] The cloud provider network 203 can provide users with an on-demand, scalable computing platform over the network, allowing them to have scalable “virtual computing devices” at their disposal, for example, through the use of compute servers (which provide compute instances through the use of central processing units (CPUs) and / or graphics processing units (GPUs), optionally with local storage) and block store servers (which provide virtualized persistent block storage for specified compute instances). These virtual computing devices have the attributes of personal computing devices, including hardware (various types of processors, local memory, random access memory (RAM), hard disk, 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 a browser, application programming interface (API), or software development kit (SDK). Unlike a personal computing device, where a user has a fixed amount of hardware resources available, the hardware associated with a virtual computing device can be scaled up or down depending on the resources needed by the user.

[0027] As previously mentioned, users can connect to virtualized computing devices and other resources and services of the cloud provider network 203 using various interfaces 206 (e.g., APIs) via intermediate network(s) 212. An API refers to an interface and / or communication protocol between a client device 215 and a server such that when a client makes a request in a predefined format, the client should receive a response in a particular format or initiate a defined action. In the context of a cloud provider network, an API provides a gateway 251 for customers to access the cloud infrastructure by allowing customers to retrieve data from or perform actions within the cloud provider network 203, enabling the development of applications that interact with resources and services hosted in the cloud provider network 203. APIs can also enable various services in 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 use by their customers or clients.

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

[0029] Cloud provider network 203 may also include an overlay network of virtualized computing resources running on a 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) over the network substrate between client resource instances on different hosts in 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 may be viewed as providing a virtual network topology overlaid on the network substrate. As such, network packets may be routed along the substrate network according to constructs in the overlay network (e.g., virtual networks, which may be called virtual private clouds (VPCs) and 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 be a regionally distributed lookup service that maps overlay Internet Protocol (IP) and network identifier combinations to substrate IPs, allowing distributed substrate computing devices to look up packet destinations.

[0030] By way of 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 techniques may enable multiple operating systems to run simultaneously on a host computer, e.g., 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 the various VMs on the host and monitors the execution of the VMs. Each VM may be assigned 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 techniques to encapsulate and route network packets (e.g., client IP packets) over the network substrate between virtualized resources on different hosts within the cloud provider network 203. Encapsulation protocol techniques may be used on the network substrate to route encapsulated packets between endpoints on the network substrate via overlay network paths or routes. The encapsulation protocol technology may be viewed as providing a virtual network topology overlaid on a network substrate. The encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (e.g., customer-visible IP addresses) to substrate IP addresses (customer-invisible IP addresses), which may be accessed by various processes on the cloud provider network 203 to route packets between endpoints.

[0031] As shown, traffic and operations of the cloud provider network substrate can, in various embodiments, be broadly subdivided into two categories: control plane traffic, carried on a logical control plane 218, and data plane operations, carried on a 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 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 should be 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 transferring data to and from customer resources.

[0032] Control plane components are typically implemented on a separate set of servers from the data plane servers, and control plane traffic and data plane traffic may be transmitted over separate and distinct networks. 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 cloud provider network 203 include a flag indicating whether the traffic is control plane traffic or data plane traffic. In some embodiments, the payload of the traffic may be inspected to determine its type (e.g., control plane or data plane). Other approaches to distinguishing traffic types are possible.

[0033] As shown, data plane 221 may include one or more compute servers, which may be bare metal (e.g., single tenant) or may be virtualized by a hypervisor to run multiple VMs (sometimes referred to as “instances”) or micro-VMs for one or more customers. These compute servers may support virtualized computing services (or “hardware virtualization services”) of cloud provider network 203. The virtualized computing services may be part of control plane 218 and allow customers to issue commands via interfaces 206 (e.g., APIs) to launch and manage compute instances (e.g., VMs, containers) for their applications. The virtualized computing services may provide virtual compute instances with various compute and / or memory resources. In one embodiment, each of the virtual compute instances may correspond to one of several instance types. An instance type may be characterized by its hardware type, computational resources (e.g., the number, type, and configuration of CPUs or CPU cores), memory resources (e.g., the capacity, type, and configuration of local memory), storage resources (e.g., the capacity, type, and configuration of locally accessible storage), network resources (e.g., the characteristics and / or network capabilities of its network interfaces), and / or other suitable descriptive characteristics. The instance type selection function may be used to select an instance type for a customer, e.g., based (at least in part) on input from the customer. For example, a customer may select an instance type from a set of predefined instance types. As another example, a customer may specify the desired resources of the instance type and / or the requirements of the workload the instance will run, and the instance type selection function 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 issue commands via interfaces 206 (e.g., APIs) to create and manage volumes for applications running on compute instances. Block store servers include one or more servers where data is stored as blocks. A block is a sequence of bytes or bits, typically containing an integer number of records with a maximum length of the block size. Blocked data is typically stored in a data buffer, and an entire block is read or written at a time. In general, a volume can correspond to a logical collection of data, such as a set of data maintained on behalf of a user. A user volume, which can be treated as an individual hard drive, ranging in size from 1 GB to 1 terabyte (TB) or more, is composed of one or more blocks stored on a block store server. Although treated as individual hard drives, it will be understood that volumes may be stored as one or more virtualized 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. A volume's data may be replicated across multiple devices within the cloud provider network 203 to provide multiple replicas of the volume (such replicas may collectively represent a volume on a computing system).Replicas of volumes in a distributed computing system can beneficially provide automatic failover and recovery, for example, by allowing users to access either a primary replica of a volume or a secondary replica of a volume synchronized at the block level with the primary replica, so that failure of either the primary or secondary replica does not prevent access to the volume's information. The role of the primary replica may be to facilitate reads and writes (sometimes referred to as "input / output operations" or simply "I / O operations") on the volume and to reflect any writes to the secondary (preferably synchronously in the I / O path, although sometimes using asynchronous replication). Secondary replicas are updated synchronously with the primary replica and can provide a seamless transition during a failover operation, whereby the secondary replica takes over the role of the primary replica and the previous primary is designated as the secondary, or a new replacement secondary replica is provisioned. While specific examples herein describe a primary replica and a secondary replica, it will be understood that a logical volume can include multiple secondary replicas. A compute instance may virtualize its I / O to the volume via a client. A client corresponds to instructions that enable a compute instance to connect to and perform I / O operations on a remote data volume (e.g., a data volume stored on a physically separate computing device accessed over a network). A client may be implemented on an offload card of a server that includes a processing unit (e.g., a CPU or GPU) of the compute instance.

[0035] The data plane 221 may also include one or more object store servers, which represent other types of storage within the cloud provider network 203. An object storage server includes one or more servers on which 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 stored data, a variable amount of metadata that enables various functions of the object storage server regarding analysis of the stored objects, and a globally unique identifier or key that can be used to retrieve the object. Each bucket is associated with a given user account. Customers can store as many objects as they want within their buckets, write, read, and delete objects within their buckets, and control access to their buckets and the objects contained therein. Furthermore, in embodiments in which several different object storage servers are distributed across different ones of the aforementioned regions, users can choose the region (or regions) in which their buckets are stored, e.g., to optimize latency. Customers can use buckets to store various types of objects, such as machine images that can be used to start VMs or snapshots that represent point-in-time views of a volume's data.

[0036] Provider substrate extension 224 (“PSE”) provides resources and services of cloud provider network 203 within a separate network, such as a telecommunications network, thereby extending the capabilities of cloud provider network 203 to new locations (e.g., for reasons related to latency in communications with customer devices, regulatory compliance, security, etc.). In some embodiments, PSE 224 may be configured to provide capacity for cloud-based workloads executing within the telecommunications network. In some embodiments, PSE 224 may be configured to provide core and / or RAN functionality for the telecommunications network and may be configured with additional hardware (e.g., radio access hardware). Some embodiments may be configured to enable both, for example, by making unused capacity by the core and / or RAN functionality available for running cloud-based workloads.

[0037] As shown, such provider substrate extensions 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 within cloud provider-managed facilities separate from those associated with the cloud provider network 203), a communications service provider-managed provider substrate extension 230 (e.g., formed by servers associated with communications service provider facilities), and a customer-managed provider substrate extension 233 (e.g., formed by servers located on-premise at a customer or partner facility).

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

[0039] A provider substrate extension server may host one or more compute instances. A compute instance may be a VM or container that packages code and all its dependencies, allowing an application to run quickly and reliably across computing environments (e.g., including VMs and micro-VMs). Additionally, depending on customer preferences, the server may host one or more data volumes. In a region of the cloud provider network 203, such volumes may be hosted on dedicated block store servers. However, because the capacity of the provider substrate extension 224 may be significantly smaller than within a region, a suboptimal usage experience may be provided if the provider substrate extension includes such dedicated block store servers. Therefore, block storage services may be virtualized within the provider substrate extension 224, such that one of the VMs runs block store software to store the volume's data. Similar to the operation of block storage services 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. The compute 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] Servers within the provider substrate extension 224 may, in some embodiments, host certain local control plane components, such as components that allow the provider substrate extension 224 to continue functioning if connectivity back to the cloud provider network 203 is lost. 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 data store that indicates the locations of volume replicas. However, in general, the control plane 236 functions of the provider substrate extension 224 remain in the cloud provider network 203 to allow customers to use as much of the resource capacity of the provider substrate extension 224 as possible.

[0041] The migration manager may have a centralized coordination component running within the region as well as a local controller running on the PSE server (and servers in the cloud provider's data center). The centralized coordination component can identify the target edge location and / or target host when a migration is triggered, and the local controller can coordinate the 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. Migration refers to moving virtual machine instances (and / or other resources) between hosts within a cloud computing network or between hosts outside the cloud computing network and hosts within the cloud. There are various types of migrations, such as live migration and reboot migration. During a reboot migration, a customer experiences a shutdown and effective power cycle of the virtual machine instance. For example, a control plane service may coordinate a reboot migration workflow that involves destroying the current domain on the original host and then creating a new domain for the virtual machine instance on a new host. The instance is restarted by shutting it down on the original host and starting it 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 disrupting the availability of the virtual machine (e.g., virtual machine downtime is not 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 running applications), 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 transferred to the destination host. The control plane may transition the inactive domain to become the active domain, demote the original active domain to become the inactive domain (also known as a "flip"), and then destroy the inactive domain.

[0043] Various types of migration techniques involve managing critical phases (times when a virtual machine instance is unavailable to customers), which should be as short as possible. This management can be particularly challenging in currently disclosed migration techniques because resources are moved between hosts in geographically distant locations that may be connected through one or more intermediate networks. For live migrations, the disclosed techniques can dynamically determine how much memory state data to copy in advance (e.g., while the instance is still running on the source host) and how much memory state data to copy afterward (e.g., after the instance has started running on the destination host) based on, for example, the latency between the 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 the locations. This analysis may be performed by a migration management component within the region or by a migration management component running locally at the source edge location. If the instance has access to virtualized storage, both the source and target domains may be simultaneously attached to the storage to enable 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 enabled to run unmodified within the provider substrate extension 224 by creating a private replica of the substrate network (a "shadow substrate") within an edge location using local network manager(s) 242. The local network manager(s) 242 operate on the provider substrate extension 224 servers and can bridge the shadow substrate with 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 within the cloud provider network 203, and by implementing a mapping service (for traffic encapsulation and de-encapsulation) that associates data plane traffic (from the data plane proxy 248) and control plane traffic (from the control plane proxy 245) with the appropriate server(s). By implementing a local version of the provider network's substrate overlay mapping service, local network manager(s) 242 enable resources in provider substrate extension 224 to seamlessly communicate with resources in cloud provider network 203. In some embodiments, a single local network manager 242 may perform these actions for all servers hosting compute instances in provider substrate extension 224. In other embodiments, each server hosting a compute instance may have its own dedicated local network manager 242.In multi-rack edge locations, local network managers maintain open tunnels with each other so that inter-rack communications can be routed through the local network manager 242 .

[0045] The provider substrate extension locations may utilize secure network tunnels through the provider substrate extension 224 network to the cloud provider network 203, for example, to maintain the security of customer data as it traverses the provider substrate extension 224 network and other intermediate networks (potentially including the public Internet). Within the cloud provider network 203, these tunnels are comprised of virtual infrastructure components, including isolated virtual networks (e.g., within an overlay network), a control plane proxy 245, a data plane proxy 248, and substrate network interfaces. Such proxies 245, 248 may be implemented as containers running on the compute instances. In some embodiments, each server at the provider substrate extension 224 location that hosts a compute instance may utilize at least two tunnels: one for control plane traffic (e.g., Constrained Application Protocol (CoAP) traffic) and one for encapsulated data plane traffic. A connection manager (not shown) within the cloud provider network 203 manages the lifecycle of the cloud provider network side 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 may provide constant 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 is an intermediary between the control plane 218 within the cloud provider network 203 and control plane targets within the control plane 236 of the provider substrate extension 224. That is, the CP proxy 245 provides the infrastructure for tunneling management API traffic destined for a provider substrate extension server from the regional substrate to the provider substrate extension 224. For example, a virtualized computing service in the cloud provider network 203 may issue a command to the VMM of a server in the provider substrate extension 224 to launch a compute instance. The CP proxy 245 maintains a tunnel (e.g., a 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 the substrate. The CP proxy 245 provides a mechanism to expose remote servers on the cloud provider substrate while still protecting the substrate's security material (e.g., encryption keys, security tokens) from leaving the cloud provider network 203. The unidirectional control plane traffic tunnel imposed by the CP proxy 245 also prevents arbitrary (potentially compromised) devices from calling back into the substrate. The CP proxy 245 may be instantiated one-to-one with a server in the provider substrate extension 224, or may be able to manage control plane traffic for multiple servers within the same provider substrate extension.

[0047] Data plane (DP) proxies 248 may also be provisioned within the cloud provider network 203 to represent specific server(s) within the provider substrate extension 224. The DP proxies 248 act as shadows or anchors for the server(s) and may be used by services within the cloud provider network 203 to monitor the host's health (including availability, used / free compute and capacity, used / free storage and capacity, and network bandwidth usage / availability). The DP proxies 248 also act as proxies for the server(s) within the cloud provider network 203, thereby enabling isolated virtual networks to span 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 shown, each DP proxy 248 may maintain a VPN tunnel with a local network manager 242, which manages traffic to the server(s) it represents. This tunnel may 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 may pass through the DP proxy 248 associated with that provider substrate extension 224. For 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 may forward the encapsulated traffic from the cloud provider network 203 directly to the provider substrate extension 224.

[0048] The local network manager(s) 242 can provide secure network connectivity with proxies 245, 248 established within the cloud provider network 203. After connectivity between the local network manager 242 and the proxies 245, 248 is established, the customer may issue commands via interface 206 to instantiate compute instances (and / or perform other operations using the compute instances) using the provider substrate extension resources in the same manner as commands would be issued for compute instances hosted within the cloud provider network 203. 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 servers at the provider substrate extension 224 may communicate with both electronic devices in 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 coupled to that extension (e.g., the communications service provider network in the example of provider substrate extension 230).

[0049] In some situations, data transfer between an object storage service and a provider substrate extension (PSE) 224 may be required. For example, an object storage service may store machine images used to boot VMs and snapshots representing point-in-time backups of volumes. An object gateway may provide, on a PSE server or specialized storage device, a configurable per-bucket cache of the contents of object storage buckets in the PSE 224 for customers to minimize the impact of PSE regional latency on customer workloads. The object gateway may also temporarily store snapshot data from volume snapshots in the PSE 224 and synchronize it with an object server in the region when possible. The object gateway may also store machine images designated by the customer for use in the PSE 224 or on the customer's premises. In some implementations, data in the PSE 224 may be encrypted with a unique key, and the cloud provider may restrict the key from being shared from the region to the PSE 224 for security reasons. Thus, 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. A means of transformation can perform these operations, and a PSE bucket can be created (on the object store server) to store the snapshot data and machine image data using the PSE encryption key.

[0050] As described above, PSE 224 forms an edge location in that it provides cloud provider network 203 resources and services closer to customer devices outside of traditional cloud provider datacenters. The edge locations referred to herein can be structured in several ways. In some implementations, an edge location can be an extension of the cloud provider network substrate, including a limited amount of capacity provided outside of an availability zone (e.g., in a smaller datacenter located closer to customer workloads and potentially far from any availability zones, or in other facilities of the cloud provider). Such edge locations are sometimes referred to as “far zones” (because they are far from other availability zones) or “near zones” (because they are closer to customer workloads). Near zones can be connected to publicly accessible networks such as the Internet in various ways, for example, directly, through another network, or through a private connection to a region. Typically, near zones have limited capacity compared to regions, but in some cases, near zones can have significant capacity, such as thousands of racks or more.

[0051] In some implementations, an edge location may be an extension of a cloud provider network substrate formed by one or more servers located on-premises at a customer or partner facility, with such server(s) communicating over a network (e.g., a publicly accessible network such as the Internet) with a nearby availability zone or region of the cloud provider network 203. This type of substrate extension located outside of a cloud provider network datacenter may be referred to as an "outpost" of the cloud provider network 203. Some outposts may be integrated into a communications network, for example, as a telecommunications datacenter, a telecommunications aggregation site, and / or a multi-access edge computing (MEC) site with physical infrastructure spanning telecommunications base stations within the telecommunications network. In an on-premises example, the outpost's limited capacity may be available only to the customer that owns the facility (and any other accounts authorized by the customer). In a telecommunications example, the outpost's limited capacity 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 controlled at least in part by the control plane of a nearby availability zone in 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., are controlled at least in part by its control plane). Certain limited control plane functions (e.g., functions requiring low-latency communication with customer resources and / or functions that allow the edge location to continue functioning when disconnected from the parent availability zone) may also be present in some edge locations. Thus, 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, close to customer devices and / or workloads.

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

[0054] In 5G wireless network development efforts, edge locations may be considered as a possible implementation of multi-access edge computing (MEC). Such edge locations may be connected to various points within the 5G network that provide data traffic breakout as part of the user plane function (UPF). Even older wireless networks may incorporate edge locations. For example, in a 3G wireless network, an edge location may be connected to a packet-switched network portion of the communications network 100, such as a serving general packet radio service support node (SGSN) or gateway general packet radio service support node (GGSN). In a 4G wireless network, an edge location may be connected to a serving gateway (SGW) or packet data network gateway (PGW) as part of the core network or evolved packet core (EPC). In some embodiments, traffic between the provider substrate extension 224 and the cloud provider network 203 may be decoupled from the communications network 100 without being routed through the core network.

[0055] In some embodiments, 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, provider substrate extension 224 may be connected to both networks. For example, each customer may assign a portion of its network address space to provider substrate extension 224, and the provider substrate extension may include a router or gateway capable of distinguishing traffic exchanged with each of communication networks 100. For example, traffic destined for 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. Traffic from provider substrate extension 224 destined for a destination in one of the networks may likewise be encapsulated to have the appropriate VLAN tag, source IP address (e.g., from a pool allocated to provider substrate extension 224 from the destination network address space), and destination IP address.

[0056] FIG. 2B illustrates an example cellularization and geographic distribution 253 of communication network 100 (FIG. 1) for providing a highly available user plane function (UPF). In FIG. 2B, a user device 254 communicates with a request router 255 to route requests to one of multiple control plane cells 257a and 257b. Each control plane cell 257 may include a network service API gateway 260, a network slice configuration 262, network service monitoring functions 264, site planning data 266 (including layouts describing customer site requirements, device types, device quantities, etc.), a network service / function catalog 268, orchestration functions 270, and / or other components. To reduce the likelihood that a large-scale error will affect a wide range of customers, a large control plane may be divided into cells, with one or more cells operating independently, for example, per customer, per network, or per region.

[0057] The network service / function catalog 268 is also referred to as the NF repository function (NRF). In a service-based architecture (SBA) 5G network, control plane functions and a common data repository may be delivered through a set of interconnected network functions built using a microservices architecture. The NRF may maintain a record of available NF instances and their supported services, allowing other NF instances to subscribe to and be notified of registrations from NF instances of a given type. Thus, the NRF may support service discovery by receiving discovery requests from NF instances and specify which NF instances support a particular service. 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 onboard new NFs, manage the migration of existing NFs to new or updated versions, identify a suitable set of NFs for a particular network slice or larger network, and orchestrate NFs across the various computing devices and sites that comprise 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 that runs one or more distributed unit (DU) network functions 282. The customer local data center 274 includes computing hardware 283 that runs one or more DU or central unit (CU) network functions 284, a network controller, a UPF 286, one or more edge applications 287 that support customer workloads, and / or other components.

[0059] The local zone 276 may reside in a data center operated by a cloud service provider and may run one or more core network functions 288, such as the AMF, SMF, a network publishing function (NEF) that securely publishes the services and capabilities of other network functions, and a unified data management (UDM) function that manages subscriber data for authorization, registration, and mobility management. The local zone 276 may also run the UPF 286, a service for metric processing 289, and one or more edge applications 287.

[0060] The 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; a UPF 286; an operations support system (OSS) 290 that supports network management systems, service delivery, service fulfillment, service assurance, and customer care; an Internet Protocol Multimedia Subsystem (IMS) 291; a business support system (BSS) 292 that supports product management, customer management, revenue management, and / or order management; one or more portal applications 293, and / or other components.

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

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

[0063] FIG. 3 illustrates an exemplary cloud provider network 203 including geographically distributed provider substrate extensions 224 (FIG. 2A) (or “edge locations 303”), according to some embodiments. As illustrated, the cloud provider network 203 may be formed as multiple regions 306, where a region is a distinct geographic 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 a fiber optic connection. An availability zone refers to an isolated failure domain that includes one or more data center facilities with separate power sources, separate networks, and separate cooling from other availability zones. Cloud providers may strive to locate availability zones within a region 306 sufficiently far from each other to prevent a natural disaster, major power outage, or other unforeseen event from taking multiple availability zones offline at the same time. Customers can connect to resources within an availability zone of the cloud provider network 203 via a publicly accessible network (e.g., the Internet, a cellular network, a communications service provider network). Transit centers (TCs) are primary backbone locations that link customers to the cloud provider network 203 and may be co-located with other network provider facilities (e.g., internet service providers, telecommunications providers). Each region 306 can operate two or more TCs for redundancy. The regions 306 are connected to a global network that includes a private network infrastructure (e.g., fiber connections controlled by the cloud service provider) that connects each region 306 to at least one other region. The cloud provider network 203 can deliver content from points of presence ("PoPs") that are external to, but networked with, these regions 306 via edge locations 303 and regional edge cache servers.This partitioning and geographic distribution of computing hardware enables cloud provider network 203 to offer customers global, low-latency resource access with a high degree of fault tolerance and stability.

[0064] The number of edge locations 303 can be much greater than the number of regional data centers or availability zones. This widespread deployment of edge locations 303 can provide low-latency connectivity to the cloud for a much larger group of end-user devices (compared to end-user devices that happen to be very close to a regional data center). 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 locations 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. It should be noted that although the edge location 303 is generally depicted herein as being within the communications service provider network or wireless network 103 (FIG. 1), in some cases, such as when the cloud provider network facilities are relatively close to the communications service provider facilities, the edge location 303 may remain within the physical premises of the cloud provider network 203 while connected to the communications service provider network via fiber or other network links.

[0065] Edge locations 303 may be structured in several ways. In some implementations, edge locations 303 may be an extension of the cloud provider network substrate, including a limited amount of capacity provided outside of availability zones (e.g., in a small data center located close to customer workloads and potentially far from any availability zones, or in other facilities of the cloud provider). Such edge locations 303 may be referred to as local zones (because they are closer to a local area or group of users than traditional availability zones). Local zones may be connected to publicly accessible networks such as the Internet in various ways, for example, directly, through another network, or through a private connection to a region 306. Typically, local zones have limited capacity compared to a region 306, but in some cases, local zones may have significant 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 shown herein, the cloud provider network 203 can be formed as several regions 306, each representing a geographic area where the cloud provider clusters its data centers 309. Each region may further include multiple (e.g., two or more) availability zones (AZs) connected to each other via a private high-speed network, e.g., fiber communications connections. An AZ may provide an isolated failure domain, including one or more data center facilities with separate power sources, separate networks, and separate cooling from another AZ. The AZs within a region 306 are preferably located in locations far enough apart from each other that the same natural disaster (or other failure-causing event) does not affect or take multiple AZs offline at the same time. Customers can connect to the AZs of the cloud provider network 203 via a publicly accessible network (e.g., the Internet, a cellular communications network, etc.).

[0067] The parenting of a given edge location 303 to an AZ or region 306 of the cloud provider network 203 may be based on several factors. One such parenting factor is data sovereignty. For example, an edge location 303 deployed within a country's communications network may be parented to an AZ or region 306 within that country to keep data originating from that country's communications network 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 such as local non-volatile storage for customer data (e.g., solid-state drives), graphics accelerators, etc. Some AZs or regions 306 may lack services to utilize those additional resources, so an edge location may be parented to an AZ or region 306 that supports the use of those resources. Another factor is the latency between the AZ or region 306 and the edge location 303. While deploying edge locations 303 within a communications network provides benefits in terms of latency, those benefits can be negated by parenting the edge location 303 to a distant AZ or region 306, which introduces significant latency to the edge location 303's regional traffic. Therefore, edge locations 303 are often parented to nearby (in terms of network latency) AZs or regions 306.

[0068] 4, a network environment 400 according to various embodiments is 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 are in data communication with each other via a network 412. The network 412 may include, for example, the Internet, an intranet, an extranet, a wide area network (WAN), a local area network (LAN), a wired network, a wireless network, a cable network, a satellite network, or any other suitable network, or any combination of two or more such networks.

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

[0070] In some embodiments, computing environment 403 may correspond to a virtualized private network within a physical network that includes virtual machine instances running on physical computing hardware, for example, by a hypervisor. The virtual machine instances and containers running on those instances may be provided network connectivity through 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 computing environment 403 according to various embodiments. Also, various data may be stored in data store 415, which is accessible to computing environment 403. Data store 415 may be representative of multiple data stores 415, as can be appreciated. Data stored in data store 415 may be associated with the operation of various applications and / or functional entities, for example, as described below.

[0072] The computing environment 403, as part of the cloud provider network 203 that provides utility computing services, includes computing devices 418 and other types of computing devices. The computing devices 418 may correspond to different types of computing devices 418 and may have different computing architectures. The computing architectures may differ by utilizing processors with different architectures, such as x86, x86_64, ARM, Scalable Processor Architecture (SPARC), PowerPC, etc. For example, one computing device 418 may have an x86 processor, while another computing device 418 may have an ARM processor. The 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 may correspond to virtual machine (VM) instances, containers, or serverless functions running on the computing devices 418. The virtual machine instances may be instantiated from virtual machine (VM) images. To this end, a customer may specify that a virtual machine instance should be launched within a computing device 418 and not other types of computing devices 418. In various examples, one 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 may run different types of VM instances or containers, which may provide different amounts of resources available via the 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 executing on the computing environment 403 include, for example, a network slice allocation service 425, a content distribution service 426, and other applications, services, processes, systems, engines, or functions not described in detail herein. The network slice allocation service 425 executes to allocate network slices on demand to applications and / or client devices 406 connected to the RAN of the wireless network 103 with an associated core network. As used herein, the term "network slice" refers to specific network traffic that is assigned a priority according to one or more quality of service requirements and / or is provided with a hardware capacity reservation for receiving, transmitting, or managing the network traffic. Network traffic in 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 (e.g., by deep packet inspection). A network slice may be temporary, 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 may be called by applications on the client device 406 and / or backend services that interact with those applications to request allocation, modification, or release of a network slice. The network slice allocation service 427 allocates a network slice on the wireless network 103; however, there may be one or more devices coupled to the wireless network 103 via one or more fixed or wired links, and the network slice determined by the network slice allocation service 427 may be applicable to such devices as well.

[0075] To allocate a network slice, 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 the network slice specification. Note that a network slice may have a higher or lower priority than normal traffic and, therefore, a corresponding cost that is higher or lower than normal usage costs. In some scenarios, the network slice allocation service 425 may increase or decrease the computing capacity 421 allocated to a network function workload to meet the specified quality of service requirements. For example, allocating more computing capacity 421 to a network function that implements a network slice may result in lower latency. In some embodiments, the network slice allocation service 425 may also relocate a network function workload at a different point within the wireless network 103 to meet the quality of service requirements. Additionally, 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 the quality of service requirements.

[0076] In some embodiments, an application developer or application owner can specify a required network slice configuration in an application template used to deploy a particular application within the cloud provider network 203, allowing the application to provide this information to the network slice allocation service 427 when making an API-based request for a 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 for the wireless network 103 as a whole. To this end, the network slice allocation service 427 may train one or more machine learning models to recognize network slice configurations taking into account customer conditions or conditions across multiple customers. The machine learning models can then be used to identify the optimal network slice to allocate to a given device type or application determined to be present in the wireless network 103. For example, the network slice allocation service 427 can receive detailed network information or automatically survey the wireless network 103 to understand devices, applications, latency, usage patterns, etc. The network slice allocation service 427 can then provide this information to the machine learning models 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 executes to provide content 427 from edge locations (such as the PoPs and other edge locations 303 described herein, collectively referred to as a content delivery network or CDN) to applications running on client devices 406 coupled to the wireless network 103. In some embodiments, the content delivery service 426 predictively caches certain 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 in advance of any content consumption request by a customer based at least in part on the customer's account, including 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 a customer associated with the wireless network 103.

[0078] Data stored in data store 415 may include, for example, data regarding 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, radio unit configuration data 457, antenna configuration data 460, network function configuration data 463, one or more network function workloads 466, one or more customer workloads 469, one or more network slices 470, and potentially other data.

[0079] The network plan 439 is a specification of the wireless network 103 to be deployed for a customer. For example, the network plan 439 may include the location or geographic area of ​​the premises to be covered, the number of cells, device identification and permissions, desired maximum network latency, desired bandwidth or network throughput for one or more classes of devices, one or more quality of service parameters for applications or services, and / or other parameters that can be used to create the wireless network 103. The customer can manually specify one or more of these parameters via a user interface. One or more of the parameters may be pre-set as default parameters. In some cases, the network plan 439 may be generated for a customer based at least in part on an automated site survey using an unmanned aerial vehicle. The values ​​of the parameters that define the network plan 439 may be used as a basis for the cloud service provider to bill the customer under a utility computing model. For example, a service level agreement (SLA) may charge a customer a higher amount for lower latency targets and / or higher bandwidth targets, and the customer may be charged per device, per cell, etc., based on the geographic area served, spectrum availability, etc.

[0080] The cellular topology 442 includes an arrangement of multiple cells for a customer, taking into account the location of the cells and, where possible, frequency spectrum reuse. The cellular topology 442 can be generated automatically 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 geographic area to be covered, the availability of backhaul connections 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 restrictions, spectrum that is privately owned or leased by a customer, spectrum that is owned or leased by a provider, spectrum that is free to use but requires a reservation, etc.

[0082] The device data 448 corresponds to data describing the wireless device 106 (FIG. 1) that is authorized to connect to the wireless network 103. This device data 448 may include the corresponding user, account information, billing information, data plan, authorized applications or uses, an indication of whether the wireless device 106 is mobile or fixed, location, current cell, network address, device identifier (e.g., International Mobile Equipment Identity (IMEI) number, Equipment Serial Number (ESN), Media Access Control (MAC) address, Subscriber Identity Module (SIM) number, etc.).

[0083] The 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. The RBN metrics 451 may be aggregated per device, per cell, per customer, etc.

[0084] The customer billing data 454 specifies the fees the customer will incur for the provider's operation of the wireless network 103 for the customer. The fees may include a fixed fee based on the equipment deployed to the customer and / or a usage-based fee. In some cases, the customer may have purchased the equipment upfront and may be charged only for bandwidth or back-end network costs. In other cases, the customer may not incur any upfront costs and may be charged purely on a usage basis. Because the equipment is provided to the customer based on a utility computing model, the cloud service provider can select the optimal configuration of equipment to meet the customer's target performance metrics while avoiding unnecessary hardware over-provisioning.

[0085] The radio unit configuration data 457 may correspond to configuration settings for radio units deployed in the wireless network 103. Such settings may include the frequency to use, the protocol to use, modulation parameters, bandwidth, network routing and / or backhaul configuration, etc.

[0086] The antenna configuration data 460 may correspond to the configuration settings of the antenna, including the frequency to use, the azimuth angle, the vertical or horizontal orientation, the beam tilt, and / or other parameters that may be controlled automatically (e.g., by networked motors and controls on the antenna) or manually by instructing a user to mount the antenna in a particular manner or make physical changes to the antenna.

[0087] Network function configuration data 463 corresponds to configuration settings that configure the operation of various network functions of wireless network 103. In various embodiments, network functions may be deployed on VM instances or containers located on computing devices 418 at cell sites, customer aggregation sites, or data centers located remotely from customers. Non-limiting examples of network functions may include access and mobility management functions, session management functions, user plane functions, policy control functions, authentication server functions, unified data management functions, application functions, network publishing functions, network function repositories, network slice selection functions, and / or others. Network function workloads 466 correspond to machine images, containers, or functions for performing one or more network functions.

[0088] Customer workloads 469 correspond to customer machine images, containers, or functions that may run as VM instances or containers alongside or instead of network function VM instances or containers. For example, customer workloads 469 may provide or support customer applications or services.

[0089] A network slice 470 corresponds to a flow of network traffic specified against one or more particular quality of service requirements 471. A flow may correspond to a flow associated with a particular application running on a particular client device 406, all network traffic from a particular client device 406, flows from all client devices 406 to a particular destination, flows from a particular client device 406 to a particular destination, etc. In one example, a network slice 470 is identified by a source port, a source network address, a destination port, a destination network address, and / or other information. A network slice 470 may be valid for a particular period of time or a particular amount of data, or may be valid until canceled or released. In one example, a network slice 470 is allocated on-demand to a particular application running on a client device 406. In some scenarios, a network slice 470 has a particular recurring validity period (e.g., from midnight to 5:00 AM every weekday), or the quality of service requirements 471 of a network slice 470 may change based on the recurring period, current cost levels, and / or other factors or events.

[0090] Quality of service requirements 471 may correspond to minimum or maximum bandwidth, minimum or maximum delay, minimum or maximum reliability measure, minimum or maximum signal strength, etc. Quality of service requirements 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 requirements 471 may be associated with a periodic monthly fixed 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 select a quality of service requirement 471 that provides a high level of service. In other cases, a customer may select a quality of service requirement 471 that provides a low level of cost but reduces service quality at certain times or in certain aspects. For example, a customer may select a quality of service requirement 471 that allows high throughput at night to send backup data over the network at low cost, but selects lower-priority throughput at other times.

[0091] Client device 406 represents multiple client devices 406 that may be coupled to network 412. Client device 406 may include, for example, a processor-based system such as a computer system. Such a computer system may be embodied in the form of a desktop computer, a laptop computer, a personal digital assistant, a mobile phone, a smartphone, a set-top box, a music player, a web pad, a tablet computer system, a game console, an e-reader, a smart watch, a head-mounted display, a voice interface device, or other device. Client device 406 may include, for example, a display comprising one or more devices such as a liquid crystal display (LCD), a gas plasma-based flat panel display, an organic light-emitting diode (OLED) display, an electronic ink (E-ink) display, an LCD projector, or other type of display device.

[0092] The client device 406 may be configured to execute various applications, such as a client application 436 and / or other applications. The client application 436 may execute within the client device 406 and render a user interface on a display, for example, by accessing network content provided by the computing environment 403 and / or other servers. To this end, the client application 436 may comprise, for example, a browser, a dedicated application, etc., and the user interface may comprise a network page, an application screen, etc. 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 may 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 telephony 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 execute applications, such as, for example, an email application, a social networking application, a word processor, a spreadsheet, and / or other applications.

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

[0094] Starting at box 503, the client application 436 determines to request allocation of a network slice 470 (FIG. 4) in the wireless network 103 (FIG. 4), for example, by invoking a network slicing API. In some cases, the client application 436 may render a user interface that allows a user to specifically request allocation of a network slice 470 and configure parameters corresponding to quality of service requirements 471 (FIG. 4). For example, the client application 436 may render a user interface that includes a slider to adjust between a combination of low latency and high cost and a combination of high latency and low cost. The user interface may also allow configuration of settings related to bandwidth, reliability, number of network hops, and / or other parameters related to network quality of service. In some implementations, network slice settings may be specified by an application developer or owner and saved as part of an application template that can be used to launch the application within the wireless network. The network slice settings may include settings such as rate limits and network topology, as well as the required capacity of the underlying shared hardware resources of the wireless network 103. The service can determine how to orchestrate and deploy only the network functions necessary to support a particular network slice. The network slice configuration can also include parameters related to scaling the network slice, allowing the amount of reserved resources to be dynamically adjusted 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 the application's connectivity, speed, latency, and capacity needs.

[0095] In other scenarios, the client application 436 may determine to automatically request a network slice 470. For example, network congestion may cause performance degradation with respect to an internal quality of service measure or requirement, and the client application 436 may be configured to request a network slice 470 to mitigate the performance degradation. A user may also specify, via a user interface, a metric that causes the client application 436 to automatically request a network slice 470. For example, in a videoconferencing application, a user may check a box that enables the request of a network slice 470 to maintain the quality of the videoconference.

[0096] In box 506, the client application 436 sends a request to allocate a network slice 470 to the network slice allocation service 425 (FIG. 4), causing the network slice 470 to be allocated. The request may be sent directly to the network slice allocation service 425 or to an intermediary entity. The request may specify one or more quality of service requirements 471, such as delay, bandwidth, reliability, jitter, or other requirements. The requirements may be expressed as maximum, minimum, median, average, or other threshold measures. To the extent that the quality of service requirements 471 are associated with corresponding costs, the request can instead specify target costs, such as maximum cost, minimum cost, or a range the customer is willing to spend on a quality of service dimension, such as bandwidth or delay, and the network assigns the corresponding service level based on the price the customer is willing to pay. In some cases, the allocation of a network slice may include adding or reserving additional frequency spectrum, which may incur costs. In such cases, the customer may bid for the additional frequency spectrum, for example, in a spot market for spectrum allocation.

[0097] The client application 436 can also specify a duration for the network slice 470, which can correspond to a length of time, a volume of data, or another measure, after which another network slice 470 or the default network slice 470 can become effective. For example, the duration may correspond to an application session. If no duration is specified, the network slice 470 may remain effective until released or canceled. The request may 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 credentials for authentication purposes. In some embodiments, the request may be sent to the network slice allocation service 425 by a backend service that interacts with the client application 436, rather than directly from the client application 436. For example, the request may be sent from a videoconferencing service provider rather than from a videoconferencing client application 436 running on the 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 targeted for the network slice 470 in the wireless network 103. For example, the client application 436 can insert the token into packets or segments of data targeted for the network slice 470. In this manner, the client application 436 can specify which network traffic should be routed through the 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, designated port, destination address) may be provided to the network slice allocation service 425 to identify the network traffic to be routed within the network slice 470. In another example, all traffic from the client application 436 may be routed through the 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, the 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 a default network connection rather than the network slice 470 allocated to a media player application. Also, the client application 436 may use a different network slice 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 different quality of service requirements 471, or the current quality of service requirements 471 may not be sufficient for the current usage of the client application 436. This difference may be an increase in the quality of service requirements 471 or a decrease in the quality of service requirements 471. In some cases, the network slice 470 may be automatically scaled based on network traffic observed within the network slice or demand 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 an updated token.

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

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

[0103] Starting at box 603, the network slice allocation service 425 determines whether to allocate a network slice 470 (FIG. 4) or modify an existing network slice 470 in the wireless network 103 (FIG. 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 an API-based request to a client application 436 (FIG. 4) or a client device 406 (FIG. 4) to allocate or modify a 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. The request may be received directly from the client application 436 or from a backend service or other host that communicates 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 (FIG. 4) for the network slice 470 and the potential cost the customer is willing to pay to meet those requirements. In one example, the network slice 470 is associated with a lower quality of service requirement 471 than a default connection over the wireless network 103. In another example, the network slice 470 is associated with a higher quality of service requirement 471 than a default connection over the wireless network 103. The request can specify a duration in terms of time period, data volume, or based on application behavior, and the network function(s) can be reconfigured to release the network slice 470 when the duration is met.

[0104] In other examples, the network slice allocation service 425 observes configurations or conditions on the wireless network 103 and automatically determines whether to allocate or modify a network slice 470 based at least in part on a machine learning model. In some cases, the network slice allocation service 425 may determine to pre-configure one or more network slices 470 for a new wireless network 103 to be deployed based on a 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 in the wireless network 103 to process data for the network slice 470 to meet the quality of service requirements 471. For example, the network slice allocation service 425 can configure the network functions to process data with a higher or lower priority to result in a lower or higher latency metric or other metric. In another example, the network slice allocation service 425 can configure the network functions to prioritize data from an application up to a specified maximum bandwidth or a specified minimum latency. In one example, the client application 436, which is a gaming application, may have very low latency requirements. The network slice allocation service 425 can also make reservations with the underlying network hardware to reserve capacity for the network slice 270. In some cases, the network slice allocation service 425 can allocate network capacity to the network slices 270 in an oversubscribed manner, such 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 a predicted ability of the network capacity to meet the QoS requirements 471 of the network slice 270. Such a prediction may be generated based at least in part on past network traffic volumes, data indicative of predicted future volumes, etc.

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

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

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

[0109] Transferring the network function workload 466 may include relocating customer workloads 469 ( FIG. 4 ) of the requesting customer or other customers away from the computing device 418, or possibly reducing the allocated computing capacity 421 of the computing device 418 to make room for the network function(s). In some cases, the network function workload 466 may cause the associated core network to transfer away from an edge location. In box 615, the network slice allocation service 425 reserves space for and adjusts the processing priority of the newly allocated network slice 470 to meet the quality of service requirements 471 of other network slices 470 with lower or higher quality of service requirements 471. Alternatively, the quality of service requirements 471 of other existing network slices 470 may be decreased or increased.

[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 client application 436 to target network traffic to the 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 the network slice 470 are scaled down, those resources can become available for allocation to other network slices 470 or for network operation in general. Operation on the part of the network slice allocation service 425 then terminates.

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

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

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

[0114] In box 712, the network slice allocation service 425 causes a content delivery service 426 to be instantiated 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 a customer site. The network may also be otherwise prepared for the network slice 470, as described in boxes 606-618 of the flowchart in FIG. 6. In some cases, computing capacity allocated to network functions may be released and reallocated in favor of the content delivery service 426, if this is optimal for meeting quality of service requirements 471.

[0115] At box 715, the network slice allocation service 425 initiates the transfer of the 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 the 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. The content 427 may be predictively cached outside of less congested times on the backbone communication link. In one scenario, the transfer of the content 427 is initiated in response to a determination that consumption of the content 427 does not meet the quality of service requirements 471. Alternatively, the content 427 is transferred before the client device 406 for which the network slice 470 is provisioned requests the content 427. Thereafter, operation on the part of the network slice allocation service 425 terminates.

[0116] 7 references content delivery service 426, network slice allocation service 425 may instantiate other types of endpoint services to support network communications with client device 406. When network slice 470 is no longer needed, instantiated services such as content delivery service 426 may be terminated and / or content 427 may be discarded from content delivery service 426.

[0117] 8, a schematic block diagram of a computing environment 403 is shown, according to an embodiment of the present disclosure. The computing environment 403 includes one or more computing devices 800. Each computing device 800 includes at least one processor circuit having, for example, a processor 803 and memory 806, both of which are coupled to a local interface 809. To this end, each computing device 800 may comprise, for example, at least one server computer or similar device. The local interface 809 may include, for example, a data bus or other bus structure including an associated address / control bus, as can be appreciated.

[0118] Stored in memory 806 are both data and several components executable by processor 803. Specifically, stored in memory 806 and executable by processor 803 are network slice allocation service 425, content distribution service 426, and potentially other applications. Also stored in memory 806 may be data store 415 and other data. Additionally, an operating system may be stored in memory 806 and executable by processor 803.

[0119] As can be appreciated, there may be other applications stored in memory 806 and executable by processor 803. If any component described herein is implemented in software, it may employ any one of several programming languages, such as, for example, C, C++, C#, ObjectiveC, Java, JavaScript, Perl, PHP, Visual Basic, Python, Ruby, Flash, or other programming languages.

[0120] Some software components are stored in memory 806 and executable by processor 803. In this regard, the term "executable" refers to a program file in a format that is ultimately executable by processor 803. Examples of executable programs may include, for example, a compiled program that can be loaded into a random access portion of memory 806 and converted into machine code in a format executable by processor 803; source code that may be expressed in a suitable format, such as object code, that can be loaded into a random access portion of memory 806 and executed 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. The executable program may be stored in any portion or component of memory 806, including, for example, random access memory (RAM), read-only memory (ROM), a hard drive, a solid-state drive, a USB flash drive, a memory card, an optical disk such as a compact disc (CD) or digital versatile disc (DVD), a floppy disk, a magnetic tape, or other memory component.

[0121] Memory 806 is defined herein to include both volatile and nonvolatile memory and data storage components. A volatile component is one that does not retain a data value upon loss of power. A nonvolatile component is one that retains data upon loss of power. Thus, memory 806 may include, for example, random access memory (RAM), read-only memory (ROM), a hard disk drive, a solid-state drive, a USB flash drive, a memory card accessed via a memory card reader, a floppy disk accessed via an associated floppy disk drive, an optical disk accessed via an optical disk drive, a magnetic tape accessed via an appropriate tape drive, and / or other memory components, or a combination of any two or more of these memory components. Additionally, 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] Also, processor 803 may represent multiple processors 803 and / or multiple processor cores, and memory 806 may represent multiple memories 806 each operating in parallel processing circuits. In such cases, local interface 809 may be a suitable network facilitating communication between any two of the multiple processors 803, between any processor 803 and any of the memories 806, or between any two of the memories 806, etc. Local interface 809 may include additional systems designed to coordinate this communication, including, for example, implementing load balancing. 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 by general-purpose hardware, as described above, although the same may alternatively be embodied in dedicated hardware or a combination of software / general-purpose hardware and dedicated hardware. If embodied in dedicated hardware, each may be implemented as a circuit or state machine using any one or combination of numerous technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates to implement various logical functions upon application of one or more data signals, 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 will not be described in detail herein.

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

[0125] While the flowcharts in FIGS. 5-7 depict a specific order of execution, it is understood that the order of execution may differ from that depicted. For example, the order of execution of two or more blocks may be swapped relative to the order depicted. Also, two or more blocks shown consecutively in FIGS. 5-7 may execute concurrently or with partial concurrence. Furthermore, in some embodiments, one or more blocks depicted in FIGS. 5-7 may be skipped or omitted. Additionally, any number of counters, state variables, alert semaphores, or messages may be added to the logic flows described herein for purposes such as improving usability, providing explanations, measuring performance, or providing clues for problem resolution. It is understood that all such variations are within the scope of the present disclosure.

[0126] Also, any logic or application described herein, including the network slice allocation service 425 and the content distribution service 426, comprising software or code, can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system, such as, for example, the processor 803 in a computer system or other system. In this sense, logic can include, for example, statements, including instructions and declarations, retrievable from a computer-readable medium and executable by an instruction execution system. In the context of the present disclosure, a "computer-readable medium" can be any medium capable of containing, storing, or retaining the logic or application described herein for use by or in connection with an instruction execution system.

[0127] The computer-readable medium may include any one of numerous physical media, such as, for example, magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media would include, but are not limited to, magnetic tape, magnetic floppy disks, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical disks. The computer-readable medium 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, the computer-readable medium 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] Also, any logic or application described herein, including the network slice allocation service 425 and the content distribution service 426, may be implemented or structured in a variety of ways. For example, one or more applications described herein may be implemented as modules or components of a single application. Furthermore, one or more applications described herein may execute on a shared computing device or separate computing devices, or a combination thereof. For example, multiple applications described herein may execute on the same computing device 800 or on multiple computing devices 800 in the same computing environment 403.

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

[0130] Embodiments of the present disclosure can be described by one or more of the following clauses. Clause 1. A system comprising: a wireless network including a radio access network and an associated core network, wherein an application utilizes a network slice of the wireless network to transmit and / or receive network traffic; a network slice allocation service configured to dynamically change the network slice in response to an application programming interface (API) request from the application; and at least one computing device implementing the application, wherein the computing device is configured to: determine that the network slice does not meet at least one of a minimum bandwidth requirement or a minimum delay requirement; 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 requirement;

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

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

[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 communications network; Transmitting, via the at least one computing device, a request to a network slice allocation service to reserve a network slice having the quality of service requirements in the communication network; and transmitting data to and from the application using the network slice via the at least one computing device.

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

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

[0136] Clause 7. The method of clause 6, wherein the duration corresponds to a session of the application.

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

[0138] Clause 9. The method of clauses 4 to 8, further comprising: determining, via the at least one computing device, that the application has increased quality of service requirements; and sending, via the at least one computing device, a subsequent request to the network slice allocation service to change the network slice so that it has the increased quality of service requirements.

[0139] Clause 10. The method of clauses 4 to 9, further comprising: determining, via the at least one computing device, that the application has reduced quality of service requirements; and sending, via the at least one computing device, to the network slice allocation service a subsequent request to change the network slice so that it has the reduced quality of service requirements.

[0140] Clause 11. The method of clauses 4 to 10, 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 transmitting, via the at least one computing device, a subsequent request to the network slice allocation service to reserve a different network slice for the application, wherein the different network slice is associated with a lower quality of service requirement than a default network slice for the particular computing device.

[0141] Clause 12. The method of clauses 4 to 11, wherein the network slice is associated with a shorter delay than a default network slice.

[0142] Clause 13. The method of clauses 4 to 12, wherein the quality of service requirements include a minimum delay requirement for the application.

[0143] Clause 14. The method of clauses 4 to 13, wherein the quality of service requirements include a minimum bandwidth requirement for the application.

[0144] Clause 15. The method of clauses 4 to 14, wherein sending the request to the network slice allocation service to reserve the network slice further includes sending the request 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 described in clauses 4 to 15, wherein sending the request to the network slice allocation service to reserve the network slice further includes sending the request 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-transitory computer-readable medium embodying an application executable in a computing device, the application, when executed, causing the computing device to at least: determine that a network slice in a wireless network does not meet a quality of service requirement of an application; send 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 requirement; and transmit and receive data using the network slice. Clause 18. The non-transitory computer-readable medium of Clause 17, wherein the application, when executed, causes the computing device to at least further send a subsequent request to the network slice allocation service to release the network slice.

[0147] Clause 19. The non-transitory computer-readable medium described in Clauses 17-18, wherein the application, when executed, further causes the computing device to determine at least the duration of the network slice, the duration being in minutes or amounts of data, and the request specifying the duration.

[0148] Clause 20. The non-transitory computer-readable medium of clauses 17 to 19, wherein the application, when executed, further causes the computing device to determine a maximum delay of the network slice, and the request specifies the maximum delay.

[0149] Clause 21. A system comprising: a wireless network including a radio access network and an associated core network, wherein an application utilizes a respective network slice of the wireless network to transmit and / or receive network traffic; and a network slice allocation service configured to at least 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 a quality of service requirement of the network slice; and, in response to the API request, identify a set of network functions from a plurality of available network functions to process data transmitted via the network slice in a manner that satisfies the quality of service requirement of the network slice; and enable the application to use the network slice.

[0150] Clause 22. The system of clause 21, wherein the network slice allocation service is further configured to increase the amount of computing resources implementing the set of network functions so as to meet at least the quality of service requirements of the network slice.

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

[0152] Clause 24. The system described in clauses 21 to 23, wherein the network slice allocation service is further configured to manage at least a plurality of network slices associated with a plurality of different wireless networks of a plurality of customers.

[0153] Clause 25. The system described in clauses 21-24, wherein the network slice allocation service is further configured to allocate network capacity to a plurality of network slices through oversubscription beyond hardware capacity based at least in part on the predicted ability of the plurality of network slices to meet the quality of service requirements.

[0154] Clause 26. The system described in Clauses 21 to 25, wherein the network slice allocation service generates an access token and returns the access token to the application, thereby enabling the application to use the network slice, and the application uses the network slice by presenting the access token.

[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 radio access network and an associated core network to an application connected to the wireless network, the request specifying a set of quality of service constraints required for the network slice; and configuring, via the at least one computing device, 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 a default connection over the wireless network.

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

[0158] Clause 30. The method of clauses 27 to 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 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 at a cell site.

[0159] Clause 31. The method of clauses 27-30, wherein configuring the set of network functions further comprises scaling, via the at least one computing device, an amount of computing resources allocated to at least one network function workload to implement the network slice.

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

[0161] Clause 33. The method of clauses 27-32, wherein configuring the set of network functions further comprises configuring at least one corresponding network function, via the at least one computing device, to prioritize data from the application up to a specified maximum bandwidth or a specified minimum latency.

[0162] Clause 34. The method of clauses 27-33, wherein the request specifies a duration or amount of data within a period, and the method further includes reconfiguring at least one network function workload within 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 of clauses 27-34, wherein the request is received from a backend service associated with the application via an application programming interface (API) call made by the backend service.

[0164] Clause 36. A non-transitory computer-readable medium embodying a network slice allocation service executable within at least one computing device, the network slice allocation service, when executed, causing the at least one computing device to at least: determine to allocate a network slice to an application communicating over a wireless network, the network slice having specified quality of service requirements; 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 scale an 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 system of clause 36, wherein the network slice corresponds to all data transmitted from a client device to a destination on the wireless network.

[0166] Clause 38. A system described in clauses 36-37, wherein the network slice corresponds to all data transmitted from a particular application running on a client device on the wireless network.

[0167] Clause 39. The system described in clauses 36 to 38, wherein the network slice allocation service, when executed, causes the at least one computing device to at least configure the at least one network function in the wireless network to deprioritize other data transmitted via another network slice to meet the specified quality of service requirement of the network slice, the other network slice having a lower quality of service requirement than the specified quality of service requirement.

[0168] Clause 40. The system described in Clauses 36-39, wherein the network slice allocation service, when executed, causes the at least one computing device to at least transfer the workload of at least one 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 meet the specified quality of service requirements of the network slice.

[0169] Clause 41. A system comprising: a wireless network including a radio access network and an associated core network, wherein an application utilizes a respective 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, the network slice having quality of service requirements for a session of the application; determine that operation of the application requires transfer of network-sensitive content through the network slice; determine that without providing the network-sensitive content at an edge location of the wireless network, the network slice will not satisfy the quality of service requirements; and initiate transfer of the network-sensitive content to a content delivery service at the edge location of the wireless network to satisfy the quality of service requirements of the network slice.

[0170] Clause 42. The system of clause 41, wherein the edge location is an edge location of a cloud provider network collocated with equipment of the radio access network.

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

[0172] Clause 44. The system described in Clauses 41 to 43, wherein the program, when executed, causes the at least one computing device to at least further discard the 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: provisioning, via at least one computing device in response to an application programming interface (API) request, a network slice with quality of service requirements in a wireless network having a radio access network and an associated core network; and initiating, via the at least one computing device in response to the API request, a transfer of content to a content delivery service at an edge location of the wireless network 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 a network connection from an endpoint of the network slice to a primary content distribution service does not meet the quality of service requirement; and initiating the content distribution service via the at least one computing device.

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

[0177] Clause 49. The method of 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 distribution service via the at least one computing device.

[0178] Clause 50. The method of clause 49, wherein reallocating the computing capacity at the edge location further includes: terminating, via the at least one computing device, a first machine instance configured to perform the at least one network function on a computing device at the edge location; and launching, via the at least one computing device, a second machine instance configured to host the content delivery service on the computing device at the edge location.

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

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

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

[0182] Clause 54. A non-transitory computer-readable medium embodying a network slice allocation service executable in at least one computing device, the network slice allocation service, when executed, causing the at least one computing device to: receive a request to create a network slice comprising quality of service requirements of an application executing on a client device in a wireless network having at least a radio access network and an associated core network; determine services for which the application communicates using the network slice; and provision computing resources for the services in the wireless network to meet the quality of service requirements.

[0183] Clause 55. The non-transitory computer-readable medium of Clause 54, wherein the network slice allocation service, when executed, further causes the at least one computing device to determine that the network slice would not meet the quality of service requirements without at least provisioning the computing resources.

[0184] Clause 56. The non-transitory computer-readable medium of clauses 54-55, wherein provisioning the computing resources includes launching a machine instance for the service.

[0185] Clause 57. The non-transitory computer-readable medium of clauses 54 to 56, wherein the computing resources are provisioned for the duration of the network slice and released at the end of the network slice.

[0186] Clause 58. The non-transitory computer-readable medium of any one of clauses 54 to 57, wherein at least a portion of the computing resources are provisioned at a cell site where the client device is connected to the wireless network.

[0187] Clause 59. The non-transitory computer-readable medium of clauses 54-58, wherein at least a portion of the computing resources are provisioned at one or more cell sites where the client devices are expected to become connected to the wireless network.

[0188] Clause 60. The non-transitory computer-readable medium of clauses 54 to 59, wherein the service corresponds to a content delivery service that provides content to the application, and provisioning the computing resources further includes caching at least a portion of the content.

[0189] It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the present disclosure. Many variations and modifications may be made to the above-described embodiment(s) without substantially departing from the spirit and principles of the present disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

1. a wireless network including a radio access network and an associated core network; a user equipment (UE) implementing an application; wherein the application comprises at least determining that the application has increased quality of service requirements for sending or receiving data over the wireless network, the increased quality of service being higher than the existing quality of service provided to the application by the wireless network; transmitting a request to allocate capacity of a network slice of the wireless network, the network slice having the increased quality of service requirement, to the application; Transmitting or receiving the data using the network slice The system is configured as follows:

2. The system of claim 1 , wherein the application is further configured to at least receive a user selection of the increased quality of service requirement.

3. The system of claim 1 , wherein the request is sent by the application through a service application programming interface (API) of the wireless network.

4. The system of claim 1 , further comprising a service of the wireless network configured to at least create the network slice in the wireless network in response to the request.

5. The system of claim 1 , further comprising a service of the wireless network configured to reserve at least the capacity of the network slice in the wireless network in response to the request.

6. determining that an application implemented on a particular user equipment (UE) has increased quality of service requirements for transmitting or receiving data over a communications network, the increased quality of service requirements being higher than an existing quality of service provided to the application by the communications network; sending, by the application, to the communications network a request to allocate to the application capacity of a network slice having the increased quality of service requirement; transmitting the data to or from the application using the network slice; 11. A computer-implemented method comprising:

7. 7. The computer-implemented method of claim 6, further comprising dynamically changing quality of service requirements of the network slice to meet performance requirements of the application.

8. 7. The computer-implemented method of claim 6, wherein determining that the application implemented on the particular user equipment (UE) has the increased quality of service requirement further comprises determining that a user of the application has selected the increased quality of service requirement.

9. 7. The computer-implemented method of claim 6, wherein the data includes video data, and determining that the application implemented on the particular user equipment (UE) has the increased quality of service requirement further comprises determining that a user of the application has selected a high priority video stream that has the increased quality of service requirement.

10. The computer-implemented method of claim 6 , wherein the application sends the request through a service application programming interface (API).

11. The computer-implemented method of claim 6 , further comprising creating the network slice in the communications network via a service of the communications network in response to the request.

12. 10. The computer-implemented method of claim 6, further comprising dynamically adjusting, via a service of the communication network, an amount of reserved resources of the network slice of the communication network based at least in part on demand of the application.

13. 7. The computer-implemented method of claim 6, further comprising reserving the capacity of the network slice in the communications network via a service of the communications network in response to the request.

14. 14. The computer-implemented method of claim 13, wherein reserving the capacity of the network slice in the communications network further comprises reserving additional frequency spectrum in a radio access network to accommodate the network slice.

15. determining that an application implemented on a particular user equipment (UE) has quality of service requirements for transmitting or receiving data over a communications network; sending, by the application, a request to dynamically change a network slice of the communication network to have the quality of service requirements; transmitting the data to or from the application using the network slice; 11. A computer-implemented method comprising:

16. 16. The computer-implemented method of claim 15, wherein the data is video data and the quality of service requirement ensures that the video data is not interrupted in the communications network.

17. 16. The computer-implemented method of claim 15, further comprising dynamically adjusting, via a service of the communication network, computing capacity allocated to one or more network functions associated with the network slice of the communication network based at least in part on the demands and the quality of service requirements of the application.

18. 16. The computer-implemented method of claim 15, further comprising determining whether one or more network functions of the network slice are deployed at a customer site or at a data center located remotely from the customer site.

19. allocating additional frequency spectrum in the radio access network to accommodate said network slice; or reserving hardware of the communication network to accommodate the network slice; The computer-implemented method of claim 15 , further comprising at least one of:

20. The computer-implemented method of claim 15 , wherein the application sends the request through a service application programming interface (API) of the communication network.

Images