Channel estimate reporting

Abstract

A method is performed by an O-RAN Radio Unit (O-RU) that sends a message to an O-RAN Distributed Unit (O-DU) indicating, for a User Equipment (UE), channel estimates that will be used for beamforming. The O-RU may exclude channel estimates of low quality when performing beamforming and determine which UE ports are valid or invalid. The O-RU may send a message to the O-DU indicating the valid UE ports. A corresponding method is performed by the O-DU that receives the message from the O-RU indicating the channel estimates to be used for beamforming. For low quality channel estimates, the message may not indicate these will be used for beamforming. A port may be deemed invalid if it will or should not be used for reception, transmission, scheduling parameter determination, channel estimation or beamforming weight determination, or if signals from the port are unlikely to make useful contributions beyond other UE ports. The disclosure also covers O-RU and O- DU apparatus, computer programs, and systems implementing these methods.

Description

[0001] 25-02-2026

[0002] Inkom till Patent- och registreringsverke! ® -Hr 15

[0003] CHANNEL ESTIMATE REPORTING

[0004] TECHNICAL FIELD

[0005] The present disclosure relates to the field of radio channel management

[0006] BACKGROUND

[0007] Massive MIMO is one key technology in 4G, 5G and beyond, which are widely deployed globally. It features with 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

[0008] example, 64 antennas serving 8 or 16 user-layers in frequency range 1 (FR1), which

[0009] 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 52.6 GHz. A user layer when used

[0010] herein e.g., means an independent downlink or uplink data stream intended for one user.

[0011] One user or UE may have one or multiple user layers. User layer is also referred to as layer, e.g., in 3GPP terminology. Massive MIMO is also referred to as massive beamforming,

[0012] which is able to form narrow beams focusing on different directions to counteract against the increased path loss at higher frequency bands. It also benefits multi-user MIMO which allows for transmissions from / to multiple users simultaneously over separate spatial

[0013] channels resolved by massive MIMO technologies nulling the interferences between users, while keeping high performance, e.g., throughput, for each user. Therefore, it can

[0014] significantly increase the spectrum efficiency and cell capacity.

[0015] At the base-station side, the interface between the distributed unit (DU) and the radio unit (RU) is the fronthaul (FH) interface, as shown in Figure 1. The great benefits of massive MIMO at the air-interface also introduce new challenges at the base-station side. The

[0016] legacy CPRI-type fronthaul transports time-domain 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

[0017] fronthaul interface. In eCPRI, other functional split options between a DU and a RU are supported, referred to as different lower-layer split (LLS) options. In the eCPRI standard specification, the terms eREC (eCPRI Radio Equipment Control) and eRE (eCPRI Radio

[0018] iInkom till Patent- och registrerin sv erxet

[0019]

[0020] Equipment) are used instead of DU and RU. The basic idea is to move the frequencydomain beamforming function from DU to RU so that frequency samples or data of userlayers are transported over the fronthaul interface. Note that the frequency-domain beamforming is sometimes also referred to as precoding in the downlink (DL) direction and equalizing or pre-equalizing in uplink (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 open fronthaul interface specification [1], DU is referred to as O-DU (O-RAN DU) while

[0021] RU is referred to as O-RU (O-RAN RU).

[0022] Figure 2 shows the downlink (DL) Weight-based Dynamic Beamforming (WDBF) implementation supported by the current O-RAN WG4 specification [1]. By having the DL beamforming function in the O-RU, the number of streams going through the fronthaul interface becomes the number of layers. The DL beamforming weights are calculated in the O-DU based on the SRS signal sent back from the O-RU.

[0023] Figure 3 shows the control-plane (C-plane) and user-plane (U-plane) data flow for WDBF in DL. For every slot, the O-DU sends first C-plane messages to convey the scheduling information to the O-RU. The scheduling information includes the REs (Resource

[0024] Elements) to be scheduled, the beam ID (referred as beamld in the specification) which represents the beamforming weights stored in the O-RU, or the beamforming weights

[0025] (BFWs) together with its beam ID to be used if not stored. Then, the O-DU sends the DL

[0026] U-Plane data (IQ data after modulation which may be compressed) to the O-RU. The O-RU receives the scheduling information and the DL U-Plane data. Then, the O-RU processes the received IQ data according to the scheduling information received, e.g., perform beamforming (i.e., apply the beamforming weights received directly or indicated by the beam ID received), perform IFFT and add cyclic prefix, etc., to generate OFDM IQ data, send the OFDM IQ data to the DFE and RF-frontend, and send the OFDM signal out from the antennas.

[0027] There is another type of beamforming methods defined in the current O-RAN WG4 specification, referred as Channel Information based Beamforming (CIBF). Figure 4 shows an exemplified implementation of CIBF. In CIBF, instead of transferring BFWs or beamld, the O-DU transfers to the O-RU the scheduled layers and the SRS channel information of the scheduled layers in the C-plane messages. The O-RU uses the received information!nkom till Patent- oct

[0028]

[0029] (i.e., the scheduled REs, the scheduled layers and their channel information for the scheduled REs) to calculate the BFWs and perform beamforming to the received DL U-Plane data using the calculated BFWs. In the specification, each scheduled layer is conveyed by a field called “ueld” in the C-plane message, i.e., Section Type 5. Although the field name is “ueld”, the ueld represents a layer, not a UE. For a UE with multiple layers scheduled, it needs multiple uelds where each ueld represents one layer of the UE. The channel information is provided per layer per PRB. The beamforming weights are calculated using the channel information received.

[0030] In the current O-RAN WG4 open-fronthaul CUS specification [1], O-RAN CU plane (control plane and user plane) distinguishes logical data flows on transport level, based on the eAxC ID presented in the eCPRI transport header of the C- and U-plane messages. It allows to distinguish RU’s logical flows, representing spatial streams (e.g. beamformed data stream), which are the layers when WDBF or CIBF is used.

[0031] In O-RAN open fronthaul, a C- or U-plane message contains an eCPRI transport header, in which the “ccpriRtcid I ecpriPcid” field represents the eAxC ID used. A C- or U-plane message further contains one or more sections using a specific Section Type. Multiple Section Types are defined to carry different types of scheduling information for different purposes. For example, Section Type 0 (STO) is used to represent unused resource blocks or symbols. Section Type 1 (STI) can be used to represent used (scheduled) resource elements (REs) for most DL / UL channels, e.g., PUSCH (Physical Uplink Shared Channel), PDSCH (Physical Downlink Shared Channel), etc., when WDBF is used. Section Type 5 (ST5) is used for PUSCH when DMRS (Demodulation Reference Signal) based beamforming is used and is used for PDSCH and / or PUSCH when channel information based beamforming is used. Each section can be attached with one or more Section Extensions. Each Section Extension attached includes additional information than that described by the section. For example, Section Extension 1 (SEI) is used to provide beamforming weights. Section Extension 4 (SE4) is used to provide modulation compression parameters. Section Extension 10 (SE10) is used to provide beamforming weights or uelds when port (or layer) grouping is used.Inkom till Patent- ooh

[0032] .'^aistrerinasvar et

[0033] There currently exist certain challcngc(s).

[0034] One problem of WDBF and CIBF in the current O-RAN open fronthaul specification is that the large amount of SRS IQ data is sent from O-RU to O-DU over the fronthaul interface, which increases the fronthaul bit rate. In this case, O-RU sends the IQ data of the SRS symbols of all antennas to the O-DU. It means that the number of FH spatial streams for transporting SRS IQ data equal to the number of antennas, while the number of FH spatial streams for transporting IQ data of PUSCH data equal to the number of the beamformed streams or layers after beamforming in O-RU which is much less than the number of antennas. As a result, the amount of the SRS IQ data per symbol is much more than that of the IQ data of beamformed PUSCH data symbol. For example, for 64 antennas and 8 spatial streams or layers used for PUSCH, the IQ data of a fully loaded SRS symbol is 8 times more than that of a fully loaded PUSCH symbol after beamforming. In O-RAN, this issue can be addressed by delaying sending SRS IQ data in DL slots. But this would cause longer delay and increase O-RU costs for data buffering.

[0035] Another problem is that the O-DU processing capacity is highly loaded by SRS processing. When one O-DU is connected to multiple O-RUs, the SRS is scheduled simultaneously across the network due to the time division duplex (TDD) pattern. All SRS IQ data from multiple O-RUs arriving at the DU at the same time. This imposes a significant processing load on the O-DU, as it must handle SRS for channel estimation from all O-RUs simultaneously. This significantly reduces the statistical multiplexing gain for O-DU processing, which assumes that the processing load from different RUs arc not at the peak simultaneously. Given limited hardware resources in O-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 fronthaul links are aggregated.

[0036] To further address these problems, O-RAN agrees to standardize a new functional split which moves SRS channel estimation function to the O-RU. It is currently referred to as SRS based beamforming (SRS-BF). Then SRS processing is offloaded to the O-RU, which could increase the O-DU capacity to process more antenna carriers and users.Inkom till Pstsnt- ocL G r 0 r h ' s '' • -

[0037]

[0038] 20Zo < 13

[0039] Figure 5 shows one variant of SRS-BF implementation for DL. In this variant, both SRS channel estimation and DL beamforming weights calculation are moved to the O-RU. O- RU also calculates some SRS-based RRM measurements (e.g., time-offset, S1NR, signal power) and sends these measurements back to the O-DU. Further, O-RU sends SRS

[0040] channel estimates back to the O-DU. The SRS channel estimates may be compressed to

[0041] reduce the amount of data over fronthaul interface. Both SRS RRM measurements and SRS channel estimates are used by the O-DU for scheduling and other purposes. Since DL beamforming weights are also moved to the O-RU, there is no beamforming weights over the fronthaul interface, which reduces the fronthaul bit rate in the direction from O-DU to

[0042] O-RU.

[0043] Figure 6 shows another variant of SRS-BF implementation for DL. In this variant, SRS

[0044] channel estimation is moved to the O-RU while DL beamforming weights calculation is

[0045] kept in the O-DU. In this variant, the O-DU can reuse most of functionalities in WDBF,

[0046] which makes easier to migrate to SRS-BF. The main benefit is to offload the O-DU

[0047] processing from SRS channel estimation.

[0048] In SRS-BF SRS channel estimation is performed in the O-RU. To enable this, the O-DU provides SRS configuration information to the O-RU via C-Plane messages. After receiving the C-Plane message containing SRS configuration information, the O-RU can generate the corresponding SRS sequences and perform SRS channel estimation for each UE which sent the SRS signal.

[0049] In 3GPP, SRS can be sent in some symbols in the special slot which contains both DL and

[0050] UL transmissions or an UL slot which only contains UL transmissions. SRS can be

[0051] configured as periodic, aperiodic, or semi-periodic. Each UE is informed by the base station the SRS configuration which will be used by the UE to generate its SRS. The SRS of one

[0052] UE can have multiple SRS ports if it has multiple antenna ports. One antenna port may be one physical antenna or a virtual antenna by beamforming with multiple antennas. Each

[0053] SRS port corresponds to the SRS sent by one UE antenna port. The SRS ports of one or

[0054] more UEs are allocated with orthogonal resources in frequency domain, time domain, or code domain. In frequency domain, different ports can use different Comb Offsets, i.e.,?nkom fill Patentocb

[0055] using different resource elements (REs) in the same PRBs. They can also use different PRB ranges. In time domain, they can use different symbols. In code domain, they can use different Cyclic Shifts (CS) which makes the SRS sequence orthogonal. An SRS symbol can multiplex many SRS ports. For example, with full bandwidth sounding per UE, one SRS symbol can multiplex 48 SRS ports. With half bandwidth sounding per UE, one SRS symbol can multiplex 96 SRS ports. The number of SRS ports further increases when multiple SRS symbols are used, e.g., 2, 4, 6 SRS symbols. SRS also supports various features such as frequency hopping, repetition, antenna switching etc. It is also constrained by the UE capabilities such as 1T4R, 2T4R, 1T2R, bandwidth part, etc.

[0056] Currently, the SRS-BF work item in O-RAN WG4 (open fronthaul) standardization focuses on the first variant of SRS-BF shown in Figure 5 where both SRS channel estimation and beamforming weights calculation arc performed in the O-RU. It is under discussion about how to best support SRS-based beamforming. It is challenging to have a solution optimized considering the aspects of performance, fronthaul load, processing efficiency and system capacity. So far, there is no detailed solution yet proposed.

[0057] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0058] SUMMARY

[0059] In SRS-based beamforming systems, an O-RAN Radio Unit (O-RU) performs channel estimation based on Sounding Reference Signals (SRS) received from User Equipment (UE) antenna ports. The O-RU determines which channel estimates arc of sufficient quality to be used for beamforming calculations and communicates this information to an O-RAN Distributed Unit (O-DU) through messaging over the fronthaul interface.

[0060] The O-RU evaluates the quality of channel estimates obtained from SRS transmissions and excludes low-quality estimates that could degrade beamforming performance. Channel estimates may be deemed low quality due to factors such as low signal power, high noise levels, poor signal-to-noise ratio (SNR), poor signal-to-interference-plus-noise ratioInkom till Patent- oca

[0061] ? A o i nPe n n a s v &■ c e i yUf Pt:

[0062] (SINR), or high correlation with other antenna ports. The O-RU also determines which UE antenna ports are valid for use in beamforming operations.

[0063] The O-RU sends a message to the O-DU indicating which channel estimates will be used for beamforming calculations. This allows the O-DU to make informed scheduling decisions based on knowledge of which channel estimates are actually being utilized by the O-RU for beamforming weight calculations. A message may also indicate which UE ports are considered valid.

[0064] This approach provides several advantages over conventional systems. By performing channel estimate quality assessment at the O-RU, which has access to full-resolution and full-precision channel estimates, higher quality determinations can be made compared to assessments based on compressed channel estimates transmitted over the fronthaul. The method reduces fronthaul bandwidth requirements since the O-DU does not need to receive high-resolution channel estimates to make quality determinations. Additionally, by informing the O-DU of which channel estimates are actually used, the O-DU can make better scheduling decisions, leading to improved radio performance and system capacity. The communication between the O-RU and O-DU occurs over the O-RAN fronthaul connection, enabling efficient coordination between the distributed processing units while maintaining the benefits of the SRS-based beamforming architecture.

[0065] In a first aspect, there is provided a method performed by an O-RAN O-RU. The method comprises sending a message to an O-RAN O-DU, where the message indicates, for a UE, channel estimates that will be used for beamforming.

[0066] Channel estimates of low quality may be excluded when the O-RU performs beamforming. The O-RU may determine, for a UE, which ports arc valid and which arc invalid. The O- RU may send a message to the O-DU which indicates, for a UE, the UE ports that arc valid. In a second aspect, there is provided a method performed by an O-RAN O-DU. The method comprises receiving a message from an O-RAN O-RU, where the message indicates, for a UE, channel estimates that will be used for beamforming.Jnkom till Patent- jcf j Of’strgnnnc".;: •- "

[0067] For channel estimates of low quality, the message may not indicate that these will be used for beamforming. The O-DU may receive a message from the O-RU which indicates, for a UE, the UE ports that are valid.

[0068] In a third aspect, there is provided an O-RU adapted to perform the method of the first aspect.

[0069] In a fourth aspect, there is provided a computer program adapted to, when run on one or more processors of an O-RU, perform the method of the first aspect.

[0070] In a fifth aspect, there is provided an O-DU adapted to perform the method of the second aspect.

[0071] In a sixth aspect, there is provided a computer program adapted to, when run on one or more processors of an O-DU, perform the method of the second aspect.

[0072] In a seventh aspect, there is provided an O-RAN Radio Unit, O-RU comprising processing circuitry and a memory configured to send a message to an O-RAN O-DU, where the message indicates, for a UE, channel estimates that will be used for beamforming.

[0073] In an eighth aspect, there is provided a tangible, non-transient computer-readable medium comprising instructions that, when executed by processing circuitry of an O-RAN Radio Unit, O-RU connected to an O-RAN Distributed Unit, O-DU over fronthaul, cause the processing circuitry to perform operations comprising sending a message to an O-RAN O- DU, where the message indicates, for a UE, channel estimates that will be used for beamforming.

[0074] In a ninth aspect, there is provided an O-RAN Distributed Unit, O-DU comprising processing circuitry and a memory configured to receive a message from an O-RAN O-RU, where the message indicates, for a UE, channel estimates that will be used for

[0075] beam forming.

[0076] In a tenth aspect, there is provided a tangible, non-transient computer-readable medium comprising instructions that, when executed by processing circuitry of an O-RAN Radio Unit, O-RU connected to an O-RAN Distributed Unit, O-DU over fronthaul, cause the processing circuitry to perform operations comprising receiving a message from an O-RANIpkon? oct;

[0077]

[0078] rJQipt >"p 'i ri''‘S’,'3^‘ft? V

[0079] O-RU, where the message indicates, for a UE, channel estimates that will be used for beamforming.

[0080] A port may be deemed invalid if it will not or should not be used, either by O-RU or O-DU,

[0081] for reception, transmission, determination of scheduling parameters, channel estimation or determining of beamforming weights. Alternatively, the port may be deemed invalid if a

[0082] signal supposedly transmitted, or received by the port, is unlikely to make a useful

[0083] contribution to channel estimation or signal transmission or reception in addition to using

[0084] the other ports of the UE. The port may also be invalid if low quality of the received signal

[0085] or channel estimate of the received signal, such as low received signal power or SNR or

[0086] SINR indicate that SRS may not have been sent. Additionally, the port may be invalid if it

[0087] is highly correlated with another port or because of low quality of the received signal or

[0088] channel estimate from the received signal.

[0089] In an eleventh aspect, there is provided a system comprising an O-RU according to the third

[0090] or seventh aspect connected over fronthaul to an O-DU according to the fifth or ninth

[0091] aspect.

[0092] BRIEF DESCRIPTION OF THE DRAWINGS

[0093] Figure 1 shows an illustration of fronthaul interface between RU and DU.

[0094] Figure 2 shows a downlink (DL) WDBF implementation supported by current O-RAN open fronthaul specification.

[0095] Figure 3 shows C-plane and U-plane data flows for DL in current O-RAN open fronthaul specification.

[0096] Figure 4 shows a DL CIBF implementation supported by current O-RAN open fronthaul specification.

[0097] Figure 5 shows a first variant of SRS-BF functional split for DL.

[0098] Figure 6 shows a second variant of SRS-BF functional split for DL.

[0099] Figure 7 shows a proposed method in which O-RU determines SRS port to layer mapping.

[0100] Figure 8 shows another implementation example of the proposed method.

[0101] Figure 9 shows an example of a flow chart of the proposed method.

[0102] Figure 10 shows an example of a communications system.

[0103] Figure 11 shows another example of a communications system.Jnkorn till Patsnt- oc

[0104] ■ o ’ s: ' e i n c r ~ F p •

[0105] fW5- I §

[0106] Figure 12 shows a block diagram of a wireless device.

[0107] Figure 13 shows a block diagram of a network node.

[0108] Figure 14 shows a block diagram illustrating a virtualization environment.

[0109] Figure 15 is a signaling diagram showing O-RU indicating a result of port to layer mapping to O-DU.

[0110] Figure 16 shows an example of port to layer mapping.

[0111] Figure 17 shows an example of measurement type XX for conveying port to layer mapping.

[0112] DETAILED DESCRIPTION

[0113] For the first variant of SRS-BF where both SRS channel estimation and beamforming weights calculation are done in the O-RU, the O-RU calculates the port to layer mapping and sends to O-DU via C-Plane the indication of port to layer mapping or the indication of which layers are ready for calculating beamforming weights. The O-DU determines the scheduling decisions per slot based on the received indication and send the scheduling information to O-RU via C-Plane. The O-RU calculates beamforming weights using the effective channel estimates of layers after port to layer mapping or transformation according to the received scheduling information and perform beamforming accordingly. In this disclosure, we propose a method to support SRS-based beamforming which achieves low fronthaul load, high processing efficiency, high system capacity, and high performance. In the proposed method that the O-RU calculates the port to layer mapping (including determination of valid SRS antenna ports) and send to the O-DU an indication that the port to layer mapping is done and the layers are ready for beamforming. The indication for port to layer mapping may indicate which SRS ports to be used for calculating beamforming weights for each layer and / or how the channel estimates of the SRS antenna ports are transformed to the channel estimates of layers for calculating beamforming weights for the scheduled layers. The indication is sent when port to layer mapping is updated using the latest SRS channel estimates obtained from the newly received SRS.

[0114] O-RU may send channel estimates to O-DU. In this case, O-RU may send to O-DU an indication of the channel estimates used for beamforming weights calculation. TheInkom till Patent- och fs-KJ! S t * '' f1'■ P '

[0115] indication can be implicitly indicated by in the channel estimates sent by setting the unused channel estimates to a special value (representing invalid channel estimates) or zero.

[0116] Then, the O-DU uses the received indication and other information (e.g., SRS RRM measurements, DMRS RRM measurements, UE CSI (Channel State Information) report, SRS channel estimates, etc.) to make scheduling decisions per slot regarding UE layer pairing for SU-MIMO and MU-MIMO, PRB allocation of UEs, MCS (modulation and coding scheme), etc. The O-DU sends to O-RU via C-Plane the scheduling information according to the scheduling decisions. The O-RU uses the scheduling information to calculate beamforming weights using the effective channel estimates of layers based on port to layer mapping or transformation and perform bcamforming for the scheduled layers accordingly.

[0117] The indication for port to layer mapping could be a list of sorted SRS ports or port-to-layer transformation weights. Alternatively, the indication could be number of layers and a list of layers. In both cases, the indication may be sent explicitly or may be implicitly indicated by sending the channel estimates of sorted SRS antenna ports or the effective channel estimates of layers after port to layer mapping. If only new channel estimates sent don’t contain all ports for a UE, the indication should be sent explicitly.

[0118] In some scenarios, no channel estimates are sent from O-RU to O-DU. In the scenarios where channel estimates are also sent from O-RU to O-DU, the channel estimates may be sent in the channel estimates of SRS antenna ports or the effective channel estimates of layers after port to layer mapping or transformation. For SRS RRM measurements, some RRM measurements may be calculated for layers.

[0119] Port to layer mapping may use the channel estimates combining the new channel estimates obtained from the newly received SRS and the old channel estimates obtained from previously received SRS. For example, for a 4-port UE, the combined estimates comprise the channel estimates of one port obtained from the new SRS and the channel estimates of other 3 ports obtained from the previous SRS.

[0120] Certain embodiments may provide one or more of the following technical advantage(s).Inkom till Pstsnt- o

[0121]

[0122] - 'i- £ b

[0123] • No channel estimates or only low-resolution channel estimates are transferred over

[0124] fronthaul interface for scheduling purpose, which results in low fronthaul load due

[0125] to SRS.

[0126] • The SRS channel estimation is done in the O-RU. Therefore, the O-RU has fullresolution and full-precision channel estimates. Using the full-resolution and fullprecision channel estimates results in the highest possible quality of port to layer

[0127] mapping or transformation. The high quality of port to layer mapping or

[0128] transformation will result in high radio performance, e.g., improved UE throughput.

[0129] If port to layer mapping or transformation would be done in O-DU, to achieve the

[0130] same performance, it would require the channel estimates sent from O-RU to O-DU

[0131] in higher resolution (e.g., higher frequency resolution, more beams) and higher

[0132] precision (e.g., with more bits to represent the channel estimates) which would

[0133] significantly increase the fronthaul load.

[0134] • Calculating port to layer mapping or transformation in O-RU (including

[0135] determination of valid SRS antenna ports) is more efficient than doing it in O-DU.

[0136] Port to layer mapping or transformation in SRS processing is computing intensive

[0137] task. The O-DU is usually connected to multiple O-RUs and serve many cells and

[0138] carriers. SRS channel estimates usually arrive at O-DU periodically all the time synchronously of multiple carriers using the same pattern. If port to layer mapping

[0139] or transformation is done in O-DU, this would create bursty high processing load in

[0140] the O-DU, which creates a bottleneck for SRS processing due to resource

[0141] limitation. This limits SRS processing capability (the number of SRS UEs to be

[0142] processed) and therefore limit the system capacity of SRS-BF regarding number of

[0143] UEs to be served with SRS-BF. With the proposed method, O-RU offloads the

[0144] processing for port to layer mapping or transformation from O-DU to O-RU. It

[0145] significantly reduces O-DU processing load. Since each O-RU will process its own

[0146] SRS, instead of one O-DU processing the SRS from multiple O-RUs, SRS

[0147] processing is less bottlenecked. This will not only increase overall SRS processing

[0148] capacity but also increase O-DU capacity.Inkom til! Patent- och o ’ H no?' fl H Pf ' t n

[0149] • Determination of valid ports that excludes the invalid ports for beamforming weights calculation in O-RU and for scheduling decision making in O-DU improves the radio performance, because the invalid ports have no valid channel estimates, e.g., too noisy, highly correlated with other ports. Including the channel estimates of these invalid ports will degrade the overall quality of the channel estimates between a UE and an O-RU. It is beneficial to perform port validation in the O-RU. It will save FH bandwidth since more and / or better channel estimates (e.g., with high frequency resolution, larger bitwidth, more beams) are needed to send to O-DU if port validation is done in O-DU.

[0150] • O-RU may determine not using some low-quality channel estimates for beamforming weights calculation. Radio performance may be improved by excluding these low-quality channel estimates (e.g., using zeros for these channel estimates when calculating beamforming weights) which may negatively affect the performance if using them for beamforming. In this proposed method, O-RU informs O-DU which channel estimates are used for beamforming weights calculation. O-DU can better determine scheduling decisions based on the knowledge of used channel estimates. If O-DU would decide which channel estimates are used for beamforming weights calculation in O-RU, O-DU would require to receive from O-RU the channel estimates in higher resolution (e.g., higher frequency resolution, more beams) and higher precision (e.g., with more bits to represent the channel estimates) which would significantly increase the fronthaul load.

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

[0152] Additional information may also be found in the document(s) provided in the Appendix. One UE usually has multiple antennas. For SRS transmission, each antenna is referred to an SRS antenna port or SRS port. It is sometimes also referred to as antenna port. In order to get the channel information between all UE antennas and all antennas at the O-RU, SRS is sent from each SRS antenna port. Then, the channel between one UE antenna and all O-RU!nkom till Patent- ooh

[0153] repistre ri nc s v ■ r1;t

[0154] antennas is estimated by SRS channel estimation using the received SRS sent from the SRS antenna port corresponding to the UE antenna. With all SRS sent from all UE antennas received, the channel between all UE antennas and all O-RU antennas is estimated. For DL reciprocity-based beamforming, the beamforming weights are calculated based on the SRS channel estimates.

[0155] The SRS sent from different UE antennas can be sent using the same frequency-time resources, i.e., the same REs (resource elements), with code-division multiplexing (CDM) using different cyclic-shift (CS). The SRS sent from different UE antennas can be sent using different REs (resource elements) in the same PRB, with frequency-division multiplexing (FDM). The SRS sent from different UE antennas can be sent using different REs (resource elements) in the same PRB, with frequency-division multiplexing (FDM). The SRS sent from different UE antennas can be sent using different symbols in the same slot or in different slots.

[0156] The SRS channel estimates for one subcarrier or a group of subcarriers of one UE can be described as a matrix, Hsrs, where Hsrsis a P-by-K matrix, where P represents the number of UE antennas (also referred to as antenna ports) that send SRS and K represents the number O-RU antennas (or beams), which describes the channel properties between UE antennas and O-RU antennas (or beams). Let hpkrepresents the element at the pth row and the kth column of Hsrs. In antenna space, hpkrepresents the channel coefficient between UE antenna p and O-RU antenna k. In beam space, hpkrepresents the channel coefficient between UE antenna p and O-RU beam k, where each beam is formed by combining K O- RU antennas with certain bcamforming weights pointing to a direction.

[0157] As an example, we assume one layer DL transmission beamformed by maximum ratio transmission (MRT) beamforming to one UE with the SRS channel estimates of Hsrs. One option is to select the SRS antenna port with the highest channel power and calculate the beamforming weights according to the channel of the selected SRS antenna port. Assuming the ith SRS antenna port is strongest and thereby selected, the channel of the ith SRS antenna port can be expressed as h; which represents the ith row vector of Hsrs. In this case, only hiis used for beamforming weights calculation. The MRT beamforming weights is calculated as w = hiHwhich is the conjugate and transpose of the row vector hi.Inkom til! Patent - och

[0158] Another option is to calculate the beamforming weights according to the channel of multiple SRS antenna ports. As an example, wc assume use all SRS antenna ports of HsrsTo calculate the bcamforming, the channel estimates Hsrsare first converted to the effective channel of one layer, hlay= wp2lHsrs, where wp2lis a row vector of K weights, representing the transformation weights to transform the channel of SRS ports to the channel of layers. Then, the MRT beamforming weights is calculated as w = hlayHwhich is the conjugate and transpose of the row vector hlay.

[0159] In either option in the above examples, the channel estimates of Hsrsare not used directly. It is first converted to an effective channel of one layer hlayand then use the effective channel of one layer to calculate the beamforming weights for the layer. For the option selecting one SRS antenna port, hlay= hi. For the option using multiple SRS ports, hlay= wp2lHsrs. When channel estimation quality is good, using multiple SRS ports performs better. But it is more complex since wp2lneeds to be calculated as well. Selecting a subset of SRS antenna ports may be also useful by removing the ports with low SINR which may negatively impact the performance due to bad channel estimation quality. Sometimes, the SRS channel estimates of some antenna ports are not available because the SRS are not sent by the UE.

[0160] Same as the single layer transmission exemplified above, multi-layer transmission of L layers also has these two options. The first option is to select one SRS antenna port per layer and convert the channel estimates of Hsrsof each UE to an effective channel of L layers Hlayof each UE by selecting L rows of Hsrs. Each row corresponds to one layer. The second option is select multiple SRS antenna ports per layer and the channel estimates of Hsrsof each UE to an effective channel of L layers as Hlay= Wp2lHsrswhere Wp2lis a L- by-P matrix representing the port to layer transformation weights. In both options, Hlayis a L-by-K matrix. For SU-MIMO, Hlayis used to calculate the beamforming weights for L layer transmission. For MU-MIMO, Hlayof multiple UEs are stacked together as Hlay,MUand then Hlay,MUis used to calculate the beamforming weights for layers of multiple UEs.

[0161] Figure 7 shows the block diagram of the proposed method. The O-DU sends to the O-RU via C-Plane the SRS configuration (including SRS allocation in the resource grid). The O- RU extracts the SRS IQ data and perform SRS channel estimation for each UE, based onInkom till Patent- och registreringsverket w -irz- 1 §

[0162] the SRS configuration information received. The SRS channel estimates may be stored in

[0163] channel memory. Then, the O-RU determines the port to layer mapping per UE for the SRS antenna ports estimated from the received SRS. A UE may send SRS from different SRS

[0164] antenna ports in different slots. In this case, the port to layer mapping considers all channel estimates of all SRS antenna ports available in the channel memory, which may contain

[0165] channel estimates estimated for the SRS antenna ports from the SRS received in previous

[0166] slot(s) and the SRS antenna ports from the SRS received in the current slot. In the first

[0167] option mentioned previously, O-RU selects one SRS antenna port per layer. In this case,

[0168] port to layer mapping can be represented as a table mapping the SRS ports to the layers

[0169] with one port mapped to one layer. In the second option, O-RU selects multiple SRS

[0170] antenna ports per layer and calculates port to layer transformation weights (Wp2l) and

[0171] convert the original channel estimates of SRS antenna ports to the effective channel

[0172] estimates of layers using the weights. Typically, the same ports are used for all layers in

[0173] port to layer mapping when multiple ports are mapped to each layer. But different layers

[0174] will have different port to layer transformation weights. The effective channel estimates

[0175] may be stored in channel memory. Note that storing effective channel estimates in channel memory is not explicitly shown in Figure 7.

[0176] Figure 8 shows another implementation example for the proposed method. In Figure 8, the

[0177] port to layer mapping function is included in the SRS measurement block. The SRS measurement block also sends the indication for used channel estimates for bcamforming weights calculation. The indication for port to layer mapping and the indication for used

[0178] channel estimates may be sent using the same C-Plane mechanism as for RRM

[0179] measurements, e.g., using Section Type 10 specified in O-RAN open fronthaul

[0180] specification. Alternatively, the indication of used channel estimates may be sent using a

[0181] new Section Extension, e.g., using it together with Section Type 6 (or a new Section Type

[0182] for sending new channel estimates). In Figure 8, the scheduler and channel memory in O- DU are also shown. Note that storing effective channel estimates in channel memory is not explicitly shown in Figure 8.

[0183] When multiple SRS antenna ports per layer are used for beamforming weights calculation, the port to layer transformation weights may not be calculated when SRS channel

[0184] estimation is done for each UE. The transformation weights may be calculated when the beamforming weights are calculated after receiving the scheduling information. Therefore,Inkom till Patent- och registrerin sverket 'i / n

[0185] the transformation weights are only calculated for scheduled UEs, not for each UE, which may save some processing resources.

[0186] One functionality of port to layer mapping is to determine the valid SRS antenna ports and then map the valid SRS antenna port(s) to each layer. An SRS antenna port may be determined invalid if all channel estimates of the SRS antenna port have too lower power or too low SNR (signal to noise ratio) or SINR (signal to interface and noise ratio), e.g., lower than a threshold. This may happen when the SRS transmission request sent to a UE via PDCCH is lost, not received or decoded with errors. For example, the request is sent when UE doesn’t wake up from sleep state in DRX (discontinuous reception). Then, the UE will not send SRS. But cither O-DU or O-RU doesn’t know it. O-DU will still send the SRS configuration for this UE to O-RU and request O-RU to perform SRS channel estimation. Another example for invalid SRS antenna ports is that the channels of two antenna ports of one UE are highly correlated. It may be caused by bad UE antenna designs such that the antennas are not decorrelated enough. It may be caused by wrong antenna switching implementation such that the SRS transmissions of different SRS antenna ports are sent from one UE antenna. These invalid ports will be excluded from port to layer mapping and therefore will not be used for beamforming weights calculation since they will not contribute to radio performance.

[0187] After O-RU determines the port to layer mapping per UE, the O-RU sends to the O-DU via C-Plane an indication that the port to layer mapping is done and the layers are ready for beamforming. When one port is mapped to one layer, the indication can be a mapping table between ports and layers or a list of sorted ports where the port indicated by the ith port ID in the list is mapped to the ith layer), or number of layers (or a list of layers) indicating the layers ready for beamforming. When multiple ports are mapped to one layer, the indication can be a mapping table between ports and layers where multiple ports are indicated for each layer, the port to layer transformation weights or number of layers (or a list of sorted layers) indicating the layers ready for beamforming. In both cases, the indication may be a mapping table that list the port(s) used for each layer, e.g., Layer 0, 1, 2, 3. The order of layers is sorted in such way that the first L layers are used for rank L transmission per UE, i.e., transmitting L independent data streams. For example, the first layer (e.g., Layer 0) is the best layer that will be used for rank 1 transmission. In this case, the index of port to layer entries (each entry contains port(s) for one layer) indicates the layer index. So, ifSnkom till Patent- ooh f'eQis c?rinoc '''oO''0!.

[0188] layers are sorted, each entry only needs to contain the ports, which saves bits in the C-Plane signaling. As described previously, the ports in the port to layer mapping indication may be the valid ports determined by the O-RU. When the same ports are used for all layers in port to layer mapping, the indication can list the ports and indicate this is common for all ports, e.g., using a flag (field) to indicate this. This would avoid sending duplicated information and therefore save some bits for sending the indication via fronthaul interface. When number of layers (or a list of layers) is sent, the O-DU will not know how port to layer mapping is done in the O-RU. But it is sufficient for O-DU to determine the number of layers (rank of transmission) per UE and send the information to the O-RU via C-Plane, the O-RU will know which layers to be used for beamforming since the layers are sorted in the port to layer mapping.

[0189] Table 1-5 show different examples of port to layer mapping for a UE. In all examples, we assume the UE has 4 SRS antenna ports and the channel estimates of 4 SRS antenna ports are estimated and stored in channel memory. O-RU will determine which SRS ports are valid. Note that O-RU will determine the valid ports among the ports with available channel estimates. If only 2-port channel estimates are available (e.g., the SRS for the other 2 ports may come in a later slot), O-RU will determine which ports are available among these two ports. Later, when the channel estimates of all 4 ports arc available. O-RU will determine the valid ports among all 4 ports. So, maximumly the UE can have L layers, i.e., the maximum rank for this UE is L, where L equals to the number of valid SRS antenna ports determined by the O-RU. Then, O-RU calculates the port to layer mapping for each layer among L layers and send the port to layer indication to O-DU. Table 1 shows Example Al where 1 port is mapped to each layer, In Example Al, O-RU determines all 4 SRS antenna ports are valid ports. So, the maximum number of layers are 4. The mapping table lists 4 entries of port to layer mapping for Layer 0-3. Table 2 shows Example A2, another example where 1 port is mapped to each layer. In Example A2, O-RU determines SRS antenna port 1, 2 and 3 are valid and SRS antenna port 0 is invalid. Since one port is invalid, the maximum number of layers arc 3. The mapping table only lists 3 entries of port to layer mapping for Layer 0-2. Table 3 shows Example Bl where multiple ports are mapped to each layer. As described, for multiple:! mapping, the same ports are typically used for all layers. But different layers will have different port to layer transformation weights. In Example Bl, O-RU determines all 4 SRS antenna ports are valid ports. So, the maximum number of layers are 4. The mapping table shows one entry listing all valid portskom till Patent- och registreringsverket 2026 1 §

[0190] for all 4 layers (Layer 0-3). Table 4 shows Example B2, another example where multiple

[0191] ports are mapped to each layer. As described, for multiple:! mapping, the same ports are typically used for all layers. But different layers will have different port to layer

[0192] transformation weights. In Example B2, O-RU determines SRS antenna port 1, 2 and 3 are valid and SRS antenna port 0 is invalid. So, the maximum number of layers arc 3. The

[0193] mapping table shows one entry listing all 3 valid ports for the 3 layers (Layer 0-2). Table 5 shows a special example, Example B3 where multiple ports are mapped to each layer, but different layers may have different valid ports. In this example, Layer 2 use SRS antenna

[0194] port 2 and 3 which is different from other 2 layers.

[0195] Table 1 Port to layer mapping table example Al (1:1 mapping, all 4 ports determined valid) Layer 0 or first layer SRS antenna port 2

[0196] Layer 1 or second layer SRS antenna port 1

[0197] Layer 2 or third layer SRS antenna port 3

[0198] Layer 3 or fourth layer SRS antenna port 0

[0199]

[0200] Table 2 Port to layer mapping table example A2 (1:1 mapping, port 0 determined

[0201] invalid)

[0202] Layer 0 or first layer SRS antenna port 2

[0203] Layer 1 or second layer SRS antenna port 1

[0204] Layer 2 or third layer SRS antenna port 3

[0205]

[0206] Table 3 Port to layer mapping table example Bl (multiple:! mapping, all 4 ports determined valid)

[0207] Layer 0-3 or all 4 layers SRS antenna port 0, 1, 2, 3

[0208]

[0209] Table 4 Port to layer mapping table example B2 (multiple:! mapping, port 0 determined

[0210] invalid)

[0211] Layer 0-2 or first 3 layers SRS antenna port 1, 2, 3

[0212]

[0213] Table 5 Port to layer mapping table example B3 (multiple:! mapping, port 0 determinedInkom till Patent- och registreringsverkot W - I 5

[0214] invalid)

[0215] Layer 0 or first layer SRS antenna port 1, 2, 3

[0216] Layer 1 or second layer SRS antenna port 1, 2, 3

[0217] Layer 2 or third layer SRS antenna port 2, 3

[0218]

[0219] Example Al, A2, Bl and B2 represent typical cases for 1:1 and multiple:! mapping. One efficient way to convey the mapping table information (as port to layer indication) from O-RU to O-DU is that O-RU sends to O-DU a list of the mapped ports per UE and also an indication if 1:1 or multiple:! mapping is used. In this way, it is efficient to use one common data format / structure in C-Planc messaging to support both mapping methods. In O-RAN open fronthaul specification, Section Type 9 is used to send RRM measurements. This indication of port to layer mapping may be conveyed as a new measurement (a new Measurement Type) using Section Type 9. Table 6 shows an exemplified format of a new Measurement Type XX in Section Type 9 for port to layer mapping. In Measurement Type XX exemplified in Table 6, there are “portToLayerType” field and “numSrsUePortlds” field in Octet 3. Field “portToLayerType” indicates if port to layer mapping is 1:1 mapping or multiple:! mapping. For example, if portToLayerType = 00b, it indicates 1: 1 mapping (one port mapped to one layer). If portToLayerType = 01b, it indicates multiple: 1 mapping (multiple ports mapped to one layer) where the same ports are mapped to all layers. Field “numSrsUePortlds” indicates the number of ports contained in this measurement, which also indicates the number of valid ports and the maximum number of layers. Basically, O- RU assumes the number of layers equal to the number of valid ports. And then O-RU performs port to layer mapping for these layers. In Measurement Type XX, there are multiple srsUePortld fields. Each srsUePortld field represents an Id for an SRS antenna port and is indexed as the ith srsUePortld. If 1:1 mapping is indicated by “portToLayerType”, the ith srsUePortld indicates the srsUePort for the ith layer. The order of layers follows that the first L layers are used for rank L transmission per UE, i.e., transmitting L independent data streams. If multiple:! mapping is indicated by “portToLayerType”, the ports indicated by all srsUePortlds are mapped to each layer. With the knowledge of port to layer mapping type using 1:1 or multiple: 1 mapping and the ports for each layer indicated by O-RU, the O-DU can use it to make scheduling decisions according to port to layer mapping that O-RU would do. For example, O-RU reports 3 valid ports in port to layer mapping indication. The O-DU knows to use these 3 ports toInkom till Patent- och

[0220] • eg istre ri ngsverket ' UP -Ur I §

[0221] determine the rank for this UE. The rank determination may be done using the RRM measurements of these 3 ports and the channel estimates of these 3 ports, which are reported by the O-RU. Other scheduling parameters like MCS, UE paring, etc. can be done in the same way. Note that O-RU may declare via M-Planc a capability supporting 1: 1 mapping, multiple: 1 mapping, or both. If O-RU declares supporting both via M-Plane, O- DU may configure via M-Plane O-RU to use 1: 1 mapping, multiple: 1 mapping, or both.

[0222] Table 6

[0223] Example of measurement type format in Section Type 9 for port to layer mapping for a UE # of O(msb) 1 2 3 4 5 6 7(lsb) byte Octet s

[0224] mf measTypeld=XX 1 N reserved 1 N+1 measDataSize[15:0] 2 N+2 portToLayerType numSrsUePortlds 1 N+4

[0225] 1stsrsUePortld 2ndsrsUePortld 1 N+5 var var last srsUePortld 1 var

[0226]

[0227] padding to ensure 4-byte boundary var var

[0228] The O-RU may also send SRS channel estimates to the O-DU. The SRS channel estimates may be compressed before being sent, e.g., by frequency-domain downsampling. The SRS channel estimates sent can be the channel estimates of SRS antenna ports or the effective channel estimates of layers. When multiple ports are mapped to one layer, if O-RU only sends number of layers (a list of layers) and O-DU doesn’t know how port to layer mapping is done, it may be preferable to send the effective channel estimates of layers, such that the O-DU can use it for layer scheduling directly. If O-RU sends port to layer transformation weights and the channel estimates of SRS antenna ports, O-DU can calculate the channel estimates of layers by multiplying the transformation weights with the channel estimates of SRS antenna ports. If O-RU sends only the channel estimates of ports, the O-DU can use the received channel estimates to calculate port to layer mapping and effective channel estimates of layers. And the channel estimates may be only reported for valid ports.Inkom till Patent- och. egistreringsverket Tirt ■ ' 25

[0229] Further, O-RU may determine not using some low-quality channel estimates for

[0230] beamforming weights calculation. Radio performance may be improved by excluding these low-quality channel estimates (e.g., using zeros for these channel estimates instead when calculating beamforming weights) which may negatively affect the performance if using them for beamforming. As shown in Figure 8, if O-RU sends the channel estimates, the O-RU may also send an indication for used channel estimates for beamforming weights calculation, indicating which channel estimates among all channel estimates per SRS

[0231] antenna port or per layer are used for beamforming weights calculation. For example, for each frequency point under certain frequency resolution, there are K channel estimates per SRS antenna port or layer for a UE, where K represents the number of O-RU antennas (or beams). The indication may indicate which channel estimates among the K channel

[0232] estimates per SRS antenna port or layer for a UE are used. For example, the indication can be a bitmask of K bits for each SRS antenna port or layer, where each bit represents the indication for each of the K channel estimates. If a bit in the bitmask for a channel estimate is set to ‘ 1 ’, it indicates this channel estimate is used for beamforming weights calculation.

[0233] If a bit in the bitmask for a channel estimate is set to ‘O’, it indicates this channel estimate is not used for beamforming weights calculation. In this way, O-DU knows which channel estimates per SRS antenna port or layer are used for beamforming weights calculation in the O-RU. The scheduler in the O-DU will consider the used channel estimates for determining scheduling decisions, as shown in Figure 8. This indication may only indicate for the channel estimates of valid ports. This indication may be implicitly indicated by

[0234] sending zeros or invalid values for unused channel estimates in the channel estimate report.

[0235] But O-DU will not receive the original values of these channel estimates which could be used for other purposes, e.g., for debugging, estimating noise, etc. If channel estimates are sent for all ports (both valid and invalid), then this indication will set all-zero bitmask for the channel estimates of any invalid port. In principle, determination of which channel estimates are used for beamforming weights calculation may be done by O-DU based on the channel estimates reported by O-RU. To determine this accurately, O-DU would require O-RU to report the channel estimates in higher resolution (e.g., higher frequency resolution, more beams) and higher precision (e.g., with more bits to represent the channel estimates) which would significantly increase the fronthaul load.^nkom till Patent- och ■^gistreringsverket

[0236]

[0237] -Liu- 15

[0238] The indication for used channel estimates may be conveyed as a new measurement (a new Measurement Type) using Section Type 9. Table 7 shows an exemplified format of a new Measurement Type YY in Section Type 9 for indication for used channel estimates. In Measurement Type YY exemplified in Table 7, there are “bitMaskSize” field and

[0239] “srsUePortld” field in Octet 3. Field bitMaskSize indicates the size of bitMask which may

[0240] be the number of bytes the bitmask field uses or may be the number of bits of bitmask used for indicating used channel estimates. Nevertheless, the number of bits of bitmask used for indicating used channel estimates equal to the number of antennas or beams used by the 0- RU. The srsUePortld field represents an Id for a specific SRS antenna port for which the

[0241] bitmask applies. Then, there is a bitmask field for one or more bytes to indicate the channel estimates used for beamforming weights calculation, as described previously. In addition, the bitmask may be conveyed by a new Section Extension, e.g., used together with Section

[0242] Type 6 or a new Section Type which are used for conveying channel estimates from O-RU

[0243] to O-DU.

[0244] Table 7

[0245] Example of measurement type format in Section Type 9 for indication for used channel estimates

[0246] # of

[0247] (msb) 1 2 3 4 5 6 7(lsb) byte Octet s

[0248] mf measTypeld=YY 1 N reserved 1 N+1 measDataSize[15:0] 2 N+2 bitMaskSize srsUePortld 1 N+4

[0249] first byte of bitmask 1 N+5

[0250] var var last byte of bitmask 1 var

[0251]

[0252] padding to ensure 4-byte boundary var var

[0253] In addition to indication for port to layer mapping and indication for used channel

[0254] estimates, the O-RU sends also SRS RRM measurement to provide O-DU more

[0255] information, e.g., to assist scheduling and for other purposes. For some RRM

[0256] measurements, they can be measured per SRS antenna port or per layer. When multiple

[0257] ports are mapped to one layer, it may be preferable to measure them per layer, such that the

[0258] O-DU can use it directly for layer scheduling. Even if O-RU sends the port to layer transformation weights, it is not possible to convert measurements per port to

[0259] measurements per layer. When one port is mapped to one layer, the RRM measurementsInkom till Patent- och registreringsverket

[0260] > 25

[0261] can be done either per SRS antenna port or per layer, since they are one to one mapped. For port-specific measurements, it may calculate and report for valid ports only.

[0262] With received SRS RRM measurements and channel estimates (if sent by O-RU) as well as other information received (e.g., UE CSI report, DMRS RRM measurements), O-DU makes scheduling decisions per slot regarding UE layer pairing for SU-MIMO and MU-MIMO, PRB allocation of UEs, MCS, etc. The O-DU will send to the O-RU via C-Plane the scheduling information to instruct O-RU calculates the beamforming weights for the scheduled layers based on the effective channel estimates of layers which is obtained based on the port to layer mapping calculated previously. Note the effective channel estimates of layers may be obtained from channel memory, which is not shown in Figure 7 and Figure 8. Then, the O-RU performs the beamforming for the scheduled layers using the calculated beamforming weights.

[0263] Furthermore, Figure 9 shows an exemplified flow chart of the proposed method, describing the steps that may be used in the proposed method.

[0264] Figure 10 shows an example of a communication system 1000 in accordance with some embodiments.

[0265] In the example, the communication system 1000 includes a telecommunications network 1002 that includes an access network 1004, such as a radio access network (RAN), and a core network 1006, which includes one or more core network nodes 1008. The access network 1004 includes one or more access network nodes or base stations of various types, access network nodes 1010A and 1010B are depicted (which may be collectively referred to as network nodes 1010), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non- 3GPP access points (APs). Some embodiments of the access network 1004 may include more than one access network technology. The network nodes 1010 of access network 1004 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs), such as by connecting UEs 1012A, 1012B, 1012C, and 1012D (one or more of which may be generally referred to as UEs 1012) to the core network 1006 over one or more wireless connections.Inkom till Potent- och

[0266] / eg istreri ng s ve rk.et - "tJZ- s

[0267] Moreover, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion arc 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 telecommunications network 1002 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network 1002 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 network nodes to implement one or more functionalities of any network node in the telecommunications network 1002, including one or more access network nodes 1010 and / or core network nodes 1008.

[0268] 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). An ORAN network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN network 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.

[0269] The network nodes 1010 facilitate direct or indirect connection of one or more UEs 1012 to the core network 1006 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 1000 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 1000 may include and / or interface withInkom till Patent- och:' g i stre ri ngsve rket jj / J; ‘U / ." Z { / )

[0270] any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0271] The UEs 1012 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 1010 and other communication devices. Similarly, the network nodes 1008, 1010 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network 1002) with the UEs 1012 and / or with other network nodes or equipment in the telecommunications network 1002 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network 1002. More specifically, UEs 1012 may send messages, data, and / or other signals to network nodes 1008, 1010 or other elements of the telecommunications network 1002 by transmitting such signals to the relevant device directly without the signals passing through any intervening devices or by transmitting such signals to the relevant device indirectly through an intervening device (or multiple intervening devices) that then transmit the signal to the relevant device. Similarly, network nodes 1008, 1010 may send messages, data, and other signals to UEs 10122, other network nodes 1008, 1010, and other devices in telecommunications network 1002 directly or indirectly. As one specific example, a core network node 108 may transmit a particular message to a UE 1012 by transmitting the message to an access network node 1010 that will then transmit the message to the intended UE 1012. Similarly, a core network node 108 may receive a particular message from a UE 1012 by receiving the message from an access network node 1010 that itself received the message from the UE 1012.

[0272] In the depicted example, the core network 1006 connects elements of the access network 1004 (e.g., one or more of the network nodes 1010) to one or more host computing systems, such as host 1016. 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 1006 includes one or more core network nodes (e.g., core network node 1008) of various types, one or more of which may be generally referred to as network nodes 1008. Network nodes 1008 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1008. Example core network nodes provide functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management FunctionInkom till Patent- och registreringsvefket tljik "'iK" 5

[0273] (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).

[0274] The host 1016 may be under the ownership or control of a service provider other than an operator or provider of the access network 1004 and / or the telecommunications network 1002. The host 1016 may be operated by the service provider or on behalf of the service provider. The host 1016 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.

[0275] As a whole, the communication system 1000 of Figure 10 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 1000 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but arc 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 (Wi-Fi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (Wi-Max), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, Li-Fi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. Moreover, the communication system 1000 may be configured to support multiple different standards, protocols, or other rule sets, with individual components supporting all of the relevant rule sets or with different components or sub-systems within the communication system 1000 supporting different standards, protocols, or rule sets.

[0276] As one example, in certain embodiments, access network 1004 may contain some access network nodes 1010 that support 3GPP radio access technologies (RAT), such as LTE or NR, while other access network nodes 1010 support (or the same access network nodes 1010 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network 1002 may support multiple generations of related communication standards (e.g., 4G and 5G 3GPP communication standards) and, as a result,Jnkom till Patent- och reg ist re ri ng sverk.ei

[0277] may include an access network 104 and / or a core network 106 that supports multiple different standard generations or may include multiple access networks 104 and / or multiple core networks 106 with individual networks 104, 106 supporting different standard generations. Telecommunications network 1002 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network 1002. For example, the telecommunications network 1002 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 loT services to yet further UEs.

[0278] In some examples, one or more of the UEs 1012 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 1004 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1004. 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).

[0279] In the example, the hub 1014 communicates with the access network 1004 to facilitate indirect communication between one or more UEs (e.g., UE 1012C and / or 1012D) and network nodes (e.g., network node 1010B). In some examples, the hub 1014 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1014 may be a broadband router enabling access to the core network 1006 for the UEs. As another example, the hub 1014 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 1010, or by executable code, script, process, or other instructions in the hub 1014.

[0280] As another example, the hub 1014 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 1014 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1014 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1014 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1014 acts as aInkom till Patent- och fegistreringsverket

[0281]

[0282] -CZ- I 5

[0283] proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0284] The hub 1014 may have a constant / persistent or intermittent connection to the network node 1010B. The hub 1014 may also allow for a different communication scheme and / or schedule between the hub 1014 andUEs (e.g., UE 1012C and / or 1012D), and between the hub 1014 and the core network 1006. In other examples, the hub 1014 is connected to the core network 1006 and / or one or more UEs via a wired connection. Moreover, the hub 1014 may be configured to connect to an M2M service provider over the access network 1004 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1010 while still connected via the hub 1014 via a wired or wireless connection.

[0285] In some embodiments, the hub 1014 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 1010B. In other embodiments, the hub 1014 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1010B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0286] Figure 11 is another example of a communication system 1100 according to some embodiments. As used herein, the communication system 1100 includes multiple access points (APs) 1110 (with four exemplary APs 1110A, 1110B, 1110C, and 1110D being depicted) and multiple wireless devices, referred to in the context of communication system 1100 as stations (STAs) 1112 (referred to individually as STA 1112A, STA 1112B, STA 1112C, STA 1112D, and STA 1112E). STA 1112A is served by AP 1110A in a first basic service set (BSS) 1120A.

[0287] STA 1110B and STA 1110C are served by AP 1110B in a second BSS, BSS 1120B. STA 1112D is served by AP 1110C in a third BSS, BSS 1120C. STA 1112E is served by AP 1110D in a fourth BSS, BSS 1120D. Stations 1112 may be non-AP STAs and correspond to various kinds of wireless devices, for example, user terminals, such as mobile or stationary computing devices like smartphones, laptop computers, desktop computers, tablet computers, gaming devices, head-mounted displays (HMDs) for Augmented Reality (AR) or Virtual Reality (VR), or the like. Further, stations 1112 could, for example, correspond to other kinds of equipment like smart home devices, printers, multimedia devices, data storage devices, or the like.

[0288] Each of STAs 1112 may connect through a radio link to one of APs 1110. For example, depending on location or channel conditions experienced by a given STA 1112, the STA may select an appropriate AP and BSS for establishing the radio link. The radio link may be based on one or more orthogonal frequency-division multiplexing (OFDM) carriers from a frequencyInkom till Patent- och

[0289] reqistferinqsverket

[0290] J't o

[0291] spectrum that is shared on the basis of a contention-based mechanism, e.g., an unlicensed or license exempt band like 2.4 GHz Industrial, Scientific, and Medical (ISM) band, the 5 GHz band, the 6 GHz band, or the 60 GHz band.

[0292] Each AP 1110 may provide data connectivity to ST As 1112 connected to a particular AP 1110. As illustrated, APs 1110 may be connected to a data network 1130. In this way, APs 1110 may also provide data connectivity between STAs 1112 and other entities, e.g., to one or more servers, service providers, data sources, data sinks, user terminals, or the like. Accordingly, the radio link established between a given ST A 1112 and its serving AP 1110 may be used for providing various kinds of services to STA 1112, e.g., a voice service, a multimedia service, or other data service. Such services may be based on applications that are executed on STA 1112 and / or on a device linked to STA 1112. By way of example, Figure 11 illustrates an application service platform 1132 provided in data network 1130. The application(s) executed on STA 1112 and / or on one or more other devices linked to STA 1112 may use the radio link for data communication with one or more other STA 1112 and / or the application service platform 1132, thereby enabling utilization of the corresponding service(s) at STA 1112. Figure 12 shows a wireless device 1200, which may be configured to operate in communication system 1000 of Figure 10 or in communication system 1100 of Figure 110. The wireless device 1200 may be alternatively referred to as a UE 1200, like a UE 1012 within the context of communication system 1000, or as a station (STA) 1200 or as a non-access-point station (non-AP STA) 1200, like a STA 1112 within the context of the communication system 1100, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device 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 device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptopmounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of 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.

[0293] A wireless device 1200 may support device-to-devicc (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-RangeInkom till Patent- och

[0294] reqistrerinqsverket '?i ■ 15

[0295] Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, wireless device 1200 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device 1200 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, wireless device 1200 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).

[0296] In particular embodiments, wireless device 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input / output interface 1206, a power source 1208, a memory 1210, a communication interface 1212, and / or any other component, or any combination thereof. Certain embodiments of wireless device 1200 may include all or a subset of the components shown in Figure 12. The level of integration between the components may vary from one embodiment of wireless device 1200 to another. In general, in a particular embodiment of wireless device 1200, processing circuitry 1202, input / output interface 1206, power source 1208, memory 1210, and communication interface 1212 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of wireless device 1200. Further, certain embodiments of wireless devices 1200 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0297] The processing circuitry 1202 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 1210. The processing circuitry 1202 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 appropriate firmware; 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 1202 may include multiple central processing units (CPUs). In the example, the input / output interface 1206 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 wirelessinkom till Patent- och re 0 i s t r e ri n o s \' e r k e t

[0298] device 1200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (c.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.

[0299] In some embodiments, the power source 1208 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 to supply power to circuitry or to charge an associated battery. The power source 1208 may further include power circuitry for delivering power from the power source 1208 itself, and / or an external power source, to the various parts of wireless device 1200 via input circuitry or an interface such as an electrical power cable. Power source 1208 may perform any formatting, converting, or other modification to make accessible power suitable for the respective components of the wireless device 1200 to which power is supplied.

[0300] The memory 1210 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 1210 includes one or more programs 1214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1216. The memory 1210 may store, for use by wireless device 1200, any of a variety of various operating systems or combinations of operating systems.

[0301] The memory 1210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash 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 circuitinkom till Patent- och registreringsverket

[0302] 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 1210 may allow wireless device 1200 to access instructions, 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 1210, which may be or comprise a device-readable storage medium.

[0303] The processing circuitry 1202 may be configured to communicate with an access network or other network via or using the communication interface 1212. The communication interface 1212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1222. The communication interface 1212 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 wireless device or a network node in an access network). Each transceiver may include a transmitter 1218 and / or a receiver 1220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., antenna 1222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0304] In the illustrated embodiment, communication functions of the communication interface 1212 may include cellular communication, Wi-Fi communication (e.g., according to an IEEE 802.11 family standard), 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 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.

[0305] In particular embodiments, wireless device 1200 may provide an output of data captured via a sensor, through its communication interface 1212, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device 1200 can beInkom till Patent- och

[0306] ( jpistrennosvsrloi

[0307] communicated through a wireless connection to a network node via another wireless device 1200. In particular embodiments, such 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).

[0308] As another example, wireless device 1200 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, wireless device 1200 may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0309] Wireless device 1200, 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, wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device arc 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, a flood / 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, a fitness 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. In particular embodiments, wireless device 1200 represents an IoT device that 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 example embodiment of wireless device 1200 shown in Figure 12.

[0310] As yet another specific example, in an IoT scenario, wireless device 1200 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 wireless device and / or a network node. Wireless device 1200 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, wireless device 1200 mayInkom till Patent- och

[0311] registreringsverket

[0312] implement the 3GPP NB-IoT standard. In other scenarios, wireless device 1200 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.

[0313] In practice, any number of wireless devices 1200 may be used together with respect to a single use case. For example, a first wireless device 1200 might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second wireless device 1200 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device 1200 may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second wireless device 1200 can also include more than one of the functionalities described above. For example, wireless device 1200 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0314] Figure 13 shows a network node 1300 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 telecommunications network. In accordance with respective embodiments, network node 1300 may be configured to operate in communication system 1000 of Figure 10, like network nodes 1008 or 1010, or in communication system 1100 of Figure 11, like an AP 1110 or a station 1112. 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).

[0315] Network nodes 1300 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. Network node 1300 may be a relay node or a relay donor node controlling a relay. Network nodes 1300 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).Inkom till Patent- ooh registreringsverket 126 12- 25

[0316] Other examples of network nodes 1300 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).

[0317] In particular embodiments, network node 1300 includes a processing circuitry 1302, a memory 1304, a communication interface 1306, and a power source 1308. In general, in a particular embodiment of network node 1300, processing circuitry 1302, memory 1304, communication interface 1306, and power source 1308 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of network node 1300. The network node 1300 may be composed of multiple distinct network entities (e.g., a NodeB entity and a RNC entity, or a BTS entity and a BSC entity, etc.), which may each have or utilize their own respective physical components. In certain scenarios in which the network node 1300 comprises multiple such entities (e.g., BTS and BSC), one or more of the separate entities 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 1300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memories 1304 or portions of memory 1304 for different RATs) and some components may be reused (e.g., a same antenna 1310 may be shared by different RATs). The network node 1300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1300, for example GSM, WCDMA, LTE, NR, Wi-Fi (e.g., according to an IEEE 802.11 family standard), 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 1300.

[0318] The processing circuitry 1302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, applicationspecific 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 components, such as the memory 1304, to provide network node 1300 functionality.Inkom till Patent- och registreringsverket 2026

[0319] In some embodiments, the processing circuitry 1302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1302 includes one or more of radio frequency (RF) transceiver circuitry 1312 and baseband processing circuitry 1314. In some embodiments, the RF transceiver circuitry 1312 and the baseband processing circuitry 1314 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 1312 and baseband processing circuitry 1314 may be on the same chip or set of chips, boards, or units.

[0320] The memory 1304 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, a flash 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 1302. The memory 1304 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 1302 and utilized by the network node 1300. The memory 1304 may be used to store any calculations made by the processing circuitry 1302 and / or any data received via the communication interface 1306. In some embodiments, the processing circuitry 1302 and memory 1304 is integrated.

[0321] The communication interface 1306 is used in wired or wireless communication of signaling and / or data with UEs, other network nodes, and / or any other network equipment. In the illustrated embodiment, communication interface 1306 comprises port(s) / terminal(s) 1316 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node 1200 may be capable of wireless communication and communication interface 1306 may also include radio front-end circuitry 1318 that may be coupled to, or in certain embodiments a part of, an antenna 1310. Particular embodiments of radio front-end circuitry 1318 include filter(s) 1320 and amplifier(s) 1322. The radio front-end circuitry 1318 may be connected to an antenna 1310 and processing circuitry 1302. The radio front-end circuitry may be configured to condition signals communicated between antenna 1310 and processing circuitry 1302. The radio front-end circuitry 1318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio frontend circuitry 1318 may convert the digital data into a radio signal(s) having the appropriateInkom till Patent- och registreringsverket " Hr I §

[0322] channel and bandwidth parameters using a combination of filters 1320 and / or amplifiers 1322. The radio signal(s) may then be transmitted via the antenna 1310. Similarly, when receiving data, the antenna 1310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1318. The digital data may be passed to the processing circuitry 1302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0323] In certain alternative embodiments, network node 1300 may be capable of wireless communication but does not include separate radio front-end circuitry 1318, instead, the processing circuitry 1302 includes radio front-end circuitry and is connected to the antenna 1310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1312 is part of the communication interface 1306. In still other embodiments, the communication interface 1306 includes one or more ports or terminals 1316, the radio front-end circuitry 1318, and the RF transceiver circuitry 1312, as part of a radio unit (not shown), and the communication interface 1306 communicates with the baseband processing circuitry 1314, which is part of a digital unit (not shown).

[0324] The antenna 1310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1310 may be coupled to the radio front-end circuitry 1318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1310 is separate from the network node 1300 and connectable to the network node 1300 through one or more interfaces or ports.

[0325] The antenna 1310, communication interface 1306, and / or the processing circuitry 1302 may be configured to perform some or all of the receiving operations and / or obtaining operations described herein as being performed by the network node 1300. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1310, the communication interface 1306, and / or the processing circuitry 1302 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node 1300. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 1308 provides power to the various components of network node 1300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1300 with power for performing the functionality described herein. For example, the network node 1300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an inputInkom till Patent- ooh registreringsverket 2026 -92- 25

[0326] circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1308. As a further example, the power source 1308 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.

[0327] Embodiments of the network node 1300 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 1300 may include user interface equipment to allow input of information into the network node 1300 and to allow output of information from the network node 1300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1300.

[0328] Figure 14 is a block diagram illustrating a virtualization environment 1400 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 1400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, UE, core network node, or host. Further, in embodiments in which a 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 1400 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.

[0329] Applications 1402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0330] Hardware 1404 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 beJnkom till Patent- och registreringsverket biZ " JZ“ t 5

[0331] executed by the processing circuitry to instantiate one or more virtualization layers 1406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VM 1408A and VM 1408B (which may be collectively referred to as VMs 1408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1406 may present a virtual operating platform that appears like networking hardware to one or more of the VMs 1408.

[0332] The VMs 1408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by virtualization layer 1406. Different embodiments of the instance of a virtual appliance 1402 may be implemented on one or more of VMs 1408, 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.

[0333] In the context of NFV, each of the VMs 1408 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 1408, and that part of hardware 1404 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 of the VMs 1408 on top of the hardware 1404 and corresponds to an application 1402.

[0334] Hardware 1404 may be implemented in a standalone network node with generic or specific components. Hardware 1404 may implement some functions via virtualization. Alternatively, hardware 1404 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 1410, which, among others, oversees lifecycle management of applications 1402. In some embodiments, hardware 1404 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 1412 which may alternatively be used for communication between hardware nodes and radio units.Inkom till Patent- och reg i st re ri n g s ve rket -p n

[0335] Although the computing devices described herein (e.g., UEs, network nodes, hosts) 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 or firmware and computationally intensive functions may be implemented in hardware.

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

[0337] REFERENCES

[0338] [1] O-RAN Control, User and Synchronization Plane Specification 16.01,*nkom till Patent- och

[0339] registreringsverke '

[0340] W "02- 25

[0341] A layer, also called user layer represents an independent data stream transmitted or received over a spatial channel. Transmission / rcception for a layer may use a set of layer-specific beamforming weights in the O-RU and a set of layer-specific antenna port weights in the UE. Antenna port weights assumed to be applicable at the UE for receiving or transmitting a layer can be used by the O-RU to transform channel estimates for the antenna ports into a channel estimate for the layer.

[0342] NUMBERED EMBODIMENTS

[0343] 1. A method performed in an O-RAN O-RU comprising the following steps, determining a mapping of UE antenna ports to layer(s),

[0344] sending an indication of a result of the mapping to an O-RAN O-DU and

[0345] receiving, from the O-DU, a result of a scheduling decision based at least in part on the indication that was sent to the O-DU.

[0346] 2. A method according to numbered embodiment 1 wherein the mapping is based on estimates of channels between the O-RU and the UE antenna ports.

[0347] 3. A method according to any preceding numbered embodiment wherein the channel estimates are based on SRS sent from the UE antenna ports and received by the O-RU.

[0348] 4. A method according to any preceding numbered embodiment wherein the SRS is received on air interface resources corresponding to an SRS configuration indicated in a message sent from the O-DU to the O-RU.

[0349] 5. A method according to any preceding numbered embodiment comprising the further step of determining beamforming weights for transmission to at least one of the one or more UEs based on the received result of the scheduling decision

[0350] 6. A method according to any preceding numbered embodiment comprising the further step of receiving, from the O-DU, an indication of signal to be transmitted to at least one of the one or more UEs.

[0351] 7. A method according to any preceding numbered embodiment comprising the further step of transmiting the indicated signal to the at least one of the one or more UEs using the determined beamforming weights.

[0352] 8. A method performed in an O-RAN O-RU comprising the following steps:

[0353] - receiving, from an O-RAN O-DU an indication of an SRS configuration for one or more UEs, the configuration indicating air interface resource elements for sending SRS by the UEs, - receiving, from the one or more UEs, SRS sent according to the configuration,

[0354] - estimating, based on the received SRS, and for the one or more UEs, a channel per antenna port,

[0355] - determining, based on the estimated channels, a port to layer mapping for at least one of the one or more UEs,

[0356] - sending, to the O-DU an indication of a result of the mapping,Inkom till Patent- ooh registrar! n gsv e rket

[0357] - I 5

[0358] - receiving, from the O-DU the result of a scheduling decision based on the indication of the result of the mapping.

[0359] - determining beamforming weights for transmission to at least one of the one or more UEs based on the received result of the scheduling decision.

[0360] - receiving, from the O-DU, an indication of signal to be transmitted to at least one of the one or more UEs,

[0361] - transmitting the indicated signal to the at least one of the one or more UEs using the determined beamforming weights.

[0362] 8a. A method according to claim 8 or 9 wherein the SRS configuration indicates SRS resource elements allocation and SRS configuration parameters of the SRS sent or to be sent by the UEs from their UE antenna ports.

[0363] 9. A method performed in an O-RAN O-DU comprising the following steps:

[0364] - receiving from an O-RAN O-RU, an indication of a result of a mapping of UE antenna ports to layer(s),

[0365] - taking a scheduling decision based at least in part of the received indication, and

[0366] - sending a result of the scheduling decision to the O-RU.

[0367] 10. A method according to numbered embodiment 9 comprising the step of sending to the O-RU, prior to receiving the indication of a result of a mapping of UE ports to layers, an indication of an SRS configuration for one or more UEs, the configuration indicating air interface resource elements for sending SRS by the UEs.

[0368] 11. A method according to any of numbered embodiments 9-10 comprising the further step of sending to the O-RU an indication of signal to be transmitted to at least one of the one or more UEs.

[0369] 12. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers is an indication of which layer(s) are ready for beamforming.

[0370] 12a. A method according to claim 12 wherein the beamforming is SRS-based beamforming.

[0371] 13. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers is an indication of the effective channel estimates of layers after port to layer mapping.

[0372] 14. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers is an indication of a number of layers or a list of layers.

[0373] 15. A method according to any preceding claim wherein the indication of a result of a mapping ofUE antenna ports to layers is an indication of how channel estimates of SRS antenna ports are transformed into channel estimates of layers.

[0374] 16. A method according to any preceding numbered embodiment wherein the O-DU has received channel port channel estimate(s) and / or RRM measurements for a port(s) andInkom till Patent- ocn reg i stre ring sve rk.et

[0375] 25

[0376] the indication of a result of a mapping of UE antenna ports to layers is an indication of which SRS ports to be used for calculating beamforming weights for a layer.

[0377] 17. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers indicates a sorted list of SRS ports, and the mapping of ports to layers is 1:1.

[0378] 18. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers indicates port-to-layer transformation weights.

[0379] 19. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers indicates a list of layer identifiers.

[0380] 20. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers indicates channel estimates of sorted antenna ports.

[0381] 21. A method according to any preceding numbered embodiment wherein the indication of a result of a mapping of UE antenna ports to layers indicates a mapping table between ports and layers.

[0382] 22. A sorted list of ports wherein the position of the port in the list indicates which layer it is mapped to.

[0383] 23. An O-RAN O-RU adapted to perform the method of any of the preceding numbered embodiments except when dependent on numbered embodiment 9.

[0384] 24. An O-RAN O-DU adapted to perform the method of any of the preceding numbered embodiments when dependent on numbered embodiment 9.

[0385] 25. A method according to any preceding numbered embodiment wherein the communication between the O-RU and the O-DU takes place over a O-RAN fronthaul connection.Jnkorn till Patent- och reg j st re ri n g s verket 2026 <- 2

[0386] With respect to a UE antenna port, “invalid” can mean that the port will not or should not be used, either by O-RU or O-DU, for e.g. reception, transmission, determination of scheduling parameters, channel estimation or determining of beamforming weights.

[0387] Invalid can also mean that that signal supposedly transmitted or received by the port is

[0388] unlikely to make a useful contribution to channel estimation or signal transmission or

[0389] reception in addition to using the other ports of the UE.

[0390] Valid means that the port is not invalid.

[0391] 30. A method performed by an O-RAN O-RU comprising sending a message to an O-RAN

[0392] O-DU.

[0393] 31. A method according to numbered embodiment 30 wherein the message indicates, for a

[0394] UE, the UE ports that are valid.

[0395] 32. A method according to numbered embodiment 30 wherein the message indicates, for a

[0396] UE, which ports were used for determining beamforming weights.

[0397] 33. A method according to numbered embodiment 30 wherein the message indicates, for a

[0398] UE, channel estimates for valid ports but not for invalid ports.

[0399] 34. A method according to numbered embodiment 30 wherein the message indicates, for a

[0400] UE, channel estimates that will be used for beamforming.

[0401] 35. A method according to numbered embodiment 34 wherein channel estimates that will not be used or were not used for beamforming are indicated as channel estimates having a special or zero value indicating non-use.

[0402] 36. A method according to numbered embodiment 30 wherein the message indicates, for a

[0403] UE, port to layer mappings for valid ports but not for invalid ports.

[0404] 37. A method according to numbered embodiment 37 wherein the port to layer mappings are indicated in the form of a table which contains mappings for valid ports only.

[0405] 38. A method according to any preceding numbered embodiment wherein channel estimates of low quality are excluded when the O-RU performs beamforming.

[0406] 39. A method according to any preceding numbered embodiment wherein O-RU determines port to layer transformation weights in response to receiving scheduling information for the UE.

[0407] 40. A method according to any of numbered embodiments 30-39 wherein the O-RU

[0408] determines, for a UE, which ports are valid and which are invalid.

[0409] 41. A method according to numbered embodiment 40 wherein O-RU determines a port to be invalid based on one or more of low power, high noise, low SNR or SINR, high correlation with another port of the UE.HiMjin mi latent- och r e a ■ str e ri n g s ve rke i I §

[0410] 42. A method according to any numbered embodiment when dependent on numbered embodiment 30 wherein the message is sent on a fronthaul connection between the O-RU and the O-DU.

[0411] 43. A method according to any of the numbered embodiments 30-42 wherein the message comprises an indication of whether the port to layer mapping for a UE maps each one layer to one port only (1:1 mapping) or it maps each one layer to multiple ports (multiple: 1 mapping), such as all ports or all valid ports.

[0412] 44. A method according to any of the numbered embodiments 30-43 wherein the message comprises an indication of whether the O-RU has the capability to do 1: 1 mapping or multiple:! mapping or both.

[0413] 45. A method wherein an O-DU configures an O-RU to use 1: 1 mapping, or to use multiple: 1 mapping, or to use both.

[0414] 50. A method according to any of the numbered embodiments 30-45 in combination with any of the numbered embodiments 1-25.

[0415] 51. A method performed in an O-RAN O-RU comprising the step of

[0416] sending to an O-RAN O-DU an indication of a result of a mapping of UE antenna ports to layers or an indication of a result of determining a channel estimate for at least one UE antenna port or an indication related to a UE port or channel estimate.Inkom till Patent- ooh

[0417] registreringsverket 28 15

[0418] APPENDIX: Ericsson O-RAN WG4 SRS-BF WI contribution

[0419] Port to layer mapping in O-RU

[0420] Background

[0421] • A UE may have multiple SRS antenna ports, corresponding to the UE's receive capability, e.g., 4R

[0422] • Port to layer mapping is used to map the port channel to the layer channel for beamforming weights calculation

[0423] — 1:1 mapping: one port is mapped to each layer. Different port is mapped to different layer — Multiple:! mapping: multiple ports are mapped to one layer. The same ports are mapped to different layers. For multiple:! mapping, we don't see use case to map different sets of ports to different layers

[0424] • Question: in SRS-BF, where is port to layer mapping done?

[0425] — ERI and NOK propose that port to layer mapping is done in O-RLJ

[0426] — SAM proposes that port to layer mapping is done in O-DU

[0427] Proposal: port to layer mapping in O-RU

[0428] • In WDBF, SRS channel estimation, beamforming weights calculation and port to layer mapping are all in O-DU

[0429] — These three functionalities are tightly connected.

[0430] • In SRS-BF, SRS channel estimation and beamforming weights calculation are moved to O- RU. It is natural to move port to layer mapping to O-RIJ as well

[0431] Proposal: port to layer mapping in O-RU

[0432] — O-RU performs SRS channel estimation per UE and updates the channel estimates in channel memory

[0433] — O-RU determines the valid ports per UE for beamforming weights calculation. The largest possible number of layers for a UE equals to the number of valid ports for the UE

[0434] — O-RU determines port to layer mapping for each layer between the valid ports and the largest possible number of layers. Note that O-RU doesn't determine the rank, which will be part of the scheduling determined by the O-DU.

[0435] — O-RU sends the port to layer mapping information to O-DU

[0436] • In M-Plane, we also propose that O-RU declares a capability supporting 1:1 mapping, multiple:! mapping, or both, while O-DU configures O-RU to use either or both if O-RU supports both

[0437] Figure 16 shows an example of port to layer mapping.

[0438] Figure 17 shows an example of measurement type XX for conveying port to layer mapping.Inkom till Patent- och registreringsverket

[0439] Port to layer mapping in O-RU vs. in O-DU

[0440] • SRS channel estimation, beamforming weights calculation and port to layer mapping are tightly connected LI functionalities. To get full parity to WDBF performance, these LI functionalities should stay together in O-RU for SRS-BF

[0441] • Splitting port to layer mapping to O-DU will require more channel estimates sent back from O-RU to O-DU, which will increase fronthaul traffic

[0442] Summary

[0443] • In this contribution, we presented two proposals

[0444] — Proposal 1: perform port to layer mapping in O-RU and send port to layer mapping information from O-RU to O-DU. In M-Plane, we also propose that O-RU declares a capability supporting 1:1 mapping, multiple:! mapping, or both, while O-DU configures O-RU to use either or both if O-RU supports both

[0445] — Proposal 2: new Measurement Type XX to convey port to layer mapping information • We propose these two proposals to be mandatory to support for SRS-BF

[0446] Some abbreviations

[0447] BF Beamforming

[0448] DL Downlink

[0449] MIMO Multiple Input Multiple Output

[0450] MU-MIMO MultiUser MIMO

[0451] SRS Sounding Reference Signal

[0452] SRS-BF SRS-based beamforming

[0453] SU- MIMO Single User MIMO

[0454] UE User Equipment

[0455] UL Uplink

Claims

25-02-2026Inkom till Patent- och reg istre ring sve rke 15CLAIMS1. A method performed by an O-RAN O-RU comprising sending a message to an O-RAN O-DU wherein the message indicates, for a UE, channel estimates that will be used for beamforming.

2. A method according to claim 1 wherein channel estimates of low quality are excludedwhen the O-RU performs beamforming.

3. A method according to claim 1 or 2 wherein the O-RU determines, for a UE, which ports are valid and which are invalid.

4. A method according to any preceding claim wherein the O-RU sends a message to the O-DU which indicates, for a UE, the UE ports that are valid.

5. A method performed by an O-RAN O-DU comprising receiving a message from an O-RAN O-RU wherein the message indicates, for a UE, channel estimates that will be used for bcamforming.

6. A method according to claim 5 wherein for channel estimates of low quality, the message does not indicate that these will be used for beamforming.

7. A method according to claim 5 or 6 wherein the O-DU receives a message from the O-RU which indicates, for a UE, the UE ports that are valid.

8. An O-RU adapted to perform the method of any of the claims 1-4.

9. A computer program adapted to, when run on one or more processors of an O-RU,perform the method of any of the claims 1-4.

10. An O-DU adapted to perform the method of any of the claims 5-7.

11. A computer program adapted to, when run on one or more processors of an O-DU,perform the method of any of the claims 1 -4.

12. An O-RAN Radio Unit, O-RU comprising processing circuitry and a memory configured to send a message to an O-RAN O-DU wherein the message indicates, for a UE, channel estimates that will be used for beamforming.

13. A tangible, non-transient computer-readable medium comprising instructions that, when executed by processing circuitry of an O-RAN Radio Unit, O-RU connected to an O-RAN Distributed Unit, O-DU over fronthaul, cause the processing circuitry to perform operations comprising sending a message to an O-RAN O-DU wherein the message indicates, for a UE, channel estimates that will be used for bcamforming.

14. An O-RAN Distributed Unit, O-DU comprising processing circuitry and a memory configured to receive a message from an O-RAN O-RU wherein the message indicates, for a UE, channel estimates that will be used for bcamforming.25-02-2026!nkom till Patent- och registre rings verket 2 §15. A tangible, non-transicnt computer-readable medium comprising instructions that, when executed by processing circuitry of an 0-RAN Radio Unit, O-RU connected to an O-RAN Distributed Unit, O-DU over fronthaul, cause the processing circuitry to perform operations comprising receiving a message from an O-RAN O-RU wherein the message indicates, for a UE, channel estimates that will be used for beamforming.

16. A method according to any preceding claim wherein a port is deemed invalid if- it will not or should not be used, either by O-RU or O-DU, for reception, transmission, determination of scheduling parameters, channel estimation or determining of beamforming weights,or the port is deemed invalid if- a signal supposedly transmitted, or received by the port, is unlikely to make a useful contribution to channel estimation or signal transmission or reception in addition to using the other ports of the UE- or the port is invalid if low quality of the received signal or channel estimate of the received signal, such as low received signal power or SNR or SINR indicate that SRS may not have been sent- or the port is invalid if it is highly correlated with another port- or the port is invalid because of low quality of the received signal or channel estimate from the received signal.

17. A system comprising an O-RU according to claim 8 or 12 connected over fronthaul to anO-DU according to claim 10 or 14.

Images