Alternative modulation compression

Abstract

It is provided a method for configuring a modulation table (22) The method is performed by a radio unit, RU, (202) of a network node (120a-b, 1200). The method comprises: receiving (40) a command (30) to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and configuring (42) a modulation table (22) in accordance with the command.

Description

ALTERNATIVE MODULATION COMPRESSION INTRODUCTION

[0001] The present disclosure is related to wireless communication systems and moreparticularly to an alternative procedure for modulation compression.

[0002] FIG. 1 illustrates an example of a new radio (“NR”) network (e.g., a 5th Generation(“5G”) network) including a 5G core (“5GC”) network 130, network nodes 120a-b (e.g., 5G base station (“gNB”)), multiple communication devices 110 (also referred to as user equipment (“UE”)).

[0003] Massive multiple-input-multiple-output (“MIMO”) techniques have been firstadopted to practice in long term evolution (“LTE”). In 5G, it becomes a key technology component, which can be deployed in a much larger scale than in LTE. It features a largenumber of antennas used on the base-station side, where the number of antennas is typicallymuch larger than the number of user-layers, for example, 64 antennas serving 8 or 16 user- layers in frequency range 1 (“FR1”), which includes sub-6 GHz frequency bands, and 256 / 512 antennas serving 2 or 4 layers in frequency range 2 (“FR2”), which includes frequency bands from 24.25 GHz to 52.6 GHz.

[0004] A user layer can be used herein to refer to an independent downlink or uplink datastream intended for one user. One user or UE may have one or multiple user layers. A user layer can also be referred to as a layer in the 3rdgeneration partnership project (“3GPP”) terminology. Massive MIMO can also be referred to as massive beamforming, which is able to form narrow beams focusing on different directions to counteract against the increased path loss at higher frequency bands. It also benefits multi-user MIMO which allows for transmissions from / to multiple users simultaneously over separate spatial channels resolved by the massive MIMO technologies, while keeping high capacity for each user. Therefore, it can significantly increase the spectrum efficiency and cell capacity.

[0005] At the base-station side, the interface between the distributed unit (“DU”) and theradio unit (RU) is the fronthaul interface, as shown in FIG.2. The great benefits of massive MIMO at the air-interface also introduce new challenges at the base-station side. The legacy common public radio interface (“CPRI”)-type fronthaul transports time-domain in-phase andquadrature (“IQ”) samples per antenna branch. As the number of antennas scales up in massiveMIMO systems, the required fronthaul capacity also increases proportionally, which significantly drives up the fronthaul costs. To address this challenge, the fronthaul interface evolves from CPRI to enhance CPRI (“eCPRI”), a packet-based fronthaul interface. In eCPRI,other functional split options between a distributed unit (“DU”) and a radio unit (“RU”) aresupported, referred to as different lower-layer split (“LLS”) options. In the eCPRI standardspecification, the terms eCPRI Radio Equipment Control (“eREC”) and (eCPRI RadioEquipment (“eRE”) are used instead of DU and RU. The basic idea is to move the frequency-domain beamforming function from DU to RU so that frequency samples or data of user-layers are transported over the fronthaul interface. Note that the frequency-domain beamforming is sometimes also referred to as precoding in the downlink (“DL”) direction and equalizing or pre- equalizing in uplink (“UL”) direction. By doing this, the required fronthaul capacity and thereby the fronthaul costs are significantly reduced, as the number of user layers is typically much fewer than the number of antennas in massive MIMO. In open radio access network (“O- RAN”), DU is referred to as O-DU while RU is referred to as O-RU. Today, a 5G NR base station indicates to the UE, e.g., via downlink control signalling on the radio interface, which modulation and coding scheme (MCS) that will be used for comingdownlink transmissions. For downlink data channels, 5G NR supports 4-QAM to 1024-QAM,and a number of different code rates for each modulation. The number of constellation points ineach of I and Q dimensions is √M, corresponding to ½ log2(M) bits per dimension, where Mdenotes the number of constellation points in the QAM modulation, M-QAM.

[0006] The M-QAM modulation used in 5G NR (and also in 4G LTE etc) performs well inpresence of Gaussian noise. However, with strong phase noise, throughput performance can improve by increasing angular separation between points. Further, in presence of large magnitude ripple (e.g., from filters), performance can improve by increasing radial distance between points, especially near the outer edges.

[0007] O-RAN Open Fronthaul specifies an interface between an O-RAN Distributed Unit(O-DU) and O-RAN Radio Unit (O-RU), based on an intra-PHY functional split (i.e., a splitinside the physical layer) where e.g., downlink coding and modulation is done in the O-DU.Scheduling information and other real-time control information is sent in Control Plane (C- Plane) messages, which are typically associated with one or more later arriving User Plane (U- Plane) messages. Different data formats and compression schemes are available for U-Plane. For instance, there is an optional downlink IQ data compression method (for O-RAN Category B O- RUs) denoted Modulation Compression (ModComp). When enabled, normalized QAM constellation points for a downlink layer or spatial stream can, after scaling and sometimes also shifting, be described in two’s complement format, with coordinates on a grid with same number of points as the constellation, i.e., ½ log2(M) bits each per I and Q. The grid size is specified by the IQ bit width (udIqWidth), which is either statically configured via the Management Plane (M-Plane), or included in the downlink U-Plane section header. For example, 256-QAM needs log2(256) / 2 = 4 bits each per I and Q, which can be set in udIqWidth.SUMMARY

[0008] It is an object to provide support for more modulation tables and while at the sametime making efficient use of the fronthaul interface.

[0009] According to some embodiments, a method of operating a network node in acommunications network is provided. The network node is configured to provide a radio unit, RU. The method includes receiving a sequence of bits that were output by a fronthaul error correction, FEC, encoder from a distributed unit, DU. The method further includes performing modulation compression on the sequence of bits.

[0010] According to other embodiments, a method of operating a first network node in acommunications network is provided. The network node is configured to provide a distributedunit, DU. The method includes obtaining a sequence of bits from a fronthaul error correction,FEC, encoder. The method further includes transmitting the sequence of bits to a radio unit, RU,without performing modulation compression on the sequence of bits.

[0011] According to other embodiments, a network node (e.g., a O-RAN distributed unit(“O-DU”), an O-RAN radio unit (“O-RU”), or a RAN node), a computer program, computer program product, or non-transitory computer readable medium is provided to perform one of the above methods.

[0012] Certain embodiments may provide one or more of the following technicaladvantages. Some embodiments may enable more efficient O-RAN modulation compression. Insome examples, a scale factor conveyed to O-RU can be independent on modulation order ifnormalization is performed based on unit energy. In additional or alternative examples, theinnovations can provide flexible support for future modulation types by reconfiguration ofmodulation tables without change of O-RAN specifications. In additional or alternativeexamples, if a lookup table or similar functionality is introduced in the O-RU for flexible modulation support, the proposal avoids double lookup tables (e.g., there does not have to be one in the O-DU).

[0013] According to a first aspect, it is provided a method for configuring a modulationtable. The method is performed by a radio unit, RU, of a network node. The method comprises: receiving a command to define IQ, in-phase quadrature phase, values of constellation points of amodulation table; and configuring a modulation table in accordance with the command.

[0014] The receiving a command may comprise receiving the command from a distributedunit, DU, via a control plane, C-plane.

[0015] The receiving a command may comprise receiving the command from a DU via amanagement plane, M-plane.

[0016] The method may further comprise: selecting a modulation based on a modulationselection parameter that is received from the DU.

[0017] The modulation selection parameter may be part of a parameter originally intendedfor indicating the number of bits for I values and Q values in each IQ sample.

[0018] The method may further comprise: performing unit-energy normalization on themodulation constellation; and subsequent to performing the unit-energy normalization on themodulation constellation, applying a scale factor to the modulation constellation.

[0019] The performing the unit-energy normalization on the modulation constellation maycomprise dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.

[0020] The method may further comprise repetitively performing: receiving a symbol codefrom the DU; and deriving an IQ value for radio transmission to a user equipment, UE, based onthe symbol code.

[0021] The deriving an IQ value may comprise finding, for the symbol code, acorresponding IQ value in the modulation table, wherein the modulation table defines correspondences between IQ values of constellation points and respective symbol codes.

[0022] According to a second aspect, it is provided a radio unit, RU, for configuring amodulation table. The RU being configured to form part of a network node. The RU comprises:processing circuitry; and memory circuitry storing instructions that, when executed by theprocessing circuitry, cause the RU to: receive a command to define IQ, in-phase quadraturephase, values of constellation points of a modulation table; and configure a modulation table inaccordance with the command.

[0023] The instructions to receive a command may comprise instructions that, whenexecuted by the processing circuitry, cause the RU to receive the command from a distributed unit, DU, via a control plane, C-plane.

[0024] The instructions to receive a command may comprise instructions that, whenexecuted by the processing circuitry, cause the RU to receive the command from a DU via a management plane, M-plane.

[0025] The RU may further comprise instructions that, when executed by the processingcircuitry, cause the RU to: select a modulation based on a modulation selection parameter that isreceived from the DU.

[0026] The modulation selection parameter may be part of a parameter originally intendedfor indicating the number of bits for I values and Q values in each IQ sample.

[0027] The RU may further comprise instructions that, when executed by the processingcircuitry, cause the RU to: perform unit-energy normalization on the modulation constellation;and subsequent to performing the unit-energy normalization on the modulation constellation,apply a scale factor to the modulation constellation.

[0028] The instructions to perform the unit-energy normalization on the modulationconstellation may comprise dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.

[0029] The RU may further comprise repetitively executing instructions that, whenexecuted by the processing circuitry, cause the RU to: receive a symbol code from the DU; andderive an IQ value for radio transmission to a user equipment, UE, based on the symbol code.

[0030] The instructions to derive an IQ value may comprise instructions that, whenexecuted by the processing circuitry, cause the RU to find, for the symbol code, a corresponding IQ value in the modulation table, wherein the modulation table defines correspondences between IQ values of constellation points and respective symbol codes.

[0031] According to a third aspect, it is provided a computer program for configuring amodulation table by a radio unit, RU, of a network node. The computer program comprisescomputer program code which, when executed on the RU causes the RU to: receive a commandto define IQ, in-phase quadrature phase, values of constellation points of a modulation table; and configure a modulation table in accordance with the command.

[0032] According to a fourth aspect, it is provided a computer program product comprisinga computer program according to the third aspect and a computer readable means comprising non-transitory memory in which the computer program is stored.

[0033] According to a fifth aspect, it is provided a method for configuring a modulationtable. The method is performed by a distributed unit, DU, of a network node. The methodcomprises: generating a command to define IQ, in-phase quadrature phase, values ofconstellation points of a modulation table; and sending the command to a radio unit, RU, toconfigure a modulation table in accordance with the command.

[0034] The sending the command may comprise sending the command to the RU via acontrol plane, C-plane.

[0035] The sending the command may comprise sending the command from a DU via amanagement plane, M-plane.

[0036] The method may further comprise: selecting a modulation table to use; and sending amodulation selection parameter to the RU.

[0037] The method may further comprise, for each symbol to be transmitted to a userequipment, UE: determining a constellation point in the selected modulation table to be used forthe symbol; finding a symbol code for the constellation point based on the selected modulationtable; and sending the symbol code to the RU.

[0038] The finding a symbol code may comprise finding, for the constellation point, acorresponding symbol code in the modulation table, wherein the modulation table defines correspondences between IQ values of constellation points and respective symbol codes.

[0039] According to a sixth aspect, it is provided a distributed unit, DU, for configuring amodulation table. The DU is configured to form part of a network node. The DU comprises:processing circuitry; and memory circuitry storing instructions that, when executed by theprocessing circuitry, cause the DU to: generate a command to define IQ, in-phase quadraturephase, values of constellation points of a modulation table; and send the command to a radiounit, RU, to configure a modulation table in accordance with the command.

[0040] The instructions to send the command may comprise instructions that, whenexecuted by the processing circuitry, cause the DU to send the command to the RU via a control plane, C-plane.

[0041] The instructions to send the command may comprise instructions that, whenexecuted by the processing circuitry, cause the DU to send the command from a DU via a management plane, M-plane.

[0042] The DU may further comprise instructions that, when executed by the processingcircuitry, cause the DU to: select a modulation table to use; and send a modulation selectionparameter to the RU.

[0043] The DU may further comprise instructions that, when executed by the processingcircuitry, cause the DU to, for each symbol to be transmitted to a user equipment, UE: determinea constellation point in the selected modulation table to be used for the symbol; find a symbolcode for the constellation point based on the selected modulation table; and send the symbolcode to the RU.

[0044] The instructions to find a symbol code may comprise instructions that, whenexecuted by the processing circuitry, cause the DU to find, for the constellation point, a corresponding symbol code in the modulation table, wherein the modulation table defines correspondences between IQ values of constellation points and respective symbol codes.

[0045] According to a seventh aspect, it is provided a computer program for configuring amodulation table by a distributed unit, DU, of a network node. The computer program comprises computer program code which, when executed on a DU causes the DU to: generate a command to define IQ, in-phase quadrature phase, values of constellation points of a modulation table; and send the command to a radio unit, RU, to configure a modulation table in accordance with the command.

[0046] According to an eighth aspect, it is provided a computer program productcomprising a computer program according to the seventh aspect and a computer readable means comprising non-transitory memory in which the computer program is stored. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are included to provide a further understandingof the disclosure and are incorporated in and constitute a part of this application, illustratecertain non-limiting embodiments of inventive concepts. In the drawings:

[0048] FIG. 1 is a schematic diagram illustrating an example of a 5th generation (“5G”)network;

[0049] FIG. 2 is a block diagram illustrating an example of a fronthaul interface between aradio unit (“RU”) and a distributed unit (“DU”);

[0050] FIG. 3 is a block diagram illustrating an example of a weight based dynamicbeamforming (“WDBF”) implementation;

[0051] FIG. 4 is a signal flow diagram illustrating an example of an UL control-plane (“C-plane”) and user-plane (“U-plane”);

[0052] FIGS. 5-6 are block diagrams illustrating examples of subvariants of demodulationreference signal beamforming with equalization (“DMRS-BF-EQ”) implementations;

[0053] FIG. 7 is a block diagram illustrating an example of a DMRS-BF-NEQimplementation;

[0054] FIG. 8 is a flow chart illustrating an example of operations performed by a RU inaccordance with some embodiments;

[0055] FIG. 9 is a flow chart illustrating an example of operations performed by a DU inaccordance with some embodiments;

[0056] FIG. 10 is a block diagram of a communication system in accordance with someembodiments;

[0057] FIG. 11 is a block diagram of a user equipment in accordance with someembodiments;

[0058] FIG. 12 is a block diagram of a network node in accordance with someembodiments;

[0059] FIG. 13 is a block diagram of a host computer communicating with a user equipmentin accordance with some embodiments;

[0060] FIG. 14 is a block diagram of a virtualization environment in accordance with someembodiments; and

[0061] FIG. 15 is a block diagram of a host computer communicating via a base station witha user equipment over a partially wireless connection in accordance with some embodiments.

[0062] FIGS. 16A-B are swimlane diagrams illustrating embodiments of methods forconfiguring a modulation table;

[0063] FIG. 17 is a schematic diagram illustrating the use of a modulation table;

[0064] FIG. 18 is a schematic diagram showing functional modules of the RU of FIG. 2according to one embodiment;

[0065] FIG. 19 is a schematic diagram showing functional modules of the DU of FIG. 2according to one embodiment; and

[0066] FIG. 20 shows one example of a computer program product comprising computerreadable means. DETAILED DESCRIPTION

[0067] Some of the embodiments contemplated herein will now be described more fullywith 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, in which examples ofembodiments of inventive concepts are shown. Inventive concepts may, however, be embodiedin many different forms and should not be construed as limited to the embodiments set forthherein. Rather, these embodiments are provided so that this disclosure will be thorough andcomplete, and will fully convey the scope of present inventive concepts to those skilled in theart. It should also be noted that these embodiments are not mutually exclusive. Componentsfrom one embodiment may be tacitly assumed to be present / used in another embodiment.

[0068] When used with a lower-layer split and modulation compression, the O-RU and UEneeds to have the the same mapping between sequences of bits and constellation points. The O- DU does not necessarily have to do anything with the actual constellation points once it hasdefined the modulation table in the O-RU. One way to design modulation tables is to removeconstellation points from a higher-order constellation. For constellations that are subsets of existing M-QAM constellations, the existing O-RAN modulation compression could be used, but with the fronthaul bitrate according to the superset constellation. In the following, solutions are presented regarding how to avoid such overhead, and / or to use modulation compression for constellations that are not a subset of a higher-order constellation.

[0069] Information is pre-agreed or conveyed from the O-DU to the O-RU, via M-Plane, C-Plane, and / or U-Plane, regarding at least one of:^ Modulation table definition and update (re-definition)^ Modulation table selection (to avoid repeating the definition for every use)

[0070] There might also be changes regarding:^ Bits to send on the interface (which bit sequence maps to a specific point)^ Constellation normalization (excluding modCompScaler or mcScaleOffset)

[0071] The O-DU could skip parts of the modulation mapping (inverse Gray-coding and I,Q de-interleaving). These parts will instead be performed in the O-RU as part of decompression (can be handled by the table lookup done in the O-RU without extra cost). Instead of sending alternating iData and qData samples for modulation compression as done today, one can send groups of log2(M) bits, each group representing a constellation point, increasing efficiency even further.

[0072] The O-RU decompresses the bits on the interface, e.g., by a lookup table, andperform any necessary scaling. Optionally, IQ samples are normalised by the average constellation energy before applying any additional scale factor (modCompScaler or mcScaleOffset). Current O-RAN modulation compression uses a different normalization as an integral part of the modulation compression and thus requires different modCompScaler or mcScaleOffset for different constellation sizes (different udIqWidth) to achieve same power spectral density.

[0073] Using embodiments presented herein, flexible support is provided for usingmodulation compression with alternative modulation types by definition (and redefinition if needed) of modulation tables, together with a mechanism for table selection. This allowsefficient use of constellations optimized for different operating conditions, e.g., for differentchannels, different O-RUs, and / or different UE impairments (phase noise, amplitude ripple etc.).

[0074] U-Plane bitrate is optimized since minimum number of bits needed for themodulation can be sent also for non-square and non-uniform constellations.

[0075] By moving part of the modulation mapping from the O-DU to the O-RUdecompression, less processing is needed in the O-DU without extra computations in the O-RU. Further, addressing the constellation with the log2(M) bits instead of separating them into I and Q components allows more efficient support for constellations for which log2(M) is odd, e.g.,32-QAM or 128-QAM or a custom modulation.

[0076] Normalization of decompressed IQ samples by average constellation energy allowssame modulation compression scale factor (modCompScaler or mcScaleOffset) to be used for different constellation sizes.

[0077] Further description of some embodiments are described in Appendices A and B.

[0078] Herein the term user layer can refer to an independent downlink (“DL”) or uplink(“UL”) data stream intended for one user. One user or communication devices (also referred to herein as a user equipment (“UE”)) may have one or multiple user layers. Massive MIMO canalso be referred to as massive beamforming, which is able to form narrow beams focusing on different directions to counteract against the increased path loss at higher frequency bands. Italso benefits multi-user MIMO which allows for transmissions from / to multiple userssimultaneously over separate spatial channels resolved by the massive MIMO technologies, while keeping high capacity for each user. Therefore, it can significantly increase the spectrum efficiency and cell capacity.

[0079] At the base-station side, the interface between the baseband unit (“BBU”) and theradio unit (“RU”) is the fronthaul interface, whereas the interface between the BBU and the core network (“CN”) is the backhaul interface. The great benefits of massive MIMO at the air- interface also introduce new challenges at the base-station side. The legacy common public radio interface (“CPRI”)-type fronthaul transports time-domain quadrature (“IQ”) samples perantenna branch. As the number of antennas scales up in massive MIMO systems, the requiredfronthaul capacity also increases proportionally, which significantly drives up the fronthaul costs. To address this challenge, the fronthaul interface evolves from CPRI to enhanced CPRI (“eCPRI”), a packet-based fronthaul interface. In eCPRI, other functional split options between a BBU and a RU are supported, referred to as different lower-layer split (“LLS”) options. The basic idea is to move the frequency-domain beamforming function from BBU to RU so that frequency samples or data of user-layers are transported over the fronthaul interface. Note that the frequency-domain beamforming is sometimes also referred to as precoding in the DL direction and equalizing or pre-equalizing in UL direction. By doing this, the required fronthaul capacity and thereby the fronthaul costs can be significantly reduced, as the number of user layers is typically much fewer than the number of antennas in massive MIMO.

[0080] This is true for the massive MIMO case, but it is not only the beamforming that ismoved. First, eCPRI allowed moving OFDM FFT / IFFT to the RU, removing the overhead of the cyclic prefix and of the oversampling of time-domain signals. This gives benefits also for classic Macro radios. Then, beamforming is moved to the RU for massive MIMO radios, which gives a significant reduction in fronthaul bitrate by sending spatial streams or layers over the interface instead of one stream per antenna.

[0081] The term radio unit (“RU”) can be used herein to refer to a network node (or aportion of a network node) that performs radio functions including a portion of physical layer (“PHY”) functions according to an LLS option. The RU can perform conversions betweenradio frequency (“RF”) signals and baseband signals. On the network side a RU can transmitand receive the frequency-domain IQ data (modulated user data) or unmodulated user data toand from BBU through a fronthaul interface (e.g. eCPRI). The RU can also transmit andreceive the RF signals to and from UEs through its antennas.

[0082] The term baseband unit (“BBU”) can be used herein to refer to a network entity(e.g., a network node or a portion of a network node) that performs baseband processing. TheBBU can communicatively couple to the CN via a backhaul interface or to a central unit (“CU”) via an F1 interface.

[0083] In an open radio access network (“O-RAN”) the BBU and RU can be referred to asO-DU and O-RU, respectively. In D-MIMO terminology, the RU can also be referred to as anaccess point (“AP”) and the BBU can be referred to as a central processing unit (“CPU”) oredge cloud processor. In some terminologies, the RU can also be referred to as remote radiounit (“RRU”) and the BBU can be referred to as a digital unit or distributed unit (“DU”). In eCPRI terminologies, the BBU and the RU are referred to as an eCPRI radio equipmentcontrol (“eREC”) and eCPRI radio equipment (“eRE”) respectively. In another terminology, aBBU and a RU may be referred to as a LLS-CU and a LLS-DU respectively. The BBU and its equivalence can also be softwarized or virtualized as Baseband Processing Function in a Cloudenvironment. Use of the terms BBU and RU herein are not intended to limit the application ofthe innovation, which can be used in any suitable wireless field.

[0084] The term desired cell / channel can be used herein to refer to the cell / channel whichconnects to the UEs of the K user-layers.

[0085] The term user-plane data can be used herein to mean, for example, frequency-domain user-layer data sent over fronthaul.

[0086] The term channel information can be used herein to mean, for example, informationabout channel properties carried by the channel values. The term channel value / data can also beused here to refer to, for example, one or a set of complex values representing the amplitude and phase of the channel coefficients in frequency domain. The channel values are related to thefrequency response of the wireless channel.

[0087] The term beam can be used herein to refer to a directional beam formed bymultiplying a signal with different weights, in frequency-domain, at multiple antennas such that the energy of the wanted signal is concentrated to a certain direction and / or the energy of the interreference signal is nulled at a certain direction.

[0088] The term beamforming can be used herein to refer to a technique which multipliesa signal with different weights (in frequency-domain) at multiple antennas, which enables the signal energy to be sent in space with a desired beam pattern by forming a directional beam concentrating on certain direction or forming nulling in certain direction, or a combination of both.

[0089] The term beamforming weight (“BFW”) can be used herein to refer to a set of one ormore complex weights, each set is multiplied with a signal of one user-layer at a subcarrier or agroup of subcarriers. The weighted signals of different user layers towards the same antenna ortransmit beam are combined linearly. As a result, different user-layer signals are beamformed to different directions. The wording beamforming performance when used herein may mean signal quality in DL at the UE side after the beamforming has been performed at the base-station side, measured by, for example, post-processing signal-to-interference-and-noise-power ratio (“SINR”) at a UE, resulted user throughput, bit rate, etc.

[0090] The term antenna array can be used herein to refer to a set of multiple antennaswhich are used collectively to transmit and / or receive signal. In some examples, an antennaarray is one antenna panel on which multiple antennas are placed. In additional examples,among these multiple antennas, more than one antennas are connected together and used as one antenna, which is connected to one radio frequency (“RF”) component (e.g., a power amplifier or a low-noise amplifier). These connected antennas can be referred to as a subarray. From a baseband processing perspective, one subarray can act as one antenna. In this example, an antenna array is composed of multiple subarrays, each of which is composed of multipleantennas. In general, the size of a subarray is 1 when each subarray is composed of only oneantenna. In some other terminologies, antennas in an antenna array are referred to as antennaelements. In O-RAN terminology, subarray can be referred to as array element and an antenna array can be referred to as an antenna. In O-RAN terminology, each antenna can include multiple array elements.

[0091] The term antenna ports can be used herein to refer to subarrays of an antenna array.When a subarray size is 1, each antenna port can correspond to each antenna. In O-RANterminology, an antenna port can refer to an array element. In some examples, an antenna port isalso referred to as a digital antenna port, where each digital antenna port corresponds to one antenna seen from baseband processing. In downlink, the output signals of beamforming in the frequency domain can be sent to the corresponding antenna ports.

[0092] Various embodiments herein focuses on the uplink (“UL”) direction of the fronthaulinterface and the downlink (“DL”) direction of the fronthaul interface.

[0093] Fig 2 illustrates the structure of the interface between the distributed unit (“DU”)200 and the radio unit (RU) 202, together performing the function of a network node. In openradio access network (“O-RAN”), DU is referred to as O-DU while RU is referred to as O-RU.Herein, the terms DU and O-DU, as well as the terms RU and O-RU are used interchangeably,even though the functions described as performed by an O-DU or O-RU can be performed by any other suitable DU or RU. Communication between the DU 200 and the RU 202 can occurover an M-plane (management plane) 203, a C-plane (control plane) 204 and / or a U-plane (userplane), as well over an S-plane (synchronisation plane).

[0094] FIG. 3 illustrates an example of the UL Weight-based Dynamic Beamforming(“WDBF”) implementation supported by the current O-RAN WG4 specification. By having thebeamforming function in the O-RU, the number of streams going through the fronthaul interface becomes smaller than the number of antenna branches. However, the beamforming weights are calculated in the O-DU based on the sounding reference signal (“SRS”) sent back from the O- RU. Since the SRS channel estimates correspond to an earlier channel, the required number of streams is still much larger than the number of layers to avoid performance loss, compared tothat using CPRI-based fronthaul. In some examples, CPRI has one stream per antenna so it canbe worse than O-RAN WG4 WDBF, which requires a number of spatial streams larger than thenumber of layers, but can be smaller than the number of antennas. Retrieving more beams thanthe number of antennas may not be useful since there is no additional information. Accordingly,there is a tradeoff between the number of streams used and the performance.

[0095] FIG. 4 illustrates an example of the control-plane (“C-plane”) and user-plane (“U-plane”) data flow for WDBF. For every slot, the O-DU sends first C-plane messages to convey the scheduling information to the O-RU. The scheduling information includes the resource elements (“REs”) to be scheduled, the beam identifier (“ID”) (referred to herein as beamId) which represents the beamforming weights pre-stored in the O-RU, the beamforming weights (“BFWs”) to be used. The O-RU receives the scheduling information and then processes the scheduled REs according to the scheduling information received, e.g., perform beamforming (i.e., apply the beamforming weights received directly or indicated by the beam ID received) for the scheduled REs. Then the O-RU sends the processed REs (i.e., U-plane data) in U-plane messages to the O-DU.

[0096] There is another type of beamforming procedure defined in the current O-RANWG4 specification, referred as Channel Information based Beamforming (“CIBF”). In CIBF, instead of transferring BFWs or beamId, the O-DU transfers to the O-RU the scheduled layers and the SRS channel estimates of the scheduled layers in the C-plane messages. The O-RU uses the received information (i.e., the scheduled REs, the scheduled layers and their channel estimates for the scheduled REs) to calculate the BFWs and perform beamforming to the scheduled REs using the calculated BFWs. Then the O-RU sends the processed REs (i.e., U- plane data) in U-plane messages to the O-DU. In the specification, each scheduled layer is conveyed by a field called “ueId” in C-plane message. Although the field name is “ueId”, the ueId represents a layer, not a UE. For a UE with multiple layers scheduled, it needs multiple ueId(s) where each ueId represent one layer of the UE.

[0097] O-RAN WG4 has agreed to improve the current specification by introducing a newbeamforming method referred to as demodulation reference signal based beamforming(“DMRS-BF”) to achieve the best performance using the minimum fronthaul bit rate, i.e. reducing the number of streams to the number of layers. There are two implementation variants of DMRS-BF solutions that are being standardized in O-RAN WG4. The first variant is referred to as DMRS based beamforming with equalization (“DMRS-BF-EQ”), where equalization is performed in O-RU. The second variant is referred to as DMRS based beamforming without equalization (“DMRS-BF-NEQ”), where equalization is not performed in O-RU.

[0098] In wireless communication, an equalizer performs an equalization operation on theinput signal, which reverses the distortion caused by the end-to-end channel including the transmitter chain, the over-the-air channel (including the wanted channel and the interference channel), and the receiver chain. After the equalization, the equalized symbols can be demodulated by a demodulator. When the input signal is from multiple transmitters which send different data, the equalizer may also mitigate the interferences between them. Equalizers can be linear or non-linear. Examples of linear equalizers are zeroforcing equalizer, MMSE equalizer etc. Examples of non-linear equalizers are decision-feedback equalizer (“DFE”), successive interference cancellation (“SIC”) receiver etc.

[0099] The DMRS-BF-EQ variant has two implementation sub-variants. FIG. 5 illustratesan example of one of the sub-variants, in which the O-DU does not perform an additionalequalization. In addition to the equalized data symbols, the O-RU sends the signal tointerference and noise ratio (SINR) measurement from the O-RU to the O-DU which are used by the O-DU to demodulate the equalized symbols. The SINR measurement represents the measured / estimated SINR values, e.g., per physical resource block (PRB) or finer frequency resolution per layer, which is used by the demodulator for demodulation of the symbols of each RE per layer, e.g., the demodulation algorithm based on LLR (log likelihood ratio). The equalized data symbols are often referred to as soft values in demodulation terminology.

[0100] FIG. 6 shows the second implementation sub-variant, in which the O-DU performsan additional equalization. This sub-variant is intended to support advanced receiver algorithms (e.g. SIC receiver, IRC-CoMP receiver) which need channel estimates in the O- DU. In this subvariant, the O-RU sends both equalized data symbols and equalized DMRS symbols which are equalized in the same way as the equalized data symbols. The O-DU will use the received equalized DMRS to estimate the effective channel including air interface channel and the O-RU processing (e.g. equalization done by the O-RU). Then, the effective channel estimates are used to further process the data symbols.

[0101] As shown in FIGS. 5-6, for both subvariants of DMRS-BF-EQ, O-RU will sendRRM (Radio Resource Management) measurements which are calculated or measured beforebeamforming and equalization. These measurements can’t be calculated in the O-DU. That’s why these measurements are calculated by the O-RU and sent to the O-DU. Some examples of the RRM measurements are listed below.

[0102] Timing advance error (“TAE”): this is used for UE Timing Advance (TA). Thismeasurement is one TAE value per UE.

[0103] Received signal power of UE: this is used for UE closed loop power control. Thismeasurement is one value per UE layer.

[0104] Frequency offset of UE: O-RU reports the frequency offset measured. Thismeasurement is one value per UE.

[0105] Interference plus noise (“IPN”) power measurement: O-RU calculates the power ofreceived interference and noise per PRB. This is useful for the scheduler in the O-DU to optimize scheduling decisions. There are two kinds of IPN measurements, i.e., IPN for the allocated PRBs and the non-allocated PRBs, respectively. The allocated PRBs are the PRBs scheduled for UE traffic, while the non-allocated PRBs are the PRBs having not UE traffic scheduled. This measurement can be one value per PRB or one value per PRB per symbol.

[0106] In addition to the list above, other possible RRM measurements (such as delayspread, doppler shift, AoA (angle of arrival)) are also beneficial to support. These measurements are usually performed and reported in every slot. In some configurations, some measurements may be requested on demand by the O-DU.

[0107] FIG. 7 shows the implementation of DMRS-BF-NEQ. In this case, the O-RU onlyperforms beamforming without doing equalization. The O-RU sends both beamformed data symbols and beamformed DMRS symbols which are beamformed in the same way as the beamformed data symbols. The O-DU will use the received beamformed DMRS to estimate the effective channel including air interface channel and the O-RU processing (e.g., beamforming done by the O-RU). Then, the effective channel estimates are used to perform the equalization. the DMRS-BF-NEQ O-RU may perform some measurements, e.g., frequency offset, Rx signal power, TAE, Doppler shift, etc. But it may use these measurements by itself,not reporting them to the O-DU. It may also support measuring and reporting somemeasurements, e.g., IPN.

[0108] O-RAN Open Fronthaul specifications, includes an optional downlink IQ datacompression method denoted Modulation Compression (ModComp). When enabled, normalized modulation constellation points for downlink are described with coordinates on a grid with same number of points as the constellation.

[0109] The O-DU separates interleaved I and Q bits from the forward error correction(FEC) encoder and converts from Gray code as specified by 3GPP to two’s complement. Aseparate scale factor to apply in the O-RAN Radio Unit (O-RU) can be sent in C-plane using a section extension (SE 4, SE 5, or SE 23).

[0110] The normalization is done by dividing the original (odd integer) coordinates withsquare root of the constellation size and ensures that all I and Q coordinates have magnitude lessthan or equal to unity. Further, a shift flag is included in SE4, SE 5, and SE 23, in order to offsetthe coordinates. The actual shift applied depends on modulation order.

[0111] For example, with 16-QAM (quadrature amplitude modulation), the different I and{^^,^^,^^,^^} Q values would after normalization take coordinates√^^={−0.75, −0.25, +0.25, +0.75}. For 16-QAM, a shift of -0.25 is used, which results in{−1, −0.5,0, +0.5}. This set of values is then represented as a two’s complement number withbit-width 2 (for each of I and Q).64-QAM would require bit-width 3 etc. The resulting two’s complement number is sent on the interface to the O-RU. In addition, a scale factor is sent. TheO-RU applies this scale factor on the normalized coordinates after undoing any shift, to achievea desired signal power per resource element.

[0112] If downlink data (PDSCH, Physical Downlink Shared Channel) is multiplexed withe.g., demodulation reference signals (DMRS) in same PRB, and if PDSCH uses a higher order modulation than DMRS, the shift is typically only applied to PDSCH. This is controlled by using different combinations of resource element mask and shift flag.

[0113] There currently exists certain challenges. For example, a disadvantage with thechosen normalization in O-RAN is that different scale factors have to be calculated and sent over the interface for different modulation orders if it is desired to reach a given transmit power per RE (which is often the case).

[0114] A second disadvantage is that the current modulation compression is tailored forsquare-shaped regular constellations. If a future 3GPP standard (e.g., 6G) introduces other modulation types with irregular constellations, the current scheme will not work.

[0115] Various embodiments discussed herein describe an alternative procedure formodulation compression. In some embodiments, it is proposed to send bits on the interface asoutput from the downlink forward error correction (FEC) encoder in the O-DU. The amount of bits to send per constellation point is the same as in today’s O-RAN. If different modulation orders are multiplexed in same resource block (e.g., PDSCH and DMRS), different endpoints (eAxCs) in the radio should be used for PDSCH and DMRS since current O-RAN protocol do not allow different bit width for IQ compression within one PRB.

[0116] In additional or alternative embodiments, if unit-energy normalization is usedinstead of current O-RAN normalization, a single scale factor can be used for all REs that shouldhave same transmit power in the O-RU, independent of modulation type. Thus, it might be possible to configure the scale factor via M-plane instead of sending it via C-plane to the O-RU for each slot.

[0117] In additional or alternative embodiments, since the O-RU is responsible forconversion from FEC encoder output bits to modulation constellation, the O-RU can have configurable lookup tables to be able to generate new modulation types. With current modulation types in 3GPP, it would be sufficient with one table per modulation order and the modulation orders can be described using the bit-width field in the udCompHeader field when Modulation Compression is used.

[0118] In the future, it might be necessary to have multiple tables for a given modulationorder where the O-DU could choose the best one for a particular UE, given e.g., information about channel characteristics and any impairments such as phase noise, frequency error, and gain ripple. In that case, an identifier other than bit width, might be needed, e.g., one of ^A new ‘modulationId’ to identify which table to use, perhaps sent in a new SectionExtension similar to SE 4 but with the additional identifier present. ^Connect the modulation to some existing identifier such as ueId or beamId. The latterwould require different beamId for different signals sent to same UE if they have different modulation, but this can be acceptable.

[0119] A mechanism to update modulation tables is desired, e.g., one or more of: M-planeupdate; New C-plane section extension to update constellation point IQ values; and New command in C-plane Section Type 4 to update constellation point IQ values.

[0120] A limit on the maximum number of tables and / or total table size could also beuseful.

[0121] In some embodiments, when supported by the O-RU and enabled by the O-DU, bitsare sent as output from the FEC encoder instead of de-interleaved and converted to two’s complement. Normal downlink data (PDSCH) and demodulation reference symbols are sent on different endpoints, at least if PDSCH and DMRS are multiplexed on same symbol.

[0122] In additional or alternative embodiments, the scale factor to use by the O-RU can besent using an existing section extension such as SE 4, SE 5, or SE 23. Alternatively, it can be configured via M-plane. To supported e.g., power boosting of DMRS, the scale factor configuration could be done with a separate value per O-RU endpoint (eAxC).

[0123] In additional or alternative embodiments, the O-RU can optionally supportconfigurable modulation tables to allow new types of modulations, e.g., optimized for different channels or different O-RU or UE impairments (phase noise etc.). If more than onemodulation is needed per modulation order, different modulations may be selectable based on e.g., beamId, ueId, a new modulationId, PRB range etc.

[0124] Operations of the network node 1200 (implemented using the structure of FIG. 12)will now be discussed with reference to the flow charts of FIGS. 8-9 according to someembodiments of inventive concepts. For example, modules may be stored in memory 1204 of FIG.12, and these modules may provide instructions 67 so that when the instructions of a module are executed by respective network node processing circuitry 1202, network node 1200 performs respective operations of the flow charts.

[0125] FIG. 8 illustrates an example of operations performed by a RU to perform analternative modulation compression procedure.

[0126] At block 810, processing circuitry 1202 transmits, via communication interface 1206,an indication to a DU that the RU is capable of performing the modulation compression.

[0127] At block 820, processing circuitry 1202 receives, via communication interface 1206,a sequence of bits that were output by a FEC encoder.

[0128] At block 830, processing circuitry 1202 performs modulation compression on thesequence of bits.

[0129] At block 840, processing circuitry 1202 transmits, via communication interface 1206,data to a communication device using the modulation compression.

[0130] FIG. 9 illustrates an example of operations performed by a DU to assist an RU inperforming an alternative modulation compression procedure.

[0131] At block 910, processing circuitry 1202 obtains a sequence of bits from a FECencoder.

[0132] At block 920, processing circuitry 1202 receives, via communication interface 1206,an indication from a RU that the RU is capable of performing modulation compression on the sequence of bits.

[0133] At block 930, processing circuitry 1202 transmits, via communication interface 1206,the sequence of bits to the RU.

[0134] At block 940, processing circuitry 1202 determines a modulation order to be appliedto the sequence of bits.

[0135] At block 950, processing circuitry 1202 transmits, via communication interface 1206,an indication of the modulation order to the RU.

[0136] At block 960, processing circuitry 1202 determines a scale factor associated with thesequence of bits.

[0137] At block 970, processing circuitry 1202 transmits, via communication interface Q306,an indication of the scale factor to the RU.

[0138] Various operations of FIGS. 8-9 may be optional or completed in a different orderthan illustrated.

[0139] FIG. 10 shows an example of a communication system 1000 in accordance withsome embodiments.

[0140] In the example, the communication system 1000 includes a telecommunicationnetwork 1002 that includes an access network 1004, such as a radio access network (RAN), and a core network 1006, which includes one or more core network nodes 1008. The access network 1004 includes one or more access network nodes, such as network nodes 1010a and 1010b (one or more of which may be generally referred to as network nodes 1010), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. Moreover, as will be appreciated by those of skill in the art, the network nodes 1010 are not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integratedby a single vendor. Thus, it will be understood that the network nodes 1010 may includedisaggregated implementations or portions thereof. For example, in some embodiments, thetelecommunication network 1002 includes one or more Open-RAN (ORAN) network nodes. AnORAN network node is a node in the telecommunication network 1002 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1002, including one or more network nodes 1010 and / or core network nodes 1008.

[0141] Examples of an ORAN network node include an open radio unit (O-RU), an opendistributed 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 RAN control application (e.g., xApp) or a non-real time RAN automation application (e.g., rApp), or any combinationthereof (the adjective “open” designating support of an ORAN specification). The network nodemay support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user planeinterface, or an open fronthaul management plane interface. Intents and content-awarenotifications described herein may be communicated from a 3GPP network node or an ORAN network node over 3GPP-defined interfaces (e.g., N2, N3) and / or ORAN Alliance-definedinterfaces (e.g., A1, O1). Moreover, an ORAN network node may be a logical node in a physicalnode. Furthermore, an ORAN network node may be implemented in a virtualizationenvironment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platformorchestrated by a Service Management and Orchestration Framework via an O-2 interfacedefined by the O-RAN Alliance. The network nodes 1010 facilitate direct or indirect connectionof user equipment (UE), such as by connecting wireless devices 1012a, 1012b, 1012c, and 1012d (one or more of which may be generally referred to as UEs 1012) to the core network1006 over one or more wireless connections. The network nodes 1010 facilitate direct or indirectconnection of user equipment (UE), such as by connecting UEs 1012a, 1012b, 1012c, and 1012d (one or more of which may be generally referred to as UEs 1012) to the core network 1006 over one or more wireless connections.

[0142] Example wireless communications over a wireless connection include transmittingand / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1000 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1000 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0143] The UEs 1012 may be any of a wide variety of communication devices, includingwireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1010 and other communication devices. Similarly, the network nodes 1010 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1012 and / or with other network nodes or equipment in the telecommunication network 1002 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1002.

[0144] In the depicted example, the core network 1006 connects the network nodes 1010 toone or more hosts, such as host 1016. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1006 includes one more core network nodes (e.g., core network node 1008) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1008. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), SubscriptionIdentifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0145] The host 1016 may be under the ownership or control of a service provider otherthan an operator or provider of the access network 1004 and / or the telecommunication network 1002, and may be operated by the service provider or on behalf of the service provider. The host 1016 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0146] As a whole, the communication system 1000 of FIG. 10 enables connectivitybetween the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low- power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0147] In some examples, the telecommunication network 1002 is a cellular network thatimplements 3GPP standardized features. Accordingly, the telecommunications network 1002 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1002. For example, the telecommunications network 1002 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive IoT services to yet further UEs.

[0148] In some examples, the UEs 1012 are configured to transmit and / or receiveinformation without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1004 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1004. Additionally,a UE may be configured for operating in single- or multi-RAT or multi-standard mode. Forexample, 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).

[0149] In the example, the hub 1014 communicates with the access network 1004 tofacilitate indirect communication between one or more UEs (e.g., UE 1012c and / or 1012d) and network nodes (e.g., network node 1010b). In some examples, the hub 1014 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1014 may be a broadband router enabling access to the core network 1006 for the UEs. As another example, the hub 1014 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1010, or by executable code, script, process, or other instructions in the hub 1014. As another example, the hub 1014 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1014 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1014 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1014 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1014 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

[0150] The hub 1014 may have a constant / persistent or intermittent connection to thenetwork node 1010b. The hub 1014 may also allow for a different communication scheme and / or schedule between the hub 1014 and UEs (e.g., UE 1012c and / or 1012d), and between the hub 1014 and the core network 1006. In other examples, the hub 1014 is connected to the core network 1006 and / or one or more UEs via a wired connection. Moreover, the hub 1014 may be configured to connect to an M2M service provider over the access network 1004 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1010 while still connected via the hub 1014 via a wired orwireless connection. In some embodiments, the hub 1014 may be a dedicated hub – that is, a hubwhose primary function is to route communications to / from the UEs from / to the network node1010b. In other embodiments, the hub 1014 may be a non-dedicated hub – that is, a devicewhich is capable of operating to route communications between the UEs and network node 1010b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0151] FIG. 11 shows a UE 1100 in accordance with some embodiments. As used herein, aUE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME),smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicleembedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0152] A UE may support device-to-device (D2D) communication, for example byimplementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may notinitially, be associated with a specific human user (e.g., a smart sprinkler controller).Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0153] The UE 1100 includes processing circuitry 1102 that is operatively coupled via a bus1104 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 UEs may utilize all or a subset of the components shown in FIG.11. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0154] The processing circuitry 1102 is configured to process instructions and data and maybe 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).

[0155] In the example, the input / output interface 1106 may be configured to provide aninterface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 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.

[0156] In some embodiments, the power source 1108 is structured as a battery or batterypack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 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 the UE 1100 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1108. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1108 to make the power suitable for the respective components of the UE 1100 to which power is supplied.

[0157] The memory 1110 may be or be configured to include memory such as randomaccess 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 application 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 the UE 1100, any of a variety of various operating systems or combinations of operating systems.

[0158] 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, externalhard 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 the UE 1100 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1110, which may be or comprise a device-readable storage medium.

[0159] The processing circuitry 1102 may be configured to communicate with an accessnetwork or other network 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 UE 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.

[0160] In the illustrated embodiment, communication functions of the communicationinterface 1112 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short- range communications such as Bluetooth, near-field communication, location-basedcommunication such as the use of the global positioning system (GPS) to determine a location,another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0161] Regardless of the type of sensor, a UE may provide an output of data captured by itssensors, through its communication interface 1112, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0162] As another example, a UE comprises an actuator, a motor, or a switch, related to acommunication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0163] A UE, when in the form of an Internet of Things (IoT) device, may be a device foruse in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensoryenhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring aplant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 1100 shown in FIG.11.

[0164] As yet another specific example, in an IoT scenario, a UE may represent a machineor other device that performs monitoring and / or measurements, and transmits the results of suchmonitoring and / or measurements to another UE and / or a network node. The UE may in this casebe an M2M device, which may in a 3GPP context be referred to as an MTC device. As oneparticular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipmentthat is capable of monitoring and / or reporting on its operational status or other functionsassociated with its operation.

[0165] In practice, any number of UEs may be used together with respect to a single usecase. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE 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 UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0166] FIG. 12 shows a network node 1200 in accordance with some embodiments. As usedherein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), NR NodeBs (gNBs)), O-RAN nodes, or components of an O-RAN node (e.g., intelligent controller, O-RU, O-DU, O-CU).

[0167] When the network node 1200 is implemented using O-RU and O-DU, somecomponents shown in Fig 12 can be present in both the O-RU and O-DU. For instance, the processing circuitry 1202, the memory 1204 and the power source 1208 can be present in both the O-RU and the O-DU.

[0168] Base stations may be categorized based on the amount of coverage they provide (or,stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units 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).

[0169] Other examples of network nodes include multiple transmission point (multi-TRP)5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiverstations (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 MobileLocation Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0170] The network node 1200 includes a processing circuitry 1202, a memory 1204, acommunication interface 1206, and a power source 1208. The network node 1200 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1200 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1200 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate 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, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1200.

[0171] The processing circuitry 1202 may comprise a combination of one or more of amicroprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1200 components, such as the memory 1204, to provide network node 1200 functionality.

[0172] 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 radio frequency (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.

[0173] 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-onlymemory (ROM), mass storage media (for example, a hard disk), removable storage media (forexample, 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 the communication interface 1206. In some embodiments, the processing circuitry 1202 and memory 1204 is integrated.

[0174] The communication interface 1206 is used in wired or wireless communication ofsignaling and / or data between a network node, access network, and / or UE. As illustrated, the 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. The communication interface 1206 also includes radio front-end circuitry 1218 that may be coupled to, or in certain embodiments a part of, the antenna 1210. Radio front-end circuitry 1218 comprises filters 1220 and amplifiers 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 front-end circuitry 1218 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1220 and / or amplifiers 1222. The radio signal 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.

[0175] In certain alternative embodiments, the network node 1200 does not include separateradio 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).

[0176] The antenna 1210 may include one or more antennas, or antenna arrays, configuredto 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 / or signals wirelessly. In certain embodiments, the antenna 1210 is separate from the network node 1200 and connectable to the network node 1200 through an interface or port.

[0177] The antenna 1210, communication interface 1206, and / or the processing circuitry1202 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1210, the communication interface 1206, and / or the processing circuitry 1202 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0178] The power source 1208 provides power to the various components of network node1200 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.

[0179] Embodiments of the network node 1200 may include additional components beyondthose shown in FIG. 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.

[0180] FIG. 13 is a block diagram of a host 1300, which may be an embodiment of the host1016 of FIG.10, in accordance with various aspects described herein. As used herein, the host 1300 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1300 may provide one or more services to one or more UEs.

[0181] The host 1300 includes processing circuitry 1302 that is operatively coupled via abus 1304 to an input / output interface 1306, a network interface 1308, a power source 1310, and a memory 1312. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices ofprevious figures, such as FIGS. 11 and 12, such that the descriptions thereof are generallyapplicable to the corresponding components of host 1300.

[0182] The memory 1312 may include one or more computer programs including one ormore host application programs 1314 and data 1316, which may include user data, e.g., data generated by a UE for the host 1300 or data generated by the host 1300 for a UE. Embodiments of the host 1300 may utilize only a subset or all of the components shown. The host application programs 1314 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1314 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1300 may select and / or indicate a different host for over-the-top services for a UE. The host application programs 1314 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0183] FIG. 14 is a block diagram illustrating a virtualization environment 1400 in whichfunctions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented asvirtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1400 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core networknode or host), then the node may be entirely virtualized. In some embodiments, the virtualizationenvironment 1400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0184] Applications 1402 (which may alternatively be called software instances, virtualappliances, 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.

[0185] Hardware 1404 includes processing circuitry, memory that stores software and / orinstructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1408a and 1408b (one or more of which may be generally referred to as VMs 1408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1406 may present a virtual operating platform that appears like networking hardware to the VMs 1408.

[0186] The VMs 1408 comprise virtual processing, virtual memory, virtual networking orinterface and virtual storage, and may be run by a corresponding virtualization layer 1406. Different embodiments of the instance of a virtual appliance 1402 may be implemented on one or more of VMs 1408, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0187] In the context of NFV, a VM 1408 may be a software implementation of a physicalmachine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1408, and that part of hardware 1404 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function isresponsible for handling specific network functions that run in one or more VMs 1408 on top of the hardware 1404 and corresponds to the application 1402.

[0188] Hardware 1404 may be implemented in a standalone network node with generic orspecific components. Hardware 1404 may implement some functions via virtualization. Alternatively, hardware 1404 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1410, which, among others, oversees lifecycle management of applications 1402. In some embodiments, hardware 1404 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1412 which may alternatively be used for communication between hardware nodes and radio units.

[0189] FIG. 15 shows a communication diagram of a host 1502 communicating via anetwork node 1504 with a UE 1506 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of theUE (such as a UE 1012a of FIG. 10 and / or UE 1100 of FIG. 11), network node (such as networknode 1010a of FIG. 10 and / or network node 1200 of FIG. 12), and host (such as host 1016 ofFIG. 10 and / or host 1300 of FIG. 13) discussed in the preceding paragraphs will now bedescribed with reference to FIG.15.

[0190] Like host 1300, embodiments of host 1502 include hardware, such as acommunication interface, processing circuitry, and memory. The host 1502 also includes software, which is stored in or accessible by the host 1502 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1506 connecting via an over-the-top (OTT) connection 1550 extending between the UE 1506 and host 1502. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1550.

[0191] The network node 1504 includes hardware enabling it to communicate with the host1502 and UE 1506. The connection 1560 may be direct or pass through a core network (like core network 1006 of FIG.10) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0192] The UE 1506 includes hardware and software, which is stored in or accessible byUE 1506 and executable by the UE’s processing circuitry. The software includes a clientapplication, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1506 with the support of the host 1502. In the host 1502, an executing host application may communicate with the executing client application via the OTT connection 1550 terminating at the UE 1506 and host 1502. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1550 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1550.

[0193] The OTT connection 1550 may extend via a connection 1560 between the host 1502and the network node 1504 and via a wireless connection 1570 between the network node 1504 and the UE 1506 to provide the connection between the host 1502 and the UE 1506. The connection 1560 and wireless connection 1570, over which the OTT connection 1550 may be provided, have been drawn abstractly to illustrate the communication between the host 1502 and the UE 1506 via the network node 1504, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0194] As an example of transmitting data via the OTT connection 1550, in step 1508, thehost 1502 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1506. In other embodiments, the user data is associated with a UE 1506 that shares data with the host 1502 without explicit human interaction. In step 1510, the host 1502 initiates a transmission carrying the user data towards the UE 1506. The host 1502 may initiate the transmission responsive to a request transmitted by the UE 1506. The request may be caused by human interaction with the UE 1506 or by operation of the client application executing on the UE 1506. The transmission may pass via the network node 1504, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1512, the network node 1504 transmits to the UE 1506 the user data that was carried in the transmission that the host 1502 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1514, the UE 1506 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1506 associated with the host application executed by the host 1502.

[0195] In some examples, the UE 1506 executes a client application which provides userdata to the host 1502. The user data may be provided in reaction or response to the data received from the host 1502. Accordingly, in step 1516, the UE 1506 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interfaceof the UE 1506. Regardless of the specific manner in which the user data was provided, the UE 1506 initiates, in step 1518, transmission of the user data towards the host 1502 via the network node 1504. In step 1520, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1504 receives user data from the UE 1506 and initiates transmission of the received user data towards the host 1502. In step 1522, the host 1502 receives the user data carried in the transmission initiated by the UE 1506.

[0196] One or more of the various embodiments improve the performance of OTT servicesprovided to the UE 1506 using the OTT connection 1550, in which the wireless connection 1570forms the last segment. More precisely, the teachings of these embodiments may enable moreefficient O-RAN modulation compression. In some examples, a scale factor conveyed to O-RUcan be independent on modulation order if normalization is performed based on unit energy. Inadditional or alternative examples, the innovations can provide flexible support for future modulation types by reconfiguration of modulation tables without change of O-RANspecifications. In additional or alternative examples, if a lookup table or similar functionality isintroduced in the O-RU for flexible modulation support, the proposal avoids double lookup tables (e.g., there does not have to be one in the O-DU).

[0197] In an example scenario, factory status information may be collected and analyzed bythe host 1502. As another example, the host 1502 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1502 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1502 may store surveillance video uploaded by a UE. As another example, the host 1502 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1502 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0198] In some examples, a measurement procedure may be provided for the purpose ofmonitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1550 between the host 1502 and UE 1506, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1502 and / or UE 1506. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1550 passes; the sensors may participate in the measurementprocedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1550 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1504. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1502. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1550 while monitoring propagation times, errors, etc.

[0199] Although the computing devices described herein (e.g., UEs, network nodes, hosts)may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functionsof any of such components may be implemented in software or firmware and computationallyintensive functions may be implemented in hardware.

[0200] In certain embodiments, some or all of the functionality described herein may beprovided 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 thoseparticular 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.

[0201] FIGS. 16A-B are swimlane diagrams illustrating embodiments of methods forconfiguring a modulation table. The swimlane diagrams can be considered to comprise a flowchart for methods in the DU 200 on the left and a flow chart for methods in the RU 202 on the right. As explained above, the RU 202 and the DU 200 form part of a network node. Communication between the DU 200 and the RU 202 is also shown, occurring of the fronthaul interface. First, embodiments illustrated by Fig 16A will be described.

[0202] In a generate command step 50 the DU 200 generates a command to define IQ (in-phase quadrature phase) values 36 of constellation points of a modulation table 22. In otherwords, the command defines the modulation table 22. The modulation table 22 is also generated in the DU 200.

[0203] In one embodiment, the modulation tables can be defined by a list of complex valuescorresponding to constellation point coordinates. An index to each constellation point can then be used as a symbol code.

[0204] In one embodiment, the modulation table is defined by a bitmask or index list tocreate a subset of an existing constellation. One example could be to create a 32-QAM (cross 32-QAM) constellation by removing points along the edges and corners from a 64-QAMconstellation). Again, an index to each constellation point can be used as symbol code.

[0205] A further alternative is by design attributes (e.g., for APSK (amplitude and phaseshift keying) or spiral-shaped constellations), where each constellation point is provided with a corresponding symbol code.

[0206] The information could be sent in C-Plane or in M-Plane. Any symmetries in aconstellation (e.g., symmetry in cartesian or polar coordinates) could be used to compress theinformation in the definition of the modulation table.

[0207] In a send command step 51, the DU 200 sends 51 the command 30 to a RU 202, toconfigure a modulation table 22 in accordance with the command comprising the definition ofthe modulation table.

[0208] Optionally, the command is sent to the RU via a C-plane (control plane).

[0209] Alternatively, the command is sent to the RU via an M-plane (management plane).

[0210] If the modulation table definition is large, there might be a need for fragmentation ofthe definition over multiple messages, e.g., by sending a subset of constellation points in each message.

[0211] A mechanism to re-define already defined modulation tables is optionally provided,e.g. using an M-plane update. a new C-plane section extension to update constellation point IQ values or a new command in C-plane Section Type 4 to update constellation point IQ values.

[0212] An O-RU might declare a limit on the maximum number of tables and / or total tablesize that can be defined.

[0213] A defined modulation table can be associated with an identifier so that the definitiondoes not have to be repeated every time the table is used.

[0214] In a receive command step 40, the RU 202 receives the command 30 to define IQvalues 36 of constellation points of a modulation table 22.

[0215] In a configure modulation table step 42, the RU 202 configures (e.g. generates) amodulation table 22 in accordance with the command.

[0216] The modulation table is now present in both the DU and the RU.

[0217] Optionally, instead of signalling the definition of the modulation table from the DU200 to the RU 202, the modulation tables can be predefined in the DU 200 and the RU 202. Inthat case, no definition of modulation table needs to be provided from the DU 200 to the RU 202.

[0218] Looking now to Fig 16B, only new or modified steps compared to what is illustratedby Fig 16A will be described.

[0219] In an optional select modulation table step 52, the DU 200 selects a modulation table22 to use. This selection can be based on measurements of the radio channel between thenetwork node and the UE. For instance, if there is strong phase noise on the radio channel, throughput performance can be improved by increasing angular separation between constellation points, whereby a suitable non-square modulation table is selected.

[0220] In one embodiment, the DU 200 selects the modulation table among multiplemodulation tables of multiple modulation types for a given constellation size, i.e. number ofconstellation points.

[0221] In one embodiment, the RU 202 first reports to the DU 200 what modulation tablesit supports together with modulation table properties, for example, modulation type, number ofconstellation points etc, allowing the DU 200 to select an appropriate modulation table supported by the DU 200. This is particularly applicable in the case when the DU 200 does not define the modulation table for the RU 202.

[0222] Alternatively of additionally, it is the RU 2.02 that defines the modulation table andsends a signal to the DU 200 to define a corresponding modulation table.

[0223] In an optional send modulation table parameter step 53, the DU 200 sends amodulation selection parameter 32 to the RU 202. The modulation selection parameter 32informs the RU 202 which modulation table to use for subsequent user plane transmissions from the DU 200 to the RU 202.

[0224] There are multiple possibilities regarding how to communicate the selection betweenmultiple modulation tables to use with modulation compression. Out of the predefined or otherwise defined alternative modulation tables, one can select one for a specific transmission of the modulation table selection.

[0225] In one embodiment, the modulation selection parameter is part of a parameteroriginally intended for indicating the number of bits for I values and Q values in each IQsample, i.e. based on redefining values of the udIqWidth parameter. If only a few differentconstellations (modulation tables) are needed per modulation order, one can redefine unused values of udIqWidth for modulation compression.

[0226] The O-RAN udIqWidth parameter is 4 bits wide and can thus represent 16 differentvalues. Today, the 5G NR downlink data channel only supports five different modulations: 4- QAM, 16-QAM, 64-QAM, 256-QAM, and 1024-QAM, encoded with udIqWidth values 1–5 when modulation compression is used. 01 2 3 4 5 6 7 (lsb) Numb(msb) er of Octets udIqWidth udCompMeth 1Table 1: Definition of udIqWidth udIqWidth Bit width of each I and each Q0000-1111b 16 for udIqWidth = 0, otherwise equals udIqWidth e.g. udIqWidth =0000b means I and Q are each 16 bits wide; e.g. udIQWidth = 0001b means I and Q are each 1 bit wide; e.g. udIqWidth = 1111b means I and Q are each 15 bits wide Table 2: conventional use of udIqWidth

[0227] In the prior art, O-RAN modulation compression in practice only uses udIqWidthvalues 1–5, which means that there are 11 unused values. A bit width equal to 1 is used for QPSK (4-QAM), which is robust against both phase noise and magnitude ripple and can thus be used under different operating conditions without any changes to the constellation. It is more important to have alternative tables for higher-order modulation. Further, in case 4096-QAM becomes standardized in 3GPP, it might be good to reserve bit width of 6 for this purpose. Hence, in decimal, values 1-6 can be reserved for the original definition of udIqWidth. Since the parameter takes up 4 bits, values 0 and 7-15, i.e.10 values, can be used to define the selection of a modulation table, as long as the DU 200 and the RU 202 agree on the same mapping of the value of udIqWidth and modulation table.

[0228] Alternatively, a new ‘mcTableId’ parameter can be conveyed in C-Plane to conveythe modulation table selection, e.g., in a new or modified Section Extension, or in a new ormodified Section Type. For instance, if many modulation tables are needed, or if the tables aredynamically generated, a 4-bit value might not be sufficient. In that case, an identifier other than bit width might be needed, e.g., one of:^ A new ‘mcTableId’ to identify which table to use out of a known set (pre-defined, orconfigured via M-Plane or C-Plane), e.g. sent in a new Section Extension similar to SE 4 orSE 5, but with the additional identifier present. The mcTableId could also be sent in a separate section extension that can be combined with e.g., SE 4 or SE 5 when needed.^ Attributes that describe the design of a constellation, e.g., to create an APSK constellation,or a spiral-shaped constellation. Such attributes might be associated to an identifier so that the list does not have to be repeated.

[0229] One possibility is to specify a new Section Extension, including a parameter(mcTableId) that can be used to select one out of a set of modulation tables for a given udIqWidth. One such example is illustrated below, based on SE 4, where the new parameter‘mcTableId’ is shown as an 8-bit field. It would also be possible to create a similar new SectionExtension, but based on e.g., SE 5 instead of SE 4. In the prior art, udIqWidth in the C-Plane udCompHdr field is always set to zero for downlink and the actual udIqWidth used in U-Plane is specified either in U-Plane udCompHdr, or statically in M-Plane. However, to give the O-RU more time to select or generate new modulation tables as described in this invention, it would be beneficial to convey information related to the constellation size in C-Plane. This can be done by changing the CUS-Plane specification so that udCompHdr in C-Plane also contains the udIqWidth value. Alternatively, an additional parameter (mcIqWidth) can be added in the new Section Extension to convey information related to the constellation size, e.g., the IQ bitwidth,log2of the constellation size, the number of points in the constellation (might require more than 8 bits in the field), or an index into a candidate set of constellation sizes. 0(msb) 1 2 3 4 5 6 7 (lsb) # ofbytes ef extType = 0x04 1extLen = 0x02 (2 words) 1csf modCompScaler[14:8] 1modCompScaler[7:0] 1mcTableId[7:0] 1mcIqWidth[7:0] 1zero padding 2Table 3: new section extension comprising mcTableId

[0230] Alternatively, the modulation table selection can be conveyed using a ueId orbeamId, or other existing parameter. Specifically, the modulation table selection can beconveyed using an existing parameter such as ueId in Section Type 5, or beamId in Section Type 1 and 3. This does not require any new Section Extension or Section Type, but might be less flexible.

[0231] In an optional select modulation table step 44, the RU 202 selects a modulationbased on a modulation selection parameter 32 that is received from the DU.

[0232] At this stage, the DU 200 and the RU 202 are aligned on what modulation table touse, and the communication of user data between the DU 200 and RU 202 is ready to commence.

[0233] In an optional determine constellation point step 54, the DU 200, for eachmodulation symbol to be transmitted to a UE 110, 1100, 1506, determines a constellation pointin the selected modulation table 22 to be used for the symbol to send over the fronthaul (U-plane) to the RU 202. Each symbol is made up of a sequence of bits that are uniquely mapped to a constellation point in the modulation table.

[0234] In an optional find symbol code step 55, the DU 200 finds a symbol code for theconstellation point based on the selected modulation table 22. In one embodiment, the finding 55 a symbol code comprises finding, for the constellation point, a corresponding symbol code 20 in the modulation table 22, wherein the modulation table 22 defines correspondences between IQvalues 36 of constellation points and respective symbol codes 20, as illustrated in Fig 17 anddescribed below. In other words, the DU 200 can perform a lookup in the modulation table 22 tofind the symbol based on the IQ value of the constellation point.

[0235] In one embodiment, there is a mapping table, equivalent the modulation table,between an input bit sequence and symbol code, which will then result in IQ values when the RU later finds IQ values in the modulation table based on the symbol code.

[0236] In one embodiment, the determine constellation point step 54 is omitted and the findsymbol code step 55 will take a group of log2M bits as output from FEC + scrambling (+ anylayer and / or RE mapping) as the basis for finding the symbol code. As long as the O-RU and UEhave the same understanding on which symbol code corresponds to each constellation point, thedetermine constellation point step 54 can be omitted. When configuring the modulation table,the O-DU can ensure that the mapping is the desired one.

[0237] In an optional send symbol code step 56, the DU 200 sends the symbol code 34 tothe RU 202. When repeated (see step 58 below), the symbol codes form part of an enumerationof symbol codes that are sent to the RU 202.

[0238] In modulation compression of the prior art, the I and Q values sent are scaled andshifted representations of the cartesian complex-valued constellation point coordinates, d(i), as output from the QAM modulation mapping. This will not work for non-square and irregularconstellations. For e.g., PSK (phase shift keying) / APSK variants, a polar representation can bemore suitable, unless the phase or amplitude shifts are not uniform. A more general approach could be to enumerate symbol codes according to a pre-defined rule. If the constellation is described as a list of coordinates, an index into that list can be used as the symbol code.

[0239] Instead of performing a full modulation mapping, it can be more efficient for the O-DU to send coded bits on the fronthaul interface as output from Forward Error Correction(FEC), scrambling, layer and / or RE mapping as symbol codes. In that case the modulationmapping step would mainly group the b(i) bitstream from FEC + scrambling into groups of log2(M) bits, as input to layer mapping and RE mapping. The existing inverse Gray coding in modulation mapping for 5G NR would be omitted and instead done in the O-RU either explicitly or implicitly in the lookup from the symbol code to IQ values. Further, each such group of bits could be used to directly address one constellation point; there is no need to split the log2(M) bits into I and Q bit groups as is done today.

[0240] In an optional receive symbol code step 45, the RU 202 receives a symbol code 34from the DU.

[0241] In an optional derive IQ value step 46, the RU 202 derives an IQ value 36 for radiotransmission to a user equipment, UE, 110, 1100, 1506 based on the symbol code 34.

[0242] The IQ value can be derived by finding, for the symbol code 34, a corresponding IQvalue 36 in the modulation table 22, wherein the modulation table 22 defines correspondencesbetween IQ values 36 of constellation points and respective symbol codes 34.

[0243] In an optional normalize step 47, the RU 202 performs unit-energy normalization onthe modulation constellation.

[0244] In the prior art, O-RAN modulation compression normalizes the complexmodulation symbols by multiplying by 1 / √M, instead of by 1 / √E (E is the average constellation energy). This means that the prior art modulation compression requires different modCompScaler (or mcScaleOffset) for different modulation orders to achieve same power spectral density. Since the scale-and-shift approach of modulation compression only works for regular M-QAM modulation, in one embodiment, the normalization is changed to instead normalize by 1 / √E in the O-RU decompression and thus achieve unit energy. This allows thesame modCompScaler to be used for different modulation orders. One possibility is then to havea statically configured modCompScaler set via M-Plane configuration of the RU 202.

[0245] Hence, in one embodiment, the unit-energy normalization on the modulationconstellation comprises dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.

[0246] In an optional scale step 48, the RU 202 (subsequent to performing the unit-energynormalization on the modulation constellation) applies scale factor to the modulationconstellation.

[0247] In an optional conditional repeat step 58, the DU 200 determines if there are moresymbols to modulate. If so, the method returns to the determine constellation point step 54.Otherwise, the method ends.

[0248] In an optional conditional repeat step 49, the RU 202 determines if there are moresymbols to modulate. If this is the case, the method returns to the receive symbol code step 45. Otherwise, the method ends.

[0249] Normally, the method is repeated as long as there is data in the data buffer.

[0250] FIG. 17 is a schematic diagram illustrating the use of a modulation table. On the left,the DU 200 uses the modulation table 22 to find a symbol code 34 based on an IQ value 36. The symbol code 34 is then transmitted to the RU 202. The RU 202 performs the lookup in reverse, based on the same modulation table 22 that is used by the DU 200. In other words, based on the symbol code 34, the RU 202 looks up a corresponding IQ value 36 by looking up this value in the modulation table 22.

[0251] FIG. 18 is a schematic diagram showing functional modules of the RU 202 of FIG. 2according to one embodiment. The modules are implemented using software instructions such asa computer program executing in the RU 202. Alternatively or additionally, the modules areimplemented using hardware, such as any one or more of an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits. The modules correspond to the steps in the methods illustrated in Figs 16A and 16B.

[0252] A command receiver 70 corresponds to step 40. A modulation table configure 72corresponds to step 42. A modulation table selector 74 corresponds to step 44. A symbol code receiver 75 corresponds to step 45. An IQ value deriver 76 corresponds to step 46. A normalizer77 corresponds to step 47. A scaler 78 corresponds to step 48. A repeater 79 corresponds to step49.

[0253] FIG. 19 is a schematic diagram showing functional modules of the DU 200 of FIG. 2according to one embodiment. The modules are implemented using software instructions such asa computer program executing in the DU 200. Alternatively or additionally, the modules are implemented using hardware, such as any one or more of an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits. Themodules correspond to the steps in the methods illustrated in Figs 16A and 16B.

[0254] A command generator 80 corresponds to step 50. A command sender 81 correspondsto step 51. A modulation table selector 82 corresponds to step 52. A modulation table

[0255] FIG. 20 shows one example of a computer program product 90 comprising computerreadable means. On this computer readable means, a computer program 91 can be stored in a non-transitory memory. The computer program can cause processing circuitry to execute a method according to embodiments described herein. In this example, the computer program product 90 is in the form of a removable solid-state memory, e.g. a Universal Serial Bus (USB) drive. As explained above, the computer program product could also be embodied in a memory of a device, such as the memory 1204 of Fig 12, which can thus also form a computer program product. While the computer program 91 is here schematically shown as a section of the removable solid-state memory, the computer program can be stored in any way which is suitable for the computer program product, such as another type of removable solid-state memory, or an optical disc, such as a CD (compact disc), a DVD (digital versatile disc) or a Blu-Ray disc. EMBODIMENTS1. A method of operating a network node in a communications network, the network nodeconfigured to provide a radio unit, RU, the method comprising: receiving (820) a sequence of bits that were output by a fronthaul error correction, FEC,encoder from a distributed unit, DU; andperforming (830) modulation compression on the sequence of bits.2. The method of Embodiment 1, wherein performing the modulation compression on thesequence of bits comprises: converting the sequence of bits to a modulation constellation; performing unit-energy normalization on the modulation constellation; and subsequent to performing the unit-energy normalization on the modulation constellation, applying a scale factor to the modulation constellation.3. The method of Embodiment 2, wherein converting the sequence of bits to the modulationconstellation comprises separating interleaved in-phase, I, and quadrature, Q, bits from the sequence of bits.4. The method of any of Embodiments 2-3, wherein performing the modulation compressionon the sequence of bits further comprises: receiving an indication of a modulation order from the DU, wherein converting the sequence of bits to the modulation constellation comprises converting the sequence of bits to the modulation constellation based on the indication the modulation order.5. The method of any of Embodiments 2-4, wherein performing the unit-energynormalization on the modulation constellation comprises dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.6. The method of any of Embodiments 2-5, wherein performing the modulation compressionfurther comprises: receiving an indication of the scale factor from the DU7. The method of Embodiment 6, wherein receiving the indication of the scale factorcomprises receiving a section extension, SE, via a control plane, C-plane, including the indication of the scale factor.8. The method of Embodiment 6, wherein receiving the indication of the scale factorcomprises receiving the indication of the scale factor via a management plane, M-plane.9. The method of any of Embodiments 1-8, further comprising:transmitting (810) an indication to the DU that the RU is capable of performing the modulation compression.10. The method of any of Embodiments 1-9, further comprising:transmitting (840) data to a communication device using the modulation compression.11. The method of any of Embodiments 1-10, wherein the communications network comprisesan open radio access network, O-RAN, wherein the RU comprises an O-RAN RU, O-RU, and wherein the DU comprises an O-RAN DU, O-DU.12. A method of operating a first network node in a communications network, the networknode configured to provide a distributed unit, DU, the method comprising: obtaining (910) a sequence of bits from a fronthaul error correction, FEC, encoder; andtransmitting (930) the sequence of bits to a radio unit, RU, without performing modulation compression on the sequence of bits.13. The method of Embodiment 12, further comprising:receiving (920) an indication from the RU that the RU is capable of performing modulation compression on the sequence of bits, wherein transmitting the sequence of bits to the RU comprises transmitting the sequence of bits to the RU in response to receiving the indication from the RU that the RU is capable of performing the modulation compression on the sequence of bits.14. The method of any of Embodiment 12-13, further comprising:determining (940) a modulation order to be applied to the sequence of bits; and transmitting (950) an indication of the modulation order to the RU.15. The method of any of Embodiments 12-14determining (960) a scale factor associated with the sequence of bits; and transmitting (970) an indication of the scale factor to the RU.16. The method of Embodiment 15, wherein transmitting the indication of the scale factorcomprises transmitting a section extension, SE, via a control plane, C-plane, including the indication of the scale factor.17. The method of Embodiment 15, wherein transmitting the indication of the scale factorcomprises transmitting the indication of the scale factor via a management plane, M-plane.18. The method of any of Embodiments 12-18, wherein the communications networkcomprises an open radio access network, O-RAN, wherein the RU comprises an O-RAN RU, O-RU, and wherein the DU comprises an O-RAN DU, O-DU.19. A network node (1200) in a communications network, the network node comprising:processing circuitry (1202); and memory (1204) coupled to the processing circuitry and having instructions stored therein that are executable by the processing circuitry to cause the network node to perform operations comprising any of the operations of Embodiments 1-18.20. A computer program comprising program code to be executed by processing circuitry(1202) of a network node (1200) in a communications network, whereby execution of the program code causes the first network entity to perform operations comprising any operations of Embodiments 1-18.21. A computer program product comprising a non-transitory storage medium (1204)including program code to be executed by processing circuitry (1202) of a network node (1200) in a communications network, whereby execution of the program code causes the network node to perform operations comprising any operations of Embodiments 1-18.22. A non-transitory computer-readable medium having instructions stored therein that areexecutable by processing circuitry (1202) of a network node (1200) in a communications network, to cause the network node to perform operations comprising any of the operations of Embodiments 1-18.APPENDIX A7 C-Plane Protocol…7.7 Coding of Section Extension IEs7.7.1 SE 1: Beamforming weights…7.7.4 SE 4: Modulation compression parameters7.7.4.1 Overview Section Extension 4 applies only to Section Types 1, 3 and 5. Section Extension 4 enables the O- DU to convey to the O-RU one set of “csf and modCompScaler values” which is needed for modulation compression described in Annex A.5.Table 7.7.4.1-1 shows the format of Section Extension 4.^ Table 7.7.4.1-1: Format of Section Extension 4 (modulation compressionparameters) 0(msb) 1 2 3 4 5 6 7 (lsb) # ofbyte s ef extType = 0x04 1 OctetN extLen = 0x01 (1 word) 1 N+1csf modCompScaler[14:8] 1 N+2modCompScaler[7:0] 1 N+37.7.4.2 csf (constellation shift flag)Description: This binary flag indicates whether to shift the constellation (csf=1) or not (csf=0).“Shift” means subtract from (during compression) or add to (during decompression) the I and Q values the value 2-udIqWidthwhere “udIqWidth” is the number of I and Q bits in the U-Plane representation (see Table 7.7.4.2-2). If the O-RU indicates support for alternative ModulationCompression by M-plane parameter alternative-modcomp-supported and the O-RU hasenabled it by setting alternative-modcomp-enabled to TRUE, then csf shall be treated as areserved bit and the O-DU shall set csf=0. ^Table 7.7.4.2-2: Constellation shift definitionudIqWidth Shiftvalue 1 1 / 2 2 1 / 4 3 1 / 8 4 1 / 16 5 1 / 32Value range: {0b-1b}Type: binary.Field length: 1 bit.7.7.4.3 modCompScaler (modulation compression scaler value)Description: This parameter conveys the scale factor O-RU shall apply to the unshiftedconstellation points during decompression. It is a fractional floating-point value having an unsigned but negative 4-bit exponent and an unsigned fractional 11-bit mantissa.Value range: { 0 through +(1-2-11 ) }.Type: unsigned fractional floating-point value. The value of the scale factor conveyed as modCompScaler field shall be calculated with: ^^^^^^^^^^^^^ = mantissa ´ 2^^^^^^^^^where exponent is the most significant 4 bits of the 15-bit modCompScaler field and mantissa is the least-significant 11 bits of the modCompScaler field. The values of exponent and mantissa shall be calculated with: mantissaexponentwhere "modCompScaler[k]" is the kthbit of the modCompScaler field.Field length: 15 bits.7.7.5 SE 5: Modulation compression additional parameters7.7.5.1 OverviewThis Section Extension applies only to Section Types 1, 3 and 5. Section Extension 5 enables the O-DU to convey one or more set(s) of mcScaleReMask, csf and mcScaleOffset values to the O-RU which is needed for modulation compression described in Annex A.5. Table 7.7.5.1-3 andTable 7.7.5.1-4 shows the Section Extension format when one set and two sets of"mcScaleReMasks, csf and mcScaleOffset values" are conveyed. Please note that Section Extension 5 may be used to convey more than two sets of "mcScaleReMasks, csf and mcScaleOffset values" in which case the frame structure is extended in similar fashion, i.e., the zero padding bits are added at the end of the Section Extension to maintain 4-byte alignment. ^Table 7.7.5.1-3: Format of Section Extension 5 with one scaler value, modulationcompression parameters 0(msb) 1 2 3 4 5 6 7 (lsb) # ofbyte s ef extType = 0x05 1 OctetN extLen = 0x2 (2 words) 1 N+1mcScaleReMask[11:4] 1 N+2mcScaleReMask[3:0] csf mcScaleOffset [14:12] 1 N+3mcScaleOffset [11:4] 1 N+4mcScaleOffset [3:0] zero padding 1 N+5zero padding 1 N+6zero padding 1 N+7^ Table 7.7.5.1-4: Format of Section Extension 5 with two scaler values, modulationcompression parameters 0(msb) 1 2 3 4 5 6 7 (lsb) # ofbytes ef extType = 0x05 1 Octet NextLen = 0x03 (3 words) 1 N+1mcScaleReMask[11:4] 1 N+2mcScaleReMask[3:0] csf mcScaleOffset [14:12] 1 N+3mcScaleOffset [11:4] 1 N+4mcScaleOffset [3:0] mcScaleReMask[11:8] 1 N+5mcScaleReMask[7:0] 1 N+6csf mcScaleOffset [14:8] 1 N+7mcScaleOffset [7:0] 1 N+8zero padding 1 N+9zero padding 1 N+10zero padding 1 N+11For a given extLen value, there are two possible cases for the number of sets of 'mcScaleReMask-csf-mcScaleOffset'. For example, when extLen equals to 4, the number of sets of 'mcScaleReMask-csf-mcScaleOffset' may be either 3 or 4; i.e., both cases will fit within 16 bytes (extLen=4). This happens when extLen minus 2 bytes equals to an integer multiple of 3.5 bytes (28bits). In such cases, if the last 28 bits (length of one set) of Section Extension 5 parameters are all set to 0, then O-RU shall consider the smaller number of parameter sets. Otherwise, if they are not all set to 0, O-RU shall consider the larger number of parameter sets.Table 7.7.5.1-5 shows example of the format when 3 or 4 sets of parameters are included in theSection Extension.^ Table 7.7.5.1-5: Format of Section Extension 5 when extLen = 4 (three or fourmodulation compression parameters may be present) 0(msb) 1 2 3 4 5 6 7 (lsb) # ofbyte s ef extType = 0x05 1 OctetN extLen = 0x04 (4 words) 1 N+1mcScaleReMask[11:4] 1 N+2mcScaleReMask[3:0] csf mcScaleOffset [14:12] 1 N+3mcScaleOffset [11:4] 1 N+4mcScaleOffset [3:0] mcScaleReMask[11:8] 1 N+5mcScaleReMask[7:0] 1 N+6csf mcScaleOffset [14:8] 1 N+7mcScaleOffset [7:0] 1 N+8mcScaleReMask[11:4] 1 N+9mcScaleReMask[3:0] csf mcScaleOffset [14:12] 1 N+10mcScaleOffset [11:4] 1 N+11mcScaleOffset [3:0] mcScaleReMask[11:8] (or zero 1 N+12padding) mcScaleReMask[7:0] (or zero padding) 1 N+13csf (or zeromcScaleOffset [14:8] (or zero padding) 1 N+14padding) mcScaleOffset [7:0] (or zero padding) 1 N+157.7.5.2 mcScaleReMask (modulation compression power scale RE mask)Description: This parameter defines the Resource Element (RE) mask to indicate the position ofRE with same scaling and modulation type within a PRB. Each bit setting in themcScaleReMask indicates if the mcScaleOffset and csf fields are applicable to the RE sent in U-Plane messages or not (0=not applicable; 1=applicable). Most significant bit of this parameter indicates the value for the RE of the lowest frequency in a PRB.Different REs in a PRB may be indicated by different invocations of mcScaleReMask within theSection Extension 5. If any RE in a PRB is never pointed to by a mcScaleReMask (but otherREs in that PRB are), the "missing" RE should be considered to represent not populated REs (e.g. no user data to transmit). There is a relationship between the mcScaleReMask values and the section's reMask: no bit in any of the mcScaleReMasks shall be set (=1) in a position where the reMask has a zero, and every reMask bit that is set (=1) shall have exactly one bit =1 in one of the mcScaleReMasks.Value range: {000000000000b – 111111111111b}.Type: unsigned integer (bit mask). Field length: 12 bits. Default Value: 111111111111b (all REs in the block applicable).7.7.5.3 csf (constellation shift flag)Description: refer to clause 7.7.4.27.7.5.4 mcScaleOffset (scaling value for modulation compression)Description: This parameter is the scale factor to apply to the unshifted constellation pointsduring decompression. It is a fractional floating-point value having an unsigned but negative 4- bit exponent and an unsigned fractional 11-bit mantissa.Value range: {0 through +(1-2-11 ) }.Type: unsigned integer. exponent is the most significant 4 bits of the 15-bit mcScaleOffset field and mantissa is the least-significant 11 bits of the mcScaleOffset field. mcScaleOffset[k] refers to the kthbit of the mcScaleOffset field. Therefore, the actual value of mcScaleOffset is: mcScaleOffset = mantissa ´ 2^^^^^^^^^ .Field length: 15 bits.… SE 23: Arbitrary symbol pattern modulation compression parameters7.7.23.1 OverviewThis Section Extension enables specifying multiple sets of 'mcScaleReMask, csf and mcScaleOffset' values for one or more 'SymPrbPatterns'. The term 'SymPrbPattern' is used tospecify set of PRBs that can span an entire PRB range (specified using prbPattern) and multiple symbols (specified using symMask). In context of this Section Extension the term SymPrbPattern is defined for each mode of operation: for PRB-MASK mode SymPrbPattern is one set of parameters symMask and prbPattern, for PRB-BLOCK mode SymPrbPattern is one set of parameters symMask, prbBlkOffset and prbBlkSize. The proposed extension is motivated by the fact that in 5G NR reference signals like DM-RS, PT-RS, and data channel experience the same channel conditions (same beamId) but may use different MCS and hence different mcScaleOffset. This Section Extension applies to Section Types 1, 3 and 5. SE 23 can also be used for specifying channels like SSB since SSB has similar requirements as DMRS and PT-RS for specifying modulation compression parameters. This Section Extension has a nested structure comprising of two loops. The outermost loop which is bounded by the field 'numSymPrbPattern' shall specify multiple SymPrbPatterns. The innermost loop is bounded by the field "numMcScaleOffset" and shall specify multiple sets of 'mcScaleReMask, csf, and mcScaleOffset' per SymPrbPattern. Refer to Table 7.7.23.1 for details of the structure of SE 23. SE 23 can be used in two modes. When 'prbMode = 0' SE 23 operates in PRB-MASK mode in which case 'prbPattern' field shall be used to specify the PRB pattern as shown in Table 7.7.23.1-1. When 'prbMode = 1' SE 23 operates in PRB-BLOCK mode, in which case 'prbBlkOffset' and 'prbBlkSize' fields shall apply as shown in figure Table 7.7.23.1-2. All other fields shall remain the same for both the modes. When SE 23 operates in PRB-BLOCK mode, SE 23 shall specify single or multiple PRB blocks, using combination of 'symMask', 'prbBlkOffset', 'prbBlkSize' fields. One PRB block is a range of contiguous PRBs spanning from (startPrbc + prbBlkOffset) to (startPrbc + prbBlkOffset + prbBlkSize) over symbols specified in 'symMask'. O-RU shall advertise support for PRB-BLOCK mode of SE 23 on a per endpoint basis using theflag 'se-23-prb-block-mode-supported'. For an O-RU which does not advertise support for 'se-23-prb-block-mode-supported', O-DU shall assume only SE 23 PRB-MASK mode of operation supported by the O-RU, in which case 'prbMode' flag shall be treated as 'reserved' field and set to '0'; PRB-BLOCK mode specific fields, prbBlkOffset and prbBlkSize shall not be specified by the O-DU and shall not be interpreted by the O-RU.If Section Extension 23 is present in a section description, then the following requirements shall apply for both modes (PRB-MASK and PRB-BLOCK) of operation: 1) Requirements 1, 2 and 3 as specified in clause 7.7.6.1 for SE 6.SE 23 using a combination of symMask, prbPattern in PRB-MASK mode OR prbBlkOffset, prbBlkSize in PRB-BLOCK mode, and mcScaleReMask shall specify mcScaleOffset values for all the symbols and REs whose scheduling information is specified in the section header (startSymbolId) and section description (numSymbols, reMask) or via the use of SE 6 or SE 12. Specifically for SE 6 and SE 12 prbPattern shall apply to all allocated non-contiguous PRBsjumping over the un-allocated RBGs. Any PRB on time-freq grid shall be addressed by only one SymPrbPattern in any instance of SE 23 Each section description shall specify only one instance of SE 23 per eAxC_ID. When SE 23 is used in combination with SE 10 refer to clause 7.9.10. For every SymPrbPattern all REs in the PRBs as designated in the reMask in section header shall be assigned "mcScaleReMask, csf and mcScaleOffset" value. No bit in any of the mcScaleReMasks shall be set (=1) in a position where the reMask has a zero, and every reMask bit that is set (=1) shall have exactly one bit =1 in one of the mcScaleReMasks. e.g. For section header reMask = 111111111111 b, union of mcScaleReMask-1 = 1010 10101010 b and mcScaleReMask-2 = 010101010101 b shall be equal to the reMask value. When SE 23 is used in a section description, the number of sets of {mcScaleReMask, csf, mcScaleOffset} values per symPrbPattern shall be limited by the M-Plane O-RU capability parameter 'max-mcscaleremask-per-prb'. The following restriction is specific to prbMode = PRB-BLOCK: When SE 23 is used in PRB-BLOCK mode, number of PRB blocks or SymPrbPattern which can be specified using one instance of SE 23 is limited by O-RU advertised M-Plane parameter 'max-prb- blks-per-sec-ext-23'. The O-DU shall comply to the limits described in clause 7.8.2.1.2 assuming the number of PRB blocks in the section description with Section Extension 23 PRB-BLOCK mode is the number of non-empty (i.e., with prbBlkSize > 0) frequency ranges in the Section Extension 23.^ Table 7.7.23.1-6: Section Extension 23 for modulation compression for multiplesymbols with prbMode = PRB-MASK0 (msb) 1 2 3 4 5 6 7(lsb) # ofbytes ef extType = 0x17 1 Octet NextLen[7:0] 1 N+1prbMod numSymPrbPattern[3:0] reserved 1 N+2e reserved 1 N+3reserved symMask[13:8] (1) 1 N+4symMask[7:0] (1) 1 N+5numMcScaleOffset[3:0] (1) prbPattern[3:0] (1) 1 N+6reserved 1 N+7reserved mcScaleReMask[11:8] (1.1) 1 N+8mcScaleReMask[7:0] (1.1) 1 N+9csf (1.1) mcScaleOffset[14:8] (1.1) 1 N+10mcScaleOffset[7:0] (1.1) 1 N+11reserved (1.2) mcScaleReMask [11:8] (1.2) 1 N+12mcScaleReMask [7:0] (1.2) 1 N+13csf (1.2) mcScaleOffset[14:8] (1.2) 1 N+14mcScaleOffset[7:0] (1.2) 1 N+15… reserved symMask[13:8] (n)symMask1[7:0] (n)numMcScaleOffset[3:0] (n) prbPattern[3:0] (n)reserved reserved mcScaleReMask [11:8] (n.1)mcScaleReMask [7:0] (n.1)csf (n.1) mcScaleOffset[14:8] (n.1)mcScaleOffset[7:0] (n.1)^ Table 7.7.23.1-2: Section Extension 23 for modulation compression for multiplesymbols with prbMode = PRB-BLOCK 0(msb) 1 2 3 4 5 6 7(lsb) # ofbytes ef extType = 0x17 1 Octet NextLen[8:0] 1 N+1prbMod numSymPrbPattern[3:0] reserved 1 N+2e reserved 1 N+3reserved symMask[13:8] (1) 1 N+4symMask[7:0] (1) 1 N+5numMcScaleOffset[3:0] (1) prbBlkOffset[7:4] (1) 1 N+6prbBlkOffset [3:0] (1) prbBlkSize[7:4] (1) 1 N+7prbBlkSize[3:0] (1) mcScaleReMask[11:8] (1.1) 1 N+8mcScaleReMask[7:0] (1.1) 1 N+9csf (1.1) mcScaleOffset[14:8] (1.1) 1 N+10mcScaleOffset[7:0] (1.1) 1 N+11reserved (1.2) mcScaleReMask [11:8] (1.2) 1 N+12mcScaleReMask [7:0] (1.2) 1 N+13csf (1.2) mcScaleOffset[14:8] (1.2) 1 N+14mcScaleOffset[7:0] (1.2) 1 N+15… reserved symMask[13:8] (n)symMask1[7:0] (n)numMcScaleOffset[3:0] (n) prbBlkOffset[7:4] (n)prbBlkOffset [3:0] (n) prbBlkSize[7:4] (n)prbBlkSize[3:0] (n) mcScaleReMask [11:8] (n.1)mcScaleReMask [7:0] (n.1)csf (n.1) mcScaleOffset[14:8] (n.1)mcScaleOffset[7:0] (n.1)7.7.23.2 numSymPrbPattern (number of symbol and resource block patterns)Description: This parameter specifies the number of SymPrbPatterns specified by SE 23 instance.Value range: {0001b - 1111b} or {1 – 15} in decimalType: unsigned integer Field length: 4 bits.7.7.23.3 symMask (symbol mask part of symPrbPattern)Description: This parameter is a bitmask for the symbols specified by SymPrbPattern 0: 'SymPrbPattern' does not apply to the associated symbol. 1: 'SymPrbPattern' applies to the associated symbol.Value range: {00000000000001b - 11111111111111b}.Type: unsigned integer (bit mask). Field length: 14 bits.7.7.23.4 prbPattern (resource block pattern part of symPrbPattern)Description: This parameter is a 4-bit pattern mask for the PRBs specified by SymPrbPattern. This pattern repeats over all the allocated PRBs. When there are allocation discontinuities e.g.SE 6, SE 12, the pattern only applies to the allocated PRBs. If the prb range is not a multiple of 4 then the last prbPattern shall be truncated. In the specified mask LSB represents the lowest frequency PRB and MSB represents the highest frequency PRB in the prbPattern. 0: 'SymPrbPattern' does not apply to the associated PRB 1: 'SymPrbPattern' applies to the associated PRB.Value range: {0000b - 1111b}.Type: unsigned integer (bit mask). Field length: 4 bits.7.7.23.5 numMcScaleOffset (number of modulation compression scaling value persymPrbPattern) Description: This parameter indicates the number of modulation compression parameter sets i.e., 'mcScaleReMask, csf and mcScaleOffset' values, present for each SymPrbPattern. Refer to requirement#6 in clause 7.7.23.1 for limits that apply to this parameter.Value range: {0001b-1111b} or {1 – 15} in decimal1 – 12: Valid range0, 13, 14, 15: reserved Type: unsigned integer. Field length: 4 bits.7.7.23.6 mcScaleReMask (modulation compression power scale RE mask)Description: refer to clause 7.7.5.2 Note: This parameter as used for Section Extension 23 shall apply only to PRBs, and symbol specified by SymPrbPattern. 7.7.23.7 csf (constellation shift flag) Description: refer to clause refer to clause 7.7.4.2 7.7.23.8 Interaction with Other Section Extensions Interaction of Section Extension 23 with other Section Extensions is defined in Table 7.7.23.1-2.^ Table 7.7.23.1-2: Section Extension 23 Interactions with other Section ExtensionsSectionTitle Interaction with existing Section ExtensionsExtension BeamformingThis Section Extension is independent of SE 23 Weights BeamformingSE 2 can be used with SE 23 only if the Beamforming Attribute Attributestransferred using SE 2 is same for DL data and control channel (DM-RS and PT-RS) DL Precoding This Section Extension is independent of SE 23ModulationSE 23 cannot co-exist with this Section Extension in the same data Compression section ModulationSE 23 cannot coexist with this Section Extension in the same data Compression section (Additional) Non-ContiguousSE 6 can be used with SE 23. SE 23 shall apply to PRB allocations PRB with SE 6. For PRB-BLOCK mode the prbBlkOffset field is relative to thestartPrbc field in the section header.eAxC Mask This Section Extension is independent of SE 23Regularization factor This Section Extension is independent of SE 23DSS Parameters This Section Extension is independent of SE 230 Group Configuration No special handling needed . Refer to clause 7.9.10 for the interactionfor multiple ports details. 1FlexibleThis Section Extension is independent of SE 23 Beamforming Weights 2Non-ContiguousInteraction same as SE 6 PRB Allocation with Frequency Ranges 3PRB Allocation withInteraction same as SE 6 Frequency Hopping 4Nulling-Layer Info This Section Extension is independent of SE 23SectionTitle Interaction with existing Section ExtensionsExtension15 Mixed NumerologyThis Section Extension is independent of SE 23 Info for ueId-based beamforming16 Antenna InformationThis Section Extension is independent of SE 23 in UE Channel Information based UL beamforming17 Indication of UserThis Section Extension is independent of SE 23 Port group18 Uplink TransmissionThis Section Extension is independent of SE 23 Management19 Compact multipleSE=19 is used for specifying separate beamforming weights for data port beamforming and reference signals (CSI-RS), usage of SE=23 with SE=19 hence is information hence restricted20 PuncturingThis Section Extension is independent of SE 23 Extension21 Variable PRB groupThis Section Extension is independent of SE 23 size for channel information7.7.23.9 prbMode (PRB Mode)Description: This parameter is a bit flag that changes the mode of Section Extension 23 to beused for specifying different PRB patterns. Changing the value of this flag only impacts the way PRBs are specified in frequency domain. Value range: {0, 1}. 0: PRB-MASK mode 1: PRB-BLOCK mode Type: boolean. Field length: 1 bit.7.7.23.10 prbBlkOffset (PRB block offset)Description: This parameter is applicable when prbMode = '1' i.e., PRB-BLOCK mode. The parameter is used to indicate the offset to start of a given PRB Block for a given SymPrbPattern relative to 'startPrbc in section description or startPrbc present in applicable extension. This parameter when added to startPrbc defines the lower bound of a PRB block for a given SymPrbPattern.Value range: {00000001b – 11111111b}.Type: unsigned integer. Field length: 8 bits.7.7.23.11 prbBlkSize (PRB block size)Description: This parameter is applicable when prbMode = '1' i.e., PRB-BLOCK mode. The parameter is used to indicate the size of one PRB block of one SymPrbPattern in PRB-BLOCK mode. This parameter when added to startPrbc and prbBlkOffset, defines the upper bound of agiven PRB block.Value range: {00000001b – 11111111b}.Type: unsigned integer. Field length: 8 bits.10 Specification mandatory and optional capabilities10.1 GeneralTable 10.1-7 lists the general system capabilities supported by the present document.^ Table 10.1-7: Supported LTE / NR channels and system capabilitiesFeature Supported system capabilitiesPDSCH, PBCH, PCFICH, PDCCH, ePDCCH, MPDCCH, PHICH, LTE DL Channels CRS, MBSFN RS, UE-RS, DMRS for ePDCCH / MPDCCH, PRS, CSI- RS, PSS, SSS, Discovery RS PUSCH, PUCCH, DMRS-PUSCH, DMRS-PUCCH, SRS, PRACH LTE UL Channels (incl. eMTC) Narrow band IoT DL NB-DMRS, NB-PDSCH, NB-PBCH, NB-PDCCH, NB-RS, NB-PRS, Channels NB-PSS, NB-SSS Narrow band IoT UL NB-PUSCH, NB-PRACH Channels PDSCH, PDCCH, DMRS-PDSCH, PTRS-PDSCH, DMRS-PDCCH, NR DL Channels DRMS-PBCH, CSI-RS, PSS, SSS, SS Block / PBCH PUSCH, PUCCH, PRACH, DMRS-PUSCH, PTRS-PUSCH, DMRS- NR UL Channels PUCCH, SRS LTE TDD, FDD (normal and extended CP) Technologies NR TDD, FDD LTE: 1.4, 3, 5, 10, 15, 20 MHz Channel Bandwidth NR: up to 400MHz LTE: 15kHz, 7.5kHz, 1.25kHz LTE PRACH: 1.25kHz, 7.5kHz NB-IoT PRACH: 3.75kHz Subcarrier Spacing NR: 15, 30, 60, 120, 240 kHz NR Multi Numerology NR PRACH: 1.25, 5, 15, 30, 60, 120 kHz DL Transmission Modes: TM1 - TM10UL Transmission Modes: TM1, TM2 Carrier Aggregation eMBMS LTE Specific Features TTI-Bundling Semi-Persistent Scheduling (SPS) MIMO (SU / MU-MIMO) UE TAS (Tx Antenna Selection) FeICIC (ABS)Feature Supported system capabilitiesCoMP (DL / UL), Joint Transmission Short TTI eMTC NB-IOT (in band / guard band / standalone) License Assisted Access (LAA) Sidelink (Proximity Services) Dynamic TDD (eIMTA) Mission Critical PS-LTE Features (MCPTT) Positioning (PRS, OTDOA etc) V2X Distributed Antenna System Support CBRS Support EN-DC SSBlock BW Part NR Specific Features Supplementary UL Mini-slot LTE-NR Co-existence Analog Beamforming Digital Beamforming Beamforming Hybrid Beamforming O-RU Support for 64 TRX L2: Ethernet Transport L3: IPv4, IPv6 QoS over Fronthaul10.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 maybe 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-8 describes the capabilities required of O-DU and O-RU units. There are threechoices: 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-8: O-RAN mandatory and optional featuresO-DU O-RU Category Featuresupportsupport Additional informationSupport for Category-A O- MandatorNA The O-DU may only supportRU (up to 8 spatial streams) y fewer than 8 spatial streams; that number of spatial streams shall however be supported for Category-A O-RUs. O-RU Support for Category-A O-Optional NACategory RU (> 8 spatial streams) Support Support for Category-B O- Mandator NA RU (precoding in O-RU) y IEEE 802.1X supplicantOptional MandatorySecurity functionality

[0051] O-DU O-RUCategory Featuresupportsupport Additional informationGrand Master ClockOptional Optional Principles for Grand MasterRedundancy Clock redundancy are provided in Annex P.2.3.1 of IEEE 1588

[0033] . Guidelines are provided in Annex G of O-RAN Synchronization Architecture and Solution Specification

[0054] . Beam index based MandatorCondition Condition applies to UE- y al specific BF for any O-RU Mandator capable of BF; a non-BF O- y RU shall be supplied a zero beamId if a C-Plane message containing a beamId is sent at all. Real-time BF Weights Condition Condition Condition for O-DU: al al Mandatory only for O-DUs Mandator Mandator designed to support any kind y y of BF that involves the Beam- operation of updating BF forming weights in real-time; Condition for O-RU: for anyO-RU internally using BF weights, the ability to update the weights in real-time via C-Plane messages (using "Real-time BF Weights") shall be mandatory. Real-time beamformingOptional Optional This is considered to notattributes internally use BF weights. Real-time UE channel Info Optional Optional This is considered tointernally use BF weights.O-DU O-RUCategory Featuresupportsupport Additional informationPredefined beam tilt for beamOptional Optionalindex based beamforming Antenna calibration support Optional OptionalNull-layer Info. for ueId-Optional Optionalbased beamforming using Section Extension 14 User port group indication forOptional Optionalbeamforming based on UE channel (Section Extension 17) IQ Data Formats Fixed point (no compression) MandatorMandator 16-bit mandatory (others y y optional). Block floating point Condition Condition 9, 12 & 14-bit mantissa compression al al mandatory if this Mandator Mandator compression method is y ysupported (others optional).Condition: if an O-DU or O-RU supports any IQ Bandwidt compression it shall support h Saving this one. Block scaling compression Optional Optional 9 & 14-bit scaler mandatoryif this compression method is supported (others optional). ^-law compression Optional Optional 9 & 14-bit width mandatoryif this compression method is supported (others optional).O-DU O-RUCategory Featuresupportsupport Additional informationModulation compression Optional Optional 4-bit width mandatory ifthis compression method is supported (others optional). Exception: If the Alternative Modulation Compression is supported, bit widths 1, 2, 3, and 4 bits are mandatory (others optional). Block floating pointOptional Optional 9, 12 & 14-bit mantissacompression + selective RE mandatory if this sending compression method is supported (others optional). Modulation compression +Optional Optional 4-bit width mandatory ifselective RE sending this compression method is supported (others optional). Block floating pointOptional Optional 9, 12 & 14-bit mantissacompression + selective RE mandatory if this sending with sReSMask1 and compression method is sReSMask2 in U-plane supported (others optional). section header Modulation compression +Optional Optional 4-bit width mandatory ifselective RE sending with this compression method is sReSMask1 and sReSMask2 supported (others optional). in U-plane section headerO-DU O-RUCategory Featuresupportsupport Additional informationPresence of udCompLen Condition Optional If the O-RU declares supportal of udCompLen then it shall Mandator be used, otherwise it shall be y omitted (in DL and UL U- Plane messages); this is only relevant for block floating point with selective RE sending or modulation compression, with selective RE sending. Real-time variable bit-width Optional Optional IQ data format is determinedby value of udCompHdr. This implies presence of udCompHdr in U-Plane messages. Real-time variable bit-widthOptional Optional IQ data format is determinedper Channel (per data section) by value of udCompHdr. This implies presence of udCompHdr in U-Plane messages. Values of udCompHdr can be different in different sections in the U- Plane messages. Static configuration of U- Condition Condition IQ data format is determined Plane IQ format and al al by M-Plane configuration. compression header Mandator Mandator This implies absence of y y udCompHdr in U-Plane messages. Mandatory for supported IQ formats listed in first 7 rows under "IQ Data Formats" in this table.O-DU O-RUCategory Featuresupportsupport Additional informationBeamspace compression Optional Optional This compression algorithmis specific to beamforming weights. Channel informationOptional Optionalcompression No compression / Fixed Condition Condition 16-bit width for ciIsample point al al and ciQsample mandatory Mandatory Mandatory if the channel information based BF feature is supported (other bitwidthoptional). Block Floating Point Optional OptionalBlock Scaling Optional Optional^-law Optional OptionalUse of "symInc" flag to allowOptional Optionalmultiple symbols in a C- Plane section Coupling via sectionId Mandator Mandator Value y y Coupling via Frequency Condition Condition If O-RU or O-DU supports and Time al al "Coupling via Frequency and Mandator Mandator Time with Priorities" it shall y y also support this one. Coupling via Frequency andOptional OptionalTime with Priorities Coupling via Frequency andOptional Optional Refer to clause 7.8.1.5 andTime with Priorities clause 7.9.8 (Optimized) PRACH data transfer withoutOptional OptionalC-Plane SRS data transfer without C-Optional OptionalPlaneO-DU O-RUCategory Featuresupportsupport Additional informationEnergyTransmission blanking Optional OptionalSavings Defined Transport Method MandatorMandator y y Measured Transport MethodOptional Optional If O-RU supports Measured(eCPRI Msg 5) Transport Method it shall support both 1-Step and 2- step version of T12 measurement and at least one of 1-Step or 2-Step version of O-DU – T34 measurement. O-RU If the O-DU supports T34 Timing measurement it shall support both 1-Step and 2-Step version. See clause 4.4.4.4 for more detailed information. External Antenna DelayOptional Optional Using Tda and Tauhandling using Minimal O- parameters as defined in DU Impact Method clause 4.7.2.G.8275.1

[0031] ConditionCondition When the G.8275.1

[0031] al al profile is used: Mandator Mandator In LLS-C1 / C2 / C3, the O-RU y y shall be synchronized from a PTP source using this profile and may optionally use PLFS assistance as well In LLS-C1 / C2 / C3 / C4, the O- DU may optionally be synchronized from a PTP source using this profile and may optionally use PLFS assistance as well. In LLS-C1, the O-DU shall synchronize the O-RU using this PTP profile on the fronthaul interface. The O- Synchroni DU shall synchronize the O- -zation RU using PLFS as well only if the O-RU requires it (otherwise it is optional). In LLS-C2, the O-DU shall synchronize the fronthaul network elements using this PTP profile and PLFS on the fronthaul interface. In LLS-C3 / C4, the O-DU does not transmit synchronization signals to the O-RU. In LLS-C2 and LLS-C3 topologies supporting Shared cell, the network elements in the Fronthaul synchronization chain (FHM or cascaded O-O-DU O-RUCategory Featuresupportsupport Additional informationRus) that are on the path to other network elements in the synchronization chain shall synchronize them using this PTP profile and PLFS on the fronthaul interface. G.8275.2

[0032] Optional Optional When the G.8275.2

[0032] profile is used: O-DU (in LLS-C1 / C2 / C3 / C4) or O-RU (in LLS-C1 / C2 / C3) may optionally be synchronized from a PTP source using this PTP profile. In LLS-C1 / C2, O-DU may optionally synchronize the O- RU using this PTP profile on the fronthaul interface. Local PRTC Optional Optional O-DU (in LLS-C1 / C2 / C3 / C4)or O-RU (in LLS-C4) may optionally be synchronized from a local time source, for example GNSS-based. L2: Ethernet MandatorMandator y y L3: IPv4, IPv6 (CUS Plane) Optional OptionalQoS over Fronthaul MandatorMandator Transport y y Features Prioritization of different U-Optional OptionalPlane traffic types Support of Jumbo EthernetOptional OptionalframesO-DU O-RUCategory Featuresupportsupport Additional informationeCPRI MandatorMandator y y support of eCPRIOptional Optionalconcatenation IEEE 1914.3 transport header Optional Optional See clause 5.1.3.3.Application layer Mandator Mandator C-Plane and U-Plane. fragmentation y y Radio Transport layerOptional Optional U-Plane (see clausefragmentation 5.1.3.2.8).O-DU O-RUCategory Featuresupportsupport Additional informationSection Type 0 Optional MandatorO-RU may ignore message if y blanking or other Section Type 0 utility is not supported. Section Type 1 MandatorMandator y y Section Type 3 MandatorMandator y y SectionSection Type 4 Optional Optional Specific configurationTypes Control andSection Type 5 Optional Optional Specific to Channel-InfoSection beamforming. ExtensionSection Type 6 Optional Optional Specific to Channel-Infos beamforming. Section Type 7 Optional Optional Specific to LAA which is anoptional capability. Condition ConditionCondition: Mandatory if SEal al 22 for ACK / NACK request is Mandator Mandator supported. Specific to y y ACK / NACK reporting for section descriptions in C- Section Type 8 plane messagesO-DU O-RUCategory Featuresupportsupport Additional informationBeamforming weight Condition Condition Condition for O-DU: transfer using Section al al Mandatory only for O-DUs Extension 1 Mandator Mandator designed to support any kind y y of BF that involves the operation of updating BF weights in real-time; Condition for O-RU: for anyO-RU internally using BF weights, the ability to update the weights in real-time via C-Plane messages (using "Real-time BF Weights") shall be mandatory. Beamforming attributeOptional Optional Attribute-based beamformingtransfer using Section is optional. Extension 2 DL precoding configurationOptional Optional While Category B isusing Section Extension 3 mandatory, it is possible to precode using beamforming so use of this extension is optional. First Data Layer and Condition ConditionCondition: DL precodingNon-first data layer al al configuration using Section association Mandator Mandator Extension 3 is supported by y y O-DU and O-RU.O-DU O-RUCategory Featuresupportsupport Additional informationModulation compr. Condition Condition Condition for O-DU: If Parameters using Section al al modulation compression is Extension 4 Mandator Mandator supported then it is y y mandatory for O-DU to support Section Extension 4 Condition for O-RU: If modulation compression is supported and the O-RU does not support Section Extension 5 then it is mandatory for O- RU to support Section Extension 4 Modulation compr. Condition Condition Condition for O-DU: If Parameters using Section al al modulation compression is Extension 5 Mandator Mandator supported then it is y y mandatory for O-DU to support Section Extension 5. Exception: if the O-DU only supports alternative modulation compression, it is optional to support SE 5. Condition for O-RU: If modulation compression is supported and the O-RU does not support Section Extension 4 then it is mandatory for O- RU to support Section Extension 5 Non-contiguous PRBOptional Optional Use of non-contiguous PRBsallocation using Section is optional. Extension 6O-DU O-RUCategory Featuresupportsupport Additional informationeAxC masking using SectionOptional Optional Use of eAxC masking isExtension 7 optional. Provide MMSE parameters Condition Condition Specific to Channel-Info using Section Extension 8 al al beamforming; Mandator MandatorO-DU condition: if O-RUy y and O-DU both support Channel-Info BF, then the O- DU shall use Section Extension 8 to convey MMSE parameters; O-RU condition: if the O-RU supports Channel-Info BF, then the O-RU shall accept Section Extension 8 MMSE parameters from the O-DU. LTE / NR DSS using SectionOptional Optional DSS using overlappingExtension 9 carriers is possible; DSS using this Section Extension is optional. Group configuring ofOptional Optional Use of multiple port (multiplemultiple ports using Section eAxC) grouping is optional. Extension 10 Flexible BeamformingOptional Optional Use of flexible beamformingWeights using Section weights Section Extension is Extension 11 optional. contInd flag in SE 11 Optional Optional See clause 7.7.11.9bundleOffset in SE 11 Optional Optional See clause 7.7.11.10Non-contiguous PRBOptional Optionalallocation with frequency ranges using Section Extension 12O-DU O-RUCategory Featuresupportsupport Additional informationPRB allocation withOptional Optionalfrequency hopping usingSection Extension 13 Nulling-layer Info. for ueId-Optional Optionalbased beamforming using Section Extension 14 Mixed-numerology Info. forOptional OptionalueId-based beamforming using Section Extension 15 Antenna mapping in UEOptional Optional Use of antenna mapping inchannel information based UE channel information UL beamforming using based UL beamforming is Section Extension 16 optional. Indication of user port groupOptional Optionalusing Section Extension 17 Uplink traffic management Condition Condition Mandatory if uplink traffic using Section Extension 18 al al management using C-Plane is Mandator Mandator supported. Not permitted if y y uplink traffic management using C-Plane is not supported. Compact beamformingOptional Optional See clause 7.7.19 and 7.9.11.information for multiple port using Section Extension 19 Dedicated puncturing SectionOptional Optional See clause 7.7.20 and 7.9.12.using Extension 20 Variable PRB group size forOptional OptionalChannel Information using Section Extension 21 ACK / NACK request usingOptional Optional See clause 7.7.22 and 7.2.8Section Extension 22 for more details.O-DU O-RUCategory Featuresupportsupport Additional informationMultiple symbol Multiple symbol mcScaleOffset using Section Optional OptionalmcScaleOffset using Section Extension=23. (PRB-MASK Extension=23 mode) The default mode is PRB- MASK mode. O-RU can indicate support for PRB- PRB-BLOCK mode of BLOCK mode of Section Optional OptionalSection Extension 23 Extension 23 using M-plane advertised capability. Refer to clause 7.7.23.1 for more details. Time-domain beamformingOptional Optional See clause 7.5.3.38 andconfiguration using clause 7.7.9.2.1 for more st4CmdType(1) details TIME_DOMAIN_BEAM_C ONFIG TDD pattern configurationOptional Optional Refer to clause 7.5.3.38 andSection using st4CmdType(2) clause 7.7.9.2.2 for more Type 4 TDD_PATTERN_CONFIG details command Array-element-specificOptional Optional See clause 7.4.6 and 16 fors energy saving using more details st4CmdType(3) TRX_CONTROL O-RU energy saving usingOptional Optional See clause 7.4.6 and 16 forst4CmdType(4) Advancedmore details Sleep Mode (ASM) LAA LBT O-DU congestion Condition Condition Mandatory only for O-DUs Other window mgmt al al and O-RUS supporting LAA. features Mandator Mandator y yO-DU O-RUCategory Featuresupportsupport Additional informationLAA LBT O-RU congestionOptional Optionalwindow mgmt UL gain correction per eAxC Optional Optional See clause 8.1.3.2.3.DL reference levelOptional Optional See Reference_Level inadjustment clause 8.1.3.3. FS adjustment Optional Optional See FS_Offset in clause 8.1.3.Ordered transmission Optional Optional See clause 4.6.3.Uplink traffic managementOptional Optional See clause 4.6.4.using M-Plane Uplink traffic managementOptional Optional See clause 4.6.4.using C-Plane Uniformly distributedOptional Optional In accordance with clausetransmission 4.6.2. Requires support of uplink traffic management (using M-Plane or C-Plane). Independent U-PlaneOptional Optional According to clause 4.6.4.transmission window control Requires support of uplink traffic management (using M- Plane or C-Plane). C-Plane Message processingOptional Optional As specified in clause 7.8.2O-RU limits and M-Plane specification [7], clause 15.8. O-RU U-Plane messageOptional Optional As specified in clause 8.5.1.1limits and M-Plane specification [7], clause 15.10 beam-update-contention-Optional Optional See clause 12.4.3control Provision of beam-context-N / A Optional See clause 12.4.3gap-period UPLANE-ONLY-DL-MODE Optional Optional See clause 8.2.2O-DU O-RUCategory Featuresupportsupport Additional informationShared Cell Optional Optional For O-DU: support forconfiguring an FHM and / or cascaded O-RUs is optional. For O-RU: support for the shared-cell copy / combine function is optional. Disable sequence numberOptional Optional Refer to feature SEQ-ID-checking CHECKING- CONFIGURABLE in clause 5.1.3.2.7 and Table 5.1.3.2.7-1. Defined-duration sleep Optional Optional Separately forTRX_CONTROL and ASM, see clause 16.4 Undefined-duration sleep Optional Optional Separately forTRX_CONTROL and ASM, see clause 16.5 Sleep extension Optional Optional Separately forTRX_CONTROL and ASM; only applies if defined- duration sleep is supported, see clause 16.9 Sleep modes Optional Optional Any of the four possible sleepmodes may be supported, separately for TRX_CONTROL and ASM; see clause 16.1 Section Type 8 "ready"Optional Optional Only applies if Section Typemessage (see 16.6.2) 8 is supported, see clause 7.5.3.56 and 16.6.2 M-Plane emergency wake-up Optional Optional See clause 16.12NB-IoT NB-IoT support Optional Optional See clause 15O-DU O-RUCategory Featuresupportsupport Additional informationExtended PRB grid method Condition Condition Condition: O-DU / O-RU for NB-IoT in DL al al supports guard-band NB-IoT Mandatory Mandatory in DL. See clause 15.2.1 for the description of the method Extended PRB grid methodOptional Optional See clause 15.4.3 for thefor NB-IoT UL description of the method SSSC method for NB-IoT in Condition Condition Condition: O-DU / O-RU UL using ST 3 al al supports guard-band or in- Mandatory Mandatory band NB-IoT. See clause 15.4.1 for the description of the SSSC method SSMC method for NB-IoT inOptional Optional See clause 15.4.2 for theUL using ST 3 description of the SSMC method Extended PRACHOptional Optional See feature EXTENDED-configuration for PRACH PRACH-CONFIGURATION data transfer without C-Plane in M-plane. for NPRACHNOTE 1: When a capability that is "per endpoint" is cited as mandatory in the O-RU, it means atleast one endpoint shall support it (a minimum number meaningful for the functionality of the O-RU), not that ALL endpoints shall support it. NOTE 2: For some mandatory capabilities, only a subset of the full set of parameter values is mandatory, this is marked in the "Additional information" column. If an optional capability is supported, the "additional information" column lists the parameter values that shall besupported; support for other parameter values of the optional capability remains optional.Annex A (normative): Compression methodsA.1 Block floating point compression…A.5 Modulation compressionModulation compression is an IQ data compression method that may be applied to DL data only and depends on the observation that modulated data symbols are represented by a very limited number of I and Q bits. For example, a QPSK modulated symbol has only two potential states of I and two potential states of Q, so such a symbol is representable with no loss of information with a single bit of I and a single bit of Q. Likewise, a 64QAM constellation point (8x8 constellation) is representable by at most 3 bits of I and 3 bits of Q. This allows for a reduction in DL throughput. To represent the constellation points as I and Q values that also overlap allowing multiple constellation sizes to be represented by a single word-width, the constellations shall be "shifted" to allow a two's-complement I and Q value to represent any constellation point. Error!Reference source not found. shows the same constellations after shifting.Once the constellations are shifted, the I and Q values shall be encoded in a limited number of bits, being the larger number needed to represent the largest constellation possible in the compression block (the data section). This means that if some data in the section use 64QAM and others use QPSK (e.g., a reference RE) all REs would use the largest needed representation which in this example is 3 bits for I and 3 bits for Q (for 64QAM). This spoils the compression efficiency a little bit but because reference REs are a small fraction of the total number of REs, the efficiency degradation is small (there is further clarification below regarding mixing MCS in a data section). In general, every user has its own data section (and own beamforming index), so users with high-order modulation need and use more bits of I and Q while users with lower- order modulation need and use fewer bits of I and Q. Some constellations need not be shifted. For example, BPSK needs I and Q data to take the values −1 / 2, zero, and +1 / 2 (different varieties of BPSK rotate these as with ^ / 4 BPSK and ^ / 2 BPSK). For this reason, BPSK would use two bits for I and 2 bits for Q; while this seems counterintuitive (BPSK using more bits than QPSK) this is a small penalty given the rarity of BPSK as a modulation type. Here, BPSK shall not be shifted. Likewise, PHICH constellations encode 3 states for each I and Q: −1, zero and 1. For this constellation the representation shall be−½, 0 and ½ with no constellation shift needed. However, constellations of all QAM modulations shall be shifted (except in mixed-MCS cases). Applied constellation shift shall beindicated by the "csf" field, where for every bit set (=1) in the reMask "csf" indicates whether toshift (csf=1) or not (csf=0) the associated RE. Mixed-MCS cases represent another example when constellations shall not be shifted. This occurs when user data REs (at high MCS) and signaling data REs (at low MCS) are in the samePRB – hence in the same data section. The reMask discriminates the REs at high MCS from theREs at the lower MCS (and provides different modCompScaler or mcScaleOffset values for the different-MCS data), but all the REs in the PRB shall use the same number of I and Q bit- widths. In this case only the high-MCS constellation shall be shifted, the lower-MCS constellation shall not be shifted, because its data points already overlap with the shifted high- MCS data points. For instance, for overlain 16QAM and 64QAM, the high-MCS points are shifted by ½ the high- MCS resolution (here, −1 / 8) to allow all points to share the same "grid", as shown in the middlesubfigure, wherein the 16QAM AND 64QAM points overlay. All I and Q values in the givenexample are represented by 3 bits each on the fronthaul interface. The O-DU shall use the constellation shift flag (csf) to tell the O-RU which data (64QAM points) to "unshift" by adding 1 / 8 to them, thereby restoring the original constellation values. After that, modCompScaler (or mcScaleOffset) shall be applied to set the data to the correctpower levels (separate modCompScaler or mcScaleOffset values may be used for the differingMCS data). When decompressing, the O-RU shall "unshift" the constellation depending on "csf" value andapply a scale factor for the constellation types represented in the section. There shall be eitherone or two modulation types in one section. The modulation type shall be inferred from the reMask bits, where each "one" bit indicates the shift command ("csf") and scale factor ("modCompScaler" when using Section Extension 4, and "mcScaleOffset" when using SectionExtension 5) for the REs in the subject PRB. The scale factor allows not only for correcting fordifferent constellation scaling (e.g., for multiplexed channel data in a PRB including QPSK and16QAM, QPSK involves a 2⁄ √2 factor while 16QAM involves a 4⁄ √10 factor), but also allowsfor different channel power scaling which is permitted as a 3GPP option. NOTE: Modulation compression method is essentially lossless, except that the scale factors, being 15 bits, impose a limit on the accuracy of representation. 15 bits is consideredsufficient for all LTE and NR data representations.When compressing, constellation points shall be shifted by the shift value defined in Table 7.7.4.2-2, and the I and Q values shall be represented as signed two's complement fractional notation and included in the U-Plane message as udIqWidth bit vectors, where udIqWidth is dependent on the modulation constellation type and is defined in Table 7.7.4.2-2. The following pseudo code depicts an example implementation of the modulation decompression algorithm:1. Read ^^^^^^^^ as an udIqWidth bit vector in the U-Plane message [this is all the IQ data inthe data section]2. Map ^^^^^^^^ [0,2^^^^^^^^^ − 1] to ^^^^^^^^^^ [−1,1) assuming that the udIqWidth bitsare represented as Q1.(udIqWidth-1) [this is the normal twos-complement representation of the I and Q samples represented in fractional notation]. 3X. For each RE in the PRB (using Section Extension 4): 3Xa: fetch the "csf" and "modCompScaler" values for which this RE has a "1" in the reMask 3Xb. If "^^^" == 1 then ^^^^^^^^^^ = ^^^^^^^^^^ + 2^^^^^^^^^^ [this is "unshifting"the constellation point]. 3Xc. ^^^^^^^^^^^^^^ = modCompScaler × ^^^^^^^^^^ × √2 [this scales theconstellation point] 3Y. For each RE in the PRB (using Section Extension 5): 3Ya: fetch the "csf" and "mcScaleOffset" values for which this RE has a "1" in the relevant mcScaleReMask 3Yb. If "^^^" == 1 then ^^^^^^^^^^ = ^^^^^^^^^^ + 2^^^^^^^^^^ [this is "unshifting"the constellation point]. 3Yc. ^^^^^^^^^^^^^^ = mcScaleOffset × ^^^^^^^^^^ × √2 [this scales the constellationpoint]After decompression, | iqSampleScaled | shall be ≤ 1 and a value of | iqSampleScaled | = 1.0matches 0 dBFS. Alternative Modulation Compression mode of operationIf the O-RU indicates support for alternative Modulation Compression by M-plane parameteralternative-modcomp-supported and the O-RU has enabled it by setting alternative-modcomp-enabled to TRUE, then operation of modulation compression changes for allcompression methods including Modulation Compression. Bits sent over U-Plane are taken directly from the DL FEC encoder where I and Q are Gray coded and interleaved. Since U-plane only allows a single bit-width per PRB, separate eAxCs are in general needed when DL reference signals (e.g., DMRS) are multiplexed with downlink data (PDSCH). Each downlink channel is sent with the number of bits required by the constellation, e.g., bit-width 1 (per I and Q) for QPSK, 2 for 16-QAM, 3 for 64-QAM, and 4 for 256-QAM. Any constellation shift flags (e.g., csf in SE 4, SE 5, or SE 23) shall be ignored by the O-RU and should be set to zero by the O-DU. Bits output from the O-DU Forward Error Correction (FEC) encoder are denoted b(i), where i={0,1,2,…}. In Table A.5-1 an example is given of U-plane data transfer for two PRBs when 64-QAM is used. Bits sent in U-plane will have same order as in the FEC encoder output, i.e., even-index bits, {b(0), b(2), b(4), …}, belong to I while odd-index bits {b(1), b(3), b(5), …} belong to Q. The bits belonging to the first PRB have shaded background in the table.^ Table A.5-1: U-plane bit ordering example for two PRBs when alternativeModulation Compression is used with 64-QAM modulation. The bits for the first PRB have shaded background. 01 2 3 4 5 6 7 (lsb) Numbe(msb) r of Octets Octetb(0) b(1) b(2) b(3) b(4) b(5) b(6) b(7) 1 Nb(8) b(9) b(10) b(11) b(12) b(13) b(14) b(15) 1 N+1…b(64) b(65) b(66) b(67) b(68) b(69) b(70) b(71) 1 N+8b(72) b(73) b(74) b(75) b(76) b(77) b(78) b(79) 1 N+9b(80) b(81) b(82) b(83) b(84) b(85) b(86) b(87) 1 N+10…b(136) b(137) b(138) b(139) b(140) b(141) b(142) b(143) 1 N+17APPENDIX B Modulation Defined in 38.211In case of QPSK modulation, pairs of bits, b (2 i ), b (2 i ^ 1) , are mapped to complex-valuedmodulation symbols d(i ) according toIn case of 16QAM modulation, quadruplets of bits, b (4 i ), b (4 i^ 1), b (4 i ^ 2), b (4 i ^ 3) , are mapped tocomplex-valued modulation symbols d(i ) according toIn case of 64QAM modulation, hextuplets of bits, b (6 i ), b (6 i^ 1), b (6 i ^ 2), b (6 i ^ 3), b (6 i ^ 4), b (6 i ^ 5) ,are mapped to complex-valued modulation symbols d(i ) according toIn case of 256QAM modulation, octuplets of bits, b(8 i ), b (8 i^ 1), b (8 i ^ 2), b (8 i ^ 3), b (8 i ^ 4), b (8 i ^ 5), b (8 i ^ 6), b (8 i ^ 7) , are mapped to complex-valuedmodulation symbols d(i ) according toMapping from Gray code to signed two’s complement 3GPP specifies gray-coded I and Q indices where the constellation energy is normalized to unity (equiprobable constellation points)In O-RAN LLS ModComp, the O-DU sends I and Q in signed two’s complement format, each with magnitude ≤ 1 For QPSK there is no difference between 3GPP and O-RAN constellation point representation For other modulation orders, a mapping is needed for conversion Proposal Introduce an optional alternative ModComp where translation from FEC output (interleaved Gray code bits) to signed two’s complement is performed in the O-RU instead of in the O-DU The alternative ModComp should also apply to Selective RE sending with ModComp Selective RE sending as specified in CUS v14 The O-RU declares support for the feature via M-Plane (per O-RU) and the O-DU can configure the feature via M-Plane (per O-RU) A given O-DU and O-RU pair can either use current ModComp or the alternative, never a mix Only one modulation order supported per section Different eAxCs needed for PDSCH DMRS and PDSCH data if PDSCH is rate-matched around DMRS Bit-widths are different and U-plane cannot refer to same PRB more than once for same eAxC SE 4 can be used to convey modCompScaler (csf will be ignored) No benefit of using SE 5 over SE 4 when single scale factor is used per eAxC Example for 64-QAM: Instead of sending O-RAN ModComp values, we want to sent b(i) values directly FEC output b(i) = 100101110110… Separation into Gray-coded I, Q for RE k cI(k): {100, 101, …}cQ(k): {011, 110, …} Mapping to 3GPP constellation point (unit energy) d(k): {-3+7j, -1-5j,…} / √42 O-RAN constellation point (divide by √64 instead of √42) IQ(k): {-0.375+0.875j, -0.125-0.625j, …} O-RAN ModComp (signed two’s complement) I(k): {110, 111, …} Q(k):{011, 101, …} Interface bit ordering example for 64-QAM (bit width = 3) PDSCH FEC output (64-QAM, full PRBs) b(i) = 100101110110… where i=0, 1, 2, … For 64-QAM, there will be 6×12=72 bits per PRB if no selective RE sending is used No zero-padding between PRBs When all 12 REs are sent, PRBs will always start on a byte boundary CUS v14, Annex A.6: For selective RE sending with sReSMask in Section header, there shall be no zero padding between bits for different PRBs, only after the last PRB in the section Interface bit ordering example for DMRS (bit width = 1) with selective RE sending (mask in Section header) PDSCH DMRS output (QPSK, comb-2) b(i) = 100101110110… where i=0, 1, 2, …For QPSK, comb-2, there will be 2×6=12 bits per PRB when selective RE sending is used (2 bits per RE, every second RE sent) First PRB visualized with pale blue background (no zero padding) CUS v14, Annex A.6: For selective RE sending with sReSMask in Section header, there shall be no zero padding between bits for different PRBs, only after the last PRB in the section Support for current ModComp indicated in o-ran-compression-factors.yang typedef compression-method-def { type enumeration { enum MODULATION { description "Modulation compression and decompression method"; } enum MODULATION-COMPRESSION-SELECTIVE-RE-SENDING { description "modulation compression with selective re sending compression and decompression method"; } enum MOD-SRES-MASK-IN-SEC-HEADER { description "modulation compression with selective re sending compression and decompression method with selective re sending mask in the sectionheader"; } } We propose an M-plane configuration that changes bit ordering for all supported types of ModComp No need to enumerate additional compression formats since there is no intent to mix current and alternative ModComp for same O-DU, O-RU pair Mandatory / Optional The Alternative Modulation Compression is optional to support for O-DU and O-RU Bit width support (Conditional Mandatory) If alternative Modulation Compression is supported, bit widths 1–4 bits are mandatory to support Summary O-RAN LLS ModComp does not use the 3GPP modulation format over the fronthaul interface Separation of I and Q in FEC encoder output, and mapping from Gray-coded indices to signed two’s complement done in O-DU before sending to O-RU Some O-DUs and / or O-RUs can be more efficient if ‘b(i)’ bits as output from FEC are sent in U- Plane Propose to add an optional alternative ModComp variant where the bits are sent as output from FEC Interleaved bits for I and Q with Gray-coded representation Controlled via M-Plane and applies to any ModComp supported by the O-RU (normal ModComp and selective RE sending variants with ModComp) CUS v14, A.6: No zero-padding between PRBs in the data section when sReSMask is in header PDSCH and DMRS must be sent on different eAxC since bit width differsSE 4 can be used to convey modCompScaler (csf will be ignored)

Claims

CLAIMS1. A method for configuring a modulation table (22), the method being performed by a radiounit, RU, (202) of a network node (120a-b, 1200), the method comprising: receiving (40) a command (30) to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and configuring (42) a modulation table (22) in accordance with the command.

2. The method according to claim 1, wherein the receiving (40) a command comprisesreceiving the command from a distributed unit, DU, (200) via a control plane, C-plane (204).

3. The method according to claim 1, wherein the receiving (40) a command comprisesreceiving the command from a DU via a management plane, M-plane (203).

4. The method according to any one of the preceding claims, further comprising:selecting (44) a modulation based on a modulation selection parameter (32) that isreceived from the DU.

5. The method according to claim 4, wherein the modulation selection parameter (32) is partof a parameter originally intended for indicating the number of bits for I values and Q values in each IQ sample.

6. The method according to any one of the preceding claims, further comprising:performing (47) unit-energy normalization on the modulation constellation; and subsequent to performing the unit-energy normalization on the modulation constellation, applying (48) a scale factor to the modulation constellation.

7. The method according to claim 6, wherein the performing (47) the unit-energynormalization on the modulation constellation comprises dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.

8. The method according to any one of the preceding claims, further comprising repetitivelyperforming: receiving (45) a symbol code (34) from the DU; andderiving (46) an IQ value (36) for radio transmission to a user equipment, UE, (110, 1100, 1506) based on the symbol code (34).

9. The method according to claim 8, wherein the deriving (46) an IQ value comprisesfinding, for the symbol code (34), a corresponding IQ value (36) in the modulation table (22), wherein the modulation table (22) defines correspondences between IQ values (36) ofconstellation points and respective symbol codes (34).

10. A radio unit, RU, (202) for configuring a modulation table (22), the RU (202) beingconfigured to form part of a network node (120a-b, 1200), the RU (202) comprising: processing circuitry (60); and memory circuitry (64) storing instructions (67) that, when executed by the processing circuitry, cause the RU (202) to: receive a command (30) to define IQ, in-phase quadrature phase, values (36) ofconstellation points of a modulation table (22); and configure a modulation table (22) in accordance with the command.

11. The RU (202) according to claim 10, wherein the instructions to receive a commandcomprises instructions (67) that, when executed by the processing circuitry, cause the RU (202)to receive the command from a distributed unit, DU, (200) via a control plane, C-plane (204).

12. The RU (202) according to claim 10, wherein the instructions to receive a commandcomprise instructions (67) that, when executed by the processing circuitry, cause the RU (202)to receive the command from a DU via a management plane, M-plane (203).

13. The RU (202) according to any one of claims 10 to 12, further comprising instructions(67) that, when executed by the processing circuitry, cause the RU (202) to: select a modulation based on a modulation selection parameter (32) that is received fromthe DU.

14. The RU (202) according to claim 13, wherein the modulation selection parameter (32) ispart of a parameter originally intended for indicating the number of bits for I values and Q values in each IQ sample.

15. The RU (202) according to any one of claims 10 to 14, further comprising instructions(67) that, when executed by the processing circuitry, cause the RU (202) to: perform unit-energy normalization on the modulation constellation; and subsequent to performing the unit-energy normalization on the modulation constellation, apply a scale factor to the modulation constellation.

16. The RU (202) according to claim 15, wherein the instructions to perform the unit-energynormalization on the modulation constellation comprises dividing coordinates of the modulation constellation by a square root of an energy of the modulation constellation.

17. The RU (202) according to any one of claims 10 to 16, further comprising repetitivelyexecuting instructions (67) that, when executed by the processing circuitry, cause the RU (202) to: receive a symbol code (34) from the DU; andderive an IQ value (36) for radio transmission to a user equipment, UE, (110, 1100, 1506)based on the symbol code (34).

18. The RU (202) according to claim 17, wherein the instructions to derive an IQ valuecomprise instructions (67) that, when executed by the processing circuitry, cause the RU (202)to find, for the symbol code (34), a corresponding IQ value (36) in the modulation table (22), wherein the modulation table (22) defines correspondences between IQ values (36) of constellation points and respective symbol codes (34).

19. A computer program (67, 91) for configuring a modulation table (22) by a radio unit, RU,(202) of a network node (120a-b, 1200), the computer program comprising computer program code which, when executed on the RU (202) causes the RU (202) to: receive a command (30) to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and configure a modulation table (22) in accordance with the command.

20. A computer program product (64, 90) comprising a computer program according to claim 19 and a computer readable means comprising non-transitory memory in which the computer program is stored.

21. A method for configuring a modulation table (22), the method being performed by adistributed unit, DU, (200) of a network node (120a-b, 1200), the method comprising: generating (50) a command to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and sending (51) the command (30) to a radio unit, RU (202), to configure a modulation table (22) in accordance with the command.

22. The method according to claim 21, wherein the sending (51) the command comprisessending the command to the RU via a control plane, C-plane.

23. The method according to claim 21, wherein the sending (51) the command comprisessending the command from a DU via a management plane, M-plane.

24. The method according to any one of claims 21 to 23, further comprising:selecting (52) a modulation table (22) to use; andsending (53) a modulation selection parameter (32) to the RU (202).

25. The method according to any one of claims 21 to 24, further comprising, for each symbolto be transmitted to a user equipment, UE (110, 1100, 1506): determining (54) a constellation point in the selected modulation table (22) to be used for the symbol; finding (55) a symbol code for the constellation point based on the selected modulation table (22); and sending (56) the symbol code to the RU.

26. The method according to claim 25, wherein the finding (55) a symbol code comprisesfinding, for the constellation point, a corresponding symbol code (34) in the modulation table (22), wherein the modulation table (22) defines correspondences between IQ values (36) of constellation points and respective symbol codes (34).

27. A distributed unit, DU, for configuring a modulation table (22), the DU (200) beingconfigured to form part of a network node (120a-b, 1200), the DU (200) comprising: processing circuitry (60); and memory circuitry (64) storing instructions (67) that, when executed by the processing circuitry, cause the DU (200) to: generate a command to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and send the command (30) to a radio unit, RU (202), to configure a modulation table (22) in accordance with the command.

28. The DU (200) according to claim 27, wherein the instructions to send the commandcomprise instructions (67) that, when executed by the processing circuitry, cause the DU (200) to send the command to the RU via a control plane, C-plane.

29. The DU (200) according to claim 27, wherein the instructions to send the commandcomprise instructions (67) that, when executed by the processing circuitry, cause the DU (200)to send the command from a DU via a management plane, M-plane.

30. The DU (200) according to any one of claims 27 to 29, further comprising instructions(67) that, when executed by the processing circuitry, cause the DU (200) to: select a modulation table (22) to use; andsend a modulation selection parameter (32) to the RU (202).

31. The DU (200) according to any one of claims 27 to 30, further comprising instructions(67) that, when executed by the processing circuitry, cause the DU (200) to, for each symbol to be transmitted to a user equipment, UE (110, 1100, 1506): determine a constellation point in the selected modulation table (22) to be used for thesymbol; find a symbol code for the constellation point based on the selected modulation table (22);and send the symbol code to the RU.

32. The DU (200) according to claim 31, wherein the instructions to find a symbol codecomprise instructions (67) that, when executed by the processing circuitry, cause the DU (200)to find, for the constellation point, a corresponding symbol code (34) in the modulation table(22), wherein the modulation table (22) defines correspondences between IQ values (36) of constellation points and respective symbol codes (34).

33. A computer program (67, 91) for configuring a modulation table (22) by a distributed unit,DU, (200) of a network node (120a-b, 1200), the computer program comprising computer program code which, when executed on a DU (200) causes the DU (200) to: generate a command to define IQ, in-phase quadrature phase, values (36) of constellation points of a modulation table (22); and send the command (30) to a radio unit, RU (202), to configure a modulation table (22) in accordance with the command.

34. A computer program product (64, 90) comprising a computer program according to claim33 and a computer readable means comprising non-transitory memory in which the computer program is stored.

Images