Method and apparatus for collecting data for o-ran-based ai-ran in communication system

Abstract

The present disclosure relates to a 6G communication system comprising a method comprising the steps of: receiving information about at least one indicator for training an artificial intelligence (AI) model; identifying one or more pieces of data for training the AI model, on the basis of the information about the at least one indicator for training the AI model; receiving, from service management and orchestration (SMO), a request for at least one of the identified one or more pieces of data; and transmitting, to the SMO, the at least one of the identified one or more pieces of data, on the basis of the request.

Description

Data collection method and apparatus for O-RAN-based AI-RAN of a communication system

[0001] The present disclosure relates to a method and apparatus for supporting AI-RAN in a communication system. More specifically, it relates to signaling and related interfaces required for data collection to support AI, etc. in an O-RAN structure.

[0002] Efforts are being made to develop 5G (5th generation) communication systems or pre-5G communication systems to meet the increasing demand for wireless data traffic following the commercialization of 4G (4th generation) communication systems. For this reason, 5G communication systems or pre-5G communication systems are referred to as Beyond 4G Network communication systems or Post-LTE systems.

[0003] To achieve high data transmission rates, 5G communication systems are being considered for implementation in the mmWave band (e.g., the 60 GHz band). To mitigate path loss and increase the transmission distance of radio waves in the mmWave band, beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large-scale antenna technologies are being discussed for 5G communication systems. In addition, to improve the network of the system, technologies such as advanced small cell, advanced small cell, cloud Radio Access Network (cloud RAN), ultra-dense network, Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation are being developed in 5G communication systems.In addition, advanced coding modulation (ACM) methods such as FQAM (hybrid FSK and QAM modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (Non-Orthogonal Multiple Access), and SCMA (Sparse Code Multiple Access) are being developed in 5G systems.

[0004] Meanwhile, since 5G communication systems must be able to freely reflect the diverse requirements of users and service providers, services that satisfy various requirements simultaneously must be supported. Services being considered for 5G communication systems include enhanced Mobile BroadBand (eMBB), massive Machine Type Communication (mMTC), and Ultra-Reliable Low-Latency Communication (URLLC).

[0005] eMBB aims to provide data transmission speeds that are superior to those supported by existing LTE, LTE-A, or LTE-Pro. For example, in a 5G communication system, eMBB must be able to provide a peak data rate of 20 Gbps in the downlink and 10 Gbps in the uplink from the perspective of a single base station. Furthermore, while providing these peak data rates, the 5G communication system must also provide an increased user-perceived data rate. To satisfy these requirements, improvements in various transmission and reception technologies are required, including enhanced multi-antenna transmission technology. Additionally, while current LTE transmits signals using a maximum bandwidth of 20 MHz in the 2 GHz band, 5G communication systems can meet the data transmission speeds required by using a frequency bandwidth wider than 20 MHz in frequency bands of 3–6 GHz or above 6 GHz.

[0006] At the same time, mMTC is being considered to support application services such as the Internet of Things (IoT) in 5G communication systems. To efficiently provide IoT, mMTC requires support for the connection of a large number of terminals within a cell, improved terminal coverage, enhanced battery life, and reduced terminal costs. Since IoT provides communication functions by attaching to various sensors and devices, a large number of terminals within a cell (e.g., 1,000,000 terminals / km²) 2It must be able to support mMTC. In addition, terminals supporting mMTC require wider coverage compared to other services provided by the 5G communication system, as they are likely to be located in dead zones where cells cannot cover, such as building basements, due to the nature of the service. Terminals supporting mMTC must consist of low-cost devices, and since it is difficult to frequently replace the device's battery, a very long battery life of 10 to 15 years is required.

[0007] Finally, URLLC is a mission-critical cellular-based wireless communication service. For example, consider services used for remote control of robots or machinery, industrial automation, Unmanned Aerial Vehicles (UAVs), remote health care, and emergency alerts. Therefore, the communication provided by URLLC must offer very low latency and very high reliability. For instance, services supporting URLLC must satisfy air interface latency of less than 0.5 milliseconds, and simultaneously 10 -5 The following packet error rate requirements apply. Therefore, for services supporting URLLC, 5G communication systems must provide a Transmit Time Interval (TTI) smaller than other services, and at the same time, design specifications are required to allocate a wide resource in the frequency band to ensure the reliability of the communication link.

[0008] Meanwhile, the Internet is evolving from a human-centric network where humans generate and consume information into an IoT network that processes information by exchanging it among distributed components, such as objects. Internet of Everything (IoE) technology, which combines IoT with big data processing technologies via connections with cloud servers, is also emerging. To implement IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required; consequently, technologies such as sensor networks, Machine-to-Machine (M2M) communication, and MTC are currently being researched to facilitate the connection of objects. In an IoT environment, intelligent IoT services can be provided that create new value for human life by collecting and analyzing data generated from connected objects. Through the convergence and integration of existing Information Technology (IT) with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0009] Looking back at the evolution of wireless communication through successive generations, technologies have been developed primarily for human-oriented services, such as voice, multimedia, and data. Following the commercialization of 5G (5th-generation) communication systems, connected devices, which have been increasing explosively, are expected to be connected to communication networks. Examples of networked objects include vehicles, robots, drones, home appliances, displays, smart sensors installed in various infrastructures, construction machinery, and factory equipment. Mobile devices are expected to evolve into various form factors, such as augmented reality glasses, virtual reality headsets, and holographic devices. In the 6G (6th-generation) era, efforts are underway to develop improved 6G communication systems to connect hundreds of billions of devices and objects to provide diverse services. For this reason, 6G communication systems are being referred to as "beyond 5G" systems.

[0010] In the 6G communication system predicted to be realized around 2030, the maximum transmission speed is tera (i.e., 1,000 gigabit) bps, and the wireless latency is 100 microseconds (μsec). In other words, compared to the 5G communication system, the transmission speed in the 6G communication system is 50 times faster, and the wireless latency is reduced to one-tenth.

[0011] To achieve such high data transmission speeds and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz band (e.g., the 95 GHz to 3 terahertz (3 THz) band). In the terahertz band, due to more severe path loss and atmospheric absorption compared to the millimeter wave (mmWave) band introduced in 5G, the importance of technology capable of guaranteeing signal reach, or coverage, is expected to increase. As key technologies to ensure coverage, radio frequency (RF) devices, antennas, new waveforms that offer better coverage than orthogonal frequency division multiplexing (OFDM), beamforming, and multi-antenna transmission technologies such as massive multiple-input and multiple-output (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas must be developed. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing technology using orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS) are being discussed to improve coverage of terahertz band signals.

[0012] In addition, to improve frequency efficiency and system network, development is underway in 6G communication systems for full duplex technology, in which uplink and downlink simultaneously utilize the same frequency resources at the same time; network technology that integrates satellites and HAPS (high-altitude platform stations); network structure innovation technology that supports mobile base stations and enables network operation optimization and automation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes AI (artificial intelligence) from the design stage and internalizes end-to-end AI support functions to realize system optimization; and next-generation distributed computing technology that realizes services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high performance communication and computing resources (mobile edge computing (MEC), cloud, etc.). In addition, attempts are continuing to further strengthen connectivity between devices, further optimize networks, promote the softwareization of network entities, and increase the openness of wireless communication through the design of new protocols to be used in 6G communication systems, the implementation of hardware-based security environments, the development of mechanisms for the safe utilization of data, and the development of technologies regarding privacy maintenance methods.

[0013] Due to the research and development of such 6G communication systems, it is expected that a new dimension of hyper-connected experience will become possible through the hyper-connectivity of 6G communication systems, which encompasses not only connections between objects but also connections between people and objects. Specifically, it is projected that 6G communication systems will enable the provision of services such as truly immersive extended reality (truly immersive XR), high-fidelity mobile holograms, and digital replicas. Furthermore, services such as remote surgery, industrial automation, and emergency response, which are provided through 6G communication systems with enhanced security and reliability, will be applied in various fields including industry, healthcare, automotive, and home appliances.

[0014] In an O-RAN structure, if an SMO receives KPIs from an O-DU and raw data from an O-RU to perform KPI labeling, fronthaul overhead may increase. The present disclosure aims to provide a method and apparatus to address this.

[0015] The technical problems to be solved by the present invention are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which the present invention belongs from the description below.

[0016] A method performed by an O-RU (open radio unit) of a communication system according to one embodiment of the present invention comprises: receiving information regarding at least one indicator for learning an AI (artificial intelligence) model; identifying one or more data for learning the AI ​​model based on the information regarding the at least one indicator for learning the AI ​​model; receiving a request from a SMO (service management and orchestration) for at least one of the identified one or more data; and transmitting at least one of the identified one or more data to the SMO based on the request.

[0017] In addition, the method is characterized by including the steps of: receiving setting information for collecting the data from the SMO; applying the setting information; and transmitting information related to the result of applying the setting information to the SMO.

[0018] In addition, it is characterized by including the step of transmitting all or part of the above configuration information to an O-DU (open distributed unit).

[0019] Additionally, the method is characterized by including the step of receiving a request for all or part of the configuration information from an O-DU (open distributed unit); and the step of transmitting all or part of the configuration information to the O-DU.

[0020] In addition, information regarding at least one metric for training the AI ​​model is characterized by being received from the SMO or O-DU (open distributed unit) based on the M (management)-plane or C (control)-plane.

[0021] In addition, the above O-RU is characterized by transmitting or receiving a signal to the above SMO based on the M(management)-plane.

[0022] Additionally, the step of identifying one or more data for training the AI ​​model is characterized by including the step of labeling one or more data collected by the O-RU based on information regarding at least one indicator for training the AI ​​model.

[0023] A method performed by the service management and orchestration (SMO) of a communication system according to one embodiment of the present invention comprises: a step of transmitting a request for at least one of data for learning an artificial intelligence (AI) model to an open radio unit (O-RU); and a step of receiving at least one of one or more of data for learning the AI ​​model from the O-RU, wherein the one or more of the data for learning the AI ​​model is identified based on information regarding at least one indicator for learning the AI ​​model.

[0024] An open radio unit (O-RU) of a communication system according to one embodiment of the present invention comprises: a transceiver; and a control unit connected to the transceiver, receiving information regarding at least one indicator for learning an artificial intelligence (AI) model, identifying one or more data for learning the AI ​​model based on the information regarding the at least one indicator for learning the AI ​​model, receiving a request from a service management and orchestration (SMO) for at least one of the identified data, and transmitting at least one of the identified data to the SMO based on the request.

[0025] In a service management and orchestration (SMO) of a communication system according to one embodiment of the present invention, the system comprises: a transceiver; and a control unit connected to the transceiver, which transmits a request for at least one of data for learning an artificial intelligence (AI) model to an open radio unit (O-RU), and receives at least one of one or more of the data for learning the AI ​​model from the O-RU.

[0026] The one or more data for training the AI ​​model are characterized by being identified based on information regarding at least one indicator for training the AI ​​model.

[0027] According to one embodiment of the present disclosure, through selective data collection, efficient AI-related learning can be performed by learning according to AI-related use cases, privacy and security issues between O-DU and O-RU can be resolved, and furthermore, fronthaul overhead can be efficiently managed. In addition, optimized AI learning can be performed through one embodiment.

[0028] The effects obtainable from the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0029] FIG. 1 is a diagram illustrating the wireless protocol structure of a base station and a terminal in a single cell, carrier aggregation, dual connectivity situation in a wireless communication system according to one embodiment.

[0030] FIG. 2 is a diagram illustrating a part of an O-RAN architecture structure according to one embodiment.

[0031] FIG. 3 is a drawing illustrating two models in relation to the architecture of an M-plane according to one embodiment.

[0032] FIG. 4 is a diagram illustrating lifecycle management (LCM) in O-RAN according to one embodiment.

[0033] FIG. 5 is a diagram illustrating a process for transmitting data and KPIs for AI model training according to one embodiment.

[0034] FIG. 6 is a diagram illustrating the process of performing KPI labeling and transmitting data in an O-RU according to one embodiment.

[0035] FIG. 7 is a diagram illustrating signaling for setting information for data collection according to one embodiment.

[0036] FIG. 8 is a diagram illustrating signaling for data collection setting information according to one embodiment.

[0037] FIG. 9 is a diagram illustrating signaling of information regarding KPIs according to one embodiment.

[0038] FIG. 10 is a diagram illustrating signaling of information regarding KPIs according to one embodiment.

[0039] FIG. 11 shows an example of a method in which an O-RU requests information about a KPI according to one embodiment.

[0040] FIG. 12 is a diagram illustrating signaling in which an O-RU transmits data to an SMO according to one embodiment.

[0041] FIG. 13 is a diagram illustrating signaling in which an O-RU transmits data to an SMO according to one embodiment.

[0042] FIG. 14 is a diagram illustrating signaling in which an O-RU transmits data to an SMO according to one embodiment.

[0043] FIG. 15 is a diagram illustrating the operation of an O-RU for performing KPI labeling and transmitting data according to one embodiment.

[0044] FIG. 16 is a diagram illustrating the operation of an O-DU for transmitting KPI information according to one embodiment.

[0045] FIG. 17 is a diagram illustrating the operation of an SMO that receives data according to an embodiment and performs AI learning.

[0046] FIG. 18 is a drawing illustrating the structure of a terminal in a communication system according to one embodiment.

[0047] FIG. 19 is a drawing illustrating the structure of a base station in a communication system according to one embodiment.

[0048] Embodiments of the present disclosure will be described in detail below with reference to the attached drawings.

[0049] In describing the embodiments, descriptions of technical details that are well known in the technical field to which this disclosure belongs and are not directly related to this disclosure are omitted.

[0050] This is intended to convey the gist of the present disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0051] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the dimensions of each component do not entirely reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference number.

[0052] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings.

[0053] However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to complete the configuration of the present disclosure and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0054] At this time, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory oriented toward the computer or other programmable data processing equipment to be implemented in a specific manner, the instructions stored in such computer-available or computer-readable memory can also produce a manufactured item containing means of instruction to perform the functions described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0055] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to their corresponding functions.

[0056] In this embodiment, the term "part" refers to a software or hardware component such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium and may be configured to run one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and '~parts' can be implemented to play one or more CPUs (central processing units) within the device or secure multimedia card.

[0057] For the convenience of the following description, some terms and names defined in 3GPP (3rd generation partnership project) standards (specifications for 5G, NR, LTE, or similar systems) may be used. Additionally, terms and names newly defined in next-generation communication systems to which this disclosure applies (e.g., 6G, Beyond 5G systems) or used in existing communication systems may be used. The use of such terms is not limited to the terms and names of this disclosure and may be applied equally to systems conforming to other standards, and may be modified in other forms within the scope of the technical spirit of this disclosure. Embodiments of this disclosure can be easily modified and applied to other communication systems.

[0058] In addition, it will be understood that singular expressions such as "one" and "the above" in one embodiment of the present disclosure, unless otherwise explicitly indicated, include plural expressions.

[0059] In addition, in one embodiment of the present disclosure, the size in relation to blocks, etc., may be expressed as length or size.

[0060] Additionally, in one embodiment of the present disclosure, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but said components are not limited by said terms. Such terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, the first component may be named the second component, and similarly, the second component may be named the first component.

[0061] Additionally, in one embodiment of the present disclosure, the term “and / or” includes a combination of a plurality of related described items or any of a plurality of related described items.

[0062] Furthermore, the terms used in the embodiments of the present disclosure are used merely to describe specific embodiments and are not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this specification, terms such as “comprising” or “having” are intended to indicate the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0063] Additionally, the terms “associated with” and “associated therewith” and their derivatives used in one embodiment of the present disclosure may mean things such as include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicated with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, etc.

[0064] Additionally, in this disclosure, expressions such as "greater than" or "less than" have been used to determine whether specific conditions are satisfied or fulfilled; however, this is merely for illustrative purposes and does not exclude descriptions of "greater than" or "less than." Conditions described as "greater than" may be replaced with "greater than," conditions described as "less than" with "less than," and conditions described as "greater than and less than" with "greater than and less than."

[0065] Additionally, in this disclosure, embodiments are described using terms used in some communication standards (e.g., LTE (long term evolution), NR (new radio) as defined by 3GPP (3rd generation partnership project)), but this is merely for illustrative purposes. The embodiments of this disclosure can be easily modified and applied to other communication systems.

[0066] Prior to a detailed description of the present disclosure, examples of possible meanings for some terms used in this specification are provided. However, it should be noted that the interpretations provided below are not limited to these examples.

[0067] In the present disclosure, a terminal (or communication terminal) is a subject that communicates with a base station or another terminal and may be referred to as a node, UE (user equipment), NG UE (next generation UE), MS (mobile station), device, or terminal. Additionally, the terminal may include at least one of a smartphone, tablet PC, mobile phone, video phone, e-book reader, desktop PC, laptop PC, netbook computer, PDA, PMP (portable multimedia player), MP3 player, medical device, camera, or wearable device. Additionally, the terminal may include at least one of a television, DVD (digital video disk) player, audio, refrigerator, air conditioner, vacuum cleaner, oven, microwave, washing machine, air purifier, set-top box, home automation control panel, security control panel, media box, game console, electronic dictionary, electronic key, camcorder, or electronic photo frame.In addition, the terminal may include at least one of various medical devices (e.g., various portable medical measuring devices (blood glucose meter, heart rate monitor, blood pressure monitor, or body temperature monitor, etc.), MRA (magnetic resonance angiography), MRI (magnetic resonance imaging), CT (computed tomography), imaging device, or ultrasound device, etc.), navigation device, satellite navigation system (GNSS (global navigation satellite system)), EDR (event data recorder), FDR (flight data recorder), automotive infotainment device, marine electronic equipment (e.g., marine navigation device, gyrocompass, etc.), avionics, security device, vehicle head unit, industrial or household robot, drone, ATM of a financial institution, POS (point of sales) of a store, or Internet of Things device (e.g., light bulb, various sensor, sprinkler device, fire alarm, thermostat, street light, toaster, exercise equipment, hot water tank, heater, boiler, etc.). In addition, the terminal may include various types of multimedia systems capable of performing communication functions. Meanwhile, the present disclosure is not limited to what has been described above, and the terminal may be referred to by terms having the same or similar meaning.

[0068] In addition, in the present disclosure, the base station is an entity that communicates with a terminal and performs resource allocation for the terminal, and may take various forms and may be referred to as a BS (base station), NodeB (NB), NG RAN (next generation radio access network), AP (access point), TRP (transmission reception point), radio access unit, base station controller, or node on a network. Alternatively, depending on the separation of functions, it may be referred to as a CU (central unit) or a DU (distributed unit). Meanwhile, the present disclosure is not limited thereto, and the base station may be referred to by terms having the same or similar meaning.

[0069] Additionally, in this disclosure, a radio resource control (RRC) message may be referred to as high-level information, high-level message, high-level signal, high-level signaling, high-layer signaling, or high-level signaling, and the disclosure is not limited thereto, but may be referred to by terms having the same or similar meaning.

[0070] Additionally, in the present disclosure, data may be referred to as a data set, user data, UP (user plane) data, or application data, or may be referred to by a term having the same or similar meaning as a signal transmitted or received through a DRB (data radio bearer).

[0071] Additionally, in the present disclosure, the direction of data transmitted from a terminal may be referred to as an uplink (UL), and the direction of data transmitted to a terminal may be referred to as a downlink (DL). Accordingly, in the case of uplink transmission, the transmitter may refer to a terminal, and the receiver may refer to a specific network entity of a base station or communication system. Alternatively, in the case of downlink transmission, the transmitter may refer to a specific network entity of a base station or communication system, and the receiver may refer to a terminal.

[0072] FIG. 1 is a diagram illustrating the wireless protocol structure of a base station and a terminal in a single cell, carrier aggregation, dual connectivity situation according to one embodiment.

[0073] Referring to Fig. 1, the wireless protocol of the next-generation mobile communication system consists of NR SDAP (service data adaptation protocol S25, S70), NR PDCP (packet data convergence protocol S30, S65), NR RLC (radio link control S35, S60), and NR MAC (medium access control S40, S55) at the terminal and the NR base station, respectively.

[0074] The main functions of NR SDAP (S25, S70) may include some of the following functions.

[0075] - User data transfer function (transfer of user plane data)

[0076] - Mapping function between a QoS flow and a DRB for both DL and UL for uplink and downlink

[0077] - Marking QoS flow ID for uplink and downlink (marking QoS flow ID in both DL and UL packets)

[0078] - Function to map reflective QoS flow to data bearers for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

[0079] Regarding the SDAP layer device, the terminal may receive a setting via an RRC message indicating whether to use the header of the SDAP layer device or the functions of the SDAP layer device for each PDCP layer device, bearer, or logical channel. If the SDAP header is configured, the terminal may instruct the NAS QoS reflective setting 1-bit indicator (NAS reflective QoS) and the AS QoS reflective setting 1-bit indicator (AS reflective QoS) of the SDAP header to update or reset the mapping information for the QoS flow of the uplink and downlink and the data bearer. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used for data processing priority, scheduling information, etc., to support smooth service.

[0080] The main functions of NR PDCP (S30, S65) may include some of the following functions.

[0081] - Header compression and decompression (ROHC only)

[0082] - User data transfer function (transfer of user data)

[0083] - Sequential delivery function (in-sequence delivery of upper layer PDUs)

[0084] - Out-of-sequence delivery of upper layer PDUs

[0085] - Reordering function (PDCP PDU reordering for reception)

[0086] - Duplicate detection function (duplicate detection of lower layer SDUs)

[0087] - Retransmission function (retransmission of PDCP SDUs)

[0088] - Encryption and decryption functions (ciphering and deciphering)

[0089] - Timer-based SDU discard in uplink.

[0090] In the above, the reordering function of the NR PDCP device refers to a function that reorders PDCP PDUs received from a lower layer in order based on the PDCP SN (sequence number), and may include a function that transmits data to an upper layer in the reordered order. Alternatively, the reordering function of the NR PDCP device may include a function that transmits immediately without considering the order, a function that records lost PDCP PDUs by reordering, a function that reports the status of lost PDCP PDUs to the transmitting side, and a function that requests retransmission of lost PDCP PDUs.

[0091] The main functions of NR RLC(S35, S60) may include some of the following functions.

[0092] - Data transfer function (transfer of upper layer PDUs)

[0093] - Sequential delivery function (in-sequence delivery of upper layer PDUs)

[0094] - Out-of-sequence delivery of upper layer PDUs

[0095] - ARQ function (error correction through ARQ)

[0096] - Concatenation, segmentation, and reassembly functions of RLC SDUs

[0097] - Re-segmentation function (re-segmentation of RLC data PDUs)

[0098] - Reordering function (reordering of RLC data PDUs)

[0099] - Duplicate detection

[0100] - Error detection function (protocol error detection)

[0101] - RLC SDU discard function

[0102] RLC re-establishment function

[0103] In the above, the in-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from a lower layer to an upper layer in order. The in-sequence delivery function of the NR RLC device may include a function of reassembling and delivering the RLC SDUs when the original RLC SDU is received divided into multiple RLC SDUs, a function of rearranging the received RLC PDUs based on an RLC SN (sequence number) or PDCP SN (sequence number), a function of recording lost RLC PDUs by rearranging the order, a function of reporting the status of lost RLC PDUs to the transmitting side, and a function of requesting retransmission of lost RLC PDUs. The in-sequence delivery function of the NR RLC device may include a function to deliver only the RLC SDUs prior to the lost RLC SDU in order to the upper layer if there is a lost RLC SDU, or a function to deliver all RLC SDUs received before the timer started in order to the upper layer if a predetermined timer has expired even if there is a lost RLC SDU. Alternatively, the in-sequence delivery function of the NR RLC device may include a function to deliver all RLC SDUs received up to the present in order to the upper layer if a predetermined timer has expired even if there is a lost RLC SDU.In addition, the RLC PDUs described above may be processed in the order they are received (regardless of the order of sequence numbers, in the order of arrival) and delivered to the PDCP device out of order (out-of-sequence delivery). In the case of segments, segments stored in a buffer or to be received later may be received, reconstructed into a single complete RLC PDU, processed, and delivered to the PDCP device. The NR RLC layer may not include a concatenation function, and this function may be performed by the NR MAC layer or replaced by the multiplexing function of the NR MAC layer.

[0104] In the above, the out-of-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from a lower layer directly to an upper layer regardless of order. It may include a function of reassembling and delivering them when a single RLC SDU is received divided into multiple RLC SDUs, and may include a function of storing the RLC SN or PDCP SN of the received RLC PDUs and sorting the order to record the lost RLC PDUs.

[0105] The NR MAC (S40, S55) can be connected to multiple NR RLC layer devices configured in a terminal, and the main functions of the NR MAC may include some of the following functions.

[0106] - Mapping function (mapping between logical channels and transport channels)

[0107] - Multiplexing and demultiplexing functions of MAC SDUs

[0108] - Scheduling information reporting function

[0109] - HARQ function (error correction through HARQ (hybrid automatic repeat request))

[0110] - Priority handling between logical channels of one UE

[0111] - Priority handling between UEs by means of dynamic scheduling

[0112] - MBMS service identification function

[0113] - Transport format selection function

[0114] - padding

[0115] The NR PHY layer (S45, S50) can perform the operation of channel coding and modulating upper layer data, creating OFDM symbols and transmitting them to the wireless channel, or demodulating OFDM symbols received through the wireless channel and channel decoding them to transmit them to the upper layer.

[0116] The detailed structure of the above wireless protocol structure may vary depending on the carrier (or cell) operation method. For example, when a base station transmits data to a terminal based on a single carrier (or cell), the base station and the terminal use a protocol structure having a single structure for each layer, as shown in S00. On the other hand, when a base station transmits data to a terminal based on Carrier Aggregation (CA) using multiple carriers in a single TRP, the base station and the terminal use a protocol structure that has a single structure up to the RLC, as shown in S10, but multiplexes the PHY layer through the MAC layer. As another example, when a base station transmits data to a terminal based on Dual Connectivity (DC) using multiple carriers in multiple TRPs, the base station and the terminal use a protocol structure that has a single structure up to the RLC, as shown in S20, but multiplexes the PHY layer through the MAC layer.

[0117] In the following disclosure, the above examples are described through a number of embodiments, but these are not independent, and one or more embodiments may be applied simultaneously or in combination.

[0118] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Hereinafter, a base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, gNB, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. A terminal may include a UE (user equipment), MS (mobile station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. Although embodiments of the present disclosure are described below using a 5G system as an example, embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or channel types. For example, LTE or LTE-A mobile communication and mobile communication technologies developed after 5G may be included therein. Accordingly, embodiments of the present disclosure may be applied to other communication systems with some modifications made in the judgment of a person skilled in the art, without significantly departing from the scope of the present disclosure. The contents of the present disclosure are applicable to FDD and TDD systems.

[0119] Furthermore, in describing the present disclosure, if it is determined that a detailed description of related functions or configurations could unnecessarily obscure the essence of the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined in consideration of their functions within the present disclosure, and these definitions may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0120] In describing the present disclosure below, the term "upper layer signaling" may be a signaling corresponding to at least one or a combination of at least one of the following signalings.

[0121] - MIB (master information block)

[0122] - SIB (system information block) or SIB

[0123] - RRC (radio resource control)

[0124] - MAC (medium access control) CE (control element)

[0125] In addition, L1 signaling may be a signaling corresponding to at least one or a combination of at least one of the following physical layer channels or signaling methods using signaling.

[0126] - PDCCH (physical downlink control channel)

[0127] - DCI (downlink control information)

[0128] - Terminal-specific (UE-specific) DCI

[0129] - Group Common DCI

[0130] - Common DCI

[0131] - Scheduling DCI (e.g., DCI used for the purpose of scheduling downlink or uplink data)

[0132] - Non-scheduling DCI (e.g., DCI not intended for scheduling downlink or uplink data)

[0133] - PUCCH (physical uplink control channel)

[0134] - UCI (uplink control information)

[0135] In the following disclosure, determining the priority between A and B may be referred to in various ways, such as selecting the one with the higher priority according to a predetermined priority rule and performing the corresponding action, or omitting or dropping the action for the one with the lower priority.

[0136] In the following disclosure, the above examples are described through a number of embodiments, but these are not independent, and one or more embodiments may be applied simultaneously or in combination.

[0137] Communication support equipment for mobile terminals can be composed of radio-units (RU), distributed-units (DU), and centralized-units (CU). As mobile communication standards have spanned multiple generations—including GSM (Global System for Mobile Communications), CDMA (Code-Division Multiple Access), LTE (Long Term Evolution), and 5G (5th Generation)—products from various manufacturers are in use. However, compatibility issues arising when heterogeneous products are manufactured by different companies have created significant constraints on carriers building wireless communication networks. To partially resolve these issues, a standardization policy called the Open Radio Access Network (O-RAN) was established. The O-RAN standard provides detailed definitions for information exchange and operations between the DU and RU; through this standard, carriers can combine and utilize the O-DU and O-RU even when they are manufactured by different companies.

[0138] The O-RAN specification defines information regarding the control plane and the user plane. The control plane is a structure that transmits control signals between the O-RU and O-DU and can be configured to indicate time information, frequency information, beam IDs, etc. The user plane can be configured to transmit demodulated values ​​in the frequency domain sent from the O-RU to the O-DU. Management plane information contains protocol-related information regarding network management between the O-RU and O-DU. Management plane information may consist of data exchanged when sharing basic information and operable functions for each product family.

[0139] FIG. 2 is a diagram illustrating a part of an O-RAN architecture structure according to one embodiment.

[0140] In FIG. 2, SMO (service management and orchestration) (201) is a core management platform of the O-RAN architecture that communicates with nodes such as O-DU (203) and O-RU (204) to perform data collection and network management. Specifically, it can transmit and receive data or control information through signaling with O-DU (203) or O-RU (204), and can control data flow and transmit and receive information through M (management)-plane (206), C (control)-plane, U (user)-plane, and S (synchronization)-plane. It can also perform network optimization based on KPI (key performance indicator) or AI model training.

[0141] Additionally, in FIG. 2, the Non-RT (non-real time) RIC (ran intelligent controller) (202) may be involved in service management, etc. in an O-RAN architecture. It may also operate as part of the SMO (201) or be included in the SMO (201). The Non-RT RIC layer and the Near-RT RIC layer may be distinguished based on control latency. The Non-RT RIC (202) may be responsible for relatively long-term network optimization or RAN-related policies, and may be responsible for training AI / ML (machine learning) models. It may also perform big data analysis such as patterns of network traffic and terminal mobility, and types or quality of services, or improve performance along with KPI monitoring. The Near-RT RIC may perform network resource management or control that requires relatively short latency (e.g., within 1 second). Additionally, rApp / xApp may correspond to AI / ML applications running on the non-RT RIC and the near-RT RIC.

[0142] According to one embodiment, the AI ​​analysis AI model training performed by SMO can be carried out in RIC.

[0143] Additionally, in FIG. 2, the O-DU (203) can be responsible for real-time management of wireless resources and processing related to the physical layer. Specifically, it can process high-PHY, MAC, and RLC layer functions, and can generate KPI data or information and transmit it to SMO or Non-RT RIC, etc. The O-DU (203) can be connected to the SMO (201) and O1 (205) interfaces.

[0144] Additionally, in FIG. 2, the O-RU (204) is responsible for the interface between the wireless interface and the base station and can primarily handle RF signal processing (e.g., may be similar to an RRH (radio remote head) or TRP (transmission and reception point)) and low-PHY layer functions. The O-RU (204) can be connected to the O-DU (203) or SMO (201) via the M-Plane (206) to transmit and receive data, and can be connected to the O-DU (203) via the CUS-plane (control, user, synchronization plane) (207).

[0145] Additionally, in FIG. 2, the M-plane (206) may perform functions related to remote O-RU initialization or provide configuration and management functions. Additionally, communication may be established using an open interface based on NETCONF / YANG. In the CUS-plane (207), the C-plane may transmit control information and configuration data, or transmit control information regarding a specific range of U-plane data symbols, PRB (physical resource block), etc., that can be processed commonly using multiple section types and section extensions. The U-plane may be involved in user data transmission and may include I (in-phase) / Q (quadrature) data that utilizes the control information of the C-plane (e.g., BFW (beamforming weight), compression parameters, etc.) for a range defined by the C-plane. The S-plane may be involved in the transmission of information for timing and synchronization. Additionally, information or related data transmitted from each plane may also be transmitted as each plane message (e.g., U-plane message).

[0146] In addition, in relation to one embodiment of the present disclosure, NETCONF (network configuration protocol) and YANG (yet another next generation) may correspond to technologies for the configuration and management of network equipment. NETCONF is a protocol for data exchange between network equipment and a management system, which primarily transmits data using the XML format and can operate in the form of requests and responses. The functions of NETCONF include reading current network configuration data. <get-config>, applying new configuration data <edit-config>Examples can be given.

[0147] In addition, in relation to one embodiment of the present disclosure, YANG is a data modeling language that defines configuration data of network equipment and can be used together with NETCONF. YANG supports a hierarchical data model and can represent data in formats such as XML. Data structures can be managed by modularizing them, and flexibility can be provided to extend them to new network technologies or equipment. For example, YANG can group data using containers within the data model, manage iterable data groups using lists, and define single data using leaves.

[0148] The above NETCONF and YANG can be applied to data transmission and reception between the SMO (201), O-DU (203), and O-RU (204) of the O-RAN.

[0149] FIG. 3 is a drawing illustrating two models in relation to the architecture of an M-plane according to one embodiment.

[0150] In FIG. 3, the Hierarchical M-plane model (301) may have interfaces applied hierarchically between SMO#1 (303) and O-DU#1 (304), and between O-DU#1 (304) and O-RU#1 (305). Specifically, O-RU#1 (305) may be directly managed only by O-DU#1 (304), and an interface may exist between SMO#1 (303) and O-DU#1 (304), but the structure may be such that SMO#1 (303) does not directly manage O-RU#1 (305) but manages it through O-DU#1 (304).

[0151] The hybrid M-plane model (302) may have interfaces applied hierarchically between SMO#2 (306), O-DU#2 (307), and O-RU#2 (308), between SMO#2 (306) and O-DU#2 (307), and between O-DU#2 (307) and O-RU#2 (308), and additionally, interfaces may also be applied between SMO#2 (306) and O-RU#2 (308). Specifically, SMO#2 (306) may directly perform software management, performance management, configuration management, etc. for O-RU#2 (308).

[0152] According to one embodiment, each O-RAN component or node can transmit and receive data, etc. using the M-plane. Additionally, the fronthaul may include an interface associated with the O-DU or O-RU.

[0153] FIG. 4 is a diagram illustrating lifecycle management (LCM) in O-RAN according to one embodiment.

[0154] LCM can be a concept for efficiently managing the lifecycle of network elements and functions, and it can systematically support the processes of deploying, operating, updating, or decommissioning network elements in O-RAN's modular architecture and virtualized environment.

[0155] According to FIG. 4, in step 410, the SMO may receive data and / or KPIs from at least one O-RU and / or O-DU. In this process, the SMO may collect data and / or KPIs necessary for analysis. In step 410, the signaling between the SMO and the O-RU may be applied using a Hierarchical M-plane model (301) that signals via the O-DU in relation to FIG. 3, or a Hybrid M-plane model (302) that signals directly connected to the O-RU may be applied.

[0156] In step 420, SMO can perform analysis on the received data and / or KPIs.

[0157] According to one embodiment, the received data may be used for AI training or learning in relation to necessary characteristics, any information or performance-related information, elements and parameters, etc.

[0158] To this end, the data received by the SMO may correspond to raw data (or, information before processing, unprocessed data, raw data, primary data), so additional work may be required. For example, KPI labeling can be performed on the said raw data through KPI information.

[0159] Specifically, KPI labeling can refer to the process of identifying, classifying, or organizing elements or metrics to analyze or evaluate data. In other words, in relation to SMO data collection, it can refer to the process of aligning raw data with specific KPIs. Alternatively, KPI labeling can refer to the process of generating training data by mapping specific KPIs to raw data. Furthermore, KPI labeling may be used as another term to describe similar operations, such as data labeling.

[0160] Regarding KPIs related to one embodiment, or information regarding KPIs, for example, the KPIs may include information related to user context and information related to communication time (e.g., information for timing synchronization such as frame ID, slot ID, GPS timing, etc.). Additionally, information regarding communication performance (e.g., SINR (signal to interference plus noise ratio), throughput, BLER (block error rate), RSRP (reference signal received power), etc.) may be included. Alternatively, one or more related KPIs may be included.

[0161] Information that may be applied to or included in KPIs may include any specific information, elements, parameters, etc. required by the user or manager, and is not limited to the examples above.

[0162] As such, KPI labeling can be a process for SMO to quickly extract and analyze necessary information related to AI and ML from multiple data.

[0163] In step 430, based on the analysis in step 420, a suitable AI / ML module update for at least one O-RU can be performed. According to one embodiment, the KPI labeling exemplified above may be performed in step 420 or step 430, or prior to the step.

[0164] In addition, according to one embodiment, steps 420 and 430 can be repeated to maintain and manage an optimal AI / ML module. That is, optimization related to AI / ML or AI RAN can be performed through fine tuning by repeating steps 420 and 430.

[0165] According to one embodiment, examples to which AI / ML-related optimization, AI training, or AI RAN may be applied include channel estimation in a communication system, CSI (channel state information) prediction, CSI compression, MIMO detector, MIMO system and related algorithm, AI scheduler, or AI beamforming.

[0166] FIG. 5 is a diagram illustrating a process for transmitting data and KPIs for AI model training according to one embodiment.

[0167] According to FIG. 5, the process of transmitting data and KPIs between SMO (501), O-DU (502), and O-RU (503) in an O-RAN structure can be illustrated. In FIG. 5, other O-RAN components or signaling that are not directly related to the embodiment may be omitted.

[0168] In step 510, O-DU (502) can transmit KPIs to SMO (501). KPIs may correspond to information for performing labeling on raw data in relation to AI / ML, etc., according to one embodiment.

[0169] In step 520, the O-RU (503) can transmit data to the SMO (501). Step 520 may correspond to the step of transmitting raw data, and may correspond to data stored or collected by the O-RU (503). The data may be transmitted to the SMO (501) or to a Non-RT RIC within the SMO (501).

[0170] Alternatively, the data transmission or collection for AI model training is achieved by transmitting data from the O-RU (503) to the SMO (501) via the O-DU (502), or by transmitting data through an interface (e.g., an M-plane) directly connected between the O-RU (503) and the SMO (501).

[0171] If the equipment sources of O-DU (502) and O-RU (503) are different, there may be limitations in data transmission and reception due to constraints to prevent information leakage. Accordingly, a Hybrid M-plane model is applied to transmit raw data from O-RU (503) to SMO (501) to prevent information leakage or enhance security.

[0172] As shown in FIG. 5, raw data transmitted from O-RU (503) to SMO (501) can be labeled with KPIs by SMO along with KPIs received from O-DU (502). This allows for the identification, classification, and organization of elements or indicators for analyzing or evaluating raw data.

[0173] SMO (501) can perform KPI labeling and then analyze it or perform AI model learning or training.

[0174] According to FIG. 5, in some cases, SMO (501) receives KPIs from O-DU (502) and raw data from O-RU (503), and all data is used for KPI labeling, which may increase fronthaul overhead. Additionally, unnecessary raw data may not be used for training and may be wasted. Since appropriate data suitable for the purpose is required for training or learning of AI, etc., related to one embodiment, indiscriminate data collection may affect the efficiency and quality of learning. Therefore, a method may be required to optimize the data collection and KPI labeling processes to reduce fronthaul overhead and improve the efficiency of AI model training.

[0175] In relation to the method of transmitting data from the O-RU to the SMO according to one embodiment, a first method of transmitting data when the buffer is full (e.g., full-and-go) and a second method of transmitting data whenever there is an opportunity to send (e.g., best-efforts) may be applied.

[0176] Specifically, according to the first method described above, the O-RU can transmit to the SMO when the buffer or data is full or when a certain capacity is filled. In the above method, the data transmitted by the O-RU may correspond to raw data, and the O-DU transmits information regarding KPIs to the SMO, and the SMO can perform labeling on the received raw data using the KPIs and perform AI model training, etc. on the labeled data.

[0177] Additionally, according to the second method described above, the O-RU may transmit to the SMO when there is an opportunity to transmit specific situations or data. In the above method, the data transmitted by the O-RU may correspond to raw data, and the O-DU transmits information regarding KPIs to the SMO, and the SMO may perform labeling on the received raw data using the KPIs and perform AI model training, etc. on the labeled data.

[0178] Additionally, a third method may be exemplified in which the O-RU receives information regarding KPIs from the SMO or O-DU, directly performs KPI labeling, and selectively transmits the labeled data to the SMO. By following the third method, fronthaul overhead can be mitigated, effective data transmission can be achieved, and optimized learning, training, or fine-tuning can be performed. Furthermore, complexity in the SMO can be reduced, or storage space can be utilized more efficiently. Alternatively, information regarding KPIs may be selectively requested and received to perform KPI labeling.

[0179] Alternatively, the first or second method may be similarly applied to data for which KPI labeling has been performed by the O-RU using the fourth method. For example, KPI labeling may be performed by the O-RU, and the labeled data may be transmitted to the SMO using a full-and-go or best-effort method.

[0180] According to one embodiment, the above methods may be appropriately selected and used for data transmission depending on fronthaul overhead, buffer status, AI model training purpose or situation, etc.

[0181] FIG. 6 is a diagram illustrating the process of performing KPI labeling and transmitting data in an O-RU according to one embodiment.

[0182] FIG. 6 demonstrates that KPI labeling can be performed at the O-RU (603) rather than the SMO (601), thereby ensuring the efficiency of data collection by transmitting only the necessary data to the SMO (601). Alternatively, a signaling method may be proposed in which the SMO (601) requests raw data having a specific KPI value from the O-RU (603) and transmits the corresponding raw data to the SMO (601). This may be related to the third method exemplified above.

[0183] Before each step exemplified below in relation to FIG. 6 is performed, SMO (601) may transmit configuration information for data collection to at least one of O-DU (602) and O-RU (603). Additionally, capability information related to data collection may be transmitted from O-DU (602) or O-RU (603) to SMO (601).

[0184] According to Fig. 6, in step 610, O-DU (602) can transmit information about the KPI to SMO (601).

[0185] Alternatively, in step 620, O-DU (602) can transmit information about the KPI to O-RU (603). In this process, a C-plane may be defined and used.

[0186] Additionally, in the above steps, the O-DU (602) may add a process of receiving a message related to the request from the SMO (601) or O-RU (603).

[0187] In step 630, SMO (601) can transmit information about the received KPI to O-RU (603). In this case, step 620 may be omitted. In the transmission process, an M-plane may be defined and used, and YANG / NETCONF may be used.

[0188] That is, O-RU (603) can receive information about KPIs directly from O-DU (602) or receive it from O-DU (602) via SMO (601).

[0189] In step 640, SMO (601) may request data from O-RU (603). The request may correspond to information requesting any raw data according to one embodiment, and may correspond to information requesting data required by SMO (601), data related to a specific KPI, etc. Additionally, the request may be made prior to or after signaling related to the KPI (e.g., steps 610 to 630).

[0190] According to one embodiment, the O-RU (603) may perform KPI labeling based on information regarding previously received KPIs. The KPI labeling may be performed in the O-RU (603) to reduce overhead associated with the SMO (601) or M-plane.

[0191] Additionally, the labeling performed by the O-RU (603) may be performed before or after the step regardless of the request according to step 640, and may also be performed based on the configuration information transmitted by the SMO (601).

[0192] In step 650, the O-RU (603) may transmit data to the SMO (601). The data may include data requested by the SMO (601) and may correspond to all data stored in the O-RU (603). Alternatively, the data may correspond to data labeled by the O-RU (603). According to an embodiment, the data transmission may be based on configuration information received from the SMO (601).

[0193] In the signaling of the SMO (601) and O-RU (603) according to steps 640 and 650, an M-plane according to one embodiment may be used.

[0194] According to one embodiment, the SMO can transmit configuration information for data collection to the O-RU or O-DU.

[0195] The above configuration information may include at least one of information related to data collection, information for KPI transmission or KPI setting, information related to KPI labeling, or information related to the transmission method. Additionally, the configuration information may be transmitted based on data defined in the YANG model via the NETCONF command. That is, it may be transmitted via the NETCONF command based on the data format established in the YANG node.

[0196] In relation to the above configuration information, information related to data collection may include information on at least one of a method for transmitting data by training type, a method for transmitting data considering fronthaul capacity and traffic, and a method for transmitting data according to the data set distribution.

[0197] In addition, the above setting information may include information for collecting data related to any purpose, and is not limited to the information exemplified above.

[0198] The method of transmitting data by training type exemplified above may correspond to a method in which a different transmission method is applied in relation to the model training process exemplified by pre-training and fine-tuning.

[0199] Specifically, for example, pre-training may correspond to the process of learning the model's initial weights using a dataset, and thus may require learning the general patterns or features of the data. Therefore, a diverse dataset of a certain size or larger may be required, and in such cases, the first or second method exemplified earlier may be utilized. That is, SMO can receive data that has not been labeled with KPIs from the O-RU through the first or second method. Alternatively, the fourth method may also be utilized to receive data labeled by the O-RU using full-and-go or best-effort methods.

[0200] In addition, since fine-tuning is a process of adjusting a pre-trained model to suit a specific purpose, the weights associated with the model can be updated using a specific dataset of a relatively small size. Therefore, a specific dataset may be required, and the third method exemplified earlier may be utilized.

[0201] Next, regarding the method of transmitting data considering the fronthaul capacity and traffic exemplified above, if the traffic is excessive relative to the fronthaul capacity (e.g., fronthaul overhead), the transmission method may be switched from the existing first, second, or fourth method to the third method. Alternatively, transmission may be switched from the first or second method to the fourth method. In this way, each method can be flexibly switched and used based on the amount of traffic.

[0202] Next, the method of transmitting data according to the data set distribution exemplified above may correspond to a method of analyzing KPIs among the collected data (e.g., data sets for pre-training, labeled data, etc.) where the distribution by KPI level is less than a certain value, requesting data related to the KPI from the O-RU through a third method, and receiving the related data.

[0203] In relation to the above configuration information, the information for KPI transmission or KPI configuration may include information related to at least one of KPIs for synchronization in time or frequency, KPIs available in the network and log data generated at the L1, L2, and L3 layers, or KPIs related to RAN use cases. Additionally, it may be applied to the M-plane or C-plane.

[0204] KPIs for time or frequency synchronization may include KPI information such as time stamps and frequency indications, and this information can be used as elements related to network synchronization.

[0205] According to one embodiment, KPIs available in the network and log data generated at the L1, L2, and L3 layers may include KPI information related to throughput, SINR (signal to interference plus noise ratio), delay, block error rate (BLER), data rate, or HARQ, and may also include general KPIs available in the network.

[0206] In addition, KPIs related to RAN use cases may include KPI information related to SINR, BLER, and MMSE (minimum mean squared error) when performing AI-based channel estimation, and KPI information related to AI-based MIMO detectors such as rank, MCS (modulation and coding scheme), CRC (cyclic redundancy check), HARQ, and LLR (log-likelihood ratio). At least one of the KPI information exemplified above may be used or included in the configuration information for each RAN use case.

[0207] In relation to the above configuration information, the information related to KPI labeling may include initial KPI labeling configuration information for each use case. That is, it may correspond to information regarding which KPIs to use for labeling in a specific use case. Additionally, it may be applied to the M-plane or C-plane.

[0208] In relation to the above setting information, information related to the transmission method may include at least one of information regarding an I / Q data compression method or information regarding a transmission method.

[0209] Specifically, for example, information regarding I / Q data compression methods may include information on data compression methods such as block floating point (BFP), block scaling, and u-law using non-linear approximations to efficiently transmit I / Q data. Additionally, since the degree of data compression can affect the noise level of the data set and fronthaul overhead, it may be appropriately adjusted according to network conditions and data characteristics.

[0210] Information on the transmission method may include at least one of the following: information on the method of transmitting data using the NETCONF command based on the data format defined in the YANG node, or information on the method of saving data in a file format and then transmitting it to NETCONF in a file format (e.g., a format including a csv extension).

[0211] In addition, the above-mentioned configuration information may include KPI labeling information related to any purpose or information related to transmission methods, and is not limited to the information exemplified above.

[0212] According to one embodiment, the YANG model can be exemplified by [Table 1].

[0213] [Table 1]

[0214]

[0215]

[0216] In relation to [Table 1] above, elements or parameters related to the setting information for data collection may be exemplified below, and at least one of the elements or parameters below may be included in the setting information.

[0217] ● ai-ran-lcm

[0218] - YANG module name (Information about the YANG module name may be displayed.)

[0219] ● Use case (May include details regarding the applied AI features. For example, channel estimation, prediction, etc.)

[0220] ● availability

[0221] - True / false - Enabled / disabled (support / not-support) (May contain information regarding support status or capability. It may also be displayed as a boolean type.)

[0222] ● collection-opt

[0223] - Select option: 1 (full-and-go), 2 (best-effort), 3 (selective), 4 (In relation to the data transmission method, information regarding the first method, second method, third method, or fourth method exemplified in one embodiment may be included.)

[0224] ● kpi (May include information about KPIs.)

[0225] ● raw-data-format

[0226] - Select inline data format / file format (Information about the inline data format or file format is displayed, which may indicate the transmission format of the raw data.)

[0227] ● raw-data-comp

[0228] - compression method (may include information related to the data compression method.)

[0229] ● Labeling method

[0230] - KPI labeling method - time stamp sync / data id / ... (Information related to the labeling method may be included.)

[0231] ● Enable-file-upload

[0232] - Flag to enable file type raw-data-transmission (Information related to file types requiring data transmission may be displayed.)

[0233] FIG. 7 is a diagram illustrating signaling for setting information for data collection according to one embodiment.

[0234] In step 710, the SMO (702) can generate configuration information for data collection. The configuration information may include information for modifying or updating the configuration.

[0235] In step 720, SMO (702) can transmit the generated configuration information to O-RU (701). Additionally, SMO (702) can also transmit the generated configuration information to O-DU and receive a response.

[0236] The configuration information that SMO (702) sends to O-RU (701) can be exemplified by the NETCONF command as shown in [Table 2].

[0237] [Table 2]

[0238]

[0239] In [Table 2], <config>The sub-configuration of may include elements or parameters for the configuration information exemplified in [Table 1] above. Additionally, the configuration information exemplified is not limited to the information exemplified in the table above, nor is it limited to the format exemplified. Specifically, in [Table 2], the use case is exemplified as channel estimation, the data collection method is the third method, and the setting is exemplified as a KPI for NMSE (normalized mean square error), etc. In step 730, the O-RU (701) can apply the received configuration information. For example, it can apply the received configuration information or change the existing configuration information.

[0240] In step 740, the O-RU (701) may transmit information to the SMO (702) regarding whether the setting has been applied. This information may include a report of success or failure. Depending on the embodiment, the report of failure may include the reason.

[0241] The report of success in the information regarding whether the setting is applied that O-RU (701) sends to SMO (702) can be exemplified in [Table 3].

[0242] [Table 3]

[0243]

[0244] The report of failure in the information regarding whether the O-RU (701) applies the settings to the SMO (702) can be exemplified in [Table 4].

[0245] [Table 4]

[0246]

[0247] FIG. 8 is a diagram illustrating signaling for data collection setting information according to one embodiment. FIG. 8 may be illustrated in a method in which SMO (803) transmits setting information for data collection to O-RU (801), and O-RU (801) notifies O-DU (802) of the changed information or setting information.

[0248] In step 810, the SMO (803) may generate configuration information for data collection. The configuration information may include information for modifying or updating the configuration.

[0249] In step 820, SMO (803) can transmit the generated configuration information to O-RU (801).

[0250] In step 830, the O-RU (801) can apply the received configuration information. For example, it can apply the received configuration information or change the existing configuration information.

[0251] In step 840, the O-RU (801) may transmit information to the SMO (803) regarding whether the setting has been applied. This information may include a report of success or failure. Depending on the embodiment, the report of failure may include the reason.

[0252] In step 850, the O-RU (801) may transmit all or part of the configuration information along with information notifying the O-DU (802) that the configuration has been changed. Alternatively, along with the information notifying that the configuration has been changed, it may transmit information that needs to be changed (e.g., information or parameters modified by the SMO (803)).

[0253] A specific example of O-RU (801) transmitting information to O-DU (802) that the settings have been changed, along with information that needs to be changed, can be illustrated in [Table 5].

[0254] [Table 5]

[0255]

[0256] In [Table 5], <edit>The subconfiguration of may include information modified by SMO. Alternatively, at step 860, O-DU (802) may request configuration information or information requiring change from O-RU (801) and receive it.

[0257] Specifically, in step 860-a, O-DU (802) may request O-RU (801) to set up information or information that needs to be changed.

[0258] For example, O-DU (802) is periodic or non-periodic <get>or <get-config>You can request information that needs to be changed using . Related to the above NETCONF <get>...may correspond to a command or request for checking information, etc. regarding settings or status currently running in relation to equipment or devices, etc. <get-config>This may correspond to a command or request to check all or part of the configuration information of a repository (e.g., a datastore) associated with specific configuration data.

[0259] In step 860-b, the O-RU (801) can transmit information to the O-DU (802) about whether the settings have been changed. This transmission can be exemplified by [Table 6].

[0260] [Table 6]

[0261]

[0262] In relation to [Table 6], for example, if the configuration information is changed, O-RU (801) tells O-DU (802) about NETCONF's <rpc-reply>Changed information or information requiring change can be transmitted using (e.g., CSI compression, the first method as a data collection method, etc.). Also, if the configuration information has not changed, O-RU (801) sends NETCONF's to O-DU (802). <rpc-reply> <rpc-error>It can be transmitted along with the reason. For example, " <error-tag>data-missing < / error-tag> " or " <error-message> Configuration unchanged < / error-message> It can be transmitted to. Step 860 can be performed in place of Step 850.

[0263] FIG. 9 is a diagram illustrating signaling of information regarding KPIs according to one embodiment.

[0264] According to Fig. 9, the process may include directly transmitting KPIs from O-DU (902) to O-RU (901) (e.g., direct KPI transmission) and performing labeling work in O-RU (901).

[0265] In step 910, the O-RU (901) may request information about the KPI from the O-DU (902). Alternatively, the requested information may correspond to information about a specific KPI. Thus, the O-RU (901) may perform labeling only on the necessary raw data. Additionally, step 910 may be omitted. Through the above steps, resources associated with the O-RU (901) can be saved or overhead reduced.

[0266] In step 920, O-DU (902) can transmit information about the KPI to O-RU (901).

[0267] According to one embodiment, steps 910 and 920 may be performed using a C-plane or an M-plane.

[0268] In step 930, the O-RU (901) can perform KPI labeling according to one embodiment on one or more raw data based on information about the received KPI.

[0269] According to one embodiment, in relation to the direct KPI transmission exemplified in FIG. 9, the O-RU (901) may request information about the KPI from the O-DU (902), or the O-DU (902) may transmit information about the KPI to the O-RU (901) by utilizing the C-plane or M-plane.

[0270] Specifically, in the C-plane, new section types or extensions can be defined for conveying information about KPIs. Additionally, in the M-plane, initial settings for conveying information about KPIs can be performed.

[0271] [Table 7] may be an example of O-DU (902) defining a new section type to transmit information about KPIs to O-RU (901) in relation to the C-plane.

[0272] [Table 7]

[0273]

[0274] msb - the most significant bit lsb - the least significant bit

[0275] reserved - reserved for future use

[0276] transport header - transport header

[0277] Radio application header - Wireless network application header

[0278] [Table 8] may be an example of O-DU (902) defining a new section extension to transmit information about KPIs to O-RU (901) in relation to the C-plane.

[0279] [Table 8]

[0280]

[0281] ef - extension flag (information on whether there are other extensions or if it is the last extension) extType - specific extension type

[0282] extLen - Length information for section extension

[0283] In [Table 7] and [Table 8], when transmitting information about KPIs, fields related to settings for KPI labeling may be included, such as fields regarding which data will be labeled. Specifically, the following fields may be examples.

[0284] timeStamp - Identifying labeled data using a time stamp

[0285] aiUsecase - Information on which cases it is used in

[0286] dataId - Data can be identified using an ID.

[0287] kpiType - Type of KPI used for labeling

[0288] kpiVal - KPI value

[0289] New SE can be attached to all STs and SEs for flexible use as needed.

[0290] When using the dataId exemplified above, the timeStamp may not be used. Alternatively, when using the dataId, the timeStamp may also be used.

[0291] [Table 9] may be an example of O-RU (901) defining a new section extension to request information about KPIs from O-DU (902) in relation to the C-plane.

[0292] [Table 9]

[0293]

[0294] In [Table 9], fields related to the required KPIs may be included. Specifically, the following fields may be examples: reqTimeStamp (or reqDataId) – A value for the Timestamp or Data ID of the raw data of the required KPI.

[0295] That is, after O-RU (901) makes a request to O-DU (902) as exemplified in [Table 8], O-DU (902) may make a response as exemplified in [Table 6] or [Table 7] to send information about the KPI to O-RU (901).

[0296] [Table 10] may show examples of settings for fields related to the C-plane exemplified above in relation to the M-plane.

[0297] [Table 10]

[0298]

[0299] As exemplified in [Table 10], M-plane settings can be changed by managing AI function data information in a bit mapping table. In [Table 10], AI functions can be indexed and defined as bits, or options or indexes composed of one or more AI functions can be defined.

[0300] Specifically, indexing can be exemplified as '0000 0001b' in relation to channel element (CE), '0000 0010b' in relation to channel prediction, and '1111 1110b' when channel compression and channel prediction are required simultaneously.

[0301] [Table 11] may show examples of settings for fields related to the C-plane exemplified above in relation to the M-plane.

[0302] [Table 11]

[0303]

[0304] As exemplified in [Table 11], KPIs may be indexed and defined as bits, or options or indices composed of one or more KPIs may be defined. Specifically, examples may include '0000 0001b' in relation to SINR, '0000 0010b' in relation to BLER, '1111 1110b' in relation to throughput, and '1111 1111b' including throughput, SINR, etc.

[0305] In addition, therefore, in relation to the M-plane as in [Table 10] or [Table 11] above, the setting can be changed to the C-plane through the process of defining with the bits (bitification) exemplified above.

[0306] FIG. 10 is a diagram illustrating signaling of information regarding KPIs according to one embodiment.

[0307] According to FIG. 10, the process may include transmitting KPIs from O-DU (1002) to O-RU (1001) via SMO (1003) (e.g., bypass KPI transmission) and performing labeling work at O-RU (1001). In this case, signaling between SMO (1003) and O-RU (1001) can be performed without the involvement of O-DU (1002), thereby enhancing security.

[0308] In step 1010, SMO (1003) may request information about KPIs from O-DU (1002). Alternatively, the requested information may correspond to information about specific KPIs. Also, step 1010 may be omitted.

[0309] In step 1020, O-DU (1002) can transmit information about KPIs to SMO (1003). The transmitted information about KPIs may include information about specific KPIs.

[0310] In step 1030, the O-RU (1001) may request information about the KPI from the SMO (1003). Alternatively, the requested information may correspond to information about a specific KPI. Thus, the O-RU (1001) may perform labeling only on the necessary raw data. Additionally, step 1030 may be omitted.

[0311] In step 1040, SMO (1003) can transmit information about KPIs to O-RU (1001). The transmitted information about KPIs may include information about specific KPIs.

[0312] According to one embodiment, steps 1030 and 1040 may be performed using an M-plane.

[0313] In step 1050, the O-RU (1001) can perform KPI labeling according to one embodiment on one or more raw data based on information about the received KPI.

[0314] As an example of the request in step 1030 of Fig. 10, the YANG model can be exemplified through [Table 12].

[0315] [Table 12]

[0316]

[0317] According to one embodiment, a temporary node may be created and operated to request information on KPIs for each AI use case in use in the YANG module. [Table 12] may include information for requesting KPIs, such as 'ai-ran-lcm', which is exemplified as the name of the YANG module, and 'ai-Usecase', which indicates which AI use case is exemplified in each data leaf.

[0318] FIG. 11 shows an example of a method in which an O-RU requests information about a KPI according to one embodiment.

[0319] In FIG. 11, an example of a NETCONF command related to an O-RU (1101) requesting information about a KPI for SMO (1102) can be shown.

[0320] In step 1110, the O-RU (1101) can generate parameters for requesting information about the KPI. The parameters may include the contents of [Table 12].

[0321] In step 1120, O-RU (1101) tells SMO (1102), <notification>You can request information about KPIs through commands exemplified by.

[0322] [Table 13] relates to step 1120 of FIG. 11. <notification>You can show an example of a request through a command.

[0323] [Table 13]

[0324]

[0325] [Table 13] exemplifies commands indicating that the required AI use case corresponds to beam management, the required KPI is for SINR, and the required KPI is for ID 112. Specifically, <notification> 과< / notification> Using a command, the time of occurrence and details related to each KPI request that requires a request (or update) may be included in the subcommand. In step 1130, SMO (1102) can send information about the KPI or set the KPI to O-RU (1101).

[0326] In one embodiment, a YANG model or NETCONF command related to the transmission of information about KPIs for O-RU by SMO may be exemplified.

[0327] When SMO transmits information about KPIs to O-RU, a YANG model such as [Table 14] can be exemplified. This may be related to step 1040 of Fig. 10.

[0328] [Table 14]

[0329]

[0330] [Table 14] includes 'ai-ran-lcm', exemplified as the name of the YANG module, 'kpi-transmission', a container that can be exemplified as a node, and 'bypass-tx', exemplified as a list of data sets, and may include information related to KPIs, such as 'KPI', representing the sending KPI, and 'kpi-value', representing the KPI value, exemplified in each data leaf. According to one embodiment, SMO tells O-RU, <edit-config>Information about KPIs can be transmitted using the command exemplified by.

[0331] When SMO transmits information about KPIs to O-RU, NETCONF commands such as [Table 15] may be exemplified. This may be related to step 1040 of FIG. 10.

[0332] [Table 15]

[0333]

[0334] Specifically, through [Table 15], SMO is <edit-config>An example is given of transmitting information about KPI value 5 to the O-RU using a command. FIG. 12 is a diagram illustrating signaling in which the O-RU transmits data to the SMO according to one embodiment.

[0335] According to FIG. 12, in step 1210, the O-RU (1201) can perform KPI labeling according to one embodiment.

[0336] In step 1220, SMO (1202) may request data from O-RU (1201). The data request may be made regardless of the step in which O-RU (1201) performs labeling.

[0337] The data requested by SMO (1202) may correspond to the information that SMO (1201) requests, such as data required, data related to specific KPIs, etc.

[0338] According to one embodiment, the data request of the SMO (1202) may correspond to a request for specific raw data by determining the state of the training data.

[0339] For example, SMO (1202) may request labeled raw data with a SINR of 10 dB or higher because the amount of raw data labeled for a KPI with a SINR of 10 dB or higher is insufficient compared to a certain standard.

[0340] Alternatively, if there are problems with training, such as when training was performed based on labeled raw data of a specific region but the level of training is below a certain threshold or there are issues related to the amount of data in that specific region, labeled raw data related to that specific region may be requested for training.

[0341] According to one embodiment, the data request of the SMO (1202) may correspond to a request for raw data labeled with a KPI associated with a specific time or a specific frequency.

[0342] For example, it may correspond to requests for raw data generated during the 1 hour when the most calls occur or during the 60 minutes of peak traffic (e.g., peak hours) when maximum traffic is applied, raw data related to band frequency information where interference is greater or less than a certain value.

[0343] According to one embodiment, the data request of the SMO (1202) may correspond to a raw data request related to a user-specific KPI.

[0344] For example, it may include requests for raw data regarding users that can be classified by KPIs related to specific criteria, such as raw data regarding users that can be classified as Line of Sight (LoS) related to cases where there are no obstacles between the transmitter and the receiver, or Non-Line of Sight (NLoS) related to cases where there are obstacles between the transmitter and the receiver, or raw data regarding users that have information about a specific spatial or region.

[0345] When SMO (1202) requests data from O-RU (1201) or receives requested data from O-RU (1201), the transmission node or related parameters may be exemplified by the YANG model as shown in [Table 16].

[0346] [Table 16]

[0347]

[0348] [Table 16] may include 'ai-ran-lcm', which is exemplified as the name of the YANG module, and 'raw-data', which is a container for data transmission, and may include 'usecase', which is a field representing a corresponding use case, exemplified as a leaf element constituting the data, 'data-id', which represents a data ID, 'compression-method' related to a data compression method (e.g., BFP, u-law, etc., as a method to reduce the size of raw data), 'raw-data-I', which represents the I (in-phase) data of the raw data composed of the above conditions, and / or 'raw-data-Q', which represents the Q (quadrature) data of the raw data composed of the above conditions. According to one embodiment, information about the data can be identified based on the 'raw-data-I' and 'raw-data-Q' fields.

[0349] When SMO (1202) requests data from O-RU (1201), NETCONF commands such as [Table 17] may be exemplified.

[0350] [Table 17]

[0351]

[0352] Specifically, [Table 17] applies when the raw data transmission method is associated with the YANG node. <get-config>This can be exemplified by a data request using a command. [Table 17] can be exemplified by a command indicating that the use case is related to CSI compression, the data ID is 100, and the condition related to the required KPI corresponds to 'above'.

[0353] In step 1230, O-RU (1201) can transmit data to SMO (1202).

[0354] The above data may correspond to data that meets the conditions related to the request of the SMO (1202). Alternatively, it may correspond to all data stored in the O-RU (1201).

[0355] In addition, the above data may correspond to all or part of the labeled data.

[0356] Additionally, the data transmission may be performed based on configuration information received from the SMO (1202). (e.g., configuration information for data transmission of the O-RU (1201))

[0357] Additionally, the data transmission may correspond to the transmission according to the first to fourth methods exemplified. In step 1240, the SMO (1202) may perform AI model training, etc. according to one embodiment based on the received data.

[0358] According to one embodiment, the O-RU (1201) can generate parameters related to [Table 16] for data transmission.

[0359] When O-RU (1201) transmits data to SMO (1202), NETCONF commands such as [Table 18] may be exemplified.

[0360] [Table 18]

[0361]

[0362] [Table 18] may exemplify a response to the request exemplified in [Table 17] above. Specifically, the use case is CSI compression, the data ID is 100, the compression method is u-law, and the I and Q data of the actual raw data are exemplified. According to one embodiment, the method by which the O-RU (1201) transmits data to the SMO (1202) may be in the form of a file, in which case the O-RU (1201) may transmit in the form of a file based on the configuration information transmitted by the SMO (1202).

[0363] For example, if the field exemplified by enable-file-upload in data-collection-config has a true value, the data transfer method may correspond to a file format. Additionally, if the field exemplified by enable-file-upload has a true value, O-RU (1201) can store raw data in a file format.

[0364] If the method of O-RU (1201) transmitting data to SMO (1202) is in the form of a file, parameters exemplified by [Table 19] or [Table 20] may be added to the existing module.

[0365] [Table 19]

[0366]

[0367] According to [Table 19], an example is provided of supporting file transfer in the existing o-ran-trace module by adding parameters included in the start-trace-raw-data and stop-trace-raw-data fields.

[0368] [Table 20]

[0369]

[0370] According to [Table 20], an example is provided of supporting file transfer in the existing o-ran-troubleshooting module by adding parameters included in the start-troubleshooting-raw-data and stop-troubleshooting-raw-data fields. Specifically, it may include AI-related use cases, information on KPIs, conditions for KPI values, etc., as exemplified according to the previously described embodiment. In addition, <status>It may include information regarding success or failure in relation to file transfer.

[0371] In addition, for the file format according to one embodiment, one or more data storage and transmission formats supported by the M-plane may be used.

[0372] For example, file formats such as '.gz', which uses the DEFLATE algorithm; '.lz4', which is based on the LZ4 algorithm; '.xz', which uses the LZMA2 algorithm; 'zip', which uses the DEFLATE algorithm; or '.csv', which stores data structures separated by commas.

[0373] FIG. 13 is a diagram illustrating signaling in which an O-RU transmits data to an SMO according to one embodiment.

[0374] Specifically, FIG. 13 can exemplify signaling when the method by which the O-RU transmits data to the SMO is in the form of a file or in the form of a file management method.

[0375] According to FIG. 13, in step 1310, O-RU (1301) can perform KPI labeling according to one embodiment.

[0376] In step 1320, SMO (1302) can request data from O-RU (1301).

[0377] In this case, step 1320 may include SMO (1302) indicating the file path or location of the raw data stored in O-RU (1301). For example, ' <rpc> <file-upload> <input> ...< / file-upload> < / rpc> The path location of the required data can be specified through the command. Additionally, regarding specific data requests, the content related to the embodiment of step 1220 of FIG. 12 may be applied.

[0378] In step 1330, O-RU (1301) can transmit data to SMO (1302).

[0379] The information transmitted in Step 1330 may include information regarding the approval or rejection of a file upload request. In the case of rejection, information regarding the reason for rejection may also be included. For example, ' <rpc> <file-upload> <output>...< / output> < / file-upload> < / rpc> This can be exemplified through the command of '. Additionally, regarding specific data transmission, the content related to the embodiment of step 1230 of FIG. 12 may be applied.

[0380] In step 1340, O-RU (1301) sends a completion message for the file upload to SMO (1302) (e.g., ' <notification> <upload-notification> ...< / upload-notification> < / notification> Can transmit ')

[0381] In step 1350, SMO (1302) can perform AI model training, etc. according to one embodiment based on the received data.

[0382] Using the above file management method, files can be transferred using the existing M-plane file management YANG module and NETCONF.

[0383] FIG. 14 is a diagram illustrating signaling in which an O-RU transmits data to an SMO according to one embodiment.

[0384] Specifically, FIG. 14 can exemplify signaling when the method by which the O-RU transmits data to the SMO is in the form of a file or in the form of a log management method.

[0385] According to FIG. 14, in step 1410, O-RU (1401) can perform KPI labeling according to one embodiment.

[0386] In step 1420, SMO (1402) can request data from O-RU (1401).

[0387] According to one embodiment, if the method by which the O-RU (1401) transmits data to the SMO (1402) is in the form of a file, a log management method may be used, and the request in step 1420 may include a request or information for troubleshooting and / or trace.

[0388] Specifically, troubleshooting is <rpc>It can be exemplified by a method that transmits only the collected logs up until a command is issued, and the trace is <rpc>This can be exemplified by a method that transmits only the logs collected from the point in time after the command was issued.

[0389] The request or information for troubleshooting and / or tracing that may be included in step 1420 above is information indicating the initiation of troubleshooting or tracing of the log management exemplified above (e.g., ' <rpc> <start-troubleshooting-raw-data> ...< / start-troubleshooting-raw-data> < / rpc> or <rpc> <start-trace-law-data> ...< / start-trace-law-data> < / rpc> Information indicating ) or suspension(' <rpc> <stop-troubleshooting-raw-data> ...< / stop-troubleshooting-raw-data> < / rpc> or <rpc> <stop-trace-law-data> ...< / stop-trace-law-data> < / rpc> It may include '). The information indicating the start may include use cases, KPIs, KPI values, information related to KPIs, etc., in relation to the required data. Additionally, regarding the specific data request, the content related to the embodiment of step 1220 of FIG. 12 may be applied.

[0390] According to one embodiment, for stopping after starting, information notifying the stop may be transmitted from the SMO (1402) to the O-RU (1401) separately from the request in step 1420.

[0391] In step 1430, the O-RU (1401) can send a response message from the O-RU (1401) to the SMO (1402), and the response message from the O-RU (1401) can be sent to the SMO (1402). For example, in the response message, ' <rpc-reply> ...< / rpc-reply> through <status>You can specify success or failure.

[0392] In step 1440, O-RU (1401) can transmit data to SMO (1402).

[0393] In addition, if a log management method is used, in step 1440 where data is transmitted, the data may include the generated log file. For example, 'notification> <troubleshooting-log-generated> ...< / troubleshooting-log-generated> < / status> < / rpc> < / rpc> < / status> < / notification> The log file generated through the ' command is ' <log-file-name>It can be transmitted as ' etc.

[0394] In step 1450, SMO (1402) can perform AI model training, etc. according to one embodiment based on the received data.

[0395] The above log management method can be exemplified by operating existing M-plane log management by creating new parameters. That is, it may be a method of collecting raw data through troubleshooting and / or tracing and transmitting the collected data to the SMO. Additionally, regarding specific data transmission, the details related to the embodiment of step 1230 of FIG. 12 may be applied.

[0396] FIG. 15 is a diagram illustrating the operation of an O-RU for performing KPI labeling and transmitting data according to one embodiment.

[0397] In step 1510, the O-RU may receive configuration information for data collection according to one embodiment from the SMO. The configuration information may include at least one of information related to data collection, information for KPI transmission or KPI setting, information related to KPI labeling, or information related to a transmission method. Additionally, prior to step 1510, the O-RU may request the configuration information from the SMO. Additionally, it may transmit a response to the SMO.

[0398] At step 1520, O-RU may receive information regarding KPIs according to one embodiment from O-DU or SMO. Additionally, prior to step 1520, O-RU may request information regarding KPIs from O-DU or SMO. The request for information regarding KPIs may include information regarding specific KPIs.

[0399] Information regarding KPIs may include information related to user context and information related to communication time (e.g., information for timing synchronization such as frame ID, slot ID, GPS timing, etc.). Additionally, information regarding communication performance (e.g., SINR, throughput, BLER, etc.) may be included. Alternatively, one or more related KPIs may be included.

[0400] Information that may be applied to or included in KPIs may include any specific information, elements, parameters, etc. required by the user or manager, and is not limited to the examples above.

[0401] As such, KPI labeling can be a process for SMO to quickly extract and analyze necessary information related to AI and ML from multiple data.

[0402] In step 1530, the O-RU can perform KPI labeling according to one embodiment based on information about the received KPI.

[0403] In step 1540, the O-RU can receive a data request from the SMO according to one embodiment.

[0404] The above data request can be made regardless of the step in which the O-RU performs labeling.

[0405] The data requested by the SMO may correspond to the information requested, such as data required by the SMO or data related to specific KPIs.

[0406] According to one embodiment, the data request of the SMO may correspond to a request for specific raw data by determining the state of the training data.

[0407] According to one embodiment, the data request of the SMO may correspond to a request for raw data labeled with a KPI related to a specific time or a specific frequency.

[0408] According to one embodiment, the data request of the SMO may correspond to a raw data request related to a user-specific KPI.

[0409] In step 1550, the O-RU can transmit data according to one embodiment to the SMO.

[0410] The above data may correspond to data that meets the conditions related to the SMO request. Alternatively, it may correspond to all data stored in the O-RU.

[0411] In addition, the above data may correspond to all or part of the labeled data.

[0412] In addition, the above data transmission may be performed based on configuration information received from the SMO. (e.g., configuration information for data transmission of the O-RU)

[0413] In addition, the above data transmission may correspond to a transmission according to the first to fourth methods exemplified.

[0414] According to one embodiment, the signaling associated with FIG. 15 can be performed using a C-plane or an M-plane.

[0415] FIG. 16 is a diagram illustrating the operation of an O-DU for transmitting KPI information according to one embodiment.

[0416] In step 1610, the O-DU may receive configuration information for data collection according to one embodiment from the SMO. Additionally, prior to step 1410, the O-RU may request configuration information from the SMO. Additionally, it may transmit a response to the SMO. Also, step 1610 may be omitted.

[0417] In step 1620, O-DU can transmit information about KPIs to SMO or O-RU.

[0418] FIG. 17 is a diagram illustrating the operation of an SMO that receives data according to an embodiment and performs AI learning.

[0419] In step 1710, the SMO may transmit configuration information for data collection according to one embodiment to the O-RU. Alternatively, the configuration information may also be transmitted to the O-DU. Additionally, a request for configuration information may be received from the O-RU or O-DU prior to step 1710.

[0420] In step 1720, SMO may transmit information regarding KPIs according to one embodiment to O-RU. The information regarding KPIs may be received from O-DU or received upon request. Additionally, step 1720 may be omitted when O-RU receives information regarding KPIs from O-DU, etc. Furthermore, prior to step 1720, SMO may receive a request for information regarding KPIs from O-RU.

[0421] In step 1730, SMO may request data from O-RU according to one embodiment.

[0422] In step 1740, SMO can receive data from O-RU according to one embodiment.

[0423] In step 1750, SMO can perform learning or training related to AI or ML. Additionally, SMO can perform LCM, AI-related module updates, etc. based on the received data.

[0424] FIG. 18 is a drawing showing an example of the structure of a terminal according to one embodiment.

[0425] Referring to FIG. 18, a terminal (1800) according to one embodiment of the present disclosure may be configured to include a control unit (1801), a transceiver (1802), and a memory (1803). In the present disclosure, the control unit (1801) of the terminal (1800) may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0426] The control unit (1801) can control the overall operation of the terminal (1800) according to one embodiment proposed in the present disclosure. For example, the control unit (1801) can control the signal flow between each block to perform an operation according to the drawing (or flowchart, flowchart) described above.

[0427] The transmitting and receiving unit (1802) can transmit and receive signals. The transmitting and receiving unit (1802) can, for example, transmit a signal to a node or base station according to one embodiment of the present disclosure and receive a signal from the node or base station. The transmitting and receiving unit (1802) can transmit and receive signals with other network entities.

[0428] The memory (1803) can store at least one of the information transmitted and received through the transmission and reception unit (1802) and the information generated through the control unit (1801). Additionally, the memory (1803) may be defined as a storage unit.

[0429] FIG. 19 is a drawing showing an example of the structure of a base station according to one embodiment.

[0430] Referring to FIG. 19, a base station (1900) according to one embodiment of the present disclosure may be configured to include a control unit (1901), a transceiver (1902), and a memory (1903). In the present disclosure, the control unit (1901) of the base station (1900) may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0431] The above base station (1900) may be an O-RAN, an O-DU, or an O-RU.

[0432] The control unit (1901) can control the overall operation according to one embodiment proposed in the present disclosure. For example, the control unit (1901) can control the signal flow between each block to perform the operation according to the drawing (or flowchart, flowchart) described above.

[0433] The transmitting and receiving unit (1902) can transmit and receive signals. The transmitting and receiving unit (1902) can transmit a signal to a terminal, another base station, another network entity or node according to one embodiment of the present disclosure, for example, and receive a signal from the terminal, another base station, another network entity or node.

[0434] The memory (1903) can store at least one of the information transmitted and received through the transmission and reception unit (1902) and the information generated through the control unit (1901). Additionally, the memory (1903) may be defined as a storage unit.

[0435] Methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0436] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of this disclosure.

[0437] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM), magnetic disc storage devices, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0438] Additionally, the program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present disclosure through an external port.

[0439] In addition, a separate storage device on a communication network may be connected to the device performing the embodiment of the present disclosure.

[0440] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0441] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples provided to facilitate the explanation of the technical content of the present disclosure and to aid in understanding the present disclosure, and are not intended to limit the scope of the present disclosure. That is, it is obvious to those skilled in the art that other variations based on the technical concept of the present disclosure are possible.

[0442] It should be noted that the configuration diagrams, example diagrams of control / data signal transmission methods, example diagrams of operation procedures, and configuration diagrams illustrated in each of the above drawings are not intended to limit the scope of the present disclosure. That is, all components, entities, or steps of operation described in each of the above drawings should not be interpreted as essential components for the implementation of the disclosure, and may be implemented to the extent that the essence of the disclosure is not compromised even if only some components are included.

[0443] Furthermore, the commands or components exemplified in each of the above tables should not be interpreted as essential components, and may be implemented to the extent that the essence of the present disclosure is not compromised even if only some components are included. Additionally, the commands exemplified in each table are examples for embodying the signaling related to the present invention and do not limit signaling to other methods.

[0444] In addition, each of the above embodiments can be combined and operated as needed.

[0445] Meanwhile, the order of description in the drawings illustrating the method of the present disclosure does not necessarily correspond to the order of execution, and the order of execution may be changed or executed in parallel.

[0446] Alternatively, drawings describing the method of the present disclosure may omit some components and include only some components to the extent that the essence of the present disclosure is not impaired.

[0447] In addition, the method of the present disclosure may be implemented by combining some or all of the contents included in each embodiment to the extent that it does not impair the essence of the present disclosure. < / notification> < / rpc-reply> < / get> < / get> < / edit> < / config>

Claims

1. A method performed by an O-RU (open radio unit) of a communication system, A step of receiving information about at least one indicator for training an AI (artificial intelligence) model; A step of identifying one or more data for training the AI ​​model based on information regarding at least one indicator for training the AI ​​model; A step of receiving a request for at least one of the identified data from SMO (service management and orchestration); and A method comprising the step of transmitting at least one of the identified data to the above SMO based on the above request.

2. In Paragraph 1, A step of receiving configuration information for collecting the data from the above SMO; Step of applying the above setting information; and A method comprising the step of transmitting information related to the result of applying the above-mentioned setting information to the above-mentioned SMO.

3. In Paragraph 2, A step of receiving a request for all or part of the configuration information from an O-DU (open distributed unit); and A method comprising the step of transmitting all or part of the setting information to the above O-DU.

4. In Paragraph 1, Information regarding at least one metric for training the above AI model is received from the above SMO or O-DU (open distributed unit) based on the M (management)-plane or C (control)-plane, and The above O-RU transmits or receives a signal to the above SMO based on the M-plane, and A method comprising the step of identifying one or more data for training the AI ​​model, wherein the step of labeling one or more data collected by the O-RU is based on information regarding at least one indicator for training the AI ​​model.

5. In a method performed by the service management and orchestration (SMO) of a communication system, A step of transmitting a request to an O-RU (open radio unit) for at least one of the data for training an AI (artificial intelligence) model; and The method includes the step of receiving at least one of one or more data for training the AI ​​model from the above O-RU, and A method characterized in that one or more data for training the AI ​​model are identified based on information regarding at least one indicator for training the AI ​​model.

6. In Paragraph 5, A step of transmitting configuration information for collecting the data to the above O-RU; and A method comprising the step of receiving information related to the result of applying the setting information from the above O-RU.

7. In Paragraph 5, A step of transmitting configuration information for collecting the above data to an O-DU (open distributed unit); A step of receiving information related to the result of applying the setting information from the above O-DU; A step of receiving information regarding at least one indicator for training the AI ​​model from the above O-DU; and The method includes the step of transmitting information about at least one indicator for AI model training to the O-RU based on the M(management)-plane. The above SMO transmits or receives a signal to the above O-RU based on the M-plane, and A method characterized in that the one or more data for training the AI ​​model are labeled based on information regarding the at least one indicator for training the AI ​​model, wherein one or more data collected by the O-RU are labeled.

8. In the O-RU (open radio unit) of a communication system, Transmitter / receiver; and Connected to the above-mentioned transmitting and receiving unit, and receiving information on at least one indicator for AI (artificial intelligence) model training, Based on information regarding at least one indicator for training the AI ​​model, one or more data for training the AI ​​model are identified, and Receiving a request for at least one of the identified data from SMO (service management and orchestration), and An O-RU comprising a control unit that transmits at least one of the identified data to the above SMO based on the above request.

9. In claim 8, the control unit is, From the above SMO, receive configuration information for collecting the above data, and Apply the above setting information, and An O-RU that transmits information related to the result of applying the above-mentioned setting information to the above-mentioned SMO.

10. In claim 9, the control unit is, Receiving a request for all or part of the above configuration information from an O-DU (open distributed unit), and An O-RU that transmits all or part of the above configuration information to the above O-DU.

11. In Paragraph 8, Information regarding at least one metric for training the above AI model is received from the above SMO or O-DU (open distributed unit) based on the M (management)-plane or C (control)-plane, and The above O-RU transmits or receives a signal to the above SMO based on the M-plane, and An O-RU characterized in that identifying one or more data for the AI ​​model training involves the control unit labeling one or more data collected by the O-RU based on information regarding at least one indicator for the AI ​​model training.

12. In the service management and orchestration (SMO) of communication systems, Transmitter / receiver; and Connected to the above-mentioned transceiver, and transmits a request for at least one of the data for training an AI (artificial intelligence) model to an O-RU (open radio unit), and The control unit receives at least one of one or more data for training the AI ​​model from the above O-RU, and The SMO is characterized in that the one or more data for training the AI ​​model are identified based on information regarding at least one indicator for training the AI ​​model.

13. In claim 12, the control unit is, Transmit configuration information for collecting the data to the above O-RU, and SMO receiving information related to the result of applying the above-mentioned setting information from the above-mentioned O-RU.

14. In claim 12, the control unit is, Transmit configuration information for collecting the above data to the O-DU (open distributed unit), and An SMO that receives information related to the result of applying the above-mentioned setting information from the above-mentioned O-DU.

15. In claim 12, the control unit is, Receive information regarding at least one indicator for training the AI ​​model from an O-DU (open distributed unit), and To the above O-RU, information regarding the above at least one indicator for training the AI ​​model is transmitted based on the M(management)-plane, and The above SMO transmits or receives a signal to the above O-RU based on the M-plane, and The SMO is characterized in that the one or more data for training the AI ​​model are labeled based on information regarding the at least one indicator for training the AI ​​model, and the one or more data collected by the O-RU are labeled.

Images