WO2025155503A1

WO2025155503A1 - Smart reuse via o-ran interface to radio unit

Info

Publication number: WO2025155503A1
Application number: PCT/US2025/011407
Authority: WO
Inventors: Ehsan Daeipour; Suman SAURAV
Original assignee: Outdoor Wireless Networks LLC
Current assignee: Outdoor Wireless Networks LLC
Priority date: 2024-01-15
Filing date: 2025-01-13
Publication date: 2025-07-24
Anticipated expiration: 2026-07-15

Abstract

A distributed unit for use in an open radio access network implementing smart reuse comprises circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

Description

SMART REUSE VIA O-RAN INTERFACE TO RADIO UNIT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Indian Provisional Patent Application Serial No. 202441002813, filed on January 15, 2024 and entitled “SMART REUSE VIA O-RAN INTERFACE TO RADIO UNIT”, which is hereby incorporated herein by reference in its entirety.

BACKGROUND

[0002] The O-RAN Alliance promulgates a group of specifications for implementing radio access networks in an open manner. (“O-RAN” is acronym for “Open RAN ”) In O-RAN, each base station is typically implemented in a disaggregated manner in which each base station is partitioned into at least one central unit (CU), at least one distributed unit (DU), and one or more radio units (RUs). Each CU typically implements Layer 3 and non-time critical Layer 2 functions for the associated base station. Each DU is typically configured to implement the time critical Layer 2 functions and at least some of the Layer 1 (also referred to as the Physical Layer) functions for the associated base station. Each RU is typically configured to implement the radio frequency (RF) interface and the physical layer functions for the associated base station that are not implemented in the DU.

SUMMARY

[0003] A distributed unit for use in an open radio access network implementing smart reuse comprises circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

[0004] A distributed unit for use in an open radio access network implementing smart reuse comprises circuitry configured to: circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit. [0005] A method for implementing smart reuse in an open radio access network comprises: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receiving, at the distributed unit, a downlink packet for transmission to the plurality of radio units being used for reuse; and transmitting, from the distributed unit, the downlink packet using the particular multicast address to the plurality of radio units.

[0006] A method for implementing smart reuse in an open radio access network comprises: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmitting, from the distributed unit, a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

[0007] An open radio access network implementing smart reuse comprises: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

[0001] An open radio access network implementing smart reuse comprises: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within an open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

[0008] A fronthaul multiplexer for use in an open radio access network implementing smart reuse comprises circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID.

[0009] A fronthaul multiplexer for use in an open radio access network implementing smart reuse comprises circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

[0010] A method for implementing smart reuse in an open radio access network comprises: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, the downlink packet to the plurality of radio units identified by the beam ID.

[0011] A method for implementing smart reuse in an open radio access network comprises: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

[0012] An open radio access network implementing smart reuse comprises: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID. [0013] An open radio access network implementing smart reuse comprises: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

BRIEF DESCRIPTION OF DRAWINGS

[0014] Understanding that the drawings depict only exemplary configurations and are not therefore to be considered limiting in scope, the exemplary configurations will be described with additional specificity and detail through the use of the accompanying drawings, in which:

[0015] Figure l is a block diagram illustrating an exemplary embodiment of a communication system in which the techniques described below can be used.

[0016] Figure 2 is a block diagram illustrating an example communication system implementing reuse with multicast.

[0017] Figures 3 A-3D are block diagrams illustrating examples of communication systems implementing reuse without multicast.

[0018] Figure 4 is a flow diagram illustrating an example method for implementing smart reuse in an open radio access network using multicast in the downlink.

[0019] Figure 5 is a flow diagram illustrating an example method for implementing smart reuse in an open radio access network using multicast in the uplink.

[0020] Figure 6 is a flow diagram illustrating an example method for implementing smart reuse in an open radio access network without multicast in the downlink.

[0021] Figure 7 is a flow diagram illustrating an example method for implementing smart reuse in an open radio access network without multicast in the uplink.

[0022] In accordance with common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the exemplary configurations.

DETAILED DESCRIPTION [0023] In O-RAN, each base station is typically implemented in a disaggregated manner in which each base station is partitioned into at least one central unit (CU), at least one distributed unit (DU), and one or more radio units (RUs). Used herein, the term “north” or “northbound” means “upstream” or toward the DU, while the term and the term “south” or “southbound” means “downstream” or away from the DU.

[0024] The O-RAN specifications define a “shared cell” configuration or implementation in which a single cell is served using multiple RUs. The O-RAN shared cell implementation attempts to make more efficient use of bandwidth to and from DUs (compared to O-RAN 1.0) in order to support communicating front-haul data with the multiple RUs. The O-RAN shared cell implementation is described in detail at Section 13 “Support of Shared Cell” in the O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Control, User and Synchronization Plane Specification version 10.0 from October 2022 (O-RAN.WG4.CUS.0- vlO.OO, hereinafter “Support of Shared Cell O-RAN Specification”, available at pages 252- 270 of PDF at https://orandownloadsweb. azurewebsites. net/download?id=364).

[0025] In the O-RAN shared cell implementation, there are generally two modes of operation in the fronthaul: Fronthaul Multiplexer (FHM) mode and Cascade mode. Examples implementing a shared cell include a FHM in order to more efficiently support one-DU-to- many-RU mapping. In examples, the FHM: (1) replicates the downlink packet stream (from the DU) for each RU; and (2) uses combining/digital summation on the uplink packet stream from the RUs (before sending to the DU). The combining/digital summation includes: (1) adding the corresponding in-phase (I) samples in corresponding physical resource blocks (PRBs) (from all the RUs); (2) adding the corresponding quadrature-phase (Q) samples in corresponding PRBs (from all the RUs); and (3) sending a combined stream of I/Q data from the FHM to the DU. The combining/digital summation may optionally include some overflow management. Using the shared cell implementation, the DU can send and receive a single packet stream (with a bandwidth of approximately N PRBs) instead of M packet streams (one for each RU with a total bandwidth of approximately N PRBs x M RUs). By reducing the DU transmitted and received data to a single stream of N PRBs, the shared cell implementation reduces bandwidth (between the DU and multiple RUs).

[0026] A FHM may be limited in how many RUs can connect to it (such as no more than 8 RUs in examples). In examples, multiple FHM are cascaded from one another to support larger quantities of RUs. In examples, each FHM only implements front-haul transport functionality and does not include radio functionality for transmitting and receiving RF signals with UEs. In examples, multicast is used in the downlink to reduce fronthaul bandwidth and unicast is used in the uplink.

[0027] 0-RAN does not currently consider reuse scenarios and its DU-RU interface is not defined for efficient implementation of smart reuse. As used herein, smart reuse refers to the same time and frequency resource(s) being used for multiple sets of UEs, each set of UEs being under a different, geographically diverse set of RUs. In examples, single physical cell identity (PCI) and smart reuse can be performed using the existing 0-RAN defined interface to maintain 0-RAN compliance. In examples, a modified DU enables standard 0-RAN RUs to implement smart reuse. In examples, efficient multicast is supported without an RUID mask by recognizing the UEs quantized signature vector (QSV) based RUs because packets are generally transmitted based on the UE QSV and so you are able to create a group of multicast which covers all possible QSV of the UE, thereby achieving reuse functionality while keeping compliance with 0-RAN standards.

[0028] For an efficient implementation of smart reuse, the RU has to support Multicast addressing. Multicast IP address configuration is something that is not defined in 0-RAN, but multicast addressing can be included as a feature in DUs (or fronthaul gateways) and RUs. In examples where RUs support multicast addressing, the DU can map RU bitmasks to multicasts groups to efficiently address RUs. In examples where RUs do not support multicast addressing, FHM (or FHM-like) functionality can be added to the DU or a separate FHM or similar functionality can be added to the system. In examples where RUs do not support multicast address, FHM-like functionality is brought to small cell networks. In examples, RU selection without using RU bitmask is performed using beam IDs to enable multicasting.

[0029] Conventional 0-RAN systems do not include RUID bitmask or downlink (DL) multicast. Conventional 0-RAN systems do not include coverage overlap of neighbor RUs and no reuse is thusly available. When overlap occurs, the physical cell identity (PCI) of the overlapping RU is different to prevent interference. Conventional 0-RAN systems do not expect single PCI configuration across the RUs. If single PCI configuration happens in conventional 0-RAN, it is referred to as “shared cell”. In examples, each RU needs to be able to determine in which multicast group it is going to receive the packet. In examples, each RU supports multicast transport by registering for a multicast address. In examples, each RU has to join the multicast group(s). In examples, a QSV based multicast requires formation. In examples, one RU may join multiple multicast groups. In examples, the RU may not recognize that a particular multicast packet is for reuse and that other RUs are receiving it in parallel, but it is not necessary for the RU to have this level of knowledge about the other RUs in the system. In examples, an IPv6 interface with one-to-one connection between the DU and each RU is used. In examples, the downlink (DL) includes multicast with RUID and the uplink (UL) includes unicast. In examples, an RUID mask based discard or packet reception can be used to only receive packets intended for the RU. In examples, an RU is configured with multicast and RUID mask discard at the ARM processor level.

[0030] In examples, a loopback messages (LBM) procedure is a procedure defined in the 0-RAN specification to bring up the discovery procedure including RU discovery, transport, network discovery that happens based on LBM procedure. Conventional 0-RAN does not have specific support for CU plane loopback messages (LBM) for multicast. Conventional 0-RAN interface YANG files do not support multicast, so it does not support LBM for the multicast group.

[0031] In examples, the RU discovery procedure includes joining the RU to multicast groups, so information about the RU(s) joining the multicast groups available for receiving packets has to be available to the DU and this confirmation can happen only after the LBM procedure is completed. In examples, there may also be alarms if there is coverage overlap between RUs if one of the RUs has implemented alarms for these situations because the RU is unaware that the same DU is asking for packets to be transmitted by the neighbor RU or the uplink direction transmissions are happening and the RSSI values are very high or it detects some interference during the idle period.

[0032] Figure 1 is a block diagram illustrating an example of a communication system 100. In the example shown in Figures 1, the communication system 100 is implemented using an 0-RAN or other point-to-multipoint distributed base station architecture. The communication system 100 may also be referred to here as a “0-RAN” or a “0-RAN system.” In examples, communication system 100 includes at least one central unit (CU or O-CU) 102, at least one distributed unit (DU or 0-DU) 104, and at least one radio unit (RU or 0-RU) 106 (such as radio unit (RU) 106-1 and any quantity of optional radio unit (RU) 106-2 through optional radio unit (RU) 106- A) configured to serve at least one user equipment (UE) 110 within the site at which wireless services is being provided.

[0033] In examples, the at least one CU 102, at least one DU 104, and at least one RU 106 implement a “base station”, “base station entity”, or “base station system” (which in the context of a fourth generation (4G) Long Term Evolution (LTE) system, may also be referred to as an “evolved NodeB”, “eNodeB”, or “eNB”; in the context of a fifth generation (5G) New Radio (NR) system, may also be referred to as a “gNodeB” or “gNB”; and may take different names in other current or future generations of radio access networks (RAN) and communication networks). In examples, the at least one CU 102 and/or at least one DU 104 are located remotely from the site at which wireless service is being provided, e.g., in centralized banks of nodes. Additionally, the RUs 106 may be physically separated from each other at the site at which wireless service is being provided, although they are each communicatively coupled to at least one DU 104 via the at least one fronthaul network 118. A base station may be used to provide UEs 110 with mobile access to the wireless network operator's core network 112 to enable UEs 110 to wirelessly communicate data and voice (using, for example, Voice over LTE (VoLTE) technology or a 3GPP 5G RAN providing wireless service using a 5G air interface).

[0034] In examples, the communication system 100 implements a base station as a respective 5G NR gNB (only one of which is shown in Figure 1 for ease of illustration). In such a configuration, each CU 102 implements Layer 3 and non-time critical Layer 2 functions for the 5G NR gNB. In examples, each CU 102 may be further partitioned into at least one control-plane entity (“CU-CP”) and at least one user-plane entity (“CU-UP”) that handle the control -plane and user-plane processing of the CU 102, respectively. In examples, each DU 104 is configured to implement the time critical Layer 2 functions and, except as described below, at least some of the Layer 1 functions for the gNB. In this example, each RU 106 is configured to implement the physical layer functions for the gNB that are not implemented in the DU 104 as well as the RF interface. Also, each RU 106 includes or is coupled to a respective set of one or more antennas 108 (such as any of antenna(s) 108-1, antennas(s) 108-2, antennas(s) 108-3, and any quantity of antennas 108-4 through 108-A) used to radiate downlink RF signals to UEs 110 and receive uplink RF signals transmitted by UEs 110.

[0035] In general, the communication system 100 is configured to provide wireless service to various items of user equipment (UEs) 110 (such as user equipment (UE) 110-1 and any quantity of optional user equipment (UE) 110-2 through optional user equipment (UE) 110- B). Unless explicitly stated to the contrary, references to Layer 1, Layer 2, Layer 3, and other or equivalent layers (such as the Physical Layer or the Media Access Control (MAC) Layer) refer to layers of the particular wireless interface (for example, Fourth Generation (4G) Long Term Evolution (LTE) or Fifth Generation (5G) New Radio (NR)) used for wirelessly communicating with UEs 110. Furthermore, it is also to be understood that 5G NR embodiments can be used in both standalone and non- standalone modes (or other modes developed in the future) and the following description is not intended to be limited to any particular mode. Moreover, although some embodiments are described here as being implemented for use with 5GNR, other embodiments can be implemented for use with other wireless interfaces and the following description is not intended to be limited to any particular wireless interface.

[0036] In examples, the at least one CU 102 is communicatively coupled to at least one corresponding core network 112 of the associated wireless operator via at least one backhaul network 114. The at least one backhaul network 114 is typically a public wide area network such as the Internet, though it is understood that the at least one backhaul network 114 can be implemented in other ways. In examples, at least one DU 104 is communicatively coupled to at least one CU 102 via at least one midhaul network 116. In examples, the midhaul interface promulgated by the O-RAN Alliance is used for the midhaul network 116 between the DU 104 and the at least one CU 102. In examples, at least one RU 106 is communicatively coupled to at least one DU 104 via at least one fronthaul network 118. In examples, the fronthaul interface promulgated by the O-RAN Alliance is used for the fronthaul network 118 between each RU 106 and a respective DU 104. In examples, each of the backhaul network 114, the midhaul network 116, and/or the fronthaul network 118 may be implemented with one or more switches, routers, and/or other networking devices. In some examples, the backhaul network 114, the midhaul network 116, and/or the fronthaul network 118 may be implemented with switched Ethernet using a switched Ethernet network and an Ethernet switch.

[0037] Although Figure 1 (and the description set forth herein more generally) is described in the context of 5G embodiments where each logical base station entity is partitioned into a CU 102, DUs 104, and RUs 106 and, for at least some of the physical channels, some physical -lay er processing is performed in the DUs 104 with the remaining physical-layer processing being performed in the RUs 106, it is to be understood that the techniques described here can be used with other wireless interfaces (for example, 4G LTE) and with other ways of implementing a base station entity (for example, using a conventional baseband band unit (BBU)/remote radio head (RRH) architecture). Accordingly, references to a CU, DU, or RU in this description and associated figures can also be considered to refer more generally to any entity (including, for example, any “base station” or “RAN” entity) implementing any of the functions or features described here as being implemented by a CU, DU, or RU. [0038] Each CU 102, DU 104, FHM (described below with reference to Figure 2), and RU 106 and any of the specific features described here as being implemented thereby, can be implemented in hardware, software, or combinations of hardware and software, and the various implementations (whether hardware, software, or combinations of hardware and software) can also be referred to generally as “circuitry,” a “circuit,” or “circuits” that is or are configured to implement at least some of the associated functionality. When implemented in software, such software can be implemented in software or firmware executing on one or more suitable programmable processors (or other programmable device) or configuring a programmable device (for example, processors or devices included in or used to implement special-purpose hardware, general -purpose hardware, and/or a virtual platform). In such a software example, the software can comprise program instructions that are stored (or otherwise embodied) on or in an appropriate non-transitory storage medium or media (such as flash or other non-volatile memory, magnetic disc drives, and/or optical disc drives) from which at least a portion of the program instructions are read by the programmable processor or device for execution thereby (and/or for otherwise configuring such processor or device) in order for the processor or device to perform one or more functions described here as being implemented the software. Such hardware or software (or portions thereof) can be implemented in other ways (for example, in a field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.).

[0039] Moreover, each CU 102, DU 104, FHM (described below with reference to Figure 2), and RU 106, can be implemented as a physical network function (PNF) (for example, using dedicated physical programmable devices and other circuitry) and/or a virtual network function (VNF) (for example, using one or more general purpose servers (possibly with hardware acceleration) in a scalable cloud environment and in different locations within an operator’s network (for example, in the operator’s “edge cloud” or “central cloud”). Each VNF can be implemented using hardware virtualization, operating system virtualization (also referred to as containerization), and application virtualization as well as various combinations of two or more the preceding. Where containerization is used to implement a VNF, it may also be referred to as a “containerized network function” (CNF). For example, in the exemplary embodiment shown in Figure 1, each RU 106 and FHM (described below with reference to Figure 2) is implemented as a PNF and is deployed in or near a physical location where radio coverage is to be provided and each CU 102 and DU 104 is implemented using a respective set of one or more VNFs deployed in a distributed manner within one or more clouds (for example, within an “edge” cloud or “central” cloud). Each CU 102, DU 104, FHM (described below with reference to Figure 2) and RU 106, and any of the specific features described here as being implemented thereby, can be implemented in other ways. [0040] The links shown in the communication system 100 in Figure 1 shows all the RUs 106 being connected to the fronthaul network 118 (which could be implemented with one or more FHMs (described below with reference to Figure 2), switches, routers, and/or other networking devices). The actual physical links between devices in the backhaul network 114, the midhaul network 116, and/or the fronthaul network 118 may be implemented using different media, such as conductive media (copper, multi-rate, multi-mode cables, etc.) and optical media (fiber optic cables). In examples, each RU 106 and each physical node on which each DU 104 is implemented includes one or more Ethernet network interfaces to couple each RU 106 and each physical node implementing the DU 104 to the fronthaul network 118 in order to facilitate communications between the DU 104 and the RUs 106. [0041] The RUs 106 may be deployed at a site to provide wireless coverage and capacity for one or more wireless network operators. The site at which wireless service is being provided may cover, for example, a building or campus or other grouping of buildings (used, for example, by one or more businesses, governments, other enterprise entities) or some other public venue (such as a hotel, resort, amusement park, hospital, shopping center, university campus, arena, or an outdoor area such as a ski area, stadium or a densely populated downtown area). In some configurations, the site at which wireless service is being provided is at least partially (and optionally entirely) indoors, but other alternatives are possible. [0042] Each UE 110 may be a computing device with at least one processor that executes instructions stored in memory, e.g., a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, vehicle-based computer, a desktop computer, etc. [0043] Each CU 102, DU 104, FHM (described below with reference to Figure 2), and RU 106 can be implemented so as to use an air interface that supports one or more of frequencydivision duplexing (FDD) and/or time-division duplexing (TDD). Also, the CU 102, DUs 104, FHM (described below with reference to Figure 2), and RUs 106 can be implemented to use an air interface that supports one or more of the multiple-input-multiple-output (MIMO), single-input-single-output (SISO), single-input-multiple-output (SIMO), and/or beam forming schemes. For example, the CU 102, DUs 104, and RUs 106 can implement one or more of the 5G NR transmission modes. Moreover, the communication system 100 can be configured to support multiple air interfaces and/or to support multiple wireless operators. [0044] In examples in the downlink, the DU 104 communicates downlink control -plane messages, downlink user-plane messages, and uplink control -plane messages to the RU 106- 1, which uses the downlink control-plane and downlink user-plane messages to wirelessly transmit downlink radio frequency signals using a respective set of antennas 108 for reception by UEs 110.

[0045] In examples in the uplink, the RUs 106 wirelessly receive uplink radio frequency signals transmitted from UEs 110 using the respective set of antennas 108 and generate uplink user-plane data from the received RF signals. In examples, an FHM (described below with reference to Figure 2) may also combine user data received from the RUs 106. In examples, the combining is an uplink summation. In examples, the combining is uplink coherent combining that requires phase information for the data.

[0046] In examples in the uplink, for each uplink slot, the serving DU schedules one or more UEs to transmit during that slot. In examples, the DU sends uplink control-plane messages to each RU identifying the resource blocks (RBs) for which the RU should provide baseband IQ data. The RBs for which the RU should provide baseband IQ data are also referred to here as “front-hauled RBs.”

[0047] In embodiments where the baseband IQ data communicated over the fronthaul comprises frequency-domain baseband IQ data, the front-hauled RBs comprise only those RBs that have been assigned to the scheduled UEs 110 for uplink transmissions during that slot. In embodiments where the baseband IQ data communicated over the fronthaul comprises time-domain baseband IQ data, the front-hauled RBs comprise all of the RBs for the slot (due to the time-domain nature of the baseband IQ data). During each uplink slot, for each antenna port, each RU 106 generates respective baseband IQ data for each front-hauled RB from a uplink RF analog signal received via a respective one of the antennas associated with that RU 106. For each RU 106, for each uplink slot, the RU 106 generates uplink userplane message that include the baseband IQ data generated at that RU 106 for the various front-hauled RBs and antenna ports and communicates the uplink user-plane messages northbound.

[0048] Each CU 102, DU 104, FHM (described below with reference to Figure 2), and RU 106, and any of the specific features described here as being implemented thereby, can be implemented in other ways. Additionally, it should be noted that the systems and methods described herein may also be used in other distributed RANs, e.g., a distributed antenna system (DAS).

[0049] Figure 2 is a block diagram illustrating examples of a communication system 200 implementing reuse. In the example shown in Figure 2, the communication system 200 is implemented using an 0-RAN or other point-to-multipoint distributed base station architecture. In the example shown in Figure 2, the communication system 200 is shown with logical connections and hardware switches will exist in between the various connections. In examples, communication system 200 includes a distributed unit (DU or O- DU) 202 (which can be an implementation of DU 104 in Figure 1 as described herein), optional at least one FHM 204 (or FHM like functionality) integrated into the DU 202, and a plurality of radio units (RUs or O-RUs) 206 (such as radio unit (RU or O-RU) 206-1, radio unit (RU or O-RU) 206-2, and any quantity of optional radio unit (RU or O-RU) 206-3 through optional radio unit (RU or O-RU) 206-C which can be implementations of RU 106 in Figure 1 as described herein) configured to serve at least one user equipment (UE) 208 (such as user equipment (UE) 208-1 through user equipment (UE) 208-D which can be implementations of UE 110 in Figure 1 as described herein).

[0050] In examples, the optional FHM 204 is integrated into the distributed unit 202. In examples, a first RU 206-1 is communicatively coupled to the optional FHM 204 of the DU 202 via a first communication link 212-1. In examples, the first RU 206-1 includes a PCI=0 and a beamId=0. In examples, a second RU 206-2 is communicatively coupled to the optional FHM 204 of the DU 202 via a second communication link 212-2. In examples, the second RU 206-2 includes a PCI=0 and a beamId=0. In examples, an optional third RU 206- 3 is communicatively coupled to the optional FHM 204 of the DU 202 via an optional third communication link 212-3. In examples, the optional third RU 206-3 includes a PCI=0 and a beamId=0. In examples, an optional fourth RU 206-C is communicatively coupled to the optional FHM 204 of the DU 202 via an optional fourth communication link 212-C. In examples, the optional fourth RU 206-C includes a PCI=0 and a beamId=0. In examples where optional FHM 204 is not included, the distributed unit 202 may handle multicasting to Rus 206 even without optional FHM 204. In examples utilizing an FHM, predefined beam forming method beamId=0 may not be allowed based on the O-RAN specification and beamld=l or other non-zero beamld may be used.

[0051] In examples, reuse functionality is enabled in system 200 based on Sounding Reference Signal (SRS) measurements. In examples, selective transmission occurs by disabling endpoints on which combining functionality is not enabled. In examples, individual SRS information is received at the DU 202 from each RU 206. In examples, the SRS information is used to enable smart reuse functionality in the system 200. In examples, this requires the optional FHM 204 (or FHM functionality) in the DU 202. In examples, the O- RAN specification describes FHM and/or shared cell solutions. In examples, system 200 uses an O-RAN standard defined selective transmission and reception using beamld. In examples, this is applicable to the shared cell solution and is based on beam based information such that the RUs 206 can selectively select some groups of packets to receive without requiring a separate FHM outside of the DU 202 and closer to the RUs 206. In examples, this is applicable only to FHM mode RUs 206. In examples, each RU 206 is individually treated as a separate link and is not combined. In examples, a group of endpoints in the optional FHM 204 is disabled to configure the optional FHM 204 to not perform combine function(s) in the uplink and to only receive a unicast packet and transmit it towards the DU 202 without combining the packets. In examples, the optional FHM 204 is configured by the DU 202 (or the DU 202 acts as the optional FHM 204) to receive the unicast packet from each RU 206. In examples, the optional FHM 204 is configured to perform either: (1) one-to-one forwarding sending unicast packets toward the individual RUs 206 using the optional FHM 204; or (2) multicast (if multicast is supported by the RUs 206). In examples, the DU 202 multicasts itself to the individual RUs 206. In examples, Ethernet based multicast is used to perform the transmission by sending efficient multicast packets to the UEs 208 using a particular group of RUs 206 which are part of the QSVs of the UE 208 depending on a RUID mask that masks some of the RUs 206. In examples, using efficient multicast enables transmission to the particular QSVs of the RUs 206.

[0052] In examples, each RU 206 reports a neighbor beam list to the DU 202. In examples, the neighbor beam list reports overlapping coverage of RUs 206 to the DU 202. In examples, the neighbor beam list can be used to form a neighbor graph list used for creating multi cast/b earn group mapping information. In examples, the DU 202 configures the RUs 2026 in a shared cell FHM mode. In examples, an IP interface is not needed. In examples, local deployment is used for L2 switching. In examples, low latency is achieved as unnecessary overhead of the network layer processing is supported in switches using snooping. In examples, there is no IP based communication in shared cell and only L2 interface Ethernet communication is supported in the system 200.

[0053] In examples, Precision Time Protocol (PTP) timing using the G.8275.1 PTP profile is used to support the architecture of system 200. In examples, the system 200 uses an Ethernet interface with one-to-one connection between the optional FHM 204 in the DU 202 and the RUs 206 in the downlink (DL). In examples, multicast with or without RUID masks is used in the downlink (DL) while unicast to the optional FHM 204 is used in the uplink (UL). In examples, the RUs 206 have multicast enabled. In examples, an RUID mask is not necessary as several multicasts groups are available to cover all possible quantized signature vector (QSV) of the UEs 208. [0054] In examples, the RUs 206 supports multicast. In examples, the RUs 206 register for certain multicast addresses such that FHM functionality is not needed other than in the DU 202 itself (with optional FHM 204). In examples, the DU 202 can send a packet to a group of RUs 206 (such as RU 206-1 and RU 206-2) by using the multicast address for the group of RUs 206 so that when the packet is sent to that multicast address, only the intended group of RUs 206 (such as RU 206-1 and RU 206-2) receive the packet. In examples supporting multicast addressing, FHM functionality further down in the system 200 closer to the RUs 206 and conversion of a global beam ID is not necessary.

[0055] Figures 3 A-3D are block diagrams illustrating examples of communication systems 300 A and 300B implementing reuse without multicast. In examples implemented without multicast addressing, using a separate FHM functionality closer to the RUs and mapping between an RUIDs and a global beam IDs can be used for similar function. In the examples shown in Figures 3A-3D, the communication system 300 is implemented using an 0-RAN or other point-to-multipoint distributed base station architecture. In examples, communication system 300 includes a distributed unit (DU or 0-DU) 302 (which can be an implementation of DU 104 in Figure 1 as described herein), at least one FHM 304 (or FHM like functionality) separate from the DU 302, and a plurality of radio units (RUs or O-RUs) 306 (such as radio unit (RU or 0-RU) 306-1, radio unit (RU or 0-RU) 306-2, and any quantity of optional radio unit (RU or 0-RU) 306-3 through optional radio unit (RU or 0-RU) 306-E which can be implementations of RU 106 in Figure 1 as described herein) configured to serve at least one user equipment (UE) 308 (such as user equipment (UE) 308-1 through user equipment (UE) 308-F which can be implementations of UE 110 in Figure 1 as described herein). In examples, the at least one FHM 304 is communicatively coupled to the DU 302 and/or the RUs 306 are communicatively coupled to the FHM 304 through a fronthaul network (which may include physical switches (such as a switch 314 described below) positioned between the DU 302 and the FHM 304 and/or between the FHM 304 and the RUs 306). In examples, the FHM 304 may include switching functionality without requiring separate physical switches (such as a switch 314 described below).

[0056] In examples, the FHM 304 is communicatively coupled to the DU 302 via a first communication link 312-1. In examples, a first RU 306-1 is communicatively coupled to the FHM 304 via a second communication link 312-2 such that the first RU 306-1 is communicatively coupled to the DU 302 via the FHM 304. In examples, the first RU 306-1 includes a PCI=0 and a beamld=l. In examples, a second RU 306-2 is communicatively coupled to the FHM 304 via a third communication link 312-3 such that the second RU 306-2 is communicatively coupled to the DU 302 via the FHM 304. In examples, the second RU 206-2 includes a PCI=0 and a beamld=l. In examples, an optional third RU 306-3 is communicatively coupled to the FHM 304 via an optional third communication link 312-4 such that the optional third RU 306-3 is communicatively coupled to the DU 302 via the FHM 304. In examples, the optional third RU 306-3 includes a PCI=0 and a beamld=l. In examples, an optional fourth RU 306-E is communicatively coupled to the FHM 304 via an optional fourth communication link 312-E such that the optional fourth RU 306-E is communicatively coupled to the DU 302 via the FHM 304. In examples, the optional fourth RU 306-C includes a PCI=0 and a beamld=l.

[0057] In examples, the FHM 304 copy function acts as a multicast in the last hop. In examples, a beamld mapping table is implemented in the FHM 304 and no RUID mask discard is needed. In examples, the mapping is one to many for the beamld to multiple RUs 306 such that multiple RUs 306 share a beamld and the beamld can be used to address packets to multiple RUs 306. In examples, it is not guaranteed that all local beam IDs are unique for all non-beamforming RUs 306. In examples, the global beam IDs are assigned in a way such that they are unique for each RU 306. In examples, the mapping is configured by the DU 302 in the FHM 304 using a beam neighbor list shared by the RU 306. In examples, 0-RAN supports many beamlds (such as 32767 beamlds), allowing it to create combinations of RUs 306. In examples, reuse is possible with a single physical cell identity (PCI). In examples, FHM 304 can be integrated as part of an Ethernet switch in system 300 A. In examples, because FHM 304 is a separate entity, it can be at the last hop. In examples, because multicast is needed at the last hop, the FHM 304 is: (1) directly connected to the RUs 306; sits just before the last hop before an access switch; or is integrated as a part of an Ethernet switch or access switch in system 300 A. In examples, the FHM 304 directly sends the packets to the RUs 306.

[0058] In examples, 0-RAN standard RUs can be used as RUs 306 in system 300A without hardware or software changes. In examples, RU 306 discovery occurs per 0-RAN M-plane for shared cell. In examples, a packet is sent to the FHM 304 to configure the FHM 304. In examples, the FHM 304 supports copy, combine, and routing function implementations. In examples, the FHM 304 only supports copy and routing function. In examples, the system 300 uses an Ethernet interface with one-to-one connection between the DU 202, optional FHM 204, and RUs 206 in the downlink. In examples, multicast with or without RUID masks is used in the downlink (DL) while unicast to the optional FHM 204 is used in the uplink (UL). [0059] In examples, the FHM 304 is configured with a beam map that maps global beam mapping to local beam mapping. In examples, the mapping also occurs between the neighbor list when there is neighbor list information available. In examples, predefined beamforming described in the 0-RAN specification is used. In examples of the predefined beamforming method, there is an overlapping list of which neighbor RUs 306 are overlapping that is available. In examples, the optional FHM 204 is configured to group the RUs 306 that are part of overlapping beams based on the selective beam ID user beam concept. In examples with overlapping RU 306 beams, the mapping is used to identify the overlapping RU 306 that have an interference. In examples while reusing, the same PRB location is not used for the same UEs 308 or multiple UEs 308 which are being served by the QSV of RUs 306 which are part of an overlapping neighbor list. In examples, the FHM 304 sends messages to each RU 206 using the section type 1 message to send a global beam ID that is representative of an RUID mask used to identify an RU 206. In examples, the global beam ID is a 64 bit value. [0060] In examples, the DU 302 is 0-RAN compliant and transmits using a beam ID. In example, the DU 302 sends a message using section type 1 that includes a field called beam ID that is used to send the global beam ID. In examples, the global beam ID can be converted to a local beam ID. In examples, the global beam ID is compressed from 64 bits to 15 bits used by the local beam ID field. In examples, the global beam ID to local beam ID conversion is stored in a table. In examples, the FHM 304 can extract a combination for the 64 bit to 15 bit compression and map the compressed bit information to the group. In examples, a global beam ID received from the DU 302 is mapped to the local beam ID in the FHM 304 using the mapping table to create a unique hash key. In examples, the unique hash key is created from the 64 bit global beam ID into a 15 bit local beam ID through compression to generate the unique hash key for the mapping table. In examples, the FHM 304 receives a 15 bit local beam ID and transmits it to the particular group of RUs 306 represented by the 15 bit local beam ID.

[0061] In examples, section extension type 10 is used to transmit the packets. In examples, a particular beam ID’s global beam ID is assigned a broadcast beam ID. In examples, when the DU 302 sends a beam ID, then the FHM 304 broadcasts those packets to all the RUs 306 which are connected to the FHM 304. In examples, the FHM 304 forwards the packets to all the RUs 306 sharing the common endpoint on which the copy function is enabled. In examples, section extension 10 is used to create a one-to-one mapping because it allows information from the 64 ports to be transmitted. In examples, section extension type 10 can be used with section type 5 or section type 1. In examples, section type 5 differs from section type 1 because section type 5 includes a field called UE ID while section type 1 includes a field called beam ID. In examples, the beam ID field of section type 1 with section extension 10 is used instead of the UE ID field of section type 5 with section extension 10. In examples, this allows the combination of a group having a similar number of ports for one particular group of RUs 306. In examples, one section type and/or section extension are used for one particular group of RUs and a different section type and/or section extension are used for another particular group of RUs. In examples, a ports can be grouped with extended antenna-carrier identifier (eAxC ID) and each port can be treated as one particular RU 306. In examples, with section extension 10, each beam ID will have its own mapping to one particular RU. In examples, a global beam ID is sent to the FHM 304 from the DU 302 and the FHM 304 does the reformatting and conversion to the local beam ID that are sent to the individual RUs 306. In examples, section extension 10 has been included in the specification as part of shared cell usage and FHM 304 supports section extension 10 features. In examples, this enable the FHM 304 to do one-to-one mapping to the RUs 306 such that each RU 306 is considered to be one individual beam.

[0062] In examples, the FHM 304 receives packets from the DU 302 with particular one- to-one beam IDs. In examples, the mapping is configured for selective beam ID function. In examples, the DU 302 configures the map of global beam ID to local beam ID on the FHM 304. In examples, the FHM 304 receives the global beam ID as bits from the DU 302. In examples, the FHM 304 is configured to send packets to RUs 306 based on the global beam ID value coming as bits from the DU 302 applied to the map of global beam ID to local beam ID. In examples, the global beam ID bits when applied to the mapping at the FHM 304 cause the FHM 304 go forward the packets to a particular group of RUs 306 based on the QSV of the UE 308. In examples, a global ID bit combination (provided with a packet) when applied to the map at the FHM 304 map to a particular group of RUID to which the packet will be forwarded.

[0063] In examples, the DU 302 provides a beam ID with packets sent to the FHM 304 and the FHM 304 uses the beam ID and the mapping stored on the FHM 304 to map the beam ID to a particular multicast group of RUs 306 and forwards the packet to the group of RUs 306 identified by the beam ID via the mapping stored on the FHM 304. In examples, packets are forwarded to the correct RUs 306 based on the global beam ID to local beam ID mapping performed by the FHM 304. In examples, the FHM 304 reformats for communication with the RUs 306 using the local beam ID and creates its own packet where it overwrites the beam ID field with the local beam ID field. In examples, the FHM 304 receives the section extension 10, but sends a normal section type 1 packet to the RUs 306. In examples, the information regarding the PRB location and symbol allocation is sent to the RUs 306 from the FHM 304. In examples, all the antennas’ PRB configuration is sent in one section extension 10 message from the FHM 304 to the RUs 306. In examples, this section extension 10 message is created at the FHM 304 for all the antennas supported on the RU 306 (at the FHM 304) or the DU 302 itself can send it separately because it is using section extension type 1.

[0064] In examples, the local beam ID will be communicated from each RU 306 to the DU 302 during the initial discovery (setup and configuration) process between the RU 306 and the DU 302. In examples, the DU 302 has information about how many RUs 306 there are and has additional information about the RUs 306. In examples, each RU 306 provides a beam configuration YANG file to report its local beam ID to the DU 302. In examples, each RU 306 has selective beam ID functionality and reports a predefined beam using a beamforming YANG configuration file. In examples, beam IDs are assigned to RUs 306 based on rules. In examples, when the DU 302 wants to send a packet to certain RUs 306, it uses the beam IDs to identify the group of RUs 306 that will be receiving the packet. In examples where an RU 306 has multiple beams, the RU 306 can provide multiple local beam IDs to the DU 302. In examples where an RU 306 has a single beam, the RU 306 can provide a single beam ID.

[0065] In examples, a global beam ID is used to segregate certain groups of RUs 306. In examples, a global beam ID consisting of RU 306-1, RU 306-2, and RU 306-3 reflects that combination of the value that maps to RU 306-1, RU 306-2, and RU 306-3. In examples, the FHM 304 is not necessary if each RU is assigned a unique beam ID (such that the beam ID of all RUs are unique from one another) and it is not necessary to convert map beam IDs in and FHM 304.

[0066] In examples, there is a reduction in fronthaul (FH) delay by sending a C/U pair per reuse layer. In examples, RUID mask transmission occurs using beam ID in a section type 1 control message. In examples, encoding of RUID bitmask to beam ID can be done by using a unique hash key mapped to a unique combination of RUID bitmask. In examples, the hash key size will be limited within 15 bits of beamld field of C-Plane. In examples, U-Plane mapping using C-Plane section ID as each section has beamld. In examples, M-Plane allows configuring the map of the Global beam ID to the local beam ID on the FHM 304 from the DU 302. [0067] In examples, section type 5 control messages are used with section extension 10 for RUID mask to beam group mapping. In examples, the same section ID can be transmitted to the beam group mapping to RUID mask. In examples, it is a one-to-one mapping of beamld and RUID. In examples, mapping up to 64 port/beamld is allowed in 0-RAN. In examples, Section Extension (SE) 10 usage is not defined in 0-RAN for shared cells but does not restrict the use described here. In examples, the RUs 306 need to support the extended antenna-carrier identifier (eAxC ID) grouping feature to use Section Extension (SE) 10 beamGroupType 10. In examples, DU 302 does not need to configure the extended antennacarrier identifier (eAxC ID) grouping feature on the RUs 306 mandatorily to use Section Extension (SE) 10.

[0068] In examples implementing reuse with Antenna Mask as beamld, Section Type 5 is used with Section Extension (SE) 16, which can provide further optimization in comparison to Section Extension (SE) 10. In examples, antMask is a 64 bit field (as is RUID Mask). In examples, the RUs 306 interpret antMask similar to an RUID Mask. In examples, the FHM 304 interprets antMask as local beamld in shared cell. In examples, the RUs 306 cannot interpret antMask as beamld based on the 0-RAN specification. In examples, the antMask field can be used with an FHM 304. In other examples, the antMask field can be used without an FHM 304. In examples, we do not need the support of selective beam ID feature, so the RUs 306 do not need to report their beam information. In examples, a shared cell can be created on the selective beam ID functionality without using a beam ID by mapping through the AntMask bits. In examples, each bit maps to one particular RUID. In examples, the mapping is created on the FHM 304 to create a global ID to local beam ID mapping that can be created on the FHM 304 where each bit maps to one particular RU 306. In examples, the packet will be forwarded from the FHM 304 to the particular RU 306. In examples, the DU 302 configures the antMask on the FHM 304 to map the particular RUID.

[0069] In examples, PTP timing using the full timing profile 8275.1 is used to support the architecture of system 300 because it does not need L3 PTP. In examples, it is possible to use a partial timing profile 8275.2 with modification to software at ARM processing level for RUs 306. In examples, PTP is over UDP+Ethemet. In examples, FHM 304 operates in Boundary Clock (BC) mode. In examples, DU 302 operates in Boundary Clock (BC) mode. In examples, the RUs 306 have a separate port for PTP and receive timing via Configuration C3. In examples, shared calls currently only consider Ethernet-based flow and 8275.1 supports Ethernet-based multicast. In examples, C3 is regarding receiving PTP packets from GM connected directly to fronthaul networks. In examples, other telecom profiles are used which support L2 transport.

[0070] In examples of Global Beam Id to Local Beam Id mapping where Section Type 5 control messages are used with Section Extension (SE) 10 beamGroupType 10, a mapping table is not necessary at the FHM 304. In examples, each RUID will be beamportld in Section Extension (SE) 10. In examples, FHM 304 reconstructs C-Plane eCPRI payload and fills local beamld field with a single beamld reported by a non-beamforming RU 306. In examples, any 0-RAN compliant DU 302 can perform reuse using this 0-RAN feature. Please see the following example table mapping Global Beam Id to RUID and Local Beam Id. In examples, a RUID global beam ID functions similar to an RUID mask, enabling similar mapping from the global beam ID to RUID and sending it towards those RUIDs.

[0071] Figure 3B shows an example system 300B with the FHM 304 after access switch 314-1 and before access switch 314-2 and access switch 314-3. In examples, when the FHM 304 is connected to RUs 306 using access switch 314-2 and access switch 314-3, inter-switch link from FHM 304 to access switch 314-2 and access switch 314-3 can increase depending on reuse factor. In examples, last hop multicast is used. In examples, multicast is needed in RUs 306 or inter-switch link bandwidth needs to be allocated to accommodate reuse factor. In examples: (1) virtual cell 1 with global beam ID X covers RU 306-1 and RU 306-2; (2) virtual cell 2 with global beam ID Y covers RU 306-2 and RU 306-3; and (3) virtual cell 3 with global beam ID Z covers RU 306-3 and RU 306-4.

[0072] Figure 3C shows an example system 300C with FHM 304-1 and FHM 304-2 after access switch 314-1, access switch 314-2, and access switch 314-3. In examples, when the FHM 304-1 and FHM 304-2 connect directly to RUs 306, last multicast is not required and inter-switch link does not increase with reuse factor. In examples, multicast from DU 302 to FHM 304 when doing transmission in virtual cell 2. In examples, there is no need to enable multicast in RUs 306. In examples, shared cell is extended across distributed FHM 304 which is not explained in 0-RAN, but does not violate 0-RAN protocol. In examples, an ICN could be used for FHM 304. In examples: (1) virtual cell 1 with global beam ID X covers RU 306-1 and RU 306-2; (2) virtual cell 2 with global beam ID Y covers RU 306-2 and RU 306-3; and (3) virtual cell 3 with global beam ID Z covers RU 306-3 and RU 306-4. [0073] Figure 3D shows an example system 300D with FHM 304-1 after access switch 314-1 and FHM 304-2 after FHM 304-1. In examples, when the FHM 304-1 and/or FHM 304-2 connect directly to RUs 306 and has hardware limitation to support only a certain quantity of RUs 306 when more are needed (such as hardware limitation to support only 32 RUs 306 and shared cell needing to support 64 RUs 306), two FHMs (FHM 304-1 and FHM 304-2) are connected in cascade to extend Global ID to local beam ID to forward packet to cascaded FHM 304-2. In examples, cascade FHM 304-2 works as defined in 0-RAN using global beamld to local beam ID mapping. In examples, 0-RAN does not describe selective beamld for this mode. In examples: (1) virtual cell 1 with global beam ID X covers RU 306- 1 and RU 306-2; (2) virtual cell 2 with global beam ID Y covers RU 306-2 and RU 306-3; and (3) virtual cell 3 with global beam ID Z covers RU 306-3 and RU 306-4.

[0074] Figure 4 is a flow diagram illustrating an example method 400 for implementing smart reuse in an open radio access network using multicast in the downlink. Example method 400 begins at block 402 with receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network. In examples, the plurality of radio units (or a single radio unit) subscribes to a switch for at least one multicast address. Example method 400 proceeds to block 404 with receiving, at the distributed unit, a downlink packet for transmission to the plurality of radio units being used for reuse. In examples, receiving, at the distributed unit, the downlink packet for transmission to the plurality of radio units being used for reuse is from a central unit of the open radio access network implementing smart reuse. Example method 400 proceeds to block 406 with transmitting, from the distributed unit, the downlink packet using the particular multicast address to the plurality of radio units. In examples, the distributed unit sends packets with a specific multicast address in the destination address field. In examples, the switch is configured to forward those packets to the plurality of radio units that subscribed to the multicast address. In examples, the plurality of radio units are configured to be subscribed to the multicast address and the distributed unit is aware of the configuration.

[0075] Figure 5 is a flow diagram illustrating an example method 500 for implementing smart reuse in an open radio access network using multicast in the uplink. Example method 500 begins at block 502 with receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network. In examples, the plurality of radio units (or a single radio unit) subscribes to a switch for at least one multicast address. Example method 500 proceeds to block 504 with transmitting, from the distributed unit, a command to the plurality of radio units using the multicast address to command the plurality of radio units to send uplink data to the distributed unit. In examples, the distributed unit sends packets with a specific multicast address in the destination address field. In examples, the switch is configured to forward those packets to the plurality of radio units that subscribed to the multicast address. In examples, the plurality of radio units are configured to be subscribed to the multicast address and the distributed unit is aware of the configuration. [0076] Figure 6 is a flow diagram illustrating an example method 600 for implementing smart reuse in an open radio access network without multicast in the downlink. Example method 600 begins at block 602 with receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse. In examples, receiving, at the fronthaul multiplexer, the downlink packet from the distributed unit is via at least one Ethernet switch. Example method 600 proceeds to block 604 with identifying, at a fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer. Example method 600 proceeds to block 606 with transmitting, from the fronthaul multiplexer, the downlink packet to the plurality of radio units identified by the beam ID. In examples, transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a first Ethernet switch. In examples, transmitting, from the multiplexer, the downlink packet to a second set of radio units of the plurality of radio units is via a second Ethernet switch that is different from the first Ethernet switch. In examples, transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a second fronthaul multiplexer.

[0077] Figure 7 is a flow diagram illustrating an example method 700 for implementing smart reuse in an open radio access network without multicast in the uplink. Example method 700 begins at block 702 with receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse. In examples, receiving, at the fronthaul multiplexer, the downlink packet from the distributed unit is via at least one Ethernet switch. Example method 700 proceeds to block 704 with identifying, at a fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer. Example method 700 proceeds to block 706 with transmitting, from the fronthaul multiplexer, a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit. In examples, transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a first Ethernet switch. In examples, transmitting, from the multiplexer, the downlink packet to a second set of radio units of the plurality of radio units is via a second Ethernet switch that is different from the first Ethernet switch. In examples, transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a second fronthaul multiplexer.

[0078] Terminology

[0079] Brief definitions of terms, abbreviations, and phrases used throughout this application are given below.

[0080] The term “determining” and its variants may include calculating, extracting, generating, computing, processing, deriving, modeling, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[0081] The phrase “based on” does not mean “based only on,” unless expressly specified otherwise. In other words, the phrase “based on” describes both “based only on” and “based at least on”. Additionally, the term “and/or” means “and” or “or”. For example, “A and/or B” can mean “A”, “B”, or “A and B”. Additionally, “A, B, and/or C” can mean “A alone,” “B alone,” “C alone,” “A and B,” “A and C,” “B and C” or “A, B, and C.”

[0082] The terms “connected”, “coupled”, and “communicatively coupled” and related terms may refer to direct or indirect connections. If the specification states a component or feature “may,” “can,” “could,” or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic. [0083] The terms “responsive” or “in response to” may indicate that an action is performed completely or partially in response to another action. The term “module” refers to a functional component implemented in software, hardware, or firmware (or any combination thereof) component.

[0084] The methods disclosed herein comprise one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

[0085] While detailed descriptions of one or more configurations of the disclosure have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the disclosure. For example, while the configurations described above refer to particular features, functions, procedures, components, elements, and/or structures, the scope of this disclosure also includes configurations having different combinations of features, functions, procedures, components, elements, and/or structures, and configurations that do not include all of the described features, functions, procedures, components, elements, and/or structures. Accordingly, the scope of the present disclosure is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof. Therefore, the above description should not be taken as limiting.

EXAMPLES

[0086] Example 1 includes a distributed unit for use in an open radio access network implementing smart reuse, the distributed unit comprising: circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

[0087] Example 2 includes the distributed unit of Example 1, wherein the circuitry of the distributed unit is configured to receive the downlink packet for transmission to the plurality of radio units being used for reuse from a central unit of the open radio access network implementing smart reuse.

[0088] Example 3 includes a distributed unit for use in an open radio access network implementing smart reuse, the distributed unit comprising: circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

[0089] Example 4 includes a method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receiving, at the distributed unit, a downlink packet for transmission to the plurality of radio units being used for reuse; and transmitting, from the distributed unit, the downlink packet using the particular multicast address to the plurality of radio units.

[0090] Example 5 includes the method of Example 4, wherein receiving, at the distributed unit, the downlink packet for transmission to the plurality of radio units being used for reuse is from a central unit of the open radio access network implementing smart reuse.

[0091] Example 6 includes a method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmitting, from the distributed unit, a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

[0092] Example 7 includes an open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

[0093] Example 8 includes the open radio access network of Example 7, wherein the circuitry of the distributed unit is configured to receive the downlink packet for transmission to the plurality of radio units being used for reuse from a central unit of the open radio access network implementing smart reuse. [0094] Example 9 includes the open radio access network of any of Examples 7-8, wherein the circuitry of the distributed unit is configured to: configure the plurality of radio units to operate in a shared cell mode.

[0095] Example 10 includes an open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within an open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

[0096] Example 11 includes the open radio access network of any of Examples 7-10, wherein the circuitry of the distributed unit is configured to: configure the plurality of radio units to operate in a shared cell mode.

[0097] Example 12 includes a fronthaul multiplexer for use in an open radio access network implementing smart reuse, the fronthaul multiplexer comprising: circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID.

[0098] Example 13 includes the fronthaul multiplexer of Example 12, wherein the circuitry of the fronthaul multiplexer is configured to receive the downlink packet having the beam ID from the distributed unit via at least one Ethernet switch.

[0099] Example 14 includes the fronthaul multiplexer of any of Examples 12-13, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a first set of radio units of the plurality of radio units via a first Ethernet switch.

[0100] Example 15 includes the fronthaul multiplexer of Example 14, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a second set of radio units of the plurality of radio units via a second Ethernet switch that is different from the first Ethernet switch.

[0101] Example 16 includes the fronthaul multiplexer of any of Examples 12-15, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a first set of radio units of the plurality of radio units via a second fronthaul multiplexer. [0102] Example 17 includes a fronthaul multiplexer for use in an open radio access network implementing smart reuse, the fronthaul multiplexer comprising: circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

[0103] Example 18 includes a method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, the downlink packet to the plurality of radio units identified by the beam ID.

[0104] Example 19 includes the method of Example 18, wherein: receiving, at the fronthaul multiplexer, the downlink packet from the distributed unit is via at least one Ethernet switch. [0105] Example 20 includes the method of Example 19, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a first Ethernet switch.

[0106] Example 21 includes the method of Example 20, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a second set of radio units of the plurality of radio units is via a second Ethernet switch that is different from the first Ethernet switch.

[0107] Example 22 includes the method of any of Examples 19-21, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a second fronthaul multiplexer.

[0108] Example 23 includes a method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit. [0109] Example 24 includes an open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID.

[0110] Example 25 includes the open radio access network of Example 24, further comprising: the distributed unit communicatively coupled to the fronthaul multiplexer so that the fronthaul multiplexer is communicatively coupled between the distributed unit and the plurality of radio units.

[0111] Example 26 includes the open radio access network of any of Examples 24-25, further comprising: at least one Ethernet switch communicatively coupled between the distributed unit and the fronthaul multiplexer; and wherein the circuitry of the fronthaul multiplexer is configured to receive the downlink packet having the beam ID from the distributed unit via the at least one Ethernet switch.

[0112] Example 27 includes the open radio access network of Example 26, further comprising: a first Ethernet switch communicatively coupled between the fronthaul multiplexer and a first set of radio units of the plurality of radio units; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the first set of radio units of the plurality of radio units via the first Ethernet switch.

[0113] Example 28 includes the open radio access network of Example 27, further comprising: a second Ethernet switch communicatively coupled between the fronthaul multiplexer and a second set of radio units of the plurality of radio units, wherein the second Ethernet switch is different from the first Ethernet switch; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the second set of radio units of the plurality of radio units via the second Ethernet switch.

[0114] Example 29 includes the open radio access network of any of Examples 24-28, further comprising: a second fronthaul multiplexer communicatively coupled between the fronthaul multiplexer and a first set of radio units of the plurality of radio units; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the first set of radio units of the plurality of radio units via the second fronthaul multiplexer. [0115] Example 30 includes an open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

Claims

CLAIMS What is claimed is:

1. A distributed unit for use in an open radio access network implementing smart reuse, the distributed unit comprising: circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

2. The distributed unit of claim 1, wherein the circuitry of the distributed unit is configured to receive the downlink packet for transmission to the plurality of radio units being used for reuse from a central unit of the open radio access network implementing smart reuse.

3. A distributed unit for use in an open radio access network implementing smart reuse, the distributed unit comprising: circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

4. A method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receiving, at the distributed unit, a downlink packet for transmission to the plurality of radio units being used for reuse; and transmitting, from the distributed unit, the downlink packet using the particular multicast address to the plurality of radio units.

5. The method of claim 4, wherein receiving, at the distributed unit, the downlink packet for transmission to the plurality of radio units being used for reuse is from a central unit of the open radio access network implementing smart reuse.

6. A method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a distributed unit of the open radio access network, information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; and transmitting, from the distributed unit, a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

7. An open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within the open radio access network; receive a downlink packet for transmission to the plurality of radio units being used for reuse; and transmit the downlink packet using the particular multicast address to the plurality of radio units.

8. The open radio access network of claim 7, wherein the circuitry of the distributed unit is configured to receive the downlink packet for transmission to the plurality of radio units being used for reuse from a central unit of the open radio access network implementing smart reuse.

9. The open radio access network of claim 7, wherein the circuitry of the distributed unit is configured to: configure the plurality of radio units to operate in a shared cell mode.

10. An open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a distributed unit communicatively coupled to the plurality of radio units, the distributed unit including circuitry configured to: receive information regarding subscription to a particular multicast address to be used for reuse by a plurality of radio units within an open radio access network; and transmit a command to the plurality of radio units using the particular multicast address to command the plurality of radio units to send uplink data to the distributed unit.

11. The open radio access network of claim 7, wherein the circuitry of the distributed unit is configured to: configure the plurality of radio units to operate in a shared cell mode.

12. A fronthaul multiplexer for use in an open radio access network implementing smart reuse, the fronthaul multiplexer comprising: circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID.

13. The fronthaul multiplexer of claim 12, wherein the circuitry of the fronthaul multiplexer is configured to receive the downlink packet having the beam ID from the distributed unit via at least one Ethernet switch.

14. The fronthaul multiplexer of claim 12, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a first set of radio units of the plurality of radio units via a first Ethernet switch.

15. The fronthaul multiplexer of claim 14, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a second set of radio units of the plurality of radio units via a second Ethernet switch that is different from the first Ethernet switch.

16. The fronthaul multiplexer of claim 12, wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to a first set of radio units of the plurality of radio units via a second fronthaul multiplexer.

17. A fronthaul multiplexer for use in an open radio access network implementing smart reuse, the fronthaul multiplexer comprising: circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

18. A method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, the downlink packet to the plurality of radio units identified by the beam ID.

19. The method of claim 18, wherein: receiving, at the fronthaul multiplexer, the downlink packet from the distributed unit is via at least one Ethernet switch.

20. The method of claim 19, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a first Ethernet switch.

21. The method of claim 20, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a second set of radio units of the plurality of radio units is via a second Ethernet switch that is different from the first Ethernet switch.

22. The method of claim 19, further comprising: transmitting, from the fronthaul multiplexer, the downlink packet to a first set of radio units of the plurality of radio units is via a second fronthaul multiplexer.

23. A method for implementing smart reuse in an open radio access network, the method comprising: receiving, at a fronthaul multiplexer of the open radio access network, a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identifying, at the fronthaul multiplexer, a plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmitting, from the fronthaul multiplexer, a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.

24. An open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit the downlink packet to the plurality of radio units identified by the beam ID.

25. The open radio access network of claim 24, further comprising: the distributed unit communicatively coupled to the fronthaul multiplexer so that the fronthaul multiplexer is communicatively coupled between the distributed unit and the plurality of radio units.

26. The open radio access network of claim 24, further comprising: at least one Ethernet switch communicatively coupled between the distributed unit and the fronthaul multiplexer; and wherein the circuitry of the fronthaul multiplexer is configured to receive the downlink packet having the beam ID from the distributed unit via the at least one Ethernet switch.

27. The open radio access network of claim 26, further comprising: a first Ethernet switch communicatively coupled between the fronthaul multiplexer and a first set of radio units of the plurality of radio units; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the first set of radio units of the plurality of radio units via the first Ethernet switch.

28. The open radio access network of claim 27, further comprising: a second Ethernet switch communicatively coupled between the fronthaul multiplexer and a second set of radio units of the plurality of radio units, wherein the second Ethernet switch is different from the first Ethernet switch; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the second set of radio units of the plurality of radio units via the second Ethernet switch.

29. The open radio access network of claim 24, further comprising: a second fronthaul multiplexer communicatively coupled between the fronthaul multiplexer and a first set of radio units of the plurality of radio units; and wherein the circuitry of the fronthaul multiplexer is configured to transmit the downlink packet to the first set of radio units of the plurality of radio units via the second fronthaul multiplexer.

30. An open radio access network implementing smart reuse, the open radio access network comprising: a plurality of radio units, wherein each of the plurality of radio units includes circuitry for exchanging radio frequency signals with at least one user equipment; and a fronthaul multiplexer communicatively coupled to the plurality of radio units, the fronthaul multiplexer including circuitry configured to: receive a downlink packet having a beam ID from a distributed unit in the open radio access network implementing smart reuse; identify a set of the plurality of radio units corresponding to the beam ID using a beam ID map stored at the fronthaul multiplexer; and transmit a command to the plurality of radio units identified by the beam ID to command the plurality of radio units to send uplink data to the distributed unit.