Centralized Acceleration Abstraction Layer for RAN Virtualization

Abstract

The present application discloses a method for aligning allocation of radio processing operations associated with multiple vRAN nodes (38) to a shared computational resource. In one embodiment, the method includes the steps of invoking, by the vRAN node (38), a virtual operation to request the operation to be accelerated, receiving, by a centralized acceleration abstraction layer, or AAL, broker (36) implemented on top of a shared accelerated computing infrastructure (20), the operation request from the vRAN node (38), selecting, by the AAL broker (36) using a predefined or configurable scheduling policy (37), a physical hardware accelerator (12) for accelerated execution of the requested operation, and forwarding, by the AAL broker (36), the operation request to a processing queue (18) of the selected hardware accelerator (12).

Description

[Technical field]

[0001] The present invention relates to a system and method for matching the allocation of radio processing operations associated with multiple vRAN nodes to a shared computational resource. [Background technology]

[0002] Extending network functions virtualization (NFV) to the far ends of mobile networks allows for the decoupling of Radio Access Network (RAN) workloads from the underlying hardware infrastructure in so-called vRANs. This approach offers many advantages over the relatively robust traditional RAN, including reduced vendor lock-in, streamlined upgrades, and multiplexed compute resources. Hence, RAN virtualization has become a key technology trend moving towards next-generation systems. Driven by the O-RAN Alliance, virtually all industry players are deploying or building vRANs, creating new markets that bring unprecedented business opportunities to the rigid RAN ecosystem.

[0003] The RAN comprises several base stations, each decomposed into a central unit (CU), which handles the top layers of the stack, distributed units (DUs) which handle the lower layers including radio link control, MAC and physical layers, and radio units (RUs) which perform basic radio functions such as signal sampling. In contrast to the CU, the DU requires a computing infrastructure to process signals in a timely and predictable manner. This is because the pipeline of tasks involved in the physical layer (PHY) has tight and strict timing constraints, i.e., missing deadlines may cause users to lose synchronization and disrupt network performance, and some of the tasks are computationally intensive. In this context, for illustrative purposes, Figure 1 shows the time required by Intel® FlexRAN, a software development kit (SDK) that is easily used by most solutions today to implement FEC (forward error correction), rate matching, and CRC (cyclic redundancy check) general-purpose processors, for successful decoding of a 4Kbyte transport block modulated with 64QAM and coded with LDPC and 1 / 3 code rate, and for different signal-to-noise ratio regimes between 10dB and 30dB on a dedicated CPU core. For FlexRAN, please refer to Intel. 2019. FlexRAN LTE and 5G NR FEC Software Development Kit Modules. https: / / software.intel.com / content / www / us / en / develop / articles / flexran-lte-and-5g-nr-fec-software-development-kit-modules.htm for reference.

[0004] Therefore, vRAN solutions in the industry today rely on offloading computationally intensive operations, such as LDPC encoding / decoding, mostly FEC tasks, to dedicated hardware accelerators (HAs). HAs can be GPUs, FPGAs, ASICs, or even CPUs dedicated to one task (e.g., FEC). GPU acceleration (e.g., NVIDIA Aerial) and FPGA acceleration (e.g., Intel® FlexRAN, which provides both FPGA drivers and CPU libraries (utilizing the Intel AVX-512 instruction set) for FEC acceleration) are the most popular processors, as they are programmable and can perform radio processing operations very fast.

[0005] However, as acknowledged by business executives, the current approach is likely to fail. The root cause is the strong reliance on HAs that are limited to individual DUs, which reduces flexibility and leads to higher costs and power consumption than traditional ASIC-based DUs, which is exactly why virtualization is being considered for RAN in the first place. This is particularly disappointing because HA resources are very underutilized most of the time with no opportunity for statistical multiplexing within short timescales.

[0006] A more rational approach is to share acceleration resources with multiple DUs using standard interfaces that provide appropriate abstractions to maximize resource usage and therefore minimize costs. In O-RAN, this is called the Acceleration Abstraction Layer (AAL). Hardware Accelerators (HAs) hold the key to preserving carrier-grade performance of network functions (NFs), including radio signal processing functions, such as DUs, without compromising the flexibility offered by virtualization. HAs can be a set of CPUs dedicated to one task, a more dedicated processor such as a GPU, a function implemented on a Field Programmable Gate Array (FPGA), or a fixed function implemented on an Application Specific Integrated Circuit (ASIC) that can execute one task faster than a shared General Purpose Processor (GPP) consisting of CPUs, as shown in Figure 2.

[0007] In this context, Ding, Jian et al., "Agora: Real-time massive MIMO baseband processing in software." Proceedings of the 16th International Conference on emerging Networking EXperiments and Technologies, 2020, disclose a 5G signal processor built on top of FlexRAN's open library, suitable for many-core general-purpose CPUs, i.e., without the need for additional HA. However, their solution is not suitable for shared platforms, and the amount of CPU cores required to provide carrier-grade performance on a single vDU makes the cost and energy consumption too high.

[0008] More recently, Foukas, Xenofon, and Bozidar Radunovic, “Concordia: teaching the 5G vRAN to share compute,” Proceedings of the 2021 ACM SIGCOMM 2021 Conference, 2021, disclosed a system with a task scheduler that allows virtualized DUs to share compute resources with other applications to maximize resource utilization. However, this approach does not address the case where multiple DUs share a common pool of HAs.

[0009] Furthermore, G. Garcia-Aviles, A. Garcia-Saavedra, M. Gramaglia, X. Costa-Perez, P. Serrano, and A. Banchs, "Nuberu: Reliable RAN Virtualization in Shared Platforms," ​​MobiCom '21. Proceedings of the 27th Annual International Conference on Mobile Computing and Networking. October 2021, pp. 749-761, https: / / doi.org / 10.1145 / 3447993.3483266, describes a DU design that provides reliability in non-deterministic (shared) computing platforms by relying on predictions and trading off latency for reliability. While the use of reliable DUs in such environments is paramount, the question remains of how to efficiently allocate computational resources across all DUs. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] Intel. 2019. FlexRAN LTE and 5G NR FEC Software Development Kit Modules. https: / / software.intel.com / content / www / us / en / develop / articles / flexran-lte-and-5g-nr-fec-software-development-kit-modules.htm [Non-Patent Document 2] Ding, Jian et al., “Agora: Real-time massive MIMO baseband processing in software.” Proceedings of the 16th International Conference on emerging Networking EXperiments and Technologies, 2020. [Non-Patent Document 3] Foukas, Xenofon, and Bozidar Radunovic, "Concordia: teaching the 5G vRAN to share compute." Proceedings of the 2021 ACM SIGCOMM 2021 Conference, 2021. [Non-Patent Document 4] G. Garcia-Aviles, A. Garcia-Saavedra, M. Gramaglia, X. Costa-Perez, P. Serrano, and A. Banchs, “Nuberu: Reliable RAN Virtualization in Shared Platforms,” MobiCom '21. Proceedings of the 27th Annual International Conference on Mobile Computing and Networking. October 2021, pp. 749–761, https: / / doi.org / 10.1145 / 3447993.3483266 [Non-Patent Document 5] O-RAN Alliance, “O-RAN Acceleration Abstraction Layer General Aspects and Principles (O-RAN.WG6.AAL-GAnP-v01.01)”, Technical Specification, July 2021 Summary of the Invention [Problem to be solved by the invention]

[0011] It is therefore an object of the present invention to improve and further develop a method and system of the type initially described for matching the allocation of radio processing operations associated to multiple vRAN nodes to a shared computational resource such that the shared computational resource is used more efficiently. [Means for solving the problem]

[0012] According to the present invention, the above mentioned object is achieved by a method for aligning allocation of radio processing operations associated with multiple vRAN nodes to a shared computational resource, the method comprising the steps of receiving, by a centralized Acceleration Abstraction Layer, or AAL, broker implemented on top of a shared accelerated computing infrastructure, an operation request for a virtual operation associated with the vRAN node, the operation request specifying the operation to be accelerated; selecting, by the AAL broker using a predefined or configurable scheduling policy, a physical hardware accelerator for accelerated execution of the requested operation; and forwarding, by the AAL broker, the operation request to a processing queue of the selected hardware accelerator.

[0013] According to the present invention, it is firstly recognized that the above mentioned objectives can be solved by implementing a centralized acceleration abstraction layer for RAN virtualization, operating on top of a shared accelerated computing infrastructure, e.g., O-RAN AAL infrastructure. The proposed centralized acceleration abstraction layer comprises a novel O-RAN entity, i.e., the AAL Broker, which provides a centralized approach to efficiently allocate a common and shared accelerated computing infrastructure (including a pool of CPUs, GPUs, FPGAs, ASICs, etc.) to radio processing tasks associated with multiple vRAN nodes (e.g., vDUs). By supporting centralized coordination of acceleration resources, the AAL Broker enables efficient implementation of load balancing, thereby avoiding overloading of each and every one of the available, heterogeneous acceleration resources. As a result, the present invention provides a more cost-effective O-RAN solution by improving the utilization efficiency of one of the most costly components (the O-Cloud).

[0014] In an embodiment, the present invention relates to an O-RAN scenario where an abstraction layer matches all vRAN requests to a pool of hardware accelerators. The AAL broker enables a centralized approach to allocate a pool of shared and co-accelerated resources, i.e., CPUs, GPUs, FPGAs, ASICs, etc., to radio processing tasks associated with multiple VDU (VRAN) nodes. The AAL broker layer may receive virtual operation requests (FEC, FFT, LDPC, etc.) and may find an appropriate queue to allocate AAL devices according to the request. Additionally, the decoded bits of each function (FEC, FFT, LDPC, etc.) may be fed back to the vRAN nodes through the broker layer.

[0015] For smooth and efficient operation, according to an embodiment of the present invention, it may be that the AAL broker is implemented to interact with the underlying shared acceleration computing infrastructure as if it were an individual vRAN node. In the context of an O-RAN architecture, when implementing a system according to the present invention, the underlying shared acceleration computing infrastructure interacting with the AAL broker may be, for example, an O-RAN AAL infrastructure, as detailed in O-RAN Alliance, "O-RAN Acceleration Abstraction Layer General Aspects and Principles (O-RAN.WG6.AAL-GAnP-v01.01)", Technical Specification, July 2021.

[0016] According to one embodiment of the present invention, a vRAN node operation request may include information about the operation to be accelerated (e.g., FEC, FFT, CRC), data required to perform the operation (e.g., code blocks in case of an FEC decode operation), and settings for performing the operation (e.g., maximum number of decoding iterations in case of an FEC decode operation).

[0017] According to one embodiment of the present invention, a hardware accelerator selected by the AAL broker to perform the requested acceleration of a particular task / operation may be configured to perform the requested operation in a FIFO manner according to the requests in its associated processing queue, thus ensuring fair and seamless operation.

[0018] According to an embodiment of the invention, the AAL broker may be further configured to receive, directly or indirectly, a response from the selected hardware accelerator in response to forwarding the operation request to the processing queue of the selected hardware accelerator, and to forward the response received from the selected hardware accelerator to the issuing vRAN node.

[0019] According to one embodiment of the present invention, the scheduling policy used by the AAL broker to select a physical hardware accelerator for accelerated execution of a requested operation may be implemented with a machine learning, or ML, model that minimizes a cost function that combines information about the network throughput and energy consumption of the underlying shared accelerated computing infrastructure.

[0020] The present invention provides an extension to the O-RAN interface to jointly allocate shared computational resources to radio processing tasks and radio resources to mobile users in a centralized manner. In particular, a new E2 endpoint may be implemented that connects the resource controller with NFs such as O-DUs to deploy radio policies on the NFs from the O-Cloud. Additionally or alternatively, a new E2 endpoint may be implemented that connects the resource controller with quasi-RT RICs to update information available there about the state of the NFs, thereby maintaining consistency across the entire O-RAN system. Finally, a new O3 interface may be implemented to deploy computational policies on the AAL brokers from the resource controller.

[0021] There are several ways to advantageously design and further develop the teaching of the present invention. For this purpose, reference is made to the following description of preferred embodiments of the present invention by way of example, which are illustrated on the one hand in the dependent claims and on the other hand by the drawings. In connection with the description of preferred embodiments of the present invention with the aid of the drawings, preferred embodiments and further developments of the present teaching are generally described. [Brief description of the drawings]

[0022] [Figure 1] FIG. 1 illustrates the decoding time of a transport block in a dedicated CPU core using Intel® FlexRAN. [Diagram 2]FIG. 1 shows an overview of latency improvement when offloading computationally intensive tasks to a hardware accelerator. [Diagram 3] FIG. 1 is a schematic diagram illustrating the general concept of an O-RAN Acceleration Abstraction Layer (AAL) according to the prior art; [Figure 4] FIG. 1 is a schematic diagram showing an O-RAN architecture according to the prior art; [Diagram 5] FIG. 1 is a schematic diagram illustrating an O-RAN Acceleration Abstraction Layer (AAL) enhanced with an AAL broker according to an embodiment of the present invention. [Figure 6] FIG. 1 is a schematic diagram illustrating an enhanced O-RAN architecture with modified E2 and O3 interfaces according to an embodiment of the present invention. [Figure 7] FIG. 2 is a schematic diagram illustrating an implementation of an AAL broker policy according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] The embodiments of the present invention are based on the Open Radio Access Network (O-RAN) and their implementation according to the O-RAN Alliance specifications. O-RAN provides a technical concept designed to improve interoperability in the RAN of mobile networks. By defining standards for open interfaces and by providing network elements abstracted from hardware, O-RAN creates a radio access network that is independent of proprietary technologies.

[0024] In this context, the Acceleration Abstraction Layer (AAL) of O-RAN provides a common interface for network functions (NFs), such as distributed units (DUs), to access hardware accelerators (HAs). This abstraction allows developers to decouple their software design from the details of the accelerators. To this end, O-RAN introduces the concept of an AAL logical processing unit (AAL-LPU) 10 as part of the O-RAN AAL 20, as shown in Figure 3. The AAL-LPU 10 is a logical representation of the HA 12 resources within a particular NF 14 (e.g., DU) running in the gNB 16. This representation supports the HA 12 providing multiple processing units, subsystems, or hard partitions of the HA 12 resources, each represented as an AAL-LPU 10. Although the HA 12 may support multiple AAL-LPUs 10, an AAL-LPU 10 is always associated with a single HA 12, as shown in Figure 3. The AAL queues 18 are then used by the NF 14 to share the AAL-LPU 10 resources. Additionally, the AAL-LPU 10 may be associated with one or more AAL profiles, which specify the functions that can be offloaded to the HA 12. This architecture is described in detail in the O-RAN Alliance, "O-RAN Acceleration Abstraction Layer General Aspects and Principles (O-RAN.WG6.AAL-GAnP-v01.01)," Technical Specification, July 2021, which is incorporated herein by reference.

[0025] 4 shows a high-level view of the O-RAN architecture, where for simplicity, only the O-DU network node 22 is shown. As shown, the O-RAN architecture consists of network functions (e.g., O-DU 22), a Service Management and Orchestration Framework (SMO) 24 for managing the network functions, and an O-Cloud 26 (O-RAN Cloud) for hosting cloudified network functions. The SMO 24 includes a non-real-time (non-RT) RAN Intelligent Controller (RIC) 28 as a central component, enabling non-real-time control and optimization of RAN elements and resources.

[0026] The DU 22 is controlled by the Near Real Time (Near RT) RIC 30 through the E2 interface 32. Common 3GPP Radio Resource Management (RRM) operations, for example, are performed through this interface. Conversely, the O2 interface 34 is used to provide two services: infrastructure management services (deployment and management of the O-Cloud 26 infrastructure) and deployment management services (lifecycle management of virtualization deployments on the O-Cloud 26 infrastructure).

[0027] The main problem with this approach is that it cannot implement load balancing efficiently, since the NF 14 may greedily select a HA 12, e.g., in a platform with heterogeneous acceleration resources, the NF 14 may overload the fastest HA 12, resulting in poor overall performance.

[0028] Thus, despite providing a suitable abstraction, the O-RAN AAL20 alone does not support centralized coordination of acceleration resources (see FIG. 3) and is therefore unable to efficiently mediate access to the shared infrastructure, nor is it able to impose radio scheduling policies on associated DUs 22 (see FIG. 4). On the contrary, according to embodiments of the present invention, it is recognized that centralized control of computational and radio resources is essential to build a resource-efficient vRAN.

[0029] To address the above problems, an embodiment of the present invention provides an upper layer abstraction implemented on top of AAL20 of O-RAN. According to an embodiment of the present invention, this abstraction includes one or more Virtual Operations (VOs) associated with every vRAN node that forward requests for specific functions. There is one VO for each acceleration function, e.g., FEC (Forward Error Correction), FFT (Fast Fourier Transform), CRC (Cyclic Redundancy Check). The request may include information about the operation and data required to perform the operation (e.g., code blocks in case of FEC decode operation). Additionally, the request may include settings for performing the operation (e.g., maximum number of decoding iterations in case of FEC decode operation).

[0030] Moreover, according to one embodiment of the present invention, and as shown in FIG. 5, where like reference numbers indicate like components / functions as in FIG. 3 and FIG. 4, the higher layer abstraction implemented on top of the AAL 20 of the O-RAN may comprise an AAL Broker 36 configured to coordinate all radio task requests to a pool of HAs 12 based on the O-Cloud (O-RAN).

[0031] More specifically, according to an embodiment, the AAL broker 36 may be configured to receive a request from a vRAN node 38 (e.g., a request to LDPC (Low Density Parity Check) decode a transport block from a DU 22). The AAL broker 36 may then allocate the request to a processing queue 18 of a most appropriate AAL device 10 according to a scheduling policy. After execution of the requested task by each HA 12, the AAL broker 36 may receive a response (i.e., execution result) from the corresponding AAL device 10 and may forward the response to the issuing vRAN node 38 (e.g., the decoded transport block to the DU 22).

[0032] As shown in FIG. 5, according to one embodiment of the present invention, the AAL broker 36 may be implemented and configured to interact with the O-RAN AAL20 interface as if it were a single vRAN node 38.

[0033] 6, according to one embodiment of the present invention, the system for coordinating allocation of radio processing operations may further comprise a resource controller 40 that may interact / communicate with the AAL broker 36. More specifically, the resource controller 40 may be to configure the AAL broker 36 (near real-time operation) via a novel O3 interface 42. For example, via the O3 interface 42, the resource controller 40 may deploy computational policies on the AAL broker 36.

[0034] Additionally, the resource controller 40 may be connected to vRAN nodes 38, such as the O-DU 22, via a novel E2 interface 44 to configure radio resource policies on these nodes (quasi-real-time operation). Still further, the resource controller 40 may be connected to the quasi-RT RIC 30 via a novel E2 interface 46. In particular, the interface 46 may be used by the resource controller 40 to notify the quasi-RT RIC 30 of changes in radio policies configured on the vRAN nodes 38 (e.g., the O-DU 22).

[0035] According to one embodiment of the present invention, the scheduling policy 37 applied by the AAL broker 36 may be implemented with a machine learning (ML) model, optimization model or heuristic that maps the system state (in particular the current occupancy of the processing queues 18 in each AAL device 10), the type of request (virtual operation), and information about the incoming request (e.g., transport block size or signal-to-noise ratio) to the AAL LPU 10 that minimizes a cost function. This is shown diagrammatically in FIG. 7.

[0036] According to one embodiment of the present invention, the scheduling policy 37 may be adapted to minimize a cost function that combines information about the networking throughput and energy consumption of the underlying infrastructure, for example as follows:

[0037]

number

[0038] In the above formula, x t is the joint radio / compute scheduling decision made for request t, and c t is the context associated with request t (e.g., transport block size, SNR, etc.), and s t (c t ,x t)∈{0,1} is the constrained (s t (c t ,x t )=0) or unconstrained (s t (c t ,x t ) = 1) indicates whether request t was serviced by the accelerator within a predefined time, and p t (c t ,x t ) in context c t and Decision x t Denote the energy consumed to service a demand t given

[0039] The radio scheduling policy 37 may be imposed on a vRAN node 38, such as an O-DU 22, by using a novel E2 interface 44 (via a resource controller 40).

[0040] It is important to note that the energy required to process a task request varies across accelerators, as does the latency to service the request. For example, the energy consumed by a dedicated CPU to perform LDPC decoding (FEC) is an order of magnitude lower than that of a GPU-based implementation, but the latency is still an order of magnitude higher. This information can be calibrated a priori or learned by machine learning techniques.

[0041] In one embodiment, the present invention provides a method for coordinating allocation of radio processing operations associated with multiple vRAN nodes to shared computational resources, the method including using an AAL broker 36 to coordinate allocation of common and shared computational resources to radio processing tasks associated with multiple vRAN nodes 38 (e.g., vDUs 22) in a centralized manner.

[0042] According to an embodiment, the method may include one or more of the following steps: 1) A network function (NF) requests an operation (e.g., FEC decoding) to the AAL broker 36. The request may include information about the operation, data needed to perform the operation (e.g., code blocks in the case of an FEC decoding operation), and settings for performing the operation (e.g., maximum number of decoding iterations in the case of an FEC decoding operation). 2) The AAL broker 36 uses a policy to forward the operation request to a queue 18 of a physical hardware accelerator 12 (eg, a GPU, FPGA, ASIC, or a pool of CPUs dedicated to this operation). 3) The hardware accelerator 12 (e.g., a GPU, FPGA, ASIC, or a pool of CPUs dedicated to this operation) performs the predefined operation in a FIFO manner for every request in its associated queue 18. Upon completion, a response (e.g., decoded bits in case of an FEC decoding operation) is sent back to the AAL broker 36, which forwards the response to the corresponding vRAN node 38.

[0043] Many modifications and other embodiments of the inventions described herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the invention is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included in the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. [Explanation of symbols]

[0044] 10 AAL Logical Processing Unit (AAL-LPU), AAL device 12 HA, Hardware Accelerator 14 NF 16 gNB 18 AAL Queue, Processing Queue, Queue 20 O-RAN AAL 22 O-DU network node, O-DU, DU, vDU 24 Service Management and Orchestration Framework (SMO) 26 O-Cloud (O-RAN Cloud) 28 Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) 30 Near-real-time (Near-RT) RIC 32 E2 Interface 34 O2 Interface 36 AAL Broker 37 Scheduling Policy, Radio Scheduling Policy 38 vRAN nodes 40 Resource Controller 42 O3 Interface 44 E2 Interface 46 E2 interface, interface

Claims

1. 1. A method for aligning allocation of radio processing operations associated with a plurality of vRAN nodes (38) to a shared computational resource, comprising: receiving, by a centralized acceleration abstraction layer, or AAL, broker (36) implemented on top of a shared accelerated computing infrastructure, an operation request for a virtual operation associated with a vRAN node (38), the operation request specifying an operation to be accelerated; selecting a physical hardware accelerator (12) for accelerated execution of the requested operation using a predefined or configurable scheduling policy (37) by said AAL broker (36); and forwarding, by the AAL broker, the operation request to a processing queue of the selected hardware accelerator.

2. 2. The method of claim 1, wherein the AAL broker (36) interacts with the underlying shared accelerated computing infrastructure as if it were an individual vRAN node (38).

3. The method of claim 1 or 2, wherein the operation request includes information about the operation to be accelerated, data required to perform the operation, and settings for performing the operation.

4. 4. The method of claim 1, further comprising: performing, by the selected hardware accelerator (12), the requested operation in a FIFO manner that takes into account the request in a processing queue (18) associated therewith.

5. receiving, by the AAL broker (36), a response from the selected hardware accelerator (12) in response to forwarding the operation request to the processing queue (18) of the selected hardware accelerator (12); and forwarding, by the AAL broker (36), the response received from the selected hardware accelerator (12) to the vRAN node (38).

6. The method of any of claims 1 to 5, wherein the scheduling policy (37) used by the AAL broker (36) to select a physical hardware accelerator (12) for accelerated execution of the requested operation is implemented with a machine learning, or ML, model that minimizes a cost function that combines information about network throughput and energy consumption of an underlying shared accelerated computing infrastructure.

7. The method of any of claims 1 to 6, further comprising using a resource controller (40) to configure the AAL broker (36) by deploying a computation policy via an O3 interface (42).

8. 8. The method of any of claims 1 to 7, further comprising using the resource controller (40) to configure a radio resource policy for the vRAN node (38) via an E2 interface (44) and / or to notify the quasi-RT RIC (30) via an E2 interface (46) of changes in the radio resource policy configured on the vRAN node (38).

9. A system for aligning allocation of radio processing operations associated with a plurality of vRAN nodes (38) to a shared computational resource, in particular for the execution of a method according to any of claims 1 to 8, said system comprising a centralized Acceleration Abstraction Layer, or AAL, Broker (36) implemented on top of a shared accelerated computing infrastructure, said AAL Broker (36) comprising: receiving an operation request for a virtual operation associated with a vRAN node (38), the operation request specifying the operation to be accelerated; selecting a physical hardware accelerator (12) for accelerated execution of the requested operation by using a predefined or configurable scheduling policy; and forwarding the operation request to a processing queue (18) of the selected hardware accelerator (12).

10. The system of claim 9, wherein the AAL broker (36) is configured to interact with an underlying O-RAN AAL infrastructure (20).

11. The AAL broker (36) receiving a response from the selected hardware accelerator in response to forwarding the operation request to the processing queue of the selected hardware accelerator; and forwarding the response received from the selected hardware accelerator (12) to the vRAN node (38).

12. The system of any of claims 9 to 11, wherein the AAL broker (36) is further configured to perform the selection of a physical hardware accelerator (12) for accelerated execution of the requested operation using a machine learning, or ML, model that minimizes a cost function that combines information about network throughput and energy consumption of an underlying shared accelerated computing infrastructure.

13. 13. The system of claim 9, further comprising a resource controller (40) configured to configure the AAL broker (36) via an O3 interface (42).

14. 14. The system of claim 9, wherein the resource controller (40) is further configured to configure a radio resource policy for the vRAN node (38) via an E2 interface (44).

15. The system of any of claims 9 to 14, wherein the resource controller (40) is further configured to notify the quasi-RT RIC (30) of changes in radio resource policies configured on the vRAN node (38) via an E2 interface (46).

Images