112 that are included in that simulcast zone or combining zone. In general, the respective simulcast zone and combining zone for a UE 106 includes those RUs 112 that have the “best” or “strongest” signal reception or transmission characteristics for that UE 106.

In one exemplary embodiment, the simulcast zone and combining zone for each UE 106 can be determined by the serving DU 110 using a “signature vector” (SV) associated with that UE 106. Each signature vector includes a respective element for all of the RUs 112 of the gNB 102. For example, if the gNB 102 uses 32 RUs 112, each signature vector will include 32 elements, one for each of the 32 RUs 112. That is, each element of the signature vector corresponds to one of the RUs 112 of the gNB 102. Each element of the signature vector comprises one or more numerical values associated with the signal transmission or reception characteristics for that UE 106.

The elements of the signature vector for each UE 106 can be determined based on uplink transmissions from the UE 106. With such an approach, it is assumed that the relative signal reception metrics determined using such uplink transmissions are representative of which RUs 112 the UE 106 will have the best or strongest signal transmission and reception characteristics for both transmitting downlink transmissions to the UE 106 and for receiving uplink transmissions from the UE 106 for the purpose of determining the simulcast zone for the UE 106. For example, the signature vector can be determined based on received power measurements made at each of the RUs 112 of the gNB 102 for one or more uplink transmissions from the UE 106 (for example, initially Physical Random Access Channel (PRACH) transmissions and thereafter Sounding Reference Signals (SRS) transmissions). More specifically, each RU 112 of the gNB 102 will receive those uplink transmissions and can measure or otherwise determine a signal reception metric indicative of the power level of the transmissions received by that RU 112 from the UE 106. One example of such a signal reception metric is a signal-to-interference plus noise ratio (SINR).

In this exemplary embodiment, each gNB 102 is configured to determine a signature vector for a UE 106 upon connection to the cell 104 (for example, based on a PRACH transmission and/or a previously determined signature vector for that UE 106) and update the signature vector for the UE 106 over the course of the UE's connection to the cell 104 based on SRS transmissions from the UE 106. For the purposes of determining and updating a UE's signature vector, each RU 112 of the gNB 102 can communicate the respective signal reception metrics periodically without an explicit request from the DU 110 and/or can communicate the signal reception metrics in response to an explicit request from the DU 110 to do so (for example, using a polling mechanism).

One way that the respective signature vector determined for a given UE 106 can be used to determine the respective simulcast zone or combining zone for that UE 106 is by using the signature vector to calculate a “total zone power” and a “total available power” for that UE 106. The total zone power for a given UE 106 is the sum of the respective signal reception metrics determined for that UE 106 corresponding to the RUs 112 that are currently included in the zone that is being determined. The “total available power” for the UE 106 is the sum of the signal reception metrics determined for that UE 106 that correspond to all of the RUs 112. The simulcast zone or combining zone for a UE 106 can be determined by including enough RUs 112 in the simulcast zone for the UE 106 so that the total zone power for the UE 106 is within a threshold amount of the total available power for the UE 106. More specifically, a respective zone for a UE 106 can be determined by starting with an empty zone for that UE 106, sorting the RUs 112 based on the respective corresponding signal reception metrics determined for that UE 106 in descending order from strongest power to weakest power, and adding, to the zone for that UE 106, successive RUs 112 (according to the resulting sorted descending order) until the total zone power calculated for that UE 106 is within a threshold amount of the respective total available power calculated for that UE 106 or until the number of RUs 112 included in the respective zone for that UE 106 is equal to a predetermined maximum value (also referred to here as the “zone cap”). That is, the size of a simulcast zone or combining zone is limited to the zone cap.

In this exemplary embodiment, the gNB 102 is configured to use “frequency reuse.” As noted above, “downlink frequency reuse” refers to situations where separate downlink user data intended for different UEs 106 is simultaneously wirelessly transmitted to the UEs 106 using the same physical resource blocks (PRBs) for the same cell 104. Likewise, as noted above, “uplink frequency reuse” refers to situations where separate uplink user data is simultaneously wirelessly transmitted from different UEs 106 using the same PRBs for the same cell 104. Generally, for those PRBs where downlink or uplink frequency reuse is used, the respective simulcast zone or the combining zone for the multiple UEs 106 that are “in reuse together” have no RUs 112 in common. Typically, frequency reuse can be used when the UEs 106 in reuse together are sufficiently physically separated from each other so that the co-channel interference resulting from the different simultaneous wireless transmissions is sufficiently low (that is, where there is sufficient RF isolation).

Each gNB 102 is configured to use all RUs 112 to receive uplink transmissions from UEs 106 on the Physical Random Access Channel (PRACH). This is because the PRACH is used by a UE 106, among other things, to initially access the cell 104 and to re-establish access after being in an idle state and the gNB 102 may have no simulcast zone or combining zone assigned to the UE 106 or the simulcast zone or combining zone assigned to the UE 106 may be “stale” and not properly reflect the current location of the UE 106 (for example, if the location of the UE 106 changed significantly while the UE 106 was an idle state).

Also, in the exemplary embodiment described here in connection with FIG. 1, each gNB 102 is configured to update the signature vector (and, therefore, the simulcast zone and combining zone) for each UE 106 using SRS transmissions from that UE 106. As a consequence, in this exemplary embodiment, each gNB 102 is also configured to use all RUs 112 to receive uplink SRS transmissions from UEs 106.

Because each gNB 102 is configured to use all RUs 112 to receive uplink PRACH and SRS transmissions from UEs 106, it can be beneficial to reduce fronthaul bandwidth usage associated with PRACH and SRS transmissions. One approach that can be used to reduce fronthaul bandwidth usage associated with uplink transmissions is illustrated in FIG. 2. It is important to note that in the following description, various techniques for reducing fronthaul bandwidth usage and/or contention associated with uplink transmissions from UEs 106 are described. Some of these techniques may be described below as being especially well suited for use with particular types of uplink transmissions. However, it is to be understood that the techniques described can be used with any type of uplink transmission. Moreover, one or more of the techniques described can be used in combination with each other.

FIG. 2 comprises a high-level flowchart illustrating one exemplary embodiment of a method 200 of communicating fronthaul data for uplink transmissions. The embodiment of method 200 shown in FIG. 2 is described here as being implemented using the gNB 102 of FIG. 2 (though it is to be understood that other embodiments can be implemented in other ways).

The blocks of the flow diagram shown in FIG. 2 have been arranged in a generally sequential manner for ease of explanation; however, it is to be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 200 (and the blocks shown in FIG. 2) can occur in a different order (for example, where at least some of the processing associated with the blocks is performed in parallel and/or in an event-driven manner). Also, most standard exception handling is not described for ease of explanation; however, it is to be understood that method 200 can and typically would include such exception handling.

Method 200 can be performed by each RU 112 of each gNB 102. The embodiment of method 200 described here in connection with FIG. 2 is described as being used for communicating fronthaul data for SRS transmissions in a base station where the DU 110 is configured to determine, for each UE 106, the simulcast zone for wirelessly transmitting to that UE 106 and/or the combining zone for wirelessly receiving from that UE 106 based on information derived from SRS transmissions from that UE 106 received at all of the RUs 112 of the associated gNB 102. However, it is to be understood that method 200 can be used for other types of uplink transmission (for example, PRACH transmissions).

Method 200 comprises receiving, by a RU 112, an uplink transmission (for example, a SRS transmission) from a UE 106 (block 202), performing, by that RU 112, at least some “high” physical layer (PHY) baseband processing for the received uplink transmission (block 204), and transmitting fronthaul data for the received uplink transmission to the DU 110 over the fronthaul network 120, where the payload of the fronthaul data comprises data generated in connection with performing at least some of the high PHY baseband processing (block 206). As noted above, the “high” PHY baseband processing is PHY baseband processing that would ordinarily be performed in the DU 110 (or similar baseband processing entity) if a “Functional Split 7-2x” were to be used.

The data generated in connection with performing at least some of the high PHY baseband processing can include, for example, “standard” data used in other processing specified by a related 3GPP 5G NR or 4G LTE (or other) public specification as well as “proprietary” data used for solely for other purposes (for example, proprietary signal reception data used solely in determining the simulcast zone and/or combining zone for a UE 106).

In one implementation of such an embodiment, each RU 112 performs all of the PHY baseband processing for the received uplink transmission (that is, each RU 112 performs all of the high PHY baseband processing for the received uplink transmission as well as all of the low PHY baseband processing for the received uplink transmission). That is, in such an implementation, a “Functional Split 6” can be used for one or more types of uplink transmission (for example, PRACH and/or SRS transmissions).

Also, a different functional split (for example, a “Functional Split 7-2x”) can be used for at least one other type of uplink transmissions (for example, Physical Uplink Shared Channel (PUSCH) and/or Physical Uplink Control Channel (PUCCH) transmissions).

By communicating fronthaul data that comprises data generated in connection with performing at least some of the high PHY baseband processing in each RU 112 for some uplink transmissions instead of, for example, as frequency-domain baseband IQ data, fronthaul bandwidth usage associated with those uplink transmissions can be greatly reduced. This is especially well suited for use with uplink transmissions that are received using all RUs 112 of the gNB 102, which in the exemplary embodiment described above in connection with FIG. 1 includes PRACH and SRS transmissions.

Other approaches to reducing fronthaul bandwidth usage and/or contention associated with uplink transmissions from UEs 106 can be used.

For example, if all RUs 112 used for receiving an uplink transmission from a UE 106 start transmitting fronthaul data for the uplink transmission at approximately the same time, there is an increased likelihood of contention over one or more communication links of the fronthaul network 120 (for example, over a communication link that couples the DU 110 to the rest of the fronthaul network 120). One approach to reducing the likelihood of this type of contention is illustrated in FIG. 3.

FIG. 3 comprises a high-level flowchart illustrating one exemplary embodiment of a method 300 of communicating fronthaul data for uplink transmissions. The embodiment of method 300 shown in FIG. 3 is described here as being implemented using the gNB 102 of FIG. 3 (though it is to be understood that other embodiments can be implemented in other ways).

The blocks of the flow diagram shown in FIG. 3 have been arranged in a generally sequential manner for ease of explanation; however, it is to be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 300 (and the blocks shown in FIG. 3) can occur in a different order (for example, where at least some of the processing associated with the blocks is performed in parallel and/or in an event-driven manner). Also, most standard exception handling is not described for ease of explanation; however, it is to be understood that method 300 can and typically would include such exception handling.

Method 300 can be performed by each RU 112 of each gNB 102. Moreover, although the embodiment of method 300 shown in FIG. 3 is described here as being performed for one type of uplink transmission, it is to be understood that method 300 can be performed for one or more types of uplink transmissions.

Method 300 comprises receiving an uplink transmission from a UE 106 using multiple RUs 112 (block 302), performing, by each of the multiple RUs 112, at least some physical layer (PHY) baseband processing for the received uplink transmission (block 304), and starting transmission of fronthaul data for the uplink transmission to the DU 110 over the fronthaul network 120 from the multiple RUs 112 at different times (block 306).

By spreading out when the various RUs 112 used to receive a given uplink transmission start transmitting fronthaul data to the DU 110 over the fronthaul network 120, the likelihood of contention over one or more communication links of the fronthaul network 120 can be reduced.

Each RU 112 receives the uplink transmission from the UE 106 using the set of antennas 118 associated with that RU 112 and performs the PHY baseband processing that the RU 112 is configured to perform for that type of uplink transmission. As noted above, the particular PHY baseband processing that is performed by the RU 112 for a given uplink transmission depends on which Functional Split is being used for that type of uplink transmission. For example, if the gNB 102 is configured to use a Functional Split 7-2x (for example, as specified by the O-RAN Alliance) for a given type of transmission, each RU 112 of the gNB 102 is configured to perform the low PHY baseband processing for that type of transmission (for example, including the fast Fourier transform (FFT), cyclic prefix (CP) removal, and any digital beamforming (if used)). In such an example, the fronthaul payload would comprise frequency-domain baseband IQ data for the uplink transmission (which can be in uncompressed or compressed form, depending on whether compression is used). In another example, if the gNB 102 is configured to use a Functional Split 6 for a given type of uplink transmission, each RU 112 of the gNB 102 is configured to perform all of the PHY baseband processing for that type of uplink transmission. In such an example, the fronthaul payload comprises the resulting transport blocks for the uplink transmission.

FIG. 4 illustrates one example of the operation of method 300 to receive an uplink transmission using three RUs 112 (individually referenced in FIG. 4 as RU A, RU B, and RU C). In the example shown in FIG. 4, RU A starts transmitting fronthaul data for the uplink transmission at a first time T_A, RU B starts transmitting fronthaul data for the uplink transmission at a second time T_B, and RU C starts transmitting fronthaul data for the uplink transmission at a third time T_C, where the first time T_A, the second time T_B, and the third time T_call differ from one another. Again, by spreading out when RU A, RU B, and RU C start transmitting fronthaul data to the DU 110 over the fronthaul network 120, the likelihood of contention over one or more communication links of the fronthaul network 120 can be reduced.

In one implementation of method 300, each RU 112 of the gNB 102 is configured to use a parameter specifying a value for an offset that the RU 112 uses to determine when to start transmitting fronthaul data for a given type of uplink transmission. The offset can be defined relative to a boundary or other attribute of the associated uplink slot in which an uplink transmission is received (for example, an offset from the start or end of the associated uplink slot for the uplink transmission). This offset is also referred to here as an “uplink fronthaul offset.” By configuring each of the RUs 112 of the gNB 102 with an uplink fronthaul offset for a given type of uplink transmission that differs from the uplink fronthaul offsets used by all of the other RUs 112 of the gNB 102, the various RUs 112 used to receive any uplink transmission of that type will determine respective transmission start times that differ from each other. In such an implementation, the uplink fronthaul offsets used by the various RUs 112 can be configured manually (for example, during initial deployment of the gNB 102 using an appropriate management system). The uplink fronthaul offsets used by the various RUs 112 can also be configured automatically (for example, by the DU 110 or a RAN Intelligent Controller (RIC)). The uplink fronthaul offsets used by the various RUs 112 can be configured autonomously by each RU 112 (for example, configuring each uplink fronthaul offset with a randomly selected value or a value generated from some other piece of configuration data).

Another way to reduce the fronthaul bandwidth usage associated with the uplink transmissions is to use compression. One type of compression is block scaling. Block scaling reduces the bit resolution used to represent IQ samples communicated over the fronthaul network 120 by quantizing the original IQ samples to a reduced bit resolution (also referred to here as the “compressed bit resolution”). In order to minimize quantization error, a form of digital automatic gain control is used, which involves scaling the original IQ samples by a scaling factor before quantization using the compressed bit resolution. The scaling factor for a block of IQ samples is determined based on the maximum absolute value of all of the original IQ samples in the block. The scaling factor is transmitted along with the compressed IQ samples for use in decompressing the compressed IQ samples. In general, the amount of compression that can be achieved using block scaling is dependent on the average received signal power.

The 3GPP specifications define various forms of uplink transmit power control that are performed for 5G. In general, this transmit power control is a function of a target signal-to-interference plus noise ratio (SINR). The 3GPP specification defines how the target SINR is typically determined. Conventionally, a gNB determines the target SINR for each UE and then uses that determined value as the target SINR in performing uplink transmit power control for the UE.

Reducing the compressed bit resolution used in block scaling IQ samples tends to increase noise (due to increased quantization noise) and, as a result, tends to reduce the resulting SINR. In situations where the resulting reduced SINR is otherwise acceptable, the reduced compressed bit resolution could be used for block scaling.

One approach to exploiting this effect in order to reduce fronthaul bandwidth usage associated with uplink transmissions is illustrated in FIG. 5.

FIG. 5 comprises a high-level flowchart illustrating one exemplary embodiment of a method 500 of communicating fronthaul data for uplink transmissions. The embodiment of method 500 shown in FIG. 5 is described here as being implemented using the gNB 102 of FIG. 5 (though it is to be understood that other embodiments can be implemented in other ways).

The blocks of the flow diagram shown in FIG. 5 have been arranged in a generally sequential manner for ease of explanation; however, it is to be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 500 (and the blocks shown in FIG. 5) can occur in a different order (for example, where at least some of the processing associated with the blocks is performed in parallel and/or in an event-driven manner). Also, most standard exception handling is not described for ease of explanation; however, it is to be understood that method 500 can and typically would include such exception handling.

Method comprises determining a reduced target SINR for a UE 106 (block 502), determining a reduced compressed bit resolution for the UE 106 associated with that reduced target SINR (block 504), using the reduced target SINR for performing uplink transmit power control for the UE 106 (block 506), scaling IQ samples of each resource block for at least some uplink transmissions from the UE 106 based on a respective peak sample in each such resource block (block 508), and quantizing each resource block using the reduced compressed bit resolution (block 510). The reduced target SINR and reduced compressed bit resolution for a given UE 106 are “reduced” in the sense that they are lower than they otherwise would be if the conventional techniques for determining the target SINR and compressed bit resolution were used. (The target SINR and compressed bit resolution that would otherwise have been determined using the conventional techniques for doing so are also referred to here as the “normal” target SINR and “normal” compressed bit resolution.)

Method 500 can be used in various ways. For example, method 500 can be used if the fronthaul network 120 is highly loaded and it would be beneficial to reduce the fronthaul bandwidth usage for communicating fronthaul data. Thereafter, if the loading of the fronthaul network 120 subsides, the compressed bit resolution and target SINR can be returned to their normal levels. Alternatively, method 500 can be used with UEs 106 that are reporting a Power Headroom (PHR) that is less than or equal to zero. These UEs 106 are good candidates for using a reduced target SINR since they are not able to achieve the normal target SINR.

The reduced target SINR and reduced compressed bit resolution for a given UE 106 can be determined so that they satisfy the following condition:

reduced compressed bit resolution=target SINR/6 bits+3 bits

- where the reduced compressed bit resolution is expressed in bits and the reduced target SINR is expressed in decibels (dB). Satisfying this condition will tend to cause the quantization noise resulting from the reduced compressed bit resolution to be about 15 dB below the current interference and other noise for the UE 106.

The reduced target SINR is used in place of the normal target SINR when performing uplink transmit power control for the UE 106. Also, the reduced compressed bit resolution is used in place of the normal compressed bit resolution when quantizing IQ samples for at least some uplink transmissions from the UE 106 (for example, for PUSCH and PUCCH transmissions).

Method 500 can be used for all UEs 106 served by the gNB 102 or can be done selectively (that is, by reducing the compressed bit resolution for some but not all of the UEs 106). If it is done selectively, the subset of UEs 106 for which the compressed bit resolution is used can be changed from time to time (for example, using a round robin (or other) scheduling scheme). Also, the reduced compressed bit resolution can be used for all RUs 112 in the UE's combining zone or less than all of the RUs 112 in the UE's combining zone (for example, the reduced compressed bit resolution can be used for one or more RUs 112 in the UE's combining zone having the lowest SINR values in the signature vector for that UE 106).

The approaches to reducing fronthaul bandwidth usage and contention for uplink transmissions described in connection with FIGS. 2-5 can be used in various configurations. For example, in one configuration, the technique described above in connection with FIG. 2 is used for PRACH transmissions, the technique described above in connection with FIG. 3 is used for SRS transmissions, and the technique described above in connection with FIG. 5 is used for PUSCH and PUCCH transmissions. In another example, the technique described above in connection with FIG. 2 is used for PRACH and SRS transmissions, the technique described above in connection with FIG. 3 is used for PUSCH and PUCCH transmissions, and the technique described above in connection with FIG. 5 is used for PUSCH and PUCCH transmissions. Other configurations are possible.

Other embodiments can be implemented in other ways.

A number of embodiments of the invention defined by the following claims have been described. Nevertheless, it will be understood that various modifications to the described embodiments may be made without departing from the spirit and scope of the claimed invention. Accordingly, other embodiments are within the scope of the following claims.

EXAMPLE EMBODIMENTS

Example 1 includes a system comprising: a distributed unit; and a plurality of radio units to wirelessly transmit and receive radio frequency signals to and from user equipment (UEs) using a wireless interface, each of the radio units associated with a respective set of antennas; wherein the distributed unit is communicatively coupled to the plurality of radio units over a fronthaul network; wherein the distributed unit and the radio units are configured to implement a base station to provide wireless services to UEs using a cell; wherein the distributed unit is configured to, for each of the UEs, determine a respective subset of the radio units to wirelessly transmit to that UE based on information derived from Sounding Reference Signal (SRS) transmissions from that UE received at all of the radio units; and wherein the base station is configured so that each of the RUs is configured to: receive, at that RU, an SRS transmission from a UE; perform, by that RU, at least some of the high physical layer (PHY) baseband processing for the received SRS transmission; and transmit fronthaul data for the received SRS transmission to the distributed unit over the fronthaul network, wherein the fronthaul data comprises a payload including data generated in connection with performing at least some of the high PHY baseband processing for the received SRS transmission.

Example 2 includes the system of Example 1, wherein the base station is configured so that each of the RUs is configured to not perform any high PHY baseband processing for uplink transmissions other than SRS transmissions.

Example 3 includes the system of any of Examples 1-2, wherein the base station is configured so that each of the RUs is configured to perform at least some high PHY baseband processing for Physical Random Access Channel (PRACH) transmissions.

Example 4 includes a method of communicating fronthaul data for Sounding Reference Signal (SRS) transmissions in a system comprising a distributed unit and a plurality of radio units to wirelessly transmit and receive radio frequency signals to and from user equipment (UEs) using a wireless interface, each of the radio units associated with a respective set of antennas, wherein the distributed unit is communicatively coupled to the plurality of radio units over a fronthaul network, wherein the distributed unit and the radio units are configured to implement a base station to provide wireless services to UEs using a cell, the method comprising: at each of the RUs: receiving, at that RU, an SRS transmission from a UE; performing, by that RU, at least some of the high physical layer (PHY) baseband processing for the received SRS transmission; and transmitting fronthaul data for the received SRS transmission to the distributed unit over the fronthaul network, wherein the fronthaul data comprises a payload including data generated in connection with performing at least some of the high PHY baseband processing for the received SRS transmission; wherein the distributed unit is configured to, for each of the UEs, determine a respective subset of the radio units to wirelessly transmit to that UE based on information derived from the SRS transmissions from that UE received at all of the radio units.