Electronic device and method for dynamic SINR reporting in fronthaul interface

Abstract

According to embodiments, a method performed by a distributed unit (DU) may involve: transmitting, to a radio unit (RU), a first control plane message including section extension information for indicating the number of one or more signal-to-interference-plus-noise-ratio (SINR) values for each physical resource block (PRB) corresponding to a frequency resolution of an SINR report by the RU; and receiving, from the RU, a second control plane message including section type information for indicating the one or more SINR values according to the frequency resolution and the number of the one or more SINR values for each PRB.

Description

Electronic device and method for dynamic sienral reporting in a fronthaul interface

[0001] The present disclosure relates to a fronthaul interface. More specifically, the present disclosure relates to an electronic device and method for dynamic signal-to-noise ratio (SINR) reporting in a fronthaul interface.

[0002] As transmission capacity increases in wireless communication systems, functional splitting, which functionally separates base stations, is being implemented. Through functional splitting, base stations can be divided into distributed units (DUs) and radio units (RUs). A fronthaul interface is defined for communication between DUs and RUs.

[0003] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art related to the present disclosure.

[0004] According to embodiments, a method performed by a distributed unit (DU) is provided. The method may include transmitting to a radio unit (RU) a first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report. The method may include receiving from the RU a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB.

[0005] In embodiments, a distributed unit (DU) is provided. The DU may include communication circuitry. The DU may include a memory storing instructions and including one or more storage media. The DU may include at least one processor including processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may cause the DU to transmit a first control plane message to a radio unit (RU), the first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report by the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the DU to receive from the RU a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of the one or more SINR values ​​per PRB.

[0006] In embodiments, a method performed by a radio unit (RU) is provided. The method may include receiving, from a distributed unit (DU), a first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report by the RU. The method may include transmitting, to the DU, a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB.

[0007] In embodiments, a radio unit (RU) is provided. The RU may include communication circuitry. The RU may include a memory storing instructions and including one or more storage media. The RU may include at least one processor including processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to receive, from a distributed unit (DU), a first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report by the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the RU to transmit a second control plane message to the DU, the second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of the one or more SINR values ​​per PRB.

[0008] Figure 1 illustrates a wireless communication system.

[0009] Figure 2a illustrates a fronthaul interface.

[0010] Figure 2b illustrates the fronthaul interface of an O(open)-RAN(radio access network).

[0011] Figure 3a illustrates the functional configuration of a distributed unit (DU).

[0012] Figure 3b illustrates the functional configuration of a RU (radio unit).

[0013] Figure 4 shows examples of channels in a communication standard.

[0014] Figure 5 illustrates an example of function split between DU and RU.

[0015] Figure 6 shows an example of a resource structure in the time domain and frequency domain.

[0016] Figures 7a and 7b illustrate functional blocks in each of the DU and RU for beamforming based on demodulation reference signal (DMRS) using equalization.

[0017] Figure 8 shows the signal flow of DU and RU for dynamic SINR (signal-to-noise ratio) reporting.

[0018] Figure 9 shows the signal flow of DU and RU for reporting the capability of RU.

[0019] Figure 10 shows an example of dynamic SINR reporting.

[0020] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0021] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0022] Terms used in the following description to refer to signals (e.g., signal, information, message, signaling), to refer to data types (e.g., list, set, subset), to refer to operational states (e.g., step, operation, procedure), to refer to data (e.g., packet, user stream, information, bit, symbol, codeword), to refer to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), to refer to channels, to refer to network entities (distributed unit (DU), radio unit (RU), central unit (CU), control plane (CU-CP), user plane (CU-UP), open radio access network (O-RAN) DU), Terms such as O-RU (O-RAN RU), O-CU (O-RAN CU), O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP)), referring to components of the device, are examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0023] In the following description, terms referring to signals (e.g., signal, information, message, signaling), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), occasion), terms for operational states (e.g., step, operation, procedure), terms referring to data (e.g., packet, user stream, information, bit, symbol, codeword), terms referring to channels, terms referring to network entities, terms referring to components of devices, etc. are examples for convenience of description. Therefore, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used. In addition, the terms '...bu', '...gi', '...mul', '...che', etc. used below may mean at least one shape structure or a unit that processes a function.

[0024] In addition, in the present disclosure, expressions such as "more than" or "less than" may be used to determine whether a specific condition is satisfied or fulfilled, but this is merely a description for expressing an example and does not exclude descriptions such as "more than" or "less than." A condition described as "more than" may be replaced with "more than," a condition described as "less than" may be replaced with "less than," and a condition described as "more than and less than" may be replaced with "more than and less than." In addition, hereinafter, "A" to "B" mean at least one of elements from A (including A) to B (including B). hereinafter, "C" and / or "D" mean at least one of "C" or "D," that is, including {"C", "D", "C" and "D"}.

[0025] Although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI), extensible radio access network (xRAN), open-radio access network (O-RAN), etc.), these are merely examples for explanation. The various embodiments of the present disclosure can be easily modified and applied to other communication systems.

[0026] Figure 1 illustrates a wireless communication system.

[0027] Referring to FIG. 1, FIG. 1 illustrates a base station (110) and a terminal (120) as some of the nodes utilizing a wireless channel in a wireless communication system. Although FIG. 1 illustrates only one base station, the wireless communication system may further include other base stations identical or similar to the base station (110).

[0028] The base station (110) is a network infrastructure that provides wireless access to the terminal (120). The base station (110) has coverage defined based on the distance at which a signal can be transmitted. In addition to the base station, the base station (110) may be referred to as an 'access point (AP)', 'eNodeB (eNB)', '5th generation node', 'next generation nodeB (gNB)', 'wireless point', 'transmission / reception point (TRP)', or other terms having equivalent technical meanings.

[0029] The terminal (120) is a device used by a user and communicates with the base station (110) via a wireless channel. The link from the base station (110) to the terminal (120) is referred to as a downlink (DL), and the link from the terminal (120) to the base station (110) is referred to as an uplink (UL). In addition, although not shown in FIG. 1, the terminal (120) and another terminal may communicate with each other via a wireless channel. In this case, the link between the terminal (120) and another terminal (device-to-device link, D2D) is referred to as a sidelink, and the sidelink may be used interchangeably with the PC5 interface. In some other embodiments, the terminal (120) may be operated without the involvement of a user. In one embodiment, the terminal (120) is a device that performs machine type communication (MTC) and may not be carried by the user. Additionally, according to one embodiment, the terminal (120) may be an MTC UE or an NB (narrowband)-IoT (internet of things) device.

[0030] The terminal (120) may be referred to as a terminal, or other terms such as 'user equipment (UE),' 'customer premises equipment (CPE),' 'mobile station,' 'subscriber station,' 'remote terminal,' 'wireless terminal,' 'electronic device,' or 'user device,' or other terms having equivalent technical meanings.

[0031] The base station (110) and the terminal (120) can perform beamforming. The base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively low frequency band (e.g., FR 1 (frequency range 1) of NR). In addition, the base station (110) and the terminal (120) can transmit and receive wireless signals in a relatively high frequency band (e.g., FR 2 (or, FR 2-1, FR 2-2, FR 2-3), FR 3 of NR), millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). To improve channel gain, the base station (110) and the terminal (120) can perform beamforming. Here, the beamforming can include transmission beamforming and reception beamforming. The base station (110) and the terminal (120) can impart directionality to the transmitted or received signal. To this end, the base station (110) and the terminal (120) can select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication can be performed through resources that have a QCL relationship with the resource that transmitted the serving beams.

[0032] If large-scale characteristics of a channel carrying a symbol on a first antenna port can be inferred from a channel carrying a symbol on a second antenna port, the first antenna port and the second antenna port can be evaluated to have a QCL relationship. For example, the large-scale characteristics may include at least one of delay spread, Doppler spread, Doppler shift, average gain, average delay, and a spatial receiver parameter.

[0033] Although both the base station (110) and the terminal (120) are described as performing beamforming in FIG. 1, the embodiments of the present disclosure are not necessarily limited thereto. In some embodiments, the terminal may or may not perform beamforming. Furthermore, the base station may or may not perform beamforming. That is, either only one of the base station and the terminal may perform beamforming, or neither the base station nor the terminal may perform beamforming.

[0034] In the present disclosure, a beam refers to a spatial flow of a signal in a wireless channel, and is formed by one or more antennas (or antenna elements), and this forming process may be referred to as beamforming. Beamforming may include at least one of analog beamforming and digital beamforming (e.g., precoding). Reference signals transmitted based on beamforming may include, for example, a demodulation-reference signal (DM-RS), a channel state information-reference signal (CSI-RS), a synchronization signal / physical broadcast channel (SS / PBCH), and a sounding reference signal (SRS). In addition, as a configuration for each reference signal, an IE such as a CSI-RS resource or an SRS-resource may be used, and this configuration may include information associated with the beam. Information associated with a beam may mean whether the configuration (e.g., a CSI-RS resource) uses the same spatial domain filter as another configuration (e.g., another CSI-RS resource within the same CSI-RS resource set) or a different spatial domain filter, or whether it is quasi-co-located (QCL) with a reference signal, and if so, what type it is (e.g., QCL type A, B, C, D).

[0035] In FIG. 1, a base station (110) and a terminal (120) are exemplified, but the base station (110) can be implemented not only through one entity but also through multiple entities. In the past, in communication systems with relatively large cell radius of base stations, each base station (e.g., base station (110)) was installed such that each base station included the functions of a digital processing unit (or distributed unit (DU)) and a radio frequency (RF) processing unit (or radio unit (RU)). However, as high frequency bands are used in 4G (4th generation) and / or subsequent communication systems (e.g., 5G) and the cell coverage of base stations becomes smaller, the number of base stations to cover a specific area has increased. The burden of installation costs on operators for installing base stations has also increased. In order to minimize the installation cost of base stations, 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 through a wired network, and one or more RUs are geographically distributed to cover a specific area. Hereinafter, deployment structures and expansion examples of base stations according to various embodiments of the present disclosure are described through FIGS. 2A and 2B.

[0036] Figure 2a illustrates a fronthaul interface.

[0037] Figure 2a illustrates an interface between an upper network node and a lower network node. The upper network node and the lower network node may be utilized to separate the functions handled by a base station (e.g., base station (110)) between a wireless access network and a core network. For example, the upper network node may represent a network node responsible for functions closer to the core network among the functions between the wireless access network and the core network, and the lower network node may represent a network node responsible for functions closer to the access network among the functions. The interface between the upper network node and the lower network node may include a fronthaul interface. Unlike the backhaul between the base station and the core network, fronthaul refers to the entity between the wireless LAN and the base station. While Figure 2a illustrates an example of a fronthaul structure between an upper network node (210) and one lower network node (220), this is merely for convenience of explanation and the present disclosure is not limited thereto. In other words, embodiments of the present disclosure may also be applied to a fronthaul structure between one upper network node and multiple lower network nodes. For example, embodiments of the present disclosure may be applied to a fronthaul structure between one upper network node and two lower network nodes. Furthermore, embodiments of the present disclosure may also be applied to a fronthaul structure between one upper network node and three lower network nodes. For example, the upper network node may include a digital unit / distributed unit (DU). The upper network node may be referred to as a DU. The lower network node may include a radio unit (RU) or a massive MIMO unit (MMU). The lower network node may be referred to as a RU or an MMU.

[0038] Referring to FIG. 2A, a base station (110) may include an upper network node (210) and a lower network node (220). A fronthaul (215) between the upper network node (210) and the lower network node (220) may be operated via an Fx interface. For operation of the fronthaul (215), an interface such as an enhanced common public radio interface (eCPRI) or radio over ethernet (ROE) may be used, for example.

[0039] As communication technology develops, mobile data traffic increases, and accordingly, the bandwidth demand required in the fronthaul between the digital unit and the wireless unit has increased significantly. In a deployment such as a centralized / cloud radio access network (C-RAN), an upper network node (210) performs functions for packet data convergence protocol (PDCP), radio link control (RLC), media access control (MAC), and physical (PHY), and a lower network node (220) may be implemented to perform functions for the PHY layer in addition to the RF (radio frequency) function.

[0040] The upper network node (210) may be responsible for upper layer functions of a wireless network. For example, the upper network node (210) may perform functions of the MAC layer and a part of the PHY layer. Here, a part of the PHY layer refers to functions performed at a higher level among the functions of the PHY layer, and may include, for example, channel encoding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). According to an embodiment, when the upper network node (210) complies with the O-RAN standard, it may be referred to as an O-DU (O-RAN DU) (or DU). The upper network node (210) may be replaced with a first network entity or DU for a base station (e.g., gNB) in embodiments of the present disclosure, as needed.

[0041] The lower network node (220) may be responsible for lower layer functions of the wireless network. For example, the lower network node (220) may perform a part of the PHY layer, an RF function. Here, a part of the PHY layer refers to functions of the PHY layer that are performed at a relatively lower level than the upper network node (210), and may include, for example, iFFT transformation (or FFT transformation), CP (cyclic prefix) insertion (CP removal), and digital beamforming. An example of such specific functional separation is described in detail in FIG. 4. The lower network node (220) may be referred to as an 'access unit (AU)', an 'access point (AP)', a 'transmission / reception point (TRP)', a 'remote radio head (RRH)', a 'radio unit (RU)', or other terms having an equivalent technical meaning thereto. In one embodiment, if a lower network node (220) complies with the O-RAN standard, it may be referred to as an O-RU (O-RAN RU) (or RU). The lower network node (220) may be replaced with a second network entity or RU for a base station (e.g., gNB) in embodiments of the present disclosure, as needed.

[0042] Although the above example describes that the upper network node (210) includes a DU and the lower network node (220) includes an RU, the embodiments of the present disclosure are not limited thereto. A base station according to the embodiments may be implemented in a distributed deployment according to a centralized unit (CU) configured to perform functions of upper layers of an access network (e.g., packet data convergence protocol (PDCP), radio resource control (RRC)) and a distributed unit (DU) configured to perform functions of lower layers. At this time, the distributed unit (DU) may include a digital unit (DU) and a radio unit (RU). Between a core (e.g., 5GC (5G core) or NGC (next generation core)) network and a radio network (RAN), the base station may be implemented in a structure in which CU, DU, and RU are arranged in that order. The interface between the CU and the distributed unit (DU) may be referred to as an F1 interface.

[0043] For example, a centralized unit (CU) may be connected to one or more DUs and may be responsible for functions at a higher layer than the DU. For example, the CU may be responsible for functions at the RRC (radio resource control) and PDCP (packet data convergence protocol) layers, while the DU and RU may be responsible for functions at lower layers. The DU may perform some functions (high PHY) of the RLC (radio link control), MAC (media access control), and PHY (physical) layers, and the RU may be responsible for the remaining functions (low PHY) of the PHY layer. In addition, for example, a digital unit (DU) may be included in a distributed unit (DU) depending on the implementation of a distributed deployment of a base station. Hereinafter, unless otherwise defined, the operations of DU and RU are described, but various embodiments of the present disclosure can be applied to both a base station deployment including a CU and a deployment in which the DU is directly connected to the core network (i.e., a base station in which the CU and DU are integrated into a single entity (e.g., an NG-RAN node)).

[0044] Figure 2b illustrates the fronthaul interface of an open RAN (radio access network). A base station (110) according to a distributed deployment is exemplified as an eNB or gNB.

[0045] Referring to FIG. 2B, the base station (110) may include an O-DU (251) and O-RUs (253-1, …, 253-n). Hereinafter, for convenience of explanation, the operation and function of the O-RU (253-1) may be understood as a description of each of the other O-RUs (e.g., O-RU (253-n)). For example, the upper network node (210) of FIG. 2A may correspond to the O-DU (251), and the lower network node (220) of FIG. 2A may correspond to the O-RU (253-i).

[0046] The O-DU (251) is a logical node that includes functions, excluding functions exclusively assigned to the O-RU (253-1), among the functions of a base station (e.g., eNB, gNB) according to FIG. 5 described below. The O-DU (251) can control the operation of the O-RUs (253-1, …, 253-n). The O-DU (251) may be referred to as an LLS (lower layer split) CU (central unit). The O-RU (253-1) is a logical node that includes a subset of the functions of a base station (e.g., eNB, gNB) according to FIG. 5 described below. Real-time aspects of control plane (C-plane) communication and user plane (U-plane) communication with the O-RU (253-1) can be controlled by the O-DU (251).

[0047] The O-DU (251) can communicate with the O-RU (253-1) through an LLS interface. The LLS interface corresponds to a fronthaul interface. The LLS interface refers to a logical interface between the O-DU (251) and the O-RU (253-1) that utilizes lower layer functional split (i.e., intra-PHY based functional split). The LLS-C between the O-DU (251) and the O-RU (253-1) provides the C-plane through the LLS interface. The LLS-U between the O-DU (251) and the O-RU (253-1) provides the U-plane through the LLS interface.

[0048] In FIG. 2B, to explain the O-RAN, entities of the base station (110) are described as O-DU and O-RU. However, these designations are not to be construed as limiting the embodiments of the present disclosure. In the following embodiments, it is obvious that the operations of the DU (210) can be performed by the O-DU (251). The description of the DU (210) can be applied to the O-DU (251). Similarly, in the following embodiments, it is obvious that the operations of the RU (220) can be performed by the O-RU (253-1). The description of the RU (220) can be applied to the O-DU (253-1).

[0049] Hereinafter, embodiments of the present disclosure are described based on DU as an example of an upper network node (210) and RU as an example of a lower network node (220). When following the O-RAN standard, DU (210) may correspond to O-DU (251) of FIG. 2b, and RU (220) may correspond to O-DU (253-i).

[0050] Fig. 3a illustrates the functional configuration of a distributed unit (DU) (e.g., DU (210)). The configuration illustrated in Fig. 3a can be understood as a configuration of DU (210) of Fig. 2a or O-DU (250) of Fig. 2b as part of a base station (e.g., base station (110)). Terms such as "...unit" and "...unit" used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0051] Referring to FIG. 3a, DU (210) includes a transceiver (310), memory (320), and processor (330).

[0052] The transceiver (310) may perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (310) may include a wired interface for controlling direct connection between devices via a transmission medium (e.g., copper wire, optical fiber). For example, the transceiver (310) may transmit an electrical signal to another device via copper wire, or perform conversion between an electrical signal and an optical signal. According to one embodiment, the DU (210) may communicate with a radio unit (RU) via the transceiver (310). In this respect, the transceiver (310) may be referred to as a fronthaul transceiver. As a non-limiting example, the DU (210) may be connected to a core network or a CU in a distributed arrangement via the transceiver (310).

[0053] The transceiver (310) may perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (310) may perform a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the transceiver (310) generates complex symbols by encoding and modulating the transmitted bit stream. In addition, when receiving data, the transceiver (310) restores the received bit stream by demodulating and decoding the baseband signal. In addition, the transceiver (310) may include multiple transmission and reception paths. In addition, according to one embodiment, the transceiver (310) may be connected to the core network or other nodes (e.g., an integrated access backhaul (IAB).

[0054] The transceiver (310) can transmit and receive signals. The transceiver (310) can function as a fronthaul transceiver. For example, the DU (210) can transmit or receive a management plane (M-plane) message through the transceiver (310). For example, the DU (210) can transmit or receive a management plane (S-plane) message through the transceiver (310). For example, the DU (210) can transmit or receive a control plane (C-plane) message through the transceiver (310). For example, the DU (210) can transmit or receive a user plane (U-plane) message through the transceiver (310). Although only the transceiver (310) is illustrated in FIG. 3a, according to other implementation examples, the DU (210) may include two or more transceivers.

[0055] The transceiver (310) transmits and receives signals as described above. Accordingly, all or part of the transceiver (310) may be referred to as a "communication unit," a "transmitter," a "receiver," or a "transmitter-receiver unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that the transceiver (310) performs the processing described above.

[0056] Although not illustrated in FIG. 3A, the transceiver (310) may further include a backhaul transceiver for connection to the core network or other base stations. The backhaul transceiver provides an interface for communicating with other nodes within the network. That is, the backhaul transceiver converts a bit stream transmitted from the base station to other nodes, such as other access nodes, other base stations, upper nodes, the core network, etc., into a physical signal, and converts a physical signal received from other nodes into a bit stream.

[0057] The memory (320) stores data such as basic programs, application programs, and setting information for the operation of the DU (210). The memory (320) may be referred to as a storage unit. The memory (320) may store instructions for the operations of the DU (210). The memory (320) may be composed of volatile memory, nonvolatile memory, or a combination of volatile memory and nonvolatile memory. In addition, the memory (320) provides the stored data according to the request of the processor (330).

[0058] The processor (330) controls the overall operations of the DU (210). The processor (380) may be referred to as a control unit. The processor (330) may include a control circuit and / or a processing circuit. For example, the processor (330) transmits and receives signals through the transceiver (310) (or through a backhaul communication unit). In addition, the processor (330) writes and reads data to and from the memory (320). In addition, the processor (330) may perform the functions of a protocol stack required by a communication standard. Although only the processor (330) is illustrated in FIG. 3A, the DU (210) may include two or more processors according to other implementation examples.

[0059] The configuration of DU (210) illustrated in FIG. 3A is merely an example, and examples of DUs performing embodiments of the present disclosure are not limited to the configuration illustrated in FIG. 3A. In some embodiments, some configurations may be added, deleted, or changed.

[0060] Fig. 3b illustrates the functional configuration of a radio unit (RU) (e.g., RU (220)). The configuration illustrated in Fig. 3b can be understood as a configuration of the RU (220) of Fig. 2b or the O-RU (253-1) of Fig. 2b as part of a base station (e.g., base station (110)). Terms such as "...unit", "...unit", etc. used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0061] Referring to FIG. 3b, the RU (220) includes an RF transceiver (360), a fronthaul transceiver (365), a memory (370), and a processor (380).

[0062] The RF transceiver (360) performs functions for transmitting and receiving signals via a wireless channel. For example, the RF transceiver (360) upconverts a baseband signal into an RF band signal and transmits it via an antenna, and downconverts an RF band signal received via the antenna into a baseband signal. For example, the RF transceiver (360) may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, and the like.

[0063] The RF transceiver (360) may include multiple transmission and reception paths. Furthermore, the RF transceiver (360) may include an antenna unit. The RF transceiver (360) may include at least one antenna array composed of multiple antenna elements. In terms of hardware, the RF transceiver (360) may be composed of digital circuits and analog circuits (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuits and analog circuits may be implemented in a single package. In addition, the RF transceiver (360) may include multiple RF chains. The RF transceiver (360) may perform beamforming. The RF transceiver (360) may apply beamforming weights to a signal to be transmitted and received in order to impart directionality according to the settings of the processor (380). According to one embodiment, the RF transceiver (360) may include an RF (radio frequency) block (or RF unit).

[0064] According to one embodiment, the RF transceiver (360) can transmit and receive signals on a radio access network. For example, the RF transceiver (360) can transmit a downlink signal. The downlink signal can include a synchronization signal (SS), a reference signal (RS) (e.g., a cell-specific reference signal (CRS), a demodulation (DM)-RS), system information (e.g., a MIB, a SIB, remaining system information (RMSI), other system information (OSI)), a configuration message, control information, or downlink data. In addition, for example, the RF transceiver (360) can receive an uplink signal. The uplink signal may include a random access related signal (e.g., a random access preamble (RAP) (or Msg1 (message 1)), Msg3 (message 3)), a reference signal (e.g., a sounding reference signal (SRS), DM-RS), or a power headroom report (PHR). Although only the RF transceiver (360) is illustrated in FIG. 3b, in other implementation examples, the RU (220) may include two or more RF transceivers.

[0065] The fronthaul transceiver (365) can transmit and receive signals. According to one embodiment, the fronthaul transceiver (365) can transmit and receive signals on the fronthaul interface. For example, the RU (220) can transmit or receive a management plane (M-plane) message through the fronthaul transceiver (365). For example, the RU (220) can transmit or receive a management plane (S-plane) message through the fronthaul transceiver (365). For example, the RU (220) can transmit or receive a control plane (C-plane) message through the fronthaul transceiver (365). For example, the RU (220) can transmit or receive a user plane (U-plane) message through the fronthaul transceiver (365). Although only the fronthaul transceiver (365) is shown in FIG. 3b, according to other implementation examples, the RU (220) may include two or more fronthaul transceivers.

[0066] The RF transceiver (360) and the fronthaul transceiver (365) transmit and receive signals as described above. Accordingly, all or part of the RF transceiver (360) and the fronthaul transceiver (365) may be referred to as a 'communication unit', a 'transmitter unit', a 'receiver unit', or a 'transmitter-receiver unit'. In addition, in the following description, transmission and reception performed through a wireless channel are used to mean that the processing as described above is performed by the RF transceiver (360). In the following description, transmission and reception performed through a wireless channel are used to mean that the processing as described above is performed by the RF transceiver (360).

[0067] The memory (370) stores data such as basic programs, application programs, and setting information for the operation of the RU (220). The memory (370) may be referred to as a storage unit. The memory (370) may store instructions for the operations of the RU (220). The memory (370) may be configured as volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. In addition, the memory (370) provides the stored data according to a request of the processor (380). According to one embodiment, the memory (370) may include a memory for conditions, commands, or setting values ​​related to the SRS transmission method.

[0068] The processor (380) controls the overall operations of the RU (220). The processor (380) may be referred to as a control unit. The processor (380) may include control circuits and / or processing circuits. For example, the processor (380) transmits and receives signals through the RF transceiver (360) or the fronthaul transceiver (365). In addition, the processor (380) writes and reads data to and from the memory (370). In addition, the processor (380) may perform functions of the protocol stack required by the communication standard. Although only the processor (380) is illustrated in FIG. 3B, the RU (220) may include two or more processors according to other implementation examples. The processor (380) may be a set of instructions or codes stored in the memory (370), or may be a storage space storing instructions / codes or instructions / codes that are temporarily residing in the processor (380), or may be a part of the circuitry constituting the processor (380). In addition, the processor (380) may include various modules for performing communication. The processor (380) may control the RU (220) to perform operations according to the embodiments described below.

[0069] The configuration of RU (220) illustrated in FIG. 3b is merely an example, and examples of RUs performing embodiments of the present disclosure are not limited to the configuration illustrated in FIG. 3b. In some embodiments, some configurations may be added, deleted, or changed.

[0070] Figure 4 illustrates examples of channels in a communication standard. The channels may include a physical channel (410), a transport channel (420), and a logical channel (430), depending on the layers defined in the communication standard.

[0071] Referring to FIG. 4, a physical channel (410) may provide functions (e.g., channel coding, HARQ processing, modulation, multi-antenna processing, resource mapping) necessary for generating physical signals at the physical layer. At the physical layer, physical signals are modulated using OFDM and may be transmitted in a wireless environment via time-frequency resources (e.g., resources of the resource grid of FIG. 5).

[0072] In downlink transmission, a physical channel (410) may include at least one of a physical broadcast channel (PBCH), a physical downlink shared channel (PDSCH), or a physical downlink control channel (PDCCH). The PDCCH may be used to carry downlink control information (DCI). Generally, downlink data refers to symbols transmitted through the PDSCH, and a downlink control signal may include symbols transmitted through the PDCCH. In addition, in the downlink, in addition to the channels illustrated in FIG. 4, a synchronization signal (e.g., a primary synchronization signal (PSS), a secondary synchronization signal (SSS)) and an SS / PBCH block including a broadcast signal (e.g., a PBCH)) may be transmitted for synchronization. In addition, in the downlink, a channel state information-reference signal (CSI-RS) for obtaining measurement or channel information, a demodulation reference signal (DMRS) for channel estimation and demodulation, and / or a phase tracking reference signal (PTRS) may be transmitted in the downlink.

[0073] In uplink transmission, the physical channel (410) may include at least one of a physical uplink shared channel (PUSCH), a physical uplink control channel (PUCCH), or a physical random access channel (PRACH). The PUSCH or PUCCH may be used to carry uplink control information (UCI). Generally, uplink data refers to symbols transmitted through the PUSCH, and the uplink control signal may include symbols corresponding to the UCI. For example, the UCI may include at least one of a scheduling request (SR), a hybrid automatic request (HARQ)-acknowledge (ACK) bit(s), or channel state information (CSI). In addition, in the uplink, in addition to the channels illustrated in FIG. 4, a DMRS and / or PTRS for channel estimation and demodulation may be transmitted in the downlink for channel estimation.

[0074] The transmission channel (420) connects the physical layer and the medium access channel (MAC) layer located at an upper level of the physical layer, and can be classified according to how data is transmitted through the wireless interface. In the downlink, the transmission channel (420) may include at least one of a paging channel (PCH) for paging, a broadcast channel (BCH) for broadcasting system information, or a downlink shared channel (DL-SCH) for transmitting downlink data. In the uplink, the transmission channel (420) may include at least one of a random access channel (RACH) for transmitting a random access preamble or an uplink shared channel (UL-SCH) for transmitting downlink data.

[0075] The logical channel (430) is located above the transport channel and is mapped to the transport channel (420). The logical channel (430) can be divided into a control channel for transmitting control region information and a traffic channel for transmitting user region information. The control channel of the logical channel (430) can include at least one of a paging control channel (PCCH), a broadcast control channel (BCCH), a common control channel (CCCH), or a dedicated control channel (DCCH). The traffic channel of the logical channel (430) can include a dedicated traffic channel (DTCH).

[0076] In describing embodiments of the present disclosure, "data" may include signals other than reference signals. For example, "data" obtained by a receiver in uplink communication may include signals transmitted via the PUSCH. However, the PUSCH is merely exemplary, and it is understood that embodiments of the present disclosure may also be applied to channels to which a precoder can be applied (e.g., PDSCH, PUCCH).

[0077] As wireless communication technology advances (e.g. 5G (5 thWith the introduction of 5G communication systems (or NR (new radio) communication systems), the frequency bands used have increased further. As the cell radius of the base station has become significantly smaller, the number of RUs required for installation has also increased further. Furthermore, in the 5G communication system, the amount of data transmitted has increased by a factor of up to ten, significantly increasing the transmission capacity of the wired network transmitted to the fronthaul. Due to the factors described above, the installation cost of the wired network in the 5G communication system may increase significantly. Therefore, in order to lower the transmission capacity of the wired network and reduce the installation cost of the wired network, 'function split' can be utilized, which transfers some of the functions of the modem of the DU to the RU, thereby lowering the transmission capacity of the fronthaul.

[0078] To reduce the burden on the DU, the role of the RU, which is traditionally solely responsible for RF functions, can be expanded to include some physical layer functions. As the RU performs higher-layer functions, its throughput increases, which can increase transmission bandwidth in the fronthaul while reducing latency requirements due to response processing. However, as the RU performs higher-layer functions, virtualization gains decrease, and the RU's size, weight, and cost increase. Considering the trade-offs between the advantages and disadvantages described above, implementing an optimal functional separation is required.

[0079] Fig. 5 illustrates an example of function split between a DU (e.g., DU (210)) and an RU (e.g., RU (220)). Fig. 5 illustrates function splits in the physical layer below the MAC layer. In the case of downlink (DL) that transmits a signal to a terminal (e.g., terminal (120)) through a wireless network, a base station (e.g., base station (110)) can sequentially perform channel encoding / scrambling, modulation, layer mapping, antenna mapping, RE mapping, digital beamforming (e.g., precoding), iFFT conversion / CP insertion, and RF conversion. In the case of uplink (UL) receiving a signal from a terminal (120) via a wireless access network, the base station (110) can sequentially perform RF conversion, FFT conversion / CP removal, digital beamforming (pre-combining), RE demapping, channel estimation, layer demapping, demodulation, and decoding / descrambling. The separation of uplink functions and downlink functions can be defined in various types according to the needs of vendors, discussions on standards, etc., according to the above-described trade-offs.

[0080] Referring to FIG. 5, in the first functional separation (505), the RU performs the RF function, and the DU performs the PHY function. The first functional separation is one in which the PHY function is not actually implemented in the RU, and may be referred to as Option 8, for example. In the second functional separation (510), the RU performs iFFT conversion / CP insertion in the DL of the PHY function and FFT conversion / CP removal in the UL, and the DU performs the remaining PHY functions. As an example, the second functional separation (510) may be referred to as Option 7-1. In the third functional separation (520a), the RU performs iFFT conversion / CP insertion in the DL of the PHY function, FFT conversion / CP removal in the UL, and digital beamforming, and the DU performs the remaining PHY functions. As an example, the third functional separation (520a) may be referred to as Option 7-2x Category A. In the fourth functional separation (520b), the RU performs up to digital beamforming in both the DL and UL, and the DU performs upper PHY functions after the digital beamforming. For example, the fourth functional separation (520b) may be referred to as Option 7-2x Category B. In the fifth functional separation (525), the RU performs up to RE mapping (or RE demapping) in both the DL and UL, and the DU performs upper PHY functions after RE mapping (or RE demapping). For example, the fifth functional separation (525) may be referred to as Option 7-2. In the sixth functional separation (530), the RU performs up to antenna mapping in the DL or up to channel estimation in the UL, and the DU performs upper PHY functions before antenna mapping or after channel estimation. In the 7th functional separation (540), the RU performs layer mapping (or layer de-mapping) in both the DL and UL, and the DU performs upper PHY functions after layer mapping (or layer de-mapping).In the eighth functional separation (545), the RU performs modulation (or demodulation) in both the DL and UL, and the DU performs subsequent higher PHY functions up to modulation (or demodulation). As an example, the eighth functional separation (545) may be referred to as Option 7-3. In the ninth functional separation (550), the RU performs encoding / scrambling (or decoding / descramming) in both the DL and UL, and the DU performs subsequent higher PHY functions up to modulation (or demodulation). As an example, the ninth functional separation (550) may be referred to as Option 6.

[0081] In one embodiment, when a large amount of signal processing is expected, such as in a FR 1 MMU, functional separation at a relatively high layer (e.g., the sixth functional separation (530)) may be required to reduce the fronthaul capacity. In addition, functional separation at too high a layer (e.g., the eighth functional separation (545)) may complicate the control interface and cause a burden on the implementation of the RU due to the inclusion of a large number of PHY processing blocks in the RU. Therefore, appropriate functional separation may be required depending on the arrangement and implementation of the DU and the RU. For example, when precoding of data received from the DU cannot be processed (i.e., when the precoding capability of the RU is limited), the third functional separation (520a) or a lower functional separation (e.g., the second functional separation (510)) may be applied. Conversely, when precoding of data received from the DU is capable of being processed, the fourth functional separation (520b) or a higher functional separation (e.g., the sixth functional separation (530)) may be applied. The O-RAN standard distinguishes between O-RU types based on whether the precoding function is located at the O-DU interface or the O-RU interface. An O-RU that does not perform precoding (i.e., has low complexity) may be referred to as a CAT-A O-RU. An O-RU that performs precoding may be referred to as a CAT-B O-RU.

[0082] Hereinafter, the term "upper-PHY" refers to physical layer processing performed in the DU of the fronthaul interface. For example, the upper-PHY may include FEC encoding / decoding, scrambling, and modulation / demodulation. Hereinafter, the term "lower-PHY" refers to physical layer processing performed in the RU of the fronthaul interface. For example, the lower-PHY may include FFT / iFFT, digital beamforming, and PRACH (physical random access channel) extraction and filtering. However, the above-described criteria do not exclude embodiments through other functional separations.

[0083] Figure 6 illustrates an example of a resource structure in the time and frequency domains. Figure 6 illustrates the basic structure of the time-frequency domain, which is a radio resource domain in which data or control channels are transmitted in the downlink or uplink.

[0084] Referring to Figure 6, the horizontal axis represents the time domain and the vertical axis represents the frequency domain. The minimum transmission unit in the time domain is an OFDM (orthogonal frequency division multiplexing) symbol, N symb A set of OFDM symbols (602) constitutes one slot (606). The length of a subframe is defined as 1 ms, and the length of a radio frame (614) is defined as 10 ms. The minimum transmission unit in the frequency domain may be a subcarrier.

[0085] The basic unit of resources in the time-frequency domain is a resource element (RE) (612), which can be represented by an OFDM symbol index and a subcarrier index. A resource block may include multiple resource elements. In the LTE system, a resource block (RB) (or physical resource block (PRB)) is N in the time domain.symb N consecutive OFDM symbols and frequency domain SC RB is defined as a series of consecutive subcarriers. In an NR system, a resource block (RB) (608) is defined as N in the frequency domain. SC RB can be defined as N consecutive subcarriers (610). In a wireless access network, the bandwidth constituting the resource grid is N RB DL Dog or N RB UL It may include RBs (604). N RB DL represents the number of RBs corresponding to the downlink bandwidth, and N RB UL represents the number of RBs corresponding to the uplink bandwidth. One RB (608) is N on the frequency axis. SC RB It contains 612 REs. In general, the minimum transmission unit of data is RB and the number of subcarriers is N. SC RB =12. The frequency domain may include common resource blocks (CRBs). Physical resource blocks (PRBs) may be defined in the bandwidth part (BWP) of the frequency domain. The CRB and PRB numbers may be determined based on the subcarrier spacing. The data rate may increase in proportion to the number of RBs scheduled to the terminal.

[0086] In the NR system, in the case of a frequency division duplex (FDD) system that operates the downlink and uplink by frequency division, the downlink transmission bandwidth and the uplink transmission bandwidth may be different. The channel bandwidth represents the radio frequency (RF) bandwidth corresponding to the system transmission bandwidth. [Table 1] shows part of the correspondence between the system transmission bandwidth, subcarrier spacing (SCS), and channel bandwidth defined in the NR system in a frequency band lower than x GHz (e.g., frequency range (FR) 1 (610 MHz to 7125 MHz)). And [Table 2] shows part of the correspondence between the transmission bandwidth, subcarrier spacing, and channel bandwidth defined in the NR system in a frequency band higher than y GHz (e.g., FR2 (24250 MHz - 52600 MHz) or FR2-2 (52600 MHz to 71000 MHz)). For example, an NR system with a 100 MHz channel bandwidth and a 30 kHz subcarrier spacing has a transmission bandwidth of 273 RBs. In [Table 1] and [Table 2], N / A may be a bandwidth-subcarrier combination not supported by the NR system.

[0087] Channel bandwidth [MHz] SCS 510205080100 Transmission bandwidth configuration (N RB )15kHz2552106207N / AN / A30kHz11245113321727360kHzN / A112465107135

[0088] Channel bandwidth [MHz] SCS50100200400 Transmission bandwidth configuration (N RB )60kHz66132264N / A120kHz3266132264

[0089] When a message is transmitted on the fronthaul interface between a DU (e.g., DU (210)) and an RU (e.g., RU (220)), the message may follow the specifications of eCPRI and O-RAN. The Ethernet payload of the message may include an eCPRI header, an O-RAN header, and additional fields. Hereinafter, various embodiments of the present disclosure are described using the standard terms of eCPRI or O-RAN, but other expressions having equivalent meanings to each term may be used instead in the various embodiments of the present disclosure.

[0090] The fronthaul transport protocol can use Ethernet and eCPRI, which are easy to share with networks. The Ethernet payload can include an eCPRI header and an O-RAN header. The eCPRI header can be located at the beginning of the Ethernet payload. The contents of the eCPRI header are as follows.

[0091] 1) ecpriVersion (4 bits): This parameter indicates the eCPRI protocol version.

[0092] 2) ecpriReserved (3 bits): This parameter is reserved for further use by eCPRI.

[0093] 3) ecpriConcatenation (1 bit): This parameter indicates when eCPRI concatenation is in use.

[0094] 4) ecpriMessage (1 byte): This parameter indicates the type of service carried by the message type. For example, the parameter indicates an in-phase / quadrature-phase data message, a real-time control data message, or a transmission network delay measurement message.

[0095] 5) ecpriPayload (2 bytes): This parameter indicates the byte size of the payload portion of the eCPRI message.

[0096] 6) ecpriRtcid / ecpriPcid (2 bytes): This parameter is the eAxC (extended antenna-carrier) identifier (eAxC ID) and identifies a specific data flow associated with each C-plane (ecpriRtcid) or U-plane (ecpriPcid) message.

[0097] 7) ecpriSeqid (2 bytes): This parameter provides unique message identification and ordering at both levels. The first octet of this parameter is a sequence ID used to identify the order of messages within the eAxC message stream. The sequence ID is used to ensure that all messages are received and to reorder out-of-order messages. The second octet of this parameter is a subsequence ID. The subsequence ID is used to ensure ordering and implement reordering when radio-transport-level (eCPRI or IEEE-1914.3) fragmentation occurs.

[0098] The eAxC identifier (ID) includes a band and sector identifier ('BandSector_ID'), a component carrier identifier ('CC_ID'), a spatial stream identifier ('RU_Port_ID'), and a distributed unit identifier ('DU_Port_ID'). The bit allocation of the eAxC ID can be distinguished as follows.

[0099] 1) DU_port ID: The DU_port ID is used to distinguish processing units (e.g., different baseband cards) in the O-DU. The O-DU is expected to allocate bits for the DU_port ID, and the O-RU is expected to append the same value to the UL U-plane message carrying the same sectionId data.

[0100] 2) BandSector_ID: Aggregated cell identifier (band and sector distinction supported by O-RU).

[0101] 3) CC_ID: CC_ID identifies the carrier component supported by the O-RU.

[0102] 4) RU_port ID: The RU_port ID specifies logical flows such as data layer or spatial streams, and signaling channels that require separate numerologies (e.g. PRACH) or special antenna allocation such as SRS.

[0103] The application protocol of the fronthaul may include a control plane (C-plane), a user plane (U-plane), a synchronization plane (S-plane), and a management plane (M-plane).

[0104] The control plane may be configured to provide scheduling information and beamforming information via control messages. The control plane refers to real-time control between DUs and RUs. The user plane may include IQ sample data transmitted between DUs and RUs. The user plane may include user downlink data (IQ data or SSB / RS), uplink data (IQ data or SRS / RS), or PRACH data. A weight vector of the beamforming information described above may be multiplied by the user's data. The synchronization plane generally refers to traffic between DUs and RUs for a synchronization controller (e.g., IEEE grand master). The synchronization plane may be related to timing and synchronization. The management plane refers to non-real-time control between DUs and RUs. The management plane may be related to initial setup, non-realtime reset or reset, and non-realtime report.

[0105] Control plane messages, or C-plane messages, can be encapsulated based on a two-layer header approach. The first layer can consist of the eCPRI common header or the IEEE 1914.3 common header, which contains fields used to indicate the message type. The second layer is the application layer, which contains fields necessary for control and synchronization. Within the application layer, sections define the characteristics of U-plane data transmitted or received on a beam with a single pattern ID. The following section types are supported within the C-plane:

[0106] Section Type can indicate the purpose of control messages transmitted on the control plane. For example, the purposes of each Section Type are as follows.

[0107] 1) sectionType=0: Used to indicate resource blocks or symbols not used in DL or UL.

[0108] 2) sectionType=1: Used for most DL / UL wireless channels. Here, 'most' indicates channels that do not require time or frequency offsets, such as those required for mixed numerology channels.

[0109] 3) sectionType=2: reserved for further use

[0110] 4) sectionType=3: PRACH and mixed-numerology channels. Channels that require a time or frequency offset or differ from the nominal SCS value(s).

[0111] 5) sectionType=4: reserved for further use

[0112] 6) sectionType=5: UE scheduling information. Transmits UE scheduling information so that the RU can perform real-time BF weight calculations (O-RAN optional BF method).

[0113] 7) sectionType=6: Transmits UE-specific channel information. Periodically transmits UE channel information to enable the RU to perform real-time BF weight calculations (O-RAN optional BF method).

[0114] 8) sectionType=7: Used for LAA support

[0115] 9) sectionType=8: Used for ACK / NACK feedback. To provide ACK / NACK feedback from the RU to the DU regarding section descriptions of C-plane messages.

[0116] 10) sectionType=9: Used for reporting SINR data. This is for reporting post-equalization SINR values ​​from the RU to the DU. This is applied for DMRS (demodulation reference signal)-BF (beamforming)-EQ (equalization).

[0117] Figures 7a and 7b illustrate functional blocks in a DU (e.g., DU 210) and an RU (e.g., RU 220) for beamforming based on a demodulation reference signal (DMRS) using equalization, respectively. The DMRS-based RU using equalization can calculate a UE channel estimate based on received PUSCH DMRS (DMRS for coherent demodulation of PUSCH) symbols according to beamforming (hereinafter, DMRS-BF-EQ). Thereafter, the RU can calculate a weight for beamforming through equalization based on the channel estimate and apply the weight to PUSCH data.

[0118] Referring to FIG. 7A, the RU (220) may receive uplink signals via an antenna. The uplink signals may include uplink data (e.g., PDSCH) and demodulation reference signals (e.g., DMRS). The RU (220) may perform FFT and CP removal (710). The RU (220) may perform DMRS extraction (720). The RU (220) may extract DMRS symbols from the CP-removed and FFT-performed signals. For example, DMRS REs may be extracted from a frequency-domain data flow of each receive antenna. For each antenna element of at least some of the antenna elements, at least some REs of the DMRS symbols may be extracted. The RU (220) may perform DMRS channel estimation (730). The DMRS data may be processed to calculate an effective RF channel estimate between each UE antenna port and the receive antenna of the RU (220). The RU (220) can estimate a DMRS channel based on the extracted DMRS symbols. The RU (220) can perform weight calculation (740). The RU (220) can calculate weights for beamforming with equalization based on the estimated DMRS channels. In the case of DMRS-BF-EQ, the DMRS channel estimate (e.g., the result of DMRS channel estimation (730)) can be used to calculate weights for beamforming with equalization, and the weights can be used to reduce the data dimensionality from the number of antennas to the number of UE data layers. This operation can be understood as port reduction (including equalization) of PUSCH data. The RU (220) can perform weight application (750). The RU (220) can apply the calculated weights to uplink signals.For example, RU (220) can apply the calculated weight to the signal from which DMRS symbols have been removed among the uplink signals, i.e., uplink data. RU (220) can calculate post-equalization SINR data.

[0119] The RU (220) may transmit equalized uplink data (e.g., PUSCH data) and SINR data to the DU (210). For example, as part of a DMRS-BF-EQ operation, the RU (220) may provide equalized PUSCH IQ data for each layer to the DU (210) via a U-plane message. For example, as part of a DMRS-BF-EQ operation, the RU (220) may provide SINR data to the DU (210) via a C-plane message. The RU (220) may provide SINR measurement results for each UE layer to the DU (210). The modulator of the DU (210) may use the SINR measurement results for calculating a log-likelihood ratio (LLR). The modulator of the DU (210) may be configured to process the equalized PUSCH data signal.

[0120] DU (210) can receive equalized uplink data (e.g., PUSCH data) from RU (220). DU (210) can perform layer de-mapping (760). DU (210) can perform layer de-mapping (760) on uplink data (e.g., PUSCH data) received from RU (220). DU (210) can perform demodulation / decoding (770). DU (210) can perform demodulation based on SINR data received from RU (220) and the result of layer de-mapping (760). DU (210) can decode uplink bits corresponding to the result of demodulation.

[0121] Referring to FIG. 7b, the DU (210) may include a PUSCH equalizer (780). As the PUSCH equalizer (780) is implemented in the DU (210), DMRS symbols may be beamformed and equalized in the same manner as PUSCH data. Accordingly, DMRS symbols with reduced ports may be transmitted to the DU (210) together with the equalized PUSCH data. Unlike FIG. 7a, SINR data may be acquired within the DU (210) as a result of the PUSCH equalizer (780) and provided to the modulator of the DU (210).

[0122] In Fig. 7a, a block diagram is shown for the case where the PUSCH equalizer (780) is not present in the DU (210), and in Fig. 7b, a block diagram is shown for the case where the PUSCH equalizer (780) is present in the DU (210). For example, in order for DMRS-BF-EQ to be supported without the PUSCH equalizer (780) in the DU (210), the DU (210) must be able to configure the RU (220) to transfer SINR data for each UE layer from the RU (220) to the DU (210) using a C-plane message carried via section type 9 of the O-RAN specification. The SINR data can be used for LLR calculation in the DU (210). Here, SINR represents the post-equalization SINR, which is defined as the power of the signal of interest relative to the sum of interference power and background noise. In one embodiment, the SINR data should be transmitted according to the time resolution and / or frequency resolution set via the M-plane or C-plane. As a non-limiting example, the SINR data resolution may be different from the resolution for calculating weights for beamforming through equalization.

[0123] The present disclosure relates to a device and method for dynamically configuring a resolution for a channel quality (e.g., SINR) reported from an RU to a DU. Although SINR is described as an example of a communication quality in the present disclosure, embodiments of the present disclosure are not limited thereto. For example, in addition to SINR, reference signal received power (RSRP), beam reference signal received power (BRSRP), reference signal received quality (RSRQ), received signal strength indicator (RSSI), carrier to interference and noise ratio (CINR), signal to noise ratio (SNR), error vector magnitude (EVM), bit error rate (BER), or block error rate (BLER) can be used as the channel quality reported from the RU to the DU. In addition to the examples described above, it should be understood that other terms having equivalent technical meanings or other metrics indicating channel quality can be used.

[0124] An RU may have a resolution set by a DU via an M-plane. The resolution in the frequency domain (hereinafter, frequency resolution) may be referred to as the number of SINR values ​​to be reported per PRB. For example, when SINR reporting is enabled, an RU may report SINR values ​​to a DU via a C-plane message of Section Type 9 of the O-RAN standard. The number of SINR values ​​may correspond to a 'sinr-per-PRB' configured via an M-plane message. For example, a C-plane message of Section Type 9 may be referred to as the table below.

[0125] Section Type 9: SINR data0(msb)1234567 (lsb)# of bytesOctettransport header, see clause 5.1.380datadirectionpayloadVersionfilterIndex18frameId19subframeIdslotId110slotIdsymbolId111numberOfsections112sectionType = 9113numSinrPerPrb[2:0]reserved114reserved115sectionId116sectionIdrbsymIncstartPrbu117startPrbu118numPrbu119sinrCompParam120sinrValue = 1 st SINR in the first PRB121sinrValue = 2 nd SINR in the first PRB (not always present)0 / 1var...varsinrValue = 11 th SINR in the first PRB (not always present)0 / 1varsinrValue = 12 th SINR in the first PRB (not always present)0 / 1varsinrCompParam0 / 1varsinrValue = 1 st SINR in the second PRB1varsinrValue = 2 nd SINR in the second PRB (not always present)0 / 1var...varsinrValue = 11 th SINR in the second PRB (not always present)0 / 1varsinrValue = 12 th SINR in the second PRB (not always present)0 / 1var...

[0126] The above C-plane message may include a transport header (e.g., eCPRI header or IEEE 1914.3) information. The transport header may include 'ecpriVersion', 'ecpriReserved', 'ecpriConcatenation', 'ecpriMessage', 'ecpriPayload', 'ecpriRtcid / ecpriPcid', and 'ecpriSeqid' as described above.

[0127] The above C-plane message may include common header information. The common header information may include 'dataDirection' indicating the data transmission direction of the base station (e.g., gNB), 'payloadVersion' indicating the valid payload protocol version of IEs in the application layer, and 'filterindex' indicating the index of the channel filter between IQ data and the air interface to be used in both DL and UL. The common header information may include information for indicating the location of time resources applicable to the message. The location of the time resource may be indicated by a frame, subframe, slot, or symbol. The common header information may include 'frameId' indicating the frame number, 'subframeId' indicating the subframe number, 'slotId' indicating the slot number, and 'startSymbolId' indicating the symbol number. The frame is determined based on a 256 modulo operation. The subframe has a unit of 1ms included in a 10ms frame. Slot numbers are numbered within a subframe, and the maximum size can be 1, 2, 4, 8, or 16 depending on the numerology. The common header information may include 'numberOfsections' indicating the number of data sections included in the C-plane message. The common header information may include 'sectionType' indicating the type of the C-plane message. The common header information may include 'numSinrPerPrb' indicating the frequency resolution for SINR in the C-plane message. 'numSinrPerPrb' may indicate the number of SINR values ​​per PRB.

[0128] A C-plane message may contain section information. The section information may include 'sectionId', which means a section identifier. When C-Plane and U-Plane coupling via 'sectionId' is used, 'sectionId' identifies an individual data section described by a data section description within a C-Plane message. The purpose of 'sectionId' is to map a U-Plane data section to the corresponding C-Plane message (and section type) associated with the data. The section information may include 'rb', which indicates whether all RBs are used or every other RB is used, 'symInc', which indicates a symbol number increment command, 'startPrbu', which indicates the starting PRB number of the data section description, and 'numPrbu', which indicates the number of consecutive PRBs per data section description. The section information of the above C-plane message includes 'startPrbu' and 'numPrbu' so that the C-plane and U-plane coupling method can be applied, but the values ​​of these parameters do not indicate that they are the same as the values ​​of the U-plane message.

[0129] A C-plane message may include SINR information. The SINR information may be structured on a PRB basis. For example, the SINR information may include 'sinrComParam', a compression parameter of user data, and 'sinrValue', an SINR value. On a PRB basis, the SINR information may include SINR values ​​for each RE in a subset of 12 REs.

[0130] For example, the M-plane for configuring the number of SINR values ​​can be referenced in the table below.

[0131] +--rw low-level-rx-endpoints* [name]| +--rw name...| +--rw sinr-reporting-enabled? boolean| +--rw sinr-reporting-configuration| +--rw sinr-resolution| | +--rw sinr-per-prb? uint8| | +--rw sinr-slot-bitmask? uint16

[0132] The M-plane message in [Table 4] can be transmitted from the DU to the RU. 'sinr-reporting-enabled' of the M-plane message can indicate whether SINR reporting of the RU is enabled. For SINR reporting, 'sinr-reporting-enabled' can indicate to the RU that SINR reporting is enabled. 'sinr-reporting-configuration' of the M-plane message can indicate the SINR reporting configuration of the RU. It can indicate whether SINR reporting of the RU is enabled. For example, 'sinr-per-prb' can indicate the number of SINRs per PRB as a frequency resolution. For example, 'sinr-slot-bitmask' can indicate the symbol pattern on which SINR reporting will be performed per slot (e.g., a bitmap indicating the SINRs to be reported among the 14 symbols of a slot).

[0133] Based on the C-plane message and M-plane message described above, the RU can report the SINR to the DU. The DU can use the SINR values ​​of the SINR report for demodulation. Meanwhile, the RU may have different capabilities for SINR reporting depending on the layer. Based on the RU capabilities and fronthaul bandwidth limitations, the DU can configure the frequency resolution (e.g., the number of SINR values ​​to be reported per PRB) to the RU through the M-plane.

[0134] If the DU configures the 'number of SINR values ​​to be reported per PRB' to the RU, there is a burden of having to transmit the M-plane message again whenever the 'number of SINR values ​​to be reported per PRB' changes. In the present disclosure, a technique for dynamically configuring the 'number of SINR values ​​to be reported per PRB' to the RU is described in order to more instantaneously reflect variable channel conditions and the capabilities of the RU. The DU can dynamically configure the frequency resolution (e.g., the number of SINR values ​​to be reported per PRB) to the RU based on the C-plane message. Hereinafter, signal flows between the DU and the RU for dynamically configuring the frequency resolution (e.g., the number of SINR values ​​to be reported per PRB) for dynamic SINR reporting are described through FIG. 8.

[0135] Figure 8 shows the signal flow of a DU (e.g., DU (210)) and an RU (e.g., RU (220)) for dynamic SINR reporting.

[0136] Referring to FIG. 8, in operation (801), DU (210) may transmit an M-plane message to RU (220). The M-plane message may be used to configure dynamic SINR reporting to RU (220). According to an embodiment, the M-plane message may include information (e.g., boolean type) to indicate that dynamic SINR reporting is possible. According to an embodiment, the M-plane message may include a dynamic SINR reporting configuration. For example, the dynamic SINR reporting configuration may include possible frequency resolution values ​​(e.g., values ​​of the number of SINR values ​​to be reported per PRB). For example, the dynamic SINR reporting configuration may include possible frequency resolution values ​​and numbers of scheduling layers. As an example, for the M-plane message, the following table may be referred to.

[0137] +--rw low-level-rx-endpoints* [name]| +--rw name...| +--rw sinr-reporting-enabled? boolean| +--rw sinr-reporting-configuration| +--rw sinr-resolution| | +--rw sinr-per-prb? uint8| | +--rw sinr-slot-bitmask? uint16...| +--rw dynamic sinr-per-prb enabled?| +--rw dynamic sinr-reporting-configuration| +--rw sinr-resolution*| | +--rw sinr-per-prb?| | +--rw num-scheduled-layer?

[0138] In operation (803), DU (210) may transmit a C-plane message to RU (220). The C-plane message may be used to indicate the frequency resolution of SINR report. The C-plane message may include information for configuring the frequency resolution of SINR report to RU. The C-plane message may include section information and one or more section extension information. The C-plane message may include section extension information for configuring the frequency resolution of SINR report to RU. RU (220) may receive uplink signals (e.g., PUSCH data and DMRSs) from a terminal (e.g., terminal (120)). Terminal (120) may transmit the uplink signals through one or more layers, and RU (220) may transmit the PUSCH data to DU (210) in units of each layer (or in units of eAxC). To demodulate the above PUSCH data, the SINR values ​​of the SINR report can be used. For each layer, the SINR values ​​to be reported can be determined through channel estimation and weight calculation for the DMRSs transmitted with the PUSCH data.

[0139] In one embodiment, the DU (210) may provide the RU (220) with a common frequency resolution (e.g., the number of SINR values ​​per PRB) for all layers scheduled for the PUSCH, or may provide individual frequency resolutions (e.g., the number of SINR values ​​per PRB) for each layer, through the section extension information. For example, the table below may be referred to for the section extension information.

[0140] Extension Type X: dynamic SINR reporting0(msb)1234567 (lsb)# of bytesefextType =

[0141] 'ef' can indicate the presence or absence of a section extension. For example, if 'ef' is 1, it indicates the presence of a section extension field (section extension information), and if 'ef' is 0, it can indicate the absence of a section extension field. 'extType' indicates the type of the section extension field, and 'extLen' indicates the length in bytes within the extension field. 'type' indicates the indication type within the section extension field. For example, if 'type=00b', it indicates that a frequency resolution value to be commonly applied to all layers is provided through the section extension field. 'numLayer' indicates the number of layers. The layers can indicate layers scheduled for PUSCH data (data layers to be demodulated). 'numSinrPerPrb' can indicate the number of SINR values ​​to be reported per PRB in each layer. In [Table 6], 'numSinrPerPrb' can be commonly set to all layers. For example, if the above layers include a first layer and a second layer, 'numSinrPerPrb' set in the first layer and 'numSinrPerPrb' set in the second layer may have the same value. If 'type=01b', it indicates that a frequency resolution value to be applied individually to each layer is provided through a section extension field. If 'type=01b', the table below may be referenced as the section extension information.

[0142] Extension Type X: dynamic SINR reporting0(msb)1234567 (lsb)# of bytesefextType = for 3th layernumSinrPerPrb[3:0] for 4th layer1N+4...

[0143] 'ef' can indicate the presence or absence of a section extension. For example, if 'ef' is 1, it indicates the presence of a section extension field (section extension information), and if 'ef' is 0, it indicates the absence of a section extension field. 'extType' indicates the type of the section extension field, and 'extLen' indicates the length in bytes within the extension field. 'numLayer' indicates the number of layers for PUSCH. 'numSinrPerPrb[3:0] for i-th layer' can indicate the frequency resolution (e.g., the number of SINR values ​​per PRB) for the i-th layer in the SINR report.

[0144] For multiple layers, the DU (210) can transmit a common frequency resolution (e.g., the number of SINR values ​​per PRB) or a frequency resolution for each layer (e.g., the number of SINR values ​​per PRB). Referring to [Table 6] and [Table 7], it can be determined through an indicator such as 'type' whether to set the frequency resolution for SINR reporting (e.g., the number of SINR values ​​per PRB) individually for each layer within a specified format or to set the frequency resolution for SINR reporting (e.g., the number of SINR values ​​per PRB) commonly for the layers. Alternatively, only the method of transmitting the frequency resolution individually for each layer may be used. In one embodiment, the section extension information for configuring the frequency resolution of the SINR report to the RU can be used to configure the frequency resolution for SINR reporting (e.g., the number of SINR values ​​per PRB) individually for each layer to the RU (220) without the indicator. For example, the table below can be referred to for the section extension information.

[0145] Extension Type X: dynamic SINR reporting0 (msb)1234567 (lsb)# of bytesefextType = layernumSinrPerPrb[3:0] for 4th layer1N+4...

[0146] 'ef' can indicate the presence or absence of a section extension. For example, if 'ef' is 1, it indicates the presence of a section extension field (section extension information), and if 'ef' is 0, it indicates the absence of a section extension field. 'extType' indicates the type of the section extension field, and 'extLen' indicates the length in bytes within the extension field. 'numSinrPerPrb[3:0] for i-th layer' can indicate the frequency resolution (e.g., the number of SINR values ​​per PRB) for the i-th layer in the SINR report.

[0147] The one or more section extension information may include a specified type of section extension information following the O-RAN standard. The frequency resolution for SINR reporting assumes DMRS-based beamforming of PUSCH data. As a non-limiting example, the section extension information for configuring the frequency resolution for SINR reporting to the RU (220) may be transmitted together with the section extension information for PUSCH DMRS configuration. For example, the one or more section extension information may include section extension 24 of the O-RAN standard. The section extension 24 may be used for PUSCH DMRS configuration. For example, the section extension 24 may be referred to in the table below.

[0148] 0 (msb)1234567 (lsb)# of bytesOctetefextType = 0x1810extLen = 711aIpnPerSymantDmrsSnrreserveduserGroupSize[4:0] = 012userGroupId[7:0] = 013entryType[2:0] = 2dmrsPortNumber[4:0]14ueIdResetreserveddmrsSymbolMask[13:8]15dmrsSymbolMask[7:0]16scrambling[15:8]17scrambling[7:0]18nsciddTypecdmWithoutData[1:0]lambda[1:0]firstPrb[8:7]19firstPrb[6:0]lastPrb[8]110lastPrb[7:0]111reserved112reserved113entryType[2:0] = 0dmrsPortNumber[4:0]114entryType[2:0] = 1dmrsPortNumber[4:0]115entryType[2:0] = 1dmrsPortNumber[4:0]116entryType[2:0] = 0dmrsPortNumber[4:0]117entryType[2:0] = 3dmrsPortNumber[4:0]118ueIdResetreserveddmrsSymbolMask[13:8]119dmrsSymbolMask[7:0]120scrambling[15:8]121scrambling[7:0]122nscidreservedlowPaprType[1:0]hoppingMode[1:0]firstPrb[8:7]123firstPrb[6:0]lastPrb[8]124lastPrb[7:0]125reserved126reserved127entryType[2:0] = 0dmrsPortNumber[4:0]128entryType[2:0] = 0dmrsPortNumber[4:0]129zero padding to ensure 4-byte boundaryvar

[0149] The above section extension 24 can be used together with section type 5 to convey the PUSCH DMRS configuration used in the DMRS-BF-EQ and DMRS-BF-NEQ beamforming methods. 'ef' can indicate the presence or absence of a section extension. For example, if 'ef' is 1, it indicates the presence of a section extension field (section extension information), and if 'ef' is 0, it can indicate the absence of a section extension field. 'extType' indicates the type of the section extension field, and 'extLen' indicates the length in bytes within the extension field. 'aIpnPerSym' indicates the allocated IPN measurement per symbol. 'antDmrsSnr' indicates the DMRS SNR per antenna in RRM (radio resource management) measurement. 'userGroupSize' indicates the number of UE data layers within the user group identified by the value of 'userGroupId'. 'userGroupId' indicates a user group in the section.

[0150] 'entryType' indicates the format of the entry in the table of DMRS configurations. 'dmrsPortNumber' is provided for each entry in the table of DMRS configurations and indicates the DMRS antenna port number for the ueId associated with the entry (e.g., indicating a user in a user group for MU-MIMO). 'ueIdReset' indicates whether the ueId value for which the configuration is provided is associated with the same UE as the one associated with the previous slot. 'dmrsSymbolMask' indicates the symbols containing the DMRSs for the UE data layer within the slot. 'scrambling' is used to compute the seed value required to initialize the pseudo-random number generator for the DMRS binary sequence applicable to the given DMRS antenna port. 'nscid' is used to compute the seed value of the pseudo-random number generator for the DMRS binary sequence applicable to the given DMRS antenna port. 'dType' indicates the type of PUSCH DMRS configuration as defined in 3GPP technical specification (TS) 38.211. 'cdmWithoutData' represents the number of data-less DMRS CDM (ode division multiplexing) groups defined in 3GPP technical specification (TS) 38.211. 'lambda' represents , and is a value defined in 3GPP TS (technical specification) 38.211. 'lowPaprType' indicates the type of low-PAPR sequence generator when transform precoding (e.g., precoding for discrete fourier transform (DFT)-S (spreading) OFDM) is enabled. 'hoppingMode' controls the hopping mode used for DMRS sequence generation when transform precoding (e.g., precoding for discrete fourier transform (DFT)-S (spreading) OFDM) is enabled. 'firstPrb' provides information about PRB allocation of UE data layer(s). 'lastPrb' provides information about PRB allocation of UE data layer(s).

[0151] In operation (805), the RU (220) may transmit a C-plane message to the DU (210). The RU (220) may perform SINR reporting according to parameters configured based on the M-plane message of operation (801) and / or the C-plane messages of operation (803). Once SINR reporting is configured, the RU (220) may report SINR values ​​to the DU (210) for all layers, PRBs, and slots for which DMRS-BF-EQ reception is requested. At this time, the RU (220) may report the measured SINR values ​​to the DU (210) according to the time resolution and frequency resolution configured from the DU (210). The RU (220) may transmit the SINR values ​​to the DU (21) through the C-plane message of [Table 3] using a layer-specific eAxC. SINR data transmitted via C-plane messages can be used together with equalized IQ data in demodulation and decoding. The SINR data can share many properties with the U-plane IQ data.

[0152] In Fig. 8, a C-plane message for dynamic SINR reporting transmitted from a DU (210) to a RU (220) is described. As a non-limiting example, the DU (210) may transmit the C-plane message to the RU (220) if the parameters meet the specified criteria. In other words, the DU (210) may transmit a C-plane message including section extension information for configuring the frequency resolution of the SINR report to the RU (220) if the parameters meet the specified criteria.

[0153] For example, if the number of layers satisfies a specified criterion, DU (210) can transmit a C-plane message including section extension information for configuring the frequency resolution of SINR reporting to RU (220). For example, since the number of SINR values ​​(to be reported) per PRB is a value configured for each layer, if the number of layers for PUSCH decreases, the total number of SINR values ​​for PUSCH data may decrease. Accordingly, if the number of layers decreases or the level corresponding to the number of layers decreases, DU (210) can increase the frequency resolution of SINR reporting. DU (210) can set the number of SINR values ​​to be reported per PRB to be larger than before. If the number of layers increases or the level corresponding to the number of layers increases, DU (210) can lower the frequency resolution of SINR reporting. DU (210) can set the number of SINR values ​​to be reported per PRB to be smaller than before.

[0154] For example, if the bandwidth satisfies a specified criterion, the DU (210) can transmit a C-plane message including section extension information for configuring the frequency resolution of the SINR report to the RU (220). If the fronthaul bandwidth (or the entire fronthaul capacity) between the DU (210) and the RU (220) narrows or the level corresponding to the fronthaul bandwidth decreases, the DU (210) can decrease the frequency resolution of the SINR report. The DU (210) can set the number of SINR values ​​to be reported per PRB to be smaller than before. If the fronthaul bandwidth increases or the level corresponding to the fronthaul bandwidth increases, the DU (210) can increase the frequency resolution of the SINR report. The DU (210) can set the number of SINR values ​​to be reported per PRB to be larger than before.

[0155] For example, if the modulation and coding scheme (MCS) satisfies a specified criterion, the DU (210) may transmit a C-plane message containing section extension information for configuring the frequency resolution of the SINR report to the RU (220). For example, the required frequency resolution may vary depending on the MCS level. Accordingly, the DU (210) may dynamically change the number of SINR values ​​to be reported per PRB depending on the varying MCS level.

[0156] In Fig. 8, an example of configuring the frequency resolution for SINR reporting (e.g., the number of SINR values ​​per PRB) through a C-plane message is described. If a C-plane message for dynamically configuring the frequency resolution for SINR reporting is not transmitted, the RU (220) can use the 'number of SINR values ​​per PRB' value configured according to the M-plane message from the DU (210) (e.g., the M-plane message of [Table 4] or the M-plane message of [Table 5]) for SINR reporting.

[0157] Figure 9 shows the signal flow of a DU (e.g., DU (210)) and an RU (e.g., RU (220)) for reporting the capability of the RU.

[0158] Referring to FIG. 9, in operation (901), the RU (220) may transmit an M-plane message to the DU (210). The M-plane message may transmit capability information (hereinafter, O-RU capability) of the RU (220) as an O-RU. According to an embodiment, the M-plane message may include information indicating that the RU (220) supports dynamic SINR reporting described through FIG. 8. According to an embodiment, the M-plane message may include information indicating that the RU (220) supports section extension for configuring frequency resolution for SINR reporting (e.g., the number of SINR values ​​to be reported per PRB). For example, the following table may be referred to for the M-plane message.

[0159] +--ro endpoint-types* [id]| +--ro id uint16...| +--ro supported-sinr-resolutions* [id] | | +--ro id uint16 | | +--ro max-data-layers? uint8 | | +--ro sinr-per-prb* uint8 | | +--ro sinr-slot-bitmask* uint16 | | +--dynamic-sinr-per-prb-supported?

[0160] 'max-data-layers' can indicate the maximum number of data layers. 'sinr-per-prb' can indicate the number of SINR values ​​per PRB supported by the RU. 'dynamic-sinr-per-prb-supported' can indicate that SINR reporting with dynamic frequency resolution is supported by the RU.

[0161] Figure 10 shows an example of dynamic SINR reporting.

[0162] Referring to FIG. 10, the frequency domain of the PUSCH can be divided into three frequency domains. The three frequency domains can include a first frequency domain (1001), a second frequency domain (1002), and a third frequency domain (1003). For example, the first frequency domain (1001) can correspond to RB #0 to RB #19. For example, the second frequency domain (1002) can correspond to RB #20 to RB #39. For example, the third frequency domain (1003) can correspond to RB #40 to RB #59.

[0163] Four layers may be scheduled for PUSCH. The four layers may include a first layer (1010), a second layer (1011), a third layer (1012), and a fourth layer (1013). Each layer represents a user in a user group for MU (multi-user)-MIMO (multiple input multiple output), and the user groups may be configured differently in each frequency domain. The users may be identified by a 'ueID'. For example, a first frequency domain (1001) may include four users (e.g., ueId=0, ueId=1, ueId=2, ueId=3), a second frequency domain (1002) may include three users (e.g., ueId=1, ueId=3, ueId=4), and a third frequency domain (1003) may include two users (e.g., ueId=3, ueId=4).

[0164] In one example, the frequency resolution values ​​(e.g., the number of SINRs to be reported per PRB) configured according to the number of scheduling layers (e.g., configured via the M-plane message in [Table 5]) may be as shown in the table below.

[0165] num-scheduled-layersinr-per-prb14243341

[0166] According to one embodiment, the number of scheduling layers may represent the number of layers scheduled for each MU-MIMO group. In the first frequency domain (1001), since four layers are scheduled, the number of SINR value(s) to be reported per PRB may be 1. That is, one SINR value per PRB. In the second frequency domain (1002), since three layers are scheduled, the number of SINR value(s) to be reported per PRB may be 3. In the third frequency domain (1003), since two layers are scheduled, the number of SINR value(s) to be reported per PRB may be 2. This is expressed in a table as follows.

[0167] MU-MIMOgroup#1MU-MIMOgroup#2MU-MIMOgroup#3SINR resolution for ueId = 4-34SINR resolution for ueId = 3134SINR resolution for ueId = 21--SINR resolution for ueId = 113-SINR resolution for ueId = 01--

[0168] According to one embodiment, the number of scheduling layers may represent the maximum number of layers scheduled for each MU-MIMO group. An SINR resolution to be set for each user may be determined. For example, the SINR frequency resolution (e.g., the number of SINR value(s) to be reported per PRB) for a first user (ueId=0) may be '1'. The SINR frequency resolution (e.g., the number of SINR value(s) to be reported per PRB) for a second user (ueId=1) may be '1'. Since the maximum number that can be scheduled for the second user (ueId=1) is 4, the frequency resolution to be used for SINR reporting may be determined based on the first frequency domain (1001). The SINR frequency resolution (e.g., the number of SINR value(s) to be reported per PRB) for a third user (ueId=2) may be '1'. Since the maximum number that can be scheduled for the third user (ueId=2) is 4, the frequency resolution to be used for SINR reporting can be determined based on the first frequency domain (1001). The SINR frequency resolution (e.g., the number of SINR value(s) to be reported per PRB) for the fourth user (ueId=3) can be '1'. Since the maximum number that can be scheduled for the fourth user (ueId=3) is 4, the frequency resolution to be used for SINR reporting can be determined based on the first frequency domain (1001). The SINR frequency resolution (e.g., the number of SINR value(s) to be reported per PRB) for the fifth user (ueId=4) can be '3'. Since the maximum number that can be scheduled for the fifth user (ueId=4) is 3, the frequency resolution to be used for SINR reporting can be determined based on the second frequency domain (1002). To summarize the above examples, the table below can be referenced.

[0169] numSinrPerPrbSINR resolution for ueId = 43SINR resolution for ueId = 31SINR resolution for ueId = 21SINR resolution for ueId = 11SINR resolution for ueId = 01

[0170] The C-plane message and / or M-plane message of the present disclosure allows an RU to dynamically perform SINR reporting to a DU. The term "dynamic" indicates that the resolution for SINR reporting (e.g., the number of SINRs to be reported per PRB) can be changed via the C-plane instead of being statically set via the M-plane. Furthermore, the resolution for SINR reporting can be individually configured for each layer via the C-plane message for dynamic SINR reporting. The effects obtainable from the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0171] According to embodiments, a method performed by a distributed unit (DU) may include transmitting, to a radio unit (RU), a management-plane (M-plane) message for configuring a signal-to-interference-plus-noise-ratio (SINR) report, and transmitting, to the RU, a downlink control-plane (C-plane) message including section extension information for dynamically setting a number of SINR values ​​per physical resource block (PRB) in the SINR report, and receiving, from the RU, an uplink control-plane message including section information used for transmitting SINR data, the section extension information including information indicating a number of layers and information on a number of SINR values ​​per PRB for the layers. The section information may include information indicating a number of SINR values ​​per PRB corresponding to the layer and at least one SINR value in each PRB in the layer.

[0172] For example, the above layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the above layers may include a value indicating the number of SINR values ​​per PRB that apply to all of the above layers.

[0173] For example, the layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the layers may include a set of SINR values ​​per PRB corresponding to the layers. Each value of the set of SINR values ​​per PRB may correspond to one of the layers.

[0174] For example, the M-plane message may include information indicating that dynamic setting of the number of SINRs per PRB in the SINR report is enabled, information about the number of scheduling layers, and information about the number of SINR values ​​per PRB for the scheduling layers.

[0175] For example, the C-plane message may further include section extension information for configuring a physical uplink shared channel (PUSCH) demodulation reference signal (DMRS). The DU may be configured to perform layer mapping, demodulation, and decoding. The RU may be used for channel estimation and beamforming weight calculation.

[0176] In embodiments, a method performed by a radio unit (RU) may include receiving, from a distributed unit (DU), a management-plane (M-plane) message for configuring a signal-to-interference-plus-noise-ratio (SINR) report, receiving, from the DU, a downlink control-plane (C-plane) message including section extension information for dynamically setting a number of SINR values ​​per physical resource block (PRB) in the SINR report, and transmitting, to the DU, for each of the layers, an uplink control-plane message including section information used for transmitting SINR data, the section extension information including information indicating a number of layers and information on a number of SINR values ​​per PRB for the layers. The section information may include information indicating a number of SINR values ​​per PRB corresponding to the layer and at least one SINR value in each PRB in the layer.

[0177] For example, the above layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the above layers may include a value indicating the number of SINR values ​​per PRB that apply to all of the above layers.

[0178] For example, the layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the layers may include a set of SINR values ​​per PRB corresponding to the layers. Each value of the set of SINR values ​​per PRB may correspond to one of the layers.

[0179] For example, the M-plane message may include information indicating that dynamic setting of the number of SINRs per PRB in the SINR report is enabled, information about the number of scheduling layers, and information about the number of SINR values ​​per PRB for the scheduling layers.

[0180] For example, the C-plane message may further include section extension information for configuring a physical uplink shared channel (PUSCH) demodulation reference signal (DMRS). The DU may be used for layer mapping, demodulation, and decoding. The RU may be configured to perform channel estimation and beamforming weight calculation.

[0181] In embodiments, a device of a distributed unit (DU) is provided. The device may include a fronthaul transceiver; at least one processor including a processing circuit; and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the device to transmit, to a radio unit (RU) via the fronthaul transceiver, a management-plane (M-plane) message for configuring a signal-to-interference-plus-noise-ratio (SINR) report, and to transmit, to the RU via the fronthaul transceiver, a downlink control-plane (C-plane) message including section extension information for dynamically setting a number of SINR values ​​per physical resource block (PRB) in the SINR report, the section extension information including information indicating a number of layers and information about a number of SINR values ​​per PRB for the layers, and to receive, from the RU via the fronthaul transceiver, an uplink control-plane message including section information used for transmitting SINR data, for each of the layers. The section information may include information indicating a number of SINR values ​​per PRB corresponding to the layer and at least one SINR value in each PRB in the layer.

[0182] For example, the above layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the above layers may include a value indicating the number of SINR values ​​per PRB that apply to all of the above layers.

[0183] For example, the layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the layers may include a set of SINR values ​​per PRB corresponding to the layers. Each value of the set of SINR values ​​per PRB may correspond to one of the layers.

[0184] For example, the M-plane message may include information indicating that dynamic setting of the number of SINRs per PRB in the SINR report is enabled, information about the number of scheduling layers, and information about the number of SINR values ​​per PRB for the scheduling layers.

[0185] For example, the C-plane message may further include section extension information for configuring a physical uplink shared channel (PUSCH) demodulation reference signal (DMRS). The DU may be configured to perform layer mapping, demodulation, and decoding. The RU may be used for channel estimation and beamforming weight calculation.

[0186] In embodiments, a device of a radio unit (RU) is provided. The device may include a fronthaul transceiver; at least one processor including a processing circuit; and a memory storing instructions. The instructions, when executed by the at least one processor, may cause the device to receive, from a distributed unit (DU) through the fronthaul transceiver, a management-plane (M-plane) message for configuring a signal-to-interference-plus-noise-ratio (SINR) report, and to receive, from the DU through the fronthaul transceiver, a downlink control-plane (C-plane) message including section extension information for dynamically setting a number of SINR values ​​per physical resource block (PRB) in the SINR report, the section extension information including information indicating a number of layers and information about a number of SINR values ​​per PRB for the layers, and to transmit, for each of the layers, an uplink control-plane message including section information used for transmitting SINR data, to the DU through the fronthaul transceiver. The section information may include information indicating a number of SINR values ​​per PRB corresponding to the layer and at least one SINR value in each PRB in the layer.

[0187] For example, the above layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the above layers may include a value indicating the number of SINR values ​​per PRB that apply to all of the above layers.

[0188] For example, the layers may be used for uplink data transmission. Information about the number of SINR values ​​per PRB for the layers may include a set of SINR values ​​per PRB corresponding to the layers. Each value of the set of SINR values ​​per PRB may correspond to one of the layers.

[0189] For example, the M-plane message may include information indicating that dynamic setting of the number of SINRs per PRB in the SINR report is enabled, information about the number of scheduling layers, and information about the number of SINR values ​​per PRB for the scheduling layers.

[0190] For example, the C-plane message may further include section extension information for configuring a physical uplink shared channel (PUSCH) demodulation reference signal (DMRS). The DU may be used for layer mapping, demodulation, and decoding. The RU may be configured to perform channel estimation and beamforming weight calculation.

[0191] In embodiments, a method performed by a distributed unit (DU) may include transmitting to a radio unit (RU) a first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report. The method may include receiving from the RU a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB.

[0192] For example, the method may include receiving a first management plane message from the RU, the first management plane message including a parameter for indicating that the capability to dynamically control the frequency resolution is supported by the RU. The method may include transmitting a second management plane message to the RU, the second management plane message including a parameter for activating the capability to dynamically control the frequency resolution.

[0193] For example, the number of one or more PRBs per PRB may be the same for all layers scheduled for a UE (user equipment).

[0194] For example, the first control plane message including the section extension information may include second section extension information according to section extension 24 for PUSCH (physical uplink shared channel) DMRS (demodulation reference signal) configuration.

[0195] For example, the first control plane message including the section extension information may include second section type information according to section type 5 for UE scheduling information.

[0196] For example, the method may include determining the number of one or more SINR values ​​per PRB based on at least one of the number of scheduled layers, a modulation and coding scheme (MCS), or a fronthaul bandwidth.

[0197] For example, the number of one or more SINR values ​​per PRB corresponding to the frequency resolution may be for a first UE. The section extension information may indicate the number of at least one SINR value per PRB corresponding to a second frequency resolution for a second UE.

[0198] In embodiments, a distributed unit (DU) may include communication circuitry. The DU may include a memory storing instructions and including one or more storage media. The DU may include at least one processor including processing circuitry. The instructions, when individually or collectively executed by the at least one processor, may cause the DU to transmit a first control plane message to a radio unit (RU), the first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report by the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the DU to receive from the RU a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of the one or more SINR values ​​per PRB.

[0199] For example, the instructions, when individually or collectively executed by the at least one processor, may cause the DU to receive from the RU a first management plane message comprising a parameter for indicating that the capability to dynamically control the frequency resolution is supported by the RU. The instructions, when individually or collectively executed by the at least one processor, may cause the DU to transmit to the RU a second management plane message comprising a parameter for activating the capability to dynamically control the frequency resolution.

[0200] For example, the number of one or more PRBs per PRB may be the same for all layers scheduled for a UE (user equipment).

[0201] For example, the first control plane message including the section extension information may include second section extension information according to section extension 24 for PUSCH (physical uplink shared channel) DMRS (demodulation reference signal) configuration.

[0202] For example, the first control plane message including the section extension information may include second section type information according to section type 5 for UE scheduling information.

[0203] For example, the instructions, when individually or collectively executed by the at least one processor, may cause the DU to determine a number of one or more SINR values ​​per PRB based on at least one of a number of scheduled layers, a modulation and coding scheme (MCS), or a fronthaul bandwidth.

[0204] For example, the number of one or more SINR values ​​per PRB corresponding to the frequency resolution may be for a first UE. The section extension information may indicate the number of at least one SINR value corresponding to a second frequency resolution for a second UE.

[0205] In embodiments, a method performed by a radio unit (RU) may include receiving, from a distributed unit (DU), a first control plane message including section extension information for indicating a number of one or more SINR values ​​per physical resource block (PRB) corresponding to a frequency resolution of a signal-to-interference-plus-noise-ratio (SINR) report by the RU. The method may include transmitting, to the DU, a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB.

[0206] For one or more embodiments, at least one of the components described in one or more of the preceding drawings may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a processor (e.g., a baseband processor) described herein with respect to one or more of the preceding drawings may be configured to operate according to one or more examples described herein. For another example, circuitry associated with a user equipment (UE), a base station, a network element, and the like, as described above with respect to one or more of the preceding drawings, may be configured to operate according to one or more examples described herein.

[0207] Any of the embodiments described above may be combined with any other embodiment (or combination of embodiments) unless explicitly stated otherwise. The foregoing description of one or more implementations provides examples and descriptions, but is not intended to be exhaustive or limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be learned from practicing various embodiments.

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

[0209] When implemented in software, a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure. The one or more programs may be provided as a computer program product. The computer program product may be traded between a seller and a buyer as a commodity. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play Store™) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0210] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in memories formed by a combination of some or all of these. In addition, each configuration memory may include multiple copies.

[0211] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

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

[0213] According to embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., modules or programs) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0214] Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure.

Claims

1. In a method performed by DU (distributed unit), Transmitting a first control plane message to the RU, the first control plane message including section extension information for indicating the number of one or more SINR values ​​per physical resource block (PRB) corresponding to the frequency resolution of the SINR (signal-to-interference-plus-noise-ratio) report by the RU; and Receiving a second control plane message from the RU, comprising section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB, method.

2. In paragraph 1, Receiving a first management plane message from the RU including a parameter indicating that the ability to dynamically control the frequency resolution is supported by the RU; and transmitting to the RU a second management plane message including parameters for activating a function for dynamically controlling the frequency resolution; method.

3. In paragraph 1, The number of PRBs per PRB is the same for all layers scheduled for the UE (user equipment). method.

4. In paragraph 1, The first control plane message including the above section extension information further includes second section extension information according to section extension 24 for PUSCH (physical uplink shared channel) DMRS (demodulation reference signal) configuration. method.

5. In paragraph 1, The first control plane message including the section extension information further includes second section type information according to section type 5 for UE scheduling information. method.

6. In paragraph 1, Further comprising determining the number of one or more SINR values ​​per PRB based on at least one of the number of scheduled layers, modulation and coding scheme (MCS), or fronthaul bandwidth. method.

7. In paragraph 1, The number of one or more SINR values ​​per PRB corresponding to the above frequency resolution is for the first UE, and The above section extension information further indicates the number of at least one SINR value per PRB corresponding to the second frequency resolution for the second UE. method. In 8.DU (distributed unit), communication circuit; A memory storing instructions and including one or more storage media; and At least one processor including a processing circuit, wherein the instructions, when individually or collectively executed by the at least one processor, cause the DU to: Transmitting a first control plane message to the RU, the first control plane message including section extension information for indicating the number of one or more SINR values ​​per PRB (physical resource block) corresponding to the frequency resolution of the SINR (signal-to-interference-plus-noise-ratio) report by the RU, and Causing the RU to receive a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB, DU.

9. In paragraph 8, The above instructions, when individually or collectively executed by the at least one processor, cause the DU to: Receive a first management plane message from the RU including a parameter indicating that the capability to dynamically control the frequency resolution is supported by the RU, and Causing the RU to transmit a second management plane message including parameters for activating the function of dynamically controlling the frequency resolution; DU.

10. In paragraph 8, The number of PRBs per PRB is the same for all layers scheduled for the UE (user equipment). DU.

11. In paragraph 8, The first control plane message including the above section extension information further includes second section extension information according to section extension 24 for PUSCH (physical uplink shared channel) DMRS (demodulation reference signal) configuration. DU.

12. In paragraph 8, The first control plane message including the section extension information further includes second section type information according to section type 5 for UE scheduling information. DU.

13. In paragraph 8, The above instructions, when individually or collectively executed by the at least one processor, cause the DU to: Causing to determine the number of one or more SINR values ​​per PRB based on at least one of the number of scheduled layers, modulation and coding scheme (MCS), or fronthaul bandwidth. DU.

14. In paragraph 8, The number of one or more SINR values ​​per PRB corresponding to the above frequency resolution is for the first UE, and The above section extension information further indicates the number of at least one SINR value corresponding to the second frequency resolution for the second UE. DU. In a method performed by 15.RU (radio unit), Receiving a first control plane message from a distributed unit (DU) including section extension information for indicating the number of one or more SINR values ​​per physical resource block (PRB) corresponding to the frequency resolution of the SINR (signal-to-interference-plus-noise-ratio) report by the RU; and Including transmitting to the DU a second control plane message including section type information for indicating the one or more SINR values ​​according to the frequency resolution and the number of one or more SINR values ​​per PRB, method.

Images