Wireless communication system, and control method and program thereof

Abstract

To provide a wireless communication system, and a control method and a program thereof that 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 prediction results.SOLUTION: In an SMO 3, a Non Real Time RIC 32 includes, as rApps, a traffic prediction unit 321 and an arithmetic operation hardware selection unit 322. The traffic prediction unit 321 predicts traffic demand for each base station device based on the Non Real Time RIC 32. The arithmetic operation hardware selection unit 322 determines whether each base station device requires an ACC based on traffic demand prediction results, and selects hardware that will perform base station processing arithmetic operations in each base station device based on the determination results.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a wireless communication system, a control method thereof, and a program, and in particular to a wireless communication system, a control method thereof, and a 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. [Background technology]

[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 base stations, which were previously 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 (NFs) 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, it is expected that the processing load of CUs and DUs will increase in order to process the increased traffic load caused by the advancement of 5G. Therefore, Patent Document 1 considers a technology for dynamically increasing or decreasing the number of virtualized base stations according to 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. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] Japanese Patent Application Publication No. 2023-093439 [Patent Document 2] Japanese Patent Publication No. 2023-047717 [Patent Document 3] Patent application No. 2023-013117 [Non-patent literature]

[0010] [Non-Patent Document 1] "O-RAN ALLIANCE," https: / / www.o-ran.org / [Non-patent document 2] 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. [Non-patent document 3] JC Borromeo, et al., "An Overview of Hardware Acceleration Techniques for 5G Functions," 2020 22nd International Conference on Transparent Optical Networks, July 2020. Summary of the Invention [Problem to be solved by the invention]

[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 virtualized base stations 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. [Means for solving the problem]

[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 a wireless unit (RU) and the interface between the base station units is opened. The system is equipped with an accelerator installed in each computer and an orchestrator that controls the entire wireless communication system in an integrated manner, and the orchestrator is equipped with a means for predicting the traffic load for each base station unit and a 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 removal of accelerators in each base station unit according to the results of the selection. [Effects of the Invention]

[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. [Brief explanation of the drawings]

[0016] [Figure 1] 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. [Figure 2] FIG. 10 is a diagram showing an example of traffic demand forecast made by the traffic forecasting unit (321) for each base station unit. [Figure 3] FIG. 10 is a diagram showing a first method for selecting arithmetic hardware by the arithmetic hardware selection unit (322). [Figure 4] FIG. 10 is a diagram showing the relationship between power consumption and traffic volume in relation to hardware selection / combination. [Figure 5] FIG. 10 is a diagram illustrating an example of a selection result of arithmetic hardware. [Figure 6] FIG. 10 is a diagram showing a second method for selecting arithmetic hardware by the arithmetic hardware selection unit (322). [Figure 7] FIG. 1 is a diagram illustrating a method for switching arithmetic hardware from a CPU to an accelerator (ACC). [Figure 8] FIG. 10 is a diagram illustrating a method for switching the calculation hardware from the ACC to the CPU. [Figure 9] This is a diagram showing a schematic diagram of a method for switching the computing hardware from GPU to FPGA between ACCs. [Figure 10] 10 is a flowchart showing a procedure for switching arithmetic hardware by an arithmetic hardware selection unit (322). DETAILED DESCRIPTION OF THE INVENTION

[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 a group of individual functions 31 (O1 termination function, NFO (Network Function Orchestration), and FOCOM (Federated-cloud Orchestration)) and a Non-Real-Time RIC 32. NF Deployment 1 has the functions of a base station unit (CU, DU) as well as a 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 NFs, 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 log 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 passed, 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 prediction accuracy of the traffic volume, probability density function, and outage probability all increases as the predicted time approaches the current time. Therefore, it is desirable for the computation hardware selection unit 322 to select 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 become operable after being powered on is the sum of the time Δt1 from powering on to entering standby mode and the time Δt2 from the standby mode to becoming operable (Δt = Δt1 + Δ2t), and in this embodiment, Δt1 is assumed to be approximately 8 seconds and Δ2t 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 small, CPU processing is selected regardless of the number of users. On the other hand, if the amount of traffic is large, 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 (· marks) falls within the range of CPU processing, but part of the variance (circles) 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 schematic diagram of 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(a). If the base station unit (DU) does not include an ACC, a DU including an ACC is first generated as a network function, as shown in Figure 7(a).

[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, it first creates a DU including an FPGA 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), it allocates the DU including the FPGA using the O2dms interface.

[0053] In step S14, the network connection of the DU is changed using the O1 interface or the 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, in the above embodiments, a GPU and an FPGA are used as examples of ACCs, but the present invention is not limited to these, and can be similarly applied to the selective placement of an APU (Associative Processing Unit), DPU (Data Processing Unit), or IPU (Infrastructure Processing Unit) 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. [Explanation of symbols]

[0058] 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. In 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 open, Accelerators installed in each computer, an orchestrator that controls the entire wireless communication system in an integrated manner; The orchestrator: means for predicting traffic load for each base station unit; a means for selecting hardware for carrying out base station processing in each base station unit according to the traffic load prediction result; The orchestrator controls virtual deployment and removal of accelerators in each base station unit according to the result of the selection.

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

3. 3. The wireless communication system according to 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 a corresponding base station unit.

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

5. 3. The wireless communication system according to claim 2, wherein 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 means for predicting traffic load predicts traffic demand; 2. The wireless communication system according to claim 1, wherein said hardware selecting means selects hardware according to the traffic demand when the predicted traffic demand exceeds a predetermined threshold.

7. the traffic load predicting means predicts whether the CPU will reach a processing limit based on a probability density function of traffic demand at a future time; 7. The wireless communication system according to claim 6, wherein said means for selecting hardware selects hardware in response to a prediction that said CPU will reach a processing limit.

8. 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 an integral value of a probability density function of traffic demand that exceeds the processing limit of the CPU.

9. 7. The wireless communication system according to claim 6, wherein the orchestrator controls the accelerator to either an on state or a standby state in which power consumption is less than that of the on state, depending on the time of traffic demand predicted by the traffic load predicting means.

10. The wireless communication system according to claim 9, wherein 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. 6. The wireless communication system according to claim 5, wherein the hardware selecting means, when selecting hardware from among a plurality of accelerators whose power consumption increases in proportion to the processing capability, preferentially selects an accelerator that can process the maximum value of traffic demand based on the variance of traffic demand prediction results.

12. 12. The wireless communication system according to claim 1, wherein 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 method for controlling a wireless communication system in which a wireless unit (RU) is connected to a vRAN realized by computer software, and the interface between the base station units (CU, DU) is opened, Each computer is equipped with an accelerator, The entire wireless communication system is controlled in an integrated manner by an orchestrator. The orchestrator: Predicting the traffic load for each base station unit; selecting hardware for carrying out base station processing in each base station unit according to the traffic load prediction result; A control method for a wireless communication system, characterized in that the orchestrator virtually allocates unallocated accelerators to each base station unit and controls their power supply in accordance with the result of the selection.

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

15. In 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 the interface between the base station units is opened, Each computer is equipped with an accelerator, The entire wireless communication system is controlled in an integrated manner by an orchestrator. In the orchestrator, a step of predicting traffic load for each base station unit; and selecting hardware for carrying out base station processing in each base station unit according to the traffic load prediction result; The control program for a wireless communication system, wherein the orchestrator virtually allocates unallocated accelerators to each base station unit and controls their power supply in accordance with the result of the selection.

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

Images