Non-Real Time CloudRIC: Energy-efficient Control of vRAN Resources in Shared O- RAN Clouds Technical Field The present disclosure relates to a communication system. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The disclosure has particular although not exclusive relevance to systems using non-real time and energy-efficient control of virtualized radio access network (vRAN) resources. Background The O-RAN Alliance (O-RAN) is a group that defines specifications for open radio access networks (Open RANs). The Open RAN architecture is based on a disaggregated approach to deploying RANs, that is built on cloud native principles, and represents an evolution of the Next Generation RAN (NG-RAN) architecture. O-RAN has proposed a cloud architecture to host O-RAN compliant Network Functions (NFs) such as Distributed Units (DUs). Therein, O-RAN’s Acceleration Abstraction Layer (AAL) provides a common interface for NFs such as DUs to access Hardware Accelerators (HAs). This abstraction allows developers to decouple their software designs from the specifics of the accelerators. To this end, O-RAN has introduced the concept of an AAL Logical Processing Unit (AAL- LPU) as shown in Figure 1. An AAL-LPU is a logical representation of the HA resources within a specific NF (e.g., a DU). This representation supports HAs that provide multiple processing units, subsystems, or hard partitions of the HA resources, each represented as an AAL-LPU. Although a HA may support multiple AAL-LPUs, an AAL-LPU is always associated to a single HA, as depicted in Figure 3. Then, AAL Queues are used by NFs to share AAL-LPU resources. In addition, an AAL-LPU may be associated with one or multiple AAL Profiles, which specify the functions that can be offloaded to a HA. Forward error correction (FEC) low-density parity-check (LDPC) decoding tasks are focussed on in the following description. In earlier work an extension was proposed to the O-RAN open cloud (O-Cloud) architecture that integrates seamlessly into the standard O-RAN O-Cloud architecture. This included a function called an “AAL Broker”, with two sub-components: – AAL Broker Control Plane (AAL-B-CP): which is responsible for assigning LPUs to final grants such that processing deadlines are met with the minimum amount of energy cost. – AAL Broker User Plane (AAL-B-UP): which acts as a proxy between O-RAN NFs (O-DUs, in this case) and an O-RAN AAL. From the perspective of the NFs, the AAL-B-UP behaves as a virtual AAL LPU that provides all the AAL Profiles supported by all the HAs in the system. From the perspective of each O-RAN AAL LPU, the AAL-B-UP simply plays the role of an NF. The AAL-B-UP is responsible for routing Transport Blocks (TBs) granted to UEs to the AAL Queue corresponding to the LPU assigned by the AAL-B-CP. In summary, therefore, a problem exists that load balancing cannot be implemented efficiently with O-RAN standard because NFs can only greedily select HAs, without information about the queues associated with other NFs sharing the same HAs. This is highly inefficient because, in platforms with heterogeneous accelerating resources, NFs may overload the fastest HA, which converges to poor performance and consumes more energy overall. While the earlier work provided a number of advantages, it did not provide a mechanism that exploited the AAL-Broker and a RT-RIC in a manner that at least contributed to maximizing throughput and minimizing energy consumption. The present invention aims to address, or at least partially ameliorate, one or more of the above problems or challenges. The invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 schematically illustrates an O-RAN Acceleration Abstraction Layer (AAL); Figure 2 schematically illustrates a cloud RIC design and workflow; Figure 3 is an illustration of an LPU Allocator; Figure 4 schematically illustrates an O-RAN architecture to which the above aspects are applicable; Figure 5 is a block diagram illustrating the main components of a UE; Figure 6 is a block diagram illustrating the main virtual components of an exemplary v(R)AN node; and Figure 7 is a block diagram illustrating the main virtual components of a core network node. Detailed description Figure 2 illustrates a cloud RAN intelligent controller (RIC) design and workflow. For the purposes of explanation, a system is considered that comprises a trivial number of virtual DU instances that share the same O-Cloud infrastructure to offload FEC decoding tasks. An O-Cloud is also considered that comprises a set of M, potentially heterogeneous, HAs. DUs allocate radio resources to associated UEs by issuing a grant following their own MAC-layer scheduling procedures but, beneficially, obeying a radio policy imposed by Non-RT RIC through A1-P interface/Near-RT RIC through E2 interface, which is referred to herein as Non-RT CloudRIC, as will be explained later. The resulting TB sent by the user shall be processed (decoded) by the AAL within a time constraint D; otherwise, the TB is discarded. A goal here is to minimize energy consumption of the system over the long run subject to satisfying the time constraint D deadline for every scheduled TB. A detailed illustration of our design is depicted in Figure 2. The main workflow goes as follows. Non Real Time operation (Non-RT RIC) ^ Step (1) Every interval T (seconds), the Non-RT RIC collects information about each grant issued by every DU. Each grant ^{^ ∈ {1,2, … }} descriptor includes its bandwidth ^{^(^)} (number of RBs), the selected modulation and coding scheme (MCS) ^ ^{(^)} , the UE’s signal to noise ( ^{^)} (^) ratio (SNR) ^ , and the corresponding TB size (bits) ^ , i.e., ^ ^{(^)} : = [^ ^{(^)} , ^ ^{(^)} , ^ ^{(^)} , ^ ^{(^)} ]. ^ Step (2) Then, the Non-RT RIC, collects statistics about the waiting time at each AAL Queue the ^ ^{^^} LPU. ^ ^{(^)} : = [w(^) (^) ^ , … , w^ ] These statistics may consist of the mean waiting time or others (e.g., variance, quartiles, etc.) ^ Step (3) The state processor consolidates all the above information into a single feature vector ^ ^{(^)} , ^ ^{(^)} : = [^ ^{(^)} , ^ ^{(^)} ]. Given the vector ^ ^{(^)} , a radio agent ^ computes a radio allocation policy ^ ^{(^)} : = ^(^ ^{(^)} ) ∈ ℝ _^^^ ^{(^)} _^^ , such that ^ ^{(^)} : = ^ ^{(^)} ⋅ ^ is the maximum bandwidth (RB count), out of the total number of possible RBs C, allowed for the each grant in interval T+1. Real Time operation (AAL Broker) ^ Step (4) As shown in Figure 2, every grant ^ ^{(^)} is communicated to the AAL through the AAL- Interface (AALI). A compute resource model ^ _^ of each LPU ^ ∈ ℒ is then used to estimate the time and energy ^(^) ^ required by the LPU n to FEC-process the TB associated with grant ^ ^{(^)} , i.e., ^ _^ (^ ^{(^)} _{) =} , ^(^) ^ }. Because these are stateless models, they can be built with simple neural networks trained offline for each HA. ^ Step (5) As depicted in Figure 2, the LPU allocation function pre-assigns an LPU to the TB associated with grant ^ ^{(^)} based on a simple algorithm (described in Figure 3). In short, the LPU allocation function prunes from the set of LPUs ℒ those AAL LPUs that do not have the bit-capacity to store the TB, which yields a (sub)set of LPUs ℒ _^ ⊆ ℒ. Then, the AAL broker predicts the waiting time at each AAL Queue n, denoted as The top hat ⋅̂ is used here to indicate that the corresponding element ⋅ is a prediction. To estimate the waiting time ^(^) ^ ,  ∀^ ∈ ℒ, the AAL-B-CP aggregates the expected (^) processing time ^ ^{^} of every grant ^ ^{(^)} in (^) ^ ^ _^ and the expected leftover processing time of the TB associated with grant ^ ^{(^)} that is being processed in the LPU at the time, i.e., _^ ^{^} (^) ^ − ^(^) ^ , where ^(^) ^ is the (real) time the TB has been held by the LPU so far (^ < ^ < ^). (^) ^{^} (^) Then, using the waiting and processing time estimates ^ _^ and ^ _^ , the allocator prunes ℒ ( (^) from the (sub)set _^ those LPUs with an expected processing time ^{^} ^) ^ _{+ ^} ^{^} _^ > ^, which yields a ‘shortlist’ (sub)set of LPUs ℒ _^ ⊆ ℒ _^ . Then, given the shortlist ℒ _^ , the one LPU ^ ∈ ℒ _^ that can process the TB with the least amount of expected energy is selected. This simple greedy approach is both efficient and extremely fast. The TB’s priority information ^ ^{(^)} can also be used when selecting the LPU. If no HA can process the grant in time, the permission for that DU, to issue that scheduling grant, is rejected. ^ Step (6) After a time equal to ^2 (specified by 3GPP), the UE wirelessly transmits the TB corresponding to the scheduled grant ^ ^{(^)} in a PUSCH. Once received, the DU forwards the TB to the AAL-B-UP’s dispatcher, which simply routes the data to the pre-assigned AAL Queue for FEC processing. Once the corresponding LPU completes the task, the decoded data is sent back to the DU for further 3GPP-standard processing (e.g., cyclic redundancy check (CRC) verification), the AAL-B-CP updates its Queue state information, and the LPU begins processing the next TB in the Queue. Summary Beneficially, the above described aspects include, although they are not limited to, one or more of the following: A method that, based on 1) statistics about radio grants scheduled by DUs during a time interval received through the O-RAN O1 interface and 2) statistics about the waiting time in each queue in O-RAN AAL received through the O-RAN O2 interface, provides DUs with non-real-time compute-aware radio scheduling policies through O-RAN Non- RT/Near-RT RIC using the O-RAN A1-P and O-RAN E2 interfaces and, based on predictions on processing latency and energy consumption of each hardware accelerator in a pool of heterogeneous hardware accelerators, an LPU (Logical Processing Unit) allocator inside O-RAN O-Cloud computes hardware accelerator selection policies in real- time. Note: Non-real-time compute-aware radio scheduling policies can be as well provided to DUs through O-RAN Non-RT/Near-RT RIC using O-RAN O1 interface or new interfaces. In order to provide the above functionalities, the present document describes the following exemplary steps comprising: For every interval T: 1) DUs send through O1 interface information (e.g. statistics) about all grants scheduled in the last interval T. 2) A state processor that uses that information and statistics about the waiting time in each AAL Queue sent through O2 interfaces from the O-Cloud to build a state feature vector 3) A radio agent in the Non-RT RIC that uses such state feature vector to propose a radio resource policy, which bounds the effective bandwidth each DU may use in the next interval T+1. For every grant issued by DUs: 4) A set of compute resource models that uses the information about the grant to predict the processing latency and energy consumption of each hardware accelerator 5) An LPU allocator that uses the predictions mentioned above, and a prediction on the waiting time at each AAL Queue to pre-assign an AAL Queue/LPU (a hardware accelerator) to the scheduled grant. If no HA can process the grant in time, the DU is rejected the permission to issue that grant. 6) When the TB arrives (after a time K2 when radio grants were signalled to UEs as per 3GPP specification), the AAL-B-UP redirects the encoded TB to the pre-assigned AAL Queue/LPU. It can be seen that the above functionalities contribute to maximizing network throughput in a shared O-Cloud system with minimum energy consumption. System Overview Figure 4 schematically illustrates an O-RAN architecture to which the above aspects are applicable. This architecture comprises the functional components: Non-RT RIC 11 and the near-RT RIC 12. While the former is hosted by the SMO framework 10 of the system (e.g., integrated within ONAP), the latter may be co-located with 3GPP gNB functions (O-CU and/or O-DU) or in a separate node as long as latency constraints are respected. Figure 4 also depicts the O-Cloud, an O-RAN compliant cloud platform that uses hardware acceleration addons when needed and a software stack that is decoupled from the hardware to deploy eNBs/gNBs as virtualized network functions in v(R)AN scenarios. O-RAN enables radio resource management (RRM) from a Near-RT RIC 12 through the E2 open interface, as shown in Figure 4. E2 nodes are 3GPP-defined RAN NFs such as DUs. On the one hand, the O2 interface is used by the SMO 10 to provide non-RT infrastructure and NF lifecycle management procedures in a virtualization environment known as O-Cloud. The SMO 10 has various organisation and management services, which may go beyond pure RAN management such as 3GPP (NG-)core management or end-to-end network slice management. In the context of O-RAN, the main responsibilities of the SMO 10 include: fault, configuration, accounting, performance, and security (FCAPS) interface to O-RAN network functions; large-timescale RAN optimization; and O-Cloud management and orchestration via the O2 interface, including resource discovery, scaling, FCAPS, software management, and interacting with O-Cloud resources. The Non-RT RIC 11 is a logical function that enables non-real-time control and optimization of RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in near-RT RIC 12. The Non- RT RIC 11 also provides the A1 interface to the Near-RT RIC 12. Its main goal is to support large 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 by the Non-RT RIC 11 should be converted into the O1/O2 interface; and contextual / enrichment information can be provided to the Near-RT RIC 12 via the A1 interface. The Near-RT RIC 12 is a logical function in charge of (^) exposing E2 node data (network measurements, context information, etc.); (^^) implement 3GPP-defined RRM procedures; and (^^^) deploy radio control policies into E2 nodes. Further, the Near-RT 12 RIC enables near-real-time optimization and control and data monitoring of O-CU and O-DU nodes and resources in near-RT timescales (between 10 ms and 1 s) via fine-grained data collection and actions over the E2 interface. Near-RT RIC 12 control is steered by the policies and assisted by models computed/trained by the non-RT RIC 11. Near-RT RIC 12 also supports xApps (independent software plug-ins to the Near-RT RIC 12 platform to provide functional extensibility to the RAN by third parties). This architecture inherently provides three independent control loops: • Non-RT RIC 11 control loop: Large-timescale operation on the order of seconds or minutes. The goal is to perform O-RAN-specific orchestration decisions such as policy configuration or ML model training. • Near-RT RIC 12 control loop: Sub-second time-scale operation. The goal is performing tasks such as policy enforcement or radio resource management operations. • O-DU scheduler control loop: Real-time operation performing legacy radio operations such as HARQ, beamforming, or scheduling. It will be appreciated that whilst the control loops are understood to be independent, they may still interact with each other. Moreover, while not visible in Fig. 4, the O-RAN architecture has been extended, in accordance with previous proposals, with an AAL Broker (as illustrated in Fig. 2). The AAL Broker has two sub-components: AAL Broker Control Plane (AAL-B-CP) and AAL Broker User Plane (AAL-B-UP). The AAL-B-CP is responsible for assigning LPUs to final grants such that processing deadlines are met with the minimum amount of energy cost. The AAL Broker User Plane (AAL-B-UP) acts as a proxy between O-RAN NFs (O-DUs, in this case) and an O-RAN AAL. From the perspective of the NFs, the AAL-B-UP behaves as a virtual AAL LPU that provides all the AAL Profiles supported by all the HAs in the system. From the perspective of each O-RAN AAL LPU, the AAL-B-UP simply plays the role of an NF. The AAL-B-UP is responsible for routing TBs granted to UEs to the AAL Queue corresponding to the LPU assigned by the AAL-B-CP. The components of this architecture are configured to perform one or more of the above described solutions. User equipment (UE) Figure 5 is a block diagram illustrating the main components of a UE (mobile device 3) that communicates with the system shown in Figure 4. As shown, the UE includes a transceiver circuit 31 which is operable to transmit signals to and to receive signals from the connected node(s) via one or more antenna 33. Although not necessarily shown in Figure 5, the UE will of course have all the usual functionality of a conventional mobile device (such as a user interface 35) and this 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 in accordance with software stored in a memory 39. The software may be pre-installed in the memory 39 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 41 and a communications control module 43. The communications control module 43 is responsible for handling (generating/ sending/receiving) signalling messages and uplink/downlink data packets between the UE 3 and other nodes, including v(R)AN nodes 5, application functions, and core network nodes. Such signaling includes appropriately formatted requests and responses relating to AI&ML model training, verification, registration and deployment. Virtual RAN (v(R)AN) node Figure 6 is a block diagram illustrating the main virtual components of an exemplary v(R)AN node 5 (base station) that can be used in the system shown in Figure 4. As shown, the v(R)AN node 5 includes a transceiver circuit 51 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antenna 53 and to transmit signals to and to receive signals from other network nodes (either directly or indirectly) via a network interface 55. The network interface 55 typically includes an appropriate base station – base station interface (such as X2/Xn) and an appropriate base station – core network interface (such as NG-U/NG-C). A controller 57 controls the operation of the v(R)AN node 5 in accordance with software stored in a memory 59. The software may be pre-installed in the memory 59 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example. 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) signalling between the v(R)AN node 5 and other nodes, such as the UE 3, and the core network nodes. Core network node Figure 7 is a block diagram illustrating the main virtual components of a generic core network node (or function) that can be used in the system shown in Figure 4. As shown, the core network node includes a transceiver circuit 71 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3 and the v(R)AN node 5) via a network interface 75. A controller 77 controls the operation of the core network node in accordance with software stored in a memory 79. The software may be pre-installed in the memory 79 and/or may be downloaded via the telecommunication network 1 or from a removable data storage device (RMD), for example. 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) signalling between the core network node and other nodes, such as the UE 3, v(R)AN node 5, and other core network nodes. Such signaling includes appropriately formatted requests and responses relating to Intelligent Data Collection and Management for Open RAN Intelligent Controllers. Modifications and Alternatives Detailed aspects have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above aspects whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described. In the above description, the UE, the v(R)AN node, and the core network node are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the above aspects, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these. Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like. In the above aspects, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE, the (R)AN node, and the core network node as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE, the (R)AN node, and the core network node in order to update their functionalities. The above aspects are also applicable to ‘non-mobile’ or generally stationary user equipment. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.