Fronthaul interface for use in a cloud radio access network

Abstract

To implement a fronthaul network of a cloud radio access network (C-RAN).SOLUTION: The C-RAN includes a plurality of remote units (RUs) and a central unit (CU) communicatively coupled to the RUs via a fronthaul network. The CU also transmits, over the fronthaul network, the set of data to the respective subset of remote units by, for each of the set of data, multicasting the set of data to a multicast group that best matches the respective subset of remote units mapped to the set of data if at least one of the multicast groups includes the respective subset of remote units mapped to the set of data.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 870,025 (Attorney Docket No. 100.1874USPR), entitled "FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK," filed July 2, 2019, U.S. Provisional Patent Application No. 62 / 895,625 (Attorney Docket No. 100.1874USP2), entitled "FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK," filed September 4, 2019, and U.S. Provisional Patent Application No. 62 / 895,625 (Attorney Docket No. 100.1874USP2), entitled "FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK," filed January 2, 2020, all of which are incorporated herein by reference in their entireties. NETWORK,” U.S. Provisional Patent Application No. 62 / 956,402 (Attorney Docket No. 100.1884USPR).

[0002] This application is also related to the following co-pending US patent applications, which are incorporated herein by reference:

[0003] U.S. Patent Application No. ______________ (Attorney Docket No. 100.1874US01), filed on even date herewith, entitled "FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK," which is incorporated herein by reference; and No. ______________ (Attorney Docket No. 100.1884US01), filed on even date herewith, entitled "DEEP PACKET INSPECTION IN A FRONTHAUL NETWORK OF A CLOUD RADIO ACCESS NETWORK," which is incorporated herein by reference. [Background technology]

[0004] In a Cloud Radio Access Network (C-RAN), geographically separated remote units are controlled by a centralized unit and provide radio services to user equipment (UE). In a C-RAN, the centralized unit may communicate with the remote units via a fronthaul network (also referred to as a "fronthaul interface"). It may be desirable to implement a C-RAN fronthaul network with certain functionality described herein. Summary of the Invention

[0005] One embodiment is directed to a Cloud Radio Access Network (C-RAN). The C-RAN includes a plurality of remote units (RUs), each configured to exchange radio frequency (RF) signals with at least one user equipment (UE). The C-RAN also includes a central unit communicatively coupled to the plurality of RUs via a fronthaul interface. The central unit is configured to determine sets of data to be transmitted to the plurality of remote units over the fronthaul interface. The central unit is also configured to determine a mapping of each of the sets of data to at least one of the plurality of remote units. The central unit is also configured to add a respective indicator to each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective set of data is intended. The central unit is also configured to broadcast a set of data, each having a respective indicator, to a plurality of remote units.

[0006] Another embodiment is directed to a Cloud Radio Access Network (C-RAN) including a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE). The C-RAN further includes a central unit communicatively coupled to the plurality of remote units via a fronthaul network. The fronthaul network is configured to implement a plurality of multicast groups, each including a respective group of the remote units. The central unit is configured to: determine a set of data to be transmitted over the fronthaul network to a respective subset of the remote units; determine a mapping of each of the sets of data to a respective one of the subsets of remote units; and, for each set of data, transmit the set of data over the fronthaul network to a respective subset of the remote units by multicasting the set of data to a multicast group that best matches the respective subset of the remote units mapped to the set of data if at least one of the multicast groups completely includes the respective subset of the remote units mapped to the set of data.

[0007] Another embodiment is directed to a Cloud Radio Access Network (C-RAN) including a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE). The C-RAN further includes a central unit communicatively coupled to the plurality of remote units via a fronthaul network and an entity configured to perform deep packet inspection, the entity communicatively coupled to the central unit via the fronthaul network. The central unit is configured to: determine sets of data to be transmitted to the plurality of remote units over the fronthaul network; determine a mapping of each of the sets of data to at least one of the plurality of remote units; add a respective indicator to a packet for each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective packet and set of data are intended; and transmit, via the fronthaul network, the packets for the set of data, each with the respective indicator, to the entity. The entity is configured to determine each remote unit for which the packet is intended and to perform deep packet inspection on each packet to communicate the packet via the fronthaul network to each remote unit for which the packet is intended.

[0008] Another embodiment is directed to a Cloud Radio Access Network (C-RAN) including a plurality of Remote Units (RUs), each configured to exchange radio frequency (RF) signals with at least one UE. The C-RAN also includes a central unit communicatively coupled to the plurality of RUs via a fronthaul interface. The fronthaul interface includes at least one ETHERNET switch configured to perform deep packet inspection on received packets to determine whether an RU identification is present in the packet. If present in the packet, the RU identification indicates at least one RU for which the packet is intended. When the RU identification is present in the packet, the at least one ETHERNET switch also configures, for each of the at least one RU, to communicate at least a portion of the packet to the RU based on a comparison of the RU identification with at least one bit pattern of the RU. It is composed of: [Brief explanation of the drawings]

[0009] Example configurations will be described with additional specificity and detail through the use of the accompanying drawings, with the understanding that the drawings depict example configurations only and therefore are not to be considered limiting in scope.

[0010] [Figure 1A] FIG. 1 is a block diagram illustrating an example configuration of a communication system including 3GPP® Fourth Generation (4G) components. [Figure 1B] FIG. 1 is a block diagram illustrating an example configuration of a communication system including 3GPP fifth generation (5G) components. [Figure 2] FIG. 1 is a block diagram illustrating an example functional division between an RU and a baseband controller (4G) or a distributed unit (DU) (5G). [Figure 3] FIG. 2 is a block diagram illustrating an example O-RAN 1.0 fronthaul interface between a DU and multiple RUs. [Figure 4]FIG. 1 is a block diagram illustrating an example fronthaul interface between a DU and multiple (M)RUs according to the O-RAN shared cell proposal. [Figure 5] FIG. 2 is a block diagram illustrating an example mapping of different data to different sets of RUs in a C-RAN. [Figure 6A] FIG. 10 is a block diagram illustrating an example downlink broadcast configuration for a fronthaul interface between a DU and multiple (M)RUs. [Figure 6B] FIG. 2 is a block diagram illustrating an example uplink configuration for a fronthaul interface between a DU and multiple (M)RUs. [Figure 7] FIG. 1 is a flow diagram illustrating a method for transmitting data over a fronthaul interface of a C-RAN. [Figure 8] FIG. 1 is a flow diagram illustrating a method for transmitting data over a fronthaul interface of a C-RAN. [Figure 9A] 1 illustrates an example C-RAN with a DPI entity (performing deep packet inspection) in a switched network implementing a fronthaul network. [Figure 9B] 1 illustrates another exemplary C-RAN with a DPI entity (performing deep packet inspection) in a switched network implementing a fronthaul network. [Figure 10] FIG. 1 is a flow diagram illustrating a method for transmitting data over a fronthaul interface of a C-RAN. [Figure 11] FIG. 1 is a flow diagram illustrating a method for transmitting data over a fronthaul interface of a C-RAN. [Figure 12] FIG. 2 is a block diagram illustrating an example of a protocol stack suitable for communicating I / Q data between each controller and associated radio units over a fronthaul network. [Figure 13A]1A and 1B are block diagrams illustrating an example of an ETHERNET packet, an Internet Protocol (IP) packet, a SwIQ-DAP protocol data unit (PDU), TLV elements, and fields in a SwIQ-DAP header. [Figure 13B] 1 is a block diagram illustrating another example of an ETHERNET packet, a SwIQ-DAP protocol data unit (PDU), TLV elements, and fields in a SwIQ-DAP header. [Figure 14A] FIG. 1 is a block diagram illustrating an example configuration for deep packet inspection in a fronthaul network of a Cloud Radio Access Network (C-RAN) system. [Figure 14B] FIG. 10 is a block diagram illustrating additional details regarding an embodiment of implementing a fronthaul network for C-RAN using a switched ETHERNET network. [Figure 15] FIG. 1 is a block diagram of a wireless system with multiple RUs and UEs. [Figure 16] FIG. 1 is a flow diagram illustrating a method for transmitting data across a fronthaul interface and a fronthaul network of a C-RAN using deep packet inspection (DPI). [Figure 17] FIG. 1 is a flow diagram illustrating a method for performing deep packet inspection (DPI) on a packet. [Figure 18] 1 is a flow diagram illustrating a method for establishing multicast rules in an ETHERNET switch.

[0011] In accordance with common practice, the various illustrated features are not drawn to scale, but are drawn to highlight particular features relevant to the exemplary configurations. DETAILED DESCRIPTION OF THE INVENTION

[0012] A Cloud Radio Access Network (C-RAN) is one way of implementing a distributed RAN. Typically, for each cell implemented by a C-RAN, one or more controllers (also referred to as "baseband controllers," "central units," or "distributed units") interact with multiple remote units (RUs) to provide wireless services to various items of user equipment (UE). In a C-RAN, the RUs may communicate with at least one controller via a fronthaul interface. The fronthaul interface may utilize at least one computing device (e.g., a switch) that facilitates communication between the RUs and the DU (5G) or baseband controller (4G). For example, the fronthaul interface may be implemented using at least one ETHERNET switch and / or router. Furthermore, the fronthaul interface may be implemented using different physical links, such as copper, multirate, or multimode cable.

[0013] Frequency reuse involves using the same frequency resource(s) for multiple sets of UEs, with each set of UEs under a different, geographically diverse set of RUs. This may include the same RU frequency resource being used to transmit to different UEs. On the downlink, multiple reuse layers of at least one RU can each transmit simultaneously on the same frequency to different UEs (where each RU in a reuse layer is sufficiently RF isolated from each RU in the other reuse layer(s). On the uplink, multiple UEs can each transmit simultaneously on the same frequency to different reuse layers of at least one RU (where each RU in a reuse layer is sufficiently RF isolated from each RU in the other reuse layer(s).

[0014] One possibility is to send all downlink traffic from the controller in the C-RAN to all RUs via multicast. For a given sector implemented by the C-RAN, there are one or more IP addresses to which downlink in-phase, quadrature (I / Q) packets are sent, and all RUs are registered to the same set of multicast IP addresses. Thus, when reuse is performed, all reuse layer packets reach all RUs. Thus, if there is 4x reuse in the DL, 4x times as many packets reach each RU, even if a given RU receives 1x or fewer packets of interest. However, it may be desirable to send different sets of data to different RUs (for transmission to UEs) in the C-RAN. There are several possible solutions to achieve this customized transmission of downlink traffic.

[0015] In the first possible solution, the source (e.g., a controller in a C-RAN) ,The packets can be duplicated and sent only to the ,target RUs by unicast., This places a processing load on the ,controller.

[0016] In a second possible solution, a controller in the C-RAN can add an indicator (e.g., a bit mask) to the data it broadcasts, which indicates the remote unit(s) the data is intended for.

[0017] In a third possible solution, each subset of RUs forming a transmission group can also form an independent multicast group, and the source then transmits data to the multicast group with only the required RUs.

[0018] In a fourth possible solution, the fronthaul network / interface (e.g., in a switch) only forwards traffic of interest to RUs in a given port. Inspection / analysis of packet traffic (e.g., in a fronthaul network / interface) is referred to herein as deep packet inspection (DPI). For example, a switch in the fronthaul network / interface may selectively forward packets to different RUs based on the presence and / or bits set in a bitmask within the packet.

[0019] The Fronthaul Working Group of the Open Radio Network Alliance (O-RAN) Alliance is seeking to standardize how data is transmitted over radio access network fronthaul interfaces. In some configurations, the fronthaul interface described herein may conform to the O-RAN 1.0 interface as found in the O-RAN-WG4.CUS.0-v01.00 Control, User and Synchronization Plane Specification, Version 1.00 (available at https: / / www.o-ran.org / specifications), which is incorporated herein by reference.

[0020] Example 4G C-RAN 1A is a block diagram illustrating an example configuration of a communication system 100A including 3GPP fourth generation (4G) components. In the example configuration shown in FIG. 1, the system 100A is implemented using a Cloud Radio Access Network (C-RAN) (point-to-multipoint distributed base station) architecture with at least one baseband unit 104 and one or more remote units (RUs) 106A-M providing at least one cell.

[0021] The RUs 106 may be deployed at sites 102 to provide wireless coverage and capacity for one or more wireless network operators. A site 102 may be, for example, a building or campus or other grouping of buildings (e.g., used by one or more businesses, governments, or other business entities), or some other public venue (such as a hotel, resort, amusement park, hospital, shopping center, airport, university campus, arena, or outdoor area such as a ski area, stadium, or densely populated downtown area). In some configurations, the site 102 is at least partially (and optionally completely) indoors, although other alternatives are possible.

[0022] The system 100A may also be referred to herein as a "C-RAN" or a "C-RAN system." The baseband unit 104 may also be referred to herein as a "baseband controller" 104, a "CU" 104, or simply a "controller" 104. Each RU 106 emits downlink RF signals to user equipment (UE) 110, 10. The baseband controller 104 may optionally be physically located remotely from the site 102, for example, in a centralized bank of baseband controllers 104. Furthermore, the RUs 106 may be physically separated from each other within the site 102, while each is communicatively coupled to the baseband controller 104 via the fronthaul network 116.

[0023] Each UE 110 may be a computing device having at least one processor that executes instructions stored in a memory, such as a mobile phone, a tablet computer, a mobile media device, a mobile gaming device, a laptop computer, a vehicle-based computer, a desktop computer, etc. Each baseband controller 104 and RU 106 may be a computing device having at least one processor that executes instructions stored in a memory. Additionally, each RU 106 may implement one or more instances (e.g., modules) of a radio unit 106.

[0024] The C-RAN 100A may optionally implement frequency reuse, in which the same frequency resource(s) are used for multiple sets of UEs 110, each set of UEs 110 under a different geographically diverse set of RUs 106.

[0025] The system 100A is coupled to each wireless network operator's core network 112 via an appropriate backhaul network 114. For example, the Internet may be used for backhaul between the system 100A and each core network 112. However, it is understood that the backhaul network 114 may be implemented in other ways. Each of the backhaul network 114 and / or fronthaul network 116 described herein may be implemented with one or more switches, routers, and / or other networking devices; for example, the backhaul network 114 and / or the fronthaul network 116 may be implemented with a switched ETHERNET network.

[0026] The system 100A may be implemented as a Long Term Evolution (LTE) radio access network that provides wireless services using an LTE air interface. LTE is a standard developed by the 3GPP standards organization. In this configuration, the baseband controller 104 and the RU 106 are used together to implement an LTE Convolutional Node B (also referred to herein as an “eNodeB” or “eNB”). The eNB may be used to provide the UE 110 with mobile access to a wireless network operator's core network 112 and enable the UE 110 to communicate data and voice wirelessly (e.g., using voice over LTE (VoLTE) technology). However, it should be noted that the present systems and methods may be used with other wireless protocols; for example, the system 100A may be implemented as a 3GPP 5G RAN that provides wireless services using a 5G air interface.

[0027] Also, in an exemplary LTE configuration, each core network 112 may be implemented as an Evolved Packet Core (EPC) 112 including standard LTE EPC network elements such as, for example, a Mobility Management Entity (MME) and a Serving Gateway (SGW), and optionally, a Home eNB Gateway (HeNB GW) (not shown) and a Security Gateway (SeGW or SecGW) (not shown).

[0028] Additionally, in the exemplary LTE configuration, each baseband controller 104 communicates with the MME and SGW in the EPC core network 112 using an LTE S1 interface. The baseband controller 104 may communicate with an outdoor macro eNB (not shown) over an LTE X2 interface.

[0029] Each baseband controller 104 and remote unit 106 may be implemented to use an air interface that supports one or more of frequency division duplexing (FDD) and / or time division duplexing (TDD). The baseband controller 104 and remote unit 106 may also be implemented to use an air interface that supports one or more of multiple input-multiple output (MIMO), single input-single output (SISO), single input-multiple output (SIMO), and / or beamforming schemes. For example, the baseband controller 104 and remote unit 106 may implement one or more LTE transmission modes. Furthermore, the baseband controller 104 and remote unit 106 may be configured to support multiple air interfaces and / or support multiple wireless operators.

[0030] In some configurations, in-phase, quadrature (I / Q) data representing pre-processed baseband symbols of the air interface is communicated between the baseband controller 104 and the RU 106. To communicate such baseband I / Q data, a relatively high data rate fronthaul is typically required.

[0031] In some configurations, the baseband signals may be pre-processed at the source RU 106 and converted to frequency-domain signals (such as after removing guard band / cyclic prefix data) to effectively manage the fronthaul rate before being sent to the baseband controller 104. The RU 106 can further reduce the data rate by quantizing these frequency-domain signals to reduce the number of bits used to carry such signals and transmit the data. In a further simplification, specific symbol / channel data may be processed entirely at the source RU 106 itself, with only the resulting information being passed to the baseband controller 104.

[0032] The Third Generation Partnership Project (3GPP) has adopted a layered model for the LTE radio access interface. Generally, some combination of baseband controller 104 and RU 106 performs analog radio frequency (RF) functions for the air interface and digital Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3) (of the 3GPP-defined LTE radio access interface protocol) functions for the air interface. Any suitable division of L1-L3 processing (between baseband controller 104 and RU 106) may be implemented. When baseband signal I / Q data is fronthauled between baseband controller 104 and RU 106, each baseband controller 104 may be configured to perform all or a portion of the digital L1, L2, and L3 processing for the air interface. In this case, the L1 function of each RU 106 is configured to implement all or a portion of the digital L1 processing for the air interface.

[0033] If the fronthaul ETHERNET network 116 cannot deliver the data rate required for the fronthaul (uncompressed) I / Q data, the I / Q data may be compressed before being communicated over the ETHERNET network 116, thereby reducing the data rate required to communicate such I / Q data over the ETHERNET network 116.

[0034] The data may be transmitted over a network (e.g., as specified in the Common Public Radio Interface (CPRI) and / or Open Base Station Architecture Initiative (OBSAI) family of specifications). The baseband controller 104 may be fronthauled in other ways between the baseband controller 104 and the RU 106 (using different fronthaul interfaces and techniques). Thus, the baseband controller 104 described herein may be similar to and / or implement at least some of the functionality of an O-RAN distributed unit (O-DU).

[0035] Furthermore, it should be noted that the present system and method may also be used in other distributed RANs (in addition to C-RAN 100A), such as distributed antenna systems (DAS).

[0036] FIG. 9A shows an example C-RAN 100A having a DPI entity 109 (performing deep packet inspection) in a switched network 120 implementing a fronthaul network 116. A management system 107 may be communicatively coupled to the baseband controller 104 and the RUs 106, for example, via the backhaul network 114 and / or the fronthaul network 116. A hierarchical architecture may be used for management plane (“M-plane”) communications. When using a hierarchical architecture, the management system 107 can send and receive management communications to and from the baseband controller 104, which forwards associated M-plane communications to and from the RUs 106 as needed. A direct architecture may also be used for M-plane communications. When using a direct architecture, the management system 107 can communicate directly with the RUs 106 (without the M-plane communications being forwarded by the controller 104). A hybrid architecture may also be used, where some M-plane communications are communicated using the hierarchical architecture and some M-plane communications are communicated using the direct architecture. Proprietary protocols and interfaces may be used for such M-plane communications. Additionally, protocols and interfaces specified by standards such as O-RAN may be used for such M-plane communications.

[0037] Example 5G C-RAN 1B is a block diagram illustrating an example configuration of a system 100B including 3GPP fifth generation (5G) components. Optionally, system 100B may additionally include 4G components. Each of the components may be implemented using at least one processor-executed instructions stored in at least one memory. In some configurations, at least some of the components are implemented using a virtual machine.

[0038] Fifth-generation (5G) standards support a wide variety of applications, bandwidths, and latencies, while supporting a variety of implementation options. In system 100, interfaces designated "-c" or simply "c" (shown with dashed lines) provide control plane connectivity, while interfaces designated "-u" or simply "u" (shown with solid lines) provide user plane connectivity. A more detailed description of the various devices and interfaces in FIG. 1B can be found in 3GPP TR 38.801 Radio Access Architecture and Interfaces, Release 14 (available at https: / / portal.3gpp.org / desktopmodules / Specifications / SpecificationDetails.aspx?specificationId=3056), which is incorporated herein by reference.

[0039] FIG. 1B shows a C-RAN 100B implementing an embodiment of a 5G next-generation Node B (gNB). The architecture of the next-generation Node B (gNB) is divided into a 5G Central Unit (CU) 103, one or more 5G Distributed Units (DUs) 105A-B, and one or more 5G Remote Units (RUs) 106N-O. The 5G Central Unit (CU) 103 is responsible for user data transfer, mobility control, radio access network sharing, positioning, session management, and other functions. The 5G CU 103 is a node that includes gNB controller functions such as 5G QoS management. The 5G CU 103 controls the operation of the distributed units (DUs) 105A-B on the interfaces (including F1-c and F1-u for the control plane and user plane, respectively).

[0040] The distributed unit (DU) 105 may be a node that implements a subset of gNB functions depending on the functional division (between the CU 103 and the DU 105). In some configurations, L3 processing (of the 5G air interface) may be implemented in the CU 103, and L2 processing (of the 5G air interface) may be implemented in the DU 105. The operation of each DU 105 is controlled by the CU 103. The functionality of the DU 105 may include radio link control (RLC), part of medium access control (MAC), and / or part of physical (PHY) layer functions. The distributed unit (DU) 105 can optionally offload part of the PHY (L1) processing (of the 5G air interface) to the RU 106.

[0041] 1B, a C-RAN 100B implementing an exemplary next-generation Node B (gNB) includes a single CU 103 that handles control plane functions and user plane functions. The 5G CU 103 (within the C-RAN 100B) may communicate with at least one wireless service provider's next-generation core (NGC) 112 using 5G NGc and 5G NGu interfaces. In some 5G configurations (not shown), the 5G CU is split between a CU-C 103B that handles control plane functions and a CU-U 103C that handles user plane functions.

[0042] In some 5G configurations, the RUs (RUs) 106N-O may communicate baseband signal data over an NG-iq interface to the DU 105. In some 5G configurations, the RUs 106 may implement at least a portion of the L1 and / or L2 processing. In some configurations, the RUs 106 may have multiple ETHERNET ports and can communicate with multiple switches.

[0043] Any of the interfaces in Figure 1B may be implemented using a switched ETHERNET (or fiber) network. Furthermore, if multiple CUs 103 (not shown) are present, they may communicate with each other using any suitable interface, e.g., Xn (Xn-c and Xn-u) and / or X2 interfaces. The fronthaul interface may facilitate any of the NG-iq, F1-c, and / or F1-u interfaces in Figure 1B.

[0044] 9B shows an example C-RAN 100B having a DPI entity 109 (performing deep packet inspection) in a switched network 120 implementing a fronthaul network 116. The management system 107 may be communicatively coupled to the CU 103, the DU 105, and the RU 106, for example, via the backhaul network 114 and / or the fronthaul network 116. A hierarchical architecture may be used for M-plane communications. When using a hierarchical architecture, the management system 107 can send and receive management communications to and from the CU 103, which then forwards associated M-plane communications to and from the DU 105, as needed, and then forwards associated communications to and from the RU 106. A direct architecture may also be used for M-plane communications. When a direct architecture is used, the management system 107 can communicate directly with the CU 103, the DU 105, and the RU 106 (without having M-plane communications forwarded to and from the DU 105 by the CU 103, and without having M-plane communications forwarded to and from the RU 106 by the DU 103). A hybrid architecture may also be used, where some M-plane communications are communicated using a hierarchical architecture and some M-plane communications are communicated using a direct architecture. Proprietary protocols and interfaces may be used for such M-plane communications. Additionally, protocols and interfaces specified by standards such as O-RAN may be used for such M-plane communications.

[0045] Functional division between RU and DU 2 is a block diagram illustrating an example functional division between the RU 106 and the baseband controller 104 (4G) or distributed unit (DU) 105 (5G). Some combination of the DU 105 (or baseband controller 104 for 5G) and the RU 106 performs analog radio frequency (RF) functions for the air interface, as well as digital layer 1 (L1), layer 2 (L2), and layer 3 (L3) functions for the air interface (of the 3GPP-defined LTE radio access interface protocol).

[0046] Various options for functional division are shown in Figure 2, where the function to the left of the vertical arrow of a given option is implemented in the DU 105 in 5G (or the baseband controller 104 in 4G), and the function to the right of the vertical arrow is implemented in the RU 106. In a 5G configuration, the function to the left of the vertical arrow of a given option may be implemented in some combination of the DU(s) 105 and the CU 103. The top half of Figure 2 shows the division between the first RU 106 and the DU 105 (or the baseband controller 104), and the bottom half of Figure 2 shows the division between the second RU 106 and the DU 105 (or the baseband controller 104).

[0047] In option 1, the radio resource control (RRC) 204A-B portion of the L3 processing is performed in the DU 105 (or baseband controller 104), and the packet data convergence protocol (PDCP) 206A-B portion of the L3 processing (in addition to all analog RF 220A-B, L1, and L2 processing) is performed in the RU 106. In option 2, the RLC 204 and PDCP 206 portions of L3 are performed in the DU 105 (or baseband controller 104), while all analog RF, L1, and L2 functions are performed in the RU 106. In option 3, L3 (RRC 204 and PDCP 206 portions) and the high radio link control (RLC) portion 208A of the L2 processing are performed in the DU 105 (or baseband controller 104), while the remaining L2 processing (low RLC 210A-B, high MAC 212A-B, low MAC 214A-B) in addition to L1 and analog RF 220 processing is performed in the RU 106. In option 4, L3 (RRC 204 and PDCP 206 portions), the high RLC 208 portion of the L2 processing, and the low RLC 210 portion are performed in the DU 105 (or baseband controller 104), while the remaining high MAC 212 and low MAC 214A-B portions of the L2 processing in addition to L1 and analog RF 220 processing are performed in the RU 106.

[0048] In option 5, L3 (the RRC 204 and PDCP 206 portions), the high RLC 208 portion of the L2 processing, the low RLC 210 portion, and the high MAC 212 portion are performed in the DU 105 (or baseband controller 104), while the remaining low MAC 214A-B portion of the L2 processing, in addition to L1 and analog RF 220 processing, is performed in the RU 106. In option 6, all L3 (the RRC 204 and PDCP 206 portions) and L2 processing (the high RLC 208 portion, the low RLC 210 portion, the high MAC 212 portion, and the low MAC 214 portion) are performed in the DU 105 (or baseband controller 104), while the L1 processing (the high physical layer (PHY) 216A-B and low PHY 218A-B portions) and analog RF 220 processing are performed in the RU 106. In some configurations, Option 6 splitting may produce very low data rates and high delay margins between the RU(s) 106 and the baseband controller 104.

[0049] In option 7, all L3 processing, L2 processing, and the high PHY 216 portion of L1 processing is performed in the DU 105 (or baseband controller 104), while the L1 The lower PHY 218A-B portion of the processing (and analog RF 220 processing) is performed in the RU 106.

[0050] In option 8, all L3, L2, and L1 (high PHY 216 and low PHY 218 portions) are implemented in the DU 105 (or baseband controller 104), while analog RF 220 processing is implemented in the RU 106.

[0051] The term "high" with respect to RLC, MAC, and PHY refers to the upper sublayer of the layer in question. The term "low" with respect to RLC, MAC, and PHY refers to the lower sublayer of the layer in question.

[0052] O-RAN Interface 3 is a block diagram illustrating an example O-RAN 1.0 fronthaul interface between a DU 105 and multiple (M)RUs 106. The DU 105 may be communicatively coupled to the RUs 106 via a switched network 120. Although not shown, the DU 105 may also be communicatively coupled to a 5G CU 103 (in 5G). Furthermore, in a 4G configuration, the DU 105 may instead be a baseband controller 104.

[0053] The 3rd Generation Partnership Project (3GPP) specifies the functional division between the DU 105 and the RU 106 (what processing occurs in the RU 106 and what processing occurs in the DU 105). For example, a "7.2x" protocol division indicates that part of the physical layer (L1) processing is performed in the RU 106 and part in the DU 105. In other words, the 7.2x division is a division of Option 7, which is in the middle of the physical layer. In some configurations, there may be minor variations in which processing is performed in the DU 105 or the RU 106, depending on the channel being processed.

[0054] However, 3GPP has not standardized how data is conveyed between the DU 105 and the RU 106. The Open Radio Access Network (O-RAN) Alliance is standardizing the actual interface between the DU 105 and the RU 106, i.e., how data is packetized and transmitted. The O-RAN 1.0 standard (using 7.2x splitting) technically supports one-DU to multiple-RU mapping, but each configured DU-RU link is addressed and managed independently. Therefore, the O-RAN 1.0 configuration of Figure 3 effectively implements multiple point-to-point links, with the DU 105 transmitting M copies of the same packet stream. This results in inefficient use of bandwidth across the fronthaul interface (between the DU 105 and the RU). Specifically, if M RUs 106 each transmit N PRBs, the uplink bandwidth from the switched network 120 to the DU 105 would be approximately N PRBs × M RUs × α. Alpha (α) represents a fraction (less than 1) that accounts for the fact that traffic may be less than the full multiple shown, e.g., less than the maximum number of N PRBs due to pruning, i.e., some PRBs not transmitted from the RU 106 to the DU 105.

[0055] 3, the downlink bandwidth from the DU 105 to the switched network 120 would be approximately N PRBs by M RUs 106. The uplink or downlink bandwidth between the switched network 120 and each RU 106 is approximately N PRBs. Thus, the example O-RAN fronthaul interface of FIG. 3 is an inefficient use of bandwidth on the link between the DU 105 and the switched network 120.

[0056] Data transfer is scheduled and managed on a symbol-by-symbol basis in O-RAN 1.0, where , the entire PDSCH resource element (RE) grid is delivered sequentially.

[0057] 4 is a block diagram illustrating an example fronthaul interface between a DU 105 and multiple (M)RUs according to the O-RAN shared cell proposal. The DU may be communicatively coupled to the RU 106 via a fronthaul manager (FHM) 122. Although not shown, the DU 105 may also be communicatively coupled to an ng-eNB CU (not shown) or a gNB CU 103 (in 5G). Furthermore, in a 4G configuration, the DU 105 may instead be a baseband controller 104.

[0058] The O-RAN shared cell proposal attempts to more efficiently use bandwidth with the DUs 105 (compared to O-RAN 1.0). Specifically, the shared cell proposal includes a fronthaul manager (FHM) 122 to more efficiently support one-DU to multiple-RU mapping. To do this, the fronthaul manager 122 (1) replicates the downlink packet stream (from the DUs 105) for each RU 106 and (2) uses combining / digital summation on the uplink packet stream from the RUs 106 (before transmitting to the DUs 105). The combining / digital summation includes (1) adding in-phase (I) samples corresponding to corresponding PRBs (from all RUs 106), (2) adding quadrature (Q) samples corresponding to corresponding PRBs (from all RUs 106), and (3) transmitting the combined stream of I / Q data from the fronthaul manager 122 to the DUs 105. The combining / digital summation may optionally include some overflow management. Using the shared cell proposal, the DU 105 can transmit and receive a single packet stream (with a bandwidth of approximately N PRBs) instead of M packet streams (one for each RU 106 with a total bandwidth of approximately N PRBs x M RUs). By reducing the DU 105 transmitted and received data to a single stream of N PRBs, the shared cell proposal of FIG. 4 would reduce the bandwidth (between the DU 105 and the FHM) compared to the O-RAN 1.0 implementation of FIG. 3.

[0059] However, both the O-RAN 1.0 implementation (in FIG. 3) and the shared cell proposal (in FIG. 4) assume that all downlink transmissions from all RUs 106 are identical, as in a distributed antenna system (DAS). In other words, neither the O-RAN 1.0 implementation (in FIG. 3) nor the shared cell proposal (in FIG. 4) distinguish between different traffic destined for different RUs 106, which would be problematic in the C-RAN 100, as discussed below.

[0060] The need for C-RAN fronthaul interfaces Figure 5 is a block diagram illustrating an example mapping of different data to different sets of RUs 106A-H in a C-RAN 100. Specifically, Figure 5 illustrates the mapping of different PRB groups and reuse layers to different RUs 106. Although Figure 5 illustrates a C-RAN 100 having eight different RUs 106, the C-RAN 100 may have more than eight RUs 106.

[0061] It may be desirable to transmit different data to different RUs 106 in the C-RAN 100 for any of the following reasons: (1) when the entire set of PRBs (e.g., 100) is divided and grouped into two different PRB groups (e.g., PRB groups 1 and 2 in FIG. 5) to which RUs 106 are assigned; (2) frequency reuse requires that samples transmitted (in the same time and frequency resources) from different sets of RUs 106 (on the downlink) or to different sets of RUs 106 (on the uplink) be kept separate; and / or (3) different channels require different types of processing (e.g., narrowcast, unicast, broadcast).

[0062] Regarding reason 1, all PRB groupings are created by a scheduler (DU 105 or CU in 5G, or L2 processing of the baseband controller 104 in 4G) to serve a set of UEs 110. The UE 110 is assigned a certain number of PRB groups based on its demand and taking into account fairness and other factors. Sets of RUs 106 are assigned to different such PRB groups based on knowledge of the UE 110's proximity to the RUs 106. This knowledge can be obtained by the scheduler through uplink measurements, UE 110 feedback information, etc. When using PRB groups, a particular RU 106 is used only for packets of the PRB group to which that RU belongs. While FIG. 5 is shown with two PRB groups, more PRB groups may be utilized.

[0063] Regarding reason 2, all reuse layers are generated by a scheduler (L2 processing in the DU 105 or CU in 5G, or the baseband controller 104 in 4G) to serve a set of UEs 110 based on knowledge of the UEs' proximity to the RUs 106, e.g., from uplink measurements, UE 110 feedback information, etc. In downlink frequency reuse, multiple reuse layers of at least one RU 106 can transmit simultaneously on the same frequency to different UEs 110 (where each RU 106 in a reuse layer is sufficiently RF isolated from each RU 106 in the other reuse layer(s)). On the uplink, multiple UEs 110 can each transmit simultaneously on a different reuse layer of at least one RU 106 (where each RU 106 in a reuse layer is sufficiently RF isolated from each RU 106 in the other reuse layer(s)). Although FIG. 5 is shown with a reuse factor of two (two different sets of RUs 106 communicating with two different UEs 110 on the same time and frequency resources) for simplicity, higher reuse factors may be utilized.

[0064] As an example, illustrating PRB groups and reuse layers, the data may be mapped as follows: (1) RU1 106A-RU3 106C are assigned to PRB group 1 / reuse layer 1 502, (2) RU4 106D-RU8 106H are assigned to PRB group 1 / reuse layer 2 504, (3) RU1 106A-RU5 106E are assigned to PRB group 2 / reuse layer 1 506, and (4) RU6 106F-RU8 106H are assigned to PRB group 2 / reuse layer 2 508.

[0065] For reason 3, the following transmission types may be used: (1) narrowcasting different data sets to different RUs 106 for some channels and reference signals (e.g., physical downlink shared channel (PDSCH), physical downlink control channel (PDCCH), demodulation reference signal (DMRS), and phase tracking reference signal (PTRS)); (2) broadcasting common channels and reference signals (e.g., physical broadcast channel (PBCH) and PDCCH (for 4G and optionally 5G)) to all RUs 106; and (3) broadcasting some channels or reference signals (e.g., channel state information reference signal (CSI-RS) group 1 510 or CSI-RS group 2 511). 512). Unlike the shared cell model, it may be desirable to transmit different sets of data to different sets of RUs 106 served by the same DU 105 based on the processed channel or signal. For example, RU1 106A is assigned to CSI-RS group 1 510, and RU2 106B and RU3 106C are assigned to CSI-RS group 2 512.

[0066] Using the example O-RAN 1.0 implementation (Figure 3), transmitting different data to different RUs 106 simply involves duplicating the I / Q data to all RUs 106 in the group. Therefore, it is inefficient. Furthermore, the use of the shared cell proposal (in FIG. 4) requires the use of a new entity (FHM) that is not outside the rack. Therefore, the present system and method can be used to modify the O-RAN 1.0 interface to selectively transmit different data (c-plane and / or u-plane) to or from different subsets of RUs 106.

[0067] Fronthaul interface for use with C-RAN 6A is a block diagram illustrating an example downlink broadcast configuration for a fronthaul interface between a DU 105 and multiple (M)RUs 106. In particular, FIG. 6A illustrates a downlink “broadcast” configuration, as the DU 105 broadcasts all data to all RUs 106, with each RU 106 filtering the data to determine which data is intended for it (RUs 106 typically do not broadcast over the air all data they receive). In FIG. 6A, the DU 105 may be communicatively coupled to the RUs 106 via a switched network 120. Although not shown, the DU 105 may also be communicatively coupled to an ng-eNB CU (not shown) or a gNB CU 103 (in 5G). Furthermore, in a 4G configuration, the DU 105 may instead be the baseband controller 104.

[0068] As mentioned above, it may be desirable in the C-RAN 100 to be able to transmit different sets of data to different RUs 106. Accordingly, additional data may be added to the control plane (C-plane) and user plane (U-plane) data (sent from the DU 105 to the RU 106) indicating which RU(s) 106 the C-plane and / or U-plane data is intended for.

[0069] In some configurations, the additional data may be a bit mask, e.g., RUid bit masks 602A-Z. Each RUid bit mask 602 may be a set of bits (e.g., each having a value of “1” or “0”), the length of which is at least equal to the number of RUs 106 communicatively coupled to (e.g., served by) a DU 105 in a single sector. The length of the RUid bit mask 602 may be configured during initial configuration of the C-RAN 100 and / or may be reconfigured after initial configuration. During initial configuration (or reconfiguration), an association is made between each bit of the RUid bit mask 602 and a specific RU 106, i.e., each bit position maps to a specific RU 106. In some embodiments, the RUid bit mask 602 may be reduced to a length of zero, e.g., corresponding to O-RAN 1.0, so that the RUid bit mask 602 is backward compatible. That is, a DU 105 that supports the enhanced fronthaul interface mode described herein, in which the additional data (i.e., the RU id bitmask) can be used to transmit different sets of data to different RUs 106, can also be configured to operate in the backward-compatible O-RAN 1.0 fronthaul interface mode by reducing the length of the RU id bitmask to zero. Furthermore, it will be appreciated that the additional data may take any form suitable for indicating for which RU(s) 106 a set of C-plane or U-plane data is intended.

[0070] Each RU 106 serving a given sector may be assigned a unique identifier (RUid). For example, each RU 106 serving a given sector may be assigned an RUid that is an integer between 0 and the number of RUs serving that sector ("nRU") minus 1 (between 0 and nRUs-1). Also, each RU 106 serving a given sector is assigned a specific bit position in the RUid bit mask 602. This bit position in the RUid bit mask 602 is also referred to herein as the "RU index." If an RUid is assigned to each RU 106, the RU index may be determined from the RUid. For example, If each serving RU 106 is assigned an RUid that is an integer between 0 and nRUs−1, the bit positions of the RUid bit mask 602 may be numbered (indexed) from 0 to nRUs−1. The RU index assigned to each RU 106 serving a sector may be the bit position number (index) corresponding to the RUid assigned to that RU 106. That is, the RU index is equal to the RUid assigned to that RU 106. For example, if an RU 106 is assigned an RUid of 6, the RU index assigned to that RU 106 is 6. However, it should be understood that the RU index need not be determined from the RUid assigned to each RU 106. It should also be understood that the use of RUids is optional (i.e., in some embodiments, a respective RU index is assigned to each RU 106 serving a sector, but each RU 106 is not assigned a separate RUid).

[0071] The management system 107 can use O-RAN M-plane communications to configure (or reconfigure) the C-RAN to use the enhanced fronthaul interface mode for a given sector (including the assignment of RUids (if used) and RU indexes). The management system 107 can determine the RUid assignments (if used) and RU index assignments and then communicate these assignments to the associated CUs 103, DUs 105, and RUs 106, in addition to other information specifying how the enhanced fronthaul interface mode should be configured. The management system 107 can also use O-RAN M-plane communications to synchronize when the CUs 103, DUs 105, and RUs 106 should begin operating in the enhanced fronthaul interface mode using the new configuration. For example, the management system 107 can use O-RAN M-plane communications to specify a specific point in time to begin operating in the enhanced fronthaul interface mode using the new configuration.

[0072] In some configurations, the DU 105 transmits C-plane data in at least one grouping of packets referred to as a C-section 604A-P, and the DU 105 transmits U-plane data in at least one grouping of packets referred to as a U-section 606A-P. In these configurations, the RUid bit mask 602 may be included within each C-section 604 and U-section 606. Alternatively, additional data (e.g., the RUid bit mask 602) may be associated with (e.g., appended to) the C-plane data and U-plane data in some other manner. Each C-section 604 and U-section 606 may include control and I / Q data, respectively.

[0073] In a simple embodiment, for each RU 106 served by the DU 105, there is one bit per RUid bitmask 602, with each bit position corresponding to a specific RU 106. When any particular bit in the RUid bitmask 602 is set (e.g., to “1”), it specifies that the grouping of packets transmitted in the associated section is intended for reception by the specific RU 106 corresponding to the set bit. Multiple bits (each corresponding to a different RU 106), or all bits, may be set in the RUid bitmask 602. All packets are broadcast from the DU 105 to all RUs 106 (e.g., via ETHERNET), and each RU 106 can identify whether a grouping of packets is intended for it without decoding all sections (by determining whether the bit in the RUid bitmask 602 corresponding to its respective RU 106 is set). In other words, each RU 106 filters packets not addressed to it based on the RUid bitmask 602 sent to (or otherwise associated with) the associated section / packet(s). Furthermore, data intended for all (or many) of the RUs 106 may still be streamed from, e.g., the DU 105. It is transmitted only once over the initial access link to the switched network 120 .

[0074] The example downlink broadcast configuration of FIG. 6A allows the DU 105 to broadcast a single stream to all RUs 106 (e.g., over ETHERNET), but allows different data to be customized to different RUs 106 because each RU 106 can filter the received data to determine whether it needs to decode a section. This has an additional advantage over the shared cell proposal (in FIG. 4) because it does not require the FHM 122 for duplication on the downlink or combining / digital summation on the uplink. For example, the switched network 120 may be implemented using off-the-shelf devices, such as switch(es), router(s), and / or other networking equipment(s). In the downlink broadcast configuration, the bandwidth utilized from the DU 105 to the switched network 120 can be approximately N PRBs × α, and the bandwidth utilized from the switched network 120 to each RU 106 can be approximately N PRBs × α.

[0075] Two possible modifications can be made to the example downlink broadcast configuration: In the first modification, multicast functionality provided by switches (or other networking equipment) in the switched network 120 (e.g., ETHERNET or IP multicast functionality) is used to transport fronthaul data.

[0076] For example, such multicast modifications may be used for downlink fronthaul data. Various multicast groups may be defined, each containing a different subset of RUs 106 serving a given sector. Each RU 106 may (and typically will) be included in multiple multicast groups. Associated switches (or other networking equipment) in the switched network 120 are configured to implement the defined multicast groups.

[0077] When downlink fronthaul data (e.g., C-plane or U-plane data) needs to be transmitted from the associated central unit (i.e., the controller 104 or the DU 105) to a particular subset of RUs 106, the central unit checks whether there is a multicast group that "matches" this subset. In one implementation, a multicast group "matches" a subset of RUs 106 if the multicast group includes all of the RUs 106 in that particular subset of RUs 106 (even if the multicast group includes other "extra" RUs 106 that are not in the subset of RUs 106 to which downlink fronthaul data is transmitted via the fronthaul). If there are multiple matching multicast groups, the matching multicast group that "best matches" the subset of RUs 106 is determined. To best match the subset of RUs 106, the matching multicast group with the smallest total number of RUs 106 can be considered. If there are multiple matching multicast groups with the smallest number of RUs 106, one of the multiple matching multicast groups may be selected (e.g., selected randomly or using some other process).

[0078] If there is a matching multicast group, the associated central unit (i.e., controller 104 or DU 105) multicasts the downlink fronthaul data to the multicast group that best matches the subset of RUs 106 to which the data is to be communicated. When multicast transmission is used, the associated central unit is designated as a switched Only a single version of the downlink fronthaul data is transmitted over the boundary ETHERNET link used to couple to the switched network 120. Switches in the switched network 120 (as part of standard ETHERNET or IP multicast) distribute the downlink fronthaul data as needed and send it to all of the RUs 106 included in the multicast group. RUs 106 that are not members of the multicast group will not receive the downlink fronthaul data transmitted to that multicast group. As a result, RUs 106 that are not members of the multicast group will not receive the downlink fronthaul data that is not intended for them, preserving bandwidth on the boundary ETHERNET link terminating at that RU 106.

[0079] When multicast is used in this manner, an RUid bitmask may be included in the multicast fronthaul data (although in some other embodiments, the RUid bitmask is not included in the multicast fronthaul data). Because the number of multicast groups that can be used in the switched network 120 is typically limited, there may be cases where there is no suitable "matching" multicast group. In this case, the relevant central unit (i.e., the controller 104 or DU 105) may use broadcast transmission of downlink fronthaul data as described above, and the RUs 106 may use the RUid bitmask and RU index to determine whether to process the received downlink fronthaul data. It may also be the case that the "matching" multicast group includes some "extra" RUs 106 that are not targeted by the fronthaul data. In this case, the central unit may use multicast transmission to transmit the downlink fronthaul data to the matching multicast group. As a result, the downlink fronthaul data will be received by these extra RUs 106 that are not targeted by the fronthaul data. Although some extra RUs 106 may receive fronthaul data not intended for them when the fronthaul data is multicast over the fronthaul network, multicast still results in fewer RUs 106 receiving the fronthaul data not intended for them (and still fewer ETHERNET links serving the affected RUs 106) than if the fronthaul data were broadcast over the fronthaul network. RUs 106 in the multicast group can use the RUid bitmask and RU index to determine whether to process the received downlink fronthaul data.Extra RUs 106 in the matching multicast group not targeted by the fronthaul data will not process the received downlink fronthaul data based on determining that their RU index does not match the RUid bitmask included in the received downlink fronthaul data.

[0080] An initial set of multicast groups may be defined for the switched network 120, each multicast group including a different subset of the RUs 106, and each RU 106 may (and typically will) be included in multiple multicast groups. Periodically, the set of multicast groups used by the switched network 120 may then be added (if the switched network 120 can accommodate additional multicast groups) or changed to reflect the actual fronthaul traffic flows and / or actual locations of the UEs and RUs 106 serving them. In this regard, the set of multicast groups used by the switched network 120 may be changed by removing the least frequently used multicast groups and replacing them with multicast groups that are more likely to be used based on the recent fronthaul traffic flows used to serve them and / or the recent locations of the UEs and RUs 106. The locations of the UEs and RUs 106 used for serving may be determined in various ways, for example, using Sounding Reference Signal (SRS), Physical Uplink Control Channel (PUCCH), Physical Uplink Shared Channel (PUSCH), and Physical Random Access Channel (PRACH) measurements in the uplink of each RU 106, preferred beam information determined by the UE, and Channel State Reference Signal (CSI-RS) measurement reports received from the UE. The definition of multicast groups and configuration of switches can be done by an entity implementing a scheduler for the air interface (e.g., the controller 104 or the DU 105), by the management system 107, or by a combination of entities implementing the scheduler and management system 107, as well as by other entities (independently or in combination with any of the aforementioned entities). O-RAN M-plane communication can be used for any relevant communication (e.g., any needed communication to inform the management system 107, associated central units, and RUs 106 of the updated set of multicast groups, configure switches in the switched network 120 to implement the updated set of multicast groups, and indicate to the management system 107, associated central units, and RUs 106 when to start using the updated set of multicast groups). Any of the M-plane communication architectures described above (hierarchical, direct, or hybrid) can be used for such M-plane communication.

[0081] In a second modification, one or more entities 109 (one of which is shown in FIGS. 9A and 9B ) within or coupled to the switched network 120 used to implement the fronthaul network 116 are configured to perform deep packet inspection (DPI). Each such entity 109 is also generally referred to as a “DPI entity” 109. In such a DPI configuration, each DPI entity 109 may (1) analyze the C-plane data (e.g., C-section 604) and U-plane data (e.g., U-section 606) for all remote units 106 using the RUid bitmask 602, and (2) selectively transmit to each RU 106 only the data intended for it. In other words, the associated central unit (i.e., the baseband controller 104 in the embodiment shown in FIG. 9A or the DU 105 in the embodiment shown in FIG. 9B) still transmits C-plane data (e.g., C-section 604) and U-plane data (e.g., U-section 606) for all RUs 106 to the switched network 120, but each DPI entity 109 performs filtering (using a bit mask) and forwards each section only to the RUs 106 indicated in the section's bit mask. Each section is not forwarded to any RUs 106 not indicated in that section's bit mask (i.e., each section is not forwarded to any RUs 106 not targeted by the section), thereby conserving bandwidth on the boundary ETHERNET links terminating at those RUs 106. The DPI approach typically involves much less management overhead than is typically required with the multicast group approach (e.g., the DPI approach does not require the definition of multicast groups and the configuration of switches to use the defined multicast groups, initially and periodically thereafter).

[0082] Each DPI entity 109 may be implemented by embedding DPI functionality as part of an ETHERNET switch. Additionally, as noted above, the DPI may be implemented in one or more other entities (in addition to, or instead of, one or more switches). Such one or more other entities may include the Fronthaul Manager (FHM) 122 described above in connection with the O-RAN shared cell proposal. Also, while only a single DPI entity 109 is shown in Figures 9A and 9B for ease of illustration, it should be understood that multiple DPI entities 109 may be used. For example, a switched network 120 typically includes multiple switches. If DPI is implemented within the switches of switched network 120, it may be preferable to implement DPI functionality in each switch of switched network 120, which may result in more efficient fronthaul bandwidth usage.

[0083] 6B is a block diagram illustrating an example uplink configuration for a fronthaul interface between the DU 105 and multiple (M)RUs 106. Similar to FIG. 6A, the DU 105 may be communicatively coupled to the RUs 106 via a switched network 120. Although not shown, the DU 105 may also be communicatively coupled to an ng-eNB CU (not shown) or a gNB CU 103 (in 5G). Furthermore, in a 4G configuration, the DU 105 may instead be a baseband controller 104.

[0084] In the C-RAN 100, the DU 105 may transmit control plane data (e.g., C-sections 604) to the RU 106. Among other things, the control plane data may indicate (to the DU 105) which PRBs to transmit on the uplink to the RU 106. Accordingly, additional data (e.g., an RUid bitmask) may be added to the control plane (C-plane) data. For example, if the DU 105 groups packets of C-plane data into C-sections 604, the DU 105 may include an RUid bitmask 602 within (or otherwise associated with) each C-section 604, as described above. However, because the uplink U-plane data (e.g., U-sections 606) is unicast from each RU 106 to the DU 105, additional data (e.g., the RUid bitmask 602) is not needed for the uplink U-plane data (U-sections 606). The bandwidth utilization may be the same as the O-RAN 1.0 implementation (with minor C-plane overhead differences), i.e., approximately N PRBs × M RUs × α from the switched network 120 to the DU 105, and approximately N PRBs from each RU 106 to the switched network 120.

[0085] In FIG. 6A, both C-plane and U-plane data are shown as being communicated over the fronthaul using the enhanced fronthaul interface mode and broadcast scheme described above. However, for a given transmission time interval (TTI), different packets may be transmitted in different manners. That is, for a given TTI, some packets may be transmitted using unicast transmission, some packets may be transmitted using broadcast transmission, and some packets, if used, may be transmitted using multicast transmission. For example, there may be instances where the same U-plane packet is communicated over the fronthaul to multiple RUs 106 (either to all of the RUs 106 using broadcast or to a subset of the RUs 106 using multicast), but separate and distinct C-plane messages (and C-plane packets) are communicated over the fronthaul to each of the RUs 106. These different C-plane messages may specify, for example, different beamforming or precoder information to be used in processing the U-plane data communicated within the common U-plane packet.

[0086] 7 is a flow diagram illustrating a method 700 for transmitting data over a fronthaul interface of the C-RAN 100. The method 700 may be performed by at least one processor of the DU 105 (in a 5G configuration) or the baseband controller 104 (in a 4G configuration). The DU 105 (or the baseband controller 104) may be communicatively coupled to multiple (M)RUs 106 via the switched network 120. The DU 105 (or the baseband controller 104) and the RUs 106 may form the C-RAN 100.

[0087] The blocks of the flow diagram shown in FIG. 7 are arranged in a generally sequential manner for ease of explanation. While shown, it should be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 700 (and the blocks illustrated in FIG. 7) may occur in a different order (e.g., if at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Also, while most standard exception handling has not been described for ease of explanation, it should be understood that method 700 is capable of, and typically would include, such exception handling.

[0088] The method 700 may begin at step 702, in which at least one processor determines sets of data to be transmitted to multiple remote units (RUs) 106 over a fronthaul interface of the C-RAN 100. Each set of data may include control plane (C-plane) data and / or user plane (U-plane) data. The C-plane data may be transmitted over at least one C-section 604, each including at least one packet of I / Q data and, optionally, an indication of at least one physical resource block (PRB) over which the I / Q data should be transmitted over the air (by the at least one RU 106). The U-plane data may be transmitted over at least one U-section 606, each including at least one packet of I / Q data and, optionally, an indication of at least one physical resource block (PRB) over which the I / Q data should be transmitted over the air (by the at least one RU 106).

[0089] The method 700 may proceed to step 704, where the at least one processor determines a mapping of each of the sets of data to at least one of the plurality of RUs 106. This mapping may be based on a PRB group, a frequency reuse layer, and / or the channel(s) with which the respective sets of data are associated.

[0090] As mentioned above, all PRB groupings are created by a scheduler (DU 105 or CU 103 in 5G, or L2 processing in the baseband controller 104 in 4G) to serve a set of UEs 110. The UE 110 is assigned a certain number of PRB groups based on its demand and taking into account fairness and other factors. Sets of RUs 106 are assigned to different such PRB groups based on knowledge of the UE 110's proximity to the RUs 106. This knowledge can be obtained by the scheduler through uplink measurements, UE 110 feedback information, etc. When using PRB groups, a particular RU 106 is used only for packets of the PRB group to which that RU belongs.

[0091] All reuse layers are generated by a scheduler (L2 processing in the DU 105 or CU in 5G, or the baseband controller 104 in 4G) to serve a set of UEs 110 based on knowledge of the UEs' proximity to the RUs 106, e.g., from uplink measurements, UE 110 feedback information, etc. On the downlink, frequency reuse utilizes multiple groups, each of which includes at least one RU 106 for transmitting simultaneously on the same frequency to different UEs 110 (where each RU 106 in a reuse layer is sufficiently RF isolated from each RU 106 in the other reuse layer(s)). On the uplink, multiple UEs 110 can each transmit simultaneously on the same frequency to a different reuse layer of at least one RU 106 (where each RU 106 in a reuse layer is sufficiently RF isolated from each RU 106 in the other reuse layer(s).

[0092] As mentioned above, the following transmission types may be used: (1) Some channels and reference signals (e.g., physical downlink shared channel (PDSCH), physical downlink control channel (PDCCH)). (1) narrowcasting different data sets to different RUs 106 for common channels and reference signals (e.g., Physical Broadcast Channel (PBCH) and PDCCH (for 4G and optionally 5G)) to all RUs 106; and (2) unicasting or narrowcasting some channels or reference signals (e.g., Channel State Information Reference Signal (CSI-RS) Group 1 or CSI-RS Group 2). Thus, different sets of data may be mapped to different sets of RUs 106 served by the same DU 105.

[0093] Method 700 may proceed to step 706, where the at least one processor adds an indicator to each set of data based on the mapping, each indicator indicating to each RU 106 that the respective set of data is intended for.

[0094] For example, each indicator may be an RUid bit mask 602 having a bit for each of multiple RUs 106, where each bit position corresponds to an RU 106. In other words, each RUid bit mask 602 may have at least as many bits as the number of RUs 106 connected to the DU 105, CU 103, or baseband controller 104. When any particular bit in the RUid bit mask 602 is set (e.g., to “1”), it specifies that a set of data (e.g., C section 604 and / or U section 606) is intended to be received by the particular RU 106 corresponding to the set bit. Multiple bits (each corresponding to a different RU 106), or all bits, may be set in the RUid bit mask 602.

[0095] Each indicator may be included in (or otherwise associated with) a respective set of data. In configurations where C sections 604 and U sections 606 are used to transmit control plane data and user plane data, respectively, the RUid bitmask 602 may be included within each C section 604 and U section 606. Alternatively, additional data (e.g., RUid bitmasks) may be associated with (e.g., appended to) the C plane data and U plane data in some other manner.

[0096] The method 700 may proceed to step 708, where the at least one processor broadcasts the sets of data, each having a respective indicator, to multiple RUs 106. For example, all packets may be broadcast from the DU 105 or baseband controller 104 to all RUs 106 via a fronthaul interface (e.g., via ETHERNET). Each RU 106 can then identify whether the packet grouping is intended for it without decoding all sections (by determining whether the bit in the RUid bitmask 602 corresponding to the respective RU 106 is set). For example, if the bit for the RU is set to “1,” the RU 106 will decode the set of data. However, if the bit for the RU is set to “0,” the RU 106 will not decode the set of data.

[0097] Method 700 may proceed to optional step 710, where at least one processor receives uplink data on PRBs specified in at least one of the sets of broadcasted data. For example, the set of data broadcast in step 708 may include commands to one or more RUs 106 instructing the RUs 106 to send back uplink signals (PRBs) on the uplink. In this case, optional step 710 includes the RUs 106 sending back the requested uplink signals.

[0098] In some configurations, multiple RUs 106 may send back information on the same PRB because either (1) the contributions of the RUs 106 are "combined," i.e., cooperative reception, or (2) the RUs 106 have RF isolation and the same PRB is assigned to different UEs 110, i.e., reuse.

[0099] 8 is a flow diagram illustrating a method 800 for transmitting data over a fronthaul interface of the C-RAN 100. The method 800 may be performed by at least one processor of the RU 106. The RU 106 may be one of multiple (M) RUs 106 communicatively coupled to the DU 105 (in a 5G configuration) or the baseband controller 104 (in a 4G configuration) via the switched network 120. The RU 106 and the DU 105 (or the baseband controller 104) may form the C-RAN 100.

[0100] 8 are arranged in a generally sequential manner for ease of explanation, it should be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 800 (and the blocks shown in FIG. 8) may occur in a different order (e.g., if at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Also, while most standard exception handling has not been described for ease of explanation, it should be understood that method 800 is capable of, and typically would include, such exception handling.

[0101] Method 800 may begin at step 802, where at least one processor receives sets of data intended for RUs 106 of the C-RAN 100. In an embodiment, at least some of the sets of data are not intended for the RUs 106 implementing method 800. Each set of data may include control plane (C-plane) data and / or user plane (U-plane) data. The C-plane data may be transmitted on at least one C-section 604, each including at least one packet of I / Q data and, optionally, an indication of at least one physical resource block (PRB) on which the I / Q data should be transmitted over the air (by the at least one RU 106). The U-plane data may be transmitted on at least one U-section 606, each including at least one packet of I / Q data and, optionally, an indication of at least one physical resource block (PRB) on which the I / Q data should be transmitted over the air (by the at least one RU 106).

[0102] Each set of data may have an associated indicator (e.g., a bit mask) that indicates the at least one RU 106 to which the respective set of data is directed. For example, each indicator may be an RUid bit mask 602 having a bit for each of a plurality of RUs 106, where each bit position corresponds to an RU 106.

[0103] Method 800 may proceed to step 804, where, for each set of data, at least one processor interprets and processes the set based on whether the respective indicator indicates whether the set is intended for the RU 106. If any particular bit of the RUid bitmask 602 is set (e.g., to "1"), it specifies that the set of data (e.g., C section 604 and / or U section 606) is intended for reception by the particular RU 106 corresponding to the set bit. For example, if the bit for the RU is set to "1," the RU 106 will decode and process the set of data. However, if the bit for the RU is set to 0, the RU 106 will not decode and process the set of data.

[0104] Method 800 may proceed to optional step 806, where the at least one processor transmits uplink data on a PRB specified in at least one of the received sets of data. For example, if the set of data received (e.g., from the DU 105) in step 802 includes a command to the RU 106 implementing method 800 (and possibly more RUs 106) instructing the RU 106 which uplink signal (PRB) to send back to the DU 105, optional step 806 includes the RU 106 sending back the requested uplink signal.

[0105] In some configurations, multiple RUs 106 may send back information on the same PRB because either (1) the contributions of the RUs 106 are "combined," i.e., cooperative reception, or (2) the RUs 106 have RF isolation and the same PRB is assigned to different UEs 110, i.e., reuse.

[0106] 10 is a flow diagram illustrating a method 1000 for transmitting data over a fronthaul interface and a fronthaul network of a C-RAN 100 using multicast transmissions and multicast groups (where possible). Except as noted below, method 1000 is identical to method 700, and the corresponding descriptions of method 700 described above also apply to method 1000 and are generally not repeated here for the sake of brevity.

[0107] Method 1000 may begin at step 702, where at least one processor determines a set of data to be transmitted to multiple remote units (RUs) 106 over a fronthaul interface of C-RAN 100. This may be done as described above in connection with FIG.

[0108] Method 1000 may proceed to step 704, where at least one processor determines a mapping of each of the sets of data to at least one of the plurality of RUs 106. That is, each of the sets of data is mapped to a subset of the RUs 106, where each such subset of RUs 106 includes one or more RUs 106. This may be done as described above in connection with FIG.

[0109] Method 1000 may proceed to optional step 706, where at least one processor adds an indicator to each set of data based on the mapping, each indicator indicating to each RU 106 that the respective set of data is intended for. This may be done as described above in connection with FIG. 7. This step 706 is optional in method 1000.

[0110] Method 1000 may proceed to step 1008, where at least one processor determines, for each set of data, whether at least one of the multicast groups matches a respective subset of remote units 106 mapped to that set of data. For each set of data for which there is at least one multicast group that matches a respective subset of remote units 106 mapped to that set of data, method 1000 may proceed to step 1010, where at least one processor transmits the set of data to a respective subset of remote units over a fronthaul network by multicasting the set of data to a multicast group that best matches a respective subset of remote units mapped to that set of data. When multicast transmission is used, downlink fronthaul data may be transmitted over a boundary ETHERNET link used to couple an associated central unit to the switched network 120. Only a single version of the data is transmitted. Switches in the switched network 120 (as part of standard ETHERNET or IP multicast) replicate the downlink fronthaul data as needed and transmit it to all of the RUs 106 included in the multicast group. RUs 106 that are not members of the multicast group will not receive the downlink fronthaul data transmitted to that multicast group. As a result, RUs 106 that are not members of the multicast group will not receive the downlink fronthaul data that is not intended for them, preserving bandwidth on the boundary ETHERNET links terminating at the RU 106.

[0111] For each set of data for which there is no multicast group matching the respective subset of remote units 106 mapped to that set of data, method 1000 may proceed to step 1012, where at least one processor broadcasts the set of data to all of the remote units 106, as described above in connection with block 708 of FIG. 7.

[0112] When performing optional step 706, each such set of data is multicast or broadcast, as the case may be, using a respective indicator. The indicator included in the set of data can be used by each RU 106 receiving the set of data to determine whether the set of data is intended for it, as described above. For example, if the set of data is multicast to a multicast group with extra RUs 106, those extra RUs 106 could use the indicator included in the set of data to determine that the set of data is not intended for them. Similarly, if the set of data is broadcast to all of the RUs 106, the indicator may be used by each of the RUs 106 to determine whether the set of data is intended for them in the manner described.

[0113] As mentioned above, in one implementation, a multicast group "matches" a subset of RUs 106 if that multicast group includes all of the RUs 106 in that particular subset of RUs 106 (even if the multicast group includes other extra RUs 106 that are not in the subset of RUs 106 to which fronthaul data is transmitted via the fronthaul). If there are multiple matching multicast groups, the multicast group that best matches the subset of RUs 106 may be determined based on the total number of RUs 106 included in each of the matching multicast groups. To best match the subset of RUs 106, the matching multicast group with the smallest total number of RUs 106 may be considered. If there are multiple matching multicast groups with the smallest number of RUs 106, one of the multiple matching multicast groups may be selected (e.g., randomly selected or using some other process).

[0114] As described above, an initial set of multicast groups for switched network 120 is defined, and switches in switched network 120 are configured to implement the initial set of multicast groups. Then, as described above, periodically, the set of multicast groups used by switched network 120 may be added (if switched network 120 can accommodate additional multicast groups) or changed to reflect the actual fronthaul traffic flows and / or actual locations of the UEs and RUs 106 serving them, and switches in switched network 120 may be configured to implement the updated set of multicast groups.

[0115] FIG. 11 shows the fronthaul interface of the C-RAN 100 using the second modification described above. 11 is a flow diagram illustrating a method 1100 for transmitting data over an interface. When using the second modification described above, deep packet inspection is used. Method 1100 may be implemented in part by at least one processor of DU 105 (in a 5G configuration) or baseband controller 104 (in a 4G configuration), and in part by an entity that performs deep packet inspection (e.g., an ETHERNET switch or another entity such as a Fronthaul Manager (FHM) described above in connection with the O-RAN shared cell proposal).

[0116] Except as noted below, method 1100 is identical to method 700, and the corresponding descriptions of method 700 described above also apply to method 1100 and are generally not repeated here for the sake of brevity.

[0117] The method 1100 may begin at step 702, where at least one processor determines a set of data to be transmitted to multiple remote units (RUs) 106 over a fronthaul interface of the C-RAN 100. This may be done as described above in connection with FIG.

[0118] Method 1100 may proceed to step 704, where at least one processor determines a mapping of each of the sets of data to at least one of the plurality of RUs 106. That is, each of the sets of data is mapped to a subset of the RUs 106, where each such subset of RUs 106 includes one or more RUs 106. This may be done as described above in connection with FIG.

[0119] Method 1100 may proceed to step 706, where the at least one processor adds an indicator to each set of data based on the mapping, each indicator indicating to each RU 106 that the respective set of data is intended. This may be done as described above in connection with FIG. 7. More specifically, in embodiments described herein in which fronthaul data is communicated over the fronthaul network in packets, an indicator is added to the packet of each set of data based on the mapping, where each such indicator indicates to each remote unit that the respective packet and set of data is intended.

[0120] Method 1100 may proceed to step 1108, where at least one processor transmits packets for the set of data, each having a respective indicator, to DPI entity 109 via the fronthaul network. Method 1100 may proceed to step 1110, where DPI entity 109 is configured to perform deep packet inspection on each of the received packets to determine each remote unit 106 for which the packet is intended, and may proceed to step 1112, where DPI entity 109 is configured to communicate each packet to each of the remote units 106 for which the packet is intended via the fronthaul network.

[0121] As a result of doing this, each packet is not forwarded to RUs 106 that are not intended for that packet, thereby preserving bandwidth on boundary ETHERNET links that terminate at those RUs 106. As noted above, method 1100 does not require the management overhead required for method 1000 (e.g., method 1100 does not require the definition of multicast groups and the configuration of switches to use the defined multicast groups initially and periodically).

[0122] FIG. 12 illustrates the network topology of each controller 104 (or 5G network) over the fronthaul network 116. 12 is a block diagram illustrating an example of a protocol stack 1200 suitable for communicating I / Q data between the controller 104 (or CU 103 or DU 105) and each associated radio unit 106. The controller 104 (or CU 103 or DU 105) and each associated radio unit 106 each implements a respective signal processing peer entity 1202 and 1204 that implements the protocol stack 1200.

[0123] 12, the top layer of the protocol stack 1200 includes an application layer protocol 1206 used to communicate I / Q data over the fronthaul 116 between the controller 104 (or CU 103 or DU 105) and each radio unit 106. As mentioned above, the I / Q data communicated over the fronthaul 116 is used in the digital signal processing performed to implement the air interface of the cell 108.

[0124] In this example, the application layer protocol 1206 is also referred to herein as the “Switched I / Q DSP Application Protocol” or “SwIQ-DAP” layer 1206. Because many different types of I / Q data may be communicated between the controller 104 (or CU 103 or DU 105) and each radio unit 106 over the fronthaul 116, the I / Q data is communicated using Type-Length-Value (TLV) elements 1300 shown in FIG.

[0125] Figure 13A is a block diagram illustrating example fields within an ETHERNET packet 534, an Internet Protocol (IP) packet 1330, a SwIQ-DAP protocol data unit (PDU) 1308, a TLV element 1300, and a SwIQ-DAP header 1310. Figures 13A and 13B do not include all fields that may be included in various packets, PDUs, headers, etc. Each TLV element 1300 includes a type field 1302 that identifies the type and format of the I / Q data included in that element 1300, a length field 1304 that identifies the length of that element 1300, and a value field 1306 that contains the data or payload of that element 1300. The type field 1302 and length field 1304 have fixed lengths, but the length of the value field 1306 can vary.

[0126] 13A, one or more TLV elements 1300 are combined together into a single SwIQ-DAP protocol data unit (PDU) 1308. Each such SwIQ-DAP PDU 1308 includes a header 1310 and a payload 1312 that includes one or more TLV elements 1300 (the number of which depends on the maximum transmission unit (MTU) size specified for the SwIQ-DAP PDU 1308). In this example, the SwIQ-DAP header 1310 includes a source identifier field 1314 that is used to identify the source of the PDU 1308. In one embodiment, where there is only one controller 104 (or CU 103 or DU 105) serving each cell 108, the source identifier field 1314 is used only for uplink data to identify which RU 106 sent the SwIQ-DAP PDU 1308 to one controller 104 (or CU 103 or DU 105) (since multiple RUs 106 can send such PDUs 1308 to a controller 104 (or CU 103 or DU 105)), but remains undefined for downlink SwIQ-DAP PDUs 1308 sent from a controller 104 (since there is only one controller 104 (or CU 103 or DU 105) serving a cell 108). In another embodiment where multiple controllers 104 (or DUs 105 or CUs 103) serve each cell 108, the source identifier field 1314 may be used to identify which RU 106 sent each uplink SwIQ-DAP PDU 1308 to the controller 104, and which controller 104 (or CU 103 or D RU 105) transmitted each downlink SwIQ-DAP PDU 1308 to one or more RUs 106. In some embodiments, the SwIQ-DAP header 1310 does not have a fixed size.

[0127] In this embodiment, the SwIQ-DAP header 1310 also includes a version number field 1316 that identifies a version number for the SwIQ-DAP, a number of TLVs field 1318 that specifies the number of TLV elements 1300 included in the PDU 1308, a sequence number 1320 that specifies the transmission sequence number of the PDU 1308, a length field 1322 that specifies the length of the PDU 1308, and a timestamp field 1324 that contains a timestamp specifying when the PDU 1308 was transmitted. In this embodiment, the SwIQ-DAP header 1310 also includes an application layer multicast address field 1326 that can be used to specify a multicast group for the wireless unit 106 at the application layer level. This can be done as described above in connection with FIG. 3 , where each bit position in the application layer multicast address field 1326 is associated with a respective wireless unit 106, and is set if the associated downlink I / Q data is intended for that wireless unit 106, and is clear if the associated downlink I / Q data is not intended for that wireless unit 106. Note that elements 1314-1326 are optional, as an actual implementation of SwIQ-DAP header 1310 may include less than (or not include) all of them.

[0128] In some configurations, the SwIQ-DAP header 1310 may include an RUid bitmask 602. For example, the RUid bitmask 602 may indicate the RUs 106 required to decode and / or transmit the payload 1312 associated with the SwIQ-DAP header 1310. During deep packet inspection, the DPI entity 109 may compare (e.g., bitwise AND) the RUid bitmask 602 to one or more bit patterns to determine whether to forward at least a portion of the ETHERNET packet 1334 to the destination RU(s) 106.

[0129] Optionally, the RUid bitmask 602 is required to be within the first X (e.g., 64, 128, etc.) bytes of the UDP payload 1328, in which case at least a portion of the SwIQ-DAP header 1310 will be located in the first X bytes of the UDP payload. This constraint is optionally implemented based on at least one processor of an ETHERNET switch (in the fronthaul network 116) performing deep packet inspection. For example, if the at least one processor can analyze the UDP payload 1328 64 bytes deep and still meet the latency requirements of the system, then the RUid bitmask 602 should be within the first 64 bytes of the UDP payload 1328. However, if the at least one processor in the DPI entity 109 can analyze the UDP payload 1328 128 bytes deep and still meet the latency requirements of the system, then the RUid bitmask 602 may only be required to remain within the first 128 bytes of the UDP payload 1328. In other words, the exact requirements placed on the positioning of the RUid bitmask 602 in the UDP payload 1328 may be based on the limitations of at least one processor performing deep packet inspection. Alternatively, or additionally, the RUid bitmask 602 may need to be within the first X (e.g., 64, 128, etc.) bytes of the ETHERNET payload 1338, in which case at least a portion of the SwIQ-DAP header 1310 would be located in the first X bytes of the ETHERNET payload 1338. Thus, despite it being indicated at the end of the SwIQ-DAP header 1310, the RUid bitmask 602 may be positioned differently within the SwIQ-DAP header 1310.

[0130] 12, the next layers in the protocol stack 1200 include an optional User Datagram Protocol (UDP) layer 1208 and an optional Internet Protocol (IP) layer 1210, through which UDP datagrams encapsulated in IP packets (or "UDP packets") may be communicated between the controller 104 (or CU 103 or DU 105) and the radio unit 106. In FIG. 13A, each SwIQ-DAP PDU 1308 is shown as being transmitted as a UDP datagram encapsulated in the payload 1340 of a multicast IP packet 1330. Each IP packet 1330 is also shown as including an IP header 1332 and a UDP header 1333, although the IP header 1332 and / or UDP header 1333 may not be included in some configurations.

[0131] The IP header 1332 may include a source IP address 1348, a destination IP address 1350, and / or an IP type 1352 field that indicates the type and format of the IP payload 1340 (e.g., UDP, Transmission Control Protocol (TCP), etc.). In some configurations, the IP header 1332 may additionally or alternatively include a multicast IP address. In some configurations, the DPI entity 109 may analyze the IP header 1332 during deep packet inspection to determine whether the IP payload 1340 includes a UDP datagram.

[0132] The UDP header 1333 may include a source port 1354 and / or a destination port 1356. In some embodiments, each port may be a 16-bit field. Some UDP port numbers may be reserved for specific standard functions, while other UDP port numbers may be customized for application-specific purposes. In some configurations, the DPI entity 109 may analyze the UDP header 1333 during deep packet inspection to determine whether the UDP destination port 1356 is within a predetermined range of UDP port numbers (or whether the UDP destination port 1356 is equal to a predetermined UDP port number) to identify whether the RUid bitmask 602 is present at a specific byte offset (sometimes multiple ports can also be used to distinguish packet types). In other words, in some configurations, the DPI entity 109 may identify a specific UDP destination port 1356 to know that the RUid bitmask 602 is located at a specific byte offset within the UDP payload 1328 from the UDP header 1333. For example, if the UDP destination port 1356 is within a predetermined range or equals a predetermined value (e.g., 0x2222), the DPI entity 109 may interpret the byte(s) at the particular offset as the RUid bitmask 602. In this example, if the UDP destination port 1356 is not within the predetermined range or is not equal to the predetermined value (e.g., 0x2222), the DPI entity 109 does not interpret the byte(s) at the particular offset as the RUid bitmask 602 before forwarding.

[0133] As mentioned above, the fronthaul 116 is implemented using a standard switched ETHERNET network 120. Thus, the lowest layer (data link layer) of the protocol stack 1200 is the ETHERNET layer 1212 (shown in FIG. 12), through which ETHERNET packets 1334 (shown in FIG. 13A) are communicated between the controller 104 (or CU 103 or DU 105) and the radio unit 106 over the ETHERNET network 120. As shown in FIG. 13A, each ETHERNET packet 1334 includes a standard ETHERNET header 1336 and a payload 1338. The ETHERNET header 1336 includes an ETHERNET source address 1342, an ETHERNET destination address 1344, an optional VLAN tag (not shown), an optional VLAN header (not shown), and / or a field for the ETHERNET type 1346. The ETHERNET type 1346 field may indicate the type and format of the ETHERNET payload 1338, for example, an IP packet 1330 or a payload according to some other protocol. In some configurations, the ETHERNET header 1336 may be analyzed during deep packet inspection to determine whether the ETHERNET payload 1338 contains an IP packet 1330. In other configurations where the ETHERNET type 1346 is not IP, the ETHERNET type 1346 may be a reserved, predetermined value that indicates that the RUid bitmask 602 is present at a particular byte offset from the ETHERNET header 1336. One or more IP packets 1330 may be encapsulated within the payload 1338 of each ETHERNET packet 1334.

[0134] The protocol stack 1200 is configured to enable I / Q fronthaul data to be communicated over the fronthaul 116 of the C-RAN 100 using a standard switched ETHERNET network 120 (instead of traditional synchronous CPRI point-to-point links). Various standard functions provided by the UDP, IP, and ETHERNET layers 1208, 1210, and 1212 (e.g., port numbers, IP multicast groups, VLANs, and packet tagging) can be used to help meet the requirements of the fronthaul 116, while additional functions implemented in the application layer 1202 are used as needed.

[0135] Figure 13B is a block diagram illustrating an example of fields within an ETHERNET packet 534, a SwIQ-DAP protocol data unit (PDU) 1308, a TLV element 1300, and a SwIQ-DAP header 1310. The example of Figure 13B includes many of the same fields as shown in the example of Figure 13A, with some differences.

[0136] Specifically, the example of FIG. 13B differs from the example of FIG. 13A because the example of FIG. 13B does not implement the IP packet 1330 or UDP datagram (in IP payload 1340) from FIG. 13A, but instead shows the SwIQ-DAP protocol data unit (PDU) 1308 in the ETHERNET payload 1338. In this case, deep packet inspection can be performed on another field. For example, the ETHERNET type 1346 can be a customized type in which the SwIQ packet resides. The O-RAN specification currently supports I / Q transport over the Enhanced Common Public Air Interface (ECPRI).

[0137] In other embodiments (not shown in FIG. 13B), IP packet 1330 may be implemented with IP header 1332 but without a UDP datagram inside it. In these configurations, another type of header may be used instead of UDP.

[0138] FIG. 14A is a block diagram illustrating an example configuration for deep packet inspection in a fronthaul network 116. The fronthaul network 116 may be implemented as an ETHERNET network including one or more switch(es), router(s), and / or other networking device(s). Specifically, the fronthaul network 116 includes an aggregation switch 111 and, optionally, at least one switch 113. The aggregation switch 111 can transport data between the at least one switch 113 and at least one baseband controller 104 (4G) or DU 105 or CU (5G), referred to as BC 104 / DU 105 / CU 103. For example, the aggregation switch 111 may receive downlink ETHERNET packets 1334 from the BC(s) 104 / DU(s) 105 / CU(s) 103 and selectively forward at least a portion of them to the switch(es) 113. In other configurations, the aggregation switch 111 may selectively forward downlink ETHERNET packets 1334 to the switch(es) 113. Switch 111 may forward directly to RU 106 (without intervening switch 113).

[0139] In some configurations, the switches 113 are daisy-chained, with only a single switch 113 coupled to an aggregation switch 111. Alternatively, multiple switches 113 may be coupled to an aggregation switch 111. Furthermore, the fronthaul network 116 may be implemented using any number of aggregation switches 111 and / or optional switches 113. In some configurations, data may be transported between the aggregation switches 111 and the switches 113 as I / Q data and / or “timing and management” (TM) data.

[0140] One or more of the aggregation switches 111 and / or switches 113 may each include a DP entity 109. If at least one of the switches 113 includes a DPI entity, the switches 113 should be able to communicate with each other. Each DPI entity 109 may be implemented using at least one processor-executable instruction stored in at least one memory and executable to perform the deep packet inspection functions described herein. During deep packet inspection, the DPI entity 109 (e.g., in an ETHERNET switch) looks at the RU id bit mask 602, if present, to determine whether to forward the ETHERNET packet 1334 (e.g., the downlink I / Q packet 1308) to the intended RU(s) 106. The RU id bit mask 602 may be any length suitable to accommodate the many RUs 106 in the C-RAN 100, such as, for example, 32 bits, 64 bits, 128 bits, etc.

[0141] In some configurations, the RUid bitmask 602 in the SwIQ-DAP header 1310 (e.g., in the first X bytes of the ETHERNET packet 1334) is compared to a predetermined bit pattern to determine whether the ETHERNET packet 1334 (or a portion thereof) is dropped or forwarded to the intended RU(s) 106.

[0142] Some switch management functions (e.g., VLANs, enabling / disabling ports, adding IPs) can be performed over a secure connection, while other management functions, such as configuring bit patterns on the switch, can be performed over a normal connection.

[0143] In some embodiments, the DPI entity 109 (e.g., in an ETHERNET switch) may check the RUid bitmask 602 only when the destination port 1356 is in a configured port range (or equals a predetermined value).

[0144] In some embodiments, each RU 106 is assigned an RUid during a discovery process, for example, performed between the RU 106 and the BC 104, DU 105, or CU 103. The RU 106 registers itself in the DPI entity 109 (e.g., in an ETHERNET switch) and requests to forward packets on a predetermined multicast address (e.g., abcd) with its RUid bit set (in the RUid bit mask 602). A given RU may request multiple multicast address and RUID combinations. Multiple IP addresses may be used within a sector for load balancing. Multiple IP addresses may be used to distinguish traffic belonging to different sectors. Furthermore, an RU 106 may serve multiple sectors.

[0145] In some embodiments, the BC 104 / DU 105 / CU 103 and RU 106 use a registration procedure similar to the Internet Group Management Protocol (IGMP). For example, The messages may be used to indicate to the aggregation switch 111 and / or optional switch 113 which multicast groups to use with which controllers 104 and RUs 106. In some embodiments, the active BC 104 / DU 105 / CU 103 and RU 106 serving a given cell 108 may join the downlink timing multicast group and the downlink and uplink IQ data multicast groups assigned to that cell. In these embodiments, the standby BC 104 / DU 105 / CU 103 does not join any of the cell's downlink timing multicast groups or downlink or uplink IQ data multicast groups.

[0146] Optionally, the management system 107 may be communicatively coupled to the BC(s) 104, the CU(s) 103, the DU(s) 105, and / or the RUs 106, for example, via the backhaul network 114 and / or the fronthaul network 116. As described above, the management system 107 may be used for management plane (“M-plane”) communications, for example, using a hierarchical architecture, a direct architecture, or a hybrid architecture. Additionally, the management system 107 may determine configuration information for various entities.

[0147] 14B is a block diagram illustrating additional details regarding an example implementation of the fronthaul network 116 for the C-RAN 100 using a switched ETHERNET network 120. The example of FIG. 14B includes many of the same or similar devices, systems, and / or modules in other figures herein. In FIG. 14B, the term controller 104 is used to refer to the baseband controller 104, the 5G CU 103, or the 5G DU 105.

[0148] Generally, the switched ETHERNET network 120 includes one or more ETHERNET switches. In the example shown in FIG. 14B, the switched ETHERNET network 120 includes an aggregation layer including one or more aggregation ETHERNET switches 111 and an access layer including one or more access ETHERNET switches 113. For ease of illustration, only one aggregation switch 111 and one access ETHERNET switch 113 are shown in FIG. 14B, but other numbers of switches 111 and 113 can be used. Other ETHERNET network topologies can also be used (e.g., there can be additional layers (or hops) of ETHERNET switches between (or within) the aggregation layer and the access layer, or an entirely different topology can be used). Each radio unit 115, 117 can alternatively be communicatively coupled to the aggregation switch 111 without an intervening switch 113.

[0149] As shown in more detail in FIG. 14B , in this exemplary embodiment, the controller 104 and the radio points 106 communicate with each other over a switched ETHERNET network 120, which is used to implement the fronthaul 116 using two common virtual local area networks (VLANs). In this embodiment, one VLAN is used to communicate timing information (e.g., Institute of Electrical and Electronics Engineers (IEEE) 1588 Precision Time Protocol (PTP) messages used to synchronize the controller 104 and the RUs 106) and management information (e.g., Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) messages) between the controller 104 and the radio points 106. This VLAN is referred to herein as the “Timing and Management” or “TM” VLAN. A second VLAN is used to communicate IQ data between the controller 104 and the radio points 106 and is referred to herein as the “IQ” VLAN.

[0150] In this embodiment, the TM and IQ VLANs are configured such that all controllers 104 and associated RUs 106 in the cluster 124 are members of the TM and IQ VLANs.

[0151] 14B, the fronthaul 116 is used to fronthaul data for two clusters 124 that serve two respective wireless operators. In this example, a separate VLAN is established for each cluster 124 for inter-controller communications between the controllers 104 that include that cluster 124. Each such VLAN is referred to herein as a "cluster" or "C" VLAN.

[0152] In the embodiment shown in FIG. 14B, each controller 104 includes multiple ETHERNET network interfaces 130 for coupling the controller 104 to the switched ETHERNET network 120 (more specifically, in the embodiment shown in FIG. 14B, to one or more aggregation switches 111).

[0153] In the example shown in FIG. 14B , a portion of the ETHERNET network interface 130 in each controller 104 is dedicated to communicating timing and management data over a timing and management VLAN. Each such ETHERNET network interface 130 is also referred to herein as a “timing and management” or “TM” ETHERNET network interface 130. In this example, a portion of the ETHERNET network interface 130 in each controller 104 is dedicated to communicating IQ data over an IQ VLAN and is referred to herein as an “IQ” ETHERNET network interface 130. Also in this example, a portion of the ETHERNET network interface 130 in each controller 104 is dedicated to communicating over a cluster VLAN. Each such ETHERNET network interface 130 is referred to herein as a “cluster” or “C” ETHERNET network interface 130. Each controller 104 also includes one or more other ETHERNET network interfaces (not shown) used to communicate with the core network 112 via a backhaul.

[0154] In the embodiment shown in FIG. 14A and / or FIG. 14B, each single-instance radio point unit 117 includes at least one ETHERNET network interface 184, and each multi-instance radio point 115 includes at least two ETHERNET network interfaces 184, where each such ETHERNET network interface 184 is used to communicate over both the timing and management VLAN and the IQ VLAN.

[0155] 14A and / or 14B, for each cell 108 served by a cluster 124, the controller 104 serving that cell 108 sends timing messages over the timing VLAN by multicasting the timing messages using the respective timing multicast group defined for that cell 108. That is, each cell 108 served by a cluster 124 has a single timing multicast group assigned to it. In this embodiment, for each cell 108 served by a cluster 124, the RU 106 sends timing messages over the timing and management VLAN by unicasting the messages to the IP address assigned to the timing and management ETHERNET interface of the serving controller 104 for that cell 108.

[0156] Also in the example shown in FIG. 14B, for each cell 108 served by cluster 124, management messages are sent between controller 104 and RU 106 over the timing and management VLAN by unicasting the messages using an IP address assigned to the timing and management ETHERNET interface of controller 104 or to the ETHERNET interface 184 of RU 106 to which the messages are sent.

[0157] A set of downlink and uplink IP multicast groups are used for transmitting downlink and uplink IQ data, respectively.

[0158] Timing, control, and IQ data may be conveyed in other ways.

[0159] Generally, when each radio point 106 powers up, each radio point instance implemented by that radio point 106 uses a discovery protocol to discover the controller 104 to which it should be homed. As part of the discovery process, the radio point instance is provided with the IP address assigned to the timing and management ETHERNET interface 130 of the discovered controller 104. The radio point instance uses that IP address to establish a SOAP (management) connection with the controller 104. The controller 104 communicates the IP addresses of the downlink and uplink IP multicast groups that the radio point instance should use to communicate downlink and uplink IQ data.

[0160] In a configuration in which multiple controllers 104 serve a given radio point instance (e.g., a controller 104 serves as a backup controller for another primary controller 104, or carrier aggregation is used and multiple controllers 104 are used to perform baseband processing for multiple carriers), each radio point instance serving a given cell 108 still registers with the appropriate downlink IP multicast group for the cell 108 and transmits data to the controller 104 over the fronthaul 116 using the appropriate uplink IP multicast group. Because IP multicast is used, multiple controllers 104 can register with and receive data using the same uplink IP multicast group that the radio point instance in that cell 108 uses to transmit data over the fronthaul 116, and multiple controllers 104 can transmit data over the fronthaul 116 to the radio point instance in that cell 108 using the downlink IP multicast group to which they subscribe. That is, due to the use of IP multicast, the radio point instance is transparently served by multiple controllers 104.

[0161] Furthermore, the use of IP multicast does not preclude a single controller 104 serving multiple cells 108. In a configuration in which a single controller 104 serves multiple cells 108 (e.g., a primary cell 108 and a secondary cell 108), the single controller 104 subscribes to the uplink IP multicast groups of the primary cell 108 and the secondary cell 108 and transmits data to the appropriate radio point instances over the fronthaul 116 using the downlink IP multicast groups of the primary cell 108 and the secondary cell 108.

[0162] In some embodiments, downlink IQ data is transmitted between the radio points 106 associated with each controller 104 for each UE, while uplink IQ data is transmitted between the radio points 106 associated with each controller 104 for each UE. , transmitted per RU. In other (e.g., O-RAN) embodiments, both downlink and uplink IQ data are transmitted per RU. For each UE 112 served by a cell 108, the serving controller 104 assigns a subset of the cell's RUs 106 to that UE 112 for downlink radio transmissions to that UE 112. This subset of RUs 106 is referred to herein as the "simulcast zone" for that UE 112. The simulcast zone for each UE 112 is determined based on received power measurements made at each of the RUs 106 for particular uplink transmissions from the UE 112 (e.g., LTE Physical Random Access Channel (PRACH) and Sounding Reference Signal (SRS) transmissions), and is updated as the UE 112 moves throughout the cell 108.

[0163] For the uplink, in this embodiment, for each cell 108, the radio point 106 serving that cell 108 sends uplink IQ data to the serving controller 104 using a set of uplink IP multicast groups and multicast load balancing. In this embodiment, multiple link aggregation groups (LAGs) are defined for each cell 108, and each LAG has an uplink IP multicast group associated with it. The switches 111 and 113 of the switched ETHERNET network 120 are configured to load balance the uplink IQ data traffic across the various IQ ETHERNET interfaces of the serving controller 104 using multicast load balancing.

[0164] As with the uplink, multiple downlink IP multicast groups are used for load balancing purposes. For the downlink, multiple sets of downlink IP multicast groups are used to transmit downlink IQ data to different combinations of RUs 106, where the set of downlink IP multicast groups is dynamic. For one set of downlink IP multicast groups, each of the downlink IP multicast groups in the set includes all of the RUs 106 serving the cell 108. These "all RU" downlink IP multicast groups are used to transmit downlink IQ data for common logical channels on the air interface to all of the RUs 106 in the cell 108. One example of where this may be done is for transmitting downlink IQ data for LTE system information blocks (SIBs). The "all RU" downlink IP multicast group may also be used when there are no other suitable sets of downlink IP multicast groups. For other sets of downlink IP multicast groups, all of the constituent downlink IP multicast groups include fewer than all of the RUs 106 serving the cell 108. These other sets of downlink IP multicast groups are created as needed to communicate downlink IQ data (Physical Downlink Shared Channel (PDSCH) downlink IQ data) only to those RUs 106 that are in the simulcast zone of a given UE 112.

[0165] When downlink data needs to be sent to a given UE 112 over the air interface, if there is an existing set of downlink IP multicast groups that "match" the simulcast zone of that UE 112, one of the downlink IP multicast groups from the matching set is used to send the UE 112's downlink IQ data to the RUs 106 in that UE's simulcast zone. If there is no set of downlink IP multicast groups that matches the simulcast zone of a given UE 112, a new set of downlink IP multicast groups can be created, where all of the downlink IP multicast groups in the set include the RUs 106 in that simulcast zone, and the newly created downlink IP multicast groups One of the designated downlink IP multicast groups is used to transmit downlink IQ data only to those RUs 106 in that simulcast zone. If a new matching set of downlink IP multicast groups cannot be created (e.g., because the maximum number of downlink IP multicast groups has already been created and at that point none of the existing downlink IP multicast group sets can be purged due to unused), one of the aforementioned "all RU" downlink IP multicast groups can be used.

[0166] However, using an "all RU" downlink IP multicast group may result in downlink IQ data for a given UE 112 being transmitted to RUs 106 that are not included in the UE's simulcast zone. To address this, in this embodiment, an application layer multicast address included in the IQ data (as described below) is used to identify the RUs 106 to which the associated downlink IQ data is actually directed. In this embodiment, the application layer multicast address includes an address field that can be viewed as multiple bit positions. One of the bit positions is assigned to each RU 106 that serves the cell 108, and the bit position is set (i.e., stores a first binary value (e.g., 1)) if the associated downlink IQ data serves the associated RU 106, and is cleared (i.e., stores a second binary value (e.g., zero)) if the associated downlink IQ data does not serve the associated RU 106. For example, all bit positions of the application layer multicast address would be set in a packet containing downlink IQ data for a common message (e.g., SIB) that is intended for all RUs 106. For downlink IQ data intended for a UE 112 that includes fewer RUs than all RUs 106 in a simulcast zone, only the bit positions of the application layer multicast address that correspond to the RUs 106 in that simulcast zone are set, and the bit positions that correspond to all other RUs 106 are cleared. (One example of an application layer multicast address is the application layer multicast address field 1326, described below in connection with Figures 13A and 13B.)

[0167] Figure 15 is a block diagram of a wireless system with multiple RUs and UEs. In the following description, the wireless system is used to explain one embodiment of a method for communicating downlink IQ data from a serving controller 104 to a radio point 106 over a switched ETHERNET network 120 using IP and application layer multicast groups. In the embodiment shown in Figure 15, five RUs 106 and three UEs 112 are shown. The RUs 106 are individually referenced in Figure 15 as RU1, RU2, RU3, RU4, and RU5, respectively. The UEs 112 are individually referenced in Figure 15 as UE A, UE B, and UE C, respectively. In the embodiment shown in Figure 15, UE A's simulcast zone includes RU1, RU2, and RU4, UE B's simulcast zone includes RU4 and RU5, and UE C's simulcast zone includes RU2, RU3, and RU5. If UE A, UE B, and UE C all remain in the same location and continue to access cell 108, three downlink IP multicast groups will be formed (if they do not already exist). These three downlink IP multicast groups include a first downlink IP multicast group containing RU1, RU2, and RU4 (and in this example, assigned IP address 293.2.1.10), a second downlink IP multicast group containing RU4 and RU5 (and in this example, assigned IP address 293.2.1.11), and a third downlink IP multicast group containing RU2, RU3, and RU5 (and in this example, assigned 293.2.1.12). However, these "matching" downlink IP multicast groups It may take some time for all the P multicast groups to be formed.

[0168] For example, when UE A first accesses cell 108 and a downlink IP multicast group including RU1, RU2, and RU4 has not yet been created, the "all RU" downlink IP multicast group (assigned IP address 239.2.1.1 in this example) can be used to transmit downlink IQ data to the RUs in UE A's simulcast zone (i.e., RU1, RU2, and RU4). In this case, as shown in FIG. 15, a packet containing downlink IQ data intended for the RUs in UE A's simulcast zone is transmitted to the "all RU" downlink IP multicast group (using the corresponding IP address 239.2.1.1) with an application layer multicast address of "11010," in which the first bit position (corresponding to RU1), the second bit position (corresponding to RU2), and the fourth bit position (corresponding to RU4) are set, and the third bit position (corresponding to RU3) and the fifth bit position (corresponding to RU5) are cleared. In this example, only five bit positions are shown for ease of explanation, but an application layer multicast address would typically use many more bit positions (e.g., 64 bit positions corresponding to an 8-byte address).

[0169] Once a downlink IP multicast group containing RU1, RU2, and RU4 is created, packets containing downlink IQ data intended for RUs in UE A's simulcast zone are sent to the downlink IP multicast group (using the corresponding IP address 239.2.1.10), with the same application layer multicast address "11010".

[0170] Also in this example, packets containing downlink IQ data for common messages (such as SIBs) are sent to the "all RU" downlink IP multicast group (using the corresponding IP address 239.2.1.1), and the application layer multicast address is "11111" (as the data is intended for all RUs).

[0171] Deep Packet Inspection 16 is a flow diagram illustrating a method 1600 for transmitting data across a fronthaul interface and a fronthaul network 116 of a C-RAN 100 using deep packet inspection (DPI). The method 1600 may be performed by at least one processor of an ETHERNET switch of the fronthaul 116 of the C-RAN 100. For example, the ETHERNET switch may be an aggregation switch 111 or a switch 113, either of which implements the DPI entity 109. The ETHERNET switch may be communicatively coupled to the BC(s) 104, the DU(s) 105, the CU(s) 103, and / or the RU(s) 106 that form the C-RAN 100 (or a portion of the C-RAN 100). Additionally, in some configurations, the ETHERNET switch implementing the method 1600 may be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1600, it may be communicatively coupled to (1) at least one switch 113 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. Alternatively, if aggregation switch 111 implements method 1600, it may be communicatively coupled to (1) at least one RU 106 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. As another example, if switch 113 implements method 1600, it may be communicatively coupled to (1) aggregation switch 111 and (2) at least one RU 106. Other configurations are possible. In some embodiments, The method 1600 is performed for every packet received at the ETHERNET switch.

[0172] 16 are arranged in a generally sequential manner for ease of explanation, it should be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 1600 (and the blocks shown in FIG. 16) may occur in a different order (e.g., if at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Also, while most standard exception handling has not been described for ease of explanation, it should be understood that method 1600 is capable of, and typically would include, such exception handling.

[0173] Method 1600 begins at optional step 1602, where at least one processor receives a packet of data. The packet may be an ETHERNET packet 1334 containing I / Q data. In a first embodiment, the ETHERNET packet 1334 may include a multicast IP packet 1330 having a UDP datagram 1308 in its IP payload 1340, which includes an I / Q packet 1308 having a header 1310 with an RUid bitmask 602 (or other form of RU identification), as in FIG. 13A. In a second embodiment, the ETHERNET packet 1334 may include the I / Q packet 1308 (with the RUid bitmask 602 therein) and not include an IP header 1332 or a UDP header 1333, as in FIG. 13B. Alternatively, the packet received in step 1602 may be the multicast IP packet 1330 or the I / Q packet 1308 itself. The packet may be, for example, one of multiple received packets in a stream of ETHERNET packets 1334.

[0174] If the ETHERNET switch implementing method 1600 is an aggregation switch 111, the packet may be received (1) in the downlink direction from a BC 104, a DU 105, or a CU 103, or (2) in the uplink direction from a switch 113 or an RU 106. If the ETHERNET switch implementing method 1600 is a switch 113, the packet may be received (1) in the downlink direction from a BC 104, a DU 105, a CU 103, or an aggregation switch 111, or (2) in the uplink direction from a different switch 113 or an RU 106.

[0175] Method 1600 proceeds to optional step 1604, where at least one processor identifies at least one bit pattern for each of the at least one RU 106 for which the packet is intended. Some RUs 106 can host multiple carriers, for example, up to four. When an RU 106 hosts multiple carriers, the RU 106 implements a processor-implemented radio unit instance or module for each carrier, all of which share the same physical ETHERNET port on the RU 106. Also, when an RU 106 hosts multiple carriers, each radio unit instance communicates with a different BC 104, DU 105, or CU 103 and assigns an RUid to the radio unit instance. Thus, a multi-instance radio unit 115 can assign multiple RUids, each from a different BC 104, DU 105, or CU 103. For example, a particular radio unit instance may be assigned RUid=1 by a first BC 104, DU 105, or CU 103, and RUid=3 by a second BC 104, DU 105, or CU 103.

[0176] However, RUids assigned by different BCs 104, DUs 105, or CUs 103 may overlap with each other. is associated with the IP address that the BC 104, DU 105, or CU 103 uses to communicate with the radio unit instance. In some embodiments, at least one bit pattern is stored in the ETHERNET switch for each combination of (1) a radio unit instance implemented in an RU 106 with which the ETHERNET switch communicates, and (2) the IP address that the BC 104, DU 105, or CU 103 uses to communicate with the radio unit instance. In other words, the RUid of a radio unit instance depends on the IP address that the BC 104, DU 105, or CU 103 uses to communicate with the radio unit instance. Alternatively, a single-instance radio unit 117 may be assigned only a single RUid, in which case the RUid is independent of the IP address that the BC 104, DU 105, or CU 103 uses to communicate with it. In some embodiments, the bit pattern may be configured at runtime over a secure connection.

[0177] In an optional first configuration of step 1604, the packet's ETHERNET type 1346 is IP, and the bit pattern is associated with the RU(s) 106 identified by the destination IP address 1350 (e.g., a multicast IP address) of the IP packet 1330 of the ETHERNET packet 1334. In an optional second configuration of step 1604, the packet's ETHERNET type 1346 is a predetermined value (not IP), and the bit pattern is associated with the RU(s) 106 identified by the destination MAC address of the ETHERNET packet 1334. In other words, the bit pattern(s) may be selected for the RU(s) 106 using a multicast IP address or a multicast MAC address, depending on the packet's ETHERNET type 1346. Furthermore, if the ETHERNET type is neither IP nor a predetermined value, the packet may be forwarded without looking at the RUid bit mask 602, as described below. Alternatively, the RUid of a wireless instance may be associated with the IP address of the BC 104, DU 105, or CU 103 that was assigned the RUid.

[0178] The method 1600 proceeds to step 1606, where at least one processor performs deep packet inspection (DPI) on the packet to determine whether an RUid bitmask 602 is present in the packet, where the RUid bitmask 602 indicates at least one RU 106 to which the packet is intended. Deep packet inspection may include hierarchical inspection / analysis of the packet to identify one or more fields within the packet. In some configurations, the I / Q packet 1308 (including the RUid bitmask 602) is contained in a UDP datagram 1330, which is contained in an IP packet 1330, which is contained in an ETHERNET packet / frame 1334. Thus, deep packet inspection can be used to determine whether the RUid bitmask 602 is present in the received packet (at what relative position / offset).

[0179] Each RUid bitmask 602 may be a set of bits (e.g., each bit having a value of “1” or “0”), the length of which is at least equal to the number of RUs 106 in the C-RAN 100 (or a single sector of the C-RAN 100). The bits of the RUid bitmask 602 in a packet are set based on whether the RUs 106 associated with the bits are required to decode and / or transmit the information in the packet. For example, if all RUs 106 are required to decode and / or transmit the packet's payload (e.g., the I / Q payload 1312), all bits are set to 1. Alternatively, if a subset of the RUs 106 are required to transmit the packet's payload, only the bits corresponding to the subset of RUs 106 are set to 1. The RUid bitmask 602 may be of any length suitable to accommodate many RUs 106 in the C-RAN 100, such as, for example, 32 bits, 64 bits, 128 bits, etc.

[0180] Alternatively, the RU identification may be communicated in other ways (instead of a bitmask having a bit for each RU 106 in the C-RAN 100). For example, the targeted RUs 106 may be identified using (1) an explicit RUid value in the packet and / or (2) a variable-length RUid bitmap with a starting offset.

[0181] The method 1600 proceeds to step 1608, where, when the RUid bitmask 602 is present in the packet, the at least one processor communicates at least a portion of the packet to each of the at least one RU 106 based on a comparison of the RUid bitmask 602 with the bit pattern(s) of the respective RU 106. In some configurations, the RUid bitmask 602 in the packet is compared to the bit pattern(s) (from optional step 1604) using a bitwise AND operation.

[0182] If the bitwise AND of the RUid bit mask 602 with the bit pattern(s) of the RU 106 are all equal to zero (indicating that the packet 1334 is not intended for the RU 106 on the specified IP address), the packet 1334 may be dropped by the ETHERNET switch. In other words, if none of the bit pattern(s) for at least one RU 106 have a set bit in the same bit position as a set bit in the RUid bit mask 602, the at least one processor may drop the packet (not send it to any RU 106).

[0183] On the other hand, if the bitwise AND of the RUid bit mask 602 with the bit pattern(s) of the RU 106 are not all equal to zero (indicating that the packet 1334 is intended for the RU 106 on the specified IP address), then the packet 1334 (or a portion thereof) may be communicated to the RU 106. In other words, for each bit pattern that has a set bit in the same bit position as a set bit in the RUid bit mask 602, at least one processor may communicate at least a portion of the packet to the RU 106 associated with the bit pattern.

[0184] At least a portion of the packet may be all or part of an ETHERNET packet / frame 1334, an IP packet 1330 contained in an ETHERNET packet 1334, a UDP datagram 1330 contained in an IP packet 1330, or an I / Q packet 1308 contained in a UDP datagram 1330. The communication may include unicast, broadcast, or multicast as described herein.

[0185] Method 1600 proceeds to optional step 1610, where, when RUid bitmask 602 is not present in the packet, at least one processor communicates at least a portion of the packet to at least one RU 106 without comparing any RUid bitmask 602 to any bit patterns of the RU 106. Packets may be constructed according to different protocols, many of which will not include RUid bitmask 602. For example, RUid bitmask 602 may not be included in a packet if ETHERNET type 1346 is not IP or another reserved, predetermined value. Similarly, RUid bitmask 602 may not be included in a packet if ETHERNET type 1346 is IP but IP type 1352 is not UDP. Similarly, RUid bitmask 602 may not be included in a packet if ETHERNET type 1346 is IP and IP type 1352 is UDP but destination port 1356 is not within a predetermined range of port numbers. If deep packet inspection cannot identify the RUid bitmask 602 (because it is not included in the packet or for other reasons), the packet must still be communicated.

[0186] 17 is a flow diagram illustrating a method 1700 for performing deep packet inspection (DPI) on a packet. Method 1700 may be performed by at least one processor of an ETHERNET switch in the fronthaul 116 of C-RAN 100. For example, the ETHERNET switch may be an aggregation switch 111 or a switch 113, either of which implements the DPI entity 109. The ETHERNET switch may be communicatively coupled to BC(s) 104, DU(s) 105, CU(s) 103, and / or RU(s) 106 that form C-RAN 100 (or a portion of C-RAN 100). Additionally, in some configurations, the ETHERNET switch implementing method 1700 may be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1700, it may be communicatively coupled to (1) at least one switch 113 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. Alternatively, if aggregation switch 111 implements method 1700, it may be communicatively coupled to (1) at least one RU 106 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. As another example, if switch 113 implements method 1700, it may be communicatively coupled to (1) aggregation switch 111 and (2) at least one RU 106. Other configurations are possible. In some embodiments, method 1700 is an example of deep packet inspection (performed on received packets) in step 1606 of method 1600 of FIG. 16 .

[0187] 17 are arranged in a generally sequential manner for ease of explanation, it should be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 1700 (and the blocks shown in FIG. 17) may occur in a different order (e.g., if at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Also, while most standard exception handling has not been described for ease of explanation, it should be understood that method 1700 is capable of, and typically would include, such exception handling.

[0188] Method 1700 begins at step 1702, where at least one processor determines an ETHERNET type 1346 of an ETHERNET packet 1334. The ETHERNET packet 1334 may include (1) an ETHERNET header 1336, including an ETHERNET source address 1342, an ETHERNET destination address 1344, an optional VLAN tag, an optional VLAN header, and / or an ETHERNET type 1346 field, and (2) an ETHERNET payload 1338. The ETHERNET type 1346 field may indicate a type of payload 1338, such as, for example, an IP packet 1330 or a payload according to some other protocol. For example, the ETHERNET type 1346 may indicate that the ETHERNET payload 1338 includes an IP packet 1330. In some configurations, a predetermined value (other than IP) may be reserved to indicate the inclusion (and byte offset) of the RUid bitmask 602 in an ETHERNET packet 1334 that does not include an IP packet 1330 or a UDP datagram (e.g., inside an IP packet 1330). In other words, the reserved predetermined value, when included in the ETHERNET type 1346 field, may specifically indicate that the RUid bitmask 602 is present at a particular byte offset within the ETHERNET header 1336 or the ETHERNET payload 1338 from the ETHERNET type 1346. This reserved predetermined value may be used by the BC(s) 104 (or DU 105 or CU 103), the ETHERNET switch(es) 111, 113, the DU(s) 105, and / or the RU(s) 106. It may be known in the system by

[0189] The method 1700 proceeds to step 1704, where the at least one processor determines whether the ETHERNET type 1346 is IP. If not, the method 1700 proceeds to step 1705, where the at least one processor determines whether the ETHERNET type 1346 is a reserved, predetermined value, for example, 0x4321. If so, the method 1700 proceeds to step 1718, where the at least one processor determines the RUid bitmask 602 of the ETHERNET packet 1334 at a first predetermined offset, for example, specifically, a first predetermined byte offset from the ETHERNET header 1336 or the ETHERNET type 1346. In other words, in response to determining that the ETHERNET type 1346 is the reserved, predetermined value, the at least one processor may interpret a set of bits (offset from the ETHERNET type 1346 field) as the RUid bitmask 602. If the ETHERNET type 1346 is not IP or a reserved predetermined value, the method 1700 proceeds to step 1706, where the at least one processor terminates the method 1700 without determining the RUid bitmask 602 (wherein at least a portion of the packet is then communicated without comparing the RUid bitmask 602 to any bit pattern).

[0190] However, if the ETHERNET type 1346 is IP, the method 1700 proceeds to step 1708, where the at least one processor determines the IP type 1352 of the IP packet 1330. The IP packet 1330 may include (1) an IP header 1332 having a source IP address 1348, a destination IP address 1350, and / or an IP type 1352 field, and (2) an IP payload 1340. The IP type 1352 indicates the type 1352 of the IP payload 1340. For example, the IP type 1352 may indicate that the IP payload 1340 includes a UDP datagram. Alternatively, the IP type 1352 may indicate that the IP payload 1340 includes data of some other protocol, such as, for example, Transmission Control Protocol (TCP). The method 1700 proceeds to step 1710, where the at least one processor determines whether the IP type 1352 indicates UDP. If the IP type 1352 is not UDP, the method 1700 proceeds to step 1706 where the at least one processor ends the method 1700 without determining the RUid bitmask 602 .

[0191] If the IP type 1352 is UDP, the method 1700 proceeds to step 1712, where the at least one processor determines the destination port 1356 in the UDP datagram. The UDP datagram (in the IP payload 1340) may include a UDP header 1333 having a source port 1354 and / or a destination port 1356 (UDP payload 1328). Some UDP port numbers may be reserved for certain standard functions, while other UDP port numbers may be customized for application-specific purposes. The method 1700 proceeds to step 1714, where the at least one processor determines whether the UDP destination port 1356 is within a predetermined range of UDP port numbers (or whether the UDP destination port 1356 is equal to a predetermined UDP port number) to identify whether the RUid bitmask 602 is present at a particular byte offset from the UDP header 1356 or the UDP destination port 1356. In other words, a UDP destination port 1356 that (1) falls within a predetermined range of UDP port numbers or (2) is equal to a predetermined UDP port number indicates that the RUid bitmask 602 will be located specifically at a particular byte offset within the UDP header 1356 or the UDP payload 1328 from the UDP destination port 1356.

[0192] If the UDP destination port 1356 (1) falls within the predetermined range of UDP port numbers or (2) equals the predetermined UDP port number, method 1700 proceeds to step 1716, where the at least one processor determines the RUid bitmask 602 in the UDP payload 1328 at a second predetermined offset, e.g., a second predetermined byte offset. In other words, in response to determining whether the UDP destination port 1356 (1) falls within the predetermined range of UDP port numbers or (2) equals the predetermined UDP port number, the at least one processor can interpret a set of bits (specifically, offset from the UDP header 1333 or the UDP destination port 1356) as the RUid bitmask 602. If the UDP destination port 1356 (1) does not fall within a predetermined range of UDP port numbers or (2) is not equal to a predetermined UDP port number, the method 1700 proceeds to step 1706, where the at least one processor terminates the method 1700 without determining the RUid bitmask 602.

[0193] IP / UDP DPI Pseudo Code Example The following pseudocode is an example implementation of DPI using IP / UDP: if ETH_TYPE==IP if IP_TYPE==UDP if UDP_port_number within range Curr_RUID=RP_RUID based on multicast IP address if(Curr_RUID & Packet_RUID) !=0 / / & is a bitwise AND forward packet else discard packet endif else forward packet endif else forward packet endif

[0194] Here, ETH_TYPE is the ETHERNET type 1346, IP_TYPE is the IP type 1352, Curr_RUID is the bit pattern of the RU 106, RP_RUID is the RUid of the RU 106 indicated by the multicast IP address of the ETHERNET packet 1334, and Packet_RUID is the RUid bit mask 602.

[0195] The following pseudocode is an example implementation of DPI based on ETHERNET packet transport (without IP / UDP): if ETH_TYPE==X Curr_RUID=RP_RUID based on multicast IP address if(Curr_RUID & Packet_RUID) !=0 / / & is a bitwise AND forward packet else discard packet endif else forward packet endif

[0196] Here, X is a reserved predetermined value that indicates that the RUid bitmask 602 is included in an ETHERNET packet 1334 that does not include an IP packet 1330 or a UDP datagram.

[0197] Forwarding rules 18 is a flow diagram illustrating a method for establishing multicast rules in an ETHERNET switch. Method 1800 may be performed by each radio unit instance of the ETHERNET switch, at least one BC 104 (or CU 103 or DU 105), and RU 106. For example, the ETHERNET switch may be an aggregation switch 111 or a switch 113, either of which implements the DPI entity 109. The ETHERNET switch may be communicatively coupled to the BC(s) 104, DU(s) 105, CU(s) 103, and / or RU(s) 106 that form the C-RAN 100 (or a portion of the C-RAN 100). Furthermore, in some configurations, the ETHERNET switch implementing method 1800 may be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1800, it may be communicatively coupled to (1) at least one switch 113 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. Alternatively, if aggregation switch 111 implements method 1700, it may be communicatively coupled to (1) at least one RU 106 and (2) BC(s) 104, DU(s) 105, and / or CU(s) 103. As another example, if switch 113 implements method 1800, it may be communicatively coupled to (1) aggregation switch 111 and (2) at least one RU 106. Other configurations are possible.

[0198] 18 are arranged in a generally sequential manner for ease of explanation, it should be understood that this arrangement is merely exemplary, and it should be recognized that the processing associated with method 1800 (and the blocks shown in FIG. 18) may occur in a different order (e.g., if at least some of the processing associated with the blocks is performed in parallel and / or in an event-driven manner). Also, while most standard exception handling has not been described for ease of explanation, it should be understood that method 1800 is capable of, and typically would include, such exception handling.

[0199] Method 1800 begins at step 1802, where an RU initiates a discovery process (e.g., upon startup) and transmits an ETHERNET broadcast packet. At step 1804, each radio unit instance (RPI) is assigned an RUid by one or more BCs 104 (or DUs 105 or CUs 103), for example, via a SOAP connection with one of the radio unit instances. Additionally, the radio unit instance's E-UTRA absolute radio frequency channel number (EARFCN), various L1 and ETHERNET parameters may also be configured. At step 1806, each RPI notifies the ETHERNET switch of its target downlink multicast IP address range, target UDP port number range, and target RUID (32 / 64-bit value). In some embodiments, filter rules (e.g., forwarding rules) are set up for each radio unit instance (RPI) to join a multicast group, for example, using IGMP. As the switch receives additional join requests, its tables (e.g., routing tables) are updated. At step 1808, the ETHERNET switch , periodically polls each RPI to determine whether those rules still exist. The RU responds to retain the rules. In step 1810, when the connection with the BC 104 (or CU 103 or DU 105) is disconnected or the carrier is removed, the RU notifies the ETHERNET switch to release the rules it has set. If there is no response to the ETHERNET switch's periodic polling, the rules are deleted.

[0200] The methods and techniques described herein may be implemented in digital electronic circuitry, or in the firmware, software, or combinations of a programmable processor (e.g., a special-purpose processor or a general-purpose processor such as a computer). Apparatus embodying these techniques may include suitable input and output devices, a programmable processor, and a storage medium tangibly embodying program instructions for execution by the programmable processor. Processes embodying these techniques may be implemented by the programmable processor to execute a program of instructions to perform the desired function by operating on input data and generating appropriate output. The techniques may advantageously be implemented in one or more programs executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Generally, the processor will receive instructions and data from a read-only memory and / or a random-access memory. For example, when a computing device is described as performing an action, the computing device may perform this action using at least one processor executing instructions stored on at least one memory. Suitable storage devices for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including, by way of example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices, magnetic disks, such as internal hard disks and removable disks, magneto-optical disks, and DVD disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs).

[0201] term Below are brief definitions of terms, abbreviations, and phrases used throughout this application.

[0202] The term "determine" and variations thereof can include calculating, extracting, generating, computing, processing, deriving, modeling, investigating, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, and the like. "Determine" can also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. "Determine" can also include resolving, selecting, choosing, establishing, and the like.

[0203] Unless expressly specified otherwise, the phrase "based on" does not mean "based only on." In other words, the phrase "based on" describes both "based only on" and "based at least on." Furthermore, the term "and / or" means "and" or "or." For example, "A and / or B" can mean "A," "B," or "A and B." Furthermore, "A, B, and / or C" means "A alone," "B alone," "C alone," "A and B," "A and C," "B and C," or "A, B, and C."

[0204] The terms "connected," "coupled," and "communicatively coupled," as well as related Associated terms may refer to direct or indirect connections. If the specification states that a component or feature "may," "can," "could," or "might" be included in or have a characteristic, that particular component or feature is not required to be included in or have the characteristic.

[0205] The terms "responsive" or "in response to" may indicate that an action is performed wholly 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) components.

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

[0207] In conclusion, the present disclosure provides novel systems, methods, and arrangements for a fronthaul interface for use in a C-RAN. While a detailed description of one or more configurations of the present disclosure has been provided above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without departing from the spirit of the present disclosure. For example, while the configurations described above refer to particular features, functions, procedures, components, elements, and / or structures, the scope of the present disclosure also includes configurations having different combinations of features, functions, procedures, components, elements, and / or structures, as well as configurations that do not include all of the described features, functions, procedures, components, and / or structures. Accordingly, the scope of the present disclosure is intended to encompass all such alternatives, modifications, and variations that fall within the scope of the claims, together with all equivalents thereof. Therefore, the above description should not be construed as limiting.

[0208] Illustrative Embodiments Example 1 includes a Cloud Radio Access Network (C-RAN) including: a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE); and a central unit communicatively coupled to the plurality of remote units via a fronthaul network, the fronthaul network configured to implement a plurality of multicast groups, each multicast group including a respective group of the remote units, the central unit configured to: determine a set of data to be transmitted to a respective subset of the remote units over the fronthaul network; determine a mapping of each of the sets of data to a respective one of the subsets of remote units; and, for each set of data, transmit the set of data to the respective subset of remote units via the fronthaul network by multicasting the set of data to a multicast group that best matches the respective subset of remote units mapped to the set of data if at least one of the multicast groups completely includes the respective subset of remote units mapped to the set of data.

[0209] Example 2 includes the C-RAN described in Example 1, in which for each set of data, the multicast group that best matches the respective subset of remote units mapped to that set of data includes one of the multicast groups that completely includes the respective subset of remote units mapped to that set of data and includes the smallest total number of remote units.

[0210] Example 3 includes the C-RAN of example 1 or 2, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP 5th generation communication system.

[0211] Example 4 includes the C-RAN of any of Examples 1-3, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

[0212] Example 5 includes the C-RAN of any of Examples 1-4, configured to add a respective indicator to each set of data based on the mapping, each respective indicator indicating a respective remote unit to which the respective set of data is directed.

[0213] Example 6 includes the C-RAN of Example 5, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of a plurality of remote units.

[0214] Example 7 includes the C-RAN of Example 5 or 6, wherein the central unit is configured to transmit, for each set of data, the set of data to the respective subset of remote units over the fronthaul network by broadcasting the set of data if none of the multicast groups matches the respective subset of remote units mapped to the set of data.

[0215] Example 8 includes the C-RAN of any of Examples 1 to 7, wherein the C-RAN is configured such that an initial plurality of multicast groups are defined and the fronthaul network is configured to implement the initial plurality of multicast groups, and periodically, updated plurality of multicast groups are defined and the fronthaul network is configured to implement the updated plurality of multicast groups.

[0216] Example 9 includes the C-RAN of Example 8, wherein the C-RAN is configured such that each updated plurality of multicast groups is defined based on recent fronthaul traffic flows and / or recent locations of user equipment and remote units used to provide service to the user equipment.

[0217] Example 10 includes the C-RAN of Example 9, wherein the locations of the user equipment and the remote units used to provide service to the user equipment are determined by one or more of uplink measurements of a sounding reference signal (SRS), a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), and / or a physical random access channel (PRACH) made at each remote unit, preferred beam information determined by the user equipment, and a channel state information reference signal (CSI-RS) measurement report received from the user equipment.

[0218] Example 11 further includes a management system, wherein at least one of the central unit and the management system is configured to: define an initial plurality of multicast groups and each of the updated plurality of multicast groups; notify one or more of the management system, the central unit, and the remote unit about the defined initial plurality of multicast groups and each of the updated plurality of multicast groups; and cause a fronthaul network to implement the defined initial plurality of multicast groups and each of the updated plurality of multicast groups. 1. The present invention includes a C-RAN described in any one of claims 1 to 0.

[0219] Example 12 includes the C-RAN of Example 11, wherein management plane (M-plane) communication is used to at least one of notify one or more of a management system, a central unit, and a remote unit about the defined initial plurality of multicast groups and each updated plurality of multicast groups, and cause a fronthaul network to implement the defined initial plurality of multicast groups and each updated plurality of multicast groups.

[0220] Example 13 includes the C-RAN of example 12, wherein the M-plane communication includes M-plane communication of the O-RAN.

[0221] Example 14 includes a method implemented by a central unit in a Cloud Radio Access Network (C-RAN), the C-RAN also including a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE), the central unit being communicatively coupled to the plurality of remote units via a fronthaul network, the fronthaul network being configured to implement a plurality of multicast groups, each multicast group including a respective group of remote units, the method including: determining a set of data to be transmitted to a respective subset of the remote units over the fronthaul interface; determining a mapping of each of the sets of data to a respective one of the subsets of remote units; and, for each set of data, if at least one of the multicast groups matches the respective subset of remote units mapped to the set of data, transmitting the set of data to the respective subset of remote units via the fronthaul network by multicasting the set of data to a multicast group that best matches the respective subset of remote units mapped to the set of data.

[0222] Example 15 includes the method of Example 14, wherein for each set of data, the multicast group that best matches the respective subset of remote units mapped to the set of data includes one of the multicast groups that completely includes the respective subset of remote units mapped to the set of data and includes the smallest total number of remote units.

[0223] Example 16 includes the method of example 14 or 15, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP 5th generation communication system.

[0224] Example 17 includes the method of any of Examples 14-16, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

[0225] Example 18 includes the method of any of Examples 14-17, further including adding a respective indicator to each set of data based on the mapping, each respective indicator indicating a respective remote unit to which the respective set of data is directed.

[0226] Example 19 includes the method of example 18, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of a plurality of remote units.

[0227] Example 20 includes the method of Example 18 or 19, further including, for each set of data, if none of the multicast groups matches the respective subset of remote units mapped to the set of data, transmitting the set of data to the respective subset of remote units via the fronthaul network by broadcasting the set of data.

[0228] Example 21 includes the method of any of Examples 14 to 20, in which an initial plurality of multicast groups are defined for the C-RAN, and the initial plurality of multicast groups are implemented by the fronthaul network; and periodically, updated plurality of multicast groups are defined for the C-RAN, and the updated plurality of multicast groups are implemented by the fronthaul network.

[0229] Example 22 includes the method described in Example 21, in which each updated plurality of multicast groups is defined based on recent fronthaul traffic flows, recent locations of user equipment and remote units used to provide service to the user equipment, or some combination.

[0230] Example 23 includes the method of Example 22, in which the locations of the user equipment and the remote units used to provide service to the user equipment are determined by one or more of uplink measurements of a sounding reference signal (SRS), a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), and / or a physical random access channel (PRACH) made at each remote unit, preferred beam information determined by the user equipment, and a channel state information reference signal (CSI-RS) measurement report received from the user equipment.

[0231] Example 24 includes the method of any of Examples 21 to 23, in which at least one of the central unit and the management system defines an initial plurality of multicast groups and each updated plurality of multicast groups, notifies one or more of the management system, the central unit, and the remote unit about the defined initial plurality of multicast groups and each updated plurality of multicast groups, and causes the fronthaul network to implement the defined initial plurality of multicast groups and each updated plurality of multicast groups.

[0232] Example 25 includes the method of any of Examples 21 to 24, in which management plane (M-plane) communication is used to at least one of notify one or more of the management system, the central unit, and the remote unit about the defined initial plurality of multicast groups and each updated plurality of multicast groups, and cause the fronthaul network to implement the defined initial plurality of multicast groups and each updated plurality of multicast groups.

[0233] Example 26 includes the method of example 25, wherein the M-plane communication includes O-RAN M-plane communication.

[0234] Example 27 is a Cloud Radio Access Network (C-RAN), comprising: a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE); a central unit communicatively coupled to the plurality of remote units via a fronthaul network; and an entity configured to perform deep packet inspection, the entity communicatively coupled to the central unit via the fronthaul network. and a central unit configured to: determine sets of data to be transmitted to a plurality of remote units over a fronthaul network; determine a mapping of each of the sets of data to at least one of the plurality of remote units; add a respective indicator to a packet for each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective packet and set of data is intended; and transmit, via the fronthaul network, the packets for the sets of data, each having the respective indicator, to an entity; and configure the entity to perform deep packet inspection on each of the packets to determine each remote unit for which the packet is intended and communicate the packet via the fronthaul network to each remote unit for which the packet is intended.

[0235] Example 28 includes the C-RAN of example 27, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP 5th generation communication system.

[0236] Example 29 includes the C-RAN of example 27 or 28, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

[0237] Example 30 includes the C-RAN of any of Examples 27-29, wherein the entity includes one or more switches in the fronthaul network.

[0238] Example 31 includes the C-RAN of any of Examples 27 to 30, wherein the entity includes a fronthaul manager (FHM).

[0239] Example 32 includes a C-RAN described in any of Examples 27 to 31, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of a plurality of remote units.

[0240] Example 33 includes a method implemented in a Cloud Radio Access Network (C-RAN), including a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE), the C-RAN also including a central unit communicatively coupled to the plurality of remote units via a fronthaul network and an entity configured to perform deep packet inspection, the entity communicatively coupled to the central unit and the remote units via the fronthaul network, the method including: determining sets of data to be transmitted to the plurality of remote units over the fronthaul network; determining a mapping of each of the sets of data to at least one of the plurality of remote units; adding a respective indicator to a packet for each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective packet and set of data are intended; transmitting, via the fronthaul network, the packets for the sets of data, each having the respective indicator, to the entity; determining, by the entity, each remote unit for which the packet is intended, and performing deep packet inspection on each of the packets to communicate the packet to each remote unit for which the packet is intended via the fronthaul network.

[0241] Example 34 is a configuration in which the central unit operates in a 3GPP fifth generation communication system. The method of claim 33, wherein the dispersion unit (DU) is configured as follows:

[0242] Example 35 includes the method of example 33 or 34, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

[0243] Example 36 includes the method of any of Examples 33-35, wherein the entity includes one or more switches in the fronthaul network.

[0244] Example 37 includes the method of any of examples 33-36, wherein the entity includes a fronthaul manager (FHM).

[0245] Example 38 includes the method of any of Examples 33-37, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of a plurality of remote units.

Claims

1. A cloud radio access network (C-RAN), comprising: a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE); a central unit communicatively coupled to the plurality of remote units via a fronthaul network, the fronthaul network configured to implement a plurality of multicast groups, each of the multicast groups including a respective group of the remote units, the central unit comprising: determining a set of data to be transmitted to each subset of the remote units over the fronthaul network; determining a mapping of each of the sets of data to a respective one of the subset of the remote units; and transmitting the set of data to the respective subset of remote units via the fronthaul network by multicasting the set of data to the multicast group that best matches the respective subset of remote units mapped to the set of data, if at least one of the multicast groups completely includes the respective subset of remote units mapped to the set of data.

2. 2. The C-RAN of claim 1, wherein for each of the sets of data, the multicast group that best matches the respective subset of the remote units mapped to that set of data includes one of the multicast groups that completely includes the respective subset of the remote units mapped to that set of data and includes the smallest total number of remote units.

3. The C-RAN of claim 1, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth generation communication system.

4. The C-RAN of claim 1 , wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

5. The central unit:

2. The C-RAN of claim 1, configured to add a respective indicator to each set of data based on the mapping, each respective indicator indicating a respective remote unit to which the respective set of data is directed.

6. 6. The C-RAN of claim 5, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of the plurality of said remote units.

7. The central unit:

6. The C-RAN of claim 5, wherein, for each of the sets of data, if none of the multicast groups matches the respective subset of remote units mapped to that set of data, then transmitting the set of data to the respective subset of remote units via the fronthaul network by broadcasting the set of data.

8. The C-RAN an initial plurality of multicast groups are defined, and the fronthaul network is configured to implement the initial plurality of multicast groups; and 2. The C-RAN of claim 1, configured such that periodically updated multicast groups are defined and the fronthaul network is configured to implement the updated multicast groups.

9. The C-RAN of claim 8, wherein the C-RAN is configured such that each updated plurality of multicast groups is defined based on recent fronthaul traffic flows and / or recent locations of the user equipment and the remote units used to provide services to the user equipment.

10. the locations of the user equipment and the remote units used to provide service to the user equipment; uplink measurements of a Sounding Reference Signal (SRS), a Physical Uplink Control Channel (PUCCH), a Physical Uplink Shared Channel (PUSCH), and / or a Physical Random Access Channel (PRACH) made at each remote unit; Preferred beam information determined by the user equipment; and a Channel State Information Reference Signal (CSI-RS) measurement report received from the user equipment.

11. 9. The C-RAN of claim 8, further comprising a management system, wherein at least one of the central unit and the management system is configured to: define the initial plurality of multicast groups and each updated plurality of multicast groups; notify one or more of the management system, the central unit, and a remote unit about the defined initial plurality of multicast groups and each updated plurality of multicast groups; and cause the fronthaul network to implement the defined initial plurality of multicast groups and each updated plurality of multicast groups.

12. Management plane (M-plane) communication notifying one or more of the management system, a central unit, and a remote unit of the defined initial plurality of multicast groups and each updated plurality of multicast groups; and causing the fronthaul network to implement the defined initial and updated multicast groups.

13. The C-RAN of claim 12, wherein the M-plane communication includes M-plane communication of an O-RAN.

14. 1. A method implemented by a central unit in a Cloud Radio Access Network (C-RAN), the C-RAN also including a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE), the central unit being communicatively coupled to the plurality of remote units via a fronthaul network, the fronthaul network configured to implement a plurality of multicast groups, each of the multicast groups including a respective group of the remote units, the method comprising: determining a set of data to be transmitted to each subset of the remote units over the fronthaul interface; determining a mapping of each of the sets of data to a respective one of the subset of the remote units; and transmitting the set of data over the fronthaul network to the respective subset of remote units by multicasting the set of data to the multicast group that best matches the respective subset of remote units mapped to the set of data if, for each of the sets of data, at least one of the multicast groups matches the respective subset of remote units mapped to the set of data.

15. 15. The method of claim 14, wherein for each of the sets of data, the multicast group that best matches the respective subset of the remote units mapped to that set of data includes one of the multicast groups that completely includes the respective subset of the remote units mapped to that set of data and includes the smallest total number of remote units.

16. 15. The method of claim 14, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP 5th generation communication system.

17. 15. The method of claim 14, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

18. 15. The method of claim 14, further comprising adding a respective indicator to each set of data based on the mapping, each respective indicator indicating a respective remote unit to which the respective set of data is directed.

19. 20. The method of claim 18, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of the plurality of said remote units.

20. 20. The method of claim 18, further comprising: if, for each of the sets of data, none of the multicast groups matches the respective subset of the remote units mapped to that set of data, transmitting the set of data to the respective subset of remote units over the fronthaul network by broadcasting the set of data.

21. an initial plurality of multicast groups are defined for the C-RAN, the initial plurality of multicast groups being implemented by the fronthaul network; The method of claim 14, wherein periodically, updated multicast groups are defined for the C-RAN, and the updated multicast groups are implemented by the fronthaul network.

22. 22. The method of claim 21, wherein each updated plurality of multicast groups is defined based on recent fronthaul traffic flows, recent locations of the user equipment and the remote units used to provide service to the user equipment, or some combination.

23. the locations of the user equipment and the remote units used to provide service to the user equipment; uplink measurements of a Sounding Reference Signal (SRS), a Physical Uplink Control Channel (PUCCH), a Physical Uplink Shared Channel (PUSCH), and / or a Physical Random Access Channel (PRACH) made at each remote unit; Preferred beam information determined by the user equipment; and a channel state information reference signal (CSI-RS) measurement report received from the user equipment.

24. 22. The method of claim 21, wherein at least one of the central unit and the management system defines the initial plurality of multicast groups and each updated plurality of multicast groups, notifies one or more of the management system, the central unit, and the remote units about the defined initial plurality of multicast groups and each updated plurality of multicast groups, and causes the fronthaul network to implement the defined initial plurality of multicast groups and each updated plurality of multicast groups.

25. Management plane (M-plane) communication notifying one or more of the management system, a central unit, and a remote unit of the defined initial plurality of multicast groups and each updated plurality of multicast groups; and causing the fronthaul network to implement the defined initial and each updated multicast group.

26. The method of claim 25, wherein the M-Plane communication comprises O-RAN M-Plane communication.

27. A cloud radio access network (C-RAN), comprising: a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE); a central unit communicatively coupled to the plurality of remote units via a fronthaul network; an entity configured to perform deep packet inspection, the entity being communicatively coupled to the central unit via the fronthaul network; The central unit: determining a set of data to be transmitted across the fronthaul network to a plurality of remote units; determining a mapping of each of the sets of data to at least one of the plurality of remote units; adding a respective indicator to a packet for each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective packet and set of data is intended; and transmitting the packets for the set of data, each having the respective indicator, to the entity via the fronthaul network; and performing deep packet inspection on each of the packets to determine each remote unit for which a packet is intended and to communicate the packet over the fronthaul network to each remote unit for which the packet is intended. A Cloud Radio Access Network (C-RAN) configured as follows:

28. The C-RAN of claim 27, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth generation communication system.

29. The C-RAN of claim 27, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

30. The C-RAN of claim 27, wherein the entity comprises one or more switches in the fronthaul network.

31. The C-RAN of claim 27, wherein the entity includes a Fronthaul Manager (FHM).

32. 28. The C-RAN of claim 27, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of the plurality of said remote units.

33. 1. A method implemented in a Cloud Radio Access Network (C-RAN), comprising a plurality of remote units, each configured to exchange radio frequency signals with at least one user equipment (UE), the C-RAN also comprising: a central unit communicatively coupled to the plurality of remote units via a fronthaul network; and an entity configured to perform deep packet inspection, the entity communicatively coupled to the central unit and the remote units via the fronthaul network, the method comprising: determining a set of data to be transmitted across the fronthaul network to a plurality of remote units; determining a mapping of each of the sets of data to at least one of the plurality of remote units; adding a respective indicator to a packet for each set of data based on the mapping, each respective indicator indicating a respective remote unit for which the respective packet and set of data is intended; transmitting the packets for the set of data, each having the respective indicator, to the entity via the fronthaul network; and performing, by the entity, deep packet inspection on each of the packets to determine each remote unit for which a packet is intended and communicate the packet over the fronthaul network to each remote unit for which the packet is intended.

34. 34. The method of claim 33, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP 5th generation communication system.

35. 34. The method of claim 33, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

36. 34. The method of claim 33, wherein the entity comprises one or more switches in the fronthaul network.

37. 34. The method of claim 33, wherein the entity comprises a fronthaul manager (FHM).

38. 34. The method of claim 33, wherein each respective indicator is a respective bit mask including a plurality of bit positions, each bit position corresponding to a respective one of the plurality of said remote units.

Images