WO2022108393A1 - 프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치 - Google Patents

프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치 Download PDF

Info

Publication number
WO2022108393A1
WO2022108393A1 PCT/KR2021/017105 KR2021017105W WO2022108393A1 WO 2022108393 A1 WO2022108393 A1 WO 2022108393A1 KR 2021017105 W KR2021017105 W KR 2021017105W WO 2022108393 A1 WO2022108393 A1 WO 2022108393A1
Authority
WO
WIPO (PCT)
Prior art keywords
measurement
result
notification
time
measurement result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2021/017105
Other languages
English (en)
French (fr)
Inventor
이재승
이문식
박재우
최지연
김영훈
박주호
이후성
전영일
정찬복
주형식
천익재
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Electronics and Telecommunications Research Institute ETRI
Original Assignee
Electronics and Telecommunications Research Institute ETRI
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Electronics and Telecommunications Research Institute ETRI filed Critical Electronics and Telecommunications Research Institute ETRI
Priority to CN202180078369.2A priority Critical patent/CN116530135A/zh
Priority to JP2023530029A priority patent/JP7528372B2/ja
Priority to US18/036,534 priority patent/US12556949B2/en
Priority to EP21895160.6A priority patent/EP4250799A4/en
Priority claimed from KR1020210160299A external-priority patent/KR20220069857A/ko
Publication of WO2022108393A1 publication Critical patent/WO2022108393A1/ko
Anticipated expiration legal-status Critical
Priority to JP2024118565A priority patent/JP7766754B2/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/085—Access point devices with remote components

Definitions

  • the present invention relates to a communication technology in a communication system including a fronthaul interface, and more particularly, to a technology for efficiently transmitting and receiving parameters for performance management of a communication system.
  • LTE long term evolution
  • NR new radio
  • 3GPP 3rd generation partnership project
  • a frequency band of a 4G communication system eg, a frequency band of 6 GHz or less
  • a 5G communication system eg, a communication system supporting NR
  • the 5G communication system may support enhanced Mobile BroadBand (eMBB), Ultra-Reliable and Low Latency Communication (URLLC), and Massive Machine Type Communication (mMTC).
  • eMBB enhanced Mobile BroadBand
  • URLLC Ultra-Reliable and Low Latency Communication
  • mMTC Massive Machine Type Communication
  • the O-RAN (open-radio access network) alliance defines a fronthaul (fronthaul) interface.
  • the fronthaul interface may be an interface between an O-RAN distributed unit (O-DU) constituting a base station (eg, eNB, gNB) and an O-RAN radio unit (O-RU).
  • the O-DU may be referred to as a lower layer split-central unit (LLS-CU), and the O-RU may be referred to as a lower layer split-distributed unit (LLS-DU).
  • LLS-CU and LLS-DU may be terms used in 3rd generation partnership project (3GPP).
  • 3GPP 3rd generation partnership project
  • An object of the present invention to solve the above problems is to provide a method and apparatus for transmitting and receiving parameters for performance management in a communication system including a fronthaul interface.
  • the O-RU operation method provides a plurality of first measurement results by performing a measurement operation on a first measurement target in one notification interval according to the notification interval. generating, generating a first measurement result list including the plurality of first measurement results, and transmitting a message including the first measurement result list to the O-DU.
  • the method of operating the O-RU may further include generating a first notification including a most recent measurement result among the plurality of first measurement results, wherein the message may further include a first notification.
  • the first measurement result list may be decoded in the O-DU supporting a version after a specific version of the O-RAN, and the first notification is decoded in the O-DU supporting a version before the specific version.
  • the method of operating the O-RU includes generating a plurality of second measurement results by performing a measurement operation on a second measurement target in the one notification period, and a second including the plurality of second measurement results.
  • the method may further include generating a measurement result list, and the message may further include the second measurement result list.
  • the first measurement result list may further include measurement start time information and measurement end time information for each of the plurality of first measurement results.
  • the plurality of first measurement results may be arranged in an ascending order of measurement time in the first measurement result list.
  • the first measurement result list may further include at least one of information indicating the number of the plurality of first measurement results and a sequence number of each of the plurality of first measurement results.
  • the notification interval may be set by the O-DU to be longer than a measurement interval in which one measurement operation is performed.
  • the first measurement target may be a transceiver, a reception window, a transmission measurement, an EPE, or a symbol RSSI.
  • an O-RU operation method generates a first measurement result by performing a measurement operation on a first measurement target in one notification interval according to a notification interval. step, generating a first notification including the first measurement result, generating a first measurement result list including the first measurement result, and including the first notification and the first measurement result list and transmitting a message to the O-DU.
  • the first measurement result list may be decoded in the O-DU supporting a version after a specific version of the O-RAN, and the first notification is decoded in the O-DU supporting a version before the specific version.
  • the notification interval may be set by the O-DU to be the same as a measurement interval at which one measurement operation is performed.
  • the method of operation of the O-RU includes generating a second measurement result by performing a measurement operation on a second measurement target in the one notification period, and generating a second notification including the second measurement result. and generating a second measurement result list including the second measurement result, and the message may further include the second notification and the second measurement result list.
  • a method of operating an O-DU according to a third embodiment of the present invention for achieving the above object includes the steps of setting a notification interval and a measurement interval for the O-RU, and a plurality of first measurement results for a first measurement target receiving, from the O-RU, a message including a first measurement result list including The first measurement results are measured in one notification interval according to the notification interval.
  • the message may further include a first notification including a most recent measurement result among the plurality of first measurement results.
  • the first measurement result list may be decoded in the O-DU supporting a version after a specific version of the O-RAN, and the first notification is decoded in another O-DU supporting a version before the specific version.
  • the first measurement result list may further include measurement start time information and measurement end time information for each of the plurality of first measurement results.
  • the plurality of first measurement results may be arranged in an ascending order of measurement time in the first measurement result list.
  • the first measurement result list may further include at least one of information indicating the number of the plurality of first measurement results and a sequence number of each of the plurality of first measurement results.
  • the first measurement target may be a transceiver, a reception window, a transmission measurement, an EPE, or a symbol RSSI.
  • various parameters for performance management can be efficiently transmitted/received between an open-radio access network (O-RAN) radio unit (O-RU) and an O-RAN distributed unit (O-DU).
  • O-RAN open-radio access network
  • O-RU radio unit
  • O-DU O-RAN distributed unit
  • a plurality of measurement results eg, a plurality of measurement results for each measurement object
  • This operation may not affect the function of the existing M-Plane. Accordingly, the performance of a communication system including a fronthaul interface may be improved.
  • FIG. 1 is a conceptual diagram illustrating a first embodiment of a communication system.
  • FIG. 2 is a block diagram showing a first embodiment of a communication node constituting a communication system.
  • FIG. 3 is a block diagram illustrating a first embodiment of a base station supporting LLS in a communication system.
  • FIG. 4 is a block diagram illustrating a first embodiment of an interface structure between an O-DU and an O-RU in a communication system.
  • 5A is a block diagram illustrating a first embodiment of a hierarchical M-Plane model.
  • 5B is a block diagram illustrating a second embodiment of a hybrid M-Plane model.
  • FIG. 6 is a block diagram illustrating a first embodiment of a protocol stack of M-Plane.
  • FIG. 7 is a conceptual diagram illustrating a first embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • FIG. 8 is a conceptual diagram illustrating a second embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • FIG. 9 is a conceptual diagram illustrating a third embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • FIG. 10 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a transceiver in a YANG model using method A;
  • FIG. 11 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a reception window in a YANG model using method A.
  • FIG. 12 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for EPE in a YANG model using method A.
  • FIG. 12 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for EPE in a YANG model using method A.
  • FIG. 13 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for transmission measurement in a YANG model using method A.
  • FIG. 14 is a conceptual diagram illustrating a structure of an extended measurement result for symbol RSSI in a YANG model using method A according to a first embodiment.
  • first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component.
  • the term “and/or” includes a combination of a plurality of related listed items or any of a plurality of related listed items.
  • “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B”. Also, in the embodiments of the present application, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B”.
  • the communication system may be a 4G communication system (eg, a long-term evolution (LTE) communication system, an LTE-A communication system), a 5G communication system (eg, a new radio (NR) communication system), and the like.
  • the 4G communication system may support communication in a frequency band of 6 GHz or less
  • the 5G communication system may support communication in a frequency band of 6 GHz or more as well as a frequency band of 6 GHz or less.
  • the communication system to which the embodiments according to the present invention are applied is not limited to the content described below, and the embodiments according to the present invention can be applied to various communication systems.
  • the communication system may be used in the same meaning as the communication network (network), and "LTE” may indicate “4G communication system”, “LTE communication system” or “LTE-A communication system”, and “NR” may indicate “5G communication system” or “NR communication system”.
  • FIG. 1 is a conceptual diagram illustrating a first embodiment of a communication system.
  • the communication system 100 is a plurality of communication nodes (110-1, 110-2, 110-3, 120-1, 120-2, 130-1, 130-2, 130-3, 130-4, 130-5, 130-6).
  • the communication system 100 is a core network (core network) (eg, S-GW (serving-gateway), P-GW (packet data network (PDN)-gateway), MME (mobility management entity)) may include more.
  • core network eg, S-GW (serving-gateway), P-GW (packet data network (PDN)-gateway), MME (mobility management entity)
  • the core network is an access and mobility management function (AMF), a user plane function (UPF), a session management function (SMF), etc.
  • AMF access and mobility management function
  • UPF user plane function
  • SMF session management function
  • SMS session management function
  • the plurality of communication nodes 110 to 130 may support a communication protocol (eg, an LTE communication protocol, an LTE-A communication protocol, an NR communication protocol, etc.) defined in a 3rd generation partnership project (3GPP) standard.
  • a plurality of communication nodes 110 to 130 are CDMA (code division multiple access) technology, WCDMA (wideband CDMA) technology, TDMA (time division multiple access) technology, FDMA (frequency division multiple access) technology, OFDM (orthogonal frequency division) technology multiplexing) technology, Filtered OFDM technology, CP (cyclic prefix)-OFDM technology, DFT-s-OFDM (discrete Fourier transform-spread-OFDM) technology, OFDMA (orthogonal frequency division multiple access) technology, SC (single carrier)-FDMA Technology, Non-orthogonal Multiple Access (NOMA) technology, GFDM (generalized frequency division multiplexing) technology, FBMC (filter bank multi-carrier) technology, UFMC (universal filtered multi
  • FIG. 2 is a block diagram showing a first embodiment of a communication node constituting a communication system.
  • the communication node 200 may include at least one processor 210 , a memory 220 , and a transceiver 230 connected to a network to perform communication.
  • the communication node 200 may further include an input interface device 240 , an output interface device 250 , a storage device 260 , and the like.
  • Each of the components included in the communication node 200 may be connected by a bus 270 to communicate with each other.
  • the processor 210 may execute a program command stored in at least one of the memory 220 and the storage device 260 .
  • the processor 210 may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.
  • Each of the memory 220 and the storage device 260 may be configured as at least one of a volatile storage medium and a non-volatile storage medium.
  • the memory 220 may be configured as at least one of a read only memory (ROM) and a random access memory (RAM).
  • the communication system 100 includes a plurality of base stations 110 - 1 , 110 - 2 , 110 - 3 , 120 - 1 and 120 - 2 , and a plurality of terminals 130 - 1, 130-2, 130-3, 130-4, 130-5, 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.
  • 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 belong to the cell coverage of the first base station 110-1.
  • the second terminal 130-2, the fourth terminal 130-4, and the fifth terminal 130-5 may belong to the cell coverage of the second base station 110-2.
  • the fifth base station 120-2, the fourth terminal 130-4, the fifth terminal 130-5, and the sixth terminal 130-6 may belong to the cell coverage of the third base station 110-3.
  • the first terminal 130-1 may belong to the cell coverage of the fourth base station 120-1.
  • the sixth terminal 130-6 may belong to the cell coverage of the fifth base station 120-2.
  • each of the plurality of base stations 110-1, 110-2, 110-3, 120-1, and 120-2 is a NodeB (NB), an evolved NodeB (eNB), gNB, an advanced base station (ABS), HR - BS (high reliability-base station), BTS (base transceiver station), radio base station (radio base station), radio transceiver (radio transceiver), access point (access point), access node (node), RAS (radio access station) ), MMR-BS (mobile multihop relay-base station), RS (relay station), ARS (advanced relay station), HR-RS (high reliability-relay station), HNB (home NodeB), HeNB (home eNodeB), RSU (road side unit), RRH (radio remote head), TP (transmission point), TRP (transmission and reception point), macro (macro) cell, pico (pico) cell, micro (micro) cell, femto (femto) It may be referred to as
  • Each of the plurality of terminals 130-1, 130-2, 130-3, 130-4, 130-5, 130-6 includes a user equipment (UE), a terminal equipment (TE), an advanced mobile station (AMS), HR-MS (high reliability-mobile station), terminal, access terminal, mobile terminal, station, subscriber station, mobile station, portable It may be referred to as a portable subscriber station, a node, a device, an on board unit (OBU), and the like.
  • UE user equipment
  • TE terminal equipment
  • AMS advanced mobile station
  • HR-MS high reliability-mobile station
  • OBU on board unit
  • a base station may support a fronthaul interface.
  • the fronthaul interface may be a fronthaul interface defined in an open-radio access network (O-RAN) alliance.
  • the base station may include an O-RAN distributed unit (O-DU) and one or more O-RAN radio units (O-RU). Communication between the O-DU and one or more O-RUs may be performed through a fronthaul interface.
  • the O-DU may be a lower layer split-central unit (LLS-CU) specified in 3GPP
  • the O-RU may be a lower layer split-distributed unit (LLS-DU) specified in 3GPP.
  • Each of the O-DU and O-RU may be configured the same as or similar to the communication node 200 shown in FIG. 2 .
  • a corresponding second communication node is a method (eg, a method corresponding to the method performed in the first communication node) For example, reception or transmission of a signal) may be performed. That is, when the operation of the O-DU is described, the corresponding O-RU may perform the operation corresponding to the operation of the O-DU. Conversely, when the operation of the O-RU is described, the corresponding O-DU may perform the operation corresponding to the operation of the O-RU.
  • FIG. 3 is a block diagram illustrating a first embodiment of a base station supporting lower layer split (LLS) in a communication system.
  • LLC lower layer split
  • the base station 300 may include an O-DU 311 , an O-RU #1 321 , an O-RU #2 322 , and the like.
  • the base station 300 may include a plurality of O-RUs. Communication between the O-DU 311 and the O-RUs 321 and 322 may be performed through a fronthaul interface.
  • the fronthaul interface may include an LLS-control plane and an LLS-user plane.
  • the LLS-control plane may be referred to as “LLS-C” or “LLS-C-Plane” and the LLS-user plane may be referred to as “LLS-U” or “LLS-U-Plane”.
  • the O-DU 311 may be a logical node that performs a radio link control (RLC) layer function, a medium access control (MAC) layer function, and/or a high-PHY (physical) layer function. have.
  • the O-DU 311 may control the plurality of O-RUs 321 and 322 .
  • Each of the O-RUs 321 and 322 may be a logical node that performs a low-PHY layer function and/or a radio frequency (RF) processing function.
  • the O-RUs 321 and 322 may transmit/receive control information and/or data by performing communication with the O-DU 311 .
  • the control information may be real-time control information.
  • the data may be user plane data.
  • the O-RUs 321 and 322 may operate based on the control of the O-DU 311 .
  • FIG. 4 is a block diagram illustrating a first embodiment of an interface structure between an O-DU and an O-RU in a communication system.
  • each of the O-DU and O-RU may include a CUS-Plane (eg, O-RAN CUS-Plane), and may perform communication according to a CUS-Plane function.
  • each of the O-DU and O-RU may include an M (management)-Plane (eg, O-RAN M-Plane), and may perform communication according to an M-Plane function. That is, the O-DU and O-RU may perform the M-Plane function as well as the CUS-Plane function.
  • the M-Plane function may support initialization, configuration, management, etc. of O-RU.
  • M-Plane may use an open interface based on the NETCONF and/or YANG model (hereinafter referred to as the "NETCONF/YANG model"). M-Plane supports start up installation, software management, configuration management, performance management, fault management, file management, etc. can
  • the M-Plane structure in O-RAN may be as follows.
  • FIG. 5A is a block diagram illustrating a first embodiment of a hierarchical M-Plane model
  • FIG. 5B is a block diagram illustrating a second embodiment of a hybrid M-Plane model.
  • an O-RU may be managed by one or more O-DUs.
  • a NETCONF-based M-Plane interface may be used between the O-DU and the O-RU.
  • An interface between the O-DU and a network management system (NMS) may exist, but the NMS may not directly manage the O-RU. That is, the NMS may manage the O-RU through the O-DU.
  • a direct interface between the O-RU and the NMS may not exist.
  • the NMS may refer to the management system shown in FIG. 4 .
  • the hybrid M-Plane model there may be a direct logical interface between the NMS and the O-RU as well as a logical interface between the O-DU and the O-RU.
  • the NMS may support a software management function, a performance management function, a configuration management function, and/or a fault management function for the O-RU.
  • the NMS and the O-RU may have end-to-end internet protocol (IP) layer connectivity.
  • IP internet protocol
  • FIG. 6 is a block diagram illustrating a first embodiment of a protocol stack of M-Plane.
  • the IP transport layer may operate above the transport network layer.
  • a transmission control protocol (TCP)/secure shell (SSH) layer may be used to transmit/receive an M-Plane message between the O-DU/NMS and the O-RU.
  • TCP transmission control protocol
  • SSH secure shell
  • the NETCONF/YANG model may be used as a network element management protocol and a data modeling language.
  • the NETCONF/YANG model can support an open management method for efficient integration and management between multi-vendor O-RU/O-DUs.
  • NETCONF may obtain configuration state information and may support a configuration change operation.
  • NETCONF can deliver a message in XML-RPC format on a transport layer (eg, SSH layer) that provides a secure transport.
  • a transport layer eg, SSH layer
  • Each of the get and get-config RPC operations may be used to obtain all of the settings, part of the settings, all of the state data, and/or part of the state data.
  • Edit-config operations may be used to change, add, and/or delete configuration elements in a configuration data store.
  • Notification support in NETCONF may be based on an event stream.
  • a NETCONF client eg, O-DU
  • O-DU may wish to receive notifications for certain events.
  • a create-subscription operation may be used.
  • the performance management function may be the main function of M-Plane.
  • the performance management function may be a function for optimizing O-RU operation.
  • O-DU eg, NETCONF client
  • O-RU operation-related information eg, transceiver, receive window (rx-window), transmit window (tx-window)
  • EPE energy, power, environmental
  • RSSI received signal strength indicator
  • the O-DU may collect configuration and/or status information for performance management.
  • Measurement objects defined and/or used in the O-RAN specification for performance management are 5 or more measurement groups (eg, transceiver-statistics stats) group, reception window statistics (rx-window-stats) group, transmission measurement statistics (tx-measurement-stats) group, EPE statistics (epe-stats) group, RSSI statistics (rssi-stats) group, etc.) and/or managed.
  • the RSSI statistics group may be a symbolic RSSI statistics group.
  • a measurement-interval may be independently set for each measurement group. For example, the measurement interval may be different for each measurement group.
  • Transceiver measurement interval (transceiver-measurement-interval), receive window measurement interval (rx-window-measurement-interval), transmit measurement interval (tx-measurement-interval), EPE measurement interval (epe-measurement interval), and / or RSSI
  • the measurement interval (rssi-measurement-interval) may be set independently of each other.
  • the measurement result (eg, measurement value) measured in the O-RU is transmitted using the NETCONF notification mechanism at the time according to the notification interval.
  • the O-RU may periodically transmit a measurement result to the O-DU.
  • the O-RU may store the measurement result for each measurement time in the local disk, and may upload the measurement result to the O-DU at a point in time according to the file-upload-interval.
  • the notification interval may be set differently from the measurement interval.
  • the measurement interval may mean a measurement interval
  • the notification interval may mean a notification interval
  • "transmission/reception operation of notification” may mean "transmission/reception operation of notification message”.
  • the measurement interval of the measurement object #A may be set to 3 minutes, and the measurement interval of the measurement object #B may be set to 5 minutes.
  • the notification interval may be set to 15 minutes.
  • sending one notification eg, a notification message
  • a plurality of measurement results may exist in the O-RU at the time of transmission of the notification.
  • a plurality of measurement results for a specific measurement object may be included in one notification.
  • the existing YANG model defined in the M-Plane of the O-RAN may not support the transmission/reception operation of one notification including a plurality of measurement results.
  • the "transmission/reception operation of one notification including a plurality of measurement results” may be referred to as a "multi-measurement result reporting function". That is, the existing YANG model can transmit one notification including one measurement result for each measurement object. Therefore, if the notification interval is set longer than the measurement interval of the measurement target, a notification including only one measurement result may be transmitted, and the remaining measurement result(s) in the notification interval are O-DU (eg, NETCONF client) cannot be transmitted to Methods for solving the above-mentioned problems will be described below.
  • O-DU eg, NETCONF client
  • O-RAN M-Plane Regarding performance management in the M-Plane of O-RAN (hereinafter referred to as "O-RAN M-Plane"), the interface and configuration information between O-DU and O-RU is o-ran-performance-management.yang It can be defined in a module.
  • "format for management information transmitted and received between devices” and “transmission procedure for management information” may be defined using the NETCONF/YANG model.
  • Table 1 and Table 2 below main parameters used for performance management in the o-ran-performance-management.yang module may be defined. According to the update of the O-RAN specification, other parameters may be added to Tables 1 and 2, and the parameter(s) defined in Tables 1 and 2 may be changed.
  • O-DU (eg, NETCONF client) is a measurement target, a value included in report-info (eg, maximum value, minimum value, count, etc.), object-unit, measurement You can set an interval, a notification interval, and/or a file upload interval.
  • the O-DU may inform the O-RU of configuration information.
  • the O-RU may perform measurement at a set measurement interval for the selected measurement target according to information (eg, value) set by the O-DU, and includes the measurement result according to the set notification interval or file upload interval. You can send a notification or upload a measurement result file.
  • a measurement interval for a measurement target may be set for each measurement group.
  • each of the transceiver measurement interval, the reception window measurement interval, the transmission measurement interval, the EPE measurement interval, and the RSSI measurement interval may be set independently of each other.
  • the O-DU may set the information element(s) included in the report information for each measurement object.
  • the reporting information may include a plurality of information elements.
  • the information element(s) may include MAXIMUM, MINIMUM, FIRST, LATEST, and/or FREQUENCY_TABLE.
  • a target unit may be independently set for each measurement target.
  • the target unit may be different for each measurement target.
  • FIG. 7 is a conceptual diagram illustrating a first embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • the O-RU may store measurement results for measurement objects belonging to each of the transceiver statistics group and the reception window statistics group in a data store based on the YANG model.
  • the O-RU may send a NETCONF notification including the measurement result(s) to the O-DU (eg, NETCONF client).
  • the transceiver statistics group may be referred to as transceiver measurement objects
  • the receive window statistics group may be referred to as receive window measurement objects. Active for each measurement target may be set to true or false. A default of activation for each measurement target may be false.
  • the count value may start from 0 at the boundary of the measurement interval.
  • FIG. 8 is a conceptual diagram illustrating a second embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • the O-RU may store measurement results for measurement objects belonging to each of the EPE statistics group and the transmission measurement statistics group in a data store based on the YANG model.
  • the O-RU may send a NETCONF notification including the measurement result(s) to the O-DU (eg, NETCONF client).
  • the EPE statistics group may be referred to as EPE measurement objects
  • the transmission measurement statistics group may be referred to as transmission measurement objects.
  • Activation for each measurement target may be set to true or false. A default of activation for each measurement object may be false.
  • FIG. 9 is a conceptual diagram illustrating a third embodiment of a data structure of a YANG model for delivery of a performance measurement result in an O-RAN M-Plane.
  • measurement group(s) for various measurement results eg, measurement information
  • symbol RSSI statistics symbol-rssi-stats
  • RSSI for specific symbols in the time domain The above-described measurement information may have the same or similar structure to the structure shown in FIG. 7 or FIG. 8 .
  • the structure of the symbol RSSI statistics may be the same as or similar to the structure of the transceiver statistics.
  • the O-RU may perform a measurement operation according to a measurement interval set by the O-DU (eg, NETCONF client).
  • the O-RU may periodically transmit the measurement result(s) to the O-DU using the NETCONF notification mechanism at a time point according to the notification interval.
  • the O-RU may store the measurement result(s) in the local disk for each measurement time, and may upload the measurement result(s) to the O-DU at a point in time according to the file upload interval.
  • the notification interval may be set differently from the measurement interval.
  • the measurement interval of the measurement object #A may be set to 3 minutes, and the measurement interval of the measurement object #B may be set to 5 minutes.
  • the notification interval may be set to 15 minutes.
  • sending one notification eg, a notification message
  • a plurality of measurement results may exist in the O-RU at the time of transmission of the notification.
  • a plurality of measurement results for a measurement target may be included in one notification.
  • the existing YANG model defined in the M-Plane of O-RAN may not support the transmission operation of one notification including a plurality of measurement results. That is, the existing YANG model can transmit one notification including one measurement result for each measurement object. Therefore, if the notification interval is set longer than the measurement interval of the measurement target, a notification including only one measurement result may be transmitted, and the remaining measurement result(s) in the notification interval are O-DU (eg, NETCONF client) cannot be transmitted to That is, in the YANG model of the current O-RAN (eg, the YANG model shown in FIGS. 7 and 8), the transmission operation of one notification may be performed to transmit one measurement result for each measurement target. have.
  • O-DU eg, NETCONF client
  • Part 1 (eg, common configuration part) of the YANG model for performance management of the O-RAN M-Plane may be as follows.
  • Part 1 of the above-described YANG model may define parameters commonly applied to all measurement objects.
  • part 1 of the YANG model includes measurement target information supported by O-RU, measurement interval by measurement group (eg, transceiver measurement interval, receive window measurement interval, transmit measurement interval, EPE measurement interval, RSSI measurement interval). ), notification interval, and/or file upload interval.
  • the transceiver measurement interval, the reception window measurement interval, the transmission measurement interval, the EPE measurement interval, and the RSSI measurement interval may be set differently.
  • the notification interval or file upload interval can be set to one common value. Each of the notification interval or the file upload interval may be set differently from the transceiver measurement interval, the receive window measurement interval, the transmission measurement interval, the EPE measurement interval, and/or the RSSI measurement interval.
  • Part 2 eg, transceiver, reception window related notification
  • Part 2 eg, transceiver, reception window related notification
  • Part 3 eg, EPE, transmission window related notification
  • Part 3 eg, EPE, transmission window related notification
  • Portions 2 and 3 of the YANG model may be a YANG model defined for transmitting measurement information related to a transceiver, a receive window, an EPE, and/or a transmit window in the form of a NETCONF notification.
  • Transceiver statistics, receive window statistics, transmit statistics, EPE statistics, and RSSI statistics each represent one result (eg, For example, a value) may be included.
  • results measured in a plurality of time intervals may not be transmitted using one notification.
  • the notification including the measurement result must be transmitted frequently.
  • the YANG model to solve this problem can be set as follows.
  • an additional measurement list including one or more measurement results for each measurement object may be set, and the additional measurement list may be added to statistical information of the corresponding measurement object. For example, an additional measurement list may be added to the statistical information in chronological order.
  • FIG. 10 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a transceiver in a YANG model using method A;
  • an additional transceiver measurement result (additional-transceiver-measurement-result) for each measurement target (eg, RX_POWER, TX_POWER, TX_BIAS_COUNT, TEMPARATURE, etc.) may be added.
  • FIG. 11 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for a reception window in a YANG model using method A.
  • an additional reception window measurement result (additional-rx-window-measurement-result) for each measurement target (eg, RX_ON_TIME, RX_EARLY, RX_LATE, RX_CORRUT, RX_DUPL, RX_TOTAL, etc.) may be added. .
  • FIG. 12 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for EPE in a YANG model using method A.
  • FIG. 12 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for EPE in a YANG model using method A.
  • an additional EPE measurement result (additional-epe-measurement-result) for each measurement target (eg, TEMPARATURE, POWER) may be added.
  • FIG. 13 is a conceptual diagram illustrating a first embodiment of the structure of an extended measurement result for transmission measurement in a YANG model using method A.
  • an additional transmission measurement result (additional-tx-measurement-result) for each measurement target (eg, TX_TOTAL, TX_TOTAL_C) may be added.
  • FIG. 14 is a conceptual diagram illustrating a structure of an extended measurement result for symbol RSSI in a YANG model using method A according to a first embodiment.
  • an additional symbol RSSI measurement result (additional-symbol-rssi-measurement-result) for each measurement target (eg, ALL-UL-SYMBOLS, CONFIGURED-SYMBOLS) may be added.
  • the structure of the YANG model according to method 1 described above may be defined as follows.
  • the modified YANG code could be as follows.
  • a plurality of measurement results of each of the measurement targets may be included in one notification (eg, one notification message).
  • each measurement object belonging to the transceiver statistics group, the reception window statistics group, the transmission statistics group, and the EPE statistics group is added to the list of additional measurement results or the entire measurement result (eg, list additional-transceiver-measurement- result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result, etc.), the YANG model may be extended.
  • the list of additional measurement results may include a start time (eg measurement start time), end time (eg measurement end time), and measurement results in that time interval (eg measurement values in measurement interval).
  • the measurement period may be a time period from a start time to an end time.
  • the existing YANG model In the existing YANG model, one notification including only one measurement result per measurement object may be transmitted.
  • the fronthaul equipment eg, O-DU and/or O-RU
  • the YANG model proposed in the present application may use the start time, end time, and measurement result of the existing YANG model as it is.
  • the measurement result of the existing YANG model may include the first measurement result.
  • the proposed YANG model can include a list of additional measurement results compared to the existing YANG model.
  • the additional measurement result list may include one or more measurement results from the second measurement result.
  • Measurement results may be arranged in chronological order (eg, in ascending order of measurement time) in the additional measurement result list. This operation may be referred to as “method a”. According to method a, since the measurement-related parameters used in the existing YANG model are used as they are, a backward compatibility problem may not occur.
  • the existing O-DU that can decode only one measurement result in one notification decodes the existing parameter(s) (eg, transceiver-stats, rx-window-stats, tx-stats, epe-stats) can do.
  • the existing O-DU may successfully receive one measurement result.
  • the O-RU may set the last measurement result (eg, the most recent measurement result) from among the plurality of measurement results as an existing measurement result parameter, from the first measurement result to the last previous measurement result. It is possible to create an additional measurement result list (eg, additional-XXXX-measurement-result) including. This operation may be referred to as “method b”. According to method b, one measurement result that the existing O-DU can receive may be the most recent measurement result.
  • the O-RU sets the number of measurement results (eg, number-of-additional-measurement-result) included in the additional measurement result list to the O-DU can inform you That is, the additional measurement result list may further include number-of-additional-measurement-result.
  • the additional measurement result list may further include a sequence number (eg, seq-number).
  • the sequence number for the measurement result in the measurement result list may start from 1 and may increase in chronological order. In this case, the sequence number of the existing measurement result (eg, the first measurement result) may be regarded as 0.
  • the sequence number for the measurement result in the measurement result list may start from 0 and may increase in chronological order.
  • the existing measurement result may be regarded as the last measurement result.
  • the O-DU can easily arrange the measurement results in chronological order by using the sequence number as a key value of the additional measurement result list.
  • the O-DU can easily find a specific measurement result using the sequence number.
  • the sequence number may not be included in the additional measurement result list, and the start time and the end time instead of the sequence number may be used as key values of the additional measurement result list.
  • the key of the additional measurement result list may not be specified. If the key of the additional measurement result list is not specified, the O-DU cannot directly access a specific entry (eg, a specific measurement result) in the additional measurement result list, and must always decode the entire additional measurement result list. . In order to reduce the number of parameters, number-of-additional-measurement-result may not be used.
  • a sequence number which is a key value, may be defined as "ordered-by user".
  • the O-RU may send the measurement result to the existing O-DU (eg, O-DU supporting the previous version of O-RAN M-Plane 7.0 version, O-DU in which decoding of the additional measurement result list is impossible)
  • the O-RU may transmit leafs (eg, start-time, end-time, and XXXX-measurement-result[]) capable of transmitting one measurement result.
  • the O-RU is an O-DU capable of processing an additional measurement result list (eg, O-DU supporting O-RAN M-Plane 7.0 version, O-RAN M-Plane version 7.0 or later)
  • An additional measurement result list including all of the plurality of measurement results may be transmitted to the supported O-DU).
  • an O-DU capable of processing the additional measurement result list may be referred to as a "new O-DU”
  • an O-DU that cannot process the additional measurement result list may be referred to as an "existing O-DU”
  • O-DU may mean a new O-DU and/or an existing O-DU.
  • the YANG model described above in method c may be used as it is.
  • transmission of the additional measurement result list eg, additional-XXXX-measurement-result[]
  • additional-XXXX-measurement-result[] may be omitted, and only existing leafs may be used.
  • the O-RU includes an additional measurement result list including a plurality of measurement results (additional-XXXX-measurement- result[]) may be transmitted to a new O-DU.
  • all measurement results eg, measurement results from the first measurement result to the last measurement result
  • the O-RU may transmit a notification including one measurement result for each measurement object to the existing O-DU.
  • the existing O-DU may set the O-RU measurement interval and the notification interval to be the same so that one measurement result is generated at one notification interval.
  • the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU may transmit only the most recent measurement result among the measurement results to the existing O-DU. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result reporting function>.
  • the O-RU is the number of measurement results included in the additional measurement result list (number-of-additional-measurement-result) can inform the O-DU.
  • the measurement result list may include a sequence number (seq-number).
  • a sequence number for a measurement result in the measurement result list may start from 0 and may increase in chronological order.
  • the O-DU can easily sort the measurement results in chronological order by using the sequence number as a key value in the list of additional measurement results.
  • the O-DU can easily find a specific measurement result using the sequence number.
  • the O-RU may send one notification including a plurality of measurement results.
  • the O-RU may generate a plurality of additional measurement result lists based on the plurality of measurement results, and may transmit a notification including the plurality of additional measurement result lists to the O-DU.
  • an O-RU that does not support the above-described operation may transmit one measurement result to the O-DU by using a leaf supporting transmission of one measurement result.
  • the existing O-DU cannot decode the additional measurement result list, but may ignore the new additional leafs (eg, the additional measurement result list). Therefore, an error may not occur in the existing O-DU.
  • the O-RU transmits “one measurement result (eg, one measurement result per measurement object, the most recent measurement result)” It is possible to transmit a notification including the leafs included” and "additional measurement result list including a plurality of measurement results" to the O-DU. All of the plurality of measurement values may be included in the additional measurement result list. This operation may be referred to as “method d”. In this case, one measurement result (eg, the most recent measurement result) may be included in both the existing leafs and the additional measurement result list.
  • the O-RU may transmit a common notification in which both the existing O-DU and the new O-DU can be decoded. That is, implementation complexity of the O-RU may be reduced.
  • the new O-DU may decode an additional measurement result list including a plurality of measurement results, and may perform a processing operation based on the plurality of measurement results.
  • the O-RU may transmit leafs including one measurement result. In this case, redundant information may be reduced. Alternatively, the O-RU may generate the leafs including one measurement result and an additional measurement result list including one measurement result, and return the leafs including one measurement result and the additional measurement result list to O- It can be transmitted to the DU. That is, the same measurement result may be included in the leafs including one measurement result and the list of additional measurement results. In this case, overhead due to transmission of duplicate information may increase, but the new O-DU may always decode the additional measurement result list instead of the existing leafs regardless of the number of measurement results. In this case, the implementation complexity of the O-DU may be reduced.
  • the new O-DU may support all functions of the existing O-DU. Therefore, even when existing leafs including one measurement result are received, the new O-DU can always decode the existing leafs. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU may ignore the additional measurement result list (eg, new leafs). Therefore, an error may not occur in the existing O-DU.
  • the existing O-DU may receive existing leafs including one measurement result and may decode the existing leafs. In method d, the existing O-DU may always perform reception and decoding operations for one measurement result (eg, the most recent measurement result). Therefore, the existing O-DU can operate in the conventional manner. According to the above-described method, the backward compatibility problem can be solved. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result report function>.
  • the O-RU is the number of measurement results included in the additional measurement result list (number-of-additional-measurement-result) can inform the O-DU.
  • the measurement result list may include a sequence number (seq-number).
  • a sequence number for a measurement result in the measurement result list may start from 0 and may increase in chronological order.
  • the O-DU can easily sort the measurement results in chronological order by using the sequence number as a key value in the list of additional measurement results.
  • the O-DU can easily find a specific measurement result using the sequence number.
  • number-of-additional-measurement-result and seq-number may not be used, and start-time and end-time are to be used as keys of the additional measurement result list (additional-XXXX-measurement list).
  • additional-XXXXX-measurement list can Measurement results for each measurement object may be arranged in an additional measurement result list (additional-xxxx-measurement-list[]) in chronological order.
  • the structure of the YANG model according to method 2 described above may be defined as follows.
  • the O-RU may send the measurement result to the existing O-DU (eg, O-DU supporting the previous version of O-RAN M-Plane 7.0 version, O-DU in which decoding of the additional measurement result list is impossible)
  • the O-RU may transmit leafs (eg, start-time, end-time, and XXXX-measurement-result[]) capable of transmitting one measurement result.
  • the O-RU is a new O-DU that can process an additional measurement result list (eg, O-DU supporting O-RAN M-Plane 7.0 version, O-RAN M-Plane version 7.0 or later)
  • An additional measurement result list including a plurality of measurement results may be transmitted to an O-DU that supports . This action may be "method c".
  • the YANG model described above in method c may be used as it is.
  • the transmission of the additional measurement result list (additional-XXXX-measurement-result[]) may be omitted, and only existing leafs may be used.
  • the O-RU includes an additional measurement result list (additional-XXXX-) including all of a plurality of measurement results.
  • measurement-result[]) can be transmitted to a new O-DU.
  • all measurement results eg, measurement results from the first measurement result to the last measurement result
  • the O-RU may transmit a notification including one measurement result for each measurement object to the existing O-DU.
  • the existing O-DU may set the O-RU measurement interval and the notification interval to be the same so that one measurement result is generated at one notification interval.
  • the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU may transmit only the most recent measurement result among the measurement results to the existing O-DU. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result report function>.
  • start-time and end-time can be used as keys of additional-XXXX-measurement list.
  • the O-RU may send one notification including a plurality of measurement results.
  • the O-RU may generate the additional measurement result list(s) based on the plurality of measurement results, and may transmit a notification including the additional measurement result list(s) to the O-DU.
  • an O-RU that does not support the above-described operation may transmit one measurement result to the O-DU using leafs supporting transmission of one measurement result.
  • the existing O-DU cannot decode the additional measurement result list, but may ignore the new additional leafs (eg, the additional measurement result list). Therefore, an error may not occur in the existing O-DU.
  • the O-RU transmits “one measurement result (eg, one measurement result per measurement object, the most recent measurement result)” It is possible to send a notification including the "including leafs" and "an additional measurement result list including a plurality of measurement results” to the O-DU. All of the plurality of measurement values may be included in the additional measurement result list. This action may be "method d". In this case, one measurement result (eg, the most recent measurement result) may be included in both the existing leafs and the additional measurement result list.
  • the O-RU may transmit a common notification in which both the existing O-DU and the new O-DU can be decoded. That is, implementation complexity of the O-RU may be reduced.
  • the new O-DU may decode an additional measurement result list including a plurality of measurement results, and may perform a processing operation based on the plurality of measurement results.
  • the O-RU may transmit leafs including one measurement result. In this case, redundant information may be reduced. Alternatively, the O-RU may generate leafs including one measurement result and an additional measurement result list including one measurement result, and return the leafs including one measurement result and the additional measurement result list to O- It can be transmitted to the DU. That is, the same measurement result may be included in the leafs including one measurement result and the list of additional measurement results. In this case, overhead due to transmission of duplicate information may increase, but the new O-DU may always decode the additional measurement result list instead of the existing leafs regardless of the number of measurement results. In this case, the implementation complexity of the O-DU may be reduced.
  • the new O-DU may support all functions of the existing O-DU. Therefore, even when an existing leaf including one measurement result is received, the new O-DU can always decode the existing leaf. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU may ignore the additional measurement result list (eg, new leafs). Therefore, an error may not occur in the existing O-DU.
  • the existing O-DU may receive an existing leaf including one measurement result and may decode the existing leaf. In method d, the existing O-DU may always perform reception and decoding operations for one measurement result (eg, the most recent measurement result). Therefore, the existing O-DU can operate in the conventional manner. According to the above-described method, the backward compatibility problem can be solved. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result report function>.
  • number-of-additional-measurement-result and seq-number may not be used, and start-time and end-time may be used as keys of the additional-XXXX-measurement list.
  • number-of-additional-measurement-result and seq-number may not be used, and the key for additional-XXXXX-measurement list may not be used. This action may be "Method 3".
  • the structure of the YANG model according to method 3 may be as follows.
  • the O-RU is a measurement result in the existing O-DU (eg, O-DU that supports the previous version of O-RAN M-Plane 7.0 version, O-DU that cannot decode the additional measurement result list)
  • the O-RU may transmit leafs (eg, start-time, end-time, and XXXX-measurement-result[]) capable of transmitting one measurement result.
  • the O-RU is an O-DU capable of processing an additional measurement result list (for example, O-DU supporting O-RAN M-Plane 7.0 version, O-RAN M-Plane 7.0 version later)
  • An additional measurement result list including a plurality of measurement results may be transmitted to the supported O-DU). This action may be "method c".
  • the YANG model described above in method c may be used as it is.
  • transmission of the additional measurement result list eg, additional-XXXX-measurement-result[]
  • additional-XXXX-measurement-result[] may be omitted, and only existing leafs may be used.
  • the O-RU includes an additional measurement result list (additional-XXXX-) including all of a plurality of measurement results.
  • measurement-result[]) can be transmitted to a new O-DU.
  • all measurement results eg, measurement results from the first measurement result to the last measurement result
  • the O-RU may transmit a notification including one measurement result for each measurement object to the existing O-DU.
  • the existing O-DU may set the O-RU's measurement interval and the notification interval to be the same so that one measurement result is generated at one notification interval.
  • the existing O-DU sets the notification interval to be longer than the measurement interval, the O-RU may transmit only the most recent measurement result among the measurement results to the existing O-DU. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result reporting function>.
  • the modified YANG code according to this method can be defined as follows.
  • the O-RU may send one notification including a plurality of measurement results.
  • the O-RU may generate the additional measurement result list(s) based on the plurality of measurement results, and may transmit a notification including the additional measurement result list(s) to the O-DU.
  • the O-RU that does not support the above-described operation may transmit one measurement result to the O-DU using leafs supporting transmission of one measurement result.
  • the existing O-DU cannot decode the additional measurement result list, but may ignore the new additional leafs (eg, the additional measurement result list). Therefore, an error may not occur in the existing O-DU.
  • the O-RU includes "one measurement result (eg, one measurement result per measurement object, the most recent measurement result)" It is possible to send a notification including the "leaves to do” and "additional measurement result list including a plurality of measurement results” to the O-DU. All of the plurality of measurement values may be included in the additional measurement result list. This action may be "method d". In this case, one measurement result (eg, the most recent measurement result) may be included in both the existing leafs and the additional measurement result list.
  • the O-RU may transmit a common notification in which both the existing O-DU and the new O-DU can be decoded. That is, implementation complexity of the O-RU may be reduced.
  • the new O-DU may decode an additional measurement result list including a plurality of measurement results, and may perform a processing operation based on the plurality of measurement results.
  • the O-RU may transmit leafs including one measurement result. In this case, redundant information may be reduced. Alternatively, the O-RU may generate leafs including one measurement result and an additional measurement result list including one measurement result, and return the leafs including one measurement result and the additional measurement result list to O- It can be transmitted to the DU. That is, the same measurement result may be included in the leafs including one measurement result and the list of additional measurement results. In this case, overhead due to transmission of duplicate information may increase, but the new O-DU may always decode the additional measurement result list instead of the existing leafs regardless of the number of measurement results. In this case, the implementation complexity of the O-DU may be reduced.
  • the new O-DU may support all functions of the existing O-DU. Therefore, even when existing leafs including one measurement result are received, the new O-DU can always decode the existing leafs. On the other hand, the existing O-DU may not be able to decode the additional measurement result list. The existing O-DU may ignore the additional measurement result list (eg, new leafs). Therefore, an error may not occur in the existing O-DU.
  • the existing O-DU may receive existing leafs including one measurement result and may decode the existing leafs. In method d, the existing O-DU may always perform reception and decoding operations for one measurement result (eg, the most recent measurement result). Therefore, the existing O-DU can operate in the conventional manner. According to the above-described method, the backward compatibility problem can be solved. Detailed methods of the above-described operation are described in ⁇ Method for ensuring backward compatibility and interoperability with equipment that does not support a multi-measurement result reporting function>.
  • number-of-additional-measurement-result and seq-number may not be used, and the key of additional-XXXXX-measurement list may not be used.
  • Method a, method b, method c, and method d, as well as combinations and/or variations of the method(s) described above, may be used.
  • parameters may be set as shown in Table 3 below.
  • the O-RU may transmit a notification including two measurement results for the measurement object A and four measurement results for the measurement object B to the O-DU.
  • the first measurement result for measurement object A (eg, a measurement value in the measurement interval of 0-30 minutes) may be included in the transceiver-stats in the notification, and the measurement interval of 0-30 minutes The start-time and end-time corresponding to can be set.
  • the second measurement result for the measurement target A (eg, the measurement value in the measurement period of 30 to 60 minutes) may be included in additional-transceiver-measurement-result, and start- corresponding to the measurement period of 30 to 60 minutes time and end-time can be set.
  • the first measurement result for measurement object B (eg, a measurement value in the measurement interval of 0 to 15 minutes) may be included in rx-window-stats in the notification, and start- corresponding to the measurement interval of 0 to 15 minutes time and end-time can be set.
  • Second measurement result for measurement object B (for example, measured value in the measuring interval of 15 to 30 minutes), third measurement result for measurement object B (for example, measurement value in measurement interval of 30 to 45 minutes) ), and a fourth measurement result for measurement object B (eg, a measurement value in a measurement interval of 45 to 60 minutes) may be included in additional-rx-window-measurement-result, and a measurement interval of 15 to 30 minutes , start-time and end-time corresponding to each of the measurement period of 30 to 45 minutes, and the measurement period of 45 to 60 minutes may be set.
  • the measurement result(s) from the first measurement result to the last previous measurement result are additional-transceiver-measurement-result and additional-rx-window-measurement- It may be set in result, and the last measurement result may be set in the existing transceiver-stats and rx-window-stats (eg, existing rx-window-stats) of measurement object A and measurement object B, respectively.
  • start-time and end-time which are key values, may be set to “ordered-by user”.
  • the transceiver-stats for measurement object A may be omitted within the notification, and the first measurement result for measurement object A (eg, the measurement value in the measurement interval of 0-30 minutes) and A second measurement result (eg, a measurement value in a measurement interval of 30 to 60 minutes) may be included in an additional-transceiver-measurement-result in the notification.
  • the first measurement result for measurement object A eg, the measurement value in the measurement interval of 0-30 minutes
  • a second measurement result eg, a measurement value in a measurement interval of 30 to 60 minutes
  • rx-window-stats for measurement object B may be omitted, and the first measurement result for measurement object B (for example, a measurement value in the measurement interval of 0 to 15 minutes), the second measurement result ( For example, a measured value in a measuring interval of 15-30 minutes), a third measurement result (eg a measured value in a measuring interval of 30 to 45 minutes), and a fourth measurement result (eg 45-60) All measurement values in the measurement interval of minutes) may be included in additional-rx-window-measurement-result.
  • the first measurement result for measurement object B for example, a measurement value in the measurement interval of 0 to 15 minutes
  • the second measurement result For example, a measured value in a measuring interval of 15-30 minutes
  • a third measurement result eg a measured value in a measuring interval of 30 to 45 minutes
  • a fourth measurement result eg 45-60 All measurement values in the measurement interval of minutes
  • the result of one measurement for measurement object A is the transceiver-stats in the notification.
  • a first measurement result eg, a measurement value in a measurement interval of 0 to 30 minutes
  • a second measurement result eg, a measurement value in a measurement interval of 30 to 60 minutes
  • additional-transceiver-measurement-result in the notification.
  • One measurement result for measurement object B (eg, the last measurement value in the notification interval (eg, the measurement value in the measurement interval of 45 to 60 minutes)) may be included in rx-window-stats in the notification, 1st measurement result for measurement object B (eg measured value in the measurement interval of 0 to 15 minutes), 2nd measurement result (eg measurement value in the measurement interval of 15 - 30 minutes), 3rd measurement Both the result (eg, the measured value in the measurement interval of 30 to 45 minutes) and the fourth measurement result (eg, the measured value in the measurement interval of 45 to 60 minutes) are additional-rx-window-measurement-result can be included in
  • each of additional-transceiver-measurement-result, additional-rx-window-measurement-result, and additional-tx-measurement-result, additional-epe-measurement-result is YANG rather than notification It can be included in the front part of the module, transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result and epe-measurement-result.
  • transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result, and epe-measurement-result which are the front parts of the YANG module, can be extended.
  • the O-DU can check the measurement-result by using get RPC instead of the notification method. In this case, since the O-DU periodically transmits the get RPC, an overhead may occur accordingly.
  • the entire structure in measurement-result-stats including measurement results of all measurement objects may be repeatedly added to the notification in chronological order for each measurement time.
  • an additional measurement result list (eg, list additional-transceiver-measurement-result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result), the YANG model may be extended.
  • the additional measurement result list may not be added to the statistical information on the corresponding measurement object for each measurement object, and the entire structure in the measurement-result-stats including the measurement results of all measurement objects is in chronological order for each measurement time may be added to the notice.
  • the YANG model according to ⁇ Method B-1> can be defined as follows.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치가 개시된다. O-RU의 동작 방법은, 통지 간격에 따른 하나의 통지 구간에서 제1 측정 대상에 대한 측정 동작을 수행함으로써 복수의 제1 측정 결과들을 생성하는 단계, 상기 복수의 제1 측정 결과들을 포함하는 제1 측정 결과 리스트를 생성하는 단계, 및 상기 제1 측정 결과 리스트를 포함하는 메시지를 O-DU에 전송하는 단계를 포함한다.

Description

프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치
본 발명은 프론트홀(fronthaul) 인터페이스를 포함하는 통신 시스템에서 통신 기술에 관한 것으로, 더욱 상세하게는 통신 시스템의 성능 관리를 위한 파라미터들을 효율적으로 송수신하기 위한 기술에 관한 것이다.
정보통신 기술의 발전과 더불어 다양한 무선 통신 기술이 개발되고 있다. 대표적인 무선 통신 기술로 3GPP(3rd generation partnership project) 표준에서 규정된 LTE(long term evolution), NR(new radio) 등이 있다. LTE는 4G(4th Generation) 무선 통신 기술들 중에서 하나의 무선 통신 기술일 수 있고, NR은 5G(5th Generation) 무선 통신 기술들 중에서 하나의 무선 통신 기술일 수 있다.
4G 통신 시스템(예를 들어, LTE를 지원하는 통신 시스템)의 상용화 이후에 급증하는 무선 데이터의 처리를 위해, 4G 통신 시스템의 주파수 대역(예를 들어, 6GHz 이하의 주파수 대역)뿐만 아니라 4G 통신 시스템의 주파수 대역보다 높은 주파수 대역(예를 들어, 6GHz 이상의 주파수 대역)을 사용하는 5G 통신 시스템(예를 들어, NR을 지원하는 통신 시스템)이 고려되고 있다. 5G 통신 시스템은 eMBB(enhanced Mobile BroadBand), URLLC(Ultra-Reliable and Low Latency Communication) 및 mMTC(massive Machine Type Communication)을 지원할 수 있다.
한편, O-RAN(open-radio access network) 얼라이언스(alliance)는 프론트홀(fronthaul) 인터페이스를 규정하고 있다. 프론트홀 인터페이스는 기지국(예를 들어, eNB, gNB)을 구성하는 O-DU(O-RAN distributed unit)과 O-RU(O-RAN radio unit) 간의 인터페이스일 수 있다. O-DU는 LLS-CU(lower layer split-central unit)로 지칭될 수 있고, O-RU는 LLS-DU(lower layer split-distributed unit)로 지칭될 수 있다. LLS-CU 및 LLS-DU는 3GPP(3rd generation partnership project)에서 사용되는 용어일 수 있다. 프론트홀 인터페이스를 포함하는 통신 시스템의 성능 관리를 위한 방법들이 필요할 수 있다. 특히, O-RAN의 M-Plane 기능을 위해, O-RU와 O-DU 간에 성능 관리를 위한 다양한 파라미터들을 송수신하기 위한 방법들이 필요할 수 있다.
상기와 같은 문제점을 해결하기 위한 본 발명의 목적은 프론트홀(fronthaul) 인터페이스를 포함하는 통신 시스템에서 성능 관리를 위한 파라미터들의 송수신을 위한 방법 및 장치를 제공하는 데 있다.
상기 목적을 달성하기 위한 본 발명의 제1 실시예에 따른 O-RU의 동작 방법은, 통지 간격에 따른 하나의 통지 구간에서 제1 측정 대상에 대한 측정 동작을 수행함으로써 복수의 제1 측정 결과들을 생성하는 단계, 상기 복수의 제1 측정 결과들을 포함하는 제1 측정 결과 리스트를 생성하는 단계, 및 상기 제1 측정 결과 리스트를 포함하는 메시지를 O-DU에 전송하는 단계를 포함한다.
상기 O-RU의 동작 방법은, 상기 복수의 제1 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 제1 통지를 생성하는 단계를 더 포함할 수 있으며, 상기 메시지는 제1 통지를 더 포함할 수 있다.
상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩될 수 있고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 상기 O-DU에서 디코딩될 수 있다.
상기 O-RU의 동작 방법은, 상기 하나의 통지 구간에서 제2 측정 대상에 대한 측정 동작을 수행함으로써 복수의 제2 측정 결과들을 생성하는 단계, 및 상기 복수의 제2 측정 결과들을 포함하는 제2 측정 결과 리스트를 생성하는 단계를 더 포함할 수 있으며, 상기 메시지는 상기 제2 측정 결과 리스트를 더 포함할 수 있다.
상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들 각각에 대한 측정 시작 시간 정보 및 측정 종료 시간 정보를 더 포함할 수 있다.
상기 복수의 제1 측정 결과들은 상기 제1 측정 결과 리스트 내에서 측정 시간의 오름차순으로 정렬될 수 있다.
상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들의 개수를 지시하는 정보 및 상기 복수의 제1 측정 결과들 각각의 시퀀스 번호 중에서 적어도 하나를 더 포함할 수 있다.
상기 통지 간격은 하나의 측정 동작이 수행되는 측정 간격보다 길도록 상기 O-DU에 의해 설정될 수 있다.
상기 제1 측정 대상은 트랜시버, 수신 윈도우, 전송 측정, EPE, 또는 심볼 RSSI일 수 있다.
상기 목적을 달성하기 위한 본 발명의 제2 실시예에 따른 O-RU의 동작 방법은, 통지 간격에 따른 하나의 통지 구간에서 제1 측정 대상에 대한 측정 동작을 수행함으로써 제1 측정 결과를 생성하는 단계, 상기 제1 측정 결과를 포함하는 제1 통지를 생성하는 단계, 상기 제1 측정 결과를 포함하는 제1 측정 결과 리스트를 생성하는 단계, 및 상기 제1 통지 및 상기 제1 측정 결과 리스트를 포함하는 메시지를 O-DU에 전송하는 단계를 포함한다.
상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩될 수 있고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 상기 O-DU에서 디코딩될 수 있다.
상기 통지 간격은 하나의 측정 동작이 수행되는 측정 간격과 동일하도록 상기 O-DU에 의해 설정될 수 있다.
상기 O-RU의 동작 방법은, 상기 하나의 통지 구간에서 제2 측정 대상에 대한 측정 동작을 수행함으로써 제2 측정 결과를 생성하는 단계, 상기 제2 측정 결과를 포함하는 제2 통지를 생성하는 단계, 및 상기 제2 측정 결과를 포함하는 제2 측정 결과 리스트를 생성하는 단계를 더 포함할 수 있으며, 상기 메시지는 상기 제2 통지 및 상기 제2 측정 결과 리스트를 더 포함할 수 있다.
상기 목적을 달성하기 위한 본 발명의 제3 실시예에 따른 O-DU의 동작 방법은, O-RU를 위한 통지 간격 및 측정 간격을 설정하는 단계, 제1 측정 대상에 대한 복수의 제1 측정 결과들을 포함하는 제1 측정 결과 리스트를 포함하는 메시지를 상기 O-RU로부터 수신하는 단계, 및 상기 제1 측정 결과 리스트를 디코딩함으로써 상기 복수의 제1 측정 결과들을 확인하는 단계를 포함하며, 상기 복수의 제1 측정 결과들은 상기 통지 간격에 따른 하나의 통지 구간에서 측정된다.
상기 메시지는 상기 복수의 제1 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 제1 통지를 더 포함할 수 있다.
상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩될 수 있고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 다른 O-DU에서 디코딩될 수 있다.
상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들 각각에 대한 측정 시작 시간 정보 및 측정 종료 시간 정보를 더 포함할 수 있다.
상기 복수의 제1 측정 결과들은 상기 제1 측정 결과 리스트 내에서 측정 시간의 오름차순으로 정렬될 수 있다.
상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들의 개수를 지시하는 정보 및 상기 복수의 제1 측정 결과들 각각의 시퀀스 번호 중에서 적어도 하나를 더 포함할 수 있다.
상기 제1 측정 대상은 트랜시버, 수신 윈도우, 전송 측정, EPE, 또는 심볼 RSSI일 수 있다.
본 출원에 의하면, O-RU(O-RAN(open-radio access network) radio unit)와 O-DU(O-RAN distributed unit) 간에 성능 관리를 위한 다양한 파리미터들은 효율적으로 송수신될 수 있다. O-RAN의 M-Plane에서 정의된 YANG 모델에서, 복수의 측정 결과들(예를 들어, 측정 대상(object) 별 복수의 측정 결과들)은 하나의 통지(notification) 메시지를 사용하여 전송될 수 있다. 이 동작은 기존 M-Plane의 기능에 영향을 주지 않을 수 있다. 따라서 프론트홀(fronthaul) 인터페이스를 포함하는 통신 시스템의 성능은 향상될 수 있다.
도 1은 통신 시스템의 제1 실시예를 도시한 개념도이다.
도 2는 통신 시스템을 구성하는 통신 노드의 제1 실시예를 도시한 블록도이다.
도 3은 통신 시스템에서 LLS를 지원하는 기지국의 제1 실시예를 도시한 블록도이다.
도 4는 통신 시스템에서 O-DU와 O-RU 간의 인터페이스 구조의 제1 실시예를 도시한 블록도이다.
도 5a는 계층적 M-Plane 모델의 제1 실시예를 도시한 블록도이다.
도 5b는 하이브리드 M-Plane 모델의 제2 실시예를 도시한 블록도이다.
도 6은 M-Plane의 프로토콜 스택의 제1 실시예를 도시한 블록도이다.
도 7은 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제1 실시예를 도시한 개념도이다.
도 8은 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제2 실시예를 도시한 개념도이다.
도 9는 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제3 실시예를 도시한 개념도이다.
도 10은 방법 A를 사용하는 YANG 모델에서 트랜시버에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 11은 방법 A를 사용하는 YANG 모델에서 수신 윈도우에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 12는 방법 A를 사용하는 YANG 모델에서 EPE에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 13은 방법 A를 사용하는 YANG 모델에서 전송 측정에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 14는 방법 A를 사용하는 YANG 모델에서 심볼 RSSI에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. "및/또는" 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
본 출원의 실시예들에서, "A 및 B 중에서 적어도 하나"는 "A 또는 B 중에서 적어도 하나" 또는 "A 및 B 중 하나 이상의 조합들 중에서 적어도 하나"를 의미할 수 있다. 또한, 본 출원의 실시예들에서, "A 및 B 중에서 하나 이상"은 "A 또는 B 중에서 하나 이상" 또는 "A 및 B 중 하나 이상의 조합들 중에서 하나 이상"을 의미할 수 있다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.
본 발명에 따른 실시예들이 적용되는 통신 시스템(communication system)이 설명될 것이다. 통신 시스템은 4G 통신 시스템(예를 들어, LTE(long-term evolution) 통신 시스템, LTE-A 통신 시스템), 5G 통신 시스템(예를 들어, NR(new radio) 통신 시스템) 등일 수 있다. 4G 통신 시스템은 6GHz 이하의 주파수 대역에서 통신을 지원할 수 있고, 5G 통신 시스템은 6GHz 이하의 주파수 대역뿐만 아니라 6GHz 이상의 주파수 대역에서 통신을 지원할 수 있다. 본 발명에 따른 실시예들이 적용되는 통신 시스템은 아래 설명된 내용에 한정되지 않으며, 본 발명에 따른 실시예들은 다양한 통신 시스템에 적용될 수 있다. 여기서, 통신 시스템은 통신 네트워크(network)와 동일한 의미로 사용될 수 있고, "LTE"는 "4G 통신 시스템", "LTE 통신 시스템" 또는 "LTE-A 통신 시스템"을 지시할 수 있고, "NR"은 "5G 통신 시스템" 또는 "NR 통신 시스템"을 지시할 수 있다.
도 1은 통신 시스템의 제1 실시예를 도시한 개념도이다.
도 1을 참조하면, 통신 시스템(100)은 복수의 통신 노드들(110-1, 110-2, 110-3, 120-1, 120-2, 130-1, 130-2, 130-3, 130-4, 130-5, 130-6)을 포함할 수 있다. 또한, 통신 시스템(100)은 코어 네트워크(core network)(예를 들어, S-GW(serving-gateway), P-GW(PDN(packet data network)-gateway), MME(mobility management entity))를 더 포함할 수 있다. 통신 시스템(100)이 5G 통신 시스템(예를 들어, NR(new radio) 시스템)인 경우, 코어 네트워크는 AMF(access and mobility management function), UPF(user plane function), SMF(session management function) 등을 포함할 수 있다.
복수의 통신 노드들(110 내지 130)은 3GPP(3rd generation partnership project) 표준에서 규정된 통신 프로토콜(예를 들어, LTE 통신 프로토콜, LTE-A 통신 프로토콜, NR 통신 프로토콜 등)을 지원할 수 있다. 복수의 통신 노드들(110 내지 130)은 CDMA(code division multiple access) 기술, WCDMA(wideband CDMA) 기술, TDMA(time division multiple access) 기술, FDMA(frequency division multiple access) 기술, OFDM(orthogonal frequency division multiplexing) 기술, Filtered OFDM 기술, CP(cyclic prefix)-OFDM 기술, DFT-s-OFDM(discrete Fourier transform-spread-OFDM) 기술, OFDMA(orthogonal frequency division multiple access) 기술, SC(single carrier)-FDMA 기술, NOMA(Non-orthogonal Multiple Access) 기술, GFDM(generalized frequency division multiplexing) 기술, FBMC(filter bank multi-carrier) 기술, UFMC(universal filtered multi-carrier) 기술, SDMA(Space Division Multiple Access) 기술 등을 지원할 수 있다. 복수의 통신 노드들 각각은 다음과 같은 구조를 가질 수 있다.
도 2는 통신 시스템을 구성하는 통신 노드의 제1 실시예를 도시한 블록도이다.
도 2를 참조하면, 통신 노드(200)는 적어도 하나의 프로세서(210), 메모리(220) 및 네트워크와 연결되어 통신을 수행하는 송수신 장치(230)를 포함할 수 있다. 또한, 통신 노드(200)는 입력 인터페이스 장치(240), 출력 인터페이스 장치(250), 저장 장치(260) 등을 더 포함할 수 있다. 통신 노드(200)에 포함된 각각의 구성 요소들은 버스(bus)(270)에 의해 연결되어 서로 통신을 수행할 수 있다.
프로세서(210)는 메모리(220) 및 저장 장치(260) 중에서 적어도 하나에 저장된 프로그램 명령(program command)을 실행할 수 있다. 프로세서(210)는 중앙 처리 장치(central processing unit, CPU), 그래픽 처리 장치(graphics processing unit, GPU), 또는 본 발명의 실시예들에 따른 방법들이 수행되는 전용의 프로세서를 의미할 수 있다. 메모리(220) 및 저장 장치(260) 각각은 휘발성 저장 매체 및 비휘발성 저장 매체 중에서 적어도 하나로 구성될 수 있다. 예를 들어, 메모리(220)는 읽기 전용 메모리(read only memory, ROM) 및 랜덤 액세스 메모리(random access memory, RAM) 중에서 적어도 하나로 구성될 수 있다.
다시 도 1을 참조하면, 통신 시스템(100)은 복수의 기지국들(base stations)(110-1, 110-2, 110-3, 120-1, 120-2), 복수의 단말들(130-1, 130-2, 130-3, 130-4, 130-5, 130-6)을 포함할 수 있다. 제1 기지국(110-1), 제2 기지국(110-2) 및 제3 기지국(110-3) 각각은 매크로 셀(macro cell)을 형성할 수 있다. 제4 기지국(120-1) 및 제5 기지국(120-2) 각각은 스몰 셀(small cell)을 형성할 수 있다. 제1 기지국(110-1)의 셀 커버리지(cell coverage) 내에 제4 기지국(120-1), 제3 단말(130-3) 및 제4 단말(130-4)이 속할 수 있다. 제2 기지국(110-2)의 셀 커버리지 내에 제2 단말(130-2), 제4 단말(130-4) 및 제5 단말(130-5)이 속할 수 있다. 제3 기지국(110-3)의 셀 커버리지 내에 제5 기지국(120-2), 제4 단말(130-4), 제5 단말(130-5) 및 제6 단말(130-6)이 속할 수 있다. 제4 기지국(120-1)의 셀 커버리지 내에 제1 단말(130-1)이 속할 수 있다. 제5 기지국(120-2)의 셀 커버리지 내에 제6 단말(130-6)이 속할 수 있다.
여기서, 복수의 기지국들(110-1, 110-2, 110-3, 120-1, 120-2) 각각은 NB(NodeB), eNB(evolved NodeB), gNB, ABS(advanced base station), HR-BS(high reliability-base station), BTS(base transceiver station), 무선 기지국(radio base station), 무선 트랜시버(radio transceiver), 액세스 포인트(access point), 액세스 노드(node), RAS(radio access station), MMR-BS(mobile multihop relay-base station), RS(relay station), ARS(advanced relay station), HR-RS(high reliability-relay station), HNB(home NodeB), HeNB(home eNodeB), RSU(road side unit), RRH(radio remote head), TP(transmission point), TRP(transmission and reception point), 매크로(macro) 셀, 피코(pico) 셀, 마이크로(micro) 셀, 펨토(femto) 셀 등으로 지칭될 수 있다.
복수의 단말들(130-1, 130-2, 130-3, 130-4, 130-5, 130-6) 각각은 UE(user equipment), TE(terminal equipment), AMS(advanced mobile station), HR-MS(high reliability-mobile station), 터미널(terminal), 액세스 터미널(access terminal), 모바일 터미널(mobile terminal), 스테이션(station), 가입자 스테이션(subscriber station), 모바일 스테이션(mobile station), 휴대 가입자 스테이션(portable subscriber station), 노드(node), 다바이스(device), OBU(on board unit) 등으로 지칭될 수 있다.
한편, 통신 시스템에서 기지국(예를 들어, eNB, gNB)은 프론트홀(fronthaul) 인터페이스를 지원할 수 있다. 여기서, 프론트홀 인터페이스는 O-RAN(open-radio access network) 얼라이언스(alliance)에서 규정된 프론트홀 인터페이스일 수 있다. 이 경우, 기지국은 O-DU(O-RAN distributed unit) 및 하나 이상의 O-RU(O-RAN radio unit)들을 포함할 수 있다. O-DU와 하나 이상의 O-RU들 간의 통신은 프론트홀 인터페이스를 통해 수행될 수 있다. O-DU는 3GPP에서 규정된 LLS-CU(lower layer split-central unit)일 수 있고, O-RU는 3GPP에서 규정된 LLS-DU(lower layer split-distributed unit)일 수 있다. O-DU 및 O-RU 각각은 도 2에 도시된 통신 노드(200)와 동일 또는 유사하게 구성될 수 있다.
다음으로, 프론트홀에서 통신 방법들이 설명될 것이다. 통신 노드들 중에서 제1 통신 노드에서 수행되는 방법(예를 들어, 신호의 전송 또는 수신)이 설명되는 경우에도 이에 대응하는 제2 통신 노드는 제1 통신 노드에서 수행되는 방법과 상응하는 방법(예를 들어, 신호의 수신 또는 전송)을 수행할 수 있다. 즉, O-DU의 동작이 설명된 경우에 이에 대응하는 O-RU는 O-DU의 동작과 상응하는 동작을 수행할 수 있다. 반대로, O-RU의 동작이 설명된 경우에 이에 대응하는 O-DU는 O-RU의 동작과 상응하는 동작을 수행할 수 있다.
도 3은 통신 시스템에서 LLS(lower layer split)를 지원하는 기지국의 제1 실시예를 도시한 블록도이다.
도 3을 참조하면, 기지국(300)은 O-DU(311), O-RU #1(321), O-RU #2(322) 등을 포함할 수 있다. 예를 들어, 기지국(300)은 복수의 O-RU들을 포함할 수 있다. O-DU(311)와 O-RU들(321, 322) 간의 통신은 프론트홀 인터페이스를 통해 수행될 수 있다. 프론트홀 인터페이스는 LLS-제어 평면(control plane) 및 LLS-사용자 평면(user plane)을 포함할 수 있다. LLS-제어 평면은 "LLS-C" 또는 "LLS-C-Plane"으로 지칭될 수 있고, LLS-사용자 평면은 "LLS-U" 또는 "LLS-U-Plane"으로 지칭될 수 있다.
O-DU(311)는 RLC(radio link control) 계층 기능, MAC(medium access control) 계층 기능, 및/또는 높은(high)-PHY(physical) 계층 기능을 수행하는 논리 노드(logical node)일 수 있다. O-DU(311)는 복수의 O-RU들(321, 322)을 제어할 수 있다. O-RU들(321, 322) 각각은 낮은(low)-PHY 계층 기능 및/또는 RF(radio frequency) 처리 기능을 수행하는 논리 노드일 수 있다. O-RU들(321, 322)은 O-DU(311)와 통신을 수행함으로써 제어 정보 및/또는 데이터를 송수신할 수 있다. 제어 정보는 실시간(real-time) 제어 정보일 수 있다. 데이터는 사용자 평면 데이터일 수 있다. O-RU들(321, 322)은 O-DU(311)의 제어에 기초하여 동작할 수 있다.
도 4는 통신 시스템에서 O-DU와 O-RU 간의 인터페이스 구조의 제1 실시예를 도시한 블록도이다.
도 4를 참조하면, O-DU 및 O-RU 각각은 CUS-Plane(예를 들어, O-RAN CUS-Plane)을 포함할 수 있고, CUS-Plane 기능에 따른 통신을 수행할 수 있다. 또한, O-DU 및 O-RU 각각은 M(management)-Plane(예를 들어, O-RAN M-Plane)을 포함할 수 있고, M-Plane 기능에 따른 통신을 수행할 수 있다. 즉, O-DU 및 O-RU는 CUS-Plane 기능뿐만 아니라 M-Plane 기능을 수행할 수 있다. M-Plane 기능은 O-RU의 초기화, 설정, 관리 등을 지원할 수 있다. M-Plane은 NETCONF 및/또는 YANG 모델(이하, "NETCONF/YANG 모델"이라 함)을 기반으로 하는 개방형 인터페이스를 사용할 수 있다. M-Plane은 스타트 업 초기화(start up installation), 소프트웨어 관리(software management), 설정 관리(configuration management), 성능 관리(performance management), 폴트 관리(fault management), 파일 관리(file management) 등을 지원할 수 있다. O-RAN에서 M-Plane 구조는 다음과 같을 수 있다.
도 5a는 계층적(hierarchical) M-Plane 모델의 제1 실시예를 도시한 블록도이고, 도 5b는 하이브리드(hybrid) M-Plane 모델의 제2 실시예를 도시한 블록도이다.
도 5a를 참조하면, 계층적 M-Plane 모델에서 O-RU는 하나 이상의 O-DU들에 의해 관리될 수 있다. O-DU와 O-RU 간에 NETCONF 기반의 M-Plane 인터페이스가 사용될 수 있다. O-DU와 NMS(network management system) 간의 인터페이스는 존재할 수 있으나, NMS는 O-RU를 직접 관리하지 않을 수 있다. 즉, NMS는 O-DU를 통해 O-RU를 관리할 수 있다. O-RU와 NMS 간에 직접적인 인터페이스는 존재하지 않을 수 있다. NMS는 도 4에 도시된 관리 시스템을 의미할 수 있다.
도 5b를 참조하면, 하이브리드 M-Plane 모델에서 O-DU와 O-RU 간의 논리적(logical) 인터페이스뿐만 아니라 NMS와 O-RU 간에 직접(direct) 논리적 인터페이스가 존재할 수 있다. NMS는 O-RU에 대한 소프트웨어 관리 기능, 성능 관리 기능, 설정 관리 기능, 및/또는 폴트 관리 기능을 지원할 수 있다. NMS와 O-RU는 엔드-투-엔드(end-to-end) IP(internet protocol) 계층 연결성(connectivity)을 가질 수 있다.
도 6은 M-Plane의 프로토콜 스택(stack)의 제1 실시예를 도시한 블록도이다.
도 6을 참조하면, 트랜스포트(transport) 네트워크 계층은 IP 트랜스포트 계층이 위에서 동작할 수 있다. TCP(transmission control protocol)/SSH(secure shell) 계층은 O-DU/NMS와 O-RU 간에 M-Plane 메시지를 송수신하기 위해 사용될 수 있다.
NETCONF/YANG 모델은 네트워크 요소 관리 프로토콜(network element management protocol) 및 데이터 모델링 언어(data modeling language)로 사용될 수 있다. NETCONF/YANG 모델은 멀티 벤더(multi-vendor) O-RU/O-DU 간의 효율적인 통합 및 관리를 위한 개방형 관리 방식을 지원할 수 있다.
NETCONF는 설정 상태(configuration state) 정보를 획득할 수 있고, 설정의 변경 동작을 지원할 수 있다. 또한, NETCONF는 보안 트랜스포트를 제공하는 트랜스포트 계층(예를 들어, SSH 계층) 위에서 XML-RPC 형태의 메시지를 전달할 수 있다. 겟(get) 및 겟 설정 RRC 동작(get-config RPC operation) 각각은 설정의 전체, 설정의 일부, 상태 데이터의 전체, 및/또는 상태 데이터의 일부를 획득하기 위해 사용될 수 있다. 수정 설정 동작(edit-config operation)은 설정 데이터 스토어(configuration data store)에서 설정 요소를 변경, 추가, 및/또는 삭제하기 위해 사용될 수 있다.
NETCONF에서 통지(notification) 지원은 이벤트 스트림(event stream)에 기반할 수 있다. NETCONF 클라이언트(예를 들어, O-DU)는 특정 이벤트에 대한 통지의 수신을 원할 수 있다. 이 경우, 해당 이벤트 스트림에 대한 구독(subscription)이 요청되면, 생성-구독 동작(create-subscription operation)이 사용될 수 있다.
성능 관리 기능은 M-Plane의 주요 기능일 수 있다. 성능 관리 기능은 O-RU 동작의 최적화를 위한 기능일 수 있다. O-DU(예를 들어, NETCONF 클라이언트)는NETCONF/YANG 모델을 이용하여 O-RU 동작 관련 정보(예를 들어, 트랜시버(transceiver), 수신 윈도우(rx-window), 전송 윈도우(tx-window), EPE(energy, power, environmental), RSSI(received signal strength indicator)(예를 들어, 심볼 RSSI))를 수집할 수 있다. 예를 들어, O-DU는 성능 관리를 위한 설정 및/또는 상태 정보를 수집할 수 있다.
성능 관리를 위해 O-RAN 규격에서 정의 및/또는 사용되는 측정 대상(object)(예를 들어, TX_POWER, RX_POWER, RX_ON_TIME, TX_TOTAL 등)는 5개 이상의 측정 그룹(예를 들어, 트랜시버 통계(transceiver-stats) 그룹, 수신 윈도우 통계(rx-window-stats) 그룹, 전송 측정 통계(tx-measurement-stats) 그룹, EPE 통계(epe-stats) 그룹, RSSI 통계(rssi-stats) 그룹 등)들로 분류 및/또는 관리될 수 있다. RSSI 통계 그룹은 심볼 RSSI 통계 그룹일 수 있다. 측정 간격(measurement-interval)은 측정 그룹 별로 독립적으로 설정될 수 있다. 예를 들어, 측정 간격은 측정 그룹 별로 다를 수 있다. 트랜시버 측정 간격(transceiver-measurement-interval), 수신 윈도우 측정 간격(rx-window-measurement-interval), 전송 측정 간격(tx-measurement-interval), EPE 측정 간격(epe-measurement interval), 및/또는 RSSI 측정 간격(rssi-measurement-interval)은 서로 독립적으로 설정될 수 있다.
O-DU(예를 들어, NETCONF 클라이언트)에 의해 설정된 각 측정 간격 설정에 따라 O-RU에서 측정된 측정 결과(예를 들어, 측정 값)는 통지 간격에 따른 시점에서 NETCONF 통지 메커니즘을 이용하여 전송될 수 있다. 예를 들어, O-RU는 측정 결과를 주기적으로 O-DU에 전송할 수 있다. 다른 방법으로, O-RU는 측정 시간 별 측정 결과를 로컬 디스크에 저장할 수 있고, 파일 업로드 간격(file-upload-interval)에 따른 시점에서 측정 결과를 O-DU에 업로드할 수 있다. 이 경우, 통지 간격은 측정 간격과 다르게 설정될 수 있다. 실시예에서 측정 간격은 측정 구간을 의미할 수 있고, 통지 간격은 통지 구간을 의미할 수 있고, "통지의 송수신 동작"은 "통지 메시지의 송수신 동작"을 의미할 수 있다.
예를 들어, 측정 대상 #A의 측정 간격은 3분으로 설정될 수 있고, 측정 대상 #B의 측정 간격은 5분으로 설정할 수 있다. 성능 관리 정보의 전송 동작을 효율적으로 수행하기 위해, 통지 간격은 15분으로 설정될 수 있다. 이 경우, NETCONF 통지의 전송 절차에서, 측정 대상 #A에 대한 5회의 측정 결과들 및 측정 대상 #B에 대한 3회의 측정 결과들을 포함하는 하나의 통지(예를 들어, 통지 메시지)를 전송하는 것이 바람직할 수 있다. 통지 간격이 특정 측정 대상의 측정 간격보다 길게 설정된 경우, 통지의 전송 시점에 복수의 측정 결과들은 O-RU에 존재할 수 있다. 특정 측정 대상에 대한 복수의 측정 결과들은 하나의 통지에 포함될 수 있다.
O-RAN의 M-Plane에서 정의된 기존 YANG 모델은 복수의 측정 결과들을 포함하는 하나의 통지의 송수신 동작을 지원하지 못할 수 있다. 실시예에서 "복수의 측정 결과들을 포함하는 하나의 통지의 송수신 동작"은 "멀티 측정 결과 보고 기능"으로 지칭될 수 있다. 즉, 기존 YANG 모델은 측정 대상 별 1회의 측정 결과를 포함하는 하나의 통지를 전송할 수 있다. 따라서 통지 간격이 측정 대상의 측정 간격보다 길게 설정된 경우, 한 개의 측정 결과만을 포함하는 통지는 전송될 수 있고, 해당 통지 간격에서 나머지 측정 결과(들)은 O-DU(예를 들어, NETCONF 클라이언트)에게 전달될 수 없다. 아래에서 상술한 문제점들을 해결하기 위한 방법들이 설명될 것이다.
O-RAN의 M-Plane(이하, "O-RAN M-Plane"이라 함)에서 성능 관리에 관련하여, O-DU와 O-RU간의 인터페이스 및 설정 정보는 o-ran-performance-management.yang 모듈에서 정의될 수 있다. O-RAN M-Plane에서 "장치들 간에 송수신되는 관리 정보에 대한 포맷" 및 "관리 정보의 전송 절차"는 NETCONF/YANG 모델을 사용하여 정의될 수 있다.
아래 표 1 및 표 2에서 o-ran-performance-management.yang 모듈에서 성능 관리를 위해 사용하는 주요 파라미터들은 정의될 수 있다. O-RAN 규격의 업데이트에 따라 다른 파라미터들은 표 1 및 표 2에 추가될 수 있고, 표 1 및 표 2에 정의된 파라미터(들)은 변경될 수 있다.
Figure PCTKR2021017105-appb-T000001
Figure PCTKR2021017105-appb-T000002
O-DU(예를 들어, NETCONF 클라이언트)는 측정 대상, 보고 정보(report-info)에 포함되는 값(예를 들어, 최대 값, 최소 값, 카운트 등), 대상 단위(object-unit), 측정 간격, 통지 간격, 및/또는 파일 업로드 간격(file upload interval)을 설정할 수 있다. O-DU는 설정 정보를 O-RU에 알려줄 수 있다. O-RU는 O-DU에 의해 설정된 정보(예를 들어, 값)에 따라 선택된 측정 대상에 대해 설정된 측정 간격으로 측정을 수행할 수 있고, 설정된 통지 간격 또는 파일 업로드 간격에 따라 측정 결과를 포함하는 통지를 전송 혹은 측정 결과 파일을 업로드 할 수 있다.
측정 대상에 대한 측정 간격은 측정 그룹별로 설정될 수 있다. 예를 들어, 트랜시버 측정 간격, 수신 윈도우 측정 간격, 전송 측정 간격, EPE 측정 간격, 및 RSSI 측정 간격 각각은 서로 독립적으로 설정될 수 있다.
측정은 측정 대상별로 활성화(activate)될 수 있다. O-DU는 보고 정보에 포함되는 정보 요소(들)을 측정 대상별로 설정할 수 있다. 예를 들어, 보고 정보는 복수의 정보 요소들을 포함할 수 있다. 정보 요소(들)은 MAXIMUM, MINIMUM, FIRST, LATEST, 및/또는 FREQUENCY_TABLE을 포함할 수 있다. 대상 유닛은 측정 대상별로 독립적으로 설정될 수 있다. 예를 들어, 대상 유닛은 측정 대상별로 다를 수 있다.
도 7은 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제1 실시예를 도시한 개념도이다.
도 7을 참조하면, O-RU는 트랜시버 통계 그룹 및 수신 윈도우 통계 그룹 각각에 속하는 측정 대상들에 대한 측정 결과들을 YANG 모델에 기반하여 데이터 스토어에 저장할 수 있다. O-RU는 측정 결과(들)을 포함하는 NETCONF 통지를 O-DU(예를 들어, NETCONF 클라이언트)에 전송할 수 있다. 트랜시버 통계 그룹은 트랜시버 측정 대상들로 지칭될 수 있고, 수신 윈도우 통계 그룹은 수신 윈도우 측정 대상들로 지칭될 수 있다. 각 측정 대상에 대한 활성화(active)는 true 또는 false로 설정 가능할 수 있다. 각 측정 대상에 대한 활성화의 디폴트(default)는 false일 수 있다. 카운트(count) 값은 측정 간격의 경계(boundary)에서 0부터 시작할 수 있다.
도 8은 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제2 실시예를 도시한 개념도이다.
도 8을 참조하면, O-RU는 EPE 통계 그룹 및 전송 측정 통계 그룹 각각에 속하는 측정 대상들에 대한 측정 결과들을 YANG 모델에 기반하여 데이터 스토어에 저장할 수 있다. O-RU는 측정 결과(들)을 포함하는 NETCONF 통지를 O-DU(예를 들어, NETCONF 클라이언트)에 전송할 수 있다. EPE 통계 그룹은 EPE 측정 대상들로 지칭될 수 있고, 전송 측정 통계 그룹은 전송 측정 대상들로 지칭될 수 있다. 각 측정 대상에 대한 활성화는 true 또는 false로 설정 가능할 수 있다. 각 측정 대상에 대한 활성화의 디폴트는 false일 수 있다.
도 9는 O-RAN M-Plane에서 성능 측정 결과의 전달을 위한 YANG 모델의 데이터 구조의 제3 실시예를 도시한 개념도이다.
도 9를 참조하면, 심볼 RSSI 통계(symbol-rssi-stats)(예를 들어, 시간 도메인에서 특정 심볼들에 대한 RSSI)의 다양한 측정 결과들(예를 들어, 측정 정보)에 대한 측정 그룹(들)은 새로 추가될 수 있다. 상술한 측정 정보는 도 7 또는 도 8에 도시된 구조와 동일 또는 유사한 구조를 가질 수 있다. 예를 들어, 심볼 RSSI 통계의 구조는 트랜시버 통계의 구조와 동일 또는 유사할 수 있다.
O-RU는 O-DU(예를 들어, NETCONF 클라이언트)에 의해 설정된 측정 간격에 따라 측정 동작을 수행할 수 있다. O-RU는 통지 간격에 따른 시점에서 NETCONF 통지 메커니즘을 사용하여 측정 결과(들)을 O-DU에 주기적으로 전송할 수 있다. 다른 방법으로, O-RU는 측정 시간 별로 측정 결과(들)을 로컬 디스크에 저장할 수 있고, 파일 업로드 간격에 따른 시점에서 측정 결과(들)을 O-DU에 업로드할 수 있다.
통지 간격은 측정 간격과 다르게 설정될 수 있다. 예를 들어, 측정 대상 #A의 측정 간격은 3분으로 설정될 수 있고, 측정 대상 #B의 측정 간격은 5분으로 설정할 수 있다. 성능 관리 정보의 전송 동작을 효율적으로 수행하기 위해, 통지 간격은 15분으로 설정될 수 있다. 이 경우, NETCONF 통지의 전송 절차에서, 측정 대상 #A에 대한 5회의 측정 결과들 및 측정 대상 #B에 대한 3회의 측정 결과들을 포함하는 하나의 통지(예를 들어, 통지 메시지)를 전송하는 것이 바람직할 수 있다. 통지 간격이 측정 대상의 측정 간격보다 길게 설정된 경우, 통지의 전송 시점에 복수의 측정 결과들은 O-RU에 존재할 수 있다. 측정 대상에 대한 복수의 측정 결과들은 하나의 통지에 포함될 수 있다.
O-RAN의 M-Plane에서 정의된 기존 YANG 모델은 복수의 측정 결과들을 포함하는 하나의 통지의 전송 동작을 지원하지 못할 수 있다. 즉, 기존 YANG 모델은 측정 대상 별 1회의 측정 결과를 포함하는 하나의 통지를 전송할 수 있다. 따라서 통지 간격이 측정 대상의 측정 간격보다 길게 설정된 경우, 한 개의 측정 결과만을 포함하는 통지는 전송될 수 있고, 해당 통지 간격에서 나머지 측정 결과(들)은 O-DU(예를 들어, NETCONF 클라이언트)에게 전달될 수 없다. 즉, 현재 O-RAN의 YANG 모델(예를 들어, 도 7 및 도 8에 도시된 YANG 모델)에서, 하나의 통지의 전송 동작은 각 측정 대상에 대한 하나의 측정 결과를 전송하기 위해 수행될 수 있다. 상술한 문제점을 해결하기 위해, 아래에서 YANG 모델을 확장하는 방법들이 제안될 것이다.
O-RAN M-Plane의 성능 관리를 위한 YANG 모델의 부분 1(예를 들어, 공통 설정 부분)은 다음과 같을 수 있다.
[YANG 모델의 부분 1]
module: o-ran-performance-management
+--rw performance-measurement-objects
+--ro measurement-capabilitites
│ +--ro transceiver-objects* [measurement-object]
│ │ +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
│ +--ro rx-window-objects* [measurement-object]
│ │ +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
│ +--ro tx-stats-objects* [measurement-object]
│ │ +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
│ +--ro epe-stats-objects* [measurement-object]
│ +--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
│ +--ro component-class* identityref
+--rw enable-SFTP-upload? boolean
+--rw enable-random-file-upload? boolean
+--rw remote-SFTP-uploads* [remote-SFTP-upload-path]
│ +--rw remote-SFTP-upload-path inet:uri
+--rw transceiver-measurement-interval? uint16
+--rw rx-window-measurement-interval? uint16
+--rw epe-measurement-interval? uint16
+--rw tx-measurement-interval? uint16
+--rw notification-interval? uint16
+--rw file-upload-interval? uint16
+--ro max-bin-count uint16
상술한 YANG 모델의 부분 1은 모든 측정 대상들에 공통적으로 적용되는 파라미터들을 정의할 수 있다. 예를 들어, YANG 모델의 부분 1은 O-RU가 지원하는 측정 대상 정보, 측정 그룹별 측정 간격(예를 들어, 트랜시버 측정 간격, 수신 윈도우 측정 간격, 전송 측정 간격, EPE 측정 간격, RSSI 측정 간격)의 설정, 통지 간격, 및/또는 파일 업로드 간격을 정의할 수 있다. 트랜시버 측정 간격, 수신 윈도우 측정 간격, 전송 측정 간격, EPE 측정 간격, 및 RSSI 측정 간격은 서로 다르게 설정될 수 있다. 통지 간격 혹은 파일 업로드 간격은 하나의 공통 값으로 설정될 수 있다. 통지 간격 혹은 파일 업로드 간격 각각은 트랜시버 측정 간격, 수신 윈도우 측정 간격, 전송 측정 간격, EPE 측정 간격, 및/또는 RSSI 측정 간격과 다르게 설정될 수 있다.
O-RAN M-Plane의 성능 관리를 위한 YANG 모델의 부분 2(예를 들어, 트랜시버, 수신 윈도우 관련 통지)는 다음과 같을 수 있다.
[YANG 모델의 부분 2]
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
│ +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
│ +--ro start-time? yang-types:data-and-time
│ +--ro end-time? yang-types:data-and-time
│ +--ro transceiver-measurement-result* [object-unit-id]
│ +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
│ +--ro min
│ │ +--ro value? decima164
│ │ +--ro time? yang-types:data-and-time
│ +--ro max
│ │ +--ro value? decima164
│ │ +--ro time? yang-types:data-and-time
│ +--ro first
│ │ +--ro value? decima164
│ │ +--ro time? yang-types:data-and-time
│ +--ro latest
│ │ +--ro value? decima164
│ │ +--ro time? yang-types:data-and-time
│ +--ro frequency-table* uint32
+--ro rx-window-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
+--ro start-time? yang-types:data-and-time
+--ro end-time? yang-types:data-and-time
+--ro (object-unit-id)?
+--:(RU)
│ +--ro name? -> /hw:hardware/component/name
│ +--ro count uint64
+--:(TRANSPORT)
│ +--ro tr-measured-result* []
│ +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
│ +--ro count uint64
+--:(EAXC_ID)
+--ro eaxc-measured-result* []
+--ro eaxc-id? uint16
+--ro count uint64
+--ro transport-name? -> /o-ran-elements:processing-elemnets/ru-elements/name
O-RAN M-Plane의 성능 관리를 위한 YANG 모델의 부분 3(예를 들어, EPE, 전송 윈도우 관련 통지)은 다음과 같을 수 있다.
[YANG 모델의 부분 3]
+--ro tx-stats* [measurement-object]
│ +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
│ +--ro start-time? yang-types:data-and-time
│ +--ro end-time? yang-types:data-and-time
│ +--ro (object-unit-id)?
│ +--:(RU)
│ │ +--ro name? -> /hw:hardware/component/name
│ │ +--ro count uint64
│ +--:(TRANSPORT)
│ │ +--ro tr-measured-result* []
│ │ +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
│ │ +--ro count uint64
│ +--:(EAXC_ID)
│ +--ro eaxc-measured-result* []
│ +--ro eaxc-id? uint16
│ +--ro count uint64
│ +--ro transport-name? -> /o-ran-elements:processing-elemnets/ru-elements/name
x--ro epe-stats
│ +--ro start-time? yang-types:data-and-time
│ +--ro end-time? yang-types:data-and-time
│ +--ro epe-measurement-result* [object-unit-id]
│ +--ro object-unit-id -> /hw:hardware/component/class
│ +--ro min? decima164
│ +--ro max? decima164
│ +--ro average? decima164
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:data-and-time
+--ro end-time? yang-types:data-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> hw:hardware/component/class
+--ro min? decima164
+--ro max? decima164
+--ro average? decima164
YANG 모델의 부분 2 및 3은 트랜시버, 수신 윈도우, EPE, 및/또는 송신 윈도우에 관련된 측정 정보를 NETCONF 통지 형태로 전송하기 위해 정의된 YANG 모델일 수 있다. 트랜시버 통계, 수신 윈도우 통계, 전송 통계, EPE 통계, 및 RSSI 통계 각각은 시작 시간(start time)부터 종료 시간(end time)까지의 측정 구간에서 하나의 측정 대상에 대해 측정된 하나의 결과(예를 들어, 값)를 포함할 수 있다.
즉, 복수의 시간 구간들(예를 들어, 복수의 측정 구간들)에서 측정된 결과들은 하나의 통지를 사용하여 전송되지 못할 수 있다. 특히, 트랜시버, 수신 윈도우, EPE, 전송 윈도우, 및 RSSI 각각을 위한 측정 간격이 서로 다르게 설정된 경우, 측정 결과를 포함하는 통지는 자주 전송되어야 한다. 이러한 문제를 해결하기 위한 YANG 모델은 다음과 같이 설정될 수 있다.
[방법 A]
방법 A가 사용되는 경우, 측정 대상 별로 하나 이상의 측정 결과들을 포함하는 추가 측정 리스트는 설정될 수 있고, 추가 측정 리스트는 해당 측정 대상의 통계 정보에 추가될 수 있다. 예를 들어, 추가 측정 리스트는 시간 순서대로 통계 정보에 추가될 수 있다.
도 10은 방법 A를 사용하는 YANG 모델에서 트랜시버에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 10을 참조하면, 각 측정 대상(예를 들어, RX_POWER, TX_POWER, TX_BIAS_COUNT, TEMPARATURE 등)을 위한 추가 트랜시버 측정 결과(additional-transceiver-measurement-result)는 추가될 수 있다.
도 11은 방법 A를 사용하는 YANG 모델에서 수신 윈도우에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 11을 참조하면, 각 측정 대상(예를 들어, RX_ON_TIME, RX_EARLY, RX_LATE, RX_CORRUT, RX_DUPL, RX_TOTAL 등)을 위한 추가 수신 윈도우 측정 결과(additional-rx-window-measurement-result)는 추가될 수 있다.
도 12는 방법 A를 사용하는 YANG 모델에서 EPE에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 12를 참조하면, 각 측정 대상(예를 들어, TEMPARATURE, POWER)을 위한 추가 EPE 측정 결과(additional-epe-measurement-result)는 추가될 수 있다.
도 13은 방법 A를 사용하는 YANG 모델에서 전송 측정에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 13을 참조하면, 각 측정 대상(예를 들어, TX_TOTAL, TX_TOTAL_C)을 위한 추가 전송 측정 결과(additional-tx-measurement-result)는 추가될 수 있다.
도 14는 방법 A를 사용하는 YANG 모델에서 심볼 RSSI에 대한 확장된 측정 결과의 구조의 제1 실시예를 도시한 개념도이다.
도 14를 참조하면, 각 측정 대상(예를 들어, ALL-UL-SYMBOLS, CONFIGURED-SYMBOLS)을 위한 추가 심볼 RSSI 측정 결과(additional-symbol-rssi-measurement-result)는 추가될 수 있다.
상술한 방법 1에 따른 YANG 모델의 구조는 다음과 같이 정의될 수 있다.
<방법 1>
module: o-ran-performance-management
... (생략) ...
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| | +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| | +--ro min
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro max
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro first
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro latest
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro frequeny-table* uint32
| +--ro number-of-additional-measurement-result? uint8
| +--ro additional-transceiver-measurement-result* [seq-number]
| +--ro seq-number uint8
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro data-direction? Enumeration
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro number-of-additional-measurement-result? uint8
| +--ro additional-rx-window-measurement-result* [seq-number]
| +--ro seq-number uint8
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro number-of-additional-measurement-result? uint8
| +--ro additional-tx-measurement-result* [seq-number]
| +--ro seq-number uint8
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?:
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro number-of-additional-measurement-result? uint8
+--ro additional-epe-measurement-result* [seq-number]
+--ro seq-number uint8
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
수정된 YANG 코드는 다음과 같을 수 있다.
grouping measurement-notification {
description
"notification may contain measurement result for transceiver-stats
and/or rx-window-stats and/or tx-stats and/or epe-stats";
list transceiver-stats {
key "measurement-object";
description
"measurement result of transceiver-measurement per measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/transceiver-measurement-objects/measurement-object";
}
description
"measurement-object for the transceiver-measurement";
}
uses start-and-end-time; // start-and-end-time of the first result
uses transceiver-measurement-result-grouping; // First result
// For additional measurement result
leaf number-of-additional-measurement-result {
type uint8;
config false;
description
"This parameter indicates the number of additional measurement result.";
}
list additional-transceiver-measurement-result {
// when measurement-interval < notification interval
config false;
description
"measurement result of additional transceiver-measurement";
key seq-number;
leaf seq-number {
type uint8 {
range "1..max";
}
}
uses start-and-end-time;
uses transceiver-measurement-result-grouping;
}
}
list rx-window-stats {
key "measurement-object";
description
"measurement result for the reception window measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/rx-window-measurement-objects/measurement-object";
}
description
"measurement-object for the reception window measurement";
}
uses start-and-end-time;
uses rx-window-measurement-result-grouping;
// For additional measurement result
leaf number-of-additional-measurement-result {
type uint8;
config false;
description
"This parameter indicates the number of additional measurement result.";
}
list additional-rx-window-measurement-result {
// when measurement-interval < notification interval
config false;
description
"measurement result of additional rx-window-measurement";
key seq-number;
leaf seq-number {
type uint8 {
range "1..max";
}
}
uses start-and-end-time;
uses rx-window-measurement-result-grouping;
}
}
list tx-stats {
key "measurement-object";
description
"measurement result for the tx stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/tx-measurement-objects/measurement-object";
}
description
"measurement-object for the tx stats measurement";
}
uses start-and-end-time;
uses tx-measurement-result-grouping;
// For additional measurement result
leaf number-of-additional-measurement-result {
type uint8;
config false;
description
"This parameter indicates the number of additional measurement result.";
}
list additional-tx-measurement-result {
// when measurement-interval < notification interval
config false;
description
"measurement result of additional tx-measurement";
key seq-number;
leaf seq-number {
type uint8 {
range "1..max";
}
}
uses start-and-end-time;
uses tx-measurement-result-grouping;
}
}
container epe-stats {
description
"container for the epe stats measurement - deprecated because measurement object isn't included";
status deprecated;
uses start-and-end-time;
uses epe-measurement-result-grouping;
}
list epe-statistics {
key "measurement-object";
description
"measurement result for the epe stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/epe-measurement-objects/measurement-object";
}
description
"measurement-object for the epe stats measurement";
}
uses start-and-end-time;
uses epe-measurement-result-grouping;
// For additional measurement result
leaf number-of-additional-measurement-result {
type uint8;
config false;
description
"This parameter indicates the number of additional measurement result.";
}
list additional-epe-measurement-result {
// when measurement-interval < notification interval
config false;
description
"measurement result of additional epe-measurement";
key seq-number;
leaf seq-number {
type uint8 {
range "1..max";
}
}
uses start-and-end-time;
uses epe-measurement-result-grouping;
}
}
}
측정 대상의 통지 간격이 측정 간격보다 긴 경우, 측정 대상들 각각의 복수의 측정 결과들은 하나의 통지(예를 들어, 하나의 통지 메시지)에 포함될 수 있다. 이 동작을 지원하기 위해, 트랜시버 통계 그룹, 수신 윈도우 통계 그룹, 전송 통계 그룹, 및 EPE 통계 그룹에 속하는 각 측정 대상이 추가 측정 결과 리스트 또는 전체 측정 결과(예를 들어, list additional-transceiver-measurement-result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result 등)를 포함할 수 있도록, YANG 모델은 확장될 수 있다.
추가 측정 결과 리스트는 시작 시간(예를 들어, 측정 시작 시간), 종료 시간(예를 들어, 측정 종료 시간), 및 해당 시간 구간에서 측정 결과(예를 들어, 측정 구간에서 측정 값)을 포함할 수 있다. 측정 구간은 시작 시간부터 종료 시간까지의 시간 구간일 수 있다.
기존 YANG 모델에서, 측정 대상 별 하나의 측정 결과만을 포함하는 하나의 통지는 전송될 수 있다. 측정 결과를 측정 결과 리스트로 변경하는 경우, 기존 YANG 모델을 지원하는 프론트홀 장비(예를 들어, O-DU 및/또는 O-RU)는 측정 결과 리스트를 디코딩할 수 없다. 즉, 기존 프론트홀 장비와의 하위 호환성(backward compatibility) 문제가 발생할 수 있다. 본 출원에서 제안된 YANG 모델은 기존 YANG 모델의 시작 시간, 종료 시간, 및 측정 결과를 그대로 사용할 수 있다. 기존 YANG 모델의 측정 결과는 첫 번째 측정 결과를 포함할 수 있다. 제안된 YANG 모델은 기존 YANG 모델에 비해 추가 측정 결과 리스트를 더 포함할 수 있다. 추가 측정 결과 리스트는 두 번째 측정 결과부터 하나 이상의 측정 결과들을 포함할 수 있다. 측정 결과들은 추가 측정 결과 리스트 내에서 시간 순서(예를 들어, 측정 시간의 오름차순)로 배치될 수 있다. 이 동작은 "방법 a"로 지칭될 수 있다. 방법 a에 의하면, 기존 YANG 모델에서 사용하는 측정 관련 파라미터는 그대로 사용되기 때문에, 하위 호환성 문제는 발생하지 않을 수 있다.
즉, 하나의 통지에서 하나의 측정 결과만을 디코딩할 수 있는 기존 O-DU는 기존 파라미터(들)(예를 들어, transceiver-stats, rx-window-stats, tx-stats, epe-stats)을 디코딩할 수 있다. 이 경우, O-RU가 복수의 측정 결과들을 포함하는 하나의 통지를 전송하는 경우에도, 기존 O-DU는 하나의 측정 결과를 성공적으로 수신할 수 있다.
다른 방법으로, O-RU는 복수의 측정 결과들 중에서 마지막 측정 결과(예를 들어, 가장 최신의 측정 결과)를 기존의 측정 결과 파라미터로 설정할 수 있고, 첫 번째 측정 결과부터 마지막 이전의 측정 결과까지 포함하는 추가 측정 결과 리스트(예를 들어, additional-XXXX-measurement-result)를 생성할 수 있다. 이 동작은 "방법 b"로 지칭될 수 있다. 방법 b에 의하면, 기존 O-DU가 수신 가능한 하나의 측정 결과는 가장 최신의 측정 결과일 수 있다.
통지의 수신 절차에서 O-DU의 디코딩 편의성을 향상시키기 위해, O-RU는 추가 측정 결과 리스트에 포함된 측정 결과들의 개수(예를 들어, number-of-additional-measurement-result)를 O-DU에 알려줄 수 있다. 즉, 추가 측정 결과 리스트는 number-of-additional-measurement-result를 더 포함할 수 있다. 또한, 추가 측정 결과 리스트는 시퀀스 번호(예를 들어, seq-number)를 더 포함할 수 있다. 방법 a가 사용되는 경우, 측정 결과 리스트 내에서 측정 결과에 대한 시퀀스 번호는 1부터 시작할 수 있고, 시간 순으로 증가할 수 있다. 이 경우, 기존 측정 결과(예를 들어, 첫 번째 측정 결과)의 시퀀스 번호는 0으로 간주될 수 있다. 방법 b가 사용되는 경우, 측정 결과 리스트 내에서 측정 결과에 대한 시퀀스 번호는 0부터 시작할 수 있고, 시간 순으로 증가할 수 있다. 이 경우, 기존 측정 결과는 마지막 측정 결과로 간주될 수 있다. O-DU는 시퀀스 번호를 추가 측정 결과 리스트의 키(key) 값으로 사용함으로써 측정 결과들을 시간 순서로 쉽게 정렬할 수 있다. 또한, O-DU는 시퀀스 번호를 사용하여 특정 측정 결과를 쉽게 찾을 수 있다.
시퀀스 번호는 추가 측정 결과 리스트에 포함되지 않을 수 있고, 시퀀스 번호 대신에 시작 시간 및 종료 시간은 추가 측정 결과 리스트의 키 값으로 사용될 수 있다. 추가 측정 결과 리스트의 키는 지정되지 않을 수도 있다. 추가 측정 결과 리스트의 키가 지정되지 않는 경우, O-DU는 추가 측정 결과 리스트 내의 특정 엔트리(예를 들어, 특정 측정 결과)에 직접 액세스할 수 없고, 항상 추가 측정 결과 리스트의 전체를 디코딩하여야 한다. 파라미터의 개수를 줄이기 위해, number-of-additional-measurement-result는 사용되지 않을 수 있다. NETCONF/YANG 모델에서 추가 측정 결과 리스트에 포함되는 엔트리(예를 들어, 측정 결과)의 개수가 명시적으로 지시되지 않는 경우에도, 수신자(예를 들어, O-DU)는 엔트리의 개수를 알 수 있다. number-of-additional-measurement-result는 수신자의 디코딩 편의성을 향상시키기 위해 사용될 수 있다. 통신 시스템에서 추가 측정 결과 리스트의 순서를 임의로 정의하지 않고, 추가 측정 결과 리스트를 시간 순서로 정렬시키기 위해, 키 값인 시퀀스 번호는 "ordered-by user"로 정의될 수 있다.
다른 방법으로, O-RU가 기존 O-DU(예를 들어, O-RAN M-Plane 7.0 버전의 이전 버전을 지원하는 O-DU, 추가 측정 결과 리스트의 디코딩이 불가능한 O-DU)에 측정 결과를 전송하는 경우, O-RU는 하나의 측정 결과를 전송할 수 있는 leaf들(예를 들어, start-time, end-time, 및 XXXX-measurement-result[])을 전송할 수 있다. 또한, O-RU는 추가 측정 결과 리스트를 처리할 수 있는 O-DU(예를 들어, O-RAN M-Plane 7.0 버전을 지원하는 O-DU, O-RAN M-Plane 7.0 버전 이후의 버전을 지원하는 O-DU)에 복수의 측정 결과들 전체를 포함하는 추가 측정 결과 리스트를 전송할 수 있다. 이 동작은 "방법 c"로 지칭될 수 있다. 실시예에서, 추가 측정 결과 리스트를 처리할 수 있는 O-DU는 "새로운 O-DU"로 지칭될 수 있고, 추가 측정 결과 리스트를 처리할 수 없는 O-DU는 "기존 O-DU"로 지칭될 수 있고, O-DU는 새로운 O-DU 및/또는 기존 O-DU를 의미할 수 있다.
방법 c에서 상술한 YANG 모델은 그대로 사용될 수 있다. 다만, 기존 O-DU에 통지를 전송하는 경우, 추가 측정 결과 리스트(예를 들어, additional-XXXX-measurement-result[])의 전송은 생략될 수 있고, 기존 leaf들만 사용될 수 있다. 새로운 O-DU에 통지를 전송하는 경우, 하나의 측정 결과의 전송이 가능한 leaf들의 전송은 생략될 수 있고, O-RU는 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트(additional-XXXX-measurement-result[])를 새로운 O-DU에 전송할 수 있다. 추가 측정 결과 리스트 내에서 모든 측정 결과들(예를 들어, 첫 번째 측정 결과부터 마지막 측정 결과까지의 측정 결과들)은 시간 순서로 정렬될 수 있다.
O-RU는 측정 대상 별 하나의 측정 결과를 포함하는 통지를 기존 O-DU에 전송할 수 있다. 이 경우, 기존 O-DU는 하나의 통지 간격에서 하나의 측정 결과가 발생하도록 O-RU의 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 또는, 기존 O-DU가 통지 간격을 측정 간격보다 길게 설정한 경우, O-RU는 측정 결과들 중에서 가장 최신의 측정 결과만을 기존 O-DU에 전송할 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에서 설명된다.
상술한 방법이 사용되는 경우, 통지의 수신 절차에서 O-DU의 디코딩 편의성을 향상시키기 위해, O-RU는 추가 측정 결과 리스트에 포함된 측정 결과들의 개수(number-of-additional-measurement-result)를 O-DU에 알려줄 수 있다. 측정 결과 리스트는 시퀀스 번호(seq-number)를 포함할 수 있다. 측정 결과 리스트 내에서 측정 결과에 대한 시퀀스 번호는 0부터 시작할 수 있고, 시간 순으로 증가할 수 있다. O-DU는 시퀀스 번호를 추가 측정 결과 리스트의 키 값으로 사용함으로써 측정 결과들을 시간 순서로 쉽게 정렬할 수 있다. 또한, O-DU는 시퀀스 번호를 사용하여 특정 측정 결과를 쉽게 찾을 수 있다.
다른 방법으로, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 있다. 이 경우, O-RU는 복수의 측정 결과들에 기초하여 복수의 추가 측정 결과 리스트들을 생성할 수 있고, 복수의 추가 측정 결과 리스트들을 포함하는 통지를 O-DU에 전송할 수 있다. 반면, 상술한 동작을 지원하지 않는 O-RU는 하나의 측정 결과의 전송을 지원하는 leaf를 사용하여 하나의 측정 결과를 O-DU에 전송할 수 있다. 기존 O-DU는 추가 측정 결과 리스트를 디코딩할 수 없지만 새로운 추가 leaf들(예를 들어, 추가 측정 결과 리스트)을 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다.
다른 방법으로, 측정 결과의 전송 절차에서, 방법 a 및/또는 방법 b와 같이, O-RU는 "하나의 측정 결과(예를 들어, 측정 대상 별 하나의 측정 결과, 가장 최신의 측정 결과)를 포함하는 leaf들" 및 "복수의 측정 결과를 포함하는 추가 측정 결과 리스트"를 포함하는 통지를 O-DU에 전송할 수 있다. 복수의 측정 값들의 전체는 추가 측정 결과 리스트에 포함될 수 있다. 이 동작은 "방법 d"로 지칭될 수 있다. 이 경우, 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)는 기존 leaf들과 추가 측정 결과 리스트에 모두 포함할 수 있다. 방법 d가 사용되는 경우, 하나의 측정 결과가 중복 전송되지만, O-RU는 O-DU의 종류(예를 들어, 기존 O-DU 또는 새로운 O-DU)를 구분할 필요가 없다. 또한, 별도의 제어 파라미터(예를 들어, enable-multiple-stats-in-notification) 없이도, O-RU는 기존 O-DU 및 새로운 O-DU가 모두 디코딩 가능한 공통 통지를 전송할 수 있다. 즉, O-RU의 구현 복잡도는 감소할 수 있다.
기존 O-DU는 하나의 측정 결과를 포함하는 leaf들을 디코딩할 수 있기 때문에 O-RU로부터 수신된 통지에서 하나의 측정 결과를 획득할 수 있다. 새로운 O-DU는 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트를 디코딩할 수 있고, 복수의 측정 결과들에 기초한 처리 동작을 수행할 수 있다.
통지 간격에서 각 측정 대상에 대해 하나의 측정 결과가 발생한 경우, O-RU는 하나의 측정 결과를 포함하는 leaf들을 전송할 수 있다. 이 경우, 중복된 정보는 감소할 수 있다. 또는, O-RU는 하나의 측정 결과를 포함하는 leaf들 및 하나의 측정 결과를 포함하는 추가 측정 결과 리스트를 생성할 수 있고, 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트를 O-DU에 전송할 수 있다. 즉, 동일한 측정 결과는 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트에 포함될 수 있다. 이 경우, 중복된 정보의 전송으로 인한 오버헤드는 증가할 수 있으나, 새로운 O-DU는 측정 결과의 개수에 상관없이 기존 leaf들 대신에 항상 추가 측정 결과 리스트를 디코딩하면 된다. 이 경우, O-DU의 구현 복잡도는 감소할 수 있다.
새로운 O-DU는 기존 O-DU의 기능들을 모두 지원할 수 있다. 따라서 하나의 측정 결과를 포함하는 기존 leaf들이 수신된 경우에도, 새로운 O-DU는 기존 leaf들을 항상 디코딩할 수 있다. 반면, 기존 O-DU는 추가 측정 결과 리스트를 디코딩하지 못할 수 있다. 기존 O-DU는 추가 측정 결과 리스트(예를 들어, 새로운 leaf들)를 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다. 기존 O-DU는 하나의 측정 결과를 포함하는 기존 leaf들을 수신할 수 있고, 기존 leaf들을 디코딩할 수 있다. 방법 d에서, 기존 O-DU는 항상 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)에 대한 수신 및 디코딩 동작들을 수행할 있다. 따라서 기존 O-DU는 기존 방식으로 동작할 수 있다. 상술한 방식에 의하면, 하위 호환성 문제는 해소될 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
상술한 방법이 사용되는 경우, 통지의 수신 절차에서 O-DU의 디코딩 편의성을 향상시키기 위해, O-RU는 추가 측정 결과 리스트에 포함된 측정 결과들의 개수(number-of-additional-measurement-result)를 O-DU에 알려줄 수 있다. 측정 결과 리스트는 시퀀스 번호(seq-number)를 포함할 수 있다. 측정 결과 리스트 내에서 측정 결과에 대한 시퀀스 번호는 0부터 시작할 수 있고, 시간 순으로 증가할 수 있다. O-DU는 시퀀스 번호를 추가 측정 결과 리스트의 키 값으로 사용함으로써 측정 결과들을 시간 순서로 쉽게 정렬할 수 있다. 또한, O-DU는 시퀀스 번호를 사용하여 특정 측정 결과를 쉽게 찾을 수 있다.
<방법 2>
방법 2에서 number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있고, start-time 및 end-time은 추가 측정 결과 리스트(additional-XXXXX-measurement list)의 키(key)로 사용될 수 있다. 측정 대상 별 측정 결과들은 시간 순서대로 추가 측정 결과 리스트(additional-xxxx-measurement-list[]) 내에서 정렬될 수 있다.
상술한 방법 2에 따른 YANG 모델의 구조는 다음과 같이 정의될 수 있다.
module: o-ran-performance-management
... (생략) ...
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| | +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| | +--ro min
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro max
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro first
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro latest
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro frequeny-table* uint32
| +--ro additional-transceiver-measurement-result* [start-time end-time]
| +--ro start-time yang-types:date-and-time
| +--ro end-time yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro data-direction? Enumeration
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro additional-rx-window-measurement-result* [start-time end-time]
| +--ro start-time yang-types:date-and-time
| +--ro end-time yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro additional-tx-measurement-result* [start-time end-time]
| +--ro start-time yang-types:date-and-time
| +--ro end-time yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name?-> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro additional-epe-measurement-result* [start-time end-time]
+--ro start-time yang-types:date-and-time
+--ro end-time yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
다른 방법으로, O-RU가 기존 O-DU(예를 들어, O-RAN M-Plane 7.0 버전의 이전 버전을 지원하는 O-DU, 추가 측정 결과 리스트의 디코딩이 불가능한 O-DU)에 측정 결과를 전송하는 경우, O-RU는 하나의 측정 결과를 전송할 수 있는 leaf들(예를 들어, start-time, end-time, 및 XXXX-measurement-result[])을 전송할 수 있다. 또한, O-RU는 추가 측정 결과 리스트를 처리할 수 있는 새로운 O-DU(예를 들어, O-RAN M-Plane 7.0 버전을 지원하는 O-DU, O-RAN M-Plane 7.0 버전 이후의 버전을 지원하는 O-DU)에 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트를 전송할 수 있다. 이 동작은 "방법 c"일 수 있다.
방법 c에서 상술한 YANG 모델은 그대로 사용될 수 있다. 다만, 기존 O-DU에 통지를 전송하는 경우, 추가 측정 결과 리스트(additional-XXXX-measurement-result[])의 전송은 생략될 수 있고, 기존 leaf들만 사용될 수 있다. 새로운 O-DU에 통지를 전송하는 경우, 하나의 측정 결과의 전송이 가능한 leaf들의 전송은 생략될 수 있고, O-RU는 복수의 측정 결과들 전체를 포함하는 추가 측정 결과 리스트(additional-XXXX-measurement-result[])를 새로운 O-DU에 전송할 수 있다. 추가 측정 결과 리스트 내에서 모든 측정 결과들(예를 들어, 첫 번째 측정 결과부터 마지막 측정 결과까지의 측정 결과들)은 시간 순서로 정렬될 수 있다.
O-RU는 측정 대상 별 하나의 측정 결과를 포함하는 통지를 기존 O-DU에 전송할 수 있다. 이 경우, 기존 O-DU는 하나의 통지 간격에서 하나의 측정 결과가 발생하도록 O-RU의 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 또는, 기존 O-DU가 통지 간격을 측정 간격보다 길게 설정한 경우, O-RU는 측정 결과들 중에서 가장 최신의 측정 결과만을 기존 O-DU에 전송할 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
상술한 방법이 사용되는 경우, number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있다. start-time과 end-time은 additional-XXXXX-measurement list의 키로 사용될 수 있다.
다른 방법으로, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 있다. 이 경우, O-RU는 복수의 측정 결과들에 기초하여 추가 측정 결과 리스트(들)을 생성할 수 있고, 추가 측정 결과 리스트(들)을 포함하는 통지를 O-DU에 전송할 수 있다. 반면, 상술한 동작을 지원하지 않는 O-RU는 하나의 측정 결과의 전송을 지원하는 leaf들을 사용하여 하나의 측정 결과를 O-DU에 전송할 수 있다. 기존 O-DU는 추가 측정 결과 리스트를 디코딩할 수 없지만 새로운 추가 leaf들(예를 들어, 추가 측정 결과 리스트)을 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다.
다른 방법으로, 측정 결과의 전송 절차에서, 방법 a 및/또는 방법 b와 같이, O-RU는 "하나의 측정 결과(예를 들어, 측정 대상 별 하나의 측정 결과, 가장 최신의 측정 결과)를 포함하는 leaf들" 및 "복수의 측정 결과들을 포함하는 추가 측정 결과 리스트"를 포함하는 통지를 O-DU에 전송할 수 있다. 복수의 측정 값들의 전체는 추가 측정 결과 리스트에 포함될 수 있다. 이 동작은 "방법 d"일 수 있다. 이 경우, 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)는 기존 leaf들과 추가 측정 결과 리스트에 모두 포함될 수 있다. 방법 d가 사용되는 경우, 하나의 측정 결과가 중복 전송되지만, O-RU는 상대 O-DU의 종류(예를 들어, 기존 O-DU 또는 새로운 O-DU)의 구분할 필요가 없다. 또한, 별도의 제어 파라미터(예를 들어, enable-multiple-stats-in-notification) 없이도, O-RU는 기존 O-DU 및 새로운 O-DU가 모두 디코딩 가능한 공통 통지를 전송할 수 있다. 즉, O-RU의 구현 복잡도는 감소할 수 있다.
기존 O-DU는 하나의 측정 결과를 포함하는 leaf들을 디코딩할 수 있기 때문에 O-RU로부터 수신된 통지에서 하나의 측정 결과를 획득할 수 있다. 새로운 O-DU는 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트를 디코딩할 수 있고, 복수의 측정 결과들에 기초한 처리 동작을 수행할 수 있다.
통지 간격에서 각 측정 대상에 대해 하나의 측정 결과가 발생한 경우, O-RU는 하나의 측정 결과를 포함하는 leaf들을 전송할 수 있다. 이 경우, 중복된 정보는 감소할 수 있다. 또는, O-RU는 하나의 측정 결과를 포함하는 leaf들 및 하나의 측정 결과를 포함하는 추가 측정 결과 리스트를 생성할 수 있고, 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트를 O-DU에 전송할 수 있다. 즉, 동일한 측정 결과는 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트에 포함될 수 있다. 이 경우, 중복된 정보의 전송으로 인한 오버헤드는 증가할 수 있으나, 새로운 O-DU는 측정 결과의 개수에 상관없이 기존 leaf들 대신에 항상 추가 측정 결과 리스트를 디코딩하면 된다. 이 경우, O-DU의 구현 복잡도는 감소할 수 있다.
새로운 O-DU는 기존 O-DU의 기능들을 모두 지원할 수 있다. 따라서 하나의 측정 결과를 포함하는 기존 leaf가 수신된 경우에도, 새로운 O-DU는 기존 leaf를 항상 디코딩할 수 있다. 반면, 기존 O-DU는 추가 측정 결과 리스트를 디코딩하지 못할 수 있다. 기존 O-DU는 추가 측정 결과 리스트(예를 들어, 새로운 leaf들)를 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다. 기존 O-DU는 하나의 측정 결과를 포함하는 기존 leaf를 수신할 수 있고, 기존 leaf를 디코딩할 수 있다. 방법 d에서, 기존 O-DU는 항상 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)에 대한 수신 및 디코딩 동작들을 수행할 있다. 따라서 기존 O-DU는 기존 방식으로 동작할 수 있다. 상술한 방식에 의하면, 하위 호환성 문제는 해소될 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
상술한 방법 2에서, number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있고, start-time과 end-time은 additional-XXXXX-measurement list의 키로 사용될 수 있다.
<방법 3>
다른 방법으로, number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있고, additional-XXXXX-measurement list를 위한 키는 사용되지 않을 수 있다. 이 동작은 "방법 3"일 수 있다.
방법 3에 따른 YANG 모델의 구조는 다음과 같을 수 있다.
module: o-ran-performance-management
… (생략) …=
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| | +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| | +--ro min
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro max
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro first
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro latest
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro frequeny-table* uint32
| +--ro additional-transceiver-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro data-direction? Enumeration
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro additional-rx-window-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro additional-tx-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name?-> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro additional-epe-measurement-result* []
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
다른 방법으로, O-RU가 기존 O-DU(예를 들어, O-RAN M-Plane 7.0 버전의 이전 버전을 지원하는 O-DU, 추가 측정 결과 리스트의 디코딩이 불가능한 O-DU)에 측정 결과를 전송하는 경우, O-RU는 하나의 측정 결과를 전송할 수 있는 leaf들(예를 들어, start-time, end-time, 및 XXXX-measurement-result[])을 전송할 수 있다. 또한, O-RU는 추가 측정 결과 리스트를 처리할 수 있는 O-DU(예를 들어, O-RAN M-Plane 7.0 버전을 지원하는 O-DU, O-RAN M-Plane 7.0 버전의 이후 버전을 지원하는 O-DU)에 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트를 전송할 수 있다. 이 동작은 "방법 c"일 수 있다.
방법 c에서 상술한 YANG 모델은 그대로 사용될 수 있다. 다만, 기존 O-DU에 통지를 전송하는 경우, 추가 측정 결과 리스트(예를 들어, additional-XXXX-measurement-result[])의 전송은 생략될 수 있고, 기존 leaf들만 사용될 수 있다. 새로운 O-DU에 통지를 전송하는 경우, 하나의 측정 결과의 전송이 가능한 leaf들의 전송은 생략될 수 있고, O-RU는 복수의 측정 결과들 전체를 포함하는 추가 측정 결과 리스트(additional-XXXX-measurement-result[])를 새로운 O-DU에 전송할 수 있다. 추가 측정 결과 리스트 내에서 모든 측정 결과들(예를 들어, 첫 번째 측정 결과부터 마지막 측정 결과까지의 측정 결과들)은 시간 순서로 정렬될 수 있다.
O-RU는 측정 대상 별 하나의 측정 결과를 포함하는 통지를 기존 O-DU에 전송할 수 있다. 이 경우, 기존 O-DU는 하나의 통지 간격에서 하나의 측정 결과가 발생하도록 O-RU의 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 또는, 기존 O-DU가 통지 간격을 측정 간격보다 길게 설정한 경우, O-RU는 측정 결과들 중에서 가장 최신의 측정 결과만을 기존 O-DU에 전송할 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
상술한 방법에서, number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있고, additional-XXXXX-measurement list에 key는 사용되지 않을 수 있다. 이 방법에 따른 수정된 YANG 코드는 다음과 같이 정의될 수 있다.
grouping measurement-notification {
description
"notification may contain measurement result for transceiver-stats
and/or rx-window-stats and/or tx-stats and/or epe-stats";
list transceiver-stats {
key "measurement-object";
description
"measurement result of transceiver-measurement per measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/transceiver-measurement-objects/measurement-object";
}
description
"measurement-object for the transceiver-measurement";
}
uses start-and-end-time; // start-and-end-time of the first result
uses transceiver-measurement-result-grouping; // First result
// For additional measurement result
list additional-transceiver-measurement-result {
// when measurement-interval < notification interval
config false;
description
"Multiple measurement results of transceiver-measurement";
uses start-and-end-time;
uses transceiver-measurement-result-grouping;
}
}
list rx-window-stats {
key "measurement-object";
description
"measurement result for the reception window measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/rx-window-measurement-objects/measurement-object";
}
description
"measurement-object for the reception window measurement";
}
uses start-and-end-time;
uses rx-window-measurement-result-grouping;
// For additional measurement result
list additional-rx-window-measurement-result {
// when measurement-interval < notification interval
config false;
description
"Multiple measurement results of rx-window-measurement";
uses start-and-end-time;
uses rx-window-measurement-result-grouping;
}
}
list tx-stats {
key "measurement-object";
description
"measurement result for the tx stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/tx-measurement-objects/measurement-object";
}
description
"measurement-object for the tx stats measurement";
}
uses start-and-end-time;
uses tx-measurement-result-grouping;
// For additional measurement result
list additional-tx-measurement-result {
// when measurement-interval < notification interval
config false;
description
"Multiple measurement result of tx-measurement";
uses start-and-end-time;
uses tx-measurement-result-grouping;
}
}
container epe-stats {
description
"container for the epe stats measurement - deprecated because measurement object isn't included";
status deprecated;
uses start-and-end-time;
uses epe-measurement-result-grouping;
}
list epe-statistics {
key "measurement-object";
description
"measurement result for the epe stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/epe-measurement-objects/measurement-object";
}
description
"measurement-object for the epe stats measurement";
}
uses start-and-end-time;
uses epe-measurement-result-grouping;
list additional-epe-measurement-result {
// when measurement-interval < notification interval
config false;
description
"Multiple measurement result of epe-measurement";
uses start-and-end-time;
uses epe-measurement-result-grouping;
}
}
}
다른 방법으로, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 있다. 이 경우, O-RU는 복수의 측정 결과들에 기초하여 추가 측정 결과 리스트(들)을 생성할 수 있고, 추가 측정 결과 리스트(들)을 포함하는 통지를 O-DU에 전송할 수 있다. 반면, 상술한 동작을 지원하지 않는 O-RU는 하나의 측정 결과의 전송을 지원하는 leaf들을 사용하여 하나의 측정 결과를 O-DU에 전송할 수 있다. 기존 O-DU는 추가 측정 결과 리스트를 디코딩할 수 없지만 새로운 추가 leaf들(예를 들어, 추가 측정 결과 리스트)을 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다.
다른 방법으로, 측정 결과의 전송 절차에서, 방법 a 및/또는 방법 b와 같이, O-RU는 "하나의 측정 결과(예를 들어, 측정 대상별 하나의 측정 결과, 가장 최신의 측정 결과)를 포함하는 leaf들" 및 "복수의 측정 결과를 포함하는 추가 측정 결과 리스트"를 포함하는 통지를 O-DU에 전송할 수 있다. 복수의 측정 값들의 전체는 추가 측정 결과 리스트에 포함될 수 있다. 이 동작은 "방법 d"일 수 있다. 이 경우, 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)는 기존 leaf들과 추가 측정 결과 리스트에 모두 포함될 수 있다. 방법 d가 사용되는 경우, 하나의 측정 결과가 중복 전송되지만, O-RU는 O-DU의 종류(예를 들어, 기존 O-DU 또는 새로운 O-DU)를 구분할 필요가 없다. 또한, 별도의 제어 파라미터(예를 들어, enable-multiple-stats-in-notification) 없이도, O-RU는 기존 O-DU 및 새로운 O-DU가 모두 디코딩 가능한 공통 통지를 전송할 수 있다. 즉, O-RU의 구현 복잡도는 감소할 수 있다.
기존 O-DU는 하나의 측정 결과를 포함하는 leaf들을 디코딩할 수 있기 때문에 O-RU로부터 수신된 통지에서 하나의 측정 결과를 획득할 수 있다. 새로운 O-DU는 복수의 측정 결과들을 포함하는 추가 측정 결과 리스트를 디코딩할 수 있고, 복수의 측정 결과들에 기초한 처리 동작을 수행할 수 있다.
통지 간격에서 각 측정 대상에 대해 하나의 측정 결과가 발생한 경우, O-RU는 하나의 측정 결과를 포함하는 leaf들을 전송할 수 있다. 이 경우, 중복된 정보는 감소할 수 있다. 또는, O-RU는 하나의 측정 결과를 포함하는 leaf들 및 하나의 측정 결과를 포함하는 추가 측정 결과 리스트를 생성할 수 있고, 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트를 O-DU에 전송할 수 있다. 즉, 동일한 측정 결과는 하나의 측정 결과를 포함하는 leaf들 및 추가 측정 결과 리스트에 포함될 수 있다. 이 경우, 중복된 정보의 전송으로 인한 오버헤드는 증가할 수 있으나, 새로운 O-DU는 측정 결과의 개수에 상관없이 기존 leaf들 대신에 항상 추가 측정 결과 리스트를 디코딩하면 된다. 이 경우, O-DU의 구현 복잡도는 감소할 수 있다.
새로운 O-DU는 기존 O-DU의 기능들을 모두 지원할 수 있다. 따라서 하나의 측정 결과를 포함하는 기존 leaf들이 수신된 경우에도, 새로운 O-DU는 기존 leaf들을 항상 디코딩할 수 있다. 반면, 기존 O-DU는 추가 측정 결과 리스트를 디코딩하지 못할 수 있다. 기존 O-DU는 추가 측정 결과 리스트(예를 들어, 새로운 leaf들)를 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다. 기존 O-DU는 하나의 측정 결과를 포함하는 기존 leaf들을 수신할 수 있고, 기존 leaf들을 디코딩할 수 있다. 방법 d에서, 기존 O-DU는 항상 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)에 대한 수신 및 디코딩 동작들을 수행할 있다. 따라서 기존 O-DU는 기존 방식으로 동작할 수 있다. 상술한 방식에 의하면, 하위 호환성 문제는 해소될 수 있다. 상술한 동작의 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
상술한 방법에서, number-of-additional-measurement-result 및 seq-number는 사용되지 않을 수 있고, additional-XXXXX-measurement list의 키는 사용되지 않을 수 있다. 방법 a, 방법 b, 방법 c, 및 방법 d뿐만 아니라, 상술한 방법(들)의 조합 및/또는 변형이 사용될 수 있다.
[방법 A에 따른 실시예]
방법 A에 따른 실시예에서 파라미터들은 아래 표 3과 같이 설정될 수 있다.
Figure PCTKR2021017105-appb-T000003
표 3의 설정에 기초하면, O-RU는 측정 대상 A에 대한 2개의 측정 결과들 및 측정 대상 B에 대한 4개의 측정 결과들을 포함하는 통지를 O-DU에 전송할 수 있다.
방법 a가 사용되는 경우, 측정 대상 A에 대한 첫 번째 측정 결과(예를 들어, 0~30분의 측정 구간에서 측정 값)은 통지 내의 transceiver-stats에 포함될 수 있고, 0~30분의 측정 구간에 해당하는 start-time 및 end-time은 설정될 수 있다. 측정 대상 A에 대한 두 번째 측정 결과(예를 들어, 30~60분의 측정 구간에서 측정 값)은 additional-transceiver-measurement-result에 포함될 수 있고, 30~60분의 측정 구간에 해당하는 start-time 및 end-time은 설정될 수 있다.
측정 대상 B에 대한 첫 번째 측정 결과(예를 들어, 0~15분의 측정 구간에서 측정 값)은 통지 내의 rx-window-stats에 포함될 수 있고, 0~15분의 측정 구간에 해당하는 start-time 및 end-time은 설정될 수 있다. 측정 대상 B에 대한 두 번째 측정 결과(예를 들어, 15~30분의 측정 구간에서 측정 값), 측정 대상 B에 대한 세 번째 측정 결과(예를 들어, 30~45분의 측정 구간에서 측정 값), 및 측정 대상 B에 대한 네 번째 측정 결과(예를 들어, 45~60분의 측정 구간에서 측정 값)는 additional-rx-window-measurement-result에 포함될 수 있고, 15~30분의 측정 구간, 30~45분의 측정 구간, 및 45~60분의 측정 구간 각각에 해당하는 start-time 및 end-time은 설정될 수 있다. 방법 b가 사용되는 경우, 첫 번째 측정 결과부터 마지막 이전의 측정 결과까지의 측정 결과(들)은 측정 대상 A 및 측정 대상 B 각각의 additional-transceiver-measurement-result 및 additional-rx-window-measurement-result 내에서 설정될 수 있고, 마지막 측정 결과는 측정 대상 A 및 측정 대상 B 각각의 기존 transceiver-stats 및 rx-window-stats(예를 들어, 기존 rx-window-stats) 내에서 설정될 수 있다.
통신 시스템에서 추가 측정 결과 리스트 내에서 측정 결과들을 시간 순서대로 정렬시키기 위해, 키 값인 start-time과 end-time은 "ordered-by user"로 설정될 수 있다.
방법 c가 사용되는 경우, 통지 내에서 측정 대상 A에 대한 transceiver-stats는 생략될 수 있고, 측정 대상 A에 대한 첫 번째 측정 결과(예를 들어, 0~30분의 측정 구간에서 측정 값) 및 두 번째 측정 결과(예를 들어, 30~60분의 측정 구간에서 측정 값)는 통지 내의 additional-transceiver-measurement-result에 포함될 수 있다. 통지 내에서 측정 대상 B에 대한 rx-window-stats는 생략될 수 있고, 측정 대상 B에 대한 첫 번째 측정 결과(예를 들어, 0~15분의 측정 구간에서 측정 값), 두 번째 측정 결과(예를 들어, 15~30분의 측정 구간에서 측정 값), 세 번째 측정 결과(예를 들어, 30~45분의 측정 구간에서 측정 값), 및 네 번째 측정 결과(예를 들어, 45~60분의 측정 구간에서 측정 값) 모두는 additional-rx-window-measurement-result에 포함될 수 있다.
방법 d가 사용되는 경우, 측정 대상 A에 대한 하나의 측정 결과(예를 들어, 통지 간격에서 마지막 측정 값(예를 들어, 30~60분의 측정 구간에서 측정 값))는 통지 내의 transceiver-stats에 포함될 수 있고, 측정 대상 A에 대한 첫 번째 측정 결과(예를 들어, 0~30분의 측정 구간에서 측정 값) 및 두 번째 측정 결과(예를 들어, 30~60분의 측정 구간에서 측정 값)는 통지 내의 additional-transceiver-measurement-result에 포함될 수 있다. 측정 대상 B에 대한 하나의 측정 결과(예를 들어, 통지 간격에서 마지막 측정 값(예를 들어, 45~60분의 측정 구간에서 측정 값))은 통지 내의 rx-window-stats에 포함될 수 있고, 측정 대상 B에 대한 첫 번째 측정 결과(예를 들어, 0~15분의 측정 구간에서 측정 값), 두 번째 측정 결과(예를 들어, 15~30분의 측정 구간에서 측정 값), 세 번째 측정 결과(예를 들어, 30~45분의 측정 구간에서 측정 값), 및 네 번째 측정 결과(예를 들어, 45~60분의 측정 구간에서 측정 값) 모두는 additional-rx-window-measurement-result에 포함될 수 있다.
[방법 A]의 변형된 방법으로, additional-transceiver-measurement-result, additional-rx-window-measurement-result, 및 additional-tx-measurement-result, additional-epe-measurement-result 각각은 통지가 아닌 YANG 모듈의 앞쪽 부분인 transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result 및 epe-measurement-result에 포함될 수 있다. 즉, YANG 모듈의 앞쪽 부분인 transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result 및 epe-measurement-result은 확장될 수 있다. O-DU는 통지 방식이 아닌 get RPC를 사용하여 해당 measurement-result를 확인할 수 있다. 이 경우, O-DU는 주기적으로 get RPC를 전송하므로, 이에 따른 오버헤드가 발생할 수 있다.
[방법 B]
방법 B에서, 전체 측정 대상들의 측정 결과들을 포함하는 measurement-result-stats 내의 구조 전체는 측정 시간마다 시간 순서대로 통지에 반복 추가될 수 있다.
방법 A에서, transceiver-stats, rx-window-stats, tx-stats, 및 epe-statistic 각각에 속하는 측정 대상에 대한 통계 정보 내에 추가 측정 결과 리스트(예를 들어, list additional-transceiver-measurement-result, list additional-rx-window-measurement-result, list additional-tx-measurement-result, list additional-epe-measurement-result)가 포함되도록, YANG 모델은 확장될 수 있다. 방법 B에서, 추가 측정 결과 리스트는 측정 대상별로 해당 측정 대상에 대한 통계 정보 내에 추가되지 않을 수 있고, 전체 측정 대상들의 측정 결과들을 포함하는 measurement-result-stats 내의 구조 전체는 측정 시간마다 시간 순서대로 통지에 추가될 수 있다.
<방법 B-1>
<방법 B-1>에 따른 YANG 모델은 다음과 같이 정의될 수 있다.
module: o-ran-performance-management
... (생략) ...
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro number-of-additional-measurement-result-stats? uint8
+--ro additional-measurement-result-stats* [seq-number]
+--ro seq-number uint8
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name?->/o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
수정된 YANG 코드는 다음과 같이 정의될 수 있다.
notification measurement-result-stats {
description
"Notification may contain measurement results for transceiver-stats and/or rx-window-stats";
uses measurement-notification;
//For sending additional measurement result when notification-interval is larger than measurement-interval
leaf number-of-additional-measurement-result-stats {
type uint8;
description
"This parameter indicates the number of additional measurement result stats.";
}
list additional-measurement-result-stats {
// For sending additional measurement result stats when notification-interval is larger than measurement-interval
description
"Additional measurement result stats are included
when notification-interval is larger than measurement-interval and 'enable-multiple-stats-in-notification' is true.";
key seq-number;
leaf seq-number { //sequence number in ascending order starting from 1
type uint8 {
range "1..max";
}
}
uses measurement-notification;
}
}
각 측정 대상의 통지 간격이 측정 간격보다 긴 경우, 측정 대상 별로 복수의측정 결과들은 통지에 포함될 수 있다. 이 동작을 지원하기 위해, transceiver-stats, rx-window-stats, tx-stats, 및 epe-statistics 각각에 속하는 전체 측정 대상들의 측정 구간에서 측정 결과(들)을 포함하는 measurement-result-stats 내의 구조 전체는 추가 측정 결과 통계 리스트(additional-measurement-result-stats)를 사용하여 측정 구간마다 시간 오름차순으로 통지에 추가될 수 있다.
추가 측정 결과 통계 리스트는 측정 구간에서 전체 측정 대상들 각각에 대한 측정 정보(예를 들어, 측정 시작 시간(start-time), 측정 종료 시간(end-time), 및/또는 측정 구간에 대한 측정 값)를 포함할 수 있다. 추가 측정 결과 통계 리스트의 하나의 엔트리에 포함되는 구조는 기존의 하나의 측정 결과만 지원하는 measurement-result-stats의 구조와 동일할 수 있다. 상술한 구조들 간의 차이점은 추가 측정 결과 통계 리스트에 포함된 엔트리의 개수를 지시하는 정보(number-of-additional-measurement-result-stats) 및 추가 측정 결과 통계 리스트의 각 엔트리에 포함되는 시퀀스 번호(seq-number)의 존재일 수 있다. 시퀀스 번호는 추가 측정 결과 통계 리스트 내에서 엔트리들을 시간 순서대로 쉽게 정렬시키기 위해 사용될 수 있다. number-of-additional-measurement-result-stats는 추가 측정 결과 통계 리스트에 포함되는 additional-measurement-result-stats entry의 개수를 지시할 수 있다. O-DU는 number-of-additional-measurement-result-stats에 기초하여 통지의 디코딩 동작을 용이하게 할 수 있다.
또한, O-DU는 시퀀스 번호에 기초하여 추가 측정 결과 통계 리스트 내에서 엔트리들을 시간 순서대로 쉽게 정렬할 수 있다. 방법 a가 사용되는 경우, 시퀀스 번호는 1부터 오름차순으로 증가할 수 있다. 방법 b가 사용되는 경우, 시퀀스 번호는 0부터 오름차순으로 증가할 수 있다. 방법 a가 사용되는 경우, 기존 measurement-result-stats에 포함된 측정 결과는 0번째 측정 결과로 간주될 수 있다. 방법 b가 사용되는 경우, 기존 measurement-result-stats에 포함된 측정 결과는 마지막 측정 결과로 간주될 수 있다. O-DU는 시퀀스 번호를 additional-measurement-result-stats의 키 값으로 사용함으로써 measurement-result-stats들을 시간 순서대로 쉽게 정렬할 수 있다. 또한, O-DU는 시퀀스 번호를 사용하여 특정 순서의 measurement-result-stats를 쉽게 찾을 수 있다.
전송 파라미터의 개수를 줄이기 위해, number-of-additional-measurement-result-stats는 사용되지 않을 수 있다. NETCONF/YANG 모델에서 추가 측정 결과 통계 리스트에 포함되는 엔트리의 개수가 명시적으로 지시되지 않는 경우에도, 수신자는 엔트리 개수를 알 수 있다. number-of-additional-measurement-result-stats는 수신자의 디코딩 편의성을 위해 사용될 수 있다.
additional-measurement-results-stats의 키는 설정되지 않을 수 있다. 키가 설정되지 않는 경우, O-DU는 추가 측정 결과 통계 리스트의 특정 엔트리에 직접 액세스 할 수 없고, 추가 측정 결과 통계 리스트의 전체를 항상 디코딩해야 한다. 기존 YANG 모델에서 하나의 통지는 하나의 측정 결과만을 포함할 수 있다. 측정 결과를 측정 결과 리스트로 변경하는 경우, 기존 YANG 모델을 사용하는 프론트홀 장비(예를 들어, O-DU 및/또는 O-RU)와의 하위 호환성 문제가 발생할 수 있다. 본 출원에서 제안된 YANG 모델에서 기존 YANG 모델의 measurement-result-stats notification의 정보 구조(예를 들어, start-time, end-time, measurement-result)는 그대로 사용될 수 있다. 기존 YANG 모델의 measurement-result-stats notification은 첫 번째 측정 결과를 포함할 수 있다. 제안된 YANG 모델은 기존 YANG 모델에 비해 추가 측정 결과 통계 리스트를 더 포함할 수 있다. 추가 측정 결과 통계 리스트는 두 번째 측정 결과부터 포함할 수 있다. 측정 결과들은 추가 측정 결과 통계 리스트 내에서 시간 순서(예를 들어, 측정 시간의 오름차순)로 배치될 수 있다. 이 동작은 "방법 a"일 수 있다. 방법 a에 의하면, 기존 YANG 모델에서 사용하는 측정 관련 파라미터는 그대로 사용되기 때문에, 하위 호환성 문제는 발생하지 않을 수 있다.
즉, 하나의 통지에서 하나의 measurement-result-stats만을 디코딩할 수 있는 기존 O-DU는 기존 파라미터(들)(예를 들어, transceiver-stats, rx-window-stats, tx-stats, epe-stats)을 디코딩할 수 있다. 이 경우, O-RU가 복수의 측정 결과들을 포함하는 하나의 통지를 전송하는 경우에도, 기존 O-DU는 하나의 측정 결과를 성공적으로 수신할 수 있다.
다른 방법으로, O-RU는 복수의 측정 결과들 중에서 마지막 측정 결과를 기존의 측정 결과 파라미터로 설정할 수 있고, 첫 번째 측정 결과부터 마지막 이전의 측정 결과까지 포함하는 추가 측정 결과 통계 리스트(예를 들어, additional-measurement-result-stat)를 생성할 수 있다. 이 동작은 "방법 b"일 수 있다. 방법 b에 의하면, 기존 O-DU가 수신 가능한 하나의 측정 결과는 가장 최신의 측정 결과일 수 있다.
통신 시스템에서 추가 측정 결과 통계 리스트를 시간 순서대로 정렬시키기 위해 키 값인 시퀀스 번호는 "ordered-by user"로 정의될 수 있다.
[방법 B-1에 따른 실시예]
방법 B-1에 따른 실시예에서 파라미터들은 아래 표 4와 같이 설정될 수 있다.
Figure PCTKR2021017105-appb-T000004
표 4의 설정에 기초하면, O-RU는 측정 대상 A에 대한 2개의 측정 결과들 및 측정 대상 B에 대한 4개의 측정 결과들을 포함하는 통지를 O-DU에 전송할 수 있다. 이 경우, measurement-result-stats의 엔트리 개수는 짧은 측정 간격을 가지는 측정 대상 B에 대한 측정 간격을 기준으로 결정될 수 있다.
방법 a가 사용되는 경우, 측정 대상 B에 대한 첫 번째 측정 결과는 기존 measurement-results-stats에 포함될 수 있고, 측정 결과 A에 대한 측정 동작은 완료되지 않았기 때문에 기존 measurement-results-stats에 포함되지 않을 수 있다. 즉, 기존 measurement-results-stats는 0~15분의 측정 구간에서 측정 결과를 포함할 수 있다.
additional-measurement-result-stats의 첫 번째 엔트리는 15~30분의 측정 구간에서 완료된 측정 동작의 결과(예를 들어, 측정 대상 B에 대한 두 번째 측정 결과 및 측정 대상 A에 대한 첫 번째 측정 결과)를 포함할 수 있다. additional-measurement-result-stats의 두 번째 엔트리는 30~45분의 측정 구간에서 완료된 측정 동작의 결과(예를 들어, 측정 대상 B에 대한 세 번째 측정 결과)를 포함할 수 있다. additional-measurement-result-stats의 세 번째 엔트리는 45~60분의 측정 구간에서 완료된 측정 동작의 결과(예를 들어, 측정 대상 B에 대한 네 번째 측정 결과 및 측정 대상 A에 대한 두 번째 측정 결과)를 포함할 수 있다. 방법 b가 사용되는 경우, 첫 번째 측정 결과부터 마지막 이전의 측정 결과까지의 측정 결과(들)은 additional-measurement-result-stats에서 설정될 수 있고, 마지막 측정 결과는 기존 measurement-result-stat에서 설정될 수 있다. 이 동작은 후술되는 방법 b-2에 동일하게 적용될 수 있다.
[방법 B]의 변형된 방법으로, additional-measurement-result-stats는 통지가 아닌 YANG 모델의 앞 부분인 "transceiver-measurement-result, rx-window-measurement-result, tx-measurement-result, 및 epe-measurement-result" 다음에 포함될 수 있다. O-DU는 통지 방식 대신에 get RPC를 사용하여 복수의 measurement-result-stats들을 확인할 수 있다. 이 경우, O-DU는 주기적으로 get RPC를 전송할 수 있고, 이에 따른 오버헤드가 발생할 수 있다.
<방법 B-2>
방법 B-2에서, number-of-additional-measurement-result-stats 및 seq-number는 사용되지 않을 수 있고, additional-measurement-result-stats 리스트의 키는 사용되지 않을 수 있다. 이 경우, additional-measurement-result-stats 리스트의 하나의 엔트리에 포함되는 구조는 하나의 측정 결과를 포함하는 기존 measurement-result-stats와 동일할 수 있다.
방법 B-2에 따른 YANG 모델은 다음과 같이 정의될 수 있다.
module: o-ran-performance-management
... (생략) ...
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro additional-measurement-result-stats* []
+--ro transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name?->/o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? Enumeration
| +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
+--ro tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name?->/o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name?->/o-ran-elements:processing-elements/ru-elements/name
x--ro epe-stats
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+--ro epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
수정된 YANG 코드는 다음과 같이 정의될 수 있다.
notification measurement-result-stats {
description
"Notification may contain measurement results for transceiver-stats and/or rx-window-stats";
uses measurement-notification;
// For sending additional measurement result when notification-interval is larger than measurement-interval
list additional-measurement-result-stats {
// For sending additional measurement result stats when notification-interval is larger than measurement-interval
description
"Additional measurement result stats are included when notification-interval is larger than measurement-interval and 'enable-multiple-stats-in-notification' is true.";
uses measurement-notification;
}
}
<하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>
기존 O-RU(예를 들어, O-RAN M-Plane 버전 7.0 이전의 버전을 지원하는 O-RU)는 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 없다. 즉, 하나의 통지는 하나의 측정 결과만을 포함할 수 있다. O-DU가 측정 간격과 통지 간격을 동일하게 설정하는 경우, 하나의 통지에 하나의 측정 결과만이 포함되기 때문에 모든 측정 결과들은 빠짐없이 개별적인 통지에 의해 송수신될 수 있다. 이 동작은 (방법 가)로 지칭될 수 있다.
O-DU가 통지 간격을 측정 간격보다 길게 설정한 경우, O-RU(예를 들어, 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 없는 기존 O-RU)는 측정 결과들 중에서 가장 최신의 측정 결과만을 포함하는 통지를 O-DU에 전송할 수 있다. 이 동작은 (방법 나)로 지칭될 수 있다. 기존 O-DU는 복수의 측정 결과들을 포함하는 통지를 해석할 수 없다. 따라서 (방법 가)가 사용되는 경우, 복수의 측정 결과들을 포함하는 리스트를 기존 O-DU가 수신하는 것은 방지될 수 있다. 또한, (방법 가)가 사용되는 경우, O-RU(예를 들어, 새로운 O-RU)가 복수의 측정 결과들을 하나의 통지를 사용하여 전송하는 것은 방지될 수 있다. 이 동작은 특히 복수의 측정 결과들을 포함하는 통지를 해석할 수 없는 기존 O-DU에게 측정 결과를 전송하는 경우에 유용한 방법일 수 있다. O-DU(예를 들어, 기존 O-DU 혹은 새로은 O-DU)가 통신 시스템의 처리 부하를 줄이기 위해 일부 측정 결과만을 포함하는 통지를 수신하는 것을 원하는 경우에도, (방법 나)는 유용할 수 있다.
O-RU가 복수의 측정 결과들을 포함하는 하나의 통지를 전송할 수 있는 경우에도, O-DU는 측정 결과의 처리 부담을 줄이기 위해 통지에 포함되는 측정 결과의 개수를 1개로 제한할 수 있다. 예를 들어, O-DU는 enable-multiple-stats-in-notification을 FALSE로 설정할 수 있고, 이 경우, O-RU는 통지 간격이 측정 간격보다 긴 경우에도 복수의 측정 결과들 중에서 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)만을 포함하는 통지를 전송할 수 있다.
"enable-multiple-stats-in-notification"의 디폴트 값이 FALSE로 정의되고, 새로운 O-RU와 기존 O-DU가 동작하는 경우, enable-multiple-stats-in-notification은 항상 FALSE이므로, 새로운 O-RU는 통지 간격이 측정 간격보다 길게 설정된 경우에도 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)를 기존 O-DU에 전송할 수 있다. "enable-multiple-stats-in-notification"의 디폴트 값이 FALSE로 정의되고, 새로운 O-RU와 새로운 O-DU가 동작하는 경우, 하나의 측정 결과를 포함하는 하나의 통지 및 복수의 측정 결과들을 포함하는 하나의 통지 모두는 사용될 수 있다.
새로운 O-DU는 새로운 O-RU의 enable-multiple-stats-in-notification를 FALSE로 설정할 수 있다. 이 경우, 새로운 O-RU는 하나의 측정 결과의 전송을 지원하는 leaf들을 사용하여 하나의 측정 결과를 새로운 O-DU에 전송할 수 있다. 또는, 새로운 O-RU는 하나의 측정 결과를 포함하는 measurement result list를 새로운 O-DU에 전송할 수 있다. 새로운 O-RU는 기존 O-DU에 통지를 전송하기 위해 하나의 측정 결과의 전송을 지원하는 leaf들을 사용할 수 있다.
O-RU의 YANG 모델은 O-RU가 지원하는 O-RAN M-Plane 버전을 표시할 수 있다. 따라서 O-DU는 O-RU에 의해 지원되는 O-RAN M-Plane 버전에 기초하여 해당 O-RU가 복수의 측정 결과들을 포함하는 하나의 통지의 전송 기능(즉, 멀티 측정 결과 보고 기능)을 지원하는지 여부를 알 수 있다.
측정 결과의 처리 부담을 줄이기 위해 통지에 포함되는 측정 결과의 개수를 제한하는 다른 방법으로, 하나의 통지에 포함되는 측정 결과의 최대 개수를 지시하는 max-number-of-measurement-result-per-notification는 설정될 수 있다. 즉, max-number-of-measurement-result-per-notification는 YANG 모델에 추가될 수 있다. O-DU는 max-number-of-measurement-result-per-notification를 O-RU에 설정할 수 있다. O-RU는 max-number-of-measurement-result-per-notification에 의해 지시되는 최대 개수 이하의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송할 수 있다.
방법 a, 방법 b, 방법 c, 및/또는 방법 d가 사용되는 경우, 하위 호환성은 보장될 수 있고, 멀티 측정 결과 통지를 지원하지 않는 장비와의 상호 운용성은 보장될 수 있다. 방법 a, 방법 b, 방법 c, 및/또는 방법 d가 사용되는 경우, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지가 O-DU에서 디코딩 가능한지를 알지 못할 수 있다.
"O-DU가 O-RAN M-Plane 7.0 버전 이전의 버전을 지원하는 경우", "O-RAN M-Plane 7.0 버전을 지원하는 O-DU가 복수의 측정 결과들의 디코딩 기능을 지원하지 않는 경우", 또는 "O-RAN M-Plane 7.0 버전을 지원하는 O-DU가 복수의 측정 결과들의 디코딩 기능을 사용하지 않는 경우", O-RU가 복수의 측정 결과들을 포함하는 하나의 통지를 전송하면, 복수의 측정 결과들은 O-DU에서 디코딩되지 못할 수 있다. 또한, O-DU는 O-RU가 멀티 측정 결과 보고 기능을 지원하는지 여부를 알지 못할 수 있다. 멀티 측정 결과 보고 기능을 지원하지 못하는 O-RU를 위한 통지 간격이 측정 간격보다 길게 설정된 경우, O-DU는 일부 측정 결과를 O-RU로부터 수신하지 못할 수 있다.
상술한 문제를 해결하기 위해, O-RU는 멀티 측정 결과 보고 기능을 지원하는지 여부를 지시하는 캐퍼빌러티(capability)를 O-DU에 알릴 수 있다. 상술한 캐퍼빌러티 관련 파라미터는 M-Plane을 통해 O-DU에게 알려질 수 있다. O-DU는 O-RU의 캐퍼빌러티 관련 파라미터에 기초하여 O-RU가 멀티 측정 결과 보고 기능을 지원하는지를 확인할 수 있다. O-RU가 멀티 측정 결과 보고 기능을 지원하는 경우, O-DU는 멀티 측정 결과 보고 기능의 인에이블(enable)을 O-RU에 지시할 수 있다. 멀티 측정 결과 보고 기능이 명시적으로 인에이블된 경우, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송할 수 있다. 상술한 동작은 (방법 I)로 지칭될 수 있다. (방법 I)을 지원하기 위해 기존 o-ran-performance-management.yang module은 다음과 같이 확장될 수 있다.
+--rw transceiver-measurement-interval? uint16
+--rw epe-measurement-interval? uint16
+--rw rx-window-measurement-interval? uint16
+--rw tx-measurement-interval? uint16
+--rw notification-interval? uint16
+--rw file-upload-interval? uint16
+--ro max-bin-count uint16
+--ro multiple-stats-in-notification-capable? boolean
+--rw enable-multiple-stats-in-notification? boolean
즉, "ro multiple-stats-in-notification-capable" 및 "rw enable-multiple-stats-in-notification"는 YANG 모듈에 추가될 수 있다. (방법 I)에 따른 확장된 YANG 코드는 다음과 같이 정의될 수 있다.
module: o-ran-performance-management
... (생략) ...
leaf max-bin-count{
type uint16;
config false;
mandatory true;
description
"indicates the maximum value of configurable bin-count for frequency table in transceiver-measurement-objects as one of module capabilities.";
}
leaf multiple-stats-in-notification-capable{
type boolean;
config false;
default false;
description
"Flag to indicate whether the O-RU is capable of sending a notification including multiple stats when notification-interval is larger than measurement-interval.";
}
leaf enable-multiple-stats-in-notification {
type boolean;
default false;
description
"Flag to enable multiple stats to be included in one notification
when notification-interval is larger than measurement-interval and 'multiple-stats-in-notification-capable' is true.";
}
multiple-stats-in-notification-capable은 통지 간격이 측정 간격보다 긴 경우에 O-RU가 멀티 측정 결과 보고 기능을 지원하는지 여부를 지시하는 캐퍼빌러티일 수 있다. multiple-stats-in-notification-capable의 디폴트 값은 false일 수 있다.
enable-multiple-stats-in-notification은 O-DU에 의해 설정될 수 있다. O-RU의 multiple-stats-in-notification-capable이 true로 설정된 경우, O-DU는 enable-multiple-stats-in-notification을 true로 설정할 수 있다. 이 경우, 통지 간격이 측정 간격보다 긴 경우, O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송할 수 있다. enable-multiple-stats-in-notification의 디폴트 값은 false일 수 있다.
O-DU는 하나의 통지에 포함된 복수의 측정 결과들을 디코딩할 수 있고, O-RU는 멀티 측정 결과 보고 기능을 지원하지 못할 수 있다. 즉, O-DU는 새로운 O-DU일 수 있고, O-RU는 기존 O-RU일 수 있다. 이 경우, O-RU의 YANG 파라미터에서 multiple-stats-in-notification-capable는 존재하지 않을 수 있다. 즉, multiple-stats-in-notification-capable는 디폴트 값(즉, false)이기 때문에, O-DU는 O-RU가 멀티 측정 결과 보고 기능을 지원하지 못하는 것으로 판단할 수 있다. 이 경우, O-DU는 멀티 측정 결과 보고 기능을 사용하지 않거나 통지 간격이 측정 간격보다 길지 않도록 O-RU의 파라미터(들)을 설정할 수 있다. 새로운 O-RU도 멀티 측정 결과 보고 기능을 지원하지 않을 수 있다. 이 경우 O-RU는 multiple-stats-in-notification-capable를 false로 설정할 수 있다. 새로운 O-RU의 multiple-stats-in-notification-capable가 false로 설정된 경우, O-DU는 멀티 측정 결과 보고 기능을 사용하지 않을 수 있다. 혹은, O-DU는 통지 간격이 측정 간격보다 길지 않도록 O-RU의 파라미터(들)을 설정할 수 있다.
"O-RU가 멀티 측정 결과 보고 기능을 지원하고, O-DU가 멀티 측정 결과 보고 기능을 지원하지 못하는 경우", O-DU는 O-RU의 enable-multiple-stats-in-notification을 true로 설정하지 않을 수 있다. 따라서 O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송하지 않을 수 있다.
enable-multiple-stats-in-notification를 해석하지 못하는 기존 O-DU는 enable-multiple-stats-in-notification를 설정하지 않을 수 있다. 이 경우, enable-multiple-stats-in-notification는 디폴트 값(즉, false)일 수 있다. 따라서 O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송하지 않을 수 있다.
상술한 방법의 변형으로, 새로운 O-RU(예를 들어, O-RAN M-Plane 7.0 버전을 지원하는 O-RU, O-RAN M-Plane 7.0 버전 이후의 버전을 지원하는 O-RU)는 멀티 측정 결과 보고 기능을 항상 지원할 수 있다. 이 동작은 (방법 II)로 지칭될 수 있다. 이 경우, multiple-stats-in-notification-capable는 사용될 필요가 없다. O-DU는 YANG 모델의 O-RAN M-Plane 버전 정보에 기초하여 O-RU가 기존 O-RU임을 확인할 수 있다. O-DU는 기존 O-RU임이 확인되면 기존 O-RU를 위한 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 새로운 O-RU임이 확인되면 새로운 O-RU는 복수의 측정 리스트들을 전송할 수 있으므로, O-DU는 새로운 O-RU를 위한 측정 간격과 통지 간격을 다르게 설정할 수 있다.
측정 간격보다 통지 간격이 길게 설정된 경우, 기존 O-RU는 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 하나의 통지를 O-DU에 전송할 수 있다. 이 경우, multiple-stats-in-notification-capable은 필요 없으므로, enable-multiple-stats-in-notification만이 YANG 모델에 추가될 수 있다. enable-multiple-stats-in-notification의 디폴트 값은 false로 설정될 수 있다. "O-DU가 enable-multiple-stats-in-notification을 true로 설정하고, O-RU를 위한 통지 간격이 측정 간격보다 긴 경우", O-RU는 복수의 측정 결과들을 포함하는 하나의 통지를 O-DU에 전송할 수 있다.
(방법 나)와 같이 측정 결과의 처리 부담을 줄이기 위해, O-DU는 하나의 통지에 포함되는 측정 결과의 개수를 1개로 제한할 수 있다. enable-multiple-stats-in-notification는 false로 설정될 수 있고, O-RU는 통지 간격이 측정 간격보다 긴 경우에도 복수의 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 통지를 O-DU에 전송할 수 있다. "enable-multiple-stats-in-notification의 디폴트 값이 false로 설정되고, 새로운 O-RU와 기존 O-DU가 동작하는 경우", O-RU의 enable-multiple-stats-in-notification의 값은 항상 false이기 때문에, 새로운 O-RU는 통기 간격이 측정 간격보다 긴 경우에 복수의 측정 결과들 중에서 하나의 측정 결과(예를 들어, 가장 최신의 측정 결과)를 O-DU에 전송할 수 있다.
새로운 O-RU와 새로운 O-DU가 동작하는 경우, 하나의 측정 결과를 포함하는 하나의 통지 및 복수의 측정 결과들을 포함하는 하나의 통지는 모두 사용될 수 있다. 새로운 O-DU가 새로운 O-RU의 enable-multiple-stats-in-notification를 false로 설정하는 경우, 새로운 O-RU는 하나의 측정 결과의 전송을 지원하는 기존 leaf들 또는 추가 측정 결과 리스트를 사용하여 하나의 측정 결과를 전송할 수 있다. 새로운 O-RU는 하나의 측정 결과의 전송을 지원하는 기존 leaf들을 사용하여 하나의 측정 결과를 기존 O-DU에 전송할 수 있다.
새로운 O-RU가 멀티 측정 결과 보고 기능을 옵션으로 지원하는 경우에도 상술한 (방법 II)가 사용될 수 있다. 이 동작은 (방법 III)으로 지칭될 수 있다. 이 경우, multiple-stats-in-notification-capable는 YANG 모델에 추가되지 않을 수 있다. enable-multiple-stats-in-notification는 YANG 모델에 추가될 수 있다. "O-DU가 enable-multiple-stats-in-notification을 true로 설정한 경우", "O-RU가 멀티 측정 결과 보고 기능을 지원하지 않은 경우", 또는 "O-RU가 멀티 측정 결과 보고 기능을 사용하지 않는 경우", O-RU는 하나의 측정 결과의 전송을 지원하는 기존 leaf들을 사용하여 하나의 측정 결과를 O-DU에 전송할 수 있다. 나머지 동작들은 상술한 (방법 II)와 동일할 수 있다.
새로운 O-RU는 복수의 측정 리스트들을 옵션으로 지원할 수 있고, multiple-stats-in-notification-capable 및 enable-multiple-stats-in-notification 모두는 YANG 모델에 추가되지 않을 수 있다. 이 동작은 (방법 IV)로 지칭될 수 있다. 멀티 측정 결과 보고 기능을 지원하는 O-RU는 복수의 측정 결과들을 포함하는 측정 결과 리스트(들)을 생성할 수 있고, 측정 결과 리스트(들)을 포함하는 통지를 전송할 수 있다. 멀티 측정 결과 보고 기능을 지원하지 않은 O-RU는 하나의 측정 결과의 전송을 지원하는 기존 leaf들을 사용하여 하나의 측정 결과를 O-DU에 전송할 수 있다.
방법 a, 방법 b, 및/또는 방법 d가 사용되는 경우, 복수의 측정 결과들을 포함하는 측정 결과 리스트(들)과 함께 하나의 측정 결과를 포함하는 기존 leaf들이 전송될 수 있다. 기존 O-DU(예를 들어, 이전 YANG 모델을 지원하는 O-DU)는 통지에 포함된 측정 결과 리스트(들)에 대한 디코딩을 하지 못할 수 있고, 새로운 leaf들(예를 들어, 측정 결과 리스트(들))을 무시할 수 있다. 따라서 기존 O-DU에서 오류는 발생하지 않을 수 있다.
(기타)
"기존 O-DU와 새로운 O-RU가 동작하고, 기존 O-DU가 새로운 O-RU를 위한 측정 간격을 통지 간격과 동일하게 설정하는 경우", 기존 O-DU가 복수의 측정 결과들을 포함하는 하나의 통지를 새로운 O-RU로부터 수신하는 것은 방지될 수 있다. 하나의 통지 간격에서 하나의 측정 결과가 발생함으로, 새로운 O-RU는 기존 방식에 따라 하나의 측정 결과를 포함하는 하나의 통지를 전송할 수 있다. 이 방법이 사용되는 경우, multiple-stats-in-notification-capable 및 enable-multiple-stats-in-notification은 사용될 필요가 없다. 하나의 측정 결과가 추가 측정 결과 리스트 대신에 기존 leaf들을 사용하여 전송되는 경우, 기존 O-DU는 항상 측정 결과를 디코딩할 수 있다. 따라서 하위 호환성 문제는 발생하지 않을 수 있다. 상술한 동작은 방법 c에서 유용할 수 있다.
방법 c가 사용되는 경우, 기존 O-DU는 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 이 경우, 하나의 통지 간격에서 하나의 측정 결과만이 발생할 수 있다. O-RU는 하나의 측정 결과의 전송을 지원하는 기존 leaf들을 사용하여 하나의 측정 결과를 기존 O-DU에 전송할 수 있다. 기존 O-DU는 O-RU로부터 수신된 측정 결과를 디코딩할 수 있다. 새로운 O-DU는 통지 간격을 측정 간격보다 길게 설정할 수 있다. 이 경우, 하나의 통지 간격에서 복수의 측정 결과들이 발생할 수 있다. O-RU는 복수의 측정 결과들을 포함하는 측정 결과 리스트를 생성할 수 있고, 측정 결과 리스트를 포함하는 통지를 새로운 O-DU에 전송할 수 있다. 새로운 O-DU는 O-RU로부터 수신된 측정 결과 리스트를 디코딩할 수 있다. 즉, 통지 간격이 측정 간격보다 긴 경우에 멀티 측정 결과 보고 기능은 인에이블될 수 있다. 통지 간격이 측정 간격보다 길지 않은 경우, 멀티 측정 결과 보고 기능은 디세이블(disable)될 수 있다.
방법 a, 방법 b, 및/또는 방법 d에서, 통지는 하나의 측정 결과의 전송을 지원하는 기존 leaf들을 항상 포함할 수 있다. 따라서 기존 O-DU는 O-RU로부터 수신된 통지를 디코딩할 수 있으므로, 하위 호환성 문제는 발생하지 않을 수 있다.
상술한 방법(들)에 의하면, 하위 호환성은 보장될 수 있고, 멀티 측정 결과 보고 기능을 지원하지 않은 장비와의 상호 운용성은 보장될 수 있다.
복수의 측정 결과들을 포함하는 하나의 통지의 전송을 방지하기 위해, 측정 대상별로 별도의 통지 간격 파라미터는 사용될 수 있다. 통지 간격은 측정 대상별로 설정될 수 있다. 측정 대상들을 위한 통지 간격들은 서로 다르게 설정될 수 있다. 예를 들어, 각 측정 대상을 위해 transceiver-notification-interval, rx-window-notification-interval, tx-stats-notification-interval, epe-stats-notification-interval, 및/또는 rssi-stats-notification-interval의 파라미터들은 각각 설정될 수 있다. 측정 대상들의 측정 간격들이 서로 다른 경우에도, 각 측정 대상의 통지 간격은 해당 측정 대상의 측정 간격보다 길지 않게 설정될 수 있다. 이 방법에 의하면, 복수의 측정 결과들을 포함하는 하나의 통지가 전송되는 것은 방지될 수 있다.
O-RAN에서 다양한 측정 대상들이 도입될 수 있으며, 상술한 방법(들)에 따라 새로운 측정 대상들에 대한 멀티 측정 결과 보고 기능은 적용될 수 있다. 예를 들어, RSSI 대상(예를 들어, Time Domain RSSI object)에 대한 통지는 아래와 같이 정의될 수 있다.
notification
... (생략) ...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
| +--ro value? int16
+--ro max
| +--ro value? int16
+--ro avg
| +--ro value? int16
+--ro frequency-table* uint32
... (생략) ...
위와 같은 하나의 측정 결과를 포함하는 하나의 통지는 상술한 방법(들)과 유사하게 확장될 수 있다. 즉, 하나의 통지는 복수의 측정 결과들을 포함하도록 확장될 수 있다. 예를 들어, 방법 A의 첫 번째 방법을 적용하면, YANG 모델은 다음과 같이 정의될 수 있다.
notifications:
+---n measurement-result-stats
...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
| +--ro value? int16
+--ro max
| +--ro value? int16
+--ro avg
| +--ro value? int16
+--ro frequency-table* uint32
+--ro number-of-additional-measurement-result? uint8
+--ro additional-symbol-rssi-measurement-result* [seq-number]
+--ro seq-number uint8
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
+--ro value? int16
+--ro max
+--ro value? int16
+--ro avg
+--ro value? int16
+--ro frequency-table* uint32
방법 A의 두 번째 방법을 적용하면, YANG 모델은 다음과 같이 정의될 수 있다.
notifications:
+---n measurement-result-stats
...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
| +--ro value? int16
+--ro max
| +--ro value? int16
+--ro avg
| +--ro value? int16
+--ro frequency-table* uint32
+--ro additional-symbol-rssi-measurement-result* [start-time end-time]
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
+--ro value? int16
+--ro max
+--ro value? int16
+--ro avg
+--ro value? int16
+--ro frequency-table* uint32
방법 A의 세 번째 방법을 적용하면, YANG 모델은 다음과 같이 정의될 수 있다.
notifications:
+---n measurement-result-stats
...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
| +--ro value? int16
+--ro max
| +--ro value? int16
+--ro avg
| +--ro value? int16
+--ro frequency-table* uint32
+--ro additional-symbol-rssi-measurement-result* []
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
+--ro value? int16
+--ro max
+--ro value? int16
+--ro avg
+--ro value? int16
+--ro frequency-table* uint32
방법 B의 첫 번째 방법을 적용하면, YANG 모델은 다음과 같이 정의될 수 있다.
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
...
+--ro rx-window-stats* [measurement-object]
...
+--ro tx-stats* [measurement-object]
...
+--ro epe-statistics* [measurement-object]
...
+--ro symbol-rssi-stats* [measurement-object]
...
+--ro number-of-additional-measurement-result-stats? uint8
+--ro additional-measurement-result-stats* [seq-number]
+--ro seq-number uint8
+--ro transceiver-stats* [measurement-object]
...
+--ro rx-window-stats* [measurement-object]
...
+--ro tx-stats* [measurement-object]
...
+--ro epe-statistics* [measurement-object]
...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
+--ro value? int16
+--ro max
+--ro value? int16
+--ro avg
+--ro value? int16
+--ro frequency-table* uint32
방법 B의 두 번째 방법을 적용하면, YANG 모델은 다음과 같이 정의될 수 있다.
notifications:
+---n measurement-result-stats
+--ro transceiver-stats* [measurement-object]
...
+--ro rx-window-stats* [measurement-object]
...
+--ro tx-stats* [measurement-object]
...
+--ro epe-statistics* [measurement-object]
...
+--ro symbol-rssi-stats* [measurement-object]
..
+--ro additional-measurement-result-stats* []
+--ro transceiver-stats* [measurement-object]
...
+--ro rx-window-stats* [measurement-object]
...
+--ro tx-stats* [measurement-object]
...
+--ro epe-statistics* [measurement-object]
...
+--ro symbol-rssi-stats* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/symbol-rssi-measurement-objects/measurement-object
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro symbol-rssi-measurement-result* [object-unit-id]
+--ro object-unit-id -> /up:user-plane-configuration/rx-array-carriers/name
+--ro per-symbol-index-result* [symbol-index]
+--ro symbol-index uint16
+--ro min
+--ro value? int16
+--ro max
+--ro value? int16
+--ro avg
+--ro value? int16
+--ro frequency-table* uint32
<복수의 측정 결과들을 포함하는 별도의 통지를 전송하는 방법>
기존 통지에 additional-xxxx-measurement-result의 추가 없이, O-RU는 복수의 측정 결과들을 포함하는 별도의 통지를 전송할 수 있다.
[방법 A]의 세번째 방식의 방법 c에서 additional-xxxx-measurement-result를 포함하는 별도의 통지가 전송될 수 있다. 이 동작을 위한 YANG 모델은 다음과 같이 정의될 수 있다.
module: o-ran-performance-management
... (생략) ...
notifications:
+---n measurement-result-stats
| +--ro transceiver-stats* [measurement-object]
| | +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| | +--ro start-time? yang-types:date-and-time
| | +--ro end-time? yang-types:date-and-time
| | +--ro transceiver-measurement-result* [object-unit-id]
| | +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| | +--ro min
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro max
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro first
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro latest
| | | +--ro value? decimal64
| | | +--ro time? yang-types:date-and-time
| | +--ro frequeny-table* uint32
| +--ro rx-window-stats* [measurement-object]
| | +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| | +--ro start-time? yang-types:date-and-time
| | +--ro end-time? yang-types:date-and-time
| | +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name?-> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro data-direction? enumeration
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| +--ro tx-stats* [measurement-object]
| | +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| | +--ro start-time? yang-types:date-and-time
| | +--ro end-time? yang-types:date-and-time
| | +--ro (object-unit-id)?
| | +--:(RU)
| | | +--ro name? -> /hw:hardware/component/name
| | | +--ro count uint64
| | +--:(TRANSPORT)
| | | +--ro tr-measured-result* []
| | | +--ro name?-> /o-ran-elements:processing-elements/ru-elements/name
| | | +--ro count uint64
| | +--:(EAXC_ID)
| | +--ro eaxc-measured-result* []
| | +--ro eaxc-id? uint16
| | +--ro count uint64
| | +--ro transport-name? -> /o-ran-elements:processing-elements/ru-elements/name
| x--ro epe-stats
| | +--ro start-time? yang-types:date-and-time
| | +--ro end-time? yang-types:date-and-time
| | +--ro epe-measurement-result* [object-unit-id]
| | +--ro object-unit-id -> /hw:hardware/component/class
| | +--ro min? decimal64
| | +--ro max? decimal64
| | +--ro average? decimal64
| +--ro epe-statistics* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro epe-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /hw:hardware/component/class
| +--ro min? decimal64
| +--ro max? decimal64
| +--ro average? decimal64
+---n multiple-measurement-result-stats
+--ro multiple-transceiver-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
| +--ro additional-transceiver-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro transceiver-measurement-result* [object-unit-id]
| +--ro object-unit-id -> /if:interfaces/interface/o-ran-int:port-reference/port-number
| +--ro min
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro max
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro first
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro latest
| | +--ro value? decimal64
| | +--ro time? yang-types:date-and-time
| +--ro frequeny-table* uint32
+--ro multiple-rx-window-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/rx-window-measurement-objects/measurement-object
| +--ro additional-rx-window-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro data-direction? enumeration
| +--ro transport-name?->/o-ran-elements:processing-elements/ru-elements/name
+--ro multiple-tx-stats* [measurement-object]
| +--ro measurement-object -> /performance-measurement-objects/tx-measurement-objects/measurement-object
| +--ro additional-tx-measurement-result* []
| +--ro start-time? yang-types:date-and-time
| +--ro end-time? yang-types:date-and-time
| +--ro (object-unit-id)?
| +--:(RU)
| | +--ro name? -> /hw:hardware/component/name
| | +--ro count uint64
| +--:(TRANSPORT)
| | +--ro tr-measured-result* []
| | +--ro name? -> /o-ran-elements:processing-elements/ru-elements/name
| | +--ro count uint64
| +--:(EAXC_ID)
| +--ro eaxc-measured-result* []
| +--ro eaxc-id? uint16
| +--ro count uint64
| +--ro transport-name?->/o-ran-elements:processing-elements/ru-elements/name
+--ro multiple-epe-statistics* [measurement-object]
+--ro measurement-object -> /performance-measurement-objects/epe-measurement-objects/measurement-object
+--ro additional-epe-measurement-result* []
+--ro start-time? yang-types:date-and-time
+--ro end-time? yang-types:date-and-time
+--ro epe-measurement-result* [object-unit-id]
+--ro object-unit-id -> /hw:hardware/component/class
+--ro min? decimal64
+--ro max? decimal64
+--ro average? decimal64
하나의 측정 결과를 전달하는 통지인 result-stats는 수정 없이 사용될 수 있고, 복수의 측정 결과들을 전달하는 통지인 multiple-measurement-result-stats는 새롭게 정의될 수 있다. O-RU는 복수의 측정 결과들을 포함하는 additional-XXXX-measurement-result[]를 생성할 수 있고, additional-XXXX-measurement-result[]를 전송할 수 있다. 복수의 측정 결과들의 전달을 위한 부분을 별도의 통지로 정의한 점을 제외한 나머지 사항들은 [방법 A]와 동일할 수 있다.
상술한 실시예는 [방법 A]의 방법 c를 변형한 방법일 수 있고, 별도의 통지가 사용될 수 있다. O-RU는 하나의 측정 결과의 전송을 지원하는 leaf들(예를 들어, start-time, end-time, 및 XXXX-measurement-result[])을 포함하는 기존 measurement-result-stats notification을 사용하여 하나의 측정 결과를 기존 O-DU에 전송할 수 있고, 복수의 측정 결과들 전체를 포함하는 새로운 multiple-measurement-result-stats를 새로운 O-DU에 전송할 수 있다. multiple-measurement-result-stats는 additional-XXXX-measurement-result[]를 포함할 수 있고, additional-XXXX-measurement-result[]는 복수의 측정 결과들을 포함할 수 있다. 모든 측정 결과들(예를 들어, 첫 번째 측정 결과부터 마지막 측정 결과까지의 측정 결과들)은 additional-XXXX-measurement-result[] 내에서 시간 순서대로 정렬될 수 있다.
기존 O-DU에 전송되는 기존 measurement-result-stats notification는 측정 대상 별 하나의 측정 결과를 포함할 수 있다. 이 경우, 기존 O-DU는 하나의 통지 간격에서 하나의 측정 결과가 발생하도록 O-RU의 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 또는, 기존 O-DU가 통지 간격을 측정 간격보다 길게 설정한 경우, O-RU는 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 기존 measurement-result-stats notification을 O-DU에 전송할 수 있다. 상술한 동작을 위한 세부 방법들은 <하위 호환성 및 멀티 측정 결과 보고 기능을 지원하지 않는 장비와의 상호 운용성을 보장하기 위한 방법>에 설명된다.
[방법 A]의 방법 a, 방법 b, 및/또는 방법 d가 사용되는 경우, 상술한 방법과 동일하게 기존 leaf들과 새로운 리스트는 별도의 통지로 전송될 수 있다. 즉, [방법 A]의 방법 a, 방법 b, 및/또는 방법 d에서, 하나의 측정 결과는 기존 measurement-result-stats notification(즉, 기존 leaf들)을 사용하여 전송될 수 있고, 복수의 측정 결과들은 multiple-measurement-result-stats notification(즉, 새로운 리스트)를 사용하여 전송될 수 있다.
O-RU의 multiple-stats-in-notification-capable이 false인 경우, O-DU는 하나의 측정 결과를 포함하는 measurement-result-stats notification(즉, 기존 통지)만을 확인할 수 있다. O-RU의 multiple-stats-in-notification-capable이 true인 경우, O-DU는 enable-multiple-stats-in-notification을 true로 설정할 수 있고, 복수의 측정 결과들을 포함하는 multiple-measurement-result-stats notification(즉, 새로운 통지)를 수신할 수 있다. O-RU가 멀티 측정 결과 보고 기능을 지원하는 경우에도, O-DU의 부담을 줄이기 위해, O-DU는 enable-multiple-stats-in-notification을 false로 설정할 수 있다. 이 경우, O-RU는 하나의 측정 결과를 포함하는 measurement-result-stats notification를 O-DU에 전송할 수 있고, O-DU는 하나의 측정 결과를 포함하는 measurement-result-stats notification를 O-RU로부터 수신할 수 있다. 또는, O-DU는 하나의 측정값을 포함하고 있는 multiple-measurement-result-stats notification를 수신할 수 있고, multiple-measurement-result-stats notification부터 하나의 측정 결과만을 획득할 수 있다.
O-RU가 YANG 모델의 multiple-stats-in-notification-capable을 사용하지 않는 경우, O-DU는 measurement-result-stats notification 및 multiple-measurement-result-stats notification 모두를 구독(subscribe)할 수 있다. 이 경우, O-RU가 복수의 측정 결과들을 포함하는 통지를 전송하면, O-DU는 O-RU로부터 multiple-measurement-result-stats notification를 수신할 수 있다. O-RU가 하나의 측정 결과를 포함하는 기존 통지를 전송하면, O-DU는 O-RU로부터 기존 measurement-result-stats notification를 수신할 수 있다.
기존 O-DU는 멀티 측정 결과 보고 기능을 지원하지 않을 수 있고, 기존 measurement-result-stats만을 구독할 수 있다. 이 경우, enable-multiple-stats-in-notification의 디폴트 값이 false로 설정되면, 기존 O-DU는 enable-multiple-stats-in-notification를 별도로 설정하지 않을 수 있다. 따라서 O-RU는 하나의 측정 결과를 포함하는 기존 measurement-result-stats notification을 기존 O-DU에 전송할 수 있다.
새로운 O-RU는 multiple-measurement-result-stats notification을 옵션으로 지원할 수 있고, multiple-stats-in-notification-capable 및 enable-multiple-stats-in-notification 모두는 YANG 모델에 추가되지 않을 수 있다. O-RU는 멀티 측정 결과 보고 기능을 지원할 수 있고, O-DU는 multiple-measurement-result-stats notification를 구독할 수 있다. 이 경우, O-DU는 복수의 측정 결과들을 포함하는 하나의 통지를 수신할 수 있다.
O-RU가 multiple-measurement-result-stats notification을 지원하지 않는 경우, O-DU는 기존 measurement-result-stats notification을 구독함으로써 하나의 측정 결과를 포함하는 통지를 수신할 수 있다. 이 경우, O-DU는 복수의 측정 결과들에 관련된 O-RU의 캐퍼빌러티를 모르기 때문에 기존 measurement-result-stats notification 및 새로운 multiple-measurement-result-stats notification 모두를 구독해야 한다. 기존 O-DU는 새로운 multiple-measurement-result-stats notification을 구독할 수 없기 때문에 O-RU로부터 multiple-measurement-result-stats notification을 수신하지 못할 수 있다. 이에 따른 오류는 발생하지 않을 수 있다.
"기존 O-DU와 새로운 O-RU가 동작하고, 기존 O-DU가 새로운 O-RU의 측정 간격과 통지 간격을 동일하게 설정한 경우", 기존 O-DU가 새로운 O-RU로부터 복수의 측정 결과들을 포함하는 하나의 통지(예를 들어, multiple-measurement-result-stats notification)를 수신하는 것은 방지될 수 있다. 즉, 하나의 통지 간격에서 하나의 측정 결과가 발생하므로, 새로운 O-RU는 하나의 측정 결과를 포함하는 기존 measurement-result-stats notification을 전송할 수 있다. 상술한 방법이 사용되는 경우, multiple-stats-in-notification-capable 및 enable-multiple-stats-in-notification는 사용되지 않을 수 있다. 상술한 동작은 방법 c에서 유용할 수 있다.
방법 c가 사용되는 경우, 기존 O-DU는 하나의 통지 간격에서 하나의 측정 결과가 발생하도록 측정 간격과 통지 간격을 동일하게 설정할 수 있다. 이 경우, O-RU는 하나의 측정 결과를 포함하는 기존 leaf들(예를 들어, measurement-result-stats notification을 통해)을 전송할 수 있다. 기존 O-DU는 O-RU로부터 수신된 기존 notification에 포함된 leaf들에 포함된 하나의 측정 결과를 디코딩할 수 있다. 새로운 O-DU는 통지 간격을 측정 간격보다 길게 설정할 수 있다. 이 경우, 하나의 통지 간격에서 복수의 측정 결과들이 발생하면, O-RU는 복수의 측정 결과들을 포함하는 새로운 리스트(예를 들어, 새로운 multiple-measurement-result-stats notification을 통해)를 새로운 O-DU에 전송할 수 있다. 새로운 O-DU는 O-RU로부터 수신된 multiple-measurement-result-stats notification에 포함된 새로운 리스트에 포함된 복수의 측정 결과들을 디코딩할 수 있다. 즉, 통지 간격이 측정 간격보다 긴 경우, 멀티 측정 결과 보고 기능은 인에이블될 수 있다. 통지 간격이 측정 간격보다 길지 않은 경우, 멀티 측정 결과 보고 기능은 디세이블될 수 있다.
방법 a, 방법 b, 및/또는 방법 d에서, 하나의 측정 결과를 포함하는 기존 leaf들은 전송될 수 있다. 따라서 기존 O-DU는 기존 leaf들을 디코딩할 수 있으므로, 하위 호환성 문제는 발생하지 않을 수 있다. 하나의 측정 결과가 존재하는 경우, 기존 measurement-result-stats notification는 사용될 수 있다. 이 경우, 기존 O-DU 및 새로운 O-DU 모두는 측정 결과를 디코딩할 수 있다. 복수의 측정 결과들이 존재하는 경우, 기존 measurement-result-stats notification 및 새로운 multiple-measurement-result-stats notification 이 모두 전송될 수 있다. 이 경우, 기존 O-DU는 기존 measurement-result-stats notification를 수신함으로써 하나의 측정 결과를 획득할 수 있고, 새로운 O-DU는 새로운 multiple-measurement-result-stats notification를 수신함으로써 복수의 측정 결과들을 획득할 수 있다.
방법 d에서 하나의 측정 결과가 존재하는 경우에도, 하나의 측정 결과를 포함하는 기존 measurement-result-stats notification 및 하나의 측정 결과를 포함하는 새로운 multiple-measurement-result-stats notification는 모두 전송될 수 있다. 즉, 동일한 측정 결과는 기존 measurement-result-stats notification 및 새로운 multiple-measurement-result-stats notification에 포함될 수 있다.
상술한 방법(들)을 위한 수정된 YANG 코드는 다음과 같이 정의될 수 있다.
grouping multiple-measurement-notification {
description
"notification may contain multiple-measurement result for transceiver-stats and/or rx-window-stats and/or tx-stats and/or epe-stats";
list multiple-transceiver-stats {
key "measurement-object";
description
"multiple measurement result of transceiver-measurement per measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/transceiver-measurement-objects/measurement-object";
}
description
"measurement-object for the transceiver-measurement";
}
list additional-transceiver-measurement-result {
config false;
description
"additional measurement result of transceiver-measurement
when notification-interval is larger than measurement-interval";
uses start-and-end-time;
uses transceiver-measurement-result-grouping;
}
}
list multiple-rx-window-stats {
key "measurement-object";
description
"multiple measurement result for the reception window measurement per measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/rx-window-measurement-objects/measurement-object";
}
description
"measurement-object for the reception window measurement";
}
list additional-rx-window-measurement-result {
config false;
description
"additional measurement result of rx-window-measurement
when notification-interval is larger than measurement-interval";
uses start-and-end-time;
uses rx-window-measurement-result-grouping;
}
}
list multiple-tx-stats {
key "measurement-object";
description
"multiple measurement result for the tx stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/tx-measurement-objects/measurement-object";
}
description
"measurement-object for the tx stats measurement";
}
list additional-tx-measurement-result {
config false;
description
"additional measurement result of tx-measurement
when notification-interval is larger than measurement-interval";
uses start-and-end-time;
uses tx-measurement-result-grouping;
}
}
list multiple-epe-statistics {
key "measurement-object";
description
"measurement result for the epe stats measurement per
measurement-object";
leaf measurement-object {
type leafref {
path "/performance-measurement-objects/epe-measurement-objects/measurement-object";
}
description
"measurement-object for the epe stats measurement";
}
list additional-epe-measurement-result {
config false;
description
"additional measurement result of epe-measurement
when notification-interval is larger than measurement-interval";
uses start-and-end-time;
uses epe-measurement-result-grouping;
}
}
}
// Top level container
container performance-measurement-objects {
description
"configuration for performance management and measurement-result are included";
uses measurement-group;
}
// Notifications
notification measurement-result-stats {
description
"Notification may contain measurement results for transceiver-stats and/or rx-window-stats";
uses measurement-notification;
}
notification multiple-measurement-result-stats {
description
"Notification may contain multiple measurement results for transceiver-stats and/or rx-window-stats";
uses multiple-measurement-notification;
}
}
상술한 방법에 의하면, 기존 장비(예를 들어, O-DU, O-RU)와의 하위 호환성 문제는 발생하지 않을 수 있다. 하나의 NETCONF 통지의 전송 절차에서, 측정 대상 별 복수의 측정 결과들은 전송될 수 있다. 따라서 O-RAN M-Plane의 성능은 향상될 수 있다.
본 발명에 따른 방법들은 다양한 컴퓨터 수단을 통해 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위해 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.
컴퓨터 판독 가능 매체의 예에는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함한다. 상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 적어도 하나의 소프트웨어 모듈로 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (20)

  1. O-RAN(open-radio access network)에서 O-RU(O-RAN radio unit)의 동작 방법으로서,
    통지 간격(notification interval)에 따른 하나의 통지 구간에서 제1 측정 대상에 대한 측정 동작을 수행함으로써 복수의 제1 측정 결과들을 생성하는 단계;
    상기 복수의 제1 측정 결과들을 포함하는 제1 측정 결과 리스트를 생성하는 단계; 및
    상기 제1 측정 결과 리스트를 포함하는 메시지를 O-DU(O-RAN distributed unit)에 전송하는 단계를 포함하는, O-RU의 동작 방법.
  2. 청구항 1에 있어서,
    상기 O-RU의 동작 방법은,
    상기 복수의 제1 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 제1 통지를 생성하는 단계를 더 포함하며,
    상기 메시지는 제1 통지를 더 포함하는, O-RU의 동작 방법.
  3. 청구항 2에 있어서,
    상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩되고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 상기 O-DU에서 디코딩되는, O-RU의 동작 방법.
  4. 청구항 1에 있어서,
    상기 O-RU의 동작 방법은,
    상기 하나의 통지 구간에서 제2 측정 대상에 대한 측정 동작을 수행함으로써 복수의 제2 측정 결과들을 생성하는 단계; 및
    상기 복수의 제2 측정 결과들을 포함하는 제2 측정 결과 리스트를 생성하는 단계를 더 포함하며,
    상기 메시지는 상기 제2 측정 결과 리스트를 더 포함하는, O-RU의 동작 방법.
  5. 청구항 1에 있어서,
    상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들 각각에 대한 측정 시작 시간 정보 및 측정 종료 시간 정보를 더 포함하는, O-RU의 동작 방법.
  6. 청구항 1에 있어서,
    상기 복수의 제1 측정 결과들은 상기 제1 측정 결과 리스트 내에서 측정 시간의 오름차순으로 정렬되는, O-RU의 동작 방법.
  7. 청구항 1에 있어서,
    상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들의 개수를 지시하는 정보 및 상기 복수의 제1 측정 결과들 각각의 시퀀스 번호(sequence number) 중에서 적어도 하나를 더 포함하는, O-RU의 동작 방법.
  8. 청구항 1에 있어서,
    상기 통지 간격은 하나의 측정 동작이 수행되는 측정 간격보다 길도록 상기 O-DU에 의해 설정되는, O-RU의 동작 방법.
  9. 청구항 1에 있어서,
    상기 제1 측정 대상은 트랜시버(transceiver), 수신 윈도우(rx-window), 전송 측정(tx-measurement), EPE(energy, power, environmental), 또는 심볼 RSSI(received signal strength indicator)인, O-RU의 동작 방법.
  10. O-RAN(open-radio access network)에서 O-RU(O-RAN radio unit)의 동작 방법으로서,
    통지 간격(notification interval)에 따른 하나의 통지 구간에서 제1 측정 대상에 대한 측정 동작을 수행함으로써 제1 측정 결과를 생성하는 단계;
    상기 제1 측정 결과를 포함하는 제1 통지(notification)를 생성하는 단계;
    상기 제1 측정 결과를 포함하는 제1 측정 결과 리스트를 생성하는 단계; 및
    상기 제1 통지 및 상기 제1 측정 결과 리스트를 포함하는 메시지를 O-DU(O-RAN distributed unit)에 전송하는 단계를 포함하는, O-RU의 동작 방법.
  11. 청구항 10에 있어서,
    상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩되고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 상기 O-DU에서 디코딩되는, O-RU의 동작 방법.
  12. 청구항 10에 있어서,
    상기 통지 간격은 하나의 측정 동작이 수행되는 측정 간격과 동일하도록 상기 O-DU에 의해 설정되는, O-RU의 동작 방법.
  13. 청구항 10에 있어서,
    상기 O-RU의 동작 방법은,
    상기 하나의 통지 구간에서 제2 측정 대상에 대한 측정 동작을 수행함으로써 제2 측정 결과를 생성하는 단계;
    상기 제2 측정 결과를 포함하는 제2 통지(notification)를 생성하는 단계; 및
    상기 제2 측정 결과를 포함하는 제2 측정 결과 리스트를 생성하는 단계를 더 포함하며,
    상기 메시지는 상기 제2 통지 및 상기 제2 측정 결과 리스트를 더 포함하는, O-RU의 동작 방법.
  14. O-RAN(open-radio access network)에서 O-DU(O-RAN distributed unit)의 동작 방법으로서,
    O-RU(O-RAN radio unit)를 위한 통지 간격(notification interval) 및 측정 간격을 설정하는 단계;
    제1 측정 대상에 대한 복수의 제1 측정 결과들을 포함하는 제1 측정 결과 리스트를 포함하는 메시지를 상기 O-RU로부터 수신하는 단계; 및
    상기 제1 측정 결과 리스트를 디코딩함으로써 상기 복수의 제1 측정 결과들을 확인하는 단계를 포함하며,
    상기 복수의 제1 측정 결과들은 상기 통지 간격에 따른 하나의 통지 구간에서 측정되는, O-DU의 동작 방법.
  15. 청구항 14에 있어서,
    상기 메시지는 상기 복수의 제1 측정 결과들 중에서 가장 최신의 측정 결과를 포함하는 제1 통지를 더 포함하는, O-DU의 동작 방법.
  16. 청구항 15에 있어서,
    상기 제1 측정 결과 리스트는 상기 O-RAN의 특정 버전 이후의 버전을 지원하는 상기 O-DU에서 디코딩되고, 상기 제1 통지는 상기 특정 버전 이전의 버전을 지원하는 다른 O-DU에서 디코딩되는, O-DU의 동작 방법.
  17. 청구항 14에 있어서,
    상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들 각각에 대한 측정 시작 시간 정보 및 측정 종료 시간 정보를 더 포함하는, O-DU의 동작 방법.
  18. 청구항 14에 있어서,
    상기 복수의 제1 측정 결과들은 상기 제1 측정 결과 리스트 내에서 측정 시간의 오름차순으로 정렬되는, O-DU의 동작 방법.
  19. 청구항 14에 있어서,
    상기 제1 측정 결과 리스트는 상기 복수의 제1 측정 결과들의 개수를 지시하는 정보 및 상기 복수의 제1 측정 결과들 각각의 시퀀스 번호(sequence number) 중에서 적어도 하나를 더 포함하는, O-DU의 동작 방법.
  20. 청구항 14에 있어서,
    상기 제1 측정 대상은 트랜시버(transceiver), 수신 윈도우(rx-window), 전송 측정(tx-measurement), EPE(energy, power, environmental), 또는 심볼 RSSI(received signal strength indicator)인, O-DU의 동작 방법.
PCT/KR2021/017105 2020-11-20 2021-11-19 프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치 Ceased WO2022108393A1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202180078369.2A CN116530135A (zh) 2020-11-20 2021-11-19 使用前传接口进行通信的方法和装置
JP2023530029A JP7528372B2 (ja) 2020-11-20 2021-11-19 フロントホールインターフェースを使う通信のための方法および装置
US18/036,534 US12556949B2 (en) 2020-11-20 2021-11-19 Method and device for communication using fronthaul interface
EP21895160.6A EP4250799A4 (en) 2020-11-20 2021-11-19 METHOD AND DEVICE FOR COMMUNICATION USING A FRONTHAUL INTERFACE
JP2024118565A JP7766754B2 (ja) 2020-11-20 2024-07-24 フロントホールインターフェースを使う通信のための方法および装置

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
KR20200156851 2020-11-20
KR10-2020-0156851 2020-11-20
KR10-2021-0070213 2021-05-31
KR20210070213 2021-05-31
KR20210081163 2021-06-22
KR10-2021-0081163 2021-06-22
KR10-2021-0083430 2021-06-25
KR20210083430 2021-06-25
KR1020210160299A KR20220069857A (ko) 2020-11-20 2021-11-19 프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치
KR10-2021-0160299 2021-11-19

Publications (1)

Publication Number Publication Date
WO2022108393A1 true WO2022108393A1 (ko) 2022-05-27

Family

ID=81709449

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/017105 Ceased WO2022108393A1 (ko) 2020-11-20 2021-11-19 프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치

Country Status (3)

Country Link
US (1) US12556949B2 (ko)
JP (2) JP7528372B2 (ko)
WO (1) WO2022108393A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116261159A (zh) * 2023-02-10 2023-06-13 南京濠暻通讯科技有限公司 一种基于5g开放式接入网中netconf协议实现性能管理的方法
WO2024099028A1 (zh) * 2022-11-09 2024-05-16 大唐移动通信设备有限公司 多节点协同控制方法、设备、装置及存储介质
WO2024136611A1 (ko) * 2022-12-23 2024-06-27 한국전자통신연구원 무선 통신 시스템에서 기능 분할 옵션 7-2 기반 프론트홀 인터페이스 방법 및 장치

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120111684A (zh) * 2024-08-16 2025-06-06 中兴通讯股份有限公司 通信方法、装置、存储介质及程序产品
WO2026078770A1 (ja) * 2024-10-08 2026-04-16 株式会社Ｎｔｔドコモ 基地局

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109587722A (zh) * 2017-09-28 2019-04-05 中兴通讯股份有限公司 一种数据传输方法和数据传输装置
US20200077287A1 (en) * 2018-08-29 2020-03-05 Nokia Technologies Oy Apparatus, method and computer program
US20200351688A1 (en) * 2016-02-08 2020-11-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods for Quality- Aware Reporting of RSSI-Based Measurements to Avoid RSSI Window Split

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2017094299A1 (ja) 2015-11-30 2018-09-13 株式会社Ｎｔｔドコモ 基地局及びタイミング制御方法
EP3448080B1 (en) 2016-04-21 2020-09-30 NTT DoCoMo, Inc. Radio unit and interference level report method
KR102100491B1 (ko) 2016-07-13 2020-04-14 주식회사 케이티 프론트홀 인터페이스를 이용한 중앙 유닛 구성 방법 및 그 장치
DE112018003906T5 (de) 2017-07-31 2020-09-03 Mavenir Networks, Inc. Verfahren und Vorrichtung zur flexiblen Aufteilung der physikalischen Fronthaul-Schicht für Cloud-Funkzugangsnetze
US10631346B2 (en) 2017-08-08 2020-04-21 Qualcomm Incorporated Communicating remote and local data in a wireless fronthaul
CN113923799B (zh) 2018-02-14 2025-05-06 华为技术有限公司 一种无线回传通信处理方法和相关设备
US10833736B2 (en) 2018-11-23 2020-11-10 Electronics And Telecommunications Research Institute Hybrid beamforming method for beam-based cooperative transmission, and apparatus for the same
US11038559B2 (en) 2018-11-29 2021-06-15 Electronics And Telecommunications Research Institute Method and apparatus for transmitting and receiving signal based on beamforming in communication system
US20220201796A1 (en) 2019-04-22 2022-06-23 Nec Corporation Communication apparatus, controller, system, and method
WO2020247129A1 (en) 2019-06-06 2020-12-10 Commscope Technologies Llc Distributed radio access network implementing fronthaul operational measurements
CN114884635B (zh) 2019-07-02 2023-12-19 康普技术有限责任公司 与云无线电接入网络一起使用的前传接口
US12309628B2 (en) * 2019-11-06 2025-05-20 Lg Electronics Inc. Method and apparatus for performing measurements in NR V2X
CN114731595B (zh) * 2019-11-07 2024-09-10 株式会社Ntt都科摩 通信装置
KR102942661B1 (ko) * 2020-01-17 2026-03-24 가부시키가이샤 엔티티 도코모 관리 노드, 분산 유닛, 무선 통신 시스템 및 무선 통신 방법
US12279156B2 (en) * 2020-06-03 2025-04-15 Mavenir Systems, Inc. Traffic timing control for an open radio access network in a cloud radio access network system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200351688A1 (en) * 2016-02-08 2020-11-05 Telefonaktiebolaget Lm Ericsson (Publ) Methods for Quality- Aware Reporting of RSSI-Based Measurements to Avoid RSSI Window Split
CN109587722A (zh) * 2017-09-28 2019-04-05 中兴通讯股份有限公司 一种数据传输方法和数据传输装置
US20200077287A1 (en) * 2018-08-29 2020-03-05 Nokia Technologies Oy Apparatus, method and computer program

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; F1 application protocol (F1AP) (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 38.473, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. V16.3.1, 15 October 2020 (2020-10-15), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 455, XP051961467 *
HUAWEI: "Clarification to 38.473 on measurement gap deactivation over F1AP (Rel-16)", 3GPP DRAFT; R3-205277, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. E-Meeting; 20200817 - 20200828, 7 August 2020 (2020-08-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051915943 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024099028A1 (zh) * 2022-11-09 2024-05-16 大唐移动通信设备有限公司 多节点协同控制方法、设备、装置及存储介质
WO2024136611A1 (ko) * 2022-12-23 2024-06-27 한국전자통신연구원 무선 통신 시스템에서 기능 분할 옵션 7-2 기반 프론트홀 인터페이스 방법 및 장치
CN116261159A (zh) * 2023-02-10 2023-06-13 南京濠暻通讯科技有限公司 一种基于5g开放式接入网中netconf协议实现性能管理的方法

Also Published As

Publication number Publication date
JP7766754B2 (ja) 2025-11-10
US12556949B2 (en) 2026-02-17
JP2024147777A (ja) 2024-10-16
US20240015539A1 (en) 2024-01-11
JP7528372B2 (ja) 2024-08-05
JP2023550103A (ja) 2023-11-30

Similar Documents

Publication Publication Date Title
WO2022108393A1 (ko) 프론트홀 인터페이스를 사용하는 통신을 위한 방법 및 장치
WO2020122676A1 (en) Apparatus and method for initial access in wireless communication system
WO2021150014A1 (en) Self-optimization method and device
WO2019107873A1 (en) Method for reporting channel state information in wireless communication system and apparatus for the same
WO2018203736A1 (en) System, data transmission method and network equipment supporting pdcp duplication function method and device for transferring supplementary uplink carrier configuration information and method and device for performing connection mobility adjustment
WO2021060941A1 (en) Method and apparatus for handover
EP3649803A1 (en) Method and user equipment (ue) for beam management framework for carrier aggregation
WO2017026764A1 (ko) 무선 통신 시스템에서 비연속 수신 모드를 적용하는 방법 및 장치
WO2010098601A2 (en) Femto access point in a communication system and control method thereof
EP3479647A1 (en) Method for establishing a fronthaul interface, method for performing access for a ue, method and apparatus for performing a handover for a ue, data forwarding method, user equipment and base station
WO2018203739A1 (en) Method for establishing a fronthaul interface, method for performing access for a ue, method and apparatus for performing a handover for a ue, data forwarding method, user equipment and base station
WO2020197360A1 (en) Method and device for remote interference management in wireless communication system
EP3403433A1 (en) Method and apparatus for generating cell measurement information in a wireless communication system
WO2014094195A1 (zh) 一种载波的分配方法、用户设备及基站
WO2012118348A2 (ko) 통신시스템에서 릴레이 제어장치 및 방법
WO2020067715A1 (en) Method and device for configuring node to transmit and receive data
WO2023068711A1 (en) Method and device for performing self-optimization and self-configuration
WO2017123078A1 (en) Method and apparatus for generating cell measurement information in a wireless communication system
WO2019031856A1 (ko) 무선 통신 시스템에서 참조 신호를 송수신하기 위한 방법 및 이를 위한 장치
WO2021215626A1 (en) Method, user equipment and base station for link failure reporting
WO2022015109A1 (en) Method and node for communication in communication system supporting integrated access and backhaul (iab)
EP3616434A1 (en) System, data transmission method and network equipment supporting pdcp duplication function method and device for transferring supplementary uplink carrier configuration information and method and device for performing connection mobility adjustment
WO2017135668A1 (en) Method and user equipment for transmitting and receiving signals
WO2020122621A1 (ko) 무선 통신 시스템에서 다중 주파수 부분대역을 활용한 측정 방법 및 장치
WO2024253336A1 (en) Method and node for delay management in communication system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21895160

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18036534

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2023530029

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 202317034809

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 202180078369.2

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021895160

Country of ref document: EP

Effective date: 20230620

WWG Wipo information: grant in national office

Ref document number: 18036534

Country of ref document: US