Channel estimate prioritization
Patent Information
- Application Number
- PCT/SE2026/050110
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-24
- Filing Date
- 2026-02-23
- Publication Date
- 2026-08-27
Smart Images
Figure SE2026050110_27082026_PF_FP_ABST
Abstract
Description
[0001] 23-02-2026
[0002] CHANNEL ESTIMATE PRIORITIZATION
[0003] TECHNICAL FELD
[0004] The application relates to the field of processing of Sounding Reference Signals.
[0005] BACKGROUND
[0006] 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
[0007] example, 64 antennas serving 8 or 16 user-layers in frequency range 1 (FR1), which comprises sub-6 GHz frequency bands, and 256 / 512 antennas serving 2 or 4 layers in FR2, which comprises frequency bands from 24.25 GHz to 52.6 GHz. A user layer when used herein e.g., means an independent downlink or uplink data stream intended for one user.
[0008] 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, 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
[0009] channels resolved by massive MIMO technologies nulling the interferences between users, while keeping high performance, e.g., throughput, for each user. Therefore, it can significantly increase the spectrum efficiency and cell capacity.
[0010] i
[0011] till Patent- och23-02-2026
[0012] 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 legacy CPRl-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 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 cREC (eCPRI Radio Equipment Control) and eRE (eCPRI Radio 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 RU is referred to as O-RU (O-RAN RU).
[0013] 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 Sounding reference signal, SRS sent back from the O-RU.23-02-2026
[0014] 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 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 (BFWs) together with its beam ID to be used if not stored. Then, the O-DU sends the DL 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..
[0015] There is another type of beamforming methods defined in the current O-RAN WG4 specification, referred as Channel Information based Beamforming (CIBF). In CIBF, instead of transferring BFWs or beamld, the O-DU transfers to the O-RU the scheduled layers and the SRS channel estimates of the scheduled layers in the C-plane messages. The O-RU uses the received information (i.e., the scheduled REs, the scheduled layers and their channel estimates 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 C-plane message. Although the field name is “ueld”, the ueld represents a layer, not a UE. For a UE with multiple layers scheduled, it needs multiple ueld(s) where each ueld represents one layer of the UE.
[0016] 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.23-02-2026
[0017] In O-RAN open fronthaul, a C- or U-plane message contains an eCPRI transport header, in which the “ccpriRtcid / 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 (ST1) is 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. 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 (SE1) 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.
[0018] There currently exist certain challenge(s). One problem of WDBF and CIBF in the current O-RAN open fronthaul specification is that a 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 bcamformed 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 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. 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.23-02-2026
[0019] 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 are 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 which utilize SRS for scheduling and beamforming etc. 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.
[0020] 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.
[0021] Figure 4 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, SINR, signal power) and sends these measurements back to the O-DU. Further, O-RU sends SRS channel estimates back to the O-DU. The SRS channel estimates may be compressed to 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 calculation are also moved to the O-RU, there is no beamforming weights transported over the fronthaul interface, which reduces the fronthaul bit rate in the direction from O-DU to O-RU.
[0022] Figure 5 shows another variant of SRS-BF implementation for DL. In this variant, SRS channel estimation is moved to the O-RU while DL beamforming weights calculation is kept in the O-DU. In this variant, the O-DU can reuse most of functionalities in WDBF, which makes easier to migrate to SRS-BF. The main benefit is to offload the O-DU processing from SRS channel estimation.23-02-2026
[0023] In SRS-BF, the key is to perform SRS channel estimation in the O-RU. To enable this, the O-DU needs to provide 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.
[0024] A challenge present in SRS beamforming as well as in virtually all forms of channel estimation is to achieve high transmission performance by way of accurate channel estimates.
[0025] SUMMARY
[0026] This disclosure addresses challenges in SRS (Sounding Reference Signal) processing within O-RAN (Open Radio Access Network) architectures, specifically in systems where SRS channel estimation is performed in the O-RU (O-RAN Radio Unit) rather than the O-DU (O-RAN Distributed Unit).
[0027] In conventional O-RAN systems, SRS processing can create bottlenecks when multiple UEs (User Equipment) transmit SRS across different symbols, particularly when UEs use features like antenna switching, frequency hopping, or repetition patterns. This results in SRS channel estimates for a single UE being spread across multiple processing intervals, leading to delays that can degrade beamforming performance due to outdated channel information.
[0028] The disclosed method provides a prioritization mechanism where the O-DU sends priority indications to the O-RU for different SRS channel estimates, to enable prioritization in the O-RU. These priority indications are embedded within C-Plane messages that describe the physical resource blocks (PRBs) on which SRS is to be received. The O-RU is then enabled to process the SRS channel estimates according to the specified priorities, and may ensure that higher-priority estimates are completed and / or transmitted back to the O-DU first.23-02-2026
[0029] Priority may be assigned at various granularities including per UE, per SRS block, per PRB cluster, per comb, or per OFDM symbol. The prioritization criteria may be based on factors such as the amount of data in a UE's transmit buffer, UE mobility, latency requirements, reliability requirements, or subscription type. UEs with higher mobility, stricter latency or reliability requirements, or premium subscriptions receive higher priority processing. The approach is particularly advantageous for UEs that utilize SRS features spanning multiple symbols, such as antenna switching (where a UE transmits from different antenna ports across different symbols), intra-slot frequency hopping, or SRS repetition. By prioritizing the processing of all SRS ports for specific UEs, the system is enabled to obtain complete channel information more quickly, enabling more timely and accurate beamforming decisions.
[0030] This approach can reduce processing delays, improve channel estimate freshness, enable better scheduling decisions, and enhance overall system performance by enabling that critical UEs receive prioritized treatment in the SRS processing pipeline. The method is applicable to both downlink and uplink implementations and can be used regardless of whether beamforming weight calculation is performed in the O-RU or O-DU.
[0031] In a first aspect, then, it is provided a method performed in an O-RAN Radio Unit (O-RU). The O-RU receives from an O-RAN Distributed Unit (O-DU) an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each User Equipment (UE). The O-RU then performs the channel estimates and sends them to the O-DU. The priority indications are received in a message that describes the physical resource blocks (PRBs) on which Sounding Reference Signal (SRS) will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS. The channel estimates may be sent to the O-DU in order of priority. The channel estimates may also be made in order of priority.
[0032] In a second aspect, it is provided an O-RAN Radio Unit (O-RU) that is adapted to perform the method of the first aspect.23-02-2026
[0033] In a third aspect, it is provided a computer program that includes program code which, when run on a processor of an O-RAN Radio Unit (O-RU), causes the O-RU to perform the method of the first aspect.
[0034] In a fourth aspect, it is provided an O-RAN Radio Unit (O-RU) that includes processing circuitry and a memory. These are configured to receive from an O-RAN Distributed Unit (O-DU) an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each UE, perform the channel estimates, and send the channel estimates to the O-DU. The priority indications are received in a message that describes the physical resource blocks (PRBs) on which SRS will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS.
[0035] In a fifth aspect, it is provided a tangible, non-transient computer-readable medium that includes instructions. When these instructions are executed by processing circuitry of an O-RAN Radio Unit (O-RU) connected to an O-RAN Distributed Unit (O-DU) over fronthaul, they cause the processing circuitry to perform operations including receiving from the O-DU an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each UE, performing the channel estimates, and sending the channel estimates to the O-DU. The priority indications are received in a message that describes the physical resource blocks (PRBs) on which SRS will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS.23-02-2026
[0036] In a sixth aspect, it is provided a method performed in an O-RAN Distributed Unit (O-DU). The method involves prioritizing the determining of SRS (Sounding Reference Signal) based channel estimates in an O-RAN Radio Unit (O-RU), sending to the O-RU an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each UE, and receiving the channel estimates from the O-RU. The priority indications are sent in a message that describes the physical resource blocks (PRBs) on which SRS will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS. Channel estimation for a UE may be prioritized based on one or more of: amount of data in UE transmit buffer, UE mobility, UE latency requirements, UE reliability requirements, and UE subscription type. A UE having higher mobility, latency requirements, reliability requirements or having a premium subscription may be assigned a higher priority than a UE having lower mobility, latency requirements, reliability requirements or not having a premium subscription. The channel estimates may be received in order of priority.
[0037] In a seventh aspect, it is provided an O-RAN Distributed Unit (O-DU) that is adapted to perform the method of the sixth aspect.
[0038] In an eighth aspect, it is provided a computer program that includes program code which, when run on a processor of an O-RAN Distributed Unit (O-DU), causes the O-DU to perform the method of the sixth aspect.
[0039] In a ninth aspect, it is provided an O-RAN Distributed Unit (O-DU) that includes processing circuitry and a memory. These are configured to prioritize the determining of SRS (Sounding Reference Signal) based channel estimates in an O-RAN Radio Unit (O-RU), send to the O-RU an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each UE, and receive the channel estimates from the O-RU. The priority indications are sent in a message that describes the physical resource blocks (PRBs) on which SRS will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS.23-02-2026
[0040] In a tenth aspect, it is provided a tangible, non-transient computer-readable medium that includes instructions. When these instructions are executed by processing circuitry of an O-RAN Radio Unit (O-RU) connected to an O-RAN Distributed Unit (O-DU) over fronthaul, they cause the processing circuitry to perform operations including prioritizing the determining of SRS (Sounding Reference Signal) based channel estimates in the O-RU, sending to the O-RU an indication of priority for each of multiple channel estimates that need to be made, where priority is indicated for each UE, and receiving the channel estimates from the O-RU. The priority indications are sent in a message that describes the physical resource blocks (PRBs) on which SRS will be received by the O-RU from one or more UEs and on which SRS channel estimates are to be made on the received SRS.
[0041] In an eleventh aspect, it is provided a system that includes an O-RAN Distributed Unit (O-DU) according to the seventh or ninth aspect connected over fronthaul to an O-RAN Radio Unit (O-RU) according to the second or fourth aspect.
[0042] BRIEF DESCRIPTION OF THE DRAWINGS
[0043] Figure 1 shows an illustration of a fronthaul interface between RU and DU.
[0044] Figure 2 shows a DL WDBF implementation supported by current O-RAN open fronthaul specification.
[0045] Figure 3 shows C-plane and U-plane data flows for DL in current O-RAN open fronthaul specification.
[0046] Figure 4 shows a first variant of SRS-BF functional split for DL.
[0047] Figure 5 shows a second variant of SRS-BF functional split for DL.
[0048] Figure 6 shows an example of SRS priority set on symbol level for 2 UEs.
[0049] Figure 7 shows an example of SRS priority set on cluster level for 3 UEs.
[0050] Figure 8 shows an example of SRS priority set on SRS UE levels for 4 UEs.
[0051] Figure 9 shows an example of SRS priority set on comb level for 4 UEs.23-02-2026
[0052] Figure 10 shows an example of a communications system.
[0053] Figure 11 shows another example of a communications system.
[0054] Figure 12 shows a block diagram of a wireless device.
[0055] Figure 13 shows a block diagram of a network node.
[0056] Figure 14 shows a block diagram illustrating a virtualization environment.
[0057] Figure 15 shows an example of an SRS configuration for 4 UEs.
[0058] Figure 16 shows a second example of an SRS configuration.
[0059] Figure 17 shows a third example of an SRS configuration.
[0060] Figure 18 shows an SRS prioritization signalling flow.
[0061] DETAILED DESCRIPTION
[0062] In 3GPP, SRS can be sent in some symbols in the special slot which contains both DL and UL transmissions or an UL slot which only contains UL transmissions. SRS can be 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 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 SRS port corresponds to the SRS sent by one UE antenna port. The SRS ports of one or 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., 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. Considering all these above, SRS resource multiplexing can be very complicated, much more complicated than DMRS resources which only have a few ports and a few configurations.23-02-2026
[0063] The C-Plane SRS configuration description structure needs to be carefully designed to optimize for flexibility (supporting all possible resource multiplexing), O-RU processing efficiency (for O-RU to easily get the necessary information for generating SRS sequences) and FH efficiency (reduce the number of bytes used for SRS configuration description). Depending on SRS UE capabilities and based on channel quality measurements for those UEs, the UE SRS transmissions may be scheduled as the following.
[0064] SRS UEs are scheduled with intra-slot frequency hopping with a certain PRB range spread across multiple symbols within a slot or adjacent slot. In this scenario, SRS of a UE in each symbol is transmitted in a narrower bandwidth and therefore the UE can send more power for SRS which increases SINR of the received SRS at the O-RU. The SRS transmission in each symbol can carry SRS for one or more SRS ports.
[0065] SRS UEs with multiple SRS ports are scheduled over multiple symbols within a slot or adjacent slot when antenna-switching is enabled. Many UEs have fewer transmitter chain than receiver chain because transmitter chain consumes more power and also more costly. However, such UEs share the same antennas to transmit and receive. The UEs can switch its antennas to transmit at different time. Such antenna-switching functionality is useful for channel sounding using SRS. For example, a 2T4R UE has two transmitter chain and 4 receiver chains, which can support 2 layers PUSCH transmission and 4 layers PDSCH transmission. The UE can send the SRS from the first two antennas (SRS ports) in the first symbol. Then the UE can send the SRS from the second two antennas (SRS ports) in another symbol. Tn this case, the base station (SRS-BF O-RU) will be able to estimate the channel of all UE antennas (SRS ports) and use the channel estimates for downlink transmission utilizing all 4 UE receive antennas. NOTE that antenna switching usually can’t perform such switch in two adjacent symbols. Normally, there is a gap (empty) symbol in between.
[0066] SRS UEs are scheduled to repeat the SRS transmission over several consecutive symbols within a slot or adjacent slot. This is referred to as SRS repetition, which can help improve SRS coverage and SRS channel estimation quality.
[0067] Normally, SRS receiver processing happens on SRS block where several SRS ports are scheduled with different cyclic shifts in that PRB range of that symbol in a certain OTA (over the air) slot.23-02-2026
[0068] In TDD (time-division duplexing), SRS transmissions are usually scheduled in the special slot between DL slots and UL slots. The next slot to the special slot (SRS transmission) is a UL slot for PUSCH transmissions. For O-RU processing, the O-RU will process PUSCH first if there is PUSCH transmission in the UL slots next to the SRS slot since PUSCH processing has higher priority than SRS processing.
[0069] So, SRS receiver processing should have a pattern like START (i.e., start processing certain SRS block(s), e.g., in one symbol), SUSPEND (i.e. pause SRS processing and PUSCH processing takes precedence than SRS) and RESUME ((i.e. after PUSCH processing, continue to process other unfinished SRS block(s)) and so on. The SRS processing is typically done in symbol order. This could take completion of SRS channel estimates for all SRS ports of a UE over a long time, e.g., the entire TDD cycle duration (multiple slots), for the cases where SRS ports are schedule over multiple SRS symbols.
[0070] For the case, where SRS UEs schedule with intra-slot hopping for example 4 symbols, SRS channel estimates for those SRS UEs are obtained only when SRS channel estimate processing is completed for all scheduled SRS symbols.
[0071] Similarly, SRS UEs schedule with antenna switching with example 2 symbols and a gap in between those two symbols, SRS channel estimates for the second symbol is obtained only after SRS channel estimate processing is completed after the preceding symbols.
[0072] Likewise, SRS UEs schedule with repetition pattern over multiple SRS symbols, SRS channel estimates for the second symbol onwards are available only after PUSCH channel processing is completed.23-02-2026
[0073] For the above cases, availability of SRS channel estimates and / or SRS channel state information (i.e. rank, layer...etc.) may take a long time over multiple slots. The channel information (SRS channel estimates and / or SRS channel state information) is sent back from O-RU to O-DU when they are ready. For example, for one UE, sending the channel estimates of the later symbol may be multiple slots late than sending the channel estimates of the earlier symbol. So, it may also take a long time over multiple slots for O-DU to obtain the complete information. If O-DU wants to get the complete information for a UE to determine the scheduling parameters (PRB allocation, UEs paired for MU-MIMO, layer, MCS, etc.), the O-DU may need to wait for all channel estimates or channel information (i.e. rank, layer...etc.) of all SRS ports of that corresponding UE for a long time and then determine the scheduling parameters. If the delay is long, it will cause the channel information more outdated for SRS-based beamforming performed by O-RU which may affects the performance negatively, since the O-RU uses more outdated channel estimates to calculate beamforming weights and the O-DU uses more outdated channel estimates for scheduling. If O-DU uses partial channel information contained in the earlier symbol(s) (c.g., with a few ports of a UE) which is received earlier, using incomplete channel information will also affect the performance negatively since incomplete channel information only include some SRS ports and the beamforming will not utilize all SRS ports for beamforming. Also, if one combines the latest partial channel information and previous channel information estimated from SRS received in previous slot(s), the previous channel information is more outdated than the latest partial channel information. Therefore, the overall channel information is still outdated.
[0074] An outdated channel estimate is typically much less accurate.
[0075] Further, as O-DU do not have complete channel estimates or channel information (i.e. rank, layer...etc.) for all SRS ports corresponds to that UE in same SRS transmission interval, it may result in underestimating SRS UE rank / layers and not accurately doing MU_MIMO UE pairing in the next immediate available downlink slot and could cause performance / throughput degradation.23-02-2026
[0076] In this disclosure, we propose that O-DU sends to the O-RU the indication about SRS processing priority for certain part of the SRS data, e.g., a set of SRS symbols, a set of SRS blocks or certain SRS UE(s). Different processing priority can be indicated to different part of the SRS data, e.g., different set of SRS symbols, different set of SRS blocks, or different UEs. After receiving the priority, the O-RU will process different part of SRS according to the priorities. The O-RU will prioritize processing the part of the SRS data with higher priority indicated and send the channel information or indication of available channel information earlier to the O-DU. In this way, O-DU can receive the complete channel information or indication of complete channel information earlier for the prioritized part of SRS data. Therefore, performance can be improved for the UEs which arc in the prioritized part of SRS data. Note that an SRS block represents the SRS data of the PRB range of a single SRS PRB cluster (PRB range) in a single symbol. In an SRS block, the SRS sequences of one or more SRS ports of one or more UEs are multiplexed. A PRB cluster is defined as a unique continuous PRB range used at least by one UE in any SRS symbol in the slot.
[0077] The part of SRS data containing SRS with antenna-switching, SRS with intra-slot frequency hopping and / or SRS with SRS repetition may be indicated with higher priority. In these cases, the part of SRS data spans over multiple symbols. If the SRS data for the same UE or same ports are sent in adjacent slots containing SRS (e.g., special slot and next UL slot), priority can also be used. For example, 1T4R UE may send SRS from different ports over 2 or 4 slots containing SRS.
[0078] The UEs with higher scheduling priority, e.g., the UEs having large amount of data in buffer, the UEs requiring lower latency, the UEs requiring higher reliability, and the UEs with premium subscription etc., may be indicated with higher priority.
[0079] The processing priority indication is sent over C-Plane message that conveys SRS configuration. It can be sent as parameter(s) in a section of a Section Type used for SRS configuration or in a section extension attached to the section of the Section Type used for SRS configuration. A priority indication can apply for certain part of the SRS data, e.g., a set of SRS symbols, a set of SRS blocks, or certain SRS UE.23-02-2026
[0080] Further, in patent applications PCT / SE2024 / 051026, PCT / SE2025 / 050129 and PCT / SE2025 / 050137, previously filed, we proposed efficient C-Plane message structures to describe the SRS configuration of all SRS ports in a slot containing SRS in one or more section descriptions in one message, if it is within the payload size limit of the packet. If the message size is higher than the payload size limit, it will split into multiple messages. In this disclosure, the indication is added to the proposed C-Plane message structures to support SRS processing prioritization in O-RAN.
[0081] Basically, we add a new parameter of SRS priority ID either at symbol, PRB cluster, comb, or SRS UE part of the section description. Based on SRS priority ID defined for each corresponding option, prioritize processing of all SRS ports mapped to higher priority first, then proceed to next set of SRS ports with lower priority in priority list and so on. The following describes different options to add the priority ID for different part of the section description.
[0082] Symbol level --- Assign identical or distinct SRS priority IDs starting from 1 (i.e. the highest priority) to N (i.e. the lowest priority) for each of the schedule SRS symbols in the same or adjacent slot.
[0083] PRB cluster level --- Assign identical or distinct SRS priority IDs starting from 1 (i.e. the highest priority) to N (i.e. the lowest priority) for each of the schedule PRB cluster in the same or adjacent slot. Note that the cluster level indication can be included in the common head where the clusters are defined.
[0084] Comb level --- Assign identical or distinct SRS priority IDs starting from 1 (i.e. the highest priority) to N (i.e. the lowest priority) for each of the schedule comb in the same or adjacent slot.
[0085] SRS UE level --- Assign identical or distinct SRS priority IDs starting from 1 (i.e. the highest priority) to N (i.e. the lowest priority) for each of the schedule SRS UE in the same or adjacent slot.23-02-2026
[0086] The proposed method in this disclosure is applicable to SRS-BF in which SRS channel estimation and beamforming weights calculation are in the O-RU. It can be also used for the case when SRS channel estimation is in the O-RU and the beamforming weights calculation is in the O-DU. It is applicable to not only DL implementation but also UL implementation
[0087] Part of the proposed method can be also used in the O-DU when SRS channel estimation is done in the O-DU. In channel-information-based beamforming, O-DU performs SRS channel estimation and sends SRS channel estimates to the O-RU. The O-RU calculates the beamforming weights based received SRS channel estimates. In this case, the O-DU can prioritize part of SRS processing to improve performance. Even if both SRS channel estimation and beamforming weights calculation are performed in the O-DU, the O-DU can prioritize part of SRS processing to improve performance.
[0088] Certain embodiments may provide one or more of the following technical advantage(s). As PUSCH suspend SRS processing, prioritizing SRS ports of a specific UE or set of SRS UEs, spread across different symbols with or without a gap in between SRS symbols, result in obtaining SRS channel estimation for all ports of that UE in the same interval earlier. The proposed method reduces the delay for O-RU and O-DU to get SRS channel estimation or SRS channel state information (i.e. rank, layer...etc.) of all schedule ports corresponding to one or more SRS UEs in the same transmission interval, by prioritizing the SRS processing for the UE. The channel information used for beamforming and scheduling decision is more timely and therefore the performance is improved.
[0089] The proposed method facilitates O-DU to prioritize SRS processing for certain UEs with higher scheduling priority, e.g., the UEs having large amount of data in buffer, the UEs requiring lower latency, the UEs requiring higher reliability, and the UEs with premium subscription etc. This would help improve user experience.
[0090] Prioritizing SRS ports of a specific UE or set of SRS UEs, spread across different symbols with or without a gap in between SRS symbols help in efficiently utilize HW resources on certain slots.23-02-2026
[0091] 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. Additional information may also be found in the document(s) provided in the Appendices.
[0092] An SRS block is identified by a PRB cluster and a symbol, in which the SRS sequences of one or more SRS ports of one or more UEs are multiplexed. A PRB cluster is defined as a unique continuous PRB range used at least by one UE in any SRS symbol in the slot. Each PRB cluster may be identified by a cluster ID. And Each symbol may be identified by a symbol ID. An SRS block represents the SRS data of the PRB range of a single SRS PRB cluster (PRB range) in a single symbol. In an SRS block, the SRS sequences of one or more SRS ports of one or more UEs are multiplexed. The following show some examples of SRS prioritization use cases.
[0093] Example of SRS priority set on symbol level
[0094] Figure 6 shows an example of SRS configuration for 2 UEs. In this example, each UE has two antenna ports (or SRS ports). Four SRS symbols are used, i.e., symbol 10 ,11, 12 and 13 in the slot. In frequency domain multiplexing, Comb 4 is used. Each UE uses full bandwidth with antenna switching enabled for those corresponding SRS ports. It also shows one PRB cluster used. UE 0 is scheduled with one SRS port in symbol 10 and the other SRS port in symbol 12 and UE1 is scheduled with one SRS port in symbol 11 and the other SRS port in symbol 13 where both UEs use same PRB cluster 0 definition.
[0095] Two antenna ports of a UE use two Cyclic Shifts of CS 0 in first symbol and CS 6 in second symbol. In Figure 6, it shows in total 4 SRS blocks in this example.
[0096] In scenario 1, symbol 10 and symbol 12 are assigned with same priority and similarly symbol 11 and symbol 13 are assigned with same priority. Since priority is same for symbol 10 and symbol 12, port 0 and port 1 of UE 0 get same priority and same principle is applied for UE 1. Among multiple symbols, first set of symbols i.e. symbol 10 and symbol 12 have higher priority than another set of symbols i.e. symbol 11 and symbol 13.23-02-2026
[0097] In this case SRS receiver in the O-RU prioritizes processing of all SRS ports in symbol 10 and symbol 12 first followed by processing of all SRS ports in symbol 11 and symbol 13 in next available opportunity.
[0098] In this example, both ports of UE 0 i.e. port 0 and port 1 are processed in first interval and channel estimates and / or channel information (i.e. rank, layer...etc.) are sent to O-DU in first transmission interval.
[0099] O-DU obtains SRS channel estimation and / or channel information (i.e. rank, layer...etc.) of all the schedule ports corresponding to that SRS UE in the same transmission interval. In this case, both O-RU and O-DU get UE 0 channel estimation and / or channel information (i.e. rank, layer...etc.) early when compared to UE1.
[0100] In scenario 2, symbol 10, symbol 11, symbol 12 and symbol 13 are assigned with same priority if not many other SRS ports are schedule across these four SRS symbols and if SRS receiver could process all those SRS ports in the same interval, e.g., not much PUSCH data scheduled in the next UL slot. This allows to efficiently utilize HW resources.
[0101] In this case, SRS receiver in the O-RU prioritizes processing of all SRS ports in symbol 10, symbol 11, symbol 12 and symbol 13 as there are fewer number of SRS ports scheduled. In this scenario, both ports of UE 0 & UE 1 i.e. port 0 and port 1 are processed in first transmission interval and channel estimates or channel information (i.e. rank, layer...etc.) are sent to higher layers in first transmission interval.
[0102] O-DU obtains SRS channel estimation and / or channel information (i.e. rank, layer...etc. rank / layer information of all the schedule ports corresponding to that SRS UE in the same transmission interval.
[0103] From scenario 1 & scenario 2, due to availability of SRS channel estimates or channel information (i.e. rank, layer...etc.) for all SRS ports of that corresponding SRS UEs in each of the SRS transmission interval, aids in quickly calculating layers for those UEs and SRS channel information (i.e. rank, layer...etc.) or SRS channel estimates are applied in the next immediate available downlink slot.
[0104] Example of SRS priority set on PRB cluster level
[0105] I923-02-2026
[0106] Figure 7 shows an example of SRS configuration for 3 UEs. In this example, each UE has two antenna ports (or SRS ports). Four SRS symbols are used, i.e., symbol 10 ,11, 12 and 13 in the slot. In frequency domain multiplexing, Comb 4 is used. UE 0 uses quarter bandwidth with intra-slot frequency hopping, UE 1 uses half bandwidth and UE 2 uses half bandwidth with intra-slot frequency hopping. It also shows the PRB clusters used. UE 0 is scheduled with two ports with four PRB clusters of cluster 2, 1, 4 and 3 in symbol 10, 1 1, and 12 and symbol 13, respectively. UE 1 is scheduled with two ports with single PRB cluster 0 in symbol 10. UE 2 is scheduled with two ports with two PRB clusters of cluster 0 and 5 in symbol 12 and symbol 13, respectively.
[0107] For the overlapping PRB range (i.e. PRB cluster 0 overlaps with PRB cluster 3 and 4), two antenna ports of one UE use two Cyclic Shifts: CS 0 and CS 6 and two antenna ports of second UE use two Cyclic Shifts: CS 3 and CS 9. In Figure 7, it shows in total 7 SRS blocks in this example.
[0108] For example, PRB cluster 2, 1, 4 and 3 in symbol 10, 11, 12 and symbol 13, respectively, are assigned with the same and highest priority, while PRB cluster 0 in symbol 10 and PRB cluster 0 and 5 in symbol 12 and symbol 13, respectively, are assigned with same and a lower priority in the list.
[0109] Since PRB cluster 2, 1, 4 and 3 in symbol 10, 11, 12 and symbol 13, respectively, having highest priority, UE 0 is prioritized in SRS processing when compare with UE 1 and UE 2. As priority level is same for PRB cluster 0 in symbol 10 and PRB cluster 0 and 5 in symbol 12, and symbol 13, respectively, both UE 1 and UE 2 are processed in same interval but later than UE 0.
[0110] In this case SRS receiver in the O-RU prioritizes processing of all SRS ports corresponds to PRB clusters 2, 1, 4 and 3 in symbol 10, 11, 12 and symbol 13, respectively, first followed by processing of all SRS ports corresponds to PRB cluster 0 in symbol 10 and PRB clusters 0 and 5 in symbol 12 and symbol 13, respectively, in next available opportunity.
[0111] In this example, UE 0 is processed in first interval and channel estimates and / or channel information (i.e. rank, layer...etc.) are sent to O-DU in first transmission interval.
[0112] O-DU obtains SRS channel estimation and / or channel information (i.e. rank, layer...etc.) of all the schedule ports corresponding to that SRS UE in the same transmission interval.23-02-2026
[0113] In this case, both O-RU and 0-DU gets UE 0 channel estimates or channel information (i.e. rank, layer...etc.) early when compared to UE1 and UE2.
[0114] Due to availability of SRS channel estimates or channel information (i.e. rank, layer...etc.) for all SRS ports of that corresponding SRS UEs in each of the SRS transmission interval, aids in quickly calculating layers for those UEs and SRS channel information (i.e. rank, layer...etc.) or SRS channel estimates are applied in the next immediate available downlink slot.
[0115] Example of SRS priority set on SRS UE level
[0116] Figure 8 shows an example of SRS configuration for 4 UEs. In this example, each UE has two antenna ports (SRS ports). Four SRS symbols are used, i.e., symbol 10 ,11, 12 and 13 in the slot. In frequency domain multiplexing, Comb 4 is used. Each UE uses full bandwidth with antenna switching enabled for those corresponding SRS ports. It also shows one PRB cluster used. UE 0 and UE 1 are scheduled with one port in symbol 10 and the other port in symbol 12 and UE 2 and UE 3 are scheduled with one port in symbol 11 and the other port in symbol 13 where all UEs use same PRB cluster 0 in frequency domain. Two UEs in the same symbol are schedule with either cyclic shift of CS 0 or CS 6. In Figure 8, it shows in total 4 SRS blocks in this example
[0117] For example, SRS UE0 port 0 in symbol 10, SRS UE0 port 1 in symbol 12, SRS UE3 port 0 in symbol 11, SRS UE3 port 1 in symbol 13 are assigned with same and highest priority and SRS UE1 port 0 in symbol 10, SRS UE1 port 1 in symbol 12, SRS UE2 port 0 in symbol 11, SRS UE2 port 1 in symbol 13 are assigned with same and next priority in the list23-02-2026
[0118] Since UEO and UE 3 and its corresponding two ports having highest priority, UE 0 two ports and UE 3 two ports are prioritized in SRS processing first when compare with UE 1 two ports and UE2 two ports. As priority level is same for UE1 and UE 2 and its corresponding two ports both UE 1 and UE 2 are processed in the same transmission interval of next available opportunity. In this case SRS receiver in the O-RU prioritizes processing of all SRS ports corresponds to UEO and UE 3 first followed by processing of all SRS ports corresponds to UE1 and UE 2 in next available opportunity.
[0119] In this example, UE 0 and UE 3 are processed in first interval and channel estimates or channel information (i.e. rank, layer...etc.) are sent to O-DU in first transmission interval. O-DU obtained SRS channel estimation or channel information (i.e. rank, layer...etc.) form all the schedule ports corresponding to that SRS UE in the same transmission interval. In this case, both O-RU and O-DU get UE 0 and UE 3 channel estimates or channel information (i.e. rank, layer...etc.) early when compared to UE1 and UE2.
[0120] Due to availability of SRS channel estimates or channel information (i.e. rank, layer...etc.) for all SRS ports of that corresponding SRS UEs in each of the SRS transmission interval, aids in quickly calculating layers for those UEs and SRS channel information (i.e. rank, layer...etc.) or SRS channel estimates are applied in the next immediate available downlink slot.
[0121] Example of SRS priority set on comb level
[0122] Figure 9 shows an example of SRS configuration for 4 UEs. In this example, each UE has two antenna ports (or SRS ports). Four SRS symbols are used, i.e., symbol 10 and 12 in the slot and no SRS data in symbol 11. In frequency domain multiplexing, Comb 4 is used. Each UE uses full bandwidth with antenna switching enabled for those corresponding SRS ports. It also shows one PRB cluster used. UE 0 and UE 3 are scheduled with one port in symbol 10 and the other port in symbol 12 with comb offset 0, respectively, while UE 1 and UE 2 are scheduled with one port in symbol 10 and the other port in symbol 12 with comb offset 1, respectively. And all UEs use same PRB cluster 0 in frequency domain. Two UEs in the same symbol and same comb offset are scheduled with either cyclic shift of CS 0 or CS 6. In Figure 9, it shows in total 2 SRS blocks in this example.23-02-2026
[0123] For example, comb 0 of symbol 10 and comb 0 of symbol 12 are assigned with same and highest priority and comb 1 of symbol 10 and comb 1 of symbol 12 are assigned with same and lower priority in the list.
[0124] Since comb 0 in symbol 10 and 12 having highest priority, UE 0 and UE 3 are prioritized in processing first when compare with UE 1 and UE2. As priority level is same for comb 1 in symbol 10 and 12 both UE 1 and UE 2 are processed in the same transmission interval. In this case SRS receiver in the O-RU prioritizes processing of all SRS ports corresponds to comb 0 in symbol 10 and 12 first followed by processing of all SRS ports corresponds to comb 1 in symbol 10 and 12 in next available opportunity.
[0125] In this example, UE 0 and UE3 and its corresponding two ports are processed in first interval and channel estimates and / or channel information (i.e. rank, layer...etc.) are sent to O-DU in first transmission interval.
[0126] O-DU obtains SRS channel estimation and / or channel information (i.e. rank, layer...etc.) form all the schedule ports corresponding to that SRS UE in the same transmission interval. In this case, both O-RU and O-DU gets UE 0 and UE 3 channel estimates and / or channel information (i.e. rank, layer...etc.) early when compared to UE1 and UE2.
[0127] Due to availability of SRS channel estimates or channel information (i.e. rank, layer...etc.) for all SRS ports of that corresponding SRS UEs in each of the SRS transmission interval, aids in quickly calculating layers for those UEs and SRS channel information (i.e. rank, layer...etc.) or SRS channel estimates are applied in the next immediate available downlink slot.
[0128] Examples of adding priority indication in C-Plane section description
[0129] In this disclosure, we exemplify adding priority indication based on Section Type WW proposed in Pl 13054. But the indication can be added in the section description of any other design of Section Type for conveying SRS configuration. The indication can be also added in a section extension for the Section Type for conveying SRS configuration.23-02-2026
[0130] In the following examples, we use priority ID as priority indication. But it doesn’t exclude using any other parameter as the priority indiction.
[0131] For convenience, section description format of Section Type WW is shown in Table 1-4. Table 1 shows the overall data structure of Section Type WW. Table 2 shows the section description format for a section. Table 3 shows the format for the UE description part of the section description of a section. Table 4 shows the format for the UE port description part of the section description of a section.23-02-2026
[0132] Table 1 SRS configuration description format (Section Type WW)
[0133] Section Type WW: SRS configuration
[0134] # of 0 (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes transport header, see clause 5.1.3 8 Octet 1 dataDirectio payloadVersion filterIndex 1 Octet 9 n
[0135] frameld 1 Octet 10 subframe Id slotld 1 Octet 11 slotld startSymbolld 1 Octet 12 numberOfsections 1 Octet 13 sectionType = ZZ 1 Octet 14 srsChestCompHdr 1 Octet 15 reserved numSrsCfgMsgs startSrsPrb [8:7] 1 Octet 16 startSrsPrb [6:0] numSrsPrb[8] 1 Octet 17 numSrsPrb [7:0] 1 Octet 18 reserved numSrsSymbols 1 Octet 19 numSrsClusters 1 Octet 20 srsClusterld of first PRB cluster startPrbOfCluster [8:7] 1 Octet 21 startPrbOfCluster of first PRB cluster [6:0] 1 Octet 22 numPrbOfCluster of first PRB cluster [7:0] 1 Octet 23 var Octet 24 srsClusterld of last PRB cluster startPrbOfCluster [8:7] 1 var startPrbOfCluster of last PRB cluster [6:0] 1 var numPrbOfCluster of last PRB cluster [7:0] 1 var section for first SRS block in first symbol var var var var section for last SRS block in first symbol var var var var section for first SRS block in last symbol var var var var section for last SRS block in last symbol var var NOTE: Octet 1-8 are transport header, Octet 9-14 is radio application header, Octet 15 to the octet before the first section description (“section for first SRS block in first symbol" in this case) is common header of Section Type, the rest are the section descriptions of multiple sections
[0136]
[0137] 23-02-2026
[0138] Table 2 Section description format (SRS block level SRS configuration description) SRS configuration of section for nth SRS block
[0139] # of
[0140] 0 (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes ef reserved symbol Id l 1 srsClusterld 1 2 numUesOfSrsBlock 1 3 reserved srsGroupSeqHopping 1 4 reserved srsCombNum 1 5 SRS configuration of UE var var var var SRS configuration of last UE var var Section Extensions as indicated by "ef1var var
[0141]
[0142] Table 3 UE level SRS configuration description format
[0143] SRS configuration of Ith UE in a cluster in an SRS symbol
[0144] # of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserved numSrsPortsOfUe 1 1 reserved 1 2 srsUeldR
[0145] eset srsUeld [14:8] 1 3 srsUeld [7:01 1 4 srsSeqld [15:81 1 5 srsSeqld [7:01 1 6 SRS configuration of first SRS port 3 7 var var
[0146]
[0147] SRS configuration of last SRS port 3 var
[0148] Table 4 SRS port level SRS configuration description format
[0149] SRS configuration of kth SRS port of a UE in a cluster in an SRS symbol
[0150] # of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s srsCyclicShift srsUePortld 1 1 reserved srsCombOffset 1 2
[0151]
[0152] reserved 1 3
[0153] Example 1: adding priority indication on SRS block level in each section of Section Type WW.23-02-2026
[0154] In this example, a field of priorityld is added in the section description format of a section, “priorityld” represents prirority ID used to indicate the SRS processing priority of the SRS block described by the section. As shown in Table 5, the field of priorityld is added in Octet 4. Compared to Table 2, priorityld in Table 5 takes the place of the reserved field in Octet 4 in Table 2.
[0155] This priorityld value applies for all UEs in the SRS block described by the section. The SRS blocks with the highest priority value among all SRS blocks in the same slot are instructed by the 0-DU to the O-RU that the O-RU prioritizes the processing of these SRS blocks than other SRS blocks (e.g., processing these SRS blocks first) and also prioritizes sending any processing result of these SRS blocks (e.g., channel estimates, RRM measurements) back to the O-DU (e.g., sending the processing results first, earlier than sending the processing results of other SRS blocks). Basically, processing SRS blocks and sending the processing results will be performed in the order of the priority ID values.
[0156] Table 5 Section description format (SRS block level SRS configuration description) SRS configuration of section for nth SRS block
[0157] # of (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes ef reserved symbolld 1 1 srsClusterld 1 2 numllesOfSrsBlock 1 3 priorityld srsGroupSeqHopping 1 4 reserved srsCombNum 1 5
[0158] SRS configuration of UE var var var var SRS configuration of last UE var var Section Extensions as indicated by "ef var var
[0159]
[0160] Example 2: adding priority indication on UE level in each UE description part of each section of Section Type WW.23-02-2026
[0161] In this example, a field of priorityld is added in the UE description part of section description format of a section, “priorityld” represents prirority ID used to indicate the SRS processing priority of the UE described by the UE part of the section. As shown in Table 6, the field of priorityld is added in Octet 1. Compared to Table 3, priorityld in Table 6 takes the place of the reserved field in Octet 1 in Table 3.
[0162] This priorityld value applies for the UE described by the UE description part of the section. The UEs with the highest priority value among UEs in the same slot are instructed by the O-DU to the O-RU that the O-RU prioritizes the processing of SRS of these UEs than other UEs (e.g., processing SRS of these UEs first) and also prioritizes sending any processing result of these UEs (e.g., channel estimates, RRM measurements) back to the O-DU (e.g., sending the processing results first, earlier than sending the processing results of other UEs). Basically, processing UEs and sending the processing results will be performed in the order of the priority ID values.
[0163] Table 6 UE level SRS configuration description format
[0164] SRS configuration of Ith UE in a cluster in an SRS symbol
[0165] #of O(msb) 1 2 3 4 5 6 7(lsb) byte Octet s priorityld numSrsPortsOfUe 1 1 reserved 1 2 srsUeldR
[0166] eset srsUeld [14:8] 1 3 srsUeld [7.01 1 4 srsSeqld [15:8] 1 5 srsSeqld [7:0] 1 6 SRS configuration of first SRS port 3 7 var var
[0167]
[0168] SRS configuration of last SRS port 3 var23-02-2026
[0169] Figure 1010 shows an example of a communication system 101000 in accordance with some embodiments.
[0170] In the example, the communication system 101000 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 3rd Generation 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.
[0171] Moreover, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the 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.
[0172] 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, Xn23-02-2026
[0173] 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 0-2 interface defined by the 0-RAN Alliance or comparable technologies. The 0-DU can be implemented as virtualized O-DU in a Cloud environment.
[0174] 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 with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.23-02-2026
[0175] 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 1012, 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.23-02-2026
[0176] 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 arc 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 Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).
[0177] 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.23-02-2026
[0178] 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 are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (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. 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, 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.
[0179] 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 (cMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs.23-02-2026
[0180] 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).
[0181] 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.
[0182] 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 a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.23-02-2026
[0183] 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 and UEs (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. 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 nondedicated 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.
[0184] 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. 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.23-02-2026
[0185] 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 frequency 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.
[0186] Each AP 1110 may provide data connectivity to STAs 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 STA 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.23-02-2026
[0187] 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), laptop-mounted 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.
[0188] A wireless device 1200 may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V21), 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).23-02-2026
[0189] 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.
[0190] 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).23-02-2026
[0191] 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 wireless device 1200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.
[0192] 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.
[0193] 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.23-02-2026
[0194] 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 circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 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.
[0195] 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 (c.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.23-02-2026
[0196] 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.
[0197] 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 be 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).
[0198] 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.23-02-2026
[0199] 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. Nonlimiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, 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.
[0200] 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 may 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.23-02-2026
[0201] 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.
[0202] 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).
[0203] 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).23-02-2026
[0204] 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).
[0205] 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.
[0206] 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.23-02-2026
[0207] The processing circuitry 1302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other components, such as the memory 1304, to provide network node 1300 functionality.
[0208] 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.
[0209] 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), readonly 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 computerexecutable 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.23-02-2026
[0210] 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 front-end circuitry 1318 may convert the digital data into a radio signal(s) having the appropriate 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.
[0211] 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).23-02-2026
[0212] 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.
[0213] 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.
[0214] 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 input 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.23-02-2026
[0215] 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.
[0216] 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.
[0217] 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.23-02-2026
[0218] 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 be 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 1408 A 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. 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.
[0219] 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, nonvirtualized 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.23-02-2026
[0220] Hardware 1404 may be implemented in a standalone network node with generic or specific components. Hardware 1404 may implement some functions via virtualization.
[0221] 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.
[0222] 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.23-02-2026
[0223] 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 arc enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.
[0224] Numbered embodiments
[0225] 1. A method performed in an O-RAN O-DU comprising the step of prioritizing the determining of SRS, Sounding Reference Signal, -based channel estimates in an O-RAN O-RU.
[0226] 2. A method according to numbered embodiment 1 comprising sending to the O-RU an indication of priority for each of a plurality of channel estimates to be made and receiving the channel estimates from the O-RU.
[0227] 3. A method according to numbered embodiment 2 wherein the channel estimates are received in order of priority.
[0228] 4. A method according to numbered embodiments 2 or 3 wherein the indications of priority are sent in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
[0229] 5. A method according to numbered embodiment 4 wherein priority is indicated per UE.23-02-2026
[0230] 6. A method according to numbered embodiment 4 wherein priority is indicated per SRS block.
[0231] 7. A method according to numbered embodiment 4 wherein priority is indicated per SRS comb.
[0232] 8. A method according to numbered embodiment 4 wherein priority is indicated per PRB cluster.
[0233] 9. A method according to numbered embodiment 4 wherein priority is indicated per OFDM symbol.
[0234] 10. A method according to any of numbered embodiments 4-9 wherein a highest priority is indicated for the symbol(s), cluster(s), comb(s) or SRS block(s) in which there are PRBs allocated to a UE for which the channel estimate is to be prioritized.
[0235] 11. A method according to any preceding numbered embodiment wherein channel estimation for a UE is prioritized based on one or more of:
[0236] - amount of data in UE transmit buffer,
[0237] - UE mobility,
[0238] - UE latency requirements,
[0239] - UE reliability requirements,
[0240] - UE subscription type.
[0241] 12. A method according to numbered embodiment 11 wherein a UE having higher mobility, latency requirements, reliability requirements or having a premium subscription is assigned a higher priority than a UE having lower mobility, latency requirements, reliability requirements or not having a premium subscription.
[0242] 13. A method performed in an O-RAN O-RU comprising the steps of receiving from an O-RAN O-DU an indication of priority for each of a plurality of channel estimates to be made, performing the channel estimates and sending the channel estimates to the O-DU. 14. A method according to numbered embodiment 13 wherein the channel estimates are made in the order of priority.23-02-2026
[0243] 15. A method according to any of numbered embodiments 13 or 14 wherein the channel estimates are sent to the O-DU in the order of priority.
[0244] 16. A method according to any of numbered embodiments 13-15 wherein the indications of priority arc received in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
[0245] 17. A method according to numbered embodiment 16 wherein priority is indicated per UE.
[0246] 18. A method according to numbered embodiment 16 wherein priority is indicated per SRS block.
[0247] 19. A method according to numbered embodiment 16 wherein priority is indicated per SRS comb.
[0248] 20. A method according to numbered embodiment 16 wherein priority is indicated per PRB cluster.
[0249] 21. A method according to numbered embodiment 16 wherein priority is indicated per OFDM symbol.
[0250] 22. An O-RAN O-DU adapted to perform the method of any of the numbered embodiments 1-12.
[0251] 23. A computer program comprising program code which when run on a processor of an O-RAN O-DU causes the O-DU to perform the method of any of the claims 1-12.
[0252] 24. A carrier comprising the computer program of claim 23.
[0253] 25. An O-RAN O-RU adapted to perform the method of any of the numbered embodiments 13-21.
[0254] 26. A computer program comprising program code which when run on a processor of an O-RAN O-RU causes the O-RU to perform the method of any of the claims 13-21.
[0255] 27. A carrier comprising the computer program of claim 26.23-02-2026
[0256] 28. A method performed by an O-RAN O-DU comprising the step of prioritizing instances of channel estimation.
[0257] 29. A method performed by an O-RAN O-RU comprising the step of prioritizing instances of channel estimation.23-02-2026
[0258] APPENDIX 1. Parts of patent application PCT / SE2024 / 051026
[0259] In this disclosure, we provide efficient C-Plane message structures to describe the SRS configuration of all SRS ports in a slot containing SRS in one section description, if it is within the payload size limit of the packet. An example: First, we define a PRB cluster as a unique continuous PRB range used at least by one UE in any SRS symbol in the slot. A PRB cluster can be defines as the start PRB and the end PRB, or the start PRB and the number of PRBs. And each PRB cluster is assigned by a cluster ID. And each SRS symbol is assigned by a symbol ID in the slot. Then, each SRS resource can be identified by a cluster ID and a symbol ID. In this way, all SRS resources are mapped in a grid of cluster IDs and symbol IDs. In the C-Plane section description, we first define the PRB clusters and assign a cluster ID for each PRB cluster. Assignment of cluster ID can be explicitly done by setting the cluster ID in the section description. It can be also implicitly done by setting a rule. For example, cluster ID n-1 is assigned to the nth PRB cluster defined in the section description. After the defining the grid of cluster IDs and symbol IDs, the SRS configuration description is provided symbol by symbol. For each symbol, the SRS configuration description is provided PRB cluster by PRB cluster. For each PRB cluster in a symbol, the SRS configuration description is provided UE by UE. For each UE, the SRS configuration description is provided SRS port by SRS port. Basically, SRS configuration description contains 5 levels of description, i.e., common level, symbol level, PRB cluster level, UE level, SRS port level. Common level contains the common information for all SRS ports in all symbols and the definition of cluster ID and symbol ID grid. Symbol level contains the common information for all SRS ports in each symbol identified by a symbol ID. PRB cluster level contains the common information for all SRS ports in each PRB cluster identified by a cluster ID in each symbol. UE level contains the common information for all SRS ports of each UE identified by an SRS UE ID in each cluster in each symbol. SRS port level contains the information for each SRS port identified by an SRS port ID of each UE in each cluster in each symbol.
[0260] The SRS configuration description structure can be included a new Section Type or a new Section Extension.23-02-2026
[0261] If the same SRS configuration is used in different SRS resources for the SRS ports of the same UE, the repetition of the same description can be avoided by adding a field indicating the repetition of the same description without repeating the description. This can be done on UE level and / or SRS port level. This will help save some bytes in the C-Plane message. Another possibility is to have the PRB cluster level before the symbol level. Basically, after common level, the description provides PRB cluster level description and then symbol level description. So, it starts describing PRB cluster by PRB cluster. Then, describe symbol by symbol in each PRB cluster. Afterwards, describe UE level and SRS port level.
[0262] The disclosure is applicable to any use case when SRS channel estimation is performed in the O-RU. It is applicable to not only DL implementation but also UL implementation, when SRS channel estimation is performed in the O-RU.
[0263] Certain aspects of the disclosure may provide, inter alia, one or more of the following advantages.
[0264] • The SRS configuration description structure is fronthaul efficient. It is more efficient that PRB range information is coded in cluster ID, instead of using two parameters of the start PRB and the end PRB, or the start PRB and the number of PRBs. Cluster ID uses much fewer bits than using two parameters. The appearances of symbol ID and cluster ID are minimized, which only appears on symbol level and cluster level, respectively.
[0265] • O-RU needs to know the configuration of all SRS ports in an SRS resource in order to perform channel estimation. The structure provides all SRS ports in a PRB cluster in a symbol together. So, O-RU can get the information efficiently after reading the description of a PRB cluster in a symbol. It doesn’t need to read further in the section description. So, it increases O-RU processing efficiency.
[0266] • The structure provides the SRS configuration of all SRS ports in slot in one section description. It reduces the FH overhead with only one section description. O-RU processing is also efficient without the need to read multiple sections or messages.
[0267] • ADDITIONAL EXPLANATION23-02-2026
[0268] • 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.
[0269] • Example of SRS configuration description
[0270] Figure 15 (Figure 6 in PCT / SE2024 / 051026) shows an example of SRS configuration for 4 UEs. In this example, each UE has to antenna ports. Two SRS symbols are used, i.e., symbol 10 and 11, in the slot. In frequency domain multiplexing, Comb 4 is used. Each UE uses half bandwidth with frequency hopping. It also shows the two PRB clusters according to the definition in this disclosure. There are two UEs in each PRB cluster in any symbol. Two antenna ports of a UE use two Cyclic Shifts of CS 0 and CS 6.
[0271] The following provides an example of the SRS configuration description structure for the SRS configuration example shown in Figure 15 / 6, providing 5 levels information regarding SRS configuration for all UE SRS ports in a slot in an efficient and well-structured way.
[0272] • Common level SRS configuration description
[0273] — numSrsSymbols = 2
[0274] -numSrsClusters = 2
[0275] —PRB cluster definition
[0276] • Definition of PRB cluster 0
[0277] - srsClusterId = 0
[0278] - startPrbOfCluster = 0
[0279] - numPrbOfCluster = 136
[0280] • Definition of cluster 123-02-2026
[0281] - srsClusterId = 1
[0282] - startPrbOfCluster = 136
[0283] - numPrbOfCluster = 136
[0284] • Symbol level SRS configuration description
[0285] -First symbol
[0286] • symbolld = 10
[0287] • numSrsUesOfSymbol = 4
[0288] • srsCombNum = 4
[0289] • PRB cluster level for first symbol
[0290] - First PRB cluster
[0291] • srsClusterId = 0
[0292] • srsGroupSeqHopping = 'groupHopping'
[0293] • UE level for first cluster in first symbol
[0294] • UE specific parameters for first UE.
[0295] • SRS port level for first UE
[0296] • SRS port specific parameters for first SRS port of UE 0
[0297] • SRS port specific parameters for second SRS port of UE 0
[0298] • UE specific parameters for second UE.
[0299] • SRS port level for second UE
[0300] • SRS port specific parameters for first SRS port of UE 1
[0301] • SRS port specific parameters for second SRS port of UE 1
[0302] - Second PRB cluster23-02-2026
[0303] • srsClusterId = 1
[0304] • srsGroupSeqHopping = 'groupHopping'
[0305] • UE level for second cluster in first symbol
[0306] • UE specific parameters for first UE.
[0307] • SRS port level for first UE
[0308] • SRS port specific parameters for first SRS port of UE 2
[0309] • SRS port specific parameters for second SRS port of UE 2
[0310] • UE specific parameters for second UE.
[0311] • SRS port level for second UE
[0312] • SRS port specific parameters for first SRS port of UE 3
[0313] • SRS port specific parameters for second SRS port of UE 3
[0314] -Second symbol
[0315] • symbolld = 11
[0316] • numSrsUesOfSymbol = 4
[0317] • srsCombNum = 4
[0318] • PRB cluster level for second symbol
[0319] - First PRB cluster
[0320] • srsClusterId = 0
[0321] • srsGroupSeqHopping = 'groupHopping'
[0322] • UE level for first cluster in second symbol
[0323] • UE specific parameters for first UE.
[0324] SRS port level for first UE23-02-2026
[0325] • SRS port specific parameters for first SRS port of UE 2
[0326] • SRS port specific parameters for second SRS port of UE 2
[0327] • UE specific parameters for second UE.
[0328] • SRS port level for second UE
[0329] • SRS port specific parameters for first SRS port of UE 3
[0330] • SRS port specific parameters for second SRS port of UE 3
[0331] - Second PRB cluster
[0332] • srsClusterId = 1
[0333] • srsGroupSeqHopping = 'groupHopping'
[0334] • UE level for second cluster in second symbol • UE specific parameters for first UE.
[0335] • SRS port level for first UE
[0336] • SRS port specific parameters for first SRS port of UE 0
[0337] • SRS port specific parameters for second SRS port of UE 0
[0338] • UE specific parameters for second UE.
[0339] • SRS port level for second UE
[0340] • SRS port specific parameters for first SRS port of UE 1
[0341] • SRS port specific parameters for second SRS port of UE 1
[0342] The following lists an example of UE specific parameters for any UE. This is an example,23-02-2026
[0343] which doesn’t exclude the possibility to add other UE specific parameters.
[0344] • UE specific parameters for any UE
[0345] -numSrsPortsOfUe
[0346] -ueCapId
[0347] -srsUeldReset
[0348] -srsUeld
[0349] -srsSequenceld
[0350] The following lists an example of SRS port specific parameters for any UE. This is an example, which doesn’t exclude the possibility to add other SRS port specific parameters.
[0351] • SRS port specific parameters
[0352] — srsUePortld
[0353] -srsCyclicShift
[0354] -srsCombOffset
[0355] Example of new Section Type for SRS configuration description
[0356] In the following, we show an example of a new Section Type format (Section Type ZZ) supporting the SRS configuration description described in this disclosure, providing 5 levels information regarding SRS configuration for all UE SRS ports in a slot in an efficient and well-structured way. A similar structure can be used to define a new Section Extension for SRS configuration description. In this case, the new Section Extension can be used together with an existing Section Type or a new Section Type.
[0357] In this document, we focus on Table Al which shows the format of Section Type ZZ defined for the SRS configuration description described in this disclosure. Table A2, Table A3, Table A4 and Table A5 show symbol level SRS configuration description format, PRB cluster level SRS configuration description format, UE level SRS configuration description format, and SRS port level SRS configuration description format, respectively, which are parts of Section Type ZZ.23-02-2026
[0358] Table Al SRS configuration description format (Section Type ZZ)
[0359] Section Type ZZ: SRS configuration
[0360] 0 (msb) 1 2 3 4 5 6 7 (lsb) # of bytes Octet transport header, see clause 5.1.3 8 Octet 1 dataDirectio payloadVersion filterIndex 1 Octet 9 n
[0361] frameld 1 Octet 10 subframeld slotld 1 Octet 11 slotld startSymbolld 1 Octet 12 numberOfsections 1 Octet 13 sectionType = ZZ 1 Octet 14 srsChestCompHdr 1 Octet 15 reserved numSrsCfgMsgs 1 Octet 16 sectionld 1 Octet 17 sectionld reserved srsOnUlSl startSrsPrb [8:7] 1 Octet 18 ot
[0362] startSrsPrb [6:0] numSrsPrb[ 1 Octet 19
[0363] 8]
[0364] numSrsPrb [7:0] 1 Octet 20 ef reserved numSrsSymbols 1 Octet 21 numSrsClusters 1 Octet 22 srsClusterld of first PRB cluster startPrbOfCluster [8:7] 1 Octet 23 startPrbOfCluster of first PRB cluster [6:0] numPrbOfCI 1 Octet 24 uster [8] numPrbOfCluster of first PRB cluster [7:0] 1 Octet 25 var Octet 26 srsClusterld of last PRB cluster startPrbOfCluster [8:7] 1 var startPrbOfCluster of last PRB cluster [6:0] numPrbOfCI 1 var uster [8] numPrbOfCluster of last PRB cluster [7:0] 1 var SRS configuration of first symbol var var var var SRS configuration of last symbol var var Section Extensions as indicated by "ef var var NOTE: Octet 1 is transport header, octets 9-14 is radio application header, octet 17 and below is the section description.
[0365]
[0366] 23-02-2026
[0367] Table A2 Symbol level SRS configuration description format
[0368] SRS configuration of nth SRS symbol
[0369] # of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserved symbolld 1 1 n u m SrsUesOfSy m bol 1 2 reserved | srsCombNum 1 3 SRS configuration of first SRS cluster var 4 var var
[0370]
[0371] SRS configuration of last SRS cluster var var
[0372] Table A3 PRB cluster level SRS configuration description format
[0373] SRS configuration of mth cluster in an; / SRS symbol
[0374] # of O(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserve extrapolati
[0375] d on srsClusterld 1 1
[0376] reserved srsGroupSeqHopping 1 2 SRS configuration of first UE var 3 var var
[0377]
[0378] SRS configuration of last UE var var
[0379] Table A4 UE level SRS configuration description format SRS configuration of Ith UE in any cluster in any SRS symbol
[0380] # of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserved numSrsPortsOfUe 1 1 reserved ueCapId 1 2 srsUeld
[0381] Reset srsUeld [14:8] 1 3 srsUeld [7:0] 1 4 srsSeqld [15:8] 1 5 srsSeqld [7:0] 1 6 SRS configuration of first SRS port 3 7 var var
[0382]
[0383] SRS configuration of last SRS port 3 var23-02-2026
[0384] Table A5 SRS port level SRS configuration description format SRS configuration of kth SRS port of any UE in any cluster in any SRS symbol
[0385] # of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s srsCyclicShift srsUePortld 1 1 reserved srsCombOffset 1 2
[0386]
[0387] reserved 1 3
[0388] List of parameter fields in exemplified Section Type ZZ design
[0389] The following lists the definitions of all parameter fields used in the section description of Section Type ZZ, shown in Table Al to Table A5.
[0390] • srsChestCompHdr: this field instructs how the O-RU will compress the channel estimates. For example, this field value indicates which compression method is used and how many bits are used to represent the channel estimates. The definition can be similar to ‘udCompHdr’ field for U-Plane data compression defined in O-RAN open fronthaul spec.
[0391] • numSrsCfgMsgs: the number of C-Plane messages that conveys the SRS configuration description of all SRS ports in the slot. This is useful when the section description for SRS configuration is so long that the number of bytes used in the C- Plane message is more than the maximum payload size of a packet, e.g., 1500 bytes. In this case, the SRS configuration description is split into two or more C-Plane messages. With this field, the O-RU will know the number of C-Plane messages expected when receive the first C-Plane message.
[0392] • srsOnUlSlot: a one-bit flag indicates if SRS is in a UL slot or not. If SRS is in a special slot, srsOnUlSlot = 0. If SRS is in a UL slot, srsOnUlSlot = 1.
[0393] • startSrsPrb: the PRB index of the first (lowest frequency) PRB that contains SRS in any SRS symbol in the slot described in this section description.23-02-2026
[0394] • numSrsPrb: the number of SRS PRBs of the continuous PRB range that contains SRS in any SRS symbol in the slot. It equals to endSrsPrb minus startSrsPrb plus one, where endSrsPrb represents the PRB number of the last (highest frequency) PRB that contains SRS in any SRS symbol in the slot. Alternatively, this field can be changed to endSrsPrb.
[0395] • numSrsSymbols: the total number of SRS symbols in the slot.
[0396] • numSrsClusters: the total number of SRS PRB clusters in the slot.
[0397] • srsClusterld: an identification value assigned to a PRB cluster. For example, srsClusterld = 0 for the first PRB cluster with lowest SRS frequency PRB.
[0398] • extrapolation: a one-bit flag to instruct O-RU to perform frequency-domain extrapolation in SRS channel estimation or not. If extrapolation is set to 1, the O- DU instructs the O-RU to perform frequency-domain extrapolation. If extrapolation is set to 0, the O-RU doesn’t need to do frequency-domain extrapolation.
[0399] • startPrbOfCluster: the PRB index of the first (lowest frequency) PRB of the referred SRS PRB cluster in a symbol.
[0400] • numPrbOfCluster: the number of PRBs of the referred SRS PRB cluster in a symbol.
[0401] • symbolld: an identification value representing a symbol in the slot. For example, symbolld = 0 for the first symbol in a slot and symbolld = 13 for the last symbol in a slot.
[0402] • numSrsUesOfSymbol: the total number of UEs sending SRS in the referred symbol.
[0403] • srsCombNum: Comb number for SRS used for all SRS in the referred symbol.
[0404] Comb number indicates the subcarrier separation between two adjust subcarriers allocated for the SRS, as defined in 3GPP.
[0405] • srsGroupSeqHopping: a value indicates the type of SRS symbol hopping used.
[0406] There are several types, e.g., ‘neither’, ‘groupHopping’, or ‘sequenceHopping’ etc., as defined in 3 GPP.23-02-2026
[0407] • numSrsPortsOfUe: the number of SRS ports of the referred UE in the referred SRS resource identified by a srsClusterld and a symbolld.
[0408] • ueCapId: UE capability identification value indicates the capability of the referred UE. The UE capabilities are 1T1R, 1T2R, 1T4R, 2T2R, 2T4R, 4T4R, etc., where xTyR means x transmit antennas and y receive antennas. Each capability is assigned to a ueCapId value.
[0409] • srsUeld: an identification value assigned to a UE that sends SRS.
[0410] • srsUeldReset: a one-bit flag indicates if the srsUeld assignment to a UE is changed.
[0411] For example, srsUeldReset = 1 indicates the srsUeld assignment is changed and srsUeldReset = 0 indicates the srsUeld assignment is unchanged. This helps the O-RU to use the historical channel estimates or measurements to calculate new measurements with higher quality.
[0412] • srsSeqld: SRS sequence identity value used to generate SRS sequence, as defined in 3GPP.
[0413] • srsUePortld: an identification value assigned to a UE SRS antenna port.
[0414] • srsCyclicShift: cyclic shift offset value indicates the cyclic shift applied to the SRS sequence for a UE SRS antenna port, as defined in 3GPP.
[0415] • srsCombOffset: comb offset value indicates a frequency offset within the comb used for a UE SRS antenna port, as defined in 3GPP.23-02-2026
[0416] To further make it clear about the Cluster ID and Symbol ID mapping to SRS resources, more SRS configuration use case examples are provided here. Figure 16 / 7 shows an example with 4 SRS resources with two PRB clusters and two symbols. In each SRS resource, one or more UE SRS ports from one or more UEs can be allocated. In this example, numSrsSymbols = 2 and numSrsClusters = 2. The first PRB cluster refers full bandwidth SRS resources, spanning from PRB 0 to PRB 271. The second PRB cluster refers half bandwidth SRS resources, spanning from PRB 136 to PRB 271. In this example, two full bandwidth SRS resources (marked as grey boxes) or the two half bandwidth SRS resources (marked as white boxes) in Figure 16 (Figure 7 in PCT / SE2024 / 051026) may be used by a UE to send multiple SRS ports from multiple UE antennas using antenna switching. For example, a 2T4R UE sends SRS from first two UE antennas in symbol 10 and then the UE switches to the second two UE antennas to send SRS in symbol 12. In this example, symbol 11 is not used because antenna switching operation takes time and can’t be done for two adjacent symbols. In this example, the 4 SRS resources can be efficiently described with only 2 symbol IDs and 2 cluster IDs.
[0417] Figure 17 (Figure 8 in PCT / SE2024 / 051026) shows another example with a more complicated SRS configuration. In this example, there are 9 SRS resources marked as different boxes in Figure 17 / 8. Following the PRB cluster definition described in this document, there are 7 PRB clusters. First PRB cluster spans from PRB 0 to PRB 135. Second PRB cluster spans from PRB 136 to PRB 203. Third PRB cluster spans from PRB 204 to PRB 271. Fourth PRB cluster spans from PRB 0 to PRB 67. Fifth PRB cluster spans from PRB 68 to PRB 135. Sixth PRB cluster spans from PRB 136 to PRB 271. Seventh PRB cluster spans from PRB 0 to PRB 271. In this example, 9 SRS resources can be efficiently described with only 4 symbol IDs and 7 cluster IDs.23-02-2026
[0418] Through the example shown previously, the proposed way of describing SRS configuration in C-Plane can efficiently describe all possible SRS configurations from simple cases to complicated cases in a well structured way. And the SRS configuration of multiple SRS ports of one or more UEs in the same PRB cluster of each symbol are placed together in the C-Plane message. The O-RU can extract the SRS configuration efficiently for each SRS resource identified by a cluster ID and a symbol ID, which facilitate channel estimation operation that are normally performed within an SRS resource with the knowledge regarding how SRS is multiplexed in the SRS resource. For example, this would become more complicated if the SRS configuration is provided UE by UE, which would have lower O-RU processing efficiency than the proposed way in the document.
[0419] APPENDIX 2. Parts of patent application PCT / SE2025 / 050137
[0420] In patent application PCT / SE2024 / 051026 previously filed, we proposed an efficient C-Plane message structure (Section Type ZZ) to describe the SRS configuration of all SRS ports in a slot containing SRS in one section description, if it is within the payload size limit of the packet. If the message size is higher than the pay load size limit, it will split into multiple messages. The split is done on symbol level. Each message contains the SRS configuration description for a set of symbols. The proposed section description contains 5 levels of description, i.e., common level, symbol level, PRB cluster level, UE level, SRS port level. Common level contains the common information for all SRS ports in all symbols and the definition of cluster ID and symbol ID grid. And a PRB cluster is defined as a unique continuous PRB range used at least by one UE in any SRS symbol in the slot. Symbol level contains the common information for all SRS ports in each symbol identified by a symbol ID. PRB cluster level contains the common information for all SRS ports in each PRB cluster identified by a cluster ID in each symbol. UE level contains the common information for all SRS ports of each UE identified by an SRS UE ID in each cluster in each symbol. SRS port level contains the information for each SRS port identified by an SRS port ID of each UE in each cluster in each symbol.23-02-2026
[0421] However, there is a challenge to support future extension, e.g., add new parameters in the future. In the current O-RAN open fronthaul specification, the section extension design can’t support the proposed 5-level section description structure. The current section extension design can only support one level. This would limit the extensibility of proposed section description. In this disclosure, we propose a new Section Extension design to solve this issue. The proposed new Section Extension can flexibly and efficiently add extension data to any part or level of the SRS description, e.g., to all symbols on common level, any specific symbol on symbol level, any specific SRS block on PRB cluster level, any specific UE on UE level, any specific UE SRS port on UE SRS port level.
[0422] Further, the original proposal in patent application PCT / SE2024 / 051026 supports one section description with multi-level structure. In this disclosure, we proposed two new message structures to support using multiple section descriptions. The multiple section descriptions describing the SRS configuration of all SRS ports in a slot containing SRS are contained in one message, if it is within the payload size limit of the packet. Otherwise, it will be split into multiple messages. One benefit for supporting multiple sections is that it is more straight-forward to split sections to multiple sections when needed. This way is conceptually more compatible to the principle of the current O-RAN open fronthaul protocol design, while still keeping the benefits of the original proposal in patent application PCT / SE2024 / 051026. So, it may be more friendly to some HW implementation designed for current O-RAN specification. In the original proposal of patent application PCT / SE2024 / 051026, the rule to split on symbol level needs to be specified in the specification, which may be considered as adding complexity to the specification since it may be considered as adding one more implementation option. Another benefit is that the section extension can address smaller part of the SRS configuration in each section, which may be considered to be easier for some HW implementations.23-02-2026
[0423] In the first new proposal in this disclosure, we propose Section Type YY supporting multiple section descriptions with one section per symbol. Effectively, this proposal still maintains 5-level structure in the message. But the symbol level is done in sections. Then the section extension is done per symbol accordingly. This proposal aggregates SRS configuration per symbol in each section and using section extension can add new parameters to different part of the section. As mentioned before, advantage is that Section Type YY supporting multiple sections which are more compatible to the current O-RAN open fronthaul protocol design without the need to introducing a new implementation option, e.g., about message fragmentation when split a message to multiple messages. This contributes to a more consistent O-RAN specification and protocol handling, since O-RAN always support multiple sections. Introducing constraint to allow only 1 section description may be treated as non-backwards compatible. And some HW may prefer processing multiple smaller sections, instead of one large section. This proposal has one section per symbol. The number sections are usually not increase so much than Section Type ZZ. In the second proposal in this disclosure, we create Section Type WW supporting multiple section descriptions with one section per SRS PRB block identified by symbol ID and cluster ID. It can be seen as merger of symbol level and PRB cluster level to one SRS block level. Note that in patent application PCT / SE2024 / 051026 SRS block is also referred as SRS resource. In this disclosure, we use SRS block as the terminology. New section extension designs are also provided to support providing new parameters (extension data) in the future. This proposal aggregates SRS configuration per SRS block in each section and using section extension can add new parameters to different part of the section. This proposal allows even smaller sections than Section Type YY, at the cost of having more sections. This proposal may benefit some HW that prefers processing even smaller sections on PRB block level.
[0424] Certain embodiments may provide one or more of the following and other technical advantage(s).
[0425] The new proposals (Section Type YY and Section Type WW) in this disclosure shares the same following advantages of Section Type ZZ proposed in patent application PCT / SE2024 / 051026, as listed below.23-02-2026
[0426] • The SRS configuration description structures of Section Type YY and Section Type WW are fronthaul efficient. It is more efficient that PRB range information is coded in cluster ID, instead of using two parameters of the start PRB and the end PRB, or the start PRB and the number of PRBs. Cluster ID uses much fewer bits than using two parameters. The appearances of symbol ID and cluster ID are minimized, which only appears on symbol level and cluster level, respectively.
[0427] • O-RU needs to know the configuration of all UE SRS ports in an SRS block in order to perform channel estimation. The proposed structures in Section Type YY and Section Type WW provide all UE SRS ports in a PRB cluster in a symbol together. So, O-RU can get the information efficiently after reading the description of a PRB cluster in a symbol. It doesn’t need to read further in the section description. So, it increases O-RU processing efficiency.
[0428] In addition, the proposed new section extension design for Section Type ZZ proposed in patent application PCT / SE2024 / 051026 can flexibly and efficiently add extension data to any part of the SRS description, e.g., to all symbols on common level, any specific symbol on symbol level, any specific SRS block on PRB cluster level, any specific UE on UE level, any specific UE SRS port on UE SRS port level. It improves the extensibility of Section Type ZZ. And the two new section structure proposed in this disclosure supports multiple sections in one message. It is more compatible to the principle of current O-RAN open fronthaul design supporting multiple sections, while still keeping most benefits of the original proposal in patent application PCT / SE2024 / 051026. It may be more friendly to some HW implementation designed for current O-RAN specification. It is more straight forward to split them into multiple messages when needed. It avoids adding one more implementation option in the specification, which makes the specification more consistent. It may be easier for some HW implementation, e.g. HW that prefers processing smaller sections.
[0429] Example of SRS configuration description
[0430] Figure 15 (figure 6 in patent application PCT / SE2025 / 050137) shows an example of SRS configuration for 4 UEs. In this example, each UE has to antenna ports. Two SRS symbols are used, i.e., symbol 10 and 11, in the slot. In frequency domain multiplexing, Comb 4 is used. Each UE uses half bandwidth with frequency hopping. It also shows the two PRB clusters according to the definition in the invention. There are two UEs in each PRB cluster23-02-2026
[0431] in any symbol. Two antenna ports of a UE use two Cyclic Shifts of CS 0 and CS 6. In Figure 6, it shows in total 4 SRS blocks in this example. An SRS block is identified by a PRB cluster and a symbol, in which the SRS sequences of one or more SRS ports of one or more UEs are multiplexed. A PRB cluster is defined as a unique continuous PRB range used at least by one UE in any SRS symbol in the slot. Each PRB cluster is identified by a cluster ID. And Each symbol is identified by a symbol ID.
[0432] An SRS block represents the SRS data of the PRB range of a single SRS PRB cluster in a single symbol. In an SRS block, the SRS sequences of one or more SRS ports of one or more UEs are multiplexed.
[0433] New Section Extension for 5-level section description (Section Type ZZ)
[0434] Table Bl shows the format of new Section Extension XX defined to support adding more parameters to a section of Section Type ZZ proposed in patent application PCT / SE2024 / 051026. The proposed section extension provides the capability to add more parameters (referred to as extension data in Table B 1 to any part in a section of Section Type ZZ, e.g., to all symbols on common level, any specific symbol on symbol level, any specific SRS block on PRB cluster level, any specific UE on UE level, any specific UE SRS port on UE SRS port level. The section extension supports to provides extension data for multiple parts in a section of Section Type ZZ. Each part is referred to as one extension entry in Table Bl. Each extension entry has fields of numExtensionEntry, srsExtensionType, srsUePortld, symbolld, srsClusterld, srsUeld and extension data.
[0435] Field of extension data represent the parameters of one entry the section extension conveys. numExtensionEntry represent the number of extension entries in this section extension. srsUePortld, symbolld, srsClusterld and srsUeld are identifier for UE SRS port, symbol, PRB cluster and UE. More detailed definitions of srsUePortld, symbolld, srsClusterld, srsUeld are provided in later description. These identifiers are used to identify different parts of the section description. But these identifiers are not always used. Field of srsExtensionType is used to indicate if and which these identifier(s) are used. When any identifier is not used, it may not be present in the structure to save some bytes in the section extension. The following lists an example of usage of srsExtensionType. Note that “reserved*” field in Table Bl is only present if the other field in the same byte is present.23-02-2026
[0436] • srsExtensionType = 0: symbolld, srsClusterld, srsUeld, srsUePortld are not present, providing extension data for all symbols.
[0437] • srsExtensionType = 1: symbolld is present, other IDs are not present, providing extension data for the symbol indicated by symbolld.
[0438] • srsExtensionType = 2: symbolld and srsClusterld are present, providing extension data for the SRS block indicated by symbolld and srsClusterld.
[0439] • srsExtensionType = 3: srsUeld is present, other IDs are not present, providing extension data for the UE indicated by srsUeld in all SRS blocks.
[0440] • srsExtensionType = 4: srsUeld and srsUePortld are present, other IDs are not present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in all SRS blocks.
[0441] • srsExtensionType = 5: symbolld, srsClusterld and srsUeld are present, srsUePortld is not present, providing extension data for the UE indicated by srsUeld in the SRS block indicated by symbolld and srsClusterld.
[0442] • srsExtensionType = 6: symbolld, srsClusterld, srsUeld, srsUePortld are present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in the SRS block indicated by symbolld and srsClusterld.
[0443] In this example, any unused identifier is not present to save some bytes. It is also possible to assign a special value to each identifier to indicate it is not used. This makes each entry with fixed structure which may benefit some HW implementation.23-02-2026
[0444] Table Bl SRS configuration section extension structure (Section Extension XX) 0(msb) 1 2 3 4 5 6 7 (lsb) bytes: Octet ef extType = XX 1 Octet N extLen 1 Octet N+1 numExtension Entry 1 Octet N+2 srsExtensionType srsUePortld for first extension entry (not 1 Octet always present) N+3 reserved* symbolld for first extension entry (not always present) 1 reserved* srsClusterld for first extension entry (not always present) 1 reserved srsUeId[15:8] for first extension entry (not always present) 1
[0445] *
[0446] srsUeId[7:0] for first extension entry (not always present) 1 extension data of first extension entry var
[0447] var srsExtensionType srsUePortld for last extension entry (not 1
[0448] always present)
[0449] reserved* symbolld for last extension entry (not always present) 1 reserved* srsClusterld for last extension entry (not always present) 1 reserved* srsUeId[15:8] for last extension entry (not always present) 1
[0450] srsUeId[7:0] for last extension entry (not always present) 1 extension data of last extension entry var
[0451]
[0452] zero pad to 4-byte boundary
[0453] Section Type YY supporting multiple sections with one section per symbol
[0454] Table B2 shows the format of the new Section Type YY defined for the SRS configuration description supporting multiple sections with one section per symbol. The difference from Section Type ZZ in patent application PCT / SE2024 / 051026 is that the common level parameters are moved to the common header of Section Type YY which is applicable to all sections in the message, while Section Type ZZ has the common level parameters in the section header since it has only one section. Table B3 shows the section description format, in which each section provides the SRS configuration description of a symbol. Therefore, the symbol level descriptions can be described in multiple sections. Table B4, Table B5 and Table B6 show PRB cluster level SRS configuration description format, UE level SRS configuration description format, and SRS port level SRS configuration description format, respectively, for Section Type YY, which are the same as Section Type ZZ.23-02-2026
[0455] Table B2 SRS configuration description format (Section Type YY)
[0456] Section Type YY: SRS configuration
[0457] #of
[0458] 0 (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes transport header, see clause 5.1.3 8 Octet 1 dataDirectio payloadVersion filterIndex 1 Octet 9 n
[0459] frameld 1 Octet 10 subframeld slotld 1 Octet 11 slotld startSymbol Id 1 Octet 12 numberOfsections 1 Octet 13 sectionType = YY 1 Octet 14 srsChestCompHdr 1 Octet 15 reserved numSrsCfgMsgs startSrsPrb [8:7] 1 Octet 16 startSrsPrb [6:0] numSrsPrb[ 1 Octet 17
[0460] 8]
[0461] numSrsPrb [7:0] 1 Octet 18 reserved numSrsSymbols 1 Octet 19 numSrsClusters 1 Octet 20 srsClusterld of first PRB cluster startPrbOfCluster [8:7] 1 Octet 21 startPrbOfCluster of first PRB cluster [6:0] numPrbOfCI 1 Octet 22 uster [8] numPrbOfCluster of first PRB cluster [7:0] 1 Octet 23 var Octet 24 srsClusterld of last PRB cluster startPrbOfCluster [8:7] 1 var startPrbOfCluster of last PRB cluster [6:0] numPrbOfCI 1 var uster [8] numPrbOfCluster of last PRB cluster [7:0] 1 var section for first symbol var var var var section for last symbol var var
[0462]
[0463] NOTE: Octet 1-8 are transport header, Octet 9-14 is radio application header, Octet 15 to the octet before the first section description (“section for first symbol” in this case) is common header of Section Type, the rest are the section descriptions of multiple sections
[0464]
[0465] 23-02-2026
[0466] Table B3 Section description format (symbol level SRS configuration description) SRS configuration of section for nth SRS symbol
[0467] #0f 0(msb) 1 2 3 4 5 6 7(Isb) byte Octet s
[0468] ef reserved symbolld 1 1 numSrsUesOfSymbol 1 2 reserved | srsCombNum 1 3 SRS configuration of first SRS cluster var 4 var var SRS configuration of last SRS cluster var var
[0469]
[0470] Section Extensions as indicated by "ef var var
[0471] Table B4 PRB cluster level SRS configuration description format
[0472] SRS configuration of mth cluster in an SRS sym 301
[0473] #of Q(msb) J; 2 3 4 5 6 7(lsb) byte Octet s reserved srsClusterld 1 1 reserved srsGroupSeqHopping 1 2 SRS configuration of first UE var 3 var var
[0474]
[0475] SRS configuration of last UE var var23-02-2026
[0476] Table B5 UE level SRS configuration description format _ SRS configuration of Ith UE in a cluster in an SRS symbol
[0477] #of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserved numSrsPortsOfUe 1 1
[0478] reserved 1 2 srsUeldR
[0479] eset srsUeld [14:8] 1 3 srsUeld [7:0] 1 4 srsSeqld [15:8] 1 5 srsSeqld [7:0] 1 6 SRS configuration of first SRS port 3 7 var var
[0480]
[0481] SRS configuration of last SRS port 3 var
[0482] Table B6 SRS port level SRS configuration description format SRS configuration of kth SRS port of a UE in a cluster in an SRS symbol #of 0(msb) 1 234 5 6 7(lsb) byte Octet s srsCyclicShift srsUePortld 1 1 reserved srsCombOffset 1 2
[0483]
[0484] reserved 1 3
[0485] Section Extension AA for Section Type YY
[0486] Table B7 shows the format of new Section Extension AA defined to support adding more parameters to a section of Section Type YY. The design is similar to Section Extension XX. But each entry only has 3 identifier fields of srsUePortld, srsClusterld and srsUeld to identify different part of a section which provides SRS configuration description of a symbol. Field of srsExtensionType is used to indicate if and which these identifier(s) are used. When any identifier is not used, it may not be present in the structure to save some bytes in the section extension. The following lists an example of usage of srsExtensionType. Note that “reserved*” field in Table B7 is only present if the other field in the same byte is present.23-02-2026
[0487] • srsExtensionType - 0: srsClusterld, srsUeld, srsUePortld are not present, providing extension data for the referred symbol.
[0488] • srsExtensionType = 1: srsClusterld are present, other IDs are not present, providing extension data for the SRS block indicated by srsClusterld in the referred symbol. • srsExtensionType = 2: srsUeld is present, other IDs are not present, providing extension data for the UE indicated by srsUeld in the referred symbol.
[0489] • srsExtensionType = 3: srsUeld and srsUePortld are present, other IDs are not present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in the referred symbol.
[0490] • srsExtensionType = 4: srsClusterld and srsUeld are present, srsUePortld is not present, providing extension data for the UE indicated by srsUeld in the SRS block indicated by symbolld and srsClusterld.
[0491] • srsExtensionType = 5: srsClusterld, srsUeld, srsUePortld are present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in the SRS block indicated by srsClusterld in the referred symbol.
[0492] In this example, any unused identifier is not present to save some bytes. It is also possible to assign a special value to each identifier to indicate it is not used. This makes each entry with fixed structure which may benefit some HW implementation.23-02-2026
[0493] Table B7 SRS configuration section extension structure (Section Extension AA) 0 (msb) 1 2 3 4 5 6 7 ( 'Isb) ' b #ytes Octet ef | extType = AA 1 Octet N extLen 1 Octet N+1 numExtension Entry 1 Octet N+2 srsExtensionType srsUePortId for first extension entry (not 1 Octet always present) N+3 reserved* | srsClusterld for first extension entry (not always present) 1 reserved srsUeld[15:8] for first extension entry (not always present) 1
[0494] *
[0495] srsUeId[7:0] for first extension entry (not always present) 1 Extension data of first extension entry var
[0496] var srsExtensionType srsUePortId for last extension entry (not 1
[0497] always present)
[0498] reserved* | srsClusterld for last extension entry (not always present) 1 reserved* srsUeld[15:8] for last extension entry (not always present) 1
[0499] srsUeId[7:0] for last extension entry (not always present) 1 Extension data of last extension entry var
[0500]
[0501] zero pad to 4-byte boundary
[0502] Section Type WW supporting multiple sections with one section per SRS block
[0503] Table B8 shows the format of the new Section Type WW defined for the SRS configuration description supporting multiple sections with one section per SRS block. Table B9 shows the section description format, in which each section provides the SRS configuration description of an SRS block identified by a symbol ED (symbolld) and cluster ID (srsClusterld).
[0504] Compared with Section Type ZZ and Section Type YY, this design can be seen as merger of symbol level and PRB cluster level to one SRS block level. Table BIO and Table Bl 1 show UE level SRS configuration description format and SRS port level SRS configuration description format, respectively, for Section Type WW, which are the same as Section Type ZZ and Section Type YY.23-02-2026
[0505] Table B8 SRS configuration description format (Section Type WW)
[0506] Section Type WW: SRS configuration
[0507] #of
[0508] 0 (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes transport header, see clause 5.1.3 8 Octet 1 dataDirectio payloadVersion filterIndex 1 Octet 9 n
[0509] frameld 1 Octet 10 subframeld slotld 1 Octet 11 slotld startSymbolld 1 Octet 12 numberOfsections 1 Octet 13 sectionType = WW 1 Octet 14 srsChestCompHdr 1 Octet 15 reserved numSrsCfgMsgs startSrsPrb [8:7] 1 Octet 16 startSrsPrb [6:0] numSrsPrb[ 1 Octet 17
[0510] 8]
[0511] numSrsPrb [7:0] 1 Octet 18 reserved numSrsSymbols 1 Octet 19 numSrsClusters 1 Octet 20 srsClusterld of first PRB cluster startPrbOfCluster [8:7] 1 Octet 21 startPrbOfCluster of first PRB cluster [6:0] numPrbOfCI 1 Octet 22 uster [8] numPrbOfCluster of first PRB cluster [7:0] 1 Octet 23 var Octet 24 srsClusterld of last PRB cluster startPrbOfCluster [8:7] 1 var startPrbOfCluster of last PRB cluster [6:0] numPrbOfCI 1 var uster [8] numPrbOfCluster of last PRB cluster [7:0] 1 var section for first SRS block in first symbol var var var var section for last SRS block in first symbol var var var var section for first SRS block in last symbol var var var var section for last SRS block in last symbol var var NOTE: Octet 1-8 are transport header, Octet 9-14 is radio application header, Octet 15 to the octet before the first section description ("section for first SRS block in first symbol” in this case) is common
[0512]
[0513] header of Section Type, the rest are the section descriptions of multiple sections23-02-2026
[0514] Table B9 Section description format (SRS block level SRS configuration description) SRS configuration of section for nth SRS block
[0515] #of
[0516] 0 (msb) 1 2 3 4 5 6 7 (lsb) Octet bytes
[0517] ef reserved symbol Id 1 1 srsClusterld
[0518] numUesOfSrsBlock 1 2 reserved srsGroupSeqHopping reserved srsCombNum 1 3 SRS configuration of UE var var var var SRS configuration of last UE var var Section Extensions as indicated by "ef var var
[0519]
[0520] Table BIO UE level SRS configuration description format
[0521] SRS configuration of Ith UE in a cluster in an SRS symbol
[0522] #of O(msb) 1 2 3 4 5 6 7(lsb) byte Octet s reserved numSrsPortsOfUe 1 1 reserved 1 2 srsUeldR
[0523] eset srsUeld [14:8] 1 3 srsUeld [7:0] 1 4 srsSeqld [15:8] 1 5 srsSeqld [7:0] 1 6 SRS configuration of first SRS port 3 7 var var
[0524]
[0525] SRS configuration of last SRS port 3 var
[0526] Table Bll SRS port level SRS configuration description format
[0527] SRS configuration of kth SRS port of a UE in a cluster in an SRS symbol #of 0(msb) 1 2 3 4 5 6 7(lsb) byte Octet s srsCyclicShift srsUePortld 1 1 reserved srsCombOffset 1 2
[0528]
[0529] reserved 1 3
[0530] Section Extension BB for Section Type WW
[0531] Table B12 shows the format of new Section Extension BB defined to support adding more parameters to a section of Section Type WW. The design is similar to Section Extension XX23-02-2026
[0532] and Section Extension AA. But each entry only has 2 identifier fields of srsUePortld, and srsUeld to identify different part of a section which provides SRS configuration description of aN SRS block. Field of srsExtensionType is used to indicate if and which these identifier(s) are used. When any identifier is not used, it may not be present in the structure to save some bytes in the section extension. The following lists an example of usage of srsExtensionType. Note that “reserved*” field in Table B12 is only present if the other field in the same byte is present.
[0533] • srsExtensionType = 0: srsUeld and srsUePortld are not present, providing extension data for the referred SRS block.
[0534] • srsExtensionType = 1: srsClusterld are present, other IDs are not present, providing extension data for the SRS block indicated by srsClusterld in the referred symbol. • srsExtensionType = 2: srsUeld is present, other IDs are not present, providing extension data for the UE indicated by srsUeld in the referred symbol.
[0535] • srsExtensionType = 3: srsUeld and srsUePortld are present, other IDs are not present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in the referred symbol.
[0536] • srsExtensionType = 4: srsClusterld and srsUeld are present, srsUePortld is not present, providing extension data for the UE indicated by srsUeld in the SRS block indicated by symbolld and srsClusterld.
[0537] • srsExtensionType = 5: srsClusterld, srsUeld, srsUePortld are present, providing extension data for the UE port indicated by srsUePortld of the UE indicated by srsUeld in the SRS block indicated by srsClusterld in the referred symbol.
[0538] Table B12 SRS configuration section extension structure (Section Extension BB) O(msb) 1 2 3 4 5 6 7(lsb) Octet ef extType = BB 1 Octet N extLen 1 Octet N+1 numExtensionEntry 1 Octet N+2 srsExtensionType srsUePortld for first extension entry (not 1 Octet always present) N+3 reserved srsUeld[15:8] for first extension entry (not always present) 1
[0539] ★
[0540] srsUeId[7:0] for first extension entry (not always present) 1 Extension data of first extension entry var
[0541] var srsExtensionType srsUePortld for last extension entry (not 1 d always present)
[0542] reserved* srsUeld[15:8] for last extension entry (not always present) 1
[0543] srsUeId[7:0] for last extension entry (not always present) 1 Extension data of last extension entry var
[0544]
[0545] zero pad to 4-byte boundary23-02-2026
[0546] In this example, any unused identifier is not present to save some bytes. It is also possible to assign a special value to each identifier to indicate it is not used. This makes each entry with fixed structure which may benefit some HW implementation.
[0547] The following lists the definitions of all parameter fields used in this disclosure, used in Table Bl to Table B12.
[0548] • srsChestCompHdr: this field instructs how the O-RU will compress the channel estimates. For example, this field value indicates which compression method is used and how many bits are used to represent the channel estimates. The definition can be similar to ‘udCompHdr’ field for U-Plane data compression defined in O-RAN open fronthaul spec.
[0549] • numSrsCfgMsgs: the number of C-Plane messages that conveys the SRS configuration description of all SRS ports in the slot. This is useful when the section description for SRS configuration is so long that the number of bytes used in the C- Plane message is more than the maximum payload size of a packet, e.g., 1500 bytes. In this case, the SRS configuration description is split into two or more C-Plane messages. With this field, the O-RU will know the number of C-Plane messages expected when receive the first C-Plane message.
[0550] • startSrsPrb: the PRB index of the first (lowest frequency) PRB that contains SRS in any SRS symbol in the slot described in this section description.
[0551] • numSrsPrb: the number of SRS PRBs of the continuous PRB range that contains SRS in any SRS symbol in the slot. It equals to endSrsPrb minus startSrsPrb plus one, where endSrsPrb represents the PRB number of the last (highest frequency) PRB that contains SRS in any SRS symbol in the slot. Alternatively, this field can be changed to endSrsPrb.
[0552] • numSrsSymbols: the total number of SRS symbols in the slot.
[0553] • numSrsClusters: the total number of SRS PRB clusters in the slot.
[0554] • srsClusterld: an identification value assigned to a PRB cluster. For example, srsClusterld = 0 for the first PRB cluster with lowest SRS frequency PRB.23-02-2026
[0555] • extrapolation: a one-bit flag to instruct O-RU to perform frequency-domain extrapolation in SRS channel estimation or not. If extrapolation is set to 1, the O- DU instructs the O-RU to perform frequency-domain extrapolation. If extrapolation is set to 0, the O-RU doesn’t need to do frequency-domain extrapolation.
[0556] • startPrbOfCluster: the PRB index of the first (lowest frequency) PRB of the referred SRS PRB cluster in a symbol.
[0557] • numPrbOfCluster: the number of PRBs of the referred SRS PRB cluster in a symbol.
[0558] • symbolld: an identification value representing a symbol in the slot. For example, symbolld = 0 for the first symbol in a slot and symbolld = 13 for the last symbol in a slot.
[0559] • numSrsUesOfSymbol: the total number of UEs sending SRS in the referred symbol.
[0560] • srsCombNum: Comb number for SRS used for all SRS in the referred symbol.
[0561] Comb number indicates the subcarrier separation between two adjust subcarriers allocated for the SRS, as defined in 3GPP.
[0562] • srsGroupSeqHopping: a value indicates the type of SRS symbol hopping used.
[0563] There are several types, e.g., ‘neither’, ‘groupHopping’, or ‘sequenceHopping’ etc., as defined in 3GPP.
[0564] • numSrsPortsOfUe: the number of SRS antenna ports of the referred UE in the referred SRS resource identified by a srsClusterld and a symbolld.
[0565] • ueCapId: UE capability identification value indicates the capability of the referred UE. The UE capabilities are 1T1R, 1T2R, 1T4R, 2T2R, 2T4R, 4T4R, etc., where xTyR means x transmit antennas and y receive antennas. Each capability is assigned to a ueCapId value.
[0566] • srsUeld: an identification value assigned to a UE that sends SRS.23-02-2026
[0567] • srsUeldReset: a one-bit flag indicates if the srsUeld assignment to a UE is changed.
[0568] For example, srsUeldReset = 1 indicates the srsUeld assignment is changed and srsUeldReset = 0 indicates the srsUeld assignment is unchanged. This helps the O-RU to use the historical channel estimates or measurements to calculate new measurements with higher quality.
[0569] • srsSeqld: SRS sequence identity value used to generate SRS sequence, as defined in 3GPP.
[0570] • srsUePortld: an identification value assigned to a UE SRS antenna port.
[0571] • srsCyclic Shift: cyclic shift offset value indicates the cyclic shift applied to the SRS sequence for a UE SRS antenna port, as defined in 3GPP.
[0572] • srsCombOffset: comb offset value indicates a frequency offset within the comb used for a UE SRS antenna port, as defined in 3GPP.
[0573] • numExtensionEntry: number of extension entries in the section extension.
[0574] Some more examples of SRS configuration use cases
[0575] To further make it clear about the Cluster ID and Symbol ID mapping to SRS resources, more SRS configuration use case examples are provided here. Figure 16 (Figure 7 in patent application PCT / SE2025 / 050137) shows an example with 4 SRS blocks with two PRB clusters and two symbols. In each SRS block, one or more UE SRS ports from one or more UEs can be allocated. In this example, numSrsSymbols = 2 and numSrsClusters = 2. The first PRB cluster refers full bandwidth SRS blocks, spanning from PRB 0 to PRB 271. The second PRB cluster refers half bandwidth SRS blocks, spanning from PRB 136 to PRB 271. In this example, two full bandwidth SRS blocks (marked as grey boxes) or the two half bandwidth SRS blocks (marked as white boxes) in Figure 16 / 7 may be used by a UE to send multiple SRS ports from multiple UE antennas using antenna switching. For example, a 2T4R UE sends SRS from first two UE antennas in symbol 10 and then the UE switches to the second two UE antennas to send SRS in symbol 12. In this example, symbol 11 is not used because antenna switching operation takes time and can’t be done for two adjacent symbols. In this example, the 4 SRS blocks can be efficiently described with only 2 symbol IDs and 2 cluster IDs.23-02-2026
[0576] Figure 17 (figure 8 in patent application PCT / SE2025 / 050137) shows another example with a more complicated SRS configuration. In this example, there are 9 SRS blocks marked as different boxes in Figure 17 / 8. Following the PRB cluster definition described in this document, there are 7 PRB clusters. First PRB cluster spans from PRB 0 to PRB 135. Second PRB cluster spans from PRB 136 to PRB 203. Third PRB cluster spans from PRB 204 to PRB 271. Fourth PRB cluster spans from PRB 0 to PRB 67. Fifth PRB cluster spans from PRB 68 to PRB 135. Sixth PRB cluster spans from PRB 136 to PRB 271. Seventh PRB cluster spans from PRB 0 to PRB 271. In this example, 9 SRS blocks can be efficiently described with only 4 symbol IDs and 7 cluster IDs.
[0577] Through the example shown previously, the proposed way of describing SRS configuration in one or multiple sections in C-Plane can efficiently describe all possible SRS configurations from simple cases to complicated cases in a well-structured way. And the SRS configuration of multiple SRS ports of one or more UEs in the same SRS block of each symbol are placed together in the C-Plane message. The O-RU can extract the SRS configuration efficiently for each SRS block identified by a cluster ID and a symbol ID, which facilitate channel estimation operation that are normally performed within an SRS block with the knowledge regarding how SRS is multiplexed in the SRS block. For example, this would become more complicated if the SRS configuration is provided UE by UE, which would have lower O-RU processing efficiency since O-RU has to identify the SRS blocks and the multiplexed UE ports in each SRS block by gathering information from multiple places describing different UEs in the message.
[0578] REFERENCES
[0579] [1] O-RAN Control, User and Synchronization Plane Specification 16.01
Claims
1. 23-02-2026CLAIMS1. A method performed in an O-RAN Radio Unit, O-RU, comprising- receiving from an O-RAN Distributed Unit, O-DU, an indication of priority for each of a plurality of channel estimates to be made, wherein priority is indicated per User Equipment, UE,- performing the channel estimates; and- sending the channel estimates to the O-DU,and wherein the indications of priority are received in a message which describes thephysical resource blocks, PRBs on which Sounding Reference Signal, SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
2. A method according to claim 1 wherein the channel estimates are sent to the O-DU in the order of priority.
3. A method according to claim 1 wherein the channel estimates are made in the order of priority.
4. An O-RAN Radio Unit, O-RU adapted to perform the method of any of the claims 1-3.
5. A computer program comprising program code which when run on a processor of an O-RAN Radio Unit, O-RU causes the O-RU to perform the method of any of the claims 1-3.
6. An O-RAN Radio Unit, O-RU comprising processing circuitry and a memoryconfigured to:-receive from an O-RAN Distributed Unit, O-DU an indication of priority for each of aplurality of channel estimates to be made, wherein priority is indicated per UE,- perform the channel estimates; and- send the channel estimates to the O-DU,and wherein the indications of priority are received in a message which describes thephysical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.Sänt / skickat till Patent- och registreringsverket7. 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 from the O-DU an indication of priority for each of a plurality of channel estimates to be made, wherein priority is indicated per UE,- performing the channel estimates; and- sending the channel estimates to the O-DU,and wherein the indications of priority are received in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
8. A method performed in an O-RAN Distributed Unit, O-DU comprising- prioritizing the determining of SRS, Sounding Reference Signal, -based channel estimates in an O-RAN Radio Unit, O-RU,- sending to the O-RU an indication of priority for each of a plurality of channel estimates to be made, wherein priority is indicated per UE; and- receiving the channel estimates from the O-RUwherein the indications of priority are sent in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
9. A method according to claim 8 wherein channel estimationfor a UE is prioritized based on one or more of:- amount of data in UE transmit buffer,- UE mobility,- UE latency requirements,- UE reliability requirements,- UE subscription typeand wherein a UE having higher mobility, latency requirements, reliability requirements or having a premium subscription is assigned a higher priority than a UE having lower mobility, latency requirements, reliability requirements or not having a premium subscription.
10. A method according to claim 8 or 9 wherein the channel estimates are received in order of priority.
11. An O-RAN Distributed Unit, O-DU adapted to perform the method of any of the claims 8-10.
12. A computer program comprising program code which when run on a processor of an O-RAN Distributed Unit, O-DU causes the O-DU to perform the method of any of the claims 8-10.
13. An O-RAN Distributed Unit, O-DU comprising processing circuitry and a memory configured to:- prioritize the determining of SRS, Sounding Reference Signal, -based channel estimates in an O-RAN Radio Unit, O-RU,- send to the O-RU an indication of priority for each of a plurality of channel estimates to be made, wherein priority is indicated per UE; and- receive the channel estimates from the O-RUwherein the indications of priority are sent in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
14. 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:- prioritizing the determining of SRS, Sounding Reference Signal, -based channel estimates in the O-RU,- sending to the O-RU an indication of priority for each of a plurality of channel estimates to be made, wherein priority is indicated per UE; and- receiving the channel estimates from the O-RUwherein the indications of priority are sent in a message which describes the physical resource blocks, PRBs on which SRS is to be received by the O-RU from one or more UEs and on which SRS channel estimate(s) are to be made on the received SRS.
15. A system comprising an O-RAN Distributed Unit, O-DU according to claim 11 or 13 connected over fronthaul to an O-RAN Radio Unit, O-RU according to claim 4 or 6.