Managing network function accelerators for wireless-based applications from a virtualized computing service control plane.

Abstract

Respective network addresses are assigned by a control plane server of the virtualized computing service to networking hardware devices and network function accelerators embedded in the offload cards of the virtualization server. Compute instances are launched in the virtualization server using the virtualization controller of the offload cards. The compute instances execute network functions of the wireless-based application in response to requests received using the network addresses assigned to the hardware devices and request execution of a second network function in the accelerator. The results of the second network function are sent to the wireless unit of the application using the address assigned to the accelerator.

Description

Background Art

[0001] In recent years, several generations of broadband cellular communication technologies have been developed. 5G is the fifth-generation technical standard for broadband cellular networks and is gradually replacing the fourth-generation (4G) standard of Long-Term Evolution (LTE). 5G technology significantly increases bandwidth, thereby expanding the cellular market beyond smartphones to provide last-mile connectivity to desktops, set-top boxes, laptops, and Internet of Things (IoT) devices. Some 5G cells employ the same frequency spectrum as 4G, while other 5G cells may employ frequency spectra within the millimeter wave band. Cells within the millimeter wave band may have a relatively small coverage area but can provide much higher throughput than 4G. As 5G technology becomes more widespread, new types of broadband-based applications are likely to be developed and deployed.

Brief Description of the Drawings

[0002] [Figure 1] Illustrate an exemplary system environment in which a virtualized management offload card, according to at least some embodiments, includes a hardware network function accelerator and a virtualized server that can be employed in the execution of a wireless-based application that at least partially uses the resources of the virtualized computing service. [Figure 2] Illustrate an exemplary configuration of a wireless-based application processing server having a partially offloaded virtualized management function, according to at least some embodiments. [Figure 3] Illustrate an overview of a user plane layer and a control plane layer defined according to the technical standard of a wireless-based application, according to at least some embodiments. [Figure 4] Illustrate an exemplary uplink and downlink pipeline of network functions for a wireless-based application, according to at least some embodiments. [Figure 5] This document illustrates exemplary networking functions that may be performed in the physical layer of a wireless-based technology stack, in at least some embodiments. [Figure 6] This illustrates an exemplary hierarchy of devices that may be used for wireless-based applications, in at least some embodiments. [Figure 7] This document illustrates exemplary deployments of L2 implementation programs of wireless-based technology stacks in wireless-based application processing servers, in at least several embodiments. [Figure 8] This document illustrates, in at least several embodiments, the virtualized representation of a hardware network function accelerator for compute instances running on a virtualized server. [Figure 9] This illustrates exemplary network function accelerator configuration management tasks that can be performed by, or initiated by, a control plane server for a virtualized computing service, in at least some embodiments. [Figure 10] This paper illustrates at least some embodiments of workload migration techniques that may be employed for wireless-based applications. [Figure 11] This illustrates exemplary categories of network traffic for wireless-based application processing servers, based on at least several embodiments. [Figure 12] This illustrates exemplary categories of isolated virtual network metadata associated with wireless-based application processing servers, in at least several embodiments. [Figure 13] This illustrates an exemplary category of compute instances that may be configured on behalf of clients of virtualized computing services, in at least some embodiments. [Figure 14] This document illustrates exemplary facilities and sites in which wireless-based application processing servers may be deployed, in at least some embodiments. [Figure 15]This flowchart illustrates modes of operation that may be performed to manage wireless-based applications, including network functions, running in an accelerator embedded within a virtualization management offload card, in at least some embodiments. [Figure 16] This paper illustrates exemplary programmatic interactions relating to wireless-based applications between a client and a provider network service, in at least several embodiments. [Figure 17] This is a block diagram illustrating an exemplary computing device that may be used in at least some embodiments.

[0003] While embodiments are described herein as examples of several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described herein. It should be understood that the drawings and their detailed descriptions are not intended to limit embodiments to any particular form disclosed, but rather to encompass all modifications, equivalents, and substitutions that fall within the spirit and scope defined by the appended claims. Headings used herein are for constituent purposes only and are not intended to limit the scope of the description or claims. Where used throughout this application, the word “may” is used in an acceptable sense (i.e., meaning it may have the potential to include) rather than an essential sense (i.e., meaning it must). Similarly, the words “include,” “including,” and “includes” mean to include but not be limited to. Where used in the claims, the term “or” is used in an inclusive sense (i.e., meaning it may include) rather than an exclusive sense (i.e., meaning it may include). For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof. Unless otherwise explicitly stated, articles such as "a" or "an" should generally be interpreted as including one or more listed items throughout this application. Thus, phrases such as "devices configured to..." are intended to include one or more enumerated devices. Such one or more enumerated devices may also be collectively configured to perform the listed enumerations. For example, "processors configured to perform enumerations A, B, and C" may include a first processor configured to perform enumeration A and a second processor, operating in conjunction with it, configured to perform enumerations B and C. Unless otherwise explicitly stated, the term "set" should generally be interpreted as including one or more listed items throughout this application. Thus, phrases such as "set of devices configured to..." are intended to include one or more enumerated devices.One or more such enumerated devices can also be configured collectively to perform the described enumerated items. For example, “a set of servers configured to perform enumerated items A, B, and C” could include a first server configured to perform enumerated item A, and a second server operating in conjunction with it, configured to perform enumerated items B and C. [Modes for carrying out the invention]

[0004] This disclosure relates to a method and apparatus for running wireless-based applications using a virtualization server comprising an offload card including network function accelerator hardware, a virtualization management component, and networking hardware devices. Such a virtualization server may also be referred to as a wireless-based application processing server or RPS. Such an RPS may, in some examples, be managed by a cloud provider and may be based on a server design used by the cloud provider in the network, thereby including one or more primary processors that run customer compute instances and an offload card that runs at least a portion of a virtualization controller that manages the startup of compute instances on the virtualization server. The Network Function Accelerator (NFA) of the RPS can be used to implement some of the functions of various radio-based or telecommunications applications (e.g., various types of broadband cellular applications such as private 5G (fifth-generation) networks, IoT (Internet of Things) based applications, and public 5G applications). In some examples, the NFA can perform certain L1 (or PHY) functions of the Radio Access Network ("RAN") protocol stack, also known as real-time baseband processing. The control plane server of the Virtualized Computing Services (VCS) can communicate with the virtualization management component on the offload card via the networking hardware device to initiate various types of management tasks on the server, including, for example, starting or stopping compute instances or virtual machines. The offload card can help reduce the workload on the primary processor (e.g., CPU) of the virtualization server in at least two ways: by performing some of the virtualization tasks that would otherwise be performed on the primary processor, and by performing at least some of the network functions of radio-based applications that would also otherwise be performed on the primary processor.Furthermore, NFAs can perform at least some network functions faster than they could using a primary processor, for example, by using a custom chipset specifically designed for networking functions. For example, an NFA could include a hybrid of digital signal processors (DSPs) and advanced RISC machine (ARM) cores optimized for L1 processing tasks.

[0005] Integrating an NFA into a Virtualization Management Offload Card (VMOC) also enables the control plane server to perform many of the configuration operations necessary to manage the NFA, such as deploying firmware to the NFA, assigning networking addresses that can be used for fronthaul and midhaul traffic of radio-based applications (RBAs) that use the NFA for network functions, and providing isolated virtual network (IVN) functions such as security groups and customizable routing for the NFA. In contrast to an alternative approach where an NFA card embedded in a larger server design can be accessed in a non-virtualized manner from bare-metal compute instances, an NFA embedded within a Virtualization Management Offload Card (VMOC) can be presented in a virtualized form to multiple compute instances running on the RPS, thereby simplifying the network slicing of the RBA. The control plane server is located in the data center of the cloud provider network, while the RPS itself can be located in a facility selected by the RBA owner, for example, based on proximity to cell towers or antennas, enabling the low latency required for high-end telecommunications applications such as 5G (fifth-generation) applications.

[0006] As a person skilled in the art would understand in light of this disclosure, certain embodiments may be capable of achieving a variety of benefits, including some or all of the following: (a) enabling new wireless-based applications to be brought online quickly and maintained using the provider network's proven resource provisioning, scalability, and availability techniques; (b) reducing the computing, memory, storage resources, and power used for wireless-based applications by, for example, intelligently distributing and / or migrating workloads at varying levels of granularity across available resources and sharing resources among multiple applications; and / or (c) improving the user experience for administrators of wireless-based applications by simplifying application management and administration using provider network tools and interfaces.

[0007] According to some embodiments, the system may comprise a set of one or more control plane servers (CPS) of a cloud provider network's VCS, and a virtualization server comprising one or more primary processors (e.g., CPUs) and an offload card. The offload card may comprise (a) a virtualization controller for compute instances launched on the virtualization server, (b) at least one NFA for wireless-based applications, and (c) at least one networking hardware device (NHD). In some implementations, the offload card may be linked to the primary processor via a peripheral interface such as a Peripheral Component Interface-Express (PCIe) interface, a Universal Serial Bus (USB) interface, or a custom peripheral interface designed by the provider network operator. In some embodiments, the offload card may comprise one or more memory and one or more processors, the memory or memory storing instructions that, when executed on the processors, implement communication-related tasks performed using the logic of the virtualization controller, the NFA, and the NHD. For example, when an instruction in offload card memory is executed in the offload card's processor, it may either use NHD to transmit a message or process the contents of a message received via NHD.

[0008] As part of their management responsibilities, the CPS set may assign several network addresses used by the components of the virtualization server. For example, network addresses within the VCS's underlying network (the underlying physical network on which virtual networks can be built) may be assigned to the NHD. The underlying network may be used for communication with resources in the cloud provider network outside the virtualization server. The CPS set may also, with the help of the virtualization controller, assign second network addresses to compute instances launched in the virtualization server. The second network addresses may not be part of the underlying network, but instead, in some embodiments, may be selected from a range of addresses in an isolated virtual network (IVN) or virtual private cloud (VPC). In various embodiments, a virtual network interface (VNI) managed by the CPS set may be programmatically attached to the compute instance in order to assign the second network address to the compute instance, and the second network address may be assigned to the VNI. Furthermore, the CPS set may also, in some embodiments, assign a third network address to the NFA used for communication between the NFA and one or more radio units (RUs) of a radio-based application (RBA). When running on the virtualization server's primary processor, the virtualization server may store instructions that cause the compute instance to execute a first network function of the RBA in response to messages received by the compute instance (for example, from an RBA component running on several other compute instances in another virtualization server). In some embodiments, the messages may be received using a mapping between the network address assigned to the compute instance and the underlying network address. Such a mapping may be employed as part of the encapsulation protocol used by the VCS for translation between the physical address of the underlying network and the address assigned to the compute instance in the virtualization network.Based at least in part on the results of the first network function, a second network function of the RBA may be performed in the NFA in at least one embodiment. The output of the second network function may be transmitted to the RU of the RBA using a third network address assigned as the source address by the CPS. Note that in some embodiments, a single network address assigned to a particular NHD in the on / offload card may be used for several different types of traffic, including, for example, fronthaul and midhaul traffic of the RBA. In one implementation, the NHD may have several network ports, each of which may be used for a different type of traffic.

[0009] Network functions are functional building blocks within a network infrastructure, possessing clearly defined external interfaces and clearly defined functional behaviors. Network functions can be linked together to form communication services. Historically, network functions have been implemented as physical network appliances or nodes, but they can also be virtualized. The core and RAN (Radio Access Network) network functions referenced herein can, in some implementations, be at least partially based on Third Generation Partnership Project (3GPP®) standards, European Telecommunications Standards Institute (ETSI) standards, and / or other wireless communication standards. RAN network functions are used in wireless networks, typically running in cell towers, and perform the conversion of radio signals to IP (Internet Protocol). Core network functions typically run in large data centers, executing subscriber-related business logic and routing IP traffic to and from the internet. According to this disclosure, both core and RAN network functions can be additionally or alternatively run on radio-based application processing servers (RPSs) provisioned as virtualized servers by a cloud provider, for example, on edge devices provisioned to customers to implement private 5G networks, or on edge devices used by radio service providers or cloud providers to create public 5G networks. The term “radio-based application” (RBA) is used herein to refer to applications in which at least several messages are transmitted using radio frequency signals and associated antennas, such as those used in various generations of cellular broadband technology (4G, 5G, etc.). RBPAS may also be referred to as radio access network (RAN) pipeline processing servers, RAN servers, RAN application servers, or radio-based application servers.It should be noted that the techniques described herein are not limited to any particular generation of cellular broadband, nor are they limited to applications that utilize any particular portion of the electromagnetic spectrum for message transmission.

[0010] Network functions performed in the compute instances of the virtualized server may, for example, be part of the distributed unit (DU) of the 5G radio technology stack used by the RBA in some embodiments. Some network functions performed in the NFA may, in at least one embodiment, be part of the physical layer, also referred to as L1 (layer 1) of the RBA. Such physical layer network functions may include, among other things, coding functions, rate matching functions, scrambling functions, modulation layer mapping functions, precoding functions, resource mapping functions, digital beamforming functions, fast Fourier transform (FFT) functions, cyclic prefix insertion functions, cyclic prefix removal functions, inverse FFT functions, demapping functions, channel estimation functions, prefiltering functions, equalization functions, demodulation functions, descrambling functions, rate inverse matching functions, or decoding functions.

[0011] In addition to assigning network addresses, the CPS may also, in various embodiments, perform a variety of other management tasks for the NFA embedded within the offload card of the virtualization server. For example, the CPS may install and run firmware or software on the NFA of the offload card and apply updates, including security patches, to the firmware or software. In at least some embodiments, the CPS may monitor the health status of the NFA, for example, by testing the NFA's responsiveness to messages transmitted by the CPS, and may provide a representation of the health status to VCS clients using the NFA via a programmatic interface. Performance metrics of the NFA, such as the total number of RBA messages processed or the execution of network functions, may be collected and analyzed in the CPS in some embodiments, and a representation of the performance metrics may be presented to VCS clients via a programmatic interface. In some embodiments, the CPS may, as needed, scrub or clean up the memory of the NFA after a particular computing instance that was using the NFA has finished, and before another computing instance that intends to use the NFA is started, so that data stored in the NFA memory during the lifetime of that particular computing instance is inaccessible to other computing instances.

[0012] According to at least some embodiments, each virtualized representation of an NFA on an offload card may be presented to one or more compute instances running on a virtualization server. This may allow several network functions of each RBA or wireless-based application pipeline to run on compute instances, with each RBA utilizing the same shared NFA hardware for other network functions. Requests for the use of NFA hardware may be submitted via and received by the NFA using a programmatic interface of the virtualized representation. NFA virtualization may allow network slicing to be implemented on the virtualization server while different wireless-based applications or pipelines are running on each of the compute instances and NFAs. A virtualized representation of an NFA, which may be referred to as a VNFA, may allow each compute instance to utilize the shared NFA hardware via a programmatic interface as if it had exclusive access to the NFA hardware, similar to how virtualized representations of other hardware devices on the virtualization server (such as virtualized CPUs or virtualized I / O hardware devices) allow compute instances to utilize those devices as if they were available for exclusive use.

[0013] According to some embodiments, the CPS can orchestrate the migration of at least a portion of the RBA's workload from one virtualization server (referred to as the source) to another virtualization server (the destination). The destination may, for example, include its own NFA within its own offload card. As a result of the migration, (a) messages from the RBA's RUs may be delivered to and processed by the destination NFA instead of the source NFA, and (b) the migrated version of the compute instance may perform other networking functions of the RBA at the destination.

[0014] In at least one embodiment, the system may comprise one or more CPSs of a cloud provider network VCS and a virtualization server including an NFA. The CPS may, for example, establish an isolated virtual network (IVN) on behalf of a client of the VCS in response to a program request from the client. The IVN, also referred to as a virtual private cloud (VPC), may comprise a set of resources that are logically isolated or separate from the rest of the resources of the VCS with respect to at least some types of networking configuration settings. For example, a given IVN may comprise one or more subnets, each with a security setting chosen by the client, and / or a set of Internet Protocol (IP) addresses chosen by the client and assigned to compute instances or other entities configured within the IVN.

[0015] In various embodiments, the CPS may store in the IVN metadata repository a representation of a first security group associated with a compute instance launched on the virtualization server in response to a first request submitted by a client via the VCS programmatic interface. The security group may, in various embodiments, include a set of network security rules. The compute instance may be assigned a first network address within the IVN, and the first security group may use the network address to include restrictions on the source of inbound traffic directed to the compute instance (and / or restrictions on outbound traffic from the compute instance). The compute instance may include software configured to perform a first network function of the RBA. The CPS may also store in the repository a representation of a second security group or security rule set associated with the NFA in response to a second request submitted via the programmatic interface. The second security group may include restrictions on the destination of outbound traffic from the network function accelerator (and / or restrictions on the sources from which traffic can be accepted by the NFA). In some embodiments, the CPS may assign network addresses within the IVN to the NFA and use them for communication between the NFA and the RU. The NFA may perform a second network function of the RBA.

[0016] Before delivering the first network message of the RBA to the computing instance using the first network address as the destination address, the CPS may cause verification that the first network message complies with the restrictions of the first security group. In some embodiments, the first network message may trigger the execution of the first network function. The CPS may also cause verification that the second network message of the RBA complies with the restrictions of the second security group before delivering the second network message of the RBA to a destination such as an RU of the RBA from the NFA. In at least some embodiments, the NFA may be incorporated within an offload card of the type described above, which also includes one or more virtualization management components and one or more networking hardware devices (NHDs). The computing instance may be launched on a virtualized server using the virtualization management component of the offload card, and the board address is assigned to the NHD by the CPS. Additional configuration settings for the computing instance and / or the NFA may also be stored by the CPS.

[0017] In some embodiments, the CPS may enforce traffic rate limits or traffic shaping rules on the NFA. For example, the CPS may determine a rate limit applied to network messages directed to or from the NFA based on, for example, program requests from a VCS client for which the NFA is being used instead, and may drop packets directed to or from the NFA if packet delivery would cause a violation of the rate limit. Such rate limits may be stored as part of a set of configuration settings maintained by the CPS.

[0018] In some embodiments, route table entries for midhaul traffic (traffic between distributed units (DUs) and centralized units (CUs)) of an RBA utilizing an NFA may be stored by the CPS. In such embodiments, at least some messages of midhaul traffic may be generated in the compute instance, and in other embodiments, some midhaul traffic messages may be generated in the NFA. Each separate security group or security rule set may be stored for fronthaul traffic and midhaul traffic in some embodiments. In one embodiment, the CPS may assign a network address within the IVN to the NFA, which may be used for communication between the NFA and the RU. According to at least one embodiment, in addition to, or instead of using security groups that define inbound and outbound traffic restrictions, a VCS client may decide to manage traffic security using network access control lists (ACLs), and the ACLs selected by the client may be stored and enforced by the CPS. In one embodiment, messages directed to compute instances running on the RPS may be formatted according to the Internet Protocol (IP), while different protocols (such as the Common Public Radio Protocol (CPRI) or Extended CPRI (eCPRI)) may be used for at least some messages exchanged between the RU and the NFA. In some implementations, CPRI or eCPRI messages may be transmitted via IP (e.g., using an encapsulation protocol).

[0019] According to various embodiments, the server may include a processor, a memory, and an offload card. The offload card may include a virtualization manager or virtualization controller, and an NFA for the RBA. The virtualization manager may execute one or more configuration tasks regarding a compute instance launched on the server, including allocation of at least a portion of the memory used by the compute instance. The memory may store instructions that, when executed by the processor, execute a first network function of the RBA on the compute instance and cause a second network function of the RBA to be executed by the NFA. The input of the second network function may be at least partially based on the output of the first network function. For example, the instructions may cause the output of the first network function to be provided as an input to the second network function executed by the NFA when executed on the processor.

[0020] In some embodiments, the offload card may include a networking hardware device (NHD) to which an address of the VCS's substrate network may be assigned. The networking hardware device may be used to transmit messages of the RBA from a compute instance running on the server to other compute instances running on other servers. In one embodiment, the messages may be transmitted by a network processing offloader operating on the offload card using the NHD. In some embodiments, multiple NHDs may be incorporated within the offload card, and one of the NHDs may be used to transmit (and receive messages from) a first set of destinations including the RBA's central unit (CU), while another NHD may be used to transmit (and receive messages from) a second set of destinations including the RBA's radio unit (RU). In one embodiment, addresses within a range of addresses selected for the IVN may be assigned to the NHD used for RU communication.

[0021] According to several embodiments, multiple NFAs may be incorporated within an offload card, with each NFA employed to execute each set of network functions of one or more RBAs. In some cases, different network functions of a single RBA may be executed by each NFA on the card. In other cases, each NFA on the card may be employed to execute the network functions of each application. In one embodiment, instructions executed by the CPU may cause each network function executed by each NFA to receive different sets of inputs (e.g., outputs generated by each network function executed by each compute instance of the virtualization server). In one embodiment, the virtualized representation of the NFA may be presented to each compute instance started on the server, allowing requests for accelerated network functions from each compute instance to be received independently of each other by the NFA (using programmatic interfaces provided as part of each virtualized representation). In various embodiments, the VCS's CPS may perform management tasks for the NFA, including installing and updating firmware / software on the NFA. In some embodiments, the network functions performed in a given NFA may, in addition to or instead of performing the types of physical layer network functions listed above, implement RAN nodes (e.g., gNodeB or eNodeB) or a portion of a distributed unit (DU), a portion of a centralized unit (CU), and / or a portion of the core network of an RBA.

[0022] In some embodiments, the virtualization server used as the RPS may be configured as part of an Extended Resource Group (ERG) of the cloud provider network, configured in a facility outside the primary data center of the provider network where the control plane server is located. The ERG may be located near a cell tower or set of antennas, for example, in response to requests from VCS clients wishing to run radio-based applications on resources managed by the VCS control plane. In other embodiments, the RPS may be configured in a local zone, a third-party data center, and / or a data center of the provider network. In some embodiments, a given ERG may share several management resources among its member servers, such as the local agent of the VCS control plane. In at least some embodiments, the server used for the ERG may be configured by a provider network operator with appropriate hardware (e.g., including network function accelerator cards), software, and firmware, and then shipped to the facility where the ERG is utilized. In some embodiments, at least some of the servers, such as RPSs, may require relatively little physical space (for example, some RPSs supplied by a provider network operator may occupy only one rack unit (1U) or a few rack units in a standard data center rack). In at least some embodiments, an RPS configured as part of an ERG or operating in a facility outside the provider network's data center may include several hardware, software, and / or firmware elements specifically designed to enable the safe and secure execution of remotely generated virtualization-related management commands without requiring the command to send messages back to the source from which it was originally issued.In some embodiments, such elements may include a Trusted Platform Module (TPM) or other security modules embedded within an offload card, a tamper-proof storage device whose contents can be decrypted as long as the storage device is physically attached to a particular RPS. In at least some embodiments, such an RPS may include a VCS control plane agent that does not make outbound calls and implements an API for inbound commands protected using a TLS (Transport Layer Security) session. Such an API may have strong authorization, authentication, and accounting-related controls in various embodiments. In at least some embodiments, shared secrets associated with virtualization management may not be stored within the RPS itself.

[0023] In some embodiments, a secure network channel, such as a virtual private network (VPN) tunnel or VPN connection, may be established between the RPS and resources located within the provider network data center, and such a channel may be employed to send commands from the VCS to the RPS. For example, each one-way secure network channel may be used to transmit commands initially generated at the control plane server in response to client requests (including requests to invoke RCI) for final execution at the RPS. In one embodiment, the secure channel used for such commands may be established between one or more resources in the RPS (such as a VCS connection manager) and one or more resources in the IVN of a client for which RCI should be invoked at the RPS at its request.

[0024] An RPS can function as a source or destination for several different types of IP traffic, including traffic between different layers of the wireless-based technology stack used in an RBA, traffic to and from other resources within the provider network, traffic to and from resources within the client network established at the client facility, and traffic to and from the public internet. A given RPS can be equipped with several different types of networking hardware devices (NHDs) that can be employed for IP traffic, including, for example, a default network interface card, a networking chipset in an NFA, and a networking chipset in a virtualization management offload card. Using network management logic provided by the provider network, the most appropriate NHD to be used for a given category of IP traffic on the RPS can be intelligently selected during a given time interval, thus enabling the RPS to make the most of its available IP networking resources in order to achieve quality of service objectives for applications running on the RPS. For example, depending on the type of RBA being run, a different NHD may be used for fronthaul traffic of a wireless-based application for at least a certain period of time than the one used for midhaul traffic. Software programs that implement parts of the RBA (e.g., programs developed by third-party vendors or provider network operators) can run within a runtime environment (RTE), such as a wireless optimization compute instance or wireless optimization software container in the RPS. In some embodiments, a given RPS or NFA may be employed in several different RBAs or pipelines, for example, on behalf of a single client or different clients of the provider network. As a result of such multi-tenancy, the overall amount of computing resources and / or power consumed for several different RBA implementations can be substantially reduced.The reduction in resources used, which can lead to lower costs, will in turn enable new entrants into the wireless-based application space and the design of new types of applications.

[0025] According to some embodiments, the provider network may include a Radio-Based Application Management Service (RBAMS) that implements a programmatic interface for configuring RPSs. Indicators of the expected geographical distribution of end-user requests for radio-based applications (e.g., mobile phone calls, text messages, inbound and outbound messages from IoT sensors) may be obtained by the RBAMS via such a programmatic interface. Information regarding geographical distribution may be used by the RBAMS to select or recommend one or more facilities where one or more categories of ERGs and / or RPSs supported by the provider network should be configured for the client. If the client indicates approval of the recommendation, one or more RPSs may be configured on behalf of the client at such facilities in such embodiments and assigned to the client's application by the RBAMS. Facilities may include, for example, point-of-presence sites of the provider network, local zone facilities of the provider network, or client-owned facilities.

[0026] In one embodiment, a given Network Function Accelerator (NFA) (or a portion of an NFA) on an offload card may be configured for exclusive use for a single client of a provider network (or a single wireless-based application for a client running multiple wireless-based applications), for example, in response to a single-tenancy request from a client. In some embodiments, multiple NFAs of a single RPS (e.g., on a single offload card) may be employed for a single wireless-based application. In other embodiments, each NFA of a given offload card may be employed for its respective RBA. In one embodiment, an NFA may be configured to be used as a backup to other NFAs, for example, in response to the detection of a failure or overload in another NFA. In some embodiments, one or more NFAs of an RPS may be incorporated into a virtualization management offload card that also includes a virtualization management component, while one or more additional NFAs of an RPS may be incorporated into other cards that do not include a virtualization management component.

[0027] In at least some embodiments, various metrics may be collected from the NFA (e.g., by a control plane server of the VCS or RBAMS) and provided to the client via a programmatic interface as needed. Such metrics may include, in different embodiments, inbound or outbound message transfer counts or message transfer rates, NFA failure rates, local processor utilization levels, memory, and other NFA resources. In one embodiment, metrics from multiple NFAs in the RPS (e.g., resource utilization information) may be collected and used to select which particular NFA should be used to perform a specific network function.

[0028] As mentioned above, in some embodiments, the RPS may be configured using at least partially the resources of the provider network. The cloud provider network (sometimes simply referred to as the “cloud”) refers to a pool of network-accessible computing resources (such as compute, storage, and networking resources, applications, and services), which may be virtualized or bare metal. The cloud can provide convenient on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adapt to variable loads. Thus, cloud computing can be viewed as both applications delivered as a service over a publicly accessible network (e.g., the internet or a cellular communication network) and the hardware and software within the cloud provider data center that provides those services.

[0029] A cloud provider network may include a physical network referred to as the "board" (e.g., sheet metal boxes, cables, rack hardware). The board can be considered a network fabric containing the physical hardware that runs the provider network's services, and may include networking devices such as routers, switches, and network address converters (NATs), as well as the physical connections between these devices. The board may be logically isolated from the rest of the cloud provider network, and it may be impossible, for example, to route from board network addresses to addresses in the production network running the cloud provider's services, or to customer networks hosting customer resources.

[0030] A cloud provider network may also include an overlay network of virtualized computing resources operating on the infrastructure (e.g., data objects such as compute instances, block storage volumes, snapshots, and machine images, file storage, databases). In at least some embodiments, a virtualization management component such as a hypervisor or other device or process on the network infrastructure may use encapsulation protocol techniques to encapsulate and route network packets (e.g., client IP packets) on the network infrastructure between client resource instances on different hosts within the provider network. Encapsulation protocol techniques may be used on the network infrastructure to route encapsulated packets (also referred to as network infrastructure packets) between endpoints on the network infrastructure via overlay network paths or routes. Encapsulation protocol techniques can be considered to provide a virtual network topology overlaid on the network infrastructure. Thus, network packets can be routed along the infrastructure network according to constructs (e.g., IVNs, security groups) within the overlay network. Mapping services can coordinate the encapsulation and routing of these network packets. The mapping service can be a region-distributed lookup service that maps combinations of overlay IP and network identifiers to substrate IP, allowing distributed substrate computing devices to determine where packets are sent.

[0031] For example, each physical host may have an IP address within the underlying network. Hardware virtualization technology can, for example, enable the simultaneous execution of multiple operating systems on a host computer as virtual machines or compute instances on the host. A hypervisor, i.e., a virtual machine monitor, running on the host (or on an offload card attached to the host), monitors the execution of virtual machines by allocating the host's hardware resources among various compute instances on the host. Each compute instance may be provided with one or more IP addresses within the overlay network, and the virtual machine monitor on the host may be aware of the IP addresses of the compute instances on the host. The virtual machine monitor (and / or other devices or processes on the network infrastructure) may use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) on the network infrastructure between virtualized resources on different hosts within the cloud provider network. Encapsulation protocol technology may be used on the network infrastructure to route encapsulated packets between endpoints on the network infrastructure via overlay network paths or routes. Encapsulation protocol technology can be considered to provide a virtual network topology overlaid on the network infrastructure. Encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (public IP addresses) to underlying IP addresses (private IP addresses), which can be accessed by various processes on the cloud provider network to route packets between endpoints.

[0032] A cloud provider network can be formed as several regions, where a region is a distinct geographical region where the cloud provider clusters its data centers. Such regions may also be referred to as provider network-defined regions, as their boundaries may not necessarily coincide with national, state, or other similar boundaries. Each region may contain two or more availability zones connected to one another via a private high-speed network, such as fiber optic communication connections. An availability zone (also known as an availability domain, or simply a “zone”) refers to an isolated failure domain containing one or more data center facilities having separate power, separate networking, and separate cooling from those in other availability zones. A data center refers to a physical building or enclosure that houses the servers of the cloud provider network and provides them with power and cooling. Preferably, availability zones within a region are located far enough apart from each other that the same natural disaster should not bring two or more availability zones offline simultaneously. Customers can access the availability zones of the cloud provider network via a transit center (TC) through a publicly accessible network (e.g., the internet, cellular communication networks). A TC can be considered the primary backbone location linking the customer to the cloud provider network, juxtaposed with other network provider facilities (e.g., Internet service providers, telecommunications providers), and securely connected to availability zones (e.g., via VPN or direct connection). Each region may operate two or more TCs for redundancy. As described herein, customers may also connect to availability zones of the cloud provider network via RAN-enabled edge locations managed by the cloud provider, which may then have a direct connection to the cloud provider network (e.g., a private fiber connection between customer facilities and cloud provider facilities) or enter the cloud provider network via a TC through other intermediate networks (e.g., the internet).Each region is connected to a global network that connects each region to at least one other region. The cloud provider network can deliver content from points of presence outside these regions, via edge locations and regional edge cache servers (points of presence, i.e., PoPs), but can also be networked with these regions. This segmentation and geographical distribution of computing hardware enables the cloud provider network to provide customers with low-latency resource access on a global scale with high fault tolerance and stability.

[0033] Edge locations (or “edge zones”), as referred to herein, can be structured in several ways. In some implementations, an edge location may be an extension of the cloud provider network infrastructure containing a limited amount of capacity delivered outside of availability zones (e.g., within a small data center or other facility of the cloud provider, located near customer workloads and far from any availability zone). Such an edge location may be referred to as a local zone (due to being more local to or close to a group of users than a traditional availability zone). A local zone may be connected to a publicly accessible network, such as the internet, in various ways, for example, directly, via another network, or via a private connection to a region. Typically, a local zone will have more limited capacity than a region, but in some cases, a local zone may have substantial capacity, e.g., thousands or more racks. Some local zones may use infrastructure similar to that of a typical cloud provider data center.

[0034] In some implementations, an edge location can be an extension of the cloud provider network infrastructure formed by one or more servers located on-premises within a customer or partner facility, where such servers communicate with nearby availability zones or regions in the cloud provider network via a network (e.g., a publicly accessible network such as the internet). This type of infrastructure extension located outside the cloud provider network data center may be referred to as an "outpost" of the cloud provider network, or a VCS extension resource group. Some outposts may be integrated into the communications network as a multi-edge cloud with physical infrastructure extending across, for example, telecommunications data centers, telecommunications aggregation sites, and / or telecommunications base stations within the telecommunications network. In the on-premises example, the limited capacity of the outpost may be available only for use by the customer who owns the facility (and other accounts permitted by the customer). In the telecommunications example, the limited capacity of the outpost may be shared among several applications (e.g., games, virtual reality applications, healthcare applications) that transmit data to users of the telecommunications network.

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

[0036] As mentioned above, some cloud provider networks may offer support for a type of infrastructure deployment for local zones, where some of the provider network's compute, storage, database, and other select services are located near large population, industrial, and IT centers, or other desired locations, which may not be very close to the provider network's primary data centers. In such local zones, applications requiring single-digit millisecond latency can run closer to specific geographically end users. Local zones provide high-bandwidth, secure connectivity between local workloads and workloads running in the provider network region, enabling provider network clients to seamlessly connect to other workloads running in that region and the full range of intra-region services through the same APIs and toolset.

[0037] A cloud provider network may implement a variety of computing resources or services, including virtual computing services, data processing services (e.g., map reduction, data flow, and / or other large-scale data processing techniques), data storage services (e.g., object storage services, block-based storage services, or data warehouse storage services), and / or any other types of network-based services (which may include various other types of storage, processing, analysis, communication, event handling, visualization, and security services). The resources required to support the operation of such services (e.g., computing and storage resources) may be provisioned to accounts associated with the cloud provider, as opposed to resources requested by users of the cloud provider network, which may be provisioned to user accounts.

[0038] Various network-accessible services may be implemented in one or more data centers of a provider network in different embodiments. Network-accessible computing services may include elastic computing cloud services (referred to in various implementations as elastic computing services, virtual machine services, computing cloud services, computing engines, virtualized computing services (VCS), or cloud computing services). This service may provide virtual computing instances (also referred to as virtual machines, or simply “instances”) with various computing and / or memory resources, managed by a computing virtualization service (referred to in various implementations as elastic computing services, virtual machine services, computing cloud services, computing engines, or cloud computing services). In one embodiment, each virtual computing instance may correspond to one of several instance types or families. An instance type may be characterized by its hardware type, computing resources (e.g., the number, type, and configuration of central processing units [CPU] or CPU cores, NFAs or other accelerators), 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 of its network interface and / or network capabilities), and / or other preferred descriptive characteristics (such as “burstable” instance types with baseline performance guarantees and the ability to periodically burst above that baseline, non-burstable or dedicated instance types with fixed amounts of resources allocated and guaranteed, or instance types optimized for wireless-based applications). Each instance type may have a specific ratio of processing, local storage, memory, and networking resources, and different instance families may also have different types of these resources. Multiple sizes of these resource configurations may be available within a given instance type.Using the instance type selection feature, the instance type may be selected for a customer based, for example, on customer input (at least partially). For example, a customer may choose an instance type from a predefined set of instance types. As another example, a customer may specify the desired resources for the instance type and / or the requirements of the workload on which the instance will run, and the instance type selection feature may select an instance type based on such specifications. A suitable host for the requested instance type may be selected based, at least partially, on factors such as collected network performance metrics and resource utilization levels across different available hosts.

[0039] Provider network computing services may also include container orchestration and management services (referred to in various implementations as container services, cloud container services, container engines, or container cloud services). A container represents a logical package of a software application that abstracts the application from the computing environment in which it runs. For example, a containerized version of a software application includes the software code and any dependencies used by the code so that the application can be consistently run on any infrastructure hosting a suitable container engine (e.g., Docker® or Kubernetes® container engine). Compared to a virtual machine (VM) that emulates an entire computer system, a container represents a lighter package for running an application on a host computing system, virtualized at the operating system level. An existing software application can be “containerized” by packaging the software application in a suitable manner and generating other artifacts (e.g., container images, container files, or other configurations) used to enable the application to run on a container engine. In some implementations, a container engine can run on a virtual machine instance, selecting it based at least in part on described network performance metrics. RBA components may run using containers in at least some embodiments. In some embodiments, other types of network-accessible services, such as packet processing services, database services, and wide-area networking (WAN) services, may also be implemented on the cloud provider network.

[0040] In various embodiments, the traffic and operations of a cloud provider network can be broadly subdivided into two categories: control plane operations, which are carried through a logical control plane, and data plane operations, which are carried through a logical data plane. The data plane represents the movement of user data through a distributed computing system, while the control plane represents the movement of control signals through a distributed computing system. The control plane generally includes one or more control plane components, which are distributed across one or more control servers and implemented by one or more control servers. Control plane traffic generally includes management operations such as system configuration and management (e.g., resource allocation, hardware capacity management, diagnostic monitoring, or system state information management). The data plane includes customer resources implemented on the cloud provider network (e.g., computing instances, containers, block storage volumes, databases, or file storage). Data plane traffic generally includes non-management operations such as transferring customer data to and from customer resources. Certain control plane components (e.g., Layer 1 control plane components such as a control plane for virtualized computing services) are typically implemented on a separate set of servers from the data plane servers, while other control plane components (e.g., Layer 2 control plane components such as analytics services) may share virtualized servers with the data plane, and control plane traffic and data plane traffic may be transmitted through separate / individual networks.

[0041] Figure 1 illustrates an exemplary system environment in which, in at least some embodiments, a virtualization server including a virtualization management offload card and a hardware network function accelerator may be employed to run a wireless-based application that at least partially uses the resources of a virtualization computing service. As shown, system 100 includes a control plane server 140, and resources and artifacts of a virtualization computing service (VCS) 110, which includes a set of virtualization servers including Category A virtualization servers, Category B virtualization servers, and Category C virtualization servers. In the embodiments described, the virtualization server categories may differ from one another in the type of virtualization management offload card (VMOC) included in the servers of each category, and / or in the primary processor (CPU), memory, and other resources included in the server, and therefore may be used for different types of applications. For example, in the embodiments described, the enhanced wireless application VMOC (EVMOC) 118 of the Category A virtualization server 150 may include a Type A Network Function Accelerator (NFA) 172, the EVMOC 119 of the Category B virtualization server 152 may include a Type B NFA 177, and the baseline VMOC 166 of the Category C virtualization server 182 may not include any NFA. The NFAs 172 and 177 may differ in the types of network functions they can accelerate, the speed at which they can perform certain types of network functions, and the vendor that developed the chipset used for the NFA. As a result of the differences in the nature of each NFA, a Category A virtualization server may be better suited to one class of wireless-based applications, and a Category B virtualization server may be better suited to different classes of wireless-based applications. A Category C virtualization server may be suitable for general-purpose applications that do not require hardware acceleration of network functions. In various embodiments, both Category A and Category B virtualization servers with NFAs may be referred to as wireless-based application processing servers or RPSs.

[0042] Each of the virtualization servers in the categories shown in Figure 1 can be used to run compute instances (CIs) on behalf of VCS clients. Some compute instances running on Category A or Category B virtualization servers may include programs that implement one or more network functions of a wireless-based application and may therefore be referred to as wireless-optimized compute instances (RCIs). Network functions that run in an RCI using the primary processor of a virtualization server may differ from network functions that run in an NFA; for example, network functions that run in an RCI may belong to a different layer of the wireless-based application technology stack than network functions that run in the server's NFA. In Figure 1, RCI 125A may run on Category A virtualization server 150, and RCI 125B may run on Category B virtualization server 152. Compute instance CI 129, which may not include a program that implements an RBA, may run on Category C virtualization server 182 in the embodiment depicted. In some cases, compute instances implementing one or more RBA networking functions may run on a virtualization server that does not include an NFA (such as a Category C virtualization server). In such cases, the networking functions may run using the virtualization server's primary processor and may not require hardware accelerators such as an NFA. In some embodiments, one or more RBA networking functions may run on the virtualization server's NFA, but not necessarily on the virtualization server's primary processor.

[0043] Compute instances may be started on the virtualization server in response to commands sent from a control plane server 140, such as an instance state manager 102, in the embodiments described. The EVMOC or VMOC may, in some embodiments, include an offloaded virtualization controller (OVC), also referred to as a virtualization manager or virtualization coordinator, to which commands may be sent from the control plane as part of the process of starting compute instances. For example, EVMOC 118 includes OVC 173A, EVMOC 119 includes OVC 173B, and baseline VMOC 166 includes OVC 173C. In various embodiments, the OVC may perform various virtualization tasks, such as starting other virtualization management components, including on-server virtualization management components 126a, 126b, or 126c, which run on the server's primary processor, and allocating a portion of the virtualization server's main memory for use by individual compute instances.

[0044] EVMOC and VMOC may also include one or more networking hardware devices (functionally similar to network interface cards or NICs), such as EVMOC118, EVMOC119, and NHD174A, NHD174B, and NHD174C in the baseline VMOC166, respectively. NHDs may be used to transmit network messages to virtualization servers, including messages to the control plane server 140, messages to other virtualization servers, and messages to other provider network services such as storage services. In at least some embodiments, a control plane server, such as a networking manager 106, may assign addresses in the underlying network to at least one NHD of each virtualization server, which may be used for subsequent communication with the control plane server and other virtualization servers. In some embodiments, the networking manager 106 may also assign network addresses (not part of the underlying network) to compute instances, for example, within a range of network addresses selected by the VCS client for their isolated virtual networks (IVNs). Multiple compute instances can be configured on a given virtualization server having a given NHD, using the respective network addresses assigned to each compute instance. In the embodiments described, a mechanism for delivering messages directed to each network address of the instances, while using the same underlying NHD, can be implemented in the VCS. The mapping between the underlying addresses and the addresses assigned to compute instances can, in some embodiments, be maintained by the networking manager 106, for example, as part of the isolated virtual network (IVN) metadata 111.

[0045] In at least some embodiments, a control plane server, such as a network manager 106 or NFA manager 104, may also assign network addresses to the NFAs of the EVMOC, which can be used for communication between the NFAs and cells 154 of radio-based applications. Cell 154A may include cell software 155A and antenna 156A associated with a radio unit (RU) of an RBA implemented using RCI 125A, and cell 154B may include cell software 155B and antenna 156B of an RU of an RBA implemented using RCI 125B. In some embodiments, the EVMOC may include multiple NHDs, one NHD being assigned an onboard network address, and another NHD being assigned a different address (e.g., an IVN address) used for communication between the NFAs and RUs. In one embodiment, a single NHD may be assigned multiple addresses by the VCS control plane server, including one address used for RU traffic and another address used for traffic directed to / from compute instances. In another embodiment, the NFA may comprise one or more NHDs that are managed by a control plane server and can be employed for communication with the RBA's RUs and / or centralized units (CUs).

[0046] A control plane server, referred to as the NFA Manager 104, may be involved in performing various management tasks relating to the NFA in the described embodiments. Such tasks may include, among other things, transmitting firmware / software used by the NFA, installing and running the firmware / software on the NFA, applying security patches to the firmware / software as needed, and scrubbing / cleaning the contents of the NFA's memory after an RCI has terminated so that data from an RBA that was running on a terminated RCI cannot be accessed by other RCIs that are subsequently started. In addition to collecting and analyzing health status and performance information from other resources within the VCS, the VCS control plane health and performance metrics manager 112 may collect and analyze health status and performance metrics from the NFA and expose the collected metrics to VCS clients, which the NFA may instead use in at least some embodiments.

[0047] In various embodiments, the instance state manager 102 and / or other control plane servers may be involved in coordinating or orchestrating the migration of RBA workloads from one RPS to another (e.g., working with an on-serve VMC or OVC). In at least some embodiments, each virtualized representation of the NFA of the virtualization server may be presented to each of one or more RCIs started on the server, allowing different RBAs running on the RCIs to share a single NFA device and perform a subset of the RBA's networking functions.

[0048] In some embodiments, any of the various network functions of the physical or L1 layer of the wireless-based technology stack may be implemented in NFA172 or NFA177. In other embodiments, the NFA may perform the network functions of the distributed units (DUs), centralized units (CUs), and / or core network components of the RBA. In some embodiments, a given EVMOC may include several different NFAs, each containing hardware optimized to accelerate different types of network functions or different sets of network functions.

[0049] As mentioned earlier, an isolated virtual network (IVN) may, in various embodiments, be logically isolated from the rest of the VCS resources with respect to at least some types of networking configuration settings, or may include a separate set of resources. For example, a given IVN may have one or more subnets and / or sets of IP addresses, each with its own security settings, of which individual IP addresses may, in some embodiments, be assigned to individual compute instances configured in one or more virtualization servers. In the case of a virtualization server including an NFA, IVN functionality may be supported for NFA traffic and traffic directed to and from compute instances. For example, the networking manager 106 may, in some embodiments, include a set of security rules, such as security groups (defining restrictions on the destination and / or source of traffic) or network ACLs, within the IVN metadata 111 that are applicable to traffic directed to and from the NFA, and may ensure that compliance with such security rules is verified for messages directed to and from the NFA. Security settings applied to the NFA may be provided by the VCS client via a programmatic interface in a manner similar to how security settings for compute instance traffic are provided by the VCS client. In one embodiment, each set of client-specified security rules may be enforced by the VCS control plane's networking manager for fronthaul traffic (traffic between the RBA's RU and DU), midhaul traffic (traffic between the RBA's DU and CU), and backhaul traffic (traffic between the CU and the RBA's core network components). In various embodiments, other benefits associated with the use of IVNs, such as automatic encryption of traffic sent to and from addresses assigned within the IVN, may be automatically obtained for traffic directed to and from NFAs embedded within the EVMOC.

[0050] In some embodiments, route table entries provided to the VCS control plane by a client using programmatic requests are stored as part of the IVN metadata 111 and may be used to direct traffic originating from or addressed to the NFA and compute instances. In some embodiments, the networking manager 106 may obtain traffic shaping rules or rate limits from the VCS client via a programmatic interface and enforce rate limits on traffic to and from compute instances or traffic to and from the NFA (e.g., by dropping or discarding packets that would violate rate limits). Generally, in the embodiments described, the NFA may be managed by the VCS control plane server as a first-class entity within the IVN of the VCS in a manner similar to how compute instances and entities such as load balancers, virtual routers, and gateways are managed by the VCS control plane server. Note that in at least one embodiment, at least several virtualization servers or RPS may be used in multi-tenant mode, and therefore a given server may be used for compute instances configured on behalf of several different clients, potentially with compute instances of several different IVNs potentially instantiated on a single server. In different embodiments, some virtualization servers used by the RBA may be located in the provider network data center, while others may be located in facilities outside the data center. In various embodiments, one or more network functions of one or more RBAs may be executed using the primary processor (e.g., CPU) of the RPS without using the NFA. The decision of whether a given network function is executed on the NFA or on the primary processor may be based on various factors in different embodiments; for example, in some cases the decision may be based on a policy indicated by the client via a programmatic interface, and in other cases the decision may be made dynamically (e.g., by the control plane server) based on an analysis of metrics / failures / errors.

[0051] As shown in Figure 1, some virtualization management components of a virtualization server (such as OVCs) may run on an offload card, while other components (such as on-server VMCs) may run on the server's primary processor. Figure 2 illustrates an exemplary configuration of a wireless-based application processing server with partially offloaded virtualization management capabilities, in at least some embodiments. As shown, the wireless-based application processing server (RPS) 202 may include a primary physical processor set 204, main memory (e.g., one or more modules of random access memory (RAM)) 208, an enhanced virtualization management offload card (EVMOC) 210, an opportunistic stripdown hypervisor 220 running on the primary physical processor, and one or more wireless-optimized compute instances (RCIs) 250, such as RCIs 250A and 250B. In some embodiments, a given RPS may also be used to run one or more general-purpose compute instances, such as a general-purpose CI 251, which may not be optimized for wireless-based applications. In the embodiment described, EVMOC210 may include one or more NFAs237, one or more networking hardware devices (NHDs)292, a virtualization controller215, and a network processing offloader216. RPS202 may also include several other components not shown in Figure 2, such as various persistent storage devices. The primary physical processor set204 may include several physical CPUs (also referred to as pCPUs, primary processors), including pCPU205A and pCPU205B, in the embodiment described. Virtualized versions of pCPUs, called vCPUs or virtual CPUs, may be allocated to individual RCIs and / or general-purpose CIs by virtualization management components, such as a hypervisor and / or virtualization controller, during the lifetime of the compute instance.Each computing instance may include an instance of an operating system (e.g., operating systems 252A, 252B, and 252C) and a set of applications (e.g., 254A, 254B, and 254C) running on behalf of a client of a virtualized computing service (VCS) having similar functionality to VCS110 in Figure 1.

[0052] The virtualization controller, network processing offloader, and hypervisor 220 can be collectively referred to as a partially offloaded virtualization manager or PVM, as some of the virtualization management tasks required by the RPS may be performed by the hypervisor using pCPUs, and the remaining virtualization management tasks may be performed by the offload card. In the embodiments described, the network processing offloader 216 may implement one or more networking protocols (e.g., including encapsulation protocols used within the VCS) and act as an intermediary between compute instances and networking endpoints outside the RPS. In at least one embodiment, the VCS control plane may communicate with the network processing offloader 216 to perform networking-related configuration operations in the RPS, such as assigning network addresses and changing / applying IVN-related settings. In various embodiments, the network processing offloader 216 may use NHD to transmit messages between compute instances and endpoints or destinations outside the virtualization server, and / or between network functions performed by NFA 237 and endpoints or destinations outside the virtualization server. Similarly, the network processing offloader may receive messages from external sources to the virtualization server via the NHD and send the messages to the NFA237 or compute instance 250 or 251, depending on the destination indicated in the message. The virtualization controller 215, the network processing offloader 216, and / or NFA237 may, in some embodiments, be implemented using their respective system-on-chip designs, for example, within a shared offload card linked to the pCPU via a peripheral interconnect. In other embodiments, the virtualization controller, networking processing offloader, and / or NFA may be implemented using a field-programmable gate array (FPGA), a digital signal processor (DSP), or other technology.While the virtualization controller 215, network processing offloader 216, and NFA 237 are shown in the described embodiment as being integrated within a single offload card (e.g., a PCIe card), other embodiments may employ different approaches to the placement and configuration of these components. For example, in one embodiment, a single system-on-chip implementation may be used to perform the functions of the virtualization controller and network processing offloader. In another embodiment, each offload card may be used for the virtualization controller 215, network processing offloader 216, and / or one or more NFA 237. The virtualization controller, as its name suggests, may be the first component of the PVM, in the described embodiment, to organize or orchestrate much of the virtualization management work performed in the RPS202, such as booting, triggering the startup of other components of the PVM, communicating with the VCS control plane, and determining memory allocation for compute instances. In at least one embodiment, the network processing offloader may select a specific NHD292 to be used for a particular category of RPS traffic (e.g., midhaul traffic, fronthaul traffic, or backhaul traffic to the RBA, or traffic not transmitted to the RBA).

[0053] The hypervisor 220 can be described as stripped down in the described embodiments because many of the operations performed by at least some conventional hypervisors can be handled by the EVMOC 210, thereby reducing the complexity and size of the hypervisor 220. Additionally, the hypervisor 220 can be designated as opportunistic because, in most situations, it can wait until a compute instance voluntarily relinquishes control of the pCPU before the hypervisor uses CPU cycles. Thus, for example, if a particular compute instance 250 or 251 issues an I / O request (the I / O is expected to take approximately time T1 to complete) and relinquishes the pCPU until a response to the I / O request is received, the hypervisor can take advantage of this opportunity to perform one or more virtualization management tasks (which can typically take time T2 (T2 << T1)) using the pCPU while the compute instance is not expected to use the pCPU. Thus, the hypervisor 220 has a minimal impact on the performance of the application 254 (which can include wireless-based applications) in the described embodiments.

[0054] In the embodiments described, the hypervisor 220 may itself include several subcomponents, including a set of operating system kernel-level components 222, a hypervisor coordinator 225, one or more virtual machine (VM) managers 228, isolation / security components 229, and / or a messaging manager 231. The hypervisor coordinator 225, the individual VM managers 228, the isolation / security components 229, and / or the messaging manager 231 may be implemented as user-mode processes, each in at least some embodiments. In various embodiments, at least some of these components may be implemented as instances of their respective statically linked programs, communicating with each other via pipes using simple, specialized protocols. In the embodiments described, the hypervisor subcomponents may remain passive or quiescent by default, reacting and becoming active only in response to events (such as messages from other subcomponents, context switches initiated by compute instances, etc.).

[0055] The kernel-level component 222 may provide support for various low-level operations, such as initial responses to VM termination commands issued by compute instances (e.g., when a compute instance relinquishes its pCPU). The hypervisor coordinator 225, as its name suggests, may be involved in orchestrating the operations of other subcomponents. The hypervisor coordinator 225 may, for example, implement APIs that can be used for communication between components and the hypervisor in EVMOC to initiate the startup and shutdown of compute instances (e.g., at the request of the virtualization controller), expose metrics collected by the VM manager, provide debugging capabilities, etc.

[0056] Each VM manager 228 may be involved in launching or instantiating its respective compute instance based on specifications provided by the coordinator 225, monitoring the metrics and logs of the compute instance, etc. In some embodiments, the VM manager 228 may also assist the compute instance in performing I / O operations requested for a particular device, for example, by trapping I / O requests and translating those requests into completed memory-mapped I / O operations with the help of offloaded virtualization management components.

[0057] The messaging manager 231 may act as an intermediary between the virtualization controller 215 and the hypervisor by, for example, translating commands issued by the virtualization controller using a queue-based protocol into pipe messages within the hypervisor. The security and isolation component 229 may be involved in, for example, scrubbing or cleaning up compute instance memory when compute instances are terminated, thereby preventing inadvertent sharing of data across compute instances. In some embodiments, the security and isolation component may also be involved in scrubbing or cleaning up the memory of the NFA 237 in response to commands issued by the NFA manager of the VCS control plane, for example.

[0058] A program that implements virtualized networking functionality in one or more layers of a wireless-based technology stack may, in the embodiments described, run as part of application 254A or 254B of the RCI. Other networking functions may be performed in the NFA, for example, in response to requests or messages transmitted from the RU and / or from programs implemented in the application. Various aspects of the configuration of compute instances and the NFA may be managed by the VCS control plane server, as described above.

[0059] In some embodiments, the EVMOC210 may include several other components not shown in Figure 2. A secure boot ROM integrated within the EVMOC may, in one embodiment, be used in the initial stages of a multi-stage boot operation by the virtualization controller. The EVMOC may also include a security module (such as a Trusted Platform Module (TPM)), which may also be extensively used for state verification during and / or after the boot procedure. In addition, in various embodiments, the EVMOC210 may include several storage, power, and connectivity-related components. For example, one or more flash devices / interfaces (or SSDs) may be integrated into the offload card. These devices may be used to store firmware and / or software corresponding to various virtualization management components, compute instance components, NFAs, etc. The PCIe interface of the EVMOC may be used to communicate with the hypervisor and / or in various embodiments. In other embodiments, other types of interconnects and corresponding interfaces may be used, such as USB, QuickPath interconnect (QPI), or variants of UltraPath interconnect (UPI). In some embodiments, the EVMOC210 may also have a power supply sufficient to keep the EVMOC components running for at least a target number of hours or days, for example, in the event of a prolonged power failure. In some implementations, a supercapacitor-based power supply may be used.

[0060] Figure 3 illustrates an overview of the user plane and control plane layers defined according to technical standards for wireless-based applications, in at least several embodiments. The arrows shown in Figure 3 represent the downlink communication path (from higher levels of standards, often implemented in backend servers, to lower levels, implemented using frontend components such as the types of wireless antennas and network function accelerators described above). The layers depicted conform to the 5G-NR standard published by 3GPP (Third Generation Partnership Project), a group of organizations involved in defining mobile communication protocols, but similar layers are also defined for other generations of cellular communication technologies.

[0061] In a manner somewhat similar to the subdivision considered for provider network functions into control plane and data plane functions, the operations required for wireless-based applications are divided into control plane operations and user plane operations. Control plane operations include connection configuration and other management tasks such as monitoring, while user plane operations involve the transmission of user data using Internet Protocol (IP) packets.

[0062] The 5G-NR protocol stack includes three layers, referred to as L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3). Standardized interfaces are defined for communication between layers (and between sublayers of individual layers), allowing for flexible mapping of layer and sublayer network functions to different hardware and / or software components, as long as the protocol stack's interface and performance requirements are met. The logic for performing the layer functions is distributed among three types of components: centralized units (CUs) for L3 operations, distributed units (DUs) used for L2 operations and optionally for some L1 operations, and radio units (RUs) used for at least a subset of L1 operations. L1 is also referred to as the physical layer (PHY). L2 includes MAC (Media Access Control) and RLC (Radio Link Control) sublayers. L3 may include sublayers for PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol). The operation of the user plane 301 may include Quality of Service (QoS) management 302 and Compression-Integrity Encryption 304 at L3, Automatic Repeat Request (ARQ) processing 306 and Hybrid ARQ (HARQ) processing 308 at L2, and channel coding 310 at the PHY layer. The operation of the control plane 351 may include Non-Access Layer (NAS) 320 protocol tasks, System Information (SI) 322 tasks, paging 324, Radio Resource Control (RRC) 326 and Compression-Integrity Encryption 328 at L3, ARQ 330 and HARQ 332 at L2, and channel coding 334 at the PHY layer. At least some of the layers and protocols shown in Figure 3 may include the execution of each set of network functions. In at least some embodiments, subsets of network functions corresponding to L1, L2, and / or L3 may be implemented using the above-described types of NFAs embedded within a virtualization management offload card.

[0063] Figure 4 illustrates exemplary uplink and downlink pipelines for network functionality for wireless-based applications, in at least some embodiments. The Standardization Committee has defined several options for splitting pipeline functionality between CUs (centralized units) and DUs (distributed units), which are shown in Figure 4 by dashed lines labeled Option 1, Option 2, ..., Option 8. Such a split allows for the distribution of wireless-based application workloads across multiple different devices, rather than relying on a monolithic device involved in performing all the functionality. Several more detailed options for splitting physical layer functionality between CUs and DUs, which are variations based on Option 7 and are therefore referred to as Option 7-1, Option 7-2, etc., are shown in Figure 5.

[0064] The downlink pipeline 401 begins with RRC (Radio Resource Control) 402 and data 404 and ends with digital-to-analog radio frequency (D / A RF) operation 420. In between, the downlink pipeline sequentially includes each set of network functions: PDCP (Packet Data Convergence Protocol) 406, upper RLC (Radio Link Control) 408, lower RLC 410, upper medium access control (MAC) 412, lower MAC 414, upper PHY (Physical Layer) 416, and lower PHY 418. The uplink pipeline 451 begins with analog-to-digital radio frequency (A / D RF) operation 452 and ends with RRC 468 and data 470. In between, the network functions are executed sequentially for lower PHY 454, upper PHY 456, lower MAC 458, upper MAC 460, lower RLC 462, upper RLC 464, and PDCP 466. In various embodiments, at least some network functions of the upper PHY layer and / or lower PHY layer (for uplink and / or downlink) may be implemented using NFAs of the type considered above. In some embodiments, network functions of other layers shown in Figure 4 may also be implemented with NFAs. In at least some embodiments, network functions of the RLC layer and MAC layer may be implemented using software operating within a radio-optimized computation instance (RCI) of the type shown in Figure 1.

[0065] Figure 5 illustrates exemplary network functions that may be performed in the physical layer of a technology stack for a wireless-based application, in at least some embodiments. In the downlink PHY (L1) pipeline 501, where control and data messages are transmitted from higher-layer components toward the RU, the lower MAC stage 502 (part of L2) leads to the coding, rate matching, and scrambling stage 504, followed by the modulation layer mapping stage 506. Subsequently, the precoding and resource mapping stage 508, the digital beamforming stage 510, and the inverse fast Fourier transform (IFFT) and cyclic prefix insertion stage 512 are performed before the digital-to-analog radio frequency (D / A RF) operation 514 is performed. In the reverse direction, when control signals and data are flowing from the radio unit toward the L3 components of the pipeline, the analog-to-digital radio frequency (A / D RF) stage 552 is followed by the cyclic prefix removal and fast Fourier transform (FFT) stage 554 of the uplink PHY (L1) pipeline. This is followed by another digital beamforming stage 556, a demapping, channel estimation and pre-filtering stage 558, an equalization and demodulation stage 560, and a decoding, rate dematching and decoding stage 562, after which it reaches the L2 lower MAC stage 564.

[0066] Each stage in the uplink pipeline 501 and downlink pipeline 551 may require the execution of a set of network functions. Splitting options 7-3, 7-2, 7-2a, and 7-1 represent proposals for distributing the entire combination of network functions between “Upper L1” (implemented in the DU) and “Lower L1” (implemented in the RU), respectively. The stages of pipelines 501 and 551 to the left of the dashed line indicating the splitting options are considered part of Upper L1, and the stages to the right are considered part of Lower L1. Thus, in the split of 7-2, stages 508, 510, 512, 554, 556, and 558 may involve the RU, while the remaining stages may involve the DU. In various embodiments, a network function accelerator used in a wireless-based pipeline processing server (RPS) may use a custom chipset to execute at least some of the network functions of the pipeline stages shown in Figure 5. For example, the network functions implemented in the accelerator may include one or more L1 network functions of a radio-based technology stack, such as (in particular) coding, rate matching, scrambling, modulation layer mapping, precoding, resource mapping, digital beamforming, fast Fourier transform (FFT), cyclic prefix insertion, cyclic prefix removal, inverse FFT, demapping, channel estimation, prefiltering, equalization, demodulation, descrambling, rate inverse matching, or decoding. In at least some embodiments, the network function accelerator may implement DU functions. In some embodiments, at least a portion of the CU functions may be implemented in the RPS in addition to the DU functions.

[0067] Figure 6 illustrates an exemplary hierarchy of devices that may be used for a wireless-based application, in at least some embodiments. In the embodiments described, a core network server 618 linked to one or more networks 615 used to transport Internet protocol packets containing application payloads and control signals over long distances implements a set of backend functions associated with the wireless-based application, enabling different subnetworks throughout the system to communicate with each other. The network functions performed on the core network server (referred to as core network functions) may include, for example, functions that aggregate data traffic from end-user devices, authenticate subscribers, apply personalized policies, and / or manage the mobility of devices before routing traffic to operator services or the Internet. A given core network server 618 may, for example, be located in a provider network data center in one embodiment. The core network server may be connected to one or more intermediate RAN servers 620, such as 620A and 620B, in which additional central unit (CU) functions may be implemented in some embodiments. Traffic between the core network server 618 and the intermediate RAN servers 620 may be referred to as backhaul traffic 691 in the embodiments described. The intermediate RAN server may be located, for example, within a facility where one or more VCS extension sites are implemented, or in a facility located near such extension sites.

[0068] In the embodiment depicted in Figure 6, the distributed unit (DU) functionality of the wireless-based application technology stack may be implemented in an RPS 670 (functionally similar to the virtualization servers 150 and 152 in Figure 1). Each intermediate RAN server 620 may be linked to one or more RPSs; for example, intermediate RAN server 620A may be connected to RPS 670A and RPS 670B, and intermediate RAN server 620B may be linked to RPS 670C and RPS 670D. ​​Traffic between CUs and DUs may be referred to as midhaul traffic 692 in various embodiments. Each RPS may then be linked to a wireless unit (RU) in one or more cell 654 devices, for example, using an NHD incorporated within a virtualization management offload card. For example, RPS670A may be linked to radio units in cells 654A and 654B, RPS670B may be linked to radio units in cell 654C, RPS670C may be linked to radio units in cell 654D, and RPS670D may be linked to radio units in cells 654E and 654F. Traffic between DUs and RUs may be referred to as fronthaul traffic 693. Each cell may include one or more antennas that can be used to receive and transmit radio frequency signals from various radio user devices 679. A given RAN node (such as gNodeB in the case of a 5G application) may, in various embodiments, include one or more CUs, one or more DUs, and one or more RUs. In some embodiments, the RPS, intermediate RAN server, and core server may all be at least partially implemented using provider network resources. According to one embodiment, at least some core network functions may be performed using the RPS (functions performed by core server 618). In one embodiment, at least some of the functions of cell 654 may also be implemented using provider network resources. In at least one embodiment, RPS may also be used to implement at least a subset of CU functions.

[0069] Figure 7 illustrates an exemplary deployment of an L2 implementation program of a wireless-based technology stack in a wireless-based application processing server, in at least some embodiments. In the embodiments depicted, the wireless-based application processing server (RPS) 710 includes a set of programs for the L2 layer, L2P725, of one or more wireless-based application (RBA) pipelines. In some embodiments, L2P725 may be developed by a third-party vendor or software provider, or by a provider network operator. In at least some embodiments, the L2P of the RBA pipeline may be invoked within a compute instance (such as a wireless-optimized compute instance similar to RCI125A or 125B in Figure 1).

[0070] In the embodiment depicted in Figure 7, a request handler may be invoked in the RPS for the RBA pipeline. The upper L1 request handler 726 may be used to process / forward requests generated in the L2P 725 for network functions. In embodiments where the RPS is used in multi-tenant mode for multiple RBA pipelines, each set of upper L1 request handlers and L2Ps may be instantiated for each of the pipelines. Request handlers may be isolated from each other within their respective runtime environments, for example, as part of their respective compute instances or software containers that have an address space inaccessible from other execution environments. In some embodiments, the request handlers 726 may include one or more privileged threads or processes running within the same runtime environment as their corresponding L2Ps. Each of the request handlers 726 may include software developed in the provider network, as opposed to the L2Ps, which may be developed by entities other than the provider network operator, for example.

[0071] The request handler 726 may, for example in some embodiments, receive requests from the L2P 725 for higher-level L1 network functions for the downlink portion of the RBA pipeline via a set of L2-to-L1 programmatic interfaces 770 designed and implemented in the provider network. The programmatic interfaces 770 may, for example in at least some embodiments, be based on or compatible with standards such as FAPI-NR (Functional API-New Radio). In one embodiment, the programmatic interfaces 770 may be exposed to external mechanisms by the provider network or communicated in other ways, thus enabling L2P vendors to develop code that can be used with the RPS higher-level L1 request handler. It should be noted that the number of L2Ps and request handlers running on a given RPS 710 may vary based on, for example, the number of provider network clients that wish to implement their radio-based applications in the same neighborhood, for example, two or more L2Ps and corresponding request handlers may be invoked on the RPS, or a single L2P and a single request handler may be invoked. In some embodiments, different boundary layer APIs (i.e., not necessarily L2-L1 interfaces) of the wireless-based technology stack may be implemented by request handlers.

[0072] The NFA Access Manager (NFAAM) 727 (also referred to as the Network Function Offload Manager) may be invoked on the RPS 710 in at least some embodiments, for example, as part of a virtualization management component such as a hypervisor. In the embodiments described, the NFAAM 727 may act as an intermediary between a request handler and a set of Network Function Accelerators (NFAs), such as the NFA 719 implemented in the Extended Virtualization Management Offload Card (EVMOC) 718 of the RPS 710, in a manner somewhat similar to how a hypervisor and other virtualization management components in a general-purpose virtualization host or server can act as an intermediary between software and other hardware components.

[0073] In the described embodiments, the NFAAM receives L1 network function requests sent from the request handler 726 for all downlink pipelines implemented using the RPS 710, determines which NFA 719 (if there are multiple NFAs) should be used for a given network function, and can transmit the request to that NFA for execution. In some embodiments, the results of the execution of the network function can be transmitted from the NFA to one or more radio units of one or more cells. For messages flowing from the antenna toward the L2 and L3 layers of the application pipeline (uplink pipeline messages), the workflow can be reversed, incoming messages can be transmitted from the RU to the NFA, one or more network functions can be executed by the NFA, and the results can be forwarded to the L2P via the NFAAM and / or request handler. The L2P can then forward the results of the L2 processing to L3 or CU implementation programs further up the stack, for example, in other RPS, intermediate RAN servers, and / or core servers.

[0074] In at least some embodiments, NFAAM may include a metrics / health status information collector that tracks resource utilization levels of the NFA (e.g., utilization levels of on-card processors, memory, etc.), failures of NFA components (if any), latency for completing network function processing in the NFA, etc. Such metrics may be provided to the VCS control plane server and, in different embodiments, may be used to make various configuration decisions, such as which particular NHD or NFA should be used for a given type of network communication or network function, RBA workload migration decisions, and whether a given network function should be run locally or transmitted to another server for remote execution.

[0075] In the embodiments described, the RPS710 may include one or more NHD733 implemented as part of the EVMOC718. In embodiments where the RPS includes multiple NHDs, the RPS's networking manager (not shown in Figure 7) may, in various embodiments, be involved in selecting a particular NHD to be used for traffic directed to a particular category of destination. A given NHD may, in the embodiments described, include several different ports, such as ports 772A, 772B, and 772C, thereby enabling the establishment of connections with several different network endpoints or networking devices, such as routers / switches, that use that NHD. In some embodiments, one NHD or port may be used for communication with RUs (fronthaul traffic), and another NHD or port may be used for midhaul traffic or backhaul traffic. The EVMOC718 may also include a virtualization controller 735 having similar functionality to the virtualization controller 215 in Figure 2.

[0076] In embodiments where EVMOC includes multiple NFAs, a particular NFA for a given request may, in different embodiments, be selected based on any combination of various factors (e.g., by NFAAM). For example, in some embodiments, a given L2P may be associated with at least one NFA in a request from a client on which the L2P is performed, and thus the NFA selected for a given network function request may be at least partially based on the L2P on which the network function is requested. In some cases, a given NFA may be assigned to exclusive use on behalf of a given client of a given wireless-based application or provider network. In some embodiments, metrics collected from NFAs may be used to select the NFA to which a given network function request is directed, for example, the NFA with the lowest recent resource utilization level may be selected in preference to other NFACs.

[0077] In the embodiments described, each wireless-based application on which the pipeline runs in the RPS may belong to one of a set of application areas, each with its own expectations regarding performance and other quality of service considerations. The ITU-R (International Telecommunication Union Radiocommunication Sector) standardization organization defines at least three such application areas for 5G cellular communications: Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communications (mMTC), and Ultra-High Reliability Low Latency Communications (URLLC). In some embodiments, the NFAAM may select at least some of the networking capabilities of an application based on the application area to which the application belongs.

[0078] The RPS can also be used for one or more additional applications 711 on behalf of one or more clients, such as applications that do not require the execution of L1 and L2 network functions. As a result of offloading at least a portion of the L1 network function workload to the NFA, in various embodiments, more of the RPS's primary processors (CPU, GPU, etc.) may become available for such additional applications.

[0079] In various embodiments, RPS similar to RPS710 may provide an implementation of Open Radio Access Network (O-RAN), which is a separate approach for deploying mobile fronthaul and midhaul networks built on cloud-native principles. O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture initially introduced by 3GPP. Mechanisms such as the O-RAN Alliance are developing O-RAN standards, and RPS may be designed to comply with such standards in at least some embodiments.

[0080] Figure 8 illustrates an exemplary presentation of a virtualized representation of a hardware network function accelerator for compute instances running on a virtualization server, in at least some embodiments. In the embodiments depicted in Figure 8, the RPS810 can be used to run at least two radio-optimized compute instances (RCIs) 870A and 870B. Each RCI may include a set of L2 implementation programs for its respective RBA, such as L2P824 for RCI 870A and L2P834 for RCI 870B. Other applications 811A (i.e., applications that do not implement L2 network functions) may also run on RCI870A, and similarly, other applications 811B may run on RCI870B.

[0081] In the embodiments described, the RPS 810 may include a hypervisor 835 and an EVMOC 818. The EVMOC 818 may include at least one NFA 819, at least one NHD 833, and a virtualization controller 838 of the type considered above. The virtualization controller and the hypervisor may communicate with one or more VCS control plane servers 837, for example, using one of the NHD 833s.

[0082] In at least some embodiments in which one or more RCIs are running on the RPS, each virtualized representation of an NFA may be programmatically presented to each RCI by the hypervisor or other virtualization management component. For example, virtualized NFA877A may be presented to RCI870A, and virtualized NFA877B may be presented to RCI870B. From the perspective of any given RCI, the virtualized representation may grant access to all the functionality that would be provided if the RCI were granted access to the physical NFA, in a manner similar to how a virtualized CPU may appear to grant access to a physical CPU. A set of APIs for issuing requests / commands to the NFA may be included in the virtualized representation. To have a given network function run on the NFA, a program running on the RCI may call the APIs of the virtualized representation provided to that RCI. In the embodiments described, each virtualized NFA may be used for its respective network slice, enabling multiple RBAs or RBA pipelines to be implemented using a shared hardware NFA.

[0083] In some implementations, the hypervisor may maintain a data structure containing several slots, each slot representing a virtualized view of at least a portion of the NFA's computing and / or networking capabilities, which can be allocated or assigned to a particular RBA or L2P for at least a certain period. Individual slots may, in some embodiments, include elements of an array, a linked list, or other similar data structure. In various embodiments, the hypervisor may schedule the execution of individual network functions from multiple pipelines (i.e., different radio-based applications) in a shared NFA in such a manner that, from the perspective of any given pipeline, the NFA appears to be used exclusively for that pipeline. In some embodiments, the number of slots maintained by the hypervisor for a given NFA may be based at least in part on the NFA's total performance capabilities along one or more dimensions, such as the NFA's network function processing capacity or the network bandwidth available for communication from the NFA to the RU.

[0084] Figure 9 illustrates an exemplary network function accelerator configuration management task that may be performed by, or initiated by, a control plane server for a virtualized computing service, in at least some embodiments. In the embodiments depicted in Figure 9, the RPS910 may be used to run at least one radio-optimized compute instance (RCI)970. The RCI may include a set of L2 implementation programs for each RBA, similar to the L2P discussed earlier in the context of Figures 7 and 8. Other applications may also be run on the RCI970.

[0085] In the embodiments described, the RPS910 may include a hypervisor 935 and an EVMOC918. The EVMOC918 may include at least one NFA919, at least one NHD933, and a virtualization controller 938 of the type considered above. The virtualization controller and the hypervisor may communicate with one or more VCS control plane servers 937, for example, using one of the NHD933s.

[0086] In the embodiments described, the VCS control plane server may, for example, perform several types of management and configuration tasks associated with the NFA919 with the help of a hypervisor and / or virtualization controller. These tasks may include firmware / software deployment 901 of the FSA, including the installation of an initial version of the firmware / software and any subsequent versions or updates that become available. As part of firmware / software management, in various embodiments, security patches or fixes may be applied to the NFA. In embodiments where the NFA firmware / software is prepared by a third-party vendor rather than by, for example, a provider network operator, the VCS control plane server may implement a programmatic interface that can be used by the third-party vendor to submit the firmware / software to the VCS, and the VCS control plane server may then propagate the firmware / software to the appropriate RPS.

[0087] In at least some embodiments, the VCS control plane server may assign a network address to the NFA for use in communication between the NFA and other components of the RBA, such as the RU and / or CU. The assignment of the NFA address 902 may, in some embodiments, be done in response to a program request from a VCS client, where the NFA will be used instead; for example, the client may specify a particular address or allow the VCS control plane server to select an address. In some cases, one address may be assigned to the fronthaul traffic of the RBA, implemented with the help of the RPS, and another address may be assigned to the midhaul traffic. In at least one embodiment, an address in the IVN, configured at the client's request, may be assigned to the NFA.

[0088] In various embodiments, the NFA may include its own processor and memory. The memory may be used to store data relating to network functions running on the NFA, such as intermediate or final results of network functions. In one such embodiment, the VCS control plane server may scrub or clean up the memory at one or more points in time, such as when the RCI that was sending network function requests to the NFA terminates. Such NFA memory scrubbing 905 can help enhance the security of RBAs running with RPS, as data generated or stored in NFA memory for one RBA may be permanently scrubbed or deleted before any other RBA can access it.

[0089] The VCS control pane server may also be involved in NFA health status monitoring 903 and NFA performance metrics monitoring 904 in the embodiments described. Information regarding the health status of the NFA and the performance characteristics of the NFA over various time intervals may, in various embodiments, be provided to a client (e.g., an RBA owner) on which the NFA is being used via a programmatic interface. Metrics collected and presented by the control plane may include, for example, utilization levels of the NFA processor, memory, etc., the rate or count of failures or errors (if any) of NFA components, and the latency required for the NFA to complete network function processing.

[0090] The VCS control plane server may also, in some embodiments, be involved in coordinating the live migration of NFA and RCI workloads. Such live migrations may be initiated based on various trigger conditions, such as the availability of a new version of L2P or the detection of a threshold for the number of failure errors in the RPS. As a result of the live migration, RBA traffic from RUs that previously sent messages to the NFA in one RPS (source RPS) may be directed to the NFA in a different RPS (destination RPS), and network functions that were running on the RCI in the source RPS may instead be run on a migrated version of the RCI in the destination RPS. The control plane server may ensure that RBA status information, including NFA and RCI status information, is replicated from the source RPS to the destination RPS in various embodiments without interrupting ongoing RBA operations.

[0091] The VCS control plane server may also be involved in the assignment of board network addresses to the NHD on the EVMOC951 and the assignment of isolated virtual network addresses to the virtual network interface 972 programmed onto the RCI970 in the described embodiment. The encapsulation protocol implemented in the VCS, and the mapping between board addresses and IVN addresses, may be used in various embodiments for communication between the RCI and entities outside the RPS.

[0092] Figure 10 illustrates embodiments of workload transition techniques that may be employed for wireless-based applications, in at least some embodiments. In the exemplary scenario depicted in Figure 10, RCI1020A may be instantiated on RPS1010 with EVMOC1018A containing the type of NFA discussed above. RCI1020A may include version 1025A of one or more programs (such as an L2 implementation program or L2P) that perform some of the DU (Distributed Unit) functionality of the wireless-based application RBA1. RBA1 may also include other layers, such as a centralized unit (CU) layer and an RU layer, which may run on resources other than RPS1010. To implement the DU functionality, state information about messages or traffic between pairs of layers in RBA1 is maintained in the RCI and can be accessed by version 1025A of the program. Such RBA1 state information 1027 may, in the embodiments depicted, include, for example, state information about fronthaul traffic (DU-RU traffic) and midhaul traffic (DU-CU traffic).

[0093] In the embodiments described, the VCS control plane server 1002 of the VCS may be involved in detecting trigger conditions for migrating the RBA1 workload, initially run on RCI 1020A, to another RCI 1020B. One or more control plane agents used for the migration may, in some embodiments, run locally on RPS 1010, for example, as part of the virtualization management layer or as part of RCI 1020A. Any of the various trigger conditions may lead to the migration in different embodiments, such as receiving a program request to upgrade a program implementing L2 or DU functionality, performance metrics, or detecting an error on RPS 1010.

[0094] In the embodiment depicted in Figure 10, the VCS control plane server 1002 may determine that at least a subset of the operation of RBA1 should be migrated to an updated / upgraded RCI1020B. RCI1020A may be referred to as the source RBA1 workload, and RCI1020B may be referred to as the destination RBA1 workload (or the migrated version of RCI1020A) in the embodiment depicted. In Figure 10, RCI1020B operates on a different RPS1012 than RCI1020A, where RPS1010 may be referred to as the source RPS and RPS1012 as the destination RPS. RCI1020B may include version 1025B of the program that implements the DU functionality of RBA1. Version 1025B may include an updated / upgraded version of the DU implementation program (whose previous version was version 1025A) in the embodiment depicted.

[0095] In response to a determination that the workload of RBA1 should be migrated, state information required to perform RBADU operation on RCI1020B may be transferred to RCI1020B in various embodiments. In the embodiments described, at least a subset of state information 1027A for RBA1's midhaul and / or fronthaul traffic may be transferred to RCI1020A without pausing RBA1, as indicated by arrow 1066A. Similarly, in various embodiments, at least a subset of additional RCI state information 1028 (such as networking state information, memory content, and device state information for traffic categories other than fronthaul or midhaul traffic) may also be transmitted to RCI1020B without pausing other applications running on RBA1 or RCI1020A, as indicated by arrow 1066B. This type of state transfer, which may involve multiple iterations in which incremental portions of state information that have changed since the last iteration are transferred, can help avoid interruptions to the end-user visibility functionality of RBA1 and / or other applications initially running on RPS1010. Ultimately, in the described embodiment, after all state information that can be transferred without pausing RBA1 has been sent to RCI1020B, RBA1 may be briefly paused to transfer any remaining state information. After the state information has been completely transferred, the DU operation of RBA1 may be started in the described embodiment with the updated / upgraded RCI1020B, which may resume DU functionality using the transferred RBA1 state information 1037. Additional transferred RCI state information 1038 may be used in the described embodiment to resume other operations previously performed in RCI1020A.

[0096] In various embodiments, the VCS control plane server 1002 may include one or more orchestration managers, such as the RU / CU orchestration manager 1078, which are involved in coordinating the transition of DU functions with other components of the RBA1 (such as CU layer components or RU layer components). For example, other components may be notified via one or more messages regarding the pending transition of a DU, and as a result, the other components may perform one or more preparatory actions (e.g., saving or backing up their own state information in case the transition fails for any reason). Fronthaul traffic 1091A, which initially flowed between RU1090 and the NFA in the EVMOC 1018A, may flow between RU1090 and the NFA in the EVMOC 1018B of the RPS 1012, as indicated by arrow 1091B in the embodiments described, after the transition of state information is complete and the RU has been notified regarding the transition. During the migration procedure, in some embodiments, the routing components of the provider network may implement traffic mirroring so that messages sent from RU1090 to the NFA of EVMOC1018A are also sent to the NFA of EVMOC1018B.

[0097] Figure 11 illustrates exemplary categories of network traffic for a wireless-based application processing server in at least some embodiments. The RPS1110 may include an EVMOC1191 (including one or more NFAs, one or more NHDs, and a virtualization controller) and an RCI1120A on which at least a portion of the DU functionality of the wireless-based application RBA1 may be implemented. In the embodiments described, the RPS1110 may be located in a facility outside the provider network data center, for example, in a local zone, or as part of a VCS extended resource group configured in a facility selected by the VCS client. In the embodiments described, the RCI1120A may be configured as part of an isolated virtual network (IVN)1145 of the provider network VCS, for example, by assigning an IP address from a range of IVN IP addresses to the RCI1120A. The IVN1145 may include one or more other RCIs, such as a local RCI1120B, in the same facility as the RPS1110, and the RCI1120B may also be used to perform, for example, a portion of RBA1. RCI1120B may operate with a different RPS than RPS1110. IVN1145 may also include one or more compute instances 1122 running on a virtualization server within the provider network's data center in the scenario shown in Figure 11. In addition, IVN1145 may, in some cases, include one or more other local compute instances that are not optimized for wireless-based applications but also run in the same facility as RPS1110. Each compute instance within IVN 1145, including instances 1122, 1120A, and 1120B, may be assigned an IP address within the range of IP addresses selected for the IVN. For example, each virtual network interface (VNI) to which an IP address is assigned may be programmatically appended to the compute instance by the VCS control plane server, thereby effectively assigning an IP address to the compute instance.

[0098] In the embodiments described, the RPS1110 may participate in at least five categories of network traffic exchange. Fronthaul traffic 1161 may flow between the NFA of the EVMOC1191 of the RPS1110 and one or more RUs of RBA 1, such as RU1104. Midhaul traffic 1162 may flow between the RPS1110 and one or more CUs of RBA 1, such as CU1102. Control plane traffic 1163 (such as commands to configure the NFA, start an RCI, terminate an RCI, or migrate an RCI workload) may be directed to the RPS1110 from VCS control plane resources located in the provider network's data center. Messages directed from applications running on the RPS1110 to other services 1144 of the provider network (such as a storage service or a database service) or messages directed from other services 1144 of the provider network may constitute non-VCS service traffic 1164 in the embodiments described. In some cases, the facility comprising RPS1110 may include one or more resources not managed by the provider network, such as client-owned devices or servers on which client applications other than RBA1 run. Such resources may be referred to as an example of non-provider network resources 1170, other examples of which may include devices on the public internet. Traffic to and from the network endpoints of such resources may be referred to as provider network external traffic 1167. The final category of network traffic referred to as IVN internal traffic may, in the embodiments described, include traffic 1165A (IVN internal traffic 1165A) between the RPS's RCI1120A and other local compute instances 1120B, and traffic between the RPS and compute instance 1122 in the provider network's data center (IVN internal traffic 1165B).

[0099] In some embodiments, as previously mentioned, the EVMOC1191 may include several networking hardware devices, i.e., NHDs, each NHD being selected from a set of NHDs for one or more of the traffic categories shown in Figure 11 (for example, based on a command from the VCS control plane server 1101). For example, one NHD may be used for fronthaul traffic, another for midhaul traffic, and so on. For example, various networking-related configuration settings of the IVN1145 (including network security-related settings), selected by the client represented by the IVN1145, may, in some embodiments, be applied to the midhaul and fronthaul traffic of the RBA1, in addition to being applied to other traffic of compute instances configured within the IVN1145.

[0100] Metadata relating to various aspects of isolated virtual networks may be stored by the VCS control plane in various embodiments. Figure 12 illustrates exemplary categories of isolated virtual network metadata associated with a wireless-based application processing server in at least some embodiments. As shown, the isolated virtual network metadata 1201 may include metadata applicable to non-RBA traffic of RCI / VNI 1220, metadata applicable to RBA midhaul traffic 1240, and metadata applicable to RBA fronthaul traffic.

[0101] Metadata 1220 may, for example, in the embodiment described, include a VNI IP address 1222 (which can be used as the source or destination address of packets originating from or directed to a compute instance containing an RCI), a security group 1224, a network access control list (ACL) 1226, a route table 1228, and a subnet 1230. Access control (also known in various implementations as security groups, network security groups, application security groups, cloud security groups, or compute engine firewall rules) acts as a virtual firewall for compute instances, controlling inbound and outbound traffic. Customers can define security groups as policies that can be applied to specific instances. When a customer launches an instance in an IVN, they can assign one or more security groups to the instance. Security groups can operate at the instance level rather than the subnet level. Thus, each instance within a subnet can be assigned to a different set of security groups. For each security group, a customer can add rules to control inbound traffic to the instance and a separate set of rules to control outbound traffic. Security groups can be stateful in that they automatically allow return traffic.

[0102] Customers can also configure network access control lists (ACLs) using rules similar to security groups to add an additional layer of security to their IVN. Network ACLs operate at the subnet level, support allow and deny rules, and automatically apply to all instances within any associated subnet. Network ACLs may not be stateful in that return traffic must be explicitly allowed by the rules. The same security group may be used or replicated for multiple compute instances. VCS clients may use only security groups without network ACLs, use network ACLs without security groups, or use both security groups and network ACLs, as needed. In some embodiments where multiple security rules (security groups and / or network ACLs) are configured for a given set of VCS resources, the VCS client may provide an indicator of the order in which different rules should be applied, effectively indicating the relative priority of the rules.

[0103] After security groups and / or network ACLs are specified for compute instance traffic and / or midhaul or fronthaul traffic, the VCS control plane server may be involved in verifying that the rules are enforced. For example, the control plane server may cause VCS networking components (such as the virtualization manager / hypervisor, routers, and networking components of other networking devices) to verify that rules related to inbound traffic will not be violated by delivery before delivering any packet or message to an applicable compute instance or NFA. Packets that would violate the rules upon delivery may be dropped in some implementations. Similarly, for outbound packets / messages, VCS networking components may verify that they do not violate outbound traffic security rules before forwarding the packet along its route to its intended destination. Rules may, in various embodiments, be propagated from the VCS control plane server to the relevant VCS networking management components.

[0104] According to some embodiments, a VCS client may specify routing entries for various sets of sources and destinations within the IVN via a programmatic interface, and such routing entries may be stored in a route table 1228 maintained as part of the IVN metadata, in the embodiments described. In some embodiments, the client may define one or more subnets 1230 within the IVN and, if necessary, use compute instances configured in different subnets for each application.

[0105] One or more NFA midhaul traffic addresses 1242 and / or fronthaul traffic addresses 1262 may, in some embodiments, be assigned by the VCS control plane server and stored as part of the IVN metadata. In some embodiments, the addresses used for midhaul and / or fronthaul traffic may be selected from the same range of IVN addresses from which the VNI / IP addresses are chosen, while in other embodiments, different ranges of addresses (or even addresses of protocols other than IP) may be used for fronthaul and / or midhaul traffic. In the embodiments described, security groups 1244 and 1264, similar to security group 1224 but specifically applicable to midhaul and fronthaul traffic, respectively, may be defined / specified by the VCS client. Similarly, network ACLs 1246 and / or 1266 may be specified / defined by the VCS client for midhaul and fronthaul traffic, and the route table 1248 may, in at least some embodiments, populate entries specified by the VCS client for midhaul traffic. In various embodiments, the VCS control plane may implement a programmatic interface that can be used by a VCS client to specify various configuration settings, as shown in Figure 12, and the control plane server may, in response to requests received through such an interface, implement or apply the specified settings.

[0106] In some embodiments, the provider network may allow a client to launch compute instances selected from several different categories located within an instance family. Figure 13 illustrates exemplary categories of compute instances that may be configured on behalf of a client of a virtualized computing service, in at least some embodiments. The instance families supported in the embodiments described include general-purpose compute instances 1310, GPU-based compute instances 1315, memory-optimized compute instances 1320, and wireless-optimized compute instances 1325. Families (other than the general-purpose family) may be optimized in some way for their respective types of applications; for example, applications requiring large amounts of high-speed persistent writes or reads may be optimized for memory-optimized compute instances 1320, applications involving substantial graphics-related tasks or certain types of machine learning workloads may be optimized for GPU-based compute instances 1315, and wireless-based applications may benefit most from running on wireless-optimized compute instances 1325.

[0107] Next, some of the instance families may include several instance categories that are distinguished from each other based on characteristics such as performance capabilities. For example, a small GPCI 1311 of the general-purpose compute instance 1310 may have fewer virtual CPUs and less available memory than a medium GPCI 1312, and then a medium GPCI 1312 may have fewer virtual CPUs and less available memory than a large GPCI 1313. Similarly, a small GPUCI 1316 of the GPU-based family may have fewer virtualized GPUs available for client applications than a medium GPUCI 1317, and a large GPUCI 1318 may have more available virtual GPUs than a medium GPUCI. More and / or faster persistent storage devices may be accessible from the large SCI 1323 of the memory-optimized compute instance 1320 than from the medium SCI 1322, and a small SCI 1321 may have less storage capacity or slower storage than a medium SCI.

[0108] In some embodiments, the Wireless Optimized Computing Instances (RCIs) 1325 may be categorized not only based on performance differences but also on the type of NFA accessible from the RCI. Within the performance capacity-based RCI types 1356, a small RCI 1326 may be capable of performing network functions at a slower aggregation rate than a medium RCI 1327 (and may also have fewer vCPUs and less memory), which in turn may be capable of performing network functions at a slower aggregation rate than a large RCI 1328 (and may also have fewer vCPUs and less memory). Several RCI categories may be defined in the embodiments described based on the type of NFA of the EVMOC accessible from the RCI. NFA category-based RCI types 1358 may include, for example, an NFA type A RCI 1329, which can be configured with a virtualization server that includes a type A NFA, and an NFA type B RCI 1330, which can be configured with a virtualization server that includes a type B NFA. RCIs may also be grouped into categories using a combination of available accelerator types and performance capabilities, for example, RCI categories such as "Small NFA-Type-A" and "Large NFA-Type-A" may be defined by the provider network. In at least one embodiment, the maximum number of NFAs that can be used in a wireless-based application implemented with the help of RCIs may be determined based on the RCI category. For example, suppose an EVMOC in an RPS has 16 NFAs. In some implementations, only a maximum of 4 of the 16 NFAs may be available from "small" RCIs, only a maximum of 8 of the 16 NFAs may be available from "medium" RCIs, and so on.

[0109] Figure 14 illustrates exemplary facilities and sites in which wireless-based application processing servers may be deployed, in at least some embodiments. In the embodiments depicted in Figure 14, the resources of the provider network 1410 may be organized into regional zones such as region R1 zone 1411A and region R2 zone 1411B. A given regional zone may then include one or more data centers located relatively close to each other (e.g., in the same state or metropolitan area). In the example shown in Figure 14, region R1 zone 1411A includes data centers 1412A and 1412B, and region R2 zone 1411B includes data centers 1412C, 1412D, and 1412E. Each such data center 1412 may include control plane servers and data plane resources and artifacts for one or more services, such as virtualized computing services (VCS) similar to VCS 110 in Figure 1, and / or wireless-based application management services (RBAMS).

[0110] The types of RPS described above may, in the embodiments described, consist of various facilities other than the provider network's own data center 1412, in response to program requests from clients. Such facilities may, in different embodiments, include, among other things, a cell site 1445, a client facility 1425 such as a local data center, a local zone 1440, and / or a point of presence site 1430. As shown, RPS 1460A and 1460B may be configured at the point of presence site 1430, for example, within a single rack. RPS 1460C and 1460D may be configured at the local zone 1440, RPS 1460F and 1460G may be configured at the client-owned facility 1425, and RPS 1460H and 1460J may be configured at a cell site (e.g., a room or group of rooms located next to a cell tower with antennas). In some embodiments, other types of facilities and locations may be used for RPS instead of, or in addition to, those shown in Figure 14. From each RPS in a given facility, in various embodiments, a connection can be established with a provider network control plane server and a radio unit (RU) typically located very close to or within the facility. After such a connection is verified, in various embodiments, software components such as isolated request handlers and L2Ps can be invoked on the RPS to handle the radio-based application workloads described above.

[0111] Figure 15 is a flowchart illustrating modes of operation that may be performed to manage a wireless-based application, including network functions, executed in an accelerator embedded within a virtualization management offload card, in at least some embodiments. As shown in element 1501, one or more control plane servers (CPS) of a cloud provider network's virtualized computing service (VCS) or wireless-based application management service (RBAMS) may assign network addresses (e.g., IP version 4 or IP version 6 addresses) that are part of the VCS's infrastructure or physical network to networking hardware devices (NHDs) embedded within an extended virtualization management offload card (EVMOC) of a wireless-based application processing server (RPS), which is also a virtualization server for the VCS. In at least some embodiments, the RPS may be located in a facility outside the VCS data center where the CPS is located, in order to enable some of the RBA operations to be performed closer to the RBA's antenna or end-user device, thereby supporting lower latency for such operations. EVMOC may also include a Network Function Accelerator (NFA), which is optimized to perform network functions in one or more layers of a radio-based technology stack, such as functions in the Distributed Unit (DU) layer of a 5G RAN stack, and is implemented using one or more dedicated chipsets. EVMOC may also include one or more virtualization management components used to start and manage one or more compute instances or virtual machines in a virtualization server, including a virtualization controller (which, among other tasks, may allocate a portion of the virtualization server's memory for each compute instance and start a hypervisor component that runs on the virtualization server's primary processor instead of an offload card), a network processing offloader, and so on. Performing a subset of virtualization management tasks on an offload card may allow more of the virtualization's primary processor and memory to be used for compute instances.Similar benefits can be achieved by offloading some of the network functions of one or more RBAs to an NFA instead of using the primary processor of the virtualization server for network functions, and furthermore, in at least some embodiments, the optimized circuitry of the NFA may be able to perform network function calculations faster than when the primary processor is used.

[0112] In the embodiments described, the CPS may assign addresses (different from the board network addresses) used for communication between the NFA and one or more radio units (RUs) of one or more RAN nodes of the RBA RBA1 (element 1504). Furthermore, in at least one embodiment, the CPS may assign addresses in an isolated virtual network (IVN) configured on a VCS client, on which at least some network functions of the RBA1 will be performed instead, to a virtual network interface (VNI) programmatically attached to a radio-optimized compute instance (RCI) running on the RPS. The RCI may be started, for example, using the virtualization controller and other virtualization management components of the RPS.

[0113] In various embodiments, the CPS may store configuration settings for the IVN and RCI, for example, in response to various program requests from a VCS client. Each set of such IVN configuration metadata may store for various categories of traffic, for example, in the embodiment described (element 1507), for general-purpose RCI traffic (e.g., network packets not transmitted as part of RBA1), fronthaul traffic for RBA1, and midhaul traffic for RBA1, effectively giving the VCS client similar types of configuration control over NFA traffic provided for RCI traffic. A given set of IVN configuration settings may include, for example, security groups (sets of firewall rules for inbound and outbound traffic related to VNI / RCI and / or NFA), network access control lists, traffic rate limits applied to inbound and / or outbound traffic, route table entries, and / or other routing information used for RCI and / or NFA traffic. In various embodiments, the CPS can have appropriate components of the system (such as virtualization management components operating on the RPS, network intermediary devices such as VCS routers) enforce security-related rules and rate limits. For example, before individual packets are delivered to / from the RCI or NFA, the VCS networking infrastructure can verify that the delivery of the packets will not violate applicable security rules and will not result in violations of applicable traffic rate limits.

[0114] In the embodiments described (element 1510), the CPS may automatically perform several other configuration-related tasks concerning RBAs such as RBA1 without requiring the continued participation of the VCS client. For example, the CPS may be involved in installing / updating firmware / software on the NFA, including bug fixes and security patches. In various embodiments, the CPS may monitor the health status of the NFA and RCI and provide indicators of health status to the VCS client via a programmatic interface. In at least some embodiments, the CPS may also monitor performance metrics from the NFA and RCI and provide a representation of the performance metrics to the VCS client via a programmatic interface. A graphical interface or dashboard may be implemented or utilized by the VCS control plane to present such information. In at least one embodiment, a decision may be made to migrate at least a portion of the workload of RBA1 to another RPS, at least in part on an analysis of collected metrics (such as performance metrics or health status metrics) and / or on a migration request programmatically submitted by the VCS client. As previously discussed, the CPS can orchestrate migration procedures that may require the replication of state information from the RCI, as well as state information of fronthaul and / or midhaul traffic (part of which may be obtained from the NFA) at the destination. In some embodiments, each virtualized representation of the NFA is provided to multiple RCIs running on the RPS, allowing several RBAs or RBA pipelines to run in parallel while sharing access to the NFA.

[0115] In various embodiments, each part of the logic of RBA1 may be performed in RCI and NFA. For example, in the downlink flow of RBA1 operation, some network functions of the DU of RBA1 may be performed in RCI in response to messages received via addresses assigned to the VNI of RCI from other components of RBA1 running on other servers (element 1513). Using the results or outputs of such network functions, additional network functions lower down the radio-based technology stack, such as various physical layer or L1 functions, may be performed in NFA (element 1516), and the results of these network functions may be transmitted from NFA to one or more RUs using addresses assigned to NFA for fronthaul communication. Traffic may also flow uplink in various embodiments, for example, from an end-user device through RU to NFA (where some network functions may be performed), and from NFA to RCI (where other network functions may be performed), and the results of network functions performed in RCI may potentially be transmitted to destinations outside the RPS. It should be noted that in various embodiments, some of the operations shown in the flowchart of Figure 16 may be implemented in a different order than shown in the figure, or may be executed in parallel rather than sequentially. Additionally, some of the operations shown in Figure 16 may not be required in one or more implementations.

[0116] Figure 16 illustrates exemplary programmatic interactions relating to a wireless-based application between a client and a provider network service, in at least some embodiments. In the embodiments described, the provider network service 1612 (such as a VCS or wireless-based application management service (RBAMS)) may implement a set of programmatic interfaces 1677, such as a web-based console, command-line tools, a graphical user interface, and APIs, which can be utilized by service clients to submit messages or requests to the service and receive corresponding responses.

[0117] Client 1610 may use the programmatic interface 1677 to send a RadioBasedApplicationsDescriptor message 1614 to service 1612 indicating a set of nearby cell locations where an RPS may be required, the expected workload at those locations (e.g., how many end-user devices are expected to be used at each location for the client's radio-based applications, such as a public or private 5G network, and what the approximate expected message rate from end-users is at different times of the day or on different days of the week), and the desired quality of service for the RBA (e.g., message latency for different types of traffic). The RadioBasedApplicationsDescriptor message 1614 may also include the client's preferences regarding single tenancy (e.g., whether the client desires exclusive use of the RPS and / or exclusive use of the NFA of such a card) versus multi-tenancy (e.g., whether the client desires to share the RPS and / or network function accelerator with other clients), and whether the client desires an NFA from a specific vendor or desires to use one of several vendors. Information provided by the client may be analyzed on the provider network, for example, by the configuration manager of the VCS control plane server, and recommendations for RPS configurations may be prepared that can be used to meet the estimated requirements of the client's application. For example, recommendations that may indicate the number and type of RPS suggested for each of one or more specific locations (point of presence sites, client-owned facilities, cell towers, etc.) may be provided to the client in one or more RecommendedRPSConfig messages 1615 in the embodiment described. Note that in some cases, some of the locations indicated in the recommendations may already have one or more RPS installed and configured for other clients that have previously submitted information about their own wireless-based application workloads.

[0118] If the client approves the recommendation, an RPSConfigApproved message 1617 may be sent to service 1612 via interface 1677. If a new RPS needs to be transported and installed at the approved recommended site, the process for doing so may be initiated by the provider network operator (note that this process may take some time, for example, several days). In some cases, additional RPS may be added to the set of pre-installed RPS (either used for other clients or not currently in use but configured in anticipation of client requirements) at one or more of the recommended sites to accommodate additional workloads indicated by the client. After the RPS to be used for the client (configured in multi-tenant mode or single-tenant mode, depending on the client's preference, or the default setting of service 1612 if the client does not indicate a tenant preference) has been identified and the connection between the RPS and the provider network control plane resources has been verified, an RPSsReady message 1621 may be sent to the client to indicate, in some embodiments, that the client can request the launch of compute instances for their radio-based applications. In some embodiments, the identifier for each RPS designated for client use may be provided in the RPSsReady message, and such identifiers can be used by the client to request the invocation of a wireless-optimized compute instance in the individual RPS. In some embodiments, before the client's wireless-optimized compute instance is invocation, service 1612 may also verify that connections have been established between the RPS designated for client use and (a) the RU (wireless unit) in the cell used for the client's application and (b) the resources used for the centralized unit (CU) and / or other layers of the application's stack. In other embodiments, such verification of connections to the RU and / or CU may be performed after the compute instance has been invocation.

[0119] In the embodiment depicted in Figure 16, client 1610 may use the programmatic interface 1677 to indicate preferences regarding various aspects of the configuration of the RBA components running with RPS, including, for example, information about the IVN on which the RCI is invoked (which may be created earlier in response to a program request from the client), preferred addresses or address ranges for various components of the RCI such as VNI or NFA, security rules for various categories of RBA traffic, and traffic rate limits. Such preferences may be indicated in one or more RBAConfigSettingsPreferences messages 1622 to service 1612. Preferences indicated by the client may be stored in the service repository, and an RBAConfigSettingsSaved message 1623 may be sent to the client.

[0120] In various embodiments, client 1610 may submit one or more LaunchRCIs requests 1624 via the programmatic interface 1677, for example, indicating a site / facility, ERG, or specific RPS where one or more RCIs of a specified category (such as the RCI types shown in Figure 13) will be instantiated for the client's application. In some embodiments, an RCIsLaunched message 1625 may be sent to client 1610 to confirm that the RCIs have been invoked. In some embodiments, configuration information about the invoked RCIs may be provided to the client, such as an instance identifier, IP address, etc. (which can be used to communicate with the client's application's CU, RU, and / or core network resources).

[0121] In at least one embodiment, a client may submit a GetTrafficCategoryMetrics request 1631 to service 1612 requesting metrics collected for one or more of the traffic categories shown in Figure 11 by one or more RPSs. The requested set of metrics may be provided to the client via one or more TCMetricSet messages 1633 in the embodiments described. For example, the client may obtain metrics for fronthaul traffic only, such as the number of messages transmitted to and from the RU during a given time interval, the total amount of data transferred to and from the RU, the latency of such messages, and whether any messages were lost. Similar sets of metrics may be provided for midhaul traffic, intra-IVN traffic, etc. In some implementations, metrics may be further decomposed by NHDs; for example, separate sets of metrics for a given category of traffic transmitted through two NHDs of an RPS may be provided to each NHD as needed. Other types of programmatic interactions relating to the implementation of wireless-based applications using provider network resources may be supported in several embodiments other than those shown in Figure 16.

[0122] In at least some embodiments, a server implementing the type of techniques described herein (e.g., various functions of a provider network service such as a VCS, including functions within a provider network service and functions at extended sites) may include a general-purpose computer system that includes, or is configured to access, one or more computer-accessible media. Figure 17 illustrates such a general-purpose computing device 9000. In the illustrated embodiment, the computing device 9000 includes one or more processors 9010 coupled to system memory 9020 (which may include both non-volatile and volatile memory modules) via an input / output (I / O) interface 9030. The computing device 9000 further includes a network interface 9040 coupled to the I / O interface 9030.

[0123] In various embodiments, the computing device 9000 may be a uniprocessor system including one processor 9010, or a multiprocessor system including several processors 9010 (e.g., two, four, eight, or another preferred number). A processor 9010 may be any preferred processor capable of executing instructions. For example, in various embodiments, a processor 9010 may be a general-purpose or embedded processor implementing one of several instruction set architectures (ISAs), such as x86, PowerPC, SPARC, ARM, or MIPS ISA, or any other preferred ISA. In a multiprocessor system, each of the processors 9010 may, but not necessarily, implement the same ISA in common. In some implementations, a graphics processing unit (GPU) and / or a field-programmable gate array (FPGA) may be used instead of, or in addition to, a conventional processor.

[0124] The system memory 9020 may be configured to store instructions and data accessible by the processor 9010. In at least some embodiments, the system memory 9020 may include both a volatile portion and a non-volatile portion, while in other embodiments, only volatile memory may be used. In various embodiments, the volatile portion of the system memory 9020 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM, or any other type of memory. With respect to the non-volatile portion of the system memory (which may include, for example, one or more NVDIMMs), in some embodiments, a flash-based memory device including a NAND flash device may be used. In at least some embodiments, the non-volatile portion of the system memory may include a power source, such as a supercapacitor or other energy storage device (e.g., a battery). In various embodiments, one of memristor-based resistive random access memory (ReRAM), three-dimensional NAND technology, ferroelectric RAM, magnetoresistive RAM (MRAM), or various types of phase-change memory (PCM) may be used for at least the non-volatile portion of the system memory. In the illustrated embodiments, it is shown that program instructions and data implementing one or more desired functions, such as the methods, techniques, and data described above, are stored in system memory 9020 as code 9025 and data 9026.

[0125] In one embodiment, the I / O interface 9030 may be configured to coordinate I / O traffic between the processor 9010, the system memory 9020, and any peripheral devices within the device, including the network interface 9040 or other peripheral interfaces such as various types of persistent and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., the system memory 9020) into a format suitable for use by another component (e.g., the processor 9010). In some embodiments, the I / O interface 9030 may include support for devices added through various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, the functionality of the I / O interface 9030 may be divided into two or more separate components, such as a northbridge and a southbridge. Furthermore, in some embodiments, some or all of the functions of the I / O interface 9030, such as the interface to the system memory 9020, may be directly incorporated into the processor 9010.

[0126] The network interface 9040 may be configured to enable data exchange between the computing device 9000 and other devices 9060 attached to the network 9050, such as other computer systems or devices illustrated in Figures 1 to 16. In various embodiments, the network interface 9040 may support communication over any suitable wired or wireless general data network, such as an Ethernet network. Additionally, the network interface 9040 may support communication over telecommunications / telephone networks, such as analog voice networks or digital fiber optic networks, communication over storage area networks, such as Fibre Channel SANs, or communication over any other suitable type of network and / or protocol.

[0127] In some embodiments, system memory 9020 may represent an embodiment of a computer-accessible medium configured to store at least a subset of program instructions and data used to implement the methods and apparatus considered in the context of Figures 1 to 16. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible media. Generally speaking, computer-accessible media may include non-temporary storage media or memory media such as magnetic or optical media, such as disks or DVDs / CDs, coupled to computing device 9000 via the I / O interface 9030. Non-temporary computer-accessible storage media may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, which may be included in some embodiments of computing device 9000 as system memory 9020 or other types of memory. In some embodiments, multiple non-temporary computer-readable storage media may collectively store program instructions that, when executed on or across one or more processors, implement at least a subset of the methods and techniques described above. Computer-accessible media may further include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted via communication media such as networks and / or wireless links, including those that can be implemented via network interface 9040. Parts or all of multiple computing devices, such as those illustrated in Figure 17, may be used to implement the functions described in various embodiments; for example, software components running on various different devices and servers may work together to provide functionality. In some embodiments, parts of the described functionality may be implemented using storage devices, network devices, or dedicated computer systems, in addition to, or instead of, using a general-purpose computer system. As used herein, the term “computing device” refers to, but is not limited to, at least all of these types of devices.

[0128] conclusion Embodiments of this disclosure can be described in light of the following clauses. Clause 1. A system, A set of control plane servers for virtualized computing services in a cloud provider network, A virtualization server comprising a primary processor and an offload card, wherein the offload card includes (a) a virtualization controller for compute instances launched on the virtualization server, (b) a network function accelerator for wireless-based applications, and (c) a networking hardware device, A set of control plane servers, Assigning a first network address within the underlying network of the virtualization computing service to a networking hardware device, which is used for communication with one or more resources in the cloud provider network located outside the virtualization server, At least using a virtualization controller, assign a second network address to a first compute instance launched on a virtualization server, wherein the second network address is not within the underlying network. The network function accelerator is configured to assign a third network address used for communication between the network function accelerator and one or more radio units (RUs) of one or more wireless-based applications, When the virtualization server stores the instruction and the instruction is executed on the primary processor, In response to a message received by the first computing instance, the first computing instance is made to execute a first network function of a first wireless-based application, wherein the message is received using a mapping between a second network address and a first network address. A system that causes a network function accelerator to execute a second network function of a first wireless-based application, at least in part, based on the results of a first network function, wherein the output of the second network function is transmitted to the wireless unit of the first wireless-based application using a third network address. Clause 2. The system described in Clause 1, wherein the set of control plane servers is located in a data center of the cloud provider network, and the virtualization servers are located in a facility outside the data center. Clause 3. When the virtualization server stores further instructions and those instructions are executed on the primary processor, The presenting of a first virtualized representation of a network function accelerator to a first compute instance, wherein a second network function is executed in response to a first request from the first compute instance, and the first request is received by the network function accelerator via the interface of the first virtualized representation. The system according to Clause 1 or 2, which causes a second virtualized representation of a network function accelerator to be presented to a second compute instance started on a virtualization server, wherein in response to a second request from the second compute instance, a third network function is executed on the network function accelerator, the third network function is part of a second wireless-based application, and the second request from the second compute instance is received by the network function accelerator using the interface of the second virtualized representation. Clause 4. A system described in any one of Clauses 1 to 3, wherein the first network function is the network function of a distributed unit (DU) of a wireless-based technology stack. Clause 5. A system described in any one of Clauses 1 to 4, wherein the second network function is the network function of the physical layer of the wireless-based technology stack. Article 6. Computer implementation method, The control plane server of the cloud provider network's virtualized computing service performs one or more configuration operations on the offload card of a virtualization server, wherein the offload card includes (a) a virtualization controller for compute instances, (b) a first network function accelerator for wireless-based applications, and (c) a networking hardware device, and the one or more configuration operations perform one or more configuration operations, including assigning a first network address to the networking hardware device and assigning a second network address to the first network function accelerator. The process involves, at least using a virtualization controller, a control plane server to start a first compute instance on a virtualization server, the first compute instance to start and execute a first network function of a first wireless-based application in response to a message received using a first network address, and A computer implementation method comprising: causing a second network function of a first wireless-based application to be executed on a first network function accelerator in response to an output obtained from a first network function, wherein the output of the second network function is sent to an external destination of a virtualization server using the second network address as the source address. Clause 7.1 or more configuration operations, The computer implementation method described in Clause 6, which includes updating the firmware or software of the first network function accelerator. Clause 8.1 or more configuration operations, To monitor the health status of the first network function accelerator, A computer implementation method as described in Clause 6 or 7, which includes providing an indicator of health status through a programmatic interface for a virtualized computing service. Clause 9.1 or more configuration operations, Monitoring the performance metrics of the first network function accelerator, A computer implementation method as described in any one of Clauses 6 to 8, including providing performance metrics through a programmatic interface for a virtualized computing service. Clause 10.1 or more configuration operations, A computer implementation method as described in any one of clauses 6 to 9, including applying security patches to the first network function accelerator. Clause 11.1 or more configuration operations, A computer implementation method according to any one of clauses 6 to 10, comprising scrubbing the contents of the memory of a first network function accelerator in response to detecting that a first computation instance has been terminated. Article 12. Presenting a first virtualized representation of the first network function accelerator, enabling the first compute instance to transmit requests for network functions of the first wireless-based application to the first network function accelerator, A computer implementation method according to any one of Clauses 6 to 11, further comprising presenting a second virtualized representation of a first network function accelerator, enabling a second compute instance, launched on a virtualization server using at least a virtualization controller, to transmit requests for network functions of a second wireless-based application to the first network function accelerator. Article 13. A computer implementation method according to any one of Clauses 6 to 12, wherein a control plane server migrates at least a portion of the workload of a first wireless-based application to another virtualization server, the other virtualization server includes an offload card with a second network function accelerator, and as a result of the migration, further includes (a) messages from the wireless units of the first wireless-based application are delivered to the second network function accelerator, and (b) the migrated version of the first compute instance is migrated to another virtualization server on the other virtualization server, which performs the first network function of the first wireless-based application. Clause 14. A computer implementation method described in any one of Clauses 6 to 13, wherein the second network function includes the L1 network function of a wireless-based technology stack. Clause 15. A computer implementation method as described in any one of Clauses 6 to 14, wherein the first network function includes the network function of a distributed unit (DU) of a wireless-based technology stack. Clause 16. A non-temporary computer-accessible storage medium that stores program instructions, which implements a control plane server for virtualized computing services when executed on a processor, and which the control plane server Assigning a first network address to the networking hardware device of the offload card of a virtualization server, wherein the offload card includes (a) a network function accelerator for wireless-based applications and (b) a virtualization controller for compute instances, and the assignment of the first network address to the offload card. Assigning a second network address to a network function accelerator, wherein the second network address is used for communication between the network function accelerator and the wireless unit of a wireless-based application. A non-temporary computer-accessible storage medium configured to use a virtualization controller to start a compute instance in a virtualization server, wherein the compute instance starts a compute instance that (a) executes a first network function of a wireless-based application in response to a request received using a first network address, and (b) requests the execution of a second network function of a wireless-based application in a network function accelerator, and the output of the second network function is transmitted to a wireless unit using a second network address. Clause 17. The control plane server, A non-temporary computer-accessible storage medium as described in Clause 16, further configured to update the firmware or software of a network function accelerator. Clause 18. The control plane server, Monitoring the health status of the network function accelerator, A non-temporary computer-accessible storage medium as described in Clause 16 or 17, further configured to display indicators of health status via a programmatic interface for virtualized computing services. Clause 19. A non-temporary computer-accessible storage medium as described in any one of Clauses 16 to 18, wherein the second network function includes the L1 network function of a wireless-based technology stack. Clause 20. A non-temporary computer-accessible storage medium as described in any one of Clauses 16 to 19, wherein the first network function includes the network function of a distributed unit (DU) of a wireless-based technology stack. Clause 21. Server, Processor and Memory and An offload card comprising (a) a virtualization controller and (b) a network function accelerator for wireless-based applications, The virtualization controller Performing one or more configuration tasks on a compute instance launched on the server, including allocating at least a portion of the memory used by the compute instance, When memory stores instructions and instructions are executed on the processor, To perform the first network function of a wireless-based application in a compute instance, A server configured to provide the output of a first network function as input to a second network function of a wireless-based application, wherein the second network function is executed by a network function accelerator and the output of the first network function is provided as input. Clause 22. The offload card includes a network processing offloader and a networking hardware device to which a network address within the underlying network of the virtualization computing service is assigned, and the network processing offloader is The server described in Clause 21, which is configured to use networking hardware devices to transmit one or more messages associated with a wireless-based application from a compute instance to a destination outside the server. Clause 23. The server as described in Clause 21, wherein the offload card includes a first networking hardware device and a second networking hardware device, the first networking hardware device being used to transmit messages to a first set of destinations including centralized units (CUs) of wireless-based applications, and the second networking hardware device being used to transmit messages to a second set of destinations including wireless units (RUs) of wireless-based applications. Clause 24. The offload card includes another network function accelerator, and its memory stores further instructions, and when the instructions are executed on the processor, A server as described in Clause 21 or 22, which causes input to be provided to a third network function executed by another network function accelerator. Clause 25. A server as described in Clause 24, in which a third network function is performed as part of another wireless-based application. Article 26. Computer implementation method, The virtualization controller operating on the server's offload card performs one or more configuration tasks relating to a first compute instance started on the server, including allocating at least a portion of the server's memory used by the first compute instance, wherein the offload card includes a first network function accelerator for wireless-based applications. Executing the first network function of the first wireless-based application in the first computing instance, A computer implementation method comprising: performing a second network function of a first wireless-based application in a first network function accelerator, wherein the input of the second network function is at least partially based on the output of the first network function. Clause 27. The offload card includes a first networking hardware device to which a first network address within the underlying network of the virtualization computing service is assigned, and the computer implementation method is The computer implementation method described in Clause 26 further includes using a first networking hardware device to transmit one or more messages associated with a first wireless-based application from a first computing instance to a second computing instance. Clause 28. The computer implementation method described in Clause 27, wherein the offload card includes a second networking hardware device, the first networking hardware device is used to transmit messages to a first set of destinations including centralized units (CUs) of a first wireless-based application running on a second compute instance, and the second networking hardware device is used to transmit messages to a second set of destinations including wireless units (RUs) of the first wireless-based application. Clause 29. The computer implementation method described in Clause 28, wherein the second networking hardware device is assigned to a second network address within an isolated virtual network of the virtualized computing service. Clause 30. The off-road card includes a second network function accelerator, and the computer implementation method is The computer implementation method described in Clause 26, further comprising performing a third network function in a second network function accelerator. Clause 31. The computer implementation method described in Clause 30, wherein the third network function is performed as part of the second wireless-based application. Article 32. Presenting a first virtualized representation of the first network function accelerator to a first compute instance, thereby enabling the transmission of network function requests from a first wireless-based application from the first compute instance to the first network function accelerator, The computer implementation method according to Clause 26, further comprising presenting a second virtualized representation of the first network function accelerator to a second compute instance started on a server, thereby enabling the transmission of network function requests of a second wireless-based application from the second compute instance to the first network function accelerator. Article 33. A computer implementation method according to any one of clauses 26, 27, 30, or 32, further comprising updating the firmware or software of a first network function accelerator in response to a message received from a control plane server of a virtualization computing service. Clause 34. A computer implementation method according to any one of Clauses 26, 27, 30, 32, or 33, wherein the first network function implements at least a portion of one of the following: (a) a distributed unit (DU) of a radio access network (RAN), or (b) a centralized unit (CU) of a RAN node, or (c) a core network of a radio-based technology stack. Clause 35. A computer implementation method as described in any one of Clauses 26, 27, 30, or 32-34, wherein the second network function implements the L1 network function of a wireless-based technology stack. Clause 36. A non-temporary computer-accessible storage medium for storing program instructions, wherein the program instructions are executed on the processor of the server's offload card. Perform one or more virtualization management tasks on a compute instance launched on a server, including allocating at least a portion of the server memory used by the compute instance. From the compute instance, retrieve the request for the first network function of the wireless-based application. A non-temporary computer-accessible storage medium that performs a first network function in a network function accelerator embedded within an off-road card. Clause 37. An offload card linked to the server's processor via a peripheral interface, a non-temporary computer-accessible storage medium as described in Clause 36. Clause 38. Store further program instructions, and when the program instructions are executed on the processor of the offload card, From another compute instance, retrieve the request for the second network function. A non-temporary computer-accessible storage medium as described in Clause 36 or 37, which performs a second network function in a network function accelerator. Clause 39. A non-temporary computer-accessible storage medium as described in any one of Clauses 36 to 38, wherein the first network function implements at least a portion of one of the following: (a) a distributed unit (DU) of a radio access network (RAN) node, (b) a central unit (CU) of a RAN node, or (c) the core network of a radio-based technology stack. Clause 40. The offload card includes a first networking hardware device, and a non-temporary computer-accessible storage medium stores further program instructions, and when the program instructions are executed on the processor of the offload card, A non-temporary computer-accessible storage medium as described in any one of clauses 36 to 39, which uses a first networking hardware device to transmit one or more messages associated with a wireless-based application to a destination outside the server. Article 41. A system, The control plane server for virtualized computing services in a cloud provider network, A virtualization server including a network function accelerator for wireless-based applications, The control plane server, Establishing isolated virtual networks on behalf of clients of virtualization computing services, In response to a first request submitted by a client via the programmatic interface of the virtualization computing service, the system stores in a repository of metadata for isolated virtual networks a representation of a first security group associated with a compute instance launched on the virtualization server, wherein the compute instance is assigned a network address within the isolated virtual network, the first security group includes a first restriction on the sources of inbound traffic directed to the compute instance, and the compute instance performs a first network function for a wireless-based application. In response to a second request submitted by the client via a programmatic interface, the repository stores a representation of a second security group associated with a network function accelerator, wherein the second security group includes a second restriction on the destination of outbound traffic from the network function accelerator, and the network function accelerator performs a second network function for a wireless-based application. The method involves using a network address as the destination address to verify that a first network message conforms to a first constraint before delivering the first network message of a wireless-based application to a compute instance, and verifying that the first network message results in at least partially the execution of a first network function. A system configured to verify that a second network message of a wireless-based application conforms to a second restriction before it is delivered from a network function accelerator to a destination, such that the output of the first network function results in at least a partial execution of the second network function. Clause 42. The control plane server, The system described in Clause 41, further configured to prevent a third network message originating from a network function accelerator from being delivered to its destination in response to a determination that the delivery of the third network message would violate the rate limit associated with the network function accelerator's traffic. Clause 43. The virtualization server includes an offload card, the offload card includes a network function accelerator and a virtualization controller, and the control plane server includes The system described in Clause 41 or 42, further configured to launch compute instances using a virtualization controller in response to another request. Clause 44. The control plane server, The system described in any one of Clauses 41 to 43, which in response to another request stores route table entries for midhaul traffic of a wireless-based application in the route table of an isolated virtual network, the system further configured to store that the midhaul traffic includes messages generated in a distributed unit (DU) of the wireless-based application and directed to a centralized unit (CU) of the wireless-based application, and that the messages are generated in a virtualization server. Clause 45. The control plane server, A system as described in any one of clauses 41 to 44, further configured to assign network addresses from a range of network addresses of an isolated virtual network to a network function accelerator. Article 46. Computer implementation method, In response to a first program request, to store a representation of a first set of configuration settings for a compute instance configured within an isolated virtual network and launched on a virtualization server, wherein the compute instance implements first network functions for a wireless-based application, the virtualization server includes network function accelerators for the wireless-based application, and the first set of configuration settings includes a first set of network security rules applied to the traffic of the compute instance. In response to a second program request, store a representation of a second set of configuration settings for a network function accelerator, wherein the second set of configuration settings includes a second set of network security rules applied to the traffic of the network function accelerator. Before delivering the first network message to the compute instance, verify that the first network message conforms to the first network security rule set, and verify that the delivery of the first network message results in the execution of the first network function on the compute instance. A computer implementation method comprising verifying that a second network message conforms to a second network security rule set before delivering the second network message from a network function accelerator to an external destination of a virtualization server, wherein the second network message includes the output of a second network function performed by the network function accelerator. Clause 47. A virtualization server includes an offload card, and the offload card includes a network function accelerator and a virtualization controller, and the computer implementation method is The computer implementation method described in Clause 46 further includes launching compute instances using a virtualization controller in response to another program request. Article 48. The computer implementation method according to Clause 46 or 47, which in response to another program request, stores route table entries for midhaul traffic of a wireless-based application in the route table of an isolated virtual network, further comprising storing that the midhaul traffic includes messages generated in a distributed unit (DU) of the wireless-based application and directed to a centralized unit (CU) of the wireless-based application, and that the messages are generated in a virtualization server. Clause 49. A second set of network security rules is applied to traffic between the network function accelerator and the wireless unit of a wireless-based application, and the computer implementation method is: A computer implementation method according to any one of clauses 46 to 48, further comprising storing a third set of network security rules that apply to traffic between a network function accelerator and a centralized unit of wireless-based applications. Article 50. A computer implementation method according to any one of clauses 46 to 49, further comprising assigning a network address to a network function accelerator from a range of network addresses of an isolated virtual network. Clause 51. A computer implementation method as described in any one of Clauses 46-50, wherein the second network security rule set includes a network access control list that applies to at least a portion of the traffic of the network function accelerator, and the network access control list applies to subnets defined within an isolated virtual network. Clause 52. A computer implementation method according to any one of Clauses 46 to 51, wherein the first network message is formatted in accordance with the Internet Protocol (IP) and the second network message is formatted in accordance with the Common Public Radio Interface (CPRI) or the Extended Common Public Radio Interface (eCPRI). Clause 53. A computer implementation method as described in any one of Clauses 46 to 52, wherein the second network function includes the L1 network function of a wireless-based technology stack. Clause 54. A computer implementation method as described in any one of Clauses 46 to 53, wherein the first network function includes the network function of a distributed unit (DU) of a wireless-based technology stack. Clause 55. A virtualization server includes an offload card, and the offload card includes a network function accelerator and networking hardware devices, and the computer implementation method is The computer implementation method described in Clause 46, further comprising (a) assigning a first network address of the underlying network of the virtualized computing service to a networking hardware device, and (b) assigning a second network address to a compute instance, wherein the second network address is not part of the underlying network and network messages originating from sources outside the virtualization server are delivered to the compute instance using a mapping between the first network address and the second network address. Clause 56. A non-temporary computer-accessible storage medium that stores program instructions, which implements a control plane server for virtualized computing services when executed on a processor, and which the control plane server In response to a first program request, to store a representation of a first set of configuration settings for a compute instance configured within an isolated virtual network and launched on a virtualization server, wherein the compute instance implements first network functions for a wireless-based application, the virtualization server includes network function accelerators for the wireless-based application, and the first set of configuration settings includes a first set of network security rules applied to the traffic of the compute instance. In response to a second program request, store a representation of a second set of configuration settings for a network function accelerator, wherein the second set of configuration settings includes a second set of network security rules applied to the traffic of the network function accelerator. Before delivering the first network message to the compute instance, verify that the first network message conforms to the first network security rule set, and verify that the delivery of the first message results in the execution of the first network function on the compute instance. A non-temporary computer-accessible storage medium is configured to verify that a second network message conforms to a second network security rule set before it is delivered from a network function accelerator to an external destination of a virtualization server, and to verify that the second network message includes the output of a second network function. Clause 57. The virtualization server includes an offload card, the offload card includes a network function accelerator and a virtualization controller, and the control plane server includes A non-temporary computer-accessible storage medium as described in Clause 56, further configured to launch compute instances using a virtualization controller in response to another program request. Clause 58. The control plane server, A non-temporary computer-accessible storage medium as described in Clause 56 or 57, which in response to another program request, stores route table entries for midhaul traffic for a wireless-based application in the route table of an isolated virtual network, the midhaul traffic includes messages generated in a distributed unit (DU) of the wireless-based application and directed to a centralized unit (CU) of the wireless-based application, and the messages are generated in a virtualization server, and is further configured to store these messages. Clause 59. A second set of network security rules is applied to traffic between the network function accelerator and the radio unit of a wireless-based application, and the control plane server, A non-temporary computer-accessible storage medium as described in any one of clauses 56 to 58, further configured to store a third set of network security rules that apply to traffic between a network function accelerator and a centralized unit of wireless-based applications in response to another program request. Clause 60. The control plane server, A non-temporary computer-accessible storage medium as described in any one of clauses 56 to 59, further configured to assign a network address from a range of network addresses of an isolated virtual network to a network function accelerator in response to another program request.

[0129] Various embodiments may further include receiving, transmitting, or storing instructions and / or data implemented in accordance with the foregoing description on a computer-accessible medium. Generally speaking, computer-accessible mediums may include magnetic or optical media, such as disks or DVD / CD-ROMs, volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), storage media or memory media such as ROM, and transmission media or signals such as electrical, electromagnetic, or digital signals transmitted over communication media such as networks and / or wireless links.

[0130] The various methods illustrated in the drawings and described herein represent exemplary embodiments of the methods. The methods may be implemented in software, hardware, or a combination thereof. The order of the methods may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc.

[0131] Various modifications and changes may be made, as will be apparent to those skilled in the art who are interested in this disclosure. All such modifications and changes are intended to be accepted, and therefore the above description should be considered illustrative rather than restrictive.

Claims

1. It is a system, Equipped with one or more computing devices, The one or more computing devices, when executed on or across the one or more computing devices, include instructions that cause the one or more computing devices to implement a control plane server for virtualization computing services, and the control plane server, Assigning a first network address to a networking hardware device of a single offload card of a virtualization server, wherein the single offload card includes both (a) a network function accelerator for wireless-based applications and (b) a virtualization controller for compute instances, Assigning a second network address to the network function accelerator, wherein the second network address is used for communication between the network function accelerator and the wireless unit of a wireless-based application. A system configured to use the virtualization controller to start a first compute instance in the virtualization server, wherein the first compute instance is configured to (a) execute a first network function of the wireless-based application in response to a first request received using the first network address, and (b) start the first compute instance which requests the execution of a second network function of the wireless-based application in the network function accelerator, and the output of the second network function is transmitted to the wireless unit using the second network address.

2. The system according to claim 1, wherein the control plane server is located in a data center of the cloud provider network, and the virtualization server is located in a facility outside the data center.

3. The control plane server, The first virtualization representation of the network function accelerator is presented to the first computing instance, and the execution of the second network function in the network function accelerator is requested by the first computing instance via the interface of the first virtualization representation. The system according to claim 1, further configured to present a second virtualization representation of the network function accelerator to a second computing instance started in the virtualization server, wherein the execution of a third network function in the network function accelerator is requested by the second computing instance via the interface of the second virtualization representation.

4. The system according to claim 1, wherein the first network function is a network function of a distributed unit (DU) of a wireless-based technology stack.

5. The system according to claim 1, wherein the second network function is a network function of the physical layer of a wireless-based technology stack.

6. A computer implementation method, wherein a control plane server for virtualized computing services is used. Assigning a first network address to a networking hardware device of a single offload card of a virtualization server, wherein the single offload card includes both (a) a first network function accelerator for wireless-based applications and (b) a virtualization controller for compute instances, and the assignment of the first network address. Assigning a second network address to the first network function accelerator, wherein the second network address is used for communication between the first network function accelerator and the wireless unit of a wireless-based application. A computer implementation method comprising: using the virtualization controller to start a compute instance in the virtualization server, the compute instance performing (a) a first network function of the wireless-based application in response to a request received using the first network address, and (b) a request for the execution of a second network function of the wireless-based application in the first network function accelerator, wherein the output of the second network function is transmitted to the wireless unit using the second network address.

7. The control plane server, The computer implementation method according to claim 6, further comprising updating the firmware or software of the first network function accelerator.

8. The control plane server, Monitoring the health status of the first network function accelerator, The computer implementation method according to claim 6, further comprising providing an indicator of the health status via a programmatic interface of the virtualized computing service.

9. The control plane server, Monitoring the performance metrics of the first network function accelerator, The computer implementation method according to claim 6, further comprising providing performance metrics via the programmatic interface of the virtualized computing service.

10. The control plane server, The computer implementation method according to claim 6, further comprising performing the action of applying a security patch to the first network function accelerator.

11. The control plane server, The computer implementation method according to claim 6, further comprising scrubbing the contents of the memory of the first network function accelerator in response to detecting that the computation instance has been terminated.

12. The control plane server, A computer implementation method according to claim 6, further comprising migrating at least a portion of the workload of the wireless-based application to another virtualization server, the other virtualization server including an offload card with a second network function accelerator, and as a result of the migration, (a) messages from the wireless unit of the wireless-based application are delivered to the second network function accelerator, and (b) the migrated version of the compute instance is migrated on the other virtualization server to another virtualization server that runs the first network function of the wireless-based application.

13. The computer implementation method according to claim 6, wherein the second network function includes an L1 network function of a wireless-based technology stack.

14. A non-temporary computer-accessible storage medium that stores program instructions, which implements a control plane server for virtualized computing services when executed on a processor, wherein the control plane server Assigning a first network address to a networking hardware device of a single offload card of a virtualization server, wherein the single offload card includes both (a) a network function accelerator for wireless-based applications and (b) a virtualization controller for compute instances, Assigning a second network address to the network function accelerator, wherein the second network address is used for communication between the network function accelerator and the wireless unit of a wireless-based application. A non-temporary computer-accessible storage medium configured to use the virtualization controller to start a compute instance in the virtualization server, wherein the compute instance starts the compute instance such that (a) it executes a first network function of the wireless-based application in response to a request received using the first network address, and (b) it requests the network function accelerator to execute a second network function of the wireless-based application, and the output of the second network function is transmitted to the wireless unit using the second network address.

15. The control plane server, Monitoring the health status of the aforementioned network function accelerator, The non-temporary computer-accessible storage medium according to claim 14, further configured to display an indicator of the health status via the programmatic interface of the virtualization computing service.

Images