Integrated wireless network with multi-operator and multi-signaling format fronthaul capabilities

Abstract

The present disclosure relates to an integrated wireless network capable of hosting multiple network operators, each of which may transmit and receive packetized signals over a fronthaul network, each of which may have one or more prioritized packet streams, whereby a given network operator may have multiple prioritized packet streams with different priorities and the multiple network operators may have differentiated priorities among one another, the integrated wireless network also comprising a switch / monitor that (1) identifies one or more network operators when they exceed their respective allocations and mitigate the violations, and (2) identifies bottlenecks in the fronthaul network and takes action to mitigate the bottlenecks by reducing or preventing lower priority packet streams.

Description

[Technical Field]

[0001] The present invention relates to wireless communications, and more particularly to integrated radio systems capable of handling multiple operators and multiple signaling formats. [Background technology]

[0002] Traditionally, wireless communication networks were built and owned by mobile network operators (MNOs). These network operators' Radio Access Networks (RANs) and other infrastructure elements were proprietary and included dedicated hardware designed by each network operator. Over time, distributed antenna systems (DASs) emerged as a solution to enable high-quality, continuous coverage in areas such as large buildings, airports, transportation systems, and stadiums. Each network operator's DAS deployment, like other infrastructure elements, included proprietary solutions compatible only with that network operator's network. Traditional DAS implementations included an analog RF network interface, which connected the DAS to an RF signal source from the network operator's base transceiver station (BTS). The DAS then distributed the RF analog signal to its numerous remote units (RUs). Other conventional DAS solutions may connect to a network operator's BTS via digital signals conforming to the Common Public Radio Interface (CPRI) standard or packetized digital signals according to the eCPRI protocol that can be transmitted over Ethernet. For eCPRI delivery, for downlink signals, the DAS Point of Interface (POI) receives analog signals from the BTS, converts them to time-domain digital signals, packetizes the time-domain digital signals, and transmits the packets over Ethernet to the appropriate RU. The RU receives the packetized time-domain signals, reassembles them, converts them back to analog signals, and transmits them over its antenna.For uplink signals, RUs receive am RF signals from one or more wireless devices or user equipment (UE), convert them to digital time-domain signals, packetize the signals, and transmit the packets over Ethernet to a point of interconnect (POI). The POI then reconstructs an RF analog signal from the packetized data and transmits the RF analog signal to the BTS. The BTS may operate using one of several legacy RAN technologies, such as 2G, 3G, or LTE.

[0003] An LTE eNodeB may communicate with RUs connected to it through either a CPRI or eCPRI fronthaul connection. In either case, DL signals from and UL signals to the LTE eNodeB are digitized time-domain RF signals. In the case of eCPRI, the digitized time-domain signals are packetized as described above. LTE eNodeBs and 5G gNodeBs are examples of baseband units (BBUs) that perform RAN protocol stack functions for LTE and 5G, respectively. As used herein, a BBU connects to a network operator's backbone network via a standard packetized digital interface and may connect to either one or more RUs and / or one or more distributed antenna systems.

[0004] 5G gNodeB fronthaul communications involve splitting BBU functions between a Central Unit (CU) and one or more Distributed Units (DUs) to optimally utilize processing that is better performed centrally, closer to the backbone network, and processing that is better performed remotely, closer to the network edge. The 5G CU is then connected to the DU via a standardized interface defined by 3GPP. This interface (hereinafter referred to as "F1") provides GPRS Tunneling Protocol (GTP) over an Ethernet connection between the CU and DU.

[0005] Another form of functional division is physical (PHY) layer division, referred to as 7.2x division by the O-RAN Alliance. 7.2x division is implemented within the 5G or LTE PHY layer, enabling centralization of upper PHY layer processing (either at the eNodeB or gNodeB) and distribution of lower PHY layer processing within the RU for both the uplink (UL) and downlink (DL). Further referring to 7.2x division, the uplink and downlink data relayed between the upper and lower PHY layers consist of frequency-domain physical channel data, such as the Physical Uplink Shared Channel (PUSCH), Physical Downlink Shared Channel (PDSCH), Physical Downlink Control Channel (PDCCH), and Physical Random-Access Channel (PRACH). Transmission between the upper and lower PHY layers may occur over a packetized network, such as using eCPRI as the transport mechanism for relaying data packets over an Ethernet connection. This allows the upper PHY layer processing to occur in the eNodeB or gNodeB, and therefore the lower PHY layer processing to occur in the RU. Any given central unit or DU may communicate with multiple remote units.

[0006] An emerging trend in the wireless communications industry is that multiple network operators may share a single RAN or DAS. In this example, a neutral host or neutral location may provide its own wireless network infrastructure. This trend can introduce the following complications: Traditionally, DAS and / or RAN infrastructure is designed and deployed by a given network operator. As a result, a network operator may design its system for the maximum expected traffic load, assuming it is the only user of its infrastructure. However, in the case of neutral hosts and multi-operator networks, it may be impossible to predict the cumulative load on the network that results when multiple network operators or private networks use a single network infrastructure.

[0007] Another key feature of a desirable modern wireless communications infrastructure is that it not only needs to deliver the latest services such as 5G, but also needs to be backward compatible with LTE eNodeBs, 3G NodeBs, and even 2G BTSs, which presents a major challenge in deploying a modern 5G infrastructure.

[0008] The above RAN and DAS examples involve Ethernet-based fronthaul. In a less-than-ideal fronthaul network, bursts of packet traffic can disrupt or delay packetized signaling and synchronization transmissions, resulting in bandwidth limitations and / or latency issues. The O-RAN Alliance specifications mention the possibility of a fronthaul-aware scheduler, whereby the MAC scheduler in the CU protocol stack can receive feedback on the state of the fronthaul network and make scheduling decisions accordingly, similar to how scheduling decisions are based on channel state information and other less-than-ideal signaling factors. However, the O-RAN specifications do not address fronthaul-aware scheduling, such as for a fronthaul network shared by multiple network operators with multiple RAN technologies and multiple remote units.

[0009] Therefore, there is a need for a fronthaul-aware, converged wireless edge network that can accommodate multiple network operators and private networks and multiple RAN technologies simultaneously, and that can accommodate sudden increases in traffic demands in a manner that is acceptable to the network operators and private networks that comprise the network. Summary of the Invention

[0010] One aspect of the present disclosure relates to a method for allocating fronthaul bandwidth resources among multiple network operators in a wireless network, the method including: assigning a priority hierarchy including allocations of fronthaul bandwidth resources to multiple network operators, establishing packet-based communications between multiple baseband processors corresponding to each of the network operators and multiple remote units, routing multiple packet streams between each of the multiple baseband processors and the multiple remote units, monitoring fronthaul traffic for one or more allocation violations or congestion anomalies, and suppressing the allocation violations or congestion anomalies based on results of the monitoring.

[0011] Another aspect of the present disclosure also relates to a method for allocating fronthaul bandwidth resources among multiple network operators in a wireless network, the method including: assigning a priority hierarchy to multiple network operators, the priority hierarchy including one or more network types corresponding to each of the multiple network operators, establishing packet-based communications between multiple baseband processors corresponding to each of the network operators and multiple remote units, routing multiple packet streams between each of the multiple baseband processors corresponding to a network operator and the multiple remote units, monitoring the packet streams for congestion anomalies, and suppressing the congestion anomalies based on results of the monitoring. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an example of an integrated wireless network according to the present disclosure. [Figure 2] FIG. 1 illustrates an example switch / monitor unit according to the present disclosure. [Figure 3] FIG. 2 illustrates an example of a traffic monitor according to the present disclosure. [Figure 4] FIG. 1 illustrates an example of a remote unit according to the present disclosure. [Figure 5A]FIG. 1 illustrates a channel / carrier based priority allocation solution according to the present disclosure. [Figure 5B] FIG. 1 illustrates a fixed percentage based priority allocation solution according to the present disclosure. [Figure 5C] FIG. 1 illustrates priority allocation based on traffic type according to the present disclosure. [Figure 6] FIG. 1 illustrates an example process for allocating fronthaul bandwidth according to pre-agreed priorities according to the present disclosure. [Figure 7] FIG. 1 illustrates an example process for allocating fronthaul bandwidth using a fixed percentage-based priority allocation solution. DETAILED DESCRIPTION OF THE INVENTION

[0013] FIG. 1 illustrates an example of an integrated wireless network 100 according to the present disclosure. The integrated wireless network 100 includes a switch / monitor 105. The switch / monitor 105 is coupled to a supervisor module 112, multiple legacy base transceiver stations (BTSs) 110, each coupled to the switch / monitor 105 via an ADC / DAC unit 115, multiple baseband units (BBUs) 120a-c, and a fronthaul network 145 via an Ethernet connection 150. The integrated wireless network 100 further includes multiple remote units (RUs) 155, each coupled to the switch / monitor 105 through the fronthaul network 145. Each RU 155 may be coupled to one or more antennas 160.

[0014] Each BBU 120a-c may be an LTE eNodeB or 5G gNodeB central unit (CU), or a combination of a 5G gNodeB central unit and a distributed unit (DU), and each conventional BTS 110 may be a 2G base station or a 3G base station, or an LTE base station.

[0015] The integrated radio network 100 allows the multiple RUs 155, individually, together, or in a given combination, to receive downlink signals and transmit uplink signals to and from various BBUs 120a-c and conventional BTSs 110, which may each belong to different network operators. The input / output signals 114 of each conventional BTS 110 may include analog RF signals or may otherwise be directly coupled to the radio. Each input / output signal 114 carrying an analog RF signal of each conventional BTS 110 is coupled to an ADC / DAC unit 115. For downlink signals from the conventional BTS 110, the ADC / DAC unit 115 digitizes the analog RF signal into a digital stream of I / Q (in-phase / quadrature-phase) data. The ADC / DAC unit 115 may then convert the digitized data stream according to a packetized digital signal transmission protocol (e.g., eCPRI) over a digitized BTS connection 124. In the case of eCPRI, digitized signals from a given legacy BTS 110 are packetized and transmitted over a BTS connection as an input to the switch / monitor 105. For uplink signals intended for a given legacy BTS 110, the ADC / DAC unit 115 receives packetized digital I / Q signal data (e.g., eCPRI data) from the switch / monitor 105 over BTS connection 124, de-packetizes and converts the data into a digital time-domain signal, converts the digital time-domain signal into an analog RF signal, and transmits the analog RF signal via input 114 to the appropriate legacy BTS 100. The ADC / DAC unit 115 may be a separate component within the integrated wireless network 100 or may be integrated into the switch / monitor 105. It should be understood that various modifications such as these are possible without departing from the spirit and scope of the present disclosure.

[0016] As used in this disclosure, the term "network operator" or "operator" may refer to a network operator that owns and operates licensed spectrum, or a private network that does not rely on licensed spectrum but rather uses shared spectrum that is open to the public (e.g., Citizens Broadband Radio Service (CBRS)), or an entity that uses both licensed and shared spectrum.

[0017] Additionally, the term "subset" as used in this disclosure may include one or all of the above, i.e., a subset of packets in a packet stream may refer to any number of packets in the packet stream, including all of the packets.

[0018] Also coupled to the switch / monitor 105 are BBUs 120a-c. In an embodiment of the present disclosure, each BBU 120a-c may be an eNodeB or gNodeB that exchanges digitized and packetized signals with the switch / monitor 105 via connections 125a-c. Each BBU 120a-c may independently exchange the digitized signals 125a-c in different formats. Each BBU 120a-c may belong to or be operated for a different network operator.

[0019] Each BBU 120a-c may be an LTE eNodeB that exchanges packetized 7.2x data in the frequency domain, transmitted using the eCPRI protocol as a transport mechanism, with one or more RUs 155 via the switch / monitor 105 over the respective connections 125a-c, or an LTE eNodeB that exchanges packetized time domain or frequency domain I / Q signal data in accordance with the eCPRI protocol with one or more RUs 155 via the switch / monitor 105 over the respective connections 125a-c, or an LTE eNodeB that exchanges time domain data in accordance with the CPRI protocol with the switch / monitor 105 over the respective connections 125a-c, or a 5G gNodeB that exchanges packetized 7.2x data in the frequency domain, transmitted using the eCPRI protocol as a transport mechanism, with one or more RUs 155 over the respective connections 125a-c via the switch / monitor 105. It may be either a CU+DU combination, or a 5G gNodeB CU exchanging packetized data with one or more RUs 155 equipped with DUs via connections 125a-c using GTP over Ethernet according to the F1 protocol defined by 3GPP. It goes without saying that various modifications such as these can be made without departing from the spirit and scope of the present disclosure.

[0020] Although the above describes the case where O-RAN 7.2x sharing is adopted, other PHY layer sharing rules may be adopted instead, and it goes without saying that such modifications are within the scope of this disclosure without departing from the gist of the present disclosure. The 7.2x sharing used in this disclosure is an example of a PHY layer sharing rule, and such fronthaul packet traffic may also be referred to as a shared PHY layer packet stream.

[0021] Each of the BBUs 120a-c has a feedback signal path 122a-c that relays information, such as Ethernet fronthaul traffic overload information, generated by the switch / monitor 105. The BBUs 120a-c may use this information for their respective internal schedulers, such as MAC schedulers (not shown), to adjust their use of carrier components and resource elements within the carrier components assigned to them in order to reduce their network traffic load through the switch / monitor 105. The internal schedulers within each of the BBUs 120a-c function according to known scheduling procedures that may be defined by relevant 3GPP technical specifications or based on proprietary scheduler algorithms.

[0022] The BBUs 120a-c may correspond to different network operators and may operate independently of one another. The BBUs 120a-c may be located in the same location as the integrated wireless network 100 or may be remotely located. Needless to say, various modifications such as these may be made without departing from the spirit and scope of the present disclosure.

[0023] According to the present disclosure, each of the BBUs 120a-c that exchange 7.2x signaling data with one or more corresponding RUs 155 receives synchronization timing from the same timing source as the timing source provided to that RU 155. Similarly, for packetized data exchanged between any of the BBUs 120a-c and an RU 155, both the BBU 120a-c and the RU 155 must also have a packetized synchronization stream along with the packetized data. These synchronization streams must be given higher priority than data streams so that they are not compromised by an overloaded fronthaul network 145. Therefore, the switch / monitor unit 105 can handle three types of packet streams: a Precision Timing Protocol (PTP) synchronization stream, a packetized data stream, and a management data stream.

[0024] Figure 2 provides a more detailed diagram of switch / monitor 105. As shown, switch / monitor 105 is coupled to supervisor module 112 and ADC / DAC unit 115 via BTS connection 124, and to BBUs 120a-c via respective connections 125a-c and feedback signal paths 122a-c as described above with reference to Figure 1.

[0025] 2, the switch / monitor unit 105 includes a policy enforcement module 215 coupled to the supervisor module 112, an overload control module 220 coupled to the policy enforcement module 215 and each of the BBUs 120a-c via respective feedback signal paths 122a-c, a traffic monitor 225 coupled to the overload control module 220 via a traffic feedback connection 232, and a switch 235 coupled to the traffic monitor 225 via an internal Ethernet connection 236 and to the overload control module 220 via a switch command connection 237. The switch / monitor unit 105 includes a CPRI / eCPRI converter 230 coupled to the traffic monitor 225, and a synchronization module 210 that may be coupled to the GPS receiver 205. The synchronization module 210 may use known systems and techniques, such as Precision Timing Protocol (PTP) and / or Synchronous Ethernet (SyncE) technology, to generate and provide a synchronization packet stream for the switch / monitor unit 105 to each BBU 120a-c and RU 155.

[0026] The supervisor module 112 may manage the operation of the integrated wireless network 100. The supervisor module 112 may be operated, for example, by a neutral host. The supervisor module 112 may maintain the allocation and isolation of Ethernet resources, such as Ethernet traffic throughput and latency, for each BTS 110 and BBU 120a-c according to a subscription model, allocate radio resources, such as power levels and RF channels, within each RU 155 according to a subscription model, and maintain resource isolation so that no BTS 110 or BBU 120a-c interferes with the function or operation of any other BTS 110 or BBU 120a-c and so that the operation of one BTS 110 or BBU 120a-c does not affect resources allocated to BTSs 110 or BBU 120a-c of other network operators. The supervisor module 112 may coordinate the above functions, which may be performed by itself or by the policy enforcement module 215.

[0027] The supervisor module 112 can allocate Ethernet resources between the BTS 110 and the BBUs 120a-c in several ways. One method is to statically allocate resources by bandwidth or bit-rate-based throughput. With this method, each network operator (the network operator to which each BTS 110 and BBUs 120a-c belong) pays a fee based on its corresponding throughput allocation. This can take the form of a paid guaranteed bit rate. Therefore, if a network operator requires increased Ethernet throughput or a guaranteed bit rate, it may have to pay more to neutral hosts or operators in the integrated wireless network 100. As previously mentioned, the supervisor module 112 manages the specific resource allocation and subsequently provides this information to the policy enforcement module 215. Another method for allocating Ethernet resources in the fronthaul network 145 among network operators and private networks is to have each network operator customer pay a guaranteed percentage of available Ethernet throughput, regardless of the currently available throughput. This may be an approach that may be taken when the fronthaul connection is less than ideal. In another variation, each network operator may define internal priorities within its particular spectrum, thereby prioritizing (hierarchizing) different channels or carriers corresponding to that network operator, and allowing the supervisor module 112 to selectively disable certain carriers to reduce Ethernet throughput according to the pre-agreed priorities if the network becomes severely congested. In yet another variation, the network operator may define pre-agreed priorities for its network usage based on traffic types, such as enhanced Mobile Broadband (eMBB), ultra-reliable low latency communications (uRLLC), massive machine-based communications (mMTC), etc. It should be understood that various such variations may be implemented without departing from the spirit and scope of the present disclosure.These options are discussed in more detail below.

[0028] Each component or module in the integrated wireless network 100 may include machine-readable instructions encoded in one or more non-transitory memory devices and executed by one or more processors to perform its respective described functions. As used herein, the term "module" may refer to a set of machine-readable instructions encoded in non-transitory memory that may be executed by one or more processors. The machine-readable instructions corresponding to that module, when executed by a processor, perform the described functions assigned to that module in accordance with this disclosure. Each module may be implemented as one or more execution threads that may be executed by one or more processors, for example, using container technology. As used herein, "non-transitory memory" refers to a tangible storage medium (as opposed to an electromagnetic or optical signal, for example) and is not limited by the location of the data (e.g., RAM or ROM). For example, the non-transitory medium may refer to embedded volatile memory encoded with instructions that the memory should be reloaded with the appropriate machine-readable instructions after a power cycle. Additionally, although embodiments of the present disclosure involve the use of Ethernet technology for the fronthaul network 145 and the switch / monitor 105, it will be appreciated that other protocols and standards for packet-based digital communications may be implemented without departing from the scope of the present disclosure.

[0029] The switch / monitor 105 may operate as follows with respect to the integrated wireless network 100: For downlink (DL) signals, each legacy BTS 110 transmits signals at its one or more carrier frequencies. The ADC / DAC unit 115 converts the downlink signals from each legacy BTS 100 into a packetized eCPRI format and transmits them to the switch / monitor 105. For a given representative BBU 120a-c that outputs digitized RF signals in CPRI format, the CPRI / eCPRI converter 230 converts the downlink CPRI format signal into a packetized eCPRI format. Other BBUs 120a-c that provide either 7.2x format, time-domain or frequency-domain eCPRI format, or F1 format do so by transmitting packetized Ethernet data using the appropriate format. Thus, all downlink signals input to the switch / monitor 105 are either in Ethernet format, eCPRI packetized over Ethernet format, or GTP(F1) over Ethernet format, and all are sequentially input to the traffic monitor 225. The traffic monitor 225 monitors the flow of Ethernet traffic, including upload and download signals. For download signals, the traffic monitor 225 extracts information from each download signal packet to identify the source BTS 100 or BBUs 120a-c, one or more destination RUs 155, the network operator, the carrier frequency corresponding to the packetized signal, and the traffic type (uRLLC, eMBB, mMTC, NB-IoT, etc.) using techniques described below, and also compiles statistics on the collected information. For upload signals, the traffic monitor 225 receives incoming packets from each RU 155 via the fronthaul network 145 and Ethernet connection 150, identifies the destination BTS 110 or BBU 120a-c, and routes the packets accordingly. In doing so, the traffic monitor 225 compiles statistics on the collected information, just as for download signals.After obtaining this information, the traffic monitor 225 determines the percentage of resources used by each BTS 110 and BBU 120a-c (and therefore each network operator and private network), and compares this resource usage percentage with the allocation percentage to each BTS 110 and BBU 120a-c obtained from the policy enforcement module 215. This will be explained in more detail below.

[0030] The traffic monitor 225 may also identify aggregate problems in the fronthaul network 145, such as network traffic overloads that may affect the latency of a given packet or that may result in packet loss between a given RU 155 and its corresponding BTS 110 or BBU 120a-c. As used in this disclosure, the term "congestion anomaly" refers to any event that may cause a surge in packet traffic in the fronthaul network 145, resulting in degradation of service for one or more network operators.

[0031] If the traffic monitor 225 determines that one or more BTSs 110 or BBUs 120a-c are using a disproportionately high percentage (%) of the fronthaul network (145) resources (i.e., an allocation violation is occurring), or if the traffic monitor 225 determines that the fronthaul network 145 is experiencing a traffic overload, the traffic monitor 225 may provide this information to the overload control module 220. The overload control module 220 may use this information to reduce network traffic to or from one or more BTSs 110 or BBUs 120a-c (i.e., mitigate the allocation violation). The overload control module 220 may obtain pre-agreed policy information from the policy enforcement module 215 and use it to provide this information, as will be described in more detail below with reference to FIG. 5.

[0032] The traffic monitor 225 checks whether each customer's guaranteed bit rate is met (fixed allocation) or whether its corresponding percentage of paid fronthaul bandwidth is met (dynamic allocation with less than ideal fronthaul), as explained in more detail below.

[0033] The overload control module 220 may receive fronthaul bandwidth usage per operator (or per BBU 120a-c or BTS 110), compare a given BBU / BTS fronthaul bandwidth usage with its corresponding allocation stored in the policy enforcement module 215, provide a corresponding feedback signal 122a-c to that BBU 120a-c, take unilateral action to reduce the fronthaul bandwidth used by the given BBU / BTS, or both, and calculate a revised fronthaul bandwidth allocation for each BBU / BTS based on the available fronthaul bandwidth determined by the traffic monitor 225. When providing the feedback signals 122a-c to their respective corresponding BBUs 120a-c, the overload control module 220 may transmit the feedback signals over a dedicated Ethernet or IP connection. Alternatively, the overload control module 220 may implement each feedback signal path 122a-c within vendor-specific data placeholders available for use in control plane signaling as enabled by and described in the relevant 3GPP specifications. In this case, the overload control module 220 may insert the feedback signals 122a-c into an existing 3GPP-defined data structure used for control signaling to a scheduler (e.g., MAC layer) in the protocol stack implementation of the given BBU 120a-c. It should be understood that various modifications such as these are possible without departing from the spirit of the present disclosure. In yet another modification, in addition to congestion control, the overload control module 220 may provide real-time or near-real-time usage information to the supervisor module 112 using data obtained from the traffic monitor 225, so that a given network operator can be billed accordingly for overutilization (or underutilization) of the aggregated network 100. It should be understood that various modifications such as these are possible without departing from the spirit of the present disclosure.

[0034] When taking unilateral action to reduce the fronthaul bandwidth used by a given BBU / BTS, the overload control module 220 may obtain pre-agreed fronthaul bandwidth reduction procedures from the policy enforcement module 215. With this information, the overload control module 220 may issue instructions to the switch 235 via the switch command connection 237. Even if a given BBU 120a-c has a feedback path 122a-c through which the overload control module 220 can provide feedback, the feedback may not be provided in a timely manner enough to prevent buffer / queue overflow within the switch 235. Therefore, the overflow control module 220 may need to take pre-agreed unilateral action to mitigate network traffic congestion anomalies. The manner in which the overflow control module 220 takes unilateral action is described in more detail below.

[0035] The policy enforcement module 215 maintains fronthaul bandwidth allocation information for each BBU 120a-c and BTS 110 (or as a function of the network operator if a network operator has multiple BBUs 120a-c or BTSs 110), which may include information regarding pre-negotiated procedures that the overflow control module 220 may take to reduce fronthaul bandwidth if a feedback signal path 122a-c is unavailable.

[0036] The switch 235 may be an Ethernet switch or router connecting components within the switch / monitor 105 to the fronthaul network 145. The switch 235 may perform traditional buffering and routing functions, as well as dropping or blocking packets at the direction of the overload control module 220. The traffic monitor may query transmit packet buffers or queues within the switch 235 to determine traffic congestion. In one variation, the switch 235 may have multiple buffers or queues with different priorities corresponding to traffic types, etc., to match the latency requirements of those traffic types. The switch 235 may use higher priorities for purposes based on service levels, network operator or best-effort traffic conditions for guaranteed traffic, or metadata information flagged by the sender for congestion and usage / billing monitoring purposes. Additionally, the switch 235 may provide separate buffers or queues for high-priority packet streams, such as the synchronization stream from the synchronization module 210. Needless to say, various modifications such as these can be made without departing from the spirit of the present disclosure.

[0037] 2 is an example of a method for dividing functions within the switch / monitor unit 105. It goes without saying that various modifications of the division and implementation method of functions are possible without departing from the spirit of the present disclosure. For example, the traffic monitor unit 225 may be integrated into the switch 235, or the overload control module 220 may be integrated into the policy enforcement module 215.

[0038] 3 illustrates an example of a traffic monitoring module 225 according to the present disclosure. The traffic monitoring module 225 may include a packet sniffer module 310, a congestion monitoring module 315, and an analysis engine module 320. The packet sniffer module 310 may execute instructions to intercept each data packet (UL or DL) and extract information about its packet stream type (e.g., synchronization stream, signaling data stream, etc.). For signaling data streams, the packet sniffer module 310 may extract information about a given packet's source / destination BBU 120a-c or BTS 110, source / destination RU 155, network operator, traffic type (uRLLC, eMBB, mMTC), data type (7.2x data, time domain eCPRI I / Q data, frequency domain eCPRI I / Q data, or F1 data), packet priority bits (as specified in IEEE 802.1p), and / or corresponding carrier frequency. Examples of approaches the packet sniffer module 310 may take to extract information from packets include: One approach involves providing each BBU 120a-c with metadata, such as one or more unique VLAN tags, and then having the packet sniffer module 310 monitor and store Ethernet traffic data by VLAN ID. Multiple VLAN tags for identifying service, priority, traffic type, data type, carrier frequency, device category, and other network slicing information metadata may be assigned to a given BBU 120a-c or BTS 110. Another example of a priority determination method a given BBU 120a-c may employ involves the location of the destination RU. For example, if the converged network 100 is deployed in a stadium, a given network operator may assign a higher priority to RUs 155 located near first aid stations than to RUs 155 located near restrooms. Additionally, the BBUs 120a-c may change the priority of their RUs 155 over time depending on expected usage.For example, RUs 155 in the stadium concourse or parking lot may be prioritized before and after an event, and RUs 155 in the stadium arena may be prioritized during the event. Obviously, various modifications such as these are possible without departing from the spirit of the present disclosure. For each conventional BTS 110, in the downlink, the ADC / DAC 115 may assign a unique VLAN tag to each carrier from each conventional BTS 110. This allows packets on that given carrier to be identified by the traffic monitoring module 225 (which may include, for example, the network operator, the carrier frequency, etc.).

[0039] For the uplink, in a similar manner to the downlink described above, each RU 155 may insert an appropriate VLAN tag to identify the BBU or BTS, service, priority, etc. Each VLAN tag may have a set of priority bits that can be used to single out individual services offered by a given network operator. Another approach involves assigning different VLAN tags to each BBU 120a-c or the network operator of a given BTS 110, so that the BBU 120a-c or BTS 110 can specify and indicate its own differentiated and prioritized services to the switch / monitor 105 via the traffic monitoring module 315.

[0040] The packet sniffer module 310 may also identify the synchronized packet stream from the synchronization module 210 and send information to the overload control module 220 and / or switch 235 indicating that the identified packets may be given the highest priority.

[0041] The packet sniffer module 310 may accumulate or buffer the packet metadata data it collects at predetermined intervals and provide it to the analysis engine module 320 .

[0042] The congestion monitor module 315 determines congestion conditions in the aggregate of the fronthaul network 145 and asserts the current bandwidth or throughput of the fronthaul network 145. There are various approaches the congestion monitor module 315 may take to do this. For example, the congestion monitor module 315 may include remote agent modules (not shown) in the switch 235 and in each RU 155. Each remote agent module monitors the depth of the transmit packet buffer in which it resides. Each remote agent module may provide the congestion monitor module 315 with information regarding the depth of its corresponding transmit packet buffer or queue, as well as an indication or alert if any of the transmit packet buffers or queues are overflowing. An overflowing transmit packet buffer may indicate that more packets are being sent from the fronthaul network 145 than either the switch 235 or a given RU 155 can handle at one time. Another (or additional) approach the congestion monitor module 315 may take involves measuring one-way packet delay time. The eCPRI specification prescribes such one-way packet delay measurements. In addition, the congestion monitoring module 315 may employ conventional tests supported by routers and switches, such as RFC2544, Y.1564, and RFC5357 (also known as Two-Way Active Measurement Protocol (TWAMP)). It goes without saying that various modifications such as these are possible without departing from the spirit and scope of this disclosure.

[0043] The analysis engine module 320 receives data from the congestion monitor module 315 and the packet sniffer module 310 and may calculate the total available bandwidth of the fronthaul network 145 and the actual bandwidth usage of each BBU 120 a-c and BTS 110. In the latter case, this may include calculating such actual bandwidth usage for each BBU 120 a-c and BTS 110 as a function of traffic type (uRLLC, eMBB, mMTC), carrier frequency, data type (7.2x data, frequency domain eCPRI I / Q data, time domain eCPRI I / Q data, or F1 data), packet priority bits (as specified in IEEE 802.1p), and / or LTE UE congestion. The analysis engine module 320 may calculate the available bandwidth at preset intervals (e.g., one transmit time interval (TTI)) or upon prompting from the congestion monitor 315. This is because, as will be described below, the total bandwidth available in the fronthaul network 145 can change dynamically, affecting how bandwidth is allocated among network operators (through their respective BBU / BTSs). Additionally, the analysis engine module 320 may identify the cause of traffic congestion bottlenecks in the fronthaul network 145 by executing instructions to correlate unusual spikes in data traffic with the BBU / BTS from which they may originate, as well as traffic types, data types, etc.

[0044] As used in this disclosure, the term "prioritized packet stream" may refer to a given packet stream of a given network operator (i.e., BBUs 120a-c or legacy BTS 110) that carries signaling data corresponding to a particular channel / carrier, traffic type (uRLLC, eMBB, mMTC), data type (7.2x data, frequency domain eCPRI I / Q data, time domain eCPRI I / Q data, or F1 data), packet priority bits (as specified in IEEE 802.1p), or carrier frequency. Signaling data of a given network operator may be differentiated and prioritized according to any of these classifications and may be further prioritized between network operators, with each network operator paying a price for differentiated priorities within itself and between operators.

[0045] 4 illustrates an example remote unit (RU) 155 according to the present disclosure. The RU 155 is configured to communicate with each of the BBUs 120a-c and the BTS 110 via the switch / monitor 105 using its own digital data format (7.2x, frequency domain eCPRI, time domain eCPRI, or F1). The RU 155 may include a boundary clock 465 for network synchronization with other elements of the converged network 100 coupled to the fronthaul network 145 according to the Precision Timing Protocol (PTP 470). The RU 155 can also obtain additional network timing assistance via a GPS receiver 475. The timing provided by the PTP 470 should be the same as the timing provided to the BBUs 120a-c. Given that each RU 155 is shared by BBUs 120a-c of different network operators, it is necessary for the network hosting the RUs 155 and the switch / monitor 105 to return PTP timing to the individual BBUs so that they can synchronize with the given RU 155 to which they converge.

[0046] The RU 155 comprises a front-end data processor 405 including an Ethernet switch 406, an uplink data summing module 407, and a 5G distributed unit 408 that cooperates with the BBUs 120a-c performing 5G CU functions to form a 5G gNodeB. The 5G DU 408 receives downlink F1 data packets from its corresponding CU in the BBUs 120a-c via the fronthaul network 145 and the Ethernet switch 406 and generates time-domain downlink I / Q data by performing lower PHY-level processing of the data according to the 3GPP specifications. For the uplink, the 5G DU 408 receives uplink time-domain data from the ADC 455 (via the digital splitter 440) and performs uplink lower PHY-layer processing on it to convert it to uplink frequency-domain F1 packet data for transmission to the fronthaul network 145 via the Ethernet switch 406. The 5G DU 408 may also include modules for performing lower PHY layer processing for the BBUs 120a-c (such as LTE eNodeB or 5G gNodeB CU+DU) that communicate with the RU 155 using 7.2x packetized data.

[0047] Additionally, the RU 155 includes an FIQ / TIQ converter 420 that converts frequency-domain eCPRI I / Q data into a time-domain digital I / Q signal stream for the downlink, and converts time-domain digital I / Q signal data into frequency-domain I / Q data for the uplink. Although the FIQ / TIQ converter 420 is shown as a separate module, it may be integrated into the front-end data processor 405. The RU 155 may include a digital summer 435 that sums the digital time-domain I / Q data stream 410 from the Ethernet switch 406 with the digital time-domain I / Q data stream 425 from the FIQ / TIQ converter 420. The summed digital I / Q data is then converted to an analog RF signal by a DAC 445, the output of which is provided to a power amplifier 450 for transmission via the antenna 160.

[0048] For the uplink, a low-noise amplifier 460 amplifies the RF signal received via antenna 160 and provides the amplified signal to an ADC 455. The ADC 455 converts the RF analog signal to a digital I / Q data stream that is routed by a digital splitter 440 to the front-end data processor 405 via connection 415 and to the FIQ-to-TIQ converter 420 via connection 430. If the RU 155 has multiple antennas 161, each with its own low-noise amplifier 460 and ADC 455, the uplink summer 407 aggregates the time-domain digital I / Q data into a single digital I / Q data stream, which the front-end data processor 405 then converts to packetized time-domain data using the eCPRI format. In one variation, the FIQ / TIQ converter 420 may take the summed output of the uplink summer 407 and convert the summed time domain I / Q data to frequency domain I / Q data, which may then be packetized into eCPRI format. The front-end data processor 405 may send all packetized data to the switch / monitor 105 via the fronthaul network 145 for subsequent routing to the appropriate BBUs 120a-c or ADC / DAC units 115 before being forwarded to the switch / monitor 105 for further processing and relaying to the target legacy BTS 110.

[0049] As described above, the switch / monitor 105 may allocate fronthaul bandwidth resources according to pre-agreed priorities and may take steps to enforce such allocations by performing procedures pre-agreed with a given network operator.

[0050] 5A-D are diagrams illustrating various example priority allocation solutions 500a-c according to the present disclosure, each illustrating a different exemplary priority allocation 510a-c. The priority allocation solutions 500a-c may be generated by the supervisor module 112 and maintained by the policy enforcement module 215, for example.

[0051] FIG. 5A illustrates a channel / carrier-based priority allocation solution 500a according to the present disclosure. In the channel / carrier-based priority allocation solution 500a, priorities are assigned based on a channel / carrier allocation 510a relative to the available fronthaul bandwidth. In this scenario, a neutral host or operator in the aggregated network 100 enters into an agreement with network operator A (Operator A, Operator B, Operator C, and Operator D) to pay a fee for the priorities. In this example, Operator A pays for the highest priorities of Priority 1 and Priority 2 for its two licensed bands (channels or carriers) and a lower priority of 14 for its third licensed band. In the channel / carrier-based priority allocation solution 500a, the switch / monitor 105 does not know which traffic is traveling on which carrier / channel and therefore relies on the individual network operator (in this example, Operator A) to schedule the appropriate traffic to each licensed band or channel / carrier that has already been prioritized. Continuing with this example, Operator B may pay for one of its licensed bands (or channels / carriers) to be assigned priority 3 and another licensed band to be assigned priority 8. Furthermore, Operator B may acquire a CBRS channel and arrange for it to be assigned priority 5. Operator C may be a private network operator without any licensed spectrum. In this case, Operator C may acquire two CBRS channels and pay for them to be assigned priority 4 and priority 11, respectively. Each Operator AE may operate one or more BBUs that provide 7.2x data or frequency-domain eCPRI data, time-domain eCPRI data, or F1 data (in the case of a CU / DU shared 5G gNodeB) to the Switch / Monitor 105. It is also possible that one or more Operator AEs also operate legacy BTSs 110. In this case, data from the fronthaul network 145 is in the form of time-domain eCPRI packets.

[0052] In the channel / carrier-based priority allocation solution 500a, the traffic monitor 225 measures the available bandwidth of the fronthaul network 145, identifies congestion anomalies in the fronthaul network 145 (using the congestion monitor 315), measures the fronthaul bandwidth usage of each channel / carrier according to the channel / carrier allocation 510a (using the packet sniffer module 310), and provides this information to the overload control module 220 (using the analysis engine module 320). This information allows the overload control module 220 to provide feedback to the BBUs 120a-c via feedback paths 122a-c. Such feedback may include the amount of fronthaul bandwidth each operator's channel / carrier utilizes within the channel / carrier allocation 510a, as well as bandwidth availability information. The network operator's corresponding BBUs 120a-c can use this information to instruct their schedulers to adjust their throughput on a given channel / carrier to address any overuse of fronthaul bandwidth. In the case of a legacy BTS 110 that does not have a scheduler feedback mechanism, the overload control module 220 may solely block or limit packet traffic on low priority channels / carriers in the channel / carrier allocation 510a.

[0053] 5B illustrates a fixed percentage-based priority allocation solution 500b according to the present disclosure. In the fixed percentage-based priority allocation solution 500b, each operator AE pays a given percentage 510b of the total available bandwidth of the fronthaul network 145 according to its priority. In the fixed percentage-based priority allocation solution 500b, the traffic monitor 225 measures the available bandwidth of the fronthaul network 145. The congestion monitor 315 determines the total available bandwidth of the fronthaul network 145, and the packet sniffer 310 determines the fronthaul bandwidth usage by each BBU 120a-c and BTS 110. Both of the above modules 315 / 310 provide this information to the analysis engine module 320, which then calculates the percentage of available bandwidth used by each operator AE and provides this information to the overload control module 220. Next, the overload control module 220 compares the calculated utilization percentage (%) of each operator AE with the prioritized percentage (%) 510b from the policy enforcement module 215. If any of the operators A-D is using a percentage (%) greater than the corresponding prioritized percentage (%) 510b, the overload control module 220 provides appropriate feedback to the appropriate BBUs 120a-c via feedback paths 122a-c to notify the MAC scheduler to reduce fronthaul traffic.

[0054] FIG. 5c illustrates a traffic-type-based priority allocation 500c according to the present disclosure. For traffic-type-based priority allocation 500c, each operator AE pays for a specific priority for its own fronthaul usage based on whether a given packet traffic is related to enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (uRLLC), massive machine-type communications (mMTC), or whether it is a time-domain or frequency-domain eCPRI representation of the RF signal. Each operator AE pays for a specific priority for the bandwidth usage of the fronthaul network 145 according to traffic-type priority allocation 510c. In this traffic-type-based priority allocation 500c example, Operator A allocates the highest priority to its uRLLC traffic, pays for eMBB traffic at priority 3, and pays for mMTC traffic at a lower priority of 6. Operator B pays for its eRLLC traffic at priority 2, eMBB traffic at priority 5, and mMTC traffic at priority 9. Operator C does not offer uRLLC communications to its customers and therefore only receives priority 7 for its eMBB traffic and priority 10 for its mMTC traffic. Operators D and E may also operate legacy BTSs 110. Thus, Operator D's and Operator E's traffic is not differentiated by traffic type. Rather, Operators D and E transmit and receive time-domain or frequency-domain representations of their respective BTS RF inputs / outputs 114. In this example, Operator D pays for priority 4 for its use of bandwidth in the fronthaul network 145, and Operator E pays for priority 8. As previously mentioned, the specific priorities 500a-c assigned in this and other examples are merely exemplary, and it should be understood that other specific allocation combinations are possible without departing from the scope of this disclosure.

[0055] In traffic type-based priority allocation 500c, the congestion monitoring module 315 measures the available bandwidth of the fronthaul network 145 to identify bottlenecks or congestion anomalies. Simultaneously, the packet sniffer module 305 identifies the traffic types used by each BBU 120a-c and BTS 110. Either of these modules 315 / 310 provides this information to the analysis engine module 320, which then executes instructions to correlate the latency impact of network congestion on uRLLC traffic to identify one or more traffic streams that are primarily responsible for the traffic congestion. In either case, the analysis engine module 315 provides the generated information to the overload control module 220. The overload control module 220 provides feedback to one or more BBUs 120a-c via the corresponding feedback paths 122a-c, informing their corresponding MAC schedulers to reduce traffic usage of the traffic types causing the congestion anomalies. The overload control module 220 does this depending on the traffic type priority allocation 510c, which may reduce or shut down one or more entries for lower priority traffic first. Note that a given BTS 110 may not have the capability to throttle its eCPRI-based RF signal's fronthaul bandwidth usage, which may be an all-or-nothing situation. Operators D and E may then compensate by paying for higher priority.

[0056] In each of these examples 500a-c, the overload control module 220 (in addition to or instead of providing feedback to the BBUs 120a-c) may proactively disrupt packet traffic in one or more of the lower priority allocations (e.g., traffic type (500c), channel / carrier (500a), source / destination BBU / BTS (500b), etc.).

[0057] FIG. 6 illustrates an example process 600 for allocating fronthaul bandwidth according to pre-agreed priorities according to the present disclosure. All of the steps in the example process 600 may be implemented as machine-readable instructions executed on one or more processors, as described above with respect to software modules. While the process descriptions use the term "processor" or "the processor," it should be understood that the term may apply to multiple processors executing on a single server or across several servers (including multiple geographically dispersed servers). The processor may execute the process 600 at a predetermined interval, such as once per transmission time interval (TTI), although other intervals may be employed without departing from the scope of the present disclosure.

[0058] In step 605, the processor executes instructions to determine a priority allocation. Depending on how and where the integrated wireless network 100 is deployed, a particular allocation solution 500a-c may be preferable. For example, if the integrated network 100 is deployed in a location with a preponderance of 5G gNodeBs and a high opportunity for uRLLC communication (such as an automated factory or an urban environment with autonomous vehicles), the traffic-type-based priority allocation 500c may be preferable. Alternatively, if the integrated wireless network 100 interacts with a disproportionate number of legacy BTSs 110, the channel / carrier-based priority allocation solution 500a may be appropriate. Having established the solutions 500a-c, the processor may execute instructions (e.g., in the supervisor 112) to obtain input from each network operator regarding the desired priority(s) and then instantiate a table of priorities 510a-c and map the priorities to each network operator. This table may be maintained in memory by the policy enforcement module 215.

[0059] In step 610, the processor executes instructions to monitor each operator's usage of the fronthaul network 145. This may be done by the traffic monitoring module 225 via the packet sniffer 310. Depending on the solution 500a-c used, the processor may extract different metadata information (such as a VLAN tag) from each examined packet as described above. The processor may then store the extracted information from each packet in a buffer or local memory.

[0060] In step 615, the processor may execute instructions to determine available bandwidth and possibly identify congestion anomalies, using one or more of the techniques described above (eCPRI One-Way Packet Delay, RFC2544, Y.1564, RFC5357, TWAMP, etc.), and may do so in coordination with the congestion monitor module 315 and the analysis engine module 320. The processor may execute instructions to buffer the determined information in local memory.

[0061] In step 620, the processor executes instructions to determine whether one or more network operators are exceeding their allocations or whether a congestion anomaly is occurring in the fronthaul network 145, which determines whether the switch / monitor unit 105 needs to intervene in the operation of the integrated wireless network 100. In determining whether the allocation has been exceeded, the processor may execute instructions to calculate the percentage of fronthaul bandwidth being used by each BBU 120a-c and the legacy BTS 110 and compare the calculated percentages to the allocation percentage 510b, which may be a bottleneck or congestion anomaly in the fronthaul, previously identified in step 615.

[0062] It should be noted that whether a network operator violates (i.e., exceeds) its allocated percentage of fronthaul bandwidth is an issue unrelated to whether a bottleneck or congestion anomaly exists in the fronthaul network. Even under nominal operating conditions, when one network operator's usage of fronthaul bandwidth exceeds its pre-agreed allocation, another network operator may have less fronthaul network bandwidth available than the latter operator is entitled to (according to its allocation).

[0063] If the result of step 620 is "no", then no intervention is required and process 600 returns to step 610 and repeats at predetermined intervals (e.g., once per TTI). If the result of step 620 is "yes", then intervention is required and process 600 proceeds to step 625.

[0064] In step 625, the processor executes instructions to identify the priority and scope of action that needs to be taken to resolve either the allocation violation or the congestion anomaly.

[0065] In the case of a congestion anomaly, in the example channel / carrier-based priority allocation solution 500a, the processor may execute instructions to determine how many of the lower priority channels / carriers in the channel / carrier allocation 510a are affected. For example, referring to FIG. 5A , assume that licensed carrier E (priority 16) and licensed carrier D (priority 15) are affected. To determine this, instructions may be executed to determine how much bandwidth usage needs to be cut off to resolve the congestion anomaly and compare it to the bandwidth usage of Operator E's priority 16 channel / carrier. If eliminating this bandwidth usage (by cutting off Operator E's priority 16 channel / carrier) does not sufficiently resolve the congestion anomaly, the processor may further determine the bandwidth usage of Operator D's priority 15 channel / carrier. (Note that this is merely an example.) In this example, eliminating the bandwidth usage of these two channels / carriers is sufficient to resolve the congestion anomaly. In the case of percentage-based priority allocation solution 500b, this answer may already have been determined in step 615. In this case, the offending network operator(s) are known. Furthermore, if the offending network operator has been identified but operates multiple BBUs 120a-c or legacy BTSs 110, the processor may execute instructions to identify which of the BBUs 120a-c or legacy BTSs 110 is using the most fronthaul bandwidth. In the case of traffic-type-based priority allocation 500c, the processor may execute instructions to identify which of the lowest priority entries in traffic type priority allocation 510c can be addressed to resolve the fronthaul congestion anomaly. This may be done in a similar manner as described above in the description of channel / carrier-based priority allocation solution 500a.

[0066] In the event of an allocation violation, the processor executes instructions to identify a low priority carrier or low priority traffic type corresponding to the offending network operator that can be blocked to resolve the allocation violation, i.e., to restore the network operator's fronthaul bandwidth utilization percentage (%) to its allocation percentage (%) 500b.

[0067] In step 630, the processor executes instructions to determine a course of action necessary to resolve the fronthaul bottleneck or congestion anomaly or percentage violation. If the affected channel / carrier or low-priority traffic type identified in step 625 corresponds to a BBU 120a-c, the processor may execute instructions to provide feedback to the appropriate BBU 120a-c via feedback path 122a-c to notify the BBU's MAC scheduler. Similarly, if a network operator has one or more BBUs 120a-c that are violating their allocated percentage, the processor may execute instructions to provide similar notification to the affected BBUs 120a-c. In such cases, the overload control module 220 may reduce fronthaul bandwidth usage by taking appropriate action via their respective MAC schedulers, depending on the affected individual fronthaul-aware BBUs 120a-c, as needed. However, if the channel / carrier identified as affected in step 625 corresponds to a conventional BTS 110, or if the network operator violating the allocated percentage operates only one or more conventional BTSs 110, the processor may execute instructions to reduce the fronthaul bandwidth usage by that BTS through pre-arranged unilateral action.

[0068] In step 635, the processor may execute instructions to reduce packet traffic for the BBUs 120a-c or BTS 110 as specified in step 630. If one or more BBUs 120a-c are identified in step 630 as requiring intervention, the processor may execute instructions to provide feedback to the appropriate BBUs 120a-c, as described above. Additionally, if desired, the processor may execute instructions to proactively reduce fronthaul bandwidth usage, pursuant to arrangements with affected network operators and as specified by the policy enforcement module 215. The processor may then execute instructions to cause the overload control module 220 to issue instructions to the switch 235 to block or block all packets having a VLAN tag corresponding to the channel / carrier, traffic type, or BBU / BTS identified in step 625, depending on how priorities are assigned (i.e., 500a / 500b / 500c). In one variation or addition, the packet sniffer module 310 may identify and tag packets associated with low priority traffic types and throttle them at the switch 235. In one variation, the integrated wireless network 100 may include a feedback path (not shown) between the switch / monitor 105 and the ADC / DAC 115, which may enable the overload control module 220 to instruct the ADC / DAC 115 to stop converting a predetermined low priority carrier signal of the appropriate legacy BTS 110. It should be understood that various variations such as these are possible without departing from the spirit and scope of the present disclosure.

[0069] 7 illustrates an example process 700 for allocating fronthaul bandwidth using a fixed percentage-based priority allocation solution 500b. All of the steps in the example process 700 may be implemented as machine-readable instructions executed on one or more processors, as described above with respect to software modules.

[0070] In step 705, the processor executes instructions to determine the priority allocation. This step is simpler than other priority allocation solutions because each network operator pays a predetermined percentage of fronthaul bandwidth. After completing this step, the processor may execute instructions to store the percentage allocation 510b in the policy enforcement module 215.

[0071] In step 710, the processor executes instructions to determine the currently available bandwidth of the fronthaul network 145. This may be performed in a manner similar to step 615 above.

[0072] In step 715, the processor executes instructions to determine whether the available fronthaul bandwidth has increased or decreased since the processor last determined it. If this is the first iteration of process 700, the policy enforcement module 215 may have an initial default reference fronthaul bandwidth stored in its memory. In this case, the first iteration of step 715 may involve comparing the fronthaul bandwidth calculated in step 710 with the initial default reference value. In either case, the fronthaul bandwidth may increase or decrease, or may not change at all.

[0073] If the fronthaul bandwidth has increased, process 700 proceeds to step 720, where the processor executes instructions to increase the reference fronthaul bandwidth, thereby increasing the bandwidth allocation to each operator AE based on its respective allocation percentage (%) 510. If the overload control module 220 is currently proactively reducing fronthaul bandwidth usage by an operator AE as described in step 635 of process 600, the processor instructs the overload control module 220 to reduce or stop fronthaul usage by the operator AE.

[0074] If step 715 determines that the fronthaul bandwidth has decreased, process 700 proceeds to step 725, where the processor executes instructions to determine new bandwidth allocations for each operator A-E in response to the decrease in the reference fronthaul bandwidth, and updates these values ​​stored in policy enforcement module 215.

[0075] In step 730, the processor executes instructions for monitoring the usage of the fronthaul bandwidth available by each operator AE by monitoring specific usage by each BBU 120a-c and the Legacy BTS 110. This may be done in a manner similar to that described above with respect to step 610 of process 600.

[0076] In step 735, the processor executes instructions to determine whether any of the operators AE are exceeding their available new reduced fronthaul bandwidth allocation percentage (%) 510b by calculating the current utilization percentage (%) by each operator AE based on the reference fronthaul bandwidth calculated in step 710 and the usage by each operator AE determined in step 730, and comparing each to the new allocation calculated in step 725. If any of the operators A-E are using more fronthaul bandwidth than their respective allocation calculated in step 725, the process 700 proceeds to step 740.

[0077] In step 740, the processor executes instructions to determine how much fronthaul bandwidth used by one or more operators determined to be violating their respective allocations in step 735 needs to be reduced. The required bandwidth reduction may take the form of shutting down low priority channels / carriers, limiting or temporarily halting packet traffic on low priority traffic types, or a combination of these measures.

[0078] In step 745, the processor executes instructions to reduce packet traffic of the operator AE that violates its respective allocation 510b. Means for reducing bandwidth usage by the offending operator may include one or more of the above procedures. For example, if the offending operator has one or more BBUs 120a-c, the processor may execute instructions to provide feedback to its MAC scheduler via feedback paths 122a-c. Alternatively, the processor may execute instructions to cause the overload control module 220 to issue commands to the packet sniffer module 310 and the switch 235 to selectively block or delay specific packet traffic corresponding to the BBUs 120a-c and / or BTS 110 of the offending operator AE. Furthermore, if the switch has multiple parallel transmit buffers (e.g., allocated to different traffic types, channels / carriers, or network operators), the overload control module 220 may instruct the switch 235 to throttle packet transmissions by each buffer. In one variation, the overload control module 220 may instruct the ADC / DAC 115 to cease conversion of low priority carrier signals in the appropriate legacy BTS 110 as described above for step 635 .

Claims

1. 1. A method for allocating fronthaul bandwidth resources among multiple network operators in a wireless network, comprising: assigning a priority hierarchy including allocations and priorities of fronthaul bandwidth resources to a plurality of network operators; establishing packet-based communications between a plurality of baseband processors, each corresponding to a respective one of the plurality of network operators, and a plurality of remote units; routing a plurality of packet streams between each of the plurality of baseband processors and the plurality of remote units using the fronthaul bandwidth resources; monitoring fronthaul traffic associated with the fronthaul bandwidth resource for at least one of an allocation violation and a congestion exception; suppressing at least one of the allocation violation and the congestion anomaly based on detecting the at least one of the allocation violation and the congestion anomaly; A method comprising:

2. 10. The method of claim 1, wherein one or more of the baseband processors comprises an LTE eNodeB.

3. 3. The method of claim 2, wherein the packet streams corresponding to the one or more LTE eNodeBs individually include one of a time-domain eCPRI packet stream, a frequency-domain eCPRI packet stream, and a shared PHY layer packet stream.

4. 4. The method of claim 3, wherein the shared PHY layer packet stream comprises a 7.2x packet stream.

5. 3. The method of claim 2, wherein the one or more LTE eNodeBs transmit and receive CPRI data streams via a switch / monitor, and the switch / monitor converts the CPRI data streams to and from a further separate time domain eCPRI packet stream.

6. 10. The method of claim 1, wherein one or more of the baseband processors comprises a 5G gNodeB.

7. 7. The method of claim 6, wherein each subset of 5G gNodeBs includes a central unit and a distributed unit, and the packet streams corresponding to the 5G gNodeBs include a shared PHY layer packet stream.

8. 8. The method of claim 7, wherein the shared PHY layer packet stream comprises a 7.2x packet stream.

9. 8. The method of claim 7, wherein each subset of 5G gNodeBs includes a central unit, one or more counterpart remote units of the plurality of remote units includes a distributed unit, and the packet stream corresponding to the 5G gNodeB includes an F1 packet stream.

10. 2. The method of claim 1, wherein said routing comprises providing a synchronous packet stream to said plurality of baseband devices and said plurality of remote units.

11. 10. The method of claim 1, wherein the monitoring includes identifying metadata within a subset of packets within the plurality of packet streams.

12. 12. The method of claim 11, wherein the metadata includes a VLAN tag.

13. 12. The method of claim 11, wherein the metadata indicates one of a time domain eCPRI packet stream, a frequency domain eCPRI packet stream, a 7.2x packet stream, and an F1 packet stream.

14. 12. The method of claim 11, wherein the metadata is inserted by a transmitting baseband device.

15. 12. The method of claim 11, wherein the metadata is inserted by a sending remote unit.

16. 12. The method of claim 11, wherein the metadata indicates one of a network operator and a baseband processor.

17. 17. The method of claim 16, wherein the metadata indicates one of a channel and a carrier frequency.

18. 18. The method of claim 17, wherein the channel comprises a CBRS channel.

19. 18. The method of claim 17, wherein assigning a priority hierarchy to the plurality of network operators comprises assigning a priority to each of the channels and carriers corresponding to each network operator.

20. The monitoring Identifying congestion anomalies; and identifying one or more low priority resources required to suppress the congestion exception; 18. The method of claim 17, comprising:

21. 21. The method of claim 20, wherein identifying congestion anomalies includes measuring packet delay.

22. 22. The method of claim 21, wherein the packet delay measurement includes one of RFC2544, Y.1564, and RFC5357.

23. The suppression identifying one or more target baseband devices corresponding to the one or more low priority resources; transmitting a feedback signal to the one or more target baseband devices; 21. The method of claim 20, comprising:

24. 21. The method of claim 20, wherein the throttling includes disrupting the flow of packets corresponding to the other, lower priority resource.

25. 17. The method of claim 16, wherein assigning a priority hierarchy to the plurality of network operators comprises allocating a prioritized fixed fronthaul bandwidth percentage to each network operator.

26. The monitoring determining available fronthaul bandwidth; determining the percentage of available fronthaul bandwidth used by each network operator; comparing the percentage of available fronthaul bandwidth used by each network operator with the corresponding network operator's fixed prioritized fronthaul bandwidth percentage; 26. The method of claim 25, comprising:

27. The suppression Identifying allocation violations, including when a fronthaul bandwidth utilization percentage exceeds a corresponding prioritized fixed fronthaul bandwidth percentage; identifying a baseband processor corresponding to the allocation violation; sending a feedback signal to the baseband processor corresponding to the allocation violation; 27. The method of claim 26, comprising:

28. The monitoring Identifying congestion anomalies; and identifying one or more low priority resources required to suppress the congestion exception; 2. The method of claim 1, comprising:

29. The inhibition is identifying one or more target baseband devices corresponding to the low priority resources; transmitting a feedback signal to the one or more target baseband devices; 29. The method of claim 28, comprising:

30. 30. The method of claim 29, wherein the throttling includes disrupting the flow of packets corresponding to the other, lower priority resource.

31. 10. The method of claim 1, wherein said establishing packet-based communications includes coupling a switch / monitor unit to a conventional base station transceiver unit through an ADC / DAC unit.

32. 32. The method of claim 31, wherein the routing includes converting an RF signal from a legacy base station transceiver unit into a time-domain eCPRI packet stream by an ADC / DAC unit.

33. 1. A method for allocating fronthaul bandwidth resources among multiple network operators in a wireless network, comprising: assigning a priority hierarchy to a plurality of network operators, the priority hierarchy including one or more traffic types and priorities corresponding to each of the plurality of network operators; allocating the fronthaul bandwidth resources among the plurality of network operators based on the priority hierarchy; establishing packet-based communications between a plurality of baseband processors each corresponding to a respective one of the plurality of network operators and a plurality of remote units; routing a plurality of packet streams between each of the plurality of baseband processors and the plurality of remote units using the fronthaul bandwidth resources; monitoring the packet stream for congestion anomalies; suppressing the congestion exception based on the detection of the congestion exception; A method comprising:

34. 34. The method of claim 33, wherein the monitoring includes identifying metadata corresponding to each packet stream.

35. 35. The method of claim 34, wherein the metadata includes a VLAN tag.

36. 35. The method of claim 34, further comprising accumulating a plurality of statistics corresponding to the metadata.

37. 34. The method of claim 33, wherein the traffic type comprises one of enhanced mobile broadband (eMBB), ultra-reliable low latency communications (uRLLC), and massive machine-based communications (mMTC).

Images