CloudRIC: Real-time and energy-efficient control of vRAN resources in a shared O-RAN cloud

Abstract

A method for real-time joint control of radio resources and computing resources in an O-RAN O-Cloud platform is disclosed.

Description

[Technical Field]

[0001] The project leading to this application has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement number 101017109.

[0002] The present disclosure relates to communication systems. The present disclosure is particularly, but not exclusively, related to wireless communication systems and devices thereof that operate in accordance with 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The present disclosure is particularly, but not exclusively, related to systems that employ real-time and energy-efficient control of virtualized radio access network (vRAN) resources. [Background technology]

[0003] The O-RAN Alliance (O-RAN) is a group that defines specifications for open radio access networks (Open RAN). The Open RAN architecture is based on a distributed approach to deploying RAN, built on cloud-native principles, and represents an evolution of the Next Generation RAN (NG-RAN) architecture.

[0004] O-RAN proposes a cloud architecture for hosting O-RAN-compliant network functions (NFs), such as distributed units (DUs). The O-RAN Acceleration Abstraction Layer (AAL) provides a common interface for NFs, such as DUs, to access hardware accelerators (HAs). This abstraction allows developers to decouple software design from accelerator details.

[0005] To this end, O-RAN introduced the concept of the AAL Logical Processing Unit (AAL-LPU), as shown in Figure 1. An AAL-LPU is a logical representation of HA resources within a particular NF (e.g., DU). This representation supports multiple processing units, subsystems, or HAs that provide hard partitioning of HA resources, each represented as an AAL-LPU. While an HA may support multiple AAL-LPUs, an AAL-LPU is always associated with a single HA, as shown in Figure 3. AAL queues are then used by NFs to share AAL-LPU resources. Additionally, an AAL-LPU can be associated with one or more AAL profiles, which specify the functions that can be offloaded to the HA. The following discussion focuses on the forward error correction (FEC) low-density parity check (LDPC) decoding task.

[0006] The main problem with this approach is that it,cannot efficiently implement load balancing since NFs can greedily,select HAs.,For example, in platforms with heterogeneous acceleration resources,,NFs may overload the fastest HAs, resulting in overall,performance degradation.,Thus, despite providing a suitable abstraction, O-RAN,AALs alone cannot efficiently mediate access to the shared,infrastructure, as they do not support centralized coordination of,acceleration resources and are unable to impose radio scheduling,policies on the involved DUs.

[0007] Previous work has proposed three extensions to the O-RAN Open Cloud (O-Cloud) architecture, as shown in Figure 2. These extensions seamlessly integrate into the standard O-RAN O-Cloud architecture and add three key enhancements: A function called the Real-Time RAN Intelligent Controller (or "Real-Time RIC (RT-RIC)") that receives the temporary grants issued by the DU and returns a final grant, which is a modified (or non-modified) version of the temporary grant that can maximize wireless throughput and allow the AAL to meet the processing deadline of the corresponding transport block (TB). A function called "AAL Broker" that has two subcomponents: - AAL Broker Control Plane (AAL-B-CP): Responsible for allocating LPUs to final grants in order to meet processing deadlines with minimal energy cost. - AAL Broker User Plane (AAL-B-UP): Acts as a proxy between the O-RAN NF (in this case, the O-DU) and the O-RAN AAL. From the NF's point of view, the AAL-B-UP behaves as a virtual AAL LPU providing all AAL profiles supported by all HAs in the system. From the point of view of each O-RAN AAL LPU, the AAL-B-UP simply acts as an NF. The AAL-B-UP is responsible for routing TBs granted to the UE to the AAL queues corresponding to the LPUs allocated by the AAL-B-CP. This is an interface for real-time communication between the broker, RT-RIC, and O-DU, and is called the "E3" interface.

[0008] Given the real-time nature of interface E3, it is expected that the RT-RIC, DU instances, and AAL brokers will be deployed in the same physical infrastructure, such as an edge data center.

[0009] This approach has three advantages. 1. By separating AAL-B-CP and AAL-B-UP, data plane overhead can be minimized. 2. By centralizing the allocation of computing resources, the load can be better balanced to achieve the desired objectives. 3. It is possible to ensure that deadlines are met by influencing the DU's radio scheduler (e.g., limiting radio resource allocation when the AAL queue is congested).

[0010] However, the remaining challenge is to design an efficient method for optimizing the performance of the RAN using the architecture of Figure 2.

[0011] Therefore, in summary, the O-RAN standard presents a problem in that load balancing cannot be implemented efficiently, as NFs can only greedily select HAs without information about the queues associated with other NFs that share the same HA. This is highly inefficient in platforms with heterogeneous high-speed resources, as NFs will overload the fastest HAs, resulting in overall poorer performance and more energy consumption. While previous work has offered some advantages, it has not provided a mechanism to utilize the AAL-Broker and RT-RIC in a way that contributes to at least maximizing throughput and minimizing energy consumption. Summary of the Invention [Problem to be solved by the invention]

[0012] The present invention aims to address or at least partially ameliorate one or more of the above problems or issues. [Means for solving the problem]

[0013] The invention will now be described, by way of example only, with reference to the accompanying drawings in which: [Brief explanation of the drawings]

[0014] [Figure 1]FIG. 1 illustrates a schematic diagram of an O-RAN Acceleration Abstraction Layer (AAL). [Figure 2] FIG. 1 is a diagram illustrating an O-Cloud architecture. [Figure 3] FIG. 1 shows a schematic diagram of the design and workflow of Cloud RIC. [Figure 4] FIG. 2 illustrates an LPU allocator. [Figure 5a] FIG. 4 is a message sequence diagram of the workflow shown in FIG. 3. [Figure 5b] FIG. 4 is a message sequence diagram of the workflow shown in FIG. 3. [Figure 6] FIG. 1 illustrates a schematic diagram of an O-RAN architecture to which the above aspects are applicable. [Figure 7] FIG. 2 is a block diagram illustrating the main components of a UE. [Figure 8] FIG. 1 is a block diagram illustrating the main virtual components of an exemplary v(R)AN node. [Figure 9] FIG. 1 is a block diagram illustrating the main virtual components of a core network node. DETAILED DESCRIPTION OF THE INVENTION

[0015] Figure 3 shows the design and workflow of the Cloud RAN Intelligent Controller (RIC).

[0016] To illustrate, consider a system containing a small number of virtual DU instances sharing the same O-Cloud infrastructure to offload FEC decoding tasks.

[0017] We also consider an O-Cloud containing a set of M potentially heterogeneous HAs.

[0018] The DU allocates radio resources to its associated UEs by issuing grants according to its own MAC layer scheduling procedure, but beneficially following a simple policy referred to herein as CloudRIC, as will be described below.

[0019] The resulting transport block (TB) sent by the user (UE) is processed (decoded) by the AAL within a time constraint D, otherwise the TB is discarded.

[0020] The goal here is to minimize the energy consumption of the system in the long term, subject to meeting the deadlines of the time constraint D for all scheduled TBs.

[0021] An important consideration in the design of real-time RAN control mechanisms, often ignored in the literature, is the latency overhead they introduce, which adds to the overall processing latency of the TB. Therefore, it is beneficial to design a system that accelerates decision-making, eliminating the use of complex optimization approaches or large machine learning models.

[0022] A detailed view of a particularly useful CloudRIC design is shown in Figure 3. An exemplary implementation of the workflow shown in Figure 3 is shown in Figures 5a and 5b, which show possible sequences of messages between various entities of the system to implement the workflow. The key to this CloudRIC design is its reliance on distributed, ultra-lightweight neural network models that work together efficiently. The main workflow of this design is as follows:

[0023] Step (1) All temporary grants arriving at RT-RIC

[0024]

number

[0025] is the bandwidth

[0026]

number

[0027] (number of RBs), selected modulation and coding scheme (MCS) m (i) , UE's signal-to-noise ratio (SNR) q (i) , corresponding TB size (bits)

[0028]

number

[0029] and priority p (i) , i.e.

[0030]

number

[0031] Top Bar

[0032]

number

[0033] is used here to indicate that the corresponding element · is temporary.

[0034] Step (2) Temporary Grant

[0035]

number

[0036] Upon receiving the AAL-B-CP, the RT-RIC state processor

[0037]

number

[0038] collects state information about k is the kth LPU. This information consists of an estimate (prediction) of the waiting time in each AAL queue, given as follows:

[0039]

number

[0040] Top hat

[0041]

number

[0042] is used here to indicate that the corresponding element · is a prediction.

[0043] Waiting time

[0044]

number

[0045] To estimate

[0046]

number

[0047] All grants in (k) Estimated processing time for

[0048]

number

[0049] and the grant g currently being processed by the LPU (s) Aggregate the expected remaining processing time of the TBs associated with

[0050]

number

[0051] where:

[0052]

number

[0053] is the (actual) time stored in the LPU so far (s <k<i)。

[0054] Processing time

[0055]

number

[0056] A useful approach for calculating is detailed in step (5).

[0057] Step (3) The state processor processes all the above information into a single feature vector x (i) Integrate into.

[0058]

number

[0059] Vector x (i) Given, the wireless agent μ

[0060]

number

[0061] The final grant

[0062]

number

[0063] The bandwidth (number of RBs) allowed for the radio allocation policy

[0064]

number

[0065] Calculate.

[0066] Step (4) As shown in Figs. 3 and 5, the radio allocation policy r (i) The policy is communicated to both the corresponding DU and the AAL-B-CP via interface E3. (i) The final scheduling grant will be determined by

[0067]

number

[0068] This can be allocated to the UE,

[0069]

number

[0070] is the corresponding TB size (bits). The DU sends grant g to the UE in the DCI message as specified by 3GPP. (i) It is now possible to notify

[0071] Step (5) Then, the computational resource model v of each LPU n∈L is n Using Grant g (i)The time required by the LPU to FEC process the TB associated with

[0072]

number

[0073] and energy

[0074]

number

[0075] is estimated, i.e.

[0076]

number

[0077] These are stateless models, so they can be constructed using simple neural networks trained offline for each HA.

[0078] As shown in Figures 3 and 5, the LPU allocation function allocates grants g based on a simple algorithm (shown in Figure 4). (i) In essence, the LPU allocation function pre-allocates LPUs to the TBs associated with L. From the set of LPUs, L, we exclude AAL LPUs that do not have the bit capacity to store a TB, generating a (sub)set of LPUs, L⊆L. Then, we use the latency and processing time estimates calculated above,

[0079]

number

[0080] and

[0081]

number

[0082] The allocator uses the expected processing time

[0083]

number

[0084] from the (sub)set L1, generating a "short list" (sub)set L2 ⊆ L1 of LPUs. Then, given the short list L2,

[0085]

number

[0086] One LPU k∈L2 is selected that can process the TB with this priority information p (i) can also be used to select the LPU.

[0087] If the HA is unable to process the grant in time, the DU is denied permission to issue the scheduling grant.

[0088] Steps (6) After a time equal to K2 (specified by 3GPP), the UE receives a scheduled grant g (i) The DU transmits the TB corresponding to the AAL-B-CP wirelessly on the PUSCH. Upon reception, the DU forwards the TB to the AAL-B-UP dispatcher, which simply routes the data to a pre-allocated AAL queue for FEC processing. Once the corresponding LPU completes its task, the decoded data is sent back to the DU for further 3GPP standard processing (e.g., cyclic redundancy check (CRC) verification, etc.), the AAL-B-CP updates its queue status information, and the LPU starts processing the next TB in the queue.

[0089] overview Beneficially, the above-described aspects include, but are not limited to, one or more of the following:

[0090] Based on the prediction of the processing latency and energy consumption of each hardware accelerator in a pool of heterogeneous hardware accelerators, we provide a compute-aware radio scheduling policy and an LPU (Logical Processing Unit) allocator that jointly assigns hardware accelerators to each radio scheduling grant, thereby maximizing throughput and minimizing energy consumption in real time.

[0091] To provide the above functionality, the following exemplary steps are described herein: 1) Before scheduling the final grant, the DU issues a request to the RT-RIC state processor with a temporary grant. 2) A state processor that uses that information and the wait estimates from the AAL broker to build a state feature vector. 3) A wireless agent that uses such state feature vector to propose a radio resource policy consisting of a restriction (or no restriction) on the amount of bandwidth that the DU can use in its final grant. 4) A set of computational resource models that use information about radio policies and grants to predict the processing latency and energy consumption of each hardware accelerator. 5) The LPU allocator uses the predictions from step 4 to pre-allocate AAL queues / LPUs (hardware accelerators) for scheduled grants. 6) When the TB arrives (after time K2 when the radio grant was signaled to the UE according to the 3GPP specifications), the AAL-B-UP redirects the coded TB to the pre-allocated AAL queue / LPU.

[0092] It can be seen that the above features contribute to maximizing the network throughput in a shared O-Cloud system with minimal energy consumption.

[0093] System Overview FIG. 6 illustrates schematically an O-RAN architecture to which the above aspects are applicable.

[0094] The architecture includes the following functional components: a Non-RT RIC 11 and a near-RT RIC 12. The former is hosted by the system's SMO framework 10 (e.g., integrated within ONAP), while the latter may be co-located with the 3GPP gNB functions (O-CU and / or O-DU) or located in a separate node as long as latency constraints are respected. Figure 6 also shows O-Cloud, an O-RAN compliant cloud platform that deploys eNB / gNB as virtualized network functions in v(R)AN scenarios using hardware acceleration add-ons, if required, and a software stack that is decoupled from the hardware.

[0095] O-RAN enables radio resource management (RRM) from Near-RT RIC 12 through the E2 open interface, as shown in Figure 6. E2 nodes are 3GPP-defined RAN NFs such as DUs, while the O2 interface is used by SMO 10 to provide non-RT infrastructure and NF lifecycle management procedures in a virtualized environment known as O-Cloud.

[0096] SMO10 has various organizational and management services that may go beyond pure RAN management, such as 3GPP (NG-) core management or end-to-end network slice management. In the O-RAN context, the primary responsibilities of SMO10 include the Fault, Configuration, Accounting, Performance, and Security (FCAPS) interface to O-RAN network functions, large-scale timescale RAN optimization, and O-Cloud management and orchestration over the O2 interface, including resource discovery, scaling, FCAPS, software management, and interaction with O-Cloud resources.

[0097] The non-RT RIC 11 is a logical function that enables non-real-time control and optimization of RAN elements and resources, AI / ML workflows including model training and updates, and policy-based guidance of applications / functions in the near-RT RIC 12. The non-RT RIC 11 also provides an A1 interface to the Near-RT RIC 12. Its primary purpose is to support large-scale timescale RAN optimization (seconds or minutes), including policy computation, ML model management, and other radio resource management functions within this timescale. Data management tasks requested from the non-RT RIC 11 are translated to the O1 / O2 interface, and contextual / enrichment information can be provided to the Near-RT RIC 12 via the A1 interface.

[0098] The Near-RT RIC 12 is a logical function responsible for (i) publishing E2 node data (e.g., network measurements, context information), (ii) implementing 3GPP-defined RRM procedures, and (iii) deploying radio control policies to E2 nodes. Furthermore, the Near-RT RIC 12 enables near-real-time optimization and control of O-CU and O-DU nodes and resources, and data monitoring, on the Near-RT timescale (10 ms to 1 s) through granular data collection and action over the E2 interface. The Near-RT RIC 12's control is directed by policies and aided by models computed / trained by the non-RT RIC 11. The Near-RT RIC 12 also supports xApps, independent software plug-ins to the Near-RT RIC 12 platform that allow third parties to extend the RAN functionality.

[0099] This architecture essentially provides three independent control loops. Non-RT RIC 11 control loop: Large timescale operation on the order of seconds to minutes. Its purpose is to execute O-RAN specific orchestration decisions, such as policy configuration or training of ML models. Near-RT RIC 12 control loop: sub-second timescale operation. Its purpose is to perform tasks such as policy enforcement or radio resource management operations. O-DU Scheduler Control Loop: Real-time operation that performs legacy radio operations such as HARQ, beamforming, or scheduling.

[0100] It will be appreciated that although the control loops are understood to be independent, they may still interact with each other.

[0101] Additionally, although not shown in Figure 6, the O-RAN architecture has been extended to include the RT-RIC, the AAL broker, and the so-called "E3" interface between the broker, the RT-RIC, and the O-DU (as shown in Figures 2 and 3). These extensions are seamlessly integrated into the standard O-RAN O-Cloud architecture shown in Figure 6.

[0102] The RT-RIC receives the temporary grants issued by the DU and returns final grants (which may represent modified (or unmodified) temporary grants), thereby maximizing wireless throughput and enabling the AALs to meet the processing deadlines of the corresponding TBs.

[0103] The AAL Broker has two subcomponents: the AAL Broker Control Plane (AAL-B-CP) and the AAL Broker User Plane (AAL-B-UP). The AAL-B-CP is responsible for allocating LPUs to final grants to meet processing deadlines with minimal energy cost. The AAL Broker User Plane (AAL-B-UP) acts as a proxy between the O-RAN NF (in this case, the O-DU) and the O-RAN AAL. From the NF's perspective, the AAL-B-UP behaves as a virtual AAL LPU that provides all AAL profiles supported by all HAs in the system. From the perspective of each O-RAN AAL LPU, the AAL-B-UP simply acts as an NF. The AAL-B-UP is responsible for routing TBs granted to UEs to the AAL queues corresponding to the LPUs allocated by the AAL-B-CP. The E3 interface is the interface for real-time communication between the AAL Broker, the RT-RIC, and the O-DU.

[0104] The components of this architecture are configured to implement one or more of the solutions described above.

[0105] User Equipment (UE) FIG. 7 is a block diagram illustrating the main components of a UE (mobile device 3) communicating with the system shown in FIG. 6. As shown, the UE includes transceiver circuitry 31 operable to transmit and receive signals to and from connected nodes via one or more antennas 33. While not necessarily shown in FIG. 7, the UE of course has all the usual functionality of a conventional mobile device (e.g., user interface 35), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. A controller 37 controls the operation of the UE according to software stored in memory 39. The software may be pre-installed in memory 39 and / or downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 41 and a communications control module 43. The communications control module 43 is responsible for processing (generating / sending / receiving) signaling messages and uplink / downlink data packets between the UE 3 and other nodes, including the v(R)AN node 5, application functions, and core network nodes. Such signaling includes properly formatted requests and responses related to training, validation, registration, and deployment of AI&ML models.

[0106] Virtual RAN (v(R)AN) node FIG. 8 is a block diagram illustrating the major virtual components of an exemplary v(R)AN node 5 (base station) that can be used in the system shown in FIG. 6. As shown, the v(R)AN node 5 includes transceiver circuitry 51 operable to transmit and receive signals to and from connected UEs 3 via one or more antennas 53 and to transmit and receive signals to and from other network nodes (directly or indirectly) via a network interface 55. The network interface 55 typically includes an appropriate base station-to-base station interface (e.g., X2 / Xn) and an appropriate base station-to-core network interface (e.g., NG-U / NG-C). A controller 57 controls the operation of the v(R)AN node 5 according to software stored in memory 59. The software may be pre-installed in memory 59 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 61 and a communications control module 63. The communications control module 63 is responsible for handling (generating / sending / receiving) signaling between the v(R)AN node 5 and other nodes, such as UEs 3 and core network nodes.

[0107] Core Network Node FIG. 9 is a block diagram illustrating the main hypothetical components of a generic core network node (or function) that may be used in the system shown in FIG. 6. As shown, the core network node includes a transceiver circuit 71 operable to transmit and receive signals to and from other nodes (including UE 3 and v(R)AN node 5) via a network interface 75. A controller 77 controls the operation of the core network node according to software stored in memory 79. The software may be pre-installed in memory 79 and / or may be downloaded, for example, via the telecommunications network 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 81 and at least a communications control module 83. The communications control module 83 is responsible for handling (generating / sending / receiving) signaling between the core network node and other nodes, such as UE 3, v(R)AN node 5, and other core network nodes. Such signaling includes appropriately formatted requests and responses related to intelligent data collection and management of the Open RAN intelligent controller.

[0108] Fixes and Alternatives Detailed embodiments have been described above. As those skilled in the art will appreciate, many modifications and alternatives may be made to the above embodiments while still enjoying the benefits of the invention embodied therein. By way of example, some of these alternatives and modifications are described.

[0109] In the above description, for ease of understanding, the UE, v(R)AN node, and core network node are described as having several separate modules (e.g., a communications control module). While these modules may be provided in this manner in certain applications, for example, when an existing system is modified to implement the above aspects, in other applications, for example, in systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into an overall operating system or code and may not be identifiable as separate entities. These modules may also be implemented in software, hardware, firmware, or a combination thereof.

[0110] Each controller may include any suitable form of processing circuitry including, for example (but not limited to), one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers and / or timers, etc.

[0111] In the above embodiments, several software modules have been described. As will be understood by those skilled in the art, the software modules may be provided in compiled or uncompiled form, and may be supplied to the UE, v(R)AN node, and core network node as signals over a computer network or as signals on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because they facilitate updating the functionality of the UE, v(R)AN node, and core network node.

[0112] The above aspects are also applicable to "non-mobile" or generally fixed user equipment.

[0113] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here. [Explanation of symbols]

[0114] 1. Telecommunications Networks 3. Mobile Devices 5 v(R)AN nodes 31 Transceiver Circuit 33 Antenna 35 User Interface 37 Controller 39 Memory 41 Operating Systems 43 Communication Control Module 51 Transceiver circuit 53 Antenna 55 Network Interface 57 Controller 59 Memory 61 Operating Systems 63 Communication Control Module 71 Transceiver Circuit 77 Controller 79 Memory 81 Operating Systems 83 Communication Control Module

Claims

1. 1. A method for allocating hardware accelerator (HA) resources to a scheduled grant for processing a transport block (TB), comprising: allocating a logical processing unit (LPU) of a plurality of LPUs to the scheduled grant; Each LPU of the plurality of LPUs represents a respective HA; the allocating step: the respective latency expected for each HA to complete processing of said TB, or The predicted energy consumption of each HA to complete the treatment of the TB and allocating the LPU based on at least one of: method.

2. 2. The method of claim 1, wherein the allocating step allocates the LPUs by identifying a set of capacity-based LPUs including at least a subset of the plurality of LPUs based on the respective capacities of each LPU for storing the TB, and allocating the LPUs from the set of capacity-based LPUs.

3. The method of claim 2 , wherein each LPU included in the set of capacity-based LPUs has a respective capacity sufficient to store the TB.

4. 4. A method according to any one of claims 1 to 3, wherein the allocating step allocates the LPUs by identifying a set of latency-based LPUs including at least a subset of the plurality of LPUs based on the respective latencies predicted for each HA, and allocating the LPUs from the set of latency-based LPUs.

5. The method of claim 4, wherein the respective latency predicted for each HA is based on a combination of a predicted waiting time until processing of the TB begins at that HA and a predicted processing time for that HA to process the TB.

6. 6. The method of claim 5, wherein the predicted waiting time is based on the sum of the respective predicted processing times of each grant in a queue associated with the LPU representing that HA and the respective predicted remaining processing times of each TB associated with each grant in the queue.

7. The method of claim 5 or 6, wherein the predicted waiting time is based on state information collected by a real-time radio access network intelligent controller for each of a plurality of queues associated with the plurality of LPUs.

8. The method of claim 4 , wherein the set of latency-based LPUs comprises LPUs whose predicted latency is less than or equal to a predefined time constraint (D).

9. 9. The method of claim 1, wherein the allocating step allocates the LPUs by comparing the predicted energy consumptions for each HA associated with at least a subset of the plurality of LPUs and allocating the LPU corresponding to the HA with the lowest predicted energy consumption to the scheduled grant.

10. The method of claim 1 , wherein the allocating step allocates the LPUs based on a priority associated with the TB.

11. The method of claim 1 , wherein the allocating step comprises allocating a queue corresponding to the allocated LPU to the scheduled grant.

12. 1. An apparatus for allocating hardware accelerator (HA) resources to a scheduled grant for processing a transport block (TB), comprising: means for assigning a logical processing unit (LPU) of a plurality of LPUs to a scheduled grant; Each LPU of the plurality of LPUs represents a respective HA; the allocating step: the respective latency expected for each HA to complete processing of said TB, or The predicted energy consumption of each HA to complete the treatment of the TB and allocating the LPU based on at least one of: Device.

Images