Method for transmitting or receiving control plane message through fronthaul interface, and electronic device for performing same

Abstract

Provided are a method for transmitting or receiving a control plane message through a fronthaul interface, and an electronic device for performing same. The method may comprise the steps of: receiving, from a radio unit (RU), a management plane message including information on a control plane message supported by the RU; on the basis of the management plane message, generating a first control plane message including a field indicating a first UE ID and a first section extension field; and transmitting the first control plane message to the RU through a fronthaul interface. The first section extension field may include a parameter indicating the number of UE IDs of a user associated with the first UE ID. The first control plane message may be transmitted with a period longer than a slot.

Description

Method for transmitting or receiving a control plane message through a fronthaul interface and an electronic device performing the same

[0001] The present disclosure relates to a method for wireless communication based on a fronthaul interface and an electronic device performing the same, and more particularly, to a method for transmitting or receiving a control plane message via a fronthaul interface and an electronic device performing the same.

[0002] Conventionally, a base station (base station) that provides wireless communication services has its data processing unit or digital unit (or distributed unit, DU) and its wireless transceiver unit or radio unit (or remote unit, RU) installed together at a cell site. Conventional base stations were not suitable for building multiple cell sites as users and traffic increased. To improve this, a base station structure was developed that concentratedly places DUs in one physical location, leaving only RUs in the cell site that actually transmit and receive wireless signals with terminals. In this case, the DU and RU can be connected using an optical cable or coaxial cable. This base station structure is also being standardized in the 3rd Generation Partnership Project (3GPP), and O-RAN (Open Radio Access Network), an open network standard that can be applied to the 5G system, is being studied.

[0003] A base station according to the O-RAN standard may include an O-DU and an O-RU. The O-DU and O-RU may communicate with each other through a fronthaul interface. A fronthaul interface according to the O-RAN standard may be referred to as an open fronthaul interface. The fronthaul interface may include a Control User Synchronization (CUS) plane and a Management (M) plane.

[0004] A method for wireless communication performed by a Distributed Unit (DU) according to one embodiment of the present disclosure may include: receiving, from a Radio Unit (RU), a management plane message including information regarding a control plane message supported by the RU; generating, based on the management plane message, a first control plane message including a field indicating a first User Equipment Identifier (UE ID) and a first section extension field; and transmitting, to the RU, the first control plane message via a fronthaul interface. The first section extension field may include a parameter indicating the number of UE IDs of users associated with the first UE ID. The first control plane message may be transmitted at a period longer than a slot.

[0005] A method for wireless communication performed by an RU according to one embodiment of the present disclosure may include: transmitting, to a DU, a management plane message including information regarding a control plane message supported by the RU; and receiving, from the DU, a first control plane message via a fronthaul interface. The first control plane message may include a field indicating a first UE ID and a first section extension field. The first section extension field may include a parameter indicating a number of UE IDs of users associated with the first UE ID. The first control plane message may be transmitted at a period longer than a slot.

[0006] An electronic device for wireless communication according to one embodiment of the present disclosure may include: at least one processor including a processing circuit; at least one transceiver for transmitting or receiving a signal via a fronthaul interface; and a memory including one or more storage media storing one or more instructions. The one or more instructions, when individually or in combination executed by the at least one processor, may cause the electronic device to: receive, from an RU, a management plane message including information regarding a control plane message supported by the RU; generate, based on the management plane message, a first control plane message including a field indicating a first UE ID and a first section extension field; and transmit, to the RU, the first control plane message via the fronthaul interface. The first section extension field may include a parameter indicating a number of UE IDs of a user associated with the first UE ID. The first control plane message may be transmitted at a period longer than a slot.

[0007] An electronic device for wireless communication according to one embodiment of the present disclosure may include: at least one processor including a processing circuit; at least one transceiver for transmitting or receiving a signal via a fronthaul interface; and a memory including one or more storage media for storing one or more instructions. The one or more instructions, when individually or in combination executed by the at least one processor, may cause the electronic device to: transmit, to a DU, a management plane message including information regarding a control plane message supported by the RU; and receive, from the DU, via the fronthaul interface, a first control plane message. The first control plane message may include a field indicating a first UE ID and a first section extension field. The first section extension field may include a parameter indicating a number of UE IDs of a user associated with the first UE ID.

[0008] FIG. 1 illustrates an example of a wireless communication system according to one embodiment of the present disclosure.

[0009] FIG. 2 illustrates an exemplary block diagram of a base station of an open wireless access network according to one embodiment of the present disclosure.

[0010] FIG. 3 illustrates an exemplary block diagram of a distributed unit (DU) according to one embodiment of the present disclosure.

[0011] FIG. 4 illustrates an exemplary block diagram of a radio unit (RU) according to one embodiment of the present disclosure.

[0012] FIG. 5 illustrates an example of transmit antenna switching (TAS) according to one embodiment of the present disclosure.

[0013] FIG. 6 illustrates an example of singular value decomposition (SVD) beamforming according to one embodiment of the present disclosure.

[0014] FIG. 7 illustrates an exemplary flowchart of a method for wireless communication according to one embodiment of the present disclosure.

[0015] FIG. 8 exemplarily illustrates a configuration of a section type according to one embodiment of the present disclosure.

[0016] FIG. 9 illustrates an example configuration of a section expansion according to one embodiment of the present disclosure.

[0017] FIG. 10 exemplarily illustrates a configuration of a section expansion according to one embodiment of the present disclosure.

[0018] FIG. 11 illustrates an example of timing of downlink control plane (C-plane) data transmission and reception between a DU and a RU according to one embodiment of the present disclosure.

[0019] FIG. 12 illustrates an example configuration of a section type according to one embodiment of the present disclosure.

[0020] FIG. 13 exemplarily illustrates a configuration of a section type including a section extension according to one embodiment of the present disclosure.

[0021] FIG. 14 illustrates an example configuration of a section type according to one embodiment of the present disclosure.

[0022] FIG. 15 illustrates an exemplary configuration of a section type including a section extension according to one embodiment of the present disclosure.

[0023] FIG. 16 illustrates an exemplary flowchart of a method for wireless communication performed by a DU according to one embodiment of the present disclosure.

[0024] FIG. 17 exemplarily illustrates a flowchart of a method for wireless communication performed by an RU according to one embodiment of the present disclosure.

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

[0026] 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.

[0027] 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.

[0028] In the following description, terms referring to signals (e.g., message, information, preamble, signal, signaling, sequence, stream), 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 control information (e.g., downlink control information (DCI), medium access control element (MAC CE), radio resource control (RRC) signaling), terms referring to network entities, terms referring to components of devices, etc. 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.

[0029] Singular expressions may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art described herein.

[0030] Throughout this disclosure, when a part is said to "include" a component, this does not exclude other components, but rather implies the inclusion of other components, unless otherwise specifically stated. Furthermore, terms such as "unit" and "module" described herein mean a unit that processes at least one function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

[0031] As used herein, the expression "configured to" can be used interchangeably with, for example, "suitable for," "having the capacity to," "designed to," "adapted to," "made to," or "capable of." The term "configured to" does not necessarily mean something is "specifically designed to" in terms of hardware. Instead, in some contexts, the expression "a system configured to" can mean that the system is "capable of" in conjunction with other devices or components. For example, the phrase "a processor configured to perform A, B, and C" can mean a dedicated processor for performing the operations (e.g., an embedded processor), or a general-purpose processor (e.g., a CPU or an application processor) that can perform the operations by executing one or more software programs stored in memory.

[0032] Additionally, when a component is referred to as being "connected" or "connected" to another component in the present disclosure, it should be understood that the component may be directly connected or connected to the other component, but may also be connected or connected via another component in between, unless otherwise specifically stated.

[0033] Additionally, 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. However, this is merely a description for expressing an example and does not exclude descriptions of "more than" or "less than." Conditions described as "more than" may be replaced with "more than," conditions described as "less than" may be replaced with "less than," and conditions described as "more than and less than" may be replaced with "more than and less than."

[0034] Additionally, although the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), 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 as well.

[0035] For the convenience of explanation below, this disclosure uses terms and names defined in the 3GPP LTE (Long Term Evolution) or NR (New Radio) standards, or terms and names modified therefrom. However, this disclosure is not limited to the above-described terms and names, and may be equally applied to systems conforming to other standards. In this disclosure, eNB (eNode B) may be used interchangeably with gNB (gNode B) for the convenience of explanation. For example, a base station referred to as eNB may also be understood as gNB. In this disclosure, the term terminal may represent various wireless communication devices, including UE (User Equipment), MS (Mobile Station), cell phones, NB-IoT (narrowband-internet of things) devices, and sensors.

[0036] FIG. 1 illustrates an example of a wireless communication system according to one embodiment of the present disclosure.

[0037] FIG. 1 illustrates a wireless communication system according to various embodiments of the present disclosure. FIG. 1 illustrates a base station (102), a terminal (104), and a terminal (106) as some of the nodes utilizing a wireless channel in the wireless communication system. While FIG. 1 illustrates only one base station, other base stations identical to or similar to base station (102) may be included.

[0038] A base station (102) is a network infrastructure that provides wireless access to terminals (104, 106). The base station (102) has coverage defined as a certain geographical area based on the distance at which a signal can be transmitted. The base station (102) may also be referred to as an access point (AP), an eNodeB (eNB), a 5th generation node, a next generation nodeB (gNB), a wireless point, a transmission / reception point (TRP), or other terms having equivalent technical meanings.

[0039] Each of the terminals (104) and the terminal (106) is a device used by a user and communicates with the base station (102) via a wireless channel. The link from the base station (102) to the terminal (104) or the terminal (106) may be referred to as a downlink (DL). The link from the terminal (104) or the terminal (106) to the base station (102) may be referred to as an uplink (UL). In addition, the terminals (104) and the terminals (106) may communicate with each other via a wireless channel. In this case, the device-to-device (D2D) link between the terminals (104) and the terminals (106) may be referred to as a sidelink. The sidelink may be used interchangeably with the PC5 interface.

[0040] In some embodiments, at least one of the terminal (104) and the terminal (106) may be operated without user intervention. That is, at least one of the terminal (104) and the terminal (106) may be a device that performs machine type communication (MTC) and may not be carried by the user. Each of the terminal (104) and the terminal (106) may be referred to as user equipment (UE), customer premises equipment (CPE), mobile station, subscriber station, remote terminal, wireless terminal, electronic device, user device, or other terms having equivalent technical meanings.

[0041] The base station (102), the terminal (104), and the terminal (106) can perform beamforming. The base station and the terminal can transmit and receive wireless signals in a relatively low frequency band (e.g., frequency range 1 (FR1) of NR). Additionally, the base station and the terminal can transmit and receive wireless signals in a relatively high frequency band (e.g., FR2 of NR, millimeter wave (mmWave) band (e.g., 28 GHz, 30 GHz, 38 GHz, 60 GHz)). In some embodiments, the base station (102) can communicate with the terminal (110) within a frequency range corresponding to FR1. In some embodiments, the base station can communicate with the terminal (104) within a frequency range corresponding to FR2. At this time, in order to improve channel gain, the base station (102), the terminal (104), and the terminal (106) can perform beamforming. Here, beamforming may include transmit beamforming and receive beamforming. For example, the base station (102), terminal (104), and terminal (106) may impart directionality to a transmit signal or a receive signal. To this end, the base station (102) and terminals (104, 106) may select serving beams through a beam search or beam management procedure. After the serving beams are selected, subsequent communication may be performed through resources that have a QCL relationship with the resource that transmitted the serving beams.

[0042] In the present disclosure, the term 'beam' may refer to the spatial flow of a signal in a wireless channel. For example, the beam of an antenna may be a radiation pattern without limitation to the main lobe. The beam is formed by one or more antennas (or antenna elements), and this forming process may be referred to as beamforming. Beamforming may include 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 information element (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, or D).

[0043] 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.

[0044] Although both the base station and the terminal are depicted as performing beamforming in FIG. 1, various 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.

[0045] In the past, in communication systems with relatively large cell radius of base stations, each base station was installed to include the functions of a digital processing unit (or DU (distributed unit)) and an RF (radio frequency) processing unit (RF processing unit, or RU (radio unit)). However, as higher frequency bands are used in 4G (4th generation) and / or subsequent communication systems (e.g., 5G) and the cell coverage of base stations decreases, the number of base stations to cover a specific area has increased. The installation costs for operators to install base stations have also increased. In order to minimize the installation costs 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 via a wired network, and one or more RUs are geographically distributed to cover a specific area. Hereinafter, the deployment structure and expansion examples of base stations according to various embodiments of the present disclosure are described through FIG. 2.

[0046] FIG. 2 illustrates an exemplary block diagram of a base station (200) of an open wireless access network according to one embodiment of the present disclosure.

[0047] Referring to FIG. 2, a base station (200) may include a DU (202) and one or more RUs (204, 206). A logical link between the DU (202) and the RUs (204, 206) may be referred to as a fronthaul. For example, the fronthaul may be a logical link connecting the DU (202) and the RUs (204, 206). The fronthaul may transport traffic of at least one of a control plane (C-Plane), a user plane (U-Plane), a synchronization plane (S-Plane), or a management plane (M-Plane). In one embodiment, the fronthaul may be operated via an FX interface. For operation of the fronthaul, an interface such as an enhanced common public radio interface (eCPRI) or radio over Ethernet (ROE) may be used, for example.

[0048] As communication technology advances, mobile data traffic increases, significantly increasing the bandwidth requirements for the fronthaul between the digital unit and the wireless unit. In a deployment such as a centralized / cloud radio access network (C-RAN), the DU (202) may be implemented to perform functions for the packet data convergence protocol (PDCP), radio link control (RLC), media access control (MAC), and physical (PHY) layer, and the RUs (204, 206) may be implemented to perform functions for the PHY layer in addition to the RF function.

[0049] The DU (202) may be responsible for upper layer functions of a wireless network. For example, the DU (202) 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). In one embodiment, if the DU (202) complies with the O-RAN standard, the DU (202) may be referred to as an O-DU (O-RAN DU). The O-DU may be a logical node that hosts RLC / MAC / upper-PHY layers based on lower layer functional split. The DU (202) may be replaced and represented as a first network entity for a base station (e.g., gNB) in embodiments of the present disclosure, as needed.

[0050] The RUs (204, 206) may be responsible for lower layer functions of the wireless network. For example, the RUs (204, 206) may perform a part of the PHY layer, an RF function. Here, the part of the PHY layer may be a function of the PHY layer that is performed at a relatively lower level than the DU (202). For example, the part of the PHY layer may include an inverse fast Fourier transform (iFFT) (or fast Fourier transform (FFT)), CP insertion (CP removal), or digital beamforming. The RUs (204, 206) 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 therefor. In one embodiment, if the RUs (204, 206) comply with the O-RAN specification, they may be referred to as O-RUs (O-RAN RUs). An O-RU may be a logical node that hosts lower PHY layers and RF processing based on lower layer functional separation. The RUs (204, 206) may be replaced with second network entity(ies) for a base station (e.g., gNB) in embodiments of the present disclosure, as needed. In one embodiment, the RUs (204, 206) may be implemented in a similar manner and may operate in a similar manner.

[0051] Although FIG. 2 illustrates a base station as including a DU and an RU, various embodiments of the present disclosure are not limited thereto. In some embodiments, the base station 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., a packet data convergence protocol (PDCP) layer or an RRC layer) and a distributed unit (DU) configured to perform functions of lower layers. A centralized unit (CU) may be connected to one or more DUs and may be responsible for functions of a higher layer than the DU. In one embodiment, if a CU complies with the O-RAN specification, it may be referred to as an O-CU (O-RAN CU). An O-CU may be a logical node hosting PDCP, RRC, SDAP (Service Data Adaptation Protocol), and / or other control functions. Various embodiments of the present disclosure can be applied to both a base station deployment including a CU and a deployment where a DU is directly connected to a core network without a CU (i.e., where the CU and DU are implemented as a single entity).

[0052] In the illustrated embodiment, the DU (202) may be implemented as an O-DU, and the RUs (204, 206) may be implemented as O-RUs. The paths (LLS-C) and (LLS-U) may provide a control plane and a user plane, respectively, via a Lower Layer Split (LLS) interface. For example, control plane traffic between the DU (202) and the RUs (204, 206) may be transported via a Lower Layer Split Control Plane (LLS-C) interface. User plane traffic between the DU (202) and the RUs (204, 206) may be transported via a Lower Layer Split User Plane (LLS-U) interface. The LLS interface may be a logical interface between the O-DU and the O-RU when using (intra-PHY based) lower layer functional separation. The LLS-C interface may be a logical interface (e.g., for the control plane) between the O-DU and the O-RU when lower layer functional separation is used. The LLS-U interface may be a logical interface (e.g., for the user plane) between the O-DU and the O-RU when lower layer functional separation is used.

[0053] As wireless communication technology develops (for example, the introduction of 5G communication systems (or NR (new radio) communication systems), the frequency bands used have increased further, and the cell radius of base stations has become very small, so the number of RUs that need to be installed has increased further. In addition, in 5G communication systems, the amount of data transmitted has increased by a large amount, up to ten times, so the transmission capacity of the wired network transmitted to the fronthaul has increased significantly. Due to these factors, 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, technologies have been proposed to lower the transmission capacity of the fronthaul by transferring some of the functions of the modem of the DU to the RU, and these technologies can be referred to as 'function split'.

[0054] To reduce the burden on the DU, a method is being considered to expand the role of the RU, which is currently solely responsible for RF functions, to include some physical layer functions. In this case, as the RU performs higher-layer functions, its throughput increases, increasing transmission bandwidth in the fronthaul while simultaneously 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.

[0055] With respect to functions in the PHY layer below the MAC layer, in the case of downlink (DL) that transmits signals to a terminal through a wireless network, the base station may sequentially perform at least some of channel encoding / scrambling, modulation, layer mapping, antenna mapping, RE (Resource Element) mapping, IQ (In-phase / Quadrature-phase) compression / decompression, digital beamforming (e.g., precoding), inverse fast Fourier transform (iFFT) and cyclic prefix (CP) addition, digital-to-analog conversion (or RF conversion), or analog beamforming. For the uplink (UL) that receives signals from terminals via a wireless network, the base station can sequentially perform at least some of analog beamforming, analog-to-digital conversion (or RF conversion), fast Fourier transform (FFT) and CP removal, filtering (e.g., CP removal, decimation filtering, and / or FFT), digital beamforming (e.g., pre-combining), IQ compression / decompression, RE demapping, channel estimation, detection, equalization, inverse Discrete Fourier Transform (iDFT) channel estimation, layer demapping, demodulation, or decoding / descrambling. The separation of uplink functions and downlink functions can be defined in various types depending on the needs of vendors, discussions in standards, etc., according to the above-described trade-offs.

[0056] Embodiments of the present disclosure may support various variations of functional separation. In one embodiment, RF functions and PHY functions may be separated. Accordingly, the PHY function may not be substantially implemented within the RU, and this functional separation may be referred to as 'Option 8'. In one embodiment, the RU may perform, among the PHY functions, iFFT / CP insertion in the DL and FFT / CP removal in the UL, and the DU may perform the remaining PHY functions. This functional separation may be referred to as 'Option 7-1'. In one embodiment, the RU may perform, among the PHY functions, iFFT / CP insertion in the DL, FFT / CP removal in the UL, and digital beamforming (e.g., precoding) in the UL, and the DU may perform the remaining PHY functions. This functional separation may be referred to as 'Option 7-2x Category A'. In one embodiment, the RU may additionally perform digital beamforming in both the DL and UL, and the DU may perform higher-order PHY functions after the digital beamforming (e.g., remaining PHY functions). For example, the RU may perform iFFT / CP insertion and digital beamforming in the DL, and also perform FFT / CP removal and digital beamforming in the UL, among the PHY functions. This separation of functions may be referred to as 'Option 7-2x Category B'. In one embodiment, the RU may additionally perform RE mapping (or RE demapping) in both the DL and UL, and the DU may perform higher-order PHY functions after the RE mapping (or RE demapping). For example, the RU may perform iFFT / CP insertion, digital beamforming, and RE mapping in the DL, and also perform FFT / CP removal, digital beamforming, and RE demapping in the UL, among the PHY functions. This separation of functions may be referred to as 'Option 7-2'.In one embodiment, the RU may additionally perform at least some of antenna port mapping, layer mapping, and modulation (or demodulation) in both the DL and the UL, and the DU may perform subsequent higher PHY functions up to modulation (or demodulation). For example, the RU may perform iFFT / CP insertion, digital beamforming, RE mapping, antenna port mapping, layer mapping, and modulation in the DL, and may also perform FFT / CP removal, digital beamforming, RE demapping, channel estimation, layer demapping, and demodulation in the UL. This functional separation may be referred to as 'Option 7-3'. In one embodiment, the RU may additionally perform encoding / scrambling (or decoding / descrambling) in both the DL and the UL, and the DU may perform subsequent higher PHY functions. For example, the RU may perform, among PHY functions, iFFT / CP insertion, digital beamforming, RE mapping, antenna port mapping, layer mapping, modulation, and channel encoding / scrambling in the DL, and also perform FFT / CP removal, digital beamforming, RE demapping, channel estimation, layer demapping, demodulation, and decoding / descrambling in the UL. This functional separation may be referred to as 'Option 6'.

[0057] In the present disclosure, the upper PHY refers to physical layer processing performed in a DU of a fronthaul interface. For example, upper PHY functions may include Forward Error Correction (FEC) encoding / decoding, scrambling / descrambling, and / or modulation / demodulation. In addition, the lower PHY refers to physical layer processing performed in a RU of the fronthaul interface. For example, lower PHY functions may include FFT / iFFT, digital beamforming, and PRACH (physical random access channel) extraction and filtering.

[0058] In one embodiment, when a large amount of signal processing is expected, such as in an FR1 MMU (massive MIMO unit), functional separation at a relatively high layer (e.g., option 7-2x category B) may be required to reduce fronthaul capacity. In addition, functional separation at too high a layer (e.g., option 7-3) 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 within the RU. Therefore, appropriate functional separation may be required depending on the arrangement and implementation method of the DU and RU.

[0059] In one embodiment, if the DU cannot handle precoding of data received from it (i.e., the RU has limited precoding capability), then Option 7-2x Category A or lower functional separation (e.g., Option 7-1) may be applied. Conversely, if the DU has the capability to handle precoding of data received from it, then Option 7-2x Category B or higher functional separation (e.g., Option 7-3) may be applied.

[0060] In one embodiment following the O-RAN standard, Option 7-2x Category A and Option 7-2x Category B may be supported with respect to functional separation. Option 7-2x Category A and Option 7-2x Category B are distinguished based on whether the O-RU can execute a precoding operation on data received from the O-DU. An O-RU that does not perform precoding (and therefore has low complexity) may be referred to as a 'Category A' O-RU, and an O-RU that performs precoding may be referred to as a 'Category B' O-RU. An O-DU shall support Category A O-RU for 8 transmission streams or less. In other words, the O-DU can be said to support precoding for up to 8 transmission streams. When Option 7-2x Category B is applied, the O-DU transmits information on modulation symbols that have completed layer mapping and beamforming information to the O-RU, and the O-RU applies beamforming to the modulation symbols to convert them into analog signals and transmits them to the terminal via the antenna.

[0061] Information to be transmitted from the O-DU to the O-RU in Option 7-2x may include at least some of information transmitted from the management plane, information transmitted from the synchronization plane, information transmitted from the control plane, or information transmitted from the user plane. Information transmitted from the management plane is transmitted in both DL and UL directions in non-real-time, and may include information for initial setup or reset between the O-DU and the O-RU. Information transmitted from the synchronization plane is transmitted in real-time, and may include information for synchronization or timing between the O-DU and the O-RU. Information transmitted from the control plane is transmitted in the DL direction in real-time, and may include information for the O-DU to transmit scheduling and / or beamforming commands to the O-RU. Information transmitted in the user plane is transmitted in both DL and UL directions in real-time transmission, and may include DL frequency domain IQ data (including a synchronization signal block (SSB) and a reference signal), UL frequency domain IQ data (including a reference signal such as SRS), and frequency domain IQ data for a physical random access channel (PRACH). The above-mentioned 'information' or 'data' may be used interchangeably with the term 'message'.

[0062] In one embodiment of the present disclosure, when transmitting a message between a DU (e.g., DU (202) of FIG. 2) and an RU (e.g., RU (202) of FIG. 2), the standards of eCPRI and O-RAN are exemplarily described as fronthaul interfaces. The Ethernet payload of the message may include an eCPRI header, an O-RAN header, and additional fields. Hereinafter, one embodiment of the present disclosure is described using the standard terms of eCPRI or O-RAN, but other expressions having equivalent meanings to each term may be used instead in one embodiment of the present disclosure.

[0063] The fronthaul application protocol may include a control plane, a user plane, a synchronization plane, and a management plane. The fronthaul transport protocol may use Ethernet and eCPRI, which are easily shared with networks. The Ethernet payload may include an eCPRI header and an O-RAN header. The eCPRI header (or eCPRI transport common header) may be located at the front end of the Ethernet payload.

[0064] FIG. 3 exemplarily illustrates a block diagram of a DU (202) according to one embodiment of the present disclosure.

[0065] Referring to FIG. 3, the DU (202) of FIG. 2 may include a processor (302), a memory (304), and a transceiver (306). The configuration of the DU (202) illustrated in FIG. 3 is merely an example, and examples of DUs performing an embodiment of the present disclosure are not limited to the configuration illustrated in FIG. 3. Depending on the embodiment, some configurations may be added, deleted, or changed. In one embodiment, the DU (202) may be understood as an electronic device performing functions as a DU.

[0066] The processor (302) controls the overall operations of the DU (202). For example, the processor (302) transmits and receives signals through the transceiver (306). The processor (302) can write data to the memory (304) and read data written to the memory (304). The processor (302) can perform functions of a protocol stack required by a communication standard. In one embodiment, the processor (302) can include at least one processor including processing circuitry. In some embodiments, the processor (302) can be configured to generate a control message including a section extension field. The processor (302) can control the transceiver (306) to transmit the generated control message to the RUs (204, 206). Additionally or alternatively, the processor (302) may control the DU (202) to perform at least some of the operations according to the embodiments described below.

[0067] Additionally or alternatively, the processor (302) may execute one or more instructions of a program stored in the memory (304). Although the processor (302) is illustrated as a single element in FIG. 3, it is not limited thereto. In one embodiment of the present disclosure, the processor (302) may be composed of one or more elements. The processor (302) may be implemented as, for example, a general-purpose processor such as a Central Processing Unit (CPU), an Application Processor (AP), a Digital Signal Processor (DSP), a graphics-only processor such as a Graphics Processing Unit (GPU), a Vision Processing Unit (VPU), or an artificial intelligence-only processor such as a Neural Processing Unit (NPU).

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

[0069] The memory (304) may store instructions, data structures, and program codes that can be read by the processor (302). For example, the memory (304) may store data such as a basic program, an application program, and setting information for the operation of the DU (202). In one embodiment, the memory (304) may store instructions that, when individually or in combination, are executed by the processor (302), cause the DU (202) to perform at least some of the operations of the DU (202) described below. For example, the processor (302) may perform at least some of the operations of the DU (202) described in the present disclosure by executing one or more instructions or codes stored in the memory (304).

[0070] The memory (304) may include a flash memory type, a hard disk type, a multimedia card micro type, a card type memory, and may include a non-volatile memory including at least one of a ROM (Read-Only Memory), an EEPROM (Electrically Erasable Programmable Read-Only Memory), a PROM (Programmable Read-Only Memory), a magnetic memory, a magnetic disk, and an optical disk, and / or a volatile memory such as a DRAM (Dynamic Random Access Memory) or an SRAM (Static Random Access Memory).

[0071] The transceiver (306) may perform functions for transmitting and receiving signals in a wired communication environment. The transceiver (306) may include a wired interface for controlling direct connections between devices via a transmission medium (e.g., copper wire or optical fiber). For example, the transceiver (306) may transmit electrical signals to other devices via copper wire, or perform conversion between electrical signals and optical signals. The transceiver (306) may be connected to the RU (204). The transceiver (306) may be connected to a core network or to a CU in a distributed arrangement.

[0072] The transceiver (306) may perform functions for transmitting and receiving signals in a wireless communication environment. For example, the transceiver (306) 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 (306) generates complex symbols by encoding and modulating the transmission bit stream. In addition, when receiving data, the transceiver (306) restores the reception bit stream by demodulating and decoding the baseband signal. For example, the transceiver (306) upconverts the baseband signal to an RF band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna to a baseband signal. For example, the transceiver (306) may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), etc. Additionally, the transceiver (306) may include multiple transmit and receive paths. Additionally, according to one embodiment, the transceiver (306) may be connected to the core network or to other nodes (e.g., an integrated access backhaul (IAB).

[0073] The transceiver (306) may include an antenna section. The transceiver (306) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the transceiver (306) may be composed of digital circuits and / or analog circuits (e.g., radio frequency integrated circuits (RFICs)). Here, the digital circuits and / or analog circuits may be implemented in a single package. In addition, the transceiver (306) may include a plurality of RF chains. The transceiver (306) may perform beamforming. The transceiver (306) may apply beamforming weights to signals to be transmitted and received in order to impart directionality to the signals according to the settings of the processor (302). According to one embodiment, the transceiver (306) may include a radio frequency (RF) block (or RF section). The transceiver (306) can transmit a synchronization signal, a reference signal, system information, a message, a control message, a stream, control information, or data.

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

[0075] FIG. 4 illustrates an exemplary block diagram of an RU (204) according to one embodiment of the present disclosure.

[0076] Referring to FIG. 4, the RU (204) of FIG. 2 may include a processor (402), a memory (404), and a transceiver (406). The configuration of the RU (204) illustrated in FIG. 4 is merely an example, and examples of DUs performing an embodiment of the present disclosure are not limited to the configuration illustrated in FIG. 4. Depending on the embodiment, some configurations may be added, deleted, or changed. In one embodiment, the RU (204) may be understood as an electronic device performing functions as an RU.

[0077] The processor (402) controls the overall operations of the RU (204). For example, the processor (402) transmits and receives signals through the transceiver (406). The processor (402) can write data to the memory (404) and read data written to the memory (404). The processor (402) can perform functions of a protocol stack required by a communication standard. In one embodiment, the processor (402) can include at least one processor including a processing circuit. In some embodiments, the processor (402) can be configured to receive a control message including a section extension field. For example, the processor (402) can control the transceiver (406) to receive a control message from the DU (202). Based on the received control message, the processor (402) can control the transceiver (406) to perform beamforming. Additionally or alternatively, the processor (402) may control the RU (204) to perform at least some of the operations according to the embodiments described below. In one embodiment, the processor (402) may be implemented in a similar manner to the processor (302) of FIG. 3.

[0078] The memory (404) may store instructions, data structures, and program codes that may be read by the processor (402). For example, the memory (304) may store data such as a basic program, an application program, and setting information for the operation of the RU (204). In one embodiment, the memory (404) may store instructions that may be individually or in combination executed by the processor (402) to cause the RU (204) to perform at least some of the operations of the RU (204) described below. For example, the processor (402) may perform at least some of the operations of the RU (204) described in the present disclosure by executing one or more instructions or codes stored in the memory (404). In one embodiment, the memory (404) may be implemented in a similar manner to the memory (304) of FIG. 3.

[0079] The transceiver (406) performs functions for transmitting and receiving signals via a wireless channel. For example, the transceiver (406) 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 transceiver (406) may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), and the like.

[0080] Additionally, the transceiver (406) may include multiple transmit and receive paths. Furthermore, the transceiver (406) may include an antenna section. In terms of hardware, the transceiver (406) may be configured with digital circuits and / or analog circuits (e.g., RFICs). Here, the digital circuits and / or analog circuits may be implemented in a single package. Additionally, the transceiver (406) may include multiple RF chains.

[0081] The transceiver (406) may include a massive MIMO unit (MMU) (408). The MMU (408) may include at least one antenna array composed of a plurality of antenna elements. The MMU (408) may perform beamforming. The MMU (408) may apply beamforming weights to signals to be transmitted and received to impart directionality according to the settings of the processor (402). The MMU (408) may transmit data to multiple users (or counterpart devices) simultaneously. In one embodiment, the MMU (408) may include a radio frequency (RF) block (or RF section). In one embodiment, the MMU (408) may perform channel estimation for a channel between the base station (200) and another device. For example, the MMU (408) can estimate the characteristics of the channel between the terminal and the base station (200) based on the SRS received from the terminal.

[0082] The transceiver (406) can transmit and receive signals. The transceiver (406) 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 Master Information Block (MIB), a System Information Block (SIB), remaining system information (RMSI), other system information (OSI)), a configuration message, control information, or downlink data. In addition, the transceiver (406) 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., an SRS or DM-RS), or a power headroom report (PHR).

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

[0084] FIG. 5 illustrates an example of transmit antenna switching (TAS) according to one embodiment of the present disclosure.

[0085] Referring to Figure 5, the base station (500) is N t The UE (502) may include N antennas (504). r It may include dog antennas (506) (N t , N r is a natural number). UE (502) is a base station (500) and N r At least some of the antennas (506) may be used to transmit a signal (e.g., SRS). For example, the UE (502) may include a transmission circuit including at least one of a power amplifier (PA), a low noise amplifier (LNA), a duplexer, a switch, or a filter. The base station (500) may perform channel estimation for one or more channels between the base station (500) and the UE (502) based on signals received from the UE (502).

[0086] When UE (502) transmits SRS to base station (500), N r It may be difficult to use the antennas (506) of the dog simultaneously. Accordingly, the UE (502) performs a TAS operation to transmit the SRS, r The antennas (506) of the dog can be switched. According to the TAS operation, the UE (502) transmits the circuit to N r The antennas (506) can be sequentially connected to the base station (500). For example, the UE (502) can transmit the SRS to the base station (500) using the first antenna, and then transmit the SRS to the base station (500) using the second antenna. Accordingly, the UE (502) performs the TAS operation to transmit the SRS to the N r You can send it.

[0087] The base station (500) is N t SRS can be received using the dog's antennas (504) simultaneously. N t N using dog antennas (504) rBased on the SRS reception of the number, the base station (500) r Х N t A channel matrix can be obtained. For example, the base station (500) can estimate one or more characteristics of each of one or more channels between the UE (502) and the base station (500) based on the received SRSs, and obtain a channel matrix as a result.

[0088] The SRS can be transmitted periodically across the frequency domain. The base station (500) can receive the SRS and estimate the channel condition in a specific frequency resource. Based on the received SRS, the base station (500) can calculate one or more channel state information elements such as path loss, signal attenuation, delay spread, reflection, multipath fading, Doppler shift, signal-to-noise ratio (SNR), and signal-to-interference-plus-noise ratio. Using the periodically transmitted SRS, the base station (500) can periodically update the channel state information. Using the acquired channel information, the base station (500) can perform beamforming or optimize resource allocation.

[0089] In one embodiment, the channel matrix is ​​a set of receiving antennas (e.g., N) of a base station (500). t The antennas (504) of the dog and the transmitting antennas of the UE (502) (e.g., N rThe base station (500) may be a channel state information (CSI) matrix between the antennas (506). The base station (500) may use advanced beamforming to mitigate co-channel and inter-user interference. In one embodiment, the base station (500) may use singular value decomposition (SVD) beamforming. For example, the base station (500) may design a precoding matrix by applying SVD to an estimated channel (e.g., a channel matrix).

[0090] FIG. 6 illustrates SVD beamforming according to an embodiment of the present disclosure.

[0091] Referring to Fig. 6, the base station (500) of Fig. 5 is N r Х N t SVD can be applied to the channel matrix. SVD can be a process of factorizing a real or complex matrix into individual matrices. This can be used to decompose a MIMO channel into independent and parallel subchannels. As described above in FIG. 5, if the UE (502) supports the TAS function for SRS transmission, the base station (500) can obtain different channel information corresponding to each transmit antenna. All channel information identified by a unique ueId (e.g., UE identifier, or UE ID) can be used to calculate beamforming weights. If the base station (500) can specify that these channel matrices belong to the UE (502), the base station (500) can use an advanced beamforming algorithm (e.g., SVD-based beamforming) to mitigate co-channel interference and improve transmission stability.

[0092] By applying SVD, the channel matrix is ​​N r Х N rAn orthogonal matrix U, N having only non-negative diagonal elements r Х N t Matrix Σ, N t Х N t It can be decomposed into an orthogonal matrix V. For example, the base station (500) can apply SVD based on mathematical expression 1.

[0093]

[0094] In Equation 1, H can be a matrix for the estimated channel. For example, H can be N obtained in Fig. 5. r Х N t It can be a channel matrix. Matrix Σ can be a diagonal matrix containing singular values, each singular value can correspond to a channel gain. Matrix U and matrix V can be unitary matrices. V H can be a Hermitian matrix of matrix V. For example, V H can represent the singular vector in the transmission direction.

[0095] In block (602), the base station (500) can preprocess the received signal using the matrix U derived using mathematical expression 1. The base station (500) can preprocess the Hermitian matrix U of the matrix U H The received signal can be preprocessed using. For example, the base station (500) may preprocess the matrix G = U for a given channel matrix H. H H can be obtained. In one embodiment, when the matrix H is decomposed as in Equation 1 through SVD, the matrix G is G = U H H = U H UΣV H = ΣV HIt can be expressed as. The matrix G can mean an effective channel preprocessed in a diagonalized state of the channel matrix. Using the matrix G, zero forcing (ZF) beamforming can be performed in block (608).

[0096] For example, the base station (500) applies SVD to the channel matrix H0 to obtain the matrix U0 corresponding to the channel matrix H0 and the Hermitian matrix of U0 (604) can be obtained. The base station (500) applies SVD to the channel matrix H1 to obtain the matrix U1 corresponding to the channel matrix H1 and the Hermitian matrix of U1. (606) can be obtained. In block (602), matrices H0, H1, (604), and Using (606), the base station (500) can obtain a matrix G as in Equation 2. In Equation 2, G0 is a channel corresponding to the channel matrix H0, and G1 is a channel corresponding to the channel matrix H1.

[0097]

[0098] Thereafter, in block (608), ZF beamforming can be performed based on the matrix G. Accordingly, the received signal y can be expressed as in mathematical expression 3.

[0099]

[0100] In Equation 3, y is a received signal, matrix W is a beamforming matrix (or precoding matrix), and x can be a transmitted signal. For example, matrix W can be based on matrix G obtained through SVD and ZF beamforming. In Equation 3, W = G H (GG H ) -1 can respond to.

[0101] In one embodiment, matrix H0 may represent channel information corresponding to a first antenna of the transmitter, and matrix H1 may represent channel information corresponding to a second antenna of the transmitter. For example, matrix H0 may include information associated with a channel between antenna 1 of UE (502) and base station (500) of FIG. 5, and matrix H1 may include information associated with a channel between antenna 2 of UE (502) and base station (500). Accordingly, base station (500) may perform SVD beamforming for each channel with each antenna of UE (502). In one embodiment, H0 may be a channel matrix at a first time point, and matrix H1 may be a channel matrix at a second time point. In one embodiment, H0 may be a channel matrix between base station (500) and a first UE (e.g., UE (502)), and matrix H1 may be a channel matrix between base station (500) and a second UE.

[0102] In one embodiment, 'SVD beamforming' may mean beamforming based on SVD. 'Performing SVD processing' may include applying SVD to a channel matrix H. In one embodiment, 'performing beamforming' may include obtaining (or calculating, deriving) a matrix G based on the channel matrix H and the corresponding matrix U in block (602), and applying ZF beamforming in block (608). Accordingly, by performing beamforming, the received signal y of Equation 3 may be obtained.

[0103] In order to perform SVD beamforming in FIG. 6, the channel matrix H needs to be acquired in advance. For example, in order to perform SVD beamforming, the base station (500) may need to first perform channel estimation. In one embodiment, in the base station (200) of FIG. 2, channel estimation may be performed in the DU (202), and SVD beamforming may be performed in the RU (204 / 206). Therefore, in order to perform SVD beamforming, the DU (202) may need to provide channel information including the channel matrix H to the RU (204 / 206). In one embodiment, in the base station (200), channel estimation and SVD beamforming may be performed in the RU (204 / 206). Therefore, the DU (202) may need to transmit a command to the RU (204 / 206) to perform channel estimation and SVD beamforming.

[0104] When the UE (502) supports TAS as in the embodiment illustrated in FIG. 5, the RU (204) of the base station (500) can perform SVD beamforming based on channel information collected for each antenna of the UE (502). To indicate an antenna of the UE (502) associated with the channel information, an identifier of the UE (502) and an identifier indicating a corresponding antenna among the antennas (506) of the UE (502) may be required. Accordingly, to perform SVD beamforming, the RU (204) may need to obtain information from the DU (202) including, together with the channel information, an identifier of the corresponding UE (502) and an identifier of the antennas (506) of the corresponding UE (502). In response to obtaining the information for identifying each antenna of the UE (502) and the channel information, the RU (204) can perform SVD beamforming.

[0105] FIG. 7 illustrates an exemplary flowchart of a method for wireless communication according to one embodiment of the present disclosure.

[0106] Referring to FIG. 7, a method for wireless communication may be performed by DU (202) and RU (204) of FIG. 2. However, the present disclosure is not limited thereto, and steps (702 to 712) may be performed individually or in combination by any electronic device. The method for wireless communication according to an embodiment of the present disclosure is not limited to that illustrated in FIG. 7, and any of the steps illustrated in FIG. 7 may be omitted, or steps not illustrated in FIG. 7 may be further included. In some embodiments, the order of at least some of the steps (702 to 714) may be changed.

[0107] At step (702), the RU (204) may transmit a management plane message to the DU (202) that includes information regarding control plane messages supported by the RU (204). The information regarding the control plane message may include information indicating whether the MMU (408) supports control plane messages of a particular section type including a particular section extension.

[0108] In step (704), the DU (202) can identify whether channel information exists in the DU (202). For example, the DU (202) can identify whether a channel estimation result exists in the DU (202). Based on the presence of the channel estimation result in the DU (202), the DU (202) can identify that channel information exists in the DU (202). The DU (202) can identify whether the DU (202) performed channel estimation and, as a result, a channel matrix H is stored in the memory (304) of the DU (202). Based on the fact that the channel matrix H is stored in the memory (304), the DU (202) can identify that channel information exists in the DU (202).

[0109] In one embodiment, based on the fact that the channel estimation result does not exist in the DU (202) or the channel matrix H is not stored in the memory (304), the DU (202) can identify whether the channel estimation function is assigned to the DU (202) or the RU (204). For example, the DU (202) can identify whether the MMU (408) of the RU (204) is capable of performing channel estimation. Based on the fact that the channel estimation function is assigned to the DU (202), the DU (202) can perform channel estimation, store the result of the channel estimation (e.g., channel information) in the memory (304), and identify that the channel information exists in the DU (202). Based on the fact that the channel estimation function is assigned to the RU (204), the DU (202) can identify that the channel information does not exist in the DU (202).

[0110] In step (706), DU (202) may generate a first control plane message including a field indicating a first UE ID (identifier) ​​and a first section extension field. For example, the first control plane message may be a section type including a field indicating a first UE ID. Information included in the section type and the first section extension field of the first control plane message will be described in detail below.

[0111] In one embodiment, based on identifying that channel information exists within the DU (202), the DU (202) may generate a first control plane message including channel information per UE. In one embodiment, based on identifying that channel information does not exist within the DU (202), the DU (202) may generate a first control plane message including a field instructing the RU (204) to perform a channel estimation operation.

[0112] In step (708), DU (202) transmits a first control plane message to RU (204) via the fronthaul interface. For example, DU (202) may transmit the first control plane message during a transmission window for the control plane. The first control plane message may be transmitted with a period longer than a slot. For example, the transmission period of the first control plane message may be longer than the period of a slot. DU (202) may transmit the first control plane message regardless of the transmission window for the control plane.

[0113] At step (710), RU (204) may perform SVD processing. For example, RU (204) may perform SVD processing described with reference to FIG. 6 using information included in the first control plane message. In one embodiment, the first control plane message may include channel information, and RU (204) may perform SVD processing using the channel information included in the first control plane message. In one embodiment, the first control plane message may request RU (204) to perform channel estimation, and in response to the first control plane message, RU (204) may perform channel estimation and perform SVD processing based on the channel estimation result.

[0114] At step (712), RU (204) can perform beamforming. For example, RU (204) can obtain matrix(s) associated with channel information through step (710). Using the matrix(s) obtained at step (710), RU (204) can perform beamforming. For example, RU (204) can perform SVD-based beamforming (e.g., ZF beamforming) as described with reference to FIG. 6. RU (204) can calculate appropriate beamforming weights for a particular slot based on SVD and / or ZF.

[0115] The SVD beamforming performed based on steps (710, 712) may be included in channel information-based beamforming. The DU (202) may provide per-UE channel information periodically (typically less frequently than every slot) to the RU (204) using a control plane message of a specific section type. The DU (202) may provide scheduling information to the RU (204) using a control plane message of a specific section type on a slot-by-slot basis. The RU (204) may use the scheduling information together with the channel information to compute appropriate beamforming weights for co-scheduled UEs for the corresponding slot (e.g., in the manner described with reference to FIGS. 5 to 7).

[0116] As illustrated in Figure 7, control plane messages are exchanged between the DU and the RU. The primary purpose of control plane messages is to transmit data-associated control information (e.g., scheduling and beamforming commands) required for processing user data. A common frame format, consisting of a transport layer and an application layer, must be used for control plane messages. The transport layer may consist of an eCPRI common header or an IEEE 1914.3 common header containing corresponding fields used to indicate the message type, and the application layer may contain fields required for control and synchronization. Within the application layer, a "section" may define the characteristics of user plane data transferred or received in a beam with a single pattern ID. The application layer is contained within the transport layer payload and consists of a common header for time reference, followed by information and parameters specific to the section type in use. Multiple sets of section data with the same section type value are lined up one after another within the payload. Sets of section data with different section type values ​​must be transmitted in separate control plane messages (i.e., different section type values ​​must not be mixed within a single control plane message payload).

[0117] To define the types of messages transmitted on the control plane, section types are defined. Section types can indicate the purpose of control messages transmitted on the control plane. For example, the purposes of each section type are as described in Table 1.

[0118]

[0119] Below, configurations of section types and configurations of section fields for control messages according to some embodiments of the present disclosure will be described.

[0120] FIG. 8 exemplarily illustrates a configuration of a section type according to one embodiment of the present disclosure.

[0121] Referring to FIG. 8, a control plane message (800) may include a transport header (802), a common header (804) (or wireless application header, timing header), a udCompHdr field (806), and section headers (808, 810). In one embodiment, the control plane message (800) may be a section type 5 control message. For example, the control plane message (800) may convey UE scheduling information.

[0122] The transport header (802) may be included in the Ethernet payload and may describe how application data is processed in the control plane and / or user plane. The transport header (802) is 8 bytes long and provides basic data routing capabilities including a data flow type description, sender and receiver port identifiers, the ability to support concatenation of multiple applications in a single Ethernet packet, and sequence numbering. In one embodiment, when following the O-RAN standard, the transport header (802) may be an eCPRI transport header or an IEEE 1914.3 transport header. The eCPRI header may include at least some of the following parameters:

[0123] - ecpriVersion (4 bits): 0001b (default). This parameter indicates the eCPRI protocol version.

[0124] - ecpriReserved (3 bits): 000b (default). This parameter is reserved for future eCPRI use.

[0125] - ecpriConcatenation (1 bit): 0b (default). This parameter indicates that eCPRI concatenation is in use (allowing multiple eCPRI messages in a single Ethernet payload).

[0126] - ecpriMessage (1 byte): Message type. This parameter indicates the type of service that the message type conveys.

[0127] - ecpriPayload (2 bytes): Payload size in bytes. This parameter is the size in bytes of the payload portion of the corresponding eCPRI message. This does not include any padding following the eCPRI message. The maximum supported payload size is 216-1, but the actual size may be further limited by the underlying transport network.

[0128] - ecpriRtcid / ecpriPcid (Real-time Control Data / IQ Data Transfer Message Series Identifier) ​​(2 bytes): This parameter is the extended Antenna-Carrier Identifier (eAxC ID) and identifies a specific data flow associated with each control plane (ecpriRtcid) or user plane (ecpriPcid) message. This is similar to the "AxC" (antenna-carrier) value in CRPI and is therefore designated here as "eAxC" (the "e" stands for "extended" to accommodate multiple bands and multiple component carriers). Multiple O-DU processors can contribute to a single eAxC.

[0129] - ecpriSeqid (2 bytes): This parameter provides unique message identification and ordering at two different levels. The first octet of this parameter is a sequence ID used to identify message order within the eAxC message stream. The second octet of this parameter is a subsequence ID used to verify order and implement reordering when fragmentation occurs at the radio level (eCPRI or IEEE-1914.3).

[0130] Additionally or alternatively, an IEEE 1914.3 transport header may be used. The IEEE 1914.3 transport header may include at least some of the following parameters:

[0131] - RoEsubType (1 byte): This field indicates the payload type within the range of the Radio over Ethernet Encapsulations and Mappings (RoE) subtypes of the IEEE 1914.3 standard.

[0132] - RoEflowId (1 byte): This is a mechanism to identify a specific flow between endpoints. RoEflowID, 0xFF, is reserved for RoE control packets. In one embodiment, the transport header (802) may not use this field.

[0133] - RoElength (2 bytes): This field is the size in bytes of the payload portion of the message. The Payload Length field value is the total number of octets following the O-RAN common header. This does not include the Ethernet FCS or any subsequent bytes.

[0134] - RoEorderInfo (4 bytes): This field contains order information. For example, this field may include DU_Port_ID (used to differentiate processing units (e.g., different baseband cards) in a DU), BandSector_ID (aggregated cell identifier, differentiating the band and sector supported by the O-RU), CC_ID (differentiating the component carrier supported by the O-RU), RU_Port_ID (used to differentiate spatial streams or beams on the O-RU), Sequence_ID (unique message order sequence), E_Bit (marks the next message associated with a section), and / or Subsequence_ID (unique message order sub-sequence).

[0135] The common header (804) may include at least some of the following fields:

[0136] - dataDirection (data direction (gNB transmit (Tx) / receive (Rx))) field: 1 bit. This parameter indicates the gNB data direction. This parameter, in combination with eAxC_ID, is used to identify which O-RU lower-level endpoint the control plane / user plane message is intended for or originated from.

[0137] - payloadVersion field: 3 bits: Set to 1 (first protocol version for payload and time reference format). This parameter defines the payload protocol version that is valid for subsequent Information Elements (IEs) in the application layer.

[0138] - filterIndex (filter index) field: 4 bits. This parameter defines the index of the channel filter to be used between the IQ data and the radio interface in both DL and UL.

[0139] - frameId (frame identifier) ​​field: 8 bits. This parameter is a counter for 10ms frames (wrapping period 2.56 seconds), specifically, frameId = frame number modulo 256.

[0140] - subframeId (subframe identifier) ​​field: 4 bits. This parameter is a counter for 1ms subframes within a 10ms frame.

[0141] - slotId (slot identifier) ​​field: 6 bits. This parameter is the slot number within a 1ms subframe.

[0142] - startSymbolId (start symbol identifier) ​​field: 6 bits. This parameter identifies the symbol number of the earliest symbol (within the slot) to which the information of the control plane message (800) applies.

[0143] - numberOfsections (number of sections) field: 8 bits. This parameter indicates the number of data section descriptions (separate citations of section ID even for multiple citations of the same sectionId) included in the control plane message (800).

[0144] - sectionType (section type) field: 8 bits: This parameter determines the characteristics of the user plane (control plane) data transmitted or received on a beam with one pattern ID.

[0145] The udCompHdr field (806) may include at least some of the following fields: In one embodiment, the udCompHdr field (806) may be included in the common header (804).

[0146] - udCompHdr (User Data Compression Header) field: 8 bits. The udCompHdr information is provided to the user plane and instructs the O-RU (DL) and O-DU (UL) how to interpret and decompress the user plane data received. For UL user plane data compression, the O-DU must instruct the O-RU via the udCompHdr of the control plane message.

[0147] - Reserved (for future use) field: 8 bits.

[0148] In one embodiment, each of the section headers (808, 810) may include at least some of the following fields. For example, each section header may be composed of any combination of the following fields, and the values ​​of each field may vary from section header to section header.

[0149] - sectionId (section identifier) ​​field: 12 bits. When control plane and user plane coupling via sectionId is used, this parameter identifies an individual data section described by a data section description within a control plane message. The purpose of sectionId is to map a user plane data section to the corresponding control plane message (and section type) associated with the data.

[0150] - rb (resource block identifier) ​​field: 1 bit. This parameter indicates whether all RBs or all other RBs are used.

[0151] - symInc (Symbol Number Increment Command) field: 1 bit. This parameter is used to indicate the symbol number associated with a given section description. As long as symInc is 0, the same value must be used for each section of the message. If symInc is 1, the maintained symbol number must be incremented to the next symbol, and that new symbol number must be used for that section and each subsequent section until the symInc bit is detected to be 1 again.

[0152] - startPrbc (start PRB of data section description) field: 10 bits. This parameter carries the first (lowest frequency) PRB described in the section description.

[0153] - numPrbc (Number of consecutive PRBs per data section description) field: 8 bits. This parameter carries the number of PRBs described by the section description.

[0154] - reMask (Resource Element Mask) field: 12 bits. This parameter defines the resource element (RE) mask within the PRB.

[0155] - numSymbol (number of symbols) field: 4 bits. This parameter defines the number of PRACH symbols in a PRACH situation or the number of PRACH symbols in a NPRACH symbol group in the case of NPRACH to which section control is applicable.

[0156] - ef (Extension Flags) field: 1 bit. This parameter is used to indicate whether any section extensions are included in the message in this section.

[0157] - ueId field: 15 bits. This parameter is used to support channel-information-based beamforming within section type 5.

[0158] In one embodiment, the section header (808 / 810) may include an "extension flag." The presence of the extension flag may indicate that a section extension follows the header. For example, if the field ef of the section header (808) is "1," the section header (808) may be followed by the section extension(s) indicated by "ef."

[0159] FIG. 9 illustrates an example configuration of a section expansion according to one embodiment of the present disclosure.

[0160] Referring to FIG. 9, the section extension field (900) may include at least a portion of ef, extType, extLen, or the second port ueId to the (numPort+1)th port ueId. In one embodiment, the section extension field (900) may correspond to section extension 10 according to the O-RAN standard. For example, the section extension field (900) may include information for grouping multiple ports or multi-UE scheduling information. In one embodiment, the section extension field (900) may be applied to control plane messages of section types 1, 3, and 5, but is not limited thereto. For example, the section extension field (900) may be included in the control plane message (800) of FIG. 8. In one embodiment, the section extension field (900) may include the beamId of each port instead of the ueId of each port.

[0161] ef may indicate the presence of a section extension. extType may indicate the type of the section extension in the section extension field (900). extLen may indicate the length of the section extension (e.g., the length of the section extension field (900)).

[0162] In one embodiment, the section extension field (900) may additionally include beamGroupType and numPortc fields. beamGroupType may indicate the type of beam grouping (e.g., common beam, beam matrix indication, beam vector listing, or beamId / ueId listing with associated port-list index). In one embodiment, the value of beamGroupType may be 10b, but embodiments of the present disclosure are not limited thereto. numPortc indicates the number of eAxC ports indicated by the section extension. In one embodiment, the beamGroupType field may follow the extLen field, and the numPortc field may follow the beamGroupType.

[0163] FIG. 10 exemplarily illustrates a configuration of a section expansion according to one embodiment of the present disclosure.

[0164] Referring to FIG. 10, the section extension field (1000) may include at least a portion of ef, extType, extLen, or numUeID of each user. In one embodiment, the section extension field (1000) may correspond to section extension 17 according to the O-RAN specification. For example, the section extension field (900) may include an indication or information about a user port group. The section extension field (1000) may include information about the number of ueIds of users scheduled in preceding section types and section extension messages. A user may have multiple ueIds (i.e., multiple channel information, for example, if the UE supports the TAS function for SRS transmission, the O-DU may obtain various channel information corresponding to each transmit antenna).

[0165] ef can indicate that a section extension exists. extType can indicate the type of the section extension in the section extension field (1000) (e.g., 0x11 or 17). extLen can indicate the length of the section extension (e.g., the length of the section extension field (10000)). numUeID can indicate the number of ueIds per user.

[0166] In one embodiment, each user's ueId may be sequentially assigned using the three reserved bits of ueId[2:0]. This may imply that the maximum number of ueIds supported per user is eight. Additionally or alternatively, ueIds with all three reserved bits set to 0 in a previous section extension (e.g., section extension 10) may be repeatedly configured as many times as the number of tiers assigned to the user. Thus, the previous section type and extension message may implicitly provide the number of scheduled users (i.e., the number of different ueIds) and the number of tiers for each user (i.e., the number of identical ueIds). Finally, the number of ueIds associated with each user may be provided in the section extension field (1000).

[0167] For example, a 15-bit ueId may include a TAS antenna identifier (or identifier) ​​of the corresponding user and identifiers (or identifiers) for different users. For example, three consecutive Least Significant Bits (LSBs) of the 15-bit ueId, i.e., ueId[2:0], may identify the TAS antenna of the same user. For example, ueId[2:0] may include information about one of the antennas of the terminal of the corresponding user (e.g., the user corresponding to the preceding ueId[14:3]). ueId[14:3] may be used to distinguish different users. For example, different users may have different ueId[14:3] values.

[0168] In one embodiment, the section extension field (1000) may be applied to the section extension field (900) of FIG. 9. For example, the section extension field (1000) may be included in the control plane message (800) of FIG. 8 together with the section extension field (900) of FIG. 9.

[0169] FIG. 11 illustrates an example of timing of downlink control plane data transmission and reception between a DU and a RU according to one embodiment of the present disclosure.

[0170] Referring to FIG. 11, a DU (202) and a RU (204) may communicate using a fronthaul interface (FH). The RU (204) may be connected to an antenna port (1102). The antenna port (1102) may include one or more antenna arrays for the base station (200) to communicate with a user terminal. For example, the antenna port (1102) may be included in a transceiver for communication between the base station (200) and the user terminal. In one embodiment, the antenna port (1102) may be included in an MMU (408) of the RU (204).

[0171] A fronthaul interface (FH) may include a control plane and a user plane. The control plane may need to be available to process corresponding user plane packets. For example, the control plane data (or message) (1106) for symbol #n needs to be forwarded to the RU (204) before processing symbol #n. In the embodiment illustrated in FIG. 11, the reference point ('t dl = 0') may be the transmission of the earliest IQ sample (including CP) in the time domain within a symbol (e.g., symbol #n) generated from IQ data received in a user plane message specific to the symbol identified by symbolId.

[0172] In the downlink, a control plane message containing instructions for downlink radio signal transmission, such as a control plane message of a data flow with dataDirection=1, may be transmitted from a DU (202) to a RU (204) and may reference one or more symbols. The transmission and reception windows of a downlink control plane message referencing multiple symbols may be relative to the start of the earliest symbol referenced by the message. For example, a control plane message (1106) may be transmitted from a DU (202) to a RU (204) during the control plane downlink transmission window (1104). In one embodiment, the control plane message (1106) may be structured in a manner similar to the control plane message (800) of FIG. 8, and may include a section extension field (900) of FIG. 9 and a section extension field (1000) of FIG. 10.

[0173] In the embodiment illustrated in FIG. 11, the control plane downlink transmission window (1104) may correspond to (or be included in) a time interval between t=-T1a_max_cp_dl and t=-T1a_min_cp_dl. T1a_max_cp_dl may be a parameter indicating the start of the control plane downlink transmission window. T1a_min_cp_dl may be a parameter indicating the end of the control plane downlink transmission window. The control plane message (1106) may be received by the RU (204) during the control plane downlink reception window (1108). In the embodiment illustrated in FIG. 11, the control plane downlink reception window (1108) may correspond to (or be included in) a time interval between t=-T2a_max_cp_dl and t=-T2a_min_cp_dl. T2a_max_cp_dl may be a parameter indicating the start of the control plane downlink receive window. T2a_min_cp_dl may be a parameter indicating the end of the control plane downlink receive window.

[0174] Based on the received control plane message (1106), the RU (204) may process information included in a symbol corresponding to the control plane message (1106). The RU (204) may need to process data (e.g., IQ sample) for symbol #n during a predefined period T2a_min_cp_dl. T2a_min_cp_dl may be a parameter indicating a minimum RU data processing delay between receiving a downlink real-time control plane message over the fronthaul interface and transmitting the corresponding first IQ sample from the antenna. The RU (204) may transmit a frame corresponding to symbol #n using the antenna port (1102) at a reference point.

[0175] As described above, in order to transmit a frame corresponding to symbol #n from the reference point using the antenna port (1102), a section-type control plane message to be transmitted for each symbol must be delivered to the RU (204) before the corresponding symbol is processed, and the RU (204) may have to process data for the corresponding symbol during the interval T2a_min_cp_dl. The data processing for symbol #n may include channel information-based beamforming. For example, during the interval T2a_min_cp_dl, the RU (204) may have to complete the SVD processing and SVD-based beamforming described above with reference to FIGS. 5 to 7 based on the information included in the control plane message (1106) (e.g., numUeID of each user and / or ueId of each port) and the channel information. The parameter T2a_min_cp_dl may be several hundred μs (e.g., 250 μs). Therefore, despite the complexity of the SVD operation, SVD-based beamforming should take a short time, which may increase the complexity of the hardware for SVD processing.

[0176] FIG. 12 illustrates an example configuration of a section type according to one embodiment of the present disclosure.

[0177] Referring to FIG. 12, a control plane message (1200) may include a transport header (1202), a common header (1204) (or a wireless application header, a timing header), a numberOfUEs field (1206), and a section header (1208). In one embodiment, the control plane message (1200) may be a control message of section type 6 of the O-RAN standard. For example, the control plane message (1200) may convey channel information (e.g., channel information per ueId).

[0178] The transmission header (1202) may be configured in a similar manner to the transmission header (802) of FIG. 8. The common header (1204) may include dataDirection, payloadVersion, filterIndex, frameId, subframeId, slotID, startSymbolId, numberOfsections, and sectionType. Descriptions of parameters common to the common header (804) of FIG. 8 among the fields of the common header (1204) are omitted.

[0179] The numberOfUEs field (1206) (8 bits) may indicate the number of UE-specific channel information data sets. The numberOfUEs field (1206) may indicate the number of UEs (for which channel information is provided) included in the control plane message (1200). The numberOfUEs field (1206) may additionally include 8-bit reserved fields.

[0180] In one embodiment, a ciCompHdr field may be added following the numberOfUEs field (1204). The ciCompHdr field (8 bits) may correspond to a channel information compression header. The ciCompHdr field may define a compression method and an IQ bit width for the channel information. For example, the ciCompHdr field may include subfields ciIqWidth, ciCompMeth, and ciCompOpt. ciIqWidth may indicate the bit width of each I and each Q. ciCompMeth may indicate a compression method (e.g., no compression, block floating point block scaling, or μ-law method). ciCompOpt may indicate a compression option (e.g., per-UE compression or per-PRB compression).

[0181] The section header (1208) may include at least some of the following fields. Descriptions of fields (parameters) common to the section headers (808, 810) of FIG. 8 are omitted.

[0182] - ef (extended flags) field: 1 bit.

[0183] - ueId field: 15 bits. This parameter supports channel-information-based beamforming (CIBF) by providing a logical identifier for a set of channel information associated with a spatial stream of a UE transmitted via a control plane message (1200).

[0184] - regularizationFactor (regularization factor used for MMSE (Minimum Mean Square Error) reception) field: 16 bits. This parameter provides a signed value to support MMSE operation within an O-RU when beamforming weights are supported in the O-RU.

[0185] - Reserved (reserved for future use) field: 4 bits.

[0186] - rb (resource block identifier) ​​field: 1 bit. For example, the value is set to 0.

[0187] - symInc (symbol number increment command) field: 1 bit.

[0188] - startPrbc (start PRB of data section description) field: 10 bits.

[0189] - numPrbc (Number of consecutive PRBs per data section description) field: 8 bits.

[0190] - ciIsample (channel information value, in-phase sample) field: 1-16 bits.

[0191] - ciQsample (channel information value, quadrature sample) field: 1-16 bits. The ciIsample and ciQsample values ​​are complex channel information values ​​relayed from the DU (202) to the RU (204). In the illustrated embodiment, values ​​for the first Prbc from the first antenna to the last antenna are transmitted, then values ​​for the second Prbc from the first antenna to the last antenna are transmitted, and so on, values ​​for the last Prbc (PRB collection) from the first antenna to the last antenna are transmitted. However, the illustrated embodiment is not limited thereto. For example, these values ​​may be transmitted for each PRB group (e.g., from the first antenna to the last antenna for the first PRB group, and then from the first antenna to the last antenna for the second PRB group). Each PRB group for one antenna includes a ciIsample. ciQsample pair. Padding (set to 0) bits may be inserted after the last Q value (e.g., the last ciQsample value).

[0192] In one embodiment, the section header (1208) may additionally include ciCompParam. ciCompParam is a channel information compression parameter, which may be 0 or 8 bits. This parameter applies to the compression method specified by the associated ciCompMeth value. If ciCompOpt (a sub-field of ciCompHdr) is 0, this parameter applies to the next vector of ciIsample, ciQsample for all PRBs of a specific UE. If ciCompOpt (a sub-field of ciCompHdr) is 1, this parameter applies to the next vector of ciIsample, ciQsample for all antennas of a specific PRB. In one embodiment, the section header (1208) may additionally include ciCompParam for the first PRB or all PRBs of the UE. ciCompParam may be inserted between numPrbc and the first ciIsample value.

[0193] In one embodiment, the control plane message (1200) may additionally include one or more repeating section headers of a similar structure to the section header (1208). For example, the control plane message (1200) may include a plurality of section headers indicating channel information of a plurality of UEs (or a plurality of ueIds). Each section header may include a ueId and channel information values ​​(e.g., pair(s) of ciIsample and ciQsample) of a corresponding UE (or corresponding ueId).

[0194] The configuration of the control plane message (1200) illustrated in FIG. 12 is merely an example, and the configuration of the control plane message (1200) is not limited to the configuration illustrated in FIG. 12. In one embodiment, some configurations of the control plane message (1200) of FIG. 12 may be added, deleted, or changed.

[0195] FIG. 13 exemplarily illustrates a configuration of a section type including a section extension according to one embodiment of the present disclosure.

[0196] Referring to FIG. 13, a control plane message (1300) may include a transport header (1302), a timing header (1304), a numberOfUEs field (1306), a section header (1308), and a section extension field (1310). In one embodiment, the control plane message (1300) may be a control message of section type 6 of the O-RAN specification, and the section extension field (1310) may be a section extension field of section extension 17 of the O-RAN specification. In other words, a control plane message of section type 6 may include section extension 17. For example, the control plane message (1300) may include information about the number of ueIds of users along with channel information (e.g., channel information per ueId). Accordingly, based on the control plane message (1300), the RU (204) can identify that the UE (502) supports TAS and can identify the number of antennas used for TAS.

[0197] In one embodiment, the RU (204) may report its capability to support section extension 17 within section type 6 to the DU (202) via a management plane message. The DU (202) may identify that the RU (204) supports the control plane message (1300) based on the management plane message from the RU (204). The DU (202) may identify whether there is channel information within the DU (202). Based on identifying that the RU (204) supports the control plane message (1300) and identifying that there is channel information within the DU (202), the DU (202) may generate a control plane message (1300) that includes a section header (1308) including a ueId and a section extension field (1310) including a numUeID.

[0198] The transmission header (1302) may be configured in a similar manner to the transmission header (1202) of FIG. 12. The timing header (1304) may be configured in a similar manner to the common header (1204) of FIG. 12. The numberOfUEs field (1306) may be configured in a similar manner to the numberOfUEs field (1206) of FIG. 12. The section header (1308) may be configured in a similar manner to the section header (1208) of FIG. 12. For example, the section header (1308) may include at least some of the fields (parameters) included in the section header (1208). The 'channel information' included in the section header (1308) may include channel information corresponding to ueId[14:0] of the section header (1308). Descriptions of common fields (or parameters) between the control plane message (1300) and the control plane message (1200) are omitted.

[0199] In Fig. 13, the section header (1308) may include a ueId field (1312). As described above with reference to Fig. 10, three consecutive Least Significant Bits (LSBs) of the 15-bit ueId, i.e., ueId[2:0], may identify the TAS antenna of the same user. The remaining bits, i.e., ueId[14:3], may be used to distinguish different users. For example, ueId[2:0] of the ueId field (1312) may indicate one of the user's antennas. ueId[14:3] may indicate the user associated with the section header (1308).

[0200] The control plane message (1300) of FIG. 13 may include a section extension field (1310). The section extension field (1310) may be configured in a similar manner to the section extension field (1000) of FIG. 10. For example, the section extension field (1310) may include an ef field indicating that a section extension exists, an extType field indicating that the section extension type is 17, an extLen field indicating the length of the section extension field (1310), and a field indicating the numUeID of a user scheduled in a previous section header (1308) of the section extension field (1310), i.e., a user corresponding to ueId[14:3].

[0201] As described above with reference to FIGS. 5 and 6, in order to transmit a signal to the UE (502), the RU (204) of the base station (200) can perform SVD beamforming using channel information associated with each antenna of the UE (502). For example, the RU (204) can perform SVD processing (operation) based on at least some of the ueId of section type 6, the channel information of section type 6, and the numUeID of section extension 17. In response to receiving the control plane message (1300), the RU (204) can initiate SVD processing based on the control plane message (1300). For example, the RU (204) can identify the number of channel information for each user based on the numUeID, and can identify antenna-specific channel information for the corresponding user based on the ueId. The RU (204) can perform SVD processing based on the antenna-specific channel information.

[0202] A control plane message of section type 6 (e.g., control plane message 1200 or control plane message 1300) may be a non-delay managed control plane message. For example, a DU (202) may transmit a control plane message of section type 6 containing per-UE channel information to an RU (204) with a periodicity equal to or longer than a slot. Transmit / receive window constraints may not apply to a control plane message of section type 6. For example, a control plane message of section type 6 may be transmitted / received regardless of a transmit / receive window for the control plane (e.g., windows 1104, 1108 of FIG. 11). A control plane message of section type 6 is not transmitted symbol-by-symbol or slot-by-slot. For example, a control plane message of section type 6 may be transmitted with a periodicity equal to or longer than a slot. Therefore, the processing delay allowed for RU (204) to perform beamforming based on the information contained in the control plane message of section type 6 with section extension 17 may be several ms. This is in contrast to the processing delay for beamforming based on the control plane message of section type 5 with section extension 17, which is several hundred μs, as described above with reference to FIG. 11. Consequently, RU (204) can secure a longer time for SVD processing, and thus the complexity of the hardware implementation for SVD processing within RU (204) can be reduced.

[0203] In one embodiment, a section extension field (1310) may be added for every ueId[2:0]. For example, in a control plane message of section type 6, each section header may include section extension 17, regardless of ueId[2:0] in the section header. Therefore, for each user, the control plane message of section type 6 may include as many section extension 17 fields as the number of ueIds of each user. Tables 2 to 4 below illustrate the ueId values ​​of the section header and the numUeID values ​​of the section extension 17 field in the section type 6 control plane messages for user 0, user 1, and user 2, respectively. The ueIds described in Tables 2 to 4 may indicate the values ​​of ueID[4:0] of each user.

[0204]

[0205] Referring to Table 2, ueId[2:0] of user 0 can be any one of the values ​​000 to 111. Each of the eight ueId[2:0] values ​​can correspond to any one of the antennas of user 0, and thus, based on ueId[2:0] of user 0, the antennas of user 0 can be identified. Since the ueIDs in Table 2 are for user 0, the values ​​of ueId[4:3] are the same. In Table 2, regardless of the value of ueId[2:0], the section header for each ueId can be followed by section extension 17. Since user 0 has eight ueIds, section extension 17 for each section header can contain a numUeID with a value of 8.

[0206]

[0207] Referring to Table 3, ueId[2:0] of User 1 can be any one of the values ​​000 to 011. Each of the four ueId[2:0] values ​​can correspond to any one of the antennas of User 1, and thus, based on ueId[2:0] of User 1, the antennas of User 1 can be identified. Since the ueIDs in Table 3 are for User 1, the values ​​of ueId[4:3] are the same. In Table 3, regardless of the values ​​of ueId[2:0], the section header for each ueId can be followed by section extension 17. Since User 1 has four ueIds, section extension 17 for each section header can contain a numUeID with a value of 4.

[0208]

[0209] Referring to Table 4, ueId[2:0] of User 2 can be 000 or 001. Each of the two ueId[2:0] values ​​can correspond to one of the antennas of User 2, and therefore, based on ueId[2:0] of User 2, the antennas of User 2 can be identified. Since the ueIDs in Table 4 are for User 2, the values ​​of ueId[4:3] are the same. In Table 4, regardless of the value of ueId[2:0], the section header for each ueId can be followed by section extension 17. Since User 2 has two ueIds, section extension 17 for each section header can contain a numUeID with value 2.

[0210] In one embodiment, the section extension field (1310) may be added only for one or more specific ueId[2:0]. Based on the ueId[2:0] value included in the section header of each section type 6, the session extension 17 may be added only for some section headers of section type 6. For example, in a control plane message of section type 6, the section extension 17 may be added only for the section header(s) in which the value of ueId[2:0] is one or more specific values. For example, the section extension 17 may be added only for the section headers with ueId[2:0]=0. Accordingly, when a section type 6 command is invoked more than once to carry channel information for a user (e.g., one or more channel information), the number of ueIds may be provided only once when ueId[2:0] is 0, and the DU (202) may append section extension 17 with the first section description in the section type 6 command for the user. Tables 5 to 7 below illustrate ueId values ​​in the section header and numUeID values ​​in the section extension 17 field in the section type 6 control plane messages for user 0, user 1, and user 2, respectively. The ueIds described in Tables 5 to 7 may indicate the values ​​of ueID[4:0] of each user.

[0211]

[0212] Referring to Table 5, ueId[2:0] of user 0 can be any of the values ​​000 to 111. In contrast to Table 2, in Table 5, section extension 17 may only follow the section header of section type 6 containing ueId[2:0]=0 (i.e., ueId=01000b). Section extension 17 may not be added to the remaining section headers of section type 6 associated with user 0.

[0213]

[0214] Referring to Table 6, ueId[2:0] of User 1 can be any of the values ​​000 to 011. In contrast to Table 3, in Table 6, section extension 17 may be followed only by the section header of section type 6 containing ueId[2:0]=0 (i.e., ueId=10000b). Section extension 17 may not be added to the remaining section headers of section type 6 associated with User 1.

[0215]

[0216] Referring to Table 7, ueId[2:0] of User 2 can be any of the values ​​000 to 001. In contrast to Table 4, in Table 7, section extension 17 may only follow the section header of section type 6 containing ueId[2:0]=0 (i.e., ueId=01000b). Section extension 17 may not be added to the section headers of the remaining section types 6 associated with User 2.

[0217] Additionally or alternatively, section extension 17 may be added only for section header(s) where the value of ueId[2:0] is even, odd, multiple of a specific natural number, prime number and / or numUeID divided by 2 (or rounded up / rounded down / truncated). However, embodiments of the present disclosure are not limited thereto.

[0218] FIG. 14 illustrates an example configuration of a section type according to one embodiment of the present disclosure.

[0219] Referring to FIG. 14, a control plane message (1400) may include a transport header (1402), a common header (1404) (or a wireless application header, a timing header), a udCompHdr field (1406), and a section header (1408). In the illustrated embodiment, the section type of the control plane message (1400) may be 'X' (where 'X' is a natural number). Hereinafter, the control plane message (1400) may be referred to as a 'control plane message of section type X' or a 'section type X control plane message'. The section header (1408) may be referred to as a 'section header of section type X' or a 'section header of section type X'.

[0220] In one embodiment, the control plane message (1400) may be a ueId-specific control plane message that instructs the RU (204) to perform a channel estimation operation. For example, the control plane message (1400) may include information that directly or indirectly commands (or instructs, requests) to perform channel estimation. In some embodiments, the channel estimation function may be assigned to the RU (204) rather than the DU (202), and thus the DU (202) may command the RU (204) to perform channel estimation via the control plane message (1400). In response to the control plane message (1400), the MMU (408) of the RU (204) may perform channel estimation and, based on the acquired channel information, perform SVD beamforming. In one embodiment, the control plane message (1400) may be transmitted from the DU (202) to the RU (204) according to an SRS cycle.

[0221] The transmission header (1402) may be configured in a similar manner to the transmission header (802) of FIG. 8. The common header (1404) may be configured in a similar manner to the common header (804) of FIG. 8. Descriptions of parameters common to the common header (804) of FIG. 8 among the fields of the common header (1404) are omitted. The udCompHdr field (1406) may be configured in a similar manner to the udCompHdr field (806) of FIG. 8. Descriptions of parameters common to the udCompHdr field (806) of FIG. 8 among the udCompHdr field (1406) are omitted.

[0222] The section header (1408) may include at least some of the following fields. Descriptions of fields (parameters) common to the section headers (808, 810) of FIG. 8 or fields (parameters) common to the section header (1208) of FIG. 12 are omitted.

[0223] - sectionId (section identifier) ​​field: 12 bits.

[0224] - rb (resource block identifier) ​​field: 1 bit.

[0225] - symInc (symbol number increment command) field: 1 bit.

[0226] - startPrbc (start PRB of data section description) field: 10 bits.

[0227] - numPrbc (Number of consecutive PRBs per data section description) field: 8 bits.

[0228] - SRS setup information field: 8 bits. The SRS setup information may include information necessary to support SRS-based channel estimation, such as SRS resource configuration (e.g., SRS transmission period, time slot location, or frequency resource), SRS transmission power and beamforming information, UE antenna configuration information, or coding and compression configuration of the SRS signal.

[0229] - ef (extended flags) field: 1 bit.

[0230] - ueId field: 15 bits.

[0231] The configuration of the control plane message (1400) illustrated in FIG. 14 is merely an example, and the configuration of the control plane message (1400) is not limited to the configuration illustrated in FIG. 14. In one embodiment, some configurations of the control plane message (1400) of FIG. 14 may be added, deleted, or changed.

[0232] FIG. 15 illustrates an exemplary configuration of a section type including a section extension according to one embodiment of the present disclosure.

[0233] Referring to FIG. 15, a control plane message (1500) may include a transport header (1502), a timing header (1504), a udCompHdr field (1506), a section header (1508), and a section extension field (1510). In one embodiment, the control plane message (1500) may correspond to the control plane message (1400) of FIG. 14 with the section extension field (1510) added. The section extension field (1510) may be a section extension field of section extension 17 of the O-RAN specification. For example, the control plane message (1500) may include information about the number of ueIds of users along with an instruction for SRS-based channel estimation. Accordingly, based on the control plane message (1500), the RU (204) may identify that the UE (502) supports TAS and may identify the number of antennas used for TAS.

[0234] In one embodiment, the RU (204) may report its capability to support section extension 17 within section type X to the DU (202) via a management plane message. The DU (202) may identify that the RU (204) supports the control plane message (1500) based on the management plane message from the RU (204). The DU (202) may identify whether channel information is present within the DU (202). Based on identifying that the RU (204) supports the control plane message (1500) and identifying that channel information is not present within the DU (202), the DU (202) may generate a control plane message (1500) that includes a section header (1508) including a ueId and a section extension field (1510) including a numUeID.

[0235] The transmission header (1502) may be configured in a similar manner to the transmission header (1402) of FIG. 14. The timing header (1504) may be configured in a similar manner to the common header (1404) of FIG. 14. The udCompHdr field (1506) may be configured in a similar manner to the udCompHdr field (1406) of FIG. 14. The section header (1508) may be configured in a similar manner to the section header (1408) of FIG. 14. For example, the section header (1508) may include at least some of the fields (parameters) included in the section header (1408). The 'SRS configuration information' included in the section header (1508) may include SRS configuration information corresponding to ueId[14:0] of the section header (1508). Description of common fields (or parameters) between the control plane message (1500) and the control plane message (1400) is omitted.

[0236] In Fig. 15, the section header (1508) may include a ueId field. As described above with reference to Figs. 10 and 13, three consecutive Least Significant Bits (LSBs) of the 15-bit ueId, i.e., ueId[2:0], may identify the TAS antenna of the same user. The remaining bits, i.e., ueId[14:3], may be used to distinguish different users. For example, ueId[2:0] of the ueId field may indicate one of the user's antennas. ueId[14:3] may indicate the user associated with the section header (1508).

[0237] The control plane message (1500) of FIG. 15 may include a section extension field (1510). The section extension field (1510) may be configured in a similar manner to the section extension field (1000) of FIG. 10 or the section extension field (1310) of FIG. 13. The section extension field (1510) may correspond to section extension 17. For example, the section extension field (1510) may include an ef field indicating that a section extension exists, an extType field indicating that the section extension type is 17, an extLen field indicating the length of the section extension field (1510), and a field indicating the numUeID of a user scheduled in a previous section header (1508) of the section extension field (1510), i.e., a user corresponding to ueId[14:3].

[0238] As described above with reference to FIGS. 5 and 6, in order to transmit a signal to the UE (502), the RU (204) of the base station (200) can perform SVD beamforming using channel information associated with each antenna of the UE (502). In response to receiving the control plane message (1500), the RU (204) can initiate SVD processing based on the control plane message (1500). For example, the RU (204) can identify the number of channel information for each user based on the numUeID of the section extension field (1510), identify antenna-specific channel information for the corresponding user based on the ueId of the section header (1508), and perform SRS-based channel estimation for each antenna of the UE (502) based on the SRS configuration information of the section header (1508). The RU (204) can then perform SVD processing based on the antenna-specific channel information. In one embodiment, at least some of the SRS-based channel estimation or SVD processing may be performed by the MMU (408) of the RU (204).

[0239] A control plane message of section type X (e.g., control plane message (1400) or control plane message (1500)) can be transmitted to the RU (204) with a period that is equal to or longer than a slot. For example, the control plane message of section type X can be transmitted to the RU (204) according to the SRS period. The transmission period of the control plane message of section type X can be aligned with the SRS period. The control plane message of section type X can be transmitted / received regardless of the transmission / reception window for the control plane (e.g., windows (1104, 1108) of FIG. 11). Therefore, the control plane message of section type X with section extension 17 can be transmitted to the RU (204) with a period (or interval) of several ms. Therefore, the processing delay allowed for RU (204) to perform channel estimation and beamforming based on the information included in the control plane message of section type X with section extension 17 may be several ms. This is in contrast to the processing delay for beamforming based on the control plane message of section type 5 with section extension 17, which is several hundred μs as described above with reference to FIG. 11. As a result, RU (204) can secure a longer time for SVD processing, and thus, the complexity of hardware implementation for SVD processing within RU (204) can be reduced.

[0240] In one embodiment, a section extension field (1510) may be added for all ueId[2:0] as described above with reference to Tables 2 to 4. For example, in a control plane message of section type X, each section header may include section extension 17, regardless of ueId[2:0] in the section header. Therefore, for each user, the control plane message of section type X may include as many section extension 17 fields as the number of ueIds of each user. Tables 8 to 10 below illustrate ueId values ​​of section headers and numUeID values ​​of section extension 17 fields in section type X control plane messages for user 0, user 1, and user 2, respectively. The ueIds described in Tables 8 to 10 may indicate the values ​​of ueID[4:0] of each user.

[0241]

[0242] Referring to Table 8, ueId[2:0] of user 0 can be any one of the values ​​000 to 111. Each of the eight ueId[2:0] values ​​can correspond to any one of the antennas of user 0, and thus, based on ueId[2:0] of user 0, the antennas of user 0 can be identified. Since the ueIDs in Table 8 are for user 0, the values ​​of ueId[4:3] are the same. In Table 8, regardless of the value of ueId[2:0], the section header for each ueId can be followed by section extension 17. Since user 0 has eight ueIds, section extension 17 for each section header can include a numUeID of value 8.

[0243]

[0244] Referring to Table 9, ueId[2:0] of User 1 can be any one of the values ​​000 to 011. Each of the four ueId[2:0] values ​​can correspond to any one of the antennas of User 1, and thus, based on ueId[2:0] of User 1, the antennas of User 1 can be identified. Since the ueIDs in Table 9 are for User 1, the values ​​of ueId[4:3] are the same. In Table 9, regardless of the value of ueId[2:0], the section header for each ueId can be followed by section extension 17. Since User 1 has four ueIds, section extension 17 for each section header can contain numUeID with value 4.

[0245]

[0246] Referring to Table 10, ueId[2:0] of User 2 can be 000 or 001. Each of the two ueId[2:0] values ​​can correspond to one of User 2's antennas, and therefore, based on User 2's ueId[2:0], User 2's antennas can be identified. Since the ueIDs in Table 10 are for User 2, the values ​​of ueId[4:3] are the same. In Table 10, regardless of the ueId[2:0] value, the section header for each ueId can be followed by section extension 17. Since User 2 has two ueIds, section extension 17 for each section header can contain numUeID with value 2.

[0247] In one embodiment, a section extension field (1510) may be added only for one or more specific ueId[2:0]. Based on the ueId[2:0] value included in the section header of each section type X control plane message, the section extension 17 may be added only for headers of some section types X. For example, in a control plane message of section type X, the section extension 17 may be added only for section header(s) in which the value of ueId[2:0] is one or more specific values. For example, the section extension 17 may be added only for section headers with ueId[2:0]=0. Additionally or alternatively, section extension 17 may be added only for section header(s) whose ueId[2:0] value is even, odd, multiple of a specific natural number, prime number and / or numUeID divided by 2 (or rounded up / rounded down / truncated). However, embodiments of the present disclosure are not limited thereto. Tables 11 to 13 below illustrate ueId values ​​of section headers and numUeID values ​​of section extension 17 field in control plane messages of section type X for user 0, user 1, and user 2, respectively. The ueId described in Tables 11 to 13 may indicate the value of ueID[4:0] of each user.

[0248]

[0249] Referring to Table 11, ueId[2:0] of user 0 can be any of the values ​​000 to 111. In contrast to Table 8, in Table 11, section extension 17 may only follow the section header of section type X that contains ueId[2:0]=0 (i.e., ueId=01000b). Section extension 17 may not be added to the remaining section headers of section type X associated with user 0.

[0250]

[0251] Referring to Table 12, ueId[2:0] of User 1 can be any of the values ​​000 to 011. In contrast to Table 9, in Table 12, section extension 17 may be followed only by the section header of section type X containing ueId[2:0]=0 (i.e., ueId=10000b). Section extension 17 may not be added for the remaining section headers of section type X associated with User 1.

[0252]

[0253] Referring to Table 13, ueId[2:0] of User 2 can be any of the values ​​000 to 001. In contrast to Table 10, in Table 13, section extension 17 may be followed only by the section header of section type X containing ueId[2:0]=0 (i.e., ueId=01000b). Section extension 17 may not be added for the remaining section headers of section type X associated with User 2.

[0254] Referring to FIGS. 13 and 15, an embodiment in which section extension 17 is added to a control plane message of section type 6 or section type X is described, but embodiments of the present disclosure are not limited thereto. In one embodiment, section extension 17 may be added to a control plane message including a field indicating ueId among non-delay-managed control plane messages (e.g., control plane messages that do not need to be transmitted per slot or control plane messages that are transmitted and received regardless of the control plane transmission and reception window) as well as section type 6 or section type X. Prior to, concurrently with, or subsequent to such a control plane message, the RU (204) may acquire channel information for each antenna of the terminal based on the control plane message of section type 6 or the control plane message of section type X, and may perform SVD-based beamforming based on the aforementioned control plane message and channel information.

[0255] FIG. 16 illustrates an exemplary flowchart of a method for wireless communication performed by a DU according to one embodiment of the present disclosure.

[0256] Referring to FIG. 16, a method (1600) performed by DU (202) may include steps (1602, 1604, 1606). However, the present disclosure is not limited thereto, and steps (1602 to 1606) may be performed individually or in combination by any electronic device. A method according to an embodiment of the present disclosure is not limited to what is illustrated in FIG. 16, and any of the steps illustrated in FIG. 16 may be omitted, or steps not illustrated in FIG. 16 may be further included. In some embodiments, the order of at least some of the steps (1602, 1604, 1606) may be changed.

[0257] At step (1602), the DU (202) may receive a management plane message from the RU (204) that includes information regarding a control plane message supported by the RU (204). At step (1604), the DU (202) may generate a first control plane message based on the management plane message, the first control plane message including a field indicating a first UE ID and a first section extension field. The first section extension field may include a parameter indicating the number of UE IDs of a user associated with the first UE ID. At step (1606), the DU (202) may transmit the first control plane message to the RU (204) via the fronthaul interface.

[0258] Additionally or alternatively, the first control plane message may be a message that is transmitted regardless of the transmit / receive window for the control plane. The first control plane message may not be a message that is transmitted symbol-by-symbol or slot-by-slot. The transmission period of the first control plane message may be longer than the transmission period of a symbol or the transmission period of a slot. The first control plane message may be transmitted at a period that is equal to or longer than the transmission period of a slot. The first control plane message may be transmitted according to the SRS period (e.g., at a period that is the same as the SRS transmission period).

[0259] Additionally or alternatively, the management plane message may indicate that the RU (204) supports a control plane message including a first section extension field with either UE-specific channel information or information requesting a channel estimation operation to the RU (204). For example, the management plane message may indicate that the RU (204) supports a section extension 6 type control plane message including a section extension 17 field (e.g., control plane message 1300 of FIG. 13). The management plane message may indicate that the RU (204) supports a section extension X type control plane message including a section extension 17 field (e.g., control plane message 1500 of FIG. 15).

[0260] Additionally or alternatively, the first control plane message may further include a field indicating channel information corresponding to the first UE ID. For example, the first control plane message may include a field indicating a specific ueId and a field indicating channel information corresponding to the specific ueId.

[0261] Additionally or alternatively, the first control plane message may further include a channel estimation operation command to the RU (204). For example, the first control plane message may include information commanding (or instructing, requesting) the RU (204) to perform channel estimation. The first control plane message may include information necessary to perform channel estimation. For example, the first control plane message may include SRS information to support SRS-based channel estimation.

[0262] Additionally or alternatively, the method (1600) may include transmitting, to the RU (204), a second control plane message, via the fronthaul interface, comprising a second UE ID of a user of the first UE ID and a second section extension field. The second section extension field may include a parameter indicating a number of UE IDs corresponding to users associated with the first UE ID. For example, the first UE ID and the second UE ID may be associated with the same user, and thus the second section extension field may have the same value as the first section extension field.

[0263] Additionally or alternatively, the method (1600) may include transmitting, to the RU (204), via the fronthaul interface, a second control plane message including a second UE ID of a user associated with the first UE ID. A field indicating the first UE ID of the first control plane message may include Least Significant Bits (LSBs) consisting of three consecutive 0s. For example, the first control plane message may include a ueId field with ueId[2:0]=0. The second control plane message may not include a section extension field including a parameter indicating the number of UE IDs.

[0264] In one embodiment, one or more instructions stored in the memory (304) of the DU (202) may, when individually or in combination, be executed by the processor (302) to cause the DU (202) to perform any combination of the operations of the DU (202) described above.

[0265] FIG. 17 exemplarily illustrates a flowchart of a method for wireless communication performed by an RU according to one embodiment of the present disclosure.

[0266] Referring to FIG. 17, a method (1700) performed by RU (204) may include steps (1702, 1704). However, the present disclosure is not limited thereto, and steps (1702, 1704) may be performed individually or in combination by any electronic device. A method according to an embodiment of the present disclosure is not limited to what is illustrated in FIG. 17, and any of the steps illustrated in FIG. 17 may be omitted, or steps not illustrated in FIG. 17 may be further included. In some embodiments, the order of at least some of steps (1702, 1704) may be changed.

[0267] At step (1702), the RU (204) may transmit a management plane message to the DU (202) that includes information regarding control plane messages supported by the RU (204). At step (1704), the RU (204) may receive a first control plane message from the DU (202) via the fronthaul interface. The first control plane message may include a field indicating a first UE ID and a first section extension field. The first section extension field may include a parameter indicating the number of UE IDs of users associated with the first UE ID.

[0268] Additionally or alternatively, the method (1700) may further include a step of performing SVD processing based on the first control plane message. For example, the RU (204) may further perform at least some of steps (710, 712) of FIG. 7 based on the first control plane message. In one embodiment, the RU (204) may estimate one or more characteristics of a channel for each antenna of the terminal based on the number of UE IDs indicated by the first control plane message and the corresponding user UE IDs, and perform SVD processing based on the estimation result.

[0269] Additionally or alternatively, the first control plane message may be a message that is transmitted regardless of the receive window for the control plane. The first control plane message may not be a message that is transmitted symbol-by-symbol. The transmission period of the first control plane message may be longer than the transmission period of a symbol. The first control plane message may be transmitted at a period that is equal to or longer than the transmission period of a slot. The first control plane message may be transmitted according to the SRS period (e.g., at a period that is the same as the SRS transmission period).

[0270] Additionally or alternatively, the management plane message may indicate that the RU (204) supports a control plane message including a first section extension field with either UE-specific channel information or information requesting a channel estimation operation to the RU (204). For example, the management plane message may indicate that the RU (204) supports a section extension 6 type control plane message including a section extension 17 field (e.g., control plane message 1300 of FIG. 14). The management plane message may indicate that the RU (204) supports a section extension X type control plane message including a section extension 17 field (e.g., control plane message 1500 of FIG. 15).

[0271] Additionally or alternatively, the first control plane message may further include a field indicating channel information corresponding to the first UE ID. For example, the first control plane message may include a field indicating a specific ueId and a field indicating channel information corresponding to the specific ueId.

[0272] Additionally or alternatively, the first control plane message may further include a channel estimation operation command to the RU (204). For example, the first control plane message may include information commanding (or instructing, requesting) the RU (204) to perform channel estimation. The first control plane message may include information necessary to perform channel estimation. For example, the first control plane message may include SRS information to support SRS-based channel estimation. In response to the first control plane message, the RU (204) may perform channel estimation.

[0273] Additionally or alternatively, the method (1700) may include receiving, from the DU (202), via the fronthaul interface, a second control plane message comprising a second UE ID of a user of the first UE ID and a second section extension field. The second section extension field may include a parameter indicating a number of UE IDs corresponding to users associated with the first UE ID. For example, the first UE ID and the second UE ID may be associated with the same user, and thus the second section extension field may have the same value as the first section extension field.

[0274] Additionally or alternatively, the method (1700) may include receiving, from the DU (202), via the fronthaul interface, a second control plane message including a second UE ID of a user associated with the first UE ID. A field indicating the first UE ID of the first control plane message may include Least Significant Bits (LSBs) consisting of three consecutive 0s. For example, the first control plane message may include a ueId field with ueId[2:0]=0. The second control plane message may not include a section extension field including a parameter indicating the number of UE IDs.

[0275] In one embodiment, one or more instructions stored in the memory (404) of the RU (204) may, when individually or in combination, be executed by the processor (402) to cause the RU (204) to perform any combination of the operations of the RU (204) described above.

[0276] At least some of the methods according to one embodiment of the present disclosure may be implemented in the form of program instructions that can be executed by various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the present disclosure or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program instructions such as ROMs, RAMs, and flash memories. Examples of program instructions include not only machine language codes generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0277] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory storage medium" simply means a tangible device that does not contain signals (e.g., electromagnetic waves). This term does not distinguish between cases where data is permanently stored in the storage medium and cases where data is temporarily stored. For example, a "non-transitory storage medium" may include a buffer in which data is temporarily stored.

[0278] According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable app) may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0279] Although the embodiments described above have been described by way of limited examples and drawings, those skilled in the art will appreciate that various changes and modifications may be made based on the above description. For example, appropriate results may still be achieved if the described techniques are performed in a different order than described, and / or if components such as the described computer system or modules are combined or combined in a different manner than described, or if they are replaced or substituted with other components or equivalents.

Claims

1. A method for wireless communication performed by a DU (Distributed Unit) (202), A step of receiving a management-plane message including information about a control-plane message supported by the RU (Radio Unit) (204); A step of generating a first control plane message including a field indicating a first UE ID (User Equipment Identifier) ​​and a first section extension field based on the above management plane message; and A step of transmitting the first control plane message to the RU via a fronthaul interface, A method wherein the first section extension field includes a parameter indicating the number of UE IDs of a user associated with the first UE ID, and the first control plane message is transmitted at a period longer than a slot.

2. In paragraph 1, A method wherein the first control plane message is transmitted regardless of the transmission window for the control plane.

3. In paragraph 1 or 2, A method according to claim 1, wherein the management plane message indicates that the RU supports a control plane message including the first section extension field together with either UE-specific channel information or information requesting a channel estimation operation to the RU.

4. In any one of paragraphs 1 to 3, A method, wherein the first control plane message further includes a field indicating channel information corresponding to the first UE ID.

5. In any one of paragraphs 1 to 3, A method wherein the first control plane message further includes a channel estimation operation command to the RU.

6. In any one of paragraphs 1 to 5, Further comprising the step of transmitting, through the fronthaul interface to the RU, a second control plane message including a second UE ID of a user associated with the first UE ID and a second section extension field, A method wherein the second section extension field includes a parameter indicating the number of UE IDs corresponding to the user.

7. In any one of paragraphs 1 to 5, Further comprising the step of transmitting, to the RU, a second control plane message including a second UE ID of a user associated with the first UE ID through the fronthaul interface, A method wherein the field indicating the first UE ID includes Least Significant Bits (LSBs) consisting of three consecutive 0s. In a method for wireless communication performed by 8.RU (Radio Unit) (204), A step of transmitting a management-plane message including information about a control-plane message supported by the RU to a DU (Distributed Unit) (202); and A step of receiving a first control plane message from the above DU through a fronthaul interface, The first control plane message includes a field indicating a first UE ID (User Equipment Identifier) ​​and a first section extension field, A method wherein the first section extension field includes a parameter indicating the number of UE IDs of users associated with the first UE ID, and the first control plane message is transmitted at a period longer than a slot.

9. In paragraph 8, A method further comprising the step of performing SVD (Singular Value Decomposition) processing based on the first control plane message.

10. In clause 8 or 9, A method wherein the first control plane message is received regardless of the receive window for the control plane.

11. In any one of paragraphs 8 to 10, A method according to claim 1, wherein the management plane message indicates that the RU supports a control plane message including the first section extension field together with either UE-specific channel information or information requesting a channel estimation operation to the RU.

12. In any one of paragraphs 8 to 11, A method, wherein the first control plane message further includes a field indicating channel information corresponding to the first UE ID.

13. In any one of paragraphs 8 to 11, A method wherein the first control plane message further includes a channel estimation operation command to the RU.

14. In any one of paragraphs 8 to 13, Further comprising the step of receiving, from the DU, a second control plane message including a second UE ID of a user associated with the first UE ID and the second section extension field, through the fronthaul interface; A method wherein the second section extension field includes a parameter indicating the number of UE IDs corresponding to the user.

15. In any one of paragraphs 8 to 13, Further comprising the step of receiving, from the DU, a second control plane message including a second UE ID of a user associated with the first UE ID through the fronthaul interface, A method wherein the field indicating the first UE ID includes Least Significant Bits (LSBs) consisting of three consecutive 0s.

Images