SRS channel compression over fronthaul interface

Abstract

A method for compressing Sounding Reference Signal (SRS) channel information in massive MIMO systems is disclosed. When SRS channel estimation is performed in a Radio Unit (RU), the resulting channel estimates create significant fronthaul bandwidth demands. The method transforms SRS channel estimates from antenna space to domains with superior energy compacting properties, enabling transmission of only a subset of channel values while preserving information quality. The method includes beam space compression using mathematical transforms such as DFT, SVD, or EVD to convert channel estimates to beam space, followed by selection of the most significant beams. Alternative embodiments include tap domain compression using DCT or DFT, and delay-Doppler domain compression. The methods support static beam space compression using predefined beam bases and dynamic compression employing adaptive beam bases. O-RAN C-Plane implementations extend Section Type 6 to support the compression methods. The methods significantly reduce fronthaul bandwidth requirements while maintaining channel estimation accuracy, enabling improved system capacity in massive MIMO deployments.

Description

[0001] SRS CHANNEL COMPRESSION OVER FRONTHAUL INTERFACE TECHNICAL FIELD The present disclosure relates to the field of a distributed base station system comprising a radio unit (RU) and a distributed unit (DU) connected over a fronthaul link, and efficient methods for communication of channel-related information over the fronthaul link. BACKGROUND Massive MIMO techniques were first adopted to practice in LTE. In 5G, it becomes one key technology component, which has been deployed in a much larger scale than in LTE. It features a large number of antennas used on the base-station side, where the number of antennas is typically much larger than the number of user layers, for example, 64 antennas serving 8 or 16 user layers in frequency range 1 (FR1), which comprises sub-6 GHz frequency bands, and 256 / 512 antennas serving 2 or 4 layers in FR2, which comprises frequency bands from 24.25 GHz to 71 GHz. A user layer when used herein e.g., means an independent downlink (DL) or uplink (UL) data stream intended for one user. One user or user equipment (UE) may have one or multiple user layers. User layer is often denoted as layer for simplicity reason. Massive MIMO is also referred to as massive beamforming, which is able to form narrow beams focusing on different directions to counteract the increased path loss at higher frequency bands. It also benefits multi-user MIMO (MU- MIMO) which allows for transmissions from / to multiple users simultaneously over separate spatial channels resolved by the massive MIMO technologies (e.g., by spatially nulling the interferences between users), while keeping high capacity for each user. Therefore, it can significantly increase the spectrum efficiency and cell capacity. At the base-station side, the interface between the distributed unit (DU) (also sometimes referred to as digital unit or baseband unit) and the radio unit (RU) is the fronthaul interface. The great benefits of massive MIMO at the air-interface also introduce new challenges at the base-station side. The legacy CPRI-type fronthaul transports time- domain in-phase and quadrature (IQ) samples per antenna branch. As the number of antennas scales up in massive MIMO systems, the required fronthaul capacity also increases proportionally, which significantly drives up the fronthaul costs. To address this challenge, the fronthaul interface evolves from CPRI to eCPRI, a packet-based fronthaul interface. In eCPRI, other functional split options between DU and RU are supported, referred to as different lower-layer split (LLS) options. In eCPRI terminologies, DU and RU are referred to as eREC (eCPRI Radio Equipment Control) and eRE (eCPRI Radio Equipment), respectively. The basic idea of these LLS options is to move the frequency- domain beamforming function from DU to RU so that frequency samples or data of user- layers are transported over the fronthaul interface. Note that the frequency-domain beamforming is sometimes also referred to as precoding in the DL direction and combining (or pre-equalizing) or equalizing in UL direction. By doing this, the required fronthaul capacity and thereby the fronthaul costs are significantly reduced, as the number of user layers is typically much fewer than the number of antennas in massive MIMO. In O-RAN, DU is referred to as O-DU while RU is referred to as O-RU, see e.g., [1]. Figure 10 shows an O-RU and an O-DU connected by a fronthaul link / fronthaul interface. However there still exist challenges. It is strongly desired to further reduce both fronthaul costs and costs for hardware in O-RU and / or O-DU, and further increase system capacity to serve more user traffic. Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. SUMMARY A method and system for compressing Sounding Reference Signal (SRS) channel information transmitted over fronthaul interfaces in massive MIMO systems is disclosed. In massive MIMO systems employing O-RAN architectures, the fronthaul interface between Distributed Units (DU) and Radio Units (RU) experiences significant capacity challenges as antenna counts increase. When SRS channel estimation functionality is relocated from the DU to the RU to reduce processing load, the resulting channel estimates require transmission back to the DU, creating substantial fronthaul traffic proportional to the number of antennas and SRS ports. The disclosed methods transform SRS channel estimates from antenna space and / or frequency domain to domains exhibiting better energy compacting properties, enabling transmission of only a subset of channel values while maintaining channel information integrity. The transformation may comprise beam space compression, which transforms channel estimates from antenna space to beam space using mathematical transforms such as Discrete Fourier Transform (DFT), Singular Value Decomposition (SVD), or Eigenvalue Decomposition (EVD), followed by selection of the most significant beams for transmission. Alternative embodiments include tap domain compression, wherein frequency-domain channel estimates are transformed to tap domain using Discrete Cosine Transform (DCT) or DFT, with selection of the highest energy taps. Additional embodiments utilize delay- Doppler domain compression, exploiting the sparse nature of delay-Doppler representations to achieve channel information compression. The system may implement static beam space compression using predefined beam bases with bitmask indication of selected beams, or dynamic beam space compression employing adaptive beam bases optimized for current channel conditions of one or multiple UE ports / layers of one or multiple UEs, which may require transmission of base vectors. The method supports both common beam selection across multiple UE ports / layers and individual selection per port. Specific O-RAN C-Plane implementations are provided, extending Section Type 6 (ST-6) to support new compression methods, efficient conveyance of beam space base vectors, and reuse mechanisms to avoid redundant transmission of shared information. The disclosed compression methods may be identified by ciCompMeth values 100b for static beamspace compression and 101b for dynamic beamspace compression. The method provides significant reduction in fronthaul bandwidth requirements while maintaining channel estimation accuracy with minimal performance impact. Additional benefits include improved statistical multiplexing, reduced peak processing demands, enhanced system capacity for serving additional users, and support for advanced features including positioning, scheduling, and coordinated multi-point transmission. In one embodiment, a Radio Unit receives a Sounding Reference Signal from a user equipment, performs channel estimation to produce a channel estimate, transforms the channel estimate to beam space, compresses the transformed channel estimate by selecting a subset of beams, and transmits the compressed channel estimate to a Distributed Unit over a fronthaul interface. The beam selection may be based on energy criteria, selecting beams with highest amplitude, power, signal-to-noise ratio or eigen values The disclosed methods enable efficient distribution of SRS processing between Radio Units and Distributed Units while maintaining the Distributed Unit's access to channel information necessary for system optimization, thereby addressing the fronthaul capacity challenges inherent in massive MIMO deployments. In one aspect, an O-RAN O-RU having a plurality of antennas may send selected beam space channel estimates or SRS on a subset of beams, together with an indication identifying the selected beams over a fronthaul interface to an O-RAN O-DU. In some embodiments, the number of channel estimates or SRS may be smaller than the number of antennas. The beam-space channel values or SRS with best quality may be selected, where best quality refers to having highest amplitude or power or highest SNR or SINR, highest eigen values of the channel covariance or any other quality metric. The channel estimates or SRS in beam space may be based on a transform from antenna space to beam space, and the O-RU may further send weights or coefficients of determined beams used for beam space transformation. The selected beams may be determined by the O-RU based on the channel estimates. In some implementations, the channel estimates or SRS may be given for a same set of beams / base vectors common to all or at least to a plurality of the ports or layers of a UE. Alternatively, the channel estimates or SRS may each be given for separate set of beams / base vectors for each specific port or layer of a UE. In other embodiments, the channel estimates or SRS may each be given for separate set of beams / base vectors for each SRS comb offset. The weights or coefficients may be determined based on SRS received for a UE. The weights or coefficients may be sent in a C-plane message. A reuse flag may be sent from O-RU to O-DU indicating that the beams, set of weights or coefficients is to be used again. In another aspect, an O-RAN O-DU may receive the information sent by the O-RU as described in the preceding aspects. An O-RAN O-RU may be adapted to perform the methods described in the preceding aspects. An O-RAN O-DU may be adapted to perform the method of receiving the transmitted information. A system may comprise an O-RAN O-RU connected to an O-RAN O-DU over a fronthaul interface, where the system implements the methods described herein. A signal for transmission from an O-RAN O-RU to an O-RAN O-DU over a fronthaul interface may comprise the information sent by the O-RU as described in the preceding aspects. A computer program may comprise instructions which, when run on a processor of an O- RAN O-RU, causes the O-RU to perform the methods described herein. A computer program may comprise instructions which, when run on a processor of an O- RAN O-DU, causes the O-DU to perform the method of receiving the transmitted information. A network node may comprise a processor and memory containing instructions which when executed cause the network node to perform the O-RU methods described herein. A network node may comprise a processor and memory containing instructions which when executed cause the network node to perform the O-DU methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a block diagram for one DL beamforming implementation of O-RAN O-DU and O-RU with SRS channel estimation performed in the O-DU. Figure 2 illustrates SRS channel estimation performed in antenna space followed by transformation to beam space. Figure 3 shows SRS signals transformed to beam space before channel estimation is performed. Figure 4 depicts antenna space SRS channel estimation with optional transformation to beam space, followed by transformation to tap domain. Figure 5 illustrates SRS signals transformed to beam space with subsequent beam space channel estimation and transformation to tap domain. Figure 6 shows SRS channel estimates transformed to delay-Doppler domain using symplectic finite Fourier transform. Figure 7 depicts SRS signals transformed to delay-Doppler domain before channel estimation is performed. Figure 8 describes a generic method for receiving reference signals with optional transforming and compressing at various stages. Figure 9 provides further details of the compress / transform step shown in Figure 8. Figure 10 shows an O-RU and an O-DU connected by a fronthaul link / fronthaul interface. Figure 11 shows an example of a communication system in accordance with some embodiments. Figure 12 shows a UE in accordance with some embodiments. Figure 13 shows a network node in accordance with some embodiments. Figure 14 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized. DETAILED DESCRIPTION Figure 1 shows a block diagram for one DL beamforming implementation of O-RAN O-DU and O-RU. In this case, O-DU receives sounding reference signals (SRSs) IQ data from O- RU and performs channel estimation. The estimated channel in frequency domain is then stored in a channel state memory. The scheduler uses the channel estimates from the channel state memory to determine which users are to be served (simultaneously) in the DL on what resource elements (REs) during the next transmission time interval (TTI), e.g., a slot of 0.5 milliseconds (ms). The channel estimates from the channel state memory are also used to calculate the beamforming weights (BFWs) for the scheduled UEs based on the scheduling decision. The BFWs or the compressed BFWs are sent over the fronthaul interface to the O-RU to conduct DL beamforming. Note that the channel estimates from the channel state memory can be used for UL scheduling and positioning as well. When one DU is connected to multiple RUs, the DU capacity becomes a single point of aggregation. For time division duplex (TDD) systems, the SRS is scheduled simultaneously across the network due to the same time TDD pattern used. Additionally, the transmission window for RUs to send SRS to the DU is usually fixed, resulting in all SRS data from multiple RUs arriving at the DU at the same time. This imposes a significant processing load on the DU, as it must handle SRS for channel estimation from all RUs simultaneously. This significantly reduces the statistical multiplexing gain for DU processing, which assumes that the processing load from different RUs are not at the peak simultaneously. Given limited hardware resources in DU, this may significantly limit SRS processing capability, i.e., the number of users sending SRS, which limits the system capacity in terms of the number of served users. Also, the simultaneous transmission of SRS samples from multiple RUs to a DU limits statistical multiplexing gain in fronthaul transport when links are aggregated. Moving at least the functional unit for SRS channel estimation to the respective RU can offload the DU and thereby increase the DU capacity to process more antenna carriers and users. According to this disclosure, intermediate solutions can provide benefits in terms of balancing fronthaul load, processing load in O-DU and / or O-RU, system capacity and the possibility for central processing of information from multiple O-RUs . For example, channel estimation could be done in DU for some UEs (e.g. UEs that are within coverage range of several RUs) whereas channel estimation for other UEs (e.g. in coverage range only to a particular RU or otherwise best handled by a single RU) can be handled in the respective RU. Since the DU might still need the channel information for scheduling, and even for calculating the DL BFWs, the SRS channel estimates need to be transported from the RUs back to the DU over the fronthaul interface. The remaining problem with the SRS channel estimation residing in the RU is the increased fronthaul load since the channel estimates have a dimension proportional to the number of antennas for each SRS port and the number of SRS ports scheduled in the SRS signal. For example, it would be a lot of channel estimates data for an RU with 64 antennas when 48 SRS ports are scheduled in the SRS signal. This disclosure provides new approaches to compress the SRS channel information transporting from the RU to the DU over the fronthaul interface. An idea is to transform the frequency-domain SRS channel estimates from antenna space and / or frequency domain to other domain or space that have better energy compacting property, i.e., more energy concentrating on fewer elements after a mathematical transformation, so that only a subset of channel values (or channel coefficients) after transformation are selected to transport over the fronthaul without losing much channel information. For example, by selecting the channel values having the highest amplitude or power values. Accordingly, the fronthaul load for transporting SRS channel information is significantly saved with little performance impact. One option is to transform from antenna space to beam space with discrete Fourier transform (DFT) or any other suitable transform (e.g., singular value decomposition (SVD), eigen value decomposition (EVD), etc.) along antenna elements (or array elements). Another option is to transform from frequency domain to tap domain with discrete cosine transform (DCT) or DFT along frequency points of each antenna element (or array element). The above two options can be used together to transform the antenna space channel estimates in frequency domain to the beam space channel values in tap domain. Note that tap domain is also referred to as time domain, with respect to the channel impulse response. C-Plane implementation of transporting the compressed beam space SRS channel information is also proposed. Especially regarding dynamic beam space (e.g., SVD-based) compression scheme, two embodiments are proposed to efficiently convey beam space base vectors. The SRS channel estimates in beam space can be obtained thus in the RU: ^ Method 1: The SRS channel estimation is performed in antenna space. The channel estimates are then transformed to beam space by DFT or any other transform (e.g., SVD, EVD, etc.). ^ Method 2: The SRS signals are transformed to beam space by DFT or any other transform (e.g., SVD, EVD, etc.). and the channel estimation is performed in beam space Ways to conduct SRS compression are provided: ^ Method 1: The beam space channel is compressed by selecting channel values on a subset of beams, the number of which is smaller than the number of antennas. For example, selecting the beam-space channel values with best quality (highest amplitude or power, or highest SNR or SINR, corresponding to highest eigen values of the channel covariance). Only the selected channel values in beam space are sent to the DU. The DU may reconstruct the channel based on the received channel values and transform the channel back to antenna space. ^ Method 2: The channel estimates are transformed from frequency domain to tap domain by DCT or DFT. Note that this works for either channel estimates in antenna space or the channel values in beam space. The tap-domain channel is compressed by selecting channel values on a subset of taps, the number of which is smaller than the number of subcarriers of the sounding bandwidth. Only the selected channel values are sent to the DU. For example, selecting the tap-domain channel values with highest amplitude or power. The DU reconstructs the channel based on the received channel information and transforms the channel back to the frequency domain, and further back to antenna space if needed. ^ Method 3: The channel estimates are obtained in delay-Doppler domain. This method is more suitable when there are more than one SRS symbols configured per slot. The delay-Doppler channel is compressed by selecting a subset of entries on the delay-Doppler frame, the number of which is smaller than the full delay-time grid. Only the selected channel values are sent to the DU. The DU reconstructs the channel based the received channel information and transforms the channel back to the time-frequency basis. Note that the methods of disclosed here are also applicable for demodulation reference signal (DMRS) based channel estimates, e.g., sent from RU to DU. As described above and below, embodiments of this disclosure may provide advantages in the form of reduced fronthaul costs and hardware costs, as well as increasing system capacity. This may be achieved with no or only small trade-off with channel estimate accuracy, which in turn is important for system capacity in terms of bit rates to users, accuracy of positioning, scheduling efficiency, etc. Advantages may be achieved for example by reducing peak fronthaul traffic and peak demand for processing capacity, as well as reducing general fronthaul load and re- distributing processing load between different parts such as O-DU and O-RU. Moving SRS channel estimation from the DU to the RU offloads the DU processing demands for simultaneous SRS handling. This disclosure provides support for efficient transporting of SRS channel information from the RU to the DU, so that the DU still has access to necessary channel information for scheduling, beamforming, positioning etc. The FH traffic load for transporting SRS channel estimates can be significantly reduced. The DFT-based beam space compression is based on static beam bases (or base vectors) whereas the SVD-based or EVD-based beam space compression is based on dynamic beam bases (or base vectors). The latter scheme is likely to have the beams better aligned with the varying directions of incoming signals, and therefore has the potential to compress the SRS channel with higher compression ratio comparing to the method based on static beam bases. This advantage is at the cost of needing to transport the beam space base vectors in addition to channel IQ samples from RU to DU. Dynamic beam space compression method (e.g., SVD-based, EVD-based) in general has higher complexity than static method, since the base vectors need to be calculated, e.g., using SVD or EVD on channel covariance. In this disclosure, for both static and dynamic beam space methods, compression is done by selecting a subset of the beams to be transported over the fronthaul interface. We propose two ways of doing beam selection. The first way is to perform beam selection per port or layer channel. So, different beams may be selected for the channel of different SRS port or layer. The second way is to perform common beam selection for the channels of multiple ports or layers. In this case, the same set of the beams are selected for multiple ports or layers. Since the beam information (e.g., bitmask indicating selected beams for static beam space compression, base vectors for dynamic beam space compression) need to be sent together with the compressed channel estimates, common beam selection can reduce the amount of data for sending the beam information, while per port / layer beam selection may have better compression quality but with more data for sending the beam information. And, for dynamic beam space compression, common beam selection may have lower complexity than per port / layer beam selection. In this case, the O-RU with lower complexity can implement common beam selection. Common beam selection on a per-UE basis is particularly advantageous in that the spatial channel is likely to be similar for all the ports of the UE. That is, a same selection of beams is used for ports of the UE but typically not for other UEs, which are likely to have different spatial channels. SRS for different antenna ports of the same UE may be sent using different frequency, time and code resources. For example, two antenna ports of a UE may be sent in different REs of two comb offset. Two antenna ports of a UE may be sent in different symbols. Two antenna ports of a UE may be sent using different cyclic shifts in code domain using the REs of one comb offset in a symbol. Common beam selection could also be used for a group of UEs, e.g. UEs determined by the RU to have similar spatial channels or a number of selected beams (e.g. allowed to achieve the targeted compression ratio) could cover more than one UE with good compression quality, etc. For example, for 64 antennas RU, beam-space compression may configure to send channel estimates in 16 beams. If the channels of two UEs are very concentrated to a few beams, 16 beams may compress the channel estimates of both UEs with good quality. The C-Plane implementations proposed in this disclosure supports both common beam selection and per port / layer beams selection with one common data format, in which the channel IQ samples are conveyed separately per port while the beam space vectors can be conveyed either per port or layer or only once for the group of ports if the group of ports share the same set of base vectors. Since the base vectors per port / layer can be quite large, e.g., when the size of PRB group or subband sharing the same selected base vectors is not so big and UE has more ports, using common beam selection may save a lot of overhead for sending the beam information and increase the compression ratio. For example, for a UE with 4 SRS antenna ports, the overhead is reduced by 4 times for transporting the beam information, e.g., the base vectors when common beam selection is used. In addition, repeating the same selected beam vectors is unnecessary which may take more O-DU processing resources (e.g., it has to read several times the same base vectors and store them for decompression). Benefits of transporting SRS channel estimates from RU to DU When the “SRS channel estimation” functionality is moved to the RU, it may consider as logical to also move the “BFW calculation” functionality to the RU, thereby eliminating the need to send SRS channel estimates from the RU to the DU. It seems cost efficient from the fronthaul interface perspective since neither SRS data nor SRS channel estimates are transported over the fronthaul. However, retaining the SRS channel estimates in the DU offers several distinct advantages. Consider the form factor and power consumption requirements of RU, allocating the BFW calculation functionality in addition to channel estimation function adds significant processing loads to the RU. Some RUs may not be capable to handle both functionalities at the same time. In this case, DU needs to calculate the beamforming weights (e.g., using channel estimates sent from RU). In a multi-transmission / reception point (multi-TRP) deployment, multiple RUs are connected to a common DU. It is advantageous for the DU to get the channel information from each RU and calculate beamforming weights using the channel information of all RUs together, rather than having each RU calculate local BFWs independently, as the former approach can achieve better performance due to coherent transmission gain. This is also applicable to RUs connected to the same DU performing Coordinated Multi-Point (CoMP). When it comes to implementations such as UE positioning and scheduling, the DU’s higher computational capacity enables it to conduct more advanced algorithms to achieve the desired objectives. For example, for scheduling, the DU can make use of the channel information to calculate the channel similarities between UEs with data to transmit in the buffer and determine how to group them for MU-MIMO. For positioning, the channel information can be further sent to external servers or Cloud which have even more resources to use even more advanced approaches, e.g., using AI, to further improve UE positioning accuracy. If RU performs SRS channel estimation and calculates the beamforming weights, RU needs to store the SRS channel estimates of all connected UEs in the cell (e.g., including all active and idle UEs). The number of served UEs may increase in time. This could be an issue that the system capacity in the number of users to be served is limited by the memory of the RU. One way to overcome this is that the channel estimates of some UEs are stored in the RU and the channel estimates of other UEs are stored in the DU. This will increase the system capacity by using the memory of both RU and DU, without the need to replace the existing RU. All the implementations mentioned above rely on high-accuracy channel information. It is essential to provide the DU with as much channel information as possible while minimizing the required fronthaul bandwidth for its transmission. Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. SRS channel compression We consider that the “SRS channel estimation” functionality in Figure 1 is moved from the DU to the RU, In this case, the SRS channel estimates need to be transported from the RU to the DU for scheduling, calculating DL BFWs in DU, among others. Consider the scenario with ^^ antennas per RU and the SRS sounding bandwidth contains ^^ subcarriers. Each SRSport will generate ^^ ൈ ^^ channel values to be transported.One way to reduce the data amount is to transport one set of ^^ channel values per several subcarrier instead of for each subcarrier. For example, ^^ channel values per physical resource block (PRB) bundle where one PRB bundle contains one or multiple PRBs. In this case, any further fronthaul load reduction requires a larger PRB bundle size, which typically introduces performance degradation since more channel information is lost by performing such even-spaced down-sampling in frequency. We propose new methods to reduce the fronthaul load for transporting SRS channel estimates from the RU to the DU. The new methods make use of channel properties in other domains to achieve a higher reduction on the required fronthaul load for transporting SRS channel estimates while keep higher quality of channel information. Such methods are referred to as SRS channel compression methods in this document. Embodiment #1: The beam-space channel typically has the energy concentrated in a limited number of beams, where the number is much smaller than the number of RU antennas. This is due to the fact that signals coming from a certain user are typically concentrated in certain directions, e.g., from the direction of Line of Sight (LoS), from the directions of other major reflectors in the environment, etc. For example, transforming from antenna space to beam space can be achieved by performing DFT spatially over the attributes, e.g., channel estimates, received IQ samples, etc., of all antennas. The SRS channel estimates in beam space can be obtained in two ways. The first option is shown in Figure 2, where the SRS channel estimation is firstly conducted in antenna space. Basically, performing SRS channel estimation on the SRS signal received from each antenna element. The antenna space channel estimates represent the channel coefficients from the UE transmit antenna elements to the RU receive antenna elements. Then the channel estimates are transformed to beam space by performing DFT on the channel estimates of all antenna elements. Effectively, the DFT operation forms a number of DFT beams. Each beam is formed by one DFT basis vector. After DFT, the beam space channel coefficients represent the channel coefficients from the UE transmit antenna elements to the beam ports formed by the DFT beams. Another option is shown in Figure 3, where the SRS signals are firstly transformed to beam space by performing DFT on the SRS signal received from all antenna elements. Each beam-space SRS signal represents a beamformed SRS signal using a DFT beam. And then the beam-space SRS signals are used for channel estimation to obtain the beam-space SRS channel estimates. Note that DFT beams are given here as an example. The beams using other mathematical transformations can be used as well. These beams can be also customized beams determined by the DU or determined by the RU. Specifically, for DFT beams, different variants, which are optimized for different antenna array configuration, can be used by both RU and DU. Let ^^^denote an ^^-point DFT matrix, where the entry on the ^^-th row and ^^-th column of ^^^is expressed as For ^^ antenna ports with ^^ polarizations, ^^ vertical antenna ports and ^^ horizontalantenna ports such that ^^ ൌ ^^ ൈ ^^ ൈ ^^, different variants of beam-space transformationmatrix ^^ ∈ ℂேൈே can be composed as: where ^ denotes Kronecker product. The RU and DU may need to coordinate about which transformation matrix is to be used so that DU applies the corresponding inverse transformation of the transformation applied by the RU. In this case, each column of ^^ is one (static) base vector that defines a beam. The ^^ beams defined by ^^ are mutually orthogonal and thereby span a predefined beam space. After beam-space channel estimates are obtained, the channel compression of this can bedone by selecting ^^ entries, where ^^ ^ ^^, i.e., R values of beam-space channel estimatesare selected. Note that ^^ ൌ ^^ can be also allowed when DU only wants RU to providebeam space channel estimates without compression. The beam-space channel estimates may be per subcarrier or multiple subcarriers, e.g., the subcarriers in a PRB bundle. Then, the selected beam-space channel estimates are sent from the RU to the DU. Those subcarriers can be a subset of all subcarriers of the sounding bandwidth. The selected ^^ entries should try to gather as much energy of the channel as possible, for example, by selecting the ^^ entries with largest amplitude or power values. In one embodiment, the selections of ^^ entries are performed independently on each selected subcarrier (or on each PRB bundle containing multiple subcarriers) and / or for each SRS port. The value of ^^ may be different regarding different subcarrier (or PRB bundle) or different SRS port. For example, the selection is based on a certain power threshold. In another embodiment, a fixed number of ^^ entries to be selected are configured. The actual selected ^^ entries may be different regarding different subcarrier (or PRB bundle) or different SRS port. In another embodiment, one common selection of ^^ entries is performed regarding all selected subcarriers (or PRB bundle) and for all SRS ports. Another implementation of beam-space channel compression is done on channel estimates from a low-complexity channel estimation algorithm, which we refer to as raw channel estimates. Note that the raw channel estimates can be further improved by applying more advanced channel estimation algorithm. The channel estimates obtained from the more advanced channel estimation algorithm are those that will be transported over FH from RU to DU. In this case, the more advanced channel estimation is only performed on beam- space channel of the selected beams and thereby it saves computational resources for performing more advanced channel estimation. For example, the raw channel estimates can be then obtained by performing matched filter with the original SRS sequence known by DU. If the SRS signals are in beam space, the obtained raw channel estimates will be in beam space. If the SRS signals are in antenna space, the obtained raw channel estimates will be in antenna space. In the latter case, the raw channel estimates are then transformed to beam space. ^^ beams are selected based on the raw channel estimates. The remaining steps of channel estimation are performed only with respect to the ^^ selected beams. The information of the beam selection is also sent from RU to DU so that the DU can reconstruct the full beam-space channel with the received reduced channel values. For example, the full beam-space channel can be reconstructed by using 0s for the unselected channel entries. The information of the beam selection is sent as well, for example, with bitmask or beam indices. Then the beam-space channel is transformed back to antenna- element domain and saved in the DU channel state memory. Another implementation example is that RU determines the transformation beams, uses the determined beams to obtain the beam space channel estimates and send only the channel estimates of the beams with the largest channel estimate values in amplitude or power from the RU to the DU and also the information indicates which beams are selected. In addition to the reduced channel estimates, RU also sends the weights or coefficients of determined beams used for beam space transformation to the DU. Then, the DU may use the received weights to transform the channel estimates back to antenna space as needed. The RU can make sure that the beam weights are invertible. Yet another implementation example is that RU determines the transformation beams, uses the determined beams to obtain the beam space channel estimates and send the beam space channel estimates transformed using the determined beams from the RU to the DU and also the information indicates which beams are selected. The number of determined beams is less than the number of antennas. And the determined beams capture most of channel energy and therefore keeps good quality of channel information. In addition to the reduced channel estimates, RU also sends the weights or coefficients of determined beams (e.g., beam space base vectors, or shortly base vectors) used for beam space transformation to the DU. Then, the DU may use the received weights to transform the channel estimates back to antenna space as needed. The RU can make sure that the beam weights which compose beam space base vectors are invertible. As examples, RU can use single value decomposition (SVD) or eigen value decomposition (EVD) to generate SVD beams or EVD beams for beam space transformation. In one implementation, RU performs SVD or EVD on the covariance matrix of the channel estimates to obtain the SVD or EVD beams. The beam space compression is achieved by selecting the channel coefficients on beams that correspond to some largest singular values or eigen values. Therefore, the number of the obtained SVD or EVD beams is less than the number of antennas. Then, multiply antenna space channel estimates of each PRB bundle or selected subcarriers with the beam weights of the obtained SVD or EVD beams to obtain the beam space channel estimates. Let ^^^^^^ denote a channel estimate obtained on resource element (RE) / subcarrier ^^. A covariance matrix of the channel estimates of certain PRBrange or selected subcarriers may be obtained by ^^ ൌ ^^^^^^ ^^ு^^^^. If the PRB rangeincludes all PRBs, it is usually referred to wideband covariance. If the PRB range includes a subset of PRBs, it is usually referred to subband covariance. Accordingly, conduct SVD of^^ ൌ ^^^^^^ு and use the unitary and mutually orthogonal column vectors of the ^^ (i.e., theleft singular vectors of ^^) as the dynamic base vectors. Comparing to the static base vectors which span a predefined beam space, the dynamic base vectors are obtained based on the instantaneous channel estimates, so they span an optimal eigenspace for the current channel and are tuned to the best extent aligned with the dominant directions of signal energy. When projecting channel coefficients into such a beam space, the channel can be efficiently represented by a linear combination of only a limited number of beams, each beam corresponding to one base vector. Alternatively, if the covariance matrix of the channel estimates is calculated with the raw SRS channel estimates (e.g., obtained by performing matched filter with SRS sequences), the SVD or EVD beams can be applied to SRS signal to obtain the beam-space SRS signal and then perform channel estimation on the beam-space SRS signal to obtain the beam- space SRS channel estimates. The beam weights of the SVD beams (e.g., the left singular vectors) or EVD beams (e.g., the eigenvectors) are sent to the DU such that the DU can transform the beam-space channel estimates back to the antenna-space channel estimates since the singular vector matrix or the eigenvector matrix is invertible. As described before, for both static and dynamic beam space methods, we propose two ways of doing beam selection. The first way is to perform beam selection per port or layer channel. So, different beams may be selected for the channel of different SRS port or layer. The second way is to perform common beam selection for the channels of multiple ports or layers. In this case, the same set of the beams are selected for multiple ports or layers. Since the beam information (e.g., bitmask indicating selected beams for static beam space compression, beam base vectors for dynamic beam space compression) need to be sent together with the compressed channel estimates, common beam selection may reduce the amount of data for sending the beam information, while per port / layer beam selection may have better compression quality but with more data for sending the beam information. The beam space channel estimates of each port / layer may be obtained by multiplying the antenna space channel estimates of the corresponding port / layer with the selected beams or base vectors. In addition, the beam selection may be done in wideband or in subband. In wideband beam selection, the same selected beams are used for all PRBs whereas in subband beam selection the selected beams may be different for different PRB groups (i.e., different subbands). As one implementation example of the proposed dynamic beam space compression method in this disclosure, base vectors are obtained by conducting SVD or EVD on the channel covariance of SRS channel. For per port or layer beam selection, the channel covariance is calculated by per port or layer channel. Then, the base vectors for channel variances for different ports or layers are different, because the channel covariances are different for different ports or layers. So, the selected beams are different on each channel covariance for each port or layer channel. For common beam selection, the channel covariance is calculated using the channels of multiple SRS ports or layers. In this way one set of base vectors are calculated since one channel covariance is calculated for the channels of these ports or layers. In addition, common beam selection has lower complexity since only one SVD or EVD is performed for one channel covariance, while multiple SVD or EVD are performed in per-port / layer beam selection. So, it is suitable for O-RU with lower complexity. More details of the C-Plane implementations regarding conveying both the beam space SRS channel estimates and the beam weights of the beams (i.e., the beam space base vectors) are provided further below. As a further example, DU can determine the beams and send the beam weights to the RU to perform beam space transformation and compression. For example, DU can rely on historical channel information to determine the beams, e.g., using SVD and EVD. For beam selection step, it can be done in the DU where DU will send only the beam weights of the selected beams. Beam selection can be also done by RU where DU sends the beam weights of all beams and RU performs the selection. The methods described above performs beam space compression to SRS channel estimates. One more possible implementation is to use the beam space compression to compress SRS IQ data. Basically, RU performs antenna-space to beam-space transformation for the received SRS IQ data to obtain the beam-space SRS IQ data. Then, RU will send SRS IQ data of some beams to compress the SRS IQ data and reduce the fronthaul load. As described before, either RU or DU can determine the beam weights used for the transformation. The beam selection can be done by either RU or DU in different cases as described before. If RU determines beam selection, RU can perform SRS channel estimation (raw or full channel estimation) to determine it. RU can also perform DMRS channel estimation and use the DMRS channel estimates to determine the beam selection. Compressing SRS IQ data is useful when RU can only do simple SRS channel estimation due to its HW constraints, where the channel estimates are not good for calculating beamforming weights, but good for beam selection. It can also rely on the power of the beam space SRS IQ data to select the beams, for DFT-based method. For SVD or EVD based method, the covariance matrix of SRS IQ data may be used for obtaining the SVD or EVD beams for beam space compression. It would be also beneficial when sending compressed SRS IQ data takes less FH bandwidth than sending compressed SRS channel estimates. This may happen when the SRS signal carries many ports. Embodiment #2: It is observed that some Fourier-related transforms, for example DCT or DFT, has good energy compacting feature after transforming the frequency responses, such as the SRS channel estimates obtained at the RU, to impulse responses of the channel. The DCT or DFT impulse responses are referred to as channel taps in the tap domain. The tap-domain channel energy can be concentrated in a limited number of taps while the remaining taps containing mostly the noise. Each tap can be seen as the channel coefficient for a multipath component. Typically, DCT compacts the channel energy better than DFT, and transforming from beam-space channels compacts the channel energy better than that from antenna space. Consider that SRS is used to probe the overall channel conditions, covering a wide bandwidth of the carrier. Usually, SRS signal per UE is sent in all PRBs of the carrier bandwidth. This makes the tap-domain compression particularly suitable for compressing SRS-based channel estimates, which can achieve a high compression ratio, since the high bandwidth gives higher tap-domain resolution. With higher tap-domain resolution, there are more taps having small values which can be removed. Similarly to Embodiment #1, in one option, SRS channel estimation has antenna space SRS signals as input. Optionally, the antenna space SRS channel estimates can be further transformed to beam space, as shown in Figure 4. In another option, the SRS signals are firstly transformed to beam space. Accordingly, the SRS channel estimation outputs beam space channel estimates, as shown in Figure 5. The channel estimates of each antenna or each beam over multiple subcarriers or frequency points are then transformed to tap-domain by DCT or DFT along the subcarriers or frequency points. The transformation may use some or all subcarriers where the channel estimation has been conducted. In some implementation, channel estimation is already done in tap-domain. In this case, this step is included in the channel estimation process.The tap-domain channel compression is done by selecting ^^ taps, where ^^ ^ ^^, for eachantenna element or beam. The ^^ selected taps can be entries with the largest power / amplitude. The value of ^^ can be different or the same for the ^^ antenna elements or beams. Only the selected taps are sent from the RU to the DU. The information of the tap selection is sent as well, for example, with bitmask, or tap indices, and is also sent from the RU to the DU together with the selected channel taps. After receiving the selected (i.e., compressed) tap-domain channel data together with the information of selection, the DU reconstructs (i.e., decompress) the tap-domain channel by, for example, filling 0s among the received channel tap values according to the bitmask or tap indices. Then the channel is transformed back to frequency domain by IDCT or IDFT. If beam-space channel is obtained, the DU can further transform it back to antenna pace. The antenna space channel data can be stored in the channel state memory for, for example, scheduling or DL BFWs calculation. Another use case of getting the tap domain channel estimates is for positioning or localizing a connected UE. Since the channel taps represent the multipath components, using channel taps one can also determine the relative arrival time of the UE signal at an antenna or a beam port, relative to the start time of the OFDM symbol window for performing OFDM FFT. In this use case, RU may send only the channel values of some taps around the tap with highest power for a few antennas or beams. DU can use the received channel values of these taps to determine the relative arrival time and therefore determine the location of the UE with the determined relative arrival time of multiple RUs for the same UE. Getting multiple taps around the peak helps to use more advanced algorithms to get better accuracy, especially when there are multiple multipath components that arrive in a cluster very close in time. Embodiment #3: The channel compression can be done both in beam space and in tap domain. In one embodiment, the selection is firstly done in beam space, then in tap domain. In another embodiment, the selection is firstly done in tap domain, then in beam space. Embodiment #4: The delay-Doppler domain is characterized by the relative delay of scatters or reflectors and their velocity (i.e., the Doppler shift) with respect to the receiver. It reflects the geometry of the scatters or reflectors which changes more slowly comparing to the rapid changing channel characteristics in time-frequency domain. Therefore, the channel representation in delay-Doppler domain is typically a sparse matrix (i.e., the channel values are mostly around 0 except for a few non-zero entries representing the scatters or reflectors). In one implementation as in Figure 6, the SRS channel estimates is transformed to delay- Doppler domain by the symplectic finite Fourier transform (SFFT). In another implementation as in Figure 7, the SRS signals are firstly transformed to the delay-Doppler domain and then the delay-Doppler channel is estimated. The delay-Doppler domain compression is done by selecting a subset of ^^ channel entries in the delay-Doppler frame for each SRS port. The ^^ selected entries can be ones with the largest power / amplitude. The value of ^^ can be different or the same for different SRS port. Only the selected entries are sent from the RU to the DU. The information of the delay-Doppler domain selection is sent as well, for example, with bitmask, or entry indices, and is also sent from RU to DU. After receiving the selected (i.e., compressed) delay-Doppler domain channel data together with the information of selection, the DU reconstructs (i.e., decompress) the delay-Doppler domain channel by, for example, filling 0s among the received non-zero channel data according to the bitmask or entry indices. The channel then is transformed back to time- frequency domain by inverse SFFT (ISFFT). The channel data will be stored at the channel state memory for, for example, scheduling or DL BFWs calculation. Proposed O-RAN C-Plane implementation of conveying compressed beam space SRS channel estimates Conveying the compressed beam space SRS channel estimates from O-RU to O-DU can reuse Section Type 6 (ST-6) defined in O-RAN open fronthaul specification [1]. Table 1 shows the ST-6 defined in the current specification [1]. Table 1: ST-6 frame format Section Type 6: channel information conveyance 0 (msb) 1 2 3 4 5 6 7 (lsb) # of byt es transport header, see clause 5.1.3 8 Octet 1 dataDire payloadVersion filterIndex 1 Octet 9 ction frameId 1 Octet 10 subframeId slotId 1 Octet 11 slotId startSymbolId 1 Octet 12 numberOfsections 1 Octet 13 sectionType = 6 1 Octet 14 numberOfUEs 1 Octet 15 ciCompHdr 1 Octet 16 ef ueId[14:8] 1 Octet 17 ueId[7:0] 1 Octet 18 regularizationFactor 2 Octet 19 reserved rb symInc startPrbc 1 Octet 21 startPrbc 1 Octet 22 numPrbc 1 Octet 23 ciCompParam (for the first PRB or all PRBs of the first UE, not var Octet always present) 24 ciIsample (first PRB, first antenna) var ciQsample (first PRB, first antenna) var ciIsample (first PRB, second antenna) var ciQsample (first PRB, second antenna) var … ciIsample (first PRB, last antenna) var ciQsample (first PRB, last antenna) var … ciCompParam (for the last PRB, not always present) var ciIsample (last PRB, last antenna) var ciQsample (last PRB, last antenna) var <padding with zeros to the next 4-byte boundary> may not be var present (NOTE 2) Section Extensions as indicated by "ef" var … ef ueId[14:8] 1 Octet N ueId[7:0] 1 N+1 regularizationFactor 2 N+2 Reserved rb symInc startPrbc 1 N+4 startPrbc 1 N+5 numPrbc 1 N+6 ciCompParam (for the first PRB or all PRBs of the last UE, not var N+7 always present) ciIsample (first PRB, first antenna) var ciQsample (first PRB, first antenna) var ciIsample (first PRB, second antenna) var ciQsample (first PRB, second antenna) var … ciIsample (first PRB, last antenna) var ciQsample (first PRB, last antenna) var … ciCompParam (for the last PRB, not always present) ciIsample (last PRB, last antenna) var ciQsample (last PRB, last antenna) var <padding with zeros to the next 4-byte boundary> may not be var present (NOTE 2) Section Extensions as indicated by "ef" var NOTE 1: shading: yellow is transport header, pink is radio application header, others are repeated sections. NOTE 2: "may not be present" depends on O-RU Boolean flag "st6-4byte- alignment-required". NOTE 3: The remainder of N divided by 4 is 1 if 4-byte alignment is to be used. Note that the field “ciCompParam (for the first PRB or all PRBs of the first UE)” in Table 1 is an error in the current O-RAN WG4 specification. The first UE should be “the first ueId”. In O-RAN, the unsigned-integer bits of the ueId can be partitioned such that the least- significant bits (LSBs) enumerate layers per UE while the remaining most-significant bits (MSBs) enumerate UEs. The channel information in ST-6 is conveyed per ueId. When conveying SRS channel estimates from O-RU to O-DU, the channel information may be presented per SRS antenna port. In this case, one option can be to use the “ueId” field to represent the port identification, for example, using the LSBs (least significant bits) to enumerate SRS antenna ports and using MSBs (most significant bits) to enumerate UEs. Another option is to use the “ueId” field only for enumerating UEs and use the “reserved” field or even the 2 bytes currently used for “regularizationFactor” field to carry the UE antenna port information, e.g., UE antenna port ID. When conveying SRS channel estimates, regularization factors will not be sent from O-RU to O-DU, therefore, the ”regularizationFactor” field can be used for other purpose. In ST-6, also note that each ciCompParam field applies for one port or layer, which is not for each UE, though it states for a UE, e.g., “the first UE”, “the last UE”. This will be corrected in the spec. To inform the O-DU about the compression information, the ciCompMeth field in ciCompParam can be extended with static (e.g. DFT-based) and dynamic (e.g. SVD-based or EVD-based) beam space compression methods. In the following, ^^ indicates the numberof antenna elements or the number of beams before compression, ^ത^ indicates themaximum number of beams the O-RU can support (where ^ത^ ^ ^^), and ^^ indicates thenumber of selected beams configured by the O-DU. Add new ciCompMeth in ciCompHdr in ST-6 In Table 2, two new compression methods are added for static beam space compression method (e.g., DFT-based) and dynamic beam space compression method (e.g., SVD-based) respectively. For both methods, O-RU may via M-Plane declare the maximum number ofbeams, referred to as ^ത^, it can support for reporting beam space SRS channel estimates. O-DU may configure via M-Plane the maximum number of beams that O-RU can use. O-DUmay also configure, via either M-Plane or C-Plane, the number of beams ^^ (for ^^ ^ ^ത^) thatthe O-RU will select from the ^^-beam SRS channel estimates of each SRS port and send back to the O-DU. O-DU control of the number of beams can make the FH data rate more deterministic, which is good for O-DU processing resource planning and FH network dimensioning

[0002] Table 2: ciCompMeth definition ciCompMe compression method ciIqWidth meaning th 000b no compression bitwidth of each uncompressed I and Q value 001b block floating point bitwidth of each I and Q mantissa value 010b block scaling bitwidth of each I and Q scaled value011b^-lawbitwidth of each compressed I and Qvalue 100b static beamspace (e.g., bitwidth of each beamspace I and Q DFT-based) coefficient 101b dynamic beamspace bitwidth of each beamspace I and Q (e.g., SVD-based) coefficient 110b –111b reserved for future depends on the specific compression methods method For DFT-based static beam space compression method, the O-DU can have the knowledge of beam space base vectors, for example, derived based on the reported O-RU capabilities such as array size or other M-Plane information. In this case, the O-RU does not need to send the beam space base vectors to the O-DU in C-Plane. The selected beams can be conveyed by a bitmask. The proposed ciComParam definition for the static beam space compression method is presented in Table 3. Table 3: ciCompParam definition for static beamspace method ciCompMeth 0 1 2 3 4 5 6 7 ciCompPara (msb) (lsb) m size 100b = static activeBeamspaceCoefficientMask ceil(K / 8) beamspace (e.g., octets DFT-based) (see NOTE 1) reserved (set to all zeros) exponent (unsigned) 1 octet (see NOTE 2) NOTE 1: K is the number of elements in uncompressed channel information vector. K is O-RU-specific and is calculated from parameters describing tx- array or rx-array, conveyed from the O-RU to the O-DU via the M-Plane as part of the initialization procedure. NOTE 2: For ciCompMeth value 100b and 101b, block floating point compression is used for the beamspace coefficients. For SVD-based dynamic beam space compression method, the beam space base vectors may be unique to each UE or UE port or layer and change when the channel changes, e.g., due to mobility. Therefore, the O-RU needs to send the beam space base vectors to the O- DU for the latter to transform the compressed beam space SRS channel estimates back to antenna space. To obtain the base vectors, covariance matrix over a certain PRB range may be calculated. The covariance matrix can either be calculated per port / layer for per- port / per-layer beam selection or jointly for multiple ports for common beam selection. If the covariance matrix is calculated per port / layer, different port / layer will use different sets of base vectors. If the covariance matrix is calculated jointly for multiple ports / layers, multiple ports / layers will share the same set of base vectors. Note that the channel IQ samples as in ST-6 of Table 1 is conveyed per port or per layer. For the case when multiple ports sharing the same set of base vectors, this disclosure proposes two embodiments to efficiently convey both channel IQ sample and base vectors, without the need to repeatedly send the same beam information. The same schemes also work for the case when both channel IQ samples and base vectors should be conveyed per port / layer. Another special aspect is the mapping between base vectors and channel IQ samples.When a dual polarized antenna array is used, in some examples, a full dimension ^^ ൈ ^^covariance matrix is used to conduct the SVD which yields base vectors of length ^^. In other examples, the characteristics that the two antenna polarizations are spatially highly correlated is utilized. The SRS channel estimates of ^^ antenna elements can be separated into two half-sized matrices, one for each polarization. Accordingly, each of the half-sized matrices are used to calculate one covariance matrices of size ^^ଶൈଶ. The beam space base vectors of dimension ^^ / 2 are then obtained by conducting SVD of a covariance matrix which is averaged over the two covariance matrices of the two polarizations. Since the base vectors are in length ^^ / 2, the beam vectors will be applied to the channel IQ samples of ^^ / 2 antennas of each polarization to obtain the corresponding beam space channel IQ samples of the antennas of each polarization. To indicate using full-length or half-length base vectors, a field “mappingType” is added in ciCompParam. Embodiment 1: convey dynamic beam space base vectors in ciCompParam of ST-6 As ciCompParam is present at the beginning of the section for each port, this disclosure introduces an “reuseFlag” field for the dynamic beam space compression method in ciCompParam to indicate whether a new set of base vectors is attached, or one should reuse a previously conveyed set of base vectors. For example, when reuseFlag = 0b, a new set of beam space base vectors is attached. In this case, block floating point compression may be used for the base vector coefficients and all coefficients in one base vector (i.e., composing one beam) may be one block to share a common exponent. The base vector coefficients are expressed by “bvIsample” and “bvQsample” where “bvIsample” indicates base vector in-phase value and “bvQsample” indicates base vector quadrature value. One example of the corresponding ciCompParam definition is shown in Table 4. When reuseFlag = 1b, the channel IQ samples of this port are based on the same set of base vectors which has been conveyed in the latest section whose reuseFlag = 0b in ciCompParam. Then, the O-DU knows that it will use the previous base vectors to decompress the channel IQ samples back to antenna space. One example of the corresponding ciCompParam definition is shown in Table 5. Table 4: ciCompParam definition for dynamic beam space compression method with reuseFlag = 0b ciCompMeth 0 1 2 3 4 5 6 7 ciCompPara (msb) (lsb) m size 101b = dynamic reuse mappingTyp nrofActiveBeams 1 octet beamspace (e.g., Flag= e SVD-based) 0b nrofActiveBeams (not always present) ceil(( logଶ^^ത^ ^1^ െ 5) / 8)octets if ^ത^≥25reserved (set to all zeros) exponent (first beam, 1 octet unsigned) bvIsample (first beam, first coefficient) var bvQsample (first beam, first coefficient) var bvIsample (first beam, second coefficient) var bvQsample (first beam, second coefficient) var … bvIsample (first beam, last coefficient) var bvQsample (first beam, last coefficient) var reserved (set to all zeros) exponent (second beam, 1 octet unsigned) bvIsample (second beam, first coefficient) var bvQsample (second beam, first coefficient) var … bvIsample (last beam, last coefficient) var bvQsample (last beam, last coefficient) var Table 5: ciCompParam definition for dynamic beam space compression method with reuseFlag = 1b ciCompMeth 0 1 2 3 4 5 6 7 ciCompPara (msb) (lsb) m size 101b = dynamic reuse mappingTyp nrofActiveBeams 1 octet beamspace (e.g., Flag= e SVD-based) 1b nrofActiveBeams (not always present) ceil(( logଶ^^ത^ ^1^ െ 5) / 8)octets if ^ത^≥25 Other fields: ^ mappingType: indicates how to map the channel IQ samples to the base vectors per beam. For example, mappingType = 00b means one-to-one mapping where the channel IQ samples have equal length as the base vector per beam; mappingType = 01b means one half and the other half of the channel IQ samples maps to the base vectors respectively where the base vectors are half of the length of the channel IQ samples, etc. ^ nrofActiveBeams: indicates the number of selected beams For the case of per-port / per-layer beam selection where different ports use different sets of base vectors, reuseFlag = 0b for all ports. For the case of common beam selection where multiple ports share the same set of base vectors, this reuseFlag = 0b is typically used at the first port while the remaining ports can use reuseFlag = 1b to avoid repeating the shared information and therefore can save the fronthaul data rate. Embodiment 2: convey dynamic beam space vectors in a new section extension to ST-6 In this case, the ciCompParam may only contain the information of the mappingType between base vectors and channel IQ sample as well as the number of selected beams, as exemplified in Table 6. One example of the section extension structure is shown in Table 7. Table 6: ciCompParam definition for dynamic beam space compression method when using SE-XX ciCompMeth 0 1 2 3 4 5 6 7 ciCompPara (msb) (lsb) m size 101b = dynamic mappingTyp nrofActiveBeams 1 octet beamspace (e.g., e SVD-based) nrofActiveBeams (not always present) ceil(( logଶ^^ത^ ^1^ െ 5) / 8)octets if ^ത^≥25 Table 7: Dynamic beam space compression section extension structure (Section Extension XX) 0 # of (msb) 1 2 3 4 5 6 7 (lsb) bytes Octet Ef extType = XX 1 Octet N extLen 1 Octet N+1 reserved (set to all zeros) exponent (first beam, unsigned) 1 bvIsample (first beam, first coefficient) var bvQsample (first beam, first coefficient) var bvIsample (first beam, second coefficient) var bvQsample (first beam, second coefficient) var … bvIsample (first beam, last coefficient) var bvQsample (first beam, last coefficient) var reserved (set to all zeros) exponent (second beam, 1 unsigned) bvIsample (second beam, first coefficient) var bvQsample (second beam, first coefficient) var … bvIsample (last beam, last coefficient) var bvQsample (last beam, last coefficient) var For the case when different ports use different sets of base vectors, SE-XX is attached to the section of each port. For the case when multiple ports share the same set of base vectors, this SE-XX is only attached to the section of the first port. Sections of other ports that do not have SE-XX convey the channel IQ samples based on the same set of base vectors which has been described in the latest SE-XX. U-Plane implementation of conveying compressed beam space SRS IQ samples Similar scheme as proposed for compressing channel IQ samples (or channel estimates) can be used to convey compressed beam space SRS IQ samples in U-Plane messages from O-RU to O-DU. Instead of ciCompParam, udCompParam in U-Plane messages can be used to convey beam space compression information for SRS IQ samples, with extension in udCompMeth to include static beam space method similar to Table 3 and dynamic beam space method similar to Table 4 and Table 5 to convey base vectors. And the beam space compression may be done for REs in the same comb offset. So different beams or beam space base vectors may be selected for the REs in different SRS comb offset. Performing beam selection for each comb offset may compress more by selecting fewer beams because each comb offset may carry a few UEs, which may be more concentrated spatially in a few beams. For SRS IQ sample beam space compression, O-DU sends the SRS configuration to the O- RU. Then, the O-RU may perform beam selection, e.g., selecting base vectors, for each SRS comb offset, using the received IQ samples of the REs in each SRS comb offset, where the comb offset information is obtained from the received SRS configuration. As described before, the beam selection may be done with static beam space base vectors or dynamic beam space base vectors. And the beam selection may be done in wideband or in subband. In wideband beam selection the same selected beams are used for all PRBs whereas in subband beam selection the selected beams may be different for different groups of PRBs (i.e., different subbands). Then, the O-RU may send the beam space SRS IQ samples of a subset of the beams, where the definition of each beam is conveyed additionally by base vectors. The beam space SRS IQ samples of each beam is obtained by multiplying the received SRS IQ samples with each base vector. The O-DU receives the beam space SRS IQ samples and may perform beam space decompression, i.e., transforming the beam space SRS IQ samples back to the antenna space SRS IQ samples using the selected base vectors. In one example of static beam space compression using static base vectors, the beam space SRS IQ samples of each beam is obtained by multiplying the received SRS IQ samples with each static base vector. The O-RU may calculate, for each SRS comb offset, the signal power or energy of the beam space SRS IQ samples on each beam and select, for each SRS comb offset, a subset of beams which have the highest signal power or energy . Then, the O-RU may send to O-DU the beam space SRS IQ samples of the selected beams. In one example of dynamic beam space compression using dynamic base vectors, the O- RU may calculate the SRS IQ covariance for the REs of each SRS comb offset, using the REs in each SRS comb offset. Then, the O-RU may calculate SVD or EVD of the SRS IQ covariance per SRS comb offset and select a subset of the SVD or EVD base vectors corresponding to the highest singular / eigen values. The O-RU obtains the beam space SRS IQ samples of the selected subset of the base vectors for the REs of each comb offset based on the calculated base vectors and send them to the O-DU. Alternatively, for both static and dynamic beam space compression, the O-RU may perform SRS channel estimation and use the channel estimates for beam selection, e.g., selecting base vectors. Then, the O-RU obtains the beam space SRS IQ samples using the selected base vectors. The benefit is that beam selection may be more accurate which is less sensitive to interference and path loss differences between UEs. But the O-RU needs to do more processing. To reduce the processing, the O-RU may use channel estimation algorithms with lower complexity algorithms. For example, using matched filter by multiplexing the received SRS IQ samples with the original SRS IQ data generated by the O-RU using the received SRS configuration. The output of the matched filter is so-called raw channel estimates which may be further refined by noise suppression techniques. Using the raw channel estimates for beam selection can improve beam selection quality without adding too much additional processing complexity, when compared with using SRS IQ samples. For clarity and ease of understanding, a number of embodiments have been described. However an embodiment may be further modified by including details from one or more other embodiments, such as by introducing a further type of transform or compressing at a different stage. For example, performing successive different transformations with or without compression before or after transforming. In the given tables of message formats, the order of the parameters may be changed, and some parameters may be omitted or added. Transforming one or more times may be made before channel estimation, after channel estimation or both, and also between different stages of channel estimation. After each transform, compression may or may not be made. Compression can be made by removing elements of low energy in the domain that the SRS or channel estimate has been transformed to. For example by removing elements whose energy is less than a threshold, by removing a certain number of elements of low energy or keeping a certain number of elements with high energy, by removing or keeping elements corresponding in total to a certain energy or a certain proportion of a total energy. Application of the ideas presented herein to an O-RAN O-DU and an O-RAN O-RU has been described, however it will be understood that the same concept can be applied in general to any arrangement of a radio unit and a digital unit or BBU connected by a fronthaul link where transformed and / or compressed reference signals such as SRS or DMRS, or channel estimates may be sent between them. The O-DU can be implemented as a virtualized O-DU in a Cloud environment. Figure 8 describes a generic method where a reference signal is received, and transforming and compressing are optionally made at various stages. The “compress / transform” step of figure 8 is further described in Figure 9. Dashed boxes indicate optional steps, dashed arrow lines indicate optional repeats. At least one transform and one compression need to be made. Transforms may be any one of the transforms mentioned above, and need not be the same one if the transform step is repeated. Particular methods have been described herein and may be modified within the bounds of the generic method using e.g. the mentioned transforms and compression methods. Figure 11 shows an example of a communication system 100 in accordance with some embodiments. In the example, the communication system 100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 102, including one or more network nodes 110 and / or core network nodes 108. Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system. The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102. In the depicted example, the core network 106 connects the network nodes 110 to one or more host computing systems, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g., core network node 108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF). The host 116 may be under the ownership or control of a service provider other than an operator or provider of the access network 104 and / or the telecommunication network 102. The host 116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. As a whole, the communication system 100 of Figure 11 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. In some examples, the telecommunication network 102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs. In some examples, the UEs 112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio – Dual Connectivity (EN-DC). In the example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and / or 112d) and network nodes (e.g., network node 110b). In some examples, the hub 114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 114 may be a broadband router enabling access to the core network 106 for the UEs. As another example, the hub 114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 114. As another example, the hub 114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 114 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices. The hub 114 may have a constant / persistent or intermittent connection to the network node 110b. The hub 114 may also allow for a different communication scheme and / or schedule between the hub 114 and UEs (e.g., UE 112c and / or 112d), and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Moreover, the hub 114 may be configured to connect to an M2M service provider over the access network 104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub – that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub – that is, a device which is capable of operating to route communications between the UEs and network node 110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels. Figure 12 shows a UE 200 in accordance with some embodiments. The UE 200 presents additional details of some embodiments of the UE 112 of Figure 11. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop- mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB- IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). The UE 200 includes processing circuitry 202 that is operatively coupled via a bus 204 to an input / output interface 206, a power source 208, a memory 210, a communication interface 212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 12. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic,field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriatefirmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs). In the example, the input / output interface 206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device. In some embodiments, the power source 208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 208 may further include power circuitry for delivering power from the power source 208 itself, and / or an external power source, to the various parts of the UE 200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 208 to make the power suitable for the respective components of the UE 200 to which power is supplied. The memory 210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges,flash drives, and so forth. In one example, the memory 210 includes one or more application programs 214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 216. The memory 210 may store, for use by the UE 200, any of a variety of various operating systems or combinations of operating systems. The memory 210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID),flash memory, USBflash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 210 may allow the UE 200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 210, which may be or comprise a device- readable storage medium. The processing circuitry 202 may be configured to communicate with an access network or other network using the communication interface 212. The communication interface 212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 222. The communication interface 212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 218 and / or a receiver 220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software orfirmware, or alternatively be implemented separately. In the illustrated embodiment, communication functions of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone inflight according to the received input or to a robotic arm performing a medical procedure according to the received input. A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, aflood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, afitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 200 shown in Figure 12. As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. In practice, any number of UEs may be used together with respect to a single use case. For example, afirst UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, thefirst UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. Thefirst and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. Figure 13 shows a network node 300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). The network node 300 includes a processing circuitry 302, a memory 304, a communication interface 306, and a power source 308. The network node 300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 304 for different RATs) and some components may be reused (e.g., a same antenna 310 may be shared by different RATs). The network node 300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 300. The processing circuitry 302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application- specific integrated circuit,field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 300 components, such as the memory 304, to provide network node 300 functionality. In some embodiments, the processing circuitry 302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 312 and baseband processing circuitry 314 may be on the same chip or set of chips, boards, or units. The memory 304 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, aflash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 302. The memory 304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 302 and utilized by the network node 300. The memory 304 may be used to store any calculations made by the processing circuitry 302 and / or any data received via the communication interface 306. In some embodiments, the processing circuitry 302 and memory 304 is integrated. The communication interface 306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface 306 comprises port(s) / terminal(s) 316 to send and receive data, for example to and from a network over a wired connection. The communication interface 306 also includes radio front-end circuitry 318 that may be coupled to, or in certain embodiments a part of, the antenna 310. Radio front-end circuitry 318 comprisesfilters 320 and amplifiers 322. The radio front-end circuitry 318 may be connected to an antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. The radio front- end circuitry 318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination offilters 320 and / or amplifiers 322. The radio signal may then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 318. The digital data may be passed to the processing circuitry 302. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, the network node 300 does not include separate radio front-end circuitry 318, instead, the processing circuitry 302 includes radio front-end circuitry and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 312 is part of the communication interface 306. In still other embodiments, the communication interface 306 includes one or more ports or terminals 316, the radio front-end circuitry 318, and the RF transceiver circuitry 312, as part of a radio unit (not shown), and the communication interface 306 communicates with the baseband processing circuitry 314, which is part of a digital unit (not shown). The antenna 310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 310 is separate from the network node 300 and connectable to the network node 300 through an interface or port. The antenna 310, communication interface 306, and / or the processing circuitry 302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 310, the communication interface 306, and / or the processing circuitry 302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 308 provides power to the various components of network node 300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 300 with power for performing the functionality described herein. For example, the network node 300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 308. As a further example, the power source 308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. Embodiments of the network node 300 may include additional components beyond those shown in Figure 13 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 300 may include user interface equipment to allow input of information into the network node 300 and to allow output of information from the network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 300. In some embodiments providing a core network node, such as core network node 108 of FIG.1, some components, such as the radio front-end circuitry 318 and the RF transceiver circuitry 312 may be omitted. Figure 14 is a block diagram illustrating a virtualization environment 400 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host. Applications 402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Hardware 404 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 408a and 408b (one or more of which may be generally referred to as VMs 408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 406 may present a virtual operating platform that appears like networking hardware to the VMs 408. The VMs 408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 406. Different embodiments of the instance of a virtual appliance 402 may be implemented on one or more of VMs 408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, a VM 408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 408, and that part of hardware 404 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 408 on top of the hardware 404 and corresponds to the application 402. Hardware 404 may be implemented in a standalone network node with generic or specific components. Hardware 404 may implement some functions via virtualization. Alternatively, hardware 404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 410, which, among others, oversees lifecycle management of applications 402. In some embodiments, hardware 404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 412 which may alternatively be used for communication between hardware nodes and radio units. Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software orfirmware and computationally intensive functions may be implemented in hardware. In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally. NUMBERED EMBODIMENTS 1. A method performed in a Radio Unit, RU, comprising the steps of: receiving a Sounding Reference Signal (SRS) from a first UE, either sending the SRS to a Distributed Unit (DU) over a fronthaul link; or performing channel estimation for the first UE based on the received SRS to produce a channel estimate and sending the channel estimate to the Distributed Unit (DU) over the fronthaul link. 2. A method according to any preceding embodiment further comprising the steps of Receiving an SRS from a second UE and sending the SRS to the DU over the fronthaul link. 3. A method according to any preceding embodiment further comprising the step of compressing the SRS or channel estimate prior to sending, and / or compressing the SRS prior to channel estimation. 4. A method according to any preceding embodiment further comprising the step of transforming the received SRS prior to channel estimation. 5. A method according to any preceding embodiment further comprising the step of transforming the channel estimate. 6. A method according to any preceding embodiment wherein compression is made by eliminating elements corresponding to low energy from the channel estimate or SRS. 7. A method according to any preceding embodiment wherein transforming comprises the step of transforming the channel estimate or SRS to beam space. 8. A method according to any preceding embodiment wherein transforming comprises the step of transforming the estimate or SRS to the tap domain. 9. A method according to any preceding embodiment wherein transforming comprises the step of transforming the estimate or SRS to the delay-Doppler domain. 10. A method according to any preceding embodiment wherein transforming comprises transforming according to one of embodiments 7-9, then transforming again according to another one of embodiments 7-9. 11. A method according to embodiment 10 wherein compression is performed between transforming and transforming again. 12. A method performed in a Radio Unit, RU, for efficient handling of channel state information, the RU being connected to a Digital Unit, DU over a fronthaul link. 13. A method according to embodiment 12 or according to any preceding embodiment comprising transferring compressed channel state information from the RU to the DU. 14. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE making a channel estimate based on the SRS transforming the channel estimate to beam space, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 15. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE transforming the SRS to beam space. making a beam space channel estimate based on the transformed SRS, compressing the channel estimate sending the channel estimate to the DU over the fronthaul link. 16 A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE making a channel estimate based on the SRS, transforming the channel estimate to beam space, transforming the so transformed channel estimate to tap domain, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 17. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE making a channel estimate based on the SRS, transforming the channel estimate to tap domain, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 18. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE transforming the SRS to beam space, making a beam space channel estimate based on the transformed SRS, transforming the channel estimate to tap domain, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 19. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE making a channel estimate based on the SRS, transforming the channel estimate to beam space, compressing the transformed channel estimate transforming the compressed channel estimate to tap domain, compressing the transformed, compressed and again transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 20. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE making a channel estimate based on the SRS, transforming the channel estimate to tap domain, compressing the transformed channel estimate transforming the compressed channel estimate to beam space, compressing the transformed, compressed and again transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 21. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE, making a channel estimate based on the SRS, transforming the channel estimate to delay-doppler domain, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 22. A method according to embodiment 13 comprising the steps of Receiving an SRS from a UE, transforming the SRS to delay-doppler domain making a channel estimate based on the SRS, compressing the transformed channel estimate and sending the channel estimate to the DU over the fronthaul link. 23. A method according to embodiment 13 wherein the channel state information is information in beam space, tap domain or delay-doppler domain. 23a. A method according to any preceding embodiment referring to beam space wherein the beam space is defined by a set of fixed beams as base vectors. 23b. A method according to embodiment 23 or any embodiment preceding embodiment 23 referring to beam space wherein a set of base vectors for the beam space is sent from the RU to the DU. 23c. A method according to embodiment 23b wherein the signal energy of the SRS or channel estimate as expressed in terms of the base vectors is concentrated to fewer of the base vectors compared to as expressed in terms of fixed beams. 23d. A method according to embodiment 23b or 23c wherein the base vectors are sent in connection with channel estimates or SRS that they apply to. 23e. A method according to embodiment 23b, 23c or 23d wherein the base vectors are, for each UE, sent once per slot. 23f. A method according to any of embodiments 23b, 23c, 23d or 23e wherein the channel estimates or SRS are given for a same set of beams / base vectors common to all or at least to a plurality of the ports or layers of a UE. 23g. A method according to any of embodiments 23b, 23c, 23d or 23e wherein the channel estimates or SRS are each given for separate set of beams / base vectors for each specific port or layer of a UE. 23h. A method according to any of embodiments 23b, 23c, 23d or 23e wherein the channel estimates or SRS are each given for separate set of beams / base vectors for each SRS comb offset. 23i. A method according to embodiment 23b or any embodiment dependent on embodiment 23b wherein the base vectors are determined based on SRS received for a UE. 23i-1. A method according to embodiment 23b or any embodiment dependent on embodiment 23b wherein the base vectors are determined based on a channel estimate. 23j. A method according to embodiment 23b or any embodiment dependent on embodiment 23b wherein the base vectors are sent in a C-plane message. 23k. A method according to embodiment 23b or any embodiment dependent on embodiment 23b wherein a dual-polarized antenna array of the RU has K antenna elements and the base vectors have dimension K / 2. 23l. A method according to embodiment 23k wherein a same set of base vectors of dimension K / 2 is used for both polarizations. 23m. A method according to embodiment 23k or 23l wherein the base vectors are for application to the channel estimates or SRS of the K / 2 elements of the array of each polarization. 23n. A method according to embodiment 23b or any embodiment dependent on embodiment 23b wherein a reuse flag is sent from RU to DU indicating that the set of base vectors is to be used again. 23o. A method according to any of embodiments 23b, 23c, 23d, 23e or 23f or any other preceding embodiment beginning with 23 wherein for each UE of a plurality of UEs a UE- specific set of beams / base vectors is provided for the UE and the channel estimates or SRS for all or at least a plurality of the ports or layers of the UE are given for a same set of beams / base vectors, the same set being the UE-specific set for that UE. 23p. A method according to any of embodiments 23b, 23c, 23d, 23e or 23f or any other preceding embodiment beginning with 23 wherein channel estimates or SRS for a plurality of UEs are given for a predetermined reduced number of base vectors, the UEs being selected based on how well the channel estimate or SRS for the UEs can be described by the base vectors. 24. An RU adapted to perform the method of any of the preceding embodiments. 25. An RU according to the preceding embodiment wherein the RU is an O-RAN O-RU. 26. A method performed by a Distributed Unit, DU, for efficient communication of channel state information over a fronthaul link between an RU and the DU, comprising the step of receiving, optionally from the RU, channel state information over the fronthaul link wherein the channel state information is in beam space, tap domain or delay-doppler domain. 26a. A method performed by a Distributed Unit, DU wherein the DU receives the information sent by the RU in any preceding embodiment. 27. A DU adapted to perform the method of the preceding embodiment. 28. A DU according to the preceding embodiment, wherein the DU is an O-RAN O-DU. 29 A computer program adapted to perform the method of any of the embodiments 1-23 in an RU according to any of the embodiments 24-25. 30. A computer program adapted to perform the method of any embodiment 26 in a DU according to any of the embodiments 27-28. Abbreviations Abbreviation Explanation BFW Beamforming Weight CPRI Common Public Radio Interface DCT Discrete Cosine Transform DFT Discrete Fourier Transform DL Downlink DU Distributed Unit eCPRI evolved or enhanced CPRI eRE eCPRI Radio Equipment eREC eCPRI Radio Equipment Controller FH Fronthaul LLS Lower Layer Split MIMO Multiple Input Multiple Output MU-MIMO Multi-User MIMO PRB Physical Resource Block RU Radio Unit SRS Sounding Reference Signal UL Uplink OFDM Orthogonal frequency division multiplex Further information on the transforms referred to in this disclosure is available in e.g. the following: Beam-space: J. Brady, N. Behdad and A. M. Sayeed, "Beamspace MIMO for Millimeter-Wave Communications: System Architecture, Modeling, Analysis, and Measurements," in IEEE Transactions on Antennas and Propagation, vol. 61, no. 7, pp. 3814-3827, July 2013. Tap-domain or channel taps: N. M. Idrees, M. R. Petit and A. Springer, "Identification of Taps in Time-Variant Multipath Channels for 3GPP LTE-Downlink," Proceedings of European Wireless 2015; 21th European Wireless Conference, Budapest, Hungary, 2015, pp. 1-6. Delay-Doppler domain: Ronny Hadani and Anton Monk, “OTFS: A New Generation of Modulation Addressing the Challenges of 5G,” arXiv:1802.02623, link: https: / / arxiv.org / abs / 1802.02623.

Claims

CLAIMS 1. A method performed by an O-RAN O-RU having a plurality of antennas, the method comprising sending selected beam space channel estimates or SRS on a subset of beams, together with an indication identifying the selected beams over a fronthaul interface to an O-RAN O-DU.

2. A method according to claim 1 wherein the number of channel estimates or SRS is smaller than the number of antennas.

3. A method according to any preceding claim wherein the beam-space channel values or SRS with best quality are selected, best quality being having highest amplitude or power or highest SNR or SINR, highest eigen values of the channel covariance or any other quality metric.

4. A method according to any preceding claim wherein the channel estimates or SRS in beam space are based on a transform from antenna space to beam space and wherein the O-RU further sends weights or coefficients of determined beams used for beam space transformation.

5. A method according to any preceding claim wherein the selected beams are determined by O-RU based on the channel estimates.

6. A method according to any of claim 4 or claim 5 when dependent on claim 4 wherein the channel estimates or SRS are given for a same set of beams / base vectors common to all or at least to a plurality of the ports or layers of a UE.

7. A method according to any of claim 4 or claim 5 when dependent on claim 4 wherein the channel estimates or SRS are each given for separate set of beams / base vectors for each specific port or layer of a UE.

8. A method according to any of claim 4 or claim 5 when dependent on claim 4 wherein the channel estimates or SRS are each given for separate set of beams / base vectors for each SRS comb offset.

9. A method according to claim 4 or claim 5 when dependent on claim 4 wherein the weights or coefficients are determined based on SRS received for a UE.

10. A method according to claim 4 or claim 5 when dependent on claim 4 wherein the weights or coefficients are sent in a C-plane message.

11. A method according to claim 4 or 5 wherein a reuse flag is sent from O-RU to O-DU indicating that the set of weights or coefficients is to be used again, or selected beams are to be used again.

12. A method performed by an O-RAN O-DU comprising receiving that which is sent by the O-RU in any of the claims 1-11.

13. An O-RAN O-RU adapted to perform the method of any of claims 1-11.

14. An O-RAN O-DU adapted to perform the method of claim 12.

15. A system comprising an O-RAN O-RU according to claim 13 connected to an O-RAN O- DU according to claim 14 over a fronthaul interface.

16. A signal for transmission from an O-RAN O-RU to an O-RAN O-DU over a fronthaul interface, the signal comprising that which is sent by the O-RU in any of the claims 1-11.

17. A computer program comprising instructions which, when run on a processor of an O- RAN O-RU, causes the O-RU to perform the method of any of the claims 1-11.

18. A computer program comprising instructions which, when run on a processor of an O- RAN O-DU, causes the O-DU to perform the method of claim 12.

19. A network node comprising a processor and memory containing instructions which when executed caused the network node to perform the method of any of the claims 1-11.

20. A network node comprising a processor and memory containing instructions which when executed causes the network node to perform the method of claim 12.

Images