Hardware acceleration system in a VRAN architecture and method of operating the same

Abstract

The present disclosure relates to a hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture. The system comprises a number of hardware accelerators (4), HA; a fronthaul, FH, switch (14) implemented between the HAs (4) and a number of associated Radio Units (5), RUs, wherein the FH switch (14) is configured to behave as a virtual HA towards the associated RUs (5) and as a virtual RU towards the HAs (4); an L1-L2 broker (15) implemented between the HAs (4) and a number of associated Distributed Units (1), DUs, wherein the L1-L2 broker (15) is configured to behave as a virtual HA towards the associated DUs (1) and as a virtual DU towards the HAs (4); and an orchestrating unit (16) configured to map the traffic of the RUs (5) and DUs (1) to individual ones of the HAs (4) for processing. Furthermore, a corresponding method of operating a hardware acceleration system in a vRAN architecture is disclosed.

Description

[0001] HARDWARE ACCELERATION SYSTEM IN A VRAN ARCHITECTURE AND METHOD OF OPERATING THE SAME

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

[0003] The present invention relates to a hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture as well as to a method of operating a hardware acceleration system in a vRAN architecture, wherein the system includes a number of hardware accelerators.

[0004] Guided by the O-RAN Alliance, the industry has turned its focus towards RAN virtualization (vRAN), aiming to transition from fixed Base Stations (BSs) to cost-effective, general-purpose computing platforms. Despite the swift adoption of dense vRANs, there is growing apprehension in the industry regarding the energy consumption of such systems. Verizon and Vodafone have established goals to achieve net zero energy emissions by 2040, while China Mobile has committed to reducing energy consumption and carbon emission intensity by at least 20% by the end of 2025. Even prior to the recent spike in energy prices, the energy-related costs in mobile networks have been a predominant factor. The vRAN solutions currently available in the market are not well-aligned with meeting these ambitious targets.

[0005] Unlike more conventional network functions like network switches or firewalls, RAN functions face strict latency constraints in handling wireless signals. Violating processing deadlines, which typically range from 1 to 3 milliseconds depending on the scenario, can result in users losing wireless synchronization with the Base Station (BS), leading to a loss of connectivity. Therefore, a high-quality BS in the industry must consistently meet these deadlines with a 99.999% probability to ensure reliability.

[0006] However, the processing of wireless signals by a BS involves compute-intensive operations such as decoding forward error correction (FEC) codes. This poses achallenge for conventional virtualization platforms based on general-purpose CPUs, as they struggle to achieve the necessary level of reliability required in this context.

[0007] As a result, the industry currently depends on hardware accelerators (HAs) to relieve the burden of the most demanding forward error correction (FEC) processing tasks. HAs, encompassing GPUs, FPGAs, or ASICs, specialize in particular operations, such as FEC in the context of vRANs, contributing significantly to achieving the reliability standards required by the industry.

[0008] It is an objective of the present invention to improve and further develop a system and a method of the initially described type in such a way that the performance and efficiency of inline acceleration can be achieved without losing the flexibility of lookaside acceleration.

[0009] This objective is addressed by the subject-matter of the independent claims.

[0010] In accordance with the invention, the aforementioned object is accomplished by a hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture, the system comprising: a number of hardware accelerators, HA; a fronthaul, FH, switch implemented between the HAs and a number of associated Radio Units, RUs, wherein the FH switch is configured to behave as a virtual HA towards the associated RUs and as a virtual RU towards the HAs; an L1-L2 broker implemented between the HAs and a number of associated Distributed Units, DUs, wherein the L1-L2 broker is configured to behave as a virtual HA towards the associated DUs and as a virtual DU towards the HAs; and an orchestrating unit configured to map the traffic of the RUs and DUs to individual ones of the HAs for processing.

[0011] Furthermore, the aforementioned object is accomplished by a method of operating a hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture, wherein the system includes a number of hardware accelerators, HA, the method comprising: sending data streams between the HAs and a number of associated Radio Units, RUs, via a fronthaul, FH, switch that behaves as a virtual HA towards the associated RUs and as a virtual RU towards the HAs; sending datastreams between the HAs and a number of associated Distributed Units, DUs, via an L1-L2 broker that behaves as a virtual HA towards the associated DUs and as a virtual DU towards the HAs; and mapping, by an orchestrating unit, the traffic of the RUs and DUs to individual ones of the HAs for processing.

[0012] The proposed concept according to the present disclosure generally provides higher flexibility and efficiency to inline hardware acceleration architectures. More specifically, the disclosed systems / methods provide Inline HAs with the flexibility of Look-aside ones to enable inline HA pooling (i.e. , the use of a shared set of inline HAs) and load balancing across several HAs. This improvement is achieved by means of an integration of a fronthaul switch and L1-L2 Broker (that are coordinated through an orchestrator) into a (heterogeneous) hardware acceleration architecture.

[0013] According to the proposed concept, the L1-L2 Broker is operated to behave as a virtual HA towards all Distributed Units it is associated with and to behave as a virtual Distributed Unit with all the HAs it is associated with. Further, the L1-L2 Broker may be operated to dynamically map the traffic of Distributed Units to HAs for processing. On the other hand, the fronthaul switch is operated to behave as a virtual HA with all the Radio Units it is associated with and to behave as a virtual Radio Unit with all the HAs it is associated with. Further, the fronthaul switch may be operated to dynamically map the traffic of Radio Units to HAs for processing. An orchestrator may configure policies on the L1-L2 broker and on the fronthaul switch for proper operation, enabling load balancing, fault-tolerance and resilience.

[0014] The implementation and operation of the above components in accordance with the proposed concept enables pooling accelerators, improve their flexible utilization, and can be seamlessly integrated into current commercial architectures. Accordingly, in various examples, the proposed concept enables Inline hardware acceleration architectures with new capabilities including hardware accelerator (HA) pooling, load balancing across several HAs, switching off HA for energy saving, resiliency to hardware failures, and temporal unavailability due to updates.

[0015] Preferably, the number of HAs includes at least one Inline HA and at least one Lookaside HA. In this way, the system offers maximum flexibility, as the system can takeadvantage of both the high performance and efficiency of the Inline accelerators and the high flexibility of the Look-aside accelerators. Accordingly, the system can dynamically adapt to different operating conditions.

[0016] According to an example, the virtual behaviour of the FH switch can be realized by means of a configuration in which the FH switch modifies the headers of the communications between the RUs and the HA. For instance, the FH switch may be configured to modify the IDs and / or the MAC addresses of the RUs / Has. This would enable an all-to-all communication, in which all RUs could potentially be served by all available HAs.

[0017] According to an example, the FH switch is configured to decide at each time step which specific HA will serve which RU based on a policy provided by the orchestrating unit. In this context, decision periods may be defined, wherein the orchestrating unit can renew the policy for each decision period. Accordingly, upon receiving from the orchestrating unit a policy for a next decision period, the FH switch is informed which of the HAs have to be used during this decision period.

[0018] According to an example, the L1-L2 broker is configured to interface the L1 and the L2 layers and to act as a proxy between the HAs and the DUs. Similar as for the FH switch, the virtual behaviour of the L1-L2 broker can be realized by means of a configuration in which the L1 -L2 broker modifies the headers of the communications between the DUs and the HAs.

[0019] According to an example, the FH switch and the L1-L2 broker are configured to operate together. Specifically, it may be provided that the FH switch is configured to redirect a data stream from a particular RU to a specific one of the HAs to perform L1 operations. Correspondingly, the L1-L2 broker may be configured to redirect the output from the HA in charge to the DU associated with the respective RU.

[0020] According to an example, uplink streams sent from a RU towards its associated DU may be handled as follows: First, upon receipt of user uplink data from a RU, the FH switch modifies the packet headers of the data. Then, it redirects the data with the modified headers to a specific one of the HAs, which is selected in accordancewith the currently applicable policy provided by the orchestrating unit. Next, the HA in charge performs the required L1 operations and sends the resulting output data to the L1-L2 broker. The L1-L2 broker modifies the packet headers of the output data such that the output data is sent to the correct DU, i.e. the DU associated with the RU that is originator of the respective uplink stream.

[0021] Similarly, according to an example, downlink streams sent from a DU towards its associated RU may be handled as follows: First, upon receipt of downlink user data from a DU, the L1-L2 broker modifies the packet headers of the data. Then, it redirects the data with the modified headers to a specific one of the HAs, which is selected in accordance with the currently applicable policy provided by the orchestrating unit. Next, the HA in charge performs the required L1 operations and sends the resulting output data to the to the FH switch. The FH switch modifies the packet headers of the output data such that the output data is sent to the correct RU, i.e. the RU associated with the DU that is originator of the respective downlink stream.

[0022] According to an example, the proposed hardware acceleration system may be integrated into a O-RAN architecture.

[0023] In this context, it may be provided that the FH switch and / or the L1-L2 broker are configured to modify the headers of packets transmitted via O-RAN standardized protocol interfaces. For instance, the O-RAN standardized protocol interface between the RUs and the fronthaul NIC is the evolved Common Public Radio Interface, eCPRI. Accordingly, the FH switch may modify the headers of eCPRI packets, which is the standardized protocol interface between the RUs and the FH NIC. For instance, the FH switch may be configured to use the field ecpriRtcid / ecpriPcid (which, according to O-RAN standard is intended to transport the extended Antenna-Carrier (eAxC) identifier) to identify O-RU / O-DU pairs. Here, O-RU (and O-DU, respectively) denote a RU (and a DU, respectively) in a O-RAN architecture. Specifically, in an example, the FH switch may, upon arrival of a downlink eCPRI packet, change the O-RU port identifier with the identifier of the corresponding O-RU, and may, upon arrival of an uplink eCPRI packet, change theO-DU port identifier with the identifier of the HA that is determined to process the corresponding data stream.

[0024] Similarly, in an 0-RAN implementation, the L1-L2 broker may be configured to modify the headers of packets sent via the functional application platform interface (FAPI), which is the O-RAN standard interface between L1 and L2.

[0025] According to an example, the system may further comprise a Real-Time RAN Intelligent Controller, RT RIC, that is configured to receive metadata from the L1-L2 broker and to compute, based on the received metadata, a radio policy for each DU to reduce the utilization of radio resources. This may help to avoid the saturation of the HAs and thus data loss.

[0026] In various examples, the orchestrating unit may pursue certain objectives when controlling which HA(s) serve each RU / DU pair at each point of time. For instance, the orchestrating unit may select a set of HAs that will be operable for processing incoming each data stream based on load metrics received from the FH switch, the L1 -L2 broker and / or the HAs. In this context, it may be provided that those HAs from the available pool that are not selected to be operable for processing incoming data streams are switched off. This approach proves to be particularly advantageous in terms of energy consumption.

[0027] According to an alternative approach, the orchestrating unit may compute a sharing policy based on load metrics received from the FH switch, the L1-L2 broker and / or the HAs. The sharing policy includes a set of rules that specify which one of the HAs will be used for each data stream. In this context, it may be provided that the sharing policy is calculated based on an objective to prioritize energy-efficient ones of the HAs or to prioritize certain types of HAs that cannot be switched off (e.g., because they are utilized for other purposes, such as machine learning (ML) workloads).

[0028] 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 theother 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

[0029] Fig. 1 is a schematic diagram showing a look-aside hardware acceleration mechanism (left) and an inline hardware acceleration mechanism (right);

[0030] Fig. 2 is a schematic diagram showing an example of the proposed hardware accelerator concept in a vRAN architecture;

[0031] Fig. 3 is a schematic diagram showing an example of the proposed hardware accelerator concept in an O-RAN architecture;

[0032] Fig. 4 is a schematic diagram showing an example based on the concept of Fig. 3 including HA sharing to enable energy savings; and

[0033] Fig. 5 is a schematic diagram showing an example based on the concept of Fig. 3 including a Real-Time RIC.

[0034] Throughout the present disclosure, like reference numbers denote like or at least substantially similar elements.

[0035] In vRAN architectures, there are typically two approaches to offloading computing tasks to hardware accelerators (HAs): Look-aside hardware acceleration and Inline hardware acceleration, which are both discussed in connection with Fig. 1.

[0036] Both diagrams of Fig. 1 show a vRAN DU (virtualized RAN Distributed Unit) 1 including a NIC (Network Interface Card) 2, a processor / CPU 3 and a HA (Hardware Accelerator) 4. The vRAN DU 1 receives user data from a RU (Radio Unit) 5 via its NIC 2, which are processed inside the vRAN DU 1 by the processor 3 and the HA 4. The processed data is then transferred to a CU (Centralised Unit) 6 and from there to the core network 7.Utilizing a Look-aside approach (Fig. 1 , left diagram) enables the CPU 3, to offload some specific network functions (e.g., Forward-Error-Correction, FEC) to the accelerator 4. Upon receiving processed data from the accelerator 4, the CPU 3 can seamlessly return to its original processing context and continue the pipeline execution until the next function that requires acceleration arises. Intel, the world’s largest provider of General-Purpose Processors (GPPs), supports the Look-aside approach. In a Look-aside architecture, the HA 4 can be integrated directly within the CPU chip (as realized by Intel® vRAN Boost) or can be an external component connected to the CPU chip via the PCI bus. The adoption of Look-aside acceleration relies on well-defined APIs to facilitate ecosystem integration.

[0037] Conversely, Inline acceleration (sometimes also termed full L1 acceleration) directly offloads the entire Layer 1 pipeline to the accelerator 4. This approach, which is illustrated in Fig. 1, right diagram, and which is supported by several manufacturers including Marvell Technology, Nvidia, and Qualcomm, reduces the intensity of data transfer via the interface between the CPU 3 and the HA 4. For that reason, this approach can potentially provide higher peak performance and lower energy consumption. However, Inline acceleration loses the flexibility provided by RAN virtualization in terms of, for example, updates of the protocol stack or the use of different HAs for load balancing or energy saving, as the L1 is implemented in hardware.

[0038] Based on this, there are many scenarios in which the concepts disclosed herein may benefit from the performance and efficiency of inline acceleration, while at the same time providing the flexibility of the look-aside architecture. The present disclosure provides methods that enable Inline HAs with the flexibility of Look-aside ones. Thus, Inline HAs can be shared among several Distributed Units (DUs) or the load can be balanced across different HAs. Exemplarily, the following scenarios are enabled by the concepts proposed herein:

[0039] Opportunistic use of HA for energy saving. The vRAN O-Cloud may use a pool of heterogeneous HAs, e.g., including faster and energy-hungry HAs and slower and energy-efficient HAs. These different HAs can be used opportunistically based on the BS’s traffic load or the nature of this traffic (e.g., the size of the transportblocks of data). This is related to applicant’s prior application published as WO 2024 / 160386 A1 , which also considers the opportunistic use of HA for energy saving. In contrast to the concept described in this previous application that is only applicable to Look-aside HAs, the concepts of the present disclosure detailed below can be used with both Look-aside and Inline hardware acceleration.

[0040] Switching off and sharing Inline HA. As mentioned before, due to their high performance, Inline HAs are able to handle traffic peaks. However, most of the time they are underutilized because, on average, the BSs are far from their maximum capacity, especially during the night. Based on this, some of the HAs can be switched off in periods of low demand and others can be shared among several DUs.

[0041] Resiliency and updates. A failure in the Inline HA of a DU implies that the whole BS cannot serve traffic at all. In this case, it would be desirable to use a backup HA in a transparent way for the rest of the system. Similarly, if a HA needs to be firmware-updated or upgraded, the use of a backup HA becomes necessary to avoid the disruption of the BS’s service.

[0042] Temporal reconfiguration of HA. A distinguishing feature of GPUs as a 5G HA lies in their capacity to be shared between demanding 5G Physical Layer processing and various machine learning (ML) workloads executed at DUs. Many DU operations necessitate rapid automated decision-making, often relying on advanced ML models, and the efficient execution of these models requires GPU resources. However, GPU’s resource allocation may change over time due to changes in the traffic demands. Current mechanisms for resource allocation (e.g., Multi-Process Sharing (MPS) mechanism, available at NVIDIA GPUs) need some reconfiguration time in which the GPU cannot operate. Although these reconfiguration periods are short (~200 milliseconds), the BS cannot stop its operation and needs a backup HA to serve the traffic during this period. In a previous approach, a method has been proposed to share the GPU resources among 5G and general ML workloads and to make use of CPU computational resources for backing up the 5G workloads during the GPU reconfiguring. However, this previous approach only considers Look-aside accelerators and cannot be applied to the Inline architecture.Embodiments of the present disclosure relate to systems and methods that provide Inline HAs with the flexibility of Look-aside ones to enable inline HA pooling (i.e. , the use of a shared set of inline HAs) and load balancing across several HAs.

[0043] In the following, an example architecture according to an embodiment of the present disclosure is described in connection with Fig. 2. The illustration presents a multi-Dll server 10 with a number of / V distributed units (Dlls) 1 (right) and their associated radio units (RUs) 5 (left). The multi-DU server 10 also comprises a number of M HAs 4 with their respective fronthaul network interface cards (FH NICs) 11. As illustrated in Fig. 2, some of the HAs 4 are Inline HAs 12 (e.g., the accelerators denoted HA 1 and HA 2 in Fig. 2) and others are Look-aside HAs 13 (e.g., the accelerators denoted HA M-1 and HA M in Fig. 2). In other words, the multi-DU server 10 comprises a pool of HAs 4, wherein the pool includes a number of Inline HAs 12 and a number of Look-aside HAs 13.

[0044] The architecture shown in Fig. 2 presents two novel components: a Fronthaul Switch (FH Switch) 14 and an L1-L2 broker 15.

[0045] The FH switch 14 is an element implemented between the RUs 5 and the HAs 4 to enable the use of several HAs 4 by several RUs 5. The FH switch 14 is configured to behave as a single HA 4 from the point of view of each individual one of the RUs 5. That is, the FH switch 14 masks the HA heterogeneity to the RUs 5. Similarly, the FH switch 14 is configured to behave as a single RU 5 from the point of view of each individual one of the HAs 4 of the multi-DU server’s 10 pool of accelerators. That is, the FH switch 14 masks the RU heterogeneity to the HAs 4. This is key to enable HA sharing even when RUs 5 and HAs 4 only support one-to-one connectivity (i.e., one RU 5 can only be connected to a single HA 4).

[0046] For example, the above effect can be realized by means of the following measures: On the one hand, the FH switch 14 modifies the headers of the communications between the RUs 5 and the HAs 4 to allow the all-to-all communication (i.e., all RUs 5 can potentially be served by all HAs 4). According to an example, modifying the headers of the communications includes modifying the RU / HA ID, MAC address,etc. On the other hand, the FH switch 14 decides at each time step which specific HA 4 will serve which RU 5. This decision is made based on a policy given by an orchestrator 16, as will be described in detail below.

[0047] As shown in Fig. 2, the L1-L2 broker 15 interfaces the L1 and the L2 layers and acts as a proxy between the HAs 4 and the DUs 1. The FH switch 14 is configured to behave as a single HA 4 from the point of view of a DU 1. That is, the FH switch 14 masks the HA heterogeneity to the DUs 1. Similarly, the FH switch 14 is configured to behave as a single DU 1 from the point of view of a HA 4. That is, the FH switch 14 masks the DU heterogeneity to the HAs 4. This is key to enable HA sharing even when DUs 1 and HAs 4 only support one-to-one connectivity (i.e., one DU 1 can only operate with a single HA 4).

[0048] As described in detail hereinafter, the FH switch 14 and the L1-L2 broker 15 may operate together.

[0049] For example, in the architecture illustrated in Fig. 2, for an uplink data stream, the data sent by a respective user to the associated RU 5nneeds to arrive to the corresponding DU 1n, regardless of which of the HAs 4 performs the L1 tasks. Accordingly, the FH switch 14 redirects the data stream from RU 5nto a particular hardware accelerator, termed HA 4m, to perform L1 operations. Then, the L1-L2 broker 15 redirects the output from HA 4mto DU 1n.

[0050] As already mentioned above, the orchestrator 16 controls which HA(s) 4 serve each RU 5 / DU 1 at each point of time according to a certain objective that depends on the use case. Details of the orchestration process are explained below in connection with Figs. 3 and 4.

[0051] In an example, the method according to the proposed process comprises the following steps:

[0052] Uplink streams may be processed as follows:a. The orchestrator 16 sends a policy to the FH switch 14 that informs the FH switch 14 which HA(s) 4 will be used for a particular uplink stream.

[0053] b. A radio unit 5, denoted RU 5n, receives user data which is sent through the FH switch 14.

[0054] c. The FH switch 14 modifies the headers of the data sent by the Rll 5nand redirects the data to a particular one of the HAs 4, denoted HA 4m, in accordance with the policy provided by the orchestrator 16.

[0055] d. The HA 4mperforms the L1 operations and sends the resulting output to the L1- L2 broker 15.

[0056] e. The L1-L2 broker 15 modifies the header of the received data, which is then sent to DU 1n.

[0057] Correspondingly, downlink streams may be processed as follows:

[0058] a. The orchestrator 16 sends a policy that informs which HA(s) will be used. b. The DU 1nreceives user data from higher layers which is sent to the L1-L2 broker 15.

[0059] c. The L1-L2 broker 15 modifies the headers of the data sent by DU 1nand redirects the data to HA 4m.

[0060] d. The HA 4mperforms the L1 operations and sends the resulting output to the FH Switch 14.

[0061] e. The FH Switch 14 modifies the header of the data, which is then sent to RU 5n. f. The RU 5nsends the downlink data to the corresponding user.

[0062] Fig. 3 is a schematic diagram showing an example of the proposed hardware accelerator concept in an O-RAN architecture.

[0063] The example considers the O-RAN standard protocols and interfaces, as shown in Fig. 3, while the FH Switch 14 and the L1-L2 broker 15 are novel components compared to the standard O-RAN architecture.

[0064] Similar to the previous example, the FH switch 14 and the L1-L2 broker 15 operate together. In concrete terms, this cooperation may be realised as follows:The FH switch 14 is key to enable compliance with the O-RAN specifications as, based on the standards, one RU 5 can only be connected to one FH NIC 11 and therefore one Inline HA 12. In accordance with the proposed concept, the FH switch 14 is configured to modify the headers of evolved Common Public Radio Interface (eCPRI) 8 packets, which is the standardized protocol interface between the RUs 5 and the FH NIC 11. In particular, the field ecpriRtcid / ecpriPcid, originally intended to transport the extended Antenna-Carrier (eAxC) identifier, can be used to identify the Rll 5 / DU 1 pair. More specifically, the eAxC consists of an O-DU port identifier, a band sector identifier, a component carrier identifier, and an O-RU port identifier.

[0065] In downlink eCPRI messages, all the O-DUs use the same O-RU identifier, which is assigned to the FH switch 14. Upon the arrival of downlink eCPRI messages, the FH switch 14 changes the O-RU port identifier with that of the corresponding O-RU, which differs from DU to DU.

[0066] In uplink eCPRI messages, all the O-RUs use the same O-DU identifier, which is assigned to the FH switch 14. Upon the arrival of uplink eCPRI messages, the FH switch 14 changes the O-DU port identifier with that of the corresponding HA, which should process that data stream.

[0067] The L1-L2 broker 15 interfaces the L1 and the L2 layers using functional application platform interface (FAPI) 9, which is the standard interface between L1 and L2. The L1-L2 broker 15 is key to enable compliance with today’s inline accelerators, which imposes a one-to-one mapping between DUs and HAs. Similarly to the FH switch 14, the L1-L2 broker 15 acts as a virtual L1 processor from the perspectives of the O-DUs 1, i.e. the one processor each O-DU 1 communicates with. From the perspective of the Has 4, the L1-L2 broker 15 acts as a single virtual O-DU 1 the HAs 4 are associated with.

[0068] Finally, as depicted in Fig. 3, the Infrastructure Management Service (IMS) 17 of the O-RAN architecture acts as orchestrator. Specifically, IMS 17 may be used to compute policies that are enforced by the FH switch 14 and the L1-L2 broker 15. The FH switch 14 and the L1-L2 broker 15 operate together as described to ensure the proper end-to-end operation of the system.Fig. 4 is a schematic diagram showing an example based on the concept of Fig. 3 including HA sharing to enable energy savings. According to this example, a subset of the HAs 4 implemented inside the multi-DU server 10 is allowed to handle all the incoming traffic of the system while the rest of the HAs 4 are switched off to save energy. This behavior is suitable for periods of low traffic load (e.g., during nighttime). When the traffic load increases, more of the HAs 4 may be switched on, especially depending on the actual demand. In the illustrated situation, all available HAs 4 implemented inside the multi-DU server 10 are switched off, except for one HA 4, namely Inline HA 42, 12, which is assumed to have enough resources to process the current traffic load alone.

[0069] In the example of Fig. 4, the IMS 17 may be configured to check the load of the system (e.g., the total traffic load and / or the utilization of the active HAs 4) and, if this metric is low enough, e.g., below a predefined threshold some of the HAs 4 may be switched off. When the metric increases again, e.g., above a predefined threshold, the IMS 17 switches on some of the HAs 4 with the objective of serving all the traffic, i.e. , to avoid the saturation of the HAs 4 and therefore losing traffic.

[0070] In an embodiment, the proposed process comprises the following steps every decision period of 1-100 seconds:

[0071] 1. The IMS 17 receives several metrics from the FH switch 14, the L1-L2 Broker, and each of the HAs 4 of the system. For instance, this metric may represent the total traffic load, the utilization of the active HAs 4, or any predefined combination of both parameters. It is understood that other parameters not expressly mentioned may be considered likewise.

[0072] 2. Based on the received metric(s), the IMS 17 computes the set of HAs 4 that will be operating during the next decision period. The rest of the HAs 4 are switched off.

[0073] 3. The system operates for the duration of the decision period with the HA configuration selected by the IMS 17. Then the operation returns to step 1.Referring again to Fig. 3, in another example, the traffic load is balanced across all available HAs 4 with a given objective. Envisaged concepts may include the following examples:

[0074] In certain scenarios, the pool of HAs 4 available in a system, for instance the pool of HAs 4 implemented on the multi-DU server 10 depicted in Fig. 3, may include HAs 4 that differ in terms of processing speed and energy consumption. For instance, the pool may include a number of HAs 4 that are fast and energy hungry and other HAs 4 that are slower and energy efficient. In such a scenario, the IMS 17 may be configured to prioritize the energy-efficient HAs 4 and only use the energy-hungry HAs 4 when necessary (e.g., traffic peak, high traffic during peak hour).

[0075] According to another scenario, there may be a preference to use, if possible, only a certain type of HA 4, e.g., because they are more versatile than other types or cannot be switched off. For example, GPU can be shared between 5G and general-purpose machine learning (ML) workloads. Therefore, in some systems, the GPUs cannot be switched off because they are used by ML algorithms. Therefore, prioritizing them to process 5G workloads can optimize the utilization of the system. When the traffic load exceeds the capacity of the available GPUs, other HAs 4 may be used.

[0076] In an embodiment, the proposed process comprises the following steps every decision period of 1-100 seconds:

[0077] 1. The IMS 17 receives several metrics from the FH switch 14, the L1-L2 broker 15, and each of the HAs 4. For instance, this metric may represent the total traffic load, the utilization of each of the HAs 4, or any predefined combination of both parameters. It is understood that other parameters not expressly mentioned may be considered likewise.

[0078] 2. Based on the received metrics, the IMS 17 computes a sharing policy that will be used during the next decision period. The sharing policy is a set of rules that indicate which HA 4 will be used for each data stream.

[0079] 3. The system operates for the duration of the decision period with the sharing policy selected by the IMS 17. Then the operation returns to step 1.According to a further example of the present disclosure, when a HA 4 is not available due to an external cause, the traffic load may be redirected to another available HA 4 based on the architecture in illustrated in Fehler! Verweisquelle konnte nicht gefunden werden.Fig. 3. The external causes of HA 4 unavailability include, but are not limited to, hardware failure of HA 4, HA 4 update (physical or logical), and HA 4 reconfiguration (e.g., reconfiguration of the MPS (multi-process service) mechanism of a GPU).

[0080] When a HA 4 is unavailable due to hardware failure, the traffic load redirection may be performed in a reactive way. Otherwise (e.g., HA 4 updates or reconfigurations), the IMS 17 may reconfigure the FH switch 14 and the L1-L2 broker 15 proactively in advance (assuming the time windows for updates / reconfigurations are known) to avoid the use of the HA 4 that will be unavailable.

[0081] Fig. 5 is a schematic diagram showing an example based on the concept of Fig. 3. Insofar as the components involved and the mode of operation of the system are the same as in the example in Fig. 3, a general description is omitted here and only the differences to the example in Fig. 3 are explained.

[0082] In contrast to the example of Fig. 3, the multi-DU server 10 depicted in Fig. 5 includes a Real-Time RAN Intelligent Controller, RT RIC 18. The RT RIC 18 is a new component, which is not included in the standard O-RAN architecture and which operates in finer time scales (~1 millisecond) compared to the RICs included by O-RAN, i.e. it operates in real-time or quasi real-time. In the illustrated example, the RT RIC 18 is used to compute radio policies and avoid the saturation of the HAs 4 and therefore the data loss. Generally, the RT RIC 18 is useful in cases where the system is not configured at full capacity, e.g., in cases where a subset of the available HAs 4 is switched off, as basically shown in Fig. 4. In these cases, the RT RIC 18 can be utilized to compute a radio policy for each DU 1, where the radio policies aim to reduce the utilization of radio resources (i.e., part of the available radio resources will be unused). As already mentioned above, the RT RIC 18 operates in real-time, i.e., the radio resource utilization can be decided for each transport block (TB). As shown in Fig. 5, the RT RIC 18 computes the radio policiesbased on metadata received from the L1-L2 broker 15. For instance, this metadata may include information on the queue state of the available HAs 4.

[0083] In summary, at least one of the examples of the present disclosure has at least one of the following features and / or at least one of the following advantages:

[0084] - enables the flexibility of look-aside accelerators to inline accelerators;

[0085] - enables inline accelerators to be part of a pool of hardware accelerators; - enables load balancing between inline accelerators and other inline accelerators or other types of processors;

[0086] - enables fault-tolerance, resilience and firmware updates or HA upgrades without service disruption.

[0087] Although the proposed concepts have been described in connection with the figures in implementations where the hardware accelerators are integrated into a multi-DU server, it is to be understood that the proposed concepts are not limited to such implementation, i.e. the pool of hardware accelerators can likewise be a part of any other device or system.

[0088] When certain aspects are mentioned in relation to a device or system, they should also be considered as descriptions of the corresponding methods. For example, a block, component, or functional aspect of the device or system may correspond to a method step or feature of the related method. Therefore, aspects described regarding a method should also be understood as depicting a corresponding element, property, or functional feature of the corresponding device or system. In simpler terms, if something is described in relation to a device or system, it can also be applied to the corresponding method, and vice versa.

[0089] 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. Althoughspecific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.L i s t o f r e f e r e n c e s i g n s

[0090] virtualized RAN Distributed Unit, vRAN, DU Network Interface Card, NIC

[0091] Processor / CPU

[0092] Hardware Accelerator, HA

[0093] Radio Unit, RU

[0094] Centralised Unit, CU

[0095] core network

[0096] evolved Common Public Radio Interface, eCPRI Functional Application Platform Interface, FAPI multi-DU server

[0097] fronthaul network interface cards, FH NIC

[0098] Inline HAs

[0099] Look-aside HA

[0100] fronthaul switch, FH switch

[0101] L1-L2 broker

[0102] orchestrator

[0103] Infrastructure Management Service, IMS

[0104] Real-Time RAN Intelligent Controller, RIC

Claims

C l a i m s1. Hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture, the system comprising:a number of hardware accelerators (4), HA;a fronthaul, FH, switch (14) implemented between the HAs (4) and a number of associated Radio Units (5), RUs, wherein the FH switch (14) is configured to behave as a virtual HA towards the associated RUs (5) and as a virtual RU towards the HAs (4);an L1-L2 broker (15) implemented between the HAs (4) and a number of associated Distributed Units (1), DUs, wherein the L1-L2 broker (15) is configured to behave as a virtual HA towards the associated DUs (1) and as a virtual DU towards the HAs (4); andan orchestrating unit (16) configured to map the traffic of the RUs (5) and DUs (1 ) to individual ones of the HAs (4) for processing.

2. The system according to claim 1 , wherein the number of HAs (4) includes at least one Inline HA (12) and at least one Look-aside HA (13).

3. The system according to claim 1 or 2, wherein the FH switch (14) is configured to modify the headers of the communications between the RUs (5) and the HA (4).

4. The system according to any of claims 1 to 3, wherein the FH switch (14) is configured to decide at each time step which specific HA (4) will serve which RU (5) based on a policy provided by the orchestrating unit (16).

5. The system according to any of claims 1 to 4, wherein the L1-L2 broker (15) is configured to interface the L1 and the L2 layers and to act as a proxy between the HAs (4) and the DUs (1).

6. The system according to any of claims 1 to 5, wherein the FH switch (14) and the L1-L2 broker (15) are configured to operate together, wherein the FH switch (14)is configured to redirect a data stream from a particular RU (5) to a specific one of the HAs (4) to perform L1 operations, and wherein the L1-L2 broker (15) is configured to redirect the output from said HA (4) to the DU (1) associated with said RU (5).

7. The system according to any of claims 1 to 6, wherein the vRAN, architecture is a 0-RAN architecture, wherein the FH switch (14) is configured to modify the headers of evolved Common Public Radio Interface (8), eCPRI, packets.

8. The system according to claim 7, wherein the FH switch (14) is configured, upon arrival of a downlink eCPRI (8) packet, to change the O-RU port identifier with the identifier of the corresponding O-RU, and upon arrival of an uplink eCPRI (8) packet, to change the O-DU port identifier with the identifier of the HA (4) that is determined to process the corresponding data stream.

9. The system according to any of claims 1 to 8, wherein the vRAN, architecture is a O-RAN architecture, the system further comprising a Real-Time RAN Intelligent Controller, RT RIC (18), that is configured to receive metadata from the L1-L2 broker (15) and to compute, based on the received metadata, a radio policy for each DU (1) to reduce the utilization of radio resources.

10. A method of operating a hardware acceleration system in a virtualized Radio Access Network, vRAN, architecture, in particular a hardware acceleration system according to claims 1 to 9, wherein the system includes a number of hardware accelerators, HA (4), the method comprising:sending data streams between the HAs (4) and a number of associated Radio Units, RUs (5), via a fronthaul, FH, switch (14) that behaves as a virtual HA towards the associated RUs (5) and as a virtual RU towards the HAs (4);sending data streams between the HAs (4) and a number of associated Distributed Units, DUs (1), via an L1-L2 broker (15) that behaves as a virtual HA towards the associated DUs (1) and as a virtual DU towards the HAs (4); and mapping, by an orchestrating unit (16), the traffic of the RUs (5) and DUs (1 ) to individual ones of the HAs (4) for processing.

11. The method according to claim 10, further comprising:modifying, by the FH switch (14), the packet headers of uplink user data received from a RU (5) and redirecting the user data to a specific one of the HAs (4) in accordance with a policy provided by the orchestrating unit (16);performing, by said specific one of the HAs (4), the L1 operations and sending the resulting output data to the L1-L2 broker (15); andmodifying, by the L1-L2 broker (15), the packet headers of the output data such that the output data is sent to the DU (1) associated with said RU (5).

12. The method according to claim 10 or 11 , further comprising:modifying, by the L1 -L2 broker (15), the packet headers of downlink user data received from a DU (1 ) and redirecting the user data to a specific one of the HAs (4) in accordance with a policy provided by the orchestrating unit (16);performing, by said specific one of the HAs (4), the L1 operations and sending the resulting output data to the FH switch (14); andmodifying, by the FH switch (14), the packet headers of the output data such that the output data is sent to the RU (5) associated with said DU (1 ).

13. The method according to any of claims 10 to 12, further comprising:selecting, by the orchestrating unit (16) from the number of HAs (4) based on load metrics received from the FH switch (14), the L1-L2 broker (15) and / or the HAs (4), a set of HAs (4) that will be operable for processing incoming each data stream, while the remaining HAs (4) are switched off.

14. The method according to any of claims 10 to 12, further comprising:computing, by the orchestrating unit (16) based on load metrics received from the FH switch (14), the L1-L2 broker (15) and / or the HAs (4), a sharing policy including a set of rules that specify which one of the HAs (4) will be used for each data stream.

15. The method according to claim 14, wherein the sharing policy is calculated based on an objective to prioritize energy-efficient ones of the HAs (4) or to prioritize certain types of HAs (4) that cannot be switched off.

Images