Method of transmitting or receiving a control plane message through a front-haul interface and electronic device performing the same

Abstract

A method for transmitting or receiving control plane messages via a fronthaul interface and an electronic device for performing the method are provided. The method may include the steps of: receiving a management plane message from a radio unit (RU) including information about control plane messages supported by the RU; generating a first control plane message based on the management plane message, including a field indicating a first UE ID and a first segment extension field; and transmitting the first control plane message to the RU via the fronthaul interface. The first segment 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 at a period longer than a time slot.

Description

Technical Field

[0001] This disclosure relates to a method for wireless communication based on a fronthaul interface and an electronic device for performing the method, and more specifically, to a method for transmitting or receiving control plane messages through a fronthaul interface and an electronic device for performing the method. Background Technology

[0002] In related technologies, for base stations providing wireless communication services, the base station's data processing unit or digital unit (or distributed unit (DU)) and radio transceiver unit or radio unit (or remote unit (RU)) are integrated and installed together in the cell site. Due to the increasing number of users and traffic, base stations in these technologies are not suitable for establishing multiple cell sites. To overcome this limitation, base stations have been developed with the following structure: the DU is centrally located in one physical location, and only the RU remains in the cell site where wireless signals are actually exchanged with terminals. In this case, the DU and RU can be connected to each other via optical fiber or coaxial cable. This base station structure is also being standardized in the 3rd Generation Partnership Project (3GPP), and Open Radio Access Network (O-RAN) is being researched as an open network standard suitable for 5G systems.

[0003] O-RAN-based base stations may include O-DUs and O-RUs. O-DUs and O-RUs can communicate with each other via a fronthaul interface. The 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. Summary of the Invention

[0004] Technical solution According to embodiments of this disclosure, a method for wireless communication performed by a distributed unit (DU) may include: receiving a management plane message from a radio unit (RU) including information about control plane messages supported by the RU; generating a first control plane message based on the management plane message, including a field indicating a first user equipment identifier (UE ID) and a first segment extension field; and transmitting the first control plane message to the RU via a fronthaul interface. The first segment 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 time slot.

[0005] According to embodiments of this disclosure, a method of wireless communication performed by an RU may include: sending a management plane message to a DU including information about control plane messages supported by the RU; and receiving a first control plane message from the DU via a fronthaul interface. The first control plane message may include a field indicating a first UE ID and a first segment extension field. The first segment 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 sent at a period longer than a time slot.

[0006] According to embodiments of this disclosure, an electronic device for wireless communication may include: at least one processor including processing circuitry; at least one transceiver configured to transmit or receive signals via a fronthaul interface; and a memory including one or more storage media storing one or more instructions. When executed individually or jointly by the at least one processor, the one or more instructions may cause the electronic device to receive from a RU a management plane message including information about control plane messages supported by the RU; generate a first control plane message based on the management plane message including a field indicating a first UE ID and a first segment extension field; and transmit the first control plane message to the RU via the fronthaul interface. The first segment 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 time slot.

[0007] According to embodiments of this disclosure, an electronic device for wireless communication may include: at least one processor including processing circuitry; at least one transceiver configured to transmit or receive signals via a fronthaul interface; and a memory including one or more storage media storing one or more instructions. When executed individually or jointly by the at least one processor, the one or more instructions may cause the electronic device to transmit a management plane message to a DU including information about control plane messages supported by the RU, and to receive a first control plane message from the DU via the fronthaul interface. The first control plane message may include a field indicating a first UE ID and a first segment extension field. The first segment extension field may include a parameter indicating the number of UE IDs of users associated with the first UE ID. Attached Figure Description

[0008] Figure 1 A wireless communication system according to an embodiment of the present disclosure is shown.

[0009] Figure 2 A block diagram of a base station for an open radio access network according to an embodiment of the present disclosure is shown.

[0010] Figure 3A block diagram of a distributed unit (DU) according to an embodiment of the present disclosure is shown.

[0011] Figure 4 A block diagram of a radio unit (RU) according to an embodiment of the present disclosure is shown.

[0012] Figure 5 Transmit antenna switching (TAS) is shown according to an embodiment of the present disclosure.

[0013] Figure 6 Singular value decomposition (SVD) beamforming according to an embodiment of the present disclosure is illustrated.

[0014] Figure 7 A flowchart illustrating a method for wireless communication according to an embodiment of the present disclosure is shown.

[0015] Figure 8 The configuration of segment types according to embodiments of this disclosure is shown.

[0016] Figure 9 The configuration of segment extension according to an embodiment of the present disclosure is shown.

[0017] Figure 10 The configuration of segment extension according to an embodiment of the present disclosure is shown.

[0018] Figure 11 The timing diagram illustrates the downlink control plane (C plane) data transmission / reception between the DU and RU according to an embodiment of the present disclosure.

[0019] Figure 12 The configuration of segment types according to embodiments of this disclosure is shown.

[0020] Figure 13 The configuration of a segment type including segment extensions is shown according to an embodiment of the present disclosure.

[0021] Figure 14 The configuration of segment types according to embodiments of this disclosure is shown.

[0022] Figure 15 The configuration of a segment type including segment extensions is shown according to an embodiment of the present disclosure.

[0023] Figure 16 A flowchart illustrating a method of wireless communication performed by a DU according to an embodiment of the present disclosure is shown.

[0024] Figure 17 A flowchart illustrating a method of wireless communication performed by a RU according to an embodiment of the present disclosure is shown. Detailed Implementation

[0025] The terminology used herein is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, such terminology may vary depending on the intent of a person skilled in the art, precedent, or new technology in the art. Additionally, in some cases, there may be terms that the applicant may optionally choose, and the meaning of these terms will be described in detail in the relevant sections of this disclosure. Therefore, the terminology used herein should not be construed as simple names, but should be understood based on the meaning of the terms and the overall description of this disclosure.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used herein, singular forms may also include plural forms unless the context clearly indicates otherwise. Unless otherwise defined, all terms used herein (including technical or scientific terms) are to have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. Terms defined in common dictionaries are to be interpreted as having the same meaning as in the context of the related art and are not to be interpreted in an idealized or overly formal sense unless explicitly defined herein. In some cases, even the terms defined herein may not be construed as excluding embodiments of this disclosure.

[0027] In the various embodiments of this disclosure described below, hardware-based methods will be described as examples. However, because the various embodiments of this disclosure include techniques using both hardware and software, software-based methods are not excluded.

[0028] In the following description, terms relating to signals (e.g., message, information, preamble, signal, signaling, sequence, and stream), terms relating to resources (e.g., symbol, time slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth portion (BWP), and timing), terms for operational states (e.g., steps, operations, and procedures), terms relating to data (e.g., packets, user streams, information, bits, symbols, and codewords), terms relating to channels, terms relating to control information (e.g., downlink control information (DCI), media access control element (MAC CE), and radio resource control (RRC) signaling), terms relating to network entities, terms relating to components of apparatus, etc., are merely examples for ease of description. Therefore, this disclosure is not limited to the terms described below, and any other terms with equivalent technical meaning may be used.

[0029] As used herein, the singular form may also include the plural form unless the context clearly indicates otherwise. Unless otherwise defined, all terms used herein (including technical or scientific terms) may have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0030] Throughout this disclosure, when something is referred to as “comprising” an element, it may further include one or more other elements unless otherwise stated. Additionally, as used herein, terms such as “unit” and “module” may refer to a unit that performs at least one function or operation, and these units may be implemented as hardware or software or a combination of hardware and software.

[0031] The phrase “configured as (or set as)” as used herein may be replaced, as appropriate, with phrases such as “suitable for,” “capable of,” “designed for,” “suitable for,” “manufactured as,” or “capable of.” The phrase “configured as (or set as)” may not necessarily mean “specifically designed for” at the hardware level. Rather, in some cases, the phrase “system configured as…” may mean that the system, together with other devices or components, is “capable of….” For example, “processor configured as (or set as) to perform A, B, and C” may refer to a dedicated processor (e.g., an embedded processor) for performing the respective operations, or a general-purpose processor (e.g., a central processing unit (CPU) or application processor) capable of performing the respective operations by executing one or more software programs stored in memory.

[0032] Additionally, when an element is referred to as “connected” or “coupled” to another element herein, unless otherwise stated, the element may be directly connected or coupled to the other element, and may also be connected or coupled to the other element through one or more other intermediate elements.

[0033] Additionally, in this document, the expressions “more than” or “less than” are used to determine whether a particular condition is met or fulfilled; however, this is merely a description used to indicate an example and does not exclude descriptions of “greater than or equal to” or “less than or equal to”. A condition described as “greater than or equal to” may be replaced with “greater than”, a condition described as “less than or equal to” may be replaced with “less than”, and a condition described as “greater than or equal to and less than or equal to” may be replaced with “greater than and less than”.

[0034] Furthermore, although this disclosure describes various embodiments using terms used in some communication standards (e.g., 3GPP, xRAN, and O-RAN), these are merely examples for illustrative purposes. The various embodiments of this disclosure can be readily modified and applied to other communication systems.

[0035] In the following disclosure, for ease of description, terms and names defined in or modified from those in the 3GPP Long Term Evolution (3GPP LTE) or New Radio (NR) standards may be used. However, this disclosure is not limited to the foregoing terms and names, and may similarly be applied to systems according to other standards. In this disclosure, for ease of description, eNB (eNode B) may be used interchangeably with gNB (gNode B). For example, a base station referred to as eNB may also be understood as gNB. In this disclosure, the term "terminal" may refer not only to user equipment (UE), mobile station (MS), mobile phone, narrowband Internet of Things (NB-IoT) device, and sensor, but also to various wireless communication devices.

[0036] Figure 1 A wireless communication system according to an embodiment of the present disclosure is shown.

[0037] Figure 1 Wireless communication systems according to various embodiments of the present disclosure are shown. Figure 1 Base station 102, terminal 104, and terminal 106 are shown as nodes using a wireless channel in a wireless communication system. Although Figure 1 Only one base station is shown, but one or more other base stations that are the same as or similar to base station 102 may also be included.

[0038] Base station 102 may be a network infrastructure that provides radio access to terminals 104 and 106. Base station 102 may be defined as having a coverage area for a specific geographic region based on the distance at which it can transmit signals. Base station 102 may also be referred to as an access point (AP), eNode B (eNB), fifth-generation node (5G node), next-generation node B (gNB), radio point, transmit / receive point (TRP), or any other term with equivalent technical meaning.

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

[0040] In some embodiments, at least one of terminals 104 and 106 can be operated without user intervention. That is, at least one of terminals 104 and 106 can be a device performing machine-type communication (MTC) and can be carried by no user. Each of terminals 104 and 106 may be referred to as user equipment (UE), client equipment (CPE), mobile station, subscriber station, remote terminal, wireless terminal, electronic device, user equipment, or any other term with its equivalent technical meaning.

[0041] Base station 102, terminal 104, and terminal 106 can perform beamforming. The base station and terminal can transmit and receive radio signals in relatively low frequency bands (e.g., NR frequency range 1 (FR1)). Additionally, the base station and terminal can transmit and receive radio signals in relatively high frequency bands (e.g., NR FR2 and millimeter-wave (mmWave) bands (e.g., 28 GHz, 30 GHz, 38 GHz, and 60 GHz)). In some embodiments, base station 102 can communicate with terminal 110 in a frequency range corresponding to FR1. In some embodiments, the base station can communicate with terminal 104 in a frequency range corresponding to FR2. In this case, base station 102, terminal 104, and terminal 106 can perform beamforming to improve channel gain. Here, beamforming can include transmit beamforming and receive beamforming. For example, base station 102, terminal 104, and terminal 106 can also impart directionality to the transmitted or received signals. For this purpose, base station 102 and terminals 104 and 106 can select a serving beam through a beam search or beam management process. After a serving beam is selected, subsequent communication can be performed through resources that have a QCL relationship with the resource that has already sent the serving beam.

[0042] In this document, the term "beam" can refer to the spatial flow of signals in a wireless channel. For example, the beam of an antenna can be a radiation pattern, not limited to the main lobe. A beam can be formed by one or more antennas (or antenna elements), and this forming process can be referred to as beamforming. Beamforming can include analog beamforming and digital beamforming (e.g., precoding). Reference signals transmitted based on beamforming can include, for example, demodulation reference signals (DM-RS), channel state information reference signals (CSI-RS), synchronization signal / physical broadcast channel (SS / PBCH), and sounding reference signals (SRS). Additionally, IEs (such as CSI-RS resources or SRS resources) can be used as the configuration for each reference signal, and this configuration can include information associated with the beam. Information associated with the beam may indicate whether the corresponding configuration (e.g., CSI-RS resource) uses the same spatial domain filter as another configuration (e.g., another CSI-RS resource in the same CSI-RS resource set) or uses a different spatial domain filter, whether it is quasi-co-located with the reference signal (QCL), or what type it is when it is QCL (e.g., QCL type A, B, C, or D).

[0043] When the large-scale characteristics of the channel transmitting symbols on the first antenna port can be inferred from the channel transmitting symbols on the second antenna port, the first and second antenna ports can be evaluated as being in a QCL relationship with each other. For example, the large-scale characteristics may include at least one of delay spread, Doppler spread, Doppler shift, average gain, average delay, and spatial receiver parameters.

[0044] Figure 1 The illustration shows that both the base station and the terminal perform beamforming; however, the various embodiments of this disclosure are not limited thereto. In some embodiments, the terminal may perform beamforming, or the terminal may not perform beamforming. Additionally, the base station may perform beamforming, or the base station may not perform beamforming. That is, 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 related technologies, in communication systems with relatively large cell radii, each base station is equipped with functions including a digital processing unit (or distributed unit (DU)) and a radio frequency (RF) processing unit (or radio unit (RU)). However, with the use of high-frequency bands in fourth-generation (4G) and / or subsequent communication systems (e.g., 5G) and the reduction in cell coverage of base stations, the number of base stations covering a specific area has increased. The installation cost burden for service providers installing base stations has also increased. To minimize the installation cost of base stations, the following structure has been proposed: the DU and RU of the base station are separated from each other, one or more RUs are connected to a DU via a wired network, and one or more geographically distributed RUs are arranged to cover a specific area. In the following text, reference will be made to... Figure 2 The arrangement structure and extended examples of base stations according to various embodiments of the present disclosure are described.

[0046] Figure 2 A block diagram of a base station 200 of an open radio access network according to an embodiment of the present disclosure is shown.

[0047] Reference Figure 2 Base station 200 may include DU 202 and one or more RUs 204 and 206. The logical link between DU 202 and RUs 204 and RUs 206 may be referred to as a fronthaul. For example, a fronthaul may be a logical link connecting DU 202 to RUs 204 and RUs 206. The fronthaul may transmit services from at least one of the control plane (C plane), user plane (U plane), synchronization plane (S plane), or management plane (M plane). In embodiments, the fronthaul may operate via an Fx interface. For example, an interface such as the Enhanced Common Public Radio Interface (eCPRI) or the Ethernet Radio (ROE) interface may be used to operate the fronthaul.

[0048] With the development of communication technology and the increase in mobile data traffic, the bandwidth requirements for fronthaul between digital units and radio units have increased significantly. In arrangements such as centralized / cloud radio access networks (C-RAN), DU202 can be implemented to perform functions related to Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY), while RU 204 and RU 206 can be implemented to perform functions related to the PHY layer in addition to RF functions.

[0049] DU 202 manages the upper-layer functions of a wireless network. For example, DU 202 can perform MAC layer functions and portions of the PHY layer. Here, the PHY layer portions can be performed at a high level within the PHY layer functions and may include, for example, channel coding (or channel decoding), scrambling (or descrambling), modulation (or demodulation), and layer mapping (or layer demapping). In embodiments, when DU 202 conforms to the O-RAN standard, DU 202 may be referred to as an O-DU (O-RANDU). The O-DU can be a logical node carrying the RLC / MAC / high PHY layer based on the separation of lower-layer functions. If necessary, in embodiments of this disclosure, DU 202 may be replaced by a first network entity (e.g., gNB) for a base station.

[0050] RU 204 and RU 206 manage the low-level functions of the wireless network. For example, RU 204 and RU 206 may perform portions of the PHY layer and RF functions. Here, portions of the PHY layer may be functions performed at a level relatively lower than DU 202. For example, portions of the PHY layer may include inverse fast Fourier transform (iFFT) (or fast Fourier transform (FFT)), CP insertion (CP removal), or digital beamforming. RU 204 and RU 206 may be referred to as Access Unit (AU), Access Point (AP), Transmit / Receive Point (TRP), Remote Radio Header (RRH), Radio Unit (RU), or any other term with its equivalent technical meaning. In embodiments, when RU 204 and RU 206 conform to the O-RAN standard, RU 204 and RU 206 may be referred to as O-RU (O-RAN RU). O-RU can be a logical node that carries low-level PHY layer and RF processing based on the separation of low-level functions. Where necessary, in embodiments of this disclosure, RU 204 and RU 206 may be replaced with a second network entity (a plurality of second network entities) for a base station (e.g., gNB). In embodiments, RU 204 and RU 206 may be implemented in a similar manner to each other and may operate in a similar manner.

[0051] Figure 2The base station shown includes DU and RU; however, various embodiments of this disclosure are not limited thereto. In some embodiments, the base station may be implemented in a distributed deployment of centralized units (CUs) configured to perform functions of higher layers of the access network (e.g., Packet Data Convergence Protocol (PDCP) layer or RRC layer) and distributed units (DUs) configured to perform lower-layer functions. A CU may connect to one or more DUs to perform functions at higher layers than the DUs. In embodiments, when the CU conforms to the O-RAN standard, the CU may be referred to as an O-CU (O-RANCU). The O-CU may be a logical node carrying PDCP, RRC, Serving Data Adaptation Protocol (SDAP), and / or other control functions. Various embodiments of this disclosure may be applied to base station arrangements that include CUs or arrangements where DUs are directly connected to the core network without CUs (i.e., CUs and DUs are integrated into a single entity).

[0052] In the illustrated embodiment, DU 202 can be implemented as an O-DU, and RU 204 and RU 206 can be implemented as O-RUs. Paths LLS-C and LLS-U can provide the control plane and user plane respectively through low-level separation (LLS) interfaces. For example, C-plane traffic between DU 202 and RU 204 and RU 206 can be transmitted through the low-level separation control plane (LLS-C) interface. U-plane traffic between DU 202 and RU 204 and RU 206 can be transmitted through the low-level separation user plane (LLS-U) interface. When using low-level (internal PHY-based) functional separation, the LLS interface can be a logical interface between O-DU and O-RU. When using low-level functional separation, the LLS-C interface can be a logical interface between O-DU and O-RU (e.g., for the control plane). When using low-level functional separation, the LLS-U interface can be a logical interface between O-DU and O-RU (e.g., for the user plane).

[0053] With the development of wireless communication technologies (e.g., the introduction of 5G communication systems (or New Radio (NR) communication systems)), the frequency bands used have further increased, and the number of RUs required to be installed has further increased as the cell radius of base stations becomes very small. Furthermore, in 5G communication systems, the amount of data transmitted increases tenfold or more, and the transmission capacity of wired networks transmitted via the fronthaul has increased significantly. Due to these factors, the installation cost of wired networks in 5G communication systems can increase substantially. Therefore, in order to reduce the transmission capacity and installation cost of wired networks, techniques have been proposed to reduce the fronthaul transmission capacity by transferring some functions of the DU's modem to the RU; these techniques can be referred to as "functional separation."

[0054] To alleviate the burden on the DU, consider extending the role of the RU (Remote Executor) from solely managing RF functions to some physical layer functions. In this case, the RU's processing load can increase when performing higher-level functions, thus increasing the transmission bandwidth in the fronthaul, while simultaneously reducing latency constraints due to response processing. However, virtualization gain can decrease, and the RU's size / weight / cost can increase when performing higher-level functions. Considering the trade-offs between these advantages and disadvantages, optimal functional separation may be necessary.

[0055] Regarding the functions in the PHY layer below the MAC layer, in the case of downlink (DL) for transmitting signals to a terminal via a wireless network, the base station may sequentially perform at least some of the following: channel coding / scrambling, modulation, layer mapping, antenna mapping, resource element (RE) mapping, in-phase / quadrature phase (IQ) 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. In the case of uplink (UL) for receiving signals from a terminal via a wireless network, the base station may sequentially perform at least some of the following: 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., precombining), 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 and downlink functions can be defined in various ways based on the trade-offs mentioned above, through discussions among suppliers regarding requirements, standards, etc.

[0056] Embodiments of this disclosure can support various modifications to the functional separation. In embodiments, the RF function and the PHY function can be separated. Therefore, the PHY function may be substantially not implemented in the RU, and this functional separation may be referred to as "Option 8". In embodiments, within the PHY function, the RU may perform iFFT / CP insertion in the DL and FFT / CP removal in the UL, and the DU may perform other PHY functions. This functional separation may be referred to as "Option 7-1". In embodiments, within the PHY function, the RU may perform 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 other PHY functions. This functional separation may be referred to as "Option 7-2x Category A". In embodiments, the RU may also perform digital beamforming in both the DL and UL, and the DU may perform high PHY functions (e.g., other PHY functions) after digital beamforming. For example, within the PHY function, the RU may perform iFFT / CP insertion and digital beamforming in the DL, and may also perform FFT / CP removal and digital beamforming in the UL. This functional separation can be referred to as "Option 7-2x Category B". In an embodiment, the RU can also perform RE mapping (or RE demapping) in both the DL and UL, and the DU can perform high PHY functions after RE mapping (or RE demapping). For example, in PHY functions, the RU can perform iFFT / CP insertion, digital beamforming, and RE mapping in the DL, and can also perform FFT / CP removal, digital beamforming, and RE demapping in the UL. This functional separation can be referred to as "Option 7-2". In an embodiment, the RU can also perform at least some of antenna port mapping, layer mapping, and modulation (or demodulation) in both the DL and UL, and the DU can perform high PHY functions after modulation (or demodulation). For example, in PHY functions, the RU can perform iFFT / CP insertion, digital beamforming, RE mapping, antenna port mapping, layer mapping, and modulation in the DL, and can also perform FFT / CP removal, digital beamforming, RE demapping, channel estimation, layer demapping, and demodulation in the UL. This functional separation can be referred to as "Option 7-3". In an embodiment, the RU can also perform coding / scrambling (or decoding / descrambling) in both the DL and UL, and the DU can perform subsequent high-PHY functions. For example, in PHY functions, the RU can perform iFFT / CP insertion, digital beamforming, RE mapping, antenna port mapping, layer mapping, modulation, and channel coding / scrambling in the DL, and can also perform FFT / CP removal, digital beamforming, RE demapping, channel estimation, layer demapping, demodulation, and decoding / descrambling in the UL. This functional separation can be referred to as "Option 6".

[0057] In this disclosure, high PHY can refer to physical layer processing performed in the DU of the fronthaul interface. For example, high PHY functions may include forward error correction (FEC), encoding / decoding, scrambling / descrambling, and / or modulation / demodulation. Conversely, low PHY can refer to physical layer processing performed in the RU of the fronthaul interface. For example, low PHY functions may include FFT / iFFT, digital beamforming, and / or Physical Random Access Channel (PRACH) extraction and filtering.

[0058] In embodiments, when a large amount of signal processing is anticipated, such as in an FR1 massive MIMO unit (FR1 MMU), functional separation at relatively high levels (e.g., option 7-2x Category B) may be necessary to reduce fronthaul capacity. Additionally, because functional separation at too high a level (e.g., option 7-3) can complicate the control interface, and the RU may include multiple PHY processing blocks, thus burdening the RU implementation, appropriate functional separation may be required depending on the arrangement and implementation of the DU and RU.

[0059] In an embodiment, when precoding of data received from the DU cannot be processed (i.e., when the RU has limited precoding capabilities), option 7-2x Category A or lower functional separation (e.g., option 7-1) may be applied. Conversely, when precoding of data received from the DU can be processed, option 7-2x Category B or high functional separation (e.g., option 7-3) may be applied.

[0060] In embodiments conforming to the O-RAN standard, regarding functional separation, Option 7-2x Category A and Option 7-2x Category B may be supported. Option 7-2x Category A and Option 7-2x Category B can be distinguished based on whether the O-RU can perform precoding operations 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. The O-DU should support Category 7-2x Category B O-RUs for 8 or fewer transport streams. That is, it can be said that the O-DU supports precoding for up to 8 transport streams. When Option 7-2x Category B is applied, the O-DU can send information about the modulation symbols that have undergone layer mapping and beamforming information to the O-RU, and the O-RU can convert the modulation symbols into analog signals by applying beamforming to the modulation signal and transmit the analog signals to the terminal via the antenna.

[0061] The information to be transmitted from the O-DU to the O-RU in Option 7-2x may include at least some of the following: information transmitted on the management plane, information transmitted on the synchronization plane, information transmitted on the control plane, or information transmitted on the user plane. Information transmitted on the management plane may be transmitted as a non-real-time transmission in both the DL and UL directions and may include information for initial setup or reset between the O-DU and O-RU. Information transmitted on the synchronization plane may be transmitted in real-time and may include information for synchronization or timing between the O-DU and O-RU. Information transmitted on the control plane may be transmitted as a real-time transmission in the DL direction and may include information for sending scheduling and / or beamforming commands from the O-DU to the O-RU. Information transmitted on the user plane may be transmitted as a real-time transmission in both the DL and UL directions and may include DL frequency domain IQ data (including synchronization signal blocks (SSBs) and reference signals), UL frequency domain IQ data (including reference signals such as SRSs) and frequency domain IQ data regarding the Physical Random Access Channel (PRACH). The terms "information" or "data" used above may be used interchangeably with the term "message".

[0062] In embodiments of this disclosure, when in DU (e.g., Figure 2 DU 202) and RU (e.g., Figure 2 When messages are sent between RU 202, the eCPRI and O-RAN standards are exemplarily described as fronthaul interfaces. The Ethernet payload of a message may include an eCPRI header, an O-RAN header, and additional fields. Hereinafter, embodiments of this disclosure will be described using the standard terminology of eCPRI or O-RAN; however, in embodiments of this disclosure, any other expressions having equivalent meanings to each term may be used alternatively.

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

[0064] Figure 3 A block diagram of DU 202 according to an embodiment of the present disclosure is shown.

[0065] Reference Figure 3 , Figure 2 The DU 202 may include a processor 302, a memory 304, and a transceiver 306. Figure 3 The configuration of DU202 shown is merely an example, and examples of DUs performing embodiments of this disclosure are not limited to. Figure 3The configuration shown is illustrated. According to embodiments, some configurations may be added, deleted, or modified. In embodiments, DU 202 can be understood as an electronic device performing the functions of a DU.

[0066] Processor 302 can control the overall operation of DU 202. For example, processor 302 can send and receive signals via transceiver 306. Processor 302 can write data to memory 304 and read data written to memory 304. Processor 302 can perform the functions of the protocol stack required by the communication standard. In embodiments, processor 302 may include at least one processor containing processing circuitry. In some embodiments, processor 302 may be configured to generate control messages including segment extension fields. Processor 302 can control transceiver 306 to send the generated control messages to RU 204 and RU 206. Additionally or optionally, processor 302 can control DU 202 to perform at least some operations according to the embodiments described below.

[0067] Alternatively or additionally, processor 302 may execute one or more instructions of a program stored in memory 304. Figure 3 In this disclosure, processor 302 is shown as a single element; however, this disclosure is not limited thereto. In embodiments of this disclosure, processor 302 may include one or more elements. For example, processor 302 may be implemented as a general-purpose processor (such as a central processing unit (CPU), application processor (AP), or digital signal processor (DSP)), a graphics-specific processor (such as a graphics processing unit (GPU) or vision processing unit (VPU)), or an artificial intelligence-specific processor (such as a neural processing unit (NPU)).

[0068] Processor 302 may include various processing circuitry and / or multiple processors. For example, the term "processor" as used in this disclosure, including the claims, may include at least one processor and may additionally or optionally include various processing circuitry. One or more processors may be configured to perform the various functions described in this disclosure individually and / or jointly in a distributed manner. As used herein, "processor," "at least one processor," or "one or more processors" may be configured to perform various functions. However, these terms may cover, but are not limited to, situations where a processor can perform some of the multiple functions and another processor or other processors can perform some of the other multiple functions, and situations where a single processor can perform all the functions. Additionally, at least one processor may include a combination of processors performing various functions of the described functions in a distributed manner. At least one processor may execute program instructions individually or jointly to implement or perform various functions.

[0069] Memory 304 may store instructions, data structures, and program code that can be read by processor 302. For example, memory 304 may store data such as a base program, application program, or configuration information for the operation of DU 202. In embodiments, memory 304 may store instructions that can be executed individually or collectively by processor 302 to cause DU 202 to perform at least some of the operations of DU 202 described below. For example, processor 302 may perform at least some of the operations of DU 202 described in this disclosure by executing one or more instructions or code stored in memory 304.

[0070] The memory 304 may include flash memory, hard disk memory, multimedia card micro memory or card memory, and may include non-volatile memory (including at least one of read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk and optical disk) and / or volatile memory (such as random access memory (RAM) or static random access memory (SRAM)).

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

[0072] Transceiver 306 performs functions for transmitting / receiving signals in a wireless communication environment. For example, transceiver 306 can perform conversion between baseband signals and bit strings according to the system's physical layer standard. For instance, during data transmission, transceiver 306 can generate complex symbols by encoding and modulating the transmitted bit string. Additionally, during data reception, transceiver 306 can recover the received bit string by demodulating and decoding the baseband signal. For example, transceiver 306 can up-convert a baseband signal to an RF band signal and then transmit the RF band signal through an antenna, and can down-convert the RF band signal received through the antenna back to a baseband signal. For example, transceiver 306 may include transmit filters, receive filters, amplifiers, mixers, oscillators, digital-to-analog converters (DACs), and / or analog-to-digital converters (ADCs). Furthermore, transceiver 306 may include multiple transmit and receive paths. Additionally, according to embodiments, transceiver 306 may be connected to a core network or to other nodes (e.g., integrated access backhaul (IAB)).

[0073] Transceiver 306 may include antenna elements. Transceiver 306 may include at least one antenna array, wherein the at least one antenna array includes multiple antenna elements. In terms of hardware, transceiver 306 may include digital and / or analog circuitry (e.g., radio frequency integrated circuits (RFICs)). Here, the digital and / or analog circuitry may be implemented in a single package. Additionally, transceiver 306 may include multiple RF chains. Transceiver 306 may perform beamforming. To impart directionality to signals to be transmitted / received according to settings of processor 302, transceiver 306 may apply beamforming weights to the signals. According to embodiments, transceiver 306 may include a radio frequency (RF) block (or RF unit). Transceiver 306 may transmit synchronization signals, reference signals, system information, messages, control messages, streams, control information, data, etc.

[0074] Transceiver 306 can transmit and receive signals as described above. Therefore, all or part of transceiver 306 may be referred to as a "transmitter," a "receiver," or a "transceiver unit." Additionally, in the following description, "transmission and reception performed via a wireless channel" may be used to mean that the aforementioned processing is performed by transceiver 306.

[0075] Figure 4 A block diagram of RU 204 according to an embodiment of the present disclosure is shown.

[0076] Reference Figure 4 , Figure 2 The DU 204 may include a processor 402, a memory 404, and a transceiver 406. Figure 4 The configuration of RU204 shown is merely an example, and examples of DUs performing embodiments of this disclosure are not limited to. Figure 4 The configuration shown is illustrated. According to embodiments, some configurations may be added, deleted, or modified. In embodiments, RU 204 can be understood as an electronic device performing the functions of an RU.

[0077] Processor 402 can control the overall operation of RU 204. For example, processor 402 can send and receive signals via transceiver 406. Processor 402 can write data to memory 404 and read data written to memory 404. Processor 402 can perform the functions of the protocol stack required by the communication standard. In embodiments, processor 402 may include at least one processor containing processing circuitry. In some embodiments, processor 402 may be configured to receive control messages including a segment extension field. For example, processor 402 can control transceiver 406 to receive control messages from DU 202. Based on the received control messages, processor 402 can control transceiver 406 to perform beamforming. Additionally or optionally, processor 402 can control RU 204 to perform at least some of the operations described below in the embodiments. In embodiments, processor 402 can be configured to... Figure 3 The processor 302 is implemented in a similar manner.

[0078] Memory 404 may store instructions, data structures, and program code that can be read by processor 402. For example, memory 404 may store data such as a basic program, application program, or configuration information for the operation of RU 204. In embodiments, memory 404 may store instructions that can be executed individually or collectively by processor 402 to cause RU 204 to perform at least some of the operations of RU 204 described below. For example, processor 402 may perform at least some of the operations of RU 204 described in this disclosure by executing one or more instructions or code stored in memory 404. In embodiments, memory 404 may be configured with... Figure 3 The memory 304 is implemented in a similar manner.

[0079] Transceiver 406 performs functions for transmitting / receiving signals via a wireless channel. For example, transceiver 406 can up-convert a baseband signal to an RF band signal and then transmit the RF band signal through an antenna, and can down-convert an RF band signal received through the antenna back to a baseband signal. For example, transceiver 406 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), and / or an analog-to-digital converter (ADC).

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

[0081] Transceiver 406 may include a massive MIMO (Multiple-Input Multiple-Output) unit 408. MMU 408 may include at least one antenna array, wherein the at least one antenna array includes multiple antenna elements. MMU 408 may perform beamforming. To impart directionality to a signal to be transmitted / received according to settings of processor 402, MMU 408 may apply beamforming weights to the signal. MMU 408 may transmit data to multiple users (or corresponding devices) simultaneously. In an embodiment, MMU 408 may include a radio frequency (RF) block (or RF unit). In an embodiment, MMU 408 may perform channel estimation for the channel between base station 200 and another device. For example, MMU 408 may estimate the characteristics of the channel between the terminal and base station 200 based on SRS received from the terminal.

[0082] Transceiver 406 can transmit / receive signals. Transceiver 406 can transmit downlink signals. Downlink signals may include synchronization signals (SS), reference signals (RS) (e.g., cell-specific reference signals (CRS), demodulation (DM)-RS), system information (e.g., Master Information Block (MIB), System Information Block (SIB), Residual System Information (RMSI), Other System Information (OSI)), configuration messages, control information, or downlink data. Additionally, transceiver 406 can receive uplink signals. Uplink signals may include random access related signals (e.g., random access preamble (RAP) (or message 1 (Msg1)) or message 3 (Msg3)), reference signals (e.g., SRS or DM-RS), or power clearance reports (PHR).

[0083] Transceiver 406 can transmit and receive signals as described above. Therefore, all or part of transceiver 406 may be referred to as a "transmitter," a "receiver," or a "transceiver unit." Additionally, in the following description, "transmission and reception performed via a wireless channel" may be used to mean that the aforementioned processing is performed by transceiver 406.

[0084] Figure 5 Transmit antenna switching (TAS) is shown according to an embodiment of the present disclosure.

[0085] Reference Figure 5 Base station 500 may include N t One antenna 504, and UE 502 may include N r 506 antennas (of which N) t and N r (It is a natural number). UE 502 can be achieved by using N. r At least some of the antennas 506 transmit signals (e.g., SRS) to the base station 500. For example, the UE 502 may include transmitting circuitry, which includes 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 the signals received from the UE 502.

[0086] When UE 502 sends SRS to base station 500, UE 502 may have difficulty using N simultaneously. r There are 506 antennas. Therefore, in order to transmit SRS, UE 502 can perform TAS operation to N. r Each antenna 506 is switched. According to TAS operation, UE 502 can sequentially connect the transmitting circuit to N. rAntenna 506. For example, UE 502 can transmit SRS to base station 500 using the first antenna, and then transmit SRS to base station 500 using the second antenna. Therefore, UE 502 can transmit SRS N by performing TAS operation. r Second-rate.

[0087] Base station 500 can simultaneously use N t 504 antennas are used to receive SRS. Based on the use of N... t 504 N antennas r One SRS receiver, base station 500 can obtain N r ×N t A channel matrix. For example, base station 500 can estimate one or more characteristics of each of one or more channels between UE 502 and base station 500 based on the received SRS, and obtain the channel matrix as a result.

[0088] The SRS can be transmitted periodically across the entire frequency domain. Base station 500 can receive the SRS and estimate the channel state in a specific frequency resource. Based on the received SRS, 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 (SNR)). By using the periodically transmitted SRS, base station 500 can periodically update the channel state information. Using the obtained channel information, base station 500 can perform beamforming or optimize resource allocation.

[0089] In this embodiment, the channel matrix may be the receiving antenna of base station 500 (e.g., N...). t Antenna 504) and the transmitting antenna of UE 502 (e.g., N) r A channel state information (CSI) matrix between the antennas 506. Base station 500 can use advanced beamforming to mitigate co-channel and inter-user interference. In an embodiment, base station 500 can use singular value decomposition (SVD) beamforming. For example, base station 500 can design a precoding matrix by applying SVD to the estimated channels (e.g., the channel matrix).

[0090] Figure 6 SVD beamforming according to an embodiment of the present disclosure is shown.

[0091] Reference Figure 6 , Figure 5 The 500 base station can apply SVD to N r ×N t Channel matrix. SVD can be the process of factoring a real or complex matrix into individual matrices. SVD can be used to decompose a MIMO channel into independent and parallel sub-channels. (See above for reference.) Figure 5 When UE 502 supports the TAS function for SRS transmission, 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 for beamforming weight calculation. When base station 500 can specify these channel matrices as belonging to UE 502, base station 500 can use advanced beamforming algorithms (e.g., SVD-based beamforming) to mitigate co-channel interference and improve transmission reliability.

[0092] By applying SVD, the channel matrix can be decomposed into N r ×N r An orthogonal matrix U, and an N matrix containing only non-negative diagonal elements. r ×N t Matrix Σ, and N t ×N t Orthogonal matrix V. For example, base station 500 can apply SVD based on Equation 1.

[0093] [Equation 1]

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

[0095] In box 602, base station 500 can preprocess the received signal using matrix U, where matrix U is derived using Equation 1. Base station 500 can preprocess the received signal using the Hermitian matrix U of matrix U. H The received signal is preprocessed. For example, base station 500 can obtain matrix G=U for a given channel matrix H. H H. In an embodiment, when matrix H is decomposed using SVD as in Equation 1, matrix G can be represented as G=U. H H=U H UΣV H =ΣV H Matrix G can represent the effective channel preprocessed in the diagonalized state of the channel matrix. Zero-forcing (ZF) beamforming can be performed in block 608 by using matrix G.

[0096] For example, by applying SVD to the channel matrix H0, the base station 500 can obtain the matrix U0 and its Hermitian matrix corresponding to the channel matrix H0. 604. By applying SVD to the channel matrix H1, the base station 500 can obtain the matrix U1 corresponding to the channel matrix H1 and its Hermitian matrix. 606. In box 602, by using matrices H0, H1, 604 and 606, base station 500 can obtain matrix G as shown in Equation 2. In Equation 2, G0 can be a channel corresponding to channel matrix H0, and G1 can be a channel corresponding to channel matrix H1.

[0097] [Equation 2]

[0098] Subsequently, in box 608, ZF beamforming can be performed based on matrix G. Therefore, the received signal y can be expressed as Equation 3.

[0099] [Equation 3]

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

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

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

[0103] In order to execute Figure 6 SVD beamforming may require prior acquisition of the channel matrix H. For example, to perform SVD beamforming, base station 500 may need to perform channel estimation beforehand. In an embodiment, in Figure 2 In base station 200, channel estimation can be performed in DU 202, and SVD beamforming can be performed in RU 204 / RU 206. Therefore, in order to perform SVD beamforming, DU 202 may need to provide channel information, including the channel matrix H, to RU 204 / RU 206. In this embodiment, in base station 200, channel estimation and SVD beamforming can be performed in RU 204 / RU 206. Therefore, DU 202 may need to send commands to RU 204 / RU 206 to perform channel estimation and SVD beamforming.

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

[0105] Figure 7 A flowchart illustrating a method for wireless communication according to an embodiment of the present disclosure is shown.

[0106] Reference Figure 7 Wireless communication methods can be derived from Figure 2 DU 202 and RU 204 perform this operation. However, this disclosure is not limited thereto, and operations 702 to 712 can be performed individually or jointly by any electronic device. The wireless communication methods according to embodiments of this disclosure are not limited to this. Figure 7 The method shown can be omitted. Figure 7Any operation shown, or may further include Figure 7 Operations not shown. In some embodiments, the order of at least some of operations 702 to 714 may be modified.

[0107] In operation 702, RU 204 may send an M-plane message to DU 202 including information about C-plane messages supported by RU 204. The information about the C-plane messages may include information indicating whether MMU 408 supports C-plane messages that include a specific segment type with a specific segment extension.

[0108] In operation 704, DU 202 can identify whether channel information is present in DU 202. For example, DU 202 can identify whether the channel estimation result is present in DU 202. Based on the channel estimation result in DU 202, DU 202 can identify that the channel information is present in DU 202. DU 202 can identify whether channel estimation has been performed in DU 202 and whether the channel matrix H is stored as a result in the memory 304 of DU 202. Based on the channel matrix H stored in the memory 304, DU 202 can identify that the channel information is present in DU 202.

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

[0110] In operation 706, DU 202 can generate a first C-plane message including a field indicating a first UE identifier (UE ID) and a first segment extension field. For example, the first C-plane message may be a segment type including a field indicating the first UE ID. The segment type of the first C-plane message and the information included in the first segment extension field will be described in detail below.

[0111] In one embodiment, based on the identification that channel information is in DU 202, DU 202 can generate a first C-plane message including channel information for each UE. In another embodiment, based on the identification that channel information is not in DU 202, DU 202 can generate a first C-plane message including fields for instructing RU 204 to perform channel estimation operations.

[0112] During operation 708, DU 202 can send a first C-plane message to RU 204 via the fronthaul interface. For example, DU 202 can send the first C-plane message during a transmission window used for the control plane. The first control plane message can be sent with a period longer than a time slot. For example, the transmission period of the first C-plane message can be longer than the period of a time slot. DU 202 can send the first C-plane message regardless of the transmission window used for the control plane.

[0113] In operation 710, RU 204 can perform SVD processing. For example, by using the information included in the first C-plane message, RU 204 can perform reference... Figure 6 The SVD process is described. In an embodiment, the first C-plane message may include channel information, and RU 204 may perform SVD processing using the channel information included in the first C-plane message. In an embodiment, the first C-plane message may request RU 204 to perform channel estimation, and in response to the first C-plane message, RU 204 may perform channel estimation and perform SVD processing based on the channel estimation result.

[0114] In operation 712, RU 204 can perform beamforming. For example, RU 204 can obtain a matrix (multiple matrices) associated with channel information through operation 710. Using the matrix (multiple matrices) obtained in operation 710, RU 204 can perform beamforming. For example, RU 204 can perform the above-mentioned... Figure 6 The described beamforming is based on SVD (e.g., ZF beamforming). The RU204 can calculate appropriate beamforming weights for a specific time slot based on SVD and / or ZF.

[0115] SVD beamforming performed based on operations 710 and 712 can be included in channel information-based beamforming. DU 202 can periodically (typically less frequently than per slot) provide per-UE channel information to RU 204 using C-plane messages of a specific segment type. DU 202 can provide scheduling information to RU 204 slot-by-slot using C-plane messages of a specific segment type. By using the scheduling information in conjunction with the channel information, RU 204 can calculate appropriate beamforming weights for the coordinated UEs in the corresponding slots (e.g., according to reference). Figures 5 to 7 (Description method).

[0116] like Figure 7As shown, C-plane messages can be exchanged between the DU and RU. The primary purpose of C-plane messages can be to send control information (e.g., scheduling and beamforming commands) associated with the data required for processing user data. A common frame format, including both the transport and application layers, should be used for C-plane messages. The transport layer may include an eCPRI common header or an IEEE 1914.3 common header containing appropriate fields to indicate the message type, and the application layer may include fields required for control and synchronization. In the application layer, a "segment" can define the characteristics of U-plane data transmitted or received in a beam with a mode ID. The application layer may include a common header for time reference in the transport layer payload, followed by specific information and parameters depending on the segment type used. Multiple sets of segment data with the same segment type value can be arranged one after another in the payload. A set of segment data with different segment type values ​​should be sent in a separate C-plane message (i.e., different segment type values ​​should not be mixed in a single C-plane message payload).

[0117] To define the type of message sent on the control plane, segment types can be defined. A segment type can represent the purpose of a control message sent on the control plane. For example, the purpose of each segment type can be as described in Table 1.

[0118] [Table 1]

[0119]

[0120] In the following, the configuration of segment types and segment fields for control messages according to some embodiments of the present disclosure will be described.

[0121] Figure 8 The configuration of segment types according to embodiments of this disclosure is shown.

[0122] Reference Figure 8 The C-plane message 800 may include a transport header 802, a common header 804 (or a radio application header or a timed header), a udCompHdr field 806, and segment headers 808 and 810. In an embodiment, the C-plane message 800 may be a segment type 5 control message. For example, the C-plane message 800 may transmit UE scheduling information.

[0123] 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 may be 8 bytes long and may provide basic data routing capabilities, including a data flow type description, send and receive port identifiers, the ability to cascade multiple applications in a single Ethernet packet, and a sequence number. In embodiments, when conforming to 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.

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

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

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

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

[0128] - 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 padding bytes following the eCPRI message. The maximum supported payload size can be 2^16-1, but the actual size may be further limited by the underlying transport network.

[0129] -ecpriRtcid / ecpriPcid (Real-time Control Data / IQ Data Transmission Message Sequence Identifier) ​​(2 bytes): This parameter is the extended antenna carrier identifier (eAxC ID) and identifies the specific data stream associated with each C-plane (ecpriRtcid) or U-plane (ecpriPcid) message. This is similar to the "AxC" (antenna-carrier) value of CRPI, and is therefore specified here as "eAxC" ("e" stands for "extended" to accommodate multiple frequency bands and multiple component carriers). Multiple O-DU processors can contribute to a single eAxC.

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

[0131] Alternatively or additionally, the IEEE 1914.3 transmission header may be used. The IEEE 1914.3 transmission header may include at least some of the following parameters.

[0132] -RoEsubType (1 byte): This field indicates the payload type within the range of Ethernet Radio Encapsulation and Mapping (RoE) subtypes in the IEEE 1914.3 standard.

[0133] -RoEflowId (1 byte): This is a mechanism used to identify a specific flow between endpoints. RoEflowID and 0xFF are reserved for RoE control packets. In an embodiment, this field may not be used in the transport header 802.

[0134] -RoElength (2 bytes): This field is the size of the message payload in bytes. The payload length field value is the total number of eight bytes following the O-RAN common header. This does not include the Ethernet FCS or subsequent bytes.

[0135] -RoEorderInfo (4 bytes): This field includes sorting information. For example, this field may include DU_Port_ID (used to distinguish processing units in a DU (e.g., different baseband cards)), BandSector_ID (aggregate cell identifier, distinguishing the frequency bands and sectors supported by the O-RU), CC_ID (distinguishing the component carriers supported by the O-RU), RU_Port_ID (used to distinguish the spatial stream or beam on the O-RU), Sequence_ID (unique message sequence), E_Bit (marking the last message associated with the segment), and / or Subsequence_ID (unique message sequence subsequence).

[0136] The public header 804 may include at least some of the following fields.

[0137] -dataDirection (gNB Transmission Tx / Rx): 1 bit. This parameter indicates the gNB data direction. This parameter is used in conjunction with eAxC_ID to identify which O-RU low-level endpoint a C-plane / U-plane message is directed to or originates from.

[0138] -payloadVersion: 3 bits: Set to value = 1 (first protocol version for payload and time reference format). This parameter defines the valid payload protocol version for the following information elements (IEs) in the application layer.

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

[0140] -frameId (frame identifier): 8 bits. This parameter is a counter for 10ms frames (wrap-around period of 2.56 seconds). Specifically, frameId = frame number modulo 256.

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

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

[0143] -startSymbolId (Start Symbol Identifier): 6 bits. This parameter identifies the symbol number (within the time slot) of the earliest symbol to which C-plane message 800 applies.

[0144] -numberOfsections (number of sections): 8 bits. This parameter indicates the number of data section descriptions (single references to section IDs, or even multiple references to the same section ID) included in a C-plane message 800.

[0145] -sectionType (section type): 8 bits: This parameter determines the characteristics of U-plane (C-plane) data that will be transmitted or received from a beam with a mode ID.

[0146] The udCompHdr field 806 may include at least some of the following fields. In an embodiment, the udCompHdr field 806 may be included in a common header 804.

[0147] -udCompHdr (User Data Compression Header): 8 bits. Provides udCompHdr information on the U plane, instructing the O-RU (on the DL) and O-DU (on the UL) on how to interpret and decompress received U-plane data. For UL U-plane data compression, the O-DU should instruct the O-RU via udCompHdr in the U-plane message.

[0148] - Reserved (reserved for future use): 8 bits.

[0149] In an embodiment, each of segment header 808 and segment header 810 may include at least some of the following fields. For example, each segment header may include any combination of the following fields, and the value of each field for each segment header may be different.

[0150] -sectionId (section identifier): 12 bits. When using the C-plane and U-plane coupled via sectionId, this parameter identifies the individual data segments described by the data segment description within the C-plane message. The purpose of sectionId is to map U-plane data segments to the corresponding U-plane messages (and segment types) associated with the data.

[0151] -rb (Resource Block Identifier): 1 bit. This parameter indicates whether to use every RB or every other RB.

[0152] -symInc (symbol number increment command): 1 bit. This parameter indicates which symbol number is associated with a given segment description. As long as symInc is 0, each segment in the message should use the same value. When symInc is 1, the held symbol number should be incremented to the next symbol, and the new symbol number should be used for that segment and every subsequent segment until the symInc bit is detected as 1 again.

[0153] -startPrbc (Starting PRB of the data segment description): 10 bits. This parameter conveys the first (lowest frequency) PRB described by the segment description.

[0154] -numPrbc (Number of consecutive PRBs described by each data segment): 8 bits. This parameter conveys the number of PRBs described by the segment description.

[0155] -reMask (Resource Element Mask): 12 bits. This parameter defines the mask for resource elements (REs) within the PRB.

[0156] -numSymbol (Number of Symbols): 4 bits. This parameter defines the number of PRACH symbols to which the segment control applies, or the number of PRACH symbols in the PRACH timing in the PRACH case, or the number of PRACH symbols in the NPRACH symbol group in the NPRACH case.

[0157] -ef (extension flag): 1 bit. This parameter indicates whether this segment has any segment extensions included in the message.

[0158] -ueId field: 15 bits. This parameter is used to support channel-information-based beamforming in segment type 5.

[0159] In an embodiment, segment header 808 / segment header 810 may include an "extension flag". The presence of the extension flag indicates that a segment extension exists after the header. For example, when the field "ef" of segment header 808 is "1", one or more segment extensions indicated by "ef" may exist after segment header 808.

[0160] Figure 9 The configuration of segment extension according to an embodiment of the present disclosure is shown.

[0161] Reference Figure 9 The segment extension field 900 may include at least some of ef, extType, extLen, or the second port ueId to the (numPort+1)th port ueId. In embodiments, the segment extension field 900 may correspond to segment extension 10 according to the O-RAN standard. For example, the segment extension field 900 may include information for grouping multiple ports or multi-UE scheduling information. In embodiments, the segment extension field 900 may be applied to C-plane messages of segment types 1, 3, and 5; however, this disclosure is not limited thereto. For example, the segment extension field 900 may include Figure 8 In the C-plane message 800. In an embodiment, the segment extension field 900 may include the beam ID (beamId) for each port instead of the ueId for each port.

[0162] `ef` indicates the presence of a segment extension. `extType` indicates the type of segment extension for segment extension field 900. `extLen` indicates the length of the segment extension (e.g., the length of segment extension field 900).

[0163] In embodiments, the segment extension field 900 may further include beamGroupType and numPortc fields. beamGroupType may indicate the type of beamgroup (e.g., common beam, beam matrix indication, beam vector list, or a list of beamId / ueId with an associated port list index). In embodiments, the value of beamGroupType may be 10b; however, embodiments of this disclosure are not limited thereto. numPortc indicates the number of eAxC ports indicated by the segment extension. In embodiments, the beamGroupType field may follow the extLen field, and the numPortc field may follow beamGroupType.

[0164] Figure 10 The configuration of segment extension according to an embodiment of the present disclosure is shown.

[0165] Reference Figure 10The segment extension field 1000 may include at least some of each user's ef, extType, extLen, or numUeID. In an embodiment, the segment extension field 1000 may correspond to segment extension 17 according to the O-RAN standard. For example, the segment extension field 900 may include indications or information about user port groups. The segment extension field 1000 may include information about the number of ueIds of users scheduled in the preceding segment type and segment extension messages. A user may have multiple ueIds (i.e., may have multiple channel information; for example, when the UE supports the TAS function for SRS transmission, the O-DU may obtain various channel information corresponding to each transmit antenna).

[0166] `ef` indicates the presence of a segment extension. `extType` indicates the type of segment extension for segment extension field 1000 (e.g., 0x11 or 17). `extLen` indicates the length of the segment extension (e.g., the length of segment extension field 10000). `numUeID` indicates the number of ueIds per user.

[0167] In an embodiment, each user's ueId can be sequentially assigned using the three reserved bits of ueId[2:0]. This may mean that the maximum number of ueIds supported by each user is 8. Alternatively or additionally, ueIds in which all three reserved bits are 0 in a previous segment extension (e.g., segment extension 10) can be repeatedly configured as many times as the number of layers assigned to a user. Thus, the previous segment type and extension message implicitly provide the number of users scheduled (i.e., the number of different ueIds) and the number of layers per user (i.e., the number of identical ueIds). Finally, the number of ueIds associated with each user can be provided in the segment extension field 1000.

[0168] For example, the 15-bit ueId may include the TAS antenna identifier (or discriminator) for the corresponding user and the identifier (or discriminator) for different users. For example, the three consecutive least significant bits (LSBs) of the 15-bit ueId, i.e., ueId[2:0], can identify the TAS antenna for the same user. For example, ueId[2:0] may include information about any one of the antennas of the terminal for the corresponding user (e.g., the user corresponding to the preceding ueId[14:3]). ueId[14:3] can be used to distinguish different users. For example, different users may have different ueId[14:3] values.

[0169] In this embodiment, the segment extension field 1000 can be applied to... Figure 9 The segment extension field 900. For example, the segment extension field 1000 can be used with... Figure 9 The segment extension field 900 is included together with it. Figure 8In C-plane message 800.

[0170] Figure 11 The timing diagram illustrates the downlink C-plane data transmission / reception between the DU and RU according to an embodiment of the present disclosure.

[0171] Reference Figure 11 DU 202 and RU 204 can communicate using a fronthaul interface FH. RU 204 can be connected to antenna port 1102. Antenna port 1102 may include one or more antenna arrays for communication between base station 200 and user terminals. For example, antenna port 1102 may be included in a transceiver for communication between base station 200 and user terminals. In an embodiment, antenna port 1102 may be included in MMU 408 of RU 204.

[0172] The fronthaul interface FH may include a control plane and a user plane. The control plane may need to be used to process the corresponding U-plane packets. For example, before processing symbol #n, it may be necessary to transmit C-plane data (or C-plane message) 1106 for symbol #n to RU 204. Figure 11 In the embodiment shown, the reference point ('t d1 =0') can be the transmission of the earliest IQ sample (including CP) in the time domain within a symbol (e.g., symbol #n), wherein the symbol is generated from IQ data received in a U-plane message specific to the symbol identified by symbolId.

[0173] For the downlink, a C-plane message with instructions for transmitting downlink radio signals (e.g., a C-plane message for a data stream with dataDirection=1) may be transmitted from DU 202 to RU 204 and may refer to one or more symbols. The transmission and reception window for downlink C-plane messages referencing multiple symbols may be relative to the start of the earliest symbol referenced by the downlink C-plane message. For example, C-plane message 1106 may be transmitted from DU 202 to RU 204 during C-plane downlink transmission window 1104. In an embodiment, C-plane message 1106 may be transmitted with... Figure 8 The C-plane message 800 is configured in a similar manner and may include... Figure 9 The segment extension field 900 and Figure 10 The segment extension field is 1000.

[0174] exist Figure 11In the illustrated embodiment, the C-plane downlink transmission window 1104 may correspond to (or be included in) the 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 C-plane downlink transmission window. T1a_min_cp_dl may be a parameter indicating the end of the C-plane downlink transmission window. C-plane messages 1106 may be received by RU 204 during the C-plane downlink reception window 1108. Figure 11 In the illustrated embodiment, the C-plane downlink receive window 1108 may correspond to (or be included in) the 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 C-plane downlink receive window. T2a_min_cp_dl may be a parameter indicating the end of the C-plane downlink receive window.

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

[0176] As described above, in order to transmit a frame corresponding to symbol #n at the reference point using antenna port 1102, a segment-type C-plane message for the corresponding symbol should be transmitted to RU 204 before processing each symbol, and RU 204 may have to process the data for the corresponding symbol during interval T2a_min_cp_dl. Data processing for symbol #n may include beamforming based on channel information. For example, during time interval T2a_min_cp_dl, RU 204 may have to perform the above reference processing based on the information included in C-plane message 1106 (e.g., numUeID for each user and / or ueId for each port) and channel information. Figures 5 to 7 The description covers SVD processing and SVD-based beamforming. The parameter T2a_min_cp_dl can be hundreds of microseconds (e.g., 250 microseconds). Therefore, although SVD operation is complex, SVD-based beamforming should take very short times, thus increasing the complexity of the hardware used for SVD processing.

[0177] Figure 12 The configuration of segment types according to embodiments of this disclosure is shown.

[0178] Reference Figure 12 C-plane message 1200 may include a transport header 1202, a common header 1204 (or a radio application header or a timed header), a numberOfUEs field 1206, and a segment header 1208. In an embodiment, C-plane message 1200 may be a segment type 6 control message of the O-RAN standard. For example, C-plane message 1200 may convey channel information (e.g., channel information per UEId).

[0179] Transmission header 1202 can be with Figure 8 The transport header 802 is configured in a similar manner. The common header 1204 may include dataDirection, payloadVersion, filterIndex, frameId, subframeId, slotID, startSymbolId, numberOfsections, and sectionType. Fields in the common header 1204 that are related to... Figure 8 The description of the public parameters in the public header 804.

[0180] The numberOfUEs field 1206 (8 bits) indicates the number of UE-specific channel information datasets. The numberOfUEs field 1206 indicates the number of UEs (providing channel information) included in the C-plane message 1200. The numberOfUEs field 1206 may also include an 8-bit reserved field.

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

[0182] The segment header 1208 may include at least some of the following fields. Fields that are not included in the following will be omitted. Figure 8 Description of fields (parameters) common to section headers 808 and 810.

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

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

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

[0186] - Reserved (for future use): 4 bits.

[0187] -rb (Resource Block Identifier): 1 bit. For example, this is set to value = 0.

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

[0189] -startPrbc (starting PRB for data segment description): 10 bits.

[0190] -numPrbc (number of consecutive PRBs described by each data segment): 8 bits.

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

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

[0193] In an embodiment, the segment header 1208 may further include ciCompParam. ciCompParam can be a channel information compression parameter and can be 0 or 8 bits. This parameter is applied to the compression method specified by the associated ciCompMeth value. When ciCompOpt (a subfield of ciCompHdr) is 0, this parameter is applied to the next vector of ciIsample and ciQsample for all PRBs for a specific UE. When ciCompOpt (a subfield of ciCompHdr) is 1, this parameter is applied to the next vector of ciIsample and ciQsample for all antennas of a specific PRB. In an embodiment, the segment header 1208 may further include ciCompParam for the first PRB for the corresponding UE or for all PRBs. ciComParam may be inserted between numPrbc and the first ciIsample value.

[0194] In an embodiment, C-plane message 1200 may also include one or more repeating segment headers configured similarly to segment header 1208. For example, C-plane message 1200 may include multiple segment headers indicating channel information for multiple UEs (or multiple ueIds). Each segment header may include the ueId (or corresponding ueId) of the corresponding UE and a channel information value (e.g., a pair (or multiple pairs) of ciIsample and ciQsample).

[0195] Figure 12 The configuration of C-plane message 1200 shown is merely an example, and the configuration of C-plane message 1200 is not limited to... Figure 12 The configuration shown is illustrated. In this embodiment, additions, deletions, or modifications may be made. Figure 12 Some configurations for C-plane message 1200.

[0196] Figure 13 The configuration of a segment type including segment extensions is shown according to an embodiment of the present disclosure.

[0197] Reference Figure 13The C-plane message 1300 may include a transport header 1302, a timing header 1304, a numberOfUEs field 1306, a segment header 1308, and a segment extension field 1310. In an embodiment, the C-plane message 1300 may be a segment type 6 control message of the O-RAN standard, and the segment extension field 1310 may be a segment extension field of segment extension 17 of the O-RAN standard. In other words, a C-plane message of segment type 6 may include segment extension 17. For example, the C-plane message 1300 may include information about the number of user ueIds and channel information (e.g., channel information per ueId). Therefore, based on the C-plane message 1300, RU 204 can identify that UE 502 supports TAS and can identify the number of antennas used for TAS.

[0198] In an embodiment, RU 204 can report its ability to support segment extension 17 in segment type 6 to DU 202 via M-plane messages. Based on the M-plane messages from RU 204, DU 202 can identify that RU 204 supports C-plane messages 1300. DU 202 can identify whether channel information is in DU 202. Based on the identification that RU 204 supports C-plane messages 1300 and that channel information is in DU 202, DU 202 can generate C-plane message 1300 including a segment header 1308 containing ueId and a segment extension field 1310 containing numUeID.

[0199] Transmission header 1302 can be with Figure 12 The transmission header 1202 is configured in a similar manner. The timed header 1304 can be configured in the same way as... Figure 12 The public header 1204 is configured in a similar manner. The numberOfUEs field 1306 can be configured in the same way as... Figure 12 The numberOfUEs field 1206 is configured in a similar manner. The segment header 1308 can be configured in the same way as... Figure 12 The segment header 1208 is configured in a similar manner. For example, the segment header 1308 may include at least some of the fields (parameters) included in the segment header 1208. The "channel information" included in the segment header 1308 may include channel information corresponding to the ueId[14:0] of the segment header 1308. Descriptions of the common fields (or parameters) between C-plane message 1300 and C-plane message 1200 will be omitted.

[0200] exist Figure 13 In the section header 1308, the ueId field 1312 may be included. (See above for reference.) Figure 10The three consecutive least significant bits (LSBs) of the 15-bit ueId, namely ueId[2:0], can identify the TAS antenna of the same user. The other bits, namely ueId[14:3], can be used to distinguish different users. For example, ueId[2:0] of ueId field 1312 can indicate any one of the user's antennas. ueId[14:3] can indicate the user associated with segment header 1308.

[0201] Figure 13 The C-plane message 1300 may include a segment extension field 1310. The segment extension field 1310 may be configured with... Figure 10 The segment extension field 1000 is configured in a similar manner. For example, the segment extension field 1310 may include an ef field indicating the presence of a segment extension, an extType field indicating that the segment extension type is 17, an extLen field indicating the length of the segment extension field 1310, and a field indicating the numUeID of the user scheduled in the segment header 1308 preceding the segment extension field 1310 (i.e., the user corresponding to ueId[14:3]).

[0202] As shown above (refer to the reference) Figure 5 and Figure 6 In order to transmit signals to UE 502, RU 204 of base station 200 can perform SVD beamforming using channel information associated with each antenna of UE 502. For example, RU 204 can perform SVD processing (operation) based on at least some of the ueId of segment type 6, the channel information of segment type 6, and the numUeID of segment extension 17. In response to receiving C-plane message 1300, RU 204 can start SVD processing based on C-plane message 1300. For example, RU 204 can identify the number of channel information for each user based on numUeID, and identify the channel information for each antenna of the corresponding user based on ueId. RU 204 can perform SVD processing based on the channel information for each antenna.

[0203] Segment type 6 C-plane messages (e.g., C-plane message 1200 or C-plane message 1300) can be non-delay-managed C-plane messages. For example, DU 202 can send segment type 6 C-plane messages including per-UE channel information to RU 204 at a period equal to or longer than the time slot. Transmit / receive window constraints may not be applied to segment type 6 C-plane messages. For example, segment type 6 C-plane messages can be transmitted / received regardless of the transmit / receive window used for the control plane (e.g., Figure 11How windows 1104 and 1108 work. Segment type 6 C-plane messages may not be transmitted symbol-by-symbol or slot-by-slot. For example, segment type 6 C-plane messages may be transmitted with a period equal to or longer than a slot. Therefore, the processing delay allowed by RU 204 performing beamforming based on the information included in segment type 6 C-plane messages with segment extension 17 can be several milliseconds. This is consistent with the above reference. Figure 11 The processing delay for beamforming based on C-plane messages of segment type 5 with segment extension 17 is several hundred microseconds, a contrasting figure. As a result, RU 204 can ensure a longer processing time for SVD, thus reducing the complexity of the hardware implementation for SVD processing in RU 204.

[0204] In an embodiment, a segment extension field 1310 may be added for all ueId[2:0]. For example, in a C-plane message of segment type 6, each segment header may include segment extension 17, regardless of the ueId[2:0] in the segment header. Therefore, for each user, a C-plane message of segment type 6 may include as many segment extension 17 fields as there are ueIds for each user. Tables 2 through 4 below show the ueId values ​​of the segment header and the numUeID values ​​of the segment extension 17 fields in the C-plane message of segment type 6 for user 0, user 1, and user 2, respectively. The ueId described in Tables 2 through 4 may indicate the value of ueId[4:0] for each user.

[0205] [Table 2]

[0206] Referring to Table 2, the ueId[2:0] of user 0 can be any value from 000 to 111. Each of the eight ueId[2:0] values ​​can correspond to any of user 0's antennas, therefore, user 0's antennas can be identified based on user 0's ueId[2:0]. Since the ueIds in Table 2 are for user 0, the values ​​of ueId[4:3] can be equal to each other. In Table 2, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Since user 0 has eight ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 8.

[0207] [Table 3]

[0208] Referring to Table 3, the ueId[2:0] of user 1 can be any value from 000 to 011. Each of the four ueId[2:0] values ​​can correspond to any of user 1's antennas, therefore, user 1's antennas can be identified based on user 1's ueId[2:0]. Since the ueIds in Table 3 are for user 1, the values ​​of ueId[4:3] can be equal to each other. In Table 3, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Since user 1 has four ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 4.

[0209] [Table 4]

[0210] Referring to Table 4, User 2's ueId[2:0] can be 000 or 001. Each of the two ueId[2:0] values ​​can correspond to either of User 2's antennas; therefore, User 2's antennas can be identified based on User 2's ueId[2:0]. Since the ueIds in Table 4 are for User 2, the values ​​of ueId[4:3] can be equal to each other. In Table 4, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Because User 2 has two ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 2.

[0211] In an embodiment, the segment extension field 1310 may be added only for one or more specific ueId[2:0]. Based on the ueId[2:0] values ​​included in the segment header of each segment type 6, the segment extension 17 may be added only for some segment headers of segment type 6. For example, in a C-plane message of segment type 6, the segment extension 17 may be added only for segment headers (multiple segment headers) where the ueId[2:0] value is one or more specific values. For example, the segment extension 17 may be added only for segment headers with ueId[2:0]=0. Therefore, when a segment type 6 command is invoked more than once to convey channel information to the user (e.g., more than one channel message), the number of ueIds may be provided only once if ueId[2:0] is 0, and DU 202 may append the segment extension 17 along with the first segment description to the segment type 6 command to the user. Tables 5 through 7 below show the ueId values ​​of the segment header and the numUeID values ​​of the segment extension 17 field in C-plane messages of segment type 6 for users 0, 1, and 2, respectively. The ueId described in Tables 5 through 7 indicates the value of ueId[4:0] for each user.

[0212] [Table 5]

[0213] Referring to Table 5, user 0's ueId[2:0] can be any value from 000 to 111. Conversely, in Table 5, segment extension 17 may only follow the segment header of segment type 6 that includes ueId[2:0] = 0 (i.e., ueId = 01000b). Segment extension 17 may not be added to other segment headers of segment type 6 associated with user 0.

[0214] [Table 6]

[0215] Referring to Table 6, user 1's ueId[2:0] can be any value from 000 to 011. Contrary to Table 3, in Table 6, segment extension 17 may only follow the segment header for segment type 6 that includes ueId[2:0]=0 (i.e., ueId=10000b). Segment extension 17 may not be added to other segment headers for segment type 6 associated with user 1.

[0216] [Table 7]

[0217] Referring to Table 7, user 2's ueId[2:0] can be any value from 000 to 001. Contrary to Table 4, in Table 7, segment extension 17 may only follow the segment header of segment type 6 that includes ueId[2:0]=0 (i.e., ueId=01000b). Segment extension 17 may not be added to other segment headers of segment type 6 associated with user 2.

[0218] Alternatively or additionally, segment extension 17 may be added only for segment headers where the value of ueId[2:0] is even (multiple segment headers), for segment headers where the value of ueId[2:0] is odd (multiple segment headers), for segment headers where the value of ueId[2:0] is a multiple of a specific natural number (multiple segment headers), for segment headers where the value of ueId[2:0] is a prime number (multiple segment headers), and / or values ​​equal to numUeID divided by 2 (or rounded / rounded to below the decimal point / truncated to below the decimal point). However, embodiments of this disclosure are not limited thereto.

[0219] Figure 14 The configuration of segment types according to embodiments of this disclosure is shown.

[0220] Reference Figure 14The C-plane message 1400 may include a transport header 1402, a common header 1404 (or a wireless application header or a timed header), a udCompHdr field 1406, and a segment header 1408. In the illustrated embodiment, the segment type of the C-plane message 1400 may be 'X' (where 'X' is a natural number). Hereinafter, the C-plane message 1400 may be referred to as a "C-plane message of segment type X" or a "C-plane message of segment type X". The segment header 1408 may be referred to as a "segment header of segment type X" or a "segment header of segment type X".

[0221] In an embodiment, C-plane message 1400 may be a ueId-by-ueId C-plane message instructing RU 204 to perform channel estimation operations. For example, C-plane message 1400 may include information for directly or indirectly commanding (or instructing or requesting) the performance of channel estimation. In some embodiments, channel estimation functionality may be assigned to RU 204 instead of DU 202, so DU 202 may command RU 204 to perform channel estimation via C-plane message 1400. In response to C-plane message 1400, MMU 408 of RU 204 may perform channel estimation and perform SVD beamforming based on the obtained channel information. In an embodiment, C-plane message 1400 may be sent from DU 202 to RU 204 according to the SRS period.

[0222] Transmission header 1402 can be with Figure 8 The transmission header 802 is configured in a similar manner. The common header 1404 can be configured in the same way as... Figure 8 The public header 804 is configured in a similar way. Fields in public header 1404 will be omitted. Figure 8 The description of the common parameters in the public header 804. The udCompHdr field 1406 can be used with... Figure 8 The udCompHdr field 806 is configured in a similar way. The udCompHdr field 1406 will be omitted. Figure 8 The description of the parameters common to the udCompHdr field 806.

[0223] Segment header 1408 may include at least some of the following fields. (The following fields will be omitted.) Figure 8 Fields (parameters) shared by segment header 808 and segment header 810 or related to Figure 12 The description of the common fields (parameters) in the segment header 1208.

[0224] -sectionId (section identifier): 12 bits.

[0225] -rb (resource block identifier): 1 bit.

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

[0227] -startPrbc (starting PRB for data segment description): 10 bits.

[0228] -numPrbc (number of consecutive PRBs described by each data segment): 8 bits.

[0229] - SRS configuration information: 8 bits. SRS configuration setup information may include information required to support SRS-based channel estimation, such as SRS resource configuration (e.g., SRS transmission period, time slot location or frequency resources), SRS transmission power and beamforming information, UE antenna configuration information, or SRS signal encoding and compression configuration.

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

[0231] -ueId field: 15 bits.

[0232] Figure 14 The configuration of C-plane message 1400 shown is merely an example, and the configuration of C-plane message 1400 is not limited to... Figure 14 The configuration shown is illustrated. In this embodiment, additions, deletions, or modifications may be made. Figure 14 Some configurations for C-plane message 1400.

[0233] Figure 15 The configuration of a segment type including segment extensions is shown according to an embodiment of the present disclosure.

[0234] Reference Figure 15 The C-plane message 1500 may include a transport header 1502, a timing header 1504, a udCompHdr field 1506, a segment header 1508, and a segment extension field 1510. In an embodiment, the C-plane message 1500 may be added along with the segment extension field 1510. Figure 14 The C-plane message 1400 corresponds to this message. The segment extension field 1510 can be the segment extension field of the O-RAN standard segment extension 17. For example, the C-plane message 1500 may include information about the number of user ueIds and commands for SRS-based channel estimation. Therefore, based on the C-plane message 1500, RU 204 can identify that UE 502 supports TAS and can identify the number of antennas used for TAS.

[0235] In an embodiment, RU 204 can report its ability to support segment extension 17 in segment type X to DU 202 via M-plane messages. Based on the M-plane messages from RU 204, DU 202 can identify that RU 204 supports C-plane messages 1500. DU 202 can identify whether channel information is in DU 202. Based on the identification that RU 204 supports C-plane messages 1500 and the identification that channel information is not in DU 202, DU 202 can generate C-plane messages 1500 including a segment header 1508 containing ueId and a segment extension field 1510 containing numUeID.

[0236] Transmission header 1502 can be with Figure 14 The transmission header 1402 is configured in a similar manner. The timing header 1504 can be configured in the same way as... Figure 14 The public header 1404 is configured in a similar manner. The udCompHdr field 1506 can be configured in the same way as... Figure 14 The udCompHdr field 1406 is configured in a similar manner. The segment header 1508 can be configured in the same way as... Figure 14 The segment header 1408 is configured in a similar manner. For example, segment header 1508 may include at least some of the fields (parameters) included in segment header 1408. The "SRS setting information" included in segment header 1508 may include SRS setting information corresponding to ueId[14:0] of segment header 1508. Descriptions of common fields (or parameters) between C-plane message 1500 and C-plane message 1400 will be omitted.

[0237] exist Figure 15 In the section header 1508, the ueId field may be included. (See above for reference.) Figure 10 and Figure 13 The three consecutive least significant bits (LSBs) of the 15-bit ueId, namely ueId[2:0], identify the TAS antenna of the same user. The other bits, namely ueId[14:3], can be used to distinguish different users. For example, ueId[2:0] of the ueId field can indicate any one of the user's antennas. ueId[14:3] can indicate the user associated with segment header 1508.

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

[0239] As shown above (refer to the reference) Figure 5 and Figure 6 To transmit signals to UE 502, RU 204 of base station 200 can perform SVD beamforming using channel information associated with each antenna of UE 502. In response to receiving C-plane message 1500, RU 204 can initiate SVD processing based on C-plane message 1500. For example, RU 204 can identify the amount of channel information for each user based on numUeID of segment extension field 1510, identify the channel information for each antenna of the corresponding user based on ueId of segment header 1508, and perform SRS-based channel estimation for each antenna of UE 502 based on SRS setting information of segment header 1508. Thereafter, RU 204 can perform SVD processing based on the channel information for each antenna. In embodiments, at least some of the SRS-based channel estimation or SVD processing can be performed by MMU 408 of RU 204.

[0240] C-plane messages of segment type X (e.g., C-plane message 1400 or C-plane message 1500) can be sent to RU 204 at a period equal to or longer than the time slot. For example, C-plane messages of segment type X can be sent to RU 204 according to the SRS period. The transmission period of C-plane messages of segment type X can be aligned with the SRS period. C-plane messages of segment type X can be sent / received regardless of the transmit / receive window used for the control plane (e.g., Figure 11 How windows 1104 and 1108 work. Therefore, C-plane messages with segment type X of segment extension 17 can be sent to RU 204 at periods (or intervals) of a few milliseconds. Therefore, the processing delay allowed by RU 204 performing beamforming based on the information included in the C-plane message of segment type X with segment extension 17 can be a few milliseconds. This is consistent with the above reference. Figure 11 The processing delay for beamforming based on C-plane messages of segment type 5 with segment extension 17 is several hundred microseconds, a contrasting figure. As a result, RU 204 can ensure a longer processing time for SVD, thus reducing the complexity of the hardware implementation for SVD processing in RU 204.

[0241] In an embodiment, as described above with reference to Tables 2 through 4, a segment extension field 1510 may be added for all ueId[2:0]. For example, in a C-plane message of segment type X, each segment header may include segment extension 17, regardless of the ueId[2:0] in the segment header. Therefore, for each user, a C-plane message of segment type X may include as many segment extension 17 fields as there are ueIds for each user. Tables 8 through 10 below show the ueId values ​​of the segment header and the numUeID values ​​of the segment extension 17 fields in the C-plane message of segment type X for user 0, user 1, and user 2, respectively. The ueId described in Tables 8 through 10 may indicate the value of ueId[4:0] for each user.

[0242] [Table 8]

[0243] Referring to Table 8, the ueId[2:0] of user 0 can be any value from 000 to 111. Each of the eight ueId[2:0] values ​​can correspond to any of user 0's antennas, therefore, user 0's antennas can be identified based on user 0's ueId[2:0]. Since the ueIds in Table 8 are for user 0, the values ​​of ueId[4:3] can be equal to each other. In Table 8, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Since user 0 has eight ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 8.

[0244] [Table 9]

[0245] Referring to Table 9, User 1's ueId[2:0] can be any value from 000 to 011. Each of the four ueId[2:0] values ​​can correspond to any of User 1's antennas; therefore, User 1's antennas can be identified based on User 1's ueId[2:0]. Since the ueIds in Table 9 are for User 1, the values ​​of ueId[4:3] can be equal to each other. In Table 9, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Because User 1 has four ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 4.

[0246] [Table 10]

[0247] Referring to Table 10, User 2's ueId[2:0] can be 000 or 001. Each of the two ueId[2:0] values ​​can correspond to either of User 2's antennas; therefore, User 2's antennas can be identified based on User 2's ueId[2:0]. Since the ueIds in Table 10 are for User 2, the values ​​of ueId[4:3] can be equal to each other. In Table 10, regardless of the value of ueId[2:0], segment extension 17 can follow the segment header for each ueId. Because User 2 has two ueIds, the segment extension 17 for each segment header can include a numUeID with a value of 2.

[0248] In an embodiment, the segment extension field 1510 may be added only for one or more specific ueId[2:0]. Based on the ueId[2:0] values ​​included in the segment header of each segment type X C-plane message, segment extension 17 may be added only for some segment headers of segment type X. For example, in a C-plane message of segment type X, segment extension 17 may be added only for segment headers (multiple segment headers) where the ueId[2:0] value is one or more specific values. For example, segment extension 17 may be added only for segment headers with ueId[2:0]=0. Alternatively or additionally, segment extension 17 may be added only for segment headers where the value of ueId[2:0] is even (multiple segment headers), for segment headers where the value of ueId[2:0] is odd (multiple segment headers), for segment headers where the value of ueId[2:0] is a multiple of a specific natural number (multiple segment headers), for segment headers where the value of ueId[2:0] is a prime number (multiple segment headers), and / or equal to numUeID divided by 2 (or rounded / rounded to below the decimal point / truncated to below the decimal point). However, embodiments of this disclosure are not limited thereto. Tables 11 through 13 below show the ueId values ​​of the segment headers and the numUeID values ​​of the segment extension 17 field in C-plane messages of segment type X for users 0, 1, and 2, respectively. The ueId described in Tables 11 through 13 may indicate the value of ueId[4:0] for each user.

[0249] [Table 11]

[0250] Referring to Table 11, the ueId[2:0] for user 0 can be any value from 000 to 111. Contrary to Table 8, in Table 11, segment extension 17 may only follow the segment header that includes segment type X with ueId[2:0] = 0 (i.e., ueId = 01000b). Segment extension 17 may not be added to other segment headers for segment type X associated with user 0.

[0251] [Table 12]

[0252] Referring to Table 12, user 1's ueId[2:0] can be any value from 000 to 011. Contrary to Table 9, in Table 12, segment extension 17 may only follow the segment header that includes segment type X with ueId[2:0]=0 (i.e., ueId=10000b). Segment extension 17 may not be added to other segment headers for segment type X associated with user 1.

[0253] [Table 13]

[0254] Referring to Table 13, user 2's ueId[2:0] can be any value from 000 to 001. Conversely, in Table 13, segment extension 17 may only follow the segment header that includes segment type X with ueId[2:0]=0 (i.e., ueId=01000b). Segment extension 17 may not be added to other segment headers for segment type X associated with user 2.

[0255] Already referred to Figure 13 and Figure 15 An embodiment of adding segment extension 17 to a C-plane message of segment type 6 or a C-plane message of segment type X is described; however, the embodiments of this disclosure are not limited thereto. In the embodiments, segment extension 17 can be added not only to C-plane messages of segment type 6 or segment type X that include a field indicating ueId, but also to C-plane messages that are not delayed (e.g., C-plane messages that do not need to be transmitted per time slot, or C-plane messages that are transmitted / received regardless of the C-plane transmit / receive window). Before, simultaneously with, or after the C-plane message, RU 204 can obtain channel information for each antenna of the terminal based on the C-plane message of segment type 6 or the C-plane message of segment type X, and perform SVD-based beamforming based on the aforementioned C-plane message and channel information.

[0256] Figure 16 A flowchart illustrating a method of wireless communication performed by a DU according to an embodiment of the present disclosure is shown.

[0257] Reference Figure 16 Method 1600 performed by DU 202 may include operations 1602, 1604, and 1606. However, this disclosure is not limited thereto, and operations 1602 to 1606 may be performed individually or jointly by any electronic device. The methods according to embodiments of this disclosure are not limited to... Figure 16 The method shown can be omitted. Figure 16 Any operation shown, or may further include Figure 16Operations not shown. In some embodiments, the order of at least some of 1602, 1604, and 1606.

[0258] In operation 1602, DU 202 may receive an M-plane message from RU 204, including information about C-plane messages supported by RU 204. In operation 1604, based on the M-plane message, DU 202 may generate a first C-plane message including a field indicating a first UE ID and a first segment extension field. The first segment extension field may include a parameter indicating the number of UE IDs of the user associated with the first UE ID. In operation 1606, DU 202 may send the first C-plane message to RU 204 via the fronthaul interface.

[0259] Alternatively or additionally, the first C-plane message may be a message transmitted independently of the transmit / receive window used for the control plane. The first C-plane message may not be transmitted symbol-by-symbol or time-slot-by-time. The transmission period of the first C-plane message may be longer than the transmission period of a symbol or the transmission period of a time slot. The first C-plane message may be transmitted with a period equal to or longer than the transmission period of a time slot. The first C-plane message may be transmitted according to the SRS period (e.g., with the same period as the SRS transmission period).

[0260] Alternatively or concurrently, the M-plane message may instruct RU 204 to support a C-plane message that includes either a first segment extension field or UE-specific channel information or information used to request channel estimation operation from RU 204. For example, the M-plane message may instruct RU 204 to support a C-plane message that includes a segment extension 17 field (e.g., Figure 13 C-plane message 1300). M-plane messages can indicate that RU 204 supports C-plane messages that include segment extension X, such as the segment extension 17 field (e.g., Figure 15 C-plane message 1500).

[0261] Alternatively or additionally, the first C-plane message may also include a field indicating channel information corresponding to the first UE ID. For example, the first C-plane message may include a field indicating a specific UE ID and a field indicating channel information corresponding to that specific UE ID.

[0262] Alternatively or additionally, the first C-plane message may also include channel estimation operation commands to RU 204. For example, the first C-plane message may include information for commanding (or instructing or requesting) RU 204 to perform channel estimation. The first C-plane message may include information required to perform channel estimation. For example, the first C-plane message may include SRS information for supporting SRS-based channel estimation.

[0263] Alternatively or additionally, method 1600 may include sending a second C-plane message to RU 204 via a fronthaul interface, including a second UE ID of the user corresponding to the first UE ID and a second segment extension field. The second segment extension field may include a parameter indicating the number of UE IDs corresponding to the user 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 therefore the second segment extension field may have the same value as the first segment extension field.

[0264] Alternatively or additionally, method 1600 may include sending a second C-plane message, comprising a second UE ID of a user associated with a first UE ID, to RU 204 via a fronthaul interface. The field in the first C-plane message indicating the first UE ID may include the least significant bit (LSB) containing three consecutive 0s. For example, the first C-plane message may include a ueId field having ueId[2:0]=0. The second C-plane message may not include a segment extension field containing a parameter indicating the number of UE IDs.

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

[0266] Figure 17 A flowchart illustrating a method of wireless communication performed by a RU according to an embodiment of the present disclosure is shown.

[0267] Reference Figure 17 Method 1700 performed by RU 204 may include operations 1702 and 1704. However, this disclosure is not limited thereto, and operations 1702 and 1704 may be performed individually or jointly by any electronic device. The methods according to embodiments of this disclosure are not limited to... Figure 17 The method shown can be omitted. Figure 17 Any operation shown, or may further include Figure 17 Operations not shown. In some embodiments, the order of at least some of operations 1702 and 1704 may be modified.

[0268] In operation 1702, RU 204 may send an M-plane message to DU 202, including information about C-plane messages supported by RU 204. In operation 1704, RU 204 may receive a first C-plane message from DU 202 via the fronthaul interface. The first C-plane message may include a field indicating a first UE ID and a first segment extension field. The first segment extension field may include a parameter indicating the number of UE IDs of the user associated with the first UE ID.

[0269] Alternatively or additionally, method 1700 may also include operations that perform SVD processing based on the first C-plane message. For example, RU 204 may also perform operations based on the first C-plane message. Figure 7 At least some of operations 710 and 712. In an embodiment, RU 204 may estimate one or more characteristics of the channel for each antenna of the terminal based on the UE ID indicated by the first C-plane message and the number of UE IDs of the corresponding users, and perform SVD processing based on the estimation results.

[0270] Alternatively or additionally, the first C-plane message may be a message transmitted independently of the receive window used for the control plane. The first C-plane message may not be a message transmitted symbol by symbol. The transmission period of the first C-plane message may be longer than the transmission period of a symbol. The first C-plane message may be transmitted with a period equal to or longer than the transmission period of a time slot. The first C-plane message may be transmitted according to the SRS period (e.g., with the same period as the SRS transmission period).

[0271] Alternatively or concurrently, the M-plane message may instruct RU 204 to support a C-plane message that includes either a first segment extension field or UE-specific channel information or information used to request channel estimation operation from RU 204. For example, the M-plane message may instruct RU 204 to support a C-plane message that includes a segment extension 17 field (e.g., Figure 14 C-plane message 1300). M-plane messages can indicate that RU 204 supports C-plane messages that include segment extension X, such as the segment extension 17 field (e.g., Figure 15 C-plane message 1500).

[0272] Alternatively or additionally, the first C-plane message may also include a field indicating channel information corresponding to the first UE ID. For example, the first C-plane message may include a field indicating a specific UE ID and a field indicating channel information corresponding to that specific UE ID.

[0273] Alternatively or additionally, the first C-plane message may also include channel estimation operation commands to RU 204. For example, the first C-plane message may include information for commanding (or instructing or requesting) RU 204 to perform channel estimation. The first C-plane message may include information required to perform channel estimation. For example, the first C-plane message may include SRS information for supporting SRS-based channel estimation. In response to the first C-plane message, RU 204 may perform channel estimation.

[0274] Alternatively or additionally, method 1700 may include receiving a second C-plane message from DU 202 via a fronthaul interface, including a second UE ID of a user and a second segment extension field. The second segment extension field may include a parameter indicating the number of UE IDs corresponding to the user 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 therefore the second segment extension field may have the same value as the first segment extension field.

[0275] Alternatively or additionally, method 1700 may include receiving a second C-plane message from DU 202 via a fronthaul interface, including a second UE ID of a user associated with a first UE ID. The field in the first C-plane message indicating the first UE ID may include the least significant bit (LSB) containing three consecutive 0s. For example, the first C-plane message may include a ueId field with ueId[2:0]=0. The second C-plane message may not include a segment extension field containing a parameter indicating the number of UE IDs.

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

[0277] At least some methods according to embodiments of this disclosure can be implemented in the form of program commands that can be recorded on a computer-readable recording medium and are executable by various computer means. The computer-readable recording medium may include program commands, data files, and data structures individually or in combination. The program commands recorded on the computer-readable recording medium may be program commands specifically designed and configured for this disclosure, or program commands known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media (such as hard disks, floppy disks, or magnetic tapes), optical media (such as CD-ROMs or DVDs), magneto-optical media (such as optical-magnetic floppy disks), and hardware devices (such as ROMs, RAMs, or flash memory) specifically configured to store and execute program commands. Examples of program commands include machine language code that can be generated by a compiler and high-level language code that can be executed by a computer using an interpreter.

[0278] Machine-readable storage media may be provided in the form of non-transitory storage media. Here, "non-transitory storage media" may mean a storage medium that is a tangible device and does not include signals (e.g., electromagnetic waves), and may mean that data can be stored in the storage medium semi-permanently or temporarily. For example, "non-transitory storage media" may include buffers for temporarily storing data.

[0279] According to embodiments of this disclosure, methods according to various embodiments of this disclosure described herein can be included and provided in a computer program product. The computer program product can be traded as a product between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)), or distributed online through an app store (e.g., downloaded or uploaded), or distributed directly between two user devices (e.g., smartphones) (e.g., downloaded or uploaded). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable application) can be at least temporarily stored or temporarily generated in a machine-readable storage medium (such as the memory of a manufacturer's server, the memory of an app store server, or the memory of a relay server).

[0280] While certain embodiments of this disclosure have been described above with reference to the accompanying drawings, those skilled in the art can make various changes and modifications based on the above description. For example, suitable results may be achieved even if the technology is performed in a different order than the method and / or components of the computer system or module are coupled or combined in a different form than the method, or are replaced or superseded by other components or equivalents.

Claims

1. A method for wireless communication performed by a distributed unit DU (202), the method comprising: Receive management plane messages from radio unit RU (204) including information about control plane messages supported by said RU; Based on the management plane message, generate a first control plane message including a field indicating a first user equipment identifier (UE ID) and a first segment extension field; and The first control plane message is sent to the RU via the fronthaul interface. The first segment extension field includes a parameter indicating the number of UE IDs of the user associated with the first UE ID, and the first control plane message is sent with a period longer than the time slot.

2. The method as described in claim 1, wherein, Sending the first control plane message is independent of the sending window used for the control plane.

3. The method as described in claim 1 or 2, wherein, The management plane message indicates that the RU supports the control plane message that includes any one of the first segment extension field and UE-specific channel information or information for requesting channel estimation operation from the RU.

4. The method according to any one of claims 1 to 3, wherein, The first control plane message also includes a field indicating channel information corresponding to the first UE ID.

5. The method according to any one of claims 1 to 3, wherein, The first control plane message also includes a channel estimation operation command to the RU.

6. The method of any one of claims 1 to 5, further comprising: A second control plane message, including a second UE ID of the user associated with the first UE ID and a second segment extension field, is sent to the RU via the fronthaul interface. The second segment extension field includes a parameter indicating the number of UE IDs corresponding to the user.

7. The method of any one of claims 1 to 5, further comprising: A second control plane message, including a second UE ID of the user associated with the first UE ID, is sent to the RU via the fronthaul interface. The field indicating the first UE ID includes the least significant bit (LSB) containing three consecutive 0s.

8. A method for wireless communication performed by a radio unit RU (204), the method comprising: Send a management plane message to the distributed unit DU (202) including information about control plane messages supported by the RU; as well as Receive first control plane messages from the DU via the fronthaul interface. The first control plane message includes a field indicating a first user equipment identifier (UE ID) and a first segment extension field. The first segment extension field includes a parameter indicating the number of UE IDs of the user associated with the first UE ID, and the first control plane message is sent with a period longer than the time slot.

9. The method of claim 8, further comprising: Based on the first control plane message, singular value decomposition (SVD) is performed.

10. The method of claim 8 or 9, wherein, Receiving the first control plane message is independent of the receiving window used for the control plane.

11. The method according to any one of claims 8 to 10, wherein, The management plane message indicates that the RU supports the control plane message that includes any one of the first segment extension field and UE-specific channel information or information for requesting channel estimation operation from the RU.

12. The method according to any one of claims 8 to 11, wherein, The first control plane message also includes a field indicating channel information corresponding to the first UE ID.

13. The method according to any one of claims 8 to 11, wherein, The first control plane message also includes a channel estimation operation command to the RU.

14. The method of any one of claims 8 to 13, further comprising: The system receives a second control plane message from the DU via the fronthaul interface, which includes a second UE ID of the user associated with the first UE ID and a second segment extension field. The second segment extension field includes a parameter indicating the number of UE IDs corresponding to the user.

15. The method of any one of claims 8 to 13, further comprising: The system receives a second control plane message from the DU via the fronthaul interface, which includes a second UE ID of the user associated with the first UE ID. The field indicating the first UE ID includes the least significant bit (LSB) containing three consecutive 0s.

Images