EP4555414A1

EP4555414A1 - Method and system for brokering heterogeneous fec accelerators in an o-ran platform

Info

Publication number: EP4555414A1
Application number: EP23753804.6A
Authority: EP
Inventors: Jose Ayala Romero; Andres GARCIA-SAAVEDRA; Xavier COSTA-PÉREZ
Original assignee: NEC Laboratories Europe GmbH
Current assignee: NEC Laboratories Europe GmbH
Priority date: 2023-01-31
Filing date: 2023-07-24
Publication date: 2025-05-21
Also published as: WO2024160386A1

Abstract

The present invention provides a method of brokering heterogeneous signal processing resources of an O-RAN cloud platform (210), the signal processing resources including one or more general-purpose CPUs (206) for performing software processing and at least one hardware accelerator, HA (208). According to an embodiment, the method comprises: computing, by a controller (309) in near-real-time, a Logical Processing Unit, LPU, policy, the LPU policy including rules to be applied by the O-RAN Distributed Units, DUs (302), sharing the O-RAN cloud platform (210) on every encoded Transport Block, TB, to decide whether to process the TB in software or to offload the TB to a HA (208) of the O-RAN cloud platform (210); deploying the computed LPU policy into the O-RAN DUs (302) sharing the O-RAN cloud platform (210); and executing, by each of the O-RAN DUs (302) sharing the O-RAN cloud platform (210), the deployed policy in real-time for every encoded TB that needs to be processed.

Description

METHOD AND SYSTEM FOR BROKERING HETEROGENEOUS FEC ACCELERATORS IN AN O-RAN PLATFORM

The project leading to this application has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101017109.

The present invention relates to a method of brokering heterogeneous signal processing resources of an O-RAN cloud platform, the signal processing resources including one or more general-purpose CPUs for performing software processing and at least one hardware accelerator, HA.

The virtualization of network functions in cellular systems has become a key strategy among mobile operators to reduce infrastructure costs. Virtualization enables the use of commodity computing infrastructure, resource multiplexing, and flexibility to adapt to changes and system upgrades.

Despite the advances made during the last decade, the radio access domain, comprised of cellular base stations, is the last frontier to be virtualized. Led by the Open RAN (O-RAN) Alliance - a world-wide community of over 300 manufacturers, operators, and field researchers - practically all the players in the industry are building virtualized radio access networks (vRANs). Indeed, business analysts project that open and virtualized RANs will lead the market by 2028.

A key network function (NF) of a 5G RAN is the distributed unit (DU) of every base station, which processes physical layer (PHY) tasks such as forward error correction (FEC). In contrast to more conventional network functions, such as network switches or firewalls, DUs must process wireless signals with stringent latency constraints. Violating processing deadlines may result in users losing wireless synchronization with the base station, which leads to dropped connectivity. Hence, the industry has established that such deadlines, which span between 1 and 3 milliseconds, must be met with 99.9999 % probability (reliability). However, to process wireless signals, a DU has to execute compute-intensive operations such as decoding forward error correction (FEC) codes, and conventional virtualization platforms based on general-purpose CPUs cannot provide the required reliability.

Consequently, the industry today relies on hardware accelerators (HAs) to offload the most intensive FEC processing operations. HAs are GPUs, FPGAs, or ASICs that are specialized in specific operations (FEC, in the case of vRANs) and help attain industry-grade reliability. Fig. 1 (top) shows that a HA can process large chunks of data (called transport blocks) a magnitude order faster than processing this data via software (with a CPU).

However, HAs are expensive - between 5 and 50 times more expensive than a CPU core (e.g., an NVIDIA GPU V100 required to accelerate FEC operations costs around $10K, in contrast to $150 of an Intel Xeon CPU core). Furthermore, HAs consume a lot of energy - between 30 and 80% of the overall consumption in a commodity server (e.g., an NVIDIA GPU V100 consumes up to 250 Watt). Both aspects question the viability of this approach, since it increases the network cost and has serious environmental implications.

In view of the above, there may be a desire for providing an improved concept for using signal processing resources of an O-RAN cloud platform with minimized energy consumption while meeting PHY processing deadlines with high probability to attain industry-level granularity. There may also be a desire to achieve the above- mentioned objectives in a legacy O-RAN platform.

This desire is addressed by the subject-matter of the independent claims.

In accordance with the present disclosure, the aforementioned desire is addressed by a method of brokering heterogeneous signal processing resources of an O-RAN cloud platform, the signal processing resources including one or more general- purpose CPUs for performing software processing and at least one hardware accelerator, HA. The method comprises computing, by a controller in near-real-time, a Logical Processing Unit, LPU, policy, the LPU policy including rules to be applied by the O-RAN Distributed Units, DUs, sharing the O-RAN cloud platform on every encoded Transport Block, TB, to decide whether to process the TB in software or to offload the TB to a HA of the O-RAN cloud platform; deploying the computed LPU policy into the O-RAN Dlls sharing the O-RAN cloud platform; and executing, by each of the O-RAN Dlls sharing the O-RAN cloud platform, the deployed policy in real-time for every encoded TB that needs to be processed.

In accordance with embodiments of the present disclosure, it has been recognized that a natural approach to reducing the energy toll of HAs is to offload only what is strictly necessary. Fig. 1 shows that small and medium-sized transport blocks can be decoded in software within common deadlines (1 -3ms), thereby consuming an order of magnitude less energy as compared to HAs. Hence, a better approach is to devise policies that minimize offloading (and so energy consumption) while preserving reliability (meeting deadlines with 99.999% probability). As such, the present disclosure provides a method and system to coordinate heterogeneous hardware accelerators using O-RAN legacy interfaces in an energy-efficient manner. According to embodiments, a light controller, deployed, e.g., in the acceleration abstraction layer (AAL) of O-RAN, assigns MAC layer transport blocks (TBs) to a hardware accelerator (HA) in a pool of HAs, for instance based on the bitsize of the TB (policy). The Near-Real-Time (Near-RT) RAN Intelligent Controller (RIC) of O-RAN may adapt the LPU policy in near real-time timescales based on contextual information.

Embodiments of the present disclosure achieve the advantage that offloading is performed in such a way that the amount of MAC-layer transport blocks processed by a Hardware Accelerator is minimized, while still meeting the required performance targets. By relieving the hardware accelerator(s), energy consumption is significantly reduced. Embodiments of the present disclosure have the further advantage that the proposed concepts do not require any amendments of the 0- RAN architecture, i.e. embodiments of the methods and systems disclosed herein can be implemented in legacy O-RAN platforms without requiring any additional building blocks that are not specified by O-RAN.

According to an embodiment, the LPU policy may comprise a configured threshold TB size such that TBs having a size larger than the configured threshold are offloaded into a HA, while TBs having a size smaller than or equal to the configured threshold are processed in software. Alternatively or additionally, the LPU policy may comprise a configured threshold with respect to an expected software processing time of the TBs, wherein TBs that have an expected software processing time higher than the configured threshold are offloaded into a HA, while TBs that have an expected software processing time smaller than or equal to the configured threshold are processed in software. In this case, prior to computing the LPU policy, the expected software processing time of a TB may be predicted by a respective 0- RAN DU, e.g. by means of applying regression models, neural network models, or the like.

According to an embodiment, the controller may be configured to compute the LPU policy based on contextual information derived from TBs arrived previously, i.e. in previous transmission time interval, TTIs. In this context, it may be provided that the contextual information includes O-RAN load information in terms of the signal-to- noise ratio, SNR, the modulation and coding scheme, MCS, and the size of TBs processed within a past time window.

According to an embodiment, it may be provided that each O-RAN DU has associated its own controller that computes an O-RAN DU specific LPU policy as a function of the O-RAN DU’s load. Alternatively and considering the fact that a policy implemented in one O-RAN DU affects all other O-RAN DUs that share the same O-Cloud, a multi LPU policy controller may be implemented with one LPU policy controller per O-RAN DU. This allows each O-RAN DU to deploy a different policy, for instance as a function of its current load.

According to an embodiment, the LPU policy controller may use actor-critic methods to compute the LPU policy. Specifically, a critic of the controller may be configured to approximate a cost function, which is used to train the actor to compute the LPU policy. Both, the actor and the critic may be configured to comprise a combination of a 3D convolutional neural network and a feed-forward neural network. The output of the actor’s feed-forward neural network may serve as input to the critic’s feedforward neural network. According to an embodiment, the controller may be implemented inside the 0- RAN’s Near-RT RIC. Specifically, the Near-RT RIC may host the controller as an xAPP.

According to an embodiment, the controller may be configured to deploy the computed LPU policy into the 0-RAN Dlls that share the 0-RAN cloud platform via the 0-RAN E2 interface.

Embodiments of the present disclosure propose a strategy to use opportunistically the HA, with the objective of saving energy while meeting the reliability target. To maximize its efficiency, this opportunistic offloading strategy needs to be configured in real time to adapt to different traffic conditions. In particular, one needs to configure the offloading strategy of every Base Station (BS) sharing the common computational resources, which renders a collaborative multi-agent problem. According to embodiments, the problem is formulated as multi-agent contextual bandit. This problem may be solved by a learning algorithm that applies concepts from mean field theory to make the solution fully scalable and to be able to operate in settings with a changing number of learning agents.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the dependent claims on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will be explained. In the drawing

Fig. 1 is a diagram showing a performance comparison between a GPU (hardware accelerator) and a CPU (software) to perform FEC over Transport Blocks of different sizes and SNRs,

Fig. 2 is a schematic view illustrating the basic 5G system architecture according to prior art, Fig. 3 is a schematic view illustrating an O-RAN architecture according to prior art,

Fig. 4 is a schematic view illustrating the general concept of an O-RAN Acceleration Abstraction Layer (AAL) according to prior art,

Fig. 5 is a schematic view illustrating an O-RAN architecture according to an embodiment of the present invention,

Fig. 6 is a schematic view illustrating operation of an LPU policy controller according to an embodiment of the present invention,

Fig. 7 is a schematic view illustrating operation of multi LPU policy controllers according to an embodiment of the present invention, and

Fig. 8 is a schematic view illustrating a setup of an LPU policy controller according to an embodiment of the present invention.

Throughout the figures, like reference numbers denote like components/functions.

Motivated by an ever-increasing network traffic in mobile networks, operators need to devise cost-efficient technologies to accommodate users’ demands. One popular strategy is Radio Access Network (RAN) densification, which deploys a large number of smaller Base Stations (BS) per square meter so radio spectrum can be used more effectively. However, this comes at a cost in terms of network equipment. Hence, driven by the Open RAN (O-RAN) Alliance (for reference, see Andres Garcia-Saavedra and Xavier Costa-Perez: “O-RAN: Disrupting theVirtualized RAN Ecosystem”, in IEEE Communications Standards Magazine 5, 4 (2021 ), 96-103, https://doi.org/10.1109/MCOMSTD.101.2000014), RAN virtualization (vRAN) has gained the attention of manufacturers and operators to shift from hardwired BSs to inexpensive general-purpose platforms.

Despite the rapid success of dense vRANs, the industry today is concerned about the energy consumption of such systems. Indeed, even before the latest surge in energy prices, the energy-related expenditures in mobile networks are one of the predominant factors of their costs. Generally, vRAN solutions on the market today are not well-suited to achieving companies’ targets in terms of reducing energy consumption and energy related emissions.

In contrast to more conventional network functions such as network switches or firewalls, RAN functions have stringent latency constraints to process wireless signals. Violating processing deadlines, which span between 1 and 3 ms depending on the scenario, may result in users losing wireless synchronization with the BS, which leads to dropping connectivity. Hence, an industry-grade BS must respect such deadlines with 99.999% probability to provide reliability (see Xenofon Foukas and Bozidar Radunovic: “Concordia: Teaching the 5G VRAN to Share Compute”, in Proceedings of the 2021 ACM SIGCOMM 2021 Conference (Virtual Event, USA), https://doi.Org/10.1145/3452296.3472894). However, to process wireless signals, a BS has to execute compute-intensive operations such as decoding forward error correction (FEC) codes, which prevents conventional virtualization platforms based on general-purpose CPUs from attaining the required reliability.

Consequently, the industry today relies on hardware accelerators (HAs) to offload the most intensive FEC processing operations. HAs are GPUs (Graphics Processing Units), FPGAs (Field Programmable Gate Arrays), or ASICs (Application-Specific Integrated Circuits) that are specialized in specific operations (FEC, in the case of vRANs) and help attain industry-grade reliability. Fig. 1 (top) shows that a HA (a GPU in this case) can process large chunks of data (called transport blocks, TB) a magnitude order faster than processing this data via software. Unfortunately, HAs are expensive (between 5 and 50 times more expensive than a CPU core), and consume a lot of energy (between 30 and 80% of the overall consumption in a commodity server).

A natural approach to reduce the energy toll of these systems is to use HAs opportunistically, only when is strictly necessary, and rely upon energy-friendly software processing when possible. Fig. 1 shows that small and medium-sized transport blocks (mostly briefly denoted TB herein, wherein a TB is the basic MAC- layer user data unit in a BS, with variable amount of bits) can be decoded in software within common deadlines (1 -3 ms) with an order of magnitude less energy than a HA. However, to design a policy that determines when to use a HA, at least three challenges emerge:

(1 ) Complexity: Balancing the workload between software (CPUs) and hardware (HAs) while preserving reliability is particularly challenging. This is because the time required to process wireless signals is hard to predict using tractable models since it depends not only on the size of the transport block, as depicted in Fig. 1 , but also on many other features such as the signal-to-noise ratio (SNR) and the modulation and coding scheme (MCS) of the signals to process. The error bars in Fig. 1 hide away the impact of these additional features, which must be taken into account to attain industry-grade reliability.

(2) Speed: Base stations must adapt their configuration to the changing dynamics of the environment, but wireless conditions change very fast (~ 1 ms) in real mobile networks due to high mobility of users and reflectors in the environment. Therefore, a useful policy must operate very fast.

(3) Scalability: Every transmission time interval (TTI < 1 ms), a large number of signals from multiple users and multiple cells have to be processed by the vRAN (e.g., NTT Docomo famously centralize up to 48 cells in a single platform), and each cell may handle dozens of users concurrently. Hence, for a policy to be useful in practice, it must reliably operate at scale.

To address these challenges, embodiments of the present disclosure provide an energy-aware learning strategy for computing offloading in vRANs. According to an embodiment, this strategy consists in (i) a simple and fast threshold-based offloading rule to operate in real-time or quasi real-time (preferably < 1 ms), and (ii) an algorithm that learns how to optimally configure the offloading rule for each BS in near-real-time (~ 100 ms). The algorithm may be implemented as a multi-agent contextual bandit algorithm.

In this context, one faces the problem that multiple BS agent need to collaborate to find the optimal configuration of their offloading rule to maximize the global system performance. This problem can be formulated as a contextual bandit problem. However, as all the BSs share the same computing resources, the offloading strategy of each BS affects all the others, and therefore the problem that is to be tackled is a multi-agent contextual bandit. As mentioned before, the number of involved BS can be arbitrarily large and so the learning agents, which increases the computational complexity of the solution. To address this problem, embodiments of the present disclosure propose a multi-agent learning algorithm that relies on an actor-critic architecture and uses concepts from mean field theory to make it fully scalable. Importantly, a multi-agent learning algorithm is built to be standard- compliant so the solution can be actually helpful in the industry. To this end, each agent may be hosted by an O-RAN xApp in a near-real-time RAN intelligent controller (Near-RT RIC), as defined by the O-RAN Alliance (for reference, see A. Garcia-Saavedra and X. Costa-Perez: “O-RAN: Disrupting the Virtualized RAN Ecosystem”, in IEEE Communications Standards Magazine 5, 4 (2021 ), 96-103. https://doi.Org/10.1109/MCOMSTD.101 .2000014).

Generally, in 5G systems, Base Stations (BSs) exchange modulated radio signals with user equipment (UE) such as smartphones to transfer data wirelessly. To this end, the system follows a set of protocols specified by a New Radio (NR) interface, which are summarized next.

Every transmission time interval (TTI), a variable amount of data bits is bundled into a transport block (TB) for every active UE at the time. The duration of a TTI ranges between 125 ps and 1 ms, depending on the configuration of the BS. The size of each TB (bits) depends on a number of factors, such as the BS’s scheduler that multiplex radio resources among UEs, the modulation and coding scheme (MCS) and the wireless link’s signal-to-noise-ratio (SNR) that determines the number of bits per radio resource, and the amount of data buffered by the users ready to be transferred.

Fig. 2 schematically illustrates a BS 202 receiving data from three mobile users 204. At the top of Fig. 2, each transmission time interval (TTI) is represented in a horizontal line. The elementary data unit is the transport block (TB). The size of the TB and the associated radio resources are decided by the BS’s 202 scheduling algorithm. At the transmitter side, each TB is converted into radio signals by executing a set of operations such as modulation or rate matching. The process is reversed at the receiver side to extract data from radio signals. Among these operations, a focus can be put on forward error correction (FEC) because it is by far the most compute-intensive task and is usually offloaded into a hardware accelerator (HA) for fast execution. Briefly, FEC-decoding a TB implies executing an iterative belief propagation algorithm. The amount of iterations required (and so the number of computing operations) depends on a number of factors such as the TB size, its MCS, the link’s SNR, or the demodulation algorithm used (as described in detail in Y. Blankenship, D. Hui, and M. Andersson: “Channel Coding in NR”, in Springer International Publishing, Cham, 303-332, 2021 , https://doi.Org/10.1007/978-3-030-58197-8_10).

Embodiments of the present invention are based on open Radio Access Networks (O-RAN). O-RAN provides a technical concept designed to improve interoperability in the RANs of mobile networks. By defining standards for open interfaces and by providing network elements abstracted from hardware, O-RAN creates radio access networks that are independent of proprietary technology.

The novel O-RAN architecture for next-generation mobile systems defines a computing platform known as O-Cloud 210 to offload signal processing workload from virtualized BSs. An O-Cloud 210 provides signal processors comprised of software processing devices 206 (e.g., general-purpose CPUs) and HAs 208 such as FPGAs, GPUs or ASICs. Each processor queues FEC processing requests in a first-in-first-out (FIFO) queue and, once processed, the resulting TB data is sent back to the associated BS 202 (see Fig. 2).

Fig. 3 illustrates a high-level view of the O-RAN architecture, wherein only an O-DU (O-RAN Distributed Node) network node 302 is shown for simplicity. As shown, the O-RAN architecture consists of the network functions (e.g. O-DUs 302) controlled by the Near-Real-Time (Near-RT) RAN Intelligent Controller (RIC) 308 through E2 interface 310, a Service Management and Orchestration framework (SMO) 304 to manage the network functions and the O-Cloud 210 (O-RAN Cloud) to host the cloudified network functions. SMO 304 includes the Non-Real-Time (NON-RT) RAN Intelligent Controller (RIC) 306 as a central component, enabling non-real-time control and optimization of RAN elements and resources.

As shown in Fig. 3, in O-RAN, BSs (i.e. O-Dlls 302, to be more specific) are controlled by a near-real-time RAN intelligent controller (Near-RT RIC) 308 using applications. These applications are known as xApps and operate in the timescale of ~ 10 - 100 ms (i.e., 10 or 100 times longer than a TTI). In the context of the present disclosure, a data-driven policy is deployed in a Near-RT RIC 308 and E2 interface 310 is used to control the offloading strategy of BSs 202 deployed over a prototype O-Cloud 210 platform. Common 3GPP Radio Resource Management (RRM) operations, for instance, are performed through this interface. Conversely, 02 interface 312 is used to provide two services: infrastructure management services (deployment and management of O-Cloud 210 infrastructure), and deployment management services (lifecycle management of virtualized deployments on O-Cloud 210 infrastructure).

In this context, O-RAN’s Acceleration Abstraction Layer (AAL) 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 designs from the specifics of the accelerators. To this end, as shown in Fig. 4, O-RAN introduces the concept of AAL Logical Processing Unit (AAL-LPU) 404 as part of the O-RAN AAL 402. An AAL-LPU 404 is a logical representation of the HA 208 resources within a specific NF 408 (e.g., a DU) running in a gNB 406. This representation supports HAs 208 that provide multiple processing units, subsystems, or hard partitions of the HA 208 resources, each represented as an AAL-LPU 404. Although a HA 208 may support multiple AAL-LPUs 404, an AAL- LPU 404 is always associated to a single HA 208, as depicted in Fig. 4. Then, AAL Queues 410 are used by NFs 408 to share AAL-LPU 404 resources. In addition, an AAL-LPU 404 may be associated with one or multiple AAL Profiles, which specify the functions that can be offloaded to a HA 208. This architecture is described in detail in O-RAN Alliance, “O-RAN Acceleration Abstraction Layer General Aspects and Principles (O-RAN. WG6.AAL-GAnP-vO1.01 )”, Technical Specification, July 2021 , which is hereby incorporated by reference herein. Modifications to the architecture of 0-RAN as described above have been proposed to implement policies for controlling computing and radio resources in real-time. According to prior art, one of these modifications includes a higher-layer abstraction implemented on top of O-RAN’s AAL 402.

In contrast, embodiments of the present disclosure aim at minimizing energy consumption while meeting PHY processing deadlines with high probability to attain industry-level granularity and using a legacy O-RAN platform.

According to embodiments, the present disclosure provides a method to deploy LPU policies into individual O-Dlls 302, as exemplarily depicted in Fig. 5. The policy enables the respective 0-Dll 302 to decide whether to offload a MAC TB into a HA 208 or process it in a software processing device 206 (represented as x86 in Fig. 5) to save energy.

In an embodiment, a policy corresponds to a threshold TB size. TBs larger than the configured threshold are offloaded into a HA 208. TBs smaller or equal than the configured threshold are processed in software (CPU) 206. This embodiment is based on the fact that a key structural difference can be observed between software and HA processing. The processing time of a CPU is highly dependent on the bitsize of the TB, while such dependency practically vanishes for the case of a HA based on a GPU. This structure holds even across different implementations of software decoder. A similar behavior can be observed for energy consumption as it is proportional to the % of the time that a processor is busy. Based on these observations, an intuitive strategy is a solution where the TBs with small bit size are processed in software (not offloaded). This maximizes the number of processed TB per second in the CPU and avoids its early saturation. Conversely, the TBs with large bit size are offloaded, as the processing time of the HA is not sensible to the bit size of the TB. Thus, one can define a threshold TB size l_th as the TB size that delimits two operational regions: When Z_£ < l_th (wherein Z_£ denotes the TB size of a TB di), TB di is processed in software, otherwise the HA is used.

In another embodiment, a policy corresponds to a threshold in an expected software processing time of a TB. To this end, the DU 302 shall first predict the software processing time of the TB. This can be done, e.g., via regression models, neural network models, etc. Then, it may be provided that TBs that require a software processing time higher than the configured threshold shall be offloaded into a HA 208. TBs that require a software processing time smaller or equal than the configured threshold shall be processed in software 206.

Such threshold-based policies enable timely processing of TBs, which can operate in real-time without extra processing burden. A remaining challenge is to adapt the policy (e.g., to configure a threshold in the aforementioned policies) to preserve reliability while minimizing the amount of HA offloading to reduce energy consumption. In this context, according to an embodiment, the present disclosure proposes the deployment of an LPU policy controller 309 that is configured to adapt the deployed LPU policies in near-real-time (e.g., every 100 milliseconds).

Accordingly, an xApp - which typically operate in the timescale of ~ 10 - 100 ms (i.e. , 10 or 100 times longer than a TTI - can be built inside the Near-RT RIC 308 of O-RAN to this end, and E2 interface 310 can be used to deploy the LPU policies into O-DUs 302. One important challenge to design the LPU policy controller 309 is to provide optimal operation in highly dynamic systems, with highly heterogeneous DUs 302 and users. This is because the processing time of a TB depends on its size, but also on its SNR and the modulation and coding scheme used. Another important challenge is to provide scalability, since a large number of users and/or DUs 302 may be active in the system every 100 milliseconds.

According to an embodiment of the present disclosure, the LPU policy controller 309 may be configured to compute a policy based on the context of the system. Again, as described in connection with the embodiments above, this LPU offloading policy may be computed in a timescale of 100 ms. In this context and as shown in Fig. 6, the load of the system may be represented as a 3-dimensional histogram of the TBs processed within a past time window, wherein a time window may correspond to a TTI. The dimensions considered may include the signal-to-noise ratio (SNR), the modulation and coding scheme (MCS) and the TB size (TBS). The output of the LPU policy controller 309 is the corresponding policy, e.g., a threshold TB size or threshold in the expected software processing time of the TB. In this embodiment, it may be considered that the 3-dimensional histogram captures the context of all the O-DUs 302 of the respective system and, in consequence, the computed policy may also be deployed into all the O-DUs 302.

According to another embodiment, illustrated in Fig. 7, it may be provided that one LPU policy controller 309 is implemented per O-DU 302, allowing each O-DU 302 to deploy a different policy, e.g., as a function of its load. It is noted that in this case, as all the O-DUs 302 share the same O-Cloud 210, the policy deployed in each O- DU 302 affects all the others, rendering a multi-agent problem. Accordingly, and as shown in Fig. 7, the input of the LPU policy controller 309i associated with O-DU i may comprise two histograms: i) the histogram i that characterizes the load of O- DU i; ii) and the histogram -i that characterizes the load of all the O-DUs 302 except the O-DU i. Thus, the computed policy of each LPU policy controller 309 is deployed in its associated O-DU 302.

Fig. 8 schematically illustrates an architecture of a LPU policy controller 309 according to an embodiment of the present disclosure. The LPU policy controller 309 may receive as input the system load, e.g., in form of one or more histograms as explained above in connection with Figs. 6 and 7.

According to this embodiment, the LPU policy controller 309 comprises two entities: an actor 802 and a critic 804. The actor 802 is configured to compute the policy and the critic 804 approximates a cost function and is used to train the actor 802. The cost function may be designed to combine the power consumption of the system and its reliability. Thus, the actor 802 is trained to select a policy that minimizes the cost. As shown in Fig. 8, both actor 802 and critic 804 may be implemented in form of a combination of 3D convolutional neural networks (as the inputs are 3D matrices) and feed-forward neural networks. In this architecture, the output of the feed-forward neural network of the actor 802 is used as input to the feed-forward neural network of the critic 804.

In summary, the present disclosure provides methods and systems that aim at achieving benefits in energy consumption (while still meeting PHY processing deadlines with high probability to attain industry-level granularity) without requiring a modified O-RAN platform, using O-RAN legacy interfaces. More specifically, the present disclosure provides methods and systems configured to offload (or not) MAC-layer transport blocks into hardware accelerators based on simple policies that use O-RAN legacy interfaces only, by implementing one or more of the following steps/components:

1) An LPU policy controller (e.g., deployed as an xApp in the Near-RT RIC computes an LPU policy for each O-RAN DU (O-DU) sharing the O-Cloud platform, for instance every 100 milliseconds, or even in the timescale of - 10 - 100 ms (i.e. in near-real-time, but of course significantly slower than the TTI timescale (1 ms)):

- An LPU policy may be a rule that every O-DU shall apply on every encoded TBs to decide whether to process the TB in software (CPU) or offload it into a hardware accelerator.

- The LPU policy controller/x4 may compute the policy based on contextual information. Contextual information may consist of a 3-dimensional histogram of data associated to prior arrived TBs (e.g., SNR, MCS and bitsize).

- A policy may be threshold-based, where DUs compute the expected processing time of every encoded TB and assigns a Logical Processing Unit (LPU) accordingly. Another threshold-based policy may be based only on the bit-size of the TB, which does not require computing any expectation.

2) Once a policy for an O-DU is calculated, the LPU policy controller may deploy the policy into the corresponding O-DU using O-RAN E2 interface.

3) Each O-DU executes the deployed policy in real-time for every encoded MAC- layer transport block that needs to be processed.

Many modifications and other embodiments of the invention set forth herein will come to mind to the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of 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.

Claims

C l a i m s

1. A method of brokering heterogeneous signal processing resources of an 0- RAN cloud platform (210), the signal processing resources including one or more general-purpose CPUs (206) for performing software processing and at least one hardware accelerator, HA (208), the method comprising: computing, by a controller (309) in near-real-time, a Logical Processing Unit, LPU, policy, the LPU policy including rules to be applied by the O-RAN Distributed Units, DUs (302), sharing the O-RAN cloud platform (210) on every encoded Transport Block, TB, to decide whether to process the TB in software or to offload the TB to a HA (208) of the O-RAN cloud platform (210); deploying the computed LPU policy into the O-RAN DUs (302) sharing the O-RAN cloud platform (210); and executing, by each of the O-RAN DUs (302) sharing the O-RAN cloud platform (210), the deployed policy in real-time for every encoded TB that needs to be processed.

2. The method according to claim 1 , wherein the LPU policy comprises a configured threshold TB size such that TBs having a size larger than the configured threshold are offloaded into a HA (208), while TBs having a size smaller than or equal to the configured threshold are processed in software.

3. The method according to claim 1 or 2, wherein the LPU policy comprises a configured threshold with respect to an expected software processing time of the TBs, wherein TBs that have an expected software processing time higher than the configured threshold are offloaded into a HA (208), while TBs that have an expected software processing time smaller than or equal to the configured threshold are processed in software.

4. The method according to claim 3, wherein the expected software processing time of a TB is predicted by a respective O-RAN DU (302) prior to computing the LPU policy.

5. The method according to any of claims 1 to 4, wherein the controller (309) computes the LPU policy based on contextual information derived from previously arrived TBs.

6. The method according to claim 5, wherein the contextual information includes O-RAN load information in terms of the signal-to-noise ratio, SNR, the modulation and coding scheme, MCS, and the size of TBs processed within a past time window.

7. The method according to any of claims 1 to 6, wherein each O-RAN DU (302) has associated its own controller (309) that computes an O-RAN DU (302) specific LPU policy as a function of the O-RAN DU’s (302) load.

8. The method according to any of claims 1 to 7, wherein the LPU policy is computed by an actor (802) of the controller (309), wherein a cost function is approximated by a critic (804) of the controller (309), and wherein the cost function is used to train the actor (802).

9. The method according to any of claims 1 to 8, wherein the controller (309) is implemented inside the O-RAN’s Near-RT RIC (308).

10. The method according to any of claims 1 to 9, wherein the controller (309) deploys the computed LPU policy into the O-RAN DUs (302) sharing the O-RAN cloud platform (210) via the O-RAN E2 interface (310).

11. A system for brokering heterogeneous signal processing resources of an O- RAN cloud platform (210), in particular for execution of a method according to any of claims 1 to 10, the signal processing resources including one or more general- purpose CPUs (206) for performing software processing and at least one hardware accelerator, HA (208), the system comprising: computing, by a controller (309) in near-real-time, a Logical Processing Unit, LPU, policy, the LPU policy including rules to be applied by the O-RAN Distributed Units, DUs (302), sharing the O-RAN cloud platform (210) on every encoded Transport Block, TB, to decide whether to process the TB in software or to offload the TB to a HA (208) of the O-RAN cloud platform (210); deploying the computed LPU policy into the O-RAN Dlls (302) sharing the O-RAN cloud platform (210); and executing, by each of the O-RAN Dlls (302) sharing the O-RAN cloud platform (210), the deployed policy in real-time for every encoded TB that needs to be processed.

12. The system according to claim 11 , wherein the controller (309) is configured to compute the LPU policy based on contextual information derived from previously arrived TBs.

13. The system according to claim 11 or 12, wherein the controller (309) comprises an actor (802) and a critic (804), wherein the actor (802) is configured to compute the LPU policy, and wherein the critic (804) is configured to approximate a cost function for training the actor (802).

14. The system according to claim 13, wherein the actor (802) and the critic (804) each comprise a combination of a 3D convolutional neural network and a feedforward neural network.

15. The system according to any of claims 1 1 to 14, wherein the controller (309) is implemented inside the O-RAN’s Near-RT RIC (308).