Wireless communication system, and control method and program for same

Abstract

In an SMO (3), a Non-real time RIC (32) includes a traffic prediction unit (321) and a computation hardware selection unit (322) as rApps. The traffic prediction unit (321) predicts, for each base station device, the traffic demand on the basis of the Non-real time RIC (32). The computation hardware selection unit (322) determines, for each base station device, whether or not the base station device requires ACC on the basis of the result of the traffic demand prediction, and selects hardware that handles computation of base station processing in each base station device on the basis of the result of the determination.

Description

Wireless communication system, control method and program thereof

[0001] The present invention relates to a wireless communication system and a control method and program thereof, and more particularly to a wireless communication system and a control method and program thereof that can reduce the power consumption of a base station system by dynamically switching hardware that handles base station processing in accordance with the traffic load of the wireless communication system. This application claims priority to Japanese Patent Application No. 2024-13828, filed in Japan on February 1, 2024, the contents of which are incorporated herein by reference.

[0002] The fifth-generation wireless communication system (5G) is expected to further increase demand for high-capacity, low-latency, and multi-connection communications, and further advancements are required to meet these demands.

[0003] In wireless communication systems, as disclosed in Non-Patent Publication 1, the functions of a base station, which have traditionally been integrated, are being divided into a session unit (CU: Centralized Unit) that performs session processing, a distributed unit (DU: Distributed Unit) that performs baseband processing, and a radio unit (RU: Radio Unit) that performs radio processing, and specifications are being considered by the O-RAN Alliance to open up the interface specifications between each unit.

[0004] The Radio Access Network (RAN) architecture being considered by the O-RAN Alliance envisions that the CUs and DUs that make up the RAN, as well as the RAN Intelligent Controller (RIC) that controls them in an integrated manner, will be deployed as Network Functions (NF) on a cloud platform called O-Cloud. The RAN, O-Cloud, and RIC will be controlled by an orchestrator (Service Management Orchestration: SMO).

[0005] On the other hand, from the viewpoint of cost reduction and ease of operation, virtualized base stations, in which CUs and DUs are virtually implemented as software on general-purpose servers or computers, are being studied.

[0006] In addition, since it is expected that the processing load of CUs and DUs will increase in order to process the increased traffic load due to the advancement of 5G, Patent Document 1 considers a technology for dynamically increasing or decreasing the number of virtualized base stations depending on the processing load.

[0007] In Patent Document 2 and Non-Patent Documents 2 and 3, in order to deal with the increased processing load on the CPU in a virtualized base station, a technology is considered for reducing the processing load on the CPU by offloading the CPU processing to an accelerator such as an FPGA or a GPU.

[0008] Patent Document 3 proposes a method for dealing with increased processing load in an O-RAN-compliant wireless communication system in which, when a DU without an accelerator and a high-performance DU with an accelerator exist, if an increase in traffic is detected in an RU connected to the DU without an accelerator, by switching the connection to the high-performance DU with an accelerator.

[0009] Japanese Patent Publication No. 2023-093439 Japanese Patent Publication No. 2023-047717 Japanese Patent Application No. 2023-013117

[0010] "O-RAN ALLIANCE," https: / / www.o-ran.org / . Nagareta et al., "Quantitative Evaluation of Power Consumption Reduction by Hardware Offloading in Virtualized Base Stations," IEICE Technical Report, vol. 122, no. 129, CQ2022-19, pp. 13-18, July 2022. JC Borromeo, et al., "An Overview of Hardware Acceleration Techniques for 5G Functions," 2020 22nd International Conference on Transparent Optical Networks, July 2020.

[0011] In order to cope with the large volume of traffic that will come with the advancement of 5G, studies are underway to dynamically change the number of CUs and DUs in a virtualized base station as disclosed in Patent Document 1, and to increase processing capacity by using accelerators as disclosed in Patent Document 2 and Non-Patent Publications 2 and 3.

[0012] However, while these methods can handle high traffic loads by optimizing the processing capacity of the virtualized base station according to the traffic load, they have the problem of making it difficult to flexibly control the accelerator during low traffic loads in order to reduce power consumption.

[0013] The object of the present invention is to solve the above technical problems and to provide a wireless communication system in which virtualized base stations are generated as network functions on a cloud platform, in which an orchestrator that controls the entire system predicts traffic demand and can flexibly control the placement and power supply of accelerators according to the prediction results, thereby minimizing power consumption, as well as a control method and program for the same.

[0014] In order to achieve the above-mentioned object, the present invention provides a wireless communication system in which base station units (CU, DU) are connected to a vRAN implemented by software on a computer and wireless units (RU) and the interfaces between the base station units are opened. The system is equipped with accelerators installed in each computer and an orchestrator that controls the entire wireless communication system in an integrated manner, and the orchestrator is equipped with means for predicting the traffic load for each base station unit and means for selecting hardware that will handle base station processing in each base station unit according to the results of the traffic load prediction, and the orchestrator controls the virtual placement and deletion of accelerators in each base station unit according to the results of the selection.

[0015] According to the present invention, the orchestrator can deploy only the minimum number of accelerators required according to the traffic demand predicted by the orchestrator and manage their power supplies, thereby minimizing power consumption while ensuring operation in response to traffic demand.

[0016] 1 is a functional block diagram showing the configuration of the main parts of the O-RAN architecture to which the present invention is applied. FIG. 2 is a diagram showing an example of traffic demand forecast predicted by a traffic forecasting unit (321) for each base station unit. FIG. 3 is a diagram showing a first method for selecting computing hardware by a computing hardware selection unit (322). FIG. 4 is a diagram showing the relationship between power consumption and traffic volume in relation to hardware selection / combination. FIG. 5 is a diagram showing an example of a result of computing hardware selection. FIG. 6 is a diagram showing a second method for selecting computing hardware by a computing hardware selection unit (322). FIG. 7 is a diagram showing a method for switching computing hardware from a CPU to an accelerator (ACC). FIG. 8 is a diagram showing a method for switching computing hardware from an ACC to a CPU. FIG. 9 is a diagram showing a method for switching computing hardware from a GPU to an FPGA between ACCs. FIG. 10 is a flowchart showing the procedure for switching computing hardware by a computing hardware selection unit (322).

[0017]

[0016] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Fig. 1 is a functional block diagram showing the configuration of the main parts of an O-RAN architecture to which the present invention is applied, which includes a session unit (CU), a distributed unit (DU), and a radio unit (RU), and each base station unit of the CU, DU, and RAN controller (RIC) is deployed (NF Deployment) as a network function 1 (NF) on a cloud platform 2 (O-Cloud2).

[0018] O-Cloud 2 is comprehensively controlled by Orchestrator 3 (SMO: Service Management Orchestration). SMO 3 predicts traffic demand and controls the processing capacity of CU, DU, and RU based on the prediction results, thereby reducing power consumption while ensuring RAN operation in response to increased traffic demand.

[0019] O-Cloud 2 is constructed as a collection of hardware devices, such as computers and servers (hereinafter sometimes referred to collectively as servers), and each server consists of hardware such as a CPU, memory, storage, and accelerator (ACC). The physical RU is connected to the DU via a fronthaul. The virtual resources of vRAN applications are deployed (placed) on O-Cloud 2 using the server components as resources.

[0020] SMO 3 has individual function groups 31 (O1 termination function, NFO (Network Function Orchestration), and FOCOM (Federated-cloud Orchestration)) and Non-Real-Time RIC 32. NF Deployment 1 has the functions of the base station unit (CU, DU) as well as Near Real-Time RIC 11. On O-Cloud 2, the base station unit's host OS, physical accelerator (ACC), DMS (Deployment Management Services) that manages the deployment status of NF, and IMS (Infrastructure Management Services) that manages resources are built.

[0021] The CU, DU, and Near Real Time RIC11 are connected to SMO 3 via the O1 interface, which is used to change parameters and obtain logs and statistical information. The IMS (Importer Management System) and DMS (Dealer Management System) are connected to FOCOM and NFO, which are components of SMO 3, via the O2ims and O2dms interfaces, respectively, and perform resource management and NF management for O-Cloud 2.

[0022] In the SMO 3, the individual function group 31 acquires control log information from the base station units (CU, DU) and the Near Real Time RIC 11 via the O1 interface. The Non Real Time RIC 32 includes a traffic prediction unit 321 and a calculation hardware selection unit 322 as rApps.

[0023] The traffic prediction unit 321 predicts traffic demand for each base station unit based on the Non Real Time RIC 32. The calculation hardware selection unit 322 determines whether each base station unit requires ACC based on the traffic demand prediction result, and selects hardware for performing calculations for base station processing in each base station unit based on the determination result.

[0024] Based on the result of the hardware selection, the SMO 3 controls the power supply of the ACC using the O2ims interface, and further changes the configuration of the base station unit as a network function using the O2dms interface.

[0025] In this configuration, the SMO 3 obtains log and statistical information from each base station unit via the O1 interface and determines whether each base station unit should use an ACC from the perspective of power consumption. Based on the result of this determination, the SMO 3 adds / removes the ACC to the DU / CU via the DMS. Furthermore, based on the result of this determination, the SMO 3 turns on / off the power of each ACC via the IMS.

[0026] 2 is a diagram showing an example of the traffic demand prediction results for each base station unit at each prediction time, which are predicted by the traffic prediction unit 321. Based on the log and statistical information acquired via the O1 interface, the traffic prediction unit 321 outputs a probability density function of the traffic volume (predicted value) after a certain time has elapsed, for example, after the ACC has been powered off or has been in standby mode and has completely started up.

[0027] Figure 3 shows a first method for selecting calculation hardware by the calculation hardware selection unit 322, which calculates the "outage probability" and the "integral value of the probability density function" based on the probability density function of the traffic volume and the predicted power consumption of the base station unit, and selects the calculation hardware that will handle base station processing in each base station unit.

[0028] The outage probability is the probability that the CPU of a server device will exceed its performance limit. In this embodiment, as shown in Figure 3, the upper limit of traffic volume that can be calculated by the CPU alone without using the ACC is set as a threshold, and the integral value of the probability density function at which the traffic volume exceeds the threshold is defined as the outage probability for each predicted time.

[0029] Figure 4 shows the relationship between power consumption and traffic volume in relation to the selection of computing hardware, where the ACC is a GPU. Note that the power consumption focuses on the power consumed by base station processing operations.

[0030] In "CPU processing (GPU power off)" where ACC is not required, power consumption increases in proportion to the increase in traffic volume from the idle state. In "CPU processing (GPU standby)" where ACC is not required, power consumption increases uniformly because the standby power of the GPU is added to the power consumption of "CPU processing (GPU power off)."

[0031] In contrast, with "GPU processing" requiring ACC, power consumption in idle state is equivalent to that of "CPU processing (GPU standby)," but the rate of increase in power consumption in response to subsequent increases in traffic volume is lower than that of "CPU processing (GPU power off)" and "CPU processing (GPU standby)."

[0032] Therefore, the computing hardware selection unit 322 determines that ACC is necessary when the traffic volume exceeds a threshold corresponding to the outage probability, and selects a GPU as the computing hardware, as shown in FIG.

[0033] On the other hand, if the traffic volume is below a threshold corresponding to the outage probability, attention is further focused on the traffic volume Tr at which the power consumption of "GPU processing" and "CPU processing (GPU power off)" are reversed. As shown in Figure 5, if the traffic volume is below Tr, it is determined that ACC is not required and the CPU is selected, whereas if the traffic volume is above Tr, it is determined that ACC is required and the GPU is selected.

[0034] The closer the predicted time is to the current time, the higher the prediction accuracy of the traffic volume, probability density function, and outage probability. Therefore, it is desirable that the computation hardware selection unit 322 selects hardware based on the traffic volume predicted by the traffic prediction unit 321 for a closer prediction time.

[0035] On the other hand, the time Δt required for the ACC to be able to perform calculations after being powered on is the sum of the time Δt1 from being powered on to being in standby mode and the time Δt2 from being in standby mode to being able to perform calculations (Δt = Δt1 + Δ2t), and in this embodiment, Δt1 is assumed to be approximately 8 seconds and Δ2t is assumed to be approximately 2 seconds.

[0036] Therefore, in a situation where fluctuations in traffic volume are small and the CPU and ACC are unlikely to be frequently switched as computing hardware, the traffic prediction unit 321 can set the predicted time to be close (for example, 10 seconds later), and "CPU processing (GPU power off)" can be selected in preference to "CPU processing (GPU standby)."

[0037] On the other hand, in a situation where the traffic volume fluctuates greatly and there is a high possibility that the CPU and ACC will be frequently switched as computing hardware, the traffic prediction unit 321 may set the predicted time to be close (for example, 2 seconds later), so that "CPU processing (GPU standby)" is selected in preference to "CPU processing (GPU power off)."

[0038] Although this increases power consumption slightly, it allows the GPU to operate immediately after selection by the calculation hardware selection unit 322, making it possible to select calculation hardware based on highly accurate prediction results regarding traffic volume. As a result, it becomes possible to reduce power consumption while ensuring the operation of the base station unit even in environments with large fluctuations in traffic volume.

[0039] 6 is a diagram showing a second selection method of arithmetic hardware by the arithmetic hardware selection unit 322, which is characterized in that in addition to selecting a CPU or ACC, when selecting an ACC, a GPU or FPGA is also selected. Note that in this explanation, it is assumed that a GPU has higher processing power and therefore consumes more power than an FPGA.

[0040] In this embodiment, the number of users and the amount of traffic are considered from the viewpoint of reducing power consumption, and if the amount of traffic is low, CPU processing is selected regardless of the number of users. On the other hand, if the amount of traffic is high, ACC (GPU or FPGA) is selected, and in this case, the greater the number of users and the amount of traffic, the more preferentially GPU is selected.

[0041] As shown in Example 1 in the figure, if the average number of users and traffic volume (marked with a dot) falls within the range of CPU processing, but part of the variance (marked with a circle) falls within the range of FPGA processing, frequent FPGA selection is predicted, and CPU processing (FPGA standby) is selected, assuming CPU processing but putting the FPGA on standby.

[0042] As shown in Example 2 in the figure, if the average number of users and traffic volume falls within the range of GPU processing but part of the variance falls within the range of FPGA processing, GPU processing is selected to prevent frequent switching between GPU and FPGA.

[0043] 7, 8, and 9 are diagrams showing a method for switching the arithmetic hardware based on the selection result of the arithmetic hardware selection unit 322, and Fig. 10 is a flowchart showing the procedure. Fig. 7 shows the procedure for switching the arithmetic hardware from a CPU to an ACC, Fig. 8 shows the procedure for switching the arithmetic hardware from an ACC to a CPU, and Fig. 9 shows the procedure for switching the arithmetic hardware from a GPU to an FPGA between ACCs.

[0044] 10, in step S1, the traffic volume after a predetermined time is predicted by the traffic prediction unit 321. In step S2, the calculation hardware is selected by the calculation hardware selection unit 322 based on the traffic volume prediction result. In step S3, the result of the selection is referred to.

[0045] If ACC is selected, the process proceeds to step S4 and subsequent steps. Here, we will explain an example in which the calculation hardware in the DU is switched from a CPU to an ACC, as shown in Figure 7. If the base station unit (DU) does not include an ACC, as shown in Figure 7(a), a DU including an ACC is first generated as a network function.

[0046] In step S4, the SMO 3 turns on the power supply of the ACC using the O2ims interface. Here, the power supplies of the GPU and FPGA are turned on. In step S5, a DU including the ACC is newly placed using the O2dms interface as shown in Figure 7(b).

[0047] In step S6, the network connection of the DU is changed using the O1 interface or the E2 interface as shown in Fig. 7(c). In step S7, the original DU is deleted using the O2dms interface as shown in Fig. 7(d).

[0048] On the other hand, if the arithmetic hardware selection unit 322 selects the CPU as the arithmetic hardware in step S2, the process proceeds from step S3 to step S8 onward. Here, as shown in Fig. 8, an example will be described in which the arithmetic hardware is switched from ACC to CPU.

[0049] As shown in Fig. 8(a), if a DU includes a GPU and FPGA, a new DU without ACC is generated as a network function. In step S8, SMO 3 allocates a DU without ACC using the O2dms interface as shown in Fig. 8(b).

[0050] In step S9, the network connection of the DU is changed using the O1 interface or E2 interface as shown in Fig. 8(c). In step S10, the original DU is deleted using the O2dms interface as shown in Fig. 8(d). In step S11, the O2ims interface is used to turn off the power to the ACC that was located in the deleted DU.

[0051] On the other hand, if the calculation hardware selection unit 322 selects an ACC other than the existing ACC as the calculation hardware in step S2, the process proceeds from step S3 to step S12. Here, as shown in Fig. 9, an example will be described in which the calculation hardware is switched from GPU to FPGA between ACCs.

[0052] As shown in Figure 9(a), if a base station unit (DU) includes a GPU as an ACC, a DU including an FPGA is first created as a network function. In step S12, the SMO 3 turns on the FPGA using the O2ims interface. In step S13, as shown in Figure 9(b), the DU including the FPGA is allocated using the O2dms interface.

[0053] In step S14, the network connection of the DU is changed using the O1 interface or E2 interface as shown in Fig. 9(c). In step S15, the original DU is deleted using the O2dms interface as shown in Fig. 9(d). In step S16, the ACC (GPU) of the deleted DU is powered off using the O2ims interface.

[0054] In the above embodiment, the selection of arithmetic hardware in a DU has been described as an example, but the present invention is not limited to this, and can be similarly applied to the selection of arithmetic hardware in a CU by simply changing the threshold value, etc.

[0055] Furthermore, while the above embodiments have been described using GPUs and FPGAs as examples of ACCs, the present invention is not limited to these, and can be similarly applied to the selective placement of APUs (Associative Processing Units), DPUs (Data Processing Units), or IPUs (Infrastructure Processing Units) as long as the ACC can be virtually placed in a network function.

[0056] Furthermore, in the above embodiment, an example was given of arranging multiple ACCs in different combinations (combinations of GPU and FPGA), but the present invention is not limited to this, and multiple identical ACCs may be combined, and the number of combinations is not limited to two, but three or more ACCs may be combined.

[0057] Furthermore, according to each of the above embodiments, it is possible to keep the power consumption of vRAN low while ensuring its operation, which will make it possible to contribute to Goal 9 "Build resilient infrastructure and promote inclusive and sustainable industrialization" and Goal 11 "Make cities inclusive, safe, resilient and sustainable" of the Sustainable Development Goals (SDGs) led by the United Nations.

[0058] According to the present invention, it is possible to provide a wireless communication system, a control method and a program thereof, which can minimize power consumption by predicting traffic demand in an orchestrator that controls the entire wireless communication system and flexibly controlling the placement and power supply of accelerators according to the prediction results.

[0059] 1...Network Function (NF Deployment), 2...Cloud Platform (O-Cloud), 3...Orchestrator (SMO), 11...Near Real-Time RIC, 31...Individual Function Group, 32...Non Real-Time RIC, 321...Traffic Prediction Unit, 322...Computation Hardware Selection Unit, CU...Session Unit, DU...Distribution Unit, RU...Radio Unit

Claims

1. A wireless communication system in which base station units (CU, DU) are connected to wireless units (RU) via a vRAN implemented by computer software, and the interface between the base station units is open, the system comprises accelerators installed in each computer and an orchestrator that controls the entire wireless communication system in an integrated manner, the orchestrator comprises means for predicting the traffic load for each base station unit, and means for selecting hardware in each base station unit that will handle base station processing in accordance with the results of the traffic load prediction, and the orchestrator controls the virtual placement and deletion of accelerators in each base station unit in accordance with the results of the selection.

2. The wireless communication system according to claim 1, wherein said hardware selection means selects at least one of a CPU and an accelerator of a computer that virtualizes each base station unit.

3. The wireless communication system described in claim 2, wherein when an undeployed accelerator is selected as the hardware, the orchestrator turns on the power of the accelerator and deploys the accelerator in the corresponding base station unit.

4. The wireless communication system described in claim 2, characterized in that when a computer CPU is selected as the hardware, the orchestrator deletes an accelerator already placed in the corresponding base station unit and turns off its power.

5. The wireless communication system described in claim 2, characterized in that when an undeployed accelerator is selected as the hardware, the orchestrator deploys the accelerator in the corresponding base station unit and turns on its power, and deletes other accelerators that have already been deployed in the corresponding base station unit and turns off their power.

6. The wireless communication system according to claim 1, characterized in that the traffic load predicting means predicts traffic demand, and the hardware selecting means selects hardware according to the traffic demand when the predicted traffic demand exceeds a predetermined threshold.

7. The wireless communication system according to claim 6, wherein the traffic load predicting means predicts whether the CPU of the computer that virtualizes each base station unit will reach its processing limit based on a probability density function of traffic demand at a future time, and the hardware selecting means selects hardware in response to the prediction that the CPU will reach its processing limit.

8. The wireless communication system according to claim 7, wherein the traffic load predicting means predicts whether the CPU will reach its processing limit based on the integral of the probability density function of traffic demand that exceeds the processing limit of the CPU.

9. The wireless communication system described in claim 6, characterized in that the orchestrator controls the deployed accelerator to either an on state or a standby state in which power consumption is lower than that of the on state, depending on the time of traffic demand predicted by the traffic load prediction means.

10. The wireless communication system described in claim 9, characterized in that the orchestrator controls the deployed accelerator to a standby state if the time of the predicted traffic demand is relatively close, and to an off state if the time is relatively far away.

11. The wireless communication system described in claim 5, characterized in that when selecting hardware from among multiple accelerators whose power consumption increases in proportion to their processing capabilities, the means for selecting hardware preferentially selects an accelerator that can process the maximum value of traffic demand based on the variance of the predicted results of traffic demand.

12. A wireless communication system according to any one of claims 1 to 11, characterized in that the accelerator is at least one of an FPGA (Field Programmable Gate Array), a GPU (Graphics Processing Unit), an APU (Associative Processing Unit), a DPU (Data Processing Unit), and an IPU (Infrastructure Processing Unit).

13. A control method for a wireless communication system in which base station units (CU, DU) are connected to a vRAN implemented by computer software and the interface between the base station units is opened, the control method for a wireless communication system being characterized in that each computer is equipped with an accelerator, the entire wireless communication system is controlled in an integrated manner by an orchestrator, the orchestrator predicts the traffic load for each base station unit, and selects hardware to handle base station processing in each base station unit according to the results of the traffic load prediction, and the orchestrator virtually allocates an accelerator that has not yet been allocated to each base station unit and controls its power supply according to the results of the selection.

14. The method for controlling a wireless communication system according to claim 13, wherein the selection of hardware involves selecting at least one of a CPU and an accelerator of a computer that virtualizes each base station unit.

15. A control program for a wireless communication system in which base station units (CU, DU) are connected to a vRAN implemented by computer software and wireless units (RU) are connected to open interfaces between the base station units, wherein each computer is equipped with an accelerator, the entire wireless communication system is controlled in an integrated manner by an orchestrator, and the orchestrator causes a computer to execute a procedure for predicting traffic load for each base station unit and a means for selecting hardware to handle base station processing in each base station unit according to the results of the traffic load prediction, and the orchestrator virtually allocates an accelerator that has not yet been allocated to each base station unit and controls its power supply according to the results of the selection.

16. A control program for a wireless communication system according to claim 15, wherein the step of selecting hardware selects at least one of a CPU and an accelerator of a computer that virtualizes each base station unit.

Images