Method and apparatus for configuring timing parameters in a communication system

Abstract

According to one embodiment of the present invention, a method performed by a controller in a communication system may include the steps of receiving SCS capability information from a plurality of O-RUs, respectively, receiving slotId setting capability information from a plurality of O-RUs, generating slotId setting information based on the received SCS capability information and slotId setting capability information, and transmitting the generated slotId setting information to an O-DU and a plurality of O-RUs.

Description

[Technical Field]

[0001] The present invention relates to a method and apparatus for determining timing parameters, which are control / user plane configurations used when configuring cells in a communication system. [Background technology]

[0002] As wireless communication systems develop and evolve into 4G communication systems, 5G communication systems, etc., various functions and specifications are required. Various methods have been introduced to meet these functions and specifications, one of which is a method of implementing a network infrastructure structure by functionally separating it. In a representative configuration of the functional separation method, a base station can be represented by a centralized unit (CU), a distributed unit (DU), and a radio unit (RU) depending on its function, and the interfaces of each unit are defined by organizations such as 3GPP and the O-RAN Alliance. Summary of the Invention [Problem to be solved by the invention]

[0003] One problem that the present invention aims to solve is to provide a method for efficiently utilizing fronthaul communications or increasing processing capacity in a method for configuring multiple cells or one or more shared cells.

[0004] Yet another problem to be solved by the present invention is to provide a method for configuring a shared cell that reduces resource waste and improves communication quality when communicating in O-RAN. [Means for solving the problem]

[0005] According to one embodiment of the present invention, a method performed by a controller in a communication system may include the steps of receiving sub-carrier spacing (SCS) capability information from a plurality of O-RUs included in a plurality of cells or one or more shared cells, respectively; receiving slot identifier (slotId) configuration capability information from the plurality of O-RUs, respectively; generating slotId configuration information based on the received SCS capability information and slotId configuration capability information; and transmitting the generated slotId configuration information to an O-DU and the plurality of O-RUs.

[0006] According to one embodiment, the SCS capability information may include information indicating what SCS each of the plurality of O-RUs supports, and the slotId setting capability information may include information indicating whether each of the plurality of O-RUs can change the slotId.

[0007] According to one embodiment, the step of generating slotId configuration information based on the received SCS capability information and slotId setting capability information may include the steps of: identifying whether the slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; and, if the slotId setting capability information of the at least one O-RU includes information indicating that the slotId can be changed, generating the slotId setting information based on the SCS capability information of the O-RU, where the slotId setting capability information includes information indicating that the slotId cannot be changed, in order to configure a shared cell or to improve the processing capacity of a DU.

[0008] According to one embodiment, the step of generating slotId setting information based on the received SCS capability information and slotId setting capability information may include the steps of identifying whether the slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; and generating the slotId setting information of the at least one O-RU based on the communication quality of the controller.

[0009] According to another embodiment of the present invention, a controller in a communication system may include a transceiver; a memory; and at least one processor electrically connected to the transceiver and the memory, wherein the at least one processor may be configured to receive subcarrier spacing (SCS) capability information from each of a plurality of O-RUs included in one or more shared cells or multiple cells, receive slot identifier (slotId) configuration capability information from each of the O-RUs, generate slotId configuration information based on the received SCS capability information and slotId configuration capability information, and transmit the generated slotId configuration information to an O-DU and the plurality of O-RUs. [Effects of the Invention]

[0010] According to an embodiment of the present invention, it is possible to unify the slotId settings of O-RUs included in a shared cell or multiple cells, thereby efficiently configuring the shared cell or increasing the processing capacity of the DU.

[0011] The effects of the technical idea of ​​the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. [Brief explanation of the drawings]

[0012] [Figure 1A] 1 illustrates a wireless communication system in accordance with various embodiments of the present invention. [Figure 1B]1 illustrates an example of a fronthaul structure based on functional separation of a base station according to various embodiments of the present invention. [Figure 2] 1 is a diagram of an O-RAN network system according to an embodiment of the present invention. [Figure 3] 1 is a diagram illustrating the structure of an O-RAN wireless communication system according to an embodiment of the present invention. [Figure 4] 1 is a diagram illustrating a structure of an Ethernet message according to an embodiment of the present invention. [Figure 5A] 1 is a diagram illustrating an example of a C-plane message according to an embodiment of the present invention. [Figure 5B] 1 is a diagram illustrating an example of a C-plane message according to an embodiment of the present invention. [Figure 6] 1 is a diagram illustrating the structure of an O-RAN base station including a middle node according to an embodiment of the present invention. [Figure 7] 10 is a table illustrating slot ID indexes according to one embodiment of the present invention. [Figure 8] 10 is a diagram illustrating a method for configuring a slot identifier (slotId) setting according to an embodiment of the present invention. [Figure 9A] 1 is a diagram illustrating a method for performing fronthaul communication according to an embodiment of the present invention. [Figure 9B] 10 is a diagram illustrating a method for performing communication by setting a slotId according to another embodiment of the present invention. [Figure 10A] 10 is a diagram illustrating a first embodiment in which slotId setting is applied according to an embodiment of the present invention. [Figure 10B] 10 is a diagram illustrating a second embodiment in which slotId setting is applied according to an embodiment of the present invention. [Figure 10C] 10 is a diagram illustrating a third embodiment in which slotId setting is applied according to an embodiment of the present invention. [Figure 10D] 10 is a diagram illustrating a fourth embodiment in which slotId setting is applied according to an embodiment of the present invention. [Figure 11]10 is a flowchart illustrating a method for setting slotId according to one embodiment of the present invention. [Figure 12] 10 is a diagram illustrating a method for communicating with an O-RU that configures multiple cells by setting a slotId according to an embodiment of the present invention. [Figure 13] 1 is a diagram illustrating a configuration of a controller according to an embodiment of the present invention. [Figure 14] 1 is a diagram illustrating the configuration of a middle node according to an embodiment of the present invention. [Figure 15] 1 is a diagram showing the configuration of an O-DU according to an embodiment of the present invention. [Figure 16] 1 is a diagram showing the configuration of an O-RU according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0014] When describing embodiments of the present invention, if a detailed description of a related function or configuration is deemed to unnecessarily obscure the gist of the present invention, the detailed description will be omitted. Furthermore, the terms used below are defined in consideration of the functions of the present invention, and may vary depending on the intentions or practices of users or operators. Therefore, the definitions should be based on the overall content of this specification.

[0015] For the same reason, in the accompanying drawings, some components may be exaggerated, omitted, or shown in a schematic manner, and the size of each component may not directly reflect the actual size. In each drawing, the same or corresponding components are given the same reference numerals.

[0016] The advantages and features of the present invention, as well as methods for achieving them, will become apparent from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be embodied in various different forms. The embodiments are provided to fully explain the present invention and to fully convey the scope of the invention to those skilled in the art to which the embodiments of the present invention pertain, and the scope of the present invention is defined only by the scope of the claims.

[0017] It will be understood that each block of the process flowchart, and combinations of process flowcharts, can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that the instructions, when executed by the processor of the computer or other programmable data processing device, create means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in computer-usable or computer-readable memory that can direct the computer or other programmable data processing device to implement the functions in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory can produce an article of manufacture that embodies the instruction means for performing the functions described in the flowchart blocks. The computer program instructions may be embodied on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device to generate a computer-implemented process, and the instructions for the computer or other programmable data processing device may provide steps for performing the functions described in the flowchart blocks.

[0018] Also, each block represents a module, segment, or portion of code that includes one or more executable instructions for performing a specified logical function. Also, it should be noted that in some alternative implementations, the functions described in the blocks may occur out of order. For example, two blocks shown in succession may actually be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order according to their functions.

[0019] The term "unit" or "part" used herein refers to software or hardware components such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), and a "unit" may be configured to perform a specific role. However, the term "unit" is not limited to software or hardware. A "unit" may be configured to reside on an addressable storage medium and to execute on one or more processors. Thus, by way of example, a "unit" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within a unit and a "unit" may be combined into fewer units and units or further separated into additional units and units. Furthermore, a unit and a "unit" may be embodied to implement one or more CPUs within a device or a secure multimedia card. Also, in the embodiments, a "unit" includes one or more processors and / or devices.

[0020] In some embodiments, the techniques described herein and systems and devices for implementing the same support communication between networks (or systems) using radio access technologies such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), LTE, GSM (registered trademark), 5G NR, as well as other radio access technologies such as WiFi (registered trademark) or WiMax (registered trademark).

[0021] Various other embodiments and features according to the technical concepts of the present invention are further described below. It should be apparent that the teachings of the present application may be embodied in a wide variety of forms, and that any specific structure, function, or both disclosed herein are exemplary and not limiting. Based on the teachings of the present application, those skilled in the art will recognize that the aspects disclosed herein may be implemented independently of any other aspects, or that two or more of these aspects may be combined in various ways. For example, an apparatus may be embodied or a method may be practiced using any number of the aspects presented herein. Such an apparatus may be embodied or a method may be practiced using one or more of the aspects described herein together, or using the structure, functionality, or structure and functionality of other aspects. For example, a method may be embodied as a system, device, apparatus, and / or a piece of instructions stored on a computer-readable medium for execution by a processor or computer. An aspect may also include at least one element of a claim.

[0022] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the same components are denoted by the same reference numerals in the accompanying drawings, and detailed descriptions of known functions and configurations that may obscure the gist of the present invention will be omitted.

[0023] In describing the embodiments in this specification, technical details that are well known in the technical field to which the present invention pertains and are not directly related to the present invention will be omitted in order to more clearly convey the gist of the present invention without obscuring it.

[0024] For the same reason, in the accompanying drawings, some components are exaggerated, omitted, or illustrated schematically, and the size of each component does not directly reflect the actual size. In each drawing, the same or corresponding components are given the same reference numerals.

[0025] The advantages and features of the present invention, as well as methods for achieving them, will become apparent from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be embodied in various different forms. However, the present embodiments are provided to fully disclose the present invention and fully convey the scope of the invention to those skilled in the art. The present invention is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same elements.

[0026] It will be understood that each block of the process flowchart and combinations of the flowcharts can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that the instructions, when executed by the processor of the computer or other programmable data processing device, create means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in computer-usable or computer-readable memory that can direct the computer or other programmable data processing device to implement the functions in a particular way, such that the instructions stored in the computer-usable or computer-readable memory can produce an article of manufacture that embodies the instruction means for performing the functions described in the flowchart blocks. The computer program instructions may be embodied on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device to generate a computer-implemented process, and the instructions for the computer or other programmable data processing device may provide steps for performing the functions described in the flowchart blocks.

[0027] Also, each block represents a module, segment, or portion of code that includes one or more executable instructions for performing a specified logical function. Also, it should be noted that in some alternative implementations, the functions described in the blocks may occur out of order. For example, two blocks shown in succession may actually be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order according to their functions.

[0028] The term "module" used in this embodiment refers to software or hardware components such as FPGAs or ASICs, and the "module" may perform either function. However, the term "module" is not limited to software or hardware. The "module" may be configured to reside on an addressable storage medium or to implement one or more processors. Thus, by way of example, the term "module" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The components and functions provided within the "modules" may be combined into fewer components and "modules" or further separated into additional components and "modules." Furthermore, the components and "modules" may be embodied to implement one or more CPUs within a device or a secure multimedia card.

[0029] Hereinafter, a base station is an entity that allocates resources to a terminal, and is at least one of a Node B, a Base Station (BS), an eNode B (eNB), a gNode B (gNB), a radio access unit, a base station controller, or a node on a network. A terminal includes a User Equipment (UE), a Mobile Station (MS), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing communication functions. Furthermore, embodiments of the present invention may be applied to other communication systems having similar technical backgrounds or channel configurations to the embodiments of the present invention described below. Furthermore, the embodiments of the present invention may be applied to other communication systems with some modifications within the scope of the present invention, as determined by those skilled in the art.

[0030] In the following description, terms for identifying an access node, terms for indicating a network entity or a network function (NF), terms for indicating a message, terms for indicating an interface between network objects, terms for indicating various identification information, etc. are provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms for indicating objects having equivalent technical meanings may be used.

[0031] For the sake of convenience, some of the terms and names defined in the 3GPP (3rd Generation Partnership Project Long Term Evolution), IETF (Internet Engineering Task Force) and IEEE 802 Project standards may be used below. However, the present invention is not limited to these terms and names and may be similarly applied to systems based on other standards.

[0032] Hereinafter, various embodiments according to the technical concept of the present invention will be described in detail.

[0033] The O-RAN Distributed Unit (O-DU) is a part of the O-RAN system that is generally implemented in software. More specifically, the O-DU is a logical node that hosts the RLC / MACI High-PHY layer based on the lower layer functional division. The O-RAN Radio Unit (O-RU) is a logical node that hosts the RF processing and Low-PHY layer based on the lower layer functional division. It is capable of transmitting and receiving radio signals, which is the main feature of the 3GPP "TRP" or "RRH."

[0034] User Equipment (UE) is a device, such as a mobile phone, that allows a user to access network services.

[0035] The uplink (UL) refers to the flow of traffic from the UE to the network and from the O-RU to the O-DU through different network elements. The interface from the UE to the O-RU is wireless, while the UL traffic from the O-RU to the O-DU can take various forms, such as wireless or wired (e.g., Ethernet connection).

[0036] The downlink (DL) refers to the flow of traffic through network elements from the O-DU to the O-RU and from the network to the UE. The fronthaul interface from the O-DU to the O-RU can take various forms, such as wired or wireless (e.g., Ethernet), while the interface from the O-RU to the UE is a wireless interface.

[0037] The O-RAN specification has four planes: the user plane (U-plane), the control plane (C-plane), the synchronization plane (S-plane), and the management plane (M-plane).

[0038] The user plane (U-plane) is a concept that includes the IQ sample data transmitted between the O-DU and the O-RU.

[0039] The control plane (C-plane) is a concept that particularly refers to scheduling information, beamforming information transmission, and other real-time controls between the O-DU and O-RU, and is distinct from the UE control plane.

[0040] The synchronization plane (S-plane) generally includes the configuration and exchange of information for time and frequency synchronization schemes, and may include other network elements in addition to the O-DU and O-RU.

[0041] The management plane (M-plane) is a concept that represents non-real-time management operations for the O-RU. Such non-real-time management operations are performed bidirectionally by the O-RU and the O-RU controller, which may reside in the O-DU or the service management and orchestration system (SMO) or exist as a separate device.

[0042] The M-plane interface is the link between the O-RU controller and the O-RU for sending and receiving non-real-time management information.

[0043] The section type is a delimiter in the C-plane message format and consists of different data fields depending on the purpose, such as the scheduling format, the beamforming information configuration format, the ACK / NACK indication response, and the LAA information exchange.

[0044] Section extension data is optional additional information attached to the end of section data in C-plane messages that mainly flow from O-DU to O-RU. It can convey additional real-time control information to support purposes or achieve optimization that cannot be achieved in general configuration formats.

[0045] A shared cell refers to a scheme in which multiple O-RUs operate within the same cell with one or more component carriers.

[0046] Depending on the number of network elements of O-DU and O-RU and the link (or data flow), it can be classified as shown in Table 1 below.

[0047] [Table 1] Classification of cell types according to the number and configuration of DUs and RUs [Table 1]

[0048] Starting from the premise of an acceptable configuration without additional implementation or major changes of the UE, the UE basically recognizes existing cells without distinguishing between shared and non-shared cells. Therefore, the cell identity is maintained as a single cell regardless of the cell type. When a cell is composed of multiple O-RUs, there is an advantage that interference between radio signals can be minimized in broadcasting channels such as System Information Block (SIB) 1 and control channels such as group common PDCCH, which are provided as a single layer within the cell, thereby providing an excellent radio environment.

[0049] However, in a shared cell, some signals, such as a synchronization signal (SS) / physical broadcast channel (PBCH) and a channel state information-reference signal (CSI-RS), can be assigned to individual or groups of O-RUs to support positioning and selective operation. Therefore, individual O-RUs in a shared cell are not always intended to operate in the same way.

[0050] From the perspective of the O-DU, cell type 2A (shared cell) has essentially the same operating principle as cell type 1. However, due to the configuration of multiple O-RUs, there are differences in the expected cell performance and cell configuration requirements. From the perspective of radio signal quality, there is an increase in noise power in the uplink signal (UL signal) in proportion to the number of O-RUs. From the perspective of message handling, to process all network entities as a single message like cell type 1, the link intermediate process between the O-DU and O-RU requires the function of copying downlink directional messages and combining uplink directional messages. Here, combining is a concept that includes expressions such as sum, aggregate, and add. In O-RAN, the network node responsible for this function is defined as a fronthaul multiplexer (FHM) or cascade O-RU.

[0051] In the FHM mode, a shared cell can be configured such that an FHM function is located between at least one O-DU and multiple O-RUs. The FHM function performs copy and combining functions and supports LLS fronthaul like a general O-RU. Here, combining includes expressions such as combine, sum, aggregate, and add. Multiple O-RUs connected to the FHM can all share one cell or can be designed to be divided into multiple cells and shared by groups.

[0052] As an example of the cascade mode, one O-RU is directly connected to the O-DU, and other O-RUs are connected to this O-RU in a serial connection configuration.

[0053] 1A illustrates a wireless communication system according to various embodiments of the present invention. Fig. 1A illustrates some of the nodes that use wireless channels in the wireless communication system, including a base station 110, a first terminal 120, and a second terminal 130. Although Fig. 1A illustrates only one base station, one or more other base stations identical to or similar to base station 110 may also be included.

[0054] The base station 110 is a network infrastructure that provides wireless connectivity to the terminals 120 and 130. The base station 110 has coverage, which is defined as a certain geographical area based on the distance over which signals can be transmitted. The base station 110 may also be called an "access point (AP)," "eNode B (eNB)," "5G node (5th generation node)," "gNB (next generation Node B, gNB)," "wireless point," "transmission / reception point (TRP)," or other terms with equivalent technical meanings, in addition to a base station.

[0055] Each of the terminals 120 and 130 is a device used by a user and communicates with the base station 110 via a wireless channel. A link from the base station 110 to the first terminal 120 or the second terminal 130 is called a downlink (DL), and a link from the first terminal 120 or the second terminal 130 to the base station 110 is called an uplink (UL). The first terminal 120 and the second terminal 130 can communicate with each other via a wireless channel. In some cases, at least one of the first terminal 120 and the second terminal 130 may be operated without the involvement of the user. That is, at least one of the first terminal 120 and the second terminal 130 is a device that performs machine type communication (MTC) and does not need to be carried by the user. Each of the first terminal 120 and the second terminal 130 may be referred to as "user equipment (UE)," "customer premises equipment (CPE)," "mobile station," "subscriber station," "remote terminal," "wireless terminal," "electronic device," "user device," or other terms having equivalent technical meanings.

[0056] In conventional communication systems with relatively large base station cell radii, each base station was installed to include a digital processing unit (DU) and a radio frequency (RF) processing unit (RU). However, as higher frequency bands are used in 4th generation (4G) and / or later communication systems and base station cell radii become smaller, the number of base stations required to cover a specific area increases, increasing the installation costs for operators to install the increased number of base stations. To minimize base station installation costs, a structure has been proposed in which the DU and RU of a base station are separated, one or more RUs are connected to one DU via a wired network, and one or more RUs are distributed geographically to cover a specific area.

[0057] 1B shows an example of a fronthaul structure based on functional separation of a base station according to various embodiments of the present invention. The fronthaul refers to an entity between a wireless LAN and a base station, unlike a backhaul between a base station and a core network.

[0058] 1B, the base station 110 includes a DU 160 and an RU 180. A fronthaul 170 between the DU 160 and the RU 180 is operated via an Fx interface. For operation of the fronthaul 170, an interface such as an enhanced common public radio interface (eCPRI) or radio over Ethernet (ROE) may be used.

[0059] As communication technology advances, mobile data traffic has increased, which has significantly increased the bandwidth requirements for the fronthaul between the DU and RU. In deployments such as C-RAN (centralized / cloud radio access network), the DU performs functions such as packet data convergence protocol (PDCP), radio link control (RLC), media access control (MAC), and physical layer (PHY), while the RU performs functions related to the PHY layer in addition to the radio frequency (RF) function.

[0060] The DU 160 is responsible for higher layer functions of the wireless network. For example, the DU 160 may perform functions of the MAC layer and part of the PHY layer. Here, the part of the PHY layer refers to functions of the PHY layer performed at a higher level, and may include, for example, channel coding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). According to an embodiment, if the DU 160 complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU). The DU 160 may be substituted for and expressed as a first network entity for a base station (e.g., a gNB) in embodiments of the present invention, as needed.

[0061] The RU 180 is responsible for lower layer functions of the radio network. For example, the RU 180 can perform part of the PHY layer and RF functions. Here, part of the PHY layer refers to functions of the PHY layer that are performed at a relatively lower level than the DU 160, including, for example, IFFT (or FFT) transformation, CP insertion (CP removal), and digital beamforming. A specific example of such functional separation is described in detail in FIG. 4. The RU 180 may also be referred to as an "access unit (AU)," "access point (AP)," "transmission / reception point (TRP)," "remote radio head (RRH)," "radio unit (RU)," or other terms having equivalent technical meanings. In one embodiment, if the DU 180 complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU). The RU 180 may be replaced with a second network entity (e.g., another FHM) for a base station (e.g., gNB) in embodiments of the present invention, as needed.

[0062] In fronthaul communication between the DU 160 and the RU 180, the RU 180 must continuously perform radio transmission and reception as specified in the 3GPP TS within error limits (e.g., frequency time error, time alignment error, etc.) defined for time and frequency resources. To this end, timing and latency must be managed for each network element in the network infrastructure. In particular, strict timing control and high accuracy are required for the DU and RU that process physical layer signal processing. Functional split option 7 performs signal processing based on each symbol, so IQ data corresponding to each symbol and its processing information must be transmitted between the DU 160 and the RU 180 within a certain latency. The message arrival time is determined by the transmission time and delay time and is expressed by the following equation:

[0063] Sending time (window) + delay time ≦ Arrival time (window)

[0064] Transmit window+transport delay≦receive window

[0065] Typically, there is a DU fixed timing processing method that ensures sufficient margin for transmission delay based on the timing of the RU 180, and a DU dynamic timing processing method that takes advantage of the time secured by varying the message transmission and reception time for fronthaul transmission delay. This is determined by the DU 160 as it depends on the message timing management capability of the DU 160. Since it is generally advantageous for the RU 180 to process messages in the shortest time possible using optimal resources, the RU 180 provides a delay profile according to certain criteria. These criteria include subcarrier spacing, bandwidth, fronthaul line rate, buffer depth, and transport flow. Because there are so many parameters between the DU 160 and RU 180 for message delay management, optimization based on vendor consultations according to use cases is generally expected rather than a convergence process based on general requirements and relationships. Even if the DU 160 dynamic timing processing method is used, this means dynamic changes depending on the use case and deployment, but does not mean dynamic changes to delays that change dynamically in already configured cells. Of course, the method can be extended to support semi-static with degradation of service, but there is currently no significant advantage.

[0066] O-RAN message timing is managed to ensure smooth transmission and reception between the DU 160 and RU 180 in relation to transport delay. The uplink combining function of U-plane messages for FHM and Cascade O-RU operates based on ta3-prime-max, which is currently based on reference timing tul=0. Ta3-prime-max is determined taking into account Ta4-max at the DU and fronthaul transport delay (FH transport delay).

[0067] Figure 2 is a diagram of an O-RAN network system according to an embodiment of the present invention. According to Figure 2, the O-RAN network is a network in which the functions of eNB and gNB in ​​existing 4G and 5G systems are logically separated. O-RAN-related standards define a non-real-time (NRT)-RIC (RAN intelligent controller) 210, a RIC 220 in an O-RAN base station 200, an O-CU-CP 230, an O-CU-UP 240, an O-DU 250, and an O-RU 260. The NRT-RIC 210 is a logical node that enables non-real-time control and optimization of RAN elements and resources, model training and updates, etc. The RIC 220 is a logical node that has a centralized server located in one physical location and enables near-real-time control and optimization of RAN elements and resources based on data collected from the O-DU 250, the O-CU-CP 230, the O-CU-UP 240, etc. via an E2 interface. The O-CU, including the O-CU-CP 230 and O-CU-UP 240, is a logical node that provides the functions of the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocols. The O-CU-CP 230 is a logical node that provides the C-plane functions of RRC and PDCP, and the O-CU-UP 240 is a logical node that provides the U-plane functions of SDAP and PDCP. The O-CU-CP 230 is connected to the access and mobility management function (AMF) included in the 5G network (5G core) via the NGAP interface. The O-DU 250 is a logical node that provides RLC, MAC, and high-PHY functions. The O-RU 260 connected to the O-DU 250 is a logical node that provides low-PHY functions and RF processing.In FIG. 2, each logical node is shown singular, but each logical node may be connected in multiple numbers. For example, one O-DU 250 may be connected to multiple O-RUs 260, and one O-CU-UP 240 may be connected to multiple O-DUs 250.

[0068] The present invention is not limited by the names of the nodes described above, and the configuration of the present invention can be applied to logical nodes or entities that perform the functions described above. Furthermore, the logical nodes may be located in the same physical location or in other locations, and their functions may be provided by the same physical device (e.g., a processor, a controller, etc.) or by other physical devices. For example, the functions of at least one of the logical nodes described above may be provided by virtualization in one physical device. Hereinafter, O-DU and O-RU may be referred to interchangeably as DU and RU, respectively.

[0069] 3 is a diagram showing the structure of an O-RAN wireless communication system according to an embodiment of the present invention. The wireless communication system includes a base station 305 and at least one UE 330a, 330b, ..., 330f. The base station includes a CU 310, at least one DU 315a and 315b, an FHM 320, and at least one RU 325a, 325b, ..., 325f. Here, the CU, DU, FHM, and RU are all included within a base station or exist as entities with separate functions.

[0070] In one embodiment, the wireless communication system is a radio access network (RAN), such as an open-RAN. Generally, a RAN includes a network, including base stations, and a connection between UEs. An O-RAN includes all functions and components within a RAN and can interoperate with other functions or components. Like a traditional RAN structure, an O-RAN can also use a CU / DU split structure. The RU generally has functions for transmitting, receiving, amplifying, and digitizing radio frequency signals. In one embodiment, the RU is located near the antenna and the DU. The CU is located closer to the core network. The FHM acts as an interface between the RU and the DU and can multiplex or demultiplex information received from the RU before providing the information to the DU. The CU 310, DU, FHM, and RU may be referred to as O-CU, O-DU, O-FHM, and O-RU, respectively.

[0071] In O-RAN architecture, the shared cell structure includes an RU that combines incoming I / Q samples before transmitting them from the RU to the DU. In O-RAN architectures that utilize CU / DU splitting, the structure can be defined in two modes:

[0072] The first mode is the FHM mode, in which the FHM 320 can retrieve compressed information along with I / Q samples from all O-RUs 325a, 325b, and 325c connected to it through signaling. Multiple O-RUs are connected to the FHM, and each RU associates with or communicates with one or more UEs.

[0073] The second mode is defined as the cascade mode (or cascade O-RU mode). The cascade O-RUs 325d and 325e can retrieve the compressed information along with the I / Q samples by messaging with the southbound node O-RU (e.g., the trailing O-RU, downstream O-RU). The upstream O-RU can perform combining to transmit the I / Q samples to the next RU or DU.

[0074] 4 illustrates the structure of an Ethernet message according to an embodiment of the present invention. The destination MAC (medium access control) address 400 in the header of the Ethernet message indicates the public address of the RU in the DL case, and indicates the public address of a specific port of the DU's channel card in the UL case (which performs the MAC layer operations responsible for scheduling, the high-PHY operations, and the operation of converting data formats via the interface between the RU and DU). The source MAC address 410 indicates the RU in the UL case, and indicates the public address of a specific port of the DU's channel card in the DL case.

[0075] The VLAN (virtual LAN) tag 420 has a size of 4 bytes and enables C-plane, U-plane, or S-plane messages to be mapped and managed to different VLAN tags. The tag protocol identifier (TPID) included in the VLAN tag 420 is set to 16 bits and can be set to 0x8100 to identify the frame as an IEEE 802.1Q tagged frame. This field is located in the same position as the Ethertype / Length field in untagged frames and can be used to distinguish untagged frames from general frames. Similarly, the tag control information (TCI) included in the VLAN tag is set to 16 bits and includes the following three fields: The priority code point (PCP) is 3 bits and represents the frame priority. The drop eligible indicator (DEI) is set to 1 bit and can be used separately or in combination with the PCP to distinguish frames that should be dropped when traffic is congested. The VLAN identifier (VID) is set to 12 bits and is a field that indicates which VLAN the frame belongs to. All values ​​except the reserved values ​​0x000 and 0xFFF are used as VLAN identifiers, allowing up to 4,094 VLANs. The reserved value 0x000 indicates that the frame does not belong to any VLAN; in this case, 802.1Q specifies only the priority, which can be referred to as the priority tag. The Type / Length (Ethertype) is set to a fixed value of 0xAEFE for CPRI.

[0076] Payload 440 may include a message in each plain format including an eCPRI header, as shown in Fig. 4. Not all fields or information contents of the Ethernet message described with reference to Fig. 4 necessarily need to be included, and the present invention may be implemented by omitting or / and adding other fields as needed.

[0077] 5A and 5B are diagrams illustrating an example of a C-plane message according to an embodiment of the present invention, where FIG. 5A illustrates a C-plane structure for section type 1, and FIG. 5B illustrates a C-plane structure for section type 3.

[0078] First, to explain each field in Figure 5A, the transport header 501 contains information according to the eCPRI header shown in Figure 4 or IEEE-1914.3. The dataDirection 502 indicates the direction of the U-Plane message, with 0 indicating UL and 1 indicating DL. The filterIndex 504 indicates the channel filter of the RU and is set to 0x1. The frameId 506 indicates a specific frame in 10 ms units. The subframeId 508 indicates a specific subframe within the frame in 1 ms units. The slotId 510 indicates a specific slot within the frame.

[0079] The numberOfsections 514 indicates the number of sections indicated by the message. The SectionType 516 indicates only one section type for a C-plane message. In this example, it indicates section type 1. The udCompHdr 518 indicates the IQ bit width and compression method for the IQ data of all sections of the message. Specifically, the upper 4 bits are iqWidth, which indicates 1 to 16 bits, and the lower 4 bits are compMeth, which indicates the compression method. The above-mentioned 502 to 518 are application headers 540 that can be commonly applied to the message and can be included in all C-plane messages with a similar structure.

[0080] A C-plane message of section type 1 includes information about a given section. SectionID 522 indicates the section ID, which can be used to match the C-plane message with the U-plane mesh. rb 524 indicates which PRB is used, with 0 indicating all PRBs are used and 1 indicating every other PRB is used. StartPrbc 526 is used to indicate the first PRB of the section, and numPrbc 528 indicates the number of PRBs in the section. reMask 530 is a bit pattern that indicates the RE (or subcarrier) corresponding to a specific beam in the PRB, and different beams can be applied within one PRB through reMask. numSymbol 532 indicates the number of symbols corresponding to the section. The above fields are referred to as a section header 542 for each section.

[0081] The C-plane message also includes a section extension, and whether or not the section extension is included is indicated by ef 520. The contents of each field or information described with reference to Fig. 5A do not necessarily include all fields, and the present invention can be carried out by omitting or / and adding other fields as necessary.

[0082] Referring to Figure 5B, the fields from the transport header to the section type are the same as those in Figure 5A, but there are differences in the following fields. Timeoffset 550, framestructure 552, cpLength 554, and udCompHdr 556 are fields that can be identified in the C-plane of section type 3. Timeoffset 550 defines the time offset from the start of the slot to the start of the cyclic prefix (CP). Framestructure 552 defines the frame structure, with the first four bits defining the size of the FFT / iFFT used to process all IQ data related to the C-plane message, and the remaining four bits defining the subcarrier spacing (SPS), the number of slots per 1 ms subframe. cpLength 554 indicates the length of the cyclic prefix. udCompHdr 556 defines the compression method and IQ (in-phase, quadrature) bit width for the user data in the data section. Most of the other fields are similar to those in Figure 5A, so their description will be omitted.

[0083] FIG. 6 is a diagram illustrating the structure of an O-RAN base station including a middle node according to an embodiment of the present invention.

[0084] Referring to FIG. 6, an O-RAN base station (or network) 600 includes at least one O-DU 610a and 610b, middle nodes 620a and 620b, at least one O-RU 630a, 630b, . . . , 640f, and a controller 650.

[0085] Here, at least one of O-DUs 610a and 610b is also referred to as a northbound node with first middle node 620a at the center, and middle nodes 620a and 620b may be used in combination with FHM 620a, Cascade FHM (not shown), or Cascade O-RU 620b, and at least one of O-RUs 630a, 630b, ..., 640f may be used in combination with a southbound node with first middle node 620a at the center. The controller 650 may be included in the O-DUs 610a and 610b, or may exist as a separate device.

[0086] 6, a controller 650 can directly communicate with at least one O-DU 610a and 610b, middle nodes 620a and 620b, and at least one O-RU 630a, 630b, ..., 640f. The controller 650 communicates M-plane messages with at least one O-DU 610a and 610b. The controller 650 communicates M-plane messages with middle nodes 620a and 620b. At least one O-DU 610a and 610b communicates C / U-Plane messages with the middle node 620a. At least one O-DU 610a and 610b communicates C / U-Plane messages directly with at least one O-RU 630a, 630b, ..., 640f. The middle node 620a can communicate with at least one O-RU included in at least one cell (cell #0 and cell #1) 630a and 630b. The first middle node 620a transmits M-plane and C / U-plane messages received from at least one O-DU 610a and 610b or the controller 650 to at least one O-RU 630a, 630b, ..., 640f. In this case, the first middle node 620a can copy and transmit the same message to each O-RU included in the same cell. For example, the same message is copied by the first middle node 620a and transmitted to O-RU #1 630a and O-RU #2 630b included in cell #0 630a. Also, different messages are transmitted from the first middle node 620a to cell #0 630a and cell #1 630b. According to one embodiment, a second middle node 620b may be included within cell 630b. In this case, the second middle node 620b may include an O-RU located southbound from the second middle node 620b and may copy and transmit messages received from the upper level to the O-RU. For example, cell #1 630b includes a second middle node 620b, which copies and transmits data received from the first middle node 620a to O-RU #5 640e and O-RU #6 640f located southbound.

[0087] Referring to FIG. 6, at least one O-RU 630a, 630b, ..., 640f may transmit a U-plane message to a first middle node 620a based on data received from a terminal. The first middle node 620a combines messages received from at least one O-RU 630a, 630b, ..., 640f. Here, "combine" includes expressions such as "combine," "sum," "aggregate," and "add." The first middle node 620a may combine messages received from at least one O-RU 630a, 630b, ..., 640f and transmit the combined messages to at least one O-DU 610a and 610b. In this case, the first middle node 620a may perform combining on data received from O-DUs included in the same cell. According to an embodiment, a middle node 620b may be included within a cell 630b. In this case, the second middle node 620b includes an O-RU located south of the second middle node 620 and can combine messages received from the O-RUs and transmit them to the upper level. For example, in cell #1 630b, the second middle node 620b combines data received from O-RU #5 640e and O-RU #6 640f located in the lower level using a cascade structure, and transmits the combined data to the first middle node 620a located in the upper level. Here, the combination includes expressions such as combine, sum, aggregate, and add. The first middle node 620a combines the data received from the second middle node 620b with the data received from O-RU #3 640c and O-RU #4 640d included in cell #1 630b, and transmits the combined data to the O-DUs 610a and 620b.

[0088] FIG. 7 is a table illustrating slot ID indexes according to one embodiment of the present invention.

[0089] FIG. 7 may show information about mapping of slot identifiers (slotId) and symbol identifiers (symbolId) that an O-RU can support according to a frequency range.

[0090] The numerology most likely supported by the O-RU in a given frequency range FR1 710 or FR2 720 can be used as a common reference (separately for FR1 and FR2) for the start of the slot identified by SlotId. In a communication system, the UL and DL must use the same reference numerology for SlotId. If the numerology most likely supported by the O-RU allows both general CP and extended CP, general CP can be used for reference. The symbol duration and time position are calculated using the μ value (which can be configured via the SCS (sub-carrier spacing) or M-Plane of the message field framework) and the SlotId field of the C / U-Plane message. The sectionId field value of a C / U-Plane message addressed per eAxC must be unique for each slot identified by the SlotId value.

[0091] 7, for FR1 710, the maximum SCS supported by the O-RU is 60 kHz, and in this case, the maximum number of slots per subframe is 4. Therefore, slotIds are set to 0, 1, 2, and 3, and 14 symbolIds are mapped to each slotId. Also, when FR1 710 supports 15 kHz, 30 kHz, and 60 kHz, the μ values ​​are 0, 1, and 2, respectively, and the slotIds are set to 0 / 0, 2 / 0, 1, 2, and 3, respectively.

[0092] In the case of FR2 720, the maximum SCS supported by the O-RU is 240 kHz, and in this case, the maximum number of slots per subframe is 16. Therefore, slotId is set to 0 to 15, and 14 symbolIds can be mapped to each slotId. Also, when FR2 720 supports 60 kHz, 120 kHz, and 240 kHz, the μ values ​​are 2, 3, and 4, respectively, and slotId is set to 0, 4, 8, 12, 0, 2, 4, 6, 8, 10, 12, 14, and 0, 1, 2, 3, ..., 15, respectively.

[0093] In this case, FR1 710 and FR2 720 both support 60 kHz, but because the maximum supported SCS is different, different slotIds are set. For example, FR1 is set to slotId 0, 1, 2, and 3 at 60 kHz, while FR2 is set to slotId 0, 4, 8, and 12 at 60 kHz, which are different settings.

[0094] This is an example, and a problem occurs when the O-RU is included in a shared cell. In fronthaul communication between the O-DU and the O-RU, in the case of a shared cell, the same configuration information must be included and transmitted in a message. However, when the O-RUs included in the shared cell include different frequency ranges such as FR1 and FR2, the O-DUs must transmit the same message, but because of different slotId settings, O-RUs with matching settings can operate, but O-RUs with different settings cannot distinguish the message and do not operate.

[0095] Furthermore, even in the case of not a shared cell, when a DU configures multiple cells by configuring multiple O-RUs each with a cell, the processing capacity of the O-DU can be increased by configuring the individual O-RUs to have a unified slot ID instead of setting one that matches each O-RU. Therefore, from the viewpoint of communication efficiency and reducing the calculation load in general fronthaul communication, a method for setting slot IDs is required.

[0096] In conclusion, in order to configure multiple cells or shared cells in fronthaul communication, a method is required to unify the slotId settings between O-RUs.

[0097] FIG. 8 is a diagram illustrating a method for configuring a slot identifier (slotId) setting according to an embodiment of the present invention.

[0098] The system is comprised of a controller 810 in FIG. 8, at least one O-DU 820, and at least one O-RU 830, where the controller 810 is the same as or similar to the controllers in FIGS. 1A to 6 and is configured to exist as a separate entity or within the O-DU.

[0099] In step S801, the controller 810 requests SlotId configuration capability information from at least one O-DU (or O-DUs) 820. When the O-DU 820 receives a request for SlotId configuration capability information from the controller 810, the O-DU 820 transmits the information through an M-Plane message. According to another embodiment, the O-DU 820 may periodically transmit predetermined SlotId configuration capability information to the controller 810.

[0100] In step S802, the controller 810 requests the capabilities on supported SCS from at least one O-RU (or O-RUs) 830 constituting a cell. When the O-RU 830 receives a request for supported SCS capability information from the controller 810, the O-RU 830 transmits the information via an M-Plane message. According to another embodiment, the O-RU 830 may periodically transmit predetermined supported SCS capability information to the controller 810. For example, in the case of the O-RU of FR1 710 in FIG. 7, the O-RU 830 transmits information indicating that the O-RU 830 can support SCS of 15 kHz, 30 kHz, and 60 kHz to the controller 810.

[0101] In step S803, the controller 810 requests SlotId configuration capabilities from at least one O-RU 830 constituting a cell. When the O-RU 830 receives a request for SlotId configuration capabilities from the controller 810, the O-RU 830 transmits the information via an M-Plane message. According to another embodiment, the O-RU 830 may periodically transmit predetermined SlotId configuration capabilities to the controller 810.

[0102] Here, the SlotId setting capability information includes information (Configurable-SlotId-Supported) indicating whether the communication node can set (or change) the slotId, and information (Configurable-slotId-granularity) indicating the scope of application of the slotId setting. The SlotId setting capability information can be shown as shown in Table 2 below.

[0103] [Table 2]

[0104] The Configurable-SlotId-Supported field indicates information indicating whether the communication node can change the currently set slotId setting according to instructions from the controller. Here, the information indicating whether slotId setting is possible may be included in the form of a configurable-SlotId supported Flag (Boolean type=true) in the YANG model. The configurable-SlotId supported field contains information of True if slotId setting is possible, and contains information of False if slotId setting is not possible. If False or if the leaf does not exist in the message, the communication node supports a slotId value according to the current standard (e.g., a slotId set by the maximum SCS supported by the communication node).

[0105] The Configurable-slotId-granularity field is information indicating the unit to which the configuration information is applied when the communication node configures the slotId. The Configurable-slotId-granularity field is divided into O-RU level, transport-flow level, and endpoint level. The O-RU level indicates that one O-RU data flow configures one SlotId step per SCS, the transport-flow level indicates that one SlotId step per SCS is configured for each transport flow (i.e., for each O-DU), and the endpoint level indicates that one SlotId step per SCS is configured for each endpoint (i.e., for each data flow).

[0106] In step S804, the controller 810 determines whether slotId setting is possible based on the slotId setting capability information and supported SCS capability information received from the communication nodes O-DU and O-RU in steps S801 to S803. If the controller 810 determines that slotId setting is possible, it can set an increment value for the slotId value for each SCS within one sub-node. For example, the controller 810 sets an increment value for the slotId value as shown in Table 3.

[0107] [Table 3]

[0108] The controller 810 sets the increment value of the slotId value for each SCS based on Table 3. The calculation method is as follows:

[0109] [Number 1] Step=2 n , n={0,1,2,3,4}

[0110] The controller 810 generates SlotId setting information based on the information. The SlotId setting information is configured in the format shown in Table 4.

[0111] [Table 4]

[0112] The controller 810 generates slotId setting information based on Table 4. Here, slotId increment is determined by Equation 2.

[0113] [Number 2] SlotId increment=2 n , n={0,1,2,3,4}

[0114] For example, when the SCS is 60 kHz and n=0, slotId=0, 1, 2, 3 are defined, and when the SCS is 120 kHz and n=1, slotId=0, 2, 4, 8, 10, 12, 14 are defined.

[0115] The controller 810 receives slotId setting capability information from multiple O-RUs and generates slotId setting information to change the slotId setting of the O-RUs that report that they can set the slotId. For example, in the case of a shared cell, if the first O-RU supports the slotId setting capability (True) but the second O-RU does not support the slotId setting capability (False), the controller 810 generates slotId setting information so that the first O-RU changes the slotId setting. Also, if all of the multiple O-RUs support the slotId setting capability or if multiple cells are configured, the O-DU generates slotId setting information according to the SCS that is determined to enable optimal communication.

[0116] According to an embodiment, different slotId configuration information can be generated for each O-RU, taking into account the Configurable-slotId-granularity field received in steps S801 to S803.

[0117] In step S805, the controller 810 transmits the slotId configuration information set in step S804 to the O-DU 820. The O-DU 820 that has received the slotId configuration information can use the set slotId when communicating with at least one connected O-RU 830.

[0118] In step S806, the controller 810 transmits the slotId configuration information set in step S804 to at least one O-RU 830 constituting the cell. The O-RU 830 that receives the slotId configuration information can use the set slotId when communicating with the connected O-DU 820.

[0119] 9A is a diagram illustrating a method for performing fronthaul communication in a shared cell according to an embodiment of the present invention, and FIG 9B is a diagram illustrating a method for performing communication in a shared cell by setting a slotId according to another embodiment of the present invention.

[0120] The O-DU 910, middle node (FHM) 920, first O-RU 940, and second ORU 950 in Figures 9A and 9B are the same as the controller, O-DU, middle node, and at least one O-RU in Figures 1A to 8. In Figures 9A and 9B, the O-DU 910 includes a controller.

[0121] 9A , an O-DU 910 can perform fronthaul communication with multiple O-RUs 940 and 950 included in a shared cell 930 via a middle node (e.g., FHM) 920. Here, the first O-RU 940 and the second O-RU 950 included in the same shared cell may support different SCSs. For example, the first O-RU 940 supports 15 and 30 kHz SCSs, while the second O-RU 950 supports 15, 30, and 60 kHz SCSs. In this case, the slotId for each O-RU is set according to the largest SCS size that can be supported. Thus, for the first O-RU 940, slotId 960 for the 30 kHz SCS is set to 0 and 1, and slotId 970 for the 30 kHz SCS for the second O-RU 950 is set to 0 and 2. However, the O-DU 910 cannot transmit different slotIds to the first O-RU 940 and the second O-RU 950 included in the same shared cell (a violation of copy operation), and therefore cannot form a shared cell under the current standard.

[0122] FIG. 9B is a diagram illustrating an example of performing fronthaul communication using a unified slotId through slotId configuration according to an embodiment of the present invention.

[0123] Referring to FIG. 9B, the O-DU 915 can perform fronthaul communication with multiple O-RUs 945 and 955 included in a shared cell 935 via a middle node (e.g., FHM) 925. Here, the third O-RU 945 and the fourth O-RU 955 included in the same shared cell support different SCSs, as shown in FIG. 9A, which poses a problem. However, slotId configuration can be performed based on the method described in FIG. 8. The O-DU 915 receives supported SCS capability information and slotId configuration capability information from each of the O-RUs 945 and 955. The O-DU 915 generates slotId configuration information based on the received SCS capability information and slotId configuration capability information. In FIG. 9B, the slotId configuration information can be generated so that slotId is set to 0 or 1 according to the 30 kHz shared cell or 30 kHz, which is the maximum supported SCS of the third O-RU 945. The O-DU 915 transmits the generated slotId setting information to each O-RU 945 and 955 via the middle node 925. The third O-RU 945 can subsequently perform operations on the message since the slotId setting is the same as its existing slotId setting, and the fourth O-RU 955 has slotId setting capability and the received slotId setting is included in the SCS it supports, so it can change the slotId setting so that slotId is set to 0 and 1, just like the third O-RU. Thereafter, the O-DU 915 can transmit the same message to multiple O-RUs 945 and 955 included in the shared cell 935, and the multiple O-RUs 945 and 955 with the same slotId due to the slotId setting can receive the message from the O-DU and perform operations.

[0124] Fig. 10A is a diagram showing a first embodiment of applying slotId setting according to an embodiment of the present invention. Fig. 10B is a diagram showing a second embodiment of applying slotId setting according to an embodiment of the present invention. Fig. 10C is a diagram showing a third embodiment of applying slotId setting according to an embodiment of the present invention. Fig. 10D is a diagram showing a fourth embodiment of applying slotId setting according to an embodiment of the present invention.

[0125] The O-RUs in Figures 10A to 10D are identical to the O-RUs in Figures 1A to 9B.

[0126] Referring to FIG. 10A, a first O-RU and a second O-RU are included in the same shared cell. The first O-RU supports SCSs of 15 kHz and 30 kHz, and the maximum supported SCS is 30 kHz, so the slotId 1010a for 30 kHz is configured with 0 and 1. The second O-RU supports SCSs of 15 kHz, 30 kHz, and 60 kHz, and the maximum supported SCS is 60 kHz, so the slotId 1020a for 30 kHz is configured with 0 and 2. In this case, slotId configuration is required. Therefore, each O-RU can transmit slotId configuration capability information and supported SCS information to the controller and receive slotId configuration information from the controller. A first method is for the first O-RU to change the slotId configuration. This case corresponds to a case where the second O-RU does not support slotId configuration. In this case, the first O-RU changes the 30 kHz slotId setting 1010b to 0 and 2. A second method is for the second O-RU to change the slotId setting. This applies when the first O-RU does not support slotId changes or when the shared cell is configured at 30 kHz. In this case, the second O-RU changes the 30 kHz slotId setting 1020b to 0 and 1.

[0127] 10B, the third O-RU and the fourth O-RU are included in the same shared cell. The third O-RU supports SCSs of 60 kHz and 120 kHz, and since the maximum supported SCS is 120 kHz, the slotId for 60 kHz is configured as 0, 2, 4, and 8, and the slotId 1030a for 120 kHz is configured as 0 to 7. The fourth O-RU supports SCSs of 60 kHz, 120 kHz, and 240 kHz, and since the maximum supported SCS is 240 kHz, the slotId 1040a for 60 kHz is configured as 0, 4, 8, and 12, and the slotId for 120 kHz is configured as 0, 2, 4, ..., 14. In this case, slotId configuration is required. Therefore, each O-RU can transmit slotId configuration capability information and supported SCS information to the controller and receive slotId configuration information. The first method is for the third O-RU to change the slotId setting. This corresponds to the case where the fourth O-RU does not support slotId changes. In this case, the third O-RU changes the 60 kHz slotId setting 1030b to 0, 4, 8, 12, and changes the 120 kHz slotId setting to 0, 2, 4, ..., 14. The second method is for the fourth O-RU to change the slotId setting. This corresponds to the case where the third O-RU does not support slotId changes or where the shared cell is configured at 120 kHz. In this case, the fourth O-RU changes the 60 kHz slotId setting 1040b to 0, 2, 4, 8, and changes the 120 kHz slotId setting from 0 to 7.

[0128] Referring to Figure 10C, the third O-RU and the fourth O-RU are included in the same shared cell. Figure 10C is a diagram showing a method of configuring slotIds in another manner in a situation similar to Figure 10B. The third O-RU supports SCSs of 60 kHz and 120 kHz, and since the maximum SCS supported is 120 kHz, the slotId for 60 kHz is configured as 0, 2, 4, and 8, and the slotId 1050a for 120 kHz is configured as 0 to 7. The fourth O-RU supports SCSs of 60 kHz, 120 kHz, and 240 kHz, and since the maximum SCS supported is 240 kHz, the slotId 1060a for 60 kHz is configured as 0, 4, 8, and 12, and the slotId for 120 kHz is configured as 0, 2, 4, ..., 14. In this case, slotId configuration is required. Therefore, each O-RU can receive slotId setting information by transmitting slotId setting capability information and supported SCS information to the controller. In the case of Figure 10C, unlike Figure 10B, each O-RU does not change the slotId setting to match that of other O-RUs, but unifies it into a third slotId setting. In this case, the third O-RU sets the 60 kHz slotId setting 1050b to 0, 1, 2, 3, and sets the 120 kHz slotId setting to 0 to 7. Similarly, the fourth O-RU changes the 60 kHz slotId setting 1060b to 0, 1, 2, 3, and changes the 120 kHz slotId setting to 0 to 7.

[0129] Referring to FIG. 10D, the fifth and sixth O-RUs are included in the same shared cell. The fifth O-RU supports SCS of 60 kHz, 120 kHz, and 240 kHz, and the maximum SCS it supports is 240 kHz, so slotId 1070a for 60 kHz is configured as 0, 4, 8, 12, slotId for 120 kHz is configured as 0, 2, 4, ..., 14, and slotId for 240 kHz is configured as 0 to 15. The sixth O-RU supports SCS of 60 kHz, 120 kHz, 240 kHz, and 480 kHz, and the maximum SCS it supports is 480 kHz, so slotId 1080a for 60 kHz is configured as 0, 8, 16, 24, slotId for 120 kHz is configured as 0, 4, 8, ..., 28, slotId for 240 kHz is configured as 0, 2, 4, ..., 30, and slotId for 480 kHz is configured as 0 to 31, in this case, the slotId setting is required. Therefore, each O-RU can receive slotId configuration information by transmitting slotId configuration capability information and supported SCS information to the controller. As a first method, the fifth O-RU changes the slotId setting. This case corresponds to the case where the sixth O-RU does not support slotId changes. In this case, the fifth O-RU changes the 60 kHz slotId setting 1070b to 0, 8, 16, 24, the 120 kHz slotId setting to 0, 4, 8, ..., 28, and the 240 kHz slotId setting to 0, 2, 4, ..., 30. As a second method, the sixth O-RU changes the slotId setting. This case corresponds to the case where the fifth O-RU does not support slotId changes or where the shared cell is configured at 240 kHz. In this case, the sixth O-RU changes the 60 kHz slotId setting 1080b to 0, 4, 8, 12, the 120 kHz slotId setting to 0, 2, 4, . . . , 14, and the 240 kHz slotId setting from 0 to 15.

[0130] 10A to 10D merely illustrate some embodiments of the method of the present invention, and it goes without saying that the actual use examples are not limited to these embodiments and can be utilized in various ways depending on the frequency range of the O-RU depending on the situation.

[0131] FIG. 11 is a flowchart illustrating a method for setting slotId according to one embodiment of the present invention.

[0132] FIG. 11 shows the operations performed by the controller, O-DU, and O-RU described in FIGS. 1A to 10D and FIG.

[0133] In step S1101, the controller receives SCS capability information from the O-RU. According to one embodiment, the controller requests SCS capability information from the O-RU and receives the SCS capability information in response to the request. Alternatively, the O-RU may periodically transmit SCS capability information to the controller. The SCS capability information includes information about the SCS supported by the O-RU.

[0134] In step S1102, the controller receives SlotId setting capability information from the O-RU. According to one embodiment, the controller requests SlotId setting capability information from the O-RU and receives the SlotId setting capability information in response to the request. Alternatively, the O-RU may periodically transmit the SlotId setting capability information to the controller. The SlotId setting capability information includes information indicating whether the O-RU can change the SlotId setting.

[0135] In step S1103, the controller generates SlotId setting information based on the capability information received in steps S1101 and S1102. The controller identifies whether the slotId setting capability information of at least one O-RU from the received slotId setting capability information includes information indicating that the slotId can be changed. If the slotId setting capability information of the at least one O-RU includes information indicating that the slotId can be changed, the controller may generate slotId setting information based on the SCS capability information of other O-RUs whose slotId setting capability information includes information indicating that the slotId cannot be changed.

[0136] In step S1104, the controller transmits the generated slotId setting information to the O-DU and O-RU. The O-RU changes the slotId setting based on the received slotId setting information. The O-DU and O-RU can perform fronthaul communication based on the received slotId setting information.

[0137] FIG. 12 is a diagram illustrating a method for communicating with O-RUs that constitute multiple cells by setting slotIds according to an embodiment of the present invention.

[0138] The O-DU 1210, first O-RU 1230, and second ORU 1240 in Fig. 12 are the same as the controller, O-DU, and at least one O-RU in Fig. 1A to Fig. 6 and Fig. 8. In Fig. 12, the O-DU 1210 is configured to include a controller.

[0139] Referring to FIG. 12 , the O-DU 1210 can perform fronthaul communication with multiple O-RUs 1230 and 1240 that constitute each cell. Here, the SCSs supported by the first O-RU 1230 and the second O-RU 1240 are set to be different from each other. For example, the first O-RU 1230 supports SCSs of 15 and 30 kHz, while the second O-RU 1240 supports SCSs of 15, 30, and 60 kHz. In this case, the slotId for each O-RU is set according to the largest SCS size that can be supported. Therefore, for the first O-RU 1230, the slotId 1250 for the 30 kHz SCS is set to 0 and 1, and the slotId 1260 for the 30 kHz SCS of the second O-RU 1240 is set to 0 and 2. However, since the O-DU 1210 transmits messages containing different slotIds to the first O-RU 1230 and the second O-RU 1240, a separate calculation is required each time a message is transmitted, resulting in a waste of resources and an increased calculation load.

[0140] However, slotId configuration can be performed based on the method described in the present invention. The O-DU 1210 receives supported SCS capability information and slotId setting capability information from each of the multiple O-RUs 1230 and 1240. The O-DU 1210 generates slotId configuration information based on the received SCS capability information and slotId setting capability information. The O-DU 1210 can generate slotId configuration information such that slotId is set to 0 and 1 in accordance with 30 kHz, the maximum supported SCS of the first O-RU 1230, taking into account the fronthaul communication state. For example, the O-DU 1210 generates slotId configuration information based on the slotId setting included in the largest number of O-RUs among the multiple connected O-RUs. Alternatively, the O-DU 1210 generates slotId configuration information based on a method that provides the highest communication quality. The O-DU 1210 transmits the generated slotId setting information to each O-RU 1230 and 1240. Since the first O-RU 1230 has the same slotId setting as its existing slotId setting, it can subsequently perform operations on messages received from the O-DU. Since the second O-RU 1240 has slotId setting capability and the received slotId setting is included in the SCS it supports, it can change the slotId setting so that slotId is set to 0 and 1, just like the first O-RU 1230. Thereafter, the O-DU 1210 can transmit messages with the same slotId configuration to multiple O-RUs 1230 and 1240 without additional calculations, and multiple O-RUs 1230 and 1240 with unified slotIds due to the slotId setting can receive messages from the O-DU and perform operations.

[0141] FIG. 13 is a diagram illustrating the configuration of a controller according to an embodiment of the present invention.

[0142] The controller of FIG. 13 is the same as the controller or O-DU described in FIGS. 1A through 12 and is configured to perform the same or similar operations.

[0143] According to an embodiment of the present invention, the controller 1300 may include each function in one device, and each function may be divided into its own device.

[0144] A controller 1300 according to one embodiment of the present invention includes a controller (or processor) 1310 that controls the overall operation of the controller, a transceiver (or transceiver unit) 1320 that includes a transmitter and a receiver, and memory 1330. Of course, this is not intended to be limiting, and the controller 1300 may include more or less components than those shown in FIG.

[0145] According to an embodiment of the present invention, the transceiver 1320 can transmit and receive signals to and from other network nodes (e.g., southbound nodes, northbound nodes, O-RUs, O-DUs, middle nodes, and upper network entities). Signals transmitted and received from the controller include C-plane, U-plane, S-plane, and M-plane signals, uplink data, and downlink data. In addition, the transceiver 1320 receives signals via a wireless path or a wired path such as fiber, transfers the signals to the processor 1310, and transmits signals determined and output from the processor 1310 via the path.

[0146] According to one embodiment of the present invention, the processor 1310 can control the controller device to perform any one of the operations of the embodiments of Figures 1A to 12. The processor 1310, memory 1330, and transceiver 1320 do not necessarily have to be implemented as separate modules, but can be implemented as a single component, such as a single chip. The processor 1310, memory 1330, and transceiver 1320 are electrically connected to each other. The processor 1310 can also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0147] According to an embodiment of the present invention, memory 1330 may store data such as basic programs, applications, and setting information for the operation of controller 1300. Memory 1330 also stores uplink and downlink data received by the controller. In particular, memory 1330 provides stored data in response to a request from processor 1310. Memory 1330 may be configured as a storage medium such as ROM, RAM, a hard disk, a CD-ROM, or a DVD, or a combination of storage media. Memory 1330 may also be multiple. Processor 1310 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in memory 1330.

[0148] FIG. 13 is a diagram illustrating the configuration of a controller according to an embodiment of the present invention.

[0149] The controller of FIG. 13 is the same as the controller or O-DU described in FIGS. 1A through 12 and is configured to perform the same or similar operations.

[0150] According to an embodiment of the present invention, the controller 1300 may include each function in one device, and each function may be divided into its own device.

[0151] A controller 1300 according to one embodiment of the present invention includes a controller (or processor) 1310 that controls the overall operation of the controller, a transceiver (or transceiver unit) 1320 that includes a transmitter and a receiver, and memory 1330. Of course, this is not intended to be limiting, and the controller 1300 may include more or less components than those shown in FIG.

[0152] According to an embodiment of the present invention, the transceiver 1320 can transmit and receive signals to and from other network nodes (e.g., southbound nodes, northbound nodes, O-RUs, O-DUs, middle nodes, and upper network entities). Signals transmitted and received from the controller include C-plane, U-plane, S-plane, and M-plane signals, uplink data, and downlink data. The transceiver 1320 also receives signals via a wireless path or a wired path such as fiber, transfers the signals to the processor 1310, and transmits signals determined and output from the processor 1310 via the path.

[0153] According to one embodiment of the present invention, the processor 1310 can control the controller device to perform any one of the operations of the embodiments of Figures 1A to 12. The processor 1310, memory 1330, and transceiver 1320 do not necessarily have to be implemented as separate modules, but can be implemented as a single component, such as a single chip. The processor 1310, memory 1330, and transceiver 1320 are electrically connected to each other. The processor 1310 can also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0154] According to an embodiment of the present invention, memory 1330 may store data such as basic programs, applications, and setting information for the operation of controller 1300. Memory 1330 also stores uplink and downlink data received by the controller. In particular, memory 1330 provides stored data in response to a request from processor 1310. Memory 1330 may be configured as a storage medium such as ROM, RAM, a hard disk, a CD-ROM, or a DVD, or a combination of storage media. Memory 1330 may also be multiple. Processor 1310 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in memory 1330.

[0155] FIG. 14 illustrates a configuration of a middle node according to an embodiment of the present invention.

[0156] The middle node in FIG. 14 is the same as the middle node (FHM, cascaded FHM or cascaded O-RU) described in FIGS. 1A to 12 and is configured to perform the same or similar operations.

[0157] According to an embodiment of the present invention, the middle node 1400 may include the middle nodes (FHM, cascaded O-RU) described in Figures 1A to 12. In the middle node, each function is included in one device, and each function is separated into each device.

[0158] The middle node 1400 according to one embodiment of the present invention includes a controller (or processor) 1410 that controls the overall operation of the middle node, a transceiver (or transceiver unit) 1420 including a transmitter and a receiver, and memory 1430. Of course, the above example is not limiting, and the middle node 1400 may include more or less components than those shown in FIG.

[0159] According to an embodiment of the present invention, the transceiver 1420 can transmit and receive signals to and from other network nodes (e.g., southbound nodes, northbound nodes, O-DUs, O-RUs, controllers, and other middle nodes). Signals transmitted and received from middle nodes include C-plane, U-plane, S-plane, and M-plane signals, uplink data, and downlink data. In addition, the transceiver 1420 receives signals via a path such as a fiber, transfers them to the processor 1410, and transmits signals determined and output from the processor 1410 via the channel.

[0160] According to an embodiment of the present invention, the processor 1410 can control the middle node device to perform any one of the operations of the embodiments of FIGS. 1A to 12. The processor 1410, memory 1430, and transceiver 1420 do not necessarily have to be implemented as separate modules, but can be implemented as a single component, such as a single chip. The processor 1410, memory 1430, and transceiver 1420 are electrically connected to each other. The processor 1410 can also be an application processor (AP), a communication processor (CP), a circuit, an application-specific circuit, or at least one processor. The processor 1410 of the middle node 1400 includes a combiner, copier, pager, trigger generator, and parser for performing operations. Each function can be implemented as a separate device or as a function within the processor 1410. The processor controls the operation of the combiner, copier, pager, trigger generator, and parser. The parser analyzes received C / U, M, and S-plain messages to identify information contained in the messages. The trigger generator calculates symbol timing based on the identified information or generates combined timing or combined triggers. The pager retrieves uplink data stored in memory according to the generated trigger. The combiner combines the retrieved data.

[0161] According to an embodiment of the present invention, memory 1430 may store data such as basic programs, applications, and configuration information for the operation of the middle node. Memory 1430 also stores uplink and downlink data received by the middle node. In particular, memory 1430 provides stored data in response to a request from processor 1410. Memory 1430 may be configured as a storage medium, such as a ROM, RAM, hard disk, CD-ROM, or DVD, or a combination of storage media. Memory 1430 may include at least one buffer for temporarily storing uplink data or downlink data. Memory 1430 may also be multiple. Processor 1410 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in memory 1430.

[0162] FIG. 15 is a diagram showing the configuration of an O-DU according to an embodiment of the present invention.

[0163] The O-DU in FIG. 15 is the same as the O-DU described in FIGS. 1A to 12 and is configured to perform the same or similar operations.

[0164] According to an embodiment of the present invention, the O-DU 1500 may have each function included in one device, and each function may be divided into its own device.

[0165] The O-DU 1500 according to one embodiment of the present invention includes a controller (or processor) 1510 that controls the overall operation of the O-DU, a transceiver (or transceiver unit) 1520 that includes a transmitter and a receiver, and a memory 1530. Of course, the above example is not limiting, and the O-DU 1500 may include more or less components than those shown in FIG.

[0166] According to an embodiment of the present invention, the transceiver 1520 can transmit and receive signals to and from other network nodes (e.g., southbound nodes, northbound nodes, O-RUs, controllers, middle nodes, and upper network entities). Signals transmitted and received from middle nodes include C-plane, U-plane, S-plane, and M-plane signals, uplink data, and downlink data. In addition, the transceiver 1520 receives signals via a wireless path or a wired path such as fiber, transfers the signals to the processor 1510, and transmits the signals determined and output from the processor 1510 via the channel.

[0167] According to one embodiment of the present invention, the processor 1510 can control the O-DU device to perform any one of the operations of the embodiments of Figures 1A to 12. Meanwhile, the processor 1510, memory 1530, and transceiver 1520 do not necessarily have to be implemented as separate modules, but can be implemented as a single component in the form of a single chip, for example. The processor 1510, memory 1530, and transceiver 1520 are electrically connected to each other. The processor 1510 can also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0168] According to an embodiment of the present invention, the memory 1530 may store data such as basic programs, applications, and setting information for the operation of the O-DU 1500. The memory 1530 also stores uplink and downlink data received by the O-DU. In particular, the memory 1530 provides the stored data in response to a request from the processor 1510. The memory 1530 may be configured as a storage medium such as a ROM, a RAM, a hard disk, a CD-ROM, or a DVD, or a combination of storage media. The memory 1530 may also be multiple. The processor 1510 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in the memory 1530.

[0169] FIG. 16 is a diagram showing the configuration of an O-RU according to an embodiment of the present invention.

[0170] The O-RU of FIG. 16 is the same as the O-RU described in FIGS. 1A through 12 and is configured to perform the same or similar operations.

[0171] According to an embodiment of the present invention, O-RU 1600 may have each function included in one device, or each function may be separated into its own device.

[0172] O-RU 1600 according to one embodiment of the present invention includes a controller (or processor) 1610 that controls the overall operation of the O-RU, a transceiver (or transceiver unit) 1620 that includes a transmitter and a receiver, and memory 1630. Of course, this example is not limiting, and O-RU 1600 may include more or less components than those shown in FIG.

[0173] According to an embodiment of the present invention, the transceiver 1620 can transmit and receive signals to and from other network nodes (e.g., southbound node, northbound node, O-DU, controller, middle node, upper network entity). Signals transmitted and received to and from the middle node include C-plane, U-plane, S-plane, M-plane signals, uplink data, and downlink data. In addition, the transceiver 1620 receives signals via a wireless path or a wired path such as fiber, transfers the signals to the processor 1610, and transmits the signals determined and output from the processor 1610 via the channel.

[0174] According to one embodiment of the present invention, the processor 1610 can control the O-RU device to perform any one of the operations of the embodiments of Figures 1A to 12. Meanwhile, the processor 1610, memory 1630, and transceiver 1620 do not necessarily have to be implemented as separate modules, but can be implemented as a single component, such as a single chip. The processor 1610, memory 1630, and transceiver 1620 are electrically connected to each other. The processor 1610 can also be an AP (Application Processor), a CP (Communication Processor), a circuit, an application-specific circuit, or at least one processor.

[0175] According to one embodiment of the present invention, memory 1630 may store data such as basic programs, applications, and configuration information for the operation of O-RU 1600. Memory 1630 also stores uplink and downlink data received by the O-RU. In particular, memory 1630 provides stored data in response to a request from processor 1610. Memory 1630 may be configured as a storage medium such as ROM, RAM, a hard disk, a CD-ROM, or a DVD, or a combination of storage media. Memory 1630 may also be provided in a plurality of locations. Processor 1610 may perform the above-described embodiments based on a program for performing the above-described embodiments of the present invention stored in memory 1630.

[0176] The various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions, including, but not limited to, various hardware and / or software components and / or modules, such as an application specific integrated circuit (ASIC), or a processor. Generally, where there are corresponding operations in the figures, such operations may also have corresponding relative means and functional components with the same numbers.

[0177] The various illustrative logic blocks, modules, and circuits described in connection with the present invention may be embodied or implemented by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions disclosed herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any commercially available processor, controller, microcontroller, or state machine. A processor may also be embodied in a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other configuration.

[0178] Additionally, the term "determining" as used above encompasses a wide variety of actions. For example, "determining" includes calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, database, or other data structure), ascertaining, etc. Also, "determining" includes receiving (e.g., receiving information), accessing (accessing data in a memory), etc. Also, "determining" includes resolving, selecting, choosing, establishing, etc.

[0179] Those skilled in the art will appreciate that various modifications and variations may be made without departing from the essential characteristics of the technical idea of ​​the present invention.

[0180] Therefore, the embodiments exemplified in the present invention are intended to explain, not to limit, the technical idea of ​​the present invention, and the scope of the technical idea of ​​the present invention is not limited by these embodiments.

[0181] The scope of protection of the technical idea of ​​the present invention should be interpreted by the following claims, and all technical ideas within the equivalent range should be interpreted as being included in the technical imaginary scope of the present invention.

Claims

1. 1. A method performed by a controller in a communication system, comprising: receiving sub-carrier spacing (SCS) capability information from each of a plurality of O-RUs; receiving slot identifier (slotId) setting capability information from each of the plurality of O-RUs; generating slotId setting information based on the received SCS capability information and slotId setting capability information; and transmitting the generated slotId setting information to an O-DU and the plurality of O-RUs.

2. The SCS capability information includes information indicating what SCS each of the plurality of O-RUs supports; The method of claim 1 , wherein the slotId setting capability information includes information indicating whether each of the plurality of O-RUs can change a slotId.

3. The step of generating slotId setting information based on the received SCS capability information and slotId setting capability information includes: Identifying whether slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; 2. The method of claim 1, further comprising: when the slotId setting capability information of the at least one O-RU includes information indicating that the slotId can be changed, generating the slotId setting information based on the SCS capability information of the O-RU, the slotId setting capability information including information indicating that the slotId cannot be changed.

4. The step of generating slotId setting information based on the received SCS capability information and slotId setting capability information includes: Identifying whether slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; and generating slotId setting information for the at least one O-RU based on communication quality of the controller.

5. In a controller in a communication system, A transmitter / receiver; Memory and at least one processor electrically coupled to the transceiver and the memory; The at least one processor: receiving sub-carrier spacing (SCS) capability information from each of a plurality of O-RUs; receiving slot identifier (slotId) setting capability information from each of the plurality of O-RUs; Generate slotId setting information based on the received SCS capability information and slotId setting capability information; a controller configured to transmit the generated slotId setting information to an O-DU and the plurality of O-RUs;

6. The SCS capability information includes information indicating what SCS each of the plurality of O-RUs supports; The controller according to claim 5 , wherein the slotId setting capability information includes information indicating whether each of the plurality of O-RUs can change a slotId.

7. The at least one processor: Identifying whether slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; The controller of claim 5, configured to generate the slotId setting information based on the SCS capability information of the O-RU, where the slotId setting capability information includes information indicating that the slotId cannot be changed, when the slotId setting capability information of the at least one O-RU includes information indicating that the slotId can be changed.

8. The at least one processor: Identifying whether slotId setting capability information of at least one O-RU among the plurality of O-RUs includes information indicating that the slotId can be changed; The controller of claim 5 , configured to generate slotId setting information for the at least one O-RU based on a communication quality of the controller.

Images