Method and apparatus for communicating using a fronthaul interface

Abstract

A method and apparatus for communicating using a fronthaul interface are disclosed. According to the present invention, an operating method of an O-RU includes the steps of generating a plurality of first measurement results by performing a measurement operation 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; and transmitting a message including the first measurement result list to an O-DU.

Description

Technical Field

[0001] This disclosure relates to a communication technology in a communication system including a fronthaul interface, and more specifically, to a technology for efficiently sending and receiving parameters for managing the performance of the communication system. Background Technology

[0002] With the development of information and communication technologies, various wireless communication technologies have been developed. Typical wireless communication technologies include Long Term Evolution (LTE) and New Radio (NR) as defined in the 3rd Generation Partnership Project (3GPP) standards. LTE can be one of the fourth-generation (4G) wireless communication technologies, and NR can be one of the fifth-generation (5G) wireless communication technologies.

[0003] 5G communication systems (e.g., NR-enabled systems) are being considered to utilize frequency bands higher than those of 4G systems (e.g., 6 GHz or lower) to handle the rapidly growing wireless data volume following the commercialization of 4G systems (e.g., LTE-enabled systems). 5G communication systems can support enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), massive machine-type communication (mMTC), and more.

[0004] Additionally, the Open Radio Access Network (O-RAN) Alliance specifies a fronthaul interface. The fronthaul interface can be the interface between the O-RAN Distributed Unit (O-DU) and the O-RAN Radio Unit (O-RU) constituting a base station (e.g., eNB or gNB). An O-DU can be referred to as a Lower Layer Segmented Central Unit (LLS-CU), and an O-RU can be referred to as a Lower Layer Segmented Distributed Unit (LLS-DU). LLS-CU and LLS-DU can be terms used in 3GPP. Methods for performance management of communication systems including the fronthaul interface may be required. Specifically, for the M-plane functions of O-RAN, methods for transmitting and receiving various parameters for performance management between the O-RU and O-DU may be needed. Summary of the Invention

[0005] The purpose of this disclosure in order to solve the above problems is to provide a method and apparatus for transmitting and receiving parameters for managing performance in a communication system including a fronthaul interface.

[0006] Technical solutions

[0007] According to a first exemplary embodiment of the present disclosure for achieving this purpose, an O-RU operation method may include: generating a plurality of first measurement results by performing a measurement operation on a first measurement object in a notification period according to a notification interval; generating a first measurement result list including the plurality of first measurement results; and sending a message including the first measurement result list to an O-RAN distributed unit (O-DU).

[0008] The operation method may further include: generating a first notification that includes the most recent measurement result among the plurality of first measurement results, wherein the message further includes the first notification.

[0009] The first list of measurement results can be decoded by an O-DU that supports a specific version of O-RAN or later, and the first notification can be decoded by an O-DU that supports a version prior to the specific version.

[0010] The operation method may further include: generating multiple second measurement results by performing a measurement operation on the second measurement object during the notification period; and generating a second measurement result list including the multiple second measurement results, wherein the message further includes the second measurement result list.

[0011] The first measurement results list may also include information about the start time and end time of each of the plurality of first measurement results.

[0012] The multiple first measurement results can be arranged in ascending order of measurement time in the first measurement result list.

[0013] The first measurement results list may also include at least one of information indicating the number of the plurality of first measurement results and the sequence number of each of the plurality of first measurement results.

[0014] The notification interval can be set by the O-DU to be longer than the measurement interval for performing a measurement operation.

[0015] The first measurement object can be a transceiver, a receive window (rx-window), a transmit measurement (tx-measurement), an "Energy, Power, Environment (EPE)" symbol, or a symbolic Received Signal Strength Indicator (RSSI).

[0016] According to a second exemplary embodiment of the present disclosure for achieving this purpose, an O-RU operation method may include: generating a first measurement result by performing a measurement operation on a first measurement object in a notification period 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 sending a message including the first notification and the first measurement result list to an O-RAN distributed unit (O-DU).

[0017] The first list of measurement results can be decoded by an O-DU that supports a specific version of O-RAN or later, and the first notification can be decoded by an O-DU that supports a version prior to that specific version.

[0018] The notification interval can be set by the O-DU to be equal to the measurement interval for performing a measurement operation.

[0019] The operation method may further include: generating a second measurement result by performing a measurement operation on the second measurement object during the notification period; generating a second notification including the second measurement result; and generating a second measurement result list including the second measurement result, wherein the message further includes the second notification and the second measurement result list.

[0020] According to a third exemplary embodiment of the present disclosure for achieving this purpose, an O-DU operation method may include: setting a notification interval and a measurement interval for an O-RAN radio unit (O-RU); receiving from the O-RU a message including a first measurement result list, wherein the first measurement result list includes a plurality of first measurement results for a first measurement object; and identifying the plurality of first measurement results by means of the first measurement result list, wherein the plurality of first measurement results are measured in a notification period according to the notification interval.

[0021] The message may also include a first notification, wherein the first notification includes the most recent measurement result among the plurality of first measurement results.

[0022] The first list of measurement results can be decoded by an O-DU that supports a specific version of O-RAN or later, and the first notification can be decoded by an O-DU that supports a version prior to that specific version.

[0023] The first measurement results list may also include information about the start time and end time of each of the plurality of first measurement results.

[0024] The multiple first measurement results can be arranged in ascending order of measurement time in the first measurement result list.

[0025] The first measurement results list may also include at least one of information indicating the number of the plurality of first measurement results and the sequence number of each of the plurality of first measurement results.

[0026] The first measurement object can be a transceiver, a receive window (rx-window), a transmit measurement (tx-measurement), an energy, power, and environment (EPE) device, or a symbolic received signal strength indicator (RSSI).

[0027] Beneficial effects

[0028] According to this disclosure, various parameters for performance management can be efficiently sent / received between the O-RU and O-DU. Based on the YANG model defined in the M-plane of the O-RAN, multiple measurement results (e.g., multiple measurement results for corresponding measurement objects) can be sent using a single notification message. This operation can be performed without affecting the functionality of the existing M-plane. Therefore, the performance of communication systems including fronthaul interfaces can be improved. Attached Figure Description

[0029] Figure 1 This is a conceptual diagram illustrating a first exemplary embodiment of a communication system.

[0030] Figure 2 This is a block diagram illustrating a first exemplary embodiment of a communication node constituting a communication system.

[0031] Figure 3 This is a block diagram illustrating a first exemplary embodiment of a base station supporting Lower Layer Segmentation (LLS) in a communication system.

[0032] Figure 4 This is a block diagram illustrating a first exemplary embodiment of the interface structure between O-DU and O-RU in a communication system.

[0033] Figure 5a This is a block diagram illustrating a first exemplary embodiment of a layered M-surface model.

[0034] Figure 5b This is a block diagram illustrating a second exemplary embodiment of the hybrid M-surface model.

[0035] Figure 6 This is a block diagram illustrating a first exemplary embodiment of the protocol stack of the M-side.

[0036] Figure 7 This is a conceptual diagram illustrating a first exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0037] Figure 8This is a conceptual diagram illustrating a second exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0038] Figure 9 This is a conceptual diagram illustrating a third exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0039] Figure 10 This is a conceptual diagram illustrating a first exemplary embodiment of the structure for extended measurement results of the transceiver in the YANG model using method A.

[0040] Figure 11 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of extended measurement results for the receiving window in the YANG model using method A.

[0041] Figure 12 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of extended measurement results for EPE in the YANG model using method A.

[0042] Figure 13 This is a conceptual diagram illustrating a first exemplary embodiment of the structure for extended measurement results of transmitted measurements in the YANG model using method A.

[0043] Figure 14 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of the extended measurement results for the symbol RSSI in the YANG model using method A. Detailed Implementation

[0044] While this disclosure is readily adaptable to various modifications and alternatives, specific embodiments are illustrated and described in detail by way of example in the accompanying drawings. However, it should be understood that this description is not intended to limit the disclosure to the specific embodiments, but rather, the disclosure is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

[0045] Although the terms “first,” “second,” etc., may be used with reference to various elements herein, these elements should not be construed as being limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of this disclosure, a first element may be referred to as a second element, and a second element may be referred to as a first element. The term “and / or” includes any and all combinations of one or more of the associated listed items.

[0046] It should be understood that when an element is referred to as "connected" or "combined" to another element, it can be directly connected or combined to said other element, or there may be intermediate elements. Conversely, when an element is referred to as "directly connected" or "directly combined" to another element, there are no intermediate elements.

[0047] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that, when used herein, the terms “comprising,” “including,” “including,” and / or “containing” specify the presence of the stated features, integers, steps, operations, elements, components, and / or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0048] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms defined in common dictionaries shall be interpreted as having a meaning consistent with their meaning in the context of the relevant field and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0049] In the following description, preferred exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In describing the present disclosure, for ease of overall understanding, the same reference numerals will refer to the same elements throughout the description of the drawings, and repeated descriptions will be omitted.

[0050] The following describes a communication system applied according to exemplary embodiments of the present disclosure. The communication system may be a 4G communication network (e.g., a Long Term Evolution (LTE) communication system or an LTE-A Advanced (LTE-A) communication system), a 5G communication network (e.g., a New Radio (NR) communication system), etc. A 4G communication system may support communication in frequency bands of 6 GHz or lower. A 5G communication system may support communication in frequency bands of 6 GHz or higher as well as frequency bands of 6 GHz or lower. The communication system applied according to exemplary embodiments of the present disclosure is not limited to what is described below, and exemplary embodiments of the present disclosure can be applied to various communication systems. Here, "communication system" may be used in the same sense as "communication network." "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.

[0051] Figure 1 This is a conceptual diagram illustrating a first exemplary embodiment of a communication system.

[0052] Reference Figure 1 The communication system 100 may include multiple 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. Furthermore, the communication system 100 may also 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., an NR system), the core network may include Access and Mobility Management Functions (AMF), User Plane Functions (UPF), Session Management Functions (SMF), etc.

[0053] Multiple communication nodes 110 to 130 can support communication protocols defined by the technical specifications of the 3rd Generation Partnership Project (3GPP) (e.g., LTE communication protocol, LTE-A communication protocol, NR communication protocol, etc.). Multiple communication nodes 110 to 130 can support communication protocols based on Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiplexing (OFDM), Filtered OFDM, Cyclic Prefix OFDM (CP-OFDM), Discrete Fourier Transform Extended OFDM (DFT-s-OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier FDMA (SC-FDMA), Non-Orthogonal Multiple Access (NOMA), Generalized Frequency Division Multiplexing (GFDM), Filter Bank Multicarrier (FBMC), Universal Filtered Multicarrier (UFMC), and Space Division Multiple Access (SDMA), etc. Each of the multiple communication nodes can have the following structure.

[0054] Figure 2 This is a block diagram illustrating a first exemplary embodiment of a communication node constituting a communication system.

[0055] Reference Figure 2 The communication node 200 may include at least one processor 210, a memory 220, and a transceiver 230 connected to a network for performing communication. Furthermore, the communication node 200 may also include an input interface device 240, an output interface device 250, a storage device 260, etc. The various components included in the communication node 200 can be connected to each other via a bus 270 for communication.

[0056] Processor 210 can execute a program stored in at least one of memory 220 and storage device 260. 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 disclosure thereon. Each of memory 220 and storage device 260 may be constituted by at least one of volatile storage medium and non-volatile storage medium. For example, memory 220 may include at least one of read-only memory (ROM) and random access memory (RAM).

[0057] Refer again Figure 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. Each of the first base station 110-1, the second base station 110-2, and the third base station 110-3 may form a macro cell, and each of the fourth base station 120-1 and the fifth base station 120-2 may form a small cell. The fourth base station 120-1, the third terminal 130-3, and the fourth terminal 130-4 may be within the cell coverage area of ​​the first base station 110-1. Furthermore, the second terminal 130-2, the fourth terminal 130-4, and the fifth terminal 130-5 may be within the cell coverage area of ​​the second base station 110-2. Furthermore, the fifth base station 120-2, the fourth terminal 130-4, the fifth terminal 130-5, and the sixth terminal 130-6 can all fall within the cell coverage area of ​​the third base station 110-3. Additionally, the first terminal 130-1 can fall within the cell coverage area of ​​the fourth base station 120-1, and the sixth terminal 130-6 can fall within the cell coverage area of ​​the fifth base station 120-2.

[0058] Here, each of the multiple base stations 110-1, 110-2, 110-3, 120-1, and 120-2 can refer to a Node B, an Evolved Node B (eNB), an Advanced Base Station (BTS), a High Reliability Base Station (HR-BS), a Base Transceiver Station (BTS), a Radio Base Station, a Radio Transceiver Station, an Access Point, an Access Node, a Radio Access Station (RAS), a Mobile Multi-Hop Relay Base Station (MMR-BS), a Relay Station (RS), an Advanced Relay Station (ARS), a High Reliability Relay Station (HR-RS), a Home Node B (HNB), a Home eNode B (HeNB), a Roadside Unit (RSU), a Radio Remote Header (RRH), a Transmitter Point (TP), a Transmitter and Receiver Point (TRP), a Macro Cell, a Pico Cell, a Micro Cell, a Femtocell, etc.

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

[0060] Additionally, in a communication system, the base station (e.g., eNB or gNB) can support a fronthaul interface. Here, the fronthaul interface can be a fronthaul interface defined by the O-RAN Alliance. In this case, the base station can include an O-DU and one or more O-RUs. Communication between the O-DU and one or more O-RUs can be performed through the fronthaul interface. The O-DU can be an LLS-CU specified by 3GPP, and the O-RU can be an LLS-DU specified by 3GPP. Each of the O-DU and O-RU can communicate with... Figure 2 The communication nodes 200 shown are configured the same or similarly.

[0061] The fronthaul communication method will be described below. Even when a method (e.g., signal transmission or reception) executed at the first communication node is described, the corresponding second communication node can also execute a method (e.g., signal reception or transmission) corresponding to the method executed at the first communication node. That is, when the operation of the O-DU is described, the corresponding O-RU can execute the operation corresponding to the operation of the O-DU. Conversely, when the operation of the O-RU is described, the corresponding O-DU can execute the operation corresponding to the operation of the O-RU.

[0062] Figure 3 This is a block diagram illustrating a first exemplary embodiment of a base station supporting Lower Layer Segmentation (LLS) in a communication system.

[0063] Reference Figure 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 can be performed through the 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".

[0064] The O-DU311 can be a logical node performing Radio Link Control (RLC) layer functions, Media Access Control (MAC) layer functions, and / or high physical (high PHY) layer functions. The O-DU311 can control multiple O-RUs 321 and 322. Each of the O-RUs 321 and 322 can be a logical node performing low PHY layer functions and / or radio frequency (RF) processing functions. The O-RUs 321 and 322 can send / receive control information and / or data by communicating with the O-DU311. The control information can be real-time control information. The data can be user plane data. The O-RUs 321 and 322 can operate based on the control of the O-DU311.

[0065] Figure 4 This is a block diagram illustrating a first exemplary embodiment of the interface structure between O-DU and O-RU in a communication system.

[0066] Reference Figure 4 Each of the O-DU and O-RU can include a CUS plane (e.g., the O-RAN CUS plane) and can perform communication based on CUS plane functions. Additionally, each of the O-DU and O-RU can include a management (M) plane (e.g., the O-RAN M plane) and can perform communication based on M plane functions. That is, the O-DU and O-RU can perform both M-plane and CUS plane functions. M-plane functions can support O-RU initialization, configuration, management, etc. The M-plane can use open interfaces based on the NETCONF and / or YANG model (hereinafter referred to as the "NETCONF / YANG model"). The M-plane can support startup installation, software management, configuration management, performance management, fault management, file management, etc. The M-plane structure in O-RAN can be as follows.

[0067] Figure 5a This is a block diagram illustrating a first exemplary embodiment of a layered M-plane model. Figure 5b This is a block diagram illustrating a second exemplary embodiment of the hybrid M-surface model.

[0068] Reference 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 O-DUs and O-RUs. An interface can exist between the O-DU and the Network Management System (NMS), but the NMS may not directly manage the O-RUs. That is, the NMS can manage O-RUs through O-DUs. There may not be a direct interface between the O-RU and the NMS. The NMS can refer to... Figure 4 The management system shown.

[0069] Reference Figure 5bIn the hybrid M-plane model, a direct logical interface can exist between the NMS and the O-RU, as well as between the O-DU and the O-RU. The NMS can support the software management, performance management, configuration management, and / or fault management functions of the O-RU. The NMS and O-RU can have end-to-end Internet Protocol (IP) layer connectivity.

[0070] Figure 6 This is a block diagram illustrating a first exemplary embodiment of the protocol stack of the M-side.

[0071] Reference Figure 6 The transport network layer can operate above the IP transport layer. The Transmission Control Protocol (TCP) / Secure Shell (SSH) layer can be used to send / receive M-plane messages between O-DU / NMS and O-RU.

[0072] The NETCONF / YANG model can be used as a network element management protocol and data modeling language. The NETCONF / YANG model supports an open management scheme for efficient integration and management between multi-vendor O-RUs / O-DUs.

[0073] NETCONF can obtain configuration status information and supports configuration change operations. Additionally, NETCONF can transmit messages via XML-RPC through a transport layer that provides secure transport (e.g., the SSH layer). Each of the "get" and "get-config" RPC operations can be used to retrieve all configuration, a portion of the configuration, all status data, and / or a portion of the status data. The edit-config operation can be used to change, add, and / or delete configuration elements in the configuration data repository.

[0074] Notification support in NETCONF can be based on event streams. NETCONF clients (e.g., O-DU) may expect to receive notifications for specific events. In this case, a create subscription operation can be used when requesting to subscribe to the corresponding event stream.

[0075] Performance management functions can be a primary feature of the M-face. Performance management functions can be features used to optimize the operation of the O-RU. The O-DU (e.g., a NETCONF client) can use the NETCONF / YANG model to collect O-RU operation-related information (e.g., transceiver, receive window (i.e., rx-window), transmit window (i.e., tx-window), Energy, Power and Environment (EPE), Received Signal Strength Indicator (RSSI) (e.g., symbolic RSSI), etc.). For example, the O-DU can collect configuration and / or status information for performance management.

[0076] Measurement objects defined and / or used in the O-RAN specification for performance management (e.g., TX_POWER, RX_POWER, RX_ON_TIME, TX_TOTAL, etc.) can be managed as being categorized into five or more measurement groups (e.g., transceiver statistics (transceiver-stats group), receive window statistics (rx-window-stats group), transmit measurement statistics (tx-measurement-stats group), EPE statistics (epe-stats group), RSSI statistics (rssi-stats group, etc.). RSSI statistics groups can be symbolic RSSI statistics groups. Measurement intervals can be set independently for each measurement group. For example, the measurement intervals can be different for each measurement group. Transceiver measurement interval (i.e., transceiver-measurement-interval), receive window measurement interval (i.e., rx-window-measurement-interval), transmit measurement interval (i.e., tx-measurement-interval), EPE measurement interval (i.e., epe-measurement-interval), etc. The interval and / or RSSI measurement interval (i.e., rssi-measurement-interval) can be set independently of each other.

[0077] The NETCONF notification mechanism can be used to send measurement results (e.g., measured values) measured by the O-RU according to each measurement interval set by the O-DU (e.g., a NETCONF client) all at once, based on the notification interval. For example, the O-RU can periodically send measurement results to the O-DU. Alternatively, the O-RU can store the measurement results for each measurement time on a local disk and upload the measurement results to the O-DU all at once according to the file upload interval. In this case, the notification interval can be set differently from the measurement interval. In an exemplary embodiment, the measurement interval can refer to a measurement period, the notification interval can refer to a notification period, and the "notification sending / receiving operation" can refer to the "notification message sending / receiving operation".

[0078] For example, the measurement interval for measurement object #a can be set to 3 minutes, and the measurement interval for measurement object #B can be set to 5 minutes. To efficiently perform the transmission of performance management information, the notification interval can be set to 15 minutes. In this case, during NETCONF notification transmission, it is preferable to send a notification (e.g., a notification message) that includes five measurement results for measurement object #a and three measurement results for measurement object #B. When 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 the notification is sent. Multiple measurement results for a specific measurement object can be included in a single notification.

[0079] The existing YANG model defined in the M-plane of O-RAN may not support the sending / receiving operation of a single notification including multiple measurement results. In an exemplary embodiment, the "sending and receiving operation of a single notification including multiple measurement results" can be referred to as a "multiple measurement result reporting function." That is, the existing YANG model can send a single notification including one measurement result for each measurement object. Therefore, when the notification interval is set to be longer than the measurement interval of the measurement object, a notification including only one measurement result may be sent, and the remaining measurement results may not be transmitted to the O-DU (e.g., NETCONF client) in the corresponding notification interval. A method to solve the above problem will be described below.

[0080] Regarding performance management in the O-RAN M-plane (hereinafter referred to as "O-RAN M-plane"), please refer to " o-ran- performance management. The module defines the interface and configuration information between O-DU and O-RU. In the O-RANM plane, the NETCONF / YANG model can be used to define the format of management information sent and received between devices, as well as the transmission process of management information.

[0081] In Tables 1 and 2 below, we can define the uses for o-ran-performance-management.yang The main parameters for performance management in the module. Additional parameters can be added to Tables 1 and 2 based on updates to the O-RAN specification, and the parameters defined in Tables 1 and 2 can be modified.

[0082] [Table 1]

[0083]

[0084] [Table 2]

[0085]

[0086] An O-DU (e.g., a NETCONF client) can be configured with the measurement object, the values ​​included in the information to be reported (i.e., report-info) (e.g., maximum, minimum, count, etc.), the object unit, the measurement interval, the notification interval, and / or the file upload interval. The O-DU can notify the O-RU of the configuration information. The O-RU can perform measurements on the selected measurement object at the set measurement interval based on the information configured by the O-DU (e.g., values), and can send notifications including measurement results according to the set notification interval, or upload measurement result files including measurement results according to the set file upload interval.

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

[0088] Measurements can be activated for each measurement object. The O-DU can configure information elements included in the reported information (i.e., report-info) for each measurement object. For example, the reported information may include multiple information elements. Information elements may include MAXIMUM, MINIMUM, FIRST, LATEST, and / or a frequency table. Object cells can be set independently for each measurement object. For example, the object cells can be different for each measurement object.

[0089] Figure 7 This is a conceptual diagram illustrating a first exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0090] Reference Figure 7 The O-RU can store measurement results of measurement objects belonging to each of the transceiver statistics group and the receive window statistics group in a data repository based on the YANG model. The O-RU can send NETCONF notifications including the measurement results to the O-DU (e.g., a NETCONF client). The transceiver statistics group can be referred to as the transceiver measurement object, and the receive window statistics group can be referred to as the receive window measurement object. Activation for each measurement object can be set to true or false. The default value for activation for each measurement object is false. Count values ​​can start from 0 at the boundaries of the measurement interval.

[0091] Figure 8 This is a conceptual diagram illustrating a second exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0092] Reference Figure 8 The O-RU can store measurement results of measurement objects belonging to each of the EPE statistics group and the sending measurement statistics group in a data repository based on the YANG model. The O-RU can send NETCONF notifications including the measurement results to the O-DU (e.g., a NETCONF client). The EPE statistics group can be referred to as the EPE measurement object, and the sending measurement statistics group can be referred to as the sending measurement object. Activation for each measurement object can be set to true or false. The default value for activation for each measurement object is false.

[0093] Figure 9 This is a conceptual diagram illustrating a third exemplary embodiment of the data structure of the YANG model used to transmit performance measurement results in the O-RAN M plane.

[0094] Reference Figure 9 New measurement groups can be added for various measurement results (e.g., measurement information) used for symbol-rssi-stats (e.g., RSSI for a specific symbol in the time domain). This measurement information can be combined with... Figure 7 or Figure 8 The structures shown have the same or similar structures. For example, the structure of symbol RSSI statistics can be the same as or similar to the structure of transceiver statistics.

[0095] The O-RU can perform measurement operations according to the measurement intervals set by the O-DU (e.g., a NETCONF client). The O-RU can periodically send measurement results to the O-DU once, based on the notification interval using the NETCONF notification mechanism. Alternatively, the O-RU can store the measurement results on its local disk at each measurement time and can upload the measurement results to the O-DU once, based on the file upload interval.

[0096] The notification interval can be set differently from the measurement interval. For example, the measurement interval for measurement object #a can be set to 3 minutes, and the measurement interval for measurement object #B can be set to 5 minutes. To efficiently perform the transmission of performance management information, the notification interval can be set to 15 minutes. In this case, during NETCONF notification transmission, it is preferable to send a single notification (e.g., a notification message) that includes five measurement results for measurement object #a and three measurement results for measurement object #B. When 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 the notification is sent. Multiple measurement results for a specific measurement object can be included in a single notification.

[0097] The existing YANG model defined in the M-plane of O-RAN may not support sending / receiving a single notification containing multiple measurement results. In other words, the existing YANG model can send a notification containing only one measurement result for each measurement object. Therefore, when the notification interval is set longer than the measurement interval for the measurement object, a notification containing only one measurement result may be sent, and the remaining measurement results may not be transmitted to the O-DU (e.g., NETCONF client) within the corresponding notification interval. That is, in the current O-RAN YANG model (e.g., ... Figure 7 and Figure 8 In the YANG model shown, a notification sending operation can be performed to send a measurement result for each measurement object. To address the aforementioned problem, a method for extending the YANG model will be proposed below.

[0098] Part 1 of the YANG model (e.g., the common configuration part) for performance management of the O-RAN M-plane can be as follows.

[0099] [Part 1 of the YANG model]

[0100] module:o-ran-performance-management

[0101] +--rw performance-measurement-objects

[0102] +--ro measurement-capabilitites

[0103] │ +--ro transceiver-objects* [measurement-object]

[0104] │ │ +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0105] │ +--ro rx-window-objects* [measurement-object]

[0106] │ │ +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0107] │ +--ro tx-stats-objects* [measurement-object]

[0108] │ │ +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0109] │ +--ro epe-stats-objects* [measurement-object]

[0110] │ +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[0111] │ +--ro component-class* identityref

[0112] +--rw enable-SFTP-upload? boolean

[0113] +--rw enable-random-file-upload? boolean

[0114] +--rw remote-SFTP-uploads* [remote-SFTP-upload-path]

[0115] │ +--rw remote-SFTP-upload-path inet:uri

[0116] +--rw transceiver-measurement-interval? uint16

[0117] +--rw rx-window-measurement-interval? uint16

[0118] +--rw epe-measurement-interval? uint16

[0119] +--rw tx-measurement-interval? uint16

[0120] +--rw notification-interval? uint16

[0121] +--rw file-upload-interval? uint16

[0122] +--ro max-bin-count uint16

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

[0124] Part 2 of the YANG model used for performance management of the O-RAN M-plane (e.g., transceiver, receive window related notifications) can be as follows.

[0125] [Part 2 of the YANG model]

[0126] notifications:

[0127] +---n measurement-result-stats

[0128] +--ro transceiver-stats* [measurement-object]

[0129] │ +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0130] │ +--ro start-time? yang-types:data-and-time

[0131] │ +--ro end-time? yang-types:data-and-time

[0132] │ +--ro transceiver-measurement-result* [object-unit-id]

[0133] │ +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0134] │ +--ro min

[0135] │ │ +--ro value? decima164

[0136] │ │ +--ro time? yang-types:data-and-time

[0137] │ +--ro max

[0138] │ │ +--ro value? decima164

[0139] │ │ +--ro time? yang-types:data-and-time

[0140] │ +--ro first

[0141] │ │ +--ro value? decima164

[0142] │ │ +--ro time? yang-types:data-and-time

[0143] │ +--ro latest

[0144] │ │ +--ro value? decima164

[0145] │ │ +--ro time? yang-types:data-and-time

[0146] │ +--ro frequency-table* uint32

[0147] +--ro rx-window-stats* [measurement-object]

[0148] +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0149] +--ro start-time? yang-types:data-and-time

[0150] +--ro end-time? yang-types:data-and-time

[0151] +--ro (object-unit-id)?

[0152] +--:(RU)

[0153] │ +--ro name? -> / hw:hardware / component / name

[0154] │ +--ro count uint64

[0155] +--:(TRANSPORT)

[0156] │ +--ro tr-measured-result* []

[0157] │ +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0158] │ +--ro count uint64

[0159] +--:(EAXC_ID)

[0160] +--ro eaxc-measured-result* []

[0161] +--ro eaxc-id? uint16

[0162] +--ro count uint64

[0163] +--ro transport-name? -> / o-ran-elements:processing-elemnets / ru-elements / name

[0164] Part 3 of the YANG model used for performance management of the O-RAN M-plane (e.g., EPE, transmission window related notifications) can be as follows.

[0165] [Part 3 of the YANG model]

[0166] +--ro tx-stats* [measurement-object]

[0167] │ +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0168] │ +--ro start-time? yang-types:data-and-time

[0169] │ +--ro end-time? yang-types:data-and-time

[0170] │ +--ro (object-unit-id)?

[0171] │ +--:(RU)

[0172] │ │ +--ro name? -> / hw:hardware / component / name

[0173] │ │ +--ro count uint64

[0174] │ +--:(TRANSPORT)

[0175] │ │ +--ro tr-measured-result* []

[0176] │ │ +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0177] │ │ +--ro count uint64

[0178] │ +--:(EAXC_ID)

[0179] │ +--ro eaxc-measured-result* []

[0180] │ +--ro eaxc-id? uint16

[0181] │ +--ro count uint64

[0182] │ +--ro transport-name? -> / o-ran-elements:processing-elemnets / ru-elements / name

[0183] x--ro epe-stats

[0184] │ +--ro start-time? yang-types:data-and-time

[0185] │ +--ro end-time? yang-types:data-and-time

[0186] │ +--ro epe-measurement-result* [object-unit-id]

[0187] │ +--ro object-unit-id -> / hw:hardware / component / class

[0188] │ +--ro min? decima164

[0189] │ +--ro max? decima164

[0190] │ +--ro average? decima164

[0191] +--ro epe-statistics* [measurement-object]

[0192] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[0193] +--ro start-time?yang-types:data-and-time

[0194] +--ro end-time? yang-types:data-and-time

[0195] +--ro epe-measurement-result* [object-unit-id]

[0196] +--ro object-unit-id ->hw:hardware / component / class

[0197] +--ro min? decima164

[0198] +--ro max? decima164

[0199] +--ro average? decima164

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

[0201] In other words, it is possible to send the results of measurements taken over multiple time periods (e.g., multiple measurement periods) without using a single notification. Specifically, when the measurement intervals for the transceiver, receive window, EPE, transmit window, and RSSI are set differently, it is necessary to send notifications containing measurement results frequently. The YANG model can be configured as follows to address the above problem.

[0202] [Method A]

[0203] When using [Method A], you can configure an additional measurement list for each measurement object, including one or more measurement results, and you can add the additional measurement list to the statistics for the corresponding measurement object. For example, you can add the additional measurement list to the statistics in chronological order.

[0204] Figure 10 This is a conceptual diagram illustrating a first exemplary embodiment of the structure for extended measurement results of the transceiver in the YANG model using method A.

[0205] Reference Figure 10 Additional transceiver measurement results can be added for each measurement object (e.g., RX_POWER, TX_POWER, TX_BIAS_COUNT, TEMPARATURE, etc.). additional-transceiver-measurement- result ).

[0206] Figure 11 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of extended measurement results for the receiving window in the YANG model using method A.

[0207] Reference Figure 11 Additional receive window measurements can be added to each measurement object (e.g., RX_ON_TIME, RX_EARLY, RX_LATE, RX_ARRORUT, RX_DUPL, RX_TOTAL, etc.). additional-rx-window- measurement-result ).

[0208] Figure 12 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of extended measurement results for EPE in the YANG model using method A.

[0209] Reference Figure 12 Additional EPE measurement results can be added for each measurement object (e.g., TEMPARATURE, POWER). additional-epe-measurement-result ).

[0210] Figure 13 This is a conceptual diagram illustrating a first exemplary embodiment of the structure for extended measurement results of transmitted measurements in the YANG model using method A.

[0211] Reference Figure 13 Additional measurement results can be sent for each measurement object (e.g., TX_TOTAL, TX_TOTAL_C). additional-tx-measurement-result ).

[0212] Figure 14 This is a conceptual diagram illustrating a first exemplary embodiment of the structure of the extended measurement results for the symbol RSSI in the YANG model using method A.

[0213] Reference Figure 14Additional symbols can be added to the RSSI measurement results for each measurement object (e.g., ALL-UL-SYMBOLS, CONFIGURED-SYMBOLS). additional-symbol-rssi-measurement-result ).

[0214] The structure of the YANG model based on Method 1 above can be defined as follows.

[0215] Method 1

[0216] module:o-ran-performance-management

[0217] ... (omitted) ...

[0218] notifications:

[0219] +---n measurement-result-stats

[0220] +--ro transceiver-stats* [measurement-object]

[0221] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0222] | +--ro start-time?yang-types:date-and-time

[0223] | +--ro end-time? yang-types:date-and-time

[0224] | +--ro transceiver-measurement-result* [object-unit-id]

[0225] | | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0226] | | +--ro min

[0227] | | | +--ro value? decimal64

[0228] | | | +--ro time? yang-types:date-and-time

[0229] | | +--ro max

[0230] | | | +--ro value? decimal64

[0231] | | | +--ro time? yang-types:date-and-time

[0232] | | +--ro first

[0233] | | | +--ro value? decimal64

[0234] | | | +--ro time? yang-types:date-and-time

[0235] | | +--ro latest

[0236] | | | +--ro value? decimal64

[0237] | | | +--ro time? yang-types:date-and-time

[0238] | | +--ro frequeny-table* uint32

[0239] | +--ro number-of-additional-measurement-result? uint8

[0240] | +--ro additional-transceiver-measurement-result* [seq-number]

[0241] | +--ro seq-number uint8

[0242] | +--ro start-time? yang-types:date-and-time

[0243] | +--ro end-time? yang-types:date-and-time

[0244] | +--ro transceiver-measurement-result* [object-unit-id]

[0245] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0246] | +--ro min

[0247] | | +--ro value? decimal64

[0248] | | +--ro time? yang-types:date-and-time

[0249] | +--ro max

[0250] | | +--ro value? decimal64

[0251] | | +--ro time? yang-types:date-and-time

[0252] | +--ro first

[0253] | | +--ro value? decimal64

[0254] | | +--ro time? yang-types:date-and-time

[0255] | +--ro latest

[0256] | | +--ro value? decimal64

[0257] | | +--ro time? yang-types:date-and-time

[0258] | +--ro frequeny-table* uint32

[0259] +--ro rx-window-stats* [measurement-object]

[0260] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0261] | +--ro start-time? yang-types:date-and-time

[0262] | +--ro end-time? yang-types:date-and-time

[0263] | +--ro (object-unit-id)?

[0264] | | +--:(RU)

[0265] | | | +--ro name? -> / hw:hardware / component / name

[0266] | | | +--ro count uint64

[0267] | | +--:(TRANSPORT)

[0268] | | | +--ro tr-measured-result* []

[0269] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0270] | | | +--ro count uint64

[0271] | | +--:(EAXC_ID)

[0272] | | +--ro eaxc-measured-result* []

[0273] | | +--ro eaxc-id? uint16

[0274] | | +--ro count uint64

[0275] | | +--ro data-direction? Enumeration

[0276] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0277] | +--ro number-of-additional-measurement-result? uint8

[0278] | +--ro additional-rx-window-measurement-result* [seq-number]

[0279] | +--ro seq-number uint8

[0280] | +--ro start-time? yang-types:date-and-time

[0281] | +--ro end-time? yang-types:date-and-time

[0282] | +--ro (object-unit-id)?

[0283] | +--:(RU)

[0284] | | +--ro name? -> / hw:hardware / component / name

[0285] | | +--ro count uint64

[0286] | +--:(TRANSPORT)

[0287] | | +--ro tr-measured-result* []

[0288] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0289] | | +--ro count uint64

[0290] | +--:(EAXC_ID)

[0291] | +--ro eaxc-measured-result* []

[0292] | +--ro eaxc-id? uint16

[0293] | +--ro count uint64

[0294] | +--ro data-direction? Enumeration

[0295] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0296] +--ro tx-stats* [measurement-object]

[0297] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0298] | +--ro start-time? yang-types:date-and-time

[0299] | +--ro end-time? yang-types:date-and-time

[0300] | +--ro (object-unit-id)?

[0301] | | +--:(RU)

[0302] | | | +--ro name? -> / hw:hardware / component / name

[0303] | | | +--ro count uint64

[0304] | | +--:(TRANSPORT)

[0305] | | | +--ro tr-measured-result* []

[0306] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0307] | | | +--ro count uint64

[0308] | | +--:(EAXC_ID)

[0309] | | +--ro eaxc-measured-result* []

[0310] | | +--ro eaxc-id? uint16

[0311] | | +--ro count uint64

[0312] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0313] | +--ro number-of-additional-measurement-result? uint8

[0314] | +--ro additional-tx-measurement-result* [seq-number]

[0315] | +--ro seq-number uint8

[0316] | +--ro start-time? yang-types:date-and-time

[0317] | +--ro end-time? yang-types:date-and-time

[0318] | +--ro (object-unit-id)?:

[0319] | +--:(RU)

[0320] | | +--ro name? -> / hw:hardware / component / name

[0321] | | +--ro count uint64

[0322] | +--:(TRANSPORT)

[0323] | | +--ro tr-measured-result* []

[0324] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0325] | | +--ro count uint64

[0326] | +--:(EAXC_ID)

[0327] | +--ro eaxc-measured-result* []

[0328] | +--ro eaxc-id? uint16

[0329] | +--ro count uint64

[0330] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0331] x--ro epe-stats

[0332] | +--ro start-time? yang-types:date-and-time

[0333] | +--ro end-time? yang-types:date-and-time

[0334] | +--ro epe-measurement-result* [object-unit-id]

[0335] | +--ro object-unit-id -> / hw:hardware / component / class

[0336] | +--ro min? decimal64

[0337] | +--ro max? decimal64

[0338] | +--ro average? decimal64

[0339] +--ro epe-statistics* [measurement-object]

[0340] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[0341] +--ro start-time? yang-types:date-and-time

[0342] +--ro end-time? yang-types:date-and-time

[0343] +--ro epe-measurement-result* [object-unit-id]

[0344] | +--ro object-unit-id -> / hw:hardware / component / class

[0345] | +--ro min? decimal64

[0346] | +--ro max? decimal64

[0347] | +--ro average? decimal64

[0348] +--ro number-of-additional-measurement-result? uint8

[0349] +--ro additional-epe-measurement-result* [seq-number]

[0350] +--ro seq-number uint8

[0351] +--ro start-time? yang-types:date-and-time

[0352] +--ro end-time? yang-types:date-and-time

[0353] +--ro epe-measurement-result* [object-unit-id]

[0354] +--ro object-unit-id -> / hw:hardware / component / class

[0355] +--ro min? decimal64

[0356] +--ro max? decimal64

[0357] +--ro average? decimal64

[0358] The improved YANG code is as follows.

[0359] grouping measurement-notification {

[0360] description

[0361] "notification may contain measurement result for transceiver-stats

[0362] and / or rx-window-stats and / or tx-stats and / or epe-stats";

[0363] list transceiver-stats {

[0364] key "measurement-object";

[0365] description

[0366] "measurement result of transceiver-measurement per measurement-object";

[0367] leaf measurement-object {

[0368] type leafref {

[0369] path" / performance-measurement-objects / transceiver-measurement-objects / measurement-object";

[0370] }

[0371] description

[0372] "measurement-object for the transceiver-measurement";

[0373] }

[0374] uses start-and-end-time; / / start-and-end-time of the firstresult

[0375] uses transceiver-measurement-result-grouping; / / First result

[0376] / / For additional measurement result

[0377] leaf number-of-additional-measurement-result {

[0378] type uint8;

[0379] config false;

[0380] description

[0381] "This parameter indicates the number of additionalmeasurement result.";

[0382] }

[0383] list additional-transceiver-measurement-result {

[0384] / / when measurement-interval<notification interval

[0385] config false;

[0386] description

[0387] "measurement result of additional transceiver-measurement";

[0388] key seq-number;

[0389] leaf seq-number {

[0390] type uint8 {

[0391] range"1..max";

[0392] }

[0393] }

[0394] uses start-and-end-time;

[0395] uses transceiver-measurement-result-grouping;

[0396] }

[0397] }

[0398] list rx-window-stats {

[0399] key"measurement-object";

[0400] description

[0401] "measurement result for the reception window measurement per

[0402] measurement-object";

[0403] leaf measurement-object {

[0404] type leafref {

[0405] path" / performance-measurement-objects / rx-window-measurement-objects / measurement-object";

[0406] }

[0407] description

[0408] "measurement-object for the reception window measurement";

[0409] }

[0410] uses start-and-end-time;

[0411] uses rx-window-measurement-result-grouping;

[0412] / / For additional measurement result

[0413] leaf number-of-additional-measurement-result {

[0414] type uint8;

[0415] config false;

[0416] description

[0417] "This parameter indicates the number of additionalmeasurement result.";

[0418] }

[0419] list additional-rx-window-measurement-result {

[0420] / / when measurement-interval<notification interval

[0421] config false;

[0422] description

[0423] "measurement result of additional rx-window-measurement";

[0424] key seq-number;

[0425] leaf seq-number {

[0426] type uint8 {

[0427] range"1..max";

[0428] }

[0429] }

[0430] uses start-and-end-time;

[0431] uses rx-window-measurement-result-grouping;

[0432] }

[0433] }

[0434] list tx-stats {

[0435] key"measurement-object";

[0436] description

[0437] "measurement result for the tx stats measurement per

[0438] measurement-object";

[0439] leaf measurement-object {

[0440] type leafref {

[0441] path" / performance-measurement-objects / tx-measurement-objects / measurement-object";

[0442] }

[0443] description

[0444] "measurement-object for the tx stats measurement";

[0445] }

[0446] uses start-and-end-time;

[0447] uses tx-measurement-result-grouping;

[0448] / / For additional measurement result

[0449] leaf number-of-additional-measurement-result {

[0450] type uint8;

[0451] config false;

[0452] description

[0453] "This parameter indicates the number of additionalmeasurement result.";

[0454] }

[0455] list additional-tx-measurement-result {

[0456] / / when measurement-interval<notification interval

[0457] config false;

[0458] description

[0459] "measurement result of additional tx-measurement";

[0460] key seq-number;

[0461] leaf seq-number {

[0462] type uint8 {

[0463] range"1..max";

[0464] }

[0465] }

[0466] uses start-and-end-time;

[0467] uses tx-measurement-result-grouping;

[0468] }

[0469] }

[0470] container epe-stats {

[0471] description

[0472] "container for the epe stats measurement - deprecated becausemeasurement object isn't included";

[0473] status deprecated;

[0474] uses start-and-end-time;

[0475] uses epe-measurement-result-grouping;

[0476] }

[0477] list epe-statistics {

[0478] key"measurement-object";

[0479] description

[0480] "measurement result for the epe stats measurement per

[0481] measurement-object";

[0482] leaf measurement-object {

[0483] type leafref {

[0484] path" / performance-measurement-objects / epe-measurement-objects / measurement-object";

[0485] }

[0486] description

[0487] "measurement-object for the epe stats measurement";

[0488] }

[0489] uses start-and-end-time;

[0490] uses epe-measurement-result-grouping;

[0491] / / For additional measurement result

[0492] leaf number-of-additional-measurement-result {

[0493] type uint8;

[0494] config false;

[0495] description

[0496] "This parameter indicates the number of additionalmeasurement result.";

[0497] }

[0498] list additional-epe-measurement-result {

[0499] / / when measurement-interval<notification interval

[0500] config false;

[0501] description

[0502] "measurement result of additional epe-measurement";

[0503] key seq-number;

[0504] leaf seq-number {

[0505] type uint8 {

[0506] range"1..max";

[0507] }

[0508] }

[0509] uses start-and-end-time;

[0510] uses epe-measurement-result-grouping;

[0511] }

[0512] }

[0513] }

[0514] When the notification interval for a measurement object is longer than the measurement interval, multiple measurement results for each measurement object within that measurement object can be included in a single notification (e.g., a notification message). To support this operation, the YANG model can be extended such that each measurement object belonging to the transceiver statistics group, receive window statistics group, transmit statistics group, and EPE statistics group includes either an additional list of measurement results or the entire set of measurement results (e.g., a list). additional-transceiver-measurement- result List additional-rx-window-measurement-result List additional-tx- measurement-result List additional-epe-measurement-result wait).

[0515] The additional list of measurement results may include a start time (e.g., measurement start time), an end time (e.g., measurement end time), and measurement results within the corresponding time period (e.g., measurement values ​​within the measurement time period). The measurement time period may be a period from the start time to the end time.

[0516] In existing YANG models, a notification may be sent that includes only one measurement result for each measurement object. When the measurement results are changed to a list of measurement results, fronthaul devices (e.g., O-DU and / or O-RU) supporting existing YANG models may not be able to decode the list of measurement results. That is, backward compatibility issues with existing fronthaul devices may occur. The YANG model proposed in this disclosure can use the start time, end time, and measurement results of existing YANG models as is. The measurement results of existing YANG models may include the first measurement result. Compared to existing YANG models, the proposed YANG model may include an additional list of measurement results. The additional list of measurement results may include one or more measurement results starting from the second measurement result. The measurement results may be arranged in chronological order (e.g., in ascending order of measurement time) in the additional list of measurement results. This operation may be referred to as "Method A". According to Method A, since the measurement-related parameters used in existing YANG models are used as is, backward compatibility issues may not occur.

[0517] In other words, an existing O-DU that can only decode one measurement result from a notification may be able to decode existing parameters (e.g., transceiver statistics, rx-window-stats, tx-stats, epe-stats). In this case, even if the O-RU sends a notification that includes multiple measurement results, the existing O-DU can successfully receive one measurement result.

[0518] Optionally, the O-RU can configure the last measurement result (e.g., the most recent measurement result) among multiple measurement results as an existing measurement result parameter, and can generate an additional list of measurement results including those from the first measurement result to those exactly before the last measurement result (e.g., additional-XXXX-measurement-result This operation can be referred to as "method b". According to method b, an existing O-DU can receive a measurement result that is the most recent measurement result.

[0519] To improve the ease of O-DU decoding during notification reception, the O-RU can increase the number of measurement results included in the supplementary measurement result list (e.g., number-of-additional-measurement-result The notification is sent to the O-DU. In other words, the additional measurement results list may also include... number-of-additional-measurement-result Additionally, the supplementary list of measurement results may include serial numbers (e.g., seq-numberWhen using method A, the sequence numbers of the measurement results in the measurement results list can start from 1 and can increase chronologically. In this case, the sequence number of an existing measurement result (e.g., the first measurement result) can be considered 0. When using method b, the sequence numbers of the measurement results in the measurement results list can start from 0 and can increase chronologically. In this case, an existing measurement result can be considered the last measurement result. By using the sequence number as the key value for the additional measurement results list, O-DU can easily arrange the measurement results in chronological order. Furthermore, O-DU can easily find a specific measurement result using the sequence number.

[0520] The sequence number may not be included in the supplementary measurement results list, and the start and end times can be used instead of the sequence number as the key values ​​for the supplementary measurement results list. A key for the supplementary measurement results list can be omitted. If no key for the supplementary measurement results list is specified, the O-DU cannot directly access specific entries (e.g., specific measurement results) in the supplementary measurement results list and should always decode the entire supplementary measurement results list. To reduce the number of parameters, it is possible to omit the use of... number-of-additional-measurement-result In the NETCONF / YANG model, the recipient (e.g., O-DU) can know the number of items (e.g., measurement results) even if the number of items included in the additional measurement results list is not explicitly indicated. number-of-additional-measurement-result This can be used to improve the decoding convenience for the receiver. In order to arrange the entries in the supplementary measurement results list in chronological order rather than having the communication system arbitrarily define the order of the entries in the supplementary measurement results list, the sequence number, which is a key value, can be defined as "sorted by the user".

[0521] Alternatively, when the O-RU sends measurement results to an existing O-DU (e.g., an O-DU that supports a previous version of O-RAN M-plane 7.0, or an O-DU that cannot decode additional lists of measurement results), the O-RU may send a leaf (e.g., start-time, end-time, and ...) capable of transmitting a single measurement result. XXXX-measurement-result[] Furthermore, the O-RU can send an additional list of measurement results, including all multiple measurement results, to an O-DU capable of processing such an additional list (e.g., an O-DU supporting O-RAN M-plane version 7.0, or an O-DU supporting O-RAN M-plane version 7.0 or higher). This operation may be referred to as "method c". In an exemplary embodiment, an O-DU capable of processing the additional list of measurement results may be referred to as a "new O-DU", an O-DU that cannot process the additional list of measurement results may be referred to as an "existing O-DU", and an O-DU may represent a new O-DU and / or an existing O-DU.

[0522] The YANG model described above can be used as is in method c. However, when sending notifications to existing O-DUs, the additional list of measurement results can be omitted (e.g., additional-XXXX-measurement-result[] The O-RU can send a notification to a new O-DU, and can use only existing leaves. When sending a notification to a new O-DU, the sending of a leaf capable of sending a single measurement result can be omitted, and the O-RU can send an additional list of measurement results to the new O-DU, including multiple measurement results (e.g., ...). additional-XXXX-measurement-result[] In the additional measurement results list, all measurement results (e.g., measurements from the first to the last measurement result) can be arranged in chronological order.

[0523] The O-RU can send a notification to an existing O-DU that includes one measurement result for each measured object. In this case, the existing O-DU can set the O-RU's measurement interval and notification interval to be the same, so that one measurement result appears within one notification interval. Alternatively, when the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU can send only the most recent measurement result from the measurement results to the existing O-DU. Detailed methods for the above operations are described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multiple Measurement Result Reporting Functionality>.

[0524] When using the above method, in order to improve the decoding convenience of O-DU during notification reception, O-RU can increase the number of measurement results included in the supplementary measurement result list (e.g., number-of-additional-measurement- result The O-DU will be notified. The list of measurement results may include a serial number. seq-number The sequence numbers of measurement results in the measurement results list can start from 0 and can increase chronologically. By using the sequence number as the key value for the additional measurement results list, the O-DU can easily arrange the measurement results in chronological order. Furthermore, the O-DU can easily locate a specific measurement result using the sequence number.

[0525] Alternatively, the O-RU can send a single notification that includes multiple measurement results. In this case, the O-RU can generate multiple additional measurement result lists based on the multiple measurement results and send the notification including these additional measurement result lists to the O-DU. On the other hand, an O-RU that does not support the above operation can send a single measurement result to the O-DU using a leaf that supports sending only one measurement result. The existing O-DU cannot decode the additional measurement result lists and can instead ignore the new additional leaves (e.g., the additional measurement result lists). Therefore, errors may not occur in the existing O-DU.

[0526] Alternatively, during the transmission of measurement results, as in method a and / or method b, the O-RU can send a notification to the O-DU including a leaf and an additional list of measurement results, wherein the leaf includes a measurement result (e.g., one measurement result per measurement object, the most recent measurement result), and the additional list of measurement results includes multiple measurement results. All measurement values ​​among the multiple measurement values ​​can be included in the additional list of measurement results. This operation can be referred to as "method d". In this case, a measurement result (e.g., the most recent measurement result) can be included in both the existing leaf and the additional list of measurement results. When using method d, a measurement result is transmitted redundantly, but the O-RU does not need to distinguish the type of O-DU (e.g., existing O-DU or new O-DU). Additionally, in the absence of separate control parameters (e.g., ... enable- multiple-stats-in-notification In this case, the O-RU can send common notifications that can be decoded by both existing O-DUs and new O-DUs. In other words, the implementation complexity of the O-RU can be reduced.

[0527] Since the existing O-DU can decode a leaf containing a single measurement result, it can obtain a measurement result from a notification received from the O-RU. The new O-DU can decode an additional list of measurement results containing multiple measurement results and can perform processing operations based on multiple measurement results.

[0528] When a measurement result occurs for each measured object within a notification interval, the O-RU can send a leaf containing that measurement result. In this case, redundant information can be reduced. Alternatively, the O-RU can generate a leaf containing a measurement result and an additional list of measurement results containing the same measurement result, and send both the leaf containing the measurement result and the additional list of measurement results to the O-DU. That is, the same measurement result can be included in both the leaf containing the measurement result and the additional list of measurement results. In this case, the overhead due to the transmission of redundant information may increase, but the new O-DU can always decode the additional list of measurement results 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.

[0529] The new O-DU can support all the functions of the existing O-DU. Therefore, even when receiving an existing leaf containing a measurement result, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode additional measurement result lists. The existing O-DU can ignore additional measurement result lists (e.g., new leaves). Therefore, errors may not occur in the existing O-DU. The existing O-DU can receive an existing leaf containing a measurement result and can decode the existing leaf. In method d, the existing O-DU can always perform receive and decode operations on a single measurement result (e.g., the most recent measurement result). Therefore, the existing O-DU can operate according to the existing scheme. According to the above scheme, backward compatibility issues can be resolved. The detailed method of the above operation will be described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multi-Measurement Result Reporting Functionality>.

[0530] When using the above method, in order to improve the decoding convenience of O-DU during notification reception, O-RU can increase the number of measurement results included in the supplementary measurement result list (e.g., number-of-additional-measurement- result The notification is sent to the O-DU. The list of measurement results may include a serial number ( seq-number The sequence numbers of measurement results in the measurement results list can start from 0 and can increase chronologically. By using the sequence number as the key value for the additional measurement results list, the O-DU can easily arrange the measurement results in chronological order. Furthermore, the O-DU can easily locate a specific measurement result using the sequence number.

[0531] Method 2

[0532] In method 2, it is not necessary to use number-of-additional-measurement-result and seq- number And the start and end times can be used as additional measurement results in the list (e.g., additional-XXXXX- measurement list Keywords for each measurement object. Measurement results for each object can be arranged chronologically in an additional list of measurement results (e.g., ...). additional-XXXXX-measurement list )middle.

[0533] The structure of the YANG model based on Method 2 above can be defined as follows.

[0534] module:o-ran-performance-management

[0535] ... (omitted) ...

[0536] notifications:

[0537] +---n measurement-result-stats

[0538] +--ro transceiver-stats* [measurement-object]

[0539] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0540] | +--ro start-time? yang-types:date-and-time

[0541] | +--ro end-time? yang-types:date-and-time

[0542] | +--ro transceiver-measurement-result* [object-unit-id]

[0543] | | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0544] | | +--ro min

[0545] | | | +--ro value? decimal64

[0546] | | | +--ro time? yang-types:date-and-time

[0547] | | +--ro max

[0548] | | | +--ro value? decimal64

[0549] | | | +--ro time? yang-types:date-and-time

[0550] | | +--ro first

[0551] | | | +--ro value? decimal64

[0552] | | | +--ro time? yang-types:date-and-time

[0553] | | +--ro latest

[0554] | | | +--ro value? decimal64

[0555] | | | +--ro time? yang-types:date-and-time

[0556] | | +--ro frequeny-table* uint32

[0557] | +--ro additional-transceiver-measurement-result* [start-timeend-time]

[0558] | +--ro start-time yang-types:date-and-time

[0559] | +--ro end-time yang-types:date-and-time

[0560] | +--ro transceiver-measurement-result* [object-unit-id]

[0561] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0562] | +--ro min

[0563] | | +--ro value? decimal64

[0564] | | +--ro time? yang-types:date-and-time

[0565] | +--ro max

[0566] | | +--ro value? decimal64

[0567] | | +--ro time? yang-types:date-and-time

[0568] | +--ro first

[0569] | | +--ro value? decimal64

[0570] | | +--ro time? yang-types:date-and-time

[0571] | +--ro latest

[0572] | | +--ro value? decimal64

[0573] | | +--ro time? yang-types:date-and-time

[0574] | +--ro frequeny-table* uint32

[0575] +--ro rx-window-stats* [measurement-object]

[0576] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0577] | +--ro start-time? yang-types:date-and-time

[0578] | +--ro end-time? yang-types:date-and-time

[0579] | +--ro (object-unit-id)?

[0580] | | +--:(RU)

[0581] | | | +--ro name? -> / hw:hardware / component / name

[0582] | | | +--ro count uint64

[0583] | | +--:(TRANSPORT)

[0584] | | | +--ro tr-measured-result* []

[0585] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0586] | | | +--ro count uint64

[0587] | | +--:(EAXC_ID)

[0588] | | +--ro eaxc-measured-result* []

[0589] | | +--ro eaxc-id? uint16

[0590] | | +--ro count uint64

[0591] | | +--ro data-direction? Enumeration

[0592] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0593] | +--ro additional-rx-window-measurement-result* [start-timeend-time]

[0594] | +--ro start-time yang-types:date-and-time

[0595] | +--ro end-time yang-types:date-and-time

[0596] | +--ro (object-unit-id)?

[0597] | +--:(RU)

[0598] | | +--ro name? -> / hw:hardware / component / name

[0599] | | +--ro count uint64

[0600] | +--:(TRANSPORT)

[0601] | | +--ro tr-measured-result* []

[0602] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0603] | | +--ro count uint64

[0604] | +--:(EAXC_ID)

[0605] | +--ro eaxc-measured-result* []

[0606] | +--ro eaxc-id? uint16

[0607] | +--ro count uint64

[0608] | +--ro data-direction? Enumeration

[0609] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0610] +--ro tx-stats* [measurement-object]

[0611] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0612] | +--ro start-time? yang-types:date-and-time

[0613] | +--ro end-time? yang-types:date-and-time

[0614] | +--ro (object-unit-id)?

[0615] | | +--:(RU)

[0616] | | | +--ro name? -> / hw:hardware / component / name

[0617] | | | +--ro count uint64

[0618] | | +--:(TRANSPORT)

[0619] | | | +--ro tr-measured-result* []

[0620] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0621] | | | +--ro count uint64

[0622] | | +--:(EAXC_ID)

[0623] | | +--ro eaxc-measured-result* []

[0624] | | +--ro eaxc-id? uint16

[0625] | | +--ro count uint64

[0626] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0627] | +--ro additional-tx-measurement-result* [start-time end-time]

[0628] | +--ro start-time yang-types:date-and-time

[0629] | +--ro end-time yang-types:date-and-time

[0630] | +--ro (object-unit-id)?

[0631] | +--:(RU)

[0632] | | +--ro name? -> / hw:hardware / component / name

[0633] | | +--ro count uint64

[0634] | +--:(TRANSPORT)

[0635] | | +--ro tr-measured-result* []

[0636] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0637] | | +--ro count uint64

[0638] | +--:(EAXC_ID)

[0639] | +--ro eaxc-measured-result* []

[0640] | +--ro eaxc-id? uint16

[0641] | +--ro count uint64

[0642] | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name

[0643] x--ro epe-stats

[0644] | +--ro start-time? yang-types:date-and-time

[0645] | +--ro end-time? yang-types:date-and-time

[0646] | +--ro epe-measurement-result* [object-unit-id]

[0647] | +--ro object-unit-id -> / hw:hardware / component / class

[0648] | +--ro min? decimal64

[0649] | +--ro max? decimal64

[0650] | +--ro average? decimal64

[0651] +--ro epe-statistics* [measurement-object]

[0652] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[0653] +--ro start-time? yang-types:date-and-time

[0654] +--ro end-time? yang-types:date-and-time

[0655] +--ro epe-measurement-result* [object-unit-id]

[0656] | +--ro object-unit-id -> / hw:hardware / component / class

[0657] | +--ro min? decimal64

[0658] | +--ro max? decimal64

[0659] | +--ro average? decimal64

[0660] +--ro additional-epe-measurement-result* [start-time end-time]

[0661] +--ro start-time yang-types:date-and-time

[0662] +--ro end-time yang-types:date-and-time

[0663] +--ro epe-measurement-result* [object-unit-id]

[0664] +--ro object-unit-id -> / hw:hardware / component / class

[0665] +--ro min? decimal64

[0666] +--ro max? decimal64

[0667] +--ro average? decimal64

[0668] Alternatively, when the O-RU sends measurement results to an existing O-DU (e.g., an O-DU that supports a previous version of O-RAN M-plane 7.0, or an O-DU that cannot decode additional lists of measurement results), the O-RU may send a leaf (e.g., start-time, end-time, and ...) capable of transmitting a single measurement result. XXXX-measurement-result[] In addition, the O-RU can send an additional list of measurement results, including all multiple measurement results, to an O-DU capable of processing such lists (e.g., an O-DU supporting O-RAN M-plane version 7.0, or an O-DU supporting O-RAN M-plane version 7.0 or higher). This operation can be referred to as "method c".

[0669] The YANG model described above can be used as is in method c. However, when sending notifications to existing O-DUs, the additional list of measurement results can be omitted (e.g., additional-XXXX-measurement-result[] The O-RU can send a notification to a new O-DU, and can use only existing leaves. When sending a notification to a new O-DU, the sending of a leaf capable of sending a single measurement result can be omitted, and the O-RU can send an additional list of measurement results to the new O-DU including all multiple measurement results (e.g., ...). additional- XXXX-measurement-result[] In the additional measurement results list, all measurement results (e.g., measurements from the first to the last measurement result) can be arranged in chronological order.

[0670] The O-RU can send a notification to an existing O-DU that includes one measurement result for each measured object. In this case, the existing O-DU can set the O-RU's measurement interval and notification interval to be the same, so that one measurement result appears within one notification interval. Alternatively, when the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU can send only the most recent measurement result from the measurement results to the existing O-DU. Detailed methods for the above operations are described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multiple Measurement Result Reporting Functionality>.

[0671] When using the above method, it is not necessary to use number-of-additional-measurement-result and seq-number Start time and end time can be used as... additional-XXXXX-measurement list Keywords.

[0672] Alternatively, the O-RU can send a single notification that includes multiple measurement results. In this case, the O-RU can generate an additional list of measurement results based on the multiple results and send a notification including the additional list of measurement results to the O-DU. On the other hand, an O-RU that does not support the above operation can send a single measurement result to the O-DU using a leaf that supports sending a single measurement result. The existing O-DU cannot decode the additional list of measurement results and can instead ignore the new additional leaf (e.g., the additional list of measurement results). Therefore, errors may not occur in the existing O-DU.

[0673] Alternatively, during the transmission of measurement results, as in method a and / or method b, the O-RU can send a notification to the O-DU including a leaf and an additional list of measurement results, wherein the leaf includes a measurement result (e.g., one measurement result per measurement object, the most recent measurement result), and the additional list of measurement results includes multiple measurement results. All measurement values ​​among the multiple measurement values ​​can be included in the additional list of measurement results. This operation can be referred to as "method d". In this case, a measurement result (e.g., the most recent measurement result) can be included in both the existing leaf and the additional list of measurement results. When using method d, a measurement result is transmitted redundantly, but the O-RU does not need to distinguish the type of O-DU (e.g., existing O-DU or new O-DU). Additionally, in the absence of separate control parameters (e.g., ... enable-multiple- stats-in-notification In this case, the O-RU can send common notifications that can be decoded by both existing O-DUs and new O-DUs. In other words, the implementation complexity of the O-RU can be reduced.

[0674] Since the existing O-DU can process a leaf containing a single measurement result, it can obtain a measurement result from a notification received from the O-RU. The new O-DU can decode an additional list of measurement results containing multiple measurement results and can perform processing operations based on multiple measurement results.

[0675] When a measurement result occurs for each measured object within a notification interval, the O-RU can send a leaf containing that measurement result. This reduces redundant information. Alternatively, the O-RU can generate a leaf containing a measurement result and an additional list of measurement results, and send both to the O-DU. That is, the same measurement result can be included in both the leaf containing a measurement result and the additional list of measurement results. In this case, the overhead from sending redundant information may increase, but the new O-DU can always decode the additional list of measurement results instead of the existing leaf, regardless of the number of measurement results. This reduces the implementation complexity of the O-DU.

[0676] The new O-DU supports all the functions of the existing O-DU. Therefore, even when receiving an existing leaf containing a measurement result, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode additional measurement result lists. The existing O-DU can ignore additional measurement result lists (e.g., new leaves). Therefore, errors may not occur in the existing O-DU. The existing O-DU can receive an existing leaf containing a measurement result and can decode the leaf. In method d, the existing O-DU can always perform the receive and decode operations for a single measurement result (e.g., the most recent measurement result). Therefore, the existing O-DU can operate according to the existing scheme. According to the above scheme, backward compatibility issues can be resolved. The detailed method of the above operation will be described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multiple Measurement Result Reporting Functions>.

[0677] In method 2 above, it is not necessary to use number-of-additional-measurement-result and seq- number And can be used start-time and end-time As an additional list of measurement results (e.g., additional- XXXXX-measurement list Keywords.

[0678] Method 3

[0679] Optionally, it can be left unused. number-of-additional-measurement-result and seq- number And it is possible to not use targeting additional-XXXXX-measurement list The keyword. This operation can be "Method 3".

[0680] The structure of the YANG model according to method 3 can be as follows.

[0681] module:o-ran-performance-management

[0682] … (omitted)…=

[0683] notifications:

[0684] +---n measurement-result-stats

[0685] +--ro transceiver-stats* [measurement-object]

[0686] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0687] | +--ro start-time?yang-types:date-and-time

[0688] | +--ro end-time? yang-types:date-and-time

[0689] | +--ro transceiver-measurement-result* [object-unit-id]

[0690] | | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0691] | | +--ro min

[0692] | | | +--ro value? decimal64

[0693] | | | +--ro time? yang-types:date-and-time

[0694] | | +--ro max

[0695] | | | +--ro value? decimal64

[0696] | | | +--ro time? yang-types:date-and-time

[0697] | | +--ro first

[0698] | | | +--ro value? decimal64

[0699] | | | +--ro time? yang-types:date-and-time

[0700] | | +--ro latest

[0701] | | | +--ro value? decimal64

[0702] | | | +--ro time? yang-types:date-and-time

[0703] | | +--ro frequeny-table* uint32

[0704] | +--ro additional-transceiver-measurement-result* []

[0705] | +--ro start-time? yang-types:date-and-time

[0706] | +--ro end-time? yang-types:date-and-time

[0707] | +--ro transceiver-measurement-result* [object-unit-id]

[0708] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0709] | +--ro min

[0710] | | +--ro value? decimal64

[0711] | | +--ro time? yang-types:date-and-time

[0712] | +--ro max

[0713] | | +--ro value? decimal64

[0714] | | +--ro time? yang-types:date-and-time

[0715] | +--ro first

[0716] | | +--ro value? decimal64

[0717] | | +--ro time? yang-types:date-and-time

[0718] | +--ro latest

[0719] | | +--ro value? decimal64

[0720] | | +--ro time? yang-types:date-and-time

[0721] | +--ro frequeny-table* uint32

[0722] +--ro rx-window-stats* [measurement-object]

[0723] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0724] | +--ro start-time? yang-types:date-and-time

[0725] | +--ro end-time? yang-types:date-and-time

[0726] | +--ro (object-unit-id)?

[0727] | | +--:(RU)

[0728] | | | +--ro name? -> / hw:hardware / component / name

[0729] | | | +--ro count uint64

[0730] | | +--:(TRANSPORT)

[0731] | | | +--ro tr-measured-result* []

[0732] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0733] | | | +--ro count uint64

[0734] | | +--:(EAXC_ID)

[0735] | | +--ro eaxc-measured-result* []

[0736] | | +--ro eaxc-id? uint16

[0737] | | +--ro count uint64

[0738] | | +--ro data-direction? Enumeration

[0739] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0740] | +--ro additional-rx-window-measurement-result* []

[0741] | +--ro start-time? yang-types:date-and-time

[0742] | +--ro end-time? yang-types:date-and-time

[0743] | +--ro (object-unit-id)?

[0744] | +--:(RU)

[0745] | | +--ro name? -> / hw:hardware / component / name

[0746] | | +--ro count uint64

[0747] | +--:(TRANSPORT)

[0748] | | +--ro tr-measured-result* []

[0749] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0750] | | +--ro count uint64

[0751] | +--:(EAXC_ID)

[0752] | +--ro eaxc-measured-result* []

[0753] | +--ro eaxc-id? uint16

[0754] | +--ro count uint64

[0755] | +--ro data-direction? Enumeration

[0756] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0757] +--ro tx-stats* [measurement-object]

[0758] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0759] | +--ro start-time? yang-types:date-and-time

[0760] | +--ro end-time? yang-types:date-and-time

[0761] | +--ro (object-unit-id)?

[0762] | | +--:(RU)

[0763] | | | +--ro name? -> / hw:hardware / component / name

[0764] | | | +--ro count uint64

[0765] | | +--:(TRANSPORT)

[0766] | | | +--ro tr-measured-result* []

[0767] | | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0768] | | | +--ro count uint64

[0769] | | +--:(EAXC_ID)

[0770] | | +--ro eaxc-measured-result* []

[0771] | | +--ro eaxc-id? uint16

[0772] | | +--ro count uint64

[0773] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0774] | +--ro additional-tx-measurement-result* []

[0775] | +--ro start-time? yang-types:date-and-time

[0776] | +--ro end-time? yang-types:date-and-time

[0777] | +--ro (object-unit-id)?

[0778] | +--:(RU)

[0779] | | +--ro name? -> / hw:hardware / component / name

[0780] | | +--ro count uint64

[0781] | +--:(TRANSPORT)

[0782] | | +--ro tr-measured-result* []

[0783] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0784] | | +--ro count uint64

[0785] | +--:(EAXC_ID)

[0786] | +--ro eaxc-measured-result* []

[0787] | +--ro eaxc-id? uint16

[0788] | +--ro count uint64

[0789] | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name

[0790] x--ro epe-stats

[0791] | +--ro start-time? yang-types:date-and-time

[0792] | +--ro end-time? yang-types:date-and-time

[0793] | +--ro epe-measurement-result* [object-unit-id]

[0794] | +--ro object-unit-id -> / hw:hardware / component / class

[0795] | +--ro min? decimal64

[0796] | +--ro max? decimal64

[0797] | +--ro average? decimal64

[0798] +--ro epe-statistics* [measurement-object]

[0799] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[0800] +--ro start-time? yang-types:date-and-time

[0801] +--ro end-time? yang-types:date-and-time

[0802] +--ro epe-measurement-result* [object-unit-id]

[0803] | +--ro object-unit-id -> / hw:hardware / component / class

[0804] | +--ro min? decimal64

[0805] | +--ro max? decimal64

[0806] | +--ro average? decimal64

[0807] +--ro additional-epe-measurement-result* []

[0808] +--ro start-time?yang-types:date-and-time

[0809] +--ro end-time?yang-types:date-and-time

[0810] +--ro epe-measurement-result* [object-unit-id]

[0811] +--ro object-unit-id -> / hw:hardware / component / class

[0812] +--ro min? decimal64

[0813] +--ro max? decimal64

[0814] +--ro average? decimal64

[0815] Alternatively, when the O-RU sends measurement results to an existing O-DU (e.g., an O-DU that supports a previous version of O-RAN M-plane 7.0, or an O-DU that cannot decode additional measurement result lists), the O-RU may send a leaf (e.g., capable of sending a single measurement result) that can transmit a measurement result. start-time , end-time and XXXX-measurement-result[] In addition, the O-RU can send an additional list of measurement results, including all multiple measurement results, to an O-DU capable of processing such lists (e.g., an O-DU supporting O-RAN M-plane version 7.0, or an O-DU supporting O-RAN M-plane version 7.0 or higher). This operation can be referred to as "method c".

[0816] The YANG model described above can be used as is in method c. However, when sending notifications to existing O-DUs, the additional list of measurement results can be omitted (e.g., additional-XXXX-measurement-result[] The O-RU can send a notification to a new O-DU, and can use only existing leaves. When sending a notification to a new O-DU, the sending of a leaf capable of sending a single measurement result can be omitted, and the O-RU can send an additional list of measurement results to the new O-DU including all multiple measurement results (e.g., ...). additional- XXXX-measurement-result[] In the additional measurement results list, all measurement results (e.g., measurements from the first to the last measurement result) can be arranged in chronological order.

[0817] The O-RU can send a notification to an existing O-DU that includes one measurement result for each measured object. In this case, the existing O-DU can set the O-RU's measurement interval and notification interval to be the same, so that one measurement result appears within one notification interval. Alternatively, when the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU can send only the most recent measurement result from the measurement results to the existing O-DU. Detailed methods for the above operations are described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multiple Measurement Result Reporting Functionality>.

[0818] In the above method, it is not necessary to use number-of-additional-measurement-result and seq- number And in additional-XXXXX-measurement list Keywords can be omitted. Based on this method, the YANG code can be defined as follows.

[0819] grouping measurement-notification {

[0820] description

[0821] "notification may contain measurement result for transceiver-stats

[0822] and / or rx-window-stats and / or tx-stats and / or epe-stats";

[0823] list transceiver-stats {

[0824] key"measurement-object";

[0825] description

[0826] "measurement result of transceiver-measurement per measurement-object";

[0827] leaf measurement-object {

[0828] type leafref {

[0829] path" / performance-measurement-objects / transceiver-measurement-objects / measurement-object";

[0830] }

[0831] description

[0832] "measurement-object for the transceiver-measurement";

[0833] }

[0834] uses start-and-end-time; / / start-and-end-time of the firstresult

[0835] uses transceiver-measurement-result-grouping; / / First result

[0836] / / For additional measurement result

[0837] list additional-transceiver-measurement-result {

[0838] / / when measurement-interval<notification interval

[0839] config false;

[0840] description

[0841] "Multiple measurement results of transceiver-measurement";

[0842] uses start-and-end-time;

[0843] uses transceiver-measurement-result-grouping;

[0844] }

[0845] }

[0846] list rx-window-stats {

[0847] key"measurement-object";

[0848] description

[0849] "measurement result for the reception window measurement per

[0850] measurement-object";

[0851] leaf measurement-object {

[0852] type leafref {

[0853] path" / performance-measurement-objects / rx-window-measurement-objects / measurement-object";

[0854] }

[0855] description

[0856] "measurement-object for the reception window measurement";

[0857] }

[0858] uses start-and-end-time;

[0859] uses rx-window-measurement-result-grouping;

[0860] / / For additional measurement result

[0861] list additional-rx-window-measurement-result {

[0862] / / when measurement-interval<notification interval

[0863] config false;

[0864] description

[0865] "Multiple measurement results of rx-window-measurement";

[0866] uses start-and-end-time;

[0867] uses rx-window-measurement-result-grouping;

[0868] }

[0869] }

[0870] list tx-stats {

[0871] key"measurement-object";

[0872] description

[0873] "measurement result for the tx stats measurement per

[0874] measurement-object";

[0875] leaf measurement-object {

[0876] type leafref {

[0877] path" / performance-measurement-objects / tx-measurement-objects / measurement-object";

[0878] }

[0879] description

[0880] "measurement-object for the tx stats measurement";

[0881] }

[0882] uses start-and-end-time;

[0883] uses tx-measurement-result-grouping;

[0884] / / For additional measurement result

[0885] list additional-tx-measurement-result {

[0886] / / when measurement-interval<notification interval

[0887] config false;

[0888] description

[0889] "Multiple measurement result of tx-measurement";

[0890] uses start-and-end-time;

[0891] uses tx-measurement-result-grouping;

[0892] }

[0893] }

[0894] container epe-stats {

[0895] description

[0896] "container for the epe stats measurement - deprecated becausemeasurement object isn't included";

[0897] status deprecated;

[0898] uses start-and-end-time;

[0899] uses epe-measurement-result-grouping;

[0900] }

[0901] list epe-statistics {

[0902] key"measurement-object";

[0903] description

[0904] "measurement result for the epe stats measurement per

[0905] measurement-object";

[0906] leaf measurement-object {

[0907] type leafref {

[0908] path" / performance-measurement-objects / epe-measurement-objects / measurement-object";

[0909] }

[0910] description

[0911] "measurement-object for the epe stats measurement";

[0912] }

[0913] uses start-and-end-time;

[0914] uses epe-measurement-result-grouping;

[0915] list additional-epe-measurement-result {

[0916] / / when measurement-interval <notification interval

[0917] config false;

[0918] description

[0919] "Multiple measurement result of epe-measurement";

[0920] uses start-and-end-time;

[0921] uses epe-measurement-result-grouping;

[0922] }

[0923] }

[0924] }

[0925] Alternatively, the O-RU can send a notification that includes multiple measurement results. In this case, the O-RU can generate an additional list of measurement results based on the multiple measurement results and send a notification including the additional list of measurement results to the O-DU. On the other hand, an O-RU that does not support the above operation can send a single measurement result to the O-DU using a leaf that supports sending a single measurement result. The existing O-DU cannot decode the additional list of measurement results and can ignore the new additional leaf (e.g., the additional list of measurement results). Therefore, errors may not occur in the existing O-DU.

[0926] Alternatively, during the transmission of measurement results, as in method a and / or method b, the O-RU can send a notification to the O-DU including a leaf and an additional list of measurement results, wherein the leaf includes a measurement result (e.g., one measurement result per measurement object, the most recent measurement result), and the additional list of measurement results includes multiple measurement results. All measurement values ​​among the multiple measurement values ​​can be included in the additional list of measurement results. This operation can be referred to as "method d". In this case, a measurement result (e.g., the most recent measurement result) can be included in both the existing leaf and the additional list of measurement results. When using method d, a measurement result is transmitted redundantly, but the O-RU does not need to distinguish the type of O-DU (e.g., existing O-DU or new O-DU). Additionally, in the absence of separate control parameters (e.g., ...), enable-multiple- stats-in-notification In this case, the O-RU can send common notifications that can be decoded by both existing O-DUs and new O-DUs. In other words, the implementation complexity of the O-RU can be reduced.

[0927] Since the existing O-DU can decode a leaf containing a single measurement result, it can obtain a measurement result from a notification received from the O-RU. The new O-DU can decode an additional list of measurement results containing multiple measurement results and can perform processing operations based on multiple measurement results.

[0928] When a measurement result occurs for each measured object within a notification interval, the O-RU can send a leaf containing that measurement result. This reduces redundant information. Alternatively, the O-RU can generate a leaf containing a measurement result and an additional list of measurement results, and send both to the O-DU. That is, the same measurement result can be included in both the leaf containing a measurement result and the additional list of measurement results. In this case, the overhead from sending redundant information may increase, but the new O-DU can always decode the additional list of measurement results instead of the existing leaf, regardless of the number of measurement results. This reduces the implementation complexity of the O-DU.

[0929] The new O-DU supports all the functions of the existing O-DU. Therefore, even when receiving an existing leaf containing a measurement result, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode additional measurement result lists. The existing O-DU can ignore additional measurement result lists (e.g., new leaves). Therefore, errors may not occur in the existing O-DU. The existing O-DU can receive an existing leaf containing a measurement result and can decode the existing leaf. In method d, the existing O-DU can always perform receive and decode operations for a single measurement result (e.g., the most recent measurement result). Therefore, the existing O-DU can operate according to the existing scheme. According to the above scheme, backward compatibility issues can be resolved. The detailed method of the above operation will be described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multi-Measurement Result Reporting Functionality>.

[0930] In the above method, it is not necessary to use number-of-additional-measurement-result and seq- number And it is not necessary to use additional-XXXXX-measurement list Keywords. Methods a, b, c, and d, as well as combinations and / or variations of the above methods, can be used.

[0931] [Exemplary implementation of method A]

[0932] In the exemplary embodiment according to [Method A], the parameters can be set as shown in Table 3 below.

[0933] [Table 3]

[0934]

[0935] Based on the configuration in Table 3, the O-RU can send a notification to the O-DU including two measurement results for measurement object A and four measurement results for measurement object B.

[0936] When using method a, the first measurement result for measurement object A (e.g., the measurement value during the 0 to 30 minute measurement period) can be included in the transceiver-stats in the notification, and the values ​​corresponding to the 0 to 30 minute measurement period can be set. start-time and end-time A second measurement result for measurement object A (e.g., a measurement value within a measurement period of 30 to 60 minutes) can be included. additional-transceiver-measurement-result It can also be set to correspond to measurement periods of 30 to 60 minutes. start-time and end-time .

[0937] The first measurement result for measurement object B (e.g., the measurement value during the 0 to 15 minute measurement period) can be included in the rx-window-stats in the notification, and the values ​​corresponding to the 0 to 15 minute measurement period can be set. start- time and end-time The second measurement result for measurement object B (e.g., a measurement value during a measurement period of 15 to 30 minutes), the third measurement result for measurement object B (e.g., a measurement value during a measurement period of 30 to 45 minutes), and the fourth measurement result for measurement object B (e.g., a measurement value during a measurement period of 45 to 60 minutes) can be included in additional-rx-window-measurement-result, and can be set to correspond to each of the 15 to 30 minute, 30 to 45 minute, and 45 to 60 minute measurement periods. start-time and end- time When using method b, you can... additional-transceiver-measurement-result and additional-rx-window-measurement-result The system can configure measurement results from the first measurement result to the measurement result just before the last measurement result, and the last measurement result can be configured in the existing transceiver-stats and rx-window-stats (e.g., existing rx-window-stats) of each of measurement objects A and B.

[0938] To arrange measurement results in chronological order in an additional measurement results list in a communication system, key values ​​can be used. start-time and end-time Set to "Sort by user".

[0939] When using method c, the transceiver-stats for measurement object A can be omitted from the notification, and the first measurement result (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) for measurement object A can be included in the notification. additional-transceiver- measurement-result In the notification, the rx-window-stats for measurement object B can be omitted, and the first measurement result (e.g., the measurement value in the measurement period of 0 to 15 minutes), the second measurement result (e.g., the measurement value in the measurement period of 15 to 30 minutes), the third measurement result (e.g., the measurement value in the measurement period of 30 to 45 minutes), and the fourth measurement result (e.g., the measurement value in the measurement period of 45 to 60 minutes) for measurement object B can all be included. additional-rx-window-measurement-result middle.

[0940] When method d is used, a measurement result for measurement object A (e.g., the last measurement value in the notification interval (e.g., the measurement value in the 30-60 minute measurement period)) can be included in the transceiver-stats within the notification. The first measurement result for measurement object A (e.g., the measurement value in the 0-30 minute measurement period) and the second measurement result (e.g., the measurement value in the 30-60 minute measurement period) can also be included in the notification. additional- transceiver-measurement-result In the notification, a measurement result for measurement object B (e.g., the last measurement value in the notification interval (e.g., the measurement value in a measurement period of 45 to 60 minutes)) can be included in the rx-window-stats within the notification. The first measurement result for measurement object B (e.g., the measurement value in a measurement period of 0 to 15 minutes), the second measurement result (e.g., the measurement value in a measurement period of 15 to 30 minutes), the third measurement result (e.g., the measurement value in a measurement period of 30 to 45 minutes), and the fourth measurement result (e.g., the measurement value in a measurement period of 45 to 60 minutes) can all be included. additional-rx-window-measurement-result middle.

[0941] As an improvement on [Method A], additional-transceiver-measurement-result , additional-rx-window-measurement-result , additional-tx-measurement-result and additional-epe-measurement-result It can be excluded from the notification and instead included separately at the beginning of the YANG module. transceiver-measurement-result , rx-window-measurement-result , tx- measurement-result and epe-measurement-result In other words, it belongs to the front part of the YANG module. transceiver-measurement-result , rx-window-measurement-result , tx-measurement- result and epe-measurement-result It is scalable. The O-DU can identify the corresponding measurement result by using "getRPC" instead of a notification scheme. In this case, there may be overhead due to the O-DU periodically sending "getRPC".

[0942] [Method B]

[0943] Method B includes measurement results for all measured objects. measurement-result-stats The entire structure can be repeatedly added to the notification in chronological order for the corresponding measurement time.

[0944] In method A, the YANG model can be extended to include an additional list of measurement results (e.g., additional- transceiver-measurement-result List additional-rx-window-measurement-result List additional-tx-measurement-result List additional-epe-measurement-result The list is included in the statistics of the measurement objects belonging to transceiver-stats, rx-window-stats, tx-stats, and epe-statistics, respectively. In method B, it is not necessary to add the additional list of measurement results to the statistics of the corresponding measurement object for each measurement object, and the entire structure of measurement-result-stats, which includes the measurement results of all measurement objects, can be added to the notification in chronological order for the corresponding measurement time.

[0945] <Method B-1>

[0946] According to Method B-1, the YANG model can be defined as follows.

[0947] module:o-ran-performance-management

[0948] ... (omitted) ...

[0949] notifications:

[0950] +---n measurement-result-stats

[0951] +--ro transceiver-stats* [measurement-object]

[0952] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[0953] | +--ro start-time?yang-types:date-and-time

[0954] | +--ro end-time? yang-types:date-and-time

[0955] | +--ro transceiver-measurement-result* [object-unit-id]

[0956] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[0957] | +--ro min

[0958] | | +--ro value? decimal64

[0959] | | +--ro time? yang-types:date-and-time

[0960] | +--ro max

[0961] | | +--ro value? decimal64

[0962] | | +--ro time? yang-types:date-and-time

[0963] | +--ro first

[0964] | | +--ro value? decimal64

[0965] | | +--ro time? yang-types:date-and-time

[0966] | +--ro latest

[0967] | | +--ro value? decimal64

[0968] | | +--ro time? yang-types:date-and-time

[0969] | +--ro frequeny-table* uint32

[0970] +--ro rx-window-stats* [measurement-object]

[0971] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[0972] | +--ro start-time? yang-types:date-and-time

[0973] | +--ro end-time? yang-types:date-and-time

[0974] | +--ro (object-unit-id)?

[0975] | +--:(RU)

[0976] | | +--ro name? -> / hw:hardware / component / name

[0977] | | +--ro count uint64

[0978] | +--:(TRANSPORT)

[0979] | | +--ro tr-measured-result* []

[0980] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0981] | | +--ro count uint64

[0982] | +--:(EAXC_ID)

[0983] | +--ro eaxc-measured-result* []

[0984] | +--ro eaxc-id? uint16

[0985] | +--ro count uint64

[0986] | +--ro data-direction? Enumeration

[0987] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[0988] +--ro tx-stats* [measurement-object]

[0989] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[0990] | +--ro start-time? yang-types:date-and-time

[0991] | +--ro end-time? yang-types:date-and-time

[0992] | +--ro (object-unit-id)?

[0993] | +--:(RU)

[0994] | | +--ro name? -> / hw:hardware / component / name

[0995] | | +--ro count uint64

[0996] | +--:(TRANSPORT)

[0997] | | +--ro tr-measured-result* []

[0998] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[0999] | | +--ro count uint64

[1000] | +--:(EAXC_ID)

[1001] | +--ro eaxc-measured-result* []

[1002] | +--ro eaxc-id? uint16

[1003] | +--ro count uint64

[1004] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1005] x--ro epe-stats

[1006] | +--ro start-time? yang-types:date-and-time

[1007] | +--ro end-time? yang-types:date-and-time

[1008] | +--ro epe-measurement-result* [object-unit-id]

[1009] | +--ro object-unit-id -> / hw:hardware / component / class

[1010] | +--ro min? decimal64

[1011] | +--ro max? decimal64

[1012] | +--ro average? decimal64

[1013] +--ro epe-statistics* [measurement-object]

[1014] | +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1015] | +--ro start-time? yang-types:date-and-time

[1016] | +--ro end-time? yang-types:date-and-time

[1017] | +--ro epe-measurement-result* [object-unit-id]

[1018] | +--ro object-unit-id -> / hw:hardware / component / class

[1019] | +--ro min? decimal64

[1020] | +--ro max? decimal64

[1021] | +--ro average? decimal64

[1022] +--ro number-of-additional-measurement-result-stats? uint8

[1023] +--ro additional-measurement-result-stats* [seq-number]

[1024] +--ro seq-number uint8

[1025] +--ro transceiver-stats* [measurement-object]

[1026] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[1027] | +--ro start-time? yang-types:date-and-time

[1028] | +--ro end-time? yang-types:date-and-time

[1029] | +--ro transceiver-measurement-result* [object-unit-id]

[1030] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[1031] | +--ro min

[1032] | | +--ro value? decimal64

[1033] | | +--ro time? yang-types:date-and-time

[1034] | +--ro max

[1035] | | +--ro value? decimal64

[1036] | | +--ro time? yang-types:date-and-time

[1037] | +--ro first

[1038] | | +--ro value? decimal64

[1039] | | +--ro time? yang-types:date-and-time

[1040] | +--ro latest

[1041] | | +--ro value? decimal64

[1042] | | +--ro time? yang-types:date-and-time

[1043] | +--ro frequeny-table* uint32

[1044] +--ro rx-window-stats* [measurement-object]

[1045] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[1046] | +--ro start-time? yang-types:date-and-time

[1047] | +--ro end-time? yang-types:date-and-time

[1048] | +--ro (object-unit-id)?

[1049] | +--:(RU)

[1050] | | +--ro name? -> / hw:hardware / component / name

[1051] | | +--ro count uint64

[1052] | +--:(TRANSPORT)

[1053] | | +--ro tr-measured-result* []

[1054] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1055] | | +--ro count uint64

[1056] | +--:(EAXC_ID)

[1057] | +--ro eaxc-measured-result* []

[1058] | +--ro eaxc-id? uint16

[1059] | +--ro count uint64

[1060] | +--ro data-direction? Enumeration

[1061] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1062] +--ro tx-stats* [measurement-object]

[1063] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[1064] | +--ro start-time? yang-types:date-and-time

[1065] | +--ro end-time? yang-types:date-and-time

[1066] | +--ro (object-unit-id)?

[1067] | +--:(RU)

[1068] | | +--ro name? -> / hw:hardware / component / name

[1069] | | +--ro count uint64

[1070] | +--:(TRANSPORT)

[1071] | | +--ro tr-measured-result* []

[1072] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1073] | | +--ro count uint64

[1074] | +--:(EAXC_ID)

[1075] | +--ro eaxc-measured-result* []

[1076] | +--ro eaxc-id? uint16

[1077] | +--ro count uint64

[1078] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1079] x--ro epe-stats

[1080] | +--ro start-time? yang-types:date-and-time

[1081] | +--ro end-time? yang-types:date-and-time

[1082] | +--ro epe-measurement-result* [object-unit-id]

[1083] | +--ro object-unit-id -> / hw:hardware / component / class

[1084] | +--ro min? decimal64

[1085] | +--ro max? decimal64

[1086] | +--ro average? decimal64

[1087] +--ro epe-statistics* [measurement-object]

[1088] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1089] +--ro start-time? yang-types:date-and-time

[1090] +--ro end-time? yang-types:date-and-time

[1091] +--ro epe-measurement-result* [object-unit-id]

[1092] +--ro object-unit-id -> / hw:hardware / component / class

[1093] +--ro min? decimal64

[1094] +--ro max? decimal64

[1095] +--ro average? decimal64

[1096] The improved YANG code can be defined as follows.

[1097] notification measurement-result-stats {

[1098] description

[1099] "Notification may contain measurement results for transceiver-stats and / or rx-window-stats";

[1100] uses measurement-notification;

[1101] / / For sending additional measurement result when notification-interval is larger than measurement-interval

[1102] leaf number-of-additional-measurement-result-stats {

[1103] type uint8;

[1104] description

[1105] "This parameter indicates the number of additionalmeasurement result stats.";

[1106] }

[1107] list additional-measurement-result-stats {

[1108] / / For sending additional measurement result stats whennotification-interval is larger than measurement-interval

[1109] description

[1110] "Additional measurement result stats are included

[1111] when notification-interval is larger than measurement-interval

[1112] and 'enable-multiple-stats-in-notification' is true.";

[1113] key seq-number;

[1114] leaf seq-number {

[1115] / / sequence number in ascending order starting from 1

[1116] type uint8 {

[1117] range"1..max";

[1118] }

[1119] }

[1120] uses measurement-notification;

[1121] }

[1122] }

[1123] When 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, an additional statistical list of measurement results can be used (e.g., additional-measurement-result-stats This adds the entire structure of measurement-result-stats to the notification for each measurement period in ascending chronological order. Measurement-result-stats includes measurement results for all measurement objects within the measurement period belonging to each of transceiver-stats, rx-window-stats, tx-stats, and epe-statistics.

[1124] The supplementary measurement results statistics list can include measurement information for each of all measured objects within a measurement period (e.g., measurement start time, measurement end time, and / or measurement value). The structure of an entry included in the supplementary measurement results statistics list can be the same as the existing structure of measurement-result-stats that only supports one measurement result. The difference between the above structures may be the presence of indicators indicating the number of entries included in the supplementary measurement results statistics list (e.g., ...). number-of-additional-measurement-result-stats ) and the serial number included in each entry of the supplementary statistical list of measurement results (e.g., seq-number The serial number can be used to easily arrange entries in chronological order within the additional statistical list of measurement results. number-of-additional- measurement-result-stats It can indicate the inclusion of a in the additional measurement results statistics list. dditional- measurement-result-stats The number of entries. O-DU can be based on... number-of-additional- measurement-result-stats To facilitate the decoding of notifications.

[1125] Furthermore, O-DU entries can be easily arranged chronologically in the supplementary measurement results statistics list based on their serial numbers. When using method a, the serial numbers can increase in ascending order from 1. When using method b, the serial numbers can increase in ascending order from 0. When using method a, entries are included in the existing... measurement-result-stats The measurement results in the above can be considered as the zeroth measurement result. When using method b, including existing... measurement-result-stats The measurement results in this process can be considered the final measurement results. This is achieved by using the sequence number as... additional-measurement-result-stats The key values, O-DU can be easily arranged in chronological order. measurement-result-stats Furthermore, O-DUs can be easily located using serial numbers in a specific order. measurement-result-stats .

[1126] To reduce the number of transmitted parameters, it is possible to omit using... number-of-additional-measurement- result-stats In the NETCONF / YANG model, even without explicit instructions... additional-measurement- result-stats When the number of items included in the list is shown, the recipient can also know the number of items. number-of- additional-measurement-result-stats It can be used to facilitate decoding on the receiving end.

[1127] You can leave it unset. additional-measurement-results-stats The keyword. When no keyword is set, the O-DU may not be able to directly access a specific entry in the supplementary measurement results statistics list, and the entire supplementary measurement results statistics list should always be decoded. In the existing YANG model, a notification may include only one measurement result. If the measurement result is changed to a list of measurement results, backward compatibility issues may occur with fronthaul devices (e.g., O-DU and / or O-RU) that use the existing YANG model. In the YANG model proposed in this disclosure, the existing YANG model can be used as is. measurement-result-stats The information structure of the notification (e.g., start-time , end-time , measurement-result The existing YANG model measurement-result-stats The notification may include the first measurement result. Compared to existing YANG models, the proposed YANG model may also include an additional statistical list of measurement results. This additional statistical list may include measurement results from the second measurement result onwards. Measurement results may be arranged in chronological order (e.g., ascending order of measurement time) within the additional statistical list. This operation may be "method a". According to method a, since the measurement-related parameters used in existing YANG models are used as is, backward compatibility issues may not occur.

[1128] In other words, only one part of a notification can be decoded. measurement-result-stats Existing O-DUs may be able to decode existing parameters (e.g., transceiver-stats, rx-window-stats, tx-stats, epe-stats). In this case, even if the O-RU sends a notification that includes multiple measurement results, the existing O-DU may successfully receive only one measurement result.

[1129] Optionally, the O-RU can utilize existing measurement result parameters to configure the last measurement result among multiple measurements, and can generate an additional statistical list of measurement results (e.g., additional-measurement-result- stat The additional statistical list of measurement results includes measurements from the first measurement result up to the measurement result exactly before the last measurement result. This operation can be "method b". According to method b, an existing O-DU can receive a measurement result that is the most recent measurement result.

[1130] In order to sort a list of additional measurement statistics in a communication system in chronological order, the sequence number of the key value can be defined as "sorted by user".

[1131] [Exemplary embodiment of method B-1]

[1132] In an exemplary embodiment according to method B-1, the parameters can be set as shown in Table 4 below.

[1133] [Table 4]

[1134]

[1135] Based on the configuration in Table 4, the O-RU can send a notification to the O-DU including two measurement results for measurement object A and four measurement results for measurement object B. In this case, the determination can be based on the measurement interval for measurement object B, which has a shorter measurement interval. measurement-result-stats The number of entries in the table.

[1136] When method a is used, the first measurement result for measurement object B can be included in the existing... measurement- results-stats Furthermore, because the measurement operation for object A has not yet been completed, the measurement results for object A may not be included in the existing data. measurement-results-stats In other words, the existing... measurement- results-stats Measurement results can be included within a measurement period of 0 to 15 minutes.

[1137] additional-measurement-result-stats The first entry may include the results of a measurement operation performed during a measurement period of 15 to 30 minutes (e.g., a second measurement result for measurement object B and a first measurement result for measurement object A). additional-measurement-result-stats The second entry may include the results of a measurement operation completed within a measurement period of 30 to 45 minutes (e.g., a third measurement result for measurement object B). additional-measurement-result-stats The third entry may include the results of measurement operations performed during a measurement period of 45 to 60 minutes (e.g., a fourth measurement result for measurement object B and a second measurement result for measurement object A). When using method b, it is possible to... additional-measurement-result-stats The configuration allows you to view measurement results from the first measurement result up to the measurement result just before the last measurement result, and this can be done within the existing... measurement-result-stat Configure the final measurement results. This operation can also be applied to <Method B-2>, which will be described later.

[1138] As an improvement on [Method B], additional-measurement-result-stats It can be excluded from the notification, but instead included at the beginning of the YANG model. transceiver-measurement-result , rx- window-measurement-result , tx-measurement-result and epe-measurement-result Subsequently, O-DU can identify multiple [users / resources] by using "getRPC" instead of a notification scheme. measurement-result-stats In this scenario, the O-DU can periodically send "getRPC", which may incur overhead accordingly.

[1139] <Method B-2>

[1140] In method B-2, it is not necessary to use number-of-additional-measurement-result-stats and seq-number And it is possible to not use targeting additional-measurement-result-stats The key of the list. In this case, additional-measurement-result-stats The structure included in an entry of the list can be similar to an existing list that includes a measurement result. measurement-result-stats same.

[1141] The YANG model according to method B-2 can be defined as follows.

[1142] module:o-ran-performance-management

[1143] ... (omitted) ...

[1144] notifications:

[1145] +---n measurement-result-stats

[1146] +--ro transceiver-stats* [measurement-object]

[1147] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[1148] | +--ro start-time?yang-types:date-and-time

[1149] | +--ro end-time? yang-types:date-and-time

[1150] | +--ro transceiver-measurement-result* [object-unit-id]

[1151] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[1152] | +--ro min

[1153] | | +--ro value? decimal64

[1154] | | +--ro time? yang-types:date-and-time

[1155] | +--ro max

[1156] | | +--ro value? decimal64

[1157] | | +--ro time? yang-types:date-and-time

[1158] | +--ro first

[1159] | | +--ro value? decimal64

[1160] | | +--ro time? yang-types:date-and-time

[1161] | +--ro latest

[1162] | | +--ro value? decimal64

[1163] | | +--ro time? yang-types:date-and-time

[1164] | +--ro frequeny-table* uint32

[1165] +--ro rx-window-stats* [measurement-object]

[1166] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[1167] | +--ro start-time? yang-types:date-and-time

[1168] | +--ro end-time? yang-types:date-and-time

[1169] | +--ro (object-unit-id)?

[1170] | +--:(RU)

[1171] | | +--ro name? -> / hw:hardware / component / name

[1172] | | +--ro count uint64

[1173] | +--:(TRANSPORT)

[1174] | | +--ro tr-measured-result* []

[1175] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1176] | | +--ro count uint64

[1177] | +--:(EAXC_ID)

[1178] | +--ro eaxc-measured-result* []

[1179] | +--ro eaxc-id? uint16

[1180] | +--ro count uint64

[1181] | +--ro data-direction? Enumeration

[1182] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1183] +--ro tx-stats* [measurement-object]

[1184] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[1185] | +--ro start-time? yang-types:date-and-time

[1186] | +--ro end-time? yang-types:date-and-time

[1187] | +--ro (object-unit-id)?

[1188] | +--:(RU)

[1189] | | +--ro name? -> / hw:hardware / component / name

[1190] | | +--ro count uint64

[1191] | +--:(TRANSPORT)

[1192] | | +--ro tr-measured-result* []

[1193] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1194] | | +--ro count uint64

[1195] | +--:(EAXC_ID)

[1196] | +--ro eaxc-measured-result* []

[1197] | +--ro eaxc-id? uint16

[1198] | +--ro count uint64

[1199] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1200] x--ro epe-stats

[1201] | +--ro start-time? yang-types:date-and-time

[1202] | +--ro end-time? yang-types:date-and-time

[1203] | +--ro epe-measurement-result* [object-unit-id]

[1204] | +--ro object-unit-id -> / hw:hardware / component / class

[1205] | +--ro min? decimal64

[1206] | +--ro max? decimal64

[1207] | +--ro average? decimal64

[1208] +--ro epe-statistics* [measurement-object]

[1209] | +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1210] | +--ro start-time? yang-types:date-and-time

[1211] | +--ro end-time? yang-types:date-and-time

[1212] | +--ro epe-measurement-result* [object-unit-id]

[1213] | +--ro object-unit-id -> / hw:hardware / component / class

[1214] | +--ro min? decimal64

[1215] | +--ro max? decimal64

[1216] | +--ro average? decimal64

[1217] +--ro additional-measurement-result-stats* []

[1218] +--ro transceiver-stats* [measurement-object]

[1219] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[1220] | +--ro start-time? yang-types:date-and-time

[1221] | +--ro end-time? yang-types:date-and-time

[1222] | +--ro transceiver-measurement-result* [object-unit-id]

[1223] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[1224] | +--ro min

[1225] | | +--ro value? decimal64

[1226] | | +--ro time? yang-types:date-and-time

[1227] | +--ro max

[1228] | | +--ro value? decimal64

[1229] | | +--ro time? yang-types:date-and-time

[1230] | +--ro first

[1231] | | +--ro value? decimal64

[1232] | | +--ro time? yang-types:date-and-time

[1233] | +--ro latest

[1234] | | +--ro value? decimal64

[1235] | | +--ro time? yang-types:date-and-time

[1236] | +--ro frequeny-table* uint32

[1237] +--ro rx-window-stats* [measurement-object]

[1238] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[1239] | +--ro start-time? yang-types:date-and-time

[1240] | +--ro end-time? yang-types:date-and-time

[1241] | +--ro (object-unit-id)?

[1242] | +--:(RU)

[1243] | | +--ro name? -> / hw:hardware / component / name

[1244] | | +--ro count uint64

[1245] | +--:(TRANSPORT)

[1246] | | +--ro tr-measured-result* []

[1247] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1248] | | +--ro count uint64

[1249] | +--:(EAXC_ID)

[1250] | +--ro eaxc-measured-result* []

[1251] | +--ro eaxc-id? uint16

[1252] | +--ro count uint64

[1253] | +--ro data-direction? Enumeration

[1254] | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1255] +--ro tx-stats* [measurement-object]

[1256] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[1257] | +--ro start-time? yang-types:date-and-time

[1258] | +--ro end-time? yang-types:date-and-time

[1259] | +--ro (object-unit-id)?

[1260] | +--:(RU)

[1261] | | +--ro name? -> / hw:hardware / component / name

[1262] | | +--ro count uint64

[1263] | +--:(TRANSPORT)

[1264] | | +--ro tr-measured-result* []

[1265] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1266] | | +--ro count uint64

[1267] | +--:(EAXC_ID)

[1268] | +--ro eaxc-measured-result* []

[1269] | +--ro eaxc-id? uint16

[1270] | +--ro count uint64

[1271] | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name

[1272] x--ro epe-stats

[1273] | +--ro start-time? yang-types:date-and-time

[1274] | +--ro end-time? yang-types:date-and-time

[1275] | +--ro epe-measurement-result* [object-unit-id]

[1276] | +--ro object-unit-id -> / hw:hardware / component / class

[1277] | +--ro min? decimal64

[1278] | +--ro max? decimal64

[1279] | +--ro average? decimal64

[1280] +--ro epe-statistics* [measurement-object]

[1281] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1282] +--ro start-time? yang-types:date-and-time

[1283] +--ro end-time? yang-types:date-and-time

[1284] +--ro epe-measurement-result* [object-unit-id]

[1285] +--ro object-unit-id -> / hw:hardware / component / class

[1286] +--ro min? decimal64

[1287] +--ro max? decimal64

[1288] +--ro average? decimal64

[1289] The improved YANG code can be defined as follows.

[1290] notification measurement-result-stats {

[1291] description

[1292] "Notification may contain measurement results for transceiver-stats and / or rx-window-stats";

[1293] uses measurement-notification;

[1294] / / For sending additional measurement result when notification-interval is larger than measurement-interval

[1295] list additional-measurement-result-stats {

[1296] / / For sending additional measurement result stats whennotification-interval is larger than measurement-interval

[1297] description

[1298] "Additional measurement result stats are includedwhen notification-interval is larger than measurement-interval and 'enable-multiple-stats-in-notification' is true.";

[1299] uses measurement-notification;

[1300] }

[1301] }

[1302] <Method for ensuring backward compatibility and interoperability with devices that do not support the multi-measurement result reporting function>

[1303] Existing O-RUs (e.g., O-RUs supporting versions earlier than O-RAN M-plane version 7.0) cannot send a single notification containing multiple measurement results. That is, a notification can include only one measurement result. When the O-DU sets the measurement interval and notification interval to the same value, since only one measurement result is included in a notification, all measurement results can be sent and received through separate notifications. This operation can be referred to as (method alpha).

[1304] When the O-DU sets the notification interval to be longer than the measurement interval, the O-RU (e.g., an existing O-RU that cannot send a single notification containing multiple measurement results) can send a notification to the O-DU that includes only the most recent measurement result among multiple measurement results. This operation can be referred to as (method beta). The existing O-DU cannot interpret a notification that includes multiple measurement results. Therefore, when using (method alpha), it is possible to prevent the existing O-DU from receiving a list that includes multiple measurement results. Furthermore, when using (method alpha), it is possible to prevent the O-RU (e.g., a new O-RU) from sending multiple measurement results using a single notification. This operation can be particularly useful in cases where measurement results are sent to an existing O-DU that cannot interpret a notification that includes multiple measurement results. Even when the O-DU (e.g., an existing O-DU or a new O-DU) wants to receive a notification that includes only some measurement results in order to reduce the processing load on the communication system, (method beta) can also be useful.

[1305] Even when the O-RU can send a single notification containing multiple measurement results, the O-DU can limit the number of measurement results included in the notification to one to reduce the burden of processing measurement results. For example, even when the notification interval is longer than the measurement interval, the O-DU can... enable-multiple-stats-in-notification If set to false, the O-RU can send a notification that includes one of multiple measurements (e.g., the most recent measurement).

[1306] when enable-multiple-stats-in-notification When the default value is defined as false and the new O-RU operates together with the existing O-DU, due to enable-multiple-stats-in-notification It is always set to false, so even when the notification interval is set to a later interval than the measurement interval, the new O-RU can still send a measurement result (e.g., the most recent measurement result) to an existing O-DU. When enable-multiple-stats-in-notification The default value is defined as false, and when the new O-RU operates with the new O-DU, both a notification that includes one measurement result and a notification that includes multiple measurement results can be used.

[1307] The new O-DU can replace the new O-RU. enable-multiple-stats-in-notification Set to false. In this case, the new O-RU can use a leaf that supports the transmission of a measurement result to send a measurement result to the new O-DU. Alternatively, the new O-RU can send a list of measurement results, including a measurement result, to the new O-DU. The new O-RU can use a leaf that supports the transmission of a measurement result to send a notification to an existing O-DU.

[1308] The YANG model of the O-RU can indicate the O-RAN M-plane version supported by the O-RU. Therefore, the O-DU can identify whether the O-RU supports the function of sending a single notification that includes multiple measurement results (i.e., multi-measurement result reporting function) based on the O-RAN M-plane version supported by the O-RU.

[1309] As another way to limit the number of measurements included in a notification to reduce the burden of processing those measurements, a maximum number of measurements can be specified for a single notification. max-number-of-measurement- result-per-notification In other words, it can be max-number-of-measurement-result-per- notification Add to the YANG model. O-DU can set parameters to O-RU. max-number-of-measurement- result-per-notification The O-RU can send a notification to the O-DU, wherein the notification includes less than or equal to the value specified by the O-DU. max-number-of-measurement-result-per-notification Indicates the maximum number of measurements.

[1310] When using methods a, b, c, and / or d, backward compatibility and interoperability with devices that do not support multiple measurement result notifications are guaranteed. However, when using methods a, b, c, and / or d, the O-RU may not know whether a notification including multiple measurement results can be decoded by the O-DU.

[1311] When the O-DU supports O-RAN M-plane versions earlier than 7.0, or when the O-DU supporting O-RAN M-plane version 7.0 or higher does not support decoding multiple measurement results, or when the O-DU supporting O-RAN M-plane version 7.0 or higher does not use the decoding function for multiple measurement results, if the O-RU sends a notification including multiple measurement results, the O-DU may be unable to decode the multiple measurement results. Furthermore, the O-DU may not know whether the O-RU supports the multiple measurement result reporting function. If the notification interval of an O-RU that does not support the multiple measurement result reporting function is set to be longer than the measurement interval, the O-DU may not be able to receive certain measurement results from the O-RU.

[1312] To address the aforementioned issues, the O-RU can notify the O-DU whether it supports the multi-measurement result reporting function. This capability-related parameters can be indicated to the O-DU via the M-direction. The O-DU can then identify whether the O-RU supports the multi-measurement result reporting function based on these parameters. When the O-RU supports the multi-measurement result reporting function, the O-DU can command the O-RU to enable it. When the multi-measurement result reporting function is explicitly enabled, the O-RU can send a notification to the O-DU including multiple measurement results. This operation can be referred to as (Method I). To support (Method I), existing methods can be extended as follows: o-ran-performance-management.yang Module.

[1313] +--rw transceiver-measurement-interval? uint16

[1314] +--rw epe-measurement-interval? uint16

[1315] +--rw rx-window-measurement-interval? uint16

[1316] +--rw tx-measurement-interval? uint16

[1317] +--rw notification-interval? uint16

[1318] +--rw file-upload-interval? uint16

[1319] +--ro max-bin-count uint16

[1320] +--ro multiple-stats-in-notification-capable? boolean

[1321] +--rw enable-multiple-stats-in-notification? boolean

[1322] In other words, you can add to the YANG module. romultiple-stats-in-notification-capable and rwenable-multiple-stats-in-notification The extended YANG code according to (Method I) can be defined as follows.

[1323] module:o-ran-performance-management

[1324] ... (omitted) ….

[1325] leaf max-bin-count{

[1326] type uint16;

[1327] config false;

[1328] mandatory true;

[1329] description

[1330] "indicates the maximum value of configurable bin-count forfrequency table in transceiver-measurement-objects as one of modulecapabilities.";

[1331] }

[1332] leaf multiple-stats-in-notification-capable{

[1333] type boolean;

[1334] config false;

[1335] default false;

[1336] description

[1337] "Flag to indicate whether the O-RU is capable of sending anotification including multiple stats when notification-interval is largerthan measurement-interval.";

[1338] }

[1339] leaf enable-multiple-stats-in-notification {

[1340] type boolean;

[1341] default false;

[1342] description

[1343] "Flag to enable multiple stats to be included in onenotification

[1344] when notification-interval is larger than measurement-intervaland 'multiple-stats-in-notification-capable' is true.";

[1345] }

[1346] multiple-stats-in-notification-capable This could be an O-RU indicator of whether it supports the ability to report multiple measurement results when the notification interval is longer than the measurement interval. multiple-stats-in-notification- capable The default value can be false.

[1347] Can be configured by O-DU enable-multiple-stats-in-notification When O-RU's multiple- stats-in-notification-capable When set to true, O-DU can enable-multiple-stats-in- notification Set to true. In this case, when the notification interval is longer than the measurement interval, the O-RU can send a single notification to the O-DU that includes multiple measurement results. enable-multiple-stats-in-notification The default value can be false.

[1348] An O-DU can decode multiple measurement results included in a single notification, and an O-RU may not support multi-measurement result reporting. That is, an O-DU can be a new O-DU, and an O-RU can be an existing O-RU. In this case, the YANG parameter of the O-RU may not be present. multiple-stats-in-notification-capable In other words, because multiple-stats-in-notification-capable If the setting is set to the default value (i.e., false), the O-DU can determine that the O-RU does not support the multiple measurement result reporting function. In this case, the O-DU can either not use the multiple measurement result reporting function or set the O-RU's parameters so that the notification interval is no longer than the measurement interval. Even a new O-RU may not support the multiple measurement result reporting function. In this case, the O-RU can... multiple-stats-in-notification-capable Set to false. If the new O-RU multiple-stats-in-notification-capable If set to false, the O-DU can disable the multiple measurement result reporting function. Optionally, the O-DU can set the parameters of the O-RU so that the notification interval is no longer than the measurement interval.

[1349] When the O-RU supports multiple measurement result reporting but the O-DU does not, the O-DU may not need to report the O-RU's results. enable-multiple-stats-in-notification Set to true. Therefore, the O-RU may not send a single notification containing multiple measurement results to the O-DU.

[1350] Unable to interpret enable-multiple-stats-in-notification Existing O-DUs may not be able to be set up enable-multiple-stats-in-notification In this case, it can be enable-multiple- stats-in-notification Set to the default value (i.e., false). Therefore, the O-RU may not send a single notification containing multiple measurement results to the O-DU.

[1351] As a variation of the above method, the 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 higher) can always support multi-measurement result reporting functionality. This operation can be referred to as (Method II). In this case, it may not be necessary to use... multiple-stats-in-notification-capable The O-DU can identify whether an O-RU is an existing O-RU based on information from the O-RAN M-plane version of the YANG model. If the O-DU identifies an O-RU as an existing O-RU, the O-DU can set the measurement interval and notification interval for the existing O-RU in the same way. If the O-DU identifies an O-RU as a new O-RU, since a new O-RU can send multiple measurement lists in a single notification, the O-DU can set the measurement interval and notification interval for the new O-RU differently.

[1352] When the notification interval is set to be longer than the measurement interval, an existing O-RU can send a single notification to the O-DU, including the most recent measurement result from the measurement results. In this case, it is not necessary to... multiple-stats-in- notification-capable Therefore, it is possible to simply include enable-multiple-stats-in-notification Add to the YANG model. enable-multiple-stats-in-notification The default value can be set to false. When O-DU will enable-multiple-stats-in-notification When set to true, and the notification interval of the O-RU is longer than the measurement interval, the O-RU can send a single notification to the O-DU that includes multiple measurement results.

[1353] To reduce the burden of processing measurement results, such as in (method beta), O-DU can limit the number of measurement results included in a single notification to one. enable-multiple-stats-in-notification Set to false, and even when the notification interval is longer than the measurement interval, the O-RU can send a notification to the O-DU including the most recent measurement result from multiple measurements. When enable-multiple-stats-in-notification When the default value is set to false and the new O-RU operates with an existing O-DU, due to the O-RU's enable-multiple-stats-in- notification The value is always set to false, so when the notification interval is longer than the measurement interval, the new O-RU can send one of the multiple measurement results (e.g., the most recent measurement result) to the O-DU.

[1354] When the new O-RU operates together with the new O-DU, a single notification including one measurement result and a single notification including multiple measurement results can be used. When the new O-DU transmits data from the new O-RU... enable-multiple-stats-in-notification When set to false, the new O-RU can send a measurement result using an existing leaf that supports the transmission of a measurement result or an additional list of measurement results. The new O-RU can send a measurement result to an existing O-DU by using an existing leaf that supports the transmission of a measurement result.

[1355] Even when the new O-RU optionally supports multi-measurement result reporting, the above (Method II) can still be used. This operation can be referred to as (Method III). In this case, it is not necessary to add to the YANG model. multiple-stats-in- notification-capable It can be enable-multiple-stats-in-notification Add to the YANG model. When O-DU will enable-multiple-stats-in-notification When set 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 send a measurement result to the O-DU using an existing leaf that supports sending a single measurement result. The remaining operations are the same as described above (Method II).

[1356] The new O-RU can optionally support multiple measurement lists and can be used without adding to the YANG model. multiple- stats-in-notification-capable and enable-multiple-stats-in-notification Both. This operation can be referred to as (Method IV). An O-RU that supports multiple measurement result reporting can generate a list of measurement results including multiple measurement results and can send a notification including the list of measurement results. An O-RU that does not support multiple measurement result reporting can send a single measurement result to an O-DU by using an existing leaf that supports sending a single measurement result.

[1357] When using methods a, b, and / or d, an existing leaf containing a single measurement result can be sent along with a list of measurement results containing multiple measurements. An existing O-DU (e.g., an O-DU supporting the legacy YANG model) may not be able to decode the list of measurement results included in the notification and may ignore the new leaf (e.g., the list of measurement results). Therefore, errors may not occur in the existing O-DU.

[1358] (other)

[1359] When an existing O-DU operates alongside a new O-RU, and the existing O-DU sets its measurement interval to equal the notification interval of the new O-RU, it prevents the existing O-DU from receiving a single notification from the new O-RU that includes multiple measurement results. Since a single measurement result occurs within a single notification interval, the new O-RU can send a single notification including only one measurement result, according to the existing protocol. When using this method, it is not necessary to use... multiple-stats-in-notification-capable and enable-multiple-stats-in-notification When a measurement result is sent using an existing leaf instead of an additional list of measurement results, the existing O-DU is always able to decode the measurement result. Therefore, no backward compatibility issues occur. The above operation can be used in method c.

[1360] When using method c, existing O-DUs can set the measurement interval and notification interval to be the same. In this case, only one measurement result can appear in a notification interval. O-RUs can send a measurement result to an existing O-DU using an existing leaf that supports sending a single measurement result. The existing O-DU can decode the measurement result received from the O-RU. New O-DUs can set the notification interval to be longer than the measurement interval. In this case, multiple measurement results can appear in a single notification interval. The O-RU can generate a list of measurement results including multiple measurement results and can send a notification including the list of measurement results to the new O-DU. The new O-DU can decode the list of measurement results received from the O-RU. That is, when 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.

[1361] In methods a, b, and / or d, the notification can always include an existing leaf that supports the transmission of a measurement result. Therefore, since the existing O-DU can decode the notification received from the O-RU, no backward compatibility issues occur.

[1362] The above method can ensure backward compatibility and interoperability with devices that do not support multiple measurement result reporting.

[1363] To prevent the sending of a single notification containing multiple measurement results, a separate notification interval parameter can be used for each measurement object. The notification interval can be set for each measurement object. The notification intervals for measurement objects can be set differently. For example, separate parameters can be set for each measurement object. transceiver-notification-interval , rx-window- notification-interval , tx-stats-notification-interval , epe-stats-notification- interval and / or rssi-stats-notification-interval The parameters can be set such that even when the measurement intervals of the measured objects are different from each other, the notification interval for each measured object can be set to be no longer than the measurement interval of the corresponding measured object. According to the above method, it is possible to prevent the sending of a single notification containing multiple measurement results.

[1364] Various measurement objects can be introduced into the O-RAN, and multi-measurement result reporting functionality for new measurement objects, according to the methods described above, can be applied. For example, notifications for RSSI objects (e.g., time-domain RSSI objects) can be defined as follows.

[1365] notification

[1366] ... (omitted) ...

[1367] +--ro symbol-rssi-stats* [measurement-object]

[1368] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1369] +--ro start-time?yang-types:date-and-time

[1370] +--ro end-time?yang-types:date-and-time

[1371] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1372] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1373] +--ro per-symbol-index-result* [symbol-index]

[1374] +--ro symbol-index uint16

[1375] +--ro min

[1376] | +--ro value? int16

[1377] +--ro max

[1378] | +--ro value? int16

[1379] +--ro avg

[1380] | +--ro value? int16

[1381] +--ro frequency-table* uint32

[1382] ... (omitted) ...

[1383] As described above, a notification that includes a single measurement result can be extended in a manner similar to that described above. That is, a notification can be extended to include multiple measurement results. For example, applying method A in the first scenario, the YANG model can be defined as follows.

[1384] +---n measurement-result-stats ...

[1385] +--ro symbol-rssi-stats* [measurement-object]

[1386] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1387] +--ro start-time?yang-types:date-and-time

[1388] +--ro end-time?yang-types:date-and-time

[1389] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1390] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1391] +--ro per-symbol-index-result* [symbol-index]

[1392] +--ro symbol-index uint16

[1393] +--ro min

[1394] | +--ro value? int16

[1395] +--ro max

[1396] | +--ro value? int16

[1397] +--ro avg

[1398] | +--ro value? int16

[1399] +--ro frequency-table* uint32

[1400] +--ro number-of-additional-measurement-result? uint8

[1401] +--ro additional-symbol-rssi-measurement-result* [seq-number]

[1402] +--ro seq-number uint8

[1403] +--ro start-time? yang-types:date-and-time

[1404] +--ro end-time? yang-types:date-and-time

[1405] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1406] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1407] +--ro per-symbol-index-result* [symbol-index]

[1408] +--ro symbol-index uint16

[1409] +--ro min

[1410] +--ro value? int16

[1411] +--ro max

[1412] +--ro value? int16

[1413] +--ro avg

[1414] +--ro value? int16

[1415] +--ro frequency-table* uint32

[1416] The second approach to applying method A, the YANG model, can be defined as follows.

[1417] notifications:

[1418] +---n measurement-result-stats ...

[1419] +--ro symbol-rssi-stats* [measurement-object]

[1420] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1421] +--ro start-time? yang-types:date-and-time

[1422] +--ro end-time? yang-types:date-and-time

[1423] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1424] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1425] +--ro per-symbol-index-result* [symbol-index]

[1426] +--ro symbol-index uint16

[1427] +--ro min

[1428] | +--ro value? int16

[1429] +--ro max

[1430] | +--ro value? int16

[1431] +--ro avg

[1432] | +--ro value? int16

[1433] +--ro frequency-table* uint32

[1434] +--ro additional-symbol-rssi-measurement-result* [start-timeend-time]

[1435] +--ro start-time? yang-types:date-and-time

[1436] +--ro end-time? yang-types:date-and-time

[1437] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1438] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1439] +--ro per-symbol-index-result* [symbol-index]

[1440] +--ro symbol-index uint16

[1441] +--ro min

[1442] +--ro value? int16

[1443] +--ro max

[1444] +--ro value? int16

[1445] +--ro avg

[1446] +--ro value? int16

[1447] +--ro frequency-table* uint32

[1448] The third approach to applying method A, the YANG model, can be defined as follows.

[1449] notifications:

[1450] +---n measurement-result-stats ...

[1451] +--ro symbol-rssi-stats* [measurement-object]

[1452] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1453] +--ro start-time? yang-types:date-and-time

[1454] +--ro end-time? yang-types:date-and-time

[1455] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1456] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1457] +--ro per-symbol-index-result* [symbol-index]

[1458] +--ro symbol-index uint16

[1459] +--ro min

[1460] | +--ro value? int16

[1461] +--ro max

[1462] | +--ro value? int16

[1463] +--ro avg

[1464] | +--ro value? int16

[1465] +--ro frequency-table* uint32

[1466] +--ro additional-symbol-rssi-measurement-result* []

[1467] +--ro start-time? yang-types:date-and-time

[1468] +--ro end-time? yang-types:date-and-time

[1469] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1470] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1471] +--ro per-symbol-index-result* [symbol-index]

[1472] +--ro symbol-index uint16

[1473] +--ro min

[1474] +--ro value? int16

[1475] +--ro max

[1476] +--ro value? int16

[1477] +--ro avg

[1478] +--ro value? int16

[1479] +--ro frequency-table* uint32

[1480] The first approach to applying method B, the YANG model, can be defined as follows.

[1481] notifications:

[1482] +---n measurement-result-stats

[1483] +--ro transceiver-stats* [measurement-object] ...

[1484] +--ro rx-window-stats* [measurement-object] ...

[1485] +--ro tx-stats* [measurement-object] ...

[1486] +--ro epe-statistics* [measurement-object] ...

[1487] +--ro symbol-rssi-stats* [measurement-object] ...

[1488] +--ro number-of-additional-measurement-result-stats? uint8

[1489] +--ro additional-measurement-result-stats* [seq-number]

[1490] +--ro seq-number uint8

[1491] +--ro transceiver-stats* [measurement-object] ...

[1492] +--ro rx-window-stats* [measurement-object] ...

[1493] +--ro tx-stats* [measurement-object] ...

[1494] +--ro epe-statistics* [measurement-object] ...

[1495] +--ro symbol-rssi-stats* [measurement-object]

[1496] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1497] +--ro start-time? yang-types:date-and-time

[1498] +--ro end-time? yang-types:date-and-time

[1499] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1500] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1501] +--ro per-symbol-index-result* [symbol-index]

[1502] +--ro symbol-index uint16

[1503] +--ro min

[1504] +--ro value? int16

[1505] +--ro max

[1506] +--ro value? int16

[1507] +--ro avg

[1508] +--ro value? int16

[1509] +--ro frequency-table* uint32

[1510] The second approach to applying method B, the YANG model, can be defined as follows.

[1511] notifications:

[1512] +---n measurement-result-stats

[1513] +--ro transceiver-stats* [measurement-object] ...

[1514] +--ro rx-window-stats* [measurement-object] ...

[1515] +--ro tx-stats* [measurement-object] ...

[1516] +--ro epe-statistics* [measurement-object] ...

[1517] +--ro symbol-rssi-stats* [measurement-object] ..

[1518] +--ro additional-measurement-result-stats* []

[1519] +--ro transceiver-stats* [measurement-object] ...

[1520] +--ro rx-window-stats* [measurement-object] ...

[1521] +--ro tx-stats* [measurement-object] ...

[1522] +--ro epe-statistics* [measurement-object] ...

[1523] +--ro symbol-rssi-stats* [measurement-object]

[1524] +--ro measurement-object -> / performance-measurement-objects / symbol-rssi-measurement-objects / measurement-object

[1525] +--ro start-time? yang-types:date-and-time

[1526] +--ro end-time? yang-types:date-and-time

[1527] +--ro symbol-rssi-measurement-result* [object-unit-id]

[1528] +--ro object-unit-id -> / up:user-plane-configuration / rx-array-carriers / name

[1529] +--ro per-symbol-index-result* [symbol-index]

[1530] +--ro symbol-index uint16

[1531] +--ro min

[1532] +--ro value? int16

[1533] +--ro max

[1534] +--ro value? int16

[1535] +--ro avg

[1536] +--ro value? int16

[1537] +--ro frequency-table* uint32

[1538] <Methods for sending separate notifications containing multiple measurement results>

[1539] Without adding to existing notifications additional-xxxx-measurement-result In this case, the O-RU can send a separate notification that includes multiple measurement results.

[1540] In method c of the third scheme of [method A], it is possible to send including additional-xxxx-measurement- result A separate notification. The YANG model used for this operation can be defined as follows.

[1541] module:o-ran-performance-management

[1542] ... (omitted) ...

[1543] notifications:

[1544] +---n measurement-result-stats

[1545] | +--ro transceiver-stats* [measurement-object]

[1546] | | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[1547] | | +--ro start-time? yang-types:date-and-time

[1548] | | +--ro end-time? yang-types:date-and-time

[1549] | | +--ro transceiver-measurement-result* [object-unit-id]

[1550] | | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[1551] | | +--ro min

[1552] | | | +--ro value? decimal64

[1553] | | | +--ro time? yang-types:date-and-time

[1554] | | +--ro max

[1555] | | | +--ro value? decimal64

[1556] | | | +--ro time? yang-types:date-and-time

[1557] | | +--ro first

[1558] | | | +--ro value? decimal64

[1559] | | | +--ro time? yang-types:date-and-time

[1560] | | +--ro latest

[1561] | | | +--ro value? decimal64

[1562] | | | +--ro time? yang-types:date-and-time

[1563] | | +--ro frequeny-table* uint32

[1564] | +--ro rx-window-stats* [measurement-object]

[1565] | | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[1566] | | +--ro start-time? yang-types:date-and-time

[1567] | | +--ro end-time? yang-types:date-and-time

[1568] | | +--ro (object-unit-id)?

[1569] | | +--:(RU)

[1570] | | | +--ro name? -> / hw:hardware / component / name

[1571] | | | +--ro count uint64

[1572] | | +--:(TRANSPORT)

[1573] | | | +--ro tr-measured-result* []

[1574] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name

[1575] | | | +--ro count uint64

[1576] | | +--:(EAXC_ID)

[1577] | | +--ro eaxc-measured-result* []

[1578] | | +--ro eaxc-id? uint16

[1579] | | +--ro count uint64

[1580] | | +--ro data-direction? enumeration

[1581] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1582] | +--ro tx-stats* [measurement-object]

[1583] | | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[1584] | | +--ro start-time? yang-types:date-and-time

[1585] | | +--ro end-time? yang-types:date-and-time

[1586] | | +--ro (object-unit-id)?

[1587] | | +--:(RU)

[1588] | | | +--ro name? -> / hw:hardware / component / name

[1589] | | | +--ro count uint64

[1590] | | +--:(TRANSPORT)

[1591] | | | +--ro tr-measured-result* []

[1592] | | | +--ro name?-> / o-ran-elements:processing-elements / ru-elements / name

[1593] | | | +--ro count uint64

[1594] | | +--:(EAXC_ID)

[1595] | | +--ro eaxc-measured-result* []

[1596] | | +--ro eaxc-id? uint16

[1597] | | +--ro count uint64

[1598] | | +--ro transport-name? -> / o-ran-elements:processing-elements / ru-elements / name

[1599] | x--ro epe-stats

[1600] | | +--ro start-time? yang-types:date-and-time

[1601] | | +--ro end-time? yang-types:date-and-time

[1602] | | +--ro epe-measurement-result* [object-unit-id]

[1603] | | +--ro object-unit-id -> / hw:hardware / component / class

[1604] | | +--ro min? decimal64

[1605] | | +--ro max? decimal64

[1606] | | +--ro average? decimal64

[1607] | +--ro epe-statistics* [measurement-object]

[1608] | +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1609] | +--ro start-time? yang-types:date-and-time

[1610] | +--ro end-time? yang-types:date-and-time

[1611] | +--ro epe-measurement-result* [object-unit-id]

[1612] | +--ro object-unit-id -> / hw:hardware / component / class

[1613] | +--ro min? decimal64

[1614] | +--ro max? decimal64

[1615] | +--ro average? decimal64

[1616] +---n multiple-measurement-result-stats

[1617] +--ro multiple-transceiver-stats* [measurement-object]

[1618] | +--ro measurement-object -> / performance-measurement-objects / transceiver-measurement-objects / measurement-object

[1619] | +--ro additional-transceiver-measurement-result* []

[1620] | +--ro start-time? yang-types:date-and-time

[1621] | +--ro end-time? yang-types:date-and-time

[1622] | +--ro transceiver-measurement-result* [object-unit-id]

[1623] | +--ro object-unit-id -> / if:interfaces / interface / o-ran-int:port-reference / port-number

[1624] | +--ro min

[1625] | | +--ro value? decimal64

[1626] | | +--ro time? yang-types:date-and-time

[1627] | +--ro max

[1628] | | +--ro value? decimal64

[1629] | | +--ro time? yang-types:date-and-time

[1630] | +--ro first

[1631] | | +--ro value? decimal64

[1632] | | +--ro time? yang-types:date-and-time

[1633] | +--ro latest

[1634] | | +--ro value? decimal64

[1635] | | +--ro time? yang-types:date-and-time

[1636] | +--ro frequeny-table* uint32

[1637] +--ro multiple-rx-window-stats* [measurement-object]

[1638] | +--ro measurement-object -> / performance-measurement-objects / rx-window-measurement-objects / measurement-object

[1639] | +--ro additional-rx-window-measurement-result* []

[1640] | +--ro start-time? yang-types:date-and-time

[1641] | +--ro end-time? yang-types:date-and-time

[1642] | +--ro (object-unit-id)?

[1643] | +--:(RU)

[1644] | | +--ro name? -> / hw:hardware / component / name

[1645] | | +--ro count uint64

[1646] | +--:(TRANSPORT)

[1647] | | +--ro tr-measured-result* []

[1648] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1649] | | +--ro count uint64

[1650] | +--:(EAXC_ID)

[1651] | +--ro eaxc-measured-result* []

[1652] | +--ro eaxc-id? uint16

[1653] | +--ro count uint64

[1654] | +--ro data-direction? enumeration

[1655] | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name

[1656] +--ro multiple-tx-stats* [measurement-object]

[1657] | +--ro measurement-object -> / performance-measurement-objects / tx-measurement-objects / measurement-object

[1658] | +--ro additional-tx-measurement-result* []

[1659] | +--ro start-time? yang-types:date-and-time

[1660] | +--ro end-time? yang-types:date-and-time

[1661] | +--ro (object-unit-id)?

[1662] | +--:(RU)

[1663] | | +--ro name? -> / hw:hardware / component / name

[1664] | | +--ro count uint64

[1665] | +--:(TRANSPORT)

[1666] | | +--ro tr-measured-result* []

[1667] | | +--ro name? -> / o-ran-elements:processing-elements / ru-elements / name

[1668] | | +--ro count uint64

[1669] | +--:(EAXC_ID)

[1670] | +--ro eaxc-measured-result* []

[1671] | +--ro eaxc-id? uint16

[1672] | +--ro count uint64

[1673] | +--ro transport-name?-> / o-ran-elements:processing-elements / ru-elements / name

[1674] +--ro multiple-epe-statistics* [measurement-object]

[1675] +--ro measurement-object -> / performance-measurement-objects / epe-measurement-objects / measurement-object

[1676] +--ro additional-epe-measurement-result* []

[1677] +--ro start-time? yang-types:date-and-time

[1678] +--ro end-time? yang-types:date-and-time

[1679] +--ro epe-measurement-result* [object-unit-id]

[1680] +--ro object-unit-id -> / hw:hardware / component / class

[1681] +--ro min? decimal64

[1682] +--ro max? decimal64

[1683] +--ro average? decimal64

[1684] As a notification for transmitting a single measurement result, result-stats can be used without modification, and as a notification for transmitting multiple measurement results... multiple-measurement-result-stats It can be redefined. O-RU can generate data including multiple measurement results. additional-XXXX-measurement-result [] And can send additional-XXXX-measurement-result[] Except for defining the portion used to transmit multiple measurement results as a separate notification, the remaining details can be the same as in [Method A].

[1685] The exemplary embodiments described above can be an improved method c of [method A], and can use separate notifications. The O-RU can use a leaf (e.g., one that supports the transmission of a measurement result) to provide this information. start-time , end-time and XXXX- measurement-result[] The existing measurement-result-stats notification can be used to send a measurement result to an existing O-DU, and a new one that includes all multiple measurement results can be sent. multiple-measurement-result- stats Send to the new O-DU. multiple-measurement-result-stats It can include additional-XXXX- measurement-result[] ,and additional-XXXX-measurement-result[] It can include multiple measurement results. All measurement results (e.g., measurement results from the first measurement result to the last measurement result) can be included. additional-XXXX-measurement-result[] Arranged chronologically.

[1686] Existing O-DU sent to existing measurement-result-stats The notification may include a measurement result for each measured object. In this case, an existing O-DU can set the measurement interval and notification interval of the O-RU to be the same, such that a measurement result is generated at one notification interval. Alternatively, when the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU may include the most recent measurement result from the existing measurement results. measurement- result-stats The notification is sent to the O-DU. Detailed methods for the above operations are described in <Methods for Ensuring Backward Compatibility and Interoperability with Devices That Do Not Support Multi-Measurement Result Reporting Functionality>.

[1687] When using methods a, b, and / or d of [Method A], existing leaves and new lists can be sent as separate notifications in the same manner as the methods described above. That is, in methods a, b, and / or d of [Method A], existing leaves and new lists can be used... measurement-result-stats The notification (i.e., the existing leaf) is used to send a measurement result, and can be used... multiple-measurement-result-stats Notifications (i.e., new lists) are sent to send multiple measurement results.

[1688] When O-RU multiple-stats-in-notification-capable When set to false, O-DU can identify only measurements that include a single measurement result. measurement-result-stats Notification (i.e., existing notification). When O-RU's multiple-stats-in-notification-capable When set to true, O-DU can enable-multiple- stats-in-notification Set to true, and it can receive multiple measurement results. multiple- measurement-result-stats Notification (i.e., new notification). Even when the O-RU supports multi-measurement result reporting, the O-DU can still reduce the burden on the O-DU by... enable-multiple-stats-in-notification Set to false. In this case, the O-RU can send a measurement result to the O-DU. measurement-result-stats The notification, and the O-DU can receive a measurement result from the O-RU. measurement-result-stats Notification. Optionally, the O-DU can receive a measurement value. multiple-measurement-result-stats Notification, and can be obtained from multiple-measurement-result-stats Only one measurement result was obtained in the notification.

[1689] When O-RU does not use the YANG model multiple-stats-in-notification-capable At that time, O-DU can subscribe measurement-result-stats Notice and multiple-measurement-result-stats Both are notified. In this case, when the O-RU sends a notification including multiple measurement results, the O-DU can receive it from the O-RU. multiple-measurement-result-stats Notification. When the O-RU sends an existing notification including a measurement result, the O-DU can receive existing notifications from the O-RU. measurement-result-stats .

[1690] Existing O-DUs may not support multi-measurement result reporting functionality and may only be available through existing subscriptions. measurement- result-stats In this case, if enable-multiple-stats-in-notification If the default value is set to false, then existing O-DUs do not need to be set separately. enable-multiple-stats-in-notification Therefore, O-RU can include an existing measurement result. measurement-result-stats The notification is sent to the existing O-DU.

[1691] The new O-RU can optionally support multiple-measurement-result-stats Notifications can be made, and it is not necessary to add them to the YANG model. multiple-stats-in-notification-capable and enable-multiple-stats- in-notification The O-RU supports multiple measurement result reporting functions, and the O-DU can be subscribed to. multiple- measurement-result-stats Notification. In this case, the O-DU can receive a single notification that includes multiple measurement results.

[1692] When O-RU does not support multiple-measurement-result-stats When notified, O-DU can subscribe to existing... measurement-result-stats The notification is received to include a measurement result. In this case, since the O-DU is unaware of the O-RU's ability to correlate multiple measurement results, it should subscribe to an existing... measurement- result-stats Notice and new multiple-measurement-result-stats Notify both parties. Because existing O-DUs cannot subscribe to new... multiple-measurement-result-stats The notification may prevent it from receiving information from the O-RU. multiple-measurement-result-stats Notification. Therefore, errors are unlikely to occur.

[1693] When an existing O-DU operates with a new O-RU, and the existing O-DU sets the measurement interval and notification interval of the new O-RU to be the same, it can prevent the existing O-DU from receiving a single notification from the new O-RU that includes multiple measurements (e.g., multiple-measurement-result-stats (Notification). In other words, since a measurement result occurs within a notification interval, the new O-RU can send an existing notification including a measurement result. measurement-result-stats Notice. When using the above method, it is not necessary to use... multiple-stats-in-notification-capable and enable- multiple-stats-in-notification The above operations will be useful in method c.

[1694] When using method c, an existing O-DU can set the measurement interval and notification interval to be the same, so that a measurement result appears at a single notification interval. In this case, the O-DU can send an existing leaf containing a measurement result (e.g., via...). measurement-result-stats (Notification). An existing O-DU can decode a measurement result included in a leaf within an existing notification received from an O-RU. A new O-DU can set the notification interval to be longer than the measurement interval. In this case, if multiple measurement results occur within a notification interval, the O-RU can send a new list including the multiple measurement results to the new O-DU (e.g., via a new...). multiple-measurement-result-stats (Notification). The new O-DU can process data received from the O-RU. multiple-measurement-result-stats The notification includes a new list of multiple measurement results, which are then decoded. In other words, the multiple measurement result reporting feature can be enabled when the notification interval is longer than the measurement interval. If the notification interval is no longer than the measurement interval, the multiple measurement result reporting feature can be disabled.

[1695] In methods a, b, and / or d, an existing leaf including a measurement result can be sent. Therefore, since the existing O-DU can decode the existing leaf, backward compatibility issues may not occur. When a measurement result exists, the existing O-DU can be used. measurement-result-stats Notification. In this case, both the existing O-DU and the new O-DU can decode the measurement results. When multiple measurement results exist, the existing O-DU can be sent. measurement-result-stats Notice and new multiple-measurement-result-stats Notify both. In this case, the existing O-DU can receive the existing measurement-result-stats The notification is used to obtain a measurement result, and the new O-DU can be obtained by receiving the new... multiple-measurement-result-stats Notifications are sent to obtain multiple measurement results.

[1696] Even when a measurement result exists in method d, it is still possible to send an existing measurement result. measurement-result-stats Notification and a new one including a measurement result multiple-measurement- result-stats Notification. In other words, the same measurement results can be included in existing... measurement-result- stats Notice and new multiple-measurement-result-stats In the notification.

[1697] The improved YANG code used for the above method can be defined as follows.

[1698] grouping multiple-measurement-notification {

[1699] description

[1700] "notification may contain multiple-measurement result fortransceiver-stats and / or rx-window-stats and / or tx-stats and / or epe-stats";

[1701] list multiple-transceiver-stats {

[1702] key"measurement-object";

[1703] description

[1704] "multiple measurement result of transceiver-measurement permeasurement-object";

[1705] leaf measurement-object {

[1706] type leafref {

[1707] path" / performance-measurement-objects / transceiver-measurement-objects / measurement-object";

[1708] }

[1709] description

[1710] "measurement-object for the transceiver-measurement";

[1711] }

[1712] list additional-transceiver-measurement-result {

[1713] config false;

[1714] description

[1715] "additional measurement result of transceiver-measurement

[1716] when notification-interval is larger than measurement-interval";

[1717] uses start-and-end-time;

[1718] uses transceiver-measurement-result-grouping;

[1719] }

[1720] }

[1721] list multiple-rx-window-stats {

[1722] key"measurement-object";

[1723] description

[1724] "multiple measurement result for the reception windowmeasurement per measurement-object";

[1725] leaf measurement-object {

[1726] type leafref {

[1727] path" / performance-measurement-objects / rx-window-measurement-objects / measurement-object";

[1728] }

[1729] description

[1730] "measurement-object for the reception window measurement";

[1731] }

[1732] list additional-rx-window-measurement-result {

[1733] config false;

[1734] description

[1735] "additional measurement result of rx-window-measurement

[1736] when notification-interval is larger than measurement-interval";

[1737] uses start-and-end-time;

[1738] uses rx-window-measurement-result-grouping;

[1739] }

[1740] }

[1741] list multiple-tx-stats {

[1742] key"measurement-object";

[1743] description

[1744] "multiple measurement result for the tx stats measurement per

[1745] measurement-object";

[1746] leaf measurement-object {

[1747] type leafref {

[1748] path" / performance-measurement-objects / tx-measurement-objects / measurement-object";

[1749] }

[1750] description

[1751] "measurement-object for the tx stats measurement";

[1752] }

[1753] list additional-tx-measurement-result {

[1754] config false;

[1755] description

[1756] "additional measurement result of tx-measurement

[1757] when notification-interval is larger than measurement-interval";

[1758] uses start-and-end-time;

[1759] uses tx-measurement-result-grouping;

[1760] }

[1761] }

[1762] list multiple-epe-statistics {

[1763] key"measurement-object";

[1764] description

[1765] "measurement result for the epe stats measurement per

[1766] measurement-object";

[1767] leaf measurement-object {

[1768] type leafref {

[1769] path" / performance-measurement-objects / epe-measurement-objects / measurement-object";

[1770] }

[1771] description

[1772] "measurement-object for the epe stats measurement";

[1773] }

[1774] list additional-epe-measurement-result {

[1775] config false;

[1776] description

[1777] "additional measurement result of epe-measurement

[1778] when notification-interval is larger than measurement-interval";

[1779] uses start-and-end-time;

[1780] uses epe-measurement-result-grouping;

[1781] }

[1782] }

[1783] }

[1784] / / Top level container

[1785] container performance-measurement-objects {

[1786] description

[1787] "configuration for performance management and measurement-resultare included";

[1788] uses measurement-group;

[1789] }

[1790] / / Notifications

[1791] notification measurement-result-stats {

[1792] description

[1793] "Notification may contain measurement results for transceiver-stats and / or rx-window-stats";

[1794] uses measurement-notification;

[1795] }

[1796] notification multiple-measurement-result-stats {

[1797] description

[1798] "Notification may contain multiple measurement results fortransceiver-stats and / or rx-window-stats";

[1799] uses multiple-measurement-notification;

[1800] }

[1801] }

[1802] Using the method described above, backward compatibility issues with existing equipment (e.g., O-DU or O-RU) may not occur. Multiple measurement results for each measurement object can be sent during a single NETCONF notification transmission. Therefore, the performance of the O-RAN M-plane can be improved.

[1803] The exemplary embodiments of this disclosure can be implemented as program instructions executable by various computers and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, or combinations thereof. The program instructions recorded on the computer-readable medium may be specifically designed and configured for this disclosure, or may be well-known and available to those skilled in the art of computer software.

[1804] Examples of computer-readable media may include hardware devices such as ROM, RAM, and flash memory, specifically configured to store and execute program instructions. Examples of program instructions include machine code generated, for example, by a compiler, and high-level language code executable by a computer using an interpreter. The exemplary hardware devices described above may be configured to operate as at least one software module to perform embodiments of this disclosure, or vice versa.

[1805] While exemplary embodiments of the present disclosure and their advantages have been described in detail, it should be understood that various changes, substitutions and alterations may be made herein without departing from the scope of the present disclosure.

Claims

1. An operation method for an O-RAN radio unit (O-RU) in an Open Radio Access Network (O-RAN), the operation method comprising: Multiple first measurement results are generated by performing measurement operations on the first measurement object within a notification period according to the notification interval; Generate a first measurement result list that includes the plurality of first measurement results; Generate a first notification, wherein the first notification includes the most recent measurement result among the plurality of first measurement results; and Send a message including the first list of measurement results and the first notification to the O-RAN distributed unit (O-DU). The first list of measurement results is decoded by an O-DU that supports a specific version of the O-RAN or later, and the first notification is decoded by an O-DU that supports a version prior to the specific version.

2. The operating method according to claim 1 further includes: Multiple second measurement results are generated by performing a measurement operation on the second measurement object during the notification period; as well as Generate a list of second measurement results that includes the plurality of second measurement results. The message also includes the second list of measurement results.

3. The operating method according to claim 1, wherein, The first measurement result list also includes information about the start time and end time of each of the plurality of first measurement results.

4. The operating method according to claim 1, wherein, The plurality of first measurement results are arranged in ascending order of measurement time in the first measurement result list.

5. The operating method according to claim 1, wherein, The first measurement result list also includes at least one of information indicating the number of the plurality of first measurement results and the sequence number of each of the plurality of first measurement results.

6. The operating method according to claim 1, wherein, The notification interval is set by the O-DU to be longer than the measurement interval for performing a single measurement operation.

7. The operating method according to claim 1, wherein, The first measurement object is a transceiver, a receive window (rx-window), a transmit measurement (tx-measurement), "Energy, Power, Environment (EPE)" or a symbolic Received Signal Strength Indicator (RSSI).

8. A method for operating an O-RAN radio unit (O-RU) in an Open Radio Access Network (O-RAN), the method comprising: The first measurement result is generated by performing a measurement operation on the first measurement object within a notification period according to the notification interval; Generate a first notification including the first measurement result; Generate a first measurement result list that includes the first measurement result; as well as Send a message including the first notification and the first list of measurement results to the O-RAN distributed unit (O-DU). The first list of measurement results is decoded by an O-DU that supports a specific version of the O-RAN or later, and the first notification is decoded by an O-DU that supports a version prior to the specific version.

9. The operating method according to claim 8, wherein, The notification interval is set by the O-DU to be equal to the measurement interval for performing one measurement operation.

10. The operating method according to claim 8, further comprising: A second measurement result is generated by performing a measurement operation on the second measurement object during the notification period. Generate a second notification that includes the second measurement result; as well as Generate a second list of measurement results, including the second measurement result. The message also includes the second notification and the second list of measurement results.

11. An operation method for an O-RAN Distributed Unit (O-DU) in an Open Radio Access Network (O-RAN), the operation method comprising: Set the notification interval and measurement interval for the O-RAN radio unit (O-RU); Receive a message from the O-RU including a first measurement result list and a first notification, wherein the first measurement result list includes multiple first measurement results for a first measurement object, and the first notification includes the most recent measurement result among the multiple first measurement results; and The plurality of first measurement results are identified by decoding the first list of measurement results. The plurality of first measurement results are measured within a notification period according to the notification interval, the list of first measurement results is decoded by O-DUs that support a specific version of the O-RAN and later, and the first notification is decoded by O-DUs that support a version of the O-RAN prior to the specific version.

12. The operating method according to claim 11, wherein, The first measurement result list also includes information about the start time and end time of each of the plurality of first measurement results.

13. The operating method according to claim 11, wherein, The plurality of first measurement results are arranged in ascending order of measurement time in the first measurement result list.

14. The operating method according to claim 11, wherein, The first measurement result list also includes at least one of information indicating the number of the plurality of first measurement results and the sequence number of each of the plurality of first measurement results.

15. The operating method according to claim 11, wherein, The first measurement object is a transceiver, a receive window (rx-window), a transmit measurement (tx-measurement), "Energy, Power, Environment (EPE)", or a symbolic Received Signal Strength Indicator (RSSI).

Images