Method and device for transmitting and receiving data through fronthaul interface in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a data transmission rate higher than that of a 4G communication system such as LTE. The disclosure relates to a wireless communication system. More particularly, the present disclosure relates to a method and device therefor, the method comprising: determining information for identifying a type of data; transmitting, to an open-radio unit (O-RU), a first control message including the information for identifying the type of data; and receiving, from the O-RU, a second control message including the data in response to the first control message.

Description

Method and device for transmitting and receiving data through a fronthaul interface in a wireless communication system

[0001] The present disclosure relates to a wireless communication system, and more particularly, to a method and apparatus for transmitting and receiving data through an open fronthaul interface in a wireless communication system.

[0002] Looking back at the evolution of wireless communication over successive generations, technologies have primarily been developed for human-facing services such as voice, multimedia, and data. With the commercialization of 5G (5th-generation) communication systems, an explosive increase in connected devices is 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 equipment, and factory equipment. Mobile devices are expected to evolve into diverse form factors, including augmented reality glasses, virtual reality headsets, and holographic devices. In the 6th-generation (6G) era, efforts are being made to develop improved 6G communication systems to connect hundreds of billions of devices and objects and provide diverse services. For this reason, 6G communication systems are often referred to as "beyond 5G."

[0003] The 6G communication system, expected to be realized around 2030, will have a maximum transmission speed of terabytes per second (i.e., 1,000 gigabits per second) and a wireless latency of 100 microseconds (μsec). In other words, compared to 5G, the transmission speed in a 6G communication system will be 50 times faster, while the wireless latency will be reduced to one-tenth.

[0004] To achieve these high data rates and ultra-low latency, 6G communication systems are being considered for implementation in the terahertz band (e.g., from 95 gigahertz (GHz) to 3 terahertz (THz)). Compared to the millimeter wave (mmWave) band introduced in 5G, the terahertz band is expected to experience more severe path loss and atmospheric absorption, making it more crucial to ensure signal reach, or coverage, in this band. Key technologies to ensure coverage include radio frequency (RF) components, antennas, new waveforms that offer better coverage than OFDM (orthogonal frequency division multiplexing), beamforming, and multiple antenna transmission technologies such as massive multiple-input and multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas. In addition, new technologies such as metamaterial-based lenses and antennas, high-dimensional spatial multiplexing using orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RIS) are being discussed to improve the coverage of terahertz band signals.

[0005] In addition, in order to improve frequency efficiency and system network, 6G communication systems are developing full duplex technology that utilizes the same frequency resources for uplink and downlink at the same time; network technology that integrates satellites and high-altitude platform stations (HAPS); network structure innovation technology that supports mobile base stations and enables optimization and automation of network operation; dynamic spectrum sharing technology through collision avoidance based on spectrum usage prediction; AI-based communication technology that utilizes artificial intelligence (AI) 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 with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources (mobile edge computing (MEC), cloud, etc.). In addition, efforts are being made to further strengthen connectivity between devices, further optimize networks, promote softwareization of network entities, and increase the openness of wireless communications 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 use of data, and the development of technologies for maintaining privacy.

[0006] Research and development of these 6G communication systems are expected to enable a new level of hyper-connected experience (the next hyper-connected experience) through the hyper-connectivity of 6G communication systems, which encompass not only connections between things but also connections between people and things. Specifically, 6G communication systems are expected to enable 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 through enhanced security and reliability, will find application in diverse fields such as industry, medicine, automobiles, and home appliances.

[0007] A method performed by an Open-Distributed Unit (O-DU) in a wireless communication system according to one embodiment of the present disclosure may include the steps of: determining information identifying a type of data; transmitting a first control message including information identifying the type of data to an Open-Radio Unit (O-RU); and receiving a second control message including data from the O-RU in response to the first control message.

[0008] In a wireless communication system according to one embodiment of the present disclosure, an Open-Distributed Unit (O-DU) includes a transceiver; and at least one processor coupled to the transceiver, wherein the at least one processor determines information identifying a type of data, transmits a first control message including the information identifying the type of data to an Open-Radio Unit (O-RU), and receives a second control message including data from the O-RU in response to the first control message.

[0009] FIG. 1 is a block diagram illustrating the structure of an Open-Distributed Unit (O-DU) and an Open-Radio Unit (O-RU) according to one embodiment of the present disclosure.

[0010] FIG. 2 is a diagram illustrating an Open-Radio Access Network (O-RAN) structure according to one embodiment of the present disclosure.

[0011] FIG. 3 is a diagram illustrating examples of a control plane (C-Plane) message and a user plane (U-Plane) message according to one embodiment of the present disclosure.

[0012] FIG. 4 is a diagram illustrating an example of an O-RAN fronthaul function splitting option according to one embodiment of the present disclosure.

[0013] FIG. 5 is a diagram for explaining a method of defining parameters for data types in a management plane (M-Plane) according to one embodiment of the present disclosure.

[0014] FIG. 6 is a diagram illustrating a method for requesting data using a first control message according to one embodiment of the present disclosure.

[0015] FIG. 7 is a diagram for explaining a method of requesting data or updating a data type using a section extension type (SET) according to one embodiment of the present disclosure.

[0016] FIGS. 8A and 8B are diagrams illustrating a method of receiving data using a second control message according to one embodiment of the present disclosure.

[0017] FIGS. 9A and 9B are diagrams illustrating examples of a first control message including instruction information for ndm (non-delay managed) and information about a transmission window size according to one embodiment of the present disclosure.

[0018] FIG. 10 is a diagram for explaining changes in fronthaul data rate (F / H data rate) according to instruction information for ndm according to one embodiment of the present disclosure.

[0019] FIG. 11 is a flowchart illustrating a method of transmitting and receiving data between an O-DU and an O-RU according to one embodiment of the present disclosure.

[0020] The operating principles of the present disclosure are described in detail below with reference to the attached drawings. In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Furthermore, the terms described below are defined based on the functions of the present disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the overall content of this specification.

[0021] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

[0022] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0023] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0024] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, 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'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0025] In the following description of the present disclosure, detailed descriptions of related known functions or configurations will be omitted if they are deemed to unnecessarily obscure the gist of the present disclosure. Hereinafter, embodiments of the present disclosure will be described with reference to the attached drawings.

[0026] The terms used in this invention have been selected from widely used, current terms, taking into account the functions of the invention. However, these terms may vary depending on the intentions of those skilled in the art, precedents, the emergence of new technologies, etc. Furthermore, in certain cases, terms may be arbitrarily selected by the applicant, in which case their meanings will be described in detail in the relevant description of the invention. Therefore, the terms used in this invention should not be defined simply as names, but rather based on their inherent meanings and the overall content of the invention.

[0027] When a part of the specification is said to "include" a component, this does not exclude other components, but rather implies the inclusion of other components, unless otherwise specifically stated. Furthermore, terms such as "part," "module," etc., used throughout the specification refer to a unit that processes at least one function or operation, which may be implemented in hardware, software, or a combination of hardware and software.

[0028] Additionally, the description 'at least one of A, B, and C' means that it can be any one of 'A', 'B', 'C', 'A and B', 'A and C', 'B and C', and 'A, B, and C'.

[0029] It should be understood that the combinations of blocks and sequence diagrams in each flowchart can be performed by one or more computer programs containing computer-executable instructions. The one or more computer programs may be stored entirely in a single memory or may be divided and stored in multiple different memories.

[0030] All functions or operations described in this document may be performed by a single processor or a combination of processors. A single processor or a combination of processors is a circuitry that performs processing, and may include circuitry such as an Application Processor (AP), a Communication Processor (CP), a Graphical Processing Unit (GPU), a Neural Processing Unit (NPU), a Microprocessor Unit (MPU), a System on Chip (SoC), or an Integrated Chip (IC).

[0031] A processor may include various processing circuits and / or multiple processors. For example, the term "processor" as used herein, including in the claims, may include various processing circuits, including at least one processor. One or more processors in at least one processor may be configured to perform various functions described herein, individually and / or collectively, in a distributed fashion. As used herein, "processor," "at least one processor," and "one or more processors" may be configured to perform multiple functions. However, these terms encompass, without limitation, situations where one processor performs some of the functions and other processor(s) perform other parts of the functions, and situations where a single processor may perform all of the functions. Furthermore, at least one processor may include a combination of processors that perform various of the disclosed functions in a distributed manner. At least one processor may execute program instructions to achieve or perform various functions.

[0032] Below, with reference to the attached drawings, embodiments of the present invention are described in detail so that those skilled in the art can easily implement the present invention. However, the present invention can be implemented in various different forms and is not limited to the embodiments described herein. In the drawings, parts irrelevant to the description have been omitted to clearly explain the present invention, and similar parts have been designated with similar reference numerals throughout the specification.

[0033] FIG. 1 is a block diagram illustrating the structure of an O-DU (Open-Distributed Unit) (100) and an O-RU (Open-Radio Unit) (130) according to one embodiment of the present disclosure.

[0034] Referring to FIG. 1, the O-DU (100) may include a transceiver (110) and a processor (120). However, the components of the O-DU (100) are not limited to the examples described above. For example, the O-DU (100) may include more or fewer components than the components described above. In addition, the processor (120) and the transceiver (110) may be implemented in the form of a single chip.

[0035] In one embodiment, the processor (120) may control a series of processes that enable the O-DU (100) to operate according to an embodiment of the present disclosure. For example, the processor may control components of the O-DU (100) to transmit and receive signals in a wireless communication system according to an embodiment of the present disclosure. There may be a plurality of processors (120), and the processors (120) may perform operations for transmitting and receiving signals in the wireless communication system of the present disclosure by executing a program stored in a memory (not shown).

[0036] In one embodiment, the transceiver (110) can transmit and receive signals with the O-RU (130). The signals transmitted and received with the O-RU (130) can include control information and data. The transceiver (110) can be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, an RF receiver that low-noise amplifies the received signal and down-converts the frequency, etc. However, the transceiver (110) is only one embodiment, and the components of the transceiver (110) are not limited to the RF transmitter and the RF receiver. In addition, the transceiver (110) can receive a signal through a wireless channel and output it to the processor (120), and transmit a signal output from the processor (120) through the wireless channel.

[0037] In one embodiment, the O-RU (130) may include a transceiver unit (140) and a processor (150). However, the components of the O-RU (130) are not limited to the examples described above. For example, the O-RU (130) may include more or fewer components than the components described above. In addition, the processor (150) and the transceiver unit (140) may be implemented in the form of a single chip.

[0038] In one embodiment, the processor (150) may control a series of processes that enable the O-RU (130) to operate according to an embodiment of the present disclosure. For example, the processor may control components of the O-RU (130) to transmit and receive signals in a wireless communication system according to an embodiment of the present disclosure. There may be a plurality of processors (150), and the processors (150) may perform operations for transmitting and receiving signals in the wireless communication system of the present disclosure by executing a program stored in a memory (not shown).

[0039] In one embodiment, the transceiver (140) can transmit and receive signals with the O-DU (100). The signals transmitted and received with the O-DU (100) can include control information and data. The transceiver (140) can be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, an RF receiver that low-noise amplifies the received signal and down-converts the frequency, etc. However, the transceiver (140) is only one embodiment, and the components of the transceiver (140) are not limited to the RF transmitter and the RF receiver. In addition, the transceiver (140) can receive a signal through a wireless channel and output it to the processor (150), and transmit a signal output from the processor (150) through the wireless channel.

[0040] FIG. 2 is a diagram illustrating an Open-Radio Access Network (O-RAN) structure according to one embodiment of the present disclosure.

[0041] Referring to FIG. 2, the O-RAN architecture may include a Service Management Orchestration (SMO) (210), a non-RT non-Real Time RAN Intelligent Controller (non-RT RIC) (220), a near-RT near-Real Time RAN Intelligent Controller (near-RT RIC) (230), an O-CU (Central Unit) (240), an O-DU (100), and an O-RU (130). However, the components of the O-RAN architecture are not limited to the examples described above. For example, the O-RAN architecture may include more or fewer components than the components described above.

[0042] In one embodiment, O-RAN refers to an open radio access network, which supports openness, interoperability, vendor neutrality, and network flexibility and scalability. In one embodiment, O-RAN may be composed of an internal RAN structure comprised of an O-CU (240), an O-DU (100), and an O-RU (130), and an external RAN structure represented by a RIC.

[0043] In one embodiment, the SMO (210) may be a component that performs management, coordination, and optimization functions of services, resources, and networks in an O-RAN architecture. For example, the SMO (210) may include the Open Network Automation Platform (ONAP), an open source Linux-based automation platform.

[0044] In one embodiment, the RIC (220, 230) may be a component that manages, controls, and optimizes RAN functions by utilizing artificial intelligence (AI) and machine learning (ML) technologies. In one embodiment, the RIC (220, 230) may be responsible for AI / ML functions. In one embodiment, the RIC (220, 230) may be divided into a non-RT RIC (220) and a near-RT RIC (230).

[0045] In one embodiment, the non-RT RIC (220) may be a non-real-time RIC. In one embodiment, the non-RT RIC (220) may perform management and control of the RAN in network situations where real-time response is not required, and may manage general aspects of network operation, such as network resource allocation and service optimization.

[0046] In one embodiment, an rApp (Radio Application) may refer to an AI / ML application running on a non-RT RIC (220). In one embodiment, an rApp may be used to provide a specific radio service or function, efficiently utilize radio resources, and control and optimize the radio aspects of the RAN.

[0047] In one embodiment, the near-RT RIC (230) may be a real-time operating RIC. In one embodiment, the near-RT RIC (230) may make decisions or perform control tasks in real time to meet fast and dynamic demands within the network, such as fault handling, interference management, and dynamic allocation of radio resources.

[0048] In one embodiment, an xApp (Extended Application) may be an AI / ML application running on a near-RT RIC (230). In one embodiment, an xApp may be an application used to extend and complement various functions of a RAN. In one embodiment, an xApp may perform a wider range of functions than an rApp, and may be utilized for network management and optimization by applying AI / ML technologies to more diverse and complex network functions.

[0049] In one embodiment, the O-CU (240) performs central control of the RAN and may be a component that manages and controls the O-DU (100) and the O-RU (130). In one embodiment, the O-CU (240) may include a CU-CP (CU-Control Plane) and a CU-UP (CU-User Plane). In one embodiment, the O-CU (240) may be represented as CU (240).

[0050] In one embodiment, the O-DU (100) may be a component that processes digital radio signals and user data, and manages and optimizes network resources. The O-DU (100) may perform functions previously performed at a base station. In one embodiment, the O-DU (100) may be represented as DU (100).

[0051] In one embodiment, the O-RU (130) may be a component that provides a wireless interface of the RAN. In one embodiment, the O-RU (130) may generate and receive wireless signals to communicate with the O-DU (100) and perform communication with the user device. In one embodiment, the O-RU (130) may be indicated as RU (130).

[0052] In one embodiment, the O-DU (100) and the O-RU (130) may be included in a single base station or may be located at separate locations. In one embodiment, the O-DU (100) and the O-RU (130) may have a separate structure or an integrated structure. In one embodiment, the O-DU (100) and the O-RU (130) may be connected via a fronthaul interface (F / H interface).

[0053] In one embodiment, the RIC (220, 230) may perform data collection from the O-CU (240), the O-DU (100), and the O-RU (130) to train, re-train, and infer an AI / ML model for RAN operation control. In one embodiment, the non-RT RIC (220) may perform data collection from the O-CU (240) and the O-DU (100) via an O1 interface. In one embodiment, the near-RT RIC (230) may perform data collection from the O-CU (240) and the O-DU (100) via an E2 interface.

[0054] In one embodiment, the interface connecting the RIC (220, 230) and the O-RU (130) may not be defined. In one embodiment, the RIC (220, 230) may perform data collection through the O-DU (100) to collect data of the O-RU (130). In one embodiment, the RIC (220, 230) may receive wireless interface information and data transmitted from the O-RU (130) to the O-DU (100) from the O-DU (100). In one embodiment, the RIC (220, 230) may acquire (or receive) data of the O-RU (130) from the O-DU (100) through an open fronthaul interface connecting the O-DU (100) and the O-RU (130).

[0055] In one embodiment, the Open Fronthaul Interface may refer to an interface defined for I / Q (In-band / Quadrature) data transmission between the O-DU (100) and the O-RU (130). In one embodiment, the Open Fronthaul Interface may be composed of a control plane (C-Plane), a user plane (U-Plane), and a management plane (M-Plane, Management-Plane).

[0056] In one embodiment, the control plane (C-Plane) may refer to a protocol for controlling data transmission. In one embodiment, the control plane (C-Plane) may include control information for a specific range of user plane (U-Plane) data symbols and physical resource blocks (PRBs) that can be commonly processed using at least one section and section extension.

[0057] In one embodiment, the user plane (U-Plane) may refer to a protocol that transmits actual data. In one embodiment, the user plane (U-Plane) may include I / Q data that utilizes control information (e.g., Beamforming Weight (BFW), compression parameters, etc.) of the control plane (C-Plane) within a range defined by the control plane (C-Plane).

[0058] In one embodiment, the management plane (M-Plane) may refer to a protocol for providing management functions. In one embodiment, the management plane (M-Plane) may use an open interface based on NETCONF / YANG for remote initialization and configuration of the O-RU (130) and management functions. In one embodiment, the management plane (M-Plane) may store parameter values ​​that can be used in the O-DU (100) and O-RU (130) in the control plane (C-Plane). In one embodiment, parameters defined in the management plane (M-Plane) may be called and used in the O-DU (100) and O-RU (130).

[0059] FIG. 3 is a diagram illustrating examples of a control plane (C-Plane) message (310) and a user plane (U-Plane) message (320) according to one embodiment of the present disclosure.

[0060] Referring to FIG. 3, a control plane (C-Plane) message (310) may play a role in controlling a user plane (U-Plane) prior to transmitting a user plane (U-Plane) message (320) that transmits user I / Q data. In one embodiment, the control plane (C-Plane) message (310) may include information such as an area of ​​resources allocated on a resource block grid (RB grid) within one slot for each layer, information on the area, and beam information to be applied to the area, and may be transmitted from an O-DU (100) to an O-RU (130) through the concept of a section.

[0061] In one embodiment, the beam information may include beam information per section or beam information per layer. In one embodiment, the beam information may include a weight vector of the length of the number of antennas to be multiplied by the section. In one embodiment, the beam weight vector may be multiplied with the I / Q data of the section area.

[0062] In one embodiment, a section may represent a characteristic of user plane (U-Plane) data transmitted or received from a beam having a single pattern identifier (ID) within the application common header. In one embodiment, a section may be 8 bits and may have 256 types called section types.

[0063] In one embodiment, six section types may be defined. In one embodiment, section type 0 may be used to indicate idle or guard periods of the O-DU (100) and the O-RU (130). In one embodiment, section type 1 may be used for most downlink (DL) and uplink (UL) radio channels. In one embodiment, section type 3 may be used for the Physical Random Access Channel (PRACH) and mixed-numerology channels. In one embodiment, section type 5 may be used for terminal scheduling information. In one embodiment, section type 6 may be used to transmit channel information for a specific terminal ID. In one embodiment, section type 7 may be used to support License Assisted Access (LAA).

[0064] In one embodiment, a user plane (U-Plane) message (320) may be used to transmit a user's I / Q data. In one embodiment, the user plane (U-Plane) message (320) may transmit the user's I / Q data from an O-DU (100) to an O-RU (130) or from an O-RU (130) to an O-DU (100) based on control information contained in the control plane (C-Plane) for a user plane (U-Plane) message (320) having the same sectionId transmitted in a control plane (C-Plane) message (310).

[0065] In one embodiment, a user plane (U-Plane) message (320) may be used to transmit user I / Q modulation information or I / Q data in the frequency domain. In one embodiment, a user plane (U-Plane) message (320) may be used to transmit modulated information such as iSample, qSample, etc.

[0066] FIG. 4 is a diagram illustrating an example of an O-RAN fronthaul function splitting option according to one embodiment of the present disclosure.

[0067] Referring to Figure 4, the fronthaul function splitting option is 3GPP (3 rd This may refer to a functional split option proposed by the 7.2x Generation Partnership Project to alleviate high throughput requirements for fronthaul interfaces. In one embodiment, the 7.2x functional split option may refer to an intra-PHY functional split option defined by the O-RAN Alliance.

[0068] In one embodiment, the O-DU (100) in the fronthaul function split option can perform a function of the upper side (PHY-high) within the PHY, and the O-RU (130) in the fronthaul function split option can perform a function of the lower side (PHY-low) within the PHY.

[0069] In one embodiment, the first option (410) may represent an option for the O-DU (100) to perform channel estimation, beamforming weight calculation, and equalization.

[0070] In one embodiment, the second option (420) may represent an option in which the O-RU (130) performs channel estimation and beamforming weight calculation, and the O-DU (100) performs equalization. In one embodiment, the second option (420) may be referred to as a DMRS-BF-NEQ option.

[0071] In one embodiment, the third option (430) may indicate an option for the O-RU (130) to perform channel estimation, beamforming weight calculation, and equalization. In one embodiment, the third option (430) may be referred to as the DMRS-BF-EQ option.

[0072] In one embodiment, the second option (420) and the third option (430) may be those proposed in the ULPI (Uplink Performance Improvement) among the open fronthaul work items (WI) in progress at O-RAN WG4 (Working Group 4). In one embodiment, the O-RU (130) in the second option (420) and the third option (430) may perform functions such as channel estimation and beamforming weight calculation to reduce the fronthaul bandwidth. In one embodiment, the O-RU (130) in the second option (420) and the third option (430) may determine BFW using channel information based on DMRS, etc.

[0073] In one embodiment, in the second option (420) and the third option (430), channel information, SRS (Sounding Reference Signal) signal, DMRS (Demodulation Reference Signal) signal, BFW (Beamforming Weight) information, etc. may not be transmitted from the O-RU (130) to the O-DU (100). In one embodiment, in the second option (420) and the third option (430), channel information, SRS (Sounding Reference Signal) signal, DMRS (Demodulation Reference Signal) signal, BFW (Beamforming Weight) information, etc. may not be transmitted to the RIC (220, 230).

[0074] In one embodiment, for the second option (420) and the third option (430), since the results of channel estimation using SRS, DMRS, etc. or the SRS / DMRS-based BFW results are not transmitted from the O-RU (130) to the O-DU (100), the RIC (220, 230) may have limitations in collecting air interface data for training, re-training, and inference of AI / ML required in the AI-Native structure.

[0075] There is a standardization tendency not to transmit channel information, BFW, etc. from O-RU (130) to O-DU (100) to reduce the fronthaul data rate, and this tendency may continue as the number of antenna ports and layers increases compared to the limited fronthaul capacity.

[0076] Although the O1 and E2 interfaces that can transmit the necessary air interface information to the RIC (220, 230) in the AI-native structure are defined, the functions for AI / ML are not considered in the fronthaul interface between the O-DU (100) and the O-RU (130).

[0077] In this disclosure, we propose a 6G open fronthaul interface for smooth data collection in the AI-native architecture being considered in 6G O-RAN. In cases where not all air interface information is always transmitted from the O-RU (130) to the O-DU (100) in accordance with the current direction of O-RAN standardization, we define a fronthaul interface through which the O-DU (100) can request data required for AI / ML from the O-RU (130). We propose new control plane (C-Plane) messages so that the O-RU (130) can transmit data required by each rApp or xApp at the time requested by the RIC (220, 230) instead of always sending raw data required for AI / ML to the O-DU (100). We also propose a control plane (C-Plane) message format and non-delay managed (ndm) traffic in the control plane (C-Plane) that can make the raw data transmission a little more efficient.

[0078] FIG. 5 is a diagram illustrating a method for defining parameters for data types in a management plane (M-Plane) according to one embodiment of the present disclosure.

[0079] Referring to FIG. 5, parameters for data types may be defined in the management plane (M-Plane). In one embodiment, parameters for data types may be defined in the management plane (M-Plane) as a bitmap. In one embodiment, parameters for combinations of data types may be defined in the management plane (M-Plane).

[0080] In one embodiment, parameters for data types may be set in the management plane (M-Plane). In one embodiment, parameters for data types may be set in the management plane (M-Plane) as a bitmap. In one embodiment, parameters for combinations of data types may be set in the management plane (M-Plane).

[0081] In one embodiment, the parameter for the data type may be a management plane (M-Plane) parameter. In one embodiment, since the parameter for the data type is defined (or set, stored) in the management plane (M-Plane), the O-DU (100) can call the parameter defined (or set, stored) in the management plane (M-Plane) and request it to the O-RU (130).

[0082] In one embodiment, parameters required for data collection in an AI-native architecture may be defined in the management plane (M-Plane). In one embodiment, the types of data required from the O-RU (130) for training, re-training, and inference in an rApp or xApp may be defined in the management plane (M-Plane).

[0083] In one embodiment, if a specific type of data is required in an rApp or an xApp, the specific type of data may be defined in the management plane (M-Plane). In one embodiment, the O-DU (100) may be configured to call data types corresponding to the specific type of data. For example, the data types may include SRS-based channel information (SRS-based CI), DMRS-based channel information (DMRS-based CI), SRS-based BFW, and DMRS-based BFW. However, the present invention is not limited thereto.

[0084] In one embodiment, parameters for data types may be defined in the management plane (M-Plane) as a bitmap. In one embodiment, parameters for data types may be defined and managed in the management plane (M-Plane) as a table.

[0085] In one embodiment, the O-DU (100) can share the data types defined in the management plane (M-Plane) with the O-RU (130). In one embodiment, the O-RU (130) can store the data types received from the O-DU (100).

[0086] In one embodiment, the O-DU (100) can manage to request data from the O-RU (130) by displaying the corresponding data type as a bitmap. In one embodiment, the O-DU (100) can display the requested data or data type as a bitmap.

[0087] In one embodiment, when the O-DU (100) calls for specific data or data type, the O-DU (100) can request the specific data or data type with a control plane (C-Plane) message using a bitmap.

[0088] Referring to Table 510, if the value of a specific data type field is 1, it may mean that the corresponding specific data type is requested. In one embodiment, if the value of a specific data type field is 0, it may mean that the corresponding specific data type is not requested.

[0089] In one embodiment, by indicating the value of a specific data type field as 1, the O-DU (100) can indicate (or inform) the O-RU (130) that a specific data type is required. In one embodiment, by indicating the value of a specific data type field as 0, the O-DU (100) can indicate (or inform) the O-RU (130) that a specific data type is not required.

[0090] For example, when SRS-based channel information (SRS-based CI) and SRS-based BFW are required, the O-DU (100) may display the value of the field corresponding to the SRS-based channel information (SRS-based CI) and the value of the field corresponding to the SRS-based BFW as 1, and display the values ​​of the remaining fields as 0.

[0091] In one embodiment, the O-DU (100) may determine information identifying the type of data. In one embodiment, the information identifying the type of data may include information that can identify the type of data requested by the O-DU (100) to the O-RU (130). In one embodiment, the information identifying the type of data may be information included in a parameter for the data type.

[0092] In one embodiment, information identifying the type of data may be included in parameters defined in the management plane (M-Plane). In one embodiment, the O-DU (100) may request the O-RU (130) to include information identifying the type of data in parameters defined in the management plane (M-Plane).

[0093] In one embodiment, the parameter for the data type may be dataTypes. In one embodiment, the parameter requesting the data type included in the control plane (C-Plane) message may be requestDataTypes. However, this is not limited thereto.

[0094] In one embodiment, information identifying the type of data may include information indicating the type of data as a bitmap. In one embodiment, when the O-DU (100) requests specific data or data type, information identifying the type of data may be determined by indicating the value of a field corresponding to the specific data or data type as 1.

[0095] In one embodiment, when the O-DU (100) requests specific data or data type, the O-DU (100) may request the O-RU (130) by including requestDataTypes, which indicates the value of the field corresponding to the specific data or data type as 1, in a control plane (C-Plane) message.

[0096] Referring to Table 510, for example, when managing data types using 4 bitmaps, the O-DU (100) can indicate (or inform) that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required by indicating the value of requestDataTypes as '1100'. However, Table 510 is only an example, and the method of requesting specific data or data types using bitmaps is not limited to this, and various methods may exist.

[0097] In one embodiment, the O-RU (130) can identify the type of data being requested using the requestDataTypes included in the received control plane (C-Plane) message. For example, if the value of requestDataTypes is indicated as '1100', the O-RU (130) can identify that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required.

[0098] In one embodiment, parameters for combinations of data types may be defined in the management plane (M-Plane). In one embodiment, parameters for combinations of data types may be defined and managed as a table in the management plane (M-Plane). In one embodiment, parameters for a set of data types may be defined in the management plane (M-Plane).

[0099] In one embodiment, the O-DU (100) may determine information identifying the type of data. In one embodiment, the information identifying the type of data may be information included in parameters for a combination of data types.

[0100] In one embodiment, a parameter for a combination of data types (or a parameter for a set of data types) may be dataSetId. However, this is not limited thereto. In one embodiment, dataSetId, a parameter for managing each set of data types, is defined in the management plane (M-Plane), so that data types can be managed in the management plane (M-Plane).

[0101] In one embodiment, the O-DU (100) can share a combination (or a set of data types) of data types defined in the management plane (M-Plane) with the O-RU (130). In one embodiment, the O-DU (100) can share a dataSetId defined in the management plane (M-Plane) with the O-RU (130). In one embodiment, the O-RU (130) can store a combination of data types, a set of data types, or a dataSetId received from the O-DU (100).

[0102] In one embodiment, a table consisting of a combination of specific data types corresponding to dataSetId is defined in the management plane (M-Plane), so that the data types can be managed in the management plane (M-Plane) so that the O-DU (100) can request the required data types. For example, if dataSetId consists of n bits, 2 combining each data type n A set of dogs can be managed in the management plane (M-Plane).

[0103] Referring to Table 520, for example, if the value of dataSetId is '0000 0001b', the combination of data types may be {SRS based CI, SRS based BFW}, and if the value of dataSetId is '0000 0010b', the combination of data types may be {DMRS based CI, DMRS based BFW}. However, Table 520 is only an example, and the method of requesting specific data or data types as parameters for the combination of data types is not limited thereto, and various methods may exist.

[0104] In one embodiment, the O-DU (100) can request specific data types from the O-RU (130) using a control plane (C-Plane) message. In one embodiment, the O-DU (100) can request specific data types from the O-RU (130) using the ID of a data set composed of specific data types. In one embodiment, the O-DU (100) can call the requested data type using dataSetId.

[0105] In one embodiment, the parameter requesting a combination of data types included in a control plane (C-Plane) message may be requestDataSetId. However, the present invention is not limited thereto. In one embodiment, when requesting a set of specific data types, the O-DU (100) may include requestDataSetId, which indicates an ID corresponding to the set of specific data types, in the control plane (C-Plane) message and request it to the O-RU (130).

[0106] Referring to Table 520, for example, O-DU (100) may indicate (or inform) that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required by indicating the value of requestDataSetId as '0000 0001b'.

[0107] In one embodiment, the information identifying the type of data may include information identifying a set that combines at least one of the types of data. For example, the set that combines at least one of the types of data may include {SRS-based channel info, SRS-based BFW}, {DMRS-based channel info, DMRS-based BFF}, etc. For example, the information identifying the set that combines at least one of the types of data may include '0000 0001b', '0000 0010b', etc.

[0108] In one embodiment, when O-DU (100) requests a specific data type, information identifying the type of data can be determined by including information identifying a set combining the specific data types in requestDataSetId.

[0109] In one embodiment, the O-RU (130) can identify a set of data types to request using the requestDataSetId included in the received control plane (C-Plane) message. For example, if the value of requestDataSetId is indicated as '0000 0001b', the O-RU (130) can identify that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required.

[0110] In one embodiment, information identifying the type of data may be updated (or changed). In one embodiment, information identifying the type of data may be updated (or changed) based on request information received from the RIC (220, 230) regarding the type of data required by the RIC (220, 230).

[0111] In one embodiment, the information indicating the type of data as a bitmap may be updated. In one embodiment, the information indicating the type of data as a bitmap may be updated based on request information received from the RIC (220, 230) regarding the type of data required by the RIC (220, 230).

[0112] In one embodiment, a set combining at least one of the data types may be updated. In one embodiment, a set combining at least one of the data types may be updated based on request information received from the RIC (220, 230) regarding the type of data required by the RIC (220, 230).

[0113] In one embodiment, information identifying a set combining at least one of the data types may be updated. In one embodiment, information identifying a set combining at least one of the data types may be updated based on request information received from the RIC (220, 230) regarding the type of data required by the RIC (220, 230).

[0114] In one embodiment, parameters for data types or combinations of data types defined in the management plane (M-Plane) may be updated (or changed). In one embodiment, if a data type or combination of data types exists that is not defined in a table defined in the management plane (M-Plane), the data type or combination of data types may be updated. In one embodiment, an existing data type or combination of data types may be updated.

[0115] In one embodiment, if a new rApp or xApp operation requires a new type of input / output data, a table defined in the management plane (M-Plane) may be updated. In one embodiment, if a new rApp or xApp operation requires a new type of input / output data, the data type or combination of data types may be updated.

[0116] In one embodiment, the O-DU (100) may receive request information from the RIC (220, 230) regarding the type of data that the RIC (220, 230) requires. In one embodiment, the O-DU (100) may receive information regarding the type of data or a combination of data types that the RIC (220, 230) requires from the RIC (220, 230) via the O1 or E2 interface.

[0117] In one embodiment, information identifying the type of data type based on information received from the RIC (220, 230) may be updated in the management plane (M-Plane). In one embodiment, information indicating the type of data type as a bitmap based on information received from the RIC (220, 230) may be updated in the management plane (M-Plane).

[0118] In one embodiment, a set combining at least one of the data types based on information received from the RIC (220, 230) may be updated in the management plane (M-Plane). In one embodiment, information identifying a set combining at least one of the data types based on information received from the RIC (220, 230) may be updated in the management plane (M-Plane).

[0119] In one embodiment, the data types may be updated in the management plane (M-Plane) based on the request information received from the RIC (220, 230). In one embodiment, the combination of data types may be updated in the management plane (M-Plane) based on the information received from the RIC (220, 230).

[0120] In one embodiment, a previously undefined data type or combination of data types may be added to the management plane (M-Plane). In one embodiment, information identifying the previously undefined data type may be added to the management plane (M-Plane). In one embodiment, information representing the previously undefined data type as a bitmap may be added to the management plane (M-Plane).

[0121] In one embodiment, a set combining at least one of the previously undefined data types may be added to the management plane (M-Plane). In one embodiment, information identifying the set combining at least one of the previously undefined data types may be added to the management plane (M-Plane). In one embodiment, previously undefined dataTypes or dataSetIds may be added to the management plane (M-Plane).

[0122] In one embodiment, data types or combinations of data types that are no longer needed may be deleted. In one embodiment, information identifying previously undefined data types may be deleted from the management plane (M-Plane). In one embodiment, information indicating previously undefined data types as bitmaps may be deleted from the management plane (M-Plane).

[0123] In one embodiment, a set that combines at least one of the previously undefined data types may be deleted from the management plane (M-Plane). In one embodiment, information identifying a set that combines at least one of the previously undefined data types may be deleted from the management plane (M-Plane). In one embodiment, dataTypes or dataSetIds that are no longer needed may be deleted.

[0124] In one embodiment, the O-DU (100) may transmit information identifying the type of updated data to the O-RU (130). In one embodiment, the O-DU (100) may transmit information identifying the type of updated data to the O-RU (130).

[0125] In one embodiment, the O-DU (100) may transmit a message to the O-RU (130) for an update of a data type based on information received from the RIC (220, 230). In one embodiment, the O-DU (100) may transmit a message to the O-RU (130) for an update of a data type in order to update the data type in the O-RU (130). In one embodiment, the message for an update of a data type may be based on request information about the type of data that the RIC (220, 230) requires.

[0126] In one embodiment, information identifying the type of updated data or a message regarding an update of the data type may be transmitted via the management plane (M-Plane). In one embodiment, information identifying the type of updated data or a message regarding an update of the data type may be transmitted via the management plane (M-Plane).

[0127] In one embodiment, the O-RU (130) may receive information from the O-DU (100) that identifies the type of updated data. In one embodiment, the O-RU (130) may receive a message from the O-DU (100) regarding an update of the type of data.

[0128] In one embodiment, the O-RU (130) may update (or change) a data type or a combination of data types based on a received message. In one embodiment, the O-RU (130) may add a data type or a combination of data types that has not been previously defined, or delete a data type or a combination of data types that is no longer needed.

[0129] FIG. 6 is a diagram for explaining a method of requesting data using a first control message (610) according to one embodiment of the present disclosure.

[0130] Referring to FIG. 6, the O-DU (100) may transmit a first control message (610) including information identifying the type of data to the O-RU (130). In one embodiment, the O-DU (100) may transmit a first control message (610) requesting data corresponding to the type of data to the O-RU (130). In one embodiment, the first control message (610) may include a first control plane (C-Plane) message (610) (Section Type or Section Extension Type).

[0131] In one embodiment, the O-DU (100) may receive request information from the RIC (220, 230) about the type of data that the RIC (220, 230) requires. In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) to the O-RU (130) based on the request information about the type of data that the RIC (220, 230) requires.

[0132] In one embodiment, information identifying the type of data may be determined based on request information about the type of data required by the RIC (220, 230). In one embodiment, the first control message (610) may include information identifying the type of data determined based on request information about the type of data required by the RIC (220, 230).

[0133] In one embodiment, the O-DU (100) may receive information about data for training, re-training, and inference of AI / ML required in the AI-Native architecture from the RIC (220, 230). In one embodiment, the O-DU (100) may request data for training, re-training, and inference of AI / ML required in the AI-Native architecture from the O-RU (130) using a first control plane (C-Plane) message (610).

[0134] In one embodiment, the O-DU (100) may request data from the O-RU (130) based on the data types defined in the management plane (M-Plane). In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) to the O-RU (130) requesting at least one data corresponding to at least one of the data types defined in the management plane (M-Plane).

[0135] In one embodiment, the O-DU (100) may transmit a first control message (610) including information identifying the type of data to the O-RU (130). In one embodiment, the O-DU (100) may transmit a first control message (610) including information indicating the type of data as a bitmap to the O-RU (130).

[0136] In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) to the O-RU (130) by indicating at least one of the data types as a bitmap. In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) including parameters for the requested data type to the O-RU (130).

[0137] In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) including a requestDataTypes parameter to the O-RU (130). In one embodiment, the requestDataTypes may indicate the types of data being requested as a bitmap.

[0138] In one embodiment, requestDataTypes may include a value in which the value of the field corresponding to the requested data type is marked as 1 and the value of the field corresponding to the non-requested data type is marked as 0. For example, by marking the value of requestDataTypes as '1100', the O-DU (100) may indicate that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required.

[0139] In one embodiment, the O-DU (100) may transmit a first control message (610) to the O-RU (130) that includes information identifying a set of data types. In one embodiment, the O-DU (100) may transmit a first control message (610) to the O-RU (130) that includes information identifying a set of at least one of the data types.

[0140] In one embodiment, the O-DU (100) may request data from the O-RU (130) based on parameters for a set of data types defined in the management plane (M-Plane). In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) requesting a set of data types defined in the management plane (M-Plane) to the O-RU (130).

[0141] In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) to the O-RU (130) that includes an identifier (ID) for a combination of data types. In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) to the O-RU (130) that includes parameters for a combination of data types to be requested.

[0142] In one embodiment, the O-DU (100) may transmit a first control plane (C-Plane) message (610) including a requestDataSetId parameter to the O-RU (130). In one embodiment, the requestDataSetId may be represented as an identifier (ID) for a set of data types being requested. In one embodiment, the requestDataSetId may be an identifier (ID) matching a data set that matches a combination of required data types among dataSetIds defined in the management plane (M-Plane).

[0143] In one embodiment, requestDataSetId may include an identifier (ID) or value corresponding to a set of requested data types. For example, by indicating the value of requestDataSetId as '0000 0001b', the O-DU (100) may indicate that SRS-based channel information (SRS-based CI) and SRS-based BFW (SRS-based BFW) are required.

[0144] In one embodiment, the first control plane (C-Plane) message (610) can be transmitted and received by defining a section type. In one embodiment, the O-DU (100) can request data using the control plane (C-Plane) section type. In one embodiment, the section type can mean a control plane (C-Plane) message. For example, the section type number can be indicated as 'XX'.

[0145] In one embodiment, O-DU (100) can request the required data types from RIC (220, 230) by defining a new section type and adding fields such as dataReqId, requestDataTypes, and requestDataSetId to the section type.

[0146] In one embodiment, the O-DU (100) can request the required data type from the RIC (220, 230) using a previously defined section type. For example, the O-DU (100) can request the data type using section type 1.

[0147] In one embodiment, the first control plane (C-Plane) message (610) may include at least one of user equipment (UE) information, resource information, PRB information, slot information, symbol information, and beam information. In one embodiment, the first control plane (C-Plane) message (610) may include at least one of dataReqId, requestDataTypes, and requestDataSetId.

[0148] In one embodiment, dataReqId may be an identifier that identifies resource information, UE information, or the type of data being requested. In one embodiment, dataReqId may use a different identifier depending on the resource information or UE information.

[0149] FIG. 7 is a diagram for explaining a method of requesting data or updating a data type using a section extension type (SET) according to one embodiment of the present disclosure.

[0150] Referring to FIG. 7, the first control plane (C-Plane) message can be transmitted and received by defining a section extension type (SET). In one embodiment, the first control plane (C-Plane) message can be transmitted and received by using a previously defined section extension type (SET).

[0151] In one embodiment, the O-DU (100) may request data collection from the O-RU (130) by using a newly defined section extension type (SET) in an existing control plane (C-Plane) section type (ST). For example, the section type (ST) may use an existing section type (ST) for UE scheduling and request data collection by using a newly defined section extension type (SET).

[0152] In one embodiment, the O-DU (100) can transmit a control plane (C-Plane) message to the O-RU (130) using a newly defined section extension type (SET) in a previously defined section type (ST).

[0153] In one embodiment, the O-DU (100) may request data collection from the O-RU (130) using a previously defined section extension type (SET) in a previously defined section type (ST). In one embodiment, the O-DU (100) may transmit a control plane (C-Plane) message requesting data from the O-RU (130) using a previously defined section extension type (SET) in a previously defined section type (ST).

[0154] Referring to 710, the O-DU (100) can newly define a section extension type (SET) for a previously defined section type (ST). In one embodiment, the O-DU (100) can request data by newly defining a section extension type (SET) for a previously defined section type (ST). For example, the section extension type (SET) number can be 'yy'.

[0155] In one embodiment, a control plane (C-Plane) message may be transmitted from an O-DU (100) to an O-RU (130) including data information requesting a newly defined section extension type (SET). In one embodiment, a control plane (C-Plane) message with a newly defined section extension type (SET) may include at least one of ef, dataReqId, RequestDatSetId, and UE ID.

[0156] In one embodiment, ef may mean a parameter or field indicating the presence of a section extension type (SET). In one embodiment, RequestDatSetId included in the section extension type (SET) may mean an identifier (ID) of a requested data set (set).

[0157] In one embodiment, the section type (ST) may not be used simultaneously with the section extension type (SET). In one embodiment, the section type (ST) may request data or data types solely through a control plane (C-Plane) message. In one embodiment, the section extension type (SET) may be attached to the section type (ST) existing in the existing O-RAN WG4 standard to request data or data types.

[0158] In one embodiment, if the table for data types defined in the management plane (M-Plane) does not contain the data types required by the AI / ML model, the data types may be updated based on the data types required by the AI / ML model. In one embodiment, the O-DU (100) may request the O-RU (130) for updated data types.

[0159] In one embodiment, when a new rApp is installed in a non-RT RIC (220) or a new xApp is installed in a near-RT RIC (230), there may be newly required input / output data in the RIC (220, 230). In one embodiment, the O-DU (100) may receive information about the newly required data types from the RIC (220, 230) through the O1 and E2 interfaces.

[0160] In one embodiment, newly requested input / output data from the RIC (220, 230) may not be defined in the management plane (M-Plane). In one embodiment, information about the types of data required by the RIC (220, 230) may not be defined in the management plane (M-Plane).

[0161] In one embodiment, if the data types required by the RIC (220, 230) are not defined in the management plane (M-Plane), the data types may be updated in the management plane (M-Plane) based on information about the data types required by the RIC (220, 230). In one embodiment, the dataTypes and dataSetId fields may be updated in the management plane (M-Plane).

[0162] In one embodiment, the first control message may include information identifying the type of updated data. In one embodiment, the O-DU (100) may transmit the first control message including information identifying the type of updated data to the O-RU (130).

[0163] In one embodiment, the O-DU (100) may request the O-RU (130) for the type of data required by the RIC (220, 230). In one embodiment, the O-DU (100) may request the O-RU (130) for the type of updated data. In one embodiment, the O-DU (100) may request the O-RU (130) for the type of data not defined in the management plane (M-Plane).

[0164] Referring to 720, the O-DU (100) can newly define a section extension type (SET) for a previously defined section type (ST). In one embodiment, the O-DU (100) can request an updated data type by newly defining a section extension type (SET) for a previously defined section type (ST). For example, the section extension type (SET) number can be 'zz'.

[0165] In one embodiment, the O-DU (100) may request the required data types from the O-RU (130) by including requestDataSetId and requestDataTypes in the section extension type (SET). In one embodiment, the O-DU (100) may request updated data types using the newly defined section extension type (SET). In one embodiment, the O-DU (100) may request updated management plane (M-Plane) parameters using the newly defined section extension type (SET).

[0166] In one embodiment, the newly defined section extension type (SET) may include a requestDataSetId including the dataSetId to be updated by the O-RU (130), and a requestDataTypes including the dataTypes to be updated.

[0167] In one embodiment, requestDataSetId may include an identifier (ID) of a data type set to be updated by O-RU (130). In one embodiment, requestDataSetId may include an identifier (ID) of a data type set to be updated by O-DU (100).

[0168] In one embodiment, requestDataTypes may include information about the types of data to be updated by the O-RU (130). In one embodiment, requestDataTypes may include information about the types of data updated by the O-DU (100). In one embodiment, requestDataTypes may be represented as a bitmap.

[0169] For example, if the set for existing requestDataSetId='0000 0001b' is {SRS CI, SRS BFW}, and the section extension type (SET) includes requestDatSetId='0000 0001b', requestDataTypes={SRS CI, SRS BFW, DMRS BFW}, then the set for requestDataSetId='0000 0001b' can be updated to {SRS CI, SRS BFW, DMRS BFW}. Afterwards, feedback for all control plane (C-Plane) messages indicated by requestDataSetId='0000 0001b' can be performed as {SRS CI, SRS BFW, DMRS BFW}. The requestDataTypes containing information about the updated data types can be represented as a bitmap defined in the management plane (M-Plane).

[0170] In one embodiment, when the O-RU (130) receives a control plane (C-Plane) message in which a section extension type (SET) is newly defined, the O-RU (130) may determine that the control plane (M-Plane) parameters have been updated. In one embodiment, when the O-RU (130) receives a control plane (C-Plane) message in which a section extension type (SET) is newly defined, the O-RU (130) may update the data type based on requestDataSetId and requestDataTypes.

[0171] In one embodiment, the O-DU (100) may receive a second control plane (C-Plane) message from the O-RU (130) that includes data corresponding to the updated data type. In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message that includes data corresponding to the updated data type to the O-DU (100).

[0172] In one embodiment, the O-RU (130) may feedback the updated data type when it receives a data request with the same requestDataSetId. In one embodiment, the O-RU (130) may feedback data corresponding to the updated data type even without requestDataTypes when it receives a section type (ST) containing the same requestDataSetId.

[0173] FIGS. 8A and 8B are diagrams illustrating a method of receiving data using a second control message (830) according to one embodiment of the present disclosure.

[0174] Referring to FIGS. 8a and 8b, the O-DU (100) may receive a second control message (830) including data from the O-RU (130) in response to the first control message. In one embodiment, the second control message (830) may include a second control plane (C-Plane) message (830).

[0175] In one embodiment, the O-DU (100) can request a specific data type to the O-RU (130) using requestDataSetId or requestDataTypes included in the section type (ST) or section extension type (SET).

[0176] In one embodiment, the O-RU (130) may feed back data corresponding to requestDataSetId or requestDataTypes included in the section type (ST) or section extension type (SET) to the O-DU (100). In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message (830) including data corresponding to requestDataSetId or requestDataTypes included in the section type (ST) or section extension type (SET) to the O-DU (100).

[0177] In one embodiment, the O-RU (130) may feed back data corresponding to a specific data type requested from the O-DU (100) to the O-DU (100). In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message (830) containing the data requested from the O-DU (100) to the O-DU (100).

[0178] In one embodiment, the second control plane (C-Plane) message (830) can be transmitted and received by defining a section type (ST) or a section extension type (SET). In one embodiment, the O-RU (130) can transmit the second control plane (C-Plane) message (830) using a previously defined section type (ST) or section extension type (SET). For example, the section type (ST) number can be 'yx'.

[0179] In one embodiment, the O-RU (130) can feed back data requested from the O-DU (100) to the O-DU (100) by defining a new control plane (C-Plane) section type (ST). In one embodiment, the O-RU (130) can transmit a second control plane (C-Plane) message (830) including data requested from the O-DU (100) to the O-DU (100) by defining a new control plane (C-Plane) section type (ST).

[0180] In one embodiment, the O-RU (130) may feed back data requested from the O-DU (100) to the O-DU (100) using a new section type (ST). In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message (830) containing data requested from the O-DU (100) to the O-DU (100) using the new section type (ST).

[0181] In one embodiment, the O-RU (130) may feed back data requested from the O-DU (100) to the O-DU (100) using a newly defined control plane (C-Plane) section type (ST). In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message (830) including data requested from the O-DU (100) to the O-DU (100) using a newly defined control plane (C-Plane) section type (ST).

[0182] Referring to 810 and 820, the DU (100) may request data from the O-RU (130) for multiple dataReqIds. In one embodiment, the O-DU (100) may request data from the O-RU (130) using a section type (ST) or a section extension type (SET). In one embodiment, a field corresponding to each dataReqId may include at least one of requestDataSetId and requestDataTypes.

[0183] In one embodiment, the O-RU (130) may feed back data corresponding to the requested dataSetId to the O-DU (100) using the newly defined section type (ST). In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message (830) including data corresponding to the requested dataSetId to the O-DU (100) using the newly defined section type (ST).

[0184] In one embodiment, the O-RU (130) can transmit feedback corresponding to multiple dataReqIds at once in a single second control plane (C-Plane) message (830) by adding a field called numberOfDataSets to the section type (ST). In one embodiment, the O-RU (130) can transmit data corresponding to multiple dataSetIds to the O-DU (100) by using the numberOfDataSets field.

[0185] In one embodiment, numberOfDataSets may be expressed as numberOfDataReqIds or numberOfFeedbacks, but is not limited thereto.

[0186] In one embodiment, the O-RU (130) can transmit data defined by dataSetId by adding it to a field of a second control plane (C-Plane) message (830) in the order of the data types corresponding to the dataSetId.

[0187] In one embodiment, the O-RU (130) may generate a second control plane (C-Plane) message (830) including I / Q samples of data corresponding to requestDataSetId included in each dataReqId and transmit it to the O-DU (100). In one embodiment, the O-RU (130) may include I / Q samples of data for each PRB and antenna in the second control plane (C-Plane) message (830) and transmit it to the O-DU (100).

[0188] In one embodiment, the O-RU (130) may feed back data requested from the O-DU (100) to the O-DU (100) using a user plane (U-Plane) message. In one embodiment, the O-RU (130) may transmit a user plane (U-Plane) message containing data requested from the O-DU (100) to the O-DU (100).

[0189] In one embodiment, the O-DU (100) may receive a second control plane (C-Plane) message (830) containing the requested data from the O-RU (130).

[0190] In one embodiment, the O-DU (100) may transmit data included in a second control message (830) to the RIC (220, 230). In one embodiment, the O-DU (100) may transmit data included in a received second control plane (C-Plane) message (830) to the RIC (220, 230) via the O1, E2 interface.

[0191] In one embodiment, the data included in the second control plane (C-Plane) message (830) may be data corresponding to the type of data requested by the RIC (220, 230) to the O-DU (100). In one embodiment, the data included in the second control plane (C-Plane) message (830) may be data required for training, re-training, and inference in an rApp or an xApp.

[0192] FIGS. 9A and 9B are diagrams illustrating examples of a first control message (910, 920) including instruction information for ndm (non-delay managed) and information about a transmit window size according to one embodiment of the present disclosure.

[0193] Referring to FIG. 9A, the first control message (910) may include indication information for non-delay managed (NDM) and information on a transmit window size. In one embodiment, the O-DU (100) may transmit the first control message (910) including indication information for non-delay managed (NDM) and information on a transmit window size to the O-RU (130).

[0194] In one embodiment, ndm may refer to a method of transmitting signals or data that is insensitive to delay.

[0195] In one embodiment, the transmit window size may refer to the size of the window in which data can be transmitted during a specific period of time, and may be divided into slots or time periods. In one embodiment, a larger transmit window size may decrease the transmission data rate.

[0196] In one embodiment, control plane (C-Plane) messages may support non-delay managed (ndm) traffic, taking into account the fronthaul data rate (F / H data rate). In one embodiment, for data collection for AI / ML that is not sensitive to delay, control plane (C-Plane) messages may be transmitted in a non-delay managed (ndm) traffic manner.

[0197] In one embodiment, data that is not sensitive to delay may be data required for training or retraining. In one embodiment, data that does not operate in real time, such as training or retraining in an rApp / xApp, may be transmitted as ndm traffic. In one embodiment, data that operates in real time, such as inference in an xApp / dApp (distributed application), may not be transmitted as ndm traffic. However, this is not limited thereto.

[0198] In one embodiment, the O-DU (100) may indicate NDM traffic by adding a 1-bit long ndm field to the control plane (C-Plane) section type (ST) or section extension type (SET). In one embodiment, the O-DU (100) may indicate NDM traffic by adding a 1-bit long ndm field to the first control plane (C-Plane) message (910).

[0199] In one embodiment, if the value of ndm added to the control plane (C-Plane) section type (ST) or section extension type (SET) is 1, the meaning of the corresponding ndm=1 may mean an instruction to transmit feedback as non-delay managed traffic.

[0200] In one embodiment, if the value of ndm added to the control plane (C-Plane) section type (ST) or section extension type (SET) is 1, the first control plane (C-Plane) message (910) may include information about a transmit window size. In one embodiment, if the value of ndm added to the control plane (C-Plane) section type (ST) or section extension type (SET) is 1, the transmit window size may be changed.

[0201] In one embodiment, even if the value of ndm added to the section type (ST) or section extension type (SET) is 1, the first control plane (C-Plane) message (910) may not include information about the transmit window size. In one embodiment, when the value of ndm is 1 and information about the transmit window size is not included, it may mean to transmit data dynamically according to the fronthaul data rate (F / H data rate).

[0202] In one embodiment, when the value of ndm is 1 and does not include information about the transmit window size, the O-RU (130) can dynamically transmit the second control message according to the fronthaul data rate (F / H data rate).

[0203] In one embodiment, when ndm added to the control plane (C-Plane) section type (ST) or section extension type (SET) is 0, the meaning of the corresponding ndm=0 may be an instruction to transmit feedback according to the existing transmit window size. For example, the existing transmit window size may be 1 symbol in size.

[0204] In one embodiment, when the O-RU (130) receives a first control plane (C-Plane) message (910) indicating ndm traffic, the O-RU (130) may transmit a second control plane (C-Plane) message to the O-DU (100) based on the indication information for the ndm and the information about the transmit window size. In one embodiment, the second control message may be transmitted based on the indication information for the ndm and the information about the transmit window size.

[0205] In one embodiment, when the O-RU (130) receives a first control plane (C-Plane) message (910) indicating ndm traffic, the O-RU (130) may feed back to the O-DU (100) based on the indication information for the ndm and information about the transmit window size.

[0206] In one embodiment, when ndm traffic is indicated, the O-RU (130) can distribute the traffic in an ndm manner according to the transmit window size included in the first control plane (C-Plane) message (910) and transmit the second control plane (C-Plane) message to the DU (100).

[0207] In one embodiment, when ndm traffic is indicated, the O-RU (130) can distribute the traffic in an ndm manner according to the transmit window size included in the first control plane (C-Plane) message (910) and feed it back to the O-DU (100).

[0208] In one embodiment, when ndm traffic is indicated, the O-RU (130) can distribute the traffic in an ndm manner according to the transmit window size included in the section type (ST) or section extension type (SET) and transmit a second control plane (C-Plane) message to the O-DU (100).

[0209] In one embodiment, when ndm traffic is indicated, the O-RU (130) can distribute the traffic in an ndm manner according to the transmit window size included in the section type (ST) or section extension type (SET) and feed it back to the O-DU (100).

[0210] In one embodiment, the O-DU (100) may receive a second control plane (C-Plane) message from the O-RU (130) based on the indication information for the ndm and the information about the transmit window size.

[0211] In one embodiment, the first control plane (C-Plane) message (910) may vary at least one of the ndm field and the transmit window size depending on the UE. In one embodiment, the first control plane (C-Plane) message (910) may vary at least one of the ndm field and the transmit window size depending on the UE ID.

[0212] In one embodiment, the first control plane (C-Plane) message (910) may have at least one of the ndm field and the transmit window size vary depending on the dataReqId.

[0213] Referring to FIG. 9b, the O-DU (100) may indicate the same ndm field and the same transmit window size for all UE IDs included in the first control plane (C-Plane) message (920). In one embodiment, the O-DU (100) may indicate the same ndm field and the same transmit window size for all dataReqIds included in the first control plane (C-Plane) message (920).

[0214] In one embodiment, the O-DU (100) may indicate the same ndm field and the same transmit window size for all UE IDs included in a control plane (C-Plane) section type (ST) or section extension type (SET). In one embodiment, the O-DU (100) may indicate the same ndm field and the same transmit window size for all dataReqIds included in a control plane (C-Plane) section type (ST) or section extension type (SET).

[0215] In one embodiment, the O-DU (100) may specify whether to use the same ndm transmission and the same transmit window size for all UE IDs or dataReqIds included in the first control plane (C-Plane) message (920).

[0216] In one embodiment, the O-RU (130) may transmit a second control plane (C-Plane) message to the O-DU (100) by distributing traffic in an ndm manner according to the same transmit window size for all UE IDs or dataReqIds based on the indication information for ndm and the information about the transmit window size included in the first control plane (C-Plane) message (920).

[0217] FIG. 10 is a diagram for explaining changes in fronthaul data rate (F / H data rate) according to instruction information for ndm according to one embodiment of the present disclosure.

[0218] Referring to FIG. 10, the fronthaul data rate (F / H data rate) can be changed depending on the instruction information for ndm.

[0219] In one embodiment, when real-time data is transmitted, the fronthaul data rate (F / H data rate) may peak because it must be transmitted within a short period of time. For example, real-time data may be data required for inference in an xApp / dApp (distributed application). However, this is not limited to this.

[0220] In one embodiment, the fronthaul data rate (F / H data rate) may increase as data is transmitted within a shorter period of time. In one embodiment, the fronthaul peak data rate (F / H peak data rate) may increase as data is transmitted within a shorter period of time.

[0221] In one embodiment, when large data is transmitted within a short slot, the fronthaul peak data rate (F / H peak data rate) may increase.

[0222] In one embodiment, data that is not sensitive to delay may be transmitted as NDM traffic. In one embodiment, data that does not operate in real time may be transmitted as NDM traffic. For example, this may be data required for training or retraining in rApp / xApp, but is not limited thereto.

[0223] In one embodiment, the O-DU (100) may add instruction information for the ndm and information about the transmit window size to the first control message and transmit it to the O-RU (130) for data that is not sensitive to delay or data that does not operate in real time.

[0224] In one embodiment, the O-RU (130) may transmit a second control message to the O-DU (100) based on the indication information for the ndm and the information for the transmit window size. In one embodiment, when there is an indication for the ndm, the O-RU (130) may distribute the traffic in an ndm manner according to the transmit window size and feed it back to the O-DU (100).

[0225] In one embodiment, when there is an instruction for ndm, the transmit window size may increase compared to when there is no instruction for ndm. In one embodiment, when data is transmitted by distributing traffic in an ndm manner according to the transmit window size, the fronthaul peak data rate (F / H peak data rate) may decrease.

[0226] In one embodiment, if there is an instruction for ndm, data may be transmitted in a time-dispersed manner. In one embodiment, if there is an instruction for ndm, the fronthaul data rate (F / H data rate) may be reduced compared to when there is no instruction for ndm.

[0227] FIG. 11 is a flowchart illustrating a method of transmitting and receiving data between an O-DU (100) and an O-RU (130) according to one embodiment of the present disclosure.

[0228] Referring to FIG. 11, in step S1110, O-DU (100) can determine information identifying the type of data.

[0229] In one embodiment, the information identifying the type of data may include information representing the type of data as a bitmap. In one embodiment, the information identifying the type of data may include information identifying a set combining at least one of the types of data.

[0230] In one embodiment, the O-DU (100) may receive request information from the RIC (220, 230) regarding the type of data required by the RIC (220, 230). In one embodiment, information identifying the type of data may be determined based on the request information. In one embodiment, information identifying the type of data may be updated based on the request information.

[0231] In one embodiment, information identifying the type of data may be included in parameters defined in a management plane (M-Plane).

[0232] In step S1120, O-DU (100) may transmit a first control message including information identifying the type of data to O-RU (130).

[0233] In one embodiment, the first control message may include instruction information for ndm (non-delay managed) and information about the transmission window size.

[0234] In one embodiment, the first control message may include information identifying the type of data being updated.

[0235] In step S1130, the O-DU (100) may receive a second control message including data from the O-RU (130) in response to the first control message.

[0236] In one embodiment, the second control message may be transmitted based on the instruction information for the ndm and information about the transmission window size.

[0237] In one embodiment, the second control message may include data corresponding to information identifying the type of updated data.

[0238] In one embodiment, data included in the second control message may be transmitted to the RIC (220, 230).

[0239] In this disclosure, we propose a 6G open fronthaul interface capable of supporting AI-native in 6G O-RAN. We define and propose details of a fronthaul interface between an O-DU (100) and an O-RU (130) for collecting raw data required by AI / ML models of xApps and rApps operating in a near-RT RIC (230) and a non-RT RIC (220), which play a key role in the O-RAN architecture. When data collection is required, data collection is requested only for the required data types, and raw data for the request is fed back to support efficient operation.

[0240] This operation is performed using the ST and SET of the C-Plane defined in the existing O-RAN WG4 fronthaul standard, and the present disclosure enables efficient data collection by using new ST and SET. We propose a method to reduce the peak data rate of the fronthaul by defining non-delay managed (ndm) traffic flows in the control plane (C-Plane) considering the fronthaul data rate.

[0241] In addition, for data collection for real-time operations such as inference of AI / ML models, a new field of the control plane (C-Plane) is proposed that can turn on / off non-delay managed (ndm) traffic to support delay-managed traffic flow.

[0242] Through this disclosure, data that was not previously transmitted from the existing O-RU (130) to the O-DU (100) can be efficiently transmitted only when necessary, thereby efficiently supporting the AI-native structure, which is one of the core technologies of 6G O-RAN, through a new fronthaul interface.

[0243] In the specific embodiments of the present disclosure described above, components included in the invention are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0244] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

[0245] The 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.

[0246] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The 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 the present disclosure.

[0247] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0248] Additionally, the program may be stored in an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a 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 via an external port. Additionally, a separate storage device on the communication network may be connected to a device performing an embodiment of the present disclosure.

[0249] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0250] While the detailed description of the present disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be determined not only by the scope of the following claims but also by equivalents thereof. In other words, it will be apparent to those skilled in the art to which the present disclosure pertains that other modifications based on the technical concept of the present disclosure are possible. Furthermore, the above-described embodiments may be combined and operated as needed.

Claims

1. In a method performed by an O-DU (Open-Distributed Unit) in a wireless communication system, A step of determining information that identifies the type of data; A step of transmitting a first control message including information identifying the type of the above data to an O-RU (Open-Radio Unit); and A method comprising the step of receiving a second control message including the data from the O-RU in response to the first control message.

2. In paragraph 1, The above first control message includes instruction information for ndm (non-delay managed) and information about the transmission window size, A method wherein the second control message is transmitted based on the instruction information for the ndm and the information about the transmission window size.

3. In paragraph 1, A method in which information identifying the type of the data includes information indicating the type of the data as a bitmap.

4. In paragraph 1, A method wherein the information identifying the type of the data includes information identifying a set combining at least one of the types of the data.

5. In paragraph 1, A method further comprising the step of receiving request information about the type of data required by the RIC from the RIC (RAN (Radio Access Network) Intelligent Controller).

6. In paragraph 5, A method in which information identifying the type of the above data is determined based on the above request information.

7. In paragraph 5, A method in which information identifying the type of the above data is updated based on the above request information.

8. In a wireless communication system, an O-DU (Open-Distributed Unit) is Transmitter and receiver; and At least one processor coupled to the transceiver, At least one processor, Determine the information that identifies the type of data, Transmit a first control message including information identifying the type of the above data to the O-RU (Open-Radio Unit), An O-DU that receives a second control message including the data from the O-RU in response to the first control message.

9. In paragraph 8, The above first control message includes instruction information for ndm (non-delay managed) and information about the transmission window size, The second control message is transmitted based on the instruction information for the ndm and the information about the transmission window size, O-DU.

10. In paragraph 8, Information identifying the type of the above data includes information indicating the type of the above data as a bitmap, O-DU.

11. In paragraph 8, O-DU, wherein the information identifying the type of the data includes information identifying a set combining at least one of the types of the data.

12. In paragraph 8, At least one processor, An O-DU that receives request information about the type of data required by the RIC (RAN (Radio Access Network) Intelligent Controller).

13. In paragraph 12, Information identifying the type of the above data is determined based on the above request information, O-DU.

14. In paragraph 12, Information identifying the type of the above data is updated based on the request information, O-DU.

15. In paragraph 14, The first control message includes information identifying the type of the updated data, The second control message includes data corresponding to information identifying the type of the updated data, O-DU.

Images