Patent Description:
5GNR is part of a continuous mobile broadband evolution promulgated by Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with Internet of Things (IoT)), and other requirements.

<CIT> discloses a method performed by a first unit of a base station system of a wireless communication network, for handling a signal for transmission over a fronthaul link between the first unit and a second unit of the base station system. The method comprises receiving the signal comprising at least one complex value, each complex value consisting of two subparts, a real part and an imaginary part, the subparts each being represented by a first number of bits, and transmitting the signal over the fronthaul link to the second unit. At least two subparts of the at least one complex value are represented in a subgroup, the subgroup being a binary codeword comprising an integer number of bits that is a multiple of a second non-integer number of bits allocated per subpart, the second non-integer number of bits being fewer than the first number of bits.

<NPL>, discloses that the user data compression header defines the compression method and IQ bit width for the user data in every section in the C-Plane message.

Aspects of the disclosure are set out in the independent claims.

Frequency range bands include frequency range <NUM> (FR1), which includes frequency bands below <NUM>, and frequency range <NUM> (FR2), which includes frequency bands above <NUM>. Although a portion of FR1 is greater than <NUM>, FR1 is often referred to (interchangeably) as a "Sub-<NUM>" band in various documents and articles. A similar nomenclature issue sometimes occurs with regard to FR2, which is often referred to (interchangeably) as a mmW band in documents and articles, despite being different from the EHF band which is identified by the International Telecommunications Union (ITU) as a mmW band.

Communications using the mmW / near mmW radio frequency (RF) band (e.g., <NUM> - <NUM>) has extremely high path loss and a short range. Base stations / UEs may operate within one or more frequency range bands.

In some examples, a base station <NUM>/<NUM> may be a radio unit (RU) that is connected to the core network <NUM> or EPC <NUM> via a distributed unit (DU) <NUM>. The RU and DU may communicate frequency-domain baseband samples referred to as IQ data. As illustrated in <FIG>, the DU <NUM> may include a bitwidth component configured to signal a maximum IQ data bitwidth for downlink communication associated with a section ID and to signal a bitwidth parameter for the downlink communication per PRB, as described herein. The DU <NUM> may transmit downlink communication to the RU (e.g., base station <NUM>/<NUM>) based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB. The RU may include a bitwidth component <NUM> configured to receive the first indication of a maximum IQ data bitwidth for downlink communication associated with a section ID and the second indication of a bitwidth parameter for the downlink communication per a PRB. The RU may then receive downlink communication from the DU <NUM> based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB.

In some examples, the bitwidth component <NUM> may be configured to signal, to the RU (e.g., base station <NUM>/<NUM>), a maximum IQ data bitwidth for uplink communication in a C-plane message and to receive a bitwidth parameter for the uplink communication per a PRB, e.g., from the RU. The DU <NUM> may then receive the uplink communication from the RU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB. Similarly, the bitwidth component <NUM> may be configured to receive, from the DU <NUM>, a first indication of a maximum IQ data bitwidth for uplink communication in a C-plane message and to transmit a second indication of a bitwidth parameter for the uplink communication per a PRB.

In the examples provided by <FIG>, the <NUM> NR frame structure is assumed to be TDD, with subframe <NUM> being configured with slot format <NUM> (with mostly DL), where D is DL, U is UL, and F is flexible for use between DL/UL, and subframe <NUM> being configured with slot format <NUM> (with mostly UL).

For slot configuration <NUM>, different numerologies µ <NUM> to <NUM> allow for <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> slots, respectively, per subframe. Accordingly, for slot configuration <NUM> and numerology µ, there are <NUM> symbols/slot and 2µ slots/subframe. <FIG> provide an example of slot configuration <NUM> with <NUM> symbols per slot and numerology µ=<NUM> with <NUM> slots per subframe. The slot duration is <NUM>, the subcarrier spacing is <NUM>, and the symbol duration is approximately <NUM>. Within a set of frames, there may be one or more different bandwidth parts (BWPs) (see <FIG>) that are frequency division multiplexed. Each BWP may have a particular numerology.

A PDCCH within one BWP may be referred to as a control resource set (CORESET). Additional BWPs may be located at greater and/or lower frequencies across the channel bandwidth. The physical broadcast channel (PBCH), which carries a master information block (MIB), may be logically grouped with the PSS and SSS to form a synchronization signal (SS)/PBCH block (also referred to as SS block (SSB)).

A base station may be configured with a distributed radio access network (D-RAN) architecture. <FIG> is a diagram <NUM> illustrating an example D-RAN architecture. In the D-RAN architecture, both the baseband unit (BBU) <NUM> and the remote radio unit (RRU) <NUM>, such as antennas and RF frontend, may be deployed together in each base station <NUM>. The RRU <NUM> may be used in telecommunication as an interface to communicate with UEs <NUM>, such that UEs <NUM> may be able to communicate with the core network (e.g., EPC <NUM>) through the RRU <NUM>. The RRU <NUM> may communicate with the BBU <NUM> via fibers (e.g., optical fibers) and the Ethernet protocol, and the BBU <NUM> may communicate with the core network via a backhauls (BH) network. The hardware and/or software for the BBU <NUM> and the RRU <NUM> within each base station <NUM> may be proprietarily owned and managed by different vendors (e.g., telecommunication companies), and the interface used for accessing the BBU <NUM> and the RRU <NUM> may also be proprietarily owned by the vendors. As such, under the D-RAN architecture, BBUs <NUM> and/or RRUs <NUM> from different vendors may be incompatible with each other, where a network operator who wants to set up a base station <NUM> may need to purchase both the RRU <NUM> and the BBU <NUM> from the same vendor. Thus, the D-RAN architecture may limit the interoperability between different network equipment.

The open radio access network (O-RAN) Reference Architecture is designed to enable next generation RAN infrastructures. Empowered by principles of intelligence and openness, the O-RAN architecture is the foundation for building the virtualized RAN on open hardware, with embedded AI-powered radio control, that has been envisioned by operators around the globe. The architecture is based on well-defined, standardized interfaces to enable an open, interoperable supply chain ecosystem in full support of and complimentary to standards promoted by 3GPP and other industry standards organizations. In order to enhance and achieve the interoperability between baseband processing equipment and radio equipment from different vendors, some networks may employ an O-RAN architecture.

<FIG> is a diagram <NUM> illustrating an example of O-RAN architecture. Under the O-RAN architecture, the hardware portions of a network, such as the RRU <NUM>, may be disaggregated from the software portions of the network, such as the BBU <NUM>. For example, multiple BBUs <NUM> corresponding to different RRUs <NUM> may be allocated in a centralized location (e.g., BBU station <NUM>), where each BBU <NUM> may be connected to its RRU <NUM> via an Ethernet connection. The multiple BBUs <NUM> within the BBU station <NUM> may be running on the same software, which may be a proprietary software. However, the software may be designed to be compatible with and operable by a general purpose (e.g., generic) hardware, such as commercial off-the-shelf (COTS) servers. Using this approach, the BBU <NUM> and the RRU <NUM> may be designed to have an open interface such that the RRU <NUM> from one vendor may interact with the BBU <NUM> from another vendor, thereby achieving the interoperability for radio equipment (e.g., RRU, BBU) from different vendors. For example, a network operator may purchase the BBU <NUM> from a particular vendor and the BBU <NUM> may work with the RRU <NUM> from another vendor as long as a correct interface is configured. In addition, a network operator may also run different types of software (e.g., BBUs <NUM>) on hardware such as by purchasing multiple licenses for the software. This may reduce the hardware cost for setting up the network for network operators and enable quick expansion of the network. In other words, the O-RAN may be characterized as an emerging form of virtualized network architecture built on general-purpose, commercial off-the-shelf hardware. The architecture may allow for a combination of different hardware and software and can be simply integrated and upgraded via software.

Under the O-RAN architecture, functions within the BBU <NUM> may further be disaggregated, where a network operator may have an option to purchase a specific function for a particular operation. <FIG> is a diagram <NUM> illustrating an example O-RAN logical architecture, which may comprise multiple network functions and components such as a Service Management and Orchestration Framework, a Near-Real Time RAN Intelligent Controller (RIC), a base station (e.g., O-eNB), a Central Unit - Control Plane (CU-CP), a Central Unit - User Plane (CU-UP), a Distributed Unit (DU) <NUM> (e.g., O-RAN Distributed Unit (O-DU)), a Radio Unit (RU) <NUM> (e.g., O-RAN Radio Unit (O-RU)), and/or a Cloud Unit, etc. An O-RAN fronthaul (O-RAN FH) corresponds to the open interface between the O-DU and O-RU to achieve the interoperability goal. Each of these functions or components may be operated by different vendor. For example, a first vendor may provide the base station, a second vendor may provide the CU-UP, and a third vendor may provide the CU-CP, etc. Functions and/or components may communicate with each other through specific interfaces, for example, the CU-CP and the CU-UP may communicate with the Near-Real Time RIC via the E2 interface, the Service Management and Orchestration Framework may communicate with DU and RU via the O1 interface, etc. The DU <NUM> may communicate with the RU <NUM> via a fronthaul interface (e.g., Open Fronthaul CUS-Plane, Open Fronthaul M-Plane, etc.), and there may be a split of functionality between the DU <NUM> and the RU <NUM> where the DU <NUM> and the RU <NUM> may each be configured to handle different network functionalities (e.g., PHY layer processing) within the O-RAN.

<FIG> is a diagram <NUM> illustrating an example of functional split between a central unit (CU) <NUM> and a DU <NUM> in a network. The CU <NUM> may be a logical node that includes the base stations functions such as transferring of user data, mobility control, session management etc., except functions exclusive to the DU <NUM>. The CU <NUM> may be connected to the core network (e.g., EPC <NUM>) via a backhaul (BH) interface, and may control the operation of multiple DUs <NUM> over a midhaul (e.g., MH or F1) interface. The DU <NUM> may be a logical node that includes a subset of the base station functions, where its operation may be controlled by the CU <NUM>. The DU <NUM> may further be split or separated into the DU <NUM> and the RU <NUM> under the O-RAN architecture, such as described in connection with <FIG> and <FIG>, where the DU <NUM> may communicate with the RU <NUM> via the FH interface. The network functionalities, such as functionalities associated with the PDCP, RLC, MAC, PHY network layers, etc., may be split between the CU <NUM>, the DU <NUM> and the RU <NUM>, such as based on the options <NUM> to <NUM> of <FIG>. For example, the functionalities may be split on option <NUM> and option <NUM> (e.g., Split Option <NUM>-2x, Option <NUM> Split, etc.) such that the CU <NUM> may be responsible for processing functionalities associated with the RRC and PDCP layers, the DU <NUM> may be responsible for processing functionalities associated with the RLC, MAC and HI-PHY (e.g., PHY-High) layers, and the RU <NUM> may be responsible for processing functionalities associated with the LO-PHY (e.g., PHY-Low) and RF layers, etc..

<FIG> is a diagram <NUM> illustrating an example of O-RAN fronthaul adopting function split at option <NUM> and option <NUM> between the CU <NUM>, the DU <NUM> the RU <NUM>. The PHY-High layer <NUM> within the DU <NUM> may comprise functions such as scrambling, modulation, layer mapping, precoding (e.g., Category A), resource element mapping and/or IQ compression, etc. The PHY-Low and RF layer <NUM> within the DU <NUM> may comprise functions such as IQ decompression, precoding (e.g., Category B), digital beamforming, iFFT and CP addition, digital to analog conversion, and/or analog beamforming, etc. In O-RAN, there may be two types of precoding for the RU, Category A (e.g., CAT A) and Category B (e.g., CAT B), depending on where the precoding occurs. For example, for Category A, the precoding may occur at the DU <NUM> and the precoding may not be supported at the RU <NUM>, and the RU <NUM> may be referred to as a non-precoding O-RAN RU. On the other hand, for Category B, precoding, the precoding in the radio is supported at the RU <NUM>, and the RU <NUM> may be referred to as a precoding O-RAN RU. Category B may also support modulation compression.

When the data is flowing from the DU (e.g., O-DU <NUM>, <NUM>, <NUM>) to the RU (e.g., O-RU <NUM>, <NUM>, <NUM>), the data may flow through a user plane (U-plane), a control plane (C-plane) and a synchronization plane (S-plane). The U-plane may be responsible for transmitting the data from the DU to the RU. For example, the U-plane message may carry a DL Frequency Domain IQ Data, e.g., downlink user data (PDSCH), control channel data (PDCCH), etc., and/or a UL Frequency Domain IQ Data, e.g., uplink user data (PUSCH), control channel data (PUCCH), etc. The C-plane message may include the control information, such as the scheduling command and the beamforming command, which may indicate how the data transmitted in the U-plane is to be interpreted. Thus, a C-plane message may correspond to a U-plane message. Both the C-plane message and the U-plane message may be carried in the payload section of a transmission via the Ethernet connection.

The C-plane message may employ a two layer header approach, where one header may be a transport header, and the other header may be an application header. <FIG> is a diagram <NUM> illustrating an example transport header for the C-plane message. The transport header may indicate the type of message and interface (e.g., ecpriMessage), the payload length (e.g., ecpriPayload), the C-plane message source and destination identifier (e.g., ecpriRtcid) or the U-plane message source and destination identifier (e.g., ecpriPcid), and/or the message sequence number (e.g., ecpriSeqid), etc. <FIG> is a diagram <NUM> illustrating an example of the C-plane message from the DU to the RU including a transport header <NUM> (e.g., an enhanced Common Public Radio Interface (eCPRI) transport header) and an application header <NUM>. The application header <NUM> may include necessary fields for the control and the synchronization. For example, the application header <NUM> may comprise various fields such as the data direction, payload version, filter index, frame ID, subframe ID, slot ID, start symbol ID, section ID, number of section, section type, user plane compression header (udCompHdr) headers, etc. The data direction field may be used for indicating whether the message is for the downlink or the uplink data. The payload version field may be used for indicating the structure or architecture version of the payload. The filter index field may be used for selecting or changing channel filter. The slot and start symbol ID fields may be used for indicating which symbol(s) within the slot is referred by the header (e.g., the start of the symbol in the slot). The number of section field may be used for indicating how many sections are after (e.g., following) the application header (i.e., how many sections are defined in the current C-plane message). The control information within the C-plane message may be transmitted in terms of sections. For example, each section in the C-plane message may define the characteristics of a U-plane data to be transferred or received from a beam with one pattern ID. The section type field may be used for defining the type of the section, such as based on the Table <NUM> below.

The user data compression header field in the C-plane message may be used for the uplink, and may have two component parts. One component part may be the compression method (e.g., udCompMeth), and the other component part may be the bitwidth. The compression method component may indicate the compression method used for the U-plane message associating with the C-plane message, and the bitwidth component may indicate the bitwidth of each IQ data after the compression. <FIG> is a diagram <NUM> illustrating an example of the compression method.

Following the application header <NUM> is the section ID portion, which may include a section ID field that may be used for assigning an ID to a frequency and time resource (e.g., resources for transporting data in the U-plane message). There may be more than one section ID defined in the section ID portion, and there may be additional parameters and configuration associating with each section ID. The section ID configured in the C-plane message may be used by the DU or the RU to associate the U-plane message with its corresponding C-plane message. For example, after a section ID and its associated parameters are defined in a C-plane message, the same section ID may be assigned to the U-plane message. Thus, the U-plane message may use the section ID to relate to the C-plane message, and may apply the parameters and configurations associated with the section ID to its transmitting data (e.g., IQ data). A C-plane message may comprise multiple section IDs for multiple frequency resources, where there may be a one to one mapping of configuration for the U-plane IQ data. The associated parameters and configurations may include a start PRB field (e.g., startPrbc) and a number of PRBs field (e.g., numPrbc), which may be used to indicate where the configuration starts and the length of the configuration. In other word, the section ID portion of the C-plane message may be used for creating section(s) that defines frequency resource for a corresponding IQ data in the corresponding U-plane message. The C-plane message may further include a beam identifier field after the section ID portion for identifying beam(s) to be used for transmitting the U-plane message.

<FIG> is a diagram <NUM> illustrating an example of the U-plane message, where the U-plane message may have a similar transport header <NUM> and application header <NUM> as the C-plane message, and may be followed by a section ID header that is received in the C-plane message, such as described in connection with <FIG>. For example, the IQ data presented in the U-plane message may use the parameters and configurations associating with the section ID assigned from the C-plane message (e.g., startPrbc, numPrbc, etc.). The U-plane message may also include a user data compression header (e.g., udCompHdr) followed by a bitwidth, and a user data compression parameter (udCompParam) field. The user data compression header in the U-plane message may be used for the downlink transmission, and may indicate the compression method used for the U-plane message and the bitwidth of the IQ data after the compression.

The payload section (e.g., eCPRI payload) of the U-Plane message may be used for transmitting an IQ sample (e.g., iSample/qSample) sequence of the OFDM signal in a frequency domain that applies the and IQ compression and the IQ compression information (e.g., udCompHdr). This information may be transmitted with time and/or frequency resource information that applies to the transmission and reception of the IQ sample sequence. The user data compression parameter (udCompParam) field may be used to indicate the compression scheme applied and the number of bits in the IQ sample after compression. The IQ compression may be performed using a common IQ compression parameter for each PRB (e.g., <NUM> IQ samples). For example, when the block floating point is used for the compression, the IQ compression parameter and IQ sample sequence may represent an exponent and mantissa in floating point form. There may be multiple user data compression parameters in a section of the U-plane message, such as once per PRB or a number of resource elements (e.g., <NUM> REs). The value (e.g., size) for the user data compression parameter may change depending on the compression method.

Under the O-RAN downlink, the bitwidth of the U-plane IQ data may be sent or indicated once per section in the user data compression header parameter (e.g., following the udCompHdr) of the U-plane message. For the uplink, the bitwidth of the IQ data may be sent over or indicated in a C-plane message, where the bitwidth may be constant for all sections defined under the C-plane message. As such, in the downlink, the bitwidth signaling granularity may be per data section, whereas in the uplink, the bitwidth signaling may be per C-plane message. In other words, in the downlink, the bitwidth signaling occurs once per data section, and in the uplink, the bitwidth signaling occurs once per C-plane message. This may lead to significant redundant information to be sent over the O-RAN FH if the bitwidth to represent the actual signal is less than the configured bitwidth in a data section (e.g., for the downlink) or in a C-plane message (e.g., for the uplink). For example, the bitwidth in a data section for the downlink or in a C-plane message for the uplink may be configured to be <NUM> bits but the actual required bitwidth may be <NUM> bits, which may result in <NUM> bits being unused or redundant. In addition, for the uplink, the DU may be assigned to determine the bitwidth for the uplink data. As the DU may not have information on the size of the uplink data (e.g., bits sufficient to represent the uplink data), the DU may overestimate the required bits to send the IQ data to avoid loss.

Aspects presented herein may provide better compression granularity for the uplink and the downlink transmission of IQ data between the DU and the RU. Aspects presented herein may enhance the estimation/reporting of the bitwidth size by reducing the signaling granularity of the bitwidth parameter to per PRB for the downlink and/or the uplink instead of per section or per C-plane message. This signaling granularity may apply to a block floating point (BFP) compression, which may be a common compression method used by the O-RAN.

In one aspect, for the downlink, the user data compression header (e.g., udCompHdr) in the U-plane message may signal a max IQ data bitwidth "R" (e.g., R being a value) using a new or an existing parameter, such as the user data IQ width (e.g., udIqWidth) parameter. The max IQ data bitwidth may provide a default bitwidth value for a PRB, and it may be associated with a section ID, such as described in connection with <FIG> and <FIG>. As the user data compression parameter (e.g., udCompParam) may be signaled once per PRB (e.g., every <NUM> REs), a MSB <NUM> bits field in the user data compression parameter may be used for signaling the actual bitwidth "X" used in the PRB (e.g., per PRB), such that the bitwidth for an IQ data may be signaled per PRB instead of per section. Each PRB within the U-plane message may indicate the actual bitwidth within the PRB, and the PRB may be transmitted based on the actual bitwidth (e.g., X) instead of the maximum/default bitwidth (e.g., R). For example, the U-plane message may determine the max IQ data bitwidth "R" to be <NUM> bits. However, if the actual IQ data bitwidth is <NUM> bits (e.g., X=<NUM>), the MSB <NUM> bits field in the user data compression parameter (e.g., udCompParam) may indicate that only <NUM> bits are to be used in this PRB. After this MSB <NUM> bits field is signaled, the PRB may use <NUM> bits for the bitwidth instead of <NUM> bits, thereby saving <NUM> bits of resources.

Some RU may not support the aforementioned per PRB bitwidth configuration, which may occur and may be known to a DU as part of a capability exchange with the RU via the M-plane. In this case, the RU may be configured to ignore the MSB <NUM> bits field in the user data compression parameter of the U-plane message. In other words, the RU may continue to use the default bitwidth value (e.g., R) for the PRBs. In some situation, the RU may not have support for certain values of bitwidth. Thus, the value for X may also be configured based on bitwidth values supported by the RU and known to the DU as part of capability exchange between the DU and the RU via M-plane message. If there is no suitable value for X, then the RU may use the maximum (e.g., default) R bits for the bitwidth.

<FIG> is a diagram <NUM> illustrating an example of signaling the IQ data bitwidth X using the MSB <NUM> bits field (e.g., udIqWidth). For example, when the MSB <NUM> bits field indicates <NUM>, the I and Q in the IQ data may each be <NUM> bits wide; when the MSB <NUM> bits field indicates <NUM>, the I and Q in the IQ data may each be <NUM> bits wide; when the MSB <NUM> bits field indicates <NUM>, the I and Q in the IQ data may each be <NUM> bits wide, etc..

In one other aspect, for the uplink, an existing parameter such as the udIqWidth in the user data compression header (e.g., in C-plane message) may be used for signaling the max IQ bitwidth "R" for all sections signaled with the C-plane message. Similarly, the MSB <NUM> bits (which may be reserved for the BFP compression) in the user data compression parameter (e.g., udCompParam) that is signaled per PRB may be used for signaling the actual bitwidth "X" used in the PRB, which may be similar to the bitwidth in the U-plane message. For DU(s) that may not have support for the per PRB bitwidth granularity configuration (which may be known to the RU as part of capability exchange via M-plane), the MSB <NUM> bits field in the user data compression parameter may be ignored. In some situation, the DU may not have support for certain values of bitwidth. Thus, the value for X may also be configured based on bitwidth values supported by the DU and known to the RU as part of capability exchange via M-plane message. If there is no suitable value for X, then the DU may use the maximum (e.g., default) R bits for the bitwidth.

In one other aspect, additional compression method may also be provided or defined for the RU and DU, and the additional compression method may be signaled in the user data compression header, such as shown by <FIG>. In one example, the user data compression parameter (udCompParam) may be configured to signal the actual bitwidth. <FIG> is a diagram <NUM> illustrating an example of the user data compression parameter format that may be used for signaling the actual bitwidth of the IQ data. For example, additional compression method (e.g., udCompMeth = 0111b) may be added and used to define the MSB <NUM> bits within the user data compression parameter to indicate the actual bitwidth used for signaling the IQ data of the PRB, and the least significant bit (LSB) <NUM> bits may be used to indicate the exponent of the BFP compression.

<FIG> is a flowchart <NUM> of a method of wireless communication. The method may be performed by a distributed unit (e.g., DU <NUM>, <NUM>, <NUM>). Optional aspects are illustrated with a dashed line. The method may enable the DU to provide better compression granularity by signaling the bitwidth of IQ data per PRB.

At <NUM>, the DU may signal a maximum IQ data bitwidth for downlink communication associated with a section ID, such as described in connection with <FIG> and <FIG>. The maximum IQ data bitwidth may be signaled in a user plane compression header (udCompHdr).

At <NUM>, the DU may signal a bitwidth parameter for the downlink communication per a PRB, such as described in connection with <FIG> and <FIG>. The bitwidth parameter per the PRB may be signaled in a user plane compression parameter (udCompParam).

At <NUM>, the DU may transmit downlink communication to a RU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB, such as described in connection with <FIG> and <FIG>. In one aspect, the DU may transmit the downlink communication based on the maximum IQ data bitwidth for the RU that does not support a per PRB bitwidth granularity. For example, the DU may receive capability signaling from the RU prior to transmitting the downlink communication, where the capability signaling may indicate that the RU does not support the PRB bitwidth granularity. In another aspect, the DU may transmit the downlink communication based on the bitwidth parameter for the PRB for the RU that supports a per PRB bitwidth granularity. For example, the DU may receive capability signaling from the RU prior to transmitting the downlink communication, wherein the capability signaling indicates that the RU supports the PRB bitwidth granularity. In one other aspect, the DU may receive capability signaling from the RU prior to transmitting the downlink communication, where the capability signaling indicates the bitwidth size supported by the RU, wherein the bitwidth parameter for the PRB is based on the bitwidth size supported by the RU.

<FIG> is a flowchart <NUM> of a method of wireless communication. The method may be performed by a radio unit (e.g., RU <NUM>, <NUM>, <NUM>). Optional aspects are illustrated with a dashed line. The method may enable the RU to provide better compression granularity by signaling the bitwidth of IQ data per PRB.

At <NUM>, the RU may receive a first indication of a maximum IQ data bitwidth for downlink communication associated with a section ID, such as described in connection with <FIG> and <FIG>. The first indication of the maximum IQ data bitwidth may be received in a user plane compression header (udCompHdr).

At <NUM>, the RU may receive a second indication of a bitwidth parameter for the downlink communication per a PRB, such as described in connection with <FIG> and <FIG>. The second indication of the bitwidth parameter per the PRB is received in a user plane compression parameter (udCompParam).

At <NUM>, the RU may receive downlink communication from a DU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB, such as described in connection with <FIG> and <FIG>. In one aspect, when the RU does not support a per PRB bitwidth granularity, the RU may receive the downlink communication based on the maximum IQ data bitwidth. The RU may transmit capability signaling to the DU prior to receiving the downlink communication, where the capability signaling may indicate that the RU does not support the PRB bitwidth granularity. In another aspect, when the RU supports a per PRB bitwidth granularity, the RU may receive the downlink communication based on the bitwidth parameter for the PRB. The RU may transmit capability signaling to the DU prior to transmitting the downlink communication, where the capability signaling may indicate that the RU supports the PRB bitwidth granularity. In one other aspect, the RU may transmit capability signaling to the DU prior to transmitting the downlink communication, where the capability signaling may indicate the bitwidth size supported by the RU, and the bitwidth parameter for the PRB may be based on the bitwidth size supported by the RU.

At <NUM>, the DU may signal, to a RU, a maximum IQ data bitwidth for uplink communication in a C-plane message, such as described in connection with <FIG> and <FIG>. For example, the maximum IQ data bitwidth may be signaled in a user plane compression header (udCompHdr).

At <NUM>, the DU may receive a bitwidth parameter for the uplink communication per a PRB, such as described in connection with <FIG> and <FIG>. For example, the bitwidth parameter per the PRB may be received in a user plane compression parameter (udCompParam).

At <NUM>, the DU may receive the uplink communication from the RU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB, such as described in connection with <FIG> and <FIG>. In one aspect, when the DU does not support a per PRB bitwidth granularity, the DU may receive the uplink communication based on the maximum IQ data bitwidth. The DU may transmit capability signaling to the RU prior to receiving the uplink communication, where the capability signaling indicates that the DU does not support the PRB bitwidth granularity. In other aspect, when the DU supports a per PRB bitwidth granularity, the DU may receive the uplink communication based on the bitwidth parameter for the PRB. The DU may transmit capability signaling to the RU prior to receiving the uplink communication, wherein the capability signaling indicates that the DU supports the PRB bitwidth granularity. In one other aspect, the DU may transmit capability signaling to the RU prior to receiving the uplink communication, wherein the capability signaling indicates the bitwidth size supported by the DU, wherein the bitwidth parameter for the PRB is based on the bitwidth size supported by the DU.

At <NUM>, the RU may receive, from a DU, a first indication of a maximum IQ data bitwidth for uplink communication in a C-plane message, such as described in connection with <FIG> and <FIG>. In one example, the first indication of the maximum IQ data bitwidth may be received in a user plane compression header (udCompHdr).

At <NUM>, the RU may transmit a second indication of a bitwidth parameter for the uplink communication per a PRB, such as described in connection with <FIG> and <FIG>. In one example, the second indication of the bitwidth parameter per the PRB is transmitted in a user plane compression parameter (udCompParam).

At <NUM>, the RU may transmit the uplink communication to the DU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB, such as described in connection with <FIG> and <FIG>. In one aspect, the uplink communication may be transmitted based on the maximum IQ data bitwidth for the DU that does not support a per PRB bitwidth granularity. The RU may receive capability signaling from the DU prior to transmitting the uplink communication, where the capability signaling indicates that the DU does not support the PRB bitwidth granularity. In other aspect, the uplink communication may be transmitted based on the bitwidth parameter for the PRB for the DU that supports a per PRB bitwidth granularity. The RU may receive capability signaling from the DU prior to transmitting the uplink communication, wherein the capability signaling indicates that the DU supports the PRB bitwidth granularity. In one other aspect, the RU may receive capability signaling from the DU prior to transmitting the uplink communication, wherein the capability signaling indicates the bitwidth size supported by the DU, wherein the bitwidth parameter for the PRB is based on the bitwidth size supported by the DU.

Claim 1:
A method (<NUM>) of wireless communication at a distributed unit, DU, comprising:
signaling (<NUM>), to a radio unit, RU, a maximum IQ data bitwidth for a downlink communication associated with a section identifier, ID;
signaling (<NUM>), to the RU, a bitwidth parameter for the downlink communication per a physical resource block, PRB;
receiving capability signaling from the RU prior to transmitting the downlink communication, wherein the capability signaling indicates either that the RU does not support the PRB bitwidth granularity or that the RU supports the PRB bitwidth granularity; and
transmitting (<NUM>) the downlink communication to the RU based on at least one of the maximum IQ data bitwidth or the bitwidth parameter for the PRB, wherein the downlink communication is transmitted based on the maximum IQ data bitwidth for the RU that does not support a per PRB bitwidth granularity and wherein the downlink communication is transmitted based on the bitwidth parameter for the PRB for the RU that supports a per PRB bitwidth granularity.