RIC device, communication system, control method, and program

Abstract

The objective of the present invention is to provide an RIC device capable of improving the accuracy of traffic steering. An RIC device according to the present disclosure comprises: a communication unit that receives, from an E2 node, a performance counter related to a cell managed by the E2 node and receives, from a server device, data indicating a state of a region within the cell; an estimation unit that estimates a state of congestion in a cell near a first cell by inputting the performance counter and the data indicating the state of the region within the cell into a learning model; and a control unit that determines a parameter related to control of the E2 node on the basis of the state of congestion.

Description

RIC apparatus, communication system, control method and program

[0001] The present disclosure relates to an RIC apparatus, a communication system, a control method, and a program.

[0002] Non-Patent Document 1 discloses use cases related to various services executed in an O-RAN (Open-Radio Access Network). Non-Patent Document 1 also discloses that a Non RT RIC (Non Real Time RAN Intelligent Controller) generates an AI / ML (Artificial Intelligence / Machine Learning) model using learning data, and a Near RT RIC performs inference using the AI / ML model. Further, Non-Patent Document 1 discloses that traffic steering is performed using an AI / ML model.

[0003] O-RAN.WG1.TR.Use-Cases-Analysis-Report-R004-v16.00

[0004] When generating an AI / ML model used for traffic steering, the Non RT RIC uses performance counters (PM counters) collected from an O-RU (O-RAN Radio Unit), an O-DU (O-RAN Distributed Unit) or an O-CU (O-RAN Central Unit) as learning data. Here, there is a demand for higher accuracy of traffic steering in order to perform resource optimization in a wireless network.

[0005] An object of the present disclosure is to provide an RIC apparatus, a communication system, a control method, and a program that can improve the accuracy of traffic steering.

[0006] The RIC device according to this disclosure includes: a communication unit that receives performance counters related to cells managed by the E2 node from the E2 node and data indicating the state of areas within the cells from a server device; an estimation unit that estimates the congestion state in surrounding cells of a first cell by inputting the performance counters and the data indicating the state of areas within the cells into a learning model; and a control unit that determines parameters related to the control of the E2 node based on the congestion state.

[0007] The communication system according to this disclosure comprises: Non RT RIC, which generates a learning model by machine learning using performance counters for cells managed by an E2 node, data indicating the state of a region within the cell, and congestion information indicating the congestion state in surrounding cells of the cell as training data; and Near RT RIC, which estimates the congestion state in surrounding cells of the cell by inputting the performance counters and data indicating the state within the cell into the learning model, and determines parameters related to the control of the E2 node based on the congestion state.

[0008] The control method according to this disclosure receives performance counters related to the cells managed by the E2 node from the E2 node and data indicating the state of the area within the cell from the server device, and inputs the performance counters and the data indicating the state of the area within the cell into a learning model to estimate the congestion state in the surrounding cells of the first cell, and determines parameters related to the control of the E2 node based on the congestion state.

[0009] The program relating to this disclosure causes a computer to receive performance counters related to cells managed by the E2 node from the E2 node, and data indicating the state of areas within the cells from a server device, input the performance counters and the data indicating the state of areas within the cells into a learning model to estimate the congestion state in surrounding cells of a first cell, and determine parameters related to the control of the E2 node based on the congestion state.

[0010] This disclosure provides a RIC device, communication system, control method, and program that can improve the accuracy of traffic steering.

[0011] Figure 1 shows an example configuration of an RIC device. Figure 2 explains the flow of control processing performed in the RIC device. Figure 3 shows an example configuration of a communication system. Figure 4 shows the flow of the learning model generation process in the application server. Figure 5 shows the flow of the learning model generation process in NonRTRIC. Figure 6 explains the flow of the parameter control process related to congestion control in NearRTRIC. Figure 7 is a block diagram showing an example configuration of an RIC device, etc.

[0012] Embodiment 1 Figure 1 shows an example configuration of an RIC device 10. The RIC device 10 may be a computer device that operates by having a processor execute a program stored in memory. The RIC device 10 may be, for example, a NonRT RIC or a Near RT RIC.

[0013] The RIC device 10 includes a communication unit 12, an estimation unit 13, and a control unit 14. The communication unit 12, estimation unit 13, and control unit 14 may be software or modules whose processing is performed by a processor executing a program stored in memory. Alternatively, the communication unit 12, estimation unit 13, and control unit 14 may be hardware such as a circuit or chip.

[0014] The communication unit 12 may be used as a means for transmitting or receiving information. The estimation unit 13 may be used as a means for estimating information. The control unit 14 may be used as a means for controlling a computer device.

[0015] The communication unit 12, estimation unit 13, and control unit 14 may be provided in a single RIC device 10, or they may be distributed across two or more computer devices. The two or more computer devices may communicate via a network. Two or more computer devices in which the communication unit 12, estimation unit 13, and control unit 14 are distributed may constitute, for example, a communication system or a control system.

[0016] The communication unit 12 receives performance counters related to the cell managed by the E2 node from the E2 node, and data indicating the status of the area within the cell from the server device. The performance counters related to the cell managed by the E2 node may be, for example, data measured at the O-RU. Alternatively, the performance counters may be data measured at the E2 node. The E2 node includes the O-DU and O-CU as defined in the O-RAN Alliance. The performance counters may be, for example, performance information indicating the performance of wireless communication between the communication terminal and the O-RU, measured at the E2 node. Specifically, the performance counters may be the amount of data related to uplink data or downlink data related to the communication terminal, the number of errors that occurred, etc. Alternatively, the performance counters may be management information indicating the operational status of the E2 node. The management information may include, for example, the number of UEs (User Equipment) present in the cell, information indicating the location of the UEs in the cell, etc.

[0017] The server device may be a computer device that operates by a processor executing a program stored in memory. The data indicating the state of a region within a cell may be data obtained by analyzing the state of that region within a cell. For example, the state of a region within a cell may be indicated by image data, or by the results of an analysis of the image data. The analysis results may indicate information about human behavior contained in the image data.

[0018] The estimation unit 13 estimates the congestion state in surrounding cells of a cell by inputting the performance counter and data indicating the state of a region within the cell into a learning model. The congestion state may also be information output as a result of inference in the learning model. The estimation unit 13 may also estimate the congestion state occurring in surrounding cells of a cell by inputting the performance counter and analysis results into a learning model. The congestion state may be, for example, the degree (level) of congestion, a specific region of the cell where congestion may occur, or a time period during which congestion may occur.

[0019] Information indicating the state of congestion (congestion information) may also be information indicating whether or not congestion has occurred in a cell managed by an E2 node or in surrounding cells of a cell managed by an E2 node. Alternatively, congestion information may be a set of reference parameters used to determine the presence or absence of congestion. Congestion information may be managed, for example, in an operation center that manages the network including O-RUs and E2 nodes. The RIC device 10 may receive congestion information from the operation center via the network. Congestion information may include the cell or area where congestion occurred, the time when congestion occurred, etc. Alternatively, the administrator of the RIC device 10 may input congestion information into the RIC device 10. For example, the administrator of the RIC device 10 may input the conditions under which congestion occurs as congestion information into the RIC device 10. The conditions under which congestion occurs may include, for example, the number of handover processes performed within a predetermined period, the amount of data communicated by multiple communication terminals within a cell, the number of communication terminals present in a cell, the number of communication terminals increasing within a cell within a predetermined period, etc. Alternatively, the conditions under which congestion occurs may include the number of communication terminals present at the cell boundary, the ratio of the number of communication terminals to the size of the cell, the rate of increase of communication terminals within the cell over a predetermined period, and so on. The RIC device 10 may obtain congestion information from a server device or the like that manages the network policy.

[0020] The learning model may be generated using AI (Artificial Intelligence). Specifically, the learning model may be a pre-trained learning model generated using a general-purpose machine learning algorithm with performance counters, data indicating the state of regions within a cell, and congestion information as training data. The training data may also be called training data or teacher data. The pre-trained learning model causes the computer device to function by receiving data as input, performing calculations on the input data based on the parameters of the pre-trained learning model, and outputting the calculation results. The machine learning algorithm may be, for example, an algorithm that performs deep learning using a neural network. Alternatively, the learning model may cause the communication device 10 to function by receiving performance counters and data indicating the state of regions within a cell, performing calculations on the received data, and then outputting congestion information. In other words, the pre-trained learning model may be a program or software that causes the computer device to function.

[0021] The learning model may be managed or stored in a management unit (not shown) within the RIC device 10. The management unit may be used as a means of managing information.

[0022] The control unit 14 determines parameters for controlling the E2 node based on the congestion state. The control of the E2 node may be, for example, congestion control. Congestion control may include, for example, transmit power control, handover control, throughput control, etc., to avoid congestion.

[0023] Figure 2 illustrates the flow of control processing performed in the RIC device 10. First, the communication unit 12 receives performance counters related to the cell managed by the E2 node from the E2 node, and data indicating the status of the area within the cell from the server device (S11).

[0024] Next, the estimation unit 13 inputs the performance counter and data indicating the state of the region within the cell to the learning model (S12).

[0025] Next, the estimation unit 13 estimates the congestion state in the surrounding cells of the cell (S13). Then, the control unit 14 determines parameters related to the control of the E2 node based on the congestion state (S14).

[0026] As explained above, the RIC device 10 can estimate the congestion state using data indicating the state of areas within a cell in addition to the performance counter. Furthermore, the RIC device 10 determines parameters for controlling the E2 node based on the estimation results regarding the occurrence of congestion. This allows the RIC device 10 to control the flow of traffic (traffic steering) to avoid the occurrence of congestion. In addition, the RIC device 10 estimates the congestion state using data indicating the state of areas within a cell in addition to the performance counter. Therefore, the RIC device 10 can estimate the occurrence of congestion with higher accuracy compared to when the congestion state is estimated using only the performance counter.

[0027] Embodiment 2 Figure 3 shows an example of the configuration of a communication system. The communication system includes an O-RU 20, an E2 node 30, a Near RT RIC 40, a Non RT RIC 50, an IoT device 60, and an application server 70. Furthermore, there is a UE 80 which is a device that communicates wirelessly with the O-RU 20.

[0028] UE80 is used as a general term for communication terminals. For example, UE80 may be a mobile phone terminal, a smartphone terminal, or an IoT (Internet of Things) terminal. UE80 may support the wireless communication standard known as 5G in order to communicate wirelessly with O-RU20.

[0029] The E2 node 30 is a logical node that terminates the E2 interface. The E2 interface is an interface defined between the E2 node 30 and the Near-RT RIC 40. In other words, the E2 interface is an interface defined between the O-CU 34 and the Near-RT RIC 40, and further between the O-DU 32 and the Near-RT RIC 40. The E2 node 30 may be a physical device corresponding to either the O-CU 34 or the O-DU 32, or it may be a physical device in which the O-CU 34 and the O-DU 32 are integrated. If the E2 node 30 is a physical device in which the O-CU 34 and the O-DU 32 are integrated, the E2 interface is an interface defined between the physical device in which the O-CU 34 and the O-DU 32 are integrated and the Near-RT RIC 40. A node may correspond to an entity (device) or to a function (function).

[0030] O-CU34 may be, for example, a logical node that hosts RRC (Radio Resource Control) and PDCP (Packet Data Convergence Protocol). Alternatively, O-CU34 may be a physical device that houses an O-CU, which is a logical node. Hosting RRC and PDCP can be rephrased as terminating the RRC protocol and PDCP, or executing processing related to the RRC protocol and PDCP. Furthermore, when O-CU34 hosts RRC and PDCP, it can be rephrased as O-CU34 executing processing related to the RRC layer and PDCP layer. In the following explanation, the term "host" may also be rephrased as described above.

[0031] An O-CU that performs processing related to the C-Plane (Control Plane) part of PDCP may be referred to as O-CU-CP (C-Plane). Furthermore, an O-CU that performs processing related to the U-Plane (User Plane) part of PDCP may be referred to as O-CU-UP (U-Plane).

[0032] O-DU32 may be a logical node hosting RLC (Radio Link Control) and MAC (Media Access Control). Furthermore, O-DU32 may be a logical node hosting higher-level functions of the physical (PHY) layer. Alternatively, O-DU32 may be a physical device equipped with an O-DU, which is a logical node. Also, O-DU32 may perform PDCP-related processing in place of or together with O-CU34. Higher-level functions of the physical layer may include, for example, encoding and modulation processing, and further, decoding and demodulation processing, etc.

[0033] O-RU20 may be a logical node that hosts or executes lower-level functions of the physical layer and RF (Radio Frequency) processing. Alternatively, O-RU20 may be a physical device that houses an O-RU, which is a logical node. Lower-level functions of the physical layer may include, for example, FFT (Fast Fourier Transform) / IFFT (Inverse FFT) processing, BF (Beam Forming) processing, etc.

[0034] The Non-RT RIC 50 may perform RAN optimization processing, for example, by communicating with the Near-RT RIC 40 via the A1 interface. RAN optimization may include, for example, generating a control policy for the RAN and further notifying the Near-RT RIC 40 of the control policy.

[0035] The Near-RT RIC 40 is a logical function that performs near real-time control and optimization of RAN elements and resources. Alternatively, the Near-RT RIC 40 may be a physical device equipped with a logical function that performs near real-time control and optimization of RAN elements and resources. The RAN elements may be, for example, O-CU 34 and O-DU 32. Specifically, the Near-RT RIC 40 collects fine-grained data from the O-CU 34 or O-DU 32 via the E2 interface. Near real-time control may be, for example, control performed with a period of about 10 ms to 1 s. The fine-grained data may be, for example, near real-time information. The near real-time information may be, for example, information at the UE level or information at the cell level.

[0036] The IoT device 60 is a device used to collect information about the UE 80 or information about the cell. For example, the IoT device 60 may be a surveillance camera that photographs all or part of the area of ​​the cell formed by the O-RU 20. The IoT device 60 may photograph a predetermined area periodically or at arbitrary times. The IoT device 60 transmits the image data generated by the photography to the application server 70.

[0037] The application server 70 may be a server that provides application services. The application server 70 may be a single computer device, or it may be a system in which multiple computer devices cooperate and operate via a network.

[0038] The application server 70 may be connected to the Near RT RIC 40 and the Non RT RIC 50. The application server 70 and the Near RT RIC 40 and Non RT RIC 50 may be connected via an interface different from the interface defined in the O-RAN Alliance. For example, the application server 70 may be used as a node different from the node defined in the O-RAN Alliance. Therefore, the application server 70 may be connected to the Near RT RIC 40 and Non RT RIC 50 via the so-called Internet.

[0039] Furthermore, the application server 70 may also be connected to the IoT device 60 via the Internet. Alternatively, the IoT device 60 may be connected to the O-RU 20. In this case, the IoT device 60 may be connected to the application server 70 via the O-RU 20, the E2 node 30, and the Near RT RIC 40. Alternatively, the IoT device 60 may be connected to the application server 70 via the O-RU 20 and the E2 node 30.

[0040] The application server 70 uses the image data to perform an analysis of the human behavior contained in the image data. The analysis of human behavior may include, for example, identifying the number of people making calls using a communication terminal, the number of people performing data communication other than calls using a communication terminal, the direction people are facing, the number of people running, the number of people walking, etc. People making calls using a communication terminal may, for example, be people holding the communication terminal close to their ear. People performing data communication other than calls may be people looking at the communication terminal. People running and walking may be identified based on, for example, their stride length. The application server 70 may perform various analyses other than the examples of analysis described above.

[0041] The application server 70 may perform inference using a machine learning model that has been trained using image data and analysis results regarding human behavior contained in the image data as training data. The machine learning model managed by the application server 70 may be generated using AI. Specifically, the machine learning model may be a pre-trained machine learning model generated using a general-purpose machine learning algorithm with image data and analysis results regarding human behavior contained in the image data as training data. The training data may also be called training data or teacher data. The pre-trained machine learning model causes the computer device to function by receiving data as input, performing calculations on the input data based on the parameters of the pre-trained machine learning model, and outputting the calculation results. The machine learning algorithm may be, for example, an algorithm that performs deep learning using a neural network. The machine learning model may also cause the application server 70 to function by receiving image data, performing calculations on the received data, and then outputting analysis results regarding human behavior contained in the image data. In other words, the pre-trained machine learning model may be a program or software that causes the computer device to function.

[0042] Figure 4 shows the flow of the learning model generation process in the application server 70. First, the IoT device 60 sends image data to the application server 70 (S21). The image data may be sent to the application server 70 via the O-RU 20, E2 node 30, and Near RT RIC 40. Alternatively, the image data may be sent to the application server 70 via the O-RU 20, E2 node 30, and core network (not shown).

[0043] The IoT device 60 may periodically capture images of a predetermined area, or may capture images of a predetermined area at any arbitrary timing. The arbitrary timing may be, for example, a timing instructed by an administrator or the like who operates the IoT device 60. Further, the IoT device 60 may periodically transmit image data to the application server 70, or may transmit image data to the application server 70 at any arbitrary timing. The arbitrary timing may be, for example, a point in time when the number of unsent image data reaches a predetermined number, a point in time when the data amount of unsent image data reaches a predetermined data amount, a point in time when a message requesting image data is received from the application server 70, or the like.

[0044] Although FIG. 4 shows an example in which one IoT device 60 transmits image data to the application server 70, a plurality of IoT devices 60 may transmit image data to the application server 70.

[0045] Alternatively, the application server 70 may collect image data from, for example, an apparatus that manages or generates image data, other than from the IoT device 60. Alternatively, the application server 70 may collect image data generated using simulation or generative AI.

[0046] Next, the application server 70 generates a learning model using the image data (S22). The application server 70 may analyze the behavior of a person included in the image data, for example, by executing image analysis processing using the image data. The application server 70 may generate a learning model by causing machine learning to be performed using, as learning data, an analysis result obtained as a result of executing the image analysis processing and the image data. Alternatively, an administrator or the like of the application server 70 may input information indicating the behavior of a person included in the image data.

[0047] Figure 5 shows the flow of a learning model generation process in Non RT RIC 50. First, the IoT device 60 transmits image data to the application server 70 (S31). Further, the E2 node 30 transmits a performance counter to the Non RT RIC 50 (S32).

[0048] Next, the application server 70 uses the image data to generate an analysis result regarding human behavior (S33). For example, the application server 70 may perform inference using the learning model generated in the process of Figure 4. Specifically, the application server 70 may obtain the analysis result regarding human behavior by inputting the image data into the learning model. Alternatively, the application server 70 may obtain the analysis result regarding human behavior by executing image analysis processing using the image data.

[0049] Next, the application server 70 transmits analysis data showing the results of the analysis regarding human behavior to the Non RT RIC 50 (S34). Next, the Non RT RIC 50 generates a learning model using the performance counter and the analysis results regarding human behavior (S35). For example, the Non RT RIC 50 may periodically or at arbitrary times receive information indicating whether or not network congestion has occurred from an operation center (not shown) that manages whether or not network congestion has occurred. The information indicating whether or not congestion has occurred may be a set of reference parameters used to determine whether or not congestion has occurred. The information indicating whether or not congestion has occurred may include information indicating the cell or region where congestion has occurred and information indicating the time when congestion occurred. Alternatively, the information indicating whether or not congestion has occurred may be generated based on the information shown in the performance counter. For example, if the amount of communication data shown in the performance counter exceeds a predetermined value, congestion may be considered to have occurred. Furthermore, the information indicating whether or not congestion has occurred may be managed in advance by the Non RT RIC 50 as information indicating the conditions under which congestion occurs. Non-RT RIC50 may generate a learning model by using machine learning with performance counters, analysis results regarding human behavior, and information indicating the presence or absence of congestion as training data.

[0050] For example, a performance counter may indicate the number of UEs present in a particular cell. Furthermore, the approximate location of the UEs within the cell can be determined from changes in radio wave intensity, etc., indicated by multiple performance counters measured at different times. The direction of movement of each person can be determined from the results of an analysis of human behavior. Furthermore, the speed of movement of a person can be determined from the distance traveled by the same person in multiple image data captured at different times. Alternatively, the speed of movement of a person may be determined based on performance counters measured at different times. Furthermore, the number of UEs that will perform a handover after a predetermined time has elapsed can be determined from the number of people on a call, the number of people performing data communication, and the speed of movement of each person. In addition, based on information indicating whether or not congestion occurs in cells surrounding a particular cell where the performance counter was measured, it is possible to associate the execution of a handover caused by human movement with the occurrence of congestion.

[0051] As described above, there is a correlation between performance counters, the results of the analysis of human behavior, and information indicating the presence or absence of congestion. There are various other examples of the correlation between performance counters, the results of the analysis of human behavior, and information indicating the presence or absence of congestion besides the example described above. The learning model generated in step S35 is used to estimate the presence or absence of congestion using the performance counters and the results of the analysis of human behavior. In other words, the learning model outputs whether or not congestion is occurring as an inference result. The learning model may also output information identifying the cells in which congestion occurs as an inference result. Furthermore, the learning model may output information indicating the factors that cause congestion. Furthermore, the learning model may output the timing of congestion, specifically the time.

[0052] Here, Non RT RIC50 may add surrounding information such as weather information, traffic information, event information, and information about buildings such as event venues to its training data, in addition to performance counters, analysis results regarding human behavior, and information indicating whether or not congestion has occurred. By using surrounding information as training data, Non RT RIC50 can generate a learning model that estimates whether or not congestion has occurred, taking into account, for example, the weather and the number of people holding UEs, the weather and the number of people making calls or data communications, and the number of people during an event.

[0053] Non-RT RIC 50 may receive peripheral information, for example, as enrichment information, from the application server 70 or other application servers or information management servers. The device that manages or supplies enrichment information may be called, for example, External EI (Enrichment Information) Sources.

[0054] Figure 6 illustrates the parameter control process related to congestion control in the Near RT RIC 40. Assume that the learning model generated by the Non RT RIC 50 in step S35 of Figure 5 is stored in the Near RT RIC 40. This can be rephrased as the Non RT RIC 50 deploying the learning model to the Near RT RIC 40. In other words, the Near RT RIC 40 performs inference processing using the learning model generated in the Non RT RIC 50.

[0055] Steps S41 and S43 are the same as steps S31 and S33 in Figure 5, so a detailed explanation is omitted. In step S42, the E2 node 30 transmits the performance counter to the Near RT RIC 40. The Near RT RIC 40 may receive the performance counter transmitted from the E2 node 30 to the Non RT RIC 50 via the O1 interface from the Non RT RIC 50 via the A1 interface.

[0056] In step S44, the application server 70 sends analysis data showing the results of the analysis regarding human behavior to the Near RT RIC 40.

[0057] Next, Near RT RIC 40 determines the presence or absence of congestion by inputting the performance counter and the analysis results regarding human behavior into the learning model (S45). Near RT RIC 40 may obtain information indicating the cells where congestion occurs as output of the learning model. Furthermore, the learning model may output information indicating the factors that cause congestion.

[0058] Next, the Near RT RIC 40 determines parameters related to wireless communication (S46). For example, the Near RT RIC 40 may change the parameter values ​​to avoid congestion.

[0059] For example, Near RT RIC 40 may reduce the transmit power in a target cell (hereinafter referred to as the target cell) to reduce the number of UE connections in that cell where congestion is estimated to occur. In other words, Near RT RIC 40 may reduce the number of UE connections in the target cell by narrowing the area of ​​the target cell.

[0060] Furthermore, the Near RT RIC 40 may change the communication quality threshold used as a criterion for determining whether to hand over from a surrounding cell to the target cell. For example, the Near RT RIC 40 may reduce the number of UEs that perform handovers from surrounding cells to the target cell by lowering the communication quality threshold in the surrounding cells compared to the current level. Communication quality may be, for example, SNR (Signal to Noise Ratio), SINR (Signal to Interference plus Noise Ratio), etc. The Near RT RIC 40 may also perform control by carrier aggregation.

[0061] Furthermore, if the Near RT RIC 40 is operating on virtual resources on hardware, it may, for example, increase the resources allocated to the O-DU 32 connected to the O-CU 34. Increasing the resources allocated to the O-DU 32 may also mean increasing the number of O-DU 32s. Increasing the number of O-DU 32s can increase the processing capacity in cells where congestion is estimated to occur.

[0062] Furthermore, the Near RT RIC 40 may specify parameters to enhance the directivity of the radio waves transmitted into the target cell by performing beamforming.

[0063] Near RT RIC 40 transmits the identified parameters to E2 node 30 (S47). Near RT RIC 40 transmits the identified parameters to E2 node 30 which manages the identified parameters.

[0064] Here, the Near RT RIC 40 may receive enrichment information from the Non RT RIC 50 before performing the inference in step S45. For example, the Near RT RIC 40 may receive enrichment information via the A1 interface defined between it and the Non RT RIC 50. The Near RT RIC 40 may then add the enrichment information to the input and perform the inference in step S45.

[0065] As explained above, the Near RT RIC 40 can estimate cells where congestion occurs using analytical data obtained by analyzing image data, in addition to performance counters. By using analytical data obtained by analyzing image data as well as performance counters, the Near RT RIC 40 can improve the accuracy of estimating the occurrence of congestion.

[0066] Furthermore, the Near RT RIC40 can improve the accuracy of estimating the occurrence of congestion caused by pedestrian flow by performing inference using enrichment information.

[0067] Furthermore, the learning model that estimates the occurrence of congestion uses analysis data related to the image data, rather than the image data itself, as training data. The analysis data is presented in a smaller amount of data than the image data, such as text data. As a result, when analysis data is used as training data, the processing load for generating the learning model can be reduced compared to when image data is used as training data. Moreover, when analysis data is used as input to the learning model, the processing load for executing inference using the learning model can be reduced compared to when image data is used as input to the learning model.

[0068] Figure 7 is a block diagram showing an example configuration of the RIC device 10, Near RT RIC 40, Non RT RIC 50, etc. (hereinafter referred to as the RIC device 10, etc.). Referring to Figure 7, the RIC device 10, etc. includes a network interface 1201, a processor 1202, and memory 1203. The network interface 1201 is used to communicate with each other's network nodes. The network interface 1201 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series. Here, IEEE stands for Institute of Electrical and Electronics Engineers.

[0069] The processor 1202 reads and executes software (computer programs) from the memory 1203 to perform the processing of the RIC device 10, etc., as described using a flowchart. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include multiple processors.

[0070] Memory 1203 is composed of a combination of volatile and non-volatile memory. Memory 1203 may include storage located away from the processor 1202. In this case, the processor 1202 may access memory 1203 via an I / O (Input / Output) interface, which is not shown.

[0071] In the example shown in Figure 7, the memory 1203 is used to store a group of software modules. The processor 1202 can read these software modules from the memory 1203 and execute them, thereby enabling the RIC device 10 and the like, as described in the above embodiment.

[0072] As explained with reference to Figure 7, each of the processors in the RIC device 10, etc., in the above-described embodiment executes one or more programs that include a set of instructions for causing a computer to perform the algorithm described with reference to the drawings.

[0073] In the examples described above, the program includes a set of instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more of the functions described in the embodiments. The program may be stored on a non-temporary computer-readable medium or a physical storage medium. Examples, but not limited to, include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technologies, CD-ROM, digital versatile disc (DVD), Blu-ray® disc or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices. The program may be transmitted over a temporary computer-readable medium or a communication medium. Examples, but not limited to, include temporary computer-readable medium or a communication medium that includes electrical, optical, acoustic or other forms of propagating signals.

[0074] Although the present disclosure has been described above with reference to embodiments, the present disclosure is not limited to the embodiments described above. Various modifications to the structure and details of the present disclosure can be made as can be understood by those skilled in the art within the scope of the present disclosure. Furthermore, each embodiment can be combined with other embodiments as appropriate.

[0075] Each drawing is merely illustrative to illustrate one or more embodiments. Each drawing may be associated with one or more other embodiments, rather than being associated with only one specific embodiment. As those skilled in the art will understand, various features or steps described with reference to any one drawing can be combined with features or steps shown in one or more other drawings, for example, to create embodiments not explicitly shown or described. Not all features or steps shown in any one drawing to illustrate an exemplary embodiment are necessarily required, and some features or steps may be omitted. The order of steps described in any of the drawings may be changed as appropriate.

[0076] Some or all of the above embodiments may also be described as follows, but are not limited to the following: (Note 1) A RIC device comprising: a communication unit that receives performance counters relating to cells managed by the E2 node from an E2 node and data indicating the state of areas within the cells from a server device; an estimation unit that estimates the congestion state in surrounding cells of a first cell by inputting the performance counters and the data indicating the state of areas within the cells to a learning model; and a control unit that determines parameters relating to the control of the E2 node based on the congestion state. (Note 2) The RIC device according to Note 1, wherein the data indicating the state of areas within the cells is data indicating the results of an analysis of human behavior included in image data indicating the areas within the cells. (Note 3) The RIC device according to Note 2, wherein the analysis results include the orientation of a person and the speed of a person's movement. (Note 4) The RIC device according to Note 2 or 3, wherein the analysis results include information regarding the use of each person's communication terminal. (Note 5) The RIC device according to any one of Notes 1 to 3, wherein the control unit determines the parameters to reduce the number of communication terminals connected to a target cell where congestion is estimated to occur. (Note 6) The RIC device according to Note 2 or 3, wherein the communication unit acquires the analysis results analyzed using image data generated by a surveillance camera monitoring the cell. (Note 7) The RIC device according to Note 6, wherein the communication unit acquires the analysis results from the server device that performs the analysis using the image data. (Note 8) The RIC device according to Note 1, further comprising a management unit that manages a learning model that has been machine-trained using a performance counter managed by the E2 node, analysis results regarding human behavior included in the image data analyzed using image data indicating an area within a cell managed by the E2 node, and congestion information indicating the state of congestion in the cell or surrounding cells of the cell as learning data. (Note 9) The RIC device is a Near RT RIC, and the management unit manages the learning model generated in the Non RT RIC, as described in Note 1 or 2.(Note 10) A communication system comprising: Non RT RIC which generates a learning model by machine learning using performance counters for cells managed by an E2 node, data indicating the state of a region within the cell, and congestion information indicating the state of congestion in surrounding cells of the cell as learning data; and Near RT RIC which estimates the state of congestion in surrounding cells of the cell by inputting the performance counters and data indicating the state within the cell into the learning model, and determines parameters for controlling the E2 node based on the congestion state. (Note 11) A control method which receives performance counters for cells managed by an E2 node from an E2 node, data indicating the state of a region within the cell from a server device, estimates the state of congestion in surrounding cells of a first cell by inputting the performance counters and data indicating the state of a region within the cell into a learning model, and determines parameters for controlling the E2 node based on the congestion state. (Note 12) A program that causes a computer to perform the following actions: receive performance counters from the E2 node regarding the cells managed by the E2 node, receive data indicating the state of the area within the cell from the server device, input the performance counters and the data indicating the state of the area within the cell into a learning model to estimate the congestion state in the surrounding cells of the first cell, and determine parameters related to the control of the E2 node based on the congestion state.

[0077] Some or all of the elements (e.g., configuration and function) described in Appendices 2 to 7 that are subordinate to Appendice 1 may also be subordinate to Appendices 8, 9, and 10 in the same way as those described in Appendices 2 to 7. Some or all of the elements described in any appendice may be applied to various hardware, software, recording means, systems, and methods for recording software.

[0078] This application claims priority based on Japanese Patent Application No. 2025-053768, filed on 27 March 2025, and incorporates all of its disclosures herein.

[0079] 10 RIC device 11 Management unit 12 Communication unit 13 Estimation unit 14 Control unit 20 O-RU 30 E2 node 32 O-DU 34 O-CU 40 Near RT RIC 50 Non RT RIC 60 IoT device 70 Application server 80 UE

Claims

1. A RIC device comprising: a communication unit that receives performance counters related to cells managed by the E2 node from the E2 node and data indicating the state of areas within the cells from a server device; an estimation unit that estimates the congestion state in surrounding cells of a first cell by inputting the performance counters and the data indicating the state of areas within the cells into a learning model; and a control unit that determines parameters related to the control of the E2 node based on the congestion state.

2. The RIC apparatus according to claim 1, wherein the data indicating the state of the region within the cell is data indicating the results of an analysis of human behavior included in the image data indicating the region within the cell.

3. The RIC apparatus according to claim 2, wherein the analysis results include the orientation of the person and the speed of the person's movement.

4. The RIC device according to claim 2 or 3, wherein the analysis results include information regarding the use of each person's communication terminal.

5. The RIC apparatus according to any one of claims 1 to 3, wherein the control unit determines the parameters to reduce the number of communication terminals connected to a target cell where congestion is estimated to occur.

6. The RIC apparatus according to claim 2 or 3, wherein the communication unit acquires the analysis results analyzed using image data generated by a surveillance camera that monitors the cell.

7. The RIC apparatus according to claim 6, wherein the communication unit obtains the analysis results from the server device that performs the analysis using the image data.

8. A communication system comprising: a Non RT RIC that generates a learning model by machine learning using performance counters for cells managed by an E2 node, data indicating the state of a region within the cell, and congestion information indicating the congestion state in surrounding cells of the cell as training data; and a Near RT RIC that estimates the congestion state in surrounding cells of the cell by inputting the performance counters and data indicating the state within the cell into the learning model, and determines parameters related to the control of the E2 node based on the congestion state.

9. A control method comprising: receiving performance counters related to cells managed by the E2 node from the E2 node, receiving data indicating the state of areas within the cells from a server device, inputting the performance counters and the data indicating the state of areas within the cells into a learning model to estimate the congestion state in surrounding cells of a first cell, and determining parameters related to the control of the E2 node based on the congestion state.

10. A program that causes a computer to perform the following actions: receive performance counters related to the cells managed by the E2 node from the E2 node, receive data indicating the state of the area within the cell from the server device, input the performance counters and the data indicating the state of the area within the cell into a learning model to estimate the congestion state in the surrounding cells of the first cell, and determine parameters related to the control of the E2 node based on the congestion state.

Images