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 technology]

[0001] Several generations of broadband cellular communications technology have been deployed in recent years. 5G is the fifth-generation technology standard for broadband cellular networks and is gradually replacing the fourth-generation (4G) standard, 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. While some 5G cells employ frequency spectrum similar to 4G, other 5G cells may employ frequency spectrum 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 explanation of the drawings]

[0002] [Figure 1] Illustrates an exemplary system environment in which a virtualization server in which a virtualization management offload card includes a hardware network function accelerator, according to at least some embodiments, may be employed to run wireless-based applications that utilize at least in part the resources of virtualized computing services. [Figure 2] 1 illustrates an example configuration of a wireless-based application processing server with partially offloaded virtualization management functionality, according to at least some embodiments. [Figure 3] 1 illustrates an overview of user plane and control plane layers defined in accordance with technical standards for radio-based applications, according to at least some embodiments. [Figure 4] 1 illustrates an example uplink and downlink pipeline of network functions for a wireless-based application, according to at least some embodiments. [Figure 5] 1 illustrates example network functions that may be performed at the physical layer of a wireless-based technology stack, according to at least some embodiments. [Figure 6] 1 illustrates an example hierarchy of devices that may be used for wireless-based applications, according to at least some embodiments. [Figure 7] 1 illustrates an exemplary deployment of an L2 implementation of a wireless-based technology stack in a wireless-based application processing server, according to at least some embodiments. [Figure 8] 1 illustrates an exemplary presentation of a virtualized representation of a hardware network function accelerator for a compute instance running on a virtualized server, according to at least some embodiments. [Figure 9] 1 illustrates exemplary network function accelerator configuration management tasks that may be performed by or initiated by a control plane server of a virtualized computing service, according to at least some embodiments. [Figure 10] 1 illustrates aspects of workload migration techniques that may be employed for wireless-based applications, according to at least some embodiments. [Figure 11] 1 illustrates exemplary categories of network traffic for a wireless-based application processing server, according to at least some embodiments. [Figure 12] 1 illustrates example categories of isolated virtual network metadata associated with a wireless-based application processing server, according to at least some embodiments. [Figure 13] 1 illustrates exemplary categories of compute instances that may be configured on behalf of a client of a virtualized computing service, according to at least some embodiments. [Figure 14] 1 illustrates exemplary facilities and sites where wireless-based application processing servers may be deployed, according to at least some embodiments. [Figure 15]FIG. 1 is a flow diagram illustrating aspects of operations that may be performed to manage a wireless-based application that includes network functions that execute in an accelerator embedded within a virtualization management offload card, according to at least some embodiments. [Figure 16] 1 illustrates an exemplary programmatic interaction between a client and a provider network service for a wireless-based application, according to at least some embodiments. [Figure 17] FIG. 1 is a block diagram illustrating an example computing device that may be used in at least some embodiments.

[0003] Although embodiments are described herein by way of example in certain embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and their detailed description are not intended to limit the embodiments to the particular forms disclosed; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or claims. As used throughout this application, the word "may" is used in an permissive sense (i.e., meaning having the possibility of), rather than a mandatory sense (i.e., meaning must). Similarly, the words "include," "including," and "includes" mean including, but not limited to, something. When used in the claims, the term "or" is used as an inclusive or, not an exclusive or. For example, the phrase "at least one of x, y, or z" means any one of x, y, and z, and any combination thereof. Unless expressly stated otherwise, articles such as "a" or "an" should generally be construed throughout this application to include one or more listed items. Thus, a phrase such as "a device configured to" is intended to include one or more listed devices. Such one or more listed devices may also be collectively configured to perform the listed items. For example, "a processor configured to perform items A, B, and C" may include a first processor configured to perform item A and a second processor configured to perform items B and C, operatively operating in conjunction therewith. Unless expressly stated otherwise, the term "set" should generally be construed throughout this application to include one or more listed items. Thus, a phrase such as "a set of devices configured to" is intended to include one or more listed devices.Such one or more enumerated devices may also be collectively configured to implement the described enumerations. For example, a "set of servers configured to implement enumerations A, B, and C" may include a first server configured to implement enumeration A and a second server operating in conjunction therewith configured to implement enumerations B and C. DETAILED DESCRIPTION OF THE INVENTION

[0004] The present disclosure relates to methods and apparatus for executing wireless-based applications using a virtualization server equipped with an offload card including network function accelerator hardware, a virtualization management component, and a networking hardware device. 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 a network, whereby the virtualization server includes 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 launch of the compute instances on the virtualization server. The network function accelerators (“NFAs”) of the RPS can be used to implement portions of the functionality of various wireless-based or telecommunication 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 NFAs can perform certain L1 (or PHY) functions of the Radio Access Network (“RAN”) protocol stack, also referred to as real-time baseband processing. A control plane server of a virtualized computing service (VCS) can communicate with a virtualization management component on the offload card via a networking hardware device to initiate various types of management tasks on the server, including, for example, launching or terminating compute instances or virtual machines. The offload cards can help reduce the workload of the primary processor (e.g., CPU) of the virtualized 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 network functions of wireless-based applications that would also otherwise be performed on the primary processor.Additionally, the NFA may perform at least some network functions faster than is possible using the primary processor, e.g., using a custom chipset designed specifically for the network functions. For example, the NFA may include a mix of digital signal processor (DSP) and advanced RISC machine (ARM) cores optimized for L1 processing tasks.

[0005] Embedding the NFA in a virtualized management offload card (VMOC) also enables a 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 for radio-based applications (RBAs) that use the NFA for network functions, and providing isolated virtual network (IVN) capabilities such as security groups and customizable routing for the NFA. In contrast to alternative approaches where an NFA card embedded in a larger server design can be accessed in a non-virtualized manner from bare-metal compute instances, the NFA embedded within the virtualized management offload card (VMOC) can be presented in a virtualized fashion to multiple compute instances running in the RPS, thereby simplifying network slicing for the RBA. While the control plane server is located in a data center in the cloud provider network, the RPS itself can be located in a facility chosen by the RBA owner based, for example, 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 one skilled in the art will understand in light of this disclosure, particular embodiments may be capable of achieving various advantages, including some or all of the following: (a) enabling new radio-based applications to be brought online quickly and maintained using the proven resource provisioning, scalability, and availability techniques of the provider network; (b) reducing the computing, memory, storage resources, and power used for radio-based applications, for example, by intelligently distributing and / or migrating workloads at various granularities across available resources and sharing resources among multiple applications; and / or (c) improving the user experience for administrators of radio-based applications by simplifying the administration and management of applications using provider network tools and interfaces.

[0007] According to some embodiments, a system may include a set of one or more control plane servers (CPSs) of a VCS of a cloud provider network and a virtualization server including one or more primary processors (e.g., CPUs) and an offload card. The offload card may include (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 an operator of the provider network. In some embodiments, the offload card may include one or more memories and one or more processors, where the memory or memories store instructions that, when executed on the processors, implement communication-related tasks performed using logic of the virtualization controller, the NFA, and the NHD. For example, instructions in the offload card memory, when executed in the offload card's processor, may cause a message to be transmitted using the NHD or may process the contents of a message received via the NHD.

[0008] As part of their management responsibilities, the set of CPSs may assign several network addresses used by components of the virtualization server. For example, a network address within the VCS's substrate network (the underlying physical network on which virtual networks can be configured) may be assigned to the NHD. The substrate network may be used for communication with resources in a cloud provider network external to the virtualization server. The set of CPSs may also, with the assistance of the virtualization controller, assign a second network address to a compute instance launched on the virtualization server. The second network address may not be part of the substrate network, but instead, in some embodiments, may be selected from an isolated virtual network (IVN) or virtual private cloud (VPC) address range. In various embodiments, to assign the second network address to the compute instance, a virtual network interface (VNI) managed by the set of CPSs may be programmatically attached to the compute instance, and the second network address may be assigned to the VNI. Furthermore, the set of CPSs 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). The virtualization server, when executing on the virtualization server's primary processor, may store instructions that cause a first network function of the RBA to be executed on a compute instance in response to a message received on the compute instance (e.g., from an RBA component executing on some other compute instance in another virtualization server). The message may, in some embodiments, be received using a mapping between a network address assigned to the compute instance and a substrate network address. Such a mapping may be employed as part of an encapsulation protocol used by the VCS to translate between physical addresses on the substrate network and addresses 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 executed 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 by the CPS as a source address. Note that in some embodiments, a single network address assigned to a particular NHD in an 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 that have well-defined external interfaces and well-defined functional behavior. Network functions can be chained together to form communication services. While network functions have historically been implemented as physical network appliances or nodes, network functions can be virtualized as well. The core and RAN (Radio Access Network) network functions referenced herein can, in some implementations, be based at least in part on 3rd 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 and typically run in cell towers, performing conversion of radio signals to IP (Internet Protocol). Core network functions typically run in large data centers, performing subscriber-related business logic and routing IP traffic to and from the Internet. According to the present disclosure, both core and RAN network functions may additionally or alternatively run on radio-based application processing servers (RPSs) provisioned as virtualized servers by a cloud provider, e.g., on edge devices provisioned to customers to implement private 5G networks or used by wireless 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 some messages are transmitted using radio frequency signals and associated antennas, such as those used in various generations of cellular broadband technology (4G, 5G, etc.). RBPASs 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, in some embodiments, be part of a distributed unit (DU) of the 5G wireless technology stack used by the RBA. 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 others, a coding function, a rate matching function, a scrambling function, a modulation layer mapping function, a precoding function, a resource mapping function, a digital beamforming function, a fast Fourier transform (FFT) function, a cyclic prefix insertion function, a cyclic prefix removal function, an inverse FFT function, a demapping function, a channel estimation function, a prefiltering function, an equalization function, a demodulation function, a descrambling function, a rate inverse matching function, or a decoding function.

[0011] In addition to assigning network addresses, the CPS may also, in various embodiments, perform various 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 offload card's NFA and apply updates, including security patches, to the firmware or software. In at least some embodiments, the CPS may monitor the health 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 via a programmatic interface to a VCS client on whose behalf the NFA is being used. Performance metrics of the NFA, such as the total number of RBA messages processed or the execution of network functions, may, in some embodiments, be collected and analyzed at the CPS, and a representation of the performance metrics may be presented to the VCS client via a programmatic interface. The CPS may, in some embodiments, scrub or clean up the memory of the NFA as needed, for example, after a particular computation instance that was using the NFA has terminated and before another computation instance that is going to use the NFA is launched, so that data stored in the NFA memory during the lifetime of the particular computation instance is inaccessible by other computation instances.

[0012] According to at least some embodiments, a virtualized representation of each of the offload card's NFAs may be presented to one or more compute instances running on the virtualization server. This may allow some network functions of each RBA or radio-based application pipeline to be executed on the compute instance, with each of the RBAs utilizing the same shared NFA hardware for other network functions. Requests for use of the NFA hardware may be submitted through and received at the NFA using the virtualized representation's programmatic interface. Virtualization of the NFA may enable network slicing to be implemented on the virtualization server, with different radio-based applications or pipelines running on each of the compute instances and NFAs. The virtualized representation of the NFA, which may be referred to as a VNFA, may enable each compute instance to utilize the shared NFA hardware through a programmatic interface as if the instance had exclusive access to the NFA hardware, similar to the way virtualized representations of other hardware devices (such as virtualized CPUs or virtualized I / O hardware devices) on the virtualization server allow compute instances to utilize those devices as if the devices were available for exclusive use.

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

[0014] In at least one embodiment, a system may include one or more CPSs of a VCS of a cloud provider network and a virtualization server including an NFA. The CPSs may establish isolated virtual networks (IVNs) on behalf of clients of the VCS, for example, in response to program requests from the clients. The IVNs, also referred to as virtual private clouds (VPCs), may include a set of resources that are logically isolated or distinct from the rest of the VCS with respect to at least some types of networking configuration settings. For example, a given IVN may have one or more subnets with respective security settings 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 a repository of metadata for the IVN, 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 through a programmatic interface of the VCS. The security group, in various embodiments, may 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 include restrictions on the source of inbound traffic directed to the compute instance (and / or restrictions on outbound traffic from the compute instance) using the network address. 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 through 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 sources from which traffic can be accepted at the NFA). In some embodiments, 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. The NFA may perform a second network function of the RBA.

[0016] The CPS may cause validation that the first network message of the RBA complies with the restrictions of the first security group before delivering the first network message of the RBA to the compute instance using the first network address as the destination address. The first network message may, in some embodiments, trigger execution of a first network function. The CPS may also cause validation 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 from the NFA to a destination, such as the RU of the RBA. In at least some embodiments, the NFA may be embedded within an offload card of the type described above that also includes one or more virtualization management components and one or more networking hardware devices (NHDs), the compute instance is launched on a virtualization 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 of the compute instance and / or the NFA may also be stored by the CPS.

[0017] The CPS, in some embodiments, may enforce traffic rate limiting or traffic shaping rules for the NFA. For example, the CPS may determine rate limits to apply to network messages destined for or from the NFA, e.g., based on program requests from VCS clients on whose behalf the NFA is being used, and may drop packets destined for or from the NFA if delivery of the packets would cause the rate limits to be violated. 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 a distributed unit (DU) and a centralized unit (CU)) of an RBA utilizing an NFA may be stored by the CPS. In such embodiments, at least some messages for the midhaul traffic may be generated at the compute instance, while in other embodiments, some midhaul traffic messages may be generated at the NFA. Separate security groups or security rule sets may be stored for fronthaul 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 communications between the NFA and the RU. According to at least one embodiment, in addition to or instead of using security groups to 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 a different protocol (such as Common Public Radio Protocol (CPRI) or enhanced 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 over IP (e.g., using an encapsulation protocol).

[0019] According to various embodiments, the server may include a processor, 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 perform one or more configuration tasks for compute instances launched on the server, including allocating at least a portion of the memory used by the compute instances. The memory may store instructions that, when executed on the processor, cause the compute instances to execute a first network function of the RBA and execute a second network function of the RBA in the NFA. The input of the second network function may be based at least in part on the output of the first network function; for example, the instructions, when executed on the processor, may cause the output of the first network function to be provided as input to a second network function executed in the NFA.

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

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

[0022] In some embodiments, a virtualization server used as an RPS may be configured as part of a cloud provider network's Extended Resource Group (ERG), configured in a facility outside the provider network's primary data center 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 wireless-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 provider network data center. A given ERG may, in some embodiments, share some management resources among its member servers, such as a local agent for the VCS control plane. In at least some embodiments, the servers used for the ERG may be configured by the provider network operator with the appropriate hardware (e.g., including network function accelerator cards), software, and firmware, and then shipped to the facility where the ERG will be utilized. In some embodiments, at least some of the servers, such as RPSs, may require relatively little physical space (e.g., 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 of a provider network's data center may include certain hardware, software, and / or firmware elements that are specifically designed to enable remotely generated virtualization-related management commands to be executed in a safe and secure manner, for example, without requiring messages to be sent back to the source where the command originally issued.In some embodiments, such elements may include a Trusted Platform Module (TPM) or other security module embedded within an offload card, a tamper-resistant storage device whose contents can be decrypted as long as the storage device is physically attached to a particular RPS, etc. In at least some embodiments, such an RPS may include a VCS control plane agent that implements an API for inbound commands that make no outbound calls and are 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 connection, may be established between the RPS and resources located within a provider network data center, and such a channel may be employed to transmit commands from the VCS to the RPS. For example, a respective unidirectional secure network channel may be used to carry commands initially generated at a control plane server in response to a client request (including a request to activate an RCI) for ultimate execution at the RPS. In one embodiment, the secure channel used for such commands may be established between one or more resources (e.g., a VCS connection manager) in the RPS and one or more resources in the client's IVN whose request should activate an RCI at the RPS.

[0024] An RPS can serve as a source or destination for several different types of IP traffic, including traffic between different layers of the radio-based technology stack used for RBA, traffic to and from other resources within the provider network, traffic to and from resources within a client network established at the client premises, traffic to and from the public Internet, etc. 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 within an NFA, a networking chipset within a virtualization management offload card, etc. Network management logic provided by the provider network can be used to intelligently select the most appropriate NHD to be used for a given category of IP traffic at the RPS during a given time interval, thus enabling the RPS to maximize its available IP networking resources to achieve quality of service targets for applications running on the RPS. For example, depending on the type of RBA being performed, a different NHD may be used for the radio-based application's fronthaul traffic than for its midhaul traffic, at least for some periods of time. A software program (e.g., a program developed by a third-party vendor or a provider network operator) implementing a portion of an RBA may execute within a runtime environment (RTE), such as a radio-optimized compute instance or radio-optimized software container at the RPS. In some embodiments, a given RPS or a given NFA may be employed in several different RBAs or pipelines, e.g., on behalf of a single client of the provider network or on behalf of different clients. As a result of such multi-tenancy, the overall amount of computing resources and / or power consumed for the implementation of several different RBAs may be substantially reduced.The reduction in resources used, which can translate into lower costs, in turn, enables new entrants into the wireless-based application space and the design of new types of applications.

[0025] According to some embodiments, a provider network may include a radio-based application management service (RBAMS) that implements a programmatic interface for configuring RPSs. Indications of the expected geographic distribution of end-user requests for radio-based applications (e.g., cellular phone calls, text messages, inbound and outbound IoT sensor messages, etc.) may be obtained by the RBAMS via such programmatic interface. Information regarding the geographic distribution may be used by the RBAMS to select or recommend one or more facilities at which ERGs and / or RPSs of one or more categories supported by the provider network should be configured for the client. If the client indicates approval of the recommendation, one or more RPSs may, in such embodiments, be configured on the client's behalf at such facilities and assigned to the client's applications 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 portion of an NFA) in an offload card may be configured for exclusive use for a single client of a provider network (or a single radio-based application of a client where multiple radio-based applications are executed), e.g., in response to a single-tenancy request from the client. In some embodiments, multiple NFAs in a single RPS (e.g., in a single offload card) may be employed for a single radio-based application. In other embodiments, each NFA in a given offload card may be employed for a respective RBA. In one embodiment, an NFA may be configured to be used as a backup to another NFA, e.g., in response to detection of a failure or overload in the other NFA. In some embodiments, one or more NFAs in an RPS may be incorporated into a virtualization management offload card that also includes a virtualization management component, while one or more additional NFAs in the 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 in a VCS or RBAMS) and provided to clients via a programmatic interface as needed; such metrics may, in different embodiments, include inbound or outbound message transfer counts or message transfer rates, failure rates of the NFA, utilization levels of local processors, memory, and other resources of the NFA, etc. In one embodiment, metrics (e.g., resource utilization information) from multiple NFAs in an RPS may be collected and used to select which particular NFA to utilize to perform a particular network function.

[0028] As mentioned above, in some embodiments, the RPS may be configured, at least in part, using resources from a provider network. A cloud provider network (sometimes simply referred to as a "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. A cloud may provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adapt to variable loads. Thus, cloud computing can be viewed as both applications delivered as services over a publicly accessible network (e.g., the Internet or a cellular communications network) and the hardware and software in cloud provider data centers that provide those services.

[0029] A cloud provider network may include a physical network (e.g., sheet metal boxes, cables, rack hardware) referred to as the substrate. The substrate may be considered a network fabric that includes the physical hardware that runs the provider network's services and may include networking devices such as routers, switches, network address translators (NATs), and the physical connections between the devices. The substrate may be logically separated from the rest of the cloud provider network; for example, it may not be possible to route from substrate network addresses to addresses in the production network that runs the cloud provider's services or to the customer network that hosts customer resources.

[0030] The cloud provider network may also include an overlay network of virtualized computing resources (e.g., compute instances, block storage volumes, data objects such as snapshots and machine images, file storage, databases) running on the substrate. In at least some embodiments, a virtualization management component, such as a hypervisor or other device or process on the network substrate, may use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) over the network substrate between client resource instances on different hosts in the provider network. The encapsulation protocol technology may be used on the network substrate to route the encapsulated packets (also referred to as network substrate packets) between endpoints on the network substrate via overlay network paths or routes. The encapsulation protocol technology may be viewed as providing a virtual network topology overlaid on the network substrate. Thus, network packets can be routed along the substrate network according to constructs in the overlay network (e.g., IVNs, security groups). A mapping service may coordinate the encapsulation and routing of these network packets. The mapping service can be a regional distributed lookup service that maps combinations of overlay IPs and network identifiers to substrate IPs so that distributed substrate computing devices can find out where to send packets.

[0031] To illustrate, each physical host may have an IP address within the substrate network. Hardware virtualization technology may enable multiple operating systems to run simultaneously on a host computer, e.g., 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) allocates the host's hardware resources among the various compute instances on the host and monitors the execution of the virtual machines. 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 recognize the IP addresses of the compute instances on the host. The virtual machine monitor (and / or other devices or processes on the network substrate) may use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) over the network substrate between virtualized resources on different hosts within the cloud provider network. The encapsulation protocol technology may be used on the network substrate to route the encapsulated packets between endpoints on the network substrate via overlay network paths or routes. The encapsulation protocol technology may be viewed as providing a virtual network topology overlaid on the network substrate. The encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (public IP addresses) to substrate 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, which are distinct geographical areas where a cloud provider clusters its data centers. Such regions may also be referred to as provider network-defined regions because their boundaries may not necessarily coincide with those of countries, states, or the like. Each region may include two or more availability zones connected to each other via a private high-speed network, e.g., a fiber optic communication connection. An availability zone (also known as an availability domain or simply a "zone") refers to an isolated failure domain that includes one or more data center facilities with separate power, separate networking, and separate cooling from those in another availability zone. A data center refers to a physical building or enclosure that houses and provides power and cooling to the servers of a cloud provider network. Preferably, availability zones within a region are located far enough from each other that the same natural disaster should not take two or more availability zones offline simultaneously. Customers can connect to availability zones of a cloud provider network through publicly accessible networks (e.g., the Internet, cellular communication networks) via transit centers (TCs). A TC can be considered a primary backbone location linking customers to the cloud provider network and may be collocated with other network provider facilities (e.g., internet service providers, telecommunications providers) and securely connected (e.g., via VPN or direct connection) to availability zones. Each region may operate two or more TCs for redundancy. As described herein, customers may also be able to 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 the customer and cloud provider facilities) or may traverse other intermediate networks (such as the Internet) and enter the cloud provider network via the TC.The regions are connected to a global network that connects each region to at least one other region. The cloud provider network may deliver content from points of presence outside these regions via edge locations and regional edge cache servers (points of presence, or PoPs), but may be networked with these regions. This partitioning and geographic distribution of computing hardware enables the cloud provider network to offer customers 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, edge locations can be extensions of a cloud provider network substrate that include a limited amount of capacity provided outside of availability zones (e.g., in the cloud provider's small datacenter or other facility, located near customer workloads and potentially far from any availability zones). Such edge locations can be referred to as local zones (due to being more local to or closer to a group of users than traditional availability zones). Local zones can be connected to publicly accessible networks such as the Internet in various ways, for example, directly, through another network, or through a private connection to a region. Typically, local zones will have more limited capacity than regions, but in some cases, local zones can have substantial capacity, e.g., thousands or more racks. Some local zones can use infrastructure similar to a typical cloud provider datacenter.

[0034] In some implementations, an edge location may be an extension of a cloud provider network substrate formed by one or more servers located on-premises in customer or partner facilities, which communicate over a network (e.g., a publicly accessible network such as the Internet) with nearby availability zones or regions in the cloud provider network. This type of substrate extension located outside of a cloud provider network datacenter may be referred to as a cloud provider network “outpost” or VCS-extended resource group. Several outposts may be integrated into a communications network, for example, as a multi-edge cloud with physical infrastructure spanning telecommunications datacenters, telecommunications aggregation sites, and / or telecommunications base stations within the telecommunications network. In an on-premises example, the outpost's limited capacity may be available for use only by the customer who owns the facility (and other accounts authorized by the customer). In a telecommunications example, the outpost's limited capacity 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 may include data plane capacity that is controlled at least in part by the control plane of a nearby availability zone. Thus, an availability zone group may include a “parent” availability zone and any “child” edge locations that are homed to the parent availability zone (e.g., controlled at least in part by the control plane of the parent availability zone). Certain limited control plane functionality (e.g., features requiring low-latency communication with customer resources and / or features that enable the edge location to continue functioning when disconnected from the parent availability zone) may also be present in some edge locations. Thus, in the above example, an edge location refers to at least an extension of data plane capacity located at the edge of the cloud provider network, 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 that place some of the provider network's compute, storage, database, and other select services near large population, industrial, and IT centers, or other desired locations that may not be very close to the provider network's primary data center. In such local zones, applications that require single-digit millisecond latency can run closer to specific geographic end users. Local zones provide high-bandwidth, secure connections 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 to the full range of intra-regional services through the same APIs and toolset.

[0037] A cloud provider network may implement various computing resources or services, which may include virtual compute 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 type of network-based service (which may include various other types of storage, processing, analytics, communication, event handling, visualization, and security services). Resources (e.g., compute and storage resources) required to support the operation of such services may be provisioned to an account associated with the cloud provider, as opposed to resources requested by a user of the cloud provider network, which may be provisioned to a user account.

[0038] The various network-accessible services, in different embodiments, may be implemented in one or more data centers of a provider network. The network-accessible computing services may include an elastic computing cloud service (referred to in various implementations as an elastic computing service, virtual machine service, computing cloud service, compute engine, virtualized computing service (VCS), or cloud computing service). The service may provide virtual computing instances (also referred to as virtual machines, or simply "instances") having various computational and / or memory resources managed by a computing virtualization service (referred to in various implementations as an elastic computing service, virtual machine service, computing cloud service, compute engine, or cloud computing service). In one embodiment, each of the virtual computing instances may correspond to one of several instance types or families. An instance type may be characterized by its hardware type, computational resources (e.g., the number, type, and configuration of central processing units [CPUs] 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 suitable descriptive characteristics (such as a “burstable” instance type that has a baseline performance guarantee and the ability to periodically burst above that baseline, a non-burstable or dedicated instance type that is allocated and guaranteed a fixed amount of resources, or an instance type optimized for wireless-based applications). Each instance type may have a particular 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 function, an instance type may be selected for a customer based (at least in part) on input from the customer, for example. 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 of the instance type and / or the requirements of the workload on which the instance will run, and the instance type selection function may select an instance type based on such specifications. A suitable host for the requested instance type may be selected based at least in part on factors such as collected network performance metrics, resource utilization levels on different available hosts, etc.

[0039] The provider network's 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 packaging 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 run consistently on any infrastructure that hosts a suitable container engine (e.g., a Docker® or Kubernetes® container engine). Compared to a virtual machine (VM), which emulates an entire computer system, a container virtualizes at the operating system level and therefore typically represents a more lightweight package for running an application on a host computing system. An existing software application can be "containerized" by packaging the software application in an appropriate manner and generating other artifacts (e.g., a container image, container file, or other configuration) used to enable the application to run on a container engine. In some implementations, the container engine may select and run a virtual machine instance based at least in part on described network performance metrics. The RBA component, in at least some embodiments, may be executed using containers. In some embodiments, other types of network-accessible services, such as packet processing services, database services, wide area networking (WAN) services, etc., may also be implemented in the cloud provider network.

[0040] Cloud provider network traffic and operations, in various embodiments, can be broadly subdivided into two categories: control plane operations, which are conveyed through a logical control plane, and data plane operations, which are conveyed through a logical data plane. The data plane represents the movement of user data through a distributed computing system, and 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 distributed across 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 (e.g., computing instances, containers, block storage volumes, databases, or file storage) implemented on the cloud provider network. 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 set of servers separate from the data plane servers, while other control plane components (e.g., Layer 2 control plane components such as analytics services) may share virtualization servers with the data plane, and control plane traffic and data plane traffic may be transmitted over separate / distinct networks.

[0041] 1 illustrates an exemplary system environment in which a virtualization server in which a virtualization management offload card includes a hardware network function accelerator may be employed to run wireless-based applications that utilize, at least in part, resources of a virtualized computing service, according to at least some embodiments. As shown, system 100 includes resources and artifacts of a virtualized computing service (VCS) 110, including a control plane server 140 and a set of virtualization servers including Category A virtualization servers, Category B virtualization servers, and Category C virtualization servers. The virtualization server categories, in the depicted embodiment, may differ from one another in the type of virtualization management offload card (VMOC) included in each category of server and / or the primary processor (CPU), memory, and other resources included in the server, and thus may be used for different types of applications. For example, in the depicted embodiment, the Enhanced Wireless Application VMOC (EVMOC) 118 of Category A virtualization server 150 may include a Type A network function accelerator (NFA) 172, the EVMOC 119 of Category B virtualization server 152 may include a Type B NFA 177, and the baseline VMOC 166 of Category C virtualization server 182 may not include any NFAs. NFAs 172 and 177 may differ in the types of network functions they can accelerate, the speed at which they can perform particular types of network functions, the vendor that developed the chipsets used for the NFAs, etc. As a result of the differences in the properties 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 a different class of wireless-based applications. A Category C virtualization server may be better suited to general-purpose applications that do not require hardware acceleration of network functions. Category A and Category B virtualization servers with NFAs may both be referred to as wireless-based application processing servers or RPSs in various embodiments.

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

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

[0044] The EVMOC and VMOC may also include one or more networking hardware devices (functionally similar to network interface cards or NICs), such as EVMOC 118, EVMOC 119, and NHD 174A, NHD 174B, and NHD 174C in baseline VMOC 166, respectively, in the depicted embodiment. The NHDs may be used to transmit network messages to and from the virtualization servers, including messages to and from the control plane server 140, other virtualization servers, and other provider network services, such as storage services. In at least some embodiments, a control plane server, such as networking manager 106, may assign an address in the substrate network to at least one NHD of each virtualization server, which address may be used for subsequent communication with the control plane server and other virtualization servers. The networking manager 106, in some embodiments, may also assign network addresses (not part of the substrate network) to the compute instances, for example, within a network address range chosen by the VCS client for their isolated virtual network (IVN). Because multiple compute instances may be configured on a given virtualization server with a given NHD, with respective network addresses assigned to each compute instance, in the depicted embodiment, a mechanism may be implemented in the VCS for delivering messages directed to the respective network addresses of the instances while using the same underlying NHD. The mapping between substrate addresses and addresses assigned to the compute instances may be maintained by the networking manager 106 in some embodiments, for example, as part of the isolated virtual network IVN metadata 111.

[0045] In at least some embodiments, a control plane server, such as network manager 106 or NFA manager 104, may also assign network addresses to the NFAs of the EVMOC, which can be used for communications between the NFAs and radio-based application cells 154. Cell 154A may include cell software 155A and antenna 156A associated with an RBA's radio unit (RU) implemented using RCI 125A, and cell 154B may include cell software 155B and antenna 156B associated with an RBA's RU implemented using RCI 125B. In some embodiments, the EVMOC may include multiple NHDs, where one NHD is assigned a substrate network address and another NHD is assigned a different address (e.g., an IVN address) used for communications between the NFAs and the 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 the compute instance. In another embodiment, the NFA may comprise one or more NHDs that may be managed by a control plane server and employed for communication with the RUs and / or centralized units (CUs) of the RBA.

[0046] A control plane server, referred to as NFA manager 104, in the depicted embodiment, may be responsible for performing various management tasks related to the NFA. 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, scrubbing / cleaning the contents of the NFA's memory after an RCI has terminated so that data from an RBA running on the terminated RCI cannot be accessed by another RCI that is later launched, etc. In addition to collecting and analyzing health and performance information from other resources in the VCS, the VCS control plane health and performance metrics manager 112 may collect and analyze health and performance metrics from the NFA and publish the collected metrics to the VCS client on whose behalf the NFA is used 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 (e.g., working with an on-serve VMC or OVC) the migration of RBA workloads from one RPS to another. In at least some embodiments, a respective virtualized representation of the virtualization server's NFA may be presented to each of one or more RCIs launched on the server, allowing different RBAs running on the RCIs to share a single NFA device to perform a subset of the RBA's network functions.

[0048] In some embodiments, any of the various network functions in the physical layer or L1 layer of a radio-based technology stack may be implemented in NFA 172 or NFA 177. In other embodiments, an NFA may perform network functions of a distributed unit (DU), centralized unit (CU), and / or core network component of an RBA. In some embodiments, a given EVMOC may include several different NFAs, each containing hardware optimized to accelerate a different type of network function or a different set of network functions.

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

[0050] In some embodiments, route table entries provided by clients to the VCS control plane using programmatic requests are stored as part of the IVN metadata 111 and may be employed to direct traffic originating from or addressed to NFAs and compute instances. Networking manager 106, in some embodiments, may obtain traffic shaping rules or rate limits from VCS clients via a programmatic interface and enforce rate limiting of traffic to / from compute instances or traffic to / from NFAs (e.g., by dropping or discarding packets whose delivery would violate the rate limits). Generally, in the depicted embodiments, NFAs may be managed by a VCS control plane server as first-class entities within the VCS's IVN, in a manner similar to the way compute instances and entities such as load balancers, virtual routers, and gateways are managed by a VCS control plane server. Note that in at least one embodiment, at least some virtualization servers or RPSs may be used in a multi-tenant mode, such that a given server may potentially be used for compute instances configured on behalf of several different clients, with several different IVN's compute instances potentially instantiated on one server. In different embodiments, some virtualization servers used for the RBAs may be located in the provider network datacenter, while other virtualization servers may be located in facilities outside the datacenter. 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 an NFA. The decision as to whether a given network function is executed in the NFA or the primary processor may be made based on various factors in different embodiments; for example, in some cases, the decision may be based on a policy indicated by a client via a programmatic interface, and in other cases, the decision may be made dynamically (e.g., by a control plane server) based on analysis of metrics / failures / errors.

[0051] As shown in FIG. 1, some virtualization management components of a virtualization server (e.g., the OVC) may run on an offload card, while other components (e.g., the on-server VMC) may run on the server's primary processor. FIG. 2 illustrates an exemplary configuration of a wireless-based application processing server with partially offloaded virtualization management functionality, according to at least some embodiments. As shown, a 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 stripped-down hypervisor 220 running on the primary physical processors, 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 general-purpose CIs 251, that may not be optimized for wireless-based applications. EVMOC 210, in the depicted embodiment, may include one or more NFAs 237, one or more networking hardware devices (NHDs) 292, a virtualization controller 215, and a network processing offloader 216. RPS 202 may also include several other components not shown in FIG. 2 , such as various persistent storage devices. Primary physical processor set 204 may include several physical CPUs (pCPUs, also referred to as primary processors), including, in the depicted embodiment, pCPU 205A and pCPU 205B. Virtualized versions of pCPUs, called vCPUs or virtual CPUs, may be allocated to individual RCIs and / or general-purpose CIs by a virtualization management component, such as a hypervisor and / or a virtualization controller, during the lifetime of a compute instance.Each computing instance may include a respective 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 virtualized computing service (VCS) client having functionality similar to VCS 110 of FIG. 1.

[0052] The virtualization controller, network processing offloader, and hypervisor 220 may collectively be referred to as a partially offloaded virtualization manager or PVM, because some of the virtualization management tasks required by the RPS may be performed by the hypervisor using the pCPUs, and the remaining virtualization management tasks may be performed on the offload card. Network processing offloader 216, in the depicted embodiment, may implement one or more networking protocols (e.g., including encapsulation protocols used within the VCS) and act as an intermediary between the compute instances and networking endpoints outside the RPS. In at least one embodiment, the VCS control plane may communicate with network processing offloader 216 to perform networking-related configuration operations in the RPS, such as allocating network addresses and changing / applying IVN-related settings. In various embodiments, network processing offloader 216 may use the NHD to transmit messages between the compute instances and endpoints or destinations external to the virtualization server, and / or between network functions running on NFA 237 and endpoints or destinations external to the virtualization server. Similarly, the network processing offloader may receive messages from sources external to the virtualization server via the NHD and send the messages to the NFA 237 or to the compute instance 250 or 251, depending on the destination indicated in the message. The virtualization controller 215, the network processing offloader 216, and / or the NFA 237 may, in some embodiments, be implemented using respective system-on-chip designs, e.g., embedded within a shared offload card linked to the pCPU via a peripheral interconnect. In other embodiments, the virtualization controller, the networking processing offloader, and / or the NFA may be implemented using a field programmable gate array (FPGA), a digital signal processor (DSP), or other technology.Although the virtualization controller 215, network processing offloader 216, and NFA 237 are shown in the depicted embodiment as being integrated into a single offload card (e.g., a PCIe card), different embodiments may employ other 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 the network processing offloader. In another embodiment, respective offload cards may be used for the virtualization controller 215, the network processing offloader 216, and / or one or more NFAs 237. As suggested by its name, in the depicted embodiment, the virtualization controller may be responsible for organizing or orchestrating many of the virtualization management tasks performed in RPS 202, and may be the first of the components of the PVM, e.g., booting, triggering the startup of other components of the PVM, communicating with the VCS control plane, determining memory allocations for compute instances, etc. In at least one embodiment, the network processing offloader may select a particular NHD 292 to be used for a particular category of RPS traffic (e.g., midhaul, fronthaul, or backhaul traffic of 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 205 before the hypervisor uses CPU cycles. Thus, for example, if a particular compute instance 250 or 251 issues an I / O request (where 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] Hypervisor 220, in the depicted embodiment, 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, an isolation / security component 229, and / or a messaging manager 231. Hypervisor coordinator 225, individual ones of VM managers 228, isolation / security component 229, and / or messaging manager 231 may, in at least some embodiments, be implemented as respective user-mode processes. In various embodiments, at least some of these components may be implemented as instances of respective statically linked programs that communicate with each other via pipes using a simple, specialized protocol. In the depicted embodiment, the hypervisor subcomponents may remain passive or quiescent by default, reacting and activating only in response to events (messages from other subcomponents, context switches initiated by a compute instance, etc.).

[0055] Kernel-level component 222 may provide support for various low-level operations, such as the initial response to a VM termination command issued by a compute instance (e.g., when a compute instance relinquishes a pCPU). Hypervisor coordinator 225, as implied by the name, may be responsible for orchestrating the operations of the other subcomponents. Hypervisor coordinator 225 may, for example, implement an API that can be used for communication between components and the hypervisor in the EVMOC, initiate the launch and termination of compute instances (e.g., at the request of a virtualization controller), expose metrics collected by the VM manager, provide debugging capabilities, etc.

[0056] Each VM manager 228 may be responsible for launching or instantiating a respective compute instance based on specifications provided by coordinator 225, monitoring compute instance metrics and logs, etc. In some embodiments, VM manager 228 may also facilitate compute instance requested I / O operations for particular devices, 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] Messaging manager 231 may act as an intermediary between virtualization controller 215 and the hypervisor, for example, by translating commands issued by the virtualization controller using a queue-based protocol into pipe messages within the hypervisor. Security and isolation component 229 may be responsible for scrubbing or cleaning up compute instance memory, for example, when a compute instance terminates, thereby preventing inadvertent sharing of data across compute instances. In some embodiments, the security and isolation component may also be responsible for scrubbing or cleaning up memory of NFA 237, for example, in response to commands issued by the NFA manager of the VCS control plane.

[0058] Programs implementing virtualized network functions at one or more layers of a radio-based technology stack may, in the depicted embodiment, be executed as part of the RCI's application 254A or 254B. Other network functions may be executed in the NFA in response to requests or messages transmitted, for example, from the RU and / or from programs implemented in the applications. Various aspects of the configuration of the compute instances and the NFA may be managed by the control plane server of the VCS, as described above.

[0059] EVMOC 210 may, in some embodiments, include several other components not shown in FIG. 2 . A secure boot ROM embedded 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 used extensively during the boot procedure and / or for post-boot state validation. In addition, EVMOC 210 may, in various embodiments, include several storage-, power-, and connectivity-related components. For example, one or more flash devices / interfaces (or SSDs) may be embedded within the offload card. These devices may be used, for example, 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 a 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). The EVMOC 210 may also, in some embodiments, comprise a power source sufficient to keep the components of the EVMOC operating for at least a targeted number of hours or days, for example, in the event of a long-term power failure. In some implementations, a supercapacitor-based power source may be used.

[0060] Figure 3 illustrates an overview of user plane and control plane layers defined in accordance with technical standards for radio-based applications, according to at least some embodiments. The arrows shown in Figure 3 represent downlink communication paths (from higher levels of the standard, often implemented in back-end servers, down to lower levels implemented using front-end components such as radio antennas and network function accelerators of the type described above). The depicted layers conform to the 5G-NR standard published by 3GPP (3rd Generation Partnership Project), a group of organizations responsible for defining protocols for mobile communications, although similar layers have been defined for other generations of cellular communications technologies.

[0061] In a manner somewhat similar to the above-discussed subdivision of provider network functions into control plane and data plane functions, the operations required for radio-based applications are divided into control plane operations, which include connection configuration and other management tasks such as monitoring, and user plane operations, which 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 for communication between layers (and between sublayers of each layer) are defined, allowing for flexible mapping of the network functions of layers and sublayers to different hardware and / or software components as long as the interface and performance requirements of the protocol stack can be met. The logic for performing the layer functions is distributed among three types of components: a centralized unit (CU) for L3 operations, a distributed unit (DU) used for L2 operations and optionally some L1 operations, and a radio unit (RU) used for at least a subset of L1 operations. L1 is also referred to as the physical layer (PHY). L2 includes the medium access control (MAC) and radio link control (RLC) sublayers. L3 may include sublayers for the packet data convergence protocol (PDCP) and the service data adaptation protocol (SDAP). User plane 301 operations may include quality of service (QoS) management 302 and compressed 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. Control plane 351 operations may include non-access stratum (NAS) 320 protocol tasks, system information (SI) 322 tasks, paging 324, radio resource control (RRC) 326 and compressed 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 FIG. 3 may involve the performance of a respective set of network functions. In at least some embodiments, a subset of the network functions corresponding to L1, L2, and / or L3 may be implemented using an NFA of the type described above embedded within a virtualization management offload card.

[0063] FIG. 4 illustrates exemplary uplink and downlink pipelines of network functions for a radio-based application, according to at least some embodiments. Standardization organizations have defined several options for dividing the pipeline's functions between a CU (Centralized Unit) and a DU (Distributed Unit), which are indicated by dashed lines labeled Option 1, Option 2, ..., Option 8 in FIG. 4. Such division allows the workload of a radio-based application to be distributed across multiple different devices, instead of relying on a monolithic device responsible for performing all functions. Several more detailed options for dividing physical layer functions between the CU and DU, referred to as Option 7-1, Option 7-2, etc., are shown in FIG. 5, as variations on Option 7.

[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) operations 420. In between, the downlink pipeline includes, in order, a respective 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) operations 452 and ends with RRC 468 and data 470. In between, the network functions are performed in order 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 the lower PHY layer (for the uplink and / or downlink) may be implemented using an NFA of the type discussed above. In some embodiments, network functions of the other layers shown in Figure 4 may also be implemented in an NFA. In at least some embodiments, network functions of the RLC layer and MAC layer may be implemented using software running within a Radio Optimization Computing Instance (RCI) of the type shown in Figure 1.

[0065] 5 illustrates example network functions that may be performed at the physical layer of a technology stack for a radio-based application, according to at least some embodiments. In a downlink PHY (L1) pipeline 501, where control and data messages are being transmitted from higher layer components toward the RU, a lower MAC stage 502 (part of L2) leads to a coding, rate matching, and scrambling stage 504, followed by a modulation layer mapping stage 506. This is followed by a precoding and resource mapping stage 508, a digital beamforming stage 510, and an inverse fast Fourier transform (IFFT) and cyclic prefix insertion stage 512, before digital-to-analog radio frequency (D / A RF) operations 514 are performed. In the reverse direction, when control signals and data are flowing from the radio unit toward the L3 component of the pipeline, the analog-to-digital radio frequency operations (A / D RF) stage 552 is followed by a 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 de-matching and decoding stage 562 before reaching the L2 lower MAC stage 564.

[0066] Each stage in the uplink pipeline 501 and the downlink pipeline 551 may require a respective set of network functions to be performed. Partitioning options 7-3, 7-2, 7-2a, and 7-1 represent respective proposals for distributing the entire combination of network functions between “upper L1” (implemented in the DU) and “lower L1” (implemented in the RU). Stages in the pipelines 501 and 551 to the left of the dashed line indicating the partitioning option are considered part of the upper L1, and stages to the right are considered part of the lower L1. Thus, in the partitioning of 7-2, stages 508, 510, 512, 554, 556, and 558 may involve the RU, and the remaining stages may involve the DU. In various embodiments, a network function accelerator utilized in a radio-based pipeline processing server (RPS) may use a custom chipset to perform at least some of the network functions of the pipeline stages shown in FIG. 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 (among other things) an encoding function, a rate matching function, a scrambling function, a modulation layer mapping function, a precoding function, a resource mapping function, a digital beamforming function, a fast Fourier transform (FFT) function, a cyclic prefix insertion function, a cyclic prefix removal function, an inverse FFT function, a demapping function, a channel estimation function, a pre-filtering function, an equalization function, a demodulation function, a descrambling function, a rate inverse matching function, or a decoding function. In at least some embodiments, the network function accelerator may implement the DU function. In some embodiments, at least a portion of the CU function may be implemented in the RPS in addition to the DU function.

[0067] FIG. 6 illustrates an example hierarchy of devices that may be used for radio-based applications, according to at least some embodiments. In the depicted embodiment, 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 back-end functions associated with radio-based applications and enables different sub-networks throughout the system to communicate with each other. Network functions performed on the core network server (referred to as core network functions) may include, for example, functions to aggregate data traffic from end-user devices, authenticate subscribers, apply personalized policies, and / or manage device mobility before routing traffic to operator services or the Internet. A given core network server 618 may be located, for example, in one embodiment, in a provider network data center. 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 depicted embodiment. 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 FIG. 6, the distributed unit (DU) functionality of the radio-based application technology stack may be implemented in RPS 670 (similar in function to virtualization servers 150 and 152 of FIG. 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 the CU and DU may be referred to as midhaul traffic 692 in various embodiments. Each of the RPSs may then be linked to radio units (RUs) in one or more cell 654 devices, for example, using an NHD embedded in a virtualization management offload card. For example, RPS 670A may be linked to radio units in cells 654A and 654B, RPS 670B may be linked to radio units in cell 654C, RPS 670C may be linked to radio units in cell 654D, and RPS 670D 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 of the cells may include one or more antennas that can be used to receive and transmit radio frequency signals from various wireless user devices 679. A given RAN node (such as a gNodeB in a 5G application) may include one or more CUs, one or more DUs, and one or more RUs, in various embodiments. In some embodiments, the RPSs, intermediate RAN servers, and core servers may all be implemented at least in part using provider network resources. According to one embodiment, an RPS may be used to perform at least some core network functions (functions performed in the core server 618). In one embodiment, at least some of the functionality of cell 654 may also be implemented using provider network resources. In at least one embodiment, the RPS may also be used to implement at least a subset of the CU functionality.

[0069] 7 illustrates an example deployment of an L2 implementation program of a radio-based technology stack in a radio-based application processing server, according to at least some embodiments. In the depicted embodiment, a radio-based application processing server (RPS) 710 includes a set of programs for the L2 layer, L2P 725, of one or more radio-based application (RBA) pipelines. L2P 725 may, in some embodiments, 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 launched within a compute instance (such as a radio-optimized compute instance similar to RCI 125A or 125B of FIG. 1).

[0070] In the embodiment depicted in FIG. 7 , a request handler may be invoked in the RPS for an RBA pipeline. An upper L1 request handler 726 may be used to process / forward requests generated by the L2P 725 for network functions. In embodiments where the RPS is used in multi-tenant mode for multiple RBA pipelines, a respective set of upper L1 request handlers and L2Ps may be instantiated for each of the pipelines. The request handlers may be isolated from each other within their respective runtime environments, e.g., as part of respective compute instances or software containers with address spaces that are inaccessible from other execution environments. In some embodiments, the request handlers 726 may include one or more privileged threads or processes executing within the same runtime environment as their corresponding L2Ps. Each of the request handlers 726, in the depicted embodiment, 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, e.g.

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

[0072] An NFA access manager (NFAAM) 727 (also referred to as a network function offload manager) may, in at least some embodiments, be launched in the RPS 710 as part of a virtualization management component, such as, for example, a hypervisor. In the depicted embodiment, the NFAAM 727 may act as an intermediary between request handlers and a set of network function accelerators (NFAs), such as the NFA 719 implemented in the enhanced virtualization management offload card (EVMOC) 718 of the RPS 710, in a manner somewhat similar to the way that, for example, hypervisors and other virtualization management components in a general-purpose virtualization host or server can act as intermediaries between software and other hardware components.

[0073] The NFAAM, in the depicted embodiment, receives L1 network function requests sent from the request handler 726 for all downlink pipelines implemented using the RPS 710, determines the specific NFA 719 (if multiple NFAs exist) that should be utilized for a given network function, and transmits the request to that NFA for execution. The results of the network function execution may, in some embodiments, be transmitted from the NFA to one or more radio units in 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 may be reversed: the incoming message may be transmitted from the RU to the NFA, one or more network functions may be executed in the NFA, and the results may be forwarded to the L2P via the NFAAM and / or request handler. The L2P may then forward the results of the L2 processing to an L3 or CU implementation further up the stack, e.g., in another RPS, an intermediate RAN server, and / or a core server.

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

[0075] The RPS 710, in the depicted embodiment, may include one or more NHDs 733 implemented as part of the EVMOC 718. In embodiments in which the RPS includes multiple NHDs, a networking manager (not shown in FIG. 7 ) in the RPS may, in various embodiments, be responsible for selecting a particular NHD to be used for traffic directed to a particular category of destination. A given NHD may include several different ports, such as ports 772A, 772B, and 772C in the depicted embodiment, allowing connections to be established with several different network endpoints or networking devices, such as routers / switches, using that NHD. In some embodiments, one NHD or port may be used for communications with RUs (fronthaul traffic), and another NHD or port may be used for midhaul or backhaul traffic. The EVMOC 718 may also include a virtualization controller 735, having functionality similar to the virtualization controller 215 of FIG. 2.

[0076] In embodiments in which an EVMOC includes multiple NFAs, the particular NFA for a given request may, in different embodiments, be selected (e.g., by an NFAAM) based on any combination of various factors. For example, in some embodiments, a given L2P may be associated with at least one NFA in the request of the client on which the L2P is executed, and thus the NFA selected for a given network function request may be based at least in part on the L2P for which the network function is requested. In some cases, a given NFA may be assigned for exclusive use on behalf of a given client of a given wireless-based application or provider network. In some embodiments, metrics collected from the 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 depicted embodiment, each of the radio-based applications whose pipelines are running on the RPS may belong to one of a set of application areas with respective expectations regarding performance and other quality of service considerations. The International Telecommunication Union-Radiocommunication Sector (ITU-R) Standardization Organization has defined at least three such application areas for 5G cellular communications: enhanced mobile broadband (eMBB), massive machine-based communications (mMTC), and ultra-reliable low-latency communications (URLLC). An NFA, in some embodiments, may be selected for at least some of the application's network functions by the NFAAM based on the application area to which the application belongs.

[0078] The RPS may 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 processor (CPU, GPU, etc.) may become available for such additional applications.

[0079] In various embodiments, an RPS similar to RPS 710 may provide an implementation of Open Radio Access Network (O-RAN), a decoupled 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 first introduced by 3GPP. Organizations such as the O-RAN Alliance are developing standards for O-RAN, and the RPS, at least in some embodiments, may be designed to comply with such standards.

[0080] FIG. 8 illustrates an example presentation of a virtualized representation of a hardware network function accelerator for compute instances running on a virtualized server, according to at least some embodiments. In the embodiment depicted in FIG. 8, an RPS 810 may be used to run at least two wireless optimized compute instances (RCIs) 870A and 870B. Each RCI may include a set of L2 implementation programs for a respective RBA, such as L2P 824 for RCI 870A and L2P 834 for RCI 870B. Other applications 811A (i.e., applications that do not implement L2 network functions) may also run on RCI 870A, and other applications 811B may similarly run on RCI 870B.

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

[0082] In at least some embodiments in which one or more RCIs execute on an RPS, a respective virtualized representation of the NFA may be programmatically presented to each of the RCIs by a hypervisor or other virtualization management component. For example, virtualized NFA 877A may be presented to RCI 870A, and virtualized NFA 877B may be presented to RCI 870B. From the perspective of any given RCI, the virtualized representation may grant access to all of the functionality that would be available if the RCI were granted access to a physical NFA, in a manner similar to the way 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 cause an NFA to perform a given network function, a program executing on the RCI may invoke the APIs of the virtualized representation provided to that RCI. In the depicted embodiment, a separate virtualized NFA may be used for each network slice, allowing multiple RBAs or RBA pipelines to be implemented using shared hardware NFAs.

[0083] In some implementations, the hypervisor may maintain a data structure including a number of slots, each representing a respective virtualized view of at least a portion of the NFA's computing and / or networking capabilities, which can be allocated or assigned, at least for a period of time, to a particular RBA or L2P. An individual slot may, in some embodiments, comprise an element of an array, 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 a manner such that, from the perspective of any given pipeline, the NFA appears to be exclusively used by 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 aggregate performance capabilities along one or more dimensions, such as the NFA's network function processing capacity, the network bandwidth available for communication from the NFA to RUs, etc.

[0084] 9 illustrates exemplary network function accelerator configuration management tasks that may be performed by or initiated by a control plane server of a virtualized computing service, according to at least some embodiments. In the embodiment depicted in FIG. 9, the RPS 910 may be used to execute at least one radio optimization compute instance (RCI) 970. The RCI may include a set of L2 implementation programs for each RBA, similar to the L2P previously discussed in the context of FIGS. 7 and 8. Other applications may also be executed on the RCI 970.

[0085] The RPS 910, in the depicted embodiment, may include a hypervisor 935 and an EVMOC 918. The EVMOC 918 may include at least one NFA 919, at least one NHD 933, and a virtualization controller 938 of the type discussed above. The virtualization controller and hypervisor may communicate with one or more VCS control plane servers 937, for example, using one of the NHDs 933.

[0086] The VCS control plane server, in the depicted embodiment, may perform several types of management and configuration tasks associated with the NFA 919, for example, with the assistance of a hypervisor and / or virtualization controller. These tasks may include firmware / software deployment 901 of the FFA, including installation of an initial version of 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, for example, by the operator of the provider network, 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, which may then propagate the firmware / software to the appropriate RPS.

[0087] In at least some embodiments, the VCS control plane server may assign network addresses used for 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, occur in response to a programmatic request from a VCS client for which the NFA is to be used; for example, the client may indicate a specific address or have the VCS control plane server select an address. In some cases, one address may be assigned to fronthaul traffic and another address may be assigned to midhaul traffic for an RBA implemented with the help of an RPS. In at least one embodiment, an address within 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 related to the network function being performed by the NFA, such as intermediate or final results of the network function. In one such embodiment, the VCS control plane server may scrub or clean up the memory at one or more points, such as when an RCI that was sending a request for the network function to the NFA terminates. Such NFA memory scrubbing 905 may help enhance the security of RBAs executed using the RPS, because data generated or stored in the NFA memory for one RBA may be permanently scrubbed or deleted before any other RBA can access it.

[0089] The VCS control pane server, in the depicted embodiment, may also be responsible for NFA health status monitoring 903 and NFA performance metrics monitoring 904. Information regarding the health status of the NFA and the performance characteristics of the NFA during various time intervals may, in various embodiments, be provided via a programmatic interface to the client (e.g., RBA owner) on whose behalf the NFA is being used. Metrics collected and presented by the control plane may include, for example, utilization levels of the NFA processor, memory, etc., rates or counts of NFA component failures or errors (if any), latency to complete network function processing at the NFA, etc.

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

[0091] The VCS control plane server may also be responsible for substrate network address assignment 952 to NHDs on the EVMOC 951, in the depicted embodiment, and for separate virtual network address assignment 952 to virtual network interfaces 972 programmatically attached to the RCI 970. The encapsulation protocol implemented in the VCS and the mapping between substrate addresses and IVN addresses may be used, in various embodiments, for communication between the RCI and entities external to the RPS.

[0092] FIG. 10 illustrates aspects of workload migration techniques that may be employed for radio-based applications, according to at least some embodiments. In the exemplary scenario depicted in FIG. 10 , an RCI 1020A may be instantiated in an RPS 1010 with an EVMOC 1018A that includes an NFA of the type discussed above. The RCI 1020A may include a version 1025A of one or more programs (e.g., an L2 implementation program or L2P) that perform a portion of the DU (Distributed Unit) functionality of radio-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 the RPS 1010. To implement the DU functionality, state information regarding messages or traffic between pairs of layers of RBA1 is maintained at the RCI and may be accessed by the version 1025A of the program. Such RBA1 state information 1027, in the depicted embodiment, may include, for example, state information regarding fronthaul traffic (DU-RU traffic) and midhaul traffic (DU-CU traffic).

[0093] The VCS control plane server 1002 of the VCS, in the depicted embodiment, may be responsible for detecting a trigger condition for migrating the RBA1 workload originally running on RCI 1020A to another RCI 1020B. One or more control plane agents used for the migration may, in some embodiments, run locally on the RPS 1010, e.g., as part of the virtualization management layer or as part of RCI 1020A. Any of a variety of 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 detection of an error in the RPS 1010.

[0094] In the embodiment depicted in FIG. 10 , a determination may be made by the VCS control plane server 1002 that at least a subset of the operations of RBA1 should be migrated to the updated / upgraded RCI 1020B. RCI 1020A may be referred to as the RBA1 workload migration source, and RCI 1020B may be referred to as the RBA1 workload migration destination (or a migrated version of RCI 1020A) in the depicted embodiment. In FIG. 10 , RCI 1020B operates on a different RPS 1012 than RCI 1020A, and RPS 1010 may be referred to as the migration source RPS, and RPS 1012 may be referred to as the migration destination RPS. RCI 1020B may include version 1025B of a program implementing the DU functionality of RBA1. Version 1025B may, in the depicted embodiment, include an updated / upgraded version of the DU implementation program (whose previous version was version 1025A).

[0095] In response to determining that RBA1's workload should be migrated, state information needed to perform an RBADU operation at RCI 1020B may, in various embodiments, be transferred to RCI 1020B. In the depicted embodiment, as indicated by arrow 1066A, at least a subset of RBA1's midhaul and / or fronthaul traffic state information 1027A may be transferred to RCI 1020A without pausing RBA1. Similarly, in various embodiments, as indicated by arrow 1066B, at least a subset of additional RCI state information 1028 (e.g., networking state information, memory contents, device state information, etc., for traffic categories other than fronthaul or midhaul traffic) may also be transmitted to RCI 1020B without pausing RBA1 or other applications executing on RCI 1020A. 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, may help avoid interruptions to end-user visible functionality of RBA1 and / or other applications originally executing on RPS 1010. Finally, in the depicted embodiment, after all state information that can be transferred without pausing RBA1 has been sent to RCI 1020B, RBA1 may be paused for a short period of time to transfer any remaining state information. After the state information has been completely transferred, DU operation for RBA1 may be initiated in the updated / upgraded RCI 1020B, which, in the depicted embodiment, may resume DU functionality using the migrated RBA1 state information 1037. The migrated additional RCI state information 1038, in the depicted embodiment, may be used to resume other operations previously performed on RCI 1020A.

[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, that are responsible for coordinating the transition of the DU functionality with other components of the RBA1 (such as CU layer components or RU layer components). For example, the other components may be notified via one or more messages about the pending transition of the DU, so that the other components can perform one or more preparatory actions (e.g., saving or backing up their own state information in case the transition fails for some reason). Fronthaul traffic 1091A that initially flowed between the RU 1090 and the NFA in the EVMOC 1018A may flow between the RU 1090 and the NFA in the EVMOC 1018B of the RPS 1012, as shown by arrow 1091B in the depicted embodiment, after the transition of the state information is complete and the RU is notified about the transition. During the transition procedure, in some embodiments, the routing component of the provider network may implement traffic mirroring such that messages being sent from the RU 1090 to the NFA of EVMOC 1018A are also sent to the NFA of EVMOC 1018B.

[0097] FIG. 11 illustrates example categories of network traffic for a radio-based application processing server, according to at least some embodiments. The RPS 1110 may include an EVMOC 1191 (including one or more NFAs, one or more NHDs, and a virtualization controller) and an RCI 1120A in which at least a portion of the DU functionality of the radio-based application RBA1 may be implemented. The RPS 1110, in the depicted embodiment, may be located in a facility outside the provider network data center, e.g., in a local zone, or as part of a VCS extended resource group configured in a facility selected by a VCS client. The RCI 1120A, in the depicted embodiment, may be configured as part of an isolated virtual network (IVN) 1145 of the provider network's VCS, e.g., by assigning an IP address in a range of IVN IP addresses to the RCI 1120A. The IVN 1145 may include one or more other RCIs, such as a local RCI 1120B, in the same facility as the RPS 1110, which may also be used to run a portion of RBA1, e.g. RCI 1120B may operate on a different RPS than RPS 1110. IVN 1145 may also include one or more compute instances 1122 running on a virtualization server in the provider network's data center in the scenario shown in FIG. 11 . Additionally, in some cases, IVN 1145 may include one or more other local compute instances that are not optimized for wireless-based applications but that also run in the same facility as RPS 1110. Each of the compute instances in IVN 1145, including instances 1122, 1120A, and 1120B, may be assigned an IP address within a 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 attached to the compute instance by a VCS control plane server, thereby effectively assigning the IP address to the compute instance.

[0098] The RPS 1110, in the depicted embodiment, may participate in at least five categories of network traffic exchange. Fronthaul traffic 1161 may flow between an NFA of the EVMOC 1191 of the RPS 1110 and one or more RUs of RBA 1, such as RU 1104. Midhaul traffic 1162 may flow between the RPS 1110 and one or more CUs of RBA 1, such as CU 1102. Control plane traffic 1163 (e.g., commands to configure an NFA, activate an RCI, terminate an RCI, or migrate an RCI workload) may be directed to the RPS 1110 from VCS control plane resources located in a data center of the provider network. Messages directed from applications running on the RPS 1110 to or from other services 1144 of the provider network (e.g., storage services or database services) may constitute non-VCS service traffic 1164 in the depicted embodiment. In some cases, the facility on which the RPS 1110 is configured 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 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. A final category of network traffic, referred to as intra-IVN traffic, may include, in the depicted embodiment, traffic 1165A between the RPS's RCI 1120A and other local compute instances 1120B (intra-IVN traffic 1165A) and traffic between the RPS and compute instances 1122 in the provider network's data center (intra-IVN traffic 1165B).

[0099] In some embodiments, as mentioned above, EVMOC 1191 may include several networking hardware devices, or NHDs, each of which may be selected (e.g., based on commands from VCS control plane server 1101) from among a set of NHDs for one or more of the traffic categories shown in FIG. 11. For example, one NHD may be used for fronthaul traffic, another NHD may be used for midhaul traffic, and so on. For example, various networking-related configuration settings of IVN 1145 (including settings related to network security), selected by the clients it represents, may, in some embodiments, be applied to RBA1's midhaul and fronthaul traffic in addition to being applied to other traffic of the compute instances configured within IVN 1145.

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

[0101] Metadata 1220 may include, for example, in the depicted embodiment, VNI IP address 1222 (which can be used as the source or destination address of packets originating from or destined for the compute instance containing the RCI), security group 1224, network access control list (ACL) 1226, route table 1228, and 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 the compute instance, controlling inbound and outbound traffic. A customer can define security groups as policies that can be applied to a particular instance. 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 in a subnet can be assigned a different set of security groups. To each security group, a customer can add rules that control inbound traffic to the instance and a separate set of rules that control outbound traffic. Security groups can be stateful in that return traffic is automatically allowed.

[0102] Customers can also configure network access control lists (ACLs) with rules similar to security groups to add an additional layer of security to the IVN. Network ACLs operate at the subnet level, support allow and deny rules, and are automatically applied to all instances in any associated subnet. Network ACLs may not be stateful, in that return traffic must be explicitly allowed by a rule. The same security group may be used or replicated for multiple compute instances. VCS clients may use only security groups without network ACLs, network ACLs without security groups, or both security groups and network ACLs, as desired. 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 indication 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 responsible for ensuring that the rules are enforced. For example, the control plane server may have the networking components of the VCS (such as the virtualization manager / hypervisor, routers, and other networking device networking components) verify that rules associated with inbound traffic will not be violated by any packet or message before delivering it to the applicable compute instance or NFA. Packets whose delivery would violate rules may be dropped in some implementations. Similarly, for outbound packets / messages, the VCS networking components may verify that outbound traffic security rules are not violated before forwarding the packet along the path 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 through a programmatic interface, and such routing entries may be stored in a route table 1228 that, in the depicted embodiment, is maintained as part of the IVN metadata. Clients, in some embodiments, may define one or more subnets 1230 within the IVN and may use compute instances configured in different subnets for respective applications as needed.

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

[0106] In some embodiments, the provider network may enable clients to launch compute instances selected from several different categories arranged into instance families. FIG. 13 illustrates exemplary categories of compute instances that may be configured on behalf of clients of a virtualized computing service, according to at least some embodiments. The instance families supported in the depicted embodiment include general-purpose compute instances 1310, GPU-based compute instances 1315, storage-optimized compute instances 1320, and wireless-optimized compute instances 1325. The families (other than the general-purpose family) may be optimized in some manner for their respective types of applications; for example, applications requiring large amounts of fast persistent writes or reads may be optimized for storage-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] Some of the instance families may then include several instance categories differentiated from one another based on characteristics such as performance capabilities. Small GPCI 1311 of general-purpose compute instance 1310 may, for example, have fewer virtual CPUs and a smaller amount of available memory than medium GPCI 1312, which in turn may have fewer virtual CPUs and a smaller amount of available memory than large GPCI 1313. Similarly, small GPU CI 1316 of a GPU-based family may have fewer virtualized GPUs available to client applications than medium GPU CI 1317, and large GPU CI 1318 may have more available virtual GPUs than medium GPU CI. More and / or faster persistent storage devices may be accessible from large SCI 1323 of storage-optimized compute instance 1320 than from medium SCI 1322, and small SCI 1321 may have less storage capacity or slower storage devices than medium SCI.

[0108] Radio optimization compute instances (RCIs) 1325 may, in some embodiments, be divided into categories based not only on performance differences but also on the type of NFA accessible from the RCI. Among performance-capacity-based RCI types 1356, a small RCI 1326 may be capable of executing network functions at a slower aggregate rate (and may have fewer vCPUs and less memory) than a medium RCI 1327, which in turn may be capable of executing network functions at a slower aggregate rate (and may have fewer vCPUs and less memory) than a large RCI 1328. Some RCI categories may, in the depicted embodiment, be defined based on the type of NFA of an EVMOC accessible from the RCI. NFA category-based RCI types 1358 may include, for example, an NFA Type A RCI 1329 in which an EVMOC may be configured with a virtualization server including a Type A NFA, an NFA Type B RCI 1330 in which an EVMOC may be configured with a virtualization server including a Type B NFA, etc. In some embodiments, the RCIs may also be grouped into categories using a combination of available accelerator types and performance capabilities; for example, RCI categories “Small NFA-Type-A,” “Large NFA-Type-A,” etc. may be defined by the provider network. In at least one embodiment, the maximum number of NFAs available for radio-based applications implemented with the aid of the RCIs may be determined based on the RCI category. For example, assume that an RPS's EVMOC has 16 NFAs. In some implementations, only a maximum of four of the 16 NFAs may be available from the “small” RCIs, only a maximum of eight of the 16 NFAs may be available from the “medium” RCIs, etc.

[0109] FIG. 14 illustrates exemplary facilities and sites where wireless-based application processing servers may be deployed, according to at least some embodiments. In the embodiment depicted in FIG. 14 , resources of 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 in turn include one or more data centers located relatively close to one another (e.g., within the same state or metropolitan area). In the example shown in FIG. 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 of one or more services, such as a virtualized computing service (VCS), similar to VCS 110 of FIG. 1, and / or a wireless-based application management service (RBAMS).

[0110] RPSs of the type described above, in the depicted embodiment, may be configured in a variety of facilities other than the provider network's own data center 1412 in response to program requests from clients. Such facilities may include, among other facilities, in different embodiments, 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, RPSs 1460A and 1460B may be configured at the point-of-presence site 1430, for example, in a single rack. RPSs 1460C and 1460D may be configured at the local zone 1440, RPSs 1460F and 1460G may be configured at a client-owned facility 1425, and RPSs 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 an antenna). In some embodiments, other types of facilities and locations may be used for RPSs instead of or in addition to those shown in FIG. 14 . From each RPS in a given facility, in various embodiments, a connection may be established with a control plane server of the provider network, typically with a radio unit (RU) located very close to or within the facility. After such a connection is verified, in various embodiments, software components such as separate request handlers and L2Ps may be launched in the RPS to handle radio-based application workloads such as those described above.

[0111] 15 is a flow diagram illustrating aspects of operations that may be performed to manage a radio-based application that includes network functions executing in an accelerator embedded within a virtualization management offload card, according to at least some embodiments. As shown in element 1501, one or more control plane servers (CPSs) of a cloud provider network's virtualization computing service (VCS) or radio-based application management service (RBAMS) may assign a network address (e.g., an IP version 4 or IP version 6 address) that is part of the VCS's board or physical network to a networking hardware device (NHD) embedded within an enhanced virtualization management offload card (EVMOC) of a radio-based application processing server (RPS), which is also a virtualization server for the VCS. The RPS may, in at least some embodiments, be located in a facility outside the VCS's data center where the CPS is located, for example, to enable some of the RBA's operations to be performed closer to the RBA's antenna or end-user device, thereby supporting low latency for such operations. The EVMOC may also include network function accelerators (NFAs), e.g., implemented using one or more specialized chipsets, optimized to perform network functions at one or more layers of a radio-based technology stack, including, e.g., functions at the distributed unit (DU) layer of a 5G RAN stack. The EVMOC may also include one or more virtualization management components used to launch and manage one or more compute instances or virtual machines on the 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 launch a hypervisor component running on the virtualization server's primary processor instead of the offload card), network processing offloaders, etc. Performing a subset of virtualization management tasks on the offload card may allow more of the virtualization's primary processor and memory to be used for the compute instances.Similar benefits may be achieved by offloading some of the network functions of one or more RBAs to an NFA instead of using the virtualization server's primary processor for the network functions, and further, in at least some embodiments, the optimized circuitry of the NFA may be able to perform network function calculations faster than if the primary processor were used.

[0112] The CPS, in the depicted embodiment, may assign an address (different from the substrate network address) to be used for communications between the NFA and one or more radio units (RUs) of one or more RAN nodes of RBA RBA1 (element 1504). Additionally, in at least one embodiment, the CPS may assign an address within an isolated virtual network (IVN) configured for a VCS client on behalf of which at least some network functions of RBA1 will be executed to a virtual network interface (VNI) programmatically attached to a radio optimization compute instance (RCI) running in the RPS. The RNI may be initiated, for example, using a virtualization controller and other virtualization management components of the RPS.

[0113] In various embodiments, the CPS may store configuration settings for the IVN and the RCI, for example, in response to various programmatic requests from the VCS client. Respective sets of such IVN configuration metadata may be stored for different categories of traffic, e.g., in the depicted embodiment (element 1507), for the RCI's general traffic (e.g., network packets not transmitted as part of RBA1), for RBA1's fronthaul traffic, and for RBA1's midhaul traffic, effectively giving the VCS client the same type of configuration control over the NFA traffic provided to the RCI traffic. A given set of IVN configuration settings may include, for example, security groups (sets of firewall rules for inbound and outbound traffic for the 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 the RCI and / or NFA's traffic. The CPS, in various embodiments, may cause appropriate components of the system (e.g., virtualization management components running on the RPS, network intermediary devices such as VCS routers, etc.) to enforce security-related rules and rate limits. For example, before an individual packet is delivered to or from an RCI or NFA, the VCS networking infrastructure may verify that delivery of the packet will not violate applicable security rules and will not result in the violation of applicable traffic rate limits.

[0114] The CPS may automatically perform several other configuration-related tasks for an RBA, such as RBA1, in the depicted embodiment (element 1510), without requiring the VCS client's ongoing participation. For example, the CPS may be responsible for installing / updating firmware / software on the NFA, including bug fixes and security patches. The CPS, in various embodiments, may monitor the health status of the NFA and RCI and provide health status indications 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 representations 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 to migrate at least a portion of RBA1's workload to another RPS may be made based at least in part on an analysis of collected metrics (e.g., performance metrics or health status metrics) and / or based on a migration request submitted programmatically by the VCS client. The CPS may orchestrate the migration procedure, which may require replication of state information from the RCI and state information for fronthaul and / or midhaul traffic (some of which may be obtained from the NFA) at the destination, as previously discussed. Respective virtualized representations of the NFA may, in some embodiments, be provided to multiple RCIs running in the RPS, allowing several RBAs or RBA pipelines to run in parallel while sharing access to the NFA.

[0115] In various embodiments, respective portions of the logic of RBA1 may be executed in the RCI and the NFA. For example, in the downlink direction flow of RBA1 operation, some network functions of the DU of RBA1 may be executed in the RCI in response to messages received via addresses assigned to the VNI of the RCI from other components of RBA1 running on other servers (element 1513). Using the results or output of such network functions, additional network functions lower in the radio-based technology stack, such as various physical layer or L1 functions, may be executed in the NFA (element 1516), and the results of these network functions may be transmitted from the NFA to one or more RUs using addresses assigned to the NFA for fronthaul communications. Traffic may also flow in the uplink direction, for example, from the end user device via the RU to the NFA (where some network functions may be executed) and from the NFA to the RCI (where other network functions may be executed), with the results of the RCI-executed network functions potentially being transmitted to a destination external to 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 that shown, or may be performed in parallel rather than sequentially. Additionally, some of the operations shown in Figure 16 may not be required in one or more implementations.

[0116] 16 illustrates an exemplary programmatic interaction between a client and a provider network service for a wireless-based application, according to at least some embodiments. In the depicted embodiment, the provider network service 1612 (such as a VCS or a 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, an API, etc., that can be utilized by service clients to submit messages or requests to the service and receive corresponding responses.

[0117] The client 1610 may use programmatic interface 1677 to send a RadioBasedApplicationsDescriptor message 1614 to the service 1612 indicating a set of nearby cell locations where an RPS may be needed, the expected workload at those locations (e.g., how many end user devices are expected to be utilized at each location for the client's radio-based application, such as a public 5G network or a private 5G network, the approximate expected message rates from end users at various times of day or days of the week, etc.), the desired quality of service for the RBA (e.g., message latency for different types of traffic), etc. 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 such card's NFA) versus multi-tenancy (e.g., that the client desires to share the RPS and / or network function accelerator with other clients), whether the client requires an NFA from a particular vendor or desires to use any of several vendors, etc. The information provided by the client may be analyzed in the provider network, for example, by a configuration manager in a control plane server of a VCS, and recommendations for RPS configurations that can be used to meet the estimated requirements of the client's applications may be prepared. For example, recommendations that may indicate the number and type of RPSs 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 depicted embodiment. Note that in some cases, some of the locations indicated in the recommendations may already have one or more RPSs installed and configured, for example, for other clients that have previously submitted information about their wireless-based application workloads.

[0118] If the client approves the recommendation, an RPSConfigApproved message 1617 may be sent to the service 1612 via interface 1677. If a new RPS needs to be transported and installed at the approved recommended sites, the process for doing so may be initiated by the provider network operator (note that this process may take some time, e.g., several days in some cases). In some cases, additional RPSs may be added to the set of pre-installed RPSs (either in use 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, if the client does not indicate a tenant preference, depending on the default setting of the service 1612) has been identified and connectivity between the RPS and the provider network's control plane resources has been verified, an RPSsReady message 1621 may be sent to the client, in some embodiments, to indicate that the client can request the launch of compute instances for their radio-based applications. In some embodiments, an identifier for each of the RPSs designated for the client's use may be provided in the RPSsReady message, and such identifier may be used by the client to request the launch of a radio optimization computation instance on the respective RPS. In some embodiments, before the client's radio optimization computation instance is launched, service 1612 may also verify that connectivity has been established between the RPSs designated for the client's use and (a) the RUs (radio units) 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 connectivity to the RUs and / or CUs may be performed after the computation instance is launched.

[0119] 16, the client 1610 may utilize the programmatic interface 1677 to indicate preferences regarding various aspects of the configuration of the components of the RBA executed using the RPS, including, for example, information regarding the IVN on which the RCI is activated (which may have been created earlier in response to a program request from the client), preferred addresses or address ranges for various components such as the RCI's VNIs or NFAs, security rules for various categories of RBA traffic, traffic rate limits, etc. Such preferences may be indicated in one or more RBAConfigSettingsPreferences messages 1622 to the service 1612. The preferences indicated by the client may be stored in the service's repository, and an RBAConfigSettingsSaved message 1623 may be sent to the client.

[0120] The client 1610, in various embodiments, may submit one or more LaunchRCIs requests 1624 via a programmatic interface 1677, indicating, for example, a site / facility, ERG, or particular RPS where one or more RCIs of a specified category (such as the RCI types shown in FIG. 13) are to be instantiated for the client's application. An RCIsLaunched message 1625 may, in some embodiments, be sent to the client 1610 to confirm that the RCIs have been launched. In some embodiments, configuration information about the launched 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 the service 1612, requesting metrics collected for one or more of the traffic categories shown in FIG. 11 over one or more RPSs. The requested set of metrics may be provided to the client via one or more TCMetricSet messages 1633, in the depicted embodiment. For example, the client may obtain metrics for fronthaul traffic only, such as the number of messages transmitted to or from the RU during a time interval, the total amount of data transferred to or 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 broken down by NHD; for example, a separate set of metrics for a given category of traffic transmitted over two NHDs of an RPS may be provided to each NHD, as needed. Other types of programmatic interactions for implementing wireless-based applications using provider network resources may be supported in some embodiments other than those shown in FIG. 16.

[0122] In at least some embodiments, a server implementing techniques of the type described herein (e.g., various functions of a provider network service such as a VCS, including functions within the provider network service as well as functions at extended sites) may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media. FIG. 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 suitable number). The processor 9010 may be any suitable processor capable of executing instructions. For example, in various embodiments, the processor 9010 may be a general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, ARM, or MIPS ISA, or any other suitable ISA. In a multiprocessor system, each of the processors 9010 may, but need not, commonly implement the same ISA. In some implementations, a graphics processing unit (GPU) and / or a field-programmable gate array (FPGA) may be used in place 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 volatile and non-volatile portions, 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. For the non-volatile portion of the system memory (which may include, for example, one or more NVDIMMs), in some embodiments, flash-based memory devices, including NAND flash devices, 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 power storage device (e.g., a battery). In various embodiments, any 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 embodiment, program instructions and data implementing one or more desired functions, such as the methods, techniques, and data described above, are shown stored within 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 other peripheral interfaces such as the network interface 9040 or various types of persistent and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocol, timing, or other data conversion 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 attached through various types of peripheral buses, such as, for example, 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 split into two or more separate components, such as, for example, a northbridge and a southbridge. Also, in some embodiments, some or all of the functionality of the I / O interface 9030, such as the interface to the system memory 9020, may be incorporated directly into the processor 9010.

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

[0127] In some embodiments, system memory 9020 may represent one embodiment of a computer-accessible medium configured to store at least a subset of the program instructions and data used to implement the methods and apparatus discussed in the context of FIGS. 1-16. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible medium. Generally speaking, computer-accessible medium may include non-transitory storage or memory media, such as magnetic or optical media, such as disks or DVDs / CDs, coupled to computing device 9000 via I / O interface 9030. Non-transitory 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, etc., that may be included in some embodiments of computing device 9000 as system memory 9020 or another type of memory. In some embodiments, multiple non-transitory 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, conveyed over communications media, such as networks and / or wireless links, such as may be implemented via network interface 9040. Portions or all of multiple computing devices, such as those illustrated in FIG. 17, may be used to implement the functionality described in various embodiments; for example, software components executing on various different devices and servers may cooperate to provide functionality. In some embodiments, portions of the functionality described may be implemented using storage devices, network devices, or dedicated computer systems in addition to, or instead of, being implemented using a general-purpose computer system. As used herein, the term “computing device” refers to at least all of these types of devices, but is not limited to these types of devices.

[0128] conclusion Embodiments of the present disclosure can be described in light of the following clauses. Clause 1. A system comprising: a set of control plane servers for a virtualized computing service in a cloud provider network; a virtualization server including a primary processor and an offload card, the offload card including: (a) a virtualization controller for compute instances running 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 to the networking hardware device a first network address within a substrate network of the virtualized computing service used for communication with one or more resources of a cloud provider network external to the virtualization server; assigning, using at least the virtualization controller, a second network address to a first compute instance launched on the virtualization server, wherein the second network address is not within a substrate network; assigning to the network function accelerator a third network address used for communications between the network function accelerator and one or more radio units (RUs) of the one or more radio-based applications; The virtualization server stores the instructions, and when the instructions are executed on the primary processor, causing a first network function of a first wireless-based application to be executed at the first compute instance in response to a message received at the first compute instance, the message being received using a mapping between a second network address and the first network address; and causing a second network function of the first wireless-based application to be executed on a network function accelerator based at least in part on a result of the first network function, wherein an output of the second network function is transmitted to a radio unit of the first wireless-based application using a third network address. Clause 2. The system of clause 1, wherein the set of control plane servers is located in a data center of a cloud provider network, and the virtualization server is located in a facility external to the data center. Clause 3. The virtualization server stores further instructions, which, when executed on the primary processor, presenting a first virtualized representation of the network function accelerator to a first compute instance, wherein the second network function is executed in response to a first request from the first compute instance, the first request being received at the network function accelerator via an interface of the first virtualized representation; 3. The system of claim 1 or 2, further comprising: presenting a second virtualized representation of the network function accelerator to a second compute instance launched on the 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 being part of a second wireless-based application, and the second request from the second compute instance is received at the network function accelerator using an interface of the second virtualized representation. Clause 4. The system of any one of clauses 1 to 3, wherein the first network function is a 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 a network function at a physical layer of a wireless-based technology stack. Clause 6. A computer-implemented method comprising: performing, by a control plane server of a virtualized computing service of a cloud provider network, one or more configuration operations on an offload card of the virtualization server, the offload card including: (a) a virtualization controller for a compute instance; (b) a first network function accelerator for a wireless-based application; and (c) a networking hardware device, the 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; launching, by the control plane server using at least the virtualization controller, a first compute instance on the virtualization server, wherein the first compute instance performs a first network function of the first wireless-based application in response to a message received using the first network address; 1. A computer-implemented method comprising: executing, on a first network function accelerator, a second network function of a first wireless-based application in response to an output obtained from the first network function, wherein the output of the second network function is sent to a destination external to the virtualization server using the second network address as a source address. Clause 7. One or more constituent actions: 7. The computer-implemented method of clause 6, comprising updating firmware or software of the first network function accelerator. Clause 8. One or more constituent actions: monitoring the health status of the first network function accelerator; and causing the health status indicator to be provided via a programmatic interface of the virtualized computing service. Clause 9. One or more constituent actions: monitoring performance metrics of the first network functions accelerator; and providing an indication of performance metrics via a programmatic interface of the virtualized computing service. Clause 10. One or more constituent actions: 10. The computer-implemented method of any one of clauses 6 to 9, comprising applying a security patch to the first network function accelerator. Clause 11. One or more constituent actions: 11. The computer-implemented method of any one of clauses 6-10, comprising scrubbing contents of a memory of the first network function accelerator in response to detecting that the first computational instance has been terminated. Article 12. presenting a first virtualized representation of the first network function accelerator to a first compute instance to enable the first compute instance to transmit requests for network functions of the first wireless-based application to the first network function accelerator; 12. The computer-implemented method of any one of clauses 6 to 11, further comprising: presenting a second virtualized representation of the first network function accelerator to a second compute instance launched on the virtualization server using at least the virtualization controller, and enabling the second compute instance to transmit requests for network functions of the second wireless-based application to the first network function accelerator. Article 13. 13. The computer-implemented method of any one of clauses 6-12, further comprising: migrating, by the control plane server, at least a portion of the workload of the first wireless-based application to another virtualization server, the other virtualization server including an offload card with a second network function accelerator, whereby as a result of the migration, (a) messages from a radio unit of the first wireless-based application are delivered to the second network function accelerator, and (b) the migrated version of the first compute instance executes a first network function of the first wireless-based application on the other virtualization server. Clause 14. The computer-implemented method of any one of clauses 6 to 13, wherein the second network function comprises an L1 network function of a wireless-based technology stack. Clause 15. The computer-implemented method of any one of clauses 6 to 14, wherein the first network function comprises a network function of a distributed unit (DU) of a wireless-based technology stack. Clause 16. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server of a virtualized computing service, the control plane server comprising: assigning a first network address to a networking hardware device of an offload card of the virtualization server, the offload card including: (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, the second network address being used for communications between the network function accelerator and a radio unit of the wireless-based application; 1. A non-transitory computer-accessible storage medium configured to: use a virtualization controller to launch a compute instance at a virtualization server, the compute instance (a) executing a first network function of a wireless-based application in response to a request received using a first network address; and (b) requesting execution of a second network function of the wireless-based application at a network function accelerator, wherein an output of the second network function is transmitted to a wireless unit using a second network address. Clause 17. The control plane server: 17. The non-transitory computer-accessible storage medium of clause 16, further configured to allow firmware or software of the network function accelerator to be updated. Clause 18. The control plane server: monitoring the health status of the network function accelerator; 18. The non-transitory computer-accessible storage medium of clause 16 or 17, further configured to: Clause 19. The non-transitory computer-accessible storage medium of any one of clauses 16 to 18, wherein the second network function includes an L1 network function of a wireless-based technology stack. Clause 20. The non-transitory computer-accessible storage medium of any one of clauses 16 to 19, wherein the first network function comprises a network function of a distributed unit (DU) of a wireless-based technology stack. Clause 21. A server: a processor; Memory and an offload card, the offload card including: (a) a virtualization controller; and (b) a network function accelerator for wireless-based applications; The virtualization controller performing one or more configuration tasks for the compute instances launched on the server, including allocating at least a portion of memory used by the compute instances; The memory stores instructions, which, when executed on the processor, executing a first network function of a wireless-based application on the compute instance; a server configured to cause an output of a first network function to be provided as an input to a second network function of a wireless-based application, the second network function being provided as an input to be executed on a network function accelerator. Clause 22. An offload card includes a network processing offloader and a networking hardware device that is assigned a network address within a substrate network of a virtualized computing service, wherein the network processing offloader: 22. The server of clause 21, configured to transmit one or more messages associated with the wireless-based application from the compute instance to a destination external to the server using a networking hardware device. Clause 23. The server of 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 a centralized unit (CU) of the radio-based application, and the second networking hardware device being used to transmit messages to a second set of destinations including a radio unit (RU) of the radio-based application. Clause 24. The offload card includes another network function accelerator, and the memory stores further instructions, which, when executed on the processor, 23. The server of clause 21 or 22, causing the server to provide input to a third network function running on another network function accelerator. Clause 25. The server of clause 24, wherein the third network function is performed as part of another wireless-based application. Clause 26. A computer-implemented method comprising: performing, by a virtualization controller operating on an offload card of the server, one or more configuration tasks for a first compute instance launched on the server, including allocating at least a portion of the server's memory for use by the first compute instance, the offload card including a first network function accelerator for a wireless-based application; executing a first network function of a first wireless-based application on a first computing instance; and executing a second network function of the first wireless-based application at a first network function accelerator, wherein an input of the second network function is based at least in part on an output of the first network function. Clause 27. The offload card includes a first networking hardware device that is assigned a first network address within a substrate network of a virtualized computing service; and a computer-implemented method comprising: 27. The computer-implemented method of claim 26, further comprising transmitting, using the first networking hardware device, one or more messages associated with the first wireless-based application from the first compute instance to the second compute instance. Clause 28. The computer-implemented method of 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 a centralized unit (CU) 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 a radio unit (RU) of the first wireless-based application. Clause 29. The computer-implemented method of clause 28, wherein the second networking hardware device is assigned a second network address within the isolated virtual network of the virtualized computing service. Clause 30. The offload card includes a second network function accelerator, and the computer-implemented method comprises: 27. The computer-implemented method of clause 26, further comprising executing a third network function in a second network function accelerator. Clause 31. The computer-implemented method of clause 30, wherein the third network function is performed as part of a second wireless-based application. Article 32. presenting a first virtualized representation of the first network function accelerator to the first compute instance to enable requests for network functions of the first wireless-based application to be transmitted from the first compute instance to the first network function accelerator; 27. The computer-implemented method of claim 26, further comprising: presenting a second virtualized representation of the first network function accelerator to a second compute instance launched at the server to enable requests for network functions of a second wireless-based application to be transmitted from the second compute instance to the first network function accelerator. Article 33. 33. The computer-implemented method of any one of clauses 26, 27, 30, or 32, further comprising updating firmware or software of the first network functions accelerator in response to a message received from a control plane server of the virtualized computing service. Clause 34. The computer-implemented method of any one of clauses 26, 27, 30, or 32 or 33, wherein the first network function implements at least a portion of one of: (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. The computer-implemented method of any one of clauses 26, 27, 30, or 32-34, wherein the second network function implements an L1 network function of a wireless-based technology stack. Clause 36. A non-transitory computer-accessible storage medium storing program instructions, which, when executed on a processor of an offload card of a server, performing one or more virtualization management tasks with respect to the compute instances launched on the server, including allocating at least a portion of the server's memory for use by the compute instances; obtaining, from the compute instance, a request for a first network function of the wireless-based application; A non-transitory computer-accessible storage medium that performs a first network function in a network function accelerator embedded within the offload card. Clause 37. The non-transitory computer-accessible storage medium of clause 36, wherein the offload card is linked to the processor of the server via a peripheral interface. Clause 38. Storing further program instructions, which when executed on the processor of the offload card: From another compute instance, a request is received for a second network function. 38. The non-transitory computer-accessible storage medium of clause 36 or 37, performing a second network function in a network function accelerator. Clause 39. A non-transitory 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: (a) a distributed unit (DU) of a radio access network (RAN) node; (b) a centralized unit (CU) of a RAN node; or (c) a core network of a radio-based technology stack. Clause 40. An offload card includes a first networking hardware device, and a non-transitory computer-accessible storage medium stores further program instructions, which, when executed on a processor of the offload card, 40. A non-transitory computer-accessible storage medium as described in any one of clauses 36 to 39, wherein a first networking hardware device is used to transmit one or more messages associated with a wireless-based application to a destination external to the server. Clause 41. A system comprising: a control plane server of a virtualized computing service of a cloud provider network; a virtualized server including a network function accelerator for wireless-based applications; The control plane server: Establishing an isolated virtual network on behalf of a client of a virtualized computing service; storing, in response to a first request submitted by a client via a programmatic interface of the virtualized computing service, in a repository of isolated virtual network metadata, 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 in the isolated virtual network, the first security group includes a first restriction on a source of inbound traffic directed to the compute instance, and the compute instance performs a first network function of a wireless-based application; storing, in response to a second request submitted by the client via the programmatic interface, in the repository a representation of a second security group associated with the network function accelerator, the second security group including second restrictions on destinations of outbound traffic from the network function accelerator, the network function accelerator performing a second network function of the wireless-based application; verifying that a first network message of the wireless-based application complies with a first constraint before delivering the first network message to the compute instance using the network address as a destination address, the first network message at least partially resulting in the execution of a first network function; a system configured to: verify that a second network message of a wireless-based application complies with a second constraint before delivering the second network message from the network function accelerator to a destination, wherein an output of the first network function at least partially results in the execution of the second network function; Clause 42. The control plane server: 42. The system of claim 41, further configured to prevent the third network message originating from the network function accelerator from being delivered to the destination in response to determining that delivery of the third network message would violate a rate limit associated with traffic of the network function accelerator. 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: 43. The system of clause 41 or 42, further configured to launch a compute instance using the virtualization controller in response to another request. Clause 44. The control plane server: 44. The system of any one of clauses 41 to 43, further configured to: in response to another request, store in the route table of the isolated virtual network a route table entry for midhaul traffic of the radio-based application, the midhaul traffic including a message generated at a distributed unit (DU) of the radio-based application and directed to a centralized unit (CU) of the radio-based application, the message being generated at the virtualization server. Clause 45. The control plane server: 45. The system of any one of clauses 41-44, further configured to assign a network address from a range of network addresses of the isolated virtual network to the network function accelerator. Clause 46. A computer-implemented method comprising: storing, in response to a first program request, a representation of a first set of configuration settings for a compute instance configured in an isolated virtual network and launched on a virtualization server, the compute instance implementing a first network function for a wireless-based application, the virtualization server including a network function accelerator for the wireless-based application, and the first set of configuration settings including a first network security rule set to be applied to traffic of the compute instance; storing, in response to the second program request, a representation of a second set of configuration settings for the network function accelerator, the second set of configuration settings including a second network security rule set to be applied to traffic of the network function accelerator; verifying that a first network message complies with a first network security rule set before delivering the first network message to the compute instance, wherein delivery of the first network message results in execution of a first network function on the compute instance; and verifying that a second network message complies with a second network security rule set before delivering the second network message from the network function accelerator to a destination external to the virtualization server, the second network message including an output of a second network function executed on the network function accelerator. Clause 47. A virtualization server includes an offload card, the offload card including a network function accelerator and a virtualization controller, and a computer-implemented method comprising: 47. The computer-implemented method of clause 46, further comprising launching a compute instance using the virtualization controller in response to another program request. Article 48. 48. The computer-implemented method of clause 46 or 47, further comprising: in response to another program request, storing in the route table of the isolated virtual network a route table entry for midhaul traffic of the radio-based application, the midhaul traffic including a message generated at a distributed unit (DU) of the radio-based application and directed to a centralized unit (CU) of the radio-based application, the message being generated at the virtualization server. Clause 49. A computer-implemented method, comprising: applying a second set of network security rules to traffic between the network function accelerator and a radio unit of a radio-based application; 49. The computer-implemented method of any one of clauses 46-48, further comprising storing a third network security rule set that applies to traffic between the network function accelerator and the wireless-based application concentration unit. Article 50. 50. The computer-implemented method of any one of clauses 46-49, further comprising assigning the network function accelerator a network address from a range of network addresses of the isolated virtual network. Clause 51. The computer-implemented method of any one of clauses 46-50, wherein the second network security rule set includes a network access control list that is applied to at least a portion of the network function accelerator's traffic, and the network access control list is applied to a subnet defined within the isolated virtual network. Clause 52. The computer-implemented method of any one of clauses 46-51, wherein the first network message is formatted according to the Internet Protocol (IP) and the second network message is formatted according to the Common Public Radio Interface (CPRI) or the enhanced Common Public Radio Interface (eCPRI). Clause 53. The computer-implemented method of any one of clauses 46-52, wherein the second network function comprises an L1 network function of a wireless-based technology stack. Clause 54. The computer-implemented method of any one of clauses 46 to 53, wherein the first network function comprises a network function of a distributed unit (DU) of a wireless-based technology stack. Clause 55. A virtualization server comprising an offload card, the offload card comprising a network function accelerator and a networking hardware device, and a computer-implemented method comprising: 47. The computer-implemented method of claim 46, further comprising: (a) assigning a first network address of a substrate network of the virtualized computing service to the networking hardware device; and (b) assigning a second network address to the compute instance, wherein the second network address is not part of the substrate network and network messages originating from a source external to 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-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server of a virtualized computing service, the control plane server comprising: storing, in response to a first program request, a representation of a first set of configuration settings for a compute instance configured in an isolated virtual network and launched on a virtualization server, the compute instance implementing a first network function for a wireless-based application, the virtualization server including a network function accelerator for the wireless-based application, and the first set of configuration settings including a first network security rule set to be applied to traffic of the compute instance; storing, in response to the second program request, a representation of a second set of configuration settings for the network function accelerator, the second set of configuration settings including a second network security rule set to be applied to traffic of the network function accelerator; verifying that a first network message complies with a first network security rule set before delivering the first network message to the compute instance, where delivery of the first message results in execution of a first network function at the compute instance; 1. A non-transitory computer-accessible storage medium configured to: verify that a second network message complies with a second network security rule set before delivering the second network message from the network function accelerator to a destination external to the virtualization server, the second network message including an 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: 57. The non-transitory computer-accessible storage medium of clause 56, further configured to launch a compute instance using the virtualization controller in response to another program request. Clause 58. The control plane server: 58. The non-transitory computer-accessible storage medium of clause 56 or 57, further configured to: in response to another program request, store in the route table of the isolated virtual network a route table entry for midhaul traffic of the wireless-based application, the midhaul traffic including a message generated at a distributed unit (DU) of the wireless-based application and directed to a centralized unit (CU) of the wireless-based application, the message being generated at the virtualization server. Clause 59. A second network security rule set is applied to traffic between the network function accelerator and the radio unit of the radio-based application, and the control plane server: 59. The non-transitory computer-accessible storage medium of any one of clauses 56 to 58, further configured to store, in response to another program request, a third network security rule set to be applied to traffic between the network function accelerator and the wireless-based application concentration unit. Clause 60. The control plane server: 59. The non-transitory computer-accessible storage medium of any one of clauses 56-59, further configured to, in response to another program request, assign to the network function accelerator a network address from a range of network addresses of the isolated virtual network.

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

[0130] The various methods as 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 having the benefit of this disclosure. All such modifications and changes are intended to be embraced and, therefore, the above description should be regarded in an illustrative rather than a restrictive sense.

Claims

1. 1. A system comprising: one or more computing devices; The one or more computing devices include instructions that, when executed on or across one or more computing devices, cause the one or more computing devices to implement a control plane server for a virtualized computing service, the control plane server: assigning a first network address to a networking hardware device of an offload card of a virtualization server, the offload card including: (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, the second network address being used for communications between the network function accelerator and a radio unit of a radio-based application; a first computing instance in the virtualization server using the virtualization controller, the first computing instance (a) executing a first network function of the wireless-based application in response to a first request received using the first network address; and (b) requesting execution of a second network function of the wireless-based application in the network function accelerator, the output of the second network function being transmitted to the wireless unit using the second network address.

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

3. the control plane server: presenting a first virtualized representation of the network function accelerator to the first compute instance, wherein execution of the second network function on the network function accelerator is requested from the first compute instance via an interface of the first virtualized representation; 3. The system of claim 1, further configured to present a second virtualized representation of the network function accelerator to a second compute instance launched on the virtualization server, wherein execution of a third network function on the network function accelerator is requested from the second compute instance via an interface of the second virtualized representation.

4. The system of any one of claims 1 to 3, wherein the first network function is a network function of a distributed unit (DU) of a radio-based technology stack.

5. The system of any one of claims 1 to 4, wherein the second network function is a network function at a physical layer of a radio-based technology stack.

6. 1. A computer-implemented method for a virtualized computing service, comprising: assigning a first network address to a networking hardware device of an offload card of a virtualization server, the offload card including: (a) a first network function accelerator for wireless-based applications; and (b) a virtualization controller for compute instances; assigning a second network address to the first network function accelerator, the second network address being used for communications between the first network function accelerator and a radio unit of a radio-based application; 12. A computer-implemented method comprising: using the virtualization controller to launch a compute instance at the virtualization server, the compute instance (a) executing a first network function of the wireless-based application in response to a request received using the first network address; and (b) requesting execution of a second network function of the wireless-based application at the first network function accelerator, wherein an output of the second network function is transmitted to the wireless unit using the second network address.

7. by the control plane server The computer-implemented method of claim 6 , further comprising: updating firmware or software of the first network function accelerator.

8. by the control plane server monitoring the health status of the first network function accelerator; The computer-implemented method of claim 6 or 7, further comprising: causing the health status indicator to be provided via a programmatic interface of the virtualized computing service.

9. by the control plane server monitoring performance metrics of the first network function accelerator; The computer-implemented method of any one of claims 6 to 8, further comprising: causing the virtualized computing service to provide an indication of the performance metrics via a programmatic interface of the virtualized computing service.

10. by the control plane server The computer-implemented method of any one of claims 6 to 9, further comprising: applying a security patch to the first network function accelerator.

11. by the control plane server 11. The computer-implemented method of claim 6, further comprising: in response to detecting that the computing instance has been terminated, scrubbing contents of a memory of the first network function accelerator.

12. by the control plane server 12. The computer-implemented method of 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, wherein as a result of the migration, (a) messages from a wireless unit of the wireless-based application are delivered to the second network function accelerator, and (b) a migrated version of the compute instance executes the first network function of the wireless-based application on the other virtualization server.

13. The computer-implemented method of any one of claims 6 to 12, wherein the second network function comprises an L1 network function of a wireless-based technology stack.

14. 1. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server for a virtualized computing service, the control plane server comprising: assigning a first network address to a networking hardware device of an offload card of a virtualization server, the offload card including: (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, the second network address being used for communications between the network function accelerator and a radio unit of a radio-based application; a non-transitory computer-accessible storage medium configured to: use the virtualization controller to launch a compute instance at the virtualization server, the compute instance (a) executing a first network function of the wireless-based application in response to a request received using the first network address; and (b) requesting execution of a second network function of the wireless-based application at the network function accelerator, wherein an 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 network function accelerator; 15. The non-transitory computer-accessible storage medium of claim 14, further configured to: cause the health status indicator to be presented via a programmatic interface of the virtualized computing service.

Images