Measurements for UE positioning

Abstract

Methods and systems are provided for UE positioning measurement in O-RAN networks. An O-RAN Radio Unit (O-RU) receives a request from an O-RAN Distributed Unit (O-DU) to perform positioning measurements on reference signals from a User Equipment (UE). The O- RU performs the requested measurements and transmits results to the O-DU over a fronthaul interface. The positioning measurements can be performed on either Demodulation Reference Signals (DMRS) or Sounding Reference Signals (SRS), with the O-DU dynamically selecting between signal types based on resource availability and positioning requirements. Measurement results include azimuth angle of arrival, zenith angle of arrival, and time of arrival offset information. DMRS-based positioning enables more frequent positioning updates and supports more UEs simultaneously compared to SRS-only approaches, while reducing air interface resource consumption. The methods improve UE positioning accuracy and system efficiency by performing measurements in the O-RU rather than transferring raw signal data over the fronthaul interface.

Description

Measurements for UE positioningTECHNICAL FIELDThe disclosure relates to positioning in Open RAN (O-RAN) systems.BACKGROUNDThe set of standards developed by the O-RAN alliance is referred to as O-RAN. O-RAN introduces an Open Fronthaul (Open FH) interface between O-RAN distribution unit (O-DU) and O-RAN radio unit (O-RU), as shown in Figure 1. O-DU is a logical node hosting RLC (Radio Link Control), MAC (Medium Access Control), and High-PHY (Physical) layers based on a lower layer functional split. O-RU is a logic node hosting Low-PHY layer and RF (Radio Frequency) processing based on a lower layer functional split.It is desirable to be able to determine the physical position of User Equipments, UEs. It is further desirable to be able to determine UE positions according to varying needs in terms of accuracy, temporal resolution / frequency of measurement, number of UEs to be positioned simultaneously as well as with respect to limits in terms of air interface resources, fronthaul interface capacity, processing capacity and simplicity of design of software and fronthaul protocols.SUMMARYThis disclosure relates to methods and systems for determining the physical position of User Equipment (UE) in Open Radio Access Network (O-RAN) systems. The invention addresses limitations in existing UE positioning approaches using positioning in O-RAN Distributed Units (O-DU) that rely solely on Sounding Reference Signals (SRS), which can be resource-constrained and provide infrequent positioning updates.The disclosed methods enable positioning measurements to be performed in O-RAN Radio Units (O-RU) on reference signals received from UEs, with the measurement results reported to O-RAN Distributed Units (O-DU) over the fronthaul interface. The positioning measurements can be performed on either Demodulation Reference Signals (DMRS) or Sounding Reference Signals (SRS), providing flexibility to optimize positioning performance based on resource availability and system requirements.DMRS-based positioning offers significant advantages over SRS-only approaches. DMRS signals are available whenever a UE transmits uplink data and do not consume additional air interface resources, enabling more frequent positioning updates and support for a greater number of UEs simultaneously. This is particularly beneficial since uplink traffic sessions typically span multiple continuous slots, allowing positioning accuracy to be improved through measurements on several DMRS instances.The positioning measurements include angle of arrival information in both azimuth and zenith dimensions, as well as time of arrival offset data. These measurements enabledetermination of both the direction and distance from the O-RU antenna to the UE antenna. The measurements may be reported for multiple multipath components of the radio channel, further enhancing positioning accuracy. Quality indicators may also be provided to indicate the reliability of the measurement results.The O-DU can dynamically select between DMRS and SRS measurements based on various factors including air interface resource availability, the number of UEs requiring positioning, required positioning accuracy and frequency, and current traffic conditions. This dynamic selection capability allows the system to adapt positioning strategies in realtime to meet varying operational requirements while optimizing resource utilization.By performing measurements in the O-RU rather than transferring complete reference signal data over the fronthaul interface, the invention reduces fronthaul capacity requirements and enables more efficient system operation. The disclosed methods are applicable to various O-RAN beamforming configurations and can be extended to other types of radio units and distributed units beyond O-RAN specifications.In a first aspect, a positioning measurement method is provided where an O-RAN Radio Unit receives a request from an O-RAN Distributed Unit to measure positioning information from a User Equipment's reference signal, performs the measurement on the received reference signal, and sends the measurement results back to the Distributed Unit. In a second aspect, a positioning measurement method is provided where an O-RAN Distributed Unit sends a request to an O-RAN Radio Unit to measure positioning information from a User Equipment's reference signal and receives the measurement results back from the Radio Unit.In a third aspect, the positioning measurement methods are provided where the reference signal being measured is a Demodulation Reference Signal (DMRS).In a fourth aspect, the positioning measurement methods are provided where the reference signal being measured is a Sounding Reference Signal (SRS).In a fifth aspect, the positioning measurement methods are provided where the measurement request specifies whether to measure SRS or DMRS signals.In sixth aspect, the DMRS-based positioning method is provided where the measurement request identifies the specific PUSCH DMRS configuration to use.In a further aspect, the SRS-based positioning method is provided where the measurement request identifies the specific SRS configuration to use.In yet another aspect, the positioning measurement methods are provided where measurement results are communicated using section type 10 messages that include an indicator of whether the measurement was performed on SRS or DMRS signals.In another aspect, the positioning measurement methods are provided where the signal type indicator is included in the section type 10 message header.In a further aspect, the positioning measurement methods are provided where the measurement results include information about the azimuth angle of arrival, zenith angle of arrival, and / or time of arrival of the signal.In yet another aspect, the positioning measurement methods are provided where the measurement results include quality indicators showing how reliable the measurements are. In another aspect, the positioning measurement methods are provided where the measurement results provide angle of arrival, time of arrival, and quality information for multiple signal paths between the User Equipment and Radio Unit.In a further aspect, the positioning measurement methods are provided where the measurement requests are sent using either the O-RAN control plane or management plane. In yet another aspect, the DMRS-based positioning method is provided where the measurement request is sent in a C-Plane section type 5 message with section extension 24, with specific bits indicating that positioning measurement should be performed.In another aspect, the positioning measurement method is provided where the Distributed Unit chooses to request DMRS-based positioning when a User Equipment is scheduled to send uplink data.In a further aspect, the positioning measurement method is provided where the Distributed Unit chooses to request DMRS-based positioning based on how much time has passed since the last SRS measurement and / or how long until the next SRS transmission.In yet another aspect, the positioning measurement method is provided where the Distributed Unit chooses to request DMRS-based positioning when there are insufficient SRS resources available.In another aspect, the positioning measurement method is provided where the Distributed Unit chooses to request SRS-based positioning when a User Equipment is scheduled for SRS transmission or when SRS resources are available.In another aspect, the positioning measurement methods are provided that can be implemented using any type of 3GPP Radio Unit and / or Distributed Unit, not limited to O-RAN specifications.BRIEF DESCRIPTION OF THE DRAWINGSFigure 1 illustrates an Open FH interface between O-DU and O-RU.Figure 2 illustrates UL C-plane and U-plane data flows.Figure 3 shows a block schematic of UL beamforming methods: WDBF and CIBF (Figure 4.1.2-1 in [2]).Figure 4 and 5 show block schematics of DMRS-BF implementations: DMRS-BF-NEQ and DMRS-EQ (Figure 12.6.1.1-1 in [1]).Figure 6 shows a block schematic of SRS-BF implementation discussed in O-RAN WG4.Figure 7 shows azimuth and zenith angle in array coordinate (Figure 12.5.2-1 in [1]).Figure 8 illustrates transmission of a positioning measurement report from O-RU to O-DU. Figure 9 shows an example of a communications system.Figure 10 shows another example of a communications system.Figure 11 shows a wireless device.Figure 12 shows a network node.Figure 13 shows a block diagram illustrating a virtualization environment.Figure 14 shows an example of an S RS configuration for 4 UEs.Figure 15 shows a second example of an SRS configuration.Figure 16 shows a third example of an SRS configuration.DETAILED DESCRIPTIONThis disclosure focuses on the uplink (UL) direction of the Open FH. Figure 2 shows UL control-plane (C -plane) and user-plane (U-plane) data flows in the O-RAN WG4 specification. For each slot, O-DU sends C-plane messages to convey control information required for processing of user data (e.g. scheduling and beamforming commands) to the O-RU. The scheduling information includes the resource elements (REs) to be scheduled, and the beamforming information provides beam Id (for pre-stored beamforming weights) or beamforming weights (BFWs) to be used. O-RU processes the scheduled REs and performs beamforming, then it sends the user data to O-DU in U-plane messages.Multiple UL beamforming methods are defined in O-RAN WG4 specification [1], Figure 3, which is a redrafted version of figure 4.1.2-1 in [2], shows Weight-based Dynamic Beamforming (WDBF) and Channel Information-based Dynamic Beamforming (CIBF) implementations supported by CUS specification [1],For WDBF, SRS symbols ysrsare extracted in O-RU and I / Q (In-phase / Quadrature) values are send to O-DU to compute the BFWs, Mrs. which are thus transported back to O-RU for UL beamforming. The beamformed user data ybf G Cwhas reduced vector size compared to the received user data yrxG CK, where N is the number of spatial streams and K is the number of antenna elements. The required fronthaul capacity is reduced by transporting ybf rather than yrx. The benefit is substantial for Massive MIMO (Multiple Input Multiple Output), i.e., when N « K.For CIBF, instead of BFWs (or beamlds), the channel estimation matrix based on SRS Hsrsis transported from O-DU to O-RU. BFWs, Urs, are hence computed by the O-RU using the received channel estimation and scheduling information. O-RU then applies beamforming on the UL data to reduce the data volume over the fronthaul interface.WG4 specification also supports another UL beamforming method: DMRS-based beamforming (DMRS-BF), as shown in Figure 4 and 5, which together are a redrafted version of Figure 12.6.1.1-1 in [1], Depending on where equalization is performed, two variants of DMRS-BF are supported in WG4 CUS specification (O-RAN Working Group 4Control, User and Synchronization Plane Specification): DMRS-BF with equalization (DMRS-BF-EQ) (figure 5) and DMRS-BF without equalization (DMRS-BF-NEQ) (figure 4). DMRS-BF-EQ has equalization performed in O-RU, while DMRS-BF-NEQ has equalization performed in O-DU. The beamformed user data in DMRS-BF ybf G CLfurther reduces the required fronthaul capacity, i.e., reducing the vector size from the number of spatial streams (N) to the number of data layers (L).As showed in figure 4 and 5, O-RU sends radio resource management (RRM) measurements to O-DU. These RRM measurements are calculated before beamforming and equalization, so they cannot be computed by O-DU in DMRS-BF-EQ. However, these measurements are essential for demodulation and decoding in O-DU. RRM measurement reporting is not mandatory but can still be beneficial for DMRS-BF-NEQ. Tablel lists supported RRM measurements in WG4 CUS specification [1],Table 1: RRM measurement types (Table 9.2.1-1 in [1])On the other hand, WG4 will further optimize the fronthaul capability by avoiding large amount of SRS I / Q data (ysrsin Figure 3) transport from O-RU to O-DU. Therefore, SRS-based beamforming (SRS-BF [3]) was proposed and is being studied in WG4, see Figure 6 for a possible implementation of SRS-BF under WG4 discussion.SRS-BF offloads SRS channel estimation function to O-RU, and the generated SRS channel estimates (Hsrs) may be compressed before transporting to O-DU to reduce the required data rate over OpenFH. Similar to DMRS-BF, O-RU may perform RRM measurements (e.g., time-offset, frequency-offset, signal power, SINR, etc) and it sends the measurement reports to O-DU.The current assumption in O-RAN is that O-DU will make positioning measurements based on SRS.SRS (Sounding Reference Signal) is typically a scarce resource, which can be a problem, particularly when a large bandwidth is sounded. Accuracy depends, inter aha, on bandwidth. Positioning needs can vary greatly. Positioning can be needed for many UEs simultaneouslyor just few, frequent or not so frequent updates, high accuracy or low. Sometimes resources are scarce, sometimes not.Instead of performing measurements in O-DU on SRS transferred there over fronthaul, several advantages can be achieved by instead performing measurements in O-RU (e.g. Ao A, ToA) and reporting the results to O-DU over fronthaul.In O-RU, it can be made possible to perform positioning measurements not only on SRS, but also on DMRS(Demodulation Reference Signal) (which in e.g. DMRS-BF beamforming including DMRS-BF-EQ and DMRS-BF-NEQ may not be available to O-DU in a form useable for positioning measurements, e.g., the beamformed DMRS after beamforming in O-RU can’t be used for positioning purpose).DMRS, while not using the large bandwidth and typically scarce resources that may be configured for SRS, is available whenever a UE is transmitting in the uplink and thus does not consume any extra resources. This saves air interface resources when many UEs are transmitting simultaneously. Accuracy can be improved by measuring on several DMRS instances, as an uplink traffic session is usually served in several continuous slots. Hence use of SRS or DMRS can be selected on the fly to meet positioning requirements and resource situation at any moment. Fronthaul resources are saved by not transferring entire SRS (or original DMRS) signals, as well as using an efficient same format for reporting positioning measurement as well as other measurements, and on either SRS or DMRS.In current WG4 CUS specification [1], UE positioning is possibly supported by using SRS IQ data in the O-DU. However, the periodicity of SRS can be quite long which makes slow update of the UE position and thereby affects the positioning accuracy. Further, SRS also has limited to capacity to support many UEs. Only using SRS will limit the number of Ues for UE positioning.The proposed methods in this disclosure enable DMRS-based UE positioning for DMRS-BF O-RUs which improves UE positioning accuracy and the number of Ues for positioning in comparison to SRS-based UE positioning, since PUSCH data arrives more often, typically in multiple slots in a row and PUSCH channel supports more Ues than SRS.The proposed method can also support SRS-based UE positioning for SRS-BF O-RU which may be supported in later O-RAN specifications.The choice of positioning method may dynamically take into account e.g. available air interface resources, number of Ues that need to be positioned, needed accuracy and frequency of positioning. Traffic load on fronthaul may also benefit and system design may become less complex.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 documents provided in the Appendices.In this disclosure, we propose a method to support DMRS based UE positioning for DMRS-BF O-RU where DMRS processing for PUSCH channel is done in the O-RU. In the proposed method, O-RU calculates the AoA (angle of arrival) and ToA (time of arrival) offset for a UE based on UL (PUSCH) DMRS symbol(s) and then send the calculated AoA and ToA offset values back to the O-DU. And O-DU can use the reported values to calculate the UE position. Or O-DU can forward the measurements to an application server which calculates the UE position. For calculating the UE position, ToA offset may be used to update the time of arrival calculation, since it provides information about how much ToA is shifted compared with previous estimated ToA per slot. Then, the ToA can be used to calculate the distance between O-RU antenna and UE antenna for each PUSCH slot. The AoA can be used to know the direction from UE antenna to O-RU antenna. Using both ToA and AoA, the relative position of the UE to the O-RU position can be derived. With additional information about O-RU’s position, the absolute position of the UE can be determined.We propose to add a UE positioning measurement report from O-RU to O-DU in O-RAN’s open fronthaul. UE positioning measurement is proposed as a new RRM measurement type, and it can be reported in Section Type 10 (ST10). The UE positioning measurement may include azimuth angle of arrival, zenith angle of arrival, time of arrival offset, and corresponding measurement uncertainty / quality. And these measurement values can be reported for a certain number of selected multipath components.For DMRS-BF, AoA and ToA offset for UE positioning can be measured based on PUSCH DMRS. A control bit is also proposed in Section Extension 24 (SE24) to allow O-DU to request the UE positioning measurement report based on PUSCH DMRS.If SRS-BF is used for SRS, AoA and ToA offset for UE positioning can be measured based on SRS in O-RU. Similarly, one control bit is added to SRS-BF configuration Section Type or Section Extension to let O-DU explicitly control the UE positioning measurement report based on SRS.The following provides more description about the new measurement report supporting different types of UE positioning measurement.UE positioning measurement report structure examplesUE positioning measurement report is conveyed by ST 10 messages from O-RU to O-DU. In the 1stembodiment, one UE positioning measurement report contains one azimuth AoA, one zenith AoA, and one ToA offset:• measTypeld = 7 shall be set for MEAS_UE_POSmeasTypeld (MEAS UE POS measurement type): 7 bitsreserved: 8 bitsmeasDataSize (length of measurement report): 16 bitsueAzAoa (UE azimuth angle of arrival): 16 bitsueZeAoa (UE zenith angle of arrival): 16 bitsueToaOffset (UE time of arrival offset): 16 bitsreserved: 48 bitsThe parameters are defined as follows:ueAzAoa (UE azimuth angle of arrival)Description: This parameter is part of the UE positioning measurement. It provides value of UE azimuth angle of arrival (AoA) in degrees with resolution of 0.1 degree. As shown in Figure 7, azimuth angle ( ) rotates counter-clockwise around z-axis. Angle value of 0 degree means it points to array broad-side, and angle value of 90 degree means it points to y-axis.Value range:{0x0000 (0) - OxOEOF (3599): positive azimuth angle of arrival (0.0 - 359.9 degree) OxFFFF: invalid measurement resultOther values: reserved}.Type: unsigned integer.Field length: 16 bits.Default Value: N / AueZeAoa (U E zenith angle of arrival)Description: This parameter is part of the UE positioning measurement. It provides value of UE zenith angle of arrival in degrees with resolution of 0.1 degree. As shown in Figure 7, 6 is the zenith angle. Angle value of 0 degree means it points to zenith and angle value of 90 degree means it points to horizon.Value range:{0x0000 (0) - 0x0708 (+1800): zenith angle of arrival (0.0 - 180.0 degree)OxFFFF: invalid measurement resultOther values: reserved}.Type: unsigned integer.Field length: 16 bits.Default Value: N / AueToaOffset (UE time of arrival offset)Description: This parameter is part of the UE positioning measurement. It provides value of UE time of arrival (ToA) offset. The measurement unit is nanoseconds, with a resolution ofx Tc, where Tc= (480 kHz x 4096)-1« 0.509 ns and / z represents the subcarrier spacing configuration. See 3GPP 38.211 for definition for Tcand / z. This gives an effective time resolution of (30 kHz / SCS) x Tc. The range of the reported value is [— 215+ 1, 215— l] / 216symbol duration, i.e. an open interval of ± 0.5 symbol duration (excluding cyclic prefix).Value range:{0x0000 (0): no UE ToA offset, 0 symbols0x0001 (+1 ) - 0x7FFF (+32767): positive UE ToA offset in the range 2-16X [1, 215— 1] symbols 0x8001 (-32767) - OxFFFF (-1 ): negative UE ToA offset in the range 2“16X [-215+ 1, -1] symbols0x8000 (-32768): invalid measurement result}Type: signed integerField length: 16 bitsDefault Value: N / AMore parameters for UE positioning can be defined in the future using the 48 reserved bits, e.g., angular spread, delay spread, measurement quality / uncertainty, etc.In the 1stembodiment, UE Positioning Measurement includes two UE angle of arrival (AoA) measurements (i.e., azimuth AoA and zenith AoA) and one UE time of arrival (ToA) offset measurement, which are measured on PUSCH DMRS or SRS for each UE. All three measurements are defined at the antenna reference point.NOTE: Since the measurements are defined at the antenna reference point, the 0-RU is expected to, when necessary, compensate the measurement result to mitigate impact of any processing (e.g. 0-RU internal dimension reduction) between the antenna reference point and the point where the 0-RU performs the measurement. When 0-DU controlled dimensionality reduction with SE 27 is used then the 0-RU may report RRM measurement as affected by thedimensionality reduction (without compensation) and the O-DU accommodates effects of the dimensionality reduction if necessary.The UE azimuth AoA is reported with one azimuth AoA value per UE per slot, which is in unit of degree, with resolution of 0.1 degrees. The measurement value is mapped to a signed 16-bit integer and the supported range is 0 to 359.9 degree. If the UE azimuth AoA measurement is not available when requested, then O-RU may set the ueAzAoa value to OxFFFF, as the invalid result, in the report.The UE zenith AoA is reported with one zenith AoA value per UE per slot, which is in unit of degree, with resolution of 0.1 degrees. The measurement value is mapped to an unsigned 16-bit integer and the supported range is 0 to 180.0 degree. If the UE zenith AoA measurement is not available when requested, then O-RU may set the ueZeAoa value to OxFFFF, as the invalid result, in the report.UE ToA offset is reported with one ToA offset value per UE per slot. The UE ToA offset is defined relative to the UL frame timing at the antenna reference point and represents the offset between the UL frame timing and UE ToA estimated. A positive UE ToA offset means that the UE ToA is later than UL frame timing while a negative UE ToA offset means that the UE ToA is earlier than UL frame timing. The reported ToA offset value is mapped to a signed 16-bit integer where one integer step represents a time resolution of (30 kHz / SCS) x Tc, where Tc= (480 kHz x 4096)-1« 0.509 ns is defined in 3GPP TS 38.211 clause 4.1. Measurement range: ± 0.5 OFDM symbol (excluding cyclic prefix) for the used subcarrier spacing. If the UE ToA offset measurement is not available when requested, then O-RU may set the ueToaOffset value to 0x8000, as the invalid results, in the report.The ueld in the Section Type 10 header indicates which UE the measurement refers to. The measurement report may be sent with the eAxC ID and ueld associated with any layer of the UE (any value of layer-number part of the ueld). The report may contain only one set of measurement results even if the UE has multiple scheduled layers or if the UE is scheduled in multiple user groups (in different PRB or symbol ranges).In the 2ndembodiment, one UE positioning measurement report contains multiple sets of positioning measurements for one UE, and each set of positioning measurement includes one azimuth AoA value, one zenith AoA value, one ToA offset value. Each set of the measurements corresponds to one multipath component of the channel. For example, the first set corresponds to the line-of-sight path estimated and the second set corresponds to a strong non-line-of-sight path estimated. With the measurements of multiple paths for one UE, UE position can be determined more accurately. A multipath component is sometimes also referred to as a channel tap.• measTypeld = 7 shall be set for MEAS_UE_POSmeasTypeld (MEAS UE POS measurement type): 7 bitsnumPosMeas (number of positioning measurement sets in this ST10 section): 8 bitsmeasDataSize (length of measurement report): 16 bitsueAzAoa (UE azimuth AoA): 16 bitsueZeAoa (UE zenith AoA): 16 bitsueToaOffset (UE time of arrival offset): 16 bitsreserved: 16bits for each set of positioning measurementTable 3: UE positioning measurement report (measTypeld = 7)The parameters are defined as follows:numPosMeas (number of positioning measurements)Description: This parameter indicates the number of positioning measurements reported in the UE positioning measurement report. It can contain 1-256 sets of measurement reports.Value range:{0x01 (1 ) - 0xFF(255): number of reported positioning measurements0x00: number of reported positioning measurements is 256}.Type: unsigned integer.Field length: 8 bits.Default Value: 0x01.ueAzAoa (azimuth angle of arrival)Description: This parameter provides the value of azimuth AoA for a multipath component of the channel, unit in degrees with resolution of 0.1 degree. See ueAzAoA in the 1stembodiment for data format definition.ueZeAoA (zenith angle of arrival)Description: This parameter provides value of zenith AoA for a multipath component of the channel, unit in degrees with resolution of 0.1 degree. See ueZeAoA in the 1stembodiment for data format definition.ueToaOffset (ToA offset)Description: This parameter provides value of time of arrival (ToA) offset of a multipath component of the channel. The measurement unit is nanoseconds. See ueToaOffset in the 1stembodiment for data format definition.In the 2ndembodiment, one UE positioning measurement report contains one or multiple sets of measurements for one UE. Each set of the measurements corresponds to one multipath component of the channel. The number of measurement sets is indicated by the parameter numPosMeas in the UE positioning measurement report. Parameter numPosMeas is a positive integer with range from 1 to 256 (value 0x00 means 256 number of positioning measurements). The number of words (16 bits), indicated by measDataSize, shall be set as 2*numPosMeas + 1.O-RU reports its capability of the maximum number of sets of positioning measurement per UE positioning measurement report via M-plane parameter ‘max-ue-posmeas -supported’.O-DU configures the maximum number of sets of positioning measurements per report, it allows O-RU to report, via M-plane parameter ‘max-ue-posmeas -configured’. O-RU shall not report more than ‘max-ue-posmeas -configured’ sets of positioning measurement in one UE positioning measurement report.All three measurements in one set of UE positioning measurement are defined at the antenna reference point, and the data formats are defined similarly to their counterpart in the previous embodiment. In this embodiment, O-RU are given more flexibility in measurement reporting. It may measure and report only one set of AoA (azimuth and zenith) and ToA offset per UE, as in the previous embodiment.The 16 reserved bits in each set of positioning measurement are used to meet the 4-byte boundary for each set of measurement. More parameters for positioning can be defined in the future using these reserved bits, e.g., angular spread, delay spread, etc.In the 3rdembodiment, one UE positioning measurement report contains multiple sets of positioning measurements for a UE, and each set of positioning measurement includes one azimuth AoA value, measurement quality / uncertainty of the azimuth AoA, one zenith AoA value, measurement quality / uncertainty of the zenith AoA, one ToA offset value, and measurement quality / uncertainty of the azimuth AoA. Each set of the measurements corresponds to one multipath component of the channel of a UE.• measTypeld = 7 shall be set for MEAS_UE_POSmeasTypeld (MEAS UE POS measurement type): 7 bitsnumPosMeas (number of positioning measurement sets in this ST10 section): 8 bitsueAoaQualityType (quality type for AoA values): 8 bits ueToaOffsetQualityType (quality type forToA offset value): 8 bits measDataSize (length of measurement report): 16 bitsueAzAoa (UE azimuth AoA): 16 bitsueAazAoaQualityVal (UE azimuth AoA quality value): 16 bitsueZeAoa (UE zenith AoA): 16 bitsueZeAoaQualityVal (UE zenith AoA quality value): 16 bitsueToaOffset (UE time of arrival offset): 16 bitsueToaOffsetQualityVal (UE ToA offset quality value): 16 bitsThe parameters are defined as follows:numPosMeas, ueAzAoa, ueZeAoa, ueToaOffset have the same definition in the 2ndembodiment.ueAoaQualityType (UE AoA quality type) indicates what type of ueAoaQuality value is used, regarding the definition of ueAoaQuality used for calculating the value. UE AoA measurement quality indicating the uncertainty of the estimated UE AoA values can be measured in many ways. For example, it can be the standard deviation of estimated AoA value. It is hard to standardize one quality measure. Multiple quality measures should be supported. This field isused to support different ways of calculating ueAoaQuality. In this way, it is more future proof to support new quality measures in the future.ueToaOffsetQualityType (UE ToA offset quality type) indicates what type of ueToaOffsetQuality value is used, regarding the definition of ueToaOffsetQuality used for calculating the value. UE ToA measurement quality indicating the uncertainty of the estimated UEToA value can be measured in many ways. For example, it can be the standard deviation of estimated ToA value. It is hard to standardize one quality measure. Multiple quality measures should be supported. This field is used to support different ways of calculating ueAoaQuality. In this way, it is more future proof to support new quality measures in the future.ueAzAoaQualityVal (UE azimuth AoA quality value): This parameter provides uncertainty of the azimuth AoA measurement. The unit could be in degrees. It can be measured using other metrics. How to calculate this value depends on ueAoaQualityType value.ueZeAoaQualityVal (UE zenith AoA quality value): This parameter provides uncertainty of the zenith AoA measurement. It can be measured as uncertainty in degrees. It can be measured using other metrics. Howto calculate this value depends on ueAoaQualityType value.toaOffsetQualityVal (ToA offset quality value): This parameter provides uncertainty of the ToA offset measurement. . It can be measured as uncertainty in degrees. How to calculate this value depends on ueToaOffsetQuality value.Further, ueAoaQualityType, ueToaOffsetQualityType, ueAzAoaQualityVal, ueZeAoaQualityVal, toaOffsetQualityVal can be added to the 1stembodiment as well to provide the estimation uncertainty of the measurement values.In the 4thembodiment, UE AoA measurement and UEToA measurement are separately reported:• measTypeld = 7 shall be set for MEAS_UE_AOAmeasTypeld (MEAS UE AOA measurement type): 7 bitsreserved: 8 bitsmeasDataSize (length of measurement report): 16 bitsueAzAoa (UE azimuth angle of arrival): 16 bitsueZeAoa (UE zenith angle of arrival): 16 bits• measTypeld = 8 shall be set for MEAS_UE_TOA_OFFSETmeasTypeld (MEAS UE TOA measurement type): 7 bitsreserved: 8 bitsmeasDataSize (length of measurement report): 16 bitsueToaOffset (UE time of arrival offset): 16 bitsreserved: 16 bitsTable 6: UE time of arrival offset measurement report (measTypeld = 8)This embodiment does not bundle measurements based on the use case / purpose (i. e. , UE positioning) so that it provides flexibility that AoA and / or ToA measurements can be used for other use cases / purposes (e.g., beamforming, UE pairing, etc.).Similar to the 2ndand 3rdembodiment, one AoA measurement report can contain multiple sets of azimuth AoA, zenith AoA, and measurement quality values for one UE. Same argument applies to ToA offset measurement.For 2nd, 3rdand 4thembodiments, the measurement values can be reported for one or more multipath components. In addition, amplitude information of each report multipath component can be also included, which helps understand the strength of each multipath component, which could help improve UE positioning.Additionally, each measurement value may be also reported per layer or per SRS port, which would provide more information regarding the spatial property of the channel and the UE position.UE positioning measurement report triggering method examplesIf the UE positioning measurement is based on PUSCH DMRS, then the triggering of the measurement report may be based Section Type 5 (ST 5) + Section Extension 24 (SE 24). SE24 is used with ST5 to convey PUSCH DMRS configuration used for DMRS-BF-EQ and DMRS-BF-NEQ beamforming methods. Entries are used to convey PUSCH DMRS configuration, and one entry is used for one UE data layer. There are four types of entry defined for SE24. For entry Type = 0 or 1, the DMRS configuration parameters follows the last preceding entry that is either entry Type = 2 or 3.For entryType = 2, the format of the entry is defined in Table 7Table 7: Format of entry with entryType = 2In one embodiment, the reserved bit in the 2ndOctet is changed to a control bit, posMeas, as shown in Table 8. The proposed change allows O-DU explicitly request UE positioning measurement report for the specific UE described in the entry (i.e., ueld associated with the entry).For entryType = 3, the format of the entry is defined in Table 9Table 9: Format of entry with entryType = 3Similarly, the reserved bit in the 2ndOctet is changed to posMeas.posMeas (UE positioning measurement report request)Description: This parameter is provided per entry in Section Extension 24 when RRM measurement MEAS_UE_POS (UE positioning measurement) is enabled via M-Plane. If the measurement is not enabled, the O-DU shall set it to 0 and the O-RU shall ignore it. This parameter indicates if MEAS_UE_POS shall be reported by the O-RU forthe specific UE described by the entry in SE 24 in which this parameter appears.• If posMeas = 0, then the O-RU shall not report the MEAS_UE_POS forthe UE described.• If posMeas = 1, then the O-RU shall report the MEAS_UE_POS forthe UE described. Value range: 0- 1.Type: unsigned integer.Field length: 1 bit.Default Value: 0.When posMeas is set 1 , UE positioning measurement may be sent with eAxCJD and ueld of any layer of the UE per UE per slot.If the UE positioning measurement is based on SRS, then the triggering of the measurement report may be based on a new Section Type proposed in patent application PCT / SE2024 / 051026, here called ST ZZ, which is proposed to convey SRS configuration in a slot from O-DU to O-RU in C-Plane to provide the SRS information for O-RU to perform SRS based beamforming. Particularly, a triggering or request field can be added on the UElevel description in ST ZZ. The current format of UE level description per cluster per SRS symbol in ST ZZ (SRS configuration) is presented in Table 11.In one embodiment, one reserved bit in SRS configuration of a UE is replaced by the posMeas (UE positioning measurement report request) to allow O-DU to explicitly request the UE positioning report.able 12: Modified SRS configuration of a UE in a cluster in an SRS symbolThe disclosed embodiments should not be seen as mutually exclusive, but feature(s) of one embodiment may be combined with feature(s) of another whenever appropriate, e.g. a field disclosed in one embodiment may be added to the fields of another embodiment and the like. It is also foreseen that it may not always be necessary to include all of the disclosed fields.One measurement type supports both DMRS-BF and SRS-BFAs described previously, UE positioning measurement can be used to report both DMRS-based measurement for DMRS-BF and SRS-based measurement for SRS-BF. In this disclosure, we propose to use the same measurement type in ST10 for both measurements. The idea is to indicate if it is DMRS-based measurement or SRS-based measurement in the header part of ST 10. When O-DU receives the measurement report, O-DU checks the ST 10header and then knows if the measurement attached is DMRS-based or SRS-based. The benefit is to avoid creating two different measurement types with the same report structure. This method also applies to other “common” measurements for DMRS-based and SRS-based. This will help to reduce the number of measurement types created.UE positioning measurement type related capabilities examplesThe O-RU may declare supported RRM measurements via M-Plane capability reporting and the O-DU may configure which RRM measurements to use via M-Plane configuration.If the UE positioning measurement is based on PUSCH DMRS, then this measurement may be supported by some RX endpoints in O-RU supporting DMRS-BF-EQ or DMRS-BF-NEQ. Moreover, it is optional for O-DU to support RRM measurement report for UE positioning measurement based on PUSCH DMRS, and it is optional for O-RU to support UE positioning measurement based on PUSCH DMRS.If the UE positioning measurement is based on SRS, then this measurement may be supported by some RX endpoints in O-RU supporting SRS-BF. Moreover, it may be optional for O-DU to support RRM measurement report for UE positioning measurement based on SRS, and it may be optional for O-RU to support UE positioning measurement based on SRS. The O-RU may declare supporting sending UE positioning measurement report for all UEs. If this is enabled by the O-DU via M-Plane, O-RU performs UE positioning measurement and sends the measurement report for all UEs without the need of checking the request field in C-Plane messages. This may simplify O-RU implementation.O-DU selection of reference signal type to measure on,O-DU can select whether to measure on SRS or DMRS. Several factors may be taken into consideration for such a decision. SRS air interface resources may be scarce, particularly if they are to be shared between many UEs. The time interval between successive SRS transmissions for a UE may therefore be relatively long. Some positioning applications may require frequent position updates (e.g. on the order of every second or more frequent) whereas others do not. DMRS may be more suitable for frequent updates. Hence if the time since a previous measurement on SRS is too long, or the time until a next SRS measurement occasion is too long, the O-DU may trigger an uplink transmission from the UE wherein DMRS measurement can be done. If SRS is anyway scheduled for other purposes and there is no need for frequent update, SRS may be more suitable for the positioning measurements. However, if the UE is anyway scheduled for PUSCH transmission, it is advantageous to perform measurement on the DMRS of that transmission, as it does not use any extra air interface resources.Other nodesThe methods and devices disclosed herein may be performed in RUs and DUs that are not necessarily as defined by O-RAN, for example any DU and / or RU according to 3GPP specifications.

[0001] Figure 9 shows an example of a communication system 900 in accordance with some embodiments.

[0002] In the example, the communication system 900 includes a telecommunications network 902 that includes an access network 904, such as a radio access network (RAN), and a core network 906, which includes one or more core network nodes 908. The access network 904 includes one or more access network nodes or base stations of various types, access network nodes 910A and 910B are depicted (which may be collectively referred to as network nodes 910), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points (APs). Some embodiments of the access network 904 may include more than one access network technology. The network nodes 910 of access network 904 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs), such as by connecting UEs 912A, 912B, 912C, and 912D (one or more of which may be generally referred to as UEs 912) to the core network 906 over one or more wireless connections.

[0003] 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 902 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network 902 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 902, including one or more access network nodes 910 and / or core network nodes 908.

[0004] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). An ORAN network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthauluser 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.

[0005] The network nodes 910 facilitate direct or indirect connection of one or more UEs 912 to the core network 906 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 900 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 900 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0006] The UEs 912 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 910 and other communication devices. Similarly, the network nodes 908, 910 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network 902) with the UEs 912 and / or with other network nodes or equipment in the telecommunications network 902 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 902. More specifically, UEs 912 may send messages, data, and / or other signals to network nodes 908, 910 or other elements of the telecommunications network 902 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 908, 910 may send messages, data, and other signals to UEs 9122, other network nodes 908, 910, and other devices in telecommunications network 902 directly or indirectly. As one specific example, a core network node 108 may transmit a particular message to a UE 912 by transmitting the messageto an access network node 910 that will then transmit the message to the intended UE 912. Similarly, a core network node 108 may receive a particular message from a UE 912 by receiving the message from an access network node 910 that itself received the message from the UE 912.

[0007] In the depicted example, the core network 906 connects elements of the access network 904 (e.g., one or more of the network nodes 910) to one or more host computing systems, such as host 916. 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 906 includes one or more core network nodes (e.g., core network node 908) of various types, one or more of which may be generally referred to as network nodes 908. Network nodes 908 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 908. 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).

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

[0009] As a whole, the communication system 900 of Figure 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 900 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 900 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 900 supporting different standards, protocols, or rule sets.

[0010] As one example, in certain embodiments, access network 904 may contain some access network nodes 910 that support 3GPP radio access technologies (RAT), such as LTE or NR, while other access network nodes 910 support (or the same access network nodes 910 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network 902 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.

[0011] Telecommunications network 902 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network 902. For example, the telecommunications network 902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

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

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

[0014] As another example, the hub 914 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 914 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 914 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 914 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 914 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0015] The hub 914 may have a constant / persistent or intermittent connection to the network node 910B. The hub 914 may also allow for a different communication scheme and / or schedule between the hub 914 and UEs (e.g., UE 912C and / or 912D), and between the hub 914 and the core network 906. In other examples, the hub 914 is connected to the core network 906 and / or one or more UEs via a wired connection. Moreover, the hub 914 may be configured to connect to an M2M service provider over the access network 904 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 910 while still connected via the hub 914 via a wired or wireless connection. In some embodiments, the hub 914 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 910B. In other embodiments, the hub 914 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 910B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0016] Figure 10 is another example of a communication system 1000 according to some embodiments. As used herein, the communication system 1000 includes multiple access points (APs) 1010 (with four exemplary APs 1010A, 1010B, 1010C, and 1010D being depicted) and multiple wireless devices, referred to in the context of communication system 1000 as stations(STAs) 1012 (referred to individually as STA 1012A, STA 1012B, STA 1012C, STA 1012D, and STA 1012E). STA 1012Ais served by AP lOlOAin a first basic service set(BSS) 1020 A. STA 1010B and STA 1010C are served by AP 1010B in a second BSS, BSS 1020B. STA 1012D is served by AP 1010C in a third BSS, BSS 1020C. STA 1012E is served by AP 1010D in a fourth BSS, BSS 1020D. Stations 1012 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 1012 could, for example, correspond to other kinds of equipment like smart home devices, printers, multimedia devices, data storage devices, or the like.

[0017] Each of STAs 1012 may connect through a radio link to one of APs 1010. For example, depending on location or channel conditions experienced by a given STA 1012, 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.

[0018] Each AP 1010 may provide data connectivity to STAs 1012 connected to a particular AP 1010. As illustrated, APs 1010 may be connected to a data network 1030. In this way, APs 1010 may also provide data connectivity between STAs 1012 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 1012 and its serving AP 1010 may be used for providing various kinds of services to STA 1012, e.g., a voice service, a multimedia service, or other data service. Such services may be based on applications that are executed on STA 1012 and / or on a device linked to STA 1012. By way of example, Figure 10 illustrates an application service platform 1032 provided in data network 1030. The application(s) executed on STA 1012 and / or on one or more other devices linked to STA 1012 may use the radio link for data communication with one or more other STA 1012 and / or the application service platform 1032, thereby enabling utilization of the corresponding service(s) at STA 1012.

[0019] Figure 11 shows a wireless device 1100, which may be configured to operate in communication system 900 of Figure 9 or in communication system 1000 of Figure 100. The wireless device 1100 may be alternatively referred to as a UE 1100, like a UE 912 within the context of communication system 900, or as a station (STA) 1100 or as a non-access-point station (non-AP STA) 1100, like a STA 1012 within the context of the communication system1000, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptopmounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0020] A wireless device 1100 may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, wireless device 1100 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device 1100 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 1100 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).

[0021] In particular embodiments, wireless device 1100 includes processing circuitry 1102 that is operatively coupled via a bus 1104 to an input / output interface 1106, a power source 1108, a memory 1110, a communication interface 1112, and / or any other component, or any combination thereof. Certain embodiments of wireless device 1100 may include all or a subset of the components shown in Figure 11. The level of integration between the components may vary from one embodiment of wireless device 1100 to another. In general, in a particular embodiment of wireless device 1100, processing circuitry 1102, input / output interface 1106, power source 1108, memory 1110, and communication interface 1112 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 1100. Further, certain embodiments of wireless devices 1100 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0022] The processing circuitry 1102 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 1110. The processing circuitry 1102 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 1102 may include multiple central processing units (CPUs).

[0023] In the example, the input / output interface 1106 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 1100. 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.

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

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

[0026] The memory 1110 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 1110 may allow wireless device 1100 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 1110, which may be or comprise a device-readable storage medium.

[0027] The processing circuitry 1102 may be configured to communicate with an access network or other network via or using the communication interface 1112. The communication interface 1112 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1122. The communication interface 1112 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another wireless device or a network node in an access network). Each transceiver may include a transmitter 1118 and / or a receiver 1120 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1118 and receiver 1120 may be coupled to one or more antennas (e.g., antenna 1122) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0028] In the illustrated embodiment, communication functions of the communication interface 1112 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 / intemet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0029] In particular embodiments, wireless device 1100 may provide an output of data captured via a sensor, through its communication interface 1112, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device 1100 can be communicated through a wireless connection to a network node via another wireless device 1100. 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).

[0030] As another example, wireless device 1100 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 1100 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.

[0031] Wireless device 1100, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT 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, aconnected 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 1100 represents an loT device that comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the example embodiment of wireless device 1100 shown in Figure 11.

[0032] As yet another specific example, in an loT scenario, wireless device 1100 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 1100 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 1100 may implement the 3GPP NB-IoT standard. In other scenarios, wireless device 1100 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.

[0033] In practice, any number of wireless devices 1100 may be used together with respect to a single use case. For example, a first wireless device 1100 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 1100 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device 1100 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 1100 can also include more than one of the functionalities described above. For example, wireless device 1100 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0034] Figure 12 shows a network node 1200 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 1200 may be configured to operate in communication system 900 of Figure 9, like network nodes 908 or 910, or in communication system 1000 of Figure 10, like an AP 1010 or a station1012. 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)), 0-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0035] Network nodes 1200 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 1200 may be a relay node or a relay donor node controlling a relay. Network nodes 1200 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).

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

[0037] In particular embodiments, network node 1200 includes a processing circuitry 1202, a memory 1204, a communication interface 1206, and a power source 1208. In general, in a particular embodiment of network node 1200, processing circuitry 1202, memory 1204, communication interface 1206, and power source 1208 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 1200.

[0038] The network node 1200 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 1200 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 1200may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memories 1204 or portions of memory 1204 for different RATs) and some components may be reused (e.g., a same antenna 1210 may be shared by different RATs). The network node 1200 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1200, 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 1200.

[0039] The processing circuitry 1202 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 1204, to provide network node 1200 functionality.

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

[0041] The memory 1204 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1202. The memory 1204 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 1202 and utilized by the network node 1200. The memory 1204 may be used to store any calculations made by the processing circuitry 1202 and / or any data received via thecommunication interface 1206. In some embodiments, the processing circuitry 1202 and memory 1204 is integrated.

[0042] The communication interface 1206 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 1206 comprises port(s) / terminal(s) 1216 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node 1100 may be capable of wireless communication and communication interface 1206 may also include radio front-end circuitry 1218 that may be coupled to, or in certain embodiments a part of, an antenna 1210. Particular embodiments of radio front-end circuitry 1218 include filter(s) 1220 and amplifier(s) 1222. The radio front-end circuitry 1218 may be connected to an antenna 1210 and processing circuitry 1202. The radio front-end circuitry may be configured to condition signals communicated between antenna 1210 and processing circuitry 1202. The radio front-end circuitry 1218 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio frontend circuitry 1218 may convert the digital data into a radio signal(s) having the appropriate channel and bandwidth parameters using a combination of filters 1220 and / or amplifiers 1222. The radio signal(s) may then be transmitted via the antenna 1210. Similarly, when receiving data, the antenna 1210 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1218. The digital data may be passed to the processing circuitry 1202. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0043] In certain alternative embodiments, network node 1200 may be capable of wireless communication but does not include separate radio front-end circuitry 1218, instead, the processing circuitry 1202 includes radio front-end circuitry and is connected to the antenna 1210. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1212 is part of the communication interface 1206. In still other embodiments, the communication interface 1206 includes one or more ports or terminals 1216, the radio front-end circuitry 1218, and the RF transceiver circuitry 1212, as part of a radio unit (not shown), and the communication interface 1206 communicates with the baseband processing circuitry 1214, which is part of a digital unit (not shown).

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

[0045] The antenna 1210, communication interface 1206, and / or the processing circuitry 1202 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 1200. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1210, the communication interface 1206, and / or the processing circuitry 1202 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node 1200. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0046] The power source 1208 provides power to the various components of network node 1200 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1208 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1200 with power for performing the functionality described herein. For example, the network node 1200 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 1208. As a further example, the power source 1208 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.

[0047] Embodiments of the network node 1200 may include additional components beyond those shown in Figure 12 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 1200 may include user interface equipment to allow input of information into the network node 1200 and to allow output of information from the network node 1200. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1200.

[0048] Figure 13 is a block diagram illustrating a virtualization environment 1300 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 relatesto 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 1300 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 1300 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

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

[0050] Hardware 1304 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 1306 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VM 1308A and VM 1308B (which may be collectively referred to as VMs 1308), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1306 may present a virtual operating platform that appears like networking hardware to one or more of the VMs 1308.

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

[0052] In the context of NFV, each of the VMs 1308 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1308, and that part of hardware 1304 that executes that VM, be ithardware 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 ofNFV, a virtual network function is responsible for handling specific network functions that run in one or more of the VMs 1308 on top of the hardware 1304 and corresponds to an application 1302.

[0053] Hardware 1304 may be implemented in a standalone network node with generic or specific components. Hardware 1304 may implement some functions via virtualization. Alternatively, hardware 1304 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 1310, which, among others, oversees lifecycle management of applications 1302. In some embodiments, hardware 1304 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 1312 which may alternatively be used for communication between hardware nodes and radio units.

[0054] 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 intensivefunctions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0055] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.Numbered embodimentsAl. A method performed in an O-RAN O-RU for providing a positioning measurement, the O-RU being connected to an O-RAN O-DU over a fronthaul interface, the method comprising the steps ofreceiving, from the O-DU, a request to perform a positioning measurement on a reference signal from a UE,receiving the reference signal from the UEperforming the requested measurement on the reference signal andtransmitting a result of the measurement to the O-DU over the fronthaul interface.A2. A method performed in an O-RAN O-DU for requesting a positioning measurement, the O-DU being connected to an O-RAN O-RU over a fronthaul interface, the method comprising the steps ofTransmitting, to the O-RU, a request to perform a positioning measurement on a reference signal from a UE andreceiving a result of the measurement from the O-RU over the fronthaul interface.A3. A method according to embodiment Al or A2 wherein the reference signal is a Demodulation Reference Signal, DMRS.A4. A method according to embodiment Al or A2 wherein the reference signal is a Sounding Reference Signal, SRS.A5. A method according to embodiment Al or A2 wherein the request to perform a positioning measurement indicates if the measurement is to be performed on SRS or DMRS. A6. A method according to embodiment A3 wherein the request identifies a PUSCH DMRS configuration.A7. A method according to embodiment A4 wherein the request identifies an SRS configuration.A8. A method according to any of the preceding numbered embodiments when dependent on embodiment Al, or dependent on numbered embodiment A2, or a method not dependent on any other embodiment, wherein a measurement result is transmitted from an O-RU to an O-DU or received by an O-DU from an O-RU in a section type 10 and the section comprises an indication of whether measurement was performed on SRS or on DMRS.A9. A method according to embodiment 8 wherein the indication is present in the section type 10 header.A10. A method according to any of the preceding numbered embodiments wherein the measurement result comprises an indication of any of an azimuth angle of arrival, a zenith angle of arrival and a time of arrival.Al 1. A Method according to any of the preceding numbered embodiments wherein the measurement result comprises an indication of measurement quality.A12. A method according to any of the preceding numbered embodiments wherein the measurement result comprises indications of any of an azimuth angle of arrival, a zenith angle of arrival, a time of arrival and measurement quality for each of a plurality of multipath components of the radio channel from the UE to the O-RU.Al 3. A method according to any of the preceding numbered embodiments wherein the request is transmitted or received of either O-RAN control plane, C-plane or O-RAN management plane, M-plane.A14. A request according to any of the preceding numbered embodiments when dependent on embodiment A3 wherein the request is contained in a C-Plane section of Section Type 5 with Section Extension 24 and wherein at least one bit indicates that positioning measurement is to be performed and wherein the use of ST5 and SE24 indicates that measurement is to be made on DMRSAl 5. A request according to any of the preceding numbered embodiments when dependent on embodiment 2 wherein the request is contained in a section of the Section Type as described in patent application PCT / SE2024 / 051026 and indicates that the measurement is to be performed on SRS.Al 6. A method according to embodiment Al 5 wherein at least one bit of the section indicates that positioning measurement is to be performed.A17. A method according to any preceding numbered embodiment when dependent on embodiment A2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to the UE being scheduled to transmit uplink data.Al 8. A method according to any preceding numbered embodiment when dependent on embodiment A2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to the time passed since a previous measurement on SRS and / or the time remaining until a next SRS is to be transmitted from the UE.Al 9. A method according to any preceding numbered embodiment when dependent on embodiment A2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to a shortage of SRS resources on the air interface between the UE and the O-RU.A20. A method according to any preceding numbered embodiment when dependent on embodiment A2 wherein the O-DU selects to request positioning measurement(s) for a UE on SRS in response to the UE being scheduled for SRS transmission or free SRS resources being available on the air interface between the UE and the O-RU.A21. A method according to any preceding numbered embodiment wherein any kind of 3 GPP RU is used instead of an O-RAN O-RU and / or any kind of 3 GPP DU is used instead of an O-RAN O-DU.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.In 3 GPP, 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.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).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 pay load 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 descriptionis 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.The SRS configuration description structure can be included a new Section Type or a new Section Extension.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.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.Certain aspects of the disclosure may provide, inter aha, one or more of the following advantages.• 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.• 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.• 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.• ADDITIONAL EXPLANATION• 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.• Example of SRS configuration descriptionFigure 14 (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.The following provides an example of the SRS configuration description structure for the SRS configuration example shown in Figure 6, providing 5 levels information regarding SRS configuration for all UE SRS ports in a slot in an efficient and well-structured way.• Common level SRS configuration description-numSrsSymbols = 2-numSrsClusters = 2-PRB cluster definition• Definition of PRB cluster 0- srsClusterld = 0- startPrbOfCluster = 0- numPrbOfCluster = 136• Definition of cluster 1- srsClusterld = 1- startPrbOfCluster = 136- numPrbOfCluster = 136• Symbol level SRS configuration description-First symbol• symbolld = 10• numSrsUesOfSymbol = 4• srsCombNum = 4• PRB cluster level for first symbolFirst PRB cluster• srsClusterld = 0• srsGroupSeqHopping = 'groupHopping'• UE level for first cluster in first symbol• UE specific parameters for first UE.• SRS port level for first UE• SRS port specific parameters for first SRS port of UE 0• SRS port specific parameters for second SRS port of UE O• UE specific parameters for second UE.• SRS port level for second UE• SRS port specific parameters for first SRS port of UE 1• SRS port specific parameters for second SRS port of UE 1- Second PRB cluster• srsClusterld = 1• srsGroupSeqHopping = 'groupHopping'• UE level for second cluster in first symbol• UE specific parameters for first UE.• SRS port level for first UE• SRS port specific parameters for first SRS port of UE 2• SRS port specific parameters for second SRS port of UE 2• UE specific parameters for second UE.• SRS port level for second UE• SRS port specific parameters for first SRS port of UE 3• SRS port specific parameters for second SRS port of UE 3-Second symbol• symbolld = 11• numSrsUesOfSymbol = 4• srsCombNum = 4• PRB cluster level for second symbol- First PRB cluster• srsClusterld = 0• srsGroupSeqHopping = 'groupHopping'• UE level for first cluster in second symbol• UE specific parameters for first UE.• SRS port level for first UE• SRS port specific parameters for first SRS port of UE 2• SRS port specific parameters for second SRS port of UE2• UE specific parameters for second UE.• SRS port level for second UE• SRS port specific parameters for first SRS port of UE3• SRS port specific parameters for second SRS port of UE 3- Second PRB cluster• srsClusterld = 1• srsGroupSeqHopping = 'groupHopping'• UE level for second cluster in second symbol • UE specific parameters for first UE.• SRS port level for first UE• SRS port specific parameters for first SRS port of UE O• SRS port specific parameters for second SRS port of UE O• UE specific parameters for second UE.• SRS port level for second UE• SRS port specific parameters for first SRS port of UE 1• SRS port specific parameters for second SRS port of UE 1The following lists an example of UE specific parameters for any UE. This is an example, which doesn’t exclude the possibility to add other UE specific parameters.• UE specific parameters for any UE-numSrsPortsOfUe-ueCapId-srsUeldReset-srsUeld-srsSequenceldThe 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.• SRS port specific parameters-srsUePortld-srsCyclicShift-srsCombOffsetExample of new Section Type for SRS configuration descriptionIn 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.In this document, we focus on Table 1 shows the format of Section Type ZZ defined for the SRS configuration description described in this disclosure. Table 2, Table 3, Table 4 and Table 5 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.Table Al SRS configuration description format (Section Type ZZ)"Table A2 Symbol level SRS configuration description formatTable A3 PRB cluster level SRS configuration description formatTable A4 UE level SRS configuration description formatTable A5 SRS port level SRS configuration description formatList of parameter fields in exemplified Section Type ZZ designThe following lists the definitions of all parameter fields used in the section description of Section Type ZZ, shown in Table 1 to Table 5.• 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.• 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.• srsOnUISIot: a one-bit flag indicates if SRS is in a UL slot or not. If SRS is in a special slot, srsOnUISIot = 0. If SRS is in a UL slot, srsOnUISIot = 1.• 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.• 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.• numSrsSymbols: the total number of SRS symbols in the slot.numSrsClusters: the total number of SRS PRB clusters in the slot. srsClusterld: an identification value assigned to a PRB cluster. For example, srsClusterld = 0 for the first PRB cluster with lowest SRS frequency PRB.• 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.• startPrbOfCluster: the PRB index of the first (lowest frequency) PRB of the referred SRS PRB cluster in a symbol.• numPrbOfCluster: the number of PRBs of the referred SRS PRB cluster in a symbol.• 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.• numSrsUesOfSymbol: the total number of UEs sending SRS in the referred symbol.• srsCombNum: Comb number for SRS used for all SRS in the referred symbol.Comb number indicates the subcarrier separation between two adjust subcarriers allocated for the SRS, as defined in 3GPP.• srsGroupSeqHopping: a value indicates the type of SRS symbol hopping used.There are several types, e.g., ‘neither’, ‘groupHopping’, or ‘sequenceHopping’ etc., as defined in 3GPP.• numSrsPortsOfUe: the number of SRS ports of the referred UE in the referred SRS resource identified by a srsClusterld and a symbolld.• 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.• srsUeld: an identification value assigned to a UE that sends SRS.• srsUeldReset: a one-bit flag indicates if the srsUeld assignment to a UE is changed. 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.• srsSeqld: SRS sequence identity value used to generate SRS sequence, as defined in 3GPP.srsUePortld: an identification value assigned to a UE SRS antenna port. srsCyclicShift: cyclic shift offset value indicates the cyclic shift applied to the SRS sequence for a UE SRS antenna port, as defined in 3GPP.srsCombOffset: comb offset value indicates a frequency offset within the comb used for a UE SRS antenna port, as defined in 3GPP.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 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 15 (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.Figure 16 (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 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.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.to be submitted< >& < >< >v1 : original CR< Change 1>7.4.12 Section Type 10 elementsSection Type 10 is used for sending RRM measurement reports from O-RU to O-DU; see Table7.4.12-1:• Common Header Fields:dataDirection (data direction (gNB Tx / Rx)) field: 1 bit.value = 0 (uplink) shall be usedpayloadVersion (payload version) field: 3 bits:value = 1 shall be set (1stprotocol version for payload and time reference format).reserved (reserved for future use) field: 4 bits.frameld (frame identifier) field: 8 bits.subframeld (subframe identifier) field: 4 bits.slotID (slot identifier) field: 6 bits.startSymbolId (start symbol id) field: 6 bits.numberOfsections (number of sections) field: 8 bits.sectionType (Section Type) field: 8 bits:value = 10 shall be set.reserved (reserved for future use) field: 16 bits.Section Fields:sectionld (section identifier) field: 12 bits.rb (resource block identifier) field: 1 bit.reserved (reserved for future use) field: 1 bit.startPrbc (starting PRB of data section description) field: 10 bits.numPrbc (number of contiguous PRBs per data section description) field: 8 bits.reMask (resource element mask) field: 12 bits.numSymbol (number of symbols) field: 4 bits.ef (extension flag) field: 1 bit.ueld (UE identifier) field: 15 bits.Section extensions (optional, supported Section Extensions described in clause 9.2.1) Measurement report structure (at least one report, additional reports indicated by 'mf' flag)mf (measurement flag) field: 1 bit.measTypeld (measurement type identifier) field: 7 bits.Different RRM measurements are indicated by different measTypeld values. More details are described in the following subclauses.measDataSize (measurement data size) field: 16 bits.Measurement data report field: variable size.The structure and format depend on the measTypeld value which indicates what RRM measurement is reported in the measDataReport. More details are described in the following subclauses.measTypeld = 1 shall be set for measTypeld: MEAS UE TAE; see Table 7.4.12-2 measTypeld (MEAS_UE_TAE measurement type): 8 bitsreserved: 8 bitsmeasDataSize (length of measurement report): 16 bitsueTae (UE-TAE measurement value): 16 bitsreserved: 16 bitsUnchanged parts omitted...measTypeld = 7 shall be set for measTypeld: MEAS UE POS; see Table 7.4.12-x measTypeld (MEAS_UE_POS measurement type): 7 bitsreserved: 8 bitsmeasDataSize (length of measurement report): 16 bitsueAzAoa (UE azimuth angle of arrival): 16 bitsreserved: 16 bitsueZeAoa (UE zenith angle of arrival): 16 bitsreserved: 16 bitsueToaOffset (UE time of arrival offset): 16 bitsreserved: 16 bitsTable 7.4.12-1: RRM measurement reports (Section Type 10)< " "< " "Table 7.4.12-2: UE Timing Advance Error measurement report (measTypeld = 1)Unchanged parts omitted...Table 7.4.12-x: UE positioning measurement report (measTypeld = 7)< Change 2>7.5.3.58 measTypeld (measurement report type identifier)Description: This parameter shall be used specifically with Section Type 10 or Section Type 11 to specify the type of measurement report (ST 10) or measurement command (ST 11). Support for a given measTypeld in ST 10 and ST 11 respectively is indicated in the table below. SectionType 10 shall contain at least one measurement report, and it is possible to append multiplereports of different type. Section Type 11 shall contain at least one measurement command and supports appending multiple commands.Value range: {0000000b -111 1111b}Table 7.5.3.58-1: measTypeld definitions and applicable Section TypesType: unsigned integerField length: 7 bitsDefault Value: n / a< Change 3>7.5.3.xx ueAzAoa (UE azimuth angle of arrival)Description: This parameter is part of the UE positioning measurement. It provides value of UE azimuth angle of arrival (AoA) in degrees with resolution of 0.1 degree. Azimuth angle is relative to antenna boresight and counted with positive values counterclockwise (see clause 12.5.2 for azimuth angle definition), based on Local Coordinate System specified in 3GPP TR 38.901

[0043] , clause 7.1.Value range: {0x0000 (0) - OxOEOF (3599): azimuth angle of arrival (0.0 - 359.9 degrees)OxFFFF (65535): invalid measurement resultOther values: reserved}.Type: unsigned integer.Field length: 16 bits.Default Value: N / A7.5.3.yy ueZeAoa (UE zenith angle of arrival)Description: This parameter is part of the UE positioning measurement. It provides value of UE zenith angle of arrival in degrees with resolution of 0.1 degree. Zenith angle is defined such that 0 degrees points to zenith and 90 degree points to horizon (see clause 12.5.2 for zenith angle definition), based on Local Coordinate System specified in 3GPP TR 38.901

[0043] , clause 7.1. Value range: {0x0000 (0) - 0x0708 (1800): zenith angle of arrival (0.0 - 180.0 degrees)OxFFFF (65535): invalid measurement result Other values: reserved}.Type: unsigned integer.Field length: 16 bits.Default Value: N / A7.5.3.zz ueToaOffset (UE time of arrival offset)Description: This parameter is part of the UE positioning measurement. It provides value of UE time of arrival (ToA) offset. See clause 9.2.2.Z for information about the measurement. The measurement unit is nanoseconds, with a resolution of 21-x Tc, where Tc= (480 kHz x 4096)-1« 0.509 ns and / z represents the subcarrier spacing configuration. This gives an effective time resolution of (30 kHz / SCS) x Tc. The range of the reported value is[— 215+ 1, 215— l] / 216symbol duration, i.e. an open interval of ± 0.5 symbol duration (excluding cyclic prefix).Value range: {0x0000 (0): no UE ToA offset, 0 symbols0x0001 (+1 ) - 0x7FFF (+32767): positive UE ToA offset in the range 2-16x [1, 215— 1] symbols0x8001 (-32767) - OxFFFF (-1): negative UE ToA offset in the range 2-16x [— 215+ 1, —1] symbols0x8000 (-32768):invalid measurement result}Type: signed integerField length: 16 bitsDefault Value: N / A< Change 4>7.7.24 SE 24: PUSCH DMRS configuration7.7.24.1 OverviewThe Section Extension 24 is used with Section Type 5 to convey PUSCH DMRS configuration used for DMRS-BF-EQ and DMRS-BF-NEQ beamforming methods. The principles of providing DMRS configuration in Section Type 5 are specified in clause 12.6.1.3.1.The Section Extension 24 consists of a header conveying parameters extType, extLen, alpnPerSym (allocated IPN per symbol, see clause 7.7.24.4), antDmrsSnr (antenna DMRS SNR, see clause 7.7.24.5), userGroupSize (see clause 7.7.24.6) and userGroupId (see clause 7.7.24.7) and a variable size table of DMRS configurations (see clause 7.7.24.3). The table is followed by a padding of 0 to 3 bytes to align the size of the Section Extension with 4-byte boundary; the padding length shall be 0 if the table ends at 4-byte boundary. The header of Section Extension 24 is presented in Table 7.7.24.1-1. Table 7.7.24.1-2 shows an example of Section Extension 24 structure.Table 7.7.24.1-1: Section Extension 24 Header 0 (msb) 1 2 3 4 5 6 7 (Isb) #of Octet bytesTable 7.7.24.1-2: Section Extension 24 Example< Change 5>7.7.24.3 Table of DMRS configurationsThe table of DMRS configurations conveys parameters describing PUSCH DMRS configuration for one or more UE data layers. There shall be exactly one entry in the table for each ueld value associated with UE data layer that is included in the section description in which the Section Extension 24 is present. The entries of the table shall be mapped to ueld values in order of occurrence of ueld values in the section description (that is, the ueld value in the Section Type 5 section description followed by ueld values in Section Extension 10 if present). There shall be no entry in the table which is not associated with a ueld value. There shall be no entry in the table associated with a ueld value not associated with UE data layer (i.e. value 0x7FFF). The number of entries in the table shall not exceed the maximum supported number of UE data layers per user group (see clause 7.7.24.1). Clause 12.6.1.3.1 defines further requirements for providing DMRS configuration with Section Type 5.An entry in table of DMRS configurations can convey different set of parameters depending on the type of the entry conveyed in the parameter entryType:• An entry with entryType = 0 is used for UE data layers that inherit the configuration from the last preceding entry with entryType = 2 or 3 in the same SE 24 instance, and to implicitly convey ueldReset = 0.• An entry with entryType = 1 is used for UE data layers that inherit the configuration from the last preceding entry with entryType = 2 or 3 in the same SE 24 instance, and to implicitly convey ueldReset = 1.• An entry with entryType = 2 is used for UE data layers that have transform precoding disabled and conveys related parameters.• An entry with entryType = 3 is used for UE data layers that have transform precoding enabled and conveys related parameters.If entryType = 0 or 1 , then the parameter dmrsPortNumber shall be provided in the entry. In this case, for the UE data layer associated with the entry, the O-RU shall use the dmrsPortNumber provided in the entry and all other parameters (excluding ueldReset) provided in the last preceding entry that has either entryType = 2 or 3. This also means the O-RU shall assume transform precoding is disabled or enabled based on the entryType of the last preceding entry. While the parameter ueldReset is not present in the entry with entryType = 0 or 1 , the value of the ueldReset is conveyed implicitly and the O-RU shall assume ueldReset = 0 for entryType = 0 and ueldReset = 1 for entryType = 1 (see clause 7.7.24.10 for definition of ueldReset).When the O-RU does not indicate support for ueld persistence over multiple slots (M-Plane feature UEID-PERSISTENCE), the O-DU shall set ueldReset = 1 , and shall not send entries with entryType = 0.The first entry in the table shall not have entryType = 0 or 1.Table 7.7.24.3-1 shows the structure of the entry with entryType = 0 and entryType = 1.Table 7.7.24.3-1: Format of entry with entryType = 0 and entryType = 10 (msb) 1 2 3 4 5 6 7 (Isb) #of Octet bytesIf entryType = 2, then the parameters: dmrsPortNumber, ueldReset, posMeas, dmrsSymbolMask, scrambling, nscid, dType, cdmWithoutData, lambda, lastPrb and firstPrb shall be provided in the entry. In this case, for the UE data layer associated with the entry O-RU shall use the dmrsPortNumber and the additional parameters provided in the entry for DMRS-BF and assume that the transform precoding is disabled (see 3GPP TS 38.211v17.6

[0055] for details on DMRS signal generation when transform precoding is disabled). Table 7.7.24.3-2 shows the structure of the entry with entryType = 2. When transform precoding is disabled, the generation and mapping of DMRS sequence values to the allocated RBs for a UE data layer uses Point A (the first subcarrier of the first CRB on the CRB grid, see clause 4.4.4.23GPP TS 38.211v17.6

[0055] ) as a reference. When the O-RU supports M-Plane parameter point-a-offset-to-absolute-frequency-center then the O-DU may configure this M-Plane parameter to indicate the offset between centre frequency of channel bandwidth (given in M-Plane parameter center-of-channel-bandwidth) and Point A. For generation and mapping of DMRS sequence values to allocated RBs of a UE data layer for transform precoding disabled, the O-RU shall use the value of point-a-offset-to-absolute-frequency-center (expressed in steps of half of a reference SCS: 15 kHz for FR1 and 60 kHz for FR2) together with the value of the M-Plane parameter offset-to-absolute-frequency-center (expressed in steps of half of the SCS configured for a given endpoint) to determine the offset in number of RBs between Point A and RE #0 of PRB #0 indicated by offset-to-absolute-frequency-center. If the parameter point-a-offset-to-absolute-frequency-center is not configured, then the O-RU shall assume Point A coincides with the RE #0 of PRB #0 indicated by M-Plane parameter offset-to-absolute-frequency-center.Table 7.7.24.3-2: Format of entry with entryType=2 0 (msb) 1 2 3 4 5 6 7 (Isb) #of Octet bytesIf entryType = 3 then the parameters: dmrsPortNumber, ueldReset, posMeas, dmrsSymbolMask, scrambling, nscid, lowPaprType, hoppingMode, lastPrb and firstPrb shall be provided in the entry. In this case, for the UE data layer associated with the entry O-RU shall use thedmrsPortNumber and the additional parameters provided in the entry for DMRS-BF and assume that the transform precoding is enabled (see 3GPPTS 38.211v17.6

[0055] for details on DMRS signal generation when transform precoding is enabled). The O-RU shall assume that dType = 0 and cdmWithoutData = 2. Table 7.7.24.3-3 shows the structure of the entry with entryType = 3.Table 7.7.24.3-3: Format of entry with entryType=3 0 (msb) 1 2 3 4 5 6 7 (Isb) #of Octet bytes< Change 6>7.7.24.y posMeas (Positioning measurement report request)Description: This parameter is provided per entry in Section Extension 24 when RRM measurement MEAS_UE_POS (UE positioning measurement, see clause 9.2.2.Z) is enabled via M-Plane. If the measurement is not enabled, the O-DU shall set it to 0 and the O-RU shall ignore it. This parameter indicates if MEAS_UE_POS shall be reported by the O-RU for the UE described by the entry in SE 24 in which this parameter appears. Further details on the MEAS_UE_POS reporting and related capabilities are provided in clause 9.2.2.Z.• If posMeas = 0, then the O-RU shall not report the MEAS_UE_POS for the UE described.• If posMeas = 1, then the O-RU shall report the MEAS_UE_POS for the UE described. Value range: 0- 1.Type: unsigned integer.Field length: 1 bit.Default Value: Ob (UE positioning measurement is not requested).< Change 7>9.2 RRM measurements9.2.1 OverviewSection Type 10 C-Plane message is used to send Radio Resource Management (RRM) measurement reports from the O-RU to the O-DU. The main purpose is for DMRS-BF, see clause 12.6. Measurements based on DMRS (UE timing advance error, UE layer signal power, UE frequency offset, interference plus noise for allocated PRBs, DMRS SNR per antenna, and UE positioning measurement) can only be supported by O-RUs supporting SE 24, which describes the DMRS configuration and triggers DMRS-based measurements. Measurement of interference plus noise for unallocated PRBs is an exception since it does not require knowledge of DMRS and can thus be used without SE 24 (and without DMRS-BF). Section Type 10 supports Section Extensions and has a flexible structure that can be extended with new RRM measurement types. Using Section Extensions is optional but at least one measurement report shall be included in each ST 10. Measurement reports come after any Section Extensions and have a format resembling Section Extensions.The O-RU declares support for different RRM measurements, and the O-DU enables desired measurements as described in clause 9.2.3. Certain measurements are mandatory to support depending on DMRS-BF type, see also clause 10.2. O-RU support for a measurement means ability to receive and process a C-Plane message requesting the measurement (where applicable), performing the measurement, and sending an ST 10 measurement report to the O-DU. O-DU support for a measurement means that the O-DU may request a measurement (where applicable) and can receive ST 10 messages containing the measurement. There is no specific requirement governing how an O-DU uses a supported measurement or if it uses a supported measurement at all.The measurement types are listed in Table 9.2.1-1 and described in more detail in clause 9.2.2. All configured RRM measurements for DMRS-BF that are triggered by Section Extension 24 shall, unless explicitly stated, be provided in every slot that uses DMRS-BF (in any PRBs). In general, the measurement reports follow a Type, Length, Value scheme.Table 9.2.1 -1: RRM measurement types< Change 8>9.2.2.Z MEAS_UE_POS (UE Positioning Measurement)UE Positioning Measurement includes two UE angle of arrival (AoA) measurements (i.e., azimuth AoAand zenith AoA) and one UE time of arrival (ToA) offset measurement, which are measured on PUSCH DM RS for each UE and are reported when requested by the O-DU via setting posMeas to 1 in SE 24. All three measurements are defined at the antenna reference point. NOTE: Since the measurements are defined at the antenna reference point, the O-RU is expected to, when necessary, compensate the measurement result to mitigate impact of any processing (e.g. O-RU internal dimension reduction) between the antenna reference point and the point where the O-RU performs the measurement. When O-DU controlled dimensionality reduction with SE 27 is used then the O-RU reports RRM measurement as affected by the dimensionality reduction (without compensation) and the O-DU accommodates effects of the dimensionality reduction if necessary. UE azimuth AoA is reported with one azimuth AoA value per UE per slot, which is in unit of degree, with resolution of 0.1 degrees. The measurement value is mapped to an unsigned 16-bit integer and the supported range is 0.0 to 359.9 degree. See parameter ueAzAoa in clause 7.5.3. xx on the data format.UE zenith AoA is reported with one zenith AoA value per UE per slot, which is in unit of degree, with resolution of 0.1 degrees. The measurement value is mapped to an unsigned 16-bit integer and the supported range is 0.0 to 180.0 degrees. See parameter ueZeAoa in clause 7.5.3.yy for more information on the data format.UE ToA offset is reported with one ToA offset value per UE per slot. The UEToA offset is defined relative to the UL frame timing at the antenna reference point and represents the offset between the UL frame timing and UE ToA estimated. A positive UE ToA offset means that the UEToA is later than UL frame timing while a negative UEToA offset means that the UE ToA is earlier than UL frame timing. The reported ToA offset value is mapped to a signed 16-bit integer where one integer step represents a time resolution of (30 kHz / SCS) x Tc, where Tc= (480 kHz x 4096)-1« 0.509 ns is defined in 3GPP TS 38.211 [4] clause 4.1. Measurement range: ± 0.5 OFDM symbol (excluding cyclic prefix) for the used subcarrier spacing. See parameter ueToaOffset in clause 7.5.3.zz for more information on the data format.The ueld in the Section Type 10 header indicates which UE the measurement refers to. The measurement report may be sent with the eAxCJD and ueld associated with any layer of the UE (any value of layer-number part of the ueld). The report will contain only one set of measurement results even if the UE has multiple scheduled layers or if the UE is scheduled in multiple user groups (in different PRB or symbol ranges).< Change 9>9.2.3 RRM measurement support declaration and enablement via M-Plane The O-RU declares supported RRM measurements via M-Plane capability reporting and the O-DU will configure which RRM measurements to use via M-Plane configuration. Capabilities are declared per endpoint-type while configuration is made per endpoint, see also respective subclauses of clause 9.2.2 regarding additional restrictions as well as any measurementspecific capabilities and configurations. Mandatory RRM measurements shall be supported by all applicable endpoints.M-Plane capability reporting of supported RRM measurements per end point-type: list rrm-meas-supportedM-Plane configuration to enable RRM measurements per RX end point: list rrm-meas- enabledThe following capability and enablement configuration restrictions are applicable for the different RRM measurements:• MEAS UE TAE (M-Plane list value: MEAS-UE-TAE)Shall be supported by all RX endpoints supporting DMRS-BF-EQ.Shall be supported by all RX endpoints supporting DMRS-BF-NEQ unless O-RU declares support for feature DMRS-BF-NEQ-UNALTERED-TAE.• MEAS UE LAYER POWER (M-Plane list value: MEAS-UE-LAYER-POWER) Shall be supported by all RX endpoints supporting DMRS-BF-EQ.Shall be supported by all RX endpoints supporting DMRS-BF-NEQ if any of those endpoints supports the RRM measurement.• MEAS UE FREQ OFFSET (M-Plane list value: MEAS-UE-TAE-FREQ-OFFSET) Shall be supported by all RX endpoints supporting DMRS-BF-EQ.Shall be supported by all RX endpoints supporting DMRS-BF-NEQ unless O-RU declares support for feature DMRS-BF-NEQ-UNALTERED-FREQ-OFFSET.• MEAS IPN ALLOC (M-Plane list value: MEAS-IPN-ALLOC)Shall be supported within an O-RU supporting DMRS-BF-EQ by one or more RX endpoints within that O-RU. Those endpoints supporting MEAS_IPN_ALLOC may, but need not, support DMRS-BF-EQ.May be supported within an O-RU supporting DMRS-BF-NEQ by one or more RX endpoints within that O-RU. Those endpoints supporting MEAS_IPN_ALLOC may, but need not, support DMRS-BF-NEQ.When enabled, it shall be enabled on exactly one RX endpoint (associated with an eAxC_ID) per rx-array-carrier, either on a dedicated RX endpoint for IpN (same as used for MEAS_IPN_UNALLOC if supported and enabled) or on an endpoint configured to use DMRS-BF-EQ or DMRS-BF-NEQ.• MEAS IPN UN ALLOC (M-Plane list value: MEAS-IPN-UNALLOC)Shall be supported within an O-RU supporting DMRS-BF-EQ by one or more RX endpoints within that O-RU. Those endpoints supporting MEAS_IPN_UNALLOC may, but need not support DMRS-BF-EQ.May be supported within an O-RU supporting DMRS-BF-NEQ by one or more RX endpoints within that O-RU. Those endpoints supporting MEAS_IPN_UNALLOC may, but need not, support DMRS-BF-NEQ.May be supported by some RX endpoints within an O-RU not supporting DMRS-BF, including non-beamforming O-RUs.When enabled, it shall be enabled on exactly one RX endpoint (associated with an eAxC_ID) per rx-array-carrier, which is a dedicated endpoint for IpN (see also description for MEAS_IPN_ALLOC).• MEAS ANT DMRS SNR (M-Plane list value: MEAS-ANT-DMRS-SNR)May be supported by some RX endpoints supporting DMRS-BF-EQ or DMRS-BF-NEQ. • MEAS UE POS (M-Plane list value: MEAS-UE-POS)May be supported by some RX endpoints supporting DMRS-BF-EQ or DMRS-BF-NEQ.< Change 10>10.2 Mandatory and optional capabilitiesThis clause provides details regarding which capabilities within the present document are mandatory and which are optional. The capability requirements of O-DU can be different from the O-RU because in many cases, the O-DU needs to implement multiple options as mandatory to ensure interoperability with O-RUs that have optional capabilities. For example, the ability to support many compression methods may be mandatory in the O-DU while in O-RUs there may be only a single mandatory compression method to allow simplicity in O-RU design (while vendors may enhance their O-RU product offering by implementing some of the optional compression methods).Table 10.2-1 describes the capabilities required of O-DU and O-RU units. There are three choices:Mandatory: The unit shall support the described capability to be O-RAN compliant.Conditional Mandatory: The unit shall support the described capability to be O-RAN compliant, but the additional information column describes the conditions under which the capability is mandatory.Optional: The unit need not support the capability and still be O-RAN compliant, but if the unit does support the described capability it shall support it in the way described within the present document.Table 10.2-1: O-RAN mandatory and optional featuresREFERENCES1. 0-RAN.WG4.TS.CUS.0-R004-v17.00, link:https: / / oranalliance.atlassian.net / wiki / download / attachments / 3393814677 / O- RAN.WG4.TS.CUS.0-R004-v17.00.pdf?api=v22. O-RAN technical report 0-RAN.WG4.TR-ULPI-R003-V01.003. O-RAN standards contribution (SRS-BF Work Item description) SAM-2024.09.05-WG4- WID-SRS-CE-in-O-RU

Claims

1. CLAIMS1. A method performed in an O-RAN O-RU for providing a positioning measurement, the O-RU being connected to an O-RAN O-DU over a fronthaul interface, the method comprising the steps ofreceiving, from the O-DU, a request to perform a positioning measurement on a reference signal from a UE,receiving the reference signal from the UEperforming the requested measurement on the reference signal andtransmitting a result of the measurement to the O-DU over the fronthaul interface.

2. A method performed in an O-RAN O-DU for requesting a positioning measurement, the O-DU being connected to an O-RAN O-RU over a fronthaul interface, the method comprising the steps ofTransmitting, to the O-RU, a request to perform a positioning measurement on a reference signal from a UE andreceiving a result of the measurement from the O-RU over the fronthaul interface.

3. A method according to claim 1 or 2 wherein the reference signal is a Demodulation Reference Signal, DMRS.

4. A method according to claim 1 or 2 wherein the reference signal is a Sounding Reference Signal, SRS.

5. A method according to claim 1 or 2 wherein the request to perform a positioning measurement indicates if the measurement is to be performed on SRS or DMRS.

6. A method according to claim 3 wherein the request identifies a PUSCH DMRS configuration.

7. A method according to claim 4 wherein the request identifies an SRS configuration.

8. A method according to any of the preceding claim when dependent on claim 1, or dependent on claim 2, or a method not dependent on any other claim, wherein a measurement result is transmitted from an O-RU to an O-DU or received by an O-DU from an O-RU in a section type 10 and the section comprises an indication of whether measurement was performed on SRS or on DMRS.

9. A method according to claim 8 wherein the indication is present in the section type 10 header.

10. A method according to any of the preceding claims wherein the measurement result comprises an indication of any of an azimuth angle of arrival, a zenith angle of arrival and a time of arrival.

11. A method according to any of the preceding claims wherein the measurement result comprises an indication of measurement quality.

12. A method according to any of the preceding claims wherein the measurement result comprises indications of any of an azimuth angle of arrival, a zenith angle of arrival, a time of arrival and measurement quality for each of a plurality of multipath components of the radio channel from the UE to the O-RU.

13. A method according to any of the preceding claims wherein the request is transmitted or received of either O-RAN control plane, C-plane or O-RAN management plane, M-plane.

14. A request according to any of the preceding claims when dependent on claim 3 wherein the request is contained in a C-Plane section of Section Type 5 with Section Extension 24 and wherein at least one bit indicates that positioning measurement is to be performed and wherein the use of ST5 and SE24 indicates that measurement is to be made on DMRS 15. A method according to any preceding claim when dependent on claim 2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to the UE being scheduled to transmit uplink data.

16. A method according to any preceding claim when dependent on claim 2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to a time passed since a previous measurement on SRS and / or a time remaining until a next SRS is to be transmitted from the UE.

17. A method according to any preceding claim when dependent on claim 2 wherein the O-DU selects to request positioning measurement(s) for a UE on DMRS in response to a shortage of SRS resources on the air interface between the UE and the O-RU.

18. A method according to any preceding claim when dependent on claim 2 wherein the O-DU selects to request positioning measurement(s) for a UE on SRS in response to the UE being scheduled for SRS transmission or free SRS resources being available on the air interface between the UE and the O-RU.

19. A method according to any preceding claim wherein any kind of 3GPP RU is used instead of an O-RAN O-RU and / or any kind of 3GPP DU is used instead of an O-RAN O-DU.

Images