Method and apparatus for communication using a fronthaul interface

Abstract

To provide a device for communication using a fronthaul interface and an operation method of an O-RU.SOLUTION: An operation method of open-radio access network (O-RAN) radio unit (O-RU) of a base station in an O-RAN in a communication system comprises the steps of: generating a plurality of first measurement results by performing measurement operations on a first measurement target in a single notification period according to a notification interval; generating a first measurement result list including the plurality of first measurement results; generating a first notification including a most recent measurement result among the plurality of first measurement results; and transmitting, to an O-RAN distributed unit (O-DU), a message including the first measurement result list and the first notification.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a communication technology in a communication system including a fronthaul interface, and more particularly to a technology for efficiently transmitting and receiving parameters for performance management of the communication system. [Background technology]

[0002] With the development of information and communication technology, various wireless communication technologies have been developed. Representative wireless communication technologies include LTE (long term evolution) and NR (new radio), which are defined by the 3GPP (3rd Generation Partnership Project) standard. LTE can be one of the wireless communication technologies of 4G (4th Generation) wireless communication technologies, and NR can be one of the wireless communication technologies of 5G (5th Generation) wireless communication technologies.

[0003] To process the rapidly increasing amount of wireless data since the commercialization of 4G communication systems (e.g., communication systems supporting LTE), 5G communication systems (e.g., communication systems supporting NR) that use not only the frequency bands of 4G communication systems (e.g., frequency bands below 6 GHz) but also higher frequency bands (e.g., frequency bands above 6 GHz) than the frequency bands of 4G communication systems are being considered. 5G communication systems can support eMBB (enhanced Mobile BroadBand), URLLC (Ultra-Reliable and Low Latency Communication), and mMTC (massive Machine Type Communication).

[0004] Meanwhile, the O-RAN (open-radio access network) alliance specifies a fronthaul interface. The fronthaul interface may be an interface between the O-RAN distributed unit (O-DU) and the O-RAN radio unit (O-RU) that make up a base station (e.g., eNB, gNB). The O-DU may be referred to as the lower layer split-central unit (LLS-CU), and the O-RU may be referred to as the lower layer split-distributed unit (LLS-DU). LLS-CU and LLS-DU are terms used in the 3GPP (3rd generation partnership project). A method for performance management of a communication system including a fronthaul interface may be required. In particular, a method for transmitting and receiving various parameters for performance management between the O-RU and O-DU may be required for the O-RAN M-Plane function. Summary of the Invention [Problem to be solved by the invention]

[0005] SUMMARY OF THE INVENTION In order to solve the above problems, an object of the present invention is to provide a method and apparatus for transmitting and receiving parameters for performance management in a communication system including a fronthaul interface. [Means for solving the problem]

[0006] To achieve the above object, an operating method of an O-RU according to a first embodiment of the present invention includes a step of generating a plurality of first measurement results by performing a measurement operation on a first measurement object in one notification section according to a notification interval, a step of generating a first measurement result list including the plurality of first measurement results, and a step of transmitting a message including the first measurement result list to an O-DU.

[0007] The O-RU operation method may further include generating a first notification including the latest measurement result among the plurality of first measurement results, and the message may further include the first notification.

[0008] The first measurement result list may be decoded by the O-DU supporting a version of the O-RAN after a specific version, and the first notification may be decoded by the O-DU supporting a version before the specific version.

[0009] The O-RU operation method may further include a step of generating a plurality of second measurement results by performing a measurement operation on a second measurement object in the one notification period, and a step of generating a second measurement result list including the plurality of second measurement results, and the message may further include the second measurement result list.

[0010] The first measurement result list may further include measurement start time information and measurement end time information for each of the plurality of first measurement results.

[0011] The plurality of first measurement results may be arranged in the first measurement result list in ascending order of measurement time.

[0012] The first measurement result list may further include at least one of information indicating the number of the plurality of first measurement results and sequence numbers of each of the plurality of first measurement results.

[0013] The notification interval may be set by the O-DU to be longer than the measurement interval during which one measurement operation is performed.

[0014] The first measurement object may be a transceiver, a receive window, a transmission measurement, an EPE, or a symbol RSSI.

[0015] To achieve the above object, an operating method of an O-RU according to a second embodiment of the present invention includes the steps of generating a first measurement result by performing a measurement operation on a first measurement object in one notification section according to a notification interval, generating a first notification including the first measurement result, generating a first measurement result list including the first measurement result, and transmitting a message including the first notification and the first measurement result list to an O-DU.

[0016] The first measurement result list may be decoded by the O-DU supporting a version of the O-RAN after a specific version, and the first notification may be decoded by the O-DU supporting a version before the specific version.

[0017] The notification interval can be set by the O-DU to be the same as the measurement interval in which one measurement operation is performed.

[0018] The O-RU operation method may further include the steps of generating a second measurement result by performing a measurement operation on a second measurement object in the one notification period, generating a second notification including the second measurement result, and generating a second measurement result list including the second measurement result, and the message may further include the second notification and the second measurement result list.

[0019] To achieve the above object, an O-DU operation method according to a third embodiment of the present invention includes the steps of setting a notification interval and a measurement interval for an O-RU, receiving a message from the O-RU including a first measurement result list including a plurality of first measurement results for a first measurement target, and confirming the plurality of first measurement results by decoding the first measurement result list, wherein the plurality of first measurement results are measured in one notification interval according to the notification interval.

[0020] The message may further include a first notification including a most recent measurement result of the plurality of first measurements.

[0021] The first measurement result list may be decoded by the O-DU supporting a version of the O-RAN after the specific version, and the first notification may be decoded by another O-DU supporting a version before the specific version.

[0022] The first measurement result list may further include measurement start time information and measurement end time information for each of the plurality of first measurement results.

[0023] The plurality of first measurement results may be arranged in the first measurement result list in ascending order of measurement time.

[0024] The first measurement result list may further include at least one of information indicating the number of the plurality of first measurement results and sequence numbers of each of the plurality of first measurement results.

[0025] The first measurement object may be a transceiver, a receive window, a transmission measurement, an EPE, or a symbol RSSI. [Effects of the Invention]

[0026] According to the present application, various parameters for performance management can be efficiently transmitted and received between an O-RU (O-RAN (open-radio access network) radio unit) and an O-DU (O-RAN distributed unit). In the YANG model defined in the O-RAN M-Plane, multiple measurement results (e.g., multiple measurement results per measurement object) can be transmitted using a single notification message. This operation does not affect the functionality of the existing M-Plane. Therefore, the performance of a communication system including a fronthaul interface can be improved. [Brief explanation of the drawings]

[0027] [Figure 1] 1 is a conceptual diagram illustrating a first embodiment of a communication system. [Figure 2] 1 is a block diagram illustrating a first embodiment of a communication node that constitutes a communication system. [Figure 3] 1 is a block diagram illustrating a first embodiment of a base station supporting LLS in a communication system. [Figure 4] FIG. 2 is a block diagram illustrating a first embodiment of an interface structure between an O-DU and an O-RU in a communication system. [Figure 5a] FIG. 1 is a block diagram illustrating a first embodiment of a hierarchical M-Plane model. [Figure 5b] FIG. 10 is a block diagram illustrating a second embodiment of the hybrid M-Plane model. [Figure 6] FIG. 1 is a block diagram illustrating a first embodiment of a protocol stack for M-Plane. [Figure 7] FIG. 1 is a conceptual diagram illustrating a first embodiment of a data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane. [Figure 8] FIG. 10 is a conceptual diagram illustrating a second embodiment of a data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane. [Figure 9] A conceptual diagram illustrating a third embodiment of the data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane. [Figure 10] FIG. 1 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for a transceiver in a YANG model using Method A. [Figure 11] FIG. 10 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a receive window in a YANG model using Method A. [Figure 12] FIG. 10 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for EPE in a YANG model using Method A. [Figure 13] FIG. 1 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for transmission measurements in a YANG model using Method A. [Figure 14]FIG. 10 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for symbol RSSI in a YANG model using Method A. DETAILED DESCRIPTION OF THE INVENTION

[0028] While the present invention can be modified in various ways and has various embodiments, specific embodiments will be illustrated in the drawings and described in detail, but it should be understood that this is not intended to limit the present invention to the specific embodiments, and that the present invention includes all modifications, equivalents, and alternatives that fall within the spirit and technical scope of the present invention.

[0029] Terms such as "first," "second," etc. may be used to describe various elements, but the elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be termed a "second element," and similarly, a second element may be termed a "first element," without departing from the scope of the present invention. The term "and / or" includes a combination of multiple associated listed items or any of multiple associated listed items.

[0030] In the examples of this application, "at least one of A and B" may mean "at least one of A or B" or "at least one of a combination of one or more of A and B." Also, in the examples of this application, "one or more of A and B" may mean "one or more of A or B" or "one or more of a combination of one or more of A and B."

[0031] When a component is said to be "coupled" or "connected" to another component, it should be understood that the component may be directly coupled or connected to the other component, but that there may be other components in between. Conversely, when a component is said to be "directly coupled" or "directly connected" to another component, it should be understood that there are no other components in between.

[0032] The terms used in this application are merely used to describe specific embodiments and are not intended to limit the present invention. The singular expressions include the plural expressions unless the context clearly dictates otherwise. In this application, the terms "comprise" or "have" are intended to specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0033] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this invention pertains. Terms as defined in commonly used dictionaries should be interpreted to have a meaning consistent with the meaning they have in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly defined in this application.

[0034] Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In describing the present invention, the same reference numerals will be used to refer to the same components in the drawings in order to facilitate overall understanding, and duplicate descriptions of the same components will be omitted.

[0035] A communication system to which an embodiment of the present invention is applied will now be described. The communication system may be a 4G communication system (e.g., a long-term evolution (LTE) communication system, an LTE-A communication system), a 5G communication system (e.g., a new radio (NR) communication system), etc. The 4G communication system can support communication in a frequency band below 6 GHz, and the 5G communication system can support communication in a frequency band above 6 GHz as well as a frequency band below 6 GHz. The communication system to which the embodiment of the present invention is applied is not limited to the content described below, and the embodiment of the present invention may be applied to various communication systems. Here, the term "communication system" may be used interchangeably with the term "communication network," and "LTE" may refer to a "4G communication system," an "LTE communication system," or an "LTE-A communication system," and "NR" may refer to a "5G communication system" or an "NR communication system."

[0036] FIG. 1 is a conceptual diagram illustrating a first embodiment of a communication system.

[0037] 1, the communication system 100 may include a plurality of communication nodes 110-1, 110-2, 110-3, 120-1, 120-2, 130-1, 130-2, 130-3, 130-4, 130-5, and 130-6. The communication system 100 may further include a core network (e.g., a serving-gateway (S-GW), a packet data network (PDN)-gateway (P-GW), and a mobility management entity (MME)). When the communication system 100 is a 5G communication system (e.g., a new radio (NR) system), the core network may include an access and mobility management function (AMF), a user plane function (UPF), a session management function (SMF), etc.

[0038] The plurality of communication nodes 110 to 130 can support communication protocols defined by 3GPP (3rd generation partnership project) standards (for example, LTE communication protocol, LTE-A communication protocol, NR communication protocol, etc.). The plurality of communication nodes 110 to 130 may support CDMA (code division multiple access) technology, WCDMA (wideband CDMA) technology, TDMA (time division multiple access) technology, FDMA (frequency division multiple access) technology, OFDM (orthogonal frequency division multiplexing) technology, Filtered OFDM technology, CP (cyclic prefix)-OFDM technology, DFT-s-OFDM (discrete Fourier transform-spread-OFDM) technology, OFDMA (orthogonal frequency division multiple access) technology, SC (single carrier)-FDMA technology, NOMA (non-orthogonal multiple access) technology, GFDM (generalized frequency division multiplexing) technology, FBMC (filter bank multi-carrier) technology, UFMC (universal filtered multi-carrier) technology, SDMA (space division multiple access) technology, etc. Each of the plurality of communication nodes may have the following structure.

[0039] FIG. 2 is a block diagram illustrating a first embodiment of a communication node that constitutes a communication system.

[0040] 2, a communication node 200 may include at least one processor 210, a memory 220, and a transceiver 230 that is connected to a network and performs communication. The communication node 200 may further include an input interface device 240, an output interface device 250, a storage device 260, etc. Each component included in the communication node 200 is connected to a bus 270 and performs communication.

[0041] The processor 210 can execute program commands stored in at least one of the memory 220 and the storage device 260. The processor 210 may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor that executes methods according to embodiments of the present invention. The memory 220 and the storage device 260 may each be composed of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory 220 may be composed of at least one of a read-only memory (ROM) and a random access memory (RAM).

[0042] 1, the communication system 100 may include multiple base stations 110-1, 110-2, 110-3, 120-1, and 120-2, and multiple terminals 130-1, 130-2, 130-3, 130-4, 130-5, and 130-6. The first base station 110-1, the second base station 110-2, and the third base station 110-3 may each form a macro cell. The fourth base station 120-1 and the fifth base station 120-2 may each form a small cell. The fourth base station 120-1, the third terminal 130-3, and the fourth terminal 130-4 may belong to the cell coverage of the first base station 110-1. The second terminal 130-2, the fourth terminal 130-4, and the fifth terminal 130-5 may belong within the cell coverage of the second base station 110-2. The fifth base station 120-2, the fourth terminal 130-4, the fifth terminal 130-5, and the sixth terminal 130-6 may belong within the cell coverage of the third base station 110-3. The first terminal 130-1 may belong within the cell coverage of the fourth base station 120-1. The sixth terminal 130-6 may belong within the cell coverage of the fifth base station 120-2.

[0043] Here, each of the multiple base stations 110-1, 110-2, 110-3, 120-1, and 120-2 may be a NodeB (NB), evolved NodeB (eNB), gNB, advanced base station (ABS), high reliability-base station (HR-BS), base transceiver station (BTS), radio base station, radio transceiver, access point, access node, radio access station (RAS), mobile multihop relay-base station (MMR-BS), relay station (RS), advanced relay station (ARS), high reliability-relay station (HR-RS), home NodeB (HNB), home eNodeB (HeNB), road side unit (RSU), radio remote head (RRH), transmission point (TP), transmission and reception point (TRP), etc. They may be called point cells, macro cells, pico cells, micro cells, femto cells, etc.

[0044] Each of the multiple terminals 130-1, 130-2, 130-3, 130-4, 130-5, and 130-6 may be referred to as a UE (user equipment), TE (terminal equipment), AMS (advanced mobile station), HR-MS (high reliability-mobile station), terminal, access terminal, mobile terminal, station, subscriber station, mobile station, portable subscriber station, node, device, OBU (on board unit), etc.

[0045] Meanwhile, in a communication system, a base station (e.g., eNB, gNB) may support a fronthaul interface. Here, the fronthaul interface may be a fronthaul interface defined by the open-radio access network (O-RAN) alliance. In this case, the base station may include an O-RAN distributed unit (O-DU) and one or more O-RAN radio units (O-RUs). Communication between the O-DU and one or more O-RUs may be performed through the fronthaul interface. The O-DU may be a lower layer split-central unit (LLS-CU) defined by 3GPP, and the O-RU may be a lower layer split-distributed unit (LLS-DU) defined by 3GPP. Each of the O-DU and O-RU may be configured the same as or similar to communication node 200 shown in FIG. 2.

[0046] Next, a communication method in the fronthaul will be described. When a method (e.g., signal transmission or reception) performed by a first communication node among communication nodes is described, a corresponding second communication node can also perform a method (e.g., signal reception or transmission) corresponding to the method performed by the first communication node. That is, when the operation of an O-DU is described, the corresponding O-RU can perform an operation corresponding to the operation of the O-DU. Conversely, when the operation of an O-RU is described, the corresponding O-DU can perform an operation corresponding to the operation of the O-RU.

[0047] FIG. 3 is a block diagram illustrating a first embodiment of a base station supporting lower layer split (LLS) in a communication system.

[0048] Referring to FIG. 3, base station 300 may include O-DU 311, O-RU #1 321, O-RU #2 322, etc. For example, base station 300 may include multiple O-RUs. Communication between O-DU 311 and O-RUs 321 and 322 may be performed through a fronthaul interface. The fronthaul interface may include an LLS-control plane and an LLS-user plane. The LLS-control plane may be referred to as "LLS-C" or "LLS-C-Plane," and the LLS-user plane may be referred to as "LLS-U" or "LLS-U-Plane."

[0049] The O-DU 311 may be a logical node that performs radio link control (RLC) layer functions, medium access control (MAC) layer functions, and / or high-physical (PHY) layer functions. The O-DU 311 can control multiple O-RUs 321 and 322. Each of the O-RUs 321 and 322 may be a logical node that performs low-PHY layer functions and / or radio frequency (RF) processing functions. The O-RUs 321 and 322 can transmit and receive control information and / or data by communicating with the O-DU 311. The control information may be real-time control information. The data may be user plane data. The O-RUs 321 and 322 can operate under the control of the O-DU 311.

[0050] FIG. 4 is a block diagram illustrating a first embodiment of an interface structure between an O-DU and an O-RU in a communication system.

[0051] Referring to FIG. 4, each of the O-DU and O-RU may include a CUS-Plane (e.g., O-RAN CUS-Plane) and may perform communication using the CUS-Plane function. Each of the O-DU and O-RU may also include an M (management)-Plane (e.g., O-RAN M-Plane) and may perform communication using the M-Plane function. That is, the O-DU and O-RU may perform not only the CUS-Plane function but also the M-Plane function. The M-Plane function may support initialization, configuration, management, etc. of the O-RU. The M-Plane may use an open interface based on NETCONF and / or the YANG model (hereinafter referred to as the "NETCONF / YANG model"). The M-Plane may support startup installation, software management, configuration management, performance management, fault management, file management, etc. In O-RAN, the M-Plane structure may be as follows:

[0052] FIG. 5a is a block diagram illustrating a first embodiment of a hierarchical M-Plane model, and FIG. 5b is a block diagram illustrating a second embodiment of a hybrid M-Plane model.

[0053] Referring to Figure 5a, in the hierarchical M-Plane model, an O-RU can be managed by one or more O-DUs. A NETCONF-based M-Plane interface can be used between the O-DU and the O-RU. An interface can exist between the O-DU and the network management system (NMS), but the NMS does not need to manage the O-RU directly. That is, the NMS can manage the O-RU through the O-DU. There does not need to be a direct interface between the O-RU and the NMS. The NMS can refer to the management system shown in Figure 4.

[0054] Referring to Figure 5b, in the hybrid M-Plane model, there may be a direct logical interface between the NMS and the O-RU as well as a logical interface between the O-DU and the O-RU. The NMS may support software management, performance management, configuration management, and / or fault management functions for the O-RU. The NMS and the O-RU may have end-to-end internet protocol (IP) hierarchical connectivity.

[0055] FIG. 6 is a block diagram illustrating a first embodiment of the protocol stack of M-Plane.

[0056] Referring to Figure 6, the transport network layer can operate on the IP transport layer, and the TCP (transmission control protocol) / SSH (secure shell) layer can be used to send and receive M-Plane messages between the O-DU / NMS and the O-RU.

[0057] The NETCONF / YANG model can be used in network element management protocols and data modeling languages, and can support an open management scheme for efficient integration and management between multi-vendor O-RU / O-DUs.

[0058] NETCONF can obtain configuration state information and support configuration change operations. NETCONF can also transmit XML-RPC messages over transport layers that provide secure transport (e.g., the SSH layer). The get and get-config RPC operations can be used to obtain the entire configuration, a portion of the configuration, the entire state data, and / or a portion of the state data, respectively. The edit-config operation can be used to change, add, and / or delete configuration elements in the configuration data store.

[0059] In NETCONF, notification support can be based on event streams. A NETCONF client (e.g., an O-DU) may want to receive notifications for specific events. In this case, a subscription to that event stream can be requested using the create-subscription operation.

[0060] The performance management function may be the main function of the M-Plane. The performance management function may be a function for optimizing O-RU operation. The O-DU (e.g., NETCONF client) can use the NETCONF / YANG model to collect O-RU operation-related information (e.g., transceiver, receive window (rx-window), transmit window (tx-window), EPE (energy, power, environmental), and RSSI (received signal strength indicator) (e.g., symbol RSSI)). For example, the O-DU can collect configuration and / or status information for performance management.

[0061] For performance management, measurement objects (e.g., TX_POWER, RX_POWER, RX_ON_TIME, TX_TOTAL, etc.) defined and / or used in the O-RAN standard can be classified and / or managed into five or more measurement groups (e.g., transceiver statistics group, receive window statistics group, transmit measurement statistics group, EPE statistics group, RSSI statistics group, etc.). The RSSI statistics group can be a symbol RSSI statistics group. The measurement interval can be set independently for each measurement group. For example, the measurement interval can be different for each measurement group. The transceiver measurement interval (transceiver-measurement-interval), receive window measurement interval (rx-window-measurement-interval), transmit measurement interval (tx-measurement-interval), EPE measurement interval (epe-measurement interval), and / or RSSI measurement interval (rssi-measurement-interval) may be set independently of each other.

[0062] Measurement results (e.g., measurement values) measured by the O-RU according to each measurement interval setting configured by the O-DU (e.g., NETCONF client) can be transmitted using the NETCONF notification mechanism at a time point according to the notification interval. For example, the O-RU can periodically transmit the measurement results to the O-DU. Alternatively, the O-RU can store the measurement results by measurement time on a local disk and upload the measurement results to the O-DU at a time point according to the file upload interval. In this case, the notification interval can be set differently from the measurement interval. In the embodiments, the measurement interval may refer to a measurement interval, the notification interval may refer to a notification interval, and the "notification sending and receiving operation" may refer to the "notification message sending and receiving operation."

[0063] For example, the measurement interval for measurement object #A may be set to 3 minutes, and the measurement interval for measurement object #B may be set to 5 minutes. To efficiently transmit performance management information, the notification interval may be set to 15 minutes. In this case, it may be preferable to transmit one notification (e.g., a notification message) including five measurement results for measurement object #A and three measurement results for measurement object #B in the NETCONF notification transmission procedure. If the notification interval is set longer than the measurement interval for a specific measurement object, multiple measurement results may exist in the O-RU at the time of notification transmission. Multiple measurement results for a specific measurement object may be included in one notification.

[0064] The existing YANG model defined in the O-RAN M-Plane may not be able to support the sending and receiving of a single notification containing multiple measurement results. In the embodiment, the "sending and receiving of a single notification containing multiple measurement results" can be referred to as a "multiple measurement result reporting function." That is, the existing YANG model can transmit a single notification containing one measurement result per measurement object. Therefore, if the notification interval is set longer than the measurement interval of the measurement object, a notification containing only one measurement result can be transmitted, and the remaining measurement results during the notification interval cannot be transmitted to the O-DU (e.g., NETCONF client). A method for solving the above problem will be described below.

[0065] In relation to performance management in the O-RAN M-Plane (hereinafter referred to as "O-RAN M-Plane"), the interface and configuration information between the O-DU and O-RU can be defined in the o-ran-performance-management.yang module. In the O-RAN M-Plane, the "format for management information sent and received between devices" and "transmission procedure for management information" can be defined using the NETCONF / YANG model.

[0066] The main parameters used for performance management in the o-ran-performance-management.yang module can be defined in Tables 1 and 2 below. As the O-RAN standard is updated, other parameters can be added to Tables 1 and 2, and the parameters defined in Tables 1 and 2 can be changed.

[0067] [Table 1]

[0068] [Table 2]

[0069] The O-DU (e.g., NETCONF client) can configure the measurement target, values ​​(e.g., maximum, minimum, count, etc.) included in the report information, object unit, measurement interval, notification interval, and / or file upload interval. The O-DU can notify the O-RU of the configuration information. The O-RU can perform measurements at the configured measurement interval for the measurement target selected by the information (e.g., values) configured by the O-DU, and can transmit notifications containing the measurement results or upload measurement result files at the configured notification interval or file upload interval.

[0070] The measurement intervals for the measurement objects can be set for each measurement group. For example, the transceiver measurement interval, the receive window measurement interval, the transmission measurement interval, the EPE measurement interval, and the RSSI measurement interval can be set independently of each other.

[0071] Measurements can be activated for each measurement object. The O-DU can set the information element(s) included in the report information for each measurement object. For example, the report information can include multiple information elements. The information element(s) can include MAXIMUM, MINIMUM, FIRST, LATEST, and / or FREQUENCY_TABLE. The target unit can be set independently for each measurement object. For example, the target unit can be different for each measurement object.

[0072] FIG. 7 is a conceptual diagram illustrating a first embodiment of a data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane.

[0073] Referring to Figure 7, the O-RU can store measurement results for measurement objects belonging to the transceiver statistics group and the receive window statistics group in a data store based on the YANG model. The O-RU can transmit a NETCONF notification including the measurement result(s) to the O-DU (e.g., a NETCONF client). The transceiver statistics group can be referred to as a transceiver measurement object, and the receive window statistics group can be referred to as a receive window measurement object. Activation for each measurement object can be set to true or false. The default activation for each measurement object can be false. The count value can start from 0 at the boundary of the measurement interval.

[0074] FIG. 8 is a conceptual diagram illustrating a second embodiment of a data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane.

[0075] Referring to Figure 8, the O-RU can store measurement results for measurement objects belonging to the EPE statistics group and the transmission measurement statistics group in a data store based on a YANG model. The O-RU can transmit a NETCONF notification containing the measurement result(s) to the O-DU (e.g., a NETCONF client). The EPE statistics group can be referred to as an EPE measurement object, and the transmission measurement statistics group can be referred to as a transmission measurement object. Activation for each measurement object can be set to true or false. Activation for each measurement object can be set to false by default.

[0076] FIG. 9 is a conceptual diagram illustrating a third embodiment of a data structure of a YANG model for transmitting performance measurement results in an O-RAN M-Plane.

[0077] 9, a measurement group (group) for various measurement results (e.g., measurement information) of symbol RSSI statistics (e.g., RSSI for a specific symbol in the time domain) may be newly added. The measurement information may have a structure identical to or similar to that shown in FIG. 7 or 8. For example, the structure of the symbol RSSI statistics may be identical to or similar to the structure of the transceiver statistics.

[0078] The O-RU can perform measurement operations at the measurement interval set by the O-DU (e.g., NETCONF client). The O-RU can periodically transmit measurement result(s) to the O-DU using the NETCONF notification mechanism at the time of the notification interval. Alternatively, the O-RU can store the measurement result(s) on its local disk at each measurement time and upload the measurement result(s) to the O-DU at the time of the file upload interval.

[0079] The notification interval may be set differently from the measurement interval. For example, the measurement interval for measurement object #A may be set to 3 minutes, and the measurement interval for measurement object #B may be set to 5 minutes. To efficiently transmit performance management information, the notification interval may be set to 15 minutes. In this case, it may be preferable to transmit one notification (e.g., a notification message) including five measurement results for measurement object #A and three measurement results for measurement object #B in the NETCONF notification transmission procedure. If the notification interval is set longer than the measurement interval for the measurement object, multiple measurement results may exist in the O-RU at the time of notification transmission. Multiple measurement results for the measurement object may be included in one notification.

[0080] The existing YANG model defined in the O-RAN M-Plane may not support the transmission of a single notification containing multiple measurement results. That is, the existing YANG model can transmit one notification containing one measurement result per measurement object. Therefore, if the notification interval is set longer than the measurement interval of the measurement object, a notification containing only one measurement result may be transmitted, and the remaining measurement results during the notification interval may not be transmitted to the O-DU (e.g., NETCONF client). That is, in the current O-RAN YANG model (e.g., the YANG model shown in Figures 7 and 8), the transmission of a single notification may be performed to transmit one measurement result for each measurement object. To address the above issues, the following method of extending the YANG model will be proposed.

[0081] Part 1 (e.g., common setting part) of the YANG model for performance management of the O-RAN M-Plane may be as follows:

[0082] [Part 1 of the YANG model] module:o-ran-performance-management +--rw performance-measurement-objects +--ro measurement-capabilitites │ +--ro transceiver-objects* [measurement-object] │ │ +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object │ +--ro rx-window-objects* [measurement-object] │ │ +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object │ +--ro tx-stats-objects* [measurement-object] │ │ +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object │ +--ro epe-stats-objects* [measurement-object] │ +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object │ +--ro component-class* identityref +--rw enable-SFTP-upload? boolean +--rw enable-random-file-upload? boolean +--rw remote-SFTP-uploads* [remote-SFTP-upload-path] │ +--rw remote-SFTP-upload-path inet:uri +--rw transceiver-measurement-interval? uint16 +--rw rx-window-measurement-interval? uint16 +--rw epe-measurement-interval? uint16 +--rw tx-measurement-interval? uint16 +--rw notification-interval? uint16 +--rw file-upload-interval? uint16 +--ro max-bin-count uint16

[0083] Part 1 of the YANG model described above can define parameters that are commonly applied to all measurement objects. For example, Part 1 of the YANG model can define measurement object information supported by the O-RU, measurement interval settings for each measurement group (e.g., transceiver measurement interval, receive window measurement interval, transmit measurement interval, EPE measurement interval, RSSI measurement interval), notification interval, and / or file upload interval. The transceiver measurement interval, receive window measurement interval, transmit measurement interval, EPE measurement interval, and RSSI measurement interval can be set differently from each other. The notification interval or file upload interval can be set to a common value. The notification interval or file upload interval can be set differently from the transceiver measurement interval, receive window measurement interval, transmit measurement interval, EPE measurement interval, and / or RSSI measurement interval.

[0084] Part 2 of the YANG model for O-RAN M-Plane performance management (eg, transceiver, receive window related notifications) may be as follows:

[0085] [Part 2 of the YANG model] notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:data-and-time | +--ro end-time? yang-types:data-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decima164 | | +--ro time? yang-types:data-and-time | +--ro max | | +--ro value? decima164 | | +--ro time? yang-types:data-and-time | +--ro first | | +--ro value? decima164 | | +--ro time? yang-types:data-and-time | +--ro latest | | +--ro value? decima164 | | +--ro time? yang-types:data-and-time | +--ro frequency-table* uint32 +--ro rx-window-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object +--ro start-time? yang-types:data-and-time +--ro end-time? yang-types:data-and-time +--ro(object-unit-id)? +--:(RU) | +--ro name? -> / hw:hardware / component / name | +--ro count uint64 +--:(TRANSPORT) | +--ro tr-measured-result* [] | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name | +--ro count uint64 +--:(EAXC_ID) +--ro eaxc-measured-result* [] +--ro eaxc-id? uint16 +--ro count uint64 +--ro transport-name? -> / o-ran-elements:processing-elemnets / ru-elements / name

[0086] Part 3 of the YANG model for O-RAN M-Plane performance management (eg, EPE, transmission window related notifications) may be as follows:

[0087] [Part 3 of the YANG model] +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:data-and-time | +--ro end-time? yang-types:data-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name? -> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name? -> / o-ran-elements:processing-elemnets / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:data-and-time | +--ro end-time? yang-types:data-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decima164 | +--ro max? decima164 | +--ro average? decima164 +--ro epe-statistics* [measurement-object] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:data-and-time +--ro end-time? yang-types:data-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id ->hw:hardware / component / class +--ro min? decima164 +--ro max? decima164 +--ro average? decima164

[0088] Parts 2 and 3 of the YANG model may be YANG models defined for transmitting measurement information related to a transceiver, receive window, EPE, and / or transmit window in the form of a NETCONF notification. Each of the transceiver statistics, receive window statistics, transmit statistics, EPE statistics, and RSSI statistics may include one result (e.g., value) measured for one measurement object in a measurement period from a start time to an end time.

[0089] That is, results measured over multiple time intervals (e.g., multiple measurement intervals) may not be transmitted using a single notification. In particular, if the measurement intervals for the transceiver, receive window, EPE, transmit window, and RSSI are set differently, notifications containing the measurement results must be transmitted frequently. A YANG model to solve this problem can be configured as follows:

[0090] [Method A] When method A is used, an additional measurement list including one or more measurement results for each measurement object can be set, and the additional measurement list can be added to the statistical information for the corresponding measurement object. For example, the additional measurement list can be added to the statistical information in chronological order.

[0091] FIG. 10 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for a transceiver in a YANG model using Method A.

[0092] Referring to FIG. 10, an additional-transceiver-measurement-result for each measurement object (eg, RX_POWER, TX_POWER, TX_BIAS_COUNT, TEMPARATURE, etc.) may be added.

[0093] FIG. 11 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a receive window in a YANG model using Method A.

[0094] Referring to FIG. 11, an additional receive window measurement result (additional-rx-window-measurement-result) for each measurement object (e.g., RX_ON_TIME, RX_EARLY, RX_LATE, RX_CORRUT, RX_DUPL, RX_TOTAL, etc.) may be added.

[0095] FIG. 12 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for EPE in a YANG model using Method A.

[0096] Referring to FIG. 12, an additional EPE measurement result (additional-epe-measurement-result) for each measurement object (eg, TEMPARATURE, POWER) can be added.

[0097] FIG. 13 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for transmission measurements in a YANG model using Method A.

[0098] Referring to FIG. 13, an additional transmission measurement result (additional-tx-measurement-result) for each measurement object (eg, TX_TOTAL, TX_TOTAL_C) may be added.

[0099] FIG. 14 is a conceptual diagram illustrating a first embodiment of an extended measurement result structure for symbol RSSI in a YANG model using Method A.

[0100] Referring to FIG. 14, an additional-symbol-rssi-measurement-result for each measurement object (eg, ALL-UL-SYMBOLS, CONFIGURED-SYMBOLS) may be added.

[0101] The structure of the YANG model according to Method 1 above can be defined as follows:

[0102] <Method 1> module:o-ran-performance-management ...(omission)... notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | | +--ro min | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro max | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro first | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro latest | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro frequeny-table* uint32 | +--ro number-of-additional-measurement-result? uint8 | +--ro additional-transceiver-measurement-result* [seq-number] | +--ro seq-number uint8 | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro data-direction? Enumeration | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro number-of-additional-measurement-result? uint8 | +--ro additional-rx-window-measurement-result* [seq-number] | +--ro seq-number uint8 | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro number-of-additional-measurement-result? uint8 | +--ro additional-tx-measurement-result* [seq-number] | +--ro seq-number uint8 | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)?: | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro number-of-additional-measurement-result? uint8 +--ro additional-epe-measurement-result* [seq-number] +--ro seq-number uint8 +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0103] The modified YANG code can be as follows:

[0104] grouping measurement-notification { description ”notification may contain measurement result for transceiver-stats and / or rx-window-stats and / or tx-stats and / or epe-stats”; list transceiver-stats { key “measurement-object”; description “measurement result of transceiver-measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / transceiver-measurement-objects / measurement-object”; } description “measurement-object for the transceiver-measurement”; } uses start-and-end-time; / / start-and-end-time of the first result uses transceiver-measurement-result-grouping; / / First result / / For additional measurement result leaf number-of-additional-measurement-result { type uint8; config false; description ”This parameter indicates the number of additional measurement result.”; } list additional-transceiver-measurement-result { / / when measurement-interval < notification interval config false; description ”measurement result of additional transceiver-measurement”; key seq-number; leaf seq-number { type uint8 { range “1..max”; } } uses start-and-end-time; uses transceiver-measurement-result-grouping; } } list rx-window-stats { key “measurement-object”; description ”measurement result for the reception window measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / rx-window-measurement-objects / measurement-object”; } description ”measurement-object for the reception window measurement”; } uses start-and-end-time; uses rx-window-measurement-result-grouping; / / For additional measurement result leaf number-of-additional-measurement-result { type uint8; config false; description ”This parameter indicates the number of additional measurement result.”; } list additional-rx-window-measurement-result { / / when measurement-interval < notification interval config false; description ”measurement result of additional rx-window-measurement”; key seq-number; leaf seq-number { type uint8 { range “1..max”; } } uses start-and-end-time; uses rx-window-measurement-result-grouping; } } list tx-stats { key “measurement-object”; description ”measurement result for the tx stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / tx-measurement-objects / measurement-object”; } description ”measurement-object for the tx stats measurement”; } uses start-and-end-time; uses tx-measurement-result-grouping; / / For additional measurement result leaf number-of-additional-measurement-result { type uint8; config false; description ”This parameter indicates the number of additional measurement result.”; } list additional-tx-measurement-result { / / when measurement-interval < notification interval config false; description ”measurement result of additional tx-measurement”; key seq-number; leaf seq-number { type uint8 { range “1..max”; } } uses start-and-end-time; uses tx-measurement-result-grouping; } } container epe-stats { description ”container for the epe stats measurement - deprecated because measurement object isn’t included”; status deprecated; uses start-and-end-time; uses epe-measurement-result-grouping; } list epe-statistics { key “measurement-object”; description ”measurement result for the epe stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / epe-measurement-objects / measurement-object”; } description ”measurement-object for the epe stats measurement”; } uses start-and-end-time; uses epe-measurement-result-grouping; / / For additional measurement result leaf number-of-additional-measurement-result { type uint8; config false; description ”This parameter indicates the number of additional measurement result.”; } list additional-epe-measurement-result { / / when measurement-interval < notification interval config false; description ”measurement result of additional epe-measurement”; key seq-number; leaf seq-number { type uint8 { range “1..max”; } } uses start-and-end-time; uses epe-measurement-result-grouping; } } }

[0105] If the notification interval of a measurement object is longer than the measurement interval, multiple measurement results for each measurement object can be included in one notification (e.g., one notification message). To support this behavior, the YANG model can be extended so that each measurement object belonging to the transceiver statistics group, receive window statistics group, transmit statistics group, and EPE statistics group can include an additional measurement result list or an entire measurement result (e.g., list additional-transceiver-measurement-result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result, etc.).

[0106] The additional measurement result list may include a start time (e.g., measurement start time), an end time (e.g., measurement end time), and measurement results for a corresponding time interval (e.g., measurement values ​​for a measurement interval). The measurement interval may be a time interval from the start time to the end time.

[0107] In the existing YANG model, one notification containing only one measurement result per measurement target can be transmitted. If the measurement results are converted into a measurement result list, fronthaul equipment (e.g., O-DU and / or O-RU) that supports the existing YANG model cannot decode the measurement result list. That is, backward compatibility issues with existing fronthaul equipment may occur. The YANG model proposed in this application can use the start time, end time, and measurement results of the existing YANG model as they are. The measurement results of the existing YANG model can include the first measurement result. Compared to the existing YANG model, the proposed YANG model can further include an additional measurement result list. The additional measurement result list can include one or more measurement results from the second measurement result. The measurement results can be arranged in chronological order (e.g., ascending order of measurement time) in the additional measurement result list. This operation may be referred to as "method a." According to method a, the measurement-related parameters used in the existing YANG model are used as they are, so backward compatibility issues do not occur.

[0108] That is, an existing O-DU that can decode only one measurement result in one notification can decode existing parameter(s) (e.g., transceiver-stats, rx-window-stats, tx-stats, epe-stats). In this case, even if an O-RU transmits one notification including multiple measurement results, the existing O-DU can successfully receive one measurement result.

[0109] Alternatively, the O-RU may set the last measurement result (e.g., the latest measurement result) of the multiple measurement results as an existing measurement result parameter and generate an additional measurement result list (e.g., additional-XXXX-measurement-result) including the first measurement result to the last but not yet final measurement result. This operation may be referred to as "Method b." According to Method b, one measurement result that the existing O-DU can receive may be the latest measurement result.

[0110] To improve the O-DU's decoding convenience during the notification reception procedure, the O-RU can notify the O-DU of the number of measurement results included in the additional measurement result list (e.g., number-of-additional-measurement-result). That is, the additional measurement result list can further include number-of-additional-measurement-result. The additional measurement result list can also include a sequence number (e.g., seq-number). When method a is used, the sequence numbers for the measurement results in the measurement result list can start from 1 and increase chronologically. In this case, the sequence number of an existing measurement result (e.g., the first measurement result) can be considered to be 0. When method b is used, the sequence numbers for the measurement results in the measurement result list can start from 0 and increase chronologically. In this case, the existing measurement result can be considered to be the last measurement result. The O-DU can easily sort the measurement results in chronological order by using the sequence number as the key value of the additional measurement result list. The O-DU can also easily find a specific measurement result using the sequence number.

[0111] The sequence number may not be included in the additional measurement result list, and the start time and end time may be used as key values ​​of the additional measurement result list instead of the sequence number. The key of the additional measurement result list may not be specified. If the key of the additional measurement result list is not specified, the O-DU cannot directly access a specific entry (e.g., a specific measurement result) in the additional measurement result list and must always decode the entire additional measurement result list. To reduce the number of parameters, the number-of-additional-measurement-result may not be used. Even if the number of entries (e.g., measurement results) included in the additional measurement result list is not explicitly specified in the NETCONF / YANG model, the receiver (e.g., O-DU) can know the number of entries. The number-of-additional-measurement-result may be used to improve the receiver's decoding convenience. In order to sort the additional measurement result list in chronological order rather than arbitrarily defining the order of the additional measurement result list in the communication system, the key value, the sequence number, may be defined as "ordered-by user".

[0112] Alternatively, when an O-RU transmits measurement results to an existing O-DU (e.g., an O-DU supporting an O-RAN M-Plane version earlier than 7.0, or an O-DU unable to decode the additional measurement result list), the O-RU may transmit a leaf (e.g., start-time, end-time, and XXXX-measurement-result[]) capable of transmitting one measurement result. Alternatively, the O-RU may transmit an additional measurement result list including all of the measurement results to an O-DU (e.g., an O-DU supporting O-RAN M-Plane 7.0, or an O-DU supporting O-RAN M-Plane 7.0 or later) capable of processing the additional measurement result list. This operation may be referred to as "method c." In the embodiment, an O-DU capable of processing the additional measurement result list may be referred to as a "new O-DU," and an O-DU unable to process the additional measurement result list may be referred to as an "existing O-DU," and O-DU may refer to a new O-DU and / or an existing O-DU.

[0113] The YANG model described above in method c can be used as is. However, when transmitting a notification to an existing O-DU, the transmission of the additional measurement result list (e.g., additional-XXXX-measurement-result[]) can be omitted, and only the existing leaf can be used. When transmitting a notification to a new O-DU, the transmission of the leaf that can transmit one measurement result can be omitted, and the O-RU can transmit an additional measurement result list (additional-XXXX-measurement-result[]) containing multiple measurement results to the new O-DU. All measurement results (e.g., from the first measurement result to the last measurement result) in the additional measurement result list can be sorted in chronological order.

[0114] The O-RU can transmit a notification containing one measurement result for each measurement target to the existing O-DU. In this case, the existing O-DU can set the measurement interval of the O-RU to be the same as the notification interval so that one measurement result is generated per notification interval. Alternatively, if the existing O-DU sets the notification interval longer than the measurement interval, the O-RU can transmit only the latest measurement result to the existing O-DU. The detailed method of the above operation is described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multi-measurement result reporting function>.

[0115] When the above method is used, to improve the O-DU's decoding convenience during the notification reception procedure, the O-RU can notify the O-DU of the number of measurement results included in the additional measurement result list (number-of-additional-measurement-result). The measurement result list can include a sequence number (seq-number). The sequence numbers for measurement results in the measurement result list can start from 0 and increase chronologically. The O-DU can easily sort the measurement results in chronological order by using the sequence number as the key value of the additional measurement result list. In addition, the O-DU can easily search for a specific measurement result using the sequence number.

[0116] Alternatively, the O-RU can transmit one notification containing multiple measurement results. In this case, the O-RU can generate multiple additional measurement result lists based on the multiple measurement results and transmit a notification containing the multiple additional measurement result lists to the O-DU. On the other hand, an O-RU that does not support the above operation can transmit one measurement result to the O-DU using a leaf that supports the transmission of one measurement result. An existing O-DU cannot decode the additional measurement result list, but can ignore the new additional leaf (e.g., the additional measurement result list). Therefore, no errors can occur in the existing O-DU.

[0117] Alternatively, in the measurement result transmission procedure, as in method a and / or method b, the O-RU can transmit a notification to the O-DU that includes a "leaf containing one measurement result (e.g., one measurement result per measurement object, the latest measurement result)" and an "additional measurement result list containing multiple measurement results." All of the multiple measurement results can be included in the additional measurement result list. This operation can be referred to as "method d." In this case, one measurement result (e.g., the latest measurement result) can be included in both the existing leaf and the additional measurement result list. When method d is used, one measurement result is transmitted in duplicate, but the O-RU does not need to distinguish the type of O-DU (e.g., existing O-DU or new O-DU). In addition, the O-RU can transmit a common notification that can be decoded by both existing and new O-DUs without a separate control parameter (e.g., enable-multiple-stats-in-notification). In other words, the implementation complexity of the O-RU can be reduced.

[0118] The existing O-DU can decode a leaf containing one measurement result and therefore obtain one measurement result in a notification received from the O-RU. The new O-DU can decode an additional measurement result list containing multiple measurement results and perform processing operations based on the multiple measurement results.

[0119] If one measurement result occurs for each measurement object during a notification interval, the O-RU can transmit a leaf containing one measurement result. In this case, duplicated information can be reduced. Alternatively, the O-RU can generate a leaf containing one measurement result and an additional measurement result list containing the measurement result, and transmit the leaf containing the measurement result and the additional measurement result list to the O-DU. That is, the same measurement result can be included in the leaf containing the measurement result and the additional measurement result list. In this case, although the overhead of transmitting duplicated information may increase, a new O-DU only needs to decode the additional measurement result list instead of the existing leaf, regardless of the number of measurement results. In this case, the implementation complexity of the O-DU can be reduced.

[0120] The new O-DU can support all the functions of the existing O-DU. Therefore, even if an existing leaf containing one measurement result is received, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU can ignore the additional measurement result list (e.g., a new leaf). Therefore, no errors may occur in the existing O-DU. The existing O-DU can receive the existing leaf containing one measurement result and decode it. In method d, the existing O-DU can always perform reception and decoding operations for one measurement result (e.g., the latest measurement result). Therefore, the existing O-DU can operate in the existing method. The above method can solve the backward compatibility issue. Detailed methods of the above operations are described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multiple measurement result reporting functions>.

[0121] When the above method is used, to improve the O-DU's decoding convenience during the notification reception procedure, the O-RU can notify the O-DU of the number of measurement results included in the additional measurement result list (number-of-additional-measurement-result). The measurement result list can include a sequence number (seq-number). The sequence numbers for measurement results in the measurement result list can start from 0 and increase chronologically. The O-DU can easily sort the measurement results in chronological order by using the sequence number as the key value of the additional measurement result list. In addition, the O-DU can easily search for a specific measurement result using the sequence number.

[0122] <Method 2> In Method 2, number-of-additional-measurement-result and seq-number may not be used, and start-time and end-time may be used as keys for the additional measurement result list (additional-XXXXX-measurement list). Measurement results for each measurement object may be sorted in chronological order within the additional measurement result list (additional-xxxx-measurement-list[]).

[0123] The structure of the YANG model according to Method 2 above can be defined as follows:

[0124] module:o-ran-performance-management ...(omission)... notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | | +--ro min | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro max | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro first | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro latest | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro frequeny-table* uint32 | +--ro additional-transceiver-measurement-result* [start-time end-time] | +--ro start-time yang-types:date-and-time | +--ro end-time yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro data-direction? Enumeration | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro additional-rx-window-measurement-result* [start-time end-time] | +--ro start-time yang-types:date-and-time | +--ro end-time yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro additional-tx-measurement-result* [start-time end-time] | +--ro start-time yang-types:date-and-time | +--ro end-time yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro additional-epe-measurement-result* [start-time end-time] +--ro start-time yang-types:date-and-time +--ro end-time yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0125] Alternatively, when an O-RU transmits measurement results to an existing O-DU (e.g., an O-DU supporting an O-RAN M-Plane version earlier than 7.0, or an O-DU that cannot decode the additional measurement result list), the O-RU can transmit a leaf (e.g., start-time, end-time, and XXXX-measurement-result[]) that can transmit one measurement result. Alternatively, the O-RU can transmit an additional measurement result list containing multiple measurement results to a new O-DU (e.g., an O-DU supporting O-RAN M-Plane 7.0, or an O-DU supporting O-RAN M-Plane 7.0 or later) that can process the additional measurement result list. This operation may be referred to as "Method c."

[0126] The YANG model described above in method c can be used as is. However, when transmitting a notification to an existing O-DU, the transmission of the additional measurement result list (additional-XXXX-measurement-result[]) can be omitted and only the existing leaf can be used. When transmitting a notification to a new O-DU, the transmission of the leaf that can transmit one measurement result can be omitted, and the O-RU can transmit an additional measurement result list (additional-XXXX-measurement-result[]) containing all of the measurement results to the new O-DU. All measurement results (e.g., from the first measurement result to the last measurement result) in the additional measurement result list can be sorted in chronological order.

[0127] The O-RU can transmit a notification including one measurement result for each measurement object to the existing O-DU. In this case, the existing O-DU can set the measurement interval of the O-RU to be the same as the notification interval so that one measurement result is generated per notification interval. Alternatively, if the existing O-DU sets the notification interval longer than the measurement interval, the O-RU can transmit only the latest measurement result to the existing O-DU. The detailed method of the above operation is described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multi-measurement result reporting function>.

[0128] If the above method is used, number-of-additional-measurement-result and seq-number may not be used. start-time and end-time may be used as keys for the additional-XXXXX-measurement list.

[0129] Alternatively, the O-RU can transmit one notification containing multiple measurement results. In this case, the O-RU can generate an additional measurement result list(s) based on the multiple measurement results and transmit a notification containing the additional measurement result list(s) to the O-DU. On the other hand, an O-RU that does not support the above operation can transmit one measurement result to the O-DU using a leaf that supports the transmission of one measurement result. An existing O-DU cannot decode the additional measurement result list, but can ignore the new additional leaf (e.g., the additional measurement result list). Therefore, no errors can occur in the existing O-DU.

[0130] Alternatively, in the measurement result transmission procedure, as in method a and / or method b, the O-RU can transmit a notification to the O-DU that includes a "leaf containing one measurement result (e.g., one measurement result per measurement object, the latest measurement result)" and an "additional measurement result list containing multiple measurement results." All of the multiple measurement results can be included in the additional measurement result list. This operation can be referred to as "method d." In this case, one measurement result (e.g., the latest measurement result) can be included in both the existing leaf and the additional measurement result list. When method d is used, one measurement result is transmitted in duplicate, but the O-RU does not need to distinguish the type of the other O-DU (e.g., existing O-DU or new O-DU). In addition, the O-RU can transmit a common notification that can be decoded by both existing and new O-DUs without a separate control parameter (e.g., enable-multiple-stats-in-notification). In other words, the implementation complexity of the O-RU can be reduced.

[0131] The existing O-DU can decode a leaf containing one measurement result and therefore obtain one measurement result in a notification received from the O-RU. The new O-DU can decode an additional measurement result list containing multiple measurement results and perform processing operations based on the multiple measurement results.

[0132] If one measurement result occurs for each measurement object during a notification interval, the O-RU can transmit a leaf containing one measurement result. In this case, duplicated information can be reduced. Alternatively, the O-RU can generate a leaf containing one measurement result and an additional measurement result list containing the measurement result, and transmit the leaf containing the measurement result and the additional measurement result list to the O-DU. That is, the same measurement result can be included in the leaf containing the measurement result and the additional measurement result list. In this case, although the overhead of transmitting duplicated information may increase, a new O-DU only needs to decode the additional measurement result list instead of the existing leaf, regardless of the number of measurement results. In this case, the implementation complexity of the O-DU can be reduced.

[0133] The new O-DU can support all the functions of the existing O-DU. Therefore, even if an existing leaf containing one measurement result is received, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU can ignore the additional measurement result list (e.g., a new leaf). Therefore, no errors may occur in the existing O-DU. The existing O-DU can receive the existing leaf containing one measurement result and decode it. In method d, the existing O-DU can always perform reception and decoding operations for one measurement result (e.g., the latest measurement result). Therefore, the existing O-DU can operate in the existing method. The above method can solve the backward compatibility issue. Detailed methods of the above operations are described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multiple measurement result reporting functions>.

[0134] In the above method 2, the number-of-additional-measurement-result and seq-number may not be used, and the start-time and end-time may be used as keys for the additional-XXXXX-measurement list.

[0135] <Method 3> Alternatively, the number-of-additional-measurement-result and seq-number may not be used, and the key for the additional-XXXXX-measurement list may not be used. This operation may be "Method 3".

[0136] The structure of the YANG model according to Method 3 may be as follows:

[0137] module:o-ran-performance-management …(omitted)… = notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | | +--ro min | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro max | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro first | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro latest | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro frequeny-table* uint32 | +--ro additional-transceiver-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro data-direction? Enumeration | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro additional-rx-window-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro additional-tx-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro additional-epe-measurement-result* [] +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0138] Alternatively, when an O-RU transmits measurement results to an existing O-DU (e.g., an O-DU supporting an O-RAN M-Plane version earlier than 7.0, or an O-DU that cannot decode the additional measurement result list), the O-RU can transmit a leaf (e.g., start-time, end-time, and XXXX-measurement-result[]) that can transmit one measurement result. Also, the O-RU can transmit an additional measurement result list containing multiple measurement results to an O-DU that can process the additional measurement result list (e.g., an O-DU supporting O-RAN M-Plane 7.0, or an O-DU supporting a version later than O-RAN M-Plane 7.0). This operation may be referred to as "Method c."

[0139] The YANG model described above in method c can be used as is. However, when transmitting a notification to an existing O-DU, the transmission of the additional measurement result list (e.g., additional-XXXX-measurement-result[]) can be omitted, and only the existing leaf can be used. When transmitting a notification to a new O-DU, the transmission of the leaf that can transmit one measurement result can be omitted, and the O-RU can transmit an additional measurement result list (additional-XXXX-measurement-result[]) containing all of the measurement results to the new O-DU. All measurement results (e.g., from the first measurement result to the last measurement result) in the additional measurement result list can be sorted in chronological order.

[0140] The O-RU can transmit a notification including one measurement result for each measurement object to the existing O-DU. In this case, the existing O-DU can set the measurement interval of the O-RU to be the same as the notification interval so that one measurement result is generated per notification interval. Alternatively, if the existing O-DU sets the notification interval longer than the measurement interval, the O-RU can transmit only the latest measurement result to the existing O-DU. The detailed method of the above operation is described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multi-measurement result reporting function>.

[0141] In the above method, the number-of-additional-measurement-result and seq-number may not be used, and the key may not be used in the additional-XXXXX-measurement list. The modified YANG code for this method can be defined as follows:

[0142] grouping measurement-notification { description ”notification may contain measurement result for transceiver-stats and / or rx-window-stats and / or tx-stats and / or epe-stats”; list transceiver-stats { key “measurement-object”; description “measurement result of transceiver-measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / transceiver-measurement-objects / measurement-object”; } description “measurement-object for the transceiver-measurement”; } uses start-and-end-time; / / start-and-end-time of the first result uses transceiver-measurement-result-grouping; / / First result / / For additional measurement result list additional-transceiver-measurement-result { / / when measurement-interval < notification interval config false; description ”Multiple measurement results of transceiver-measurement”; uses start-and-end-time; uses transceiver-measurement-result-grouping; } } list rx-window-stats { key “measurement-object”; description ”measurement result for the reception window measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / rx-window-measurement-objects / measurement-object”; } description ”measurement-object for the reception window measurement”; } uses start-and-end-time; uses rx-window-measurement-result-grouping; / / For additional measurement result list additional-rx-window-measurement-result { / / when measurement-interval < notification interval config false; description ”Multiple measurement results of rx-window-measurement”; uses start-and-end-time; uses rx-window-measurement-result-grouping; } } list tx-stats { key “measurement-object”; description ”measurement result for the tx stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / tx-measurement-objects / measurement-object”; } description ”measurement-object for the tx stats measurement”; } uses start-and-end-time; uses tx-measurement-result-grouping; / / For additional measurement result list additional-tx-measurement-result { / / when measurement-interval < notification interval config false; description ”Multiple measurement result of tx-measurement”; uses start-and-end-time; uses tx-measurement-result-grouping; } } container epe-stats { description ”container for the epe stats measurement - deprecated because measurement object isn’t included”; status deprecated; uses start-and-end-time; uses epe-measurement-result-grouping; } list epe-statistics { key “measurement-object”; description ”measurement result for the epe stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / epe-measurement-objects / measurement-object”; } description ”measurement-object for the epe stats measurement”; } uses start-and-end-time; uses epe-measurement-result-grouping; list additional-epe-measurement-result { / / when measurement-interval < notification interval config false; description ”Multiple measurement result of epe-measurement”; uses start-and-end-time; uses epe-measurement-result-grouping; } } }

[0143] Alternatively, the O-RU can transmit one notification containing multiple measurement results. In this case, the O-RU can generate an additional measurement result list(s) based on the multiple measurement results and transmit a notification containing the additional measurement result list(s) to the O-DU. On the other hand, an O-RU that does not support the above operation can transmit one measurement result to the O-DU using a leaf that supports the transmission of one measurement result. An existing O-DU cannot decode the additional measurement result list but can ignore the new additional leaf (e.g., the additional measurement result list). Therefore, no errors can occur in the existing O-DU.

[0144] Alternatively, in the measurement result transmission procedure, as in method a and / or method b, the O-RU can transmit a notification to the O-DU that includes a "leaf containing one measurement result (e.g., one measurement result per measurement object, the latest measurement result)" and an "additional measurement result list containing multiple measurement results." All of the multiple measurement results can be included in the additional measurement result list. This operation can be "method d." In this case, one measurement result (e.g., the latest measurement result) can be included in both the existing leaf and the additional measurement result list. When method d is used, one measurement result is transmitted in duplicate, but the O-RU does not need to distinguish the type of O-DU (e.g., existing O-DU or new O-DU). In addition, the O-RU can transmit a common notification that can be decoded by both existing and new O-DUs without a separate control parameter (e.g., enable-multiple-stats-in-notification). In other words, the implementation complexity of the O-RU can be reduced.

[0145] The existing O-DU can decode a leaf containing one measurement result and therefore obtain one measurement result in a notification received from the O-RU. The new O-DU can decode an additional measurement result list containing multiple measurement results and perform processing operations based on the multiple measurement results.

[0146] If one measurement result occurs for each measurement object during a notification interval, the O-RU can transmit a leaf containing one measurement result. In this case, duplicated information can be reduced. Alternatively, the O-RU can generate a leaf containing one measurement result and an additional measurement result list containing the measurement result, and transmit the leaf containing the measurement result and the additional measurement result list to the O-DU. That is, the same measurement result can be included in the leaf containing the measurement result and the additional measurement result list. In this case, although the overhead of transmitting duplicated information may increase, a new O-DU only needs to decode the additional measurement result list instead of the existing leaf, regardless of the number of measurement results. In this case, the implementation complexity of the O-DU can be reduced.

[0147] The new O-DU can support all the functions of the existing O-DU. Therefore, even if an existing leaf containing one measurement result is received, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU can ignore the additional measurement result list (e.g., a new leaf). Therefore, no errors may occur in the existing O-DU. The existing O-DU can receive the existing leaf containing one measurement result and decode it. In method d, the existing O-DU can always perform reception and decoding operations for one measurement result (e.g., the latest measurement result). Therefore, the existing O-DU can operate in the existing method. The above method can solve the backward compatibility issue. Detailed methods of the above operations are described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multiple measurement result reporting functions>.

[0148] In the above methods, the number-of-additional-measurement-result and seq-number may not be used, and the key of the additional-XXXXX-measurement list may not be used. Method a, method b, method c, and method d may be used, as well as combinations and / or variations of the above method(s).

[0149] [Example of Method A] In an embodiment according to Method A, the parameters may be set as shown in Table 3 below.

[0150] [Table 3]

[0151] Based on the settings in Table 3, the O-RU can transmit a notification containing two measurement results for measurement object A and four measurement results for measurement object B to the O-DU.

[0152] When method a is used, the first measurement result for measurement object A (e.g., measurement value in a measurement period of 0 to 30 minutes) may be included in transceiver-stats in the notification, and the start-time and end-time corresponding to the measurement period of 0 to 30 minutes may be set. The second measurement result for measurement object A (e.g., measurement value in a measurement period of 30 to 60 minutes) may be included in additional-transceiver-measurement-result, and the start-time and end-time corresponding to the measurement period of 30 to 60 minutes may be set.

[0153] The first measurement result for measurement object B (e.g., a measurement value in a measurement interval of 0 to 15 minutes) may be included in rx-window-stats in the notification, and a start-time and end-time corresponding to the measurement interval of 0 to 15 minutes may be set. The second measurement result for measurement object B (e.g., a measurement value in a measurement interval of 15 to 30 minutes), the third measurement result for measurement object B (e.g., a measurement value in a measurement interval of 30 to 45 minutes), and the fourth measurement result for measurement object B (e.g., a measurement value in a measurement interval of 45 to 60 minutes) may be included in additional-rx-window-measurement-result, and a start-time and end-time corresponding to the measurement interval of 15 to 30 minutes, 30 to 45 minutes, and 45 to 60 minutes may be set. When method b is used, the measurement result(s) from the first measurement result to the last but one measurement result may be set within additional-transceiver-measurement-result and additional-rx-window-measurement-result for measurement object A and measurement object B, respectively, and the last measurement result may be set within the existing transceiver-stats and rx-window-stats (e.g., existing rx-window-stats) for measurement object A and measurement object B, respectively.

[0154] In order to arrange the measurement results in chronological order within the additional measurement result list in the communication system, the key values ​​start-time and end-time can be set as "ordered-by user".

[0155] When method c is used, transceiver-stats for measurement target A may be omitted in the notification, and the first measurement result (e.g., measurement value in the measurement period of 0 to 30 minutes) and second measurement result (e.g., measurement value in the measurement period of 30 to 60 minutes) for measurement target A may be included in additional-transceiver-measurement-result in the notification. rx-window-stats for measurement target B may be omitted in the notification, and the first measurement result (e.g., measurement value in the measurement period of 0 to 15 minutes), second measurement result (e.g., measurement value in the measurement period of 15 to 30 minutes), third measurement result (e.g., measurement value in the measurement period of 30 to 45 minutes), and fourth measurement result (e.g., measurement value in the measurement period of 45 to 60 minutes) for measurement target B may all be included in additional-rx-window-measurement-result.

[0156] When method d is used, one measurement result for measurement object A (e.g., the last measurement value in the notification interval (e.g., the measurement value in the measurement period from 30 to 60 minutes)) may be included in transceiver-stats in the notification, and the first measurement result for measurement object A (e.g., the measurement value in the measurement period from 0 to 30 minutes) and the second measurement result (e.g., the measurement value in the measurement period from 30 to 60 minutes) may be included in additional-transceiver-measurement-result in the notification. One measurement result for measurement object B (e.g., the last measurement value in the notification interval (e.g., the measurement value in the 45-60 minute measurement period)) may be included in rx-window-stats in the notification, and the first measurement result for measurement object B (e.g., the measurement value in the 0-15 minute measurement period), the second measurement result (e.g., the measurement value in the 15-30 minute measurement period), the third measurement result (e.g., the measurement value in the 30-45 minute measurement period), and the fourth measurement result (e.g., the measurement value in the 45-60 minute measurement period) may all be included in additional-rx-window-measurement-result.

[0157] As a modified method of [Method A], additional-transceiver-measurement-result, additional-rx-window-measurement-result, additional-tx-measurement-result, and additional-epe-measurement-result can be included in the front parts of the YANG model, transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result, and epe-measurement-result, rather than notification. In other words, the front parts of the YANG model, transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result, and epe-measurement-result, can be extended. The O-DU can check the corresponding measurement-result using a get RPC instead of a notification method. In this case, the O-DU periodically sends a get RPC, which can cause overhead.

[0158] [Method B] In Method B, the entire structure in measurement-result-stats containing the measurement results for the entire measurement object can be repeatedly added to the notification in chronological order by measurement time.

[0159] In Method A, the YANG model can be extended to include additional measurement result lists (e.g., list additional-transceiver-measurement-result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result) in the statistics for the measurement objects belonging to each of transceiver-stats, rx-window-stats, tx-stats, and epe-statistic. In Method B, the additional measurement result lists can be added to the statistics for each measurement object separately, and the entire structure in measurement-result-stats containing the measurement results for all measurement objects can be added to the notification in chronological order for each measurement time.

[0160] <Method B-1> A YANG model according to <Method B-1> can be defined as follows:

[0161] module:o-ran-performance-management ...(omission)... notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro number-of-additional-measurement-result-stats? uint8 +--ro additional-measurement-result-stats* [seq-number] +--ro seq-number uint8 +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0162] The modified YANG code can be defined as follows:

[0163] notification measurement-result-stats { description “Notification may contain measurement results for transceiver-stats and / or rx-window-stats”; uses measurement-notification; / / For sending additional measurement result when notification-interval is larger than measurement-interval leaf number-of-additional-measurement-result-stats { type uint8; description “This parameter indicates the number of additional measurement result stats.”; } list additional-measurement-result-stats { / / For sending additional measurement result stats when notification-interval is larger than measurement-interval description ”Additional measurement result stats are included when notification-interval is larger than measurement-interval and 'enable-multiple-stats-in-notification' is true.”; key seq-number; leaf seq-number { / / sequence number in ascending order starting from 1 type uint8 { range “1..max”; } } uses measurement-notification; } }

[0164] If the notification interval for each measurement object is longer than the measurement interval, multiple measurement results for each measurement object can be included in the notification. To support this operation, the entire structure in measurement-result-stats containing the measurement result(s) for the measurement interval for all measurement objects belonging to transceiver-stats, rx-window-stats, tx-stats, and epe-statistics can be added to the notification in ascending time order for each measurement interval using the additional measurement result statistics list (additional-measurement-result-stats).

[0165] The additional measurement result statistics list may include measurement information for each of the entire measurement objects in the measurement interval (e.g., measurement start time, measurement end time, and / or measurement value for the measurement interval). The structure included in one entry of the additional measurement result statistics list may be the same as the structure of the existing measurement-result-stats that supports only one measurement result. The difference between the above structures may be the presence of information indicating the number of entries included in the additional measurement result statistics list (number-of-additional-measurement-result-stats) and a sequence number (seq-number) included in each entry of the additional measurement result statistics list. The sequence number may be used to easily sort entries in chronological order within the additional measurement result statistics list. The number-of-additional-measurement-result-stats may indicate the number of additional-measurement-result-stats entries included in the additional measurement result statistics list. The O-DU may facilitate the notification decoding operation based on the number-of-additional-measurement-result-stats.

[0166] In addition, the O-DU can easily sort entries in chronological order within the additional measurement result statistics list based on the sequence number. When method a is used, the sequence number can increase in ascending order from 1. When method b is used, the sequence number can increase in ascending order from 0. When method a is used, the measurement result included in the existing measurement-result-stats can be considered the 0th measurement result. When method b is used, the measurement result included in the existing measurement-result-stats can be considered the last measurement result. The O-DU can easily sort the measurement-result-stats in chronological order by using the sequence number as the key value of additional-measurement-result-stats. In addition, the O-DU can easily use the sequence number to search for measurement-result-stats in a specific order.

[0167] To reduce the number of transmission parameters, number-of-additional-measurement-result-stats may not be used. Even if the NETCONF / YANG model does not explicitly indicate the number of entries in the additional measurement result statistics list, the receiver knows the number of entries. number-of-additional-measurement-result-stats may be used for the receiver's decoding convenience.

[0168] The additional-measurement-results-stats key does not have to be set. If the key is not set, the O-DU cannot directly access a specific entry in the additional measurement result statistics list and must always decode the entire additional measurement result statistics list. In the existing YANG model, one notification can contain only one measurement result. If the measurement results are converted into a measurement result list, backward compatibility issues may occur with fronthaul equipment (e.g., O-DU and / or O-RU) that uses the existing YANG model. In the YANG model proposed in this application, the information structure (e.g., start-time, end-time, measurement-result) of the measurement-result-stats notification in the existing YANG model can be used as is. The measurement-result-stats notification in the existing YANG model can include the first measurement result. Compared to the existing YANG model, the proposed YANG model can further include an additional measurement result statistics list. The additional measurement result statistics list can be included from the second measurement result onwards. The measurement results can be arranged in chronological order (e.g., ascending order of measurement time) in the additional measurement result statistics list. This operation may be referred to as "Method A". According to method a, the measurement-related parameters used in the existing YANG model are used as they are, so there is no backward compatibility issue.

[0169] That is, an existing O-DU that can decode only one measurement-result-stats in one notification can decode existing parameter(s) (e.g., transceiver-stats, rx-window-stats, tx-stats, epe-stats). In this case, even if an O-RU transmits one notification including multiple measurement results, the existing O-DU can successfully receive one measurement result.

[0170] Alternatively, the O-RU may set the latest measurement result among the multiple measurement results as an existing measurement result parameter and generate an additional measurement result statistic list (e.g., additional-measurement-result-stat) including the first measurement result to the last measurement result. This operation may be referred to as "Method b." According to Method b, one measurement result that the existing O-DU can receive may be the latest measurement result.

[0171] In order to arrange the additional measurement result statistics list in chronological order in a communication system, the sequence number, which is a key value, can be defined as "ordered-by user."

[0172] [Example of Method B-1] In an embodiment according to Method B-1, the parameters can be set as shown in Table 4 below.

[0173] [Table 4]

[0174] Based on the settings in Table 4, the O-RU can transmit a notification to the O-DU containing two measurement results for measurement object A and four measurement results for measurement object B. In this case, the number of entries in measurement-result-stats can be determined based on the measurement interval for measurement object B, which has a short measurement interval.

[0175] When method a is used, the first measurement result for measurement object B may be included in the existing measurement-results-stats, but the measurement operation for measurement result A may not be included in the existing measurement-results-stats because it has not been completed. In other words, the existing measurement-results-stats can include measurement results in the measurement period from 0 to 15 minutes.

[0176] The first entry of additional-measurement-result-stats can include the results of measurement operations completed in a measurement period of 15 to 30 minutes (e.g., the second measurement result for measurement object B and the first measurement result for measurement object A). The second entry of additional-measurement-result-stats can include the results of measurement operations completed in a measurement period of 30 to 45 minutes (e.g., the third measurement result for measurement object B). The third entry of additional-measurement-result-stats can include the results of measurement operations completed in a measurement period of 45 to 60 minutes (e.g., the fourth measurement result for measurement object B and the second measurement result for measurement object A). When method b is used, the measurement result(s) from the first measurement result to the last but one measurement result can be set in additional-measurement-result-stats, and the last measurement result can be set in the existing measurement-result-stat. This operation can be applied equally to method b-2 described below.

[0177] As a modified method of [Method B], additional-measurement-result-stats can be included next to "transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result, and epe-measurement-result" in the earlier part of the YANG model instead of notification. The O-DU can check multiple measurement-result-stats using get RPC instead of notification. In this case, the O-DU can periodically send get RPC, which can incur overhead.

[0178] <Method B-2> In method B-2, the number-of-additional-measurement-result-stats and seq-number may be unused, and the key of the additional-measurement-result-stats list may be unused. In this case, the structure contained in one entry of the additional-measurement-result-stats list may be identical to the existing measurement-result-stats containing one measurement result.

[0179] A YANG model according to Method B-2 may be defined as follows:

[0180] module:o-ran-performance-management ...(omission)... notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro additional-measurement-result-stats* [] +--ro transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? Enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name x--ro epe-stats | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +--ro epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0181] The modified YANG code can be defined as follows:

[0182] notification measurement-result-stats { description ”Notification may contain measurement results for transceiver-stats and / or rx-window-stats”; uses measurement-notification; / / For sending additional measurement result when notification-interval is larger than measurement-interval list additional-measurement-result-stats { / / For sending additional measurement result stats when notification-interval is larger than measurement-interval description ”Additional measurement result stats are included when notification-interval is larger than measurement-interval and ’enable-multiple-stats-in-notification’ is true.”; uses measurement-notification;<00017!7>} }

[0183] <Method for ensuring interoperability with equipment that does not support backward compatibility and multi-measurement result reporting function>

[0184] It should be noted that there may be an error in the tag <00017!7> in the original text, which is likely to be . The translation is adjusted according to the corrected tag.Existing O-RUs (e.g., O-RUs supporting O-RAN M-Plane version 7.0 or earlier) cannot transmit a single notification containing multiple measurement results. That is, a single notification can only contain one measurement result. If the O-DU sets the measurement interval and notification interval to be the same, a single notification contains only one measurement result, so all measurement results can be sent and received without omission through individual notifications. This operation can be referred to as (Method B).

[0185] If the O-DU sets the notification interval longer than the measurement interval, the O-RU (e.g., an existing O-RU that cannot transmit one notification containing multiple measurement results) can transmit a notification containing only the latest measurement result to the O-DU. This operation can be referred to as (Method B). The existing O-DU cannot interpret a notification containing multiple measurement results. Therefore, when (Method A) is used, the existing O-DU can be prevented from receiving a list containing multiple measurement results. Also, when (Method A) is used, the O-RU (e.g., a new O-RU) can be prevented from transmitting multiple measurement results using one notification. This operation can be particularly useful when transmitting measurement results to an existing O-DU that cannot interpret a notification containing multiple measurement results. (Method B) can also be useful when the O-DU (e.g., an existing O-DU or a new O-DU) wants to receive a notification containing only some measurement results in order to reduce the processing load of the communication system.

[0186] Even if the O-RU can transmit one notification containing multiple measurement results, the O-DU can limit the number of measurement results included in the notification to 1 to reduce the measurement result processing burden. For example, the O-DU can set enable-multiple-stats-in-notification to FALSE. In this case, the O-RU can transmit a notification containing only one measurement result (e.g., the latest measurement result) among multiple measurement results even if the notification interval is longer than the measurement interval.

[0187] When the default value of 'enable-multiple-stats-in-notification' is defined as FALSE and a new O-RU and an existing O-DU are operating, enable-multiple-stats-in-notification is always FALSE, so the new O-RU can transmit one measurement result (e.g., the latest measurement result) to the existing O-DU even if the notification interval is set longer than the measurement interval. When the default value of 'enable-multiple-stats-in-notification' is defined as FALSE and a new O-RU and a new O-DU are operating, both one notification containing one measurement result and one notification containing multiple measurement results can be used.

[0188] The new O-DU can set enable-multiple-stats-in-notification of the new O-RU to FALSE. In this case, the new O-RU can transmit one measurement result to the new O-DU using a leaf that supports the transmission of one measurement result. Or, the new O-RU can transmit a measurement result list containing one measurement result to the new O-DU. The new O-RU can use a leaf that supports the transmission of one measurement result to transmit a notification to the existing O-DU.

[0189] The YANG model of the O-RU can display the O-RAN M-Plane version supported by the O-RU. Therefore, the O-DU can determine whether the O-RU supports the transmission function of one notification containing multiple measurement results (i.e., the multi-measurement result reporting function) based on the O-RAN M-Plane version supported by the O-RU.

[0190] As another way to limit the number of measurement results included in a notification to reduce the measurement result processing burden, max-number-of-measurement-result-per-notification can be configured, which indicates the maximum number of measurement results included in one notification. That is, max-number-of-measurement-result-per-notification can be added to the YANG model. The O-DU can configure max-number-of-measurement-result-per-notification to the O-RU. The O-RU can transmit one notification to the O-DU containing measurement results up to the maximum number indicated by max-number-of-measurement-result-per-notification.

[0191] When method a, method b, method c, and / or method d are used, backward compatibility can be ensured and interoperability with equipment that does not support multiple measurement result notification can be ensured. When method a, method b, method c, and / or method d are used, the O-RU may not know whether a notification containing multiple measurement results can be decoded by the O-DU.

[0192] If the O-DU supports a version earlier than O-RAN M-Plane 7.0, if the O-DU that supports O-RAN M-Plane 7.0 does not support the multiple measurement result decoding function, or if the O-DU that supports O-RAN M-Plane 7.0 does not use the multiple measurement result decoding function, when the O-RU transmits one notification containing multiple measurement results, the multiple measurement results may not be decoded by the O-DU. Also, the O-DU may not know whether the O-RU supports the multiple measurement result reporting function. If the notification interval for an O-RU that does not support the multiple measurement result reporting function is set longer than the measurement interval, the O-DU may not receive some measurement results from the O-RU.

[0193] To solve the above problem, the O-RU can notify the O-DU of a capability indicating whether it supports the multi-measurement result reporting function. The above-mentioned capability-related parameters can be notified to the O-DU via the M-Plane. The O-DU can check whether the O-RU supports the multi-measurement result reporting function based on the O-RU's capability-related parameters. If the O-RU supports the multi-measurement result reporting function, the O-DU can instruct the O-RU to enable the multi-measurement result reporting function. If the multi-measurement result reporting function is explicitly enabled, the O-RU can send one notification containing multiple measurement results to the O-DU. The above operation can be referred to as (Method I). To support (Method I), the existing o-ran-performance-management.yang module can be extended as follows:

[0194] +--rw transceiver-measurement-interval? uint16 +--rw epe-measurement-interval? uint16 +--rw rx-window-measurement-interval? uint16 +--rw tx-measurement-interval? uint16 +--rw notification-interval? uint16 +--rw file-upload-interval? uint16 +--ro max-bin-count uint16 +--ro multiple-stats-in-notification-capable? boolean +--rw enable-multiple-stats-in-notification? boolean

[0195] That is, "ro multiple-stats-in-notification-capable" and "rw enable-multiple-stats-in-notification" can be added to the YANG model. The extended YANG code by (Method I) can be defined as follows:

[0196] module:o-ran-performance-management ...(omission)... leaf max-bin-count{ type uint16; config false; mandatory true; description “indicates the maximum value of configurable bin-count for frequency table in transceiver-measurement-objects as one of module capabilities.”; } leaf multiple-stats-in-notification-capable{ type boolean; config false; default false; description “Flag to indicate whether the O-RU is capable of sending a notification including multiple stats when notification-interval is larger than measurement-interval.”; } leaf enable-multiple-stats-in-notification { type boolean; default false; description ”Flag to enable multiple stats to be included in one notification when notification-interval is larger than measurement-interval and 'multiple-stats-in-notification-capable' is true.”; }

[0197] multiple-stats-in-notification-capable may be a capability that indicates whether the O-RU supports multiple measurement result reporting functionality when the notification interval is longer than the measurement interval. The default value of multiple-stats-in-notification-capable may be false.

[0198] enable-multiple-stats-in-notification can be set by the O-DU. If multiple-stats-in-notification-capable of an O-RU is set to true, the O-DU can set enable-multiple-stats-in-notification to true. In this case, if the notification interval is longer than the measurement interval, the O-RU can send one notification containing multiple measurement results to the O-DU. The default value of enable-multiple-stats-in-notification can be false.

[0199] The O-DU can decode multiple measurement results included in one notification, and the O-RU may not support the multiple measurement result reporting function. That is, the O-DU may be a new O-DU, and the O-RU may be an existing O-RU. In this case, the O-RU's YANG parameter multiple-stats-in-notification-capable may not exist. That is, because multiple-stats-in-notification-capable is set to the default value (i.e., false), the O-DU can determine that the O-RU cannot support the multiple measurement result reporting function. In this case, the O-DU can configure the O-RU's parameter(s) so that the multiple measurement result reporting function is not used or the notification interval is not longer than the measurement interval. The new O-RU may also not support the multiple measurement result reporting function. In this case, the O-RU can set multiple-stats-in-notification-capable to false. If the new O-RU's multiple-stats-in-notification-capable is set to false, the O-DU may not use the multiple measurement result reporting function. Alternatively, the O-DU can configure the parameters of the O-RU so that the notification interval is not longer than the measurement interval.

[0200] If the O-RU supports the multiple measurement result reporting function and the O-DU cannot support the multiple measurement result reporting function, the O-DU may not set enable-multiple-stats-in-notification in the O-RU to true, and therefore the O-RU may not send one notification containing multiple measurement results to the O-DU.

[0201] An existing O-DU that cannot interpret enable-multiple-stats-in-notification may not configure enable-multiple-stats-in-notification. In this case, enable-multiple-stats-in-notification may be set to the default value (i.e., false). Therefore, the O-RU may not transmit a single notification containing multiple measurement results to the O-DU.

[0202] As a variation of the above method, a new O-RU (e.g., an O-RU supporting O-RAN M-Plane version 7.0, or an O-RU supporting O-RAN M-Plane version 7.0 or later) can always support the multiple measurement result reporting function. This operation can be referred to as (Method II). In this case, multiple-stats-in-notification-capable does not need to be used. The O-DU can confirm that the O-RU is an existing O-RU based on the O-RAN M-Plane version information in the YANG model. If the O-DU confirms that the O-RU is an existing O-RU, it can set the measurement interval and notification interval for the existing O-RU to be the same. If the O-RU is confirmed to be a new O-RU, the new O-RU can transmit multiple measurement lists, so the O-DU can set the measurement interval and notification interval for the new O-RU differently.

[0203] If the notification interval is set longer than the measurement interval, the existing O-RU can transmit one notification containing the latest measurement result to the O-DU. In this case, multiple-stats-in-notification-capable is not required, so only enable-multiple-stats-in-notification can be added to the YANG model. The default value of enable-multiple-stats-in-notification can be set to false. If the O-DU sets enable-multiple-stats-in-notification to true and the notification interval for the O-RU is longer than the measurement interval, the O-RU can transmit one notification containing multiple measurement results to the O-DU.

[0204] As in (Method B), to reduce the processing burden of measurement results, the O-DU can limit the number of measurement results included in one notification to one. enable-multiple-stats-in-notification can be set to false, and the O-RU can transmit a notification containing the latest measurement result among multiple measurement results to the O-DU even if the notification interval is longer than the measurement interval. When the default value of enable-multiple-stats-in-notification is set to false and a new O-RU and an existing O-DU are operating, the value of enable-multiple-stats-in-notification of the O-RU is always false, so the new O-RU can transmit one measurement result (e.g., the latest measurement result) among multiple measurement results to the O-DU if the notification interval is longer than the measurement interval.

[0205] When a new O-RU and a new O-DU are operating, both one notification containing one measurement result and one notification containing multiple measurement results can be used. If the new O-DU sets enable-multiple-stats-in-notification of the new O-RU to false, the new O-RU can transmit one measurement result using an existing leaf that supports the transmission of one measurement result or an additional measurement result list. The new O-RU can transmit one measurement result to the existing O-DU using an existing leaf that supports the transmission of one measurement result.

[0206] The above-mentioned (Method II) can also be used when a new O-RU optionally supports the multiple measurement result reporting function. This operation can be referred to as (Method III). In this case, multiple-stats-in-notification-capable does not need to be added to the YANG model. enable-multiple-stats-in-notification can be added to the YANG model. If the O-DU sets enable-multiple-stats-in-notification to true, if the O-RU does not support the multiple measurement result reporting function, or if the O-RU does not use the multiple measurement result reporting function, the O-RU can transmit one measurement result to the O-DU using an existing leaf that supports the transmission of one measurement result. The remaining operations can be the same as those described above (Method II).

[0207] A new O-RU can optionally support multiple measurement lists, and neither multiple-stats-in-notification-capable nor enable-multiple-stats-in-notification need be added to the YANG model. This behavior can be referred to as (Method IV). An O-RU that supports the multiple measurement result reporting function can generate measurement result lists containing multiple measurement results and transmit notifications containing the measurement result lists. An O-RU that does not support the multiple measurement result reporting function can transmit one measurement result to the O-DU using an existing leaf that supports the transmission of one measurement result.

[0208] When method a, method b, and / or method d is used, an existing leaf containing one measurement result may be transmitted along with a measurement result list(s) containing multiple measurement results. An existing O-DU (e.g., an O-DU supporting a previous YANG model) may not be able to decode the measurement result list(s) included in the notification and may ignore the new leaf (e.g., the measurement result list(s)). Therefore, no errors may occur in the existing O-DU.

[0209] (others) When an existing O-DU and a new O-RU are operating and the existing O-DU sets the measurement interval for the new O-RU to be the same as the notification interval, the existing O-DU can be prevented from receiving a single notification containing multiple measurement results from the new O-RU. Since one measurement result occurs in one notification interval, the new O-RU can transmit one notification containing one measurement result using the existing method. When this method is used, multiple-stats-in-notification-capable and enable-multiple-stats-in-notification do not need to be used. If one measurement result is transmitted using the existing leaf instead of an additional measurement result list, the existing O-DU can always decode the measurement result. Therefore, no backward compatibility issues occur. The above operation can be useful in method c.

[0210] When method c is used, the existing O-DU can set the measurement interval and notification interval to be the same. In this case, only one measurement result can occur in one notification interval. The O-RU can transmit one measurement result to the existing O-DU using an existing leaf that supports transmission of one measurement result. The existing O-DU can decode the measurement result received from the O-RU. The new O-DU can set the notification interval longer than the measurement interval. In this case, multiple measurement results can occur in one notification interval. The O-RU can generate a measurement result list containing multiple measurement results and transmit a notification including the measurement result list to the new O-DU. The new O-DU can decode the measurement result list received from the O-RU. In other words, if the notification interval is longer than the measurement interval, the multiple measurement result reporting function can be enabled. If the notification interval is not longer than the measurement interval, the multiple measurement result reporting function can be disabled.

[0211] In method a, method b, and / or method d, the notification can always include an existing leaf that supports the transmission of one measurement result. Therefore, the existing O-DU can decode the notification received from the O-RU, so there is no backward compatibility issue.

[0212] According to the above method(s), backward compatibility can be ensured and interoperability with equipment that does not support the multi-measurement result reporting function can be ensured.

[0213] To prevent the transmission of a single notification containing multiple measurement results, separate notification interval parameters may be used for each measurement object. The notification interval may be set for each measurement object. The notification intervals for the measurement objects may be set differently. For example, the transceiver-notification-interval, rx-window-notification-interval, tx-stats-notification-interval, epe-stats-notification-interval, and / or rssi-stats-notification-interval parameters may be set separately for each measurement object. Even if the measurement intervals for the measurement objects are different, the notification interval for each measurement object may be set so that it is not longer than the measurement interval for the corresponding measurement object. This method may prevent the transmission of a single notification containing multiple measurement results.

[0214] Various measurement objects may be introduced in O-RAN, and the multi-measurement result reporting function for new measurement objects may be applied by the above-mentioned method(s). For example, reporting for an RSSI object (e.g., a Time Domain RSSI object) may be defined as follows:

[0215] notification ...(omission)... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min | +--ro value? int16 +--ro max | +--ro value? int16 +--ro avg | +--ro value? int16 +--ro frequency-table* uint32 ...(omission)...

[0216] A single notification containing a single measurement result as described above can be extended in the same manner as in the method(s) described above. That is, a single notification can be extended to include multiple measurements. For example, applying the first method in Method A, a YANG model can be defined as follows:

[0217] notifications: +---n measurement-result-stats ... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min | +--ro value? int16 +--ro max | +--ro value? int16 +--ro avg | +--ro value? int16 +--ro frequency-table* uint32 +--ro number-of-additional-measurement-result? uint8 +--ro additional-symbol-rssi-measurement-result* [seq-number] +--ro seq-number uint8 +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min +--ro value? int16 +--ro max +--ro value? int16 +--ro avg +--ro value? int16 +--ro frequency-table* uint32

[0218] Applying the second method of Method A, the YANG model can be defined as follows:

[0219] notifications: +---n measurement-result-stats ... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min | +--ro value? int16 +--ro max | +--ro value? int16 +--ro avg | +--ro value? int16 +--ro frequency-table* uint32 +--ro additional-symbol-rssi-measurement-result* [start-time end-time] +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min +--ro value? int16 +--ro max +--ro value? int16 +--ro avg +--ro value? int16 +--ro frequency-table* uint32

[0220] Applying the third method of Method A, the YANG model can be defined as follows:

[0221] notifications: +---n measurement-result-stats ... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min | +--ro value? int16 +--ro max | +--ro value? int16 +--ro avg | +--ro value? int16 +--ro frequency-table* uint32 +--ro additional-symbol-rssi-measurement-result* [] +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min +--ro value? int16 +--ro max +--ro value? int16 +--ro avg +--ro value? int16 +--ro frequency-table* uint32

[0222] Applying the first method of Method B, the YANG model can be defined as follows:

[0223] notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] ... +--ro rx-window-stats* [measurement-object] ... +--ro tx-stats* [measurement-object] ... +--ro epe-statistics* [measurement-object] ... +--ro symbol-rssi-stats* [measurement-object] ... +--ro number-of-additional-measurement-result-stats? uint8 +--ro additional-measurement-result-stats* [seq-number] +--ro seq-number uint8 +--ro transceiver-stats* [measurement-object] ... +--ro rx-window-stats* [measurement-object] ... +--ro tx-stats* [measurement-object] ... +--ro epe-statistics* [measurement-object] ... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min +--ro value? int16 +--ro max +--ro value? int16 +--ro avg +--ro value? int16 +--ro frequency-table* uint32

[0224] Applying the second method of Method B, the YANG model can be defined as follows:

[0225] notifications: +---n measurement-result-stats +--ro transceiver-stats* [measurement-object] ... +--ro rx-window-stats* [measurement-object] ... +--ro tx-stats* [measurement-object] ... +--ro epe-statistics* [measurement-object] ... +--ro symbol-rssi-stats* [measurement-object] .. +--ro additional-measurement-result-stats* [] +--ro transceiver-stats* [measurement-object] ... +--ro rx-window-stats* [measurement-object] ... +--ro tx-stats* [measurement-object] ... +--ro epe-statistics* [measurement-object] ... +--ro symbol-rssi-stats* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro symbol-rssi-measurement-result* [object-unit-id] +--ro object-unit-id-> / up:user-plane-configuration / rx-array-carriers / name +--ro per-symbol-index-result* [symbol-index] +--ro symbol-index uint16 +--ro min +--ro value? int16 +--ro max +--ro value? int16 +--ro avg +--ro value? int16 +--ro frequency-table* uint32

[0226] <How to send a separate notification containing multiple measurement results> The O-RU may transmit a separate notification containing multiple measurement results without adding additional-xxxx-measurement-result to the existing notification.

[0227] In method c of the third method of [Method A], a separate notification including additional-xxxx-measurement-result can be transmitted. The YANG model for this operation can be defined as follows:

[0228] module:o-ran-performance-management ...(omission)... notifications: +---n measurement-result-stats | +--ro transceiver-stats* [measurement-object] | | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | | +--ro start-time? yang-types:date-and-time | | +--ro end-time? yang-types:date-and-time | | +--ro transceiver-measurement-result* [object-unit-id] | | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | | +--ro min | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro max | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro first | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro latest | | | +--ro value? decimal64 | | | +--ro time? yang-types:date-and-time | | +--ro frequeny-table* uint32 | +--ro rx-window-stats* [measurement-object] | | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | | +--ro start-time? yang-types:date-and-time | | +--ro end-time? yang-types:date-and-time | | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro data-direction? enumeration | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | +--ro tx-stats* [measurement-object] | | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | | +--ro start-time? yang-types:date-and-time | | +--ro end-time? yang-types:date-and-time | | +--ro(object-unit-id)? | | +--:(RU) | | | +--ro name?-> / hw:hardware / component / name | | | +--ro count uint64 | | +--:(TRANSPORT) | | | +--ro tr-measured-result* [] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | | +--ro count uint64 | | +--:(EAXC_ID) | | +--ro eaxc-measured-result* [] | | +--ro eaxc-id? uint16 | | +--ro count uint64 | | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name | x--ro epe-stats | | +--ro start-time? yang-types:date-and-time | | +--ro end-time? yang-types:date-and-time | | +--ro epe-measurement-result* [object-unit-id] | | +--ro object-unit-id-> / hw:hardware / component / class | | +--ro min? decimal64 | | +--ro max? decimal64 | | +--ro average? decimal64 | +--ro epe-statistics* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro epe-measurement-result* [object-unit-id] | +--ro object-unit-id-> / hw:hardware / component / class | +--ro min? decimal64 | +--ro max? decimal64 | +--ro average? decimal64 +---n multiple-measurement-result-stats +--ro multiple-transceiver-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / transceiver-measurement-objects / measurement-object | +--ro additional-transceiver-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro transceiver-measurement-result* [object-unit-id] | +--ro object-unit-id-> / if:interfaces / interface / o-ran-int:port-reference / port-number | +--ro min | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro max | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro first | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro latest | | +--ro value? decimal64 | | +--ro time? yang-types:date-and-time | +--ro frequeny-table* uint32 +--ro multiple-rx-window-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / rx-window-measurement-objects / measurement-object | +--ro additional-rx-window-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro data-direction? enumeration | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro multiple-tx-stats* [measurement-object] | +--ro measurement-object-> / performance-measurement-objects / tx-measurement-objects / measurement-object | +--ro additional-tx-measurement-result* [] | +--ro start-time? yang-types:date-and-time | +--ro end-time? yang-types:date-and-time | +--ro(object-unit-id)? | +--:(RU) | | +--ro name?-> / hw:hardware / component / name | | +--ro count uint64 | +--:(TRANSPORT) | | +--ro tr-measured-result* [] | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name | | +--ro count uint64 | +--:(EAXC_ID) | +--ro eaxc-measured-result* [] | +--ro eaxc-id? uint16 | +--ro count uint64 | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name +--ro multiple-epe-statistics* [measurement-object] +--ro measurement-object-> / performance-measurement-objects / epe-measurement-objects / measurement-object +--ro additional-epe-measurement-result* [] +--ro start-time? yang-types:date-and-time +--ro end-time? yang-types:date-and-time +--ro epe-measurement-result* [object-unit-id] +--ro object-unit-id-> / hw:hardware / component / class +--ro min? decimal64 +--ro max? decimal64 +--ro average? decimal64

[0229] The result-stats notification that transmits one measurement result can be used without modification, and the multiple-measurement-result-stats notification that transmits multiple measurement results can be newly defined. The O-RU can generate additional-XXXX-measurement-result[] containing multiple measurement results and transmit additional-XXXX-measurement-result[]. The remaining matters can be the same as [Method A], except that the part for transmitting multiple measurement results is defined in a separate notification.

[0230] The above embodiment may be a modified version of Method c of [Method A], and separate notifications may be used. The O-RU can transmit one measurement result to the existing O-DU using the existing measurement-result-stats notification, which includes a leaf (e.g., start-time, end-time, and XXXX-measurement-result[]) that supports the transmission of one measurement result, and can transmit a new multiple-measurement-result-stats, which includes all of the multiple measurement results, to the new O-DU. The multiple-measurement-result-stats can include additional-XXXX-measurement-result[], which can include multiple measurement results. All measurement results (e.g., from the first measurement result to the last measurement result) can be sorted chronologically within additional-XXXX-measurement-result[].

[0231] The existing measurement-result-stats notification transmitted to the existing O-DU can include one measurement result per measurement object. In this case, the existing O-DU can set the measurement interval and notification interval of the O-RU to be the same so that one measurement result is generated per notification interval. Alternatively, if the existing O-DU sets the notification interval longer than the measurement interval, the O-RU can transmit the existing measurement-result-stats notification including the latest measurement result to the O-DU. Detailed methods for the above operations are described in <Method for ensuring backward compatibility and interoperability with equipment that does not support multi-measurement result reporting function>.

[0232] When Method A, Method B, and / or Method D of [Method A] are used, the existing leaf and the new list can be transmitted in separate notifications, as in the above-mentioned methods. That is, in Method A, Method B, and / or Method D of [Method A], one measurement result can be transmitted using the existing measurement-result-stats notification (i.e., the existing leaf), and multiple measurement results can be transmitted using the multiple-measurement-result-stats notification (i.e., the new list).

[0233] If the O-RU's multiple-stats-in-notification-capable is false, the O-DU can only check the measurement-result-stats notification containing one measurement result (i.e., an existing notification). If the O-RU's multiple-stats-in-notification-capable is true, the O-DU can set enable-multiple-stats-in-notification to true and receive a multiple-measurement-result-stats notification containing multiple measurement results (i.e., a new notification). Even if the O-RU supports the multiple measurement result reporting function, the O-DU can set enable-multiple-stats-in-notification to false to reduce the burden on the O-DU. In this case, the O-RU can transmit a measurement-result-stats notification containing one measurement result to the O-DU, and the O-DU can receive a measurement-result-stats notification containing one measurement result from the O-RU. Alternatively, the O-DU may receive a multiple-measurement-result-stats notification containing one measurement result and obtain only one measurement result from the multiple-measurement-result-stats notification.

[0234] If the O-RU does not use the YANG model multiple-stats-in-notification-capable, the O-DU can subscribe to both the measurement-result-stats notification and the multiple-measurement-result-stats notification. In this case, if the O-RU transmits a notification containing multiple measurement results, the O-DU can receive the multiple-measurement-result-stats notification from the O-RU. If the O-RU transmits an existing notification containing one measurement result, the O-DU can receive the existing measurement-result-stats notification from the O-RU.

[0235] The existing O-DU may not support the multiple measurement result reporting function and can only subscribe to the existing measurement-result-stats. In this case, if the default value of enable-multiple-stats-in-notification is set to false, the existing O-DU does not need to configure enable-multiple-stats-in-notification separately. Therefore, the O-RU can transmit the existing measurement-result-stats notification containing one measurement result to the existing O-DU.

[0236] A new O-RU can optionally support multiple-measurement-result-stats notification, and both multiple-stats-in-notification-capable and enable-multiple-stats-in-notification may not be added to the YANG model. An O-RU can support multiple measurement result reporting capability, and an O-DU can subscribe to the multiple-measurement-result-stats notification. In this case, the O-DU can receive one notification containing multiple measurement results.

[0237] If the O-RU does not support the multiple-measurement-result-stats notification, the O-DU can receive a notification containing one measurement result by subscribing to the existing measurement-result-stats notification. In this case, the O-DU must subscribe to both the existing measurement-result-stats notification and the new multiple-measurement-result-stats notification because it does not know the O-RU's capability related to multiple measurement results. The existing O-DU may not be able to receive the multiple-measurement-result-stats notification from the O-RU because it cannot subscribe to the new multiple-measurement-result-stats notification. This does not cause an error.

[0238] When an existing O-DU and a new O-RU are operating and the existing O-DU sets the measurement interval and notification interval of the new O-RU to be the same, the existing O-DU can be prevented from receiving a single notification containing multiple measurement results (e.g., a multiple-measurement-result-stats notification) from the new O-RU. That is, since one measurement result occurs in one notification interval, the new O-RU can transmit the existing measurement-result-stats notification containing one measurement result. When the above-mentioned method is used, multiple-stats-in-notification-capable and enable-multiple-stats-in-notification do not need to be used. The above-mentioned operation can be useful in method c.

[0239] When method c is used, the existing O-DU can set the measurement interval and the notification interval to be the same so that one measurement result occurs in one notification interval. In this case, the O-RU can transmit an existing leaf (e.g., through a measurement-result-stats notification) containing one measurement result. The existing O-DU can decode one measurement result included in the leaf included in the existing notification received from the O-RU. The new O-DU can set the notification interval longer than the measurement interval. In this case, if multiple measurement results occur in one notification interval, the O-RU can transmit a new list (e.g., through a new multiple-measurement-result-stats notification) containing multiple measurement results to the new O-DU. The new O-DU can decode multiple measurement results included in the new list included in the multiple-measurement-result-stats notification received from the O-RU. That is, if the notification interval is longer than the measurement interval, the multiple measurement result reporting function can be enabled. If the notification interval is not longer than the measurement interval, the multiple measurement result reporting function can be disabled.

[0240] In method a, method b, and / or method d, an existing leaf containing one measurement result can be transmitted. Therefore, existing O-DUs can decode the existing leaf, so no backward compatibility issues occur. If one measurement result exists, the existing measurement-result-stats notification can be used. In this case, both the existing O-DU and the new O-DU can decode the measurement result. If multiple measurement results exist, the existing measurement-result-stats notification and the new multiple-measurement-result-stats notification can all be transmitted. In this case, the existing O-DU can obtain one measurement result by receiving the existing measurement-result-stats notification, and the new O-DU can obtain multiple measurement results by receiving the new multiple-measurement-result-stats notification.

[0241] Even if one measurement result exists in method d, the existing measurement-result-stats notification containing the one measurement result and the new multiple-measurement-result-stats notification containing the one measurement result can both be transmitted. That is, the same measurement result can be included in the existing measurement-result-stats notification and the new multiple-measurement-result-stats notification.

[0242] The modified YANG code for the above method(s) can be defined as follows:

[0243] grouping multiple-measurement-notification { description ”notification may contain multiple-measurement result for transceiver-stats and / or rx-window-stats and / or tx-stats and / or epe-stats”; list multiple-transceiver-stats { key “measurement-object”; description ”multiple measurement result of transceiver-measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / transceiver-measurement-objects / measurement-object”; } description ”measurement-object for the transceiver-measurement”; } list additional-transceiver-measurement-result { config false; description ”additional measurement result of transceiver-measurement when notification-interval is larger than measurement-interval”; uses start-and-end-time; uses transceiver-measurement-result-grouping; } } list multiple-rx-window-stats { key “measurement-object”; description ”multiple measurement result for the reception window measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / rx-window-measurement-objects / measurement-object”; } description ”measurement-object for the reception window measurement”; } list additional-rx-window-measurement-result { config false; description ”additional measurement result of rx-window-measurement when notification-interval is larger than measurement-interval”; uses start-and-end-time; uses rx-window-measurement-result-grouping; } } list multiple-tx-stats { key “measurement-object”; description ”multiple measurement result for the tx stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / tx-measurement-objects / measurement-object”; } description ”measurement-object for the tx stats measurement”; } list additional-tx-measurement-result { config false; description ”additional measurement result of tx-measurement when notification-interval is larger than measurement-interval”; uses start-and-end-time; uses tx-measurement-result-grouping; } } list multiple-epe-statistics { key “measurement-object”; description ”measurement result for the epe stats measurement per measurement-object”; leaf measurement-object { type leafref { path “ / performance-measurement-objects / epe-measurement-objects / measurement-object”; } description ”measurement-object for the epe stats measurement”; } list additional-epe-measurement-result { config false; description ”additional measurement result of epe-measurement when notification-interval is larger than measurement-interval”; uses start-and-end-time; uses epe-measurement-result-grouping; } } } / / Top level container container performance-measurement-objects { description ”configuration for performance management and measurement-result are included”; uses measurement-group; } / / Notifications notification measurement-result-stats { description “Notification may contain measurement results for transceiver-stats and / or rx-window-stats”; uses measurement-notification; } notification multiple-measurement-result-stats { description “Notification may contain multiple measurement results for transceiver-stats and / or rx-window-stats”; uses multiple-measurement-notification; } }

[0244] The above method does not cause backward compatibility issues with existing equipment (e.g., O-DU, O-RU). Multiple measurement results for each measurement target can be transmitted using a single NETCONF notification transmission procedure. This improves the performance of the O-RAN M-Plane.

[0245] The methods according to the present invention may be embodied in the form of program instructions that can be executed by various computer means and stored on a computer-readable medium. The computer-readable medium may include, alone or in combination with other program instructions, data files, data structures, and the like. The program instructions stored on the computer-readable medium may be those specially designed and constructed for the present invention, or they may be readily available to those skilled in the art of computer software.

[0246] Examples of computer-readable media include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include not only machine code, such as produced by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc. The aforementioned hardware devices may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa.

[0247] Although the present invention has been described with reference to the preferred embodiments, it will be understood by those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. A method of operating an O-RAN radio unit (O-RU) in an O-RAN (open-radio access network), comprising: generating a plurality of first measurement results by performing a measurement operation on a first measurement object in one notification section according to the notification interval; generating a first measurement result list including the plurality of first measurement results; generating a first notification including a most recent measurement result of the plurality of first measurements; generating a plurality of second measurement results by performing a measurement operation on a second measurement object in the one notification period; generating a second measurement result list including the plurality of second measurement results; and transmitting a message including the first measurement result list and the first notification regarding the first measurement object and the second measurement result list regarding the second measurement object to an O-RAN distributed unit (O-DU); A method of operating an O-RU, comprising:

2. The operation method of the O-RU is as follows: setting the latest measurement result among the plurality of first measurement results as an existing measurement result decoded by an existing O-DU supporting a version earlier than the specific version; further comprising setting the existing measurement results is performed before generating the first notification, and the latest measurement results and the existing measurement results include the same measurement results. A method for operating an O-RU according to claim 1.

3. The first measurement result list is decoded by an O-DU supporting a version of the O-RAN after a specific version, and the first notification is decoded by an existing O-DU supporting a version before the specific version. A method for operating an O-RU according to claim 1.

4. The message further includes a second notification including the latest measurement result of the plurality of second measurement results. A method for operating an O-RU according to claim 1.

5. the first measurement result list further includes measurement start time information and measurement end time information for each of the plurality of first measurement results; A method for operating an O-RU according to claim 1.

6. the plurality of first measurement results are arranged in the first measurement result list in ascending order of measurement time; A method for operating an O-RU according to claim 1.

7. the first measurement result list further includes at least one of information indicating the number of the plurality of first measurement results and sequence numbers of each of the plurality of first measurement results; A method for operating an O-RU according to claim 1.

8. the notification interval is set by the O-DU to be longer than the measurement interval during which one measurement operation is performed; A method for operating an O-RU according to claim 1.

9. The first measurement object is a transceiver, a reception window (rx-window), a transmission measurement (tx-measurement), EPE (Energy, Power, Environment), or a symbol RSSI (Symbol Received Signal Strength Indicator); A method for operating an O-RU according to claim 1.

10. A method of operating an O-RAN radio unit (O-RU) in an O-RAN (open-radio access network), comprising: generating a first measurement result by performing a measurement operation on a first measurement object in one notification section according to the notification interval; generating a first notification including the first measurement; generating a first measurement result list including the first measurement result; generating a second measurement result by performing a measurement operation on a second measurement object in the one notification period; generating a second measurement result list including the second measurement results; and transmitting a message including the first notification and the first measurement result list regarding the first measurement object and the second notification and the second measurement result list regarding the second measurement object to an O-RAN distributed unit (O-DU); wherein the first measurement result is the most recent measurement result. A method of operation of the O-RU.

11. The operation method of the O-RU is as follows: Setting the first measurement result as an existing measurement result decoded in an existing O-DU supporting a version earlier than the specific version. further comprising and configuring the existing measurement result is performed before generating the first notification, and the first measurement result, the existing measurement result, and the latest measurement result comprise the same measurement result. The method for operating an O-RU according to claim 10.

12. The first measurement result list is decoded by an O-DU supporting a version of the O-RAN after a specific version, and the first notification is decoded by an existing O-DU supporting a version before the specific version. The method for operating an O-RU according to claim 10.

13. The notification interval is set by the O-DU to be the same as the measurement interval during which one measurement operation is performed. The method for operating an O-RU according to claim 10.

14. 1. A method of operating an O-RAN distributed unit (O-DU) in an open-radio access network (O-RAN), comprising: setting notification intervals and measurement intervals for an O-RAN radio unit (O-RU); receiving from the O-RU a message including a first measurement result list including a plurality of first measurement results for a first measurement object, a first notification including a latest measurement result of the plurality of first measurement results, and a second measurement result list including a plurality of second measurement results for a second measurement object; and identifying the plurality of first measurement results by decoding the first measurement result list; Including, The plurality of first measurement results are measured in one notification interval according to the notification interval. How the O-DU works.

15. The first measurement result list is decoded by an O-DU supporting a version of the O-RAN after a specific version, and the first notification is decoded by an O-DU supporting a version earlier than the specific version. A method for operating an O-DU according to claim 14.

16. the first measurement result list further includes measurement start time information and measurement end time information for each of the plurality of first measurement results; A method for operating an O-DU according to claim 14.

17. The method of claim 14, wherein the plurality of first measurement results are arranged in the first measurement result list in ascending order of measurement time.

18. the first measurement result list further includes at least one of information indicating the number of the plurality of first measurement results and sequence numbers of each of the plurality of first measurement results; A method for operating an O-DU according to claim 14.

19. The first measurement object is a transceiver, a receiving window (rx-window), a transmission measurement (tx-measurement), an EPE (Energy, Power, Environment), or a symbol RSSI (Received Signal Strength Indicator); A method for operating an O-DU according to claim 14.

20. The message further includes a second notification including the latest measurement result of the plurality of second measurement results. A method for operating an O-DU according to claim 14.

Images