Operating a Distributed Unit Part of a Radio Access Network

Abstract

A Distributed Unit (DU) part of a Radio Access Network (RAN) entity comprises a processor system that is configured to provide RAN services. The DU part is operated by: identifying spare capacity in the processor system that is not required to provide the RAN 5 services; and allocating the identified spare capacity to provide additional services that are distinct from the RAN services.

Description

[0001] Operating a Distributed Unit Part of a Radio Access Network

[0002] Technical Field of the Disclosure

[0003] The disclosure concerns operating a Distributed Unit (DU) Part (which may comprise a DU or collocated DU and a Central Unit (CU)) of a Radio Access Network (RAN) entity, for instance forming a base station (for example, a gNodeB of a 5G network architecture). Implementations may include a computer program and / or a controller.

[0004] Backoround to the Disclosure

[0005] Open RAN is a technology architecture concept directed to decoupling the hardware and software components of a Radio Access Network (RAN). It is a RAN that includes open interoperable interfaces and virtualization. In prior art (Non-Open) RANs, the hardware and software components are typically proprietary. Non-Open RAN equipment is generally obtained from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, Open RAN introduces open communication standards for interoperability among various network elements. For Mobile Network Operators (MNOs), Open RAN holds strategic importance as it opens the door to Open Source software over Commercial of the Shelf (COTS) servers and promotes vendor diversity, allowing the integration of new suppliers and enhancing supply chain resilience. It also allows energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, Open RAN facilitates innovation and competition by providing a more dynamic and efficient network environment. Additionally, it provides an opportunity for collaboration with specialist suppliers and facilitates resource optimization by allowing upgrades to software, without necessitating hardware replacements. Open RAN is important in the long-term network innovation strategy of MNOs, offering energy efficiency, supply chain diversification, resilience enhancement, and facilitating innovation and competition.

[0006] Referring to Figure 1 , there are illustrated some of the elements of an example Open RAN system 100, which is here implemented as an edge computing platform. The system 100 may be described with reference to different hardware and software layers of the platform. Although the splitting of technology by function is described here with respect to Open RAN, it may also be applicable to other RAN implementations, in accordance with Third Generation Partnership Project (3GPP) specifications. 3GPP 5G specifications incorporate virtualization and cloud computing into its infrastructure.

[0007] 16985486.SK.SK At the edge Node layer 110, the system comprises one or more physical infrastructure nodes 120A, 120N that meet O-RAN requirements. Each physical infrastructure node 120A may comprise computing 121 , networking 122, GPU 123, and storage 124 components, alongside acceleration technologies 125 for RAN operations (such as forward error correction and other computationally intensive operations that are offloaded to dedicated hardware). Each physical infrastructure node 120A, 120N is configured to host the relevant O-RAN network functions 150, 160, which are implemented at the Open RAN application layer 140. The network functions 150, 160 implemented at the Open RAN application layer 140 may include an Open Centralized Unit (O-CU) 160, an Open Distributed Unit (O-DU) 150, and an Open Radio Unit (O-RU). In alternative RAN implementations, the Open part of the names of these network function deployments may be dropped, such that they are more generally termed CU 160, DU 150 and RU. CU 160 may also be deployed at the edge, collocated with the DU 150. When the CU and DU are collocated, the two network functions may share elements 121 -125. The processes related to the CU may then run on the same processing system as the DU. Such implementations of network functions (whether separate CU and DU or collocated CU-DU) are often termed virtualization at the RAN edge.

[0008] The CU 160, DU 150 and RU network function deployments comprise functional elements for processing different protocols in the RAN protocol stack. The DU 150 comprises: a processor system 151 ; an interfacing portion 152 (for interfacing with the CU 160 and RU). The CU 160 comprises: a processor system 161 ; an interfacing portion 162 (for interfacing with the DU 150).

[0009] At the edge hypervisor or containers / OS layer 130, there exists a collection of edge functions to enable the Open RAN applications 150, 160 to run on the one or more edge hardware nodes 120A. The edge functions may comprise supporting software components, such as an operating system, Containers (stand-alone executable software packages), a Container Orchestration Platforms (such as Kubernetes), a container runtime, and the like. The edge functions may also include the corresponding management and orchestration functions.

[0010] This architecture is designed to be flexible and efficient. Moreover, the RAN can be designed to self-optimize, such that RAN services can be dynamically allocated to the resources, including between CU-DUs, such as discussed in “Dynamic CU-DU Selection for Resource Allocation in O-RAN Using Actor-Critic Learning”, Mollahasani et al., arXiv:2110.00492v1 [cs.NI], 1 Oct 2021 and 2021 IEEE Global Communications Conference (GLOBECOM). IEEE, 2021. WO-2022 / 125752 also considers more general

[0011] 16985486.SK.SK reallocation of excess capacity of the computing hardware in radio-based networks. Nevertheless, it is desirable to improve the efficiency of implementation, in terms of energy usage and capacity utilization.

[0012] Summary of the Disclosure

[0013] Against this background, the present disclosure provides a method for operating a Distributed Unit (DU) part (typically a DU or collocated Central Unit (CU)-DU) of a Radio Access Network (RAN) entity according to claim 1 , a computer program in line with claim 14 and a controller for operating a DU part (DU / CU-DU) of a RAN as defined by claim 15. Other preferred features are disclosed with reference to the claims and in the description below.

[0014] It has been recognized that, in a RAN architecture (and especially Open RAN), the edge-DU / CU-DU often has spare CPU capacity. This may be due to variations in traffic load, network conditions, and / or user demand. However, this unused capacity remains underutilized, leading to inefficiencies and underutilization. A resource allocation mechanism is therefore proposed to improve efficiency and utilization of the processor system at the DU / CU-DU, which is normally intended to provide RAN services.

[0015] Spare capacity in the processor system, not required to provide the RAN services, is identified. This identified spare capacity is then allocated to provide additional services that are distinct from (and in particular, unrelated to) the RAN services. A wide range of additional services can be provided in this way with significant benefits. These include: efficiency (by maximizing resource utilization, thereby making best use of the energy powering the DU / CU-DU); performance (processing capability at the edge would be able to provide low latency for data exchange); scalability ( neighbour nodes can dynamically create clusters on the go) segregation (sensitive data can be maintained at the edge of the network, to avoid “cloud exposure”); and resilience (fault tolerance may be improved by distributing tasks across multiple DU parts, that is DU / CU-DUs). The identifying and / or allocating may be performed at the DU part (DU / CU-DU) or a controller, which may be distinct or separate from the DU part (DU / CU-DU).

[0016] Spare capacity can be identified in a variety of ways. One approach is to monitor utilisation of the processor system to provide the RAN services (that is, how much CPU and / or memory capacity is utilised). Additionally or alternatively, provision of the RAN services may be monitored (for instance, by considering the traffic load on any RAN cells

[0017] 16985486.SK.SK serviced by the DU / CU-DU). Realtime spare capacity may be identified by monitoring, for instance.

[0018] In one approach, the identification of spare capacity may be done predictively. Spare capacity may be predicted, for instance, based on one or more of: previous utilisation of the processor system to provide the RAN services; previous provision of the RAN services; previous RAN traffic patterns; and previous demand for computational resource to provide the additional services. Such predictions may be made using machine learning algorithms, for example. Predicting spare capacity can encompass estimating when any requests for additional services will be received and / or estimating when capacity will be available in the processor system (that is, because the computational resource required for the RAN services will be lower than its capacity). Spare capacity predictions can be made dynamically. Additionally or alternatively, the predictions may be used for allocating additional services in the future (that is, to envisaged spare capacity).

[0019] Spare capacity, once identified, may be allocated by comparing a parameter or set of parameters of the additional services to the identified spare capacity. For example, additional services may have a resource requirement (in terms of computations, for example in terms of cycles, and / or memory), a latency consideration or they may have a target time frame or time duration. Another issue is whether the DU part (DU / CU-DU) can segregate data, since this may be relevant to certain additional services. Where multiple additional services are available for allocation, the comparison of the one or more parameters with a characteristic (or characteristics) of the identified spare capacity may allow improved resource allocation.

[0020] The additional services are typically scheduled to the identified spare capacity prior to allocation.

[0021] RAN services allocated to the processor system may be reallocated to another DU part (DU / CU-DU), for example, for load balancing reasons. It will also be understood that the DU part (DU / CU-DU) may accept reallocated RAN services from another DU part (DU / CU-DU). Additionally or alternatively, RAN services may be prioritized over the additional services at the DU part (DU / CU-DU). Spare capacity that is not required to provide the RAN services at the processor system after the reallocating and / or prioritizing can then be identified.

[0022] Spare capacity identification and / or allocation of the additional services are advantageously performed repeatedly (for example, at intervals) and / or dynamically (for instance, in real time), to account for changes in the RAN services. This allows the resources of the processing system to be allocated in an efficient manner.

[0023] 16985486.SK.SK Although allocation of additional services at a single DU part (DU / CU-DU) may have been understood above, the additional services may be distributed between DU parts (DU / CU-DUs), for example, by cooperation between DU parts (DU / CU-DUs) to provide the additional services.

[0024] Options for the additional services may include one or more of: data processing and / or analysis; machine learning model training; algorithm execution; grid computing; content caching; data optimization and / or compression; multi-access edge computing; and piracy shielding. The additional services may originate from one or more of: a User Equipment (UE) utilising the RAN; a UE associated with a subscriber of a cellular network operating the RAN; a Mobile Network Operator (MNO) operating the RAN; and a system external to the cellular network operating the RAN.

[0025] All aspects may be implemented as a computer program and / or as a controller (which may form part of a DU / CU-DU or be distinct or separate from it). A DU part (that is, DU / CU-DU) comprising such a controller may also be considered.

[0026] Brief Description of the Drawings

[0027] The approach of the disclosure may be put into practice in various ways, one of which will now be described by way of example only and with reference to the accompanying drawings in which:

[0028] Figure 1 illustrates some of the elements of an example Open RAN system; and Figure 2 shows a flowchart of a process in line with an embodiment of the disclosure.

[0029] Detailed Description of Preferred Embodiments

[0030] The present disclosure proposes a dynamic resource allocation mechanism that may intelligently utilize spare CPU cycles and / or spare RAM resources of the DU or collocated CU-DU, which for the purposes of this disclosure, may be termed a DU part. In particular, it considered operating a DU 150 or CU-DU 160-150 of a RAN entity (for instance, a base station, such as a gNodeB or gNB in 5G networks). As discussed above, the DU 150150 comprises a processor system 151 that is configured to provide RAN services. Where a collocated CU-DU is implemented (not shown), they may share a processor system and / or memory.

[0031] In the context of a collocated CU-DU, spare DU processing capabilities may be considered essentially spare CU-DU capabilities. It might also be possible to adjust dynamically the processing capabilities assigned to the CU. The DU part in the

[0032] 16985486.SK.SK discussions below may thus indicate a separate DU or CU-DU, depending on the specific implementation.

[0033] Referring now to Figure 1 , there is shown a flowchart of a process in line with an embodiment of the disclosure. In an identification step 200, spare capacity of the processor system 151 of the DU part (DU 150 or CU-DU 160-150) is identified. This spare capacity in the processor system is not required to provide the RAN services.

[0034] There are a number of approaches for such identification 200. A monitoring process 201 may be used to monitor resources. In general, the monitoring process 201 may be considered to comprise monitoring utilisation of the processor system to provide the RAN services and / or monitoring provision of the RAN services, such that the spare capacity can be identified thereby. For example, the CPU utilization, memory, and other relevant metrics of the DU part (DU / CU-DU) may be monitored, for example continuously. In this way, periods of low load may be identified (for example, during off-peak hours or when nearby cells are less congested). Additionally or alternatively, the load on the RAN entity serviced by the DU part (DU / CU-DU) may be monitored to achieve the same effect.

[0035] Additionally or alternatively, the identification 200 may comprise a prediction process 202. In general, the prediction process 202 may predict spare capacity based on one or more of: previous utilisation of the processor system to provide the RAN services; previous provision of the RAN services; previous RAN traffic patterns; and previous demand for computational resource to provide the additional services. For example, the prediction process 202 uses predictive analytics, especially based on historical data and machine learning algorithms, to predict future traffic patterns and / or utilisation of the processor system 151. In particular, the prediction process 202 can estimate: when additional computational resources will be needed; and / or how the periods of low load are distributed during a predefined time period (for instance, one or more weeks, one or more months or one or more years).

[0036] In general terms, the prediction process 202 may comprise estimating when any requests for additional services will be received and / or when computational resource in the processor system required to provide the RAN services will be lower than a total available computational resource in the processor system. Optionally, the identified spare capacity is allocated for a future time period. This may involve scheduling, as will be discussed further below.

[0037] In an allocating step 210, additional services are identified. These additional services are distinct from the RAN services (at least in the sense that they are not directly or at all connected with provision of a RAN and / or a RAN node, such as a base station).

[0038] 16985486.SK.SK As part of the allocating 210, the additional services are allocated to the identified spare capacity. In this way, the identified spare capacity can provide the additional services thereby. This may be considered a form of resource redistribution. Effectively, during low- load periods, the spare CPU cycles and / or spare RAM of the DU part (DU / CU-DU) are reallocated to the additional services. Low load periods may be at night, for instance. The additional services may be identified through an interface in the DU part (DU / CU-DU), a controller in the DU part (DU / CU-DU) or a controller that is distinct or separate from the DU part (DU / CU-DU). New network architectural interfaces may be desirable for this purpose, for example, if a User Equipment (UE) is to instruct the additional services, a new interface may be specified for the network.

[0039] Examples of additional services may include: data processing from mobile users (for instance, computing data generated by users via mobile devices and / or optimizing for network efficiency and real-time processing); Al Model Training of the Mobile Network Operator (MNO) (for instance, training Al models during night-time, dynamic spectrum management: optimizing frequency allocation based on real-time conditions and / or network optimization: running optimization algorithms to improve overall network performance); and third-party algorithms.

[0040] Other examples of additional services, particularly third-party algorithms, may be based on the algorithm and / or service requirements. Use cases with low latency requirements may include: dangerous animal detection and deterrence (for instance, detecting nocturnal predators or carriers of infectious diseases to protect farms); and cloud or fog computing applications (for example, sensor networks). Use cases without low latency requirements, but leveraging on segregation (because the DU / CU-DU can segregate data, as an edge processing device): a payroll algorithm (where the data is private in nature and confidentiality and security of the data should be guaranteed); and session management with distributed cache. Other use cases without low latency requirements may include grid computing applications (for instance, distributed data processing, weather modelling, scientific research); deployment of content delivery networks (for example, caching of contents to reduce load and network traffic); and video traffic optimization. Other examples may include Mobile Private Network, Multi-access Edge Computing (MPN MEC); and prevention of illegal sharing of streaming contents (implementing effective piracy shields could be potentially addressed together with previous Content Delivery Network, CDN, distribution).

[0041] In general terms, the additional services may comprise one or more of: data processing and / or analysis; machine learning model training; algorithm execution; grid

[0042] 16985486.SK.SK computing; content caching; data optimization and / or compression; multi-access edge computing; and piracy shielding. In embodiments, the additional services may originate from one or more of: a UE utilising the RAN; a UE associated with a subscriber of a cellular network operating the RAN; a Mobile Network Operator (MNO) operating the RAN; and a system external to the cellular network operating the RAN.

[0043] Advantageously, the allocating step 210 may comprise comparing at least one parameter (or characteristic) of the additional services to the identified spare capacity (that is, at least one parameter or characteristic of the identified spare capacity). Beneficially, the at least one parameter of the additional services comprises one or more of: a computational cycle (for example, CPU) requirement; a memory requirement (for instance, in terms of RAM); a latency requirement; and a data segregation requirement. Correspondingly, the at least one parameter or characteristic of the identified spare capacity may relate to one or more of: a computational cycle (for example, CPU) availability; a memory availability (for instance, in terms of RAM); a latency constraint; and a data segregation availability.

[0044] In a load balancing step 220 (which is shown as taking place after the identification step 200 and the allocating step 210, but which can take place before or between these steps), the DU / CU-DU cooperates with other DU / CU-DUs for load balancing of RAN services across cells. For example, the DU / CU-DU might collaborate with neighbouring DU / CU-DUs to balance computational load as an optional addition to resource sharing. If one DU / CU-DU experiences high demand, it can offload tasks to one or more nearby DU / CU-DUs with spare capacity. A safe margin may be applied on the cluster. Separated orchestration may be required for such an approach.

[0045] In general terms, RAN services allocated to the processor system of the DU / CU-DU may be reallocated to a processor system of another DU / CU-DU. Additionally or alternatively, RAN services at the processer system of the DU / CU-DU may be prioritized over the additional services. Either or both of these may be considered a form of load balancing at the DU part (DU / CU-DU). The identified spare capacity in the processor system may then comprise (or be) spare capacity that is not required to provide the RAN services at the processor system after the reallocating and / or the prioritizing. In other words, the identification step 200 and / or the allocating step 210 may be based on spare capacity after load balancing).

[0046] As discussed above, an initial part of the allocating step 210 optionally comprises scheduling the additional services to the identified spare capacity prior to the allocating. This is advantageous, especially for future allocations of services. For instance, the

[0047] 16985486.SK.SK method may identify spare capacity at specific future times and schedule one or more of the identified additional services for those times, but the allocation may not take place until just prior to the time. This allows changes to the scheduling prior to allocation, for example when changes are made to the additional services and / or to the identified spare capacity.

[0048] As will be seen in Figure 2, a feedback loop 230 is formed in the process. Thus, the process repeats either at intervals (typically regular) and / or dynamically (for example, when a change in the spare capacity is indicated). In this way, the system may continuously adapt based on real-time feedback. For example, if unexpected traffic spikes occur, the DU part (DU / CU-DU) may dynamically reallocate resources to handle the load. Optionally, further improvement in load balancing among DU parts (DU / CU-DUs) may be achieved by using different DU part (DU / CU-DUs) orchestrated in a CaaS / PaaS (Container as a Service / Platform as a Service) environment to offer a complete managed proprietary (to a specific network operator) “Fog” platform in a geographic set of DU parts (DU / CU-DUs). In general terms, the allocating step 210 may comprise cooperating with one or more other DU parts (DU / CU-DUs) to provide the additional services.

[0049] As noted above, the identifying process 200 and / or allocating step 210 may be performed at a controller, which can be located at the DU part (DU / CU-DU), distinct from the DU part (DU / CU-DU) or a combination thereof. For this reason, a separate controller is not shown in the drawings, but can conceptually be understood.

[0050] A number of specific applications or use cases of the approach in according to the disclosure can be used. A first possible use case is to make use of the distributed computing (proximate or nearby cloud or “fog” computing) offered by the spare capacity of the DU / CU-DU to deploy and provision in short time and on demand a Mobile Private Network (MPN) for any users or subscribers of the cellular network requesting this. Current MPN implementations may be based on ad-hoc hardware provisioning that is commissioned near customer premises. An approach according to the disclosure may enable MPN provisioning on the fly. This may be helpful for local events with special connectivity, for instance a fair. It should be noted that MPN provisioning is distinct from the RAN services for which the base station (DU / CU-DU) is configured.

[0051] A second possible use case relates to localized network slicing. A network slice could be related to a geographical area and the idea may be to deploy the slice only at nearby cell(s) level (for instance, events, concert, fair, sporting events) could benefit from the computing capabilities offered by the spare capacity of DU / CU-DU.

[0052] Any of the methods described herein may be implemented as a computer program. The computer program may be configured to control a network node or entity to perform

[0053] 16985486.SK.SK any method according to the disclosure. A controller, server or network node of a cellular network may also be provided, configured to operate in accordance with certain methods disclosed herein. For example, the controller, server or network node may include a processor and at least one communication interface, particularly comprising one or both of a transmitter and receiver.

[0054] Although specific embodiments have now been described, the skilled person will understand that various modifications and variations are possible. For example, whilst the disclosure is described in relation to existing network architecture, it will be understood that changes to the architecture (and / or nomenclature) are possible, but the present disclosure may still be applicable in this case. Also, combinations of any specific features shown with reference to one embodiment (or aspect) or with reference to multiple embodiments (or aspects) are also provided, even if that combination has not been explicitly detailed herein.

[0055] 16985486.SK.SK

Claims

CLAIMS1 . A method for operating a Distributed Unit (DU) part of a Radio Access Network (RAN) entity, the DU part comprising a processor system that is configured to provide RAN services, the method comprising: identifying spare capacity in the processor system that is not required to provide the RAN services; and allocating the identified spare capacity to provide additional services that are distinct from the RAN services.

2. The method of claim 1 , wherein the identifying spare capacity comprises: monitoring utilisation of the processor system to provide the RAN services and / or monitoring provision of the RAN services, such that the spare capacity can be identified thereby.

3. The method of claim 1 or claim 2, wherein the identifying spare capacity further comprises: predicting spare capacity based on one or more of: previous utilisation of the processor system to provide the RAN services; previous provision of the RAN services; previous RAN traffic patterns; and previous demand for computational resource to provide the additional services.

4. The method of claim 3, wherein the predicting spare capacity comprises estimating when any requests for additional services will be received and / or when computational resource in the processor system required to provide the RAN services will be lower than a total available computational resource in the processor system.

5. The method of claim 3 or claim 4, wherein the identified spare capacity is allocated for a future time period.

6. The method of any preceding claim, wherein the allocating the identified spare capacity comprises comparing at least one parameter of the additional services to the identified spare capacity.16985486.SK.SK7. The method of claim 6, wherein the at least one parameter of the additional services comprises one or more of: a computational cycle requirement; a memory requirement; a latency requirement; and a data segregation requirement.

8. The method of any preceding claim, further comprising: reallocating RAN services allocated to the processor system of the DU part to a processor system of another DU part and / or prioritizing RAN services at the processer system of the DU part over the additional services; and wherein the identified spare capacity in the processor system comprises spare capacity that is not required to provide the RAN services at the processor system after the reallocating and / or prioritizing.

9. The method of any preceding claim, wherein: the identifying and allocating are performed repeatedly and / or dynamically, to account for changes in the RAN services; and / or the method further comprises scheduling the additional services to the identified spare capacity prior to the allocating.

10. The method of any preceding claim, wherein the allocating the identified spare capacity comprises cooperating with one or more other DU parts to provide the additional services.11 . The method of any preceding claim, wherein the additional services comprise one or more of: data processing and / or analysis; machine learning model training; algorithm execution; grid computing; content caching; data optimization and / or compression; multiaccess edge computing; and piracy shielding.

12. The method of any preceding claim, wherein the additional services originate from one or more of: a User Equipment (UE) utilising the RAN; a UE associated with a subscriber of a cellular network operating the RAN; a Mobile Network Operator (MNO) operating the RAN; and a system external to the cellular network operating the RAN.

13. The method of any preceding claim, wherein the identifying and / or allocating is performed at a controller distinct from the DU part.16985486.SK.SK14. A computer program, configured when operated by a processor to perform the method of any preceding claim.

15. A controller for operating a Distributed Unit (DU) part of a Radio Access Network (RAN), the controller configured to perform the method of any one of claims 1 to 13.16985486.SK.SK

Images