RAN node and method

Abstract

A control unit (102) in this RAN node (2A) causes a communication unit (101) to transmit a "first message" to an RAN node (3A). The first message includes information related to a prediction value for a "load parameter" pertaining to a cell (4-1). The first message furthermore includes "state information" pertaining to the cell (4-1), the "state information" indicating at least one of the necessity of offloading traffic in the cell (4-1) and the ability of the cell (4-1) to accept traffic.

Description

[Technical Field]

[0001] The present disclosure relates to a RAN node and method. [Background technology]

[0002] 3GPP (registered trademark) (3rd Generation Partnership Project) specifies communications between RAN (Radio access network) nodes that manage adjacent cells, such as HO (Handover). For example, Non-Patent Document 1 specifies signaling procedures in the radio network layer of the control plane between NG-RAN (Next Generation-Radio access network) nodes in an NG-RAN. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] 3GPP TS 38.423 V16.7.0 (2021-10), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Xn application protocol (XnAP) (Release 16)”. [Non-patent document 2] 3GPP TR 37.816 V16.0.0 (2019-07), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on RAN-centric data collection and utilization for LTE and NR (Release 16)”. [Non-patent document 3] Aurelien Geron, “Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems 2nd Edition”. [Non-patent document 4] Charu C. Aggarwal, “Neural Networks and Deep Learning: A Textbook”. [Non-Patent Document 5] Maxim Lapan, “Deep Reinforcement Learning Hands-On: Apply modern RL methods to practical problems of chatbots, robotics, discrete optimization, web automation, and more, 2nd Edition”. [Non-patent document 6] 3GPP TS 38.300 V16.7.0 (2021-09), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)”. [Non-Patent Document 7] 3GPP TS 23.501 V16.10.0 (2021-09), “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)”. Summary of the Invention [Problem to be solved by the invention]

[0004] One objective of the present disclosure is to provide a RAN node and a method that contribute to collecting information useful for the RAN node to provide a cell. It should be noted that this objective is only one of multiple objectives that multiple embodiments disclosed in this specification aim to achieve. Other objectives or problems and novel features will become apparent from the description of this specification or the accompanying drawings. [Means for solving the problem]

[0005] A RAN node according to a first aspect is a Radio Access Network (RAN) node, Memory and a processor coupled to the memory; a transceiver, the processor is configured to cause the transceiver to transmit a first message to another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of a first cell of the RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Includes:

[0006] A RAN node according to a second aspect is a Radio Access Network (RAN) node, Memory and a processor coupled to the memory; a transceiver, the processor is configured to cause the transceiver to receive a first message transmitted from another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of the first cell of the other RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Includes:

[0007] A method according to a third aspect is a method performed by a Radio Access Network (RAN) node, comprising: transmitting a first message to another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of a first cell of the RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Includes:

[0008] A method according to a fourth aspect is a method performed by a Radio Access Network (RAN) node, comprising: receiving a first message transmitted from another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of the first cell of the other RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Includes: [Effects of the Invention]

[0009] According to the present disclosure, a RAN node and method can be provided that helps the RAN node gather information useful for providing a cell. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a communication system according to a first embodiment. [Figure 2] FIG. 1 is a diagram illustrating an example of the configuration of a RAN node. [Figure 3] FIG. 2 is a diagram illustrating an example of the operation of the communication system according to the first embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of the operation of the communication system according to the second embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of the configuration of a communication system according to a third embodiment. [Figure 6] FIG. 10 is a diagram illustrating an example of the operation of the communication system according to the third embodiment. [Figure 7A] FIG. 10 is a diagram illustrating an example of time-series data of information related to predicted values ​​of load parameters. [Figure 7B] FIG. 10 is a diagram illustrating another example of time-series data of information related to predicted values ​​of load parameters. [Figure 8] A diagram showing the Resource Status Reporting Initiation procedure. [Figure 9] FIG. 10 is a diagram illustrating another example of time-series data of information related to predicted values ​​of load parameters. [Figure 10] FIG. 10 is a diagram illustrating the procedure for Resource Status Reporting. [Figure 11] FIG. 10 illustrates a PREDICTIONS Reporting Initiation procedure. [Figure 12] FIG. 1 is a diagram illustrating the procedure for PREDICTIONS Reporting. [Figure 13] FIG. 10 illustrates the LB HO negotiation procedure between RAN nodes when traffic is offloaded. [Figure 14] FIG. 10 illustrates the LB HO negotiation procedure between RAN nodes when traffic is accepted. [Figure 15] FIG. 1 is a diagram illustrating an example of the hardware configuration of a RAN node. [Figure 16A]FIG. 10 is a diagram illustrating an example of the configuration of a RESOURCE STATUS REQUEST message. [Figure 16B] FIG. 16B is a diagram showing an example of the configuration of a RESOURCE STATUS REQUEST message (continuation of FIG. 16A). [Figure 16C] FIG. 16B is a diagram showing an example of the configuration of a RESOURCE STATUS REQUEST message (continuation of FIG. 16B). [Figure 16D] FIG. 16C is a diagram showing an example of the configuration of a RESOURCE STATUS REQUEST message. [Figure 17] FIG. 10 is a diagram illustrating an example of the configuration of a RESOURCE STATUS UPDATE message. [Figure 18A] FIG. 10 is a diagram illustrating an example of the configuration of a Radio Resource Status IE. [Figure 18B] FIG. 18B is a diagram showing an example of the configuration of a Radio Resource Status IE (continuation of FIG. 18A). [Figure 18C] FIG. 18B is a diagram showing an example of the configuration of a Radio Resource Status IE. [Figure 18D] FIG. 18C is a diagram showing an example of the configuration of a Radio Resource Status IE. [Figure 18E] FIG. 18B is a diagram showing an example of the configuration of a Radio Resource Status IE (continuation of FIG. 18D). [Figure 18F] FIG. 18B is a diagram showing an example of the configuration of a Radio Resource Status IE (continuation of FIG. 18E). [Figure 18G] FIG. 18F is a diagram showing an example of the configuration of a Radio Resource Status IE. [Figure 18H] FIG. 18B is a diagram showing an example of the configuration of a Radio Resource Status IE (continuation of FIG. 18G). [Figure 19] FIG. 10 is a diagram illustrating an example of the configuration of a Composite Available Capacity Group IE. [Figure 20] FIG. 10 is a diagram illustrating an example of the configuration of a Composite Available Capacity IE. [Figure 21] A diagram showing an example of the configuration of Cell Capacity Class Value IE. [Figure 22] FIG. 10 is a diagram illustrating an example of the configuration of a Capacity Value IE. [Figure 23] FIG. 10 is a diagram illustrating an example of the configuration of Slice Available Capacity IE. [Figure 24A] FIG. 10 is a diagram illustrating an example of the configuration of a PREDICTIONS REQUEST message. [Figure 24B] FIG. 24B is a diagram showing an example of the configuration of a PREDICTIONS REQUEST message (continuation of FIG. 24A). [Figure 25] FIG. 10 is a diagram illustrating an example of the configuration of a PREDICTIONS RESPONSE message. [Figure 26] FIG. 10 is a diagram illustrating an example of the configuration of a PREDICTIONS UPDATE message. [Figure 27A] FIG. 10 is a diagram illustrating an example of the configuration of a Radio Resource Load Predictions IE. [Figure 27B] FIG. 27B is a diagram showing an example of the configuration of a Radio Resource Load Predictions IE (continuation of FIG. 27A). [Figure 27C] FIG. 27B is a diagram showing an example of the configuration of a Radio Resource Load Predictions IE. [Figure 28A] FIG. 10 is a diagram illustrating a configuration example of a Load prediction type. [Figure 28B] FIG. 28B is a diagram showing an example of the configuration of the Load prediction type (continuation of FIG. 28A). [Figure 29] FIG. 10 is a diagram illustrating an example of the configuration of a prediction time series. [Figure 30] FIG. 10 is a diagram illustrating an example of an LB HO proposal message. [Figure 31]FIG. 10 is a diagram illustrating an example of LB HO accept. [Figure 32A] FIG. 10 is a diagram illustrating an example of an LB HO proposal message. [Figure 32B] FIG. 32B is a diagram showing an example of an LB HO proposal message (continuation of FIG. 32A). [Figure 33] FIG. 10 is a diagram illustrating an example of a first LB HO accept. [Figure 34] FIG. 10 is a diagram illustrating an example of a second LB HO accept. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Note that the following description and drawings have been omitted or simplified as appropriate for clarity of explanation. Furthermore, in the following drawings, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary. Furthermore, in this disclosure, unless otherwise specified, "at least one of A or B (A / B)" may mean any one of A or B, or both A and B. Similarly, when "at least one" is used with respect to three or more elements, it may mean any one of these elements, or any multiple elements (including all elements).

[0012] First Embodiment <Example of communication system configuration> FIG. 1 is a diagram illustrating a configuration example of a communication system according to a first embodiment. The communication system 1 is, for example, a fifth-generation mobile communication system (5G system). The 5G system is New Radio Access (NR), which is a fifth-generation radio access technology. Note that the communication system 1 is not limited to a fifth-generation mobile communication system and may be a different mobile communication system such as a Long Term Evolution (LTE) system, an LTE-Advanced system, or a sixth-generation mobile communication system. The communication system 1 may also be another wireless communication system including at least a Radio Access Network (RAN) node and user equipment (UE). The communication system 1 may also be a communication system in which an LTE evolved NodeB (ng-eNB), which is a base station in LTE (Long Term Evolution), is connected to a 5G core network (5GC) via an NG interface.

[0013] The communication system 1 includes a RAN node 2 and a RAN node 3. Although only two RAN nodes are illustrated in Fig. 1, the communication system 1 may include three or more RAN nodes.

[0014] The RAN node 2 and the RAN node 3 may be gNBs. The gNB is a node that terminates NR user plane and control plane protocols for the UE and connects to the 5GC via an NG interface. The RAN node 2 and the RAN node 3 may be ng-eNBs. The ng-eNB is a node that terminates E-UTRA (Evolved Universal Terrestrial Radio Access) user plane and control plane protocols for the UE and connects to the 5GC via an NG interface. The RAN node 2 and the RAN node 3 may be CUs (Central Units) in a C-RAN (cloud RAN) configuration or gNB-CUs. The gNB-CU is a logical node that hosts the gNB's RRC (Radio Resource Control) protocol, SDAP (Service Data Adaptation Protocol) protocol, and PDCP (Packet Data Convergence Protocol) protocol. Alternatively, the gNB-CU is a logical node that hosts the en-gNB's RRC protocol and PDCP protocol that controls the operation of one or more gNB-Distributed Units (gNB-DUs). The gNB-CU terminates the F1 interface connecting to the gNB-DU. RAN node 2 and RAN node 3 may be CP (Control Plane) Units or gNB-CU-CP (gNB-CU-Control Plane). The gNB-CU-CP is a logical node that hosts the RRC protocol and the control plane portion of the PDCP protocol of the gNB-CU for the en-gNB or gNB. The gNB-CU-CP terminates the E1 interface connecting to the gNB-CU-UP (gNB-CU-User Plane) and the F1-C interface connecting to the gNB-DU. The gNB-CU-UP is a logical node that hosts the user plane portion of the PDCP protocol of the gNB-CU for the en-gNB. The gNB-CU-UP terminates the E1 interface connecting to the gNB-CU-CP and the F1-U interface connecting to the gNB-DU.

[0015] The RAN node 2 and the RAN node 3 may be eNBs or eNB-CUs. The RAN node 2 and the RAN node 3 may be EUTRAN (Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network) nodes or NG-RAN (Next Generation Radio Access Network) nodes. The EUTRAN node may be an eNB or en-gNB. The NG-RAN node may be a gNB or ng-eNB. The en-gNB provides NR user plane and control plane protocol termination for the UE and operates as a secondary node in EN-DC (NR Dual Connectivity).

[0016] RAN node 2 and RAN node 3 establish an inter-node interface and communicate with each other through the inter-node interface, which may be an Xn interface (a network interface between NG-RAN nodes), an X2 interface, or any other inter-node interface.

[0017] Also in FIG. 1, RAN node 2 serves at least one cell 4-1 (first cell). RAN node 2 operates cell 4-1 and connects to and communicates with UEs located in cell 4-1. RAN node 3 serves at least one cell 4-2 (second cell). RAN node 3 operates cell 4-2 and connects to and communicates with UEs located in cell 4-2. Here, cells 4-1 and 4-2 are adjacent to each other. "Cell 4-1 being adjacent to cell 4-2" may refer to a state in which cells 4-1 and 4-2 are adjacent to each other, or may refer to a state in which part of cell 4-1 overlaps with cell 4-2.

[0018] Fig. 2 is a diagram showing an example of the configuration of a RAN node. In Fig. 2, RAN node 2 and RAN node 3 are collectively referred to as RAN node 100. RAN node 100 includes a communication unit 101 and a control unit 102. The communication unit 101 and the control unit 102 may be software or modules that perform processing by a processor executing a program stored in a memory. Alternatively, the communication unit 101 and the control unit 102 may be hardware such as a circuit or a chip.

[0019] The communication unit 101 connects to and communicates with other RAN nodes and core network nodes included in the access network. The communication unit 101 also connects to and communicates with UEs. More specifically, the communication unit 101 receives various types of information from other RAN nodes, core network nodes, and UEs. The communication unit 101 also transmits various types of information to other RAN nodes, core network nodes, and UEs.

[0020] The control unit 102 reads out and executes various information and programs stored in the memory, thereby executing various processes of the RAN node 100. The control unit 102 performs processing in accordance with any or all of the setting information such as various information elements (IEs), various fields, and various conditions included in the message received by the communication unit 101. The control unit 102 is configured to be able to execute processes of multiple layers. The multiple layers may include a physical layer, a media access control (MAC) layer, a radio link control (RLC) layer, a PDCP layer, an RRC layer, and a non-access stratum (NAS) layer.

[0021] The configuration example of the communication system shown above is common to the first and second embodiments. Furthermore, RAN node 2 is a general term for RAN nodes 2A and 2B in the first and second embodiments, and RAN node 3 is a general term for RAN nodes 3A and 3B in the first and second embodiments. In the first and second embodiments, different operations performed by different RAN nodes will be described.

[0022] <Example of communication system operation> 3 is a diagram showing an example of the operation of the communication system according to the first embodiment. Hereinafter, an example of the operation of the communication system 1 will be described with reference to FIG.

[0023] In step S1, the RAN node 2A transmits a first message to the RAN node 3A. The first message includes information related to a predicted value of a parameter related to the load of the cell 4-1. The "load parameter" is a parameter that can be an indicator of the load of the cell 4-1. The "predicted value of the load parameter" means a value of the load parameter that is not an actual measured value. The "information related to the predicted value" may include predicted values ​​at each of multiple timings. For example, the "predicted value of the load parameter" may include a predicted value of the load parameter for the timing at which the prediction is performed, a predicted value of the load parameter for a timing after that timing, or both. Note that hereinafter, the "load parameter" may be referred to as a "load parameter."

[0024] Furthermore, for example, the "information related to the predicted value" may include the predicted value and the prediction accuracy of the predicted value. Furthermore, for example, the "information related to the predicted value" may include a predicted value assuming that the number of active user equipments (UEs) in a domain related to the cell load parameter (e.g., a cell, a beam, a slice, or any combination thereof) does not change during the prediction period, a predicted value taking into account a change in the number of active UEs in a domain related to the cell load parameter during the prediction period, or both.

[0025] Furthermore, the first message includes status information of the cell 4-1. The "status information" indicates at least either the necessity of offloading traffic in the cell 4-1 or the ability of the cell 4-1 to accept traffic. Here, the "necessity of offloading" may indicate only binary information, "whether offloading is necessary" or may indicate ternary or more information, such as indicating the "degree of need for offloading" in detail. Similarly, the "ability to accept traffic" may indicate only binary information, "whether traffic can be accepted" or may indicate ternary or more information, such as indicating the "degree of ability to accept traffic" in detail. However, the information included in the status information is not limited to this.

[0026] Then, the RAN node 3A receives the first message transmitted from the RAN node 2A. Note that, as will be described in detail later, the first message is not particularly limited, and may be, for example, a Resource Status Update message of the Resource Status Reporting procedure, or a message of a new procedure (for example, a Predictions Update message of the Predictions reporting procedure).

[0027] As described above, according to the first embodiment, the RAN node 2A transmits a first message to the RAN node 3A. The first message includes information related to predicted values ​​of load parameters of the cell 4-1. This allows the RAN node 3A to obtain information about the load parameters at a timing closer to the timing used for processing than the timing of actual measurements. As a result, the accuracy of processing by the RAN node 3A can be improved. That is, the RAN node 2A contributes to the RAN node 3A gathering information useful for providing the cell. The first message also includes status information of the cell 4-1 indicating at least either the need for traffic offload in the cell 4-1 or the ability of the cell 4-1 to accept traffic. This further allows the RAN node 2A to contribute to the RAN node 3A gathering information useful for providing the cell.

[0028] Second Embodiment 4 is a diagram showing an example of the operation of the communication system according to the second embodiment. Hereinafter, an example of the operation of the communication system 1 in the second embodiment will be described with reference to FIG.

[0029] In step S2, the RAN node 3B transmits a second message to the RAN node 2B. The second message includes, for example, information regarding a transmission request for information related to the predicted value (a report request for information related to the predicted value). Hereinafter, the "transmission request for information related to the predicted value" may be simply referred to as a "transmission request for the predicted value." For example, the "transmission request for the predicted value" may be made for each combination of a load parameter and a prediction type. For example, a bit field may be prepared for each combination of a load parameter and a prediction type in the second message, and depending on the bit value included in the bit field, it may be indicated that a predicted value for the combination corresponding to the bit field is requested or that a predicted value for the combination corresponding to the bit field is not requested. For example, when the bit value of the bit field is "1," a predicted value for the combination corresponding to the bit field is requested. On the other hand, when the bit value of the bit field is "0," a predicted value for the combination corresponding to the bit field is not requested.

[0030] Furthermore, for example, the second message may include information regarding a reporting period for the predicted value. The "reporting period for the predicted value" means, for example, the time interval between the transmission timings of two first messages containing the predicted value when the predicted value is repeatedly transmitted by being included in the first message.

[0031] For example, the second message may also include information about a prediction granularity related to the timing interval of the predicted values, where "prediction granularity" means the time interval between the timings corresponding to each two predicted values ​​when the first message includes multiple predicted values.

[0032] Furthermore, the second message may include, for example, information regarding a request to transmit status information (a request to report status information). For example, a bit field for a request to transmit status information may be provided in the second message, and depending on the bit value included in the bit field, it may indicate that transmission of status information is requested or that transmission of status information is not requested. For example, when the bit value of the bit field is "1," transmission of status information is requested. On the other hand, when the bit value of the bit field is "0," transmission of status information is not requested.

[0033] Then, the RAN node 2B receives the second message transmitted from the RAN node 3B. Then, in response to the request to transmit the predicted value and the request to transmit the status information in the second message, the RAN node 2B transmits a first message including information related to the predicted value of the load parameter of the cell 4-1 and status information of the cell 4-1 to the RAN node 3B. Note that, as will be described in detail later, the second message is not particularly limited, and may be, for example, a RESOURCE STATUS REQUEST message defined in section 9.1.3.18 of Non-Patent Document 1, or a message of a new procedure (for example, a Predictions Request message of the Predictions reporting initiation procedure).

[0034] As described above, according to the second embodiment, the RAN node 3B transmits a second message to the RAN node 3A. The second message includes information regarding a request for transmission of predicted values. Therefore, the RAN node 3B can cause the RAN node 3A to transmit information related to load parameters at a timing closer to the timing used for processing than the timing of actual measured values. This allows the RAN node 3B to obtain information related to load parameters at a timing closer to the timing used for processing than the timing of actual measured values. As a result, the accuracy of processing by the RAN node 3B can be improved. That is, the RAN node 2B and the RAN node 3B contribute to the RAN node 3B collecting information useful for providing the cell. The second message further includes information regarding a request for transmission of status information. Therefore, the RAN node 3B can cause the RAN node 3A to transmit status information of the cell 4-1 indicating at least either the need for traffic offload in the cell 4-1 or the ability of the cell 4-1 to accept traffic. This further allows the RAN node 2B to contribute to the RAN node 3B collecting information useful for providing the cell.

[0035] Third Embodiment In the third embodiment, a specific example of the communication system shown in the first and second embodiments will be described.

[0036] <Example of communication system configuration> 5 is a diagram illustrating a configuration example of a communication system according to the third embodiment. The communication system 10 is, for example, a 5G system, and includes a RAN node 20 and a RAN node 30, which are gNBs or gNB-CUs.

[0037] In FIG. 5, the RAN node 20 provides cells 41-43. Specifically, the RAN node 20 operates the cells 41-43, and connects to and communicates with UEs located in the cells 41-43. In this example, the RAN node 20 is connected to a UE 51 located in the cell 43. Also in FIG. 5, the RAN node 30 provides cells 44-46. Specifically, the RAN node 30 operates the cells 44-46, and connects to and communicates with UEs located in the cells 44-46. The RAN node 20 and the RAN node 30 establish an inter-node Xn interface and communicate with each other via the inter-node interface. Note that, for simplicity of explanation, the RAN node 20 and the RAN node 30 are described as each operating three cells, but the number of cells operated by each of the RAN node 20 and the RAN node 30 is not limited to this.

[0038] In FIG. 5 , cell 43 served by RAN node 20 is adjacent to cell 44 served by RAN node 30. Hereinafter, cells 43 and 44 may be referred to as "neighbor cells." Herein, "neighbor cells" refers to two or more cells having at least partially overlapping coverage areas. Similarly, two or more RAN nodes having neighbor cells are referred to as "neighboring RAN nodes." For example, RAN nodes 20 and 30 are neighboring RAN nodes. Because of this neighbor cell relationship, handover processing can be performed between cell 43 and cell 44. Meanwhile, cells 41 and 42 of RAN node 20 are not adjacent to any of cells of RAN node 30. Furthermore, cells 45 and 46 of RAN node 30 are not adjacent to any of cells of RAN node 20. Therefore, hereinafter, cells 41 and 42 may be referred to as "internal cells" of RAN node 20, and cells 45 and 46 may be referred to as "internal cells" of RAN node 30.

[0039] In this situation, the RAN node 20 and the RAN node 30 recognize their neighboring relationships based on at least one of the settings made in each device and measurement reports sent from UEs located in cells served by the nodes. That is, the RAN node 20 recognizes that the cell 43 is neighboring the cell 44, and the RAN node 30 recognizes that the cell 44 is neighboring the cell 43. However, the RAN node 20 and the RAN node 30 do not recognize each other's internal topology unless they perform special processing. For example, the RAN node 20 does not recognize the internal topology of the RAN node 30 (especially the topology of the cells 45 and 46, which are not neighboring cells).

[0040] Furthermore, the RAN node 20 is an AI-enabled RAN node (RAN AI / ML node). The RAN node 20 may be referred to as a RAN node equipped with an AI function, or as a RAN node equipped with an AI function. In the third embodiment, the RAN node 20 is referred to as an AI-enhanced RAN node. The RAN node 20 is equipped with an AI function that performs communication control based on information received from other devices (other network elements) including the RAN node 30 and UEs such as the UE 51, and in the third embodiment, the RAN node 20 is equipped with machine learning (ML) as an example of the AI ​​function. In this example, the AI / ML function executes a process of "predicting values ​​related to load-related parameters" and a process of "determining cell state information," but the processes executed are not limited to these.

[0041] In this disclosure, the terms "AI-enabled RAN node," "AI-enabled RAN node," and "AI-equipped RAN node" refer to a RAN node that uses AI / ML models to control communications based on information received from other devices (other network elements). The RAN node 20 may operate as an AI-equipped RAN node, for example, by communicating with a RAN intelligence device (not shown) and using AI / ML models held by the RAN intelligence device. Alternatively, the RAN node 20 may operate as an AI-equipped RAN node by having the functionality of the RAN intelligence device and using AI / ML models held by the RAN intelligence device. Alternatively, the RAN node 20 may operate as an AI-equipped RAN node by obtaining AI / ML models from the RAN intelligence device and using the AI / ML models.

[0042] The RAN intelligence device is, for example, a control device that makes the RAN intelligent and controls communications in the RAN. The RAN intelligence device may be, for example, a RAN Intelligent Controller (RIC) defined in O-RAN (Open-RAN). The RAN intelligence device performs, for example, policy management, analysis of various RAN information, AI-based function management, load balancing for each UE, radio resource management, QoS (Quality of Service) management, and mobility management such as handover control.

[0043] An example configuration of the RAN nodes 20 and 30 is as shown in Figure 2. Here, when the RAN node 100 operates as the RAN node 20 and the RAN intelligence device is provided outside the RAN node 20, the communication unit 101 connects to and communicates with the RAN intelligence device. In this case, the communication unit 101 may communicate with the RAN intelligence device, and the control unit 102 may enable the use of an AI / ML model held by the RAN intelligence device. Alternatively, the communication unit 101 may communicate with the RAN intelligence device and acquire the AI / ML model held by the RAN intelligence device.

[0044] When the RAN node 100 is the RAN node 20, the control unit 102 may use the AI / ML model to perform RAN communication control based on information received by the communication unit 101. Specifically, the control unit 102 may input the information received by the communication unit 101 to the AI / ML model and cause it to output various information related to RAN communication control and / or various information related to UE communication control. The control unit 102 may control the RAN and the UE by transmitting such various information to the RAN node and the UE. The control unit 102 may machine-learn the AI / ML model based on the information received by the communication unit 101. Note that the terms "learning," "training," and "training" in the present disclosure refer to automatically adjusting the parameters of an AI / ML model and constructing the model.

[0045] The third embodiment provides a deployment scenario in which the AI ​​function in the RAN node serves only one gNB or gNB-CU, thereby providing a fully distributed and autonomous solution. However, the AI ​​function in the RAN node may also serve multiple gNBs or gNB-CUs.

[0046] 5 is a Network Data Analytic Function (NWDAF). The CN node 60 has a function of collecting and analyzing various data acquired in the network in 5GC. The OAM (Operations, Administration and Management) device 70 has an operation and management function for the communication system 10.

[0047] <Example of communication system operation> Fig. 6 is a diagram showing an example of the operation of a communication system according to the third embodiment. Below, an outline of the processing executed in the communication system 10 will be described with reference to Fig. 6. Note that in this embodiment, it is assumed that the RAN node 20 knows the adjacent RAN node 30, and that the RAN node 20, the RAN node 30, the CN node 60, and the OAM device 70 have mutually established inter-node interfaces. Note that the order of the steps shown below is not limited unless explicitly stated. Furthermore, the presence or absence of each step or the presence or absence of detailed processing of each step can be changed as appropriate.

[0048] (Step S1001) The RAN node 20 acquires various types of information from a UE (for example, UE 51) located in a cell provided by the RAN node 20.

[0049] The information acquired from the UE (for example, the UE 51) includes, for example, some or all of the following information: UE location information Information about the quality of service required for the UE (UE QoS requirements) UE traffic information: for example, average traffic rate or more detailed information about the traffic (such as information about the next packet arrival). Information about UE radio measurements (UE radio measurements): For example, quality information measured for the serving cell in which the UE is located, the cells adjacent to this cell, or both. The quality information may include at least one of RSRP, RSRQ, and SINR. Information about inactive UEs

[0050] (Step S1002) The RAN node 20 acquires various information from the adjacent RAN nodes 30 .

[0051] The "information acquired from the adjacent RAN node 30" includes, for example, some or all of the information listed below.

[0052] Load information (which may also be called Load metrics) on adjacent RAN nodes 30: The load information may be information indicating traffic or may be information relating to traffic. The load information may also be information indicating a bit rate or may be information relating to the bit rate. For example, the load information may be information indicating GBR (Guaranteed Bit Rate) or non-GBR for at least one of DL (Downlink) / UL (Uplink). The load information may also be information indicating the amount of resource blocks used or may be information relating to the amount of resource blocks used. For example, the load information may be information indicating the total amount of PRBs (Physical Resource Blocks) used. As a specific example, the load information may be information indicating at least one of the following: At least one of GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage in at least one of DL (Downlink) / UL (Uplink) in at least one of each cell or each beam provided by the RAN node 30 - At least one of DL / UL, GBR, non-GBR, or total PRB usage per slice in each cell The information about the load may also include individual load information for at least one of NUL (Normal UL) / SUL (Supplementary UL).

[0053] Information related to handover performance with this RAN node: This is information related to the performance of handover between the cell of the RAN node 20 and the cell of an adjacent RAN node 30.

[0054] Information about UEs moving toward this RAN node: This is information about UEs located in the cells of neighboring RAN nodes 30 and moving toward the RAN node 20.

[0055] If the RAN node 30 is also an AI-enabled RAN node, the information acquired from the adjacent RAN node 30 may include "information related to predicted values ​​for load parameters of the cell of the adjacent RAN node 30." Furthermore, if the RAN node 30 is also an AI-enabled RAN node, the information acquired from the adjacent RAN node 30 may include "state information of the cell of the adjacent RAN node 30."

[0056] Note that a "slice" in this disclosure refers to a network slice provided by a core network (e.g., 5GC), as defined in, for example, section 16.3.1 of Non-Patent Document 6. In particular, network slicing can be implemented in NR connected to 5GC and NG-RAN of E-UTRA connected to 5GC. A slice consists of a RAN part and a CN part, and slice support is based on the principle that traffic for different slices is handled by different PDU sessions. The network can implement different slices by providing scheduling or different L1 / L2 configurations.

[0057] Each slice is uniquely identified by a Single Network Slice Selection Assistance Information (S-NSSAI), as defined in Non-Patent Document 7. An NSSAI (Network Slice Selection Assistance Information) contains one or more S-NSSAIs, which are a combination of: A mandatory SST (Slice / Service Type) field that identifies the type of slice and consists of 8 bits (range 0-255). An optional 24-bit SD (Slice Differentiator) field that distinguishes slices with the same SST field. This list contains up to eight S-NSSAIs. The UE provides an NSSAI for slice selection in RRCSetupComplete if it is provided by the NAS. A network can support a large number of slices (several hundred), but a UE is not required to support more than eight slices simultaneously. A BL (Bandwidth reduced Low complexity) UE or NB-IoT (Narrow Band Internet of Things) UE supports up to eight slices simultaneously.

[0058] The slice is notified, for example, from the core network (e.g., 5GC) to the NAS layer of the UE, and is notified from the NAS layer of the UE to the AS layer (e.g., RRC). The network slice selected and the intended network slice by the UE may be referred to as the selected NSSAI and the intended NSSAI, respectively. The selected network slice (selected NSSAI) may be referred to as the allowed NSSAI, meaning the network slice permitted for use by the core network. The SST may be included in the S-NSSAI (i.e., the S-NSSAI may include information about the SST).

[0059] Each network slice selected or intended by the UE may be identified by an identifier, S-NSSAI. The selected or intended network slice may be S-NSSAI(s) included in the Configured NSSAI or S-NSSAI(s) included in the Allowed NSSAI. Note that the S-NSSAIs in the Requested NSSAI included in the NAS Registration Request message must be part of the Configured NSSAI and / or the Allowed NSSAI. Therefore, the intended network slice may be S-NSSAI(s) included in the Requested NSSAI.

[0060] Such network slicing uses Network Function Virtualization (NFV) and software-defined networking (SDN) technologies to create multiple virtualized logical networks on a physical network. Each virtualized logical network is called a network slice or network slice instance, and includes logical nodes and functions used for specific traffic and signaling. The NG RAN and / or the NG Core have a Slice Selection Function (SSF). The SSF selects one or more network slices suitable for the NG UE based on information provided by the NG UE and / or the NG Core.

[0061] The slices are distinguished by the services or use cases provided to a UE on each network slice. Use cases include, for example, enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communication (URLLC), and massive Machine Type Communication (mMTC). These are called slice types (e.g., Slice / Service Type (SST)). A RAN node providing communication to a UE may assign to the UE a RAN slice and a radio slice associated with a network slice of the core network selected for the UE to provide end-to-end network slicing to the UE.

[0062] (Step S1003) The RAN node 20 obtains "network information" from the CN node 60 (NWDAF).

[0063] The network information can be acquired, for example, via an existing NWDAF subscription service. The network information transmitted from the CN node 60 may include, for example, network function load, slice load, and service experience. The network information may include network performance. The network information may also include UE mobility. Here, the network performance may include statistics or predictions of the status of RAN nodes such as gNBs, resource usage, communication and mobility performance, the number of UEs in an area of ​​interest, and the average rate of successful handovers. The UE mobility may also be a time series of statistics or predictions of the locations of a specific UE or a group of UEs. However, the RAN node 20 may acquire such network information from devices on the 5GC, not limited to the CN node 60.

[0064] (Step S1004) As the RAN node 20 is an AI-enhanced RAN node, it obtains network information from the OAM device 70.

[0065] The network information transmitted from the OAM device 70 may include area information such as the cell in which the UE is located, traffic information, and statistical information. The statistical information may include statistical information related to handover and statistical information related to call processing such as call connection and call disconnection. Note that step S1004 may be performed before step S1003, after step S1003, or simultaneously with step S1003.

[0066] In this way, the RAN node 20 can receive network information from the CN node 60 and the OAM device 70. Therefore, the system including the RAN node 20, the CN node 60, and the OAM device 70 contributes to the AI-enabled RAN node 20 transmitting and receiving information to and from the CN node 60 and the OAM device 70. Furthermore, the RAN node 20 can further optimize RAN communication control using the AI ​​function provided in the RAN node 20 based on the network information.

[0067] (Step S1005) The RAN node 20 acquires its own "internal information."

[0068] The "internal information" may include a time series of previously measured (generated) load-related information. The "internal information" may also include information regarding the distribution of UEs between slices, cells, beams, or any combination thereof of the RAN node 20. The "internal information" may also include information regarding the operation of a load balancing algorithm applied between slices, cells, beams, or any combination thereof of the RAN node 20.

[0069] (Step S1006) The RAN node 20 performs initial or periodic training of the AI / ML model held by the RAN intelligence device or the AI / ML model acquired from the RAN intelligence device, based on various information (e.g., measurement values) acquired in steps S1001 to S1005. The AI / ML model is a machine learning (ML) model that receives the information acquired in steps S1001 to S1005 and controls RAN communications. In this embodiment, the AI / ML model receives the information acquired in steps S1001 to S1005 and outputs at least "information related to predicted values ​​of load parameters" and a "load status indicator." This load status indicator is a specific example of the "status information" described in the first embodiment. When the RAN node 20 acquires information for the first time in steps S1001 to S1005, it performs initial training of the AI / ML model. Furthermore, the RAN node 20 periodically trains and updates the AI / ML model every time it acquires information in steps S1001 to S1005. This ensures that the AI / ML is sufficiently trained. The RAN node 20 may also pass the information acquired in steps S1001 to S1005 to, for example, a training device for updating the AI / ML model. Note that the AI / ML model used in this disclosure may be a new one or a known ML model (for example, as described in Non-Patent Documents 3-5).

[0070] (Steps S1007-S1011) In steps S1007-S1011, the RAN node 20 acquires various pieces of information in the same manner as in steps S1001-S1005.

[0071] (Step S1012) When the AI / ML is sufficiently trained, the RAN node 20 generates "information related to predicted values ​​of load parameters of the cell of the RAN node 20" using the information obtained in S1007-S1011. Also, when the AI / ML is sufficiently trained, the RAN node 20 generates "load status indicators" using the information obtained in S1007-S1011.

[0072] Regarding "Information related to predicted values ​​of load parameters": The "cell load parameters" may include, for example, at least one of the following: For the requested cells, beams, and slices: At least one of GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage for at least one of DL (Downlink) / UL (Uplink) for each beam of each cell provided by the RAN node 20 At least one of GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage for at least one of DL (Downlink) / UL (Uplink) for each slice of each cell provided by the RAN node 20 Regarding the required cells and beams: DL, UL, and Supplementary UL (SUL) capacity, including at least one of the per cell capacity and per beam capacity of each cell provided by the RAN node 20. Regarding requested cells and slices: Capacity of at least one of DL (Downlink) / UL (Uplink) for each beam of each cell provided by the RAN node 20

[0073] Furthermore, the prediction of each parameter related to the cell load may include the following "prediction type." "Predictions for fixed number of UEs" - Average load prediction - Minimum and maximum load prediction "Predictions for changing number of UEs" - Average load prediction - Minimum and maximum load prediction

[0074] That is, a prediction for a fixed number of UEs, a prediction for a variable number of UEs, items included in a prediction for a fixed number of UEs (average load prediction, minimum load prediction, and maximum load prediction), and any combination of items included in a prediction for a variable number of UEs (average load prediction, minimum load prediction, and maximum load prediction) can each be one "prediction type."

[0075] For example, the following prediction types may exist: Five examples are given here, but the present invention is not limited to these. "prediction type 1" = "prediction for a fixed number of UEs: average load prediction" "Prediction type 2" = "Forecast for a fixed number of UEs: average load forecast, minimum load forecast, maximum load forecast" "Prediction type 3" = "Forecast for a fixed number of UEs: Minimum load prediction, Maximum load prediction" Forecast Type 4 = Forecast for a fixed number of UEs: Average Load Forecast + Forecast for a variable number of UEs: Average Load Forecast "Prediction type 5" = "Forecast for a fixed number of UEs: average load forecast, minimum load forecast, maximum load forecast" + "Forecast for a variable number of UEs: average load forecast, minimum load forecast, maximum load forecast"

[0076] Here, "Predictions for a fixed number of UEs" refers to predictions that assume that the number of active user equipments (UEs) in a domain (e.g., cell, beam, slice, or any combination thereof) related to the load parameter remains unchanged during the prediction period. Additionally, "Predictions for a changing number of UEs" refers to predictions that take into account changes in the number of active UEs in a domain (e.g., cell, beam, slice, or any combination thereof) related to the load parameter during the prediction period. Also, the "average load forecast" is a forecast of the average load value based on the current measured load values ​​for the cell of interest. Furthermore, the "minimum load prediction" is a prediction of the minimum load value based on the current measured load values ​​of the cell of interest and the internal cell, assuming offloading of traffic from the cell of interest to an internal cell adjacent to the cell of interest (e.g., internal cell 42 adjacent to cell 43). Furthermore, the "maximum load forecast" is a forecast of the maximum load value based on the current measured load values ​​of the cell of interest and the internal cell, assuming offloading of traffic from an internal cell adjacent to the cell of interest (e.g., internal cell 42 adjacent to cell 43) to the cell of interest.

[0077] Furthermore, the "information related to predicted values ​​of load parameters" may be expressed as a time series. FIG. 7A is a diagram illustrating an example of time series data of information related to predicted values ​​of load parameters. In the example shown in FIG. 7A, the time series data of the "information related to predicted values" includes multiple data sets. In FIG. 7A, one data set is represented as a part enclosed in parentheses. Each data set includes timing information (time(N)) and a predicted value (load_value(N)).

[0078] FIG. 7B is a diagram illustrating another example of time-series data of information related to predicted values ​​of load parameters. In the example shown in FIG. 7B, the time-series data of "information related to predicted values" includes multiple data sets. In FIG. 7B, one data set is represented as a part enclosed in parentheses. Each data set includes timing information (time(N)), a predicted value (load_value(N)), and prediction accuracy (load_accuracy(N)).

[0079] Additionally, the time series data of the "information related to the predicted value" may include multiple data sets with a predetermined "prediction granularity." The "prediction granularity" corresponds to the timing interval of the predicted value. That is, in the examples of FIGS. 7A and 7B, the "prediction granularity" corresponds to "time (N) - time (N-1)."

[0080] About the "Load Status Indicator": The cell for which the "load status indicator" is to be generated (that is, the cell of interest) is, for example, the neighboring cell 43. This load status indicator is a specific example of the "status information" shown in the first embodiment.

[0081] The load status indicator may be information indicating the amount of traffic or information related to the amount of traffic. For example, the load status indicator may be capable of presenting multiple candidate values, including a value indicating that traffic offloading is required in the cell of the transmitting RAN node and a value indicating that the cell is capable of accepting traffic. The multiple candidate values ​​may be defined, for example, by a bit string.

[0082] A first example of a load status indicator encoding is as follows: "shall offload traffic" "should offload traffic" "may offload traffic" "OK with current load" "can accept small traffic" "can accept some traffic" "can accept many traffic"

[0083] And here is a second example of encoding a load status indicator, which is expressed in the integer range [-100..100], with an example mapping for that range: "Traffic should be offloaded" = [71..100] "better to offload traffic" = [41..70] "May offload traffic" = [11..40] "Current load is OK" = [-10..10] "Can accept a small amount of traffic" = [-40..-11] "can accept some traffic"=[-70..-41] "can accept many traffic"=[-100..-71] In this example, "100" indicates full capacity and "-100" indicates no capacity. This second encoding is similar to the first encoding in that it indicates load status, but it offers more precision (201 values ​​instead of 7).

[0084] However, the encoding of the load status indicator is not limited to this example, and other similar types of encoding are also possible. The encoding requirement is that it indicates the need to offload traffic (e.g., a positive value) and the possibility of accepting traffic (e.g., a negative value). It also indicates the amount of traffic that needs to be offloaded and can be accepted with a certain degree of granularity. When the amount of traffic indicates the offload amount, information indicating the offload amount may be indicated as the number of UEs. Furthermore, the above-mentioned "possibility of accepting traffic" may also be expressed as "possibility of being able to accept traffic." The load status indicator may be set, for example, for at least one of a slice unit, a cell unit, and a beam unit.

[0085] (Step S1013) The RAN node 20 transmits a first message including the generated "load status indicator" and "information relating to predicted values ​​for the cell's load parameters" towards the RAN node 30.

[0086] Here, the prediction item corresponding to the prediction type may be changed depending on the content indicated by the "load status indicator." For example, if the "load status indicator" corresponding to a certain load parameter indicates "necessity of traffic offloading," the predicted value for that load parameter included in the first message may be the average load prediction and the maximum load prediction for a fixed number of UEs and the average load prediction and the maximum load prediction for a variable number of UEs. In this case, the predicted value for the minimum load prediction for that load parameter may not be included in the first message. This is because the RAN node 30, having received this load status indicator, decides to accept traffic offloading for the cell 43, and the predicted value for the minimum load prediction for the cell 43 may not be very useful information for that decision.

[0087] Also, for example, if a "load status indicator" corresponding to a certain load parameter indicates "traffic acceptability," the predicted values ​​for that load parameter included in the first message may be predicted values ​​for an average load forecast and a minimum load forecast for a fixed number of UEs and predicted values ​​for an average load forecast and a minimum load forecast for a variable number of UEs. In this case, the predicted value for a maximum load forecast for that load parameter may not be included in the first message. This is because the RAN node 30, having received this load status indicator, decides to offload traffic of the cell 43, and the predicted value for a maximum load forecast for the cell 43 may not be very useful information for that decision.

[0088] The first message may be, for example, a Resource Status Update message of the Resource Status Reporting procedure, or a message of a new procedure (for example, a Predictions Update message of the Predictions reporting procedure).

[0089] (A) Use of Resource Status Reporting Procedure Figure 8 shows a Resource Status Reporting Initiation procedure used to request other NG-RAN nodes to report load measurements. This procedure can be used to send the second message described in the second embodiment. In step S11 of Figure 8, the NG-RAN node R1 sends a RESOURCE STATUS REQUEST message to the NG-RAN node R2. The NG-RAN node R1 corresponds to the above-mentioned RAN node 30, and the NG-RAN node R2 corresponds to the above-mentioned RAN node 20.

[0090] The RESOURCE STATUS REQUEST message can be used to transmit the "load status indicators" and "information related to predicted values ​​of cell load parameters" from NG-RAN node R2 to NG-RAN node R1. The RESOURCE STATUS REQUEST message is defined in section 9.1.3.18 of 3GPP TS 23.10.2014-01-01 16:16 Page 16 of 21. Examples of such RESOURCE STATUS REQUEST messages are shown in Figures 16A-16D.

[0091] This RESOURCE STATUS REQUEST message is sent from NG-RAN node R1 to NG-RAN node R2 to initiate the transmission of load status indicators and predictions and prediction results for load parameters, as requested according to the parameters provided in the message. The values ​​(bit values ​​from the sixth bit onwards) of the underlined IE (Report Characteristics IE) in Figures 16A-16D indicate a "load status indicator transmission request" and a "prediction value transmission request." In Figures 16A-16D, the sixth bit corresponds to a "load status indicator transmission request." The seventh bit and subsequent bits correspond to different combinations of load parameters and prediction types. By sending this RESOURCE STATUS REQUEST message as a preliminary step to step S1013, the "load status indicators" and "information related to predicted values ​​for load parameters" are transmitted in a RESOURCE STATUS UPDATE message in step S1013. That is, the Report Characteristics IE in Figures 16A-16D is used to indicate whether the "load status indicator" should be reported using the RESOURCE STATUS UPDATE message, and which predicted value of which load parameter, among the predicted values ​​of the load parameters formed in step S1012, corresponding to which prediction type should be reported using the RESOURCE STATUS UPDATE message.

[0092] The "load parameters" may include, for example, at least one of the following: For the requested cells, beams, and slices: At least one of GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage for at least one of DL (Downlink) / UL (Uplink) for each beam of each cell provided by the RAN node 20 At least one of GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage for at least one of DL (Downlink) / UL (Uplink) for each slice of each cell provided by the RAN node 20 Regarding the required cells and beams: DL, UL, and SUL capacity, including at least one of the per cell capacity and the per beam capacity of each cell provided by the RAN node 20. Regarding requested cells and slices: Capacity of at least one of DL (Downlink) / UL (Uplink) for each slice of each cell provided by the RAN node 20

[0093] The "prediction type" may include, for example, at least one of the following: "Predictions for fixed number of UEs" "Predictions for changing number of UEs"

[0094] That is, as described above, each of a prediction for a fixed number of UEs, a prediction for a variable number of UEs, items included in a prediction for a fixed number of UEs (average load prediction, minimum load prediction, and maximum load prediction), and any combination of items included in a prediction for a variable number of UEs (average load prediction, minimum load prediction, and maximum load prediction) can be one "prediction type."

[0095] For example, in Figure 16, load metric #1 and prediction type #1 corresponding to the 7th bit of the Report Characteristics IE may correspond to a combination of a "load parameter" which is the GBR (Guaranteed Bit Rate), non-GBR, or total PRB (Physical Resource Block) usage of DL (Downlink) / UL (Uplink) for each beam of each cell, and a "prediction type" which is an average load prediction for a fixed number of UEs.

[0096] Furthermore, the RESOURCE STATUS REQUEST message can be used to set the "reporting period for predicted values," "prediction granularity," or both. FIG. 9 is a diagram showing another example of time-series data of information related to predicted values ​​of load parameters. In the time-series data shown in FIG. 9, the timing information of adjacent data sets is in increments of 100 milliseconds. That is, by setting the value of "prediction granularity" in the RESOURCE STATUS REQUEST message to a value corresponding to 100 milliseconds, the time-series data shown in FIG. 9 is reported. Also, in FIG. 9, the time-series data is transmitted (reported) at the timings of "timing information = 0 milliseconds" and "timing information = 2000 milliseconds." That is, by setting the value of "reporting period for predicted values" in the RESOURCE STATUS REQUEST message to a value corresponding to 2000 milliseconds, the time-series data shown in FIG. 9 is reported. Here, the "information related to predicted values ​​of load parameters" is transmitted in the RESOURCE STATUS UPDATE message. Therefore, the "reporting period for predicted values" may be equal to the transmission period for RESOURCE STATUS UPDATE messages containing "information related to predicted values ​​for load parameters." In the example shown in Fig. 9, the timing at which the load parameters are actually measured is 1000 milliseconds before the timing (0 milliseconds) at which the time-series data is transmitted (reported). For example, the time-series data reported at the timing (0 milliseconds) may include predicted values ​​for the timing between the actual measurement timing (-1000 milliseconds) and the reporting timing of the next time-series data (+2000 milliseconds).

[0097] Figure 10 shows the procedure of Resource Status Reporting used to report load information. In response to receiving the RESOURCE STATUS REQUEST message shown in Figure 8, the NG-RAN node R2 starts the requested measurements and predictions according to the parameters given in the message, and sends a RESOURCE STATUS UPDATE message to the NG-RAN node R1 in step S21. This RESOURCE STATUS UPDATE message may include the following information elements. Note that ">" indicates the data hierarchy. >Radio Resource Status IE >Composite Available Capacity Group IE >Slice Available Capacity IE

[0098] The Radio Resource Status IE is used to report the following load parameters for the requested cell, beam, and slice: >Per cell per beam DL GBR / nonGBR / total PRB usage >Per cell per beam UL GBR / nonGBR / total PRB usage >Per cell per slice DL GBR / nonGBR / total PRB usage >Per cell per slice UL GBR / nonGBR / total PRB usage

[0099] The Composite Available Capacity Group IE is used to report the following load parameters for the requested cell and beam: > DL, UL, Supplementary UL (SUL) capacity including: >>Capacity per cell >>Capacity of each beam in cells

[0100] The Slice Available Capacity IE is used to report the following load parameters for the requested cell and slice: >> DL / UL capacity of each slice on a cell-by-cell basis After receiving such information from RAN node R2, RAN node R1 can initiate a LB HO from the cell of RAN node R1 to the cell of RAN node R2, if necessary.

[0101] Specific examples of the structure of the RESOURCE STATUS UPDATE message are shown in Figures 17 to 23. First, as shown in Figure 17, the RESOURCE STATUS UPDATE message contains the following: >Radio Resource Status IE >Composite Available Capacity Group IE >Slice Available Capacity IE Contains:

[0102] The Radio Resource Status IE is defined in section 9.2.2.50 of Non-Patent Document 1. The Radio Resource Status IE indicates the usage status of PRBs in each cell, each SSB (Synchronization Signal Block) area, and each slice for all downlink and uplink traffic, and the usage status of PDCCH CCEs (Control Channel Elements) for downlink and uplink scheduling.

[0103] In the present disclosure, the Radio Resource Status IE may be used to report at least one of the following: a guaranteed bit rate (GBR), a non-GBR, or a total physical resource block (PRB) usage for at least one of downlink (DL) and / or uplink (UL) for each beam of each cell of each RAN node, for the requested cell, beam, and slice, along with a corresponding load status indicator. Also, in the present disclosure, the Radio Resource Status IE may be used to report at least one of the guaranteed bit rate (GBR), a non-GBR, or a total physical resource block (PRB) usage for at least one of downlink (DL) and / or uplink (UL) for each slice of each cell of each RAN node, for the requested cell, beam, and slice, along with a corresponding load status indicator. Examples of when the "information related to predicted values ​​of load parameters" and the "load status indicator" of the present disclosure are implemented in the Radio Resource Status IE are shown in Figures 18A-18H. The underlined IEs in FIGS. 18A-18H correspond to "information related to predicted values ​​of load parameters" in the present disclosure. The presence of each underlined IE in FIGS. 18A-18H may be "O" (Optional) or "M" (Mandatory). Of the underlined IEs in FIGS. 18A-18H, not all IEs need to be included in the Radio Resource Status IE; one or more of the IEs may be included. Examples of definitions of prediction types are shown in FIGS. 28A and 28B. An example of a definition of time-series data of "information related to predicted values" included in each underlined IE in FIGS. 18A-18H is shown in FIG. 29.

[0104] The Composite Available Capacity Group IE is defined in section 9.2.2.51 of Non-Patent Document 1. In the present disclosure, the Composite Available Capacity Group IE can be used to report DL, UL, and Supplementary UL (SUL) capacities, including at least one of the per cell capacity or per beam capacity of each cell of each RAN node, for requested cells and beams, along with corresponding load status indicators. Examples of the case where the "information related to predicted values ​​of load parameters" and the "load status indicator" of the present disclosure are implemented in the Composite Available Capacity Group IE are shown in Figures 19 to 22. The underlined IEs in Figures 19 to 22 correspond to the "information related to predicted values ​​of load parameters" or the "load status indicator" of the present disclosure. Note that the presence of each underlined IE in Figures 19 to 22 may be either "O" (Optional) or "M" (Mandatory). Furthermore, among the underlined IEs in Figures 19 to 22, not all IEs need to be included in the Composite Available Capacity Group IE; one or more arbitrary IEs may be included. Further, examples of definitions of prediction types are shown in Figures 28A and 28B. Further, an example of a definition of time-series data of "information related to prediction values" included in each underlined IE in Figures 19 to 22 is shown in Figure 29.

[0105] The Slice Available Capacity IE is defined in section 9.2.2.55 of Non-Patent Document 1. In the present disclosure, the Slice Available Capacity IE may be used to report at least one of the DL (Downlink) and UL (Uplink) capacities for each slice of each PLMN in each cell for a requested cell and slice, along with the corresponding load status indicator. FIG. 23 shows an example of the case where the "information related to predicted values ​​of load parameters" and the "load status indicator" of the present disclosure are implemented in the Slice Available Capacity IE. The underlined IEs in FIG. 23 correspond to the "information related to predicted values ​​of load parameters" or the "load status indicator" of the present disclosure. Note that the presence of each underlined IE in FIG. 23 may be "O" (Optional) or "M" (Mandatory). Furthermore, it is not necessary for all of the underlined IEs in FIG. 23 to be included in the Composite Available Capacity Group IE; one or more of the underlined IEs may be included. 28A and 28B show examples of definitions of prediction types. 29 shows an example of definitions of time-series data of "information related to predicted values" included in each underlined IE in FIG. 23.

[0106] (B) Use of new procedures Here, we propose a procedure specialized for setting up and reporting forecasted value reports, which can be used not only for setting up and reporting reports of "information related to forecasted values ​​for load parameters" but also for setting up and reporting reports of other forecasted values.

[0107] Figure 11 shows a PREDICTIONS Reporting Initiation procedure used to request other NG-RAN nodes to report information related to predicted values ​​for load parameters. This procedure can be used to send the second message described in the second embodiment. In step S31 of Figure 11, NG-RAN node R1 sends a PREDICTIONS REQUEST message to NG-RAN node R2. NG-RAN node R1 corresponds to the above-mentioned RAN node 30, and NG-RAN node R2 corresponds to the above-mentioned RAN node 20.

[0108] The PREDICTIONS REQUEST message can be used to configure the "load status indicators" and "information related to predicted values ​​for cell load parameters" sent from NG-RAN node R2. The PREDICTIONS REQUEST message is shown in Figures 24A and 24B.

[0109] This PREDICTIONS REQUEST message is transmitted from NG-RAN node R1 to NG-RAN node R2 to initiate the transmission of load status indicators and predictions and prediction results for load parameters, as requested in accordance with the parameters provided in the message. The values ​​of the Report Characteristics IE (values ​​of each bit) in FIGS. 24A and 24B indicate a "load status indicator transmission request" and a "prediction value transmission request." In FIGS. 24A and 24B, each of the first to (N-1)th bits corresponds to a different combination of load parameter and prediction type. The Nth bit corresponds to a "load status indicator transmission request." By transmitting this PREDICTIONS REQUEST message as a preliminary step to step S1013, in step S1013, the "load status indicators" and "information related to predicted values ​​for load parameters" are included in a PREDICTIONS UPDATE message and transmitted. That is, the Report Characteristics IE in Figures 24A and 24B is used to indicate whether the "load status indicator" should be reported using the RESOURCE STATUS UPDATE message, and also which predicted value of which load parameter formed in step S1012 and which predicted value corresponding to which prediction type should be reported using the PREDICTIONS UPDATE message.

[0110] The "load parameters," "forecast type," "reporting period for forecasted values," and "forecast granularity" have been explained in the Resource Status Reporting procedure, so they will not be explained here.

[0111] In step S32 of Figure 11, NG-RAN node R2 sends a PREDICTIONS RESPONSE message to NG-RAN node R1. The PREDICTIONS RESPONSE message is shown in Figure 25.

[0112] FIG. 12 shows a PREDICTIONS Reporting procedure used to report information related to predicted values ​​of load parameters together with a load status indicator. In response to receiving the PREDICTIONS REQUEST message shown in FIG. 11, the NG-RAN node R2 starts the requested measurements and predictions according to the parameters provided in the message and sends a PREDICTIONS UPDATE message to the NG-RAN node R1 in step 41. The PREDICTIONS UPDATE message is shown in FIG. 26. This PREDICTIONS UPDATE message may include a "Radio Resource Load Predictions IE." This "Radio Resource Load Predictions IE" may include the "information related to predicted values ​​of load parameters" shown in FIGS. 17 to 23 together with the load status indicator. Examples of the configuration of the Radio Resource Load Predictions IE are shown in FIGS. 27A to 27C. Not all of the "information related to predicted values ​​of load parameters" shown in FIGS. 17 to 23 are shown in FIGS. 27A to 27C, and some of them are omitted. In addition, the PREDICTIONS UPDATE message may include other Predictions IEs, which may include information related to other predicted values ​​(e.g., information related to predicted values ​​for the UE trajectory, etc.).

[0113] 28A and 28B show prediction types that may be included in each IE related to a predicted value for a load parameter. Each IE related to a predicted value for a load parameter may have the following configuration as shown in FIGS. 28A and 28B. Note that ">" indicates a data hierarchy. >Load status indicator type >>Traffic Offload >>>"Predictions for fixed number of UEs" >>>>Average load prediction >>>>Maximum load prediction >>>"Predictions for changing number of UEs" >>>>Average load prediction >>>>Maximum load prediction >>Traffic Accept >>>"Predictions for fixed number of UEs" >>>>Average load prediction >>>>Maximum load prediction >>>"Predictions for changing number of UEs" >>>>Average load prediction >>>>Maximum load prediction

[0114] Fig. 29 shows an example of the structure of time-series data of information related to predicted values. As shown in Fig. 29, the time-series data can have the following structure. Note that ">" indicates the data hierarchy. Sequence of Predictions >>Timing Information (Prediction Time) >>Prediction Value >>Prediction Accuracy

[0115] The prediction value can have multiple candidate values. The multiple candidate values ​​are defined, for example, by a bit string. For example, the prediction value may be encoded as an integer (0...100). For example, 0 corresponds to a 0% load, and 100 corresponds to a 100% load.

[0116] For the prediction accuracy, multiple candidate values ​​can be presented, which are defined by, for example, a bit string.

[0117] For example, Prediction Accuracy may be encoded as an integer (0...100), where 0 corresponds to accuracy 0 (completely inaccurate) and 100 corresponds to accuracy 1 (completely accurate).

[0118] Also, for example, the prediction accuracy may be encoded as follows: Very accurate = greater than 0.95 and less than or equal to 1 High accuracy = greater than 0.9 and less than or equal to 0.95 Very accurate = greater than 0.75 and less than or equal to 0.9 Inaccurate = Values ​​below 0.75

[0119] (Step S1014) The RAN node 30 and the RAN node 20 perform a LB HO negotiation procedure (negotiation for off-loading or accepting traffic). The LB HO negotiation is a procedure for making necessary arrangements between RAN nodes when a handover related to load balancing is performed between RAN nodes. In addition to the new procedure described below, the Mobility Settings Change procedure defined in section 8.4.9 of Non-Patent Document 1 may be used for this negotiation by modifying it. Furthermore, the number of RRC connections may be used as the traffic volume instead of the number of UEs shown below.

[0120] (A) Traffic offloading 13 shows the LB HO negotiation procedure between RAN node R3 and RAN node R4 when traffic is offloaded. The NG-RAN node R3 corresponds to the above-mentioned RAN node 20, and the NG-RAN node R4 corresponds to the above-mentioned RAN node 30.

[0121] First, before starting the LB HO negotiation procedure, the RAN node 30 compares the received load condition indicator value of the RAN node 20 with the load condition indicator value of the RAN node 30's own cell to check whether there is a matching pair between them. Examples of matching pairs are as follows: >Cell ID = "RAN node 20 cell 43" >>Cell DL Load Status Indicator = "Able to accept some traffic" >>Cell UL Load Status Indicator = "Able to accept some traffic" and >Cell ID = "RAN node 30 cell 44" >> Cell DL Load Status Indicator = "Traffic should be offloaded" >> Cell UL Load Status Indicator = "Traffic should be offloaded" Here, cell 43 and cell 44 are adjacent to each other. Such a matching pair indicates that some traffic may be offloaded from cell 44 of RAN node 30 to cell 43 of RAN node 20.

[0122] Here, the RAN node 30 determines that there is a matching pair in the load condition indicator values ​​of the RAN node 20 and the neighboring cells of the RAN node 30. Therefore, the RAN node 30 determines that it is preferable to perform a corresponding LB HO. The RAN node 30 may also determine the number of UEs to be offloaded (or the number of RRC connections), the offloaded load value (load percentage), or both, based on the information reported in the first message, the number of UEs for which LB HO is possible from the RAN node 30 to the RAN node 20, etc.

[0123] In step S51 of FIG. 13, the RAN node R4 (RAN node 30) transmits an LB HO proposal message to the RAN node R3 (RAN node 20).

[0124] For example, the LB HO proposal message may include the following information: > Cell ID of RAN node 30 >>RAN node 20 cell ID >>>Load status indicator pair description >>>Proposed number of UEs (or RRC connections) for LB HO >>>Offloaded load value (percentage of load) The "cell ID of RAN node 30" means the ID of the cell proposed to offload traffic, and the "cell ID of RAN node 20" means the ID of the cell proposed to accept traffic. The "load status indicator pair description" means the description of the matching pair. The "proposed number of UEs for LB HO" is information indicating the amount of offload.

[0125] An example of this LB HO proposal message is shown in FIG. 30. As shown in FIG. 30, the LB HO proposal message includes, as items in the LB HO proposal source cell list, the cell IDs of the RAN nodes R3 and R4, the proposed operation, a description of the matching pair, the proposed number of UEs for LB HO, and the proposed offloaded load value for LB HO. For this procedure, the proposed operation is set to offload. Note that in FIG. 30, the presence of the "proposed number of UEs for LB HO" item in the LB HO proposal source cell list is set to "0", but it may also be set to "M". In FIG. 30, the presence of the "proposed offloaded load value for LB HO" item in the LB HO proposal source cell list is set to "0", but it may also be set to "M". Conversely, among the IEs in items other than those with a presence of "M", the presence of any part or all of the IEs may also be set to "0". Furthermore, it is not necessary to include all of the IEs in the items shown in FIG. 30, and one or more of any IEs may be included.

[0126] 13, the RAN node R3 (RAN node 20) performs necessary internal preparations in response to the LB HO proposal message. For example, upon receiving the LB HO proposal message, the RAN node 20 performs necessary internal preparations (internal LB HOs) to prepare available capacity necessary to accept traffic in the cell indicated by the cell ID of the RAN node 20 indicated in the LB HO proposal message.

[0127] Then, in step S53, RAN node R3 (RAN node 20) sends an LB HO accept to RAN node R4 (RAN node 30). The LB HO accept notifies the RAN node 30 that, based on the result of internal preparation, the specific cell to be subjected to LB HO and the proposed number of UEs for LB HO indicated in the LB HO proposal message have been approved. For example, the LB HO accept may include the following information: > Cell ID of RAN node 30 >>Cell ID of RAN node 20 >>>Load status indicator pair description >>> Number of UEs accepted by LB HO >>>LB Load value on HO (percentage of load) The description of each of these IEs is the same as the description of the IEs in the LB HO proposal message above. If some cells are not accepted, for example, those cells may not be included in the LB HO accept, or the number of UEs accepted for LB HO may be set to 0.

[0128] An example of this LB HO accept is shown in Figure 31. As shown in Figure 31, the LB HO accept includes, as items in the LB HO proposed source cell list, the cell IDs of RAN nodes R3 and R4, the number of UEs involved in the LB HO, and a load value involved in the LB HO. Here, the list of cells of RAN nodes R3 and R4 in the LB HO accept is a subset of the list of cells of RAN nodes R3 and R4 in the LB HO proposal message. Note that, although the Presence of each item in the LB HO proposed source cell list is described as "M" in Figure 31, the Presence of any part or all of these IEs may be "O". Furthermore, it is not necessary to include all IEs in the LB HO proposed source cell list shown in Figure 31, and one or more optional IEs may be included.

[0129] (B) Acceptance of Traffic 14 shows the LB HO negotiation procedure between RAN node R3 and RAN node R4 when traffic is accepted. NG-RAN node R3 corresponds to RAN node 20 above, and NG-RAN node R4 corresponds to RAN node 30 above.

[0130] First, before starting the LB HO negotiation procedure, the RAN node 30 compares the received load condition indicator value of the RAN node 20 with the load condition indicator value of the RAN node 30's own cell to check whether there is a matching pair between them. Examples of matching pairs are as follows: >Cell ID = "RAN node 20 cell 43" >>Cell DL Load Status Indicator = "Traffic should be offloaded" >> Cell UL Load Status Indicator = "Traffic should be offloaded" and >Cell ID = "RAN node 30 cell 44" >> Cell DL load status indicator = "Able to accept some traffic" >>Cell UL Load Status Indicator = "Able to accept some traffic" Here, cell 43 and cell 44 are adjacent to each other. Such a matching pair indicates that some traffic may be offloaded from cell 43 of RAN node 20 to cell 44 of RAN node 30.

[0131] Here, the RAN node 30 determines that there is a matching pair in the load condition indicator values ​​of the RAN node 20 and the neighboring cells of the RAN node 30. Therefore, the RAN node 30 determines that it is preferable to perform a corresponding LB HO.

[0132] In step S61 of FIG. 14, the RAN node R4 (RAN node 30) transmits an LB HO proposal message to the RAN node R3 (RAN node 20).

[0133] For example, the LB HO proposal message may include the following information: > Cell ID of RAN node 30 >>RAN node 20 cell ID >>>Load status indicator pair description Unlike the LB HO proposal message in (A), this LB HO proposal message does not include information on the number of UEs (or the number of RRC connections) and the load value (load percentage). This is because the RAN node 30 does not recognize the UEs within the RAN node 20. The other explanations of each IE in the LB HO proposal message are the same as those explained in (A), and therefore will not be repeated.

[0134] An example of this LB HO proposal message is shown in Figures 32A and 32B. As shown in Figures 32A and 32B, the LB HO proposal message includes, as items in the LB HO proposal source cell list, the cell IDs of RAN nodes R3 and R4, the proposed operation, a description of the matching pair, the proposed number of UEs for LB HO, and the proposed load value for LB HO. For this procedure, the proposed operation is set to accept. Correspondingly, as shown in Figures 32A and 32B, information on the proposed number of UEs for LB HO and the proposed load value for LB HO are not included in this LB HO proposal message.

[0135] 32A and 32B, the presence of the IE for the proposed number of UEs for LB HO is described as "0", but this presence may also be "M". Also, in FIGS. 32A and 32B, the presence of the IE for the proposed load value for LB HO is described as "0", but this presence may also be "M". Conversely, among the IEs in each item of the LB HO proposed source cell list other than those with a presence of "M", the presence of any part or all of the IEs may be "0". Also, among the IEs of the load status indicator shown in FIG. 24, it is not necessary to include all IEs, and any one or more IEs may be included.

[0136] In step S62 of FIG. 14, the RAN node R3 (RAN node 20) checks for UEs that are in matching pairs and that can perform LB HO from the RAN node R3 to the RAN node R4 (RAN node 30) based on the received quality measurement results of neighboring cells.

[0137] For example, the RAN node 20 receives a reference signal quality measurement result of a neighboring cell from the UE 51. The reference signal quality information indicated by the reference signal quality measurement result may include, for example, at least one of RSRP, RSRQ, and SINR. The RAN node 20 uses this measurement result to determine whether a UE exists in the cell 43, whose reference signal strength level (reference signal level) received from the RAN node 30 is equal to or greater than a predetermined threshold (handover trigger). A UE whose reference signal strength level is equal to or greater than the handover trigger can communicate with the RAN node 30, and can therefore be handed over to the cell 44 of the RAN node 30. In other words, the RAN node 20 checks for UEs that are part of a matching pair and that are capable of LB HO from the RAN node 20 to the RAN node 30.

[0138] In step S63 of Fig. 14, the RAN node R3 (RAN node 20) accepts the execution of the LB HO by sending a first LB HO accept that accepts the LB HO proposal message to the RAN node R4 (RAN node 30). The first LB HO accept may include a load condition indicator value of the cell 44 of the corresponding RAN node 30. The first LB HO accept may also include information about multiple cells, or may indicate the number of UEs per cell for which HO is proposed.

[0139] For example, the first LB HO accept may include the following information: > Cell ID of RAN node 20 >>Cell ID of RAN node 30 >>>Load status indicator pair description >>>Proposed number of UEs for LB HO >>>Proposed load value on LB HO (percentage of load) The explanation of each IE in the first LB HO accept is the same as that explained in (A), so the explanation will be omitted.

[0140] An example of this first LB HO accept is shown in Figure 33. As shown in Figure 33, the first LB HO accept includes, as items in the LB HO proposed source cell list, the cell IDs of RAN nodes R3 and R4, the number of UEs involved in the LB HO, and a load value involved in the LB HO. Here, the list of cells of RAN nodes R3 and R4 in the first LB HO accept is a subset of the list of cells of RAN nodes R3 and R4 in the LB HO proposal message. Note that, although the Presence of each item in the LB HO proposed source cell list is described as "M" in Figure 33, the Presence of any part or all of these IEs may be "O". Furthermore, it is not necessary to include all IEs in the LB HO proposed source cell list shown in Figure 33, and one or more optional IEs may be included.

[0141] In step S64, the RAN node R4 that has received the first LB HO accept performs internal preparations necessary to prepare available capacity necessary to accept traffic in the cell indicated by the cell ID of the RAN node R4 that is indicated in the first LB HO accept. For example, the RAN node 30 that has received the first LB HO accept performs internal preparations (internal LB HOs) necessary to prepare available capacity necessary to accept traffic in the cell indicated by the cell ID of the RAN node 30 that is indicated in the first LB HO accept.

[0142] In step S65, after the internal preparation is completed, RAN node R4 (RAN node 30) sends a second LB HO accept to RAN node R3 (RAN node 20) to accept the LB HO. The second LB HO accept notifies RAN node 20 that, based on the result of the internal preparation, it has approved the specific cell to be subject to LB HO and the proposed number of UEs for LB HO indicated in the first LB HO accept. For example, the second LB HO accept may include the following information: > Cell ID of RAN node 20 >>Cell ID of RAN node 30 >>>Load status indicator pair description >>> Number of UEs accepted by LB HO >>>LB Load value on HO (percentage of load) The description of each of these IEs is the same as the description of the IEs for LB HO accept described in (A). If some cells are not accepted, for example, those cells may not be included in the second LB HO accept, or the number of accepted UEs for LB HO or the load value for LB HO may be set to 0.

[0143] An example of this second LB HO accept is shown in Figure 34. As shown in Figure 34, the second LB HO accept includes, as items in the LB HO proposed source cell list, the cell IDs of RAN nodes R3 and R4, the number of UEs involved in the LB HO, and a load value involved in the LB HO. Here, the list of cells of RAN nodes R3 and R4 in the second LB HO accept is a subset of the list of cells of RAN nodes R3 and R4 in the first LB HO accept. Note that, although the Presence of each item in the LB HO proposed source cell list is described as "M" in Figure 34, the Presence of any part or all of these IEs may be "O." Furthermore, it is not necessary to include all IEs in the LB HO proposed source cell list shown in Figure 34, and one or more optional IEs may be included.

[0144] (Step S1015) The RAN node 20 and the RAN node 30 perform LB HO for the pair of cells and the UE negotiated in step S1014.

[0145] <Other embodiments> An example of a hardware configuration of the RAN node 100 described in the above-described embodiments will be described. FIG. 15 is a block diagram showing an example of a configuration of a RAN node according to each embodiment. Referring to FIG. 15, the RAN node 100 includes a radio frequency (RF) transceiver 1001, a network interface 1003, a processor 1004, and a memory 1005. The RF transceiver 1001 performs analog RF signal processing for communication with a UE. The RF transceiver 1001 may include multiple transceivers. The RF transceiver 1001 is coupled to an antenna 1002 and the processor 1004. The RF transceiver 1001 receives modulation symbol data (or orthogonal frequency division multiplexing (OFDM) symbol data) from the processor 1004, generates a transmit RF signal, and provides the transmit RF signal to the antenna 1002. The RF transceiver 1001 also generates a baseband receive signal based on the receive RF signal received by the antenna 1002 and provides the baseband receive signal to the processor 1004.

[0146] The network interface 1003 is used to communicate with network nodes (e.g., other core network nodes) and may include, for example, a network interface card (NIC) compliant with the IEEE (Institute of Electrical and Electronics Engineers) 802.3 series.

[0147] The processor 1004 performs data plane processing and control plane processing, including digital baseband signal processing for wireless communication. For example, in the case of LTE and 5G, the digital baseband signal processing by the processor 1004 may include signal processing of a MAC layer and a physical layer.

[0148] The processor 1004 may include multiple processors. For example, the processor 1004 may include a modem processor (e.g., a digital signal processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a central processing unit (CPU) or a microprocessor unit (MPU)) that performs control plane processing.

[0149] The memory 1005 is configured by a combination of volatile memory and nonvolatile memory. The memory 1005 may include multiple physically independent memory devices. The volatile memory may be, for example, static random access memory (SRAM), dynamic random access memory (DRAM), or a combination thereof. The nonvolatile memory may be mask read only memory (MROM), electrically erasable programmable read only memory (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 1005 may include storage located remotely from the processor 1004. In this case, the processor 1004 may access the memory 1005 via the network interface 1003 or an I / O interface (not shown).

[0150] The memory 1005 may store software modules (computer programs) including instructions and data for performing the processes of the RAN node 100 described in the above embodiments. In some implementations, the processor 1004 may be configured to read and execute the software modules from the memory 1005 to perform the processes of the RAN node 100 described in the above embodiments.

[0151] As described above, one or more processors included in each device in the above-described embodiments execute one or more programs including instructions for causing a computer to execute the algorithms described using the drawings. This processing enables the signal processing method described in each embodiment to be realized.

[0152] The program includes instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The program may be stored in a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, non-transitory computer-readable medium or tangible storage medium includes random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disk (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The program may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic, or other forms of propagated signals.

[0153] In this specification, a user equipment (UE) (or mobile station, mobile terminal, mobile device, or wireless device, etc.) is an entity connected to a network via a radio interface.

[0154] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes. (Appendix 1) A Radio Access Network (RAN) node, comprising: Memory and a processor coupled to the memory; a transceiver, the processor is configured to cause the transceiver to transmit a first message to another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of a first cell of the RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Including, RAN node. (Appendix 2) the information about the predicted value includes the predicted value at each of a plurality of timings; RAN node as described in Appendix 1. (Appendix 3) the information about the predicted value includes the predicted value at a timing after the transmission timing of the first message; RAN node as defined in Supplementary Note 1 or 2. (Appendix 4) The information about the predicted value includes the predicted value and a prediction accuracy of the predicted value. 1. The RAN node of any one of Supplementary Notes 1 to 3. (Appendix 5) The information about the predicted value includes a plurality of sets; each of the sets includes timing information, the predicted value, and a prediction accuracy of the predicted value; 1. The RAN node of any one of Supplementary Notes 1 to 4. (Appendix 6) The information about the predicted value is a prediction value assuming that the number of active user equipments (UEs) in the domain related to the load-related parameter of the first cell does not change during a prediction period; a prediction value taking into account the change in the number of active UEs in the domain related to the load-related parameter of the first cell during a prediction period, or Including both of these, 6. The RAN node of any one of Supplementary Notes 1 to 5. (Appendix 7) The information about the predicted value includes the predicted value for each uplink and each downlink in the first cell. 7. The RAN node of any one of Supplementary Notes 1 to 6. (Appendix 8) the information about the predicted value includes the predicted value in a slice of the first cell; 8. The RAN node of any one of Supplementary Notes 1 to 7. (Appendix 9) the processor is configured to cause the transceiver to receive a second message sent from the other RAN node, the second message including information regarding a request to transmit information related to the predicted value. 10. The RAN node of any one of Supplementary Notes 1 to 8. (Appendix 10) the second message further includes information regarding a reporting period of the predicted value. RAN node as described in Appendix 9. (Appendix 11) the second message further includes information regarding a prediction granularity related to a timing interval of the prediction value. 11. A RAN node as defined in Supplementary Note 9 or 10. (Appendix 12) the first message is a RESOURCE STATUS REQUEST message; 12. The RAN node of any one of Supplementary Notes 1 to 11. (Appendix 13) the second message is a RESOURCE STATUS UPDATE message; 12. The RAN node of any one of Supplementary Notes 9 to 11. (Appendix 14) the state information has a plurality of candidate values; The plurality of candidate values ​​include a value indicating that traffic offloading in the first cell is necessary and a value indicating that the first cell is capable of accepting traffic. 14. The RAN node of any one of Supplementary Notes 1 to 13. (Appendix 15) the status information indicates the need or the acceptability for each uplink and each downlink in the first cell. 15. The RAN node of any one of Supplementary Notes 1 to 14. (Appendix 16) the status information indicates at least one of a need for offloading traffic in the slice of the first cell or an acceptability of traffic in the slice of the first cell. 16. The RAN node of any one of Supplementary Notes 1 to 15. (Appendix 17) the processor is configured to cause the transceiver to receive a third message transmitted from the other RAN node, the third message including a proposal to offload traffic from a second cell of the other RAN node to the first cell or to accept traffic of the first cell by the second cell. 17. The RAN node of any one of Supplementary Notes 1 to 16. (Appendix 18) the processor is configured to cause the transceiver to transmit a fourth message toward the other RAN node indicating acceptance of an offer to offload traffic from the second cell to the first cell or to have the second cell accept traffic of the first cell. RAN node as described in Appendix 17. (Appendix 19) the third message includes numerical information regarding traffic in the first cell and the second cell; 19. A RAN node as defined in Supplementary Note 17 or 18. (Appendix 20) The third message and the fourth message include information indicating an offload amount or an acceptance amount. RAN node as described in Appendix 18. (Appendix 21) The information indicating the offload amount or the acceptance amount indicates the number of UEs. RAN node as described in Appendix 20. (Appendix 22) A Radio Access Network (RAN) node, comprising: Memory and a processor coupled to the memory; a transceiver, the processor is configured to cause the transceiver to receive a first message transmitted from another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of the first cell of the other RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Including, RAN node. (Appendix 23) the information about the predicted value includes the predicted value at each of a plurality of timings; RAN node as described in Appendix 22. (Appendix 24) the information about the predicted value includes the predicted value at a timing after the transmission timing of the first message; 24. The RAN node of claim 22 or 23. (Appendix 25) the information related to the predicted value includes the predicted value and a prediction accuracy of the predicted value; 25. The RAN node of any one of Supplementary Notes 22 to 24. (Appendix 26) The information about the predicted value includes a plurality of sets; each of the sets includes timing information, the predicted value, and a prediction accuracy of the predicted value; 26. The RAN node of any one of Supplementary Notes 22 to 25. (Appendix 27) The information related to the predicted value may include: a prediction value assuming that the number of active user equipments (UEs) in the domain related to the load-related parameter of the first cell does not change during a prediction period; a prediction value taking into account the change in the number of active UEs in the domain related to the load-related parameter of the first cell during a prediction period, or Including both of these, 27. The RAN node of any one of Supplementary Notes 22 to 26. (Appendix 28) The information about the predicted value includes the predicted value for each uplink and each downlink in the first cell. 28. The RAN node of any one of Supplementary Notes 22 to 27. (Appendix 29) the information about the predicted value includes the predicted value in a slice of the first cell; 29. The RAN node of any one of Supplementary Notes 22 to 28. (Appendix 30) the processor is configured to cause the transceiver to transmit, to the other RAN node, a second message including information regarding a request for transmission of information related to the predicted value. 30. The RAN node of any one of Supplementary Notes 22 to 29. (Appendix 31) the second message further includes information regarding a reporting period of the predicted value. RAN node as described in Appendix 30. (Appendix 32) the second message further includes information regarding a prediction granularity related to a timing interval of the prediction value. 32. The RAN node of claim 30 or 31. (Appendix 33) the first message is a RESOURCE STATUS UPDATE message; 33. The RAN node of any one of Supplementary Notes 22 to 32. (Appendix 34) the second message is a RESOURCE STATUS REQUEST message; 33. The RAN node of any one of Supplementary Notes 30 to 32. (Appendix 35) the state information has a plurality of candidate values; The plurality of candidate values ​​include a value indicating that traffic offloading in the first cell is necessary and a value indicating that the first cell is capable of accepting traffic. 35. The RAN node of any one of Supplementary Notes 22 to 34. (Appendix 36) the status information indicates the need or the acceptability for each uplink and each downlink in the first cell. 36. The RAN node of any one of Supplementary Notes 22 to 35. (Appendix 37) the status information indicates at least one of a need for offloading traffic in the slice of the first cell or an acceptability of traffic in the slice of the first cell. 37. The RAN node of any one of Supplementary Notes 22 to 36. (Appendix 38) the processor is configured to cause the transceiver to transmit a third message toward the other RAN node, the third message including a proposal for offloading traffic from the first cell to a second cell of the RAN node or for the first cell to accept traffic of the second cell. 38. The RAN node of any one of Supplementary Notes 22 to 37. (Appendix 39) the processor is configured to cause the transceiver to receive a fourth message transmitted from the other RAN node indicating acceptance of an offer to offload traffic from the first cell to the second cell or to have the first cell accept traffic of the second cell. RAN node as described in Appendix 38. (Appendix 40) the third message includes numerical information regarding traffic in the first cell and the second cell; 39. The RAN node of claim 38. (Appendix 41) The third message and the fourth message include information indicating an offload amount or an acceptance amount. RAN node as described in Appendix 39. (Appendix 42) The information indicating the offload amount or the acceptance amount indicates the number of UEs. RAN node as described in Appendix 41. (Appendix 43) 1. A method performed by a Radio Access Network (RAN) node, comprising: transmitting a first message to another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of a first cell of the RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Including, method. (Appendix 44) the information includes the predicted value at each of a plurality of timings; The method described in Appendix 43. (Appendix 45) 1. A method performed by a Radio Access Network (RAN) node, comprising: receiving a first message transmitted from another RAN node; The first message comprises: information relating to predicted values ​​of parameters related to the load of the first cell of the other RAN node; status information of the first cell indicating at least one of the need for offloading traffic in the first cell or the acceptability of traffic by the first cell; Including, method. (Appendix 46) the information includes the predicted value at each of a plurality of timings; The method described in Appendix 45.

[0155] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above. Various modifications that can be understood by a person skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure.

[0156] This application claims priority based on Japanese Patent Application No. 2022-035281, filed on March 8, 2022, the disclosure of which is incorporated herein in its entirety. [Explanation of symbols]

[0157] 1,10 Communication Systems 2,3,20,30,100,R1,R2,R3,R4 RAN nodes 4-1, 4-2, 41, 42, 43, 44, 45, 46 cells 51UE 101 Communications Department 102 Control section

Claims

1. A first RAN node in a radio access network (RAN) that supports artificial intelligence / machine learning (AI / ML) as a RAN function, comprising: means for receiving a first message from a second RAN node in the RAN, the first message including a first information element; The first information element is Report Characteristics indicating a type of target on which the first RAN node performs prediction for generating Radio Resource Status, which is prediction information related to the AI / ML; The first RAN node: means for performing the prediction to generate the prediction information; means for transmitting a second message including the prediction information to the second RAN node; Equipped with the prediction information includes physical resource block (PRB) usage per synchronization signal block (SSB) for downlink and uplink traffic; First RAN node.

2. the first message includes a second information element; The second information element indicates a time point at which the prediction is to be applied. The first RAN node of claim 1 .

3. the forecast information relates to a forecast number of active user equipments (UEs); The first RAN node according to claim 1 or 2.

4. The prediction information includes: a usage amount of guaranteed bit rate (GBR) PRBs for downlink (DL) in the SSB area; a usage amount of GBR PRBs for uplink (UL) in the SSB area; a usage amount of non-GBR PRBs for DL ​​in the SSB area; a usage amount of non-GBR PRBs for UL in the SSB area; a total usage amount of DL PRBs in the SSB area; and a total usage amount of UL PRBs in the SSB area. The first RAN node according to claim 1 or 2.

5. The second information element is a Prediction Time. The first RAN node of claim 2.

6. the first RAN node is a Next Generation RAN (NG-RAN) node; the second RAN node is an NG-RAN node; the first message is an Xn message; The second message is an Xn message. The first RAN node according to claim 1 or 2.

7. A method performed by a first RAN node in a radio access network (RAN) that supports artificial intelligence / machine learning (AI / ML) as a RAN function, comprising: receiving a first message from a second RAN node in the RAN, the first message including a first information element; The first information element is Report Characteristics indicating a type of target on which the first RAN node performs prediction for generating Radio Resource Status, which is prediction information related to the AI / ML; The method comprises: performing the prediction to generate the prediction information; transmitting a second message including the prediction information to the second RAN node; Including, the prediction information includes physical resource block (PRB) usage per synchronization signal block (SSB) for downlink and uplink traffic; method.

8. the first message includes a second information element; The second information element indicates a time point at which the prediction is to be applied. The method of claim 7.

9. the forecast information relates to a forecast number of active user equipments (UEs); 9. The method according to claim 7 or 8.

10. The prediction information includes: a usage amount of guaranteed bit rate (GBR) PRBs for downlink (DL) in the SSB area; a usage amount of GBR PRBs for uplink (UL) in the SSB area; a usage amount of non-GBR PRBs for DL ​​in the SSB area; a usage amount of non-GBR PRBs for UL in the SSB area; a total usage amount of DL PRBs in the SSB area; and a total usage amount of UL PRBs in the SSB area.

9. The method according to claim 7 or 8.

11. The second information element is a Prediction Time. The method of claim 8.

12. the first RAN node is a Next Generation RAN (NG-RAN) node; the second RAN node is an NG-RAN node; the first message is an Xn message; The second message is an Xn message.

9. The method according to claim 7 or 8.

Images