Managing network function accelerators for radio-based applications from virtualized computing service control plane

Abstract

Respective network addresses are assigned by a control plane server of a virtualized computing service to networked hardware devices and network function accelerators incorporated into an offload card of a virtualized server. A virtualization controller using the offload card launches a compute instance at the virtualization server. The compute instance performs a network function of a radio-based application in response to a request received using the network address assigned to the hardware device, and requests to perform a second network function at the accelerator. A result of the second network function is transmitted to a radio of the application using the address assigned to the accelerator.

Description

Background Art

[0001] In recent years, several generations of broadband cellular communication technology have been deployed. 5G is the fifth generation technology standard for broadband cellular networks, which is gradually replacing the fourth generation (4G) standard of Long Term Evolution (LTE). 5G technology provides a significantly increased bandwidth, thereby broadening the cellular market beyond smartphones, thereby providing the last mile connection for desktops, set-top boxes, laptops, Internet of Things (IoT) devices, etc. Some 5G cells use a spectrum similar to that of 4G, while other 5G cells can use a spectrum in the millimeter wave band. Although the cells in the millimeter wave band may have a relatively small coverage area, it can provide a much higher throughput than 4G. As 5G technology becomes more common, new broadband-based applications may be developed and deployed. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An example system environment is presented in accordance with at least some embodiments in which a virtualized server whose virtualization management offload card includes a hardware network function accelerator can be used to run radio-based applications at least in part using resources of a virtualized computing service.

[0003] Figure 2 Example configurations of a radio-based application processing server with partially offloaded virtualized management functions are presented in accordance with at least some embodiments.

[0004] Figure 3 An overview of user plane and control plane layers defined according to a radio-based application technology standard according to at least some embodiments is presented.

[0005] Figure 4 Example uplink and downlink pipelines of network functions for radio-based applications are presented in accordance with at least some embodiments.

[0006] Figure 5 Example network functions that may be performed at the physical layer of a radio-based technology stack in accordance with at least some embodiments are presented.

[0007] Figure 6 An example hierarchy of devices that may be used for radio-based applications in accordance with at least some embodiments is presented.

[0008] Figure 7 An example deployment of L2 implementation procedures of a radio-based technology stack at a radio-based application processing server is presented in accordance with at least some embodiments.

[0009] Figure 8An example presentation of a virtualized representation of a compute instance running at a virtualized server by a hardware network function accelerator is presented in accordance with at least some embodiments.

[0010] Fig. 9 Example network function accelerator configuration management tasks are presented that may be performed or initiated by a control plane server of a virtualized computing service in accordance with at least some embodiments.

[0011] Fig.10 Aspects of workload migration techniques that may be used for radio-based applications in accordance with at least some embodiments are presented.

[0012] Fig.11 Example categories of network traffic for a radio-based application processing server are presented in accordance with at least some embodiments.

[0013] Fig.12 Example categories of isolated virtual network metadata associated with a radio-based application processing server are presented in accordance with at least some embodiments.

[0014] Fig.13 Example categories of computing instances that can represent client configurations of virtualized computing services are presented in accordance with at least some embodiments.

[0015] Fig.14 Example locations and sites are presented where radio-based application processing servers may be deployed in accordance with at least some embodiments.

[0016] Fig.15 is a flow chart illustrating aspects of operations that may be performed to manage radio-based applications including network functions executed at an accelerator incorporated within a virtualization management offload card, in accordance with at least some embodiments.

[0017] Fig.16 Example programmatic interactions between a client and a provider network service related to a radio-based application are presented in accordance with at least some embodiments.

[0018] Fig.17 is a block diagram illustrating an example computing device that may be used in at least some embodiments.

[0019] Although embodiments are described herein for several embodiments and illustrative drawings by way of example, it will be appreciated by those skilled in the art that embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and detailed descriptions thereof are not intended to limit the embodiments to the specific forms disclosed, but rather, are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope defined by the appended claims. The titles used herein are only for organizational purposes and are not intended to be used to limit the scope of this specification or claims. As used throughout this application, the word "may" is used in an allowed sense (i.e., meaning "possibly") rather than a mandatory sense (i.e., meaning "must"). Similarly, the words "include", "including" and "includes" are meant to include but are not limited to. When used in the claims, the term "or" is used as an inclusive rather than 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 otherwise expressly stated, articles such as "a" or "an" should generally be interpreted as including one or more of the items described throughout this application. Therefore, phrases such as "a device configured to..." are intended to include one or more of the listed devices. Such one or more listed devices may also be configured together to perform the stated enumeration. For example, "a processor configured to perform enumeration A, B, and C" may include a first processor configured to perform enumeration A working in conjunction with a second processor configured to perform enumeration B and C. Unless otherwise expressly stated, the term "a set" should generally be interpreted as including one or more of the items described throughout this application. Therefore, phrases such as "a set of devices configured to..." are intended to include one or more of the listed devices. Such one or more listed devices may also be configured together to perform the stated enumeration. For example, "a set of servers configured to perform enumeration A" may include a first server configured to perform enumeration A working in conjunction with a second server configured to perform enumeration B and C. DETAILED DESCRIPTION

[0020] The present disclosure relates to methods and devices for executing radio-based applications using a virtualized server equipped with an offload card, the offload card including network function accelerator hardware, a virtualization management component, and a networking hardware device. Such virtualized servers are also referred to as radio-based application processing servers or RPSs. In some instances, such RPSs can be managed by a cloud provider and can be based on the server design used by the cloud provider in its network, whereby the virtualized server includes one or more main processors running customer computing instances and an offload card running at least a portion of a virtualization controller, the virtualization controller managing the startup of computing instances on the virtualized server. The network function accelerator ("NFA") of the RPS can be used to implement a portion of the functions of various radio-based or telecommunication applications (e.g., various types of broadband cellular applications, such as dedicated 5G (fifth generation) networks, IoT (Internet of Things)-based applications, public 5G applications, etc.). In some instances, the NFA can perform certain L1 (or PHY) functions of the radio access network ("RAN") protocol stack, also known as real-time baseband processing. The control plane server of the virtualized computing service (VCS) can communicate with the virtualization management component on the offload card through the networking hardware device to initiate various types of management tasks at the server, including, for example, starting or terminating a computing instance or a virtual machine. The offload card can help reduce the workload of the main processor (e.g., CPU) of the virtualized server in at least two ways: by performing some of the virtualized tasks that would otherwise be performed at the main processor, and by performing at least some of the network functions of the radio-based applications that would otherwise be performed at the main processor. In addition, the NFA can, for example, use a custom chipset designed specifically for the network functions to perform at least some of the network functions faster than is feasible using the main processor. For example, the NFA can include a mix of digital signal processors (DSPs) and advanced RISC machine (ARM) cores optimized for L1 processing tasks.

[0021] Incorporating the NFA at the virtualization management offload card (VMOC) also enables the control plane server to perform many of the configuration operations required to manage the NFA, such as deploying firmware to the NFA, allocating networking addresses that can be used for fronthaul and midhaul traffic of radio-based applications (RBA) that use the NFA for network functions, and providing isolated virtual network (IVN) features for the NFA, such as security groups and customizable routing. In contrast to alternative approaches in which NFA cards incorporated into larger server designs can be accessed from bare metal compute instances in a non-virtualized manner, the NFA incorporated into the virtualization management offload card (VMOC) can be presented in a virtualized form to multiple compute instances running at the RPS, thereby simplifying network slicing of the RBA. While the control plane server is located at a data center of the cloud provider's network, the RPS itself can be located at a location selected by the RBA owner, for example, based on proximity to a cellular tower or antenna, thereby achieving the low latency required for high-end telecommunications applications such as 5G (fifth generation) applications.

[0022] As will be appreciated by those skilled in the art in light of the present disclosure, certain embodiments may be able to achieve various advantages, including some or all of the following: (a) enabling new radio-based applications to be quickly brought online and maintained using the provider network's time-tested resource provisioning, scalability, and availability techniques, (b) reducing the compute, memory, storage resources, and electrical power used for radio-based applications, for example by intelligently allocating and / or migrating workloads across available resources at various granularities and sharing resources among multiple applications, and / or (c) improving the user experience for administrators of radio-based applications by simplifying management and administration of applications using provider network tools and interfaces.

[0023] According to some embodiments, the system may include a group of one or more control plane servers (CPS) and virtualization servers of a VCS of a cloud provider network, the virtualization server including one or more main processors (e.g., CPU) and an offload card. The offload card may include (a) a virtualization controller for computing instances started at the virtualization server, (b) at least one NFA for radio-based applications, and (c) at least one networking hardware device (NHD). In some embodiments, the offload card may be linked to the main 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, wherein the memory or memories store instructions for implementing the logic of the virtualization controller, the NFA, and communication-related tasks performed using the NHD when executed on the processor. For example, the instructions of the offload card memory, when executed at the processor of the offload card, may enable the use of the NHD to transmit messages, or process the content of messages received through the NHD.

[0024] As part of its management responsibilities, a group of CPSs can allocate several network addresses for use by components of a virtualized server. For example, a network address within the underlying network of the VCS (the underlying physical network on which a virtual network can be configured) can be allocated to the NHD. The underlying network can be used for the cloud provider network to communicate with resources located outside the virtualized server. The group of CPSs can also allocate a second network address to a computing instance launched at the virtualized server with the help of a virtualization controller. In some embodiments, the second network address may not be part of the underlying network, but may be selected from the address range of an isolated virtual network (IVN) or a virtual private cloud (VPC). In various embodiments, in order to assign a second network address to a computing instance, a virtual network interface (VNI) managed by the group of CPSs can be programmatically attached to the computing instance, and the second network address can be assigned to the VNI. In addition, in some embodiments, the group of CPSs can also allocate a third network address to the NFA, which is used for communication between the NFA and one or more radio units (RUs) of a radio-based application (RBA). The virtualization server may store instructions that, when executed on the main processor of the virtualization server, perform a first network function of the RBA at the computing instance in response to a message received at the computing instance (e.g., from an RBA component running at some other computing instance at another virtualization server). In some embodiments, a mapping between a network address assigned to the computing instance and an underlying network address may be used to receive a message. Such a mapping may be used as part of an encapsulation protocol used at the VCS for conversion between a physical address of the underlying network and an address assigned to a computing instance within the virtualized network. In at least one embodiment, based at least in part on the result of the first network function, a second network function of the RBA may be performed at the NFA. Using a third network address assigned by the CPS as a source address, the output of the second network function may be transmitted to the RU of the RBA. Note that in some embodiments, a single network address assigned to a particular NHD on an offload card may be used for several different types of traffic, including, for example, fronthaul traffic and midhaul traffic of the RBA. In one embodiment, the NHD may have several network ports, and the corresponding ports may be used for different types of traffic.

[0025] A network function is a functional building block within a network infrastructure that has a well-defined external interface and well-defined functional behavior. Network functions can be linked together to form communication services. Network functions have historically been implemented as physical network devices or nodes; however, network functions can also be virtualized. In some embodiments, the core and RAN (radio access network) network functions cited herein may be based at least in part on the 3rd Generation Partnership Project (3GPP) specification, the European Telecommunications Standards Institute (ETSI) specification, and / or other wireless communication standards. RAN network functions are used in radio networks, typically running in cellular towers and performing wireless signal to IP (Internet Protocol) conversion. Core network functions typically run in large data centers that execute subscriber-related business logic and route IP traffic to the Internet and back. According to the present disclosure, both core network functions and RAN network functions may additionally or alternatively run on a radio-based application processing server (RPS) supplied as a virtualized server by a cloud provider, such as an edge device supplied to a customer to implement a private 5G network, or used by a wireless service provider or cloud provider to create a public 5G network. The term "radio-based application" (RBA) is used herein to refer to applications that use radio frequency signals and associated antennas to transmit at least some messages, such as applications used for different generations (4G, 5G, etc.) of cellular broadband technology. RBPAS may also be referred to as a radio access network (RAN) pipeline processing server, RAN server, RAN application server, or radio-based application server. Note that the technology described herein is not limited to any particular generation of cellular broadband, nor is it limited to applications that utilize any particular portion of the electromagnetic spectrum for message transmission.

[0026] In some embodiments, the network functions executed at the computing instance of the virtualized server may be, for example, part of a distributed unit (DU) of a 5G radio technology stack used by the RBA. In at least one embodiment, some of the network functions executed at the NFA may 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, encoding functions, rate matching functions, scrambling functions, modulation layer mapping functions, precoding functions, resource mapping functions, digital beamforming functions, fast Fourier transform (FFT) functions, cyclic prefix insertion functions, cyclic prefix removal functions, inverse FFT functions, demapping functions, channel estimation functions, pre-filtering functions, equalization functions, demodulation functions, descrambling functions, rate dematching functions, or decoding functions.

[0027] In various embodiments, in addition to assigning network addresses, the CPS may also perform various other management tasks for the NFA incorporated into the offload card of the virtualized server. For example, the CPS may install and run firmware or software at the NFA of the offload card, and apply updates including security patches to the firmware or software. In at least some embodiments, the CPS may monitor the health of the NFA, such as by testing the responsiveness of the NFA to messages caused by the CPS to its transmission, and provide a representation of the health status to the VCS client on its behalf that is using the NFA through a programming interface. In some embodiments, performance metrics of the NFA, such as the total number of RBA messages processed or network functions run, may be collected and analyzed at the CPS, and representations of the performance metrics may be presented to the VCS client through a programming interface. In some embodiments, the CPS may erase or clean up the memory of the NFA in some embodiments as needed, such as after a specific computing instance using the NFA is terminated and before another computing instance that is to use the NFA is started, so that data stored in the NFA memory during the life cycle of the specific computing instance cannot be accessed by other computing instances.

[0028] According to at least some embodiments, the corresponding virtualized representation of the NFA of the offload card can be presented to one or more computing instances running at a virtualized server. This can enable some network functions of the corresponding RBA or radio-based application pipeline to run at the computing instance, where each of the RBAs uses the same shared NFA hardware for other network functions. Requests to use the NFA hardware can be submitted through the NFA using a programming interface of the virtualized representation and received at the NFA. Virtualization of the NFA can enable network slicing to be implemented at a virtualized server, where different radio-based applications or pipelines run at each of the computing instances and NFAs. The virtualized representation of the NFA (which can be referred to as a VNFA) can enable each computing instance to utilize the shared NFA hardware through a programming interface, as if the instance had exclusive access to the NFA hardware, in a manner similar to the virtualized representation of other hardware devices of the virtualized server (such as a virtualized CPU or a virtualized I / O hardware device) that enables the computing instance to utilize those devices, as if the device is available for exclusive use.

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

[0030] In at least one embodiment, a system may include one or more CPSs of a VCS of a cloud provider network, and a virtualized server including an NFA. The CPS may establish an isolated virtual network (IVN) on behalf of a client of the VCS, for example, in response to a programmatic request from the client. The IVN, also known as a virtual private cloud (VPC), may include a set of resources that are logically isolated or separated from the rest of the resources of the VCS in terms of at least some types of networking configuration settings. For example, a given IVN may have one or more subnets with corresponding security settings selected by the client, and / or a set of Internet Protocol (IP) addresses selected by the client and assigned to computing instances or other entities configured within the IVN.

[0031] In various embodiments, in response to a first request submitted by a client through a programming interface of the VCS, the CPS may store a representation of a first security group associated with a computing instance started at a virtualized server in a metadata repository of the IVN. In various embodiments, the security group may include a set of network security rules. A first network address within the IVN may be assigned to the computing instance, and the first security group may include restrictions on the source of inbound traffic to the computing instance using the network address (and / or restrictions on outbound traffic from the computing instance). The computing instance may include software configured to perform the first network function of the RBA. The CPS may also store a representation of a second security group or security rule set associated with the NFA in the repository in response to a second request submitted through a programming interface. The second security group may include restrictions on the destination of outbound traffic from a network function accelerator (and / or restrictions on the source from which its traffic can be accepted at the NFA). In some embodiments, the CPS may assign a network address within the IVN to the NFA, which will be used for communication between the NFA and the RU. The NFA may perform the second network function of the RBA.

[0032] Before delivering the first network message of the RBA to the computing instance using the first network address as the destination address, the CPS may verify whether the first network message complies with the restrictions of the first security group. In some embodiments, the first network message may trigger the execution of the first network function. Before delivering the second network message of the RBA from the NFA to a destination such as the RU of the RBA, the CPS may also verify whether the second network message complies with the restrictions of the second security group. In at least some embodiments, the NFA may be incorporated into an offload card of the type introduced above, the offload card also including one or more virtualization management components and one or more networked hardware devices (NHDs), wherein the computing instance is started at the virtualization server using the virtualization management component of the offload card, and the underlying address is assigned to the NHD by the CPS. Additional configuration settings for the computing instance and / or the NFA may also be stored by the CPS.

[0033] In some embodiments, the CPS may implement traffic rate limiting or traffic shaping rules on the NFA. For example, the CPS may determine, for example based on a programmatic request from a VCS client on whose behalf the NFA is used, a rate limit to be applied to network messages directed to or from the NFA, and if delivery of packets directed to or from the NFA would result in a violation of the rate limit, the packet would be dropped. Such rate limits may be stored as part of a collection of configuration settings maintained by the CPS.

[0034] In some embodiments, routing table entries for mid-haul traffic (traffic between distributed units (DUs) and centralized units (CUs)) of RBA utilizing NFAs may be stored by the CPS. In such embodiments, at least some messages for mid-haul traffic may be generated at the compute instance; in other embodiments, some mid-haul traffic messages may be generated at the NFA. In some embodiments, corresponding different security groups or security rule sets may be stored for fronthaul traffic and mid-haul traffic. In one embodiment, the CPS may assign a network address within the IVN to the NFA, and the address may be used for communication between the NFA and the RU. According to at least one embodiment, in addition to or instead of using security groups that define inbound and outbound traffic restrictions, the VCS client may decide to use a network access control list (ACL) to manage traffic security, and the ACL selected by the client may be stored and implemented by the CPS. In one embodiment, messages directed to compute instances running on the RPS may be formatted according to the Internet Protocol (IP), while different protocols such as the Common Public Radio Protocol (CPRI) or enhanced CPRI (eCPRI) may be used for at least some messages exchanged between the RU and the NFA. In some embodiments, CPRI or eCPRI messages may be sent over IP (eg, using an encapsulation protocol).

[0035] According to various embodiments, a server may include a processor, a memory, and an offload card. The offload card may include a virtualization manager or a virtualization controller and an NFA for the RBA. The virtualization manager may perform one or more configuration tasks related to a computing instance started at the server, the task including allocating at least a portion of the memory for use by the computing instance. The memory may store instructions that, when executed on the processor, run a first network function of the RBA at the computing instance and cause a second network function of the RBA to be executed at 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, when executed on the processor, the instructions may cause the output of the first network function to be provided as input to the second network function executed at the NFA.

[0036] The offload card may include a networking hardware device (NHD), to which, in some embodiments, the address of the underlying network of the VCS may be assigned. The networking hardware device may be used to transmit messages of the RBA from a computing instance running at a server to other computing instances running at other servers. In one embodiment, the NHD may be used by a network processing offload running at the offload card to transmit messages. In some embodiments, multiple NHDs may be incorporated into the offload card, wherein one of the NHDs is used to transmit messages to (and receive messages from) a first set of destinations including a centralized unit (CU) of the RBA, and another NHD is used to send messages to (and receive messages from) a second set of destinations including a radio unit (RU) of the RBA. In one embodiment, addresses within the address range selected for the IVN may be assigned to the NHDs used for RU communications.

[0037] According to some embodiments, multiple NFAs may be incorporated into an offload card, where each NFA is used to execute a corresponding set of network functions of one or more RBAs. In some cases, different network functions of a single RBA may be executed at the corresponding NFA of the card. In other cases, the corresponding NFA of the card may be used to execute the network functions of the corresponding application. In one embodiment, the instructions executed at the CPU may cause the corresponding network functions running at the corresponding NFA to receive different input sets (e.g., outputs generated at the corresponding network functions running at the computing instance of the virtualized server). In one embodiment, the virtualized representation of the NFA may be presented to the corresponding computing instance started at the server, so that the accelerated network function requests from each computing instance can be received independently of each other at the NFA (using a programming interface provided as part of the corresponding virtualized representation). In various embodiments, the CPS of the VCS may perform management tasks on the NFA, including causing firmware / software to be installed and updated at the NFA. In some embodiments, the network functions performed at a given NFA may be implemented as part of a RAN node (e.g., a gNodeB or eNodeB) or a distributed unit (DU) of an RBA, part of a centralized unit (CU), and / or part of a core network of the RBA, for example, in addition to or instead of performing physical layer network functions of the classes listed previously.

[0038] In some embodiments, a virtualized server used as an RPS can be established as part of an extended resource group (ERG) of a cloud provider network, which is configured at a location outside the main data center of the provider network where the control plane server is located. In response to a request from a VCS client that wishes to run a radio-based application on a resource managed by the VCS control plane, the ERG can be located near, for example, a group of cellular towers or antennas. In other embodiments, the RPS can be established at a local area, a third-party data center, and / or a data center of the provider network. In some embodiments, a given ERG can share some management resources between its member servers, such as a local agent of the VCS control plane. In at least some embodiments, the server for the ERG can be configured with appropriate hardware (e.g., including a network function accelerator card), software, and firmware by the provider network operator, and then shipped to the location where the ERG is used. In some embodiments, at least some servers (such as RPS) may require relatively little physical space (e.g., some RPS provided by the provider network operator may only occupy one rack unit (1U) or a small number of rack units in a standard data center rack). In at least some embodiments, an RPS established as part of an ERG or running at a location outside of a provider network's data center may include multiple hardware, software, and / or firmware elements that are specifically designed to enable remotely generated virtualization-related management commands to be executed in a secure and reliable manner without, for example, sending messages back to the source that originally issued the command. In some embodiments, such elements may include a trusted platform module (TPM) or other security module incorporated into an offload card, a tamper-proof storage device (whose contents can only be decrypted when the storage device is physically attached to a specific RPS), and the like. In at least some embodiments, such an RPS may include a VCS control plane agent that does not make outbound calls and implements an API for inbound commands protected by a TLS (Transport Layer Security) session. In various embodiments, such an API may have strong authorization, authentication, and accounting-related controls. In at least some embodiments, no shared secrets associated with virtualization management may be stored within the RPS itself.

[0039] In some embodiments, a secure network channel, such as a virtual private network (VPN) tunnel or VPN connection, can be established between the RPS and resources located within a provider network data center, and such a channel can be used to send commands from the VCS to the RPS. For example, a corresponding one-way secure network channel can be used to transmit commands initially generated at a control plane server in response to a client request (including a request to initiate an RCI) for ultimate execution at the RPS. In one embodiment, a secure channel for such commands can be established between one or more resources at the RPS (such as a VCS connection manager) and one or more resources within the client's IVN, and at the request of the client, the RCI will be initiated at the RPS.

[0040] 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 for the RBA, traffic to and from other resources within the provider network, traffic to and from resources in a client network established at a client location, traffic to and from the public Internet, and the like. A given RPS can be equipped with several different kinds of networking hardware devices (NHDs) that can be used 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, and the like. Network management logic provided by the provider network can be used to intelligently select the most appropriate NHD to use for a given class of IP traffic for the RPS within a given time interval, thereby enabling optimal utilization of the available IP networking resources of the RPS to implement the quality of service objectives of applications running at the RPS. For example, depending on the type of RBA being run, different NHDs may be used for fronthaul traffic for radio-based applications rather than for midhaul traffic, at least during some time periods. A software program that implements a portion of an RBA (e.g., a program developed by a third-party vendor or provider network operator) can run within a runtime environment (RTE), such as a radio-optimized computing instance or a radio-optimized software container at an RPS. In some embodiments, a given RPS or a given NFA can be used for several different RBAs or pipelines, for example, on behalf of a single client of a provider network or on behalf of different clients. Due to such multi-tenancy, the total amount of computing resources and / or power consumed to implement several different RBAs can be greatly reduced. The reduction in resources used can translate into lower costs, thereby enabling new entrants to enter the field of radio-based applications and design new types of applications.

[0041] In accordance with some embodiments, the provider network may include a radio-based application management service (RBAMS) that implements programming interfaces related to the configuration of RPSs. Indications of the expected geographic distribution of end-user requests for radio-based applications (e.g., cell phone calls, text messages, IoT sensor inbound and outbound messages, etc.) may be obtained at the RBMAS through such programming interfaces. Information about the geographic distribution may be used at the RBAMS to select or recommend one or more venues where one or more categories of ERGs and / or RPSs supported by the provider network should be configured for the client. In such embodiments, if the client indicates approval of the recommendation, one or more RPSs may be configured on behalf of the client at such venues and assigned to the client's application by the RBMAS. Venues may include, for example, point-of-presence sites of the provider network, local area venues of the provider network, or customer-owned venues.

[0042] In one embodiment, a given network function accelerator (NFA) (or a portion of an NFA) at an offload card can be configured to be dedicated to a single client of a provider network (or a single radio-based application of a client on whose behalf multiple radio-based applications are running), for example, in response to a single tenant request from the client. In some embodiments, multiple NFAs of a single RPS (e.g., at a single offload card) can be used for a single radio-based application. In other embodiments, the corresponding NFA of a given offload card can be used for a corresponding RBA. In one embodiment, an NFA can be configured as a backup for other NFAs, for example, in response to a failure or overload detected at other NFAs. In some embodiments, one or more NFAs of an RPS can be incorporated into a virtualization management offload card that also includes a virtualization management component, while one or more additional NFAs of the RPS can be incorporated into other cards that do not include a virtualization management component.

[0043] In at least some embodiments, various metrics may be collected from the NFA (e.g., by a control plane server of a VCS or RBAMS) and provided to the client via a programming interface when desired; in different embodiments, such metrics may include inbound or outbound message transmission counts or message transmission 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 at the RPS may be collected and used to select which particular NFA should be used to perform a particular network function.

[0044] As described above, in some embodiments, the RPS can be configured at least in part using resources of a provider network. A cloud provider network (sometimes referred to simply as a "cloud") refers to a network-accessible pool of computing resources (such as computing, storage, and networking resources, applications, and services), which can be virtualized or bare metal. The cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to accommodate variable loads. Therefore, cloud computing can be viewed both as applications delivered as services over a publicly accessible network (e.g., the Internet or a cellular communications network), and as the hardware and software in a cloud provider's data center that provides these services.

[0045] The cloud provider network may include a physical network (e.g., sheet metal boxes, cables, rack hardware) called the underlay. The underlay may be viewed as the network fabric containing the physical hardware that runs the provider network's services, and may include networking devices such as routers, switches, network address translators (NATs), etc., as well as the physical connections between the devices. The underlay may be logically isolated from the rest of the cloud provider network, e.g., it may not be possible to route from an underlay network address to an address in the production network running the cloud provider's services, or to a customer network hosting customer resources.

[0046] The cloud provider network may also include an overlay network of virtualized computing resources (e.g., computing instances, block storage volumes, data objects such as snapshots and machine images, file storage, databases) running on the bottom layer. In at least some embodiments, a virtualization management component (e.g., a hypervisor or other device or process) on the network bottom layer may use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) on the network bottom layer between client resource instances on different hosts within the provider network. Encapsulation protocol technology can be used on the network bottom layer to route encapsulated packets (also referred to as network bottom layer packets) between endpoints on the network bottom layer through an overlay network path or routing. Encapsulation protocol technology can be viewed as providing a virtual network topology overlaid on the network bottom layer. Therefore, network packets can be routed along the bottom layer network according to the construction in the overlay network (e.g., IVN, security group). A mapping service may coordinate the encapsulation and routing of these network packets. A mapping service may be a regional distributed lookup service that maps a combination of an overlay IP and a network identifier to an underlying IP so that a distributed underlying computing device can find the location where the packet is sent.

[0047] For illustration, each physical host can have an IP address in the underlying network. Hardware virtualization technology can enable multiple operating systems to run concurrently on the host, such as as a virtual machine or computing instance on the host. The hypervisor or virtual machine monitor running on the host (or on the offload card attached to the host) distributes host hardware resources between various computing instances on the host and monitors the execution of the virtual machine. Each computing instance can provide one or more IP addresses in the overlay network, and the virtual machine monitor on the host can know the IP address of the computing instance on the host. The virtual machine monitor (and / or other devices or processes on the network bottom layer) can use encapsulation protocol technology to encapsulate and route network packets (e.g., client IP packets) on the network bottom layer between visualization resources on different hosts in the cloud provider network. Encapsulation protocol technology can be used on the network bottom layer to route encapsulated packets between endpoints on the network bottom layer by overlaying network paths or routing. Encapsulation protocol technology can be regarded as providing a virtual network topology covered on the network bottom layer. The encapsulation protocol technology may include a mapping service that maintains a mapping directory that maps IP overlay addresses (public IP addresses) to underlying IP addresses (private IP addresses), which can be accessed by various processes on the cloud provider network for routing packets between endpoints.

[0048] The cloud provider network can be formed into multiple regions, where a region is a separate geographic area in which a cloud provider clusters data centers. Such a region can also be referred to as a region defined by the provider network, because its boundaries do not necessarily coincide with the boundaries of a country, state, etc. Each region can include two or more availability zones connected to each other by a dedicated high-speed network (e.g., a fiber-optic communication connection). An availability zone (also referred to as an availability domain, or simply a "region") refers to an isolated failure domain that includes one or more data center facilities with separate power, separate networking, and separate cooling separated from facilities in another availability zone. A data center refers to a physical building or housing that houses and provides power and cooling for servers of a cloud provider network. Preferably, the availability zones within a region are far enough apart from each other that the same natural disaster should not take more than one availability zone offline at the same time. Customers can connect to the availability zones of the cloud provider network through a transit center (TC) via a publicly accessible network (e.g., the Internet, a cellular communication network). The TC can be considered as the main backbone location that connects customers to the cloud provider network, and can be collocated with other network provider facilities (e.g., an Internet service provider, a telecommunications provider) and securely connected (e.g., via VPN or direct connection) to the availability zone. Each region can operate two or more TCs to implement redundancy. As described herein, customers can also connect to availability zones of cloud provider networks through RAN-enabled edge locations managed by cloud providers, which in turn can be directly connected to the cloud provider network (e.g., a dedicated fiber connection between customer facilities and cloud provider facilities), or they can transmit other intermediate networks (such as the Internet) and enter the cloud provider network through TCs. The regions are connected to a global network that connects each region to at least one other region. The cloud provider network can deliver content from points of presence outside of these regions but networked to these regions through edge locations and regional edge cache servers (points of presence or PoPs). This division and geographic distribution of computing hardware enables the cloud provider network to provide customers with low-latency resource access on a global scale with a high degree of fault tolerance and stability.

[0049] As mentioned herein, edge locations (or "edge zones") can be constructed in several ways. In some embodiments, edge locations can be extensions of the underlying cloud provider network, including a limited amount of capacity provided outside the availability zone (e.g., in a small data center or other facility located near the customer workload and possibly away from any availability zone's cloud provider). Such edge locations can be referred to as local areas (due to being more local or closer to a group of users than traditional availability zones). Local areas can be connected to publicly accessible networks, such as the Internet, in various ways, such as directly connected, connected through another network, or through a dedicated connection to a region. Although local areas generally have more limited capacity than regions, in some cases, local areas may have considerable capacity, such as thousands of racks or more. Some local areas may use infrastructure similar to typical cloud provider data centers.

[0050] In some embodiments, the edge location can be an extension of the underlying cloud provider network formed by one or more locally deployed servers located in a customer or partner facility, where such servers communicate with nearby availability zones or regions of the cloud provider network over a network (e.g., a publicly accessible network such as the Internet). This type of underlying extension located outside the cloud provider network data center can be referred to as a "sentry" or VCS extension resource group of the cloud provider network. Some sentinels can be integrated into a communication network, such as a multi-edge cloud, with its physical infrastructure distributed across telecommunication data centers, telecommunication aggregation sites, and / or telecommunication base stations within a telecommunication network. In a locally deployed instance, the limited capacity of the sentinel may only be available to the customer who owns the place (and any other accounts allowed by the customer). In a telecommunication instance, the limited capacity of the sentinel can be shared between multiple applications (e.g., games, virtual reality applications, healthcare applications) that send data to users of the telecommunication network.

[0051] Edge locations may include data plane capacity that is at least partially controlled 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 subordinate to the parent availability zone (e.g., at least partially controlled by its control plane). Certain limited control plane functions (e.g., functions that require low-latency communication with customer resources, and / or functions that enable the edge location to continue to operate when disconnected from the parent availability zone) may also exist in some edge locations. Thus, in the above examples, an edge location refers to an extension of at least data plane capacity located at the edge of the cloud provider's network, close to customer devices and / or workloads.

[0052] As mentioned above, some cloud provider networks may offer support for Local Regions, an infrastructure deployment that places some of the provider network's compute, storage, database, and other selected services in desired locations close to large populations, industry, and IT centers, or other locations that may not be close to the provider network's primary data centers. Using such Local Regions, applications that require single-digit millisecond latency can run closer to end users in a specific geographic environment. Local Regions provide high-bandwidth, secure connectivity between local workloads and workloads running in a provider network region, allowing provider network clients to seamlessly connect to other workloads running in the region and a full range of in-region services through the same APIs and toolset.

[0053] The cloud provider network may implement a variety of computing resources or services, which may include virtual computing services, data processing services (e.g., map reduce, data streaming, 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 services (which may include various other types of storage, processing, analysis, communication, event processing, visualization, and security services). The resources required to support the operation of such services (e.g., computing and storage resources) may be provided in an account associated with the cloud provider, as distinct from resources requested by users of the cloud provider network, which may be provided in a user account.

[0054] In various embodiments, various network-accessible services may be implemented at one or more data centers of a provider network. Network-accessible computing services may include elastic computing cloud services (referred to in various embodiments as elastic computing services, virtual machine services, computing cloud services, computing engines, virtualized computing services (VCS) or cloud computing services). The service may provide virtual computing instances (also referred to as virtual machines, or simply "instances") with different computing and / or memory resources, which are managed by computing virtualization services (referred to in various embodiments as elastic computing services, virtual machine services, computing cloud services, computing engines or cloud computing services). 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, computing 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 interfaces and / or network capabilities), and / or other suitable descriptive characteristics (such as a "bursting" instance type that has a baseline performance guarantee and can periodically burst above that baseline, a non-bursting or dedicated instance type that allocates and guarantees a fixed amount of resources, or an instance type optimized for radio-based applications). Each instance type may have a specific ratio of processing, local storage, memory, and networking resources, and different instance families may also have different types of these resources. Multiple sizes of these resource configurations may be used in a given instance type. Using the instance type selection functionality, an instance type may be selected for a customer, for example, based (at least in part) on input from the customer. For example, a customer may select an instance type from a predefined set of instance types. As another example, a customer may specify desired resources for an instance type and / or requirements for a workload that the instance will run, and the instance type selection function may select an instance type based on such specifications. A host suitable for the requested instance type may be selected based at least in part on factors such as collected network performance metrics, resource utilization levels at different available hosts, and the like.

[0055] The computing services of the provider network may also include container orchestration and management services (referred to in various embodiments as container services, cloud container services, container engines, or container cloud services). A container represents a logical encapsulation of a software application that abstracts the application from the computing environment in which the application is executed. 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 on a server hosting a suitable container engine (e.g., or Containers are virtualized at the operating system level and therefore generally represent a more lightweight software package for running applications on a host computing system. Existing software applications can be "containerized" by packaging the software application in an appropriate manner and generating other artifacts (e.g., container images, container files, or other configurations) that enable the application to run in a container engine. In some embodiments, the container engine can run on a virtual machine instance, where the virtual machine instance is selected based at least in part on the described network performance metrics. In at least some embodiments, RBA components can run using containers. In some embodiments, other types of network-accessible services such as packet processing services, database services, wide area network (WAN) services, etc. can also be implemented at the cloud provider network.

[0056] In various embodiments, the traffic and operations of the cloud provider network can be broadly divided into two categories: control plane operations carried on the logical control plane and data plane operations carried on the logical data plane. The data plane represents the movement of user data through the distributed computing system, while the control plane represents the movement of control signals through the distributed computing system. The control plane typically includes one or more control plane components distributed across one or more control servers and implemented by them. Control plane traffic typically includes management operations, such as system configuration and management (e.g., resource placement, hardware capacity management, diagnostic monitoring, or system status information management). The data plane includes customer resources (e.g., computing instances, containers, block storage volumes, databases, or file storage devices) implemented on the cloud provider network. Data plane traffic typically includes non-management operations, such as transferring customer data back and forth with customer resources. Certain control plane components (e.g., first-tier control plane components, such as control planes 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., second-tier control plane components, such as analytical services) can share virtualized servers with the data plane, and control plane traffic and data plane traffic can be sent through separate / different networks.

[0057] Figure 1An example system environment is shown according to at least some embodiments, in which a virtualized server whose virtualization management offload card includes a hardware network function accelerator can be used for a radio-based application that runs at least in part using resources of a virtualized computing service. As shown, the system 100 includes resources and artifacts of a virtualized computing service (VCS) 110, the resources and artifacts including a control plane server 140 and a group of virtualized servers, the group of virtualized servers including a class A virtualized server, a class B virtualized server, and a class C virtualized server. In the depicted embodiment, the virtualized server classes can differ from each other in the type of virtualization management offload card (VMOC) included in each class of servers and / or the main processor (CPU), memory, and other resources included in the server, and can therefore be used for different types of applications. For example, in the depicted embodiment, the enhanced radio application VMOC (EVMOC) 118 at the class A virtualized server 150 may include a type A network function accelerator (NFA) 172, the EVMOC 119 at the class B virtualized server 152 may include a type B NFA 177, and the baseline VMOC 166 at the class C virtualized server 182 may not include any NFA. The NFAs 172 and 177 may differ in the types of network functions they can accelerate, the speed at which they can perform a particular type of network function, the vendor of the chipset developed for the NFA, etc. Due to the differences in the characteristics of their corresponding NFAs, the class A virtualized server may be more suitable for a class of radio-based applications, while the class B virtualized server may be more suitable for a different class of radio-based applications. The class C virtualized server may be suitable for general-purpose applications that do not require network function hardware acceleration. In various embodiments, both the class A virtualized server and the class B virtualized server equipped with NFAs may be referred to as radio-based application processing servers or RPSs.

[0058] Figure 1 Each class of virtualized servers in the categories shown can be used to run compute instances (CIs) on behalf of VCS clients. Some compute instances running at Class A virtualized servers or Class B virtualized servers may include programs that implement one or more network functions of radio-based applications, and therefore may be referred to as radio-optimized compute instances (RCIs). The network functions running at the RCI using the virtualized server's main processor may be different from the network functions running at the NFA, for example, the network functions running at the RCI may belong to a different layer of the radio-based application technology stack than the network functions running at the server's NFA. Figure 1, RCI 125A may be executed at class A virtualized server 150, while RCI 125B may be executed at class B virtualized server 152. In the depicted embodiment, computing instance CI 129, which may not include a program implementing RBA, may be executed at class C virtualized server 182. Note that in some cases, a computing instance implementing one or more RBA network functions may be executed at a virtualized server that does not include an NFA (such as a class C virtualized server); in such cases, the network functions may be executed using the main processor of the virtualized server, and a hardware accelerator such as an NFA may not be required. In some embodiments, one or more RBA network functions may be executed at the NFA of a virtualized server, but not necessarily at the main processor of the virtualized server.

[0059] In the depicted embodiment, a compute instance may be started at a virtualized server in response to a command sent from a control plane server 140, such as instance state manager 102. The EVMOC or VMOC may include an offloaded virtualization controller (OVC), also referred to in some embodiments as a virtualization manager or virtualization coordinator, which may send commands from the control plane as part of the process of starting a compute instance. For example, EVMOC 118 includes OVC 173A, EVMOC 119 includes OVC 173B, and baseline VMOC 166 includes OVC 173C. In various embodiments, the OVC may perform various virtualization tasks, such as starting other virtualization management components, including server virtualization management components 126A, 126B, or 126C running on a main processor of the server, allocating a portion of the main memory of the virtualized server for use by various compute instances, and the like.

[0060] In the depicted embodiment, the EVMOC and VMOC may also include one or more networking hardware devices (similar in function to a network interface card or NIC), such as NHD 174A, NHD 174B, and NHD 174C at EVMOC 118, EVMOC 119, and baseline VMOC 166, respectively. The NHDs may be used to transmit network messages to and from the virtualized servers, including to and from the control plane server 140, to and from other virtualized servers, to and from other provider network services (such as storage services, etc.). In at least some embodiments, a control plane server (such as the networking manager 106) may assign an address within the underlying network to at least one NHD of each virtualized server, and the address may be used for subsequent communications with the control plane server and the other virtualized servers. In some embodiments, the networking manager 106 may also assign a network address (which is not part of the underlying network) to a computing instance, for example, within a network address range selected by a VCS client for its isolated virtual network (IVN). In the depicted embodiment, since multiple compute instances can be established at a given virtualization server with a given NHD, with corresponding network addresses assigned to each compute instance, a mechanism can be implemented at the VCS for delivering messages directed to the corresponding network addresses of the instances while using the same underlying NHD. In some embodiments, the mapping between the underlying addresses and the addresses assigned to the compute instances can be maintained by the network manager 106, for example as part of the isolated virtual network IVN metadata 111.

[0061] In at least some embodiments, a control plane server (such as the networking manager 106 or the NFA manager 104) may also assign a network address to the NFA of the EVMOC, which may be used for communication between the NFA and a cell 154 of a radio-based application. The cell 154A may include a cell software 155A and an antenna 156A associated with a radio unit (RU) of an RBA implemented using an RCI 125A, while the cell 154B may include a cell software 155B and an antenna 156B of an RU of an RBA implemented using an RCI 125B. In some embodiments, the EVMOC may include multiple NHDs, one of which is assigned an underlying network address and another of which is assigned a different address (e.g., an IVN address) for communication between the NFA and the RU. In one embodiment, a single NHD may be assigned multiple addresses by the VCS control plane server, including one address for RU traffic and another address for traffic directed to / from a computing instance. In another embodiment, the NFA may include one or more NHDs, which may be managed by a control plane server and used to communicate with the RUs and / or centralized units (CUs) of the RBA.

[0062] In the depicted embodiment, a control plane server referred to as NFA manager 104 may be responsible for performing various management tasks related to the NFA. Such tasks may include, among other things, transferring firmware / software to be used at the NFA, causing firmware / software to be installed and executed at the NFA, applying security patches to the firmware / software as needed, erasing / cleaning the contents of the NFA's memory after an RCI has terminated so that data of the RBA running at the terminated RCI cannot be accessed by other RCIs that are later started, etc. In at least some embodiments, in addition to collecting and analyzing health status and performance information from other resources within the VCS, the VCS control plane health and performance metrics manager 112 may collect and analyze health status and performance metrics from the NFA, and present the collected metrics to the VCS clients on whose behalf the NFA is being used.

[0063] In various embodiments, the instance state manager 102 and / or other control plane servers may be responsible for coordinating or orchestrating the migration of an RBA's workload from one RPS to another (e.g., working in conjunction with an on-service VMC or OVC). In at least some embodiments, a corresponding virtualized representation of a virtualized server's NFA may be presented to each of one or more RCIs launched at the server, such that different RBAs running at the RCIs can share a single NFA device to perform a subset of the RBA's network functions.

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

[0065] As previously described, in various embodiments, an isolated virtual network (IVN) may include a set of resources that are logically isolated or separated from the rest of the resources of the VCS with respect to at least some types of networking configuration settings. For example, in some embodiments, a given IVN may have one or more subnets and / or a set of IP addresses with corresponding security settings, and each of the IP addresses in the set of IP addresses may be assigned to each computing instance established at one or more virtualized servers. For virtualized servers including NFAs, IVN features may be supported for traffic to the NFA and traffic to / from computing instances. For example, in some embodiments, the networking manager 106 may include a security rule set within the IVN metadata 111, such as a security group (which defines restrictions on traffic destinations and / or sources) or a network ACL applicable to traffic to / from the NFA, and may ensure that compliance with such security rules is verified for messages to / from the NFA. The security settings to be implemented on the NFA may be provided by the VCS client through a programming interface in a manner similar to the way security settings for traffic to computing instances are provided by the VCS client. In one embodiment, the networking manager of the VCS control plane can implement corresponding client-specified security rule sets for fronthaul traffic (traffic between RU and DU of RBA), midhaul traffic (traffic between DU and CU of RBB), and backhaul traffic (traffic between CU of RBA and core network components). In various embodiments, other benefits associated with the use of IVN can be automatically obtained for traffic directed to NFAs incorporated into EVMOC, such as automatic encryption of traffic sent to / from addresses allocated within the IVN.

[0066] In some embodiments, the routing table entries provided by the client to the VCS control plane using programmatic requests can be stored as part of the IVN metadata 111 and used to direct traffic originating from or addressed to the NFA and the computing instance. In some embodiments, the networking manager 106 can obtain traffic shaping rules or rate limits from the VCS client through a programmatic interface and implement rate limits on traffic to / from the computing instance or to / from the NFA (e.g., by abandoning or discarding packets whose delivery will violate the rate limit). In general, in the depicted embodiment, the NFA can be managed by the VCS control plane server as a first-class entity within the IVN of the VCS, in a manner similar to the way the VCS control plane server manages computing instances and entities (such as load balancers, virtual routers, gateways, etc.). Please note that in at least one embodiment, at least some virtualized servers or RPSs can be used in multi-tenant mode, so a given server can potentially be used to represent computing instances established by several different clients, where computing instances of several different IVNs are potentially instantiated on one server. In different embodiments, some virtualized servers for RBA can be located at the provider network data center, while other virtualized servers can be located at a location outside the data center. In various embodiments, one or more network functions of one or more RBAs may be executed using a host processor (e.g., CPU) of the RPS and without using an NFA. In different embodiments, the decision as to whether a given network function is executed at the NFA or at the host processor may be made based on various factors, for example, in some cases, the decision may be based on a policy indicated by a client through a programming interface, in other cases, the decision may be made dynamically (e.g., by a control plane server) based on analysis of metrics / faults / errors, etc.

[0067] like Figure 1 As shown, some virtualization management components of the virtualized server (such as OVC) can be executed on the offload card, while other components (such as VMC on the server) can be executed on the main processor of the server. Figure 2An example configuration of a radio-based application processing server with partially offloaded virtualization management functionality according to at least some embodiments is shown. As shown, a radio-based application processing server (RPS) 202 may include a primary physical processor group 204, a primary memory (e.g., one or more modules of random access memory or RAM) 208, an enhanced virtualization management offload card (EVMOC) 210, an opportunistic reduced hypervisor 220 running on the primary physical processor, and one or more radio-optimized computing 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 computing instances, such as general-purpose CI 251, which may not be optimized for radio-based applications. In the depicted embodiment, the EVMOC 210 may include one or more NFAs 237, one or more networking hardware devices (NHDs) 292, a virtualization controller 215, and a network processing offload 216. The RPS 202 may also include many other components, such as Figure 2 , and various persistent storage devices not shown in the figure. In the depicted embodiment, the main physical processor group 204 can include many physical CPUs (pCPUs, also called main processors), including pCPUs 205A and 205B. Virtualized versions of the pCPUs, called vCPUs or virtual CPUs, can be assigned to various RCIs and / or general CIs by a virtualization management component (e.g., a hypervisor and / or a virtualization controller) during the life of the computing instance. Each computing instance can include a corresponding instance of an operating system (e.g., operating system 252A, 252B, and 252C) and a set of applications (e.g., 254A, 254B, and 254C) running on behalf of a client of a virtualized computing service (VCS), which functions similarly to Figure 1 VCS110.

[0068] The virtualization controller, network processing offloader, and hypervisor 220 may be collectively referred to as a partially offloaded virtualization manager or PVM because a portion of the virtualization management tasks required at the RPS may be performed by the hypervisor using the pCPU, while the remaining virtualization management tasks may be performed at the offload card. In the depicted embodiment, the network processing offloader 216 may implement one or more networking protocols (including, for example, encapsulation protocols used within the VCS) and act as an intermediary between computing instances and networking endpoints external to the RPS. In at least one embodiment, the VCS control plane may communicate with the network processing offloader 216 to perform networking-related configuration operations at the RPS, such as assigning network addresses, changing / applying IVN-related settings, etc. In various embodiments, the network processing offloader 216 may use the NHD to transmit messages between computing instances and endpoints or destinations external to the virtualization server, and / or transmit messages between network functions executed at the NFA 237 and endpoints and destinations external to the virtualization server. Similarly, the network processing offloader can receive messages from sources external to the virtualization server via the NHD and send them to the NFA 237 or to the computing instance 250 or 251 according to the destination indicated in the message. In some embodiments, the virtualization controller 215, the network processing offloader 216, and / or the NFA 237 can be implemented using a corresponding system-on-chip design, for example, incorporated into a shared offload card linked to the pCPU via a peripheral interconnect. In other embodiments, a field programmable gate array (FPGA), a digital signal processor (DSP), or other technology can be used to implement the virtualization controller, the network processing offloader, and / or the NFA. Although in the depicted embodiment, the virtualization controller 215, the network processing offloader 216, and the NFA 237 are shown as being incorporated into a single offload card (e.g., a PCIe card), other methods of arrangement and organization of these components can be adopted in different embodiments. For example, in one embodiment, a single system-on-chip implementation can be used to perform the functions of the virtualization controller and the network processing offloader. In another embodiment, corresponding offload cards may be used for the virtualization controller 215, the network processing offload 216, and / or one or more NFAs 237. In the depicted embodiment, as its name suggests, the virtualization controller may be responsible for organizing or orchestrating most of the virtualization management work performed at the RPS 202, for example, it may be the first component of the PVM to start, trigger the startup of other components of the PVM, communicate with the VCS control plane, make memory allocation decisions for compute instances, etc. In at least one embodiment, the network processing offload may select a specific NHD 292 for a specific class of RPS traffic (e.g., midhaul, forward, or backhaul traffic for an RBA, or traffic not transmitted for an RBA).

[0069] In the depicted embodiment, the hypervisor 220 can be described as being lean because most of the work performed by at least some conventional hypervisors can be handled at 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 cases, it can wait until a compute instance voluntarily relinquishes control of the pCPU 205 before using CPU cycles. Thus, for example, when a particular compute instance 250 or 251 issues an I / O request (where the I / O is expected to take approximately time T1 to complete) and relinquishes the pCPU until it receives a response to the I / O request, the hypervisor can take advantage of this opportunity to use the pCPU to perform one or more virtualization management tasks (which typically may take time T2, where T2 << T1), while the compute instance is not expected to use the pCPU. Thus, in the depicted embodiment, the hypervisor 220 has a minimal impact on the performance of the application 254 (which can include radio-based applications).

[0070] In the depicted embodiment, the hypervisor 220 itself can include multiple sub-components, the multiple sub-components 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. In at least some embodiments, the hypervisor coordinator 225, each of the VM managers in the VM managers 228, the isolation / security component 229, and / or the messaging manager 231 can be implemented as corresponding user-mode processes. In various embodiments, at least some of these components can be implemented as instances of corresponding statically linked programs, communicating with each other via pipes using a simple proprietary protocol. In the depicted embodiment, the sub-components of the hypervisor can default to being passive or quiescent, reacting and activating only in response to events such as messages from other sub-components, context switches initiated by compute instances, etc.

[0071] The kernel-level components 222 can provide support for various low-level operations, such as an initial response to VM exit instructions issued by compute instances (e.g., when a compute instance relinquishes the pCPU). As the name implies, the hypervisor coordinator 225 can be responsible for orchestrating the operations of other sub-components. The hypervisor coordinator 225 can, for example, implement an API that can be used for communication between components at the EVMOC and the hypervisor, initiate compute instance start and termination (e.g., at the request of the virtualization controller), expose metrics collected by the VM managers, provide debugging capabilities, etc.

[0072] Each VM manager 228 may be responsible for launching or instantiating a corresponding compute instance according to the specifications provided by the orchestrator 225, monitoring metrics and logs of the compute instance, etc. In some embodiments, the VM manager 228 may also assist in I / O operations requested by the compute instances of certain devices, for example, by capturing I / O requests and converting them into memory-mapped I / O operations that are completed with the help of an offloaded virtualization management component.

[0073] The messaging manager 231 can act as an intermediary between the virtualization controller 215 and the hypervisor, for example, by converting commands issued by the virtualization controller using a queue-based protocol into pipe messages within the hypervisor. For example, the security and isolation component 229 can be responsible for erasing or cleaning up the computing instance memory when the computing instance is terminated, so that unintentional sharing of data across computing instances can be avoided. In some embodiments, the security and isolation component can also be responsible for erasing or cleaning up the memory of the NFA 237, for example, in response to a command issued by the NFA manager of the VCS control plane.

[0074] In the depicted embodiment, programs that implement virtualized network functions at one or more layers of the radio-based technology stack can run as part of the application 254A or 254B of the RCI. Other network functions can be executed at the NFA, for example, in response to requests or messages transmitted from the RU and / or from programs implemented at the application. As described above, various aspects of the configuration of the compute instances and NFAs can be managed by the control plane server of the VCS.

[0075] In some embodiments, the EVMOC 210 may include Figure 2Several other components not shown in the figure. In one embodiment, the secure boot ROM incorporated into the EVMOC can be used for the initial stage of the multi-stage boot operation of the virtualization controller. The EVMOC may also include a security module (such as a trusted platform module (TPM)), which may also be widely used in the boot process and / or for post-boot state verification. In addition, in various embodiments, the EVMOC 210 may include multiple storage devices, power supplies, and connection-related components. For example, one or more flash memory devices / interfaces (or SSDs) may be incorporated into the uninstall card. For example, these devices may be used to store firmware and / or software corresponding to various virtualization management components, computing instance components, NFAs, etc. The PCIe interface of the EVMOC may be used to communicate with the hypervisor and / or in various embodiments. In other embodiments, other types of interconnects and corresponding interfaces may be used, such as variants of USB, QuickPath interconnect (QPI), or UltraPath interconnect (UPI). In some embodiments, the EVMOC 210 may also include a power supply, for example, sufficient to keep the components of the EVMOC working for at least some target number of hours or days in the event of a long power failure. In some embodiments, a supercapacitor based power source may be used.

[0076] Figure 3 An overview of user plane and control plane layers defined according to a radio-based application technology standard according to at least some embodiments is presented. Figure 3 The arrows shown in the figure represent the downlink communication path (from the higher levels of the standard, which are typically implemented on back-end servers, down to the lower levels implemented using front-end components such as radio antennas and network function accelerators of the kind mentioned above). The layers depicted conform to the 5G-NR standard published by 3GPP (3rd Generation Partnership Project), a group of organizations responsible for defining protocols for mobile communications; similar layers have also been defined for other generations of cellular communication technologies.

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

[0078] The 5G-NR protocol stack contains three layers, called L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3). Standardized interfaces for communication between layers (and between sublayers of each layer) have been defined; this allows the network functions of the layers and sublayers to be flexibly mapped 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 functions of the layers is distributed among three types of components: a centralized unit (CU) for L3 operations, a distributed unit (DU) for L2 operations and optionally for some L1 operations, and a radio unit (RU) for at least a subset of L1 operations. L1 is also called the physical layer (PHY). L2 contains the MAC (Medium Access Control) and RLC (Radio Link Control) sublayers. L3 may include sublayers for PDCP (Packet Data Convergence Protocol) and SDAP (Service Data Adaptation Protocol). The operation of the user plane 301 may include quality of service (QoS) management 302 and compression integrity encryption 304 in L3, automatic repeat request (ARQ) processing 306 and hybrid ARQ (HARQ) processing 308 in L2, and channel coding 310 at the PHY layer. The operation of the control plane 351 may include non-access stratum (NAS) 320 protocol tasks in L3, system information (SI) 322 tasks, paging 324, radio resource control (RRC) 326 and compression integrity encryption 328, ARQ 330 and HARQ 332 in L2, and channel coding 334 in the PHY layer. Figure 3 At least some of the layers and protocols shown in the may include executing a corresponding set of network functions. In at least some embodiments, a subset of network functions corresponding to L1, L2, and / or L3 may be implemented using the NFA of the type introduced above, which is incorporated into a virtualization management offload card.

[0079] Figure 4 Example uplink and downlink pipelines of network functions for radio-based applications according to at least some embodiments are shown. Standards organizations have defined several options for dividing the functions of the pipeline between CU (centralized unit) and DU (distributed unit), which are described in Figure 4 , indicated by dashed lines, Option 1, Option 2, ..., Option 8. Such partitioning makes it possible to distribute the workload of a radio-based application across several different devices, rather than relying on a monolithic device responsible for performing all functions. Figure 5 Several more detailed options for dividing the physical layer functions between the CU and the DU are shown in , referred to as Option 7-1, Option 7-2, etc., because they are variations based on Option 7.

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

[0081] Figure 5 Example network functions that may be performed at the physical layer of a radio-based application technology stack are shown according to at least some embodiments. In the downlink PHY (L1) pipeline 501, where control and data messages are sent from higher layer components to the RU, the lower MAC stage 502 (which is 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, followed by digital-to-analog radio frequency (D / A RF) operations 514. In the opposite direction, as control signals and data flow from the radio unit to the L3 components of the pipeline, the analog-to-digital radio frequency operations (A / D RF) stage 552 of the uplink PHY (L1) pipeline is followed by a cyclic prefix removal and fast Fourier transform (FFT) stage 554. 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 descrambling, rate dematching and decoding stage 562 before reaching the lower layer MAC stage 564 of L2.

[0082] Each of the stages in the uplink pipeline 501 and the downlink pipeline 551 may need to perform a corresponding set of network functions. Partitioning options 7-3, 7-2, 7-2a, and 7-1 represent corresponding recommendations for allocating the overall combination of network functions between the "upper layer L1" (implemented at the DU) and the "lower layer L1" (implemented at the RU). The stages of pipelines 501 and 551 to the left of the dashed line indicating the partitioning option are considered part of the upper layer L1, while the stages to the right are considered part of the lower layer L1. Therefore, in the 7-2 partition, stages 508, 510, 512, 554, 556, and 558 may be the responsibility of the RU and the remaining stages may be the responsibility of the DU. In various embodiments, the network function accelerator utilized at the radio-based pipeline processing server (RPS) may be executed using a custom chipset Figure 5 . For example, the network functions implemented at the accelerator may include one or more L1 network functions of the radio-based technology stack, such as (among others): encoding function, rate matching function, scrambling function, modulation layer mapping function, precoding function, resource mapping function, digital beamforming function, fast Fourier transform (FFT) function, cyclic prefix insertion function, cyclic prefix removal function, inverse FFT function, demapping function, channel estimation function, pre-filtering function, equalization function, demodulation function, descrambling function, rate dematching function or decoding function. In at least some embodiments, the network function accelerator may implement DU functions. In some embodiments, in addition to DU functions, at least a portion of CU functions may be implemented at the RPS.

[0083] Figure 6An example hierarchy of devices that can be used for radio-based applications according to at least some embodiments is shown. In the depicted embodiment, a core network server 618 linked to one or more networks 615 can implement a set of back-end functions associated with radio-based applications, so that different sub-networks of the entire system can communicate with each other, and the one or more networks are used to transmit Internet protocol packets containing the payload and control signals of the application over a large distance. The network functions performed at the core network server (referred to as core network functions) may, for example, include functions for aggregating data traffic from end-user devices, authenticating users, applying personalized policies, and / or managing the mobility of devices before routing traffic to operator services or the Internet. In one embodiment, a given core network server 618 may, for example, be located at a provider network data center. In some embodiments, the core network server may be connected to one or more intermediate RAN servers 620, such as 620A and 620B, where additional central unit (CU) functions may be implemented. In the depicted embodiment, the traffic between the core network server 618 and the intermediate RAN server 620 may be referred to as backhaul traffic 691. The intermediate RAN server may be located, for example, within a location where one or more VCS extension sites are implemented or at a location close to such extension sites.

[0084] exist Figure 6 In the embodiment depicted in FIG. 1 , the distributed unit (DU) functionality of the radio-based application technology stack may be implemented at the RPS 670 (similar in functionality to Figure 1Virtualized servers 150 and 152). Each intermediate RAN server 620 can be linked to one or more RPSs, for example, the intermediate RAN server 620A can be connected to RPS 670A and RPS 670B, and the intermediate RAN server 620B can be linked to RPS 670C and RPS 670D. ​​In various embodiments, the traffic between the CU and the DU can be referred to as mid-transmission traffic 692. Each of the RPSs can be linked to the radio units (RUs) at the devices of one or more cells 654, for example, using an NHD incorporated into a virtualization management offload card. For example, RPS 670A can be linked to radio units at cells 654A and 654B, RPS 670B can be linked to a radio unit at cell 654C, RPS 670C can be linked to a radio unit at cell 654D, and RPS 670D can be linked to a radio unit at cells 654E and 654F. The traffic between the DU and the RU can be referred to as fronthaul traffic 693. Each of the cells may include one or more antennas that may be used to receive and transmit radio frequency signals from various wireless user devices 679. In various embodiments, a given RAN node (such as a gNodeB in the case of 5G applications) may include one or more CUs, one or more DUs, and one or more RUs. In some embodiments, the RPS, intermediate RAN servers, and core servers may all be implemented at least in part using provider network resources. According to one embodiment, the RPS may be used to run at least some core network functions (which are run at the core server 618). In one embodiment, at least some of the functions of the 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 CU functions.

[0085] Figure 7 An example deployment of L2 implementation programs of a radio-based technology stack at a radio-based application processing server is shown in accordance with at least some embodiments. In the depicted embodiment, a radio-based application processing server (RPS) 710 includes a set of programs for an L2 layer L2P 725 for one or more radio-based application (RBA) pipelines. In some embodiments, the L2P 725 may have been 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 deployed on a compute instance (e.g., similar to Figure 1 The RCI 125A or 125B radio-optimized computing instance is started within the RCI 125A or 125B radio-optimized computing instance.

[0086] exist Figure 7In the depicted embodiment, a request processor can be started for an RBA pipeline at the RPS. The upper layer L1 request processor 726 can be used to process / forward requests for network functions generated at the L2P 725. In an embodiment where the RPS is being used for multiple RBA pipelines in a multi-tenant mode, a corresponding upper layer L1 request processor and a set of L2Ps can be instantiated for each pipeline. The request processors can be isolated from each other in corresponding runtime environments, for example, as part of corresponding computing instances or software containers with address spaces that are not accessible from other execution environments. In some embodiments, the request processor 726 can include one or more privileged threads or processes that run in the same runtime environment as their corresponding L2P. In the depicted embodiment, each request processor 726 can include software developed at the provider network, for example, as opposed to an L2P that may have been developed by an entity other than the provider network operator.

[0087] In some embodiments, the request processor 726 may receive requests for upper layer L1 network functions from the L2P 725 for the downlink portion of the RBA pipeline, for example, through a set of L2←→L1 programming interfaces 770 designed and implemented at the provider network. In at least some embodiments, the programming interface 770 may be based on, or compatible with, a standard such as FAPI-NR (Functional API-New Radio). In one embodiment, the programming interface 770 may be published by the provider network or otherwise communicated to an external organization, thereby enabling the vendor of the L2P to develop code that can be used with the RPS upper layer L1 request processor. Note that the number of L2Ps and request processors executed at a given RPS 710 may vary, for example, based on the number of provider network clients that wish to implement their radio-based applications in the same vicinity; for example, more than two L2Ps and corresponding request processors may be started at the RPS, or a single L2P and a single request processor may be started. In some embodiments, APIs for different boundary layers (i.e., not necessarily L2-L1 interfaces) of the radio-based technology stack may be implemented by the request processor.

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

[0089] In the depicted embodiment, the NFAAM may receive L1 network function requests sent from the request processor 726 for all downlink pipelines implemented using the RPS 710, determine the specific NFA 719 that applies to a given network function (if there are multiple NFAs), and transmit the request to that NFA for execution. In some embodiments, the results of the execution of the network function may be transmitted from the NFA to one or more radio units of one or more cells. For messages flowing from the antenna to 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 at the NFA, and the results may be forwarded to the L2P via the NFAAM and / or the request processor. The L2P may then transmit the results of the L2 processing further up the stack, for example, to L3 or CU implementation programs at other RPSs, intermediate RAN servers, and / or core servers.

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

[0091] In the depicted embodiment, the RPS 710 may include one or more NHDs 733 implemented as part of the EVMOC 718. In various embodiments, in embodiments where the RPS includes multiple NHDs, the networking manager ( Figure 7In some embodiments, one NHD or port may be used for communication with a RU (forward haul traffic) while another NHD or port may be used for midhaul or backhaul traffic. EVMOC 718 may also include a virtualization controller 735, which functions similarly to a virtualization controller 735. Figure 2 A virtualization controller 215 is provided.

[0092] In various embodiments, in embodiments where the EVMOC includes multiple NFAs, a specific NFA for a given request may 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 at the request of a client on whose behalf the L2P is running, and thus the NFA selected for a given network function request may be based at least in part on the L2P from which the network function is requested. In some cases, a given NFA may be allocated for exclusive use on behalf of a given client of a given radio-based application or provider network. In some embodiments, metrics collected from the NFA may be used to select the NFA for which a given network function request is intended, for example, an NFA with the lowest recent resource utilization level may be selected over other NFACs.

[0093] In the depicted embodiment, each of the radio-based applications whose pipeline is being executed at the RPS may belong to one of a set of application domains with corresponding expectations regarding performance and other quality of service considerations. The ITU-R (International Telecommunication Union - Radiocommunication Sector) standards organization has defined at least three such application domains for 5G cellular communications: enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable and low-latency communications (URLLC). In some embodiments, the NFAAM may select an NFA for at least some network functions of an application based on the application domain to which the application belongs.

[0094] 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 need to perform L1 and L2 network functions. In various embodiments, more of the main processors (CPU, GPU, etc.) of the RPS may be available for such additional applications due to offloading at least some L1 network function workloads to the NFA.

[0095] In various embodiments, an RPS similar to RPS 710 may provide an implementation of an open radio access network (O-RAN), which is a disaggregated approach to deploying mobile fronthaul and midhaul networks based on cloud-native principles. O-RAN is an evolution of the next generation RAN (NG-RAN) architecture first introduced by 3GPP. In at least some embodiments, organizations such as the O-RAN Alliance have developed standards for O-RAN, and the RPS may be designed to comply with such standards.

[0096] Figure 8 An example presentation of a virtualized representation of a computing instance running at a virtualized server by a hardware network function accelerator according to at least some embodiments is shown. Figure 8 In the depicted embodiment, RPS 810 may be used to run at least two radio optimized computing instances (RCIs) 870A and 870B. Each RCI may include a set of L2 implementation programs for a corresponding 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 at RCI 870A, and other applications 811B may similarly run at RCI 870B.

[0097] In the depicted embodiment, RPS 810 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 kind 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.

[0098] In at least some embodiments, where one or more RCIs are running at an RPS, a corresponding virtualized representation of the NFA can be programmatically presented to each RCI by a hypervisor or other virtualization management component. For example, a virtualized NFA 877A can be presented to RCI 870A, and a virtualized NFA 877B can be presented to RCI 870B. From the perspective of any given RCI, the virtualized representation can authorize access to all functionality that would be provided if the RCI were authorized to access a physical NFA, in a manner similar to the way a virtualized CPU might appear to authorize access to a physical CPU. A set of APIs for issuing requests / commands to the NFA can be included in the virtualized representation. In order for a given network function to be executed at the NFA, a program running at the RCI can call an API of the virtualized representation provided to the RCI. In the depicted embodiment, the corresponding virtualized NFA can be used for the corresponding network slice, enabling multiple RBAs or RBA pipelines to be implemented using a shared hardware NFA.

[0099] In some embodiments, the hypervisor may maintain a data structure that includes multiple slots in some embodiments, wherein each slot represents a corresponding virtualized view of at least a portion of the computing and / or networking capacity of the NFA, which can be allocated or assigned to a specific RBA or L2P for at least a period of time. In some embodiments, individual slots may contain elements in an array, linked list, or other similar data structure. In various embodiments, the hypervisor may schedule the execution of separate network functions from multiple pipelines (i.e., different radio-based applications) at a shared NFA so that from the perspective of any given pipeline, the NFA appears to be dedicated to 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 total performance capacity of the NFA along one or more dimensions, such as the network function processing power of the NFA, the network bandwidth available for communicating with RUs from the NFA, etc.

[0100] Fig. 9 Example network function accelerator configuration management tasks that may be performed or initiated by a control plane server of a virtualized computing service are presented in accordance with at least some embodiments. Fig. 9 In the embodiment depicted in FIG. 1 , RPS 910 may be used to run at least one radio optimized computing instance (RCI) 970. The RCI may include a set of L2 implementation programs for corresponding RBAs, similar to the previously described Figure 7 and Figure 8 Other applications may also run at the RCI 970.

[0101] In the depicted embodiment, RPS 910 may include a hypervisor 935 and an EVMOC 918. EVMOC 918 may include at least one NFA 919, at least one NHD 933, and a virtualization controller 938 of the kind 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.

[0102] In the depicted embodiment, the VCS control plane server 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 FSA, including installing an initial version of the firmware / software and any subsequent versions or updates that become available. In various embodiments, as part of the firmware / software management, security patches or fixes may be applied to the NFA. In embodiments where the NFA firmware / software is prepared by, for example, a third-party vendor rather than by the operator of the provider network, the VCS control plane server may implement a programming interface that may be used by the third-party vendor to submit the firmware / software to the VCS, and the VCS control plane server may then propagate the firmware / software to the appropriate RPSs.

[0103] In at least some embodiments, the VCS control plane server can allocate network addresses for communication between the NFA and other components of the RBA (such as the RU and / or CU). In some embodiments, the allocation of the NFA address 902 can be completed in response to a programmatic request from a VCS client on whose behalf the NFA will be used, for example, the client can indicate a specific address or let the VCS control plane server select an address. In some cases, one address can be allocated for the forward traffic of the RBA implemented with the help of the RPS, while another address can be allocated for the mid-haul traffic. In at least one embodiment, an address within an IVN established at the request of a client can be assigned to the NFA.

[0104] In various embodiments, the NFA may contain its own processor and memory. The memory may be used to store data related to the network functions executed at the NFA, such as intermediate or final results of the network functions, etc. In one such embodiment, the VCS control plane server may erase or clean up the memory at one or more points in time, such as when the RCI that sent the network function request to the NFA is terminated. Such NFA memory erase 905 can help enhance the security of RBAs running with RPS, because data generated for one RBA or stored in the NFA memory can be permanently erased or deleted before any other RBA can access it.

[0105] In the depicted embodiment, the VCS control pane server may also be responsible for NFA health status monitoring 903 and NFA performance metrics monitoring 904. In various embodiments, information regarding the health status of the NFA and the performance characteristics of the NFA during various time intervals may be provided to clients (e.g., RBA owners) on whose behalf the NFA is being used through a programming interface. Metrics collected and presented by the control plane may include, for example, utilization levels of NFA processors, memory, etc., rates or counts of failures or errors (if any) of NFA components, wait times for network function processing to complete at the NFA, and the like.

[0106] In some embodiments, the VCS control plane server may also be responsible for coordinating the live migration of NFA and RCI workloads 906. Such live migration may be initiated based on various trigger conditions (such as the availability of a new version of L2P, the error count of a detected failure at an RPS having exceeded a threshold, etc.). As a result of the live migration, RBA traffic from an RU that previously sent a message to an NFA at one RPS (the migration source RPS) may be directed to an NFA at a different RPS (the migration destination RPS), and network functions running at the RCI of the migration source RPS may instead run at a migrated version of the RCI at the migration destination RPS. In various embodiments, the control plane server may ensure that the state information of the RBA (including NFA state information as well as RCI state information) is replicated from the migration source RPS at the migration destination RPS without interrupting ongoing RBA operations.

[0107] In the depicted embodiment, the VCS control plane server may also be responsible for assigning underlying network addresses to the NHD on the EVMOC 951, and assigning isolated virtual network addresses 952 to virtual network interfaces 972 that are programmatically attached to the RCI 970. In various embodiments, the encapsulation protocol implemented at the VCS and the mapping between underlying addresses and IVN addresses may be used for communications between the RCI and entities located external to the RPS.

[0108] Fig.10 Various aspects of workload migration techniques that can be used for radio-based applications according to at least some embodiments are presented. Fig.10In the depicted example scenario, RCI 1020A may be instantiated at RPS 1010 equipped with EVMOC 1018A, which includes an NFA of the type discussed above. RCI 1020A may include a version 1025A of one or more programs (such as L2 implementation programs or L2Ps) that perform a portion of the DU (distributed unit) functionality of a radio-based application RBA1. RBA1 may also include other layers, such as a centralized unit (CU) layer and a RU layer, which may run at resources other than RPS 1010. In order to implement the DU functionality, state information related to messages or traffic between RBA1 layer pairs may be maintained at the RCI and accessed by version 1025A of the program. In the depicted embodiment, such RBA1 state information 1027 may include, for example, state information related to fronthaul traffic (DU-RU traffic) and midhaul traffic (DU-CU traffic).

[0109] In the depicted embodiment, the VCS control plane server 1002 of the VCS may be responsible for detecting a trigger condition for migrating an RBA1 workload initially running at an RCI 1020A to another RCI 1020B. In some embodiments, one or more control plane agents for migration may run locally at the RPS 1010, for example, as part of a virtualization management layer or as part of the RCI 1020A. In different embodiments, any of a variety of trigger conditions may cause the migration, such as receiving a programmatic request to upgrade a program implementing L2 or DU functionality, performance metrics, error detection at the RPS 1010, etc.

[0110] exist Fig.10 In the depicted embodiment, it may be determined by the VCS control plane server 1002 that at least a subset of the operations of RBA1 are to be migrated to the updated / upgraded RCI 1020B. In the depicted embodiment, 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). Fig.10 1020A; 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. In the depicted embodiment, version 1025B may include an updated / upgraded version of the DU implementation program program (whose earlier version was version 1025A).

[0111] In various embodiments, in response to determining that the workload of RBA1 is to be migrated, state information required to operate the RBA DU operation at RCI 1020B may be transferred to RCI 1020B. In the depicted embodiment, at least a subset of the state information 1027A for midhaul and / or forwardhaul traffic of RBA1 may be transferred to RCI 1020A without suspending RBA1, as indicated by arrow 1066A. Similarly, in various embodiments, at least a subset of additional RCI state information 1028 (e.g., networking state information related to traffic classes other than forwardhaul or midhaul traffic, memory contents, device state information, etc.) may also be transferred to RCI 1020B without suspending RBA1 or other applications running at RCI 1020A, as indicated by arrow 1066B. This type of state transfer may involve multiple iterations in which incremental portions of the state information that have been modified since the last iteration are transferred, which may help avoid disruption to end-user visible functionality of RBA1 and / or other applications originally running at 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 briefly paused to transfer any remaining state information. In the depicted embodiment, after the state information has been completely transferred, operations of the DUs of RBA1 may be initiated at the updated / upgraded RCI 1020B, where they may use the migrated RBA1 state information 1037 to resume DU functionality. In the depicted embodiment, the migrated additional RCI state information 1038 may be used to resume other operations previously running at RCI 1020A.

[0112] In various embodiments, the VCS control plane server 1002 may include one or more orchestration managers, such as the RU / CU orchestration manager 1078, responsible for coordinating the migration of DU functions with other components of the RBA1 (such as CU layer components or RU layer components). For example, other components may be notified by one or more messages about the pending migration of the DU so that the other components can perform one or more preparation operations (e.g., save or back up their own state information in the event that the migration fails for some reason). In the depicted embodiment, after the migration of the state information is completed and the RU receives notification of the migration, the forward traffic 1091A that originally flowed between the RU 1090 and the NFA at the EVMOC 1018A may flow between the RU 1090 and the NFA at the EVMOC 1018B at the RPS 1012, as shown by arrow 1091B. During the migration process, in some embodiments, the routing components of the provider network may implement traffic mirroring so that messages sent from the RU 1090 to the NFA at the EVMOC 1018A are also sent to the NFA at the EVMOC 1018B.

[0113] Fig.11 Example categories of network traffic for a radio-based application processing server according to at least some embodiments are shown. RPS 1110 may include EVMOC 1191 (which includes one or more NFAs, one or more NHDs, and a virtualization controller) and RCI 1120A, where at least a portion of the DU functionality of the radio-based application RBA1 may be implemented. In the depicted embodiment, RPS 1110 may be located at a location outside of a provider network data center, for example, at a local location or as part of a VCS extended resource group configured at a location selected by a VCS client. In the depicted embodiment, RCI 1120A may be configured as part of an isolated virtual network (IVN) 1145 of the provider network's VCS, for example, by assigning an IP address of a range of IVN IP addresses to RCI 1120A. IVN 1145 may include one or more other RCIs, such as local RCI 1120B, at the same location as RPS 1110; RCI 1120B may also be used, for example, to execute some portions of RBA1. RCI 1120B may operate at a different RPS than RPS 1110. Fig.11In the depicted scenario, IVN 1145 may also include one or more computing instances 1122 running at a virtualized server within a data center of the provider network. Additionally, in some cases, IVN 1145 may include one or more other local computing instances that are not optimized for radio-based applications but also run at the same location as RPS 1110. Each computing instance within IVN 1145, including instances 1122, 1120A, and 1120B, may be assigned an IP address within the range of IP addresses selected for the IVN. For example, a corresponding virtual network interface (VNI) to which an IP address is assigned may be programmatically attached to a computing instance via a VCS control plane server, thereby actually assigning an IP address to the computing instance.

[0114] In the depicted embodiment, RPS1110 can participate in at least five types of network traffic exchanges. Fronthaul traffic 1161 can flow between the NFA of the EVMOC 1191 of the RPS1110 and one or more RUs (such as RU 1104) of RBA1. Midhaul traffic 1162 can flow between the RPS1110 and one or more CUs (such as CU 1102) of RBA1. Control plane traffic 1163 (such as commands to configure NFA, start RCI, terminate RCI, or migrate RCI workloads) can be directed to RPS1110 from VCS control plane resources located at the data center of the provider network. In the depicted embodiment, messages directed to or from other services 1144 (such as storage services or database services) of the provider network from applications running at RPS1110 can constitute non-VCS service traffic 1164. In some cases, the location where RPS1110 is configured may include one or more resources that are not managed by the provider network, such as client-owned devices or servers running client applications other than RBA1. Such resources may be referred to as an instance of non-provider network resources 1170; other instances may include devices of the public Internet. Traffic to / from network endpoints of such resources may be referred to as provider external network traffic 1167. In the depicted embodiment, the last category of network traffic, referred to as intra-IVN traffic, may include traffic 1165A between the RCI 1120A of the RPS and other local compute instances 1120B (intra-IVN traffic 1165A) and traffic between the RPS and compute instances 1122 within the provider network data center (intra-IVN traffic 1165B).

[0115] In some embodiments, as previously mentioned, the EVMOC 1191 may include several networked hardware devices or NHDs and may be Fig.11The corresponding NHD is selected from the set of NHDs for one or more traffic categories shown (e.g., based on a command from the control plane server 1101 of the VCS). For example, one NHD can be used for fronthaul traffic, another for midhaul traffic, and so on. In some embodiments, various networking-related configuration settings (including settings related to network security of IVN 1145, such as client selection represented by IVN 1145) can be applied to midhaul and fronthaul traffic of RBA1 in addition to other traffic applied to computing instances established within the IVN.

[0116] In various embodiments, metadata related to various aspects of the isolated virtual network may be stored by the VCS control plane. Fig.12 Example categories of isolated virtual network metadata associated with a radio-based application processing server according to at least some embodiments are shown. As shown, isolated virtual network metadata 1201 may include metadata applicable to non-RBA traffic of RCI / VNI 1220, metadata applicable to RBA midhaul traffic 1240, and metadata applicable to RBB fronthaul traffic.

[0117] In the depicted embodiment, metadata 1220 may include, for example, a VNI IP address 1222 (which may be used as a source address or destination address for a packet originating from or pointing to a computing instance including an RCI), a security group 1224, a network access control list (ACL) 1226, a routing table 1228, and a subnet 1230. Access control (also referred to as a security group, a network security group, an application security group, a cloud security group, or a computing engine firewall rule in various embodiments) acts as a virtual firewall for a computing instance to control inbound and outbound traffic. Customers can define security groups as policies that can be applied to specific instances. When a customer launches an instance in IVN, they can assign one or more security groups to the instance. Security groups can work at the instance level rather than the subnet level. Therefore, each instance in a subnet can be assigned to a set of security groups of different groups. For each security group, customers can add rules that control inbound traffic to the instance, as well as a separate set of rules that control outbound traffic. Security groups can be stateful because return traffic is automatically allowed.

[0118] Customers can also establish network access control lists (ACLs) with rules similar to security groups to add an additional layer of security to IVN. Network ACLs operate at the subnet level, support allow and deny rules, and are automatically applied to all instances in any subnet associated with it. Network ACLs can be non-stateful because the rules must explicitly allow return traffic. The same security group can be used or replicated for multiple compute instances. If desired, the VCS client can use security groups alone without network ACLs, use network ACLs without security groups, or use both security groups and network ACLs. 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 can provide an indication of the order in which different rules should be applied, in effect indicating the relative priority of the rules.

[0119] After specifying security groups and / or network ACLs for traffic to a compute instance and / or mid-haul or forward traffic, the VCS control plane server can be responsible for ensuring that the rules are enforced. For example, the control plane server can enable the networking components of the VCS (such as the networking components of the virtualization manager / hypervisor, routers, and other networked devices) to verify that the delivery does not violate the rules related to inbound traffic before delivering any packets or messages to the applicable compute instance or NFA. In some embodiments, packets whose delivery would violate the rules may be discarded. Similarly, for outbound packets / messages, the VCS networking components can ensure that outbound traffic security rules are not violated before forwarding the packets along the path to the intended destination. In various embodiments, the rules can be propagated from the VCS control plane server to the relevant VCS networking management components.

[0120] In the depicted embodiment, according to some embodiments, the VCS client can specify routing entries for various sets of sources and destinations in the IVN through a programming interface, and such routing entries can be stored in a routing table 1228 maintained as part of the IVN metadata. In some embodiments, the client can define one or more subnets 1230 within the IVN, and if desired, can use computing instances configured in different subnets for corresponding applications.

[0121] In some embodiments, one or more NFA midhaul traffic addresses 1242 and / or forwardhaul traffic addresses 1262 may be allocated by the VCS control plane server and stored as part of the IVN metadata. In some embodiments, addresses for midhaul traffic and / or forwardhaul traffic may be selected from the same range of IVN addresses as the VNI / IP addresses from which the VNI / IP addresses are selected; in other embodiments, different ranges of addresses (or even addresses of a different protocol than IP) may be used for forwardhaul traffic and / or midhaul traffic. In the depicted embodiment, security groups 1244 and 1264, which are similar to security group 1224 but may be specifically applied to midhaul traffic and forwardhaul traffic, respectively, may be defined / specified by the VCS client. Similarly, in at least some embodiments, network ACLs 1246 and / or 1266 may be specified / defined by the VCS client for midhaul traffic and forwardhaul traffic, and routing table 1248 may be populated with entries specified by the VCS client for midhaul traffic. In various embodiments, the VCS control plane may implement security groups that may be used by the VCS client to specify Fig.12 The control plane servers may provide corresponding programming interfaces for the various configuration settings shown in , and the control plane servers may cause the specified settings to be implemented or applied in response to requests received through such interfaces.

[0122] In some embodiments, a provider network may allow clients to launch compute instances selected from several different classes arranged in an instance family. Fig.13 Example categories of compute instances that can represent client configurations of a virtualized compute service are shown, according to at least some embodiments. In the depicted embodiment, supported instance families include general-purpose compute instances 1310, GPU-based compute instances 1315, storage-optimized compute instances 1320, and radio-optimized compute instances 1325. Families (other than the general-purpose family) can be optimized in some way for corresponding types of applications; for example, applications that require a large number of fast persistent writes or reads may be best suited for storage-optimized compute instances 1320, applications that include a large number of graphics-related tasks or certain types of machine learning workloads may be best suited for GPU-based compute instances 1315, and radio-based applications may benefit most from running at radio-optimized compute instances 1325.

[0123] Some of the instance families may include several instance categories that are distinguished from each other based on characteristics such as performance capabilities. The small GPCI 1311 of the general computing instance 1310 may, for example, have fewer virtual CPUs and a smaller amount of available memory than the medium GPCI 1312, which in turn may have fewer virtual CPUs and a smaller amount of available memory than the large GPCI 1313. Similarly, the small GPUCI 1316 of the GPU-based family may have fewer virtualized GPUs available for client applications than the medium GPUCI 1317, and the large GPUCI 1318 may have more available virtual GPUs than the medium GPUCI. More and / or faster persistent storage devices can be accessed from the large SCI 1323 of the storage-optimized computing instance 1320 than the medium SCI 1322, and the small SCI 1321 may have a smaller storage capacity or slower storage speed than the medium SCI.

[0124] In some embodiments, the radio optimized computing instances (RCIs) 1325 can be classified not only based on performance differences, but also based on the type of NFA accessible from the RCI. In the performance capacity based RCI type 1356, the small RCI 1326 can be able to perform network functions at a slower aggregation rate (and can also have fewer vCPUs and smaller memory) than the medium RCI 1327, which can in turn be able to perform network functions at a slower aggregation rate (and can also have fewer vCPUs and smaller memory) than the large RCI 1328. In the depicted embodiment, some RCI categories can be defined based on the type of NFA of the EVMOC accessible from the RCI. The RCI type 1358 based on the NFA category can include, for example, NFA-A type RCI 1329, which can be configured at a virtualized server whose EVMOC includes an A-type NFA; NFA-B type RCI 1330, which can be configured at a virtualized server whose EVMOC includes a B-type NFA, etc. In some embodiments, the RCIs may also be grouped into categories using a combination of available accelerator types and performance capabilities, e.g., 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 that a radio-based application implemented with the help of an RCI may be determined based on the category of the RCI. For example, assume that the EVMOC of the RPS has 16 NFAs. In some embodiments, there may be a situation where only up to 4 of the 16 NFAs can be utilized from a "Small" RCI, only up to 8 of the 16 NFAs can be utilized from a "Medium" RCI, and so on.

[0125] Fig.14Example locations and sites where radio-based application processing servers may be deployed in accordance with at least some embodiments are shown. Fig.14 In the depicted embodiment, the resources of the provider network 1410 may be organized into regional zones, such as regional R1 zone 1411A and regional R2 zone 1411B. A given regional zone may further include one or more data centers that are relatively close to each other (e.g., within the same state or metropolitan area). Fig.14 In the example shown, region R1 zone 1411A includes data centers 1412A and 1412B, while 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 as well as one or more service artifacts, such as similar to Figure 1 The VCS 110 may include a virtualized computing service (VCS) and / or a radio-based application management service (RBAMS).

[0126] In the depicted embodiment, the above-described types of RPSs may be configured at various facilities other than the provider network's own data center 1412 in response to programmatic requests from clients. In different embodiments, such facilities may include cell sites 1445, client premises 1425 (e.g., local data centers), local regions 1440, and / or point of presence sites 1430. As shown, RPSs 1460A and 1460B may be established within a single rack, for example, at point of presence site 1430. RPSs 1460C and 1460D may be established at local region 1440, RPSs 1460F and 1460G may be established at a customer-owned premises 1425, and RPSs 1460H and 1460J may be established at a cell site (e.g., a room or group of rooms located next to a cell tower with antennas). In some embodiments, other types of facilities and locations may be used for RPSs, such as a cell site 1445, a client premises 1425 (e.g., a local data center), a local region 1440, and / or a point of presence site 1430. Fig.14 In various embodiments, a connection can be established from each RPS at a given facility to the control plane servers of the provider network and the radio units (RUs) that are typically located near or in the facility. After verifying such a connection, in various embodiments, software components such as the isolation request processor and L2P can be started at the RPS to handle radio-based application workloads as described above.

[0127] Fig.15is a flow chart illustrating various aspects of operations that may be performed to manage radio-based applications that include network functions executed at an accelerator incorporated into a virtualization management offload card according to at least some embodiments. As shown in element 1501, one or more control plane servers (CPS) of a virtualized computing service (VCS) or a radio-based application management service (RBAMS) of a cloud provider network may assign a network address (e.g., an IP version 4 or IP version 6 address) that is part of an underlying or physical network of the VCS to a networking hardware device (NHD) that is incorporated into an enhanced virtualization management offload card (EVMOC) of a radio-based application processing server (RPS), which is also a virtualization server of the VCS. In at least some embodiments, the RPS may be located at a location external to the VCS data center where the CPS is located, for example, to enable some operations of the RBA to be performed closer to the antennas or end-user devices of the RBA and thereby support low latency for such operations. The EVMOC may also include a network function accelerator (NFA), for example, implemented using one or more dedicated chipsets that are optimized to perform network functions at one or more layers of a radio-based technology stack, including, for example, functions at the distributed unit (DU) layer of a 5G RAN stack. The EVMOC may also include one or more virtualization management components for starting and managing one or more computing instances or virtual machines at a virtualized server, including a virtualization controller (which, among other tasks, can allocate a portion of the memory of the virtualized server to each computing instance and start a hypervisor component running on the main processor of the virtualized server rather than at the offload card), a network processing offload, etc. Executing a subset of virtualization management tasks at the offload card can enable more of the virtualized main processor and memory to be used for computing instances. Similar benefits can be implemented by offloading some of the network functions of one or more RBAs to the NFA, rather than using the main processor of the virtualized server for network functions; in addition, in at least some embodiments, the optimized circuits of the NFA can be able to perform network function calculations faster than using the main processor.

[0128] In the depicted embodiment, the CPS may assign addresses (different from underlying network addresses) to be used for communications between the NFA and one or more radio units (RUs) of one or more RAN nodes of the RBA RBA1 (element 1504). In addition, in at least one embodiment, the CPS may assign addresses within an isolated virtual network (IVN) established for a VCS client to a virtual network interface (VNI) programmatically attached to a radio optimized compute instance (RCI) running at the RPS on whose behalf at least some network functions of RBA1 will run. For example, the RCI may be initiated using a virtualization controller and other virtualization management components of the RPS.

[0129] In various embodiments, the CPS may store configuration settings related to IVN and RCI, for example, in response to various programmatic requests from VCS clients. Corresponding sets of such IVN configuration metadata may be stored for various categories of traffic: for example, in the depicted embodiment, generic traffic for RCI (e.g., network packets not transmitted as part of RBA1), forward traffic for RBA1, and mid-haul traffic for RBA1 (element 1507), in effect providing the VCS client with similar types of configuration controls for NFA traffic as are provided for RCI traffic. A given set of IVN configuration settings may include, for example, security groups (a set of firewall rules for inbound and outbound traffic for VNI / RCI and / or NFA), network access control lists, traffic rate limits to be applied to inbound and / or outbound traffic, routing table entries and / or other routing information to be used for traffic for RCI and / or NFA, and the like. In various embodiments, the CPS may enable security-related rules and rate limits to be implemented at appropriate components of the system (e.g., virtualization management components running at the RPS, networking intermediaries such as VCS routers, and the like). For example, before delivering individual packets to or from an RCI or NFA, the VCS networking infrastructure may ensure that delivery of the packets does not violate applicable security rules and does not result in violation of applicable traffic rate limits.

[0130] In the depicted embodiment, the CPS can automatically perform many other configuration-related tasks (element 1510) related to the RBA (RBA1) without the continued involvement of the VCS client. For example, the CPS can be responsible for installing / updating firmware / software at the NFA, including bug fixes and security patches. In various embodiments, the CPS can monitor the health of the NFA and RCI and provide an indication of the health status to the VCS client through a programming interface. In at least some embodiments, the CPS can also monitor performance metrics from the NFA and RCI and also provide a representation of the performance metrics to the VCS client through a programming interface. The VCS control plane can implement or utilize a graphical interface or dashboard to present such information. In at least one embodiment, a decision to migrate at least a portion of the workload of RBA1 to another RPS can be made based at least in part on an analysis of collected metrics (such as performance metrics or health status metrics), and / or based on a migration request programmatically submitted by a VCS client. As previously discussed, the CPS can orchestrate the migration process, which may require copying state information from the RCI, as well as state information for the fronthaul and / or midhaul traffic at the migration destination (part of which may be obtained from the NFA). In some embodiments, a corresponding virtualized representation of the NFA may be provided to multiple RCIs running at the RPS, enabling several RBAs or RBA pipelines to execute in parallel while sharing access to the NFA.

[0131] In various embodiments, corresponding portions of the logic of RBA1 may be executed at the RCI and the NFA. For example, in a downlink direction flow of RBA1 operations, some network functions of the DU of RBA1 may be executed at the RCI in response to messages received from other components of RBA1 running at other servers via addresses assigned to the VNI of the RCI (element 1513). Using the results or outputs of such network functions, additional network functions lower in the radio infrastructure technology stack, such as various physical layer or L1 functions (element 1516), may be executed at the NFA, 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. In various embodiments, traffic may also flow in the uplink direction, for example, from an end-user device through 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), where the results of the network functions performed by the RCI may be transmitted to a destination external to the RPS. It should be noted that in various embodiments, Fig.16 Some of the operations shown in the flowcharts of the drawings may be implemented in a different order than that shown in the drawings, or may be performed in parallel rather than sequentially. Additionally, in one or more embodiments, it may not be necessary to Fig.16Some of the operations shown.

[0132] Fig.16 An example programming interaction between a client and a provider network service related to a radio-based application is shown according to at least some embodiments. In the depicted embodiment, a provider network service 1612 (such as a VCS or a radio-based application management service (RBAMS)) can implement a set of programming interfaces 1677, such as a web-based console, command line tool, graphical user interface, API, etc., which a service client can utilize to submit messages or requests to the service and receive corresponding responses.

[0133] Client 1610 may use programming interface 1677 to send RadioBasedApplicationsDescriptor message 1614 to service 1612, indicating a set of locations of nearby cells that may require RPS, expected workloads at the locations (e.g., how many end-user devices for the client's radio-based applications (such as a public 5G network or a private 5G network) are expected to be used at each location, the approximate expected message rates from end users at different times of the day or different days of the week, etc.), the quality of service expected by RBA (e.g., message latency for different kinds of traffic), etc. RadioBasedApplicationsDescriptor message 1614 may also include the client's preferences regarding single-tenancy (e.g., whether the client wants exclusive use of the RPS and / or exclusive use of the NFA of such a card) versus multi-tenancy (e.g., whether the client is willing to share the RPS and / or network function accelerator with other clients), whether the client requires an NFA from a specific vendor or is willing to use any one of several vendors, etc. The information provided by the client may be analyzed at the provider network, e.g., by a configuration manager at a control plane server of the VCS, and a recommendation may be prepared for an RPS configuration that may be used to meet the estimated requirements of the client's applications. In the depicted embodiment, the recommendations may be provided to the client in one or more RecommendedRPSConfig messages 1615, which may, for example, indicate a count and type of RPS proposed for each of one or more specific locations (point of presence sites, client-owned premises, cell towers, etc.). Note that in some cases, some of the locations indicated in the recommendations may already have one or more RPSs installed and configured, e.g., for other clients that have previously submitted information about their own radio-based application workloads.

[0134] If the client approves the suggestion, an RPSConfigApproved message 1617 may be sent to the service 1612 via interface 1677. If a new RPS must be transported and installed to the approved suggested site, the process 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 a set of pre-installed RPSs at one or more suggested sites (for other clients, or not currently in use but established at client request) to accommodate additional workloads indicated by the client. When the RPS to be used for the client (configured in multi-tenant mode, or in single-tenant mode, depending on the client's preference, or depending on the default settings of the service 1612 if the client does not indicate a leasing preference) has been identified, and after connectivity between the RPS and the control plane resources of the provider network has been verified, in some embodiments, an RPSsReady message 1621 may be sent to the client to indicate that the client may request to launch a compute instance for its radio-based application. In some embodiments, corresponding identifiers of RPSs designated for use by the client may be provided in the RPSsReady message, and the client may use such identifiers to request the launch of radio-optimized compute instances at respective RPSs. In some embodiments, before launching the client's radio-optimized compute instance, service 1612 may also verify that a connection has also been established between the RPS designated for use by the client and (a) the RU (radio unit) at the cell to be used for the client application and (b) the resources to be used for the centralized unit (CU) and / or other layers of the application stack. In other embodiments, such verification of the connection of the RU and / or CU may be performed after launching the compute instance.

[0135] exist Fig.16 , client 1610 may utilize programmatic interface 1677 to indicate preferences regarding various aspects of the configuration of components of the RBA to be run using the RPS, including, for example, information regarding the IVN within which the RCI is to be launched (which may have been previously created in response to a programmatic request from the client), preferred addresses or address ranges for various components (such as the RCI's VNI or NFA), security rules for various classes of traffic of the RBA, traffic rate limits, etc. Such preferences may be indicated in one or more RBAConfigSettingsPreferences messages 1622 to service 1612. The preferences indicated by the client may be stored at the service's repository, and an RBAConfigSettingsSaved message 1623 may be sent to the client.

[0136] In various embodiments, the client 1610 may submit one or more LaunchRCIs requests 1624 through the programming interface 1677, thereby instructing, for example, the client's application to instantiate one or more RCIs of a specified category (e.g., Fig.13 In some embodiments, an RCIsLaunched message 1625 may be sent to the client 1610 to confirm that the RCI has been launched. In some embodiments, configuration information about the launched RCI, such as an instance identifier, IP address, etc. (which may be used to communicate with the CU, RU, and / or core network resources of the client's application) may be provided to the client.

[0137] In at least one embodiment, the client may submit a GetTrafficCategoryMetrics request 1631 to the service 1612 to request traffic at one or more RPSs for Fig.11 Metrics collected for one or more traffic categories in the traffic categories indicated in . In the depicted embodiment, the requested set of metrics may be provided to the client via one or more TCMetricSet messages 1633. For example, the client may obtain metrics for fronthaul traffic alone, such as how many messages were sent to and from the RU during a certain time interval, the total amount of data transmitted to and from the RU, the latency of such messages, whether any messages were lost, and the like. Similar sets of metrics may be provided for midhaul traffic, intra-IVN traffic, and the like. In some embodiments, metrics may be further decomposed by NHD, for example, if desired, a separate set of metrics for a given category of traffic transmitted through two NHDs of the RPS may be provided to each NHD. In some embodiments, compared to Fig.16 The programmatic interactions shown in can support other types of programmatic interactions related to implementing radio-based applications using provider network resources.

[0138] In at least some embodiments, a server implementing the types of techniques described herein (e.g., various functionality of a provider network service such as a VCS, including functionality within the provider network service and at extension sites) may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media. Fig.17 Such a general purpose computing device 9000 is shown. In the illustrated embodiment, the computing device 9000 includes one or more processors 9010 coupled to a system memory 9020 (which may include both non-volatile memory modules 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.

[0139] In various embodiments, the computing device 9000 may be a single processor 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 x86, PowerPC, SPARC, ARM or MIPS ISAs, or any other suitable ISAs. In a multiprocessor system, each processor in the processor 9010 may generally but not necessarily implement the same ISA. In some embodiments, a graphics processing unit (GPU) and / or a field programmable gate array (FPGA) may be used to replace a conventional processor or as a supplement to a conventional processor.

[0140] The system memory 9020 may be configured to store instructions and data accessible by the processor 9010. In at least some embodiments, the system memory 9020 may include both a volatile portion and a non-volatile portion; 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 (e.g., which may include one or more NVDIMMs), in some embodiments, flash-based memory devices may be used, including NAND flash devices. 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, memristor-based resistive random access memory (ReRAM), three-dimensional NAND technology, ferroelectric RAM, magnetoresistive RAM (MRAM), or any of various types of phase change memory (PCM) may be used at least for the non-volatile portion of the system memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown as being stored within system memory 9020 as code 9025 and data 9026 .

[0141] 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 in the device, including the network interface 9040 or other peripheral interfaces such as various types of persistent and / or volatile storage devices. In some embodiments, the I / O interface 9030 may perform any necessary protocol, timing, or other data transformations 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, for example, the I / O interface 9030 may include support for devices attached through various types of peripheral buses (e.g., variants of the peripheral component interconnect (PCI) bus standard or the universal serial bus (USB) standard). In some embodiments, for example, the functionality of the I / O interface 9030 may be split into two or more separate components, such as a north bridge and a south bridge. Moreover, in some embodiments, some or all of the functionality of the I / O interface 9030 (e.g., the interface of the system memory 9020) may be directly incorporated into the processor 9010.

[0142] The network interface 9040 may be configured to allow data to be exchanged between the computing device 9000 and other devices 9060 attached to one or more networks 9050, such as Figures 1 to 16 Other computer systems or devices shown. For example, in various embodiments, network interface 9040 can support communication through any suitable wired or wireless general data network (such as Ethernet type). Additionally, network interface 9040 can support communication through a telecommunications / telephone network (such as an analog voice network or a digital fiber optic communication network), through a storage area network (such as a Fiber Channel SAN), or through any other suitable type of network and / or protocol.

[0143] In some embodiments, system memory 9020 may represent one embodiment of a computer-accessible medium configured to store a program for implementing Figures 1 to 16At least a subset of the program instructions and data of the methods and devices discussed in the context of . However, in other embodiments, the program instructions and / or data can be received, sent or stored on different types of computer-accessible media. In general, the computer-accessible medium may include a non-transitory storage medium or a storage medium such as a magnetic or optical medium, such as a disk or DVD / CD coupled to the computing device 9000 via an I / O interface 9030. The non-transitory computer-accessible storage medium may also include any volatile or non-volatile medium, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be included in some embodiments of the computing device 9000 as a system memory 9020 or another type of memory. In some embodiments, a plurality of non-transitory computer-readable storage media may store program instructions together, and when the program instructions are executed on one or more processors or across one or more processors, at least a subset of the methods and techniques described above is implemented. The computer-accessible medium may further include a transmission medium or a signal such as an electrical signal, an electromagnetic signal or a digital signal, which is transmitted through a communication medium such as a network and / or a wireless link, such as can be implemented through a network interface 9040. You can use Fig.17 Some or all of the computing devices shown in the present invention can be used to implement the functions described in various embodiments; for example, software components running on various different devices and servers can cooperate to provide functions. In some embodiments, in addition to or instead of using a general-purpose computer system for implementation, a storage device, a network device, or a dedicated computer system can be used to implement part of the described functions. As used herein, the term "computing device" refers to at least all of these types of devices and is not limited to these types of devices.

[0144] in conclusion

[0145] Embodiments of the present disclosure may be described in light of the following terms:

[0146] Clause 1. A system comprising:

[0147] A set of control plane servers for virtualized computing services of a cloud provider network; and

[0148] A virtualized server comprising a main processor and an offload card, wherein the offload card includes (a) a virtualization controller for a computing instance launched at the virtualized server, (b) a network function accelerator for a radio-based application, and (c) a networking hardware device;

[0149] The set of control plane servers is configured as follows:

[0150] assigning to the networked hardware device a first network address within an underlying network of the virtualized computing service, the first network address to be used for communicating with one or more resources of the cloud provider network external to the virtualized server;

[0151] assigning a second network address to a first computing instance launched at the virtualization server using at least the virtualization controller, wherein the second network address is not within the underlying network; and

[0152] assigning a third network address to the network function accelerator, the third network address to be used for communication between the network function accelerator and one or more radio units (RUs) of one or more radio-based applications; and

[0153] The virtualization server stores instructions, which when executed on the main processor:

[0154] causing a first network function of a first radio-based application to be executed at the first computing instance in response to a message received at the first computing instance, wherein the message is received using a mapping between the second network address and the first network address; and

[0155] Based at least in part on a result of the first network function, causing a second network function of the first radio-based application to be executed at the network function accelerator, wherein an output of the second network function is transmitted to a radio unit of the first radio-based application using the third network address.

[0156] Clause 2. The system of clause 1, wherein the set of control plane servers is located at a data center of the cloud provider network, and wherein the virtualization server is located at a location external to the data center.

[0157] Clause 3. The system of any one of clauses 1 to 2, wherein the virtualization server stores further instructions that, when executed on the host processor:

[0158] causing a first virtualized representation of the network function accelerator to be presented to the first computing instance, wherein the second network function is executed in response to a first request from the first computing instance, wherein the first request is received at the network function accelerator through an interface of the first virtualized representation; and

[0159] causing a second virtualized representation of the network function accelerator to be presented to a second computing instance launched at the virtualization server, wherein in response to a second request from the second computing instance, a third network function is performed at the network function accelerator, wherein the third network function is part of a second radio-based application, and wherein the second request from the second computing instance is received at the network function accelerator using an interface of the second virtualized representation.

[0160] Clause 4. The system of any of clauses 1 to 3, wherein the first network function is a network function of a distributed unit (DU) based on a technology stack of a radio.

[0161] Clause 5. The system of any of clauses 1 to 4, wherein the second network function is a network function based on a physical layer of a technology stack of the radio.

[0162] Clause 6. A computer-implemented method comprising:

[0163] performing, by a control plane server of a virtualized computing service of a cloud provider network, one or more configuration operations at an offload card of a virtualized server, wherein the offload card includes (a) a virtualization controller for a computing instance, (b) a first network function accelerator for a radio-based application, and (c) a networking hardware device, wherein the one or more configuration operations include assigning a first network address to the networking hardware device, and assigning a second network address to the first network function accelerator;

[0164] causing, by the control plane server using at least the virtualization controller, a first computing instance to be launched at the virtualization server, wherein the first computing instance performs a first network function of a first radio-based application in response to a message received using the first network address; and

[0165] A second network function of the first radio-based application is executed at the first network function accelerator in response to output obtained from the first network function, wherein the output of the second network function is sent to a destination external to the virtualized server using the second network address as a source address.

[0166] Clause 7. The computer-implemented method of clause 6, wherein the one or more configuration operations include:

[0167] Enable a firmware or software update of the first network function accelerator.

[0168] Clause 8. The computer-implemented method of any one of clauses 6 to 7, wherein the one or more configuration operations include:

[0169] monitoring the health status of the first network function accelerator; and

[0170] The indication of the health status is caused to be provided through a programming interface of the virtualized computing service.

[0171] Clause 9. The computer-implemented method of any one of clauses 6 to 8, wherein the one or more configuration operations include:

[0172] monitoring a performance metric of the first network function accelerator; and

[0173] An indication of the performance metric is caused to be provided through a programming interface of the virtualized computing service.

[0174] Clause 10. The computer-implemented method of any one of clauses 6 to 9, wherein the one or more configuration operations include:

[0175] The security patch is applied to the first network function accelerator.

[0176] Clause 11. The computer-implemented method of any one of clauses 6 to 10, wherein the one or more configuration operations include:

[0177] In response to detecting that the first computing instance has been terminated, contents of the memory of the first network function accelerator are erased.

[0178] Clause 12. The computer-implemented method of any one of clauses 6 to 11, further comprising:

[0179] presenting a first virtualized representation of the first network function accelerator to the first computing instance so that the first computing instance can transmit a request for a network function of the first radio-based application to the first network function accelerator; and

[0180] Presenting a second virtualized representation of the first network function accelerator to a second computing instance launched at the virtualization server using at least the virtualization controller, so that the second computing instance can transmit a request for a network function of a second radio-based application to the first network function accelerator.

[0181] Clause 13. The computer-implemented method of any one of clauses 6 to 12, further comprising:

[0182] The control plane server causes at least a portion of the workload of the first radio-based application to be migrated to another virtualized server, wherein the other virtualized server includes an offload card having a second network function accelerator, wherein as a result of the migration, (a) messages from a radio unit of the first radio-based application are delivered to the second network function accelerator, and (b) a migrated version of the first computing instance executes the first network function of the first radio-based application at the other virtualized server.

[0183] Clause 14. The computer-implemented method of any of Clauses 6 to 13, wherein the second network function comprises an L1 network function based on a technology stack of the radio.

[0184] 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 radio-based technology stack.

[0185] Clause 16. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server for virtualized computing services, wherein the control plane server is configured to:

[0186] assigning a first network address to a networking hardware device of an offload card of a virtualized server, wherein the offload card includes (a) a network function accelerator for a radio-based application, and (b) a virtualization controller for a computing instance;

[0187] assigning a second network address to the network function accelerator, wherein the second network address is used for communication between the network function accelerator and a radio unit of a radio-based application; and

[0188] Causes a computing instance to be launched at the virtualization server using the virtualization controller, wherein the computing instance (a) executes a first network function of the radio-based application in response to a request received using the first network address, and (b) requests execution of a second network function of the radio-based application at the network function accelerator, and wherein an output of the second network function is transmitted to the radio unit using the second network address.

[0189] Clause 17. The non-transitory computer-accessible storage medium of Clause 16, wherein the control plane server is further configured to:

[0190] Enable a firmware or software update of the network function accelerator.

[0191] Clause 18. The non-transitory computer-accessible storage medium of any one of clauses 16 to 17, wherein the control plane server is further configured to:

[0192] Monitoring the health status of the network function accelerator; and

[0193] The indication of the health status is caused to be presented through a programming interface of the virtualized computing service.

[0194] Clause 19. The non-transitory computer-accessible storage medium of any of Clauses 16 to 18, wherein the second network function comprises an L1 network function of a radio-based technology stack.

[0195] 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 radio-based technology stack.

[0196] Clause 21. A server comprising:

[0197] processor;

[0198] Memory; and

[0199] An offload card, wherein the offload card comprises (a) a virtualization controller and (b) a network function accelerator for radio-based applications;

[0200] The virtualization controller is configured to:

[0201] performing one or more configuration tasks associated with a computing instance started at the server, the tasks comprising allocating at least a portion of the memory for use by the computing instance; and

[0202] wherein the memory stores instructions which, when executed on the processor:

[0203] executing a first network function of a radio-based application at the computing instance; and

[0204] An output of the first network function is caused to be provided as an input to a second network function of the radio-based application, wherein the second network function runs at the network function accelerator.

[0205] Clause 22. The server of clause 21, wherein the offload card comprises a network processing offload and a networking hardware device, a network address within an underlying network of the virtualized computing service being assigned to the networking hardware device, and wherein the network processing offload is configured to:

[0206] One or more messages associated with the radio-based application are transmitted from the computing instance to a destination external to the server using the networking hardware device.

[0207] Clause 23. A server according to Clause 21, wherein the offload card comprises a first networking hardware device and a second networking hardware device, wherein the first networking hardware device is used to transmit messages to a first set of destinations including a centralized unit (CU) of the radio-based application, and wherein the second networking hardware device is used to transmit messages to a second set of destinations including a radio unit (RU) of the radio-based application.

[0208] Clause 24. A server according to any one of clauses 21 to 22, wherein the offload card comprises another network function accelerator, and wherein the memory stores further instructions that, when executed on the processor:

[0209] The input is caused to be provided to a third network function executed at another network function accelerator.

[0210] Clause 25. The server of Clause 24, wherein the third network function is executed as part of another radio-based application.

[0211] Clause 26. A computer-implemented method comprising:

[0212] performing, by a virtualization controller executing at an offload card of a server, one or more configuration tasks associated with a first computing instance launched at a server, the tasks comprising allocating at least a portion of a memory of the server for use by the first computing instance, wherein the offload card includes a first network function accelerator for a radio-based application;

[0213] executing, at the first computing instance, a first network function of a first radio-based application; and

[0214] A second network function of the first radio-based application is executed at the 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.

[0215] Clause 27. The computer-implemented method of clause 26, wherein the offload card comprises a first networking hardware device, a first network address within an underlying network of the virtualized computing service being assigned to the first networking hardware device, the computer-implemented method further comprising:

[0216] One or more messages associated with the first radio-based application are transmitted from the first computing instance to a second computing instance using the first networking hardware device.

[0217] Clause 28. A computer-implemented method according to Clause 27, wherein the offload card includes a second networking hardware device, wherein the first networking hardware device is used to transmit messages to a first set of destinations including a centralized unit (CU) of the first radio-based application running at the second computing instance, and wherein the second networking hardware device is used to transmit messages to a second set of destinations including a radio unit (RU) of the first radio-based application.

[0218] 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.

[0219] Clause 30. The computer-implemented method of clause 26, wherein the offload card comprises a second network function accelerator, the computer-implemented method further comprising:

[0220] A third network function is performed at the second network function accelerator.

[0221] Clause 31. The computer-implemented method of Clause 30, wherein the third network function is executed as part of a second radio-based application.

[0222] Clause 32. The computer-implemented method of clause 26, further comprising:

[0223] presenting a first virtualized representation of the first network function accelerator to the first computing instance so that a request for a network function of the first radio-based application can be transmitted from the first computing instance to the first network function accelerator; and

[0224] A second virtualized representation of the first network function accelerator is presented to a second computing instance launched at the server so that a request for a network function of the second radio-based application can be transmitted from the second computing instance to the first network function accelerator.

[0225] Clause 33. The computer-implemented method of any one of clauses 26, 27, 30 or 32, further comprising:

[0226] The firmware or software of the first network function accelerator is updated in response to a message received from a control plane server of a virtualized computing service.

[0227] Clause 34. A computer-implemented method according to any one of clauses 26, 27, 30 or 32 to 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.

[0228] Clause 35. A computer-implemented method as recited in any one of Clauses 26, 27, 30, or 32 to 34, wherein the second network function implements an L1 network function based on a technology stack of the radio.

[0229] Clause 36. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor of an offload card of a server:

[0230] performing one or more virtualization management tasks associated with a computing instance started at the server, the tasks comprising allocating at least a portion of a memory of the server for use by the computing instance;

[0231] obtaining, from the computing instance, a request for a first network function of a radio-based application; and

[0232] The first network function is performed at a network function accelerator incorporated into the offload card.

[0233] Clause 37. The non-transitory computer-accessible storage medium of Clause 36, wherein the offload card is linked to a processor of the server through a peripheral interface.

[0234] Clause 38. A non-transitory computer-accessible storage medium according to any one of clauses 36 to 37, storing further program instructions that, when executed on the processor of the offload card:

[0235] Obtaining a request for a second network function from another computing instance; and

[0236] The second network function is performed at the network function accelerator.

[0237] Clause 39. A non-transitory computer-accessible storage medium as described in any 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 or (b) a centralized unit (CU) of a RAN node or (c) a core network of a radio-based technology stack.

[0238] Clause 40. The non-transitory computer-accessible storage medium of any one of clauses 36 to 39, wherein the offload card comprises a first networked hardware device, the non-transitory computer-accessible storage medium storing further program instructions that, when executed on the processor of the offload card:

[0239] One or more messages associated with the radio-based application are transmitted using the first networking hardware device to a destination external to the server.

[0240] Clause 41. A system comprising:

[0241] Control plane servers for virtualized computing services of a cloud provider network; and

[0242] a virtualized server comprising a network function accelerator for radio-based applications;

[0243] The control plane server is configured to:

[0244] establishing an isolated virtual network on behalf of a client of the virtualized computing service;

[0245] storing, in response to a first request submitted by the client through a programming interface of the virtualized computing service, within a repository of metadata of the isolated virtual network, a representation of a first security group associated with a computing instance launched at the virtualized server, wherein the computing instance is assigned a network address within the isolated virtual network, wherein the first security group includes a first restriction on a source of inbound traffic directed to the computing instance, and wherein the computing instance performs a first network function of a radio-based application;

[0246] storing, in response to a second request submitted by the client through the programming interface, within the repository, a representation of a second security group associated with the network function accelerator, wherein the second security group includes a second restriction on a destination of outbound traffic from the network function accelerator, and wherein the network function accelerator performs a second network function of the radio-based application;

[0247] prior to delivering a first network message of the radio-based application to the computing instance using the network address as a destination address, verifying whether the first network message complies with the first restriction, wherein the first network message at least partially causes execution of the first network function; and

[0248] Prior to delivering a second network message of the radio-based application from the network function accelerator to a destination, verifying that the second network message complies with the second restriction, wherein the output of the first network function at least partially causes the execution of the second network function.

[0249] Clause 42. The system of clause 41, wherein the control plane server is further configured to:

[0250] In response to determining that delivery of the third network message would violate a rate limit associated with traffic of the network function accelerator, a third network message originated at the network function accelerator is not delivered to a destination.

[0251] Clause 43. The system of any one of clauses 41 to 42, wherein the virtualization server comprises an offload card, wherein the offload card includes the network function accelerator and the virtualization controller, wherein the control plane server is further configured to:

[0252] In response to another request, the computing instance is started using the virtualization controller.

[0253] Clause 44. The system of any one of clauses 41 to 43, wherein the control plane server is further configured to:

[0254] In response to another request, a routing table entry for the intermediate traffic of the radio-based application is stored in the routing table of the isolated virtual network, wherein the intermediate traffic includes 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, wherein the message is generated at the virtualization server.

[0255] Clause 45. The system of any one of clauses 41 to 44, wherein the control plane server is further configured to:

[0256] A network address in a network address range of the isolated virtual network is assigned to the network function accelerator.

[0257] Clause 46. A computer-implemented method comprising:

[0258] storing a representation of a first set of configuration settings of a computing instance configured within an isolated virtual network and launched at a virtualization server in response to a first programmatic request, wherein the computing instance implements a first network function of a radio-based application, wherein the implementation virtualization server includes a network function accelerator for the radio-based application, and wherein the first set of implementation configuration settings includes a first set of network security rules to be applied to traffic of the computing instance;

[0259] storing a representation of a second set of configuration settings for the network function accelerator in response to a second programming request, wherein the second set of configuration settings includes a second set of network security rules to be applied to traffic of the network function accelerator;

[0260] verifying, before delivering a first network message to the computing instance, whether the first network message complies with the first network security rule set, wherein delivery of the first network message results in execution of the first network function at the computing instance; and

[0261] Prior to delivering a second network message from the network function accelerator to a destination external to the virtualized server, verifying whether the second network message complies with the second set of network security rules, wherein the second network message includes an output of a second network function executed at the network function accelerator.

[0262] Clause 47. The computer-implemented method of clause 46, wherein the virtualized server comprises an offload card, wherein the offload card comprises the network function accelerator and the virtualization controller, the computer-implemented method further comprising:

[0263] The computing instance is started using the virtualization controller in response to another programmatic request.

[0264] Clause 48. The computer-implemented method of any one of clauses 46 to 47, further comprising:

[0265] In response to another programming request, a routing table entry for the mid-haul traffic of the radio-based application is stored in the routing table of the isolated virtual network, wherein the mid-haul traffic includes 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, and wherein the message is generated at the virtualized server.

[0266] Clause 49. The computer-implemented method of any one of clauses 46 to 48, wherein the second set of network security rules applies to traffic between the network function accelerator and a radio unit of the radio-based application, the computer-implemented method further comprising:

[0267] A third set of network security rules is stored to be applied to traffic between the network function accelerator and the centralized unit for radio-based applications.

[0268] Clause 50. The computer-implemented method of any one of clauses 46 to 49, further comprising:

[0269] A network address in a network address range of the isolated virtual network is allocated to the network function accelerator.

[0270] Clause 51. A computer-implemented method according to any one of Clauses 46 to 50, wherein the second network security rule set includes a network access control list to be applied to at least a portion of the traffic of the network function accelerator, wherein the network access control list is applied to a subnet defined within the isolated virtual network.

[0271] Clause 52. A computer-implemented method according to any one of clauses 46 to 51, wherein the first network message is formatted according to the Internet Protocol (IP), and wherein the second network message is formatted according to the Common Public Radio Interface (CPRI) or the enhanced Common Public Radio Interface (eCPRI).

[0272] Clause 53. The computer-implemented method of any one of clauses 46 to 52, wherein the second network function comprises an L1 network function based on a technology stack of a radio.

[0273] 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 radio-based technology stack.

[0274] Clause 55. The computer-implemented method of clause 46, wherein the virtualized server comprises an offload card, wherein the offload card comprises the network function accelerator and the networking hardware device, the computer-implemented method further comprising:

[0275] The networked hardware device is assigned (a) a first network address of an underlying network of the virtualized computing service, and the computing instance is assigned (b) a second network address, wherein the second network address is not part of the underlying network, wherein a mapping between the first network address and the second network address is used to deliver network messages originating from a source external to the virtualized server to the computing instance.

[0276] Clause 56. A non-transitory computer-accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server for virtualized computing services, wherein the control plane server is configured to:

[0277] storing a representation of a first set of configuration settings of a computing instance configured within an isolated virtual network and launched at a virtualization server in response to a first programmatic request, wherein the computing instance implements a first network function of a radio-based application, wherein the implementation virtualization server includes a network function accelerator for the radio-based application, and wherein the first set of implementation configuration settings includes a first set of network security rules to be applied to traffic of the computing instance;

[0278] storing a representation of a second set of configuration settings for the network function accelerator in response to a second programming request, wherein the second set of configuration settings includes a second set of network security rules to be applied to traffic of the network function accelerator;

[0279] Before delivering a first network message to the computing instance, verifying whether the first network message complies with the first network security rule set, wherein delivery of the first message results in execution of the first network function at the computing instance; and

[0280] Prior to delivering a second network message from the network function accelerator to a destination external to the virtualized server, verifying whether the second network message complies with the second network security rule set, wherein the second network message includes an output of a second network function.

[0281] Clause 57. The non-transitory computer-accessible storage medium of Clause 56, wherein the virtualization server comprises an offload card, wherein the offload card includes the network function accelerator and the virtualization controller, wherein the control plane server is further configured to:

[0282] The computing instance is started using the virtualization controller in response to another programmatic request.

[0283] Clause 58. The non-transitory computer-accessible storage medium of any one of clauses 56 to 57, wherein the control plane server is further configured to:

[0284] In response to another programming request, a routing table entry for the radio-based application's intermediate traffic is stored in the routing table of the isolated virtual network, wherein the intermediate traffic includes 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, wherein the message is generated at the virtualized server.

[0285] Clause 59. The non-transitory computer-accessible storage medium of any one of clauses 56 to 58, wherein the second set of network security rules is to be applied to traffic between the network function accelerator and the radio unit of the radio-based application, and wherein the control plane server is further configured to:

[0286] In response to another programming request, a third set of network security rules is stored to be applied to traffic between the network function accelerator and the centralized unit for radio-based applications.

[0287] Clause 60. The non-transitory computer-accessible storage medium of any one of clauses 56 to 59, wherein the control plane server is further configured to:

[0288] A network address in the network address range of the isolated virtual network is assigned to the network function accelerator in response to another programming request.

[0289] Various embodiments may further include receiving, sending or storing instructions and / or data implemented according to the foregoing description on a computer-accessible medium. In general, a computer-accessible medium may include a storage medium or memory medium (such as a magnetic or optical medium, for example, a disk or a DVD / CD-ROM), a volatile or non-volatile medium (such as a RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), a ROM, etc.), and a transmission medium or signal (such as an electrical signal, an electromagnetic signal, or a digital signal) conveyed by a communication medium (such as a network and / or a wireless link).

[0290] The various methods shown 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, reordered, combined, omitted, modified, etc.

[0291] It will be apparent to those skilled in the art having the benefit of this disclosure that various modifications and changes may occur. It is intended to embrace all such modifications and changes, and therefore, the above description is to be regarded as illustrative rather than restrictive.

Claims

1. A system comprising: one or more computing devices; wherein the one or more computing devices include instructions that, when executed on or across the one or more computing devices, cause the one or more computing devices to implement a control plane server for a virtualized computing service, wherein the control plane server is configured to: assigning a first network address to a networking hardware device of an offload card of a virtualized server, wherein the offload card includes (a) a network function accelerator for a radio-based application, and (b) a virtualization controller for a computing instance; assigning a second network address to the network function accelerator, wherein the second network address is used for communication between the network function accelerator and a radio unit of a radio-based application; and Causes a first computing instance to be launched at the virtualization server using the virtualization controller, wherein the first computing instance (a) executes a first network function of the radio-based application in response to a first request received using the first network address, and (b) requests execution of a second network function of the radio-based application at the network function accelerator, and wherein an output of the second network function is transmitted to the radio unit using the second network address. 2 . The system of claim 1 , wherein the control plane server is located at a data center of a cloud provider network, and wherein the virtualization server is located at a location external to the data center.

3. The system according to any one of claims 1 to 2, wherein the control plane server is further configured to: causing a first virtualized representation of the network function accelerator to be presented to the first computing instance, and wherein requesting execution of the second network function at the network function accelerator from the first computing instance through an interface of the first virtualized representation; and A second virtualized representation of the network function accelerator is presented to a second computing instance started at the virtualization server, and wherein execution of a third network function at the network function accelerator is requested from the second computing instance through an interface of the second virtualized representation.

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

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

6. A computer-implemented method comprising performing, by a control plane server of a virtualized computing service: assigning a first network address to a networking hardware device of an offload card of a virtualized server, wherein the offload card includes (a) a first network function accelerator for a radio-based application, and (b) a virtualization controller for a computing instance; allocating a second network address to the first network function accelerator, wherein the second network address is used for communication between the first network function accelerator and a radio unit of a radio-based application; and Causes a computing instance to be launched at the virtualization server using the virtualization controller, wherein the computing instance (a) executes a first network function of the radio-based application in response to a request received using the first network address, and (b) requests execution of a second network function of the radio-based application at the first network function accelerator, and wherein an output of the second network function is transmitted to the radio unit using the second network address.

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

8. The computer-implemented method of any one of claims 6 to 7, further comprising performing the following operations by the control plane server: monitoring the health status of the first network function accelerator; and The indication of the health status is caused to be provided through a programming interface of the virtualized computing service.

9. The computer-implemented method of any one of claims 6 to 8, further comprising performing the following operations by the control plane server: monitoring a performance metric of the first network function accelerator; and An indication of the performance metric is caused to be provided through a programming interface of the virtualized computing service.

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

11. The computer-implemented method of any one of claims 6 to 10, further comprising performing the following operations by the control plane server: In response to detecting that the computing instance has been terminated, contents of the memory of the first network function accelerator are erased.

12. The computer-implemented method of any one of claims 6 to 11, further comprising performing, by the control plane server: Causes at least a portion of the workload of the radio-based application to be migrated to another virtualized server, wherein the other virtualized server includes an offload card having a second network function accelerator, wherein as a result of the migration, (a) messages from a radio unit of the radio-based application are delivered to the second network function accelerator, and (b) a migrated version of the computing instance executes the first network function of the radio-based application at the other virtualized server.

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

14. A non-transitory computer accessible storage medium storing program instructions that, when executed on a processor, implement a control plane server for virtualized computing services, wherein the control plane server is configured to: assigning a first network address to a networking hardware device of an offload card of a virtualized server, wherein the offload card includes (a) a network function accelerator for a radio-based application, and (b) a virtualization controller for a computing instance; assigning a second network address to the network function accelerator, wherein the second network address is used for communication between the network function accelerator and a radio unit of a radio-based application; and Causes a computing instance to be launched at the virtualization server using the virtualization controller, wherein the computing instance (a) executes a first network function of the radio-based application in response to a request received using the first network address, and (b) requests execution of a second network function of the radio-based application at the network function accelerator, and wherein an output of the second network function is transmitted to the radio unit using the second network address.

15. The non-transitory computer-accessible storage medium of claim 14, wherein the control plane server is further configured to: monitoring the health status of the network function accelerator; and The indication of the health status is caused to be presented through a programming interface of the virtualized computing service.

Images