Front-haul interface for use with a cloud radio access network

Abstract

The present disclosure relates to a fronthaul interface for use with a cloud radio access network. A C-RAN includes a plurality of remote units; and a central unit communicatively coupled to the plurality of remote units via a fronthaul network. The central unit is configured to determine a set of data to be transmitted to a respective subset of remote units over the fronthaul network. The central unit is further configured to determine a mapping of each of the set of data to a respective one of the subset of remote units. The central unit is further configured to, for each of the set of data, if at least one of the multicast groups completely contains the respective subset of remote units mapped to that data, transmit that data to the respective subset of remote units over the fronthaul network by multicasting that data to the multicast group that best matches the respective subset of remote units mapped to that data.

Description

[0001] This application is a divisional application of the invention patent application filed on July 1, 2020, with application number 202080056388.0 and titled "Fronthaul Interface for Use with Cloud Radio Access Network".

[0002] Cross-references to related applications

[0003] This application claims priority to the following applications: U.S. Provisional Patent Application No. 62 / 870,025 (Agency No. 100.1874USPR), filed July 2, 2019, entitled “FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK”; U.S. Provisional Patent Application No. 62 / 895,625 (Agency No. 100.1874USP2), filed September 4, 2019, entitled “FRONTHAUL INTERFACE FOR USE WITH A CLOUD RADIO ACCESS NETWORK”; and U.S. Provisional Patent Application No. 62 / 895,625 (Agency No. 100.1874USP2), filed January 2, 2020, entitled “DEEP PACKETINSPECTION IN A FRONTHAUL NETWORK OF A CLOUD RADIO ACCESS NETWORK”. The entire contents of U.S. Provisional Patent Application No. 62 / 956,402 (Agency File No. 100.1884 USPR) concerning “NETWORK” are incorporated herein by reference.

[0004] This application also relates to the following co-pending U.S. patent applications, which are incorporated herein by reference:

[0005] The U.S. Patent Application Serial No. ______________ (Agency Document No. 100.1874US01), entitled "FRONTHAUL INTERFACE FOR USE WITH A CLOUDRADIO ACCESS NETWORK," filed on the same date as this application, is hereby incorporated by reference; and

[0006] The U.S. Patent Application No. ______________ (Agency Document No. 100.1884US01), filed on the same date as this application and entitled “DEEP PACKET INSPECTION IN A FRONTHAUL NETWORK OF A CLOUD RADIO ACCESS NETWORK”, is hereby incorporated by reference. Background Technology

[0007] 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). Within the C-RAN, the centralized unit can communicate with remote units via a fronthaul network (also known as a "fronthaul interface"). It may be desirable to implement a fronthaul network for the C-RAN that incorporates some of the functionalities described herein. Summary of the Invention

[0008] One embodiment relates 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 a dataset to be transmitted to the plurality of remote units via the fronthaul interface. The central unit is further configured to determine a mapping from each of the datasets to at least one of the plurality of remote units. The central unit is further configured to add a corresponding indicator to each dataset based on the mapping, wherein each corresponding indicator indicates each remote unit to which the corresponding dataset points. The central unit is also configured to broadcast the datasets to the plurality of remote units, each dataset having a corresponding indicator.

[0009] Another embodiment relates to a cloud radio access network (C-RAN) comprising a plurality of remote units, each remote unit being 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 of the multicast groups includes a corresponding group of the remote units. The central unit is further configured to: determine a dataset to be transmitted via the fronthaul network to a corresponding subset of the remote units; determine a mapping of each of the datasets to a corresponding one of the subsets of the remote units; and for each of the datasets, if at least one of the multicast groups completely contains a corresponding subset of the remote units mapped to that dataset, transmit the dataset via the fronthaul network to the corresponding subset of the remote units by multicasting the dataset to a multicast group that best matches the corresponding subset of the remote units mapped to that dataset.

[0010] Another embodiment relates to a cloud radio access network (C-RAN) comprising a plurality of remote units, each remote unit being 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 being communicatively coupled to the central unit via the fronthaul network. The central unit is configured to: determine a dataset to be transmitted to the plurality of remote units via the fronthaul network; determine a mapping from each of the datasets to at least one of the plurality of remote units; add a corresponding indicator to a packet of each dataset based on the mapping, wherein each corresponding indicator indicates the corresponding packet and each remote unit to which the dataset points; and transmit the packets of the datasets, each packet of the dataset having a corresponding indicator, to the entity via the fronthaul network. The entity is configured to perform deep packet inspection on each of the packets to determine each remote unit to which the packet points, and transmit the packet to each remote unit to which the packet points via the fronthaul network.

[0011] Another embodiment relates to a cloud radio access network (C-RAN) comprising a plurality of remote units (RUs), each RU 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 fronthaul interface includes at least one Ethernet switch configured to perform deep packet inspection on received packets to determine the presence of an RU identifier in the packets. If the RU identifier is present in the packets, it indicates at least one RU to which the packets are directed. When the RU identifier is present in the packets, the at least one Ethernet switch is also configured to, for each of the at least one RU, transmit at least a portion of the packets to that RU based on a comparison of the RU identifier with at least one bit pattern of the RU. Attached Figure Description

[0012] It should be understood that the accompanying drawings only depict exemplary configurations and therefore should not be considered as a limitation of scope. The exemplary configurations will be described with additional characteristics and details using the accompanying drawings, wherein:

[0013] Figure 1A This is a block diagram illustrating an exemplary configuration of a communication system including 3GPP fourth-generation (4G) components;

[0014] Figure 1B It is a block diagram showing an exemplary configuration of a communication system including 3GPP fifth-generation (5G) components;

[0015] Figure 2This is a block diagram illustrating an exemplary functional division between the RU and the baseband controller (in 4G) or the distributed unit (DU) (in 5G);

[0016] Figure 3 This is a block diagram illustrating an exemplary O-RAN 1.0 fronthaul interface between a DU and multiple RUs;

[0017] Figure 4 This is a block diagram illustrating an exemplary fronthaul interface between a DU and multiple (M)RUs according to the O-RAN shared cell proposal;

[0018] Figure 5 This is a block diagram illustrating an exemplary mapping of different data to different sets of RUs in a C-RAN;

[0019] Figure 6A This is a block diagram illustrating an exemplary downlink broadcast configuration for the fronthaul interface between the DU and multiple (M)RUs;

[0020] Figure 6B This is a block diagram illustrating an exemplary uplink configuration for the fronthaul interface between the DU and multiple (M)RUs;

[0021] Figure 7 This is a flowchart illustrating a method for transmitting data across the fronthaul interface in a C-RAN;

[0022] Figure 8 This is a flowchart illustrating a method for transmitting data across the fronthaul interface in a C-RAN;

[0023] Figure 9A An exemplary C-RAN with a DPI entity (performing deep packet inspection) is shown in a switched network implementing a fronthaul network;

[0024] Figure 9B Another exemplary C-RAN with a DPI entity (performing deep packet inspection) is shown in a switched network implementing a fronthaul network;

[0025] Figure 10 This is a flowchart illustrating a method for transmitting data across the fronthaul interface in a C-RAN;

[0026] Figure 11 This is a flowchart illustrating a method for transmitting data across the fronthaul interface in a C-RAN;

[0027] Figure 12 This is a block diagram illustrating an example of a protocol stack suitable for transmitting I / Q data between each controller and its associated radio unit via a fronthaul network;

[0028] Figure 13AThis is a block diagram illustrating an example of Ethernet packets, Internet Protocol (IP) packets, SwIQ-DAP Protocol Data Units (PDUs), TLV elements, and fields in the SwIQ-DAP header; and

[0029] Figure 13B This is a block diagram showing another example of Ethernet packets, SwIQ-DAP Protocol Data Units (PDUs), TLV elements, and fields in the SwIQ-DAP header;

[0030] Figure 14A This is a block diagram illustrating an exemplary configuration of deep packet inspection in the fronthaul network of a cloud radio access network (C-RAN) system;

[0031] Figure 14B This is a block diagram showing additional details of an example of implementing a C-RAN fronthaul network using a switched Ethernet network;

[0032] Figure 15 It is a block diagram of a wireless system with multiple RUs and UEs;

[0033] Figure 16 This is a flowchart illustrating a method for transmitting data across the fronthaul interface and fronthaul network in a C-RAN using deep packet inspection (DPI);

[0034] Figure 17 This is a flowchart illustrating a method for performing deep grouping inspection (DPI) on groups; and

[0035] Figure 18 This is a flowchart illustrating a method for establishing multicast rules in an Ethernet switch.

[0036] According to conventional practice, the various features described are not drawn to scale, but rather drawn to emphasize specific features relevant to the exemplary configuration. Detailed Implementation

[0037] Cloud Radio Access Network (C-RAN) is one method for implementing distributed RAN. Typically, for each cell implemented by C-RAN, one or more controllers (also known as "baseband controllers," "central units," or "distributed units") interact with multiple remote units (RUs) to provide radio services to individual user equipment (UEs). In C-RAN, an RU can communicate with at least one controller via a fronthaul interface. The fronthaul interface can utilize at least one computing device (e.g., a switch) that facilitates communication between the RU and a DU (in 5G) or a baseband controller (in 4G). For example, the fronthaul interface can be implemented using at least one Ethernet switch and / or router. Alternatively, different physical links, such as copper, multi-rate, multimode cables, etc., can be used to implement the fronthaul interface.

[0038] Frequency reuse involves using the same frequency resources for multiple sets of UEs, each set of UEs located under a geographically diverse set of RUs. This can include the same RU frequency resources used for transmission to different UEs. In the downlink, multiple reuse layers of at least one RU can each transmit simultaneously to different UEs at the same frequency (wherein, each RU in a reuse layer is fully RF isolated from each RU in other reuse layers). In the uplink, each of the multiple UEs can simultaneously transmit at the same frequency to different reuse layers of at least one RU (wherein, each RU in a reuse layer is fully RF isolated from each RU in other reuse layers).

[0039] 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 on which downlink in-phase, quadrature-phase (I / Q) packets are sent, and all RUs are registered to the same set of multicast IP addresses. Therefore, when reuse is employed, packets from all reused layers reach all RUs. Thus, if 4X reuse exists in the DL, then 4X times the number of packets reach each RU, even if the packet of interest for a given RU is 1X or less. However, it may be desirable to send different datasets to different RUs in the C-RAN (to be sent to the UE). Several possible solutions exist to accomplish this customized downlink traffic transmission.

[0040] In the first possible solution, the initiator (e.g., the controller in a C-RAN) can replicate packets and send them only to interested RUs via unicast. This places a processing load on the controller.

[0041] In a second possible solution, the controller in the C-RAN can add an indicator (e.g., a bitmask) to its broadcast data, where the bitmask indicates the remote unit to which the data is directed.

[0042] In a third possible solution, each subset of RUs forming a transport group can also form an independent multicast group, after which the initiator sends data to the multicast group containing only the required RUs.

[0043] In a fourth possible solution, the fronthaul network / interface (e.g., within a switch) only forwards traffic of interest to the RU in a given port. The inspection / analysis of packet traffic (e.g., within the 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 of a bitmask in the packet and / or the bits set therein.

[0044] The Open Radio Networks (O-RAN) Alliance's fronthaul working group is seeking to standardize the way data is transmitted on the fronthaul interface of a radio access network. In some configurations, the fronthaul interface described herein may conform to the O-RAN 1.0 interface in 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.

[0045] Example 4G C-RAN

[0046] Figure 1A This is a block diagram illustrating an exemplary configuration of a communication system 100A including 3GPP fourth-generation (4G) components. In the exemplary configuration shown in Figure 1, system 100A is implemented using a cloud radio access network (C-RAN) (point-to-multipoint distributed base station) architecture, which employs at least one baseband unit 104 and one or more remote units (RUs) 106A-M serving at least one cell.

[0047] RU 106 can be deployed at location 102 to provide wireless coverage and capacity for one or more wireless network operators. Location 102 can be, for example, a building or campus, or other combination of buildings (e.g., used by one or more businesses, governments, or other business entities), or some other public place (e.g., a hotel, resort, amusement park, hospital, shopping mall, airport, university campus, arena, or outdoor area such as a ski resort, stadium, or densely populated downtown area). In some configurations, location 102 is at least partially (and optionally entirely) indoors, but other alternatives are possible.

[0048] System 100A may also be referred to herein as “C-RAN” or “C-RAN system”. Baseband unit 104 may also be referred to herein as “baseband controller” 104, “CU” 104, or simply “controller” 104. Each RU 106 may include or be coupled to at least one antenna for radiating downlink RF signals to user equipment (UE) 110 and receiving uplink RF signals transmitted by UE 110. Baseband controller 104 may optionally be located physically away from location 102, for example, in a centralized group of baseband controllers 104. Additionally, RUs 106 may be physically separated from each other within location 102, although they are each communicatively coupled to baseband controller 104 via fronthaul network 116.

[0049] Each UE 110 may be a computing device having at least one processor that executes instructions stored in memory, such as a mobile phone, tablet computer, mobile media device, mobile gaming device, laptop computer, vehicle-based computer, 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 memory. Furthermore, each RU 106 may implement one or more instances (e.g., modules) of the radio unit 106.

[0050] C-RAN 100A can optionally enable frequency reuse, where the same frequency resources are used for multiple UE 110 sets, each of which is under a different geographic diversity RU 106 set.

[0051] System 100A is coupled to the core network 112 of each wireless network operator via a suitable backhaul network 114. For example, the Internet can be used for backhaul between System 100A and each core network 112. However, it should be understood that the backhaul network 114 can be implemented in other ways. Each of the backhaul network 114 and / or fronthaul network 116 described herein can be implemented using one or more switches, routers, and / or other network devices; for example, the backhaul network 114 and / or fronthaul network 116 can be implemented using a switched Ethernet network.

[0052] System 100A enables a Long Term Evolution (LTE) radio access network that provides radio services using the LTE air interface. LTE is a standard developed by the 3GPP standards organization. In this configuration, baseband controller 104 and RU 106 work together to implement an LTE Evolution Node B (also referred to herein as an "eNodeB" or "eNB"). The eNB can be used to provide UE 110 with mobile access to the core network 112 of the wireless network operator, enabling UE 110 to wirelessly transmit data and voice (e.g., using LTE Voice (VoLTE) technology). However, it should be noted that this system and method can be used with other wireless protocols; for example, System 100A can enable a 3GPP 5G RAN that provides radio services using a 5G air interface.

[0053] Furthermore, in the exemplary LTE configuration, each core network 112 can be implemented as an evolved packet core (EPC) 112 comprising standard LTE EPC network elements, such as 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).

[0054] Furthermore, in the exemplary LTE configuration, each baseband controller 104 can communicate with the MME and SGW in the EPC core network 112 using the LTE S1 interface and with the eNB using the LTE X2 interface. For example, the baseband controller 104 can communicate with an outdoor macro eNB (not shown) via the LTE X2 interface.

[0055] Each baseband controller 104 and remote unit 106 can be implemented using an air interface supporting one or more of Frequency Division Multiplexing (FDD) and / or Time Division Multiplexing (TDD). Additionally, the baseband controller 104 and remote unit 106 can be implemented using an air interface supporting 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 can implement one or more of LTE transmission modes. Furthermore, the baseband controller 104 and remote unit 106 can be configured to support multiple air interfaces and / or multiple radio operators.

[0056] In some configurations, in-phase and quadrature-phase (I / Q) data representing preprocessed baseband symbols of the air interface is transmitted between the baseband controller 104 and the RU 106. Transmitting this type of baseband I / Q data typically requires a relatively high data rate fronthaul.

[0057] In some configurations, the baseband signal can be preprocessed at the source RU 106 and converted into a frequency domain signal (after removing guard band / cyclic prefix data, etc.) before being sent to the baseband controller 104, in order to efficiently manage the fronthaul rate. The RU 106 can further reduce the data rate by quantizing such frequency domain signals and reducing the number of bits used to carry such signals and transmit data. In a further simplification, some symbol data / channel data can be fully processed within the source RU 106 itself, and only the resulting information is passed to the baseband controller 104.

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

[0059] If the fronthaul Ethernet network 116 cannot achieve the data rate required for fronthaul (uncompressed) I / Q data, the I / Q data can be compressed before being transmitted through the Ethernet network 116, thereby reducing the data rate required to transmit such I / Q data through the Ethernet network 116.

[0060] Data can be forwarded between the baseband controller 104 and the RU 106 in other ways (e.g., using the Common Public Radio Interface (CPRI) and / or the fronthaul interfaces and technologies specified in the Open Base Station Architecture Plan (OBSAI) series of specifications). Therefore, the baseband controller 104 described herein can resemble an O-RAN Distributed Unit (O-DU) and / or perform at least some of the functions of that O-RAN Distributed Unit.

[0061] Additionally, it should be noted that this system and method can also be used in other distributed RANs (other than C-RAN 100A), such as distributed antenna systems (DAS).

[0062] Figure 9AAn exemplary C-RAN 100A with a DPI entity 109 (performing deep packet inspection) in a switched network 120 implementing a fronthaul network 116 is shown. A management system 107 may be communicatively coupled to a baseband controller 104 and an RU 106, for example, via a backhaul network 114 and / or a fronthaul network 116. A hierarchical architecture can 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 in turn forwards relevant M-plane communications to and from the RU 106 as needed. A direct architecture can also be used for M-plane communications. When using a direct architecture, the management system 107 can communicate directly with the RU 106 (without the controller 104 forwarding M-plane communications). A hybrid architecture can also be used, in which some M-plane communications are transmitted using a hierarchical architecture and some are transmitted using a direct architecture. Proprietary protocols and interfaces may be used for such M-plane communications. In addition, protocols and interfaces specified by standards such as O-RAN can be used for this type of M-plane communication.

[0063] Exemplary 5G C-RAN

[0064] Figure 1B This is a block diagram illustrating an exemplary configuration of a system 100B including 3GPP fifth-generation (5G) components. Optionally, the system 100B may additionally include 4G components. Each component can be implemented using at least one processor that executes instructions stored in at least one memory. In some configurations, at least some components are implemented using virtual machines.

[0065] The fifth-generation (5G) standard supports a wide range of applications, bandwidths, and latency, as well as various implementation options. In System 100, interfaces denoted by "-c" or simply "c" (shown as dashed lines) provide control plane connectivity, while interfaces denoted by "-u" or simply "u" (shown as solid lines) provide user plane connectivity. Figure 1B Further details on the various devices and interfaces can be found in 3GPP TR 38.801 Radio Access Architecture and Interfaces, version 14 (available at https: / / portal.3gpp.org / desktopmodules / Specifications / SpecificationDetails.aspx?specificationId=3056), which is incorporated herein by reference.

[0066] Figure 1BA C-RAN 100B is shown as an example of implementing a 5G next-generation NodeB (gNB). The architecture of the next-generation NodeB (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 a node that includes gNB controller functions (e.g., user data delivery, mobility control, radio access network sharing, location, session management, etc.). The 5G CU 103 controls the operation of the Distributed Units (DUs) 105A-B through interfaces (including F1-c and F1-u for the control plane and user plane, respectively).

[0067] Based on the functional partitioning (between CU 103 and DU 105), the Distributed Unit (DU) 105 can be a node implementing a subset of gNB functions. In some configurations, L3 processing (of the 5G air interface) can be implemented in CU 103, and L2 processing (of the 5G air interface) can be implemented in DU 105. The operation of each DU 105 is controlled by CU 103. The functions of DU 105 may include portions of Radio Link Control (RLC), Media Access Control (MAC), and / or Physical (PHY) layer functions. The Distributed Unit (DU) 105 may optionally offload some of its PHY (L1) processing (of the 5G air interface) to RU 106.

[0068] exist Figure 1B In the example, the C-RAN 100B implementing an exemplary next-generation NodeB (gNB) includes a single CU 103 that handles control plane functions and user plane functions. The 5G CU 103 (in the C-RAN 100B) can communicate with the next-generation core (NGC) 112 of at least one radio service provider using 5G NGc and 5G NGu interfaces. In some 5G configurations (not shown), the 5G CU is split between the CU-C 103B that handles control plane functions and the CU-U 103C that handles user plane functions.

[0069] In some 5G configurations, the RU (RU)106N-O can transmit baseband signal data to the DU105 via the NG-iq interface. In some 5G configurations, the RU 106 can implement at least some of L1 and / or L2 processing. In some configurations, the RU106 can have multiple Ethernet ports and can communicate with multiple switches.

[0070] Figure 1BAny interface can be implemented using a switched Ethernet (or fiber optic) network. Additionally, if multiple CU 103s (not shown) exist, they can communicate with each other using any suitable interface, such as Xn (Xn-c and Xn-u) and / or X2 interfaces. The fronthaul interface can facilitate... Figure 1B Any one of the NG-iq, F1-c, and / or F1-u interfaces.

[0071] Figure 9B An exemplary C-RAN 100B with DPI entity 109 (performing deep packet inspection) in a switched network 120 implementing fronthaul network 116 is shown. Management system 107 can be communicatively coupled to CU 103, DU 105, and RU 106, for example, via backhaul network 114 and / or fronthaul network 116. A hierarchical architecture can be used for M-plane communication. When using a hierarchical architecture, management system 107 can send and receive management communications to and from CU 103, which in turn forwards relevant M-plane communications to and from DU 105, which in turn forwards relevant communications to and from RU 106 as needed. A direct architecture can also be used for M-plane communication. When using a direct architecture, management system 107 can communicate directly with CU 103, DU 105, and RU 106 (without requiring forwarding of M-plane communications from CU 103 to and from DU 105, and without requiring forwarding of M-plane communications from DU 103 to and from RU 106). Hybrid architectures can also be used, where some M-plane communications are transmitted using a layered architecture, while others are transmitted using a direct architecture. Proprietary protocols and interfaces can be used for such M-plane communications. Additionally, protocols and interfaces specified by standards such as O-RAN can be used for such M-plane communications.

[0072] Functional division between RU and DU

[0073] Figure 2 This is a block diagram illustrating an exemplary functional division between RU 106 and either the baseband controller 104 (in 4G) or the distributed unit (DU) 105 (in 5G). A combination of DU 105 (or the baseband controller 104 in 5G) and RU 106 performs analog radio frequency (RF) functions of the air interface, as well as digital layer 1 (L1), layer 2 (L2), and layer 3 (L3) functions of the air interface (as defined in the 3GPP LTE Radio Access Interface Protocol).

[0074] Various options for feature splitting Figure 2As shown, the function to the left of the vertical arrow for a given option is implemented at DU 105 in 5G (or baseband controller 104 in 4G), while the function to the right of the vertical arrow is implemented at RU 106. In a 5G configuration, the function to the left of the vertical arrow for a given option can be implemented in some combination of one or more DU 105 and CU 103. Figure 2 The upper half shows the division between the first RU 106 and DU 105 (or baseband controller 104), while Figure 2 The lower half shows the division between the second RU 106 and DU 105 (or baseband controller 104).

[0075] In Option 1, the Radio Resource Control (RRC) 204A-B portion of the L3 processing is executed at DU 105 (or baseband controller 104), while the Packet Data Convergence Protocol (PDCP) 206A-B portion of the L3 processing (along with all analog RF 220A-B, L1, and L2 processing) is executed at RU 106. In Option 2, the RRC 204 and PDCP 206 portions of L3 are executed at DU 105 (or baseband controller 104), while all analog RF, L1, and L2 functions are executed at RU 106. In Option 3, the high radio link control (RLC) portion 208A of L3 (RRC 204 and PDCP 206 sections) and L2 processing is performed at DU 105 (or baseband controller 104), while the remaining L2 processing (low RLC 210A-B, high MAC 212A-B, low MAC 214A-B), as well as L1 and analog RF 220 processing, is performed at RU 106. In Option 4, the L3 (RRC 204 and PDCP 206 sections), the high RLC 208 and low RLC 210 sections of L2 processing are performed at DU 105 (or baseband controller 104), while the remaining high MAC 212 and low MAC 214A-B sections of L2 processing, as well as L1 and analog RF 220 processing, are performed at RU 106.

[0076] In Option 5, L3 (RRC 204 and PDCP 206 portions), the high RLC 208 portion, the low RLC 210 portion, and the high MAC 212 portion of L2 processing are executed at DU 105 (or baseband controller 104), while the remaining low MAC 214A-B portions of L2 processing, as well as L1 and analog RF 220 processing, are executed at RU 106. In Option 6, L3 (RRC 204 and PDCP 206 portions) and L2 processing (high RLC 208 portion, low RLC 210 portion, high MAC 212 portion, and low MAC 214 portion) are all executed at DU 105 (or baseband controller 104), while L1 processing (high physical layer (PHY) 216A-B and low PHY 218A-B portions) and analog RF 220 processing are executed at RU 106. In some configurations, Option 6 splitting can produce extremely low data rates and high latency margins between (one or more) RU 106 and baseband controller 104.

[0077] In option 7, the high PHY 216 portions of L3 processing, L2 processing, and L1 processing are all executed at DU 105 (or baseband controller 104), while the low PHY 218A-B portions of L1 processing (and analog RF 220 processing) are executed at RU 106.

[0078] In option 8, L3, L2, and L1 processing (high PHY 216 section and low PHY 218 section) are all performed at DU 105 (or baseband controller 104), while analog RF 220 processing is performed at RU 106.

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

[0080] O-RAN interface

[0081] Figure 3 This is a block diagram illustrating an exemplary O-RAN 1.0 fronthaul interface between DU 105 and multiple (M) RUs 106. DU 105 can be communicatively coupled to RU 106 via a switched network 120. Although not shown, DU 105 can also be communicatively coupled to a 5G CU 103 (in 5G). Furthermore, in a 4G configuration, DU 105 can alternatively be a baseband controller 104.

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

[0083] However, 3GPP has not yet standardized the way data is transferred between DU 105 and RU 106. The Open Radio Networking (O-RAN) Alliance has standardized the actual interface between DU 105 and RU 106, i.e., how data is packetized and transmitted. The O-RAN 1.0 standard (using 7.2x segmentation) technically supports single DU to multiple RU mapping, but each configured DU-RU link is addressed and managed independently. Therefore, Figure 3 The O-RAN 1.0 configuration in the example effectively implements multiple one-to-one links, where DU 105 sends M copies of the same packet stream. This results in inefficient use of bandwidth across the fronthaul interface (between DU 105 and RU). Specifically, if each of the M RUs 106 transmits N PRBs, the uplink bandwidth from the switched network 120 to DU 105 will be approximately N PRBs x M RUs x α. Alpha(α) represents a fraction (less than 1) that indicates the traffic can be less than the full multiple shown, for example, less than the maximum number of N PRBs due to pruning, i.e., some PRBs are not sent from RU 106 to DU 105.

[0084] exist Figure 3 In the O-RAN 1.0 configuration, the downlink bandwidth from DU 105 to the switched network 120 is approximately NPRB x M RU 106. The uplink or downlink bandwidth between the switched network 120 and each RU 106 is approximately N PRB. Therefore, Figure 3 The exemplary O-RAN fronthaul interface in the example represents an inefficient use of bandwidth on the link between DU 105 and the switched network 120.

[0085] In O-RAN 1.0, data delivery is scheduled and managed on a per-symbol basis, where the entire PDSCH resource element (RE) grid is delivered sequentially.

[0086] Figure 4This is a block diagram illustrating an exemplary fronthaul interface between a DU 105 and multiple (M) RUs according to the O-RAN shared cell proposal. The DU can be communicatively coupled to an RU 106 via a fronthaul manager (FHM) 122. Although not shown, the DU 105 can 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 can alternatively be a baseband controller 104.

[0087] (Compared to O-RAN 1.0) The O-RAN shared cell proposal attempts to utilize the bandwidth to and from DU 105 more efficiently. Specifically, the shared cell proposal includes a fronthaul manager (FHM) 122 to more efficiently support single-DU to multiple-RU mapping. To this end, the fronthaul manager 122: (1) replicates the downlink packet flow (from DU 105) for each RU 106; and (2) performs a combination / digital summation on the uplink packet flow from RU 106 (before sending to DU 105). The combination / digital summation includes: (1) summing corresponding in-phase (I) samples from the corresponding PRBs (from all RU 106); (2) summing corresponding quadrature-phase (Q) samples from the corresponding PRBs (from all RU 106); and (3) sending the combined I / Q data flow from the fronthaul manager 122 to DU 105. The combination / 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 per RU 106, for a total bandwidth of approximately N PRBs x M RUs). By reducing the data transmitted and received by the DU 105 to a single stream of N PRBs, Figure 4 The shared community proposal and Figure 3 Compared to the O-RAN 1.0 implementation, the bandwidth (between DU 105 and FHM) will be reduced.

[0088] However,( Figure 3 The O-RAN 1.0 implementation method and ( Figure 4 The shared cell proposals in all cases assume that all downlink transmissions from all RU 106 are identical, as in a distributed antenna system (DAS). In other words, ( Figure 3 The O-RAN 1.0 implementation method and ( Figure 4 The shared cell proposal in the C-RAN 100 does not distinguish between different traffic flows of different RU 106, which is problematic in C-RAN 100, as described below.

[0089] C-RAN fronthaul interface requirements

[0090] Figure 5This is a block diagram illustrating exemplary mappings of different data to different RU 106A-H sets in C-RAN 100. Specifically, Figure 5 The mapping from different PRB groups and reuse layers to different RU 106 is shown. Figure 5 For the C-RAN 100, there are 8 different RU106; however, the C-RAN 100 can have more than 8 RU 106.

[0091] For any of the following reasons, it is desirable to send different data to different RUs 106 in C-RAN 100: (1) if the entire PRB set (e.g., 100) is divided and grouped into two different PRB groups to which RU 106 is assigned (e.g., Figure 5 (1) PRB groups 1 and 2 in the frequency reuse; (2) in frequency reuse, samples transmitted from different RU 106 sets (on the downlink) or to different RU 106 sets (on the uplink) need to be kept separate; and / or (3) different channels require different types of processing, such as narrowcast, unicast, broadcast.

[0092] Regarding reason 1, all PRB packets are created by the scheduler (DU 105 or CU in 5G or L2 processing in baseband controller 104 in 4G) to serve the set of UEs 110. Based on the needs of UE 110 and considering fairness and other factors, a certain number of PRB groups are allocated to this UE. Based on the proximity of UE 110 to RU 106, the set of RU 106 is assigned to different such PRB groups. The scheduler can obtain this knowledge through uplink measurements, UE 110 feedback information, etc. If PRB groups are used, a particular RU 106 can only be used for packets belonging to its PRB group. Figure 5 This is shown for two PRB groups, but more PRB groups can be used.

[0093] Regarding reason 2, all reuse layers are created by the scheduler (in DU 105 or CU in 5G or L2 processing in baseband controller 104 in 4G) to serve the set of UEs 110, for example, based on an understanding of the proximity of UE 110 and RU 106 according to uplink measurements, UE 110 feedback information, etc. In downlink frequency reuse, multiple reuse layers of at least one RU 106 can each transmit simultaneously to different UEs 110 at the same frequency (wherein, each RU 106 in the reuse layer is fully RF isolated from each RU 106 in other reuse layers). In the uplink, each of multiple UEs 110 can simultaneously transmit to different reuse layers of at least one RU 106 at the same frequency (wherein, each RU 106 in the reuse layer is fully RF isolated from each RU 106 in other reuse layers). For simplicity, Figure 5 It is shown as having a reuse factor of 2 (where two different sets of RU106 communicate with two different UE 110 on the same time and frequency resources), but can utilize a higher reuse factor.

[0094] For example, when considering PRB groups and reuse layers, the data can be mapped as follows: (1) RU1106A to RU3 106C are assigned to PRB group 1 / reuse layer 1 502; (2) RU4 106D to RU8 106H are assigned to PRB group 1 / reuse layer 2 504; (3) RU1106A to RU5 106E are assigned to PRB group 2 / reuse layer 1 506; and (4) RU6 106F to RU8 106H are assigned to PRB group 2 / reuse layer 2 508.

[0095] Regarding reason 3, the following transmission types can be used: (1) narrowcasting different datasets to different RU 106s for certain 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), etc.); (2) broadcasting common channels and reference signals (e.g., Physical Broadcast Channel (PBCH) and PDCCH (for 4G and optional 5G), etc.) to all RU 106s; and (3) unicasting or narrowcasting certain channels or reference signals (e.g., Channel State Information Reference Signal (CSI-RS) Group 1 510 or CSI-RS Group 2 512, etc.). Unlike the shared cell model, it is expected that different datasets will be transmitted to different sets of RU 106s served by the same DU105 based on the channel or signal being processed. For example, RU1 106A was assigned to CSI-RS group 1 510, while RU2 106B and RU3 106C were assigned to CSI-RS group 2 512.

[0096] use( Figure 3 The exemplary O-RAN 1.0 implementation in ( ) sends different data to different RU 106, which is inefficient because it only involves copying I / Q data to all RU 106 in the packet. Additionally, using ( Figure 4 The shared cell proposal requires the use of a new entity (FHM) that is not readily available. Therefore, this system and method can be used to modify the O-RAN 1.0 interface to selectively send different data (c-plane and / or u-plane) to and from different subsets of RU 106.

[0097] Fronthaul interface used with C-RAN

[0098] Figure 6AThis is a block diagram illustrating an exemplary downlink broadcast configuration for the fronthaul interface between DU 105 and multiple (M) RU 106. Specifically, Figure 6A The downlink "broadcast" configuration is shown, as DU 105 broadcasts all data to all RU 106, and each RU 106 filters the data to determine which data is directed to it (RU 106 typically does not broadcast all data it receives over the air). Figure 6A In this configuration, DU 105 can be communicatively coupled to RU 106 via switched network 120. Although not shown, DU 105 can also be communicatively coupled to ng-eNB CU (not shown) or (in 5G) gNB CU 103. Furthermore, in a 4G configuration, DU 105 can alternatively be a baseband controller 104.

[0099] As described above, it is desirable to be able to send different datasets to different RUs 106 in C-RAN 100. Therefore, additional data can be added to the control plane (C plane) data and user plane (U plane) data (sent from DU 105 to RU106) to indicate which RU(s)(s) the C plane and / or U plane data are directed to.

[0100] In some configurations, the additional data can be a bitmask, such as RUid bitmasks 602A-Z. Each RUid bitmask 602 can be a set of bits (e.g., each with a value "1" or "0"), with a length at least equal to the number of RUs 106 in a single sector that are communicatively coupled to (e.g., served by) a DU 105. The length of the RUid bitmask 602 can be configured during the initial configuration of the C-RAN 100 and / or reconfigured after the initial configuration. During the initial configuration (or during reconfiguration), each bit in the RUid bitmask 602 is associated with a specific RU 106, i.e., each bit position is mapped to a specific RU 106. In some examples, the RUid bitmask 602 can be reduced to a length of zero, corresponding to O-RAN 1.0, thus making the RUid bitmask 602 backward compatible. In other words, the DU 105, which supports the enhanced fronthaul interface mode described herein, which allows sending different datasets to different RU 106s using additional data (i.e., RUid bitmasks), can also be configured to operate in the backward-compatible O-RAN 1.0 fronthaul interface mode by reducing the length of the RUid bitmask to zero. Furthermore, it should be understood that the additional data can take any form suitable for indicating which RU(s) 106(s) a C-plane or U-plane dataset is directed to.

[0101] A unique identifier (“RUid”) can be assigned to each RU 106 serving a given sector. For example, a RUid can be assigned to each RU 106 serving a given sector, where the RUid is an integer between 0 and the number of RUs serving that sector (“nRU”) minus 1 (i.e., 0 to nRU-1). Furthermore, a specific bit position within a RUid bitmask 602 is assigned to each RU 106 serving a given sector. This bit position within the RUid bitmask 602 is also referred to herein as the “RU index”. If a RUid is assigned to each RU 106, the RU index can be determined based on the RUid. For example, in the case of assigning a RUid (which is an integer between 0 and nRU-1) to each RU 106 serving a sector, the bit positions in the RUid bitmask 602 can be numbered (indexed) from 0 to nRU-1. The RU index assigned to each RU 106 serving a sector can be a bit position number (index) corresponding to the RUid assigned to that RU 106. In other words, the RU index is equal to the RUid assigned to that RU 106. For example, if RUid 6 is assigned to RU 106, then the RU index assigned to that RU 106 is 6. However, it should be understood that the RU index does not need to be determined based on the RUid assigned to each RU 106. Moreover, it should be understood that the use of RUid is optional (i.e., in some embodiments, a corresponding RU index is assigned to each RU 106 serving a sector, but no separate RUid is assigned to each RU 106).

[0102] The management system 107 can use O-RAN M-plane communication to configure (or reconfigure) the C-RAN to use the enhanced fronthaul interface mode (including the allocation of RUids (if used) and RU indexes) for a given sector. The management system 107 can determine the RUid allocation (if used) and RU index allocation, and then communicate these allocations, along with other information specifying how the enhanced fronthaul interface mode should be configured, to the relevant CU 103, DU 105, and RU 106. The management system 107 can also use O-RAN M-plane communication to synchronize when CU 103, DU 105, and RU 106 should begin operation in the enhanced fronthaul interface mode using the new configuration. For example, the management system 107 can use O-RAN M-plane communication to specify a specific point in time when operation should begin in the enhanced fronthaul interface mode using the new configuration.

[0103] In some configurations, DU 105 transmits C-plane data in packets of at least one group referred to as C-segment 604A-P, and DU 105 transmits U-plane data in packets of at least one group referred to as U-segment 606A-P. In these configurations, a RUid bitmask 602 may be included within each C-segment 604 and U-segment 606. Alternatively, additional data (e.g., the RUid bitmask 602) may be associated with the C-plane data and U-plane data in other ways, such as by appending. Each C-segment 604 and U-segment 606 may include control and I / Q data, respectively.

[0104] In a simplified example, for each RU 106 served by DU 105, there is one bit in each RUid bitmask 602, with each bit position corresponding to a specific RU 106. When any specific bit in the RUid bitmask 602 is set (e.g., set to "1"), it indicates that the grouping of packets transmitted in the associated segment is intended to be received by the specific RU 106 corresponding to the set bit. More than one bit (each bit corresponding to a different RU 106) or all bits can be set in the RUid bitmask 602. All packets (e.g., via Ethernet) are broadcast from DU 105 to all RU 106, and each RU 106 can identify whether the grouping of packets is intended for it without decoding all segments (by determining whether the bit in the RUid bitmask 602 corresponding to the respective RU 106 is set). In other words, each RU106 filters packets whose addresses do not point to it based on the RUid bitmask 602 sent (or otherwise associated) in the associated segment / packet. Furthermore, data for all (or many) RU 106 is still sent only once via the initial access link, for example, from DU 105 to the switched network 120.

[0105] Figure 6A The exemplary downlink broadcast configuration allows the DU 105 (e.g., via Ethernet) to broadcast a single stream to all RU 106, but enables the customization of different data for different RU 106, as each RU 106 can filter the received data to determine whether it needs to decode segments. This is relative to ( Figure 4The shared cell proposal has an additional advantage because it eliminates the need for FHM 122 to replicate on the downlink or perform combination / digital summation on the uplink. For example, off-the-shelf devices such as switches, routers, and / or other network equipment can be used to implement the switched network 120. In a downlink broadcast configuration, the bandwidth utilized from DU 105 to the switched network 120 can be approximately N PRB x α, while the bandwidth utilized from the switched network 120 to each RU 106 can be approximately N PRB x α.

[0106] Two possible modifications can be made to the exemplary downlink broadcast configuration. In the first modification, multicast capabilities (e.g., Ethernet or IP multicast capabilities) provided by the switches (or other network devices) in the switched network 120 are used to transmit fronthaul data.

[0107] For example, such multicast modifications can be used for downlink fronthaul data. Various multicast groups can be defined, each containing a different subset of RU 106 serving a given sector. Each RU 106 can (and typically will) be included in more than one multicast group. The relevant switches (or other network devices) in the switched network 120 are configured to implement the defined multicast groups.

[0108] When downlink fronthaul data (e.g., C-plane or U-plane data) needs to be transmitted from the relevant central unit (i.e., controller 104 or DU 105) to a specific subset of RUs 106, the central unit checks whether a multicast group "matches" that subset exists. In one implementation, if a multicast group includes all RUs 106 in the subset of RUs 106 (even if the multicast group may include other "additional" RUs 106 that are not in the subset of RUs 106 to which the downlink fronthaul data is to be sent via fronthaul), then the multicast group "matches" that specific subset of RUs 106. If more than one matching multicast group exists, the matching multicast group that is the "best match" for the subset of RUs 106 is determined. A matching multicast group that includes the minimum total number of RUs 106 can be considered the best match for the subset of RUs 106. If multiple matching multicast groups that include the minimum number of RUs 106 exist, one of these multiple matching multicast groups can be selected (e.g., randomly or using some other process).

[0109] If a matching multicast group exists, the relevant 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 delivered. When using multicast transmission, only a single version of the downlink fronthaul data is transmitted via the border Ethernet link used to couple the relevant central unit to the switched network 120. The 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 RUs 106 included in the multicast group. Any RU 106 that is not a member of the multicast group will not receive downlink fronthaul data transmitted to that multicast group. Therefore, RUs 106 that are not members of the multicast group will not receive downlink fronthaul data that is not directed to them, which saves bandwidth on the border Ethernet link terminating at these RUs 106.

[0110] When multicast is used in this manner, the RUid bitmask can also be included in the multicast fronthaul data (although in some other examples, the RUid bitmask is not included in the multicast fronthaul data). Since the number of multicast groups that can be used in the switched network 120 is typically limited, a suitable “matching” multicast group may not exist. In this case, the relevant central unit (i.e., controller 104 or DU 105) can use the broadcast transmission of the downlink fronthaul data as described above, and RU 106 can use the RUid bitmask and RU index to determine whether they should process the received downlink fronthaul data. Furthermore, a “matching” multicast group may include some “extra” RU 106 that the fronthaul data does not point to. In this case, the central unit can use multicast transmission to transmit the downlink fronthaul data to the matching multicast group. Therefore, the downlink fronthaul data will be received at these extra RU 106 that the fronthaul data does not point to. Even though some additional RU106s may receive fronthaul data not directed to them when fronthaul data is multicast over the fronthaul network, multicast will still result in fewer RU106s receiving fronthaul data not directed to them (and will still result in fewer RU106s having their Ethernet link provisioning affected) compared to if the fronthaul data were broadcast over the fronthaul network. RU106s in a multicast group can use the RUid bitmask and RU index to determine whether they should process the received downlink fronthaul data. Additional RU106s in a matching multicast group whose fronthaul data is not directed to will not process the received downlink fronthaul data based on the determination that their RU index does not match the RUid bitmask included in the received downlink fronthaul data.

[0111] An initial set of multicast groups can be defined for the switched network 120, where each multicast group contains a distinct subset of RUs 106, and where each RU 106 can (and typically will) be included in more than one multicast group. The set of multicast groups used in the switched network 120 can then be periodically added (if the switched network 120 can accommodate additional multicast groups) or changed to reflect actual fronthaul traffic flow and / or the actual locations of the UEs and the RUs 106 serving them. In combination, the set of multicast groups used in the switched network 120 can be changed by removing the least used multicast groups and replacing them with multicast groups more likely to be used based on the most recent fronthaul traffic flow and / or the most recent locations of the UEs and the RUs 106 serving them. The location of the UE and the RU 106 serving it can be determined in various ways, such as using the preferred beam information determined by the UE using the sounding reference signal (SRS), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), and physical random access channel (PRACH) measurements in the uplink at each RU 106, the channel state information reference signal (CSI-RS) measurement report received from the UE. The definition of multicast groups and the configuration of switches can be accomplished by the entity implementing the scheduler for the air interface (e.g., controller 104 or DU 105), by the management system 107, or by a combination of the entity implementing the scheduler and the management system 107, or 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., notifying the management system 107, relevant central units, and RU 106 of the update set of a multicast group, configuring switches in the switched network 120 to implement the update set of the multicast group, and any communication required to indicate to the management system 107, relevant central units, and RU 106 when to start using the update set of the multicast group). Any of the above-described M-plane communication architectures (layered, direct, or hybrid) can be used for such M-plane communication.

[0112] In the second modification, in the switched network 120 used to implement the fronthaul network 116, or in one or more entities 109 coupled to the switched network (one of which is in Figure 9A and 9B (shown in the diagram) is configured to perform Deep Group Inspection (DPI). Each such entity 109 is generally also referred to as a “DPI entity” 109. In this DPI configuration, each DPI entity 109 can (1) analyze C-plane data (e.g., C-segment 604) and U-plane data (e.g., U-segment 606) for all remote units 106 using RUid bitmask 602; and (2) selectively send only data directed to each RU 106. In other words, the relevant central unit (i.e., Figure 9A The baseband controller 104 in the example shown Figure 9B In the example shown, DU105 still sends C-plane data (e.g., C-segment 604) and U-plane data (e.g., U-segment 606) for all RUs 106 to the switched network 120, but each DPI entity 109 performs filtering (using a bitmask) and forwards each segment only to the RU 106 indicated in the segment's bitmask. Each segment is not forwarded to any RU 106 not indicated in the segment's bitmask (i.e., each segment is not forwarded to any RU 106 that the segment does not point to), saving bandwidth on boundary Ethernet links terminating at these RUs 106. The DPI method typically involves far less administrative overhead than the multicast group method typically requires (e.g., the DPI method does not require defining multicast groups, or configuring switches to use defined multicast groups, whether initially or periodically thereafter).

[0113] Each DPI entity 109 can be implemented as part of an Ethernet switch by embedding DPI functionality. Furthermore, as mentioned above, DPI can be implemented in one or more other entities (in addition to or as a replacement for implementation in one or more switches). Such one or more other entities may include the fronthaul manager (FHM) 122 described above in conjunction with the O-RAN shared cell proposal. Moreover, for ease of illustration, Figure 9A and 9B Only a single DPI entity 109 is shown, but it should be understood that multiple DPI entities 109 can be used. For example, a switched network 120 typically includes multiple switches. If DPI is implemented in the switches of the switched network 120, it may be preferable to implement the DPI function in each switch of the switched network 120, which may result in more efficient fronthaul bandwidth utilization.

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

[0115] In C-RAN 100, DU 105 can transmit control plane data (e.g., C segment 604) to RU 106. This control plane data can indicate to RU 106 which PRBs should be transmitted uplink (to DU 105). Therefore, additional data (e.g., RUid bitmasks) can be added to the control plane (C plane) data. For example, when DU 105 groups packets of C plane data in C segment 604, DU 105 can include a RUid bitmask 602 for each C segment 604 (or otherwise associated with it), as described above. However, since uplink U plane data (e.g., U segment 606) is unicast from each RU 106 to DU 105, additional data (e.g., RUid bitmask 602) is not required for uplink U plane data (U segment 606). The bandwidth utilization can be the same as the O-RAN 1.0 implementation (with a slight difference in C-plane overhead): approximately N PRB x M RU xa from the switched network 120 to DU 105, and approximately N PRB from each RU 106 to the switched network 120.

[0116] exist Figure 6A In the diagram, both C-plane and U-plane data are shown as being transmitted via fronthaul using the enhanced fronthaul interface mode and the aforementioned broadcast scheme. However, for a given transmission time interval (TTI), different packets can be transmitted in different ways. That is, for a given TTI, some packets can be transmitted using unicast transmission, some packets can be transmitted using broadcast transmission, and some packets can be transmitted using multicast transmission, if applicable. For example, it is possible that the same U-plane packets are transmitted via fronthaul to multiple RU 106 (either via broadcast to all RU 106 or via multicast to a subset of RU 106), but separate and different C-plane messages (and C-plane packets) are transmitted via fronthaul to each RU 106. These different C-plane messages can specify, for example, different beamforming or precoder information used when processing U-plane data transmitted in a common U-plane packet.

[0117] Figure 7 This is a flowchart illustrating a method 700 for transmitting data across a fronthaul interface in C-RAN 100. Method 700 can be executed by at least one processor in either a DU 105 (in a 5G configuration) or a baseband controller 104 (in a 4G configuration). The DU 105 (or baseband controller 104) can be communicatively coupled to a plurality of (M)RUs 106 via a switched network 120. The DU 105 (or baseband controller 104) and RUs 106 can form C-RAN 100.

[0118] For ease of explanation, it has been arranged in a roughly sequential manner. Figure 7 The flowchart shown is a box; however, it should be understood that this arrangement is merely exemplary and should be recognized that it is not consistent with method 700 (and Figure 7 The processes associated with the boxes shown may occur in different orders (e.g., in the case that at least some of the processes associated with the boxes are executed in parallel and / or in an event-driven manner). Furthermore, for ease of interpretation, most standard exception handling is not described; however, it is to be understood that method 700 is capable of and typically includes such exception handling.

[0119] Method 700 may begin at step 702, wherein at least one processor determines a dataset to be transmitted via the fronthaul interface of C-RAN 100 to a plurality of remote units (RUs) 106. Each dataset may include control plane (C-plane) data and / or user plane (U-plane) data. C-plane data may be transmitted in at least one C-segment 604, each C-segment including at least one packet of I / Q data, and optionally including an indication of at least one physical resource block (PRB) on which I / Q data will be transmitted over the air (by at least one RU 106). U-plane data may be transmitted in at least one U-segment 606, each U-segment including at least one packet of I / Q data, and optionally including an indication of at least one physical resource block (PRB) on which I / Q data will be transmitted over the air (by at least one RU 106).

[0120] Method 700 may be performed at step 704, wherein at least one processor determines a mapping from each of the datasets to at least one of the plurality of RUs 106. Such mapping may be based on the PRB group, the frequency reuse layer, and / or the channel involved in the corresponding dataset.

[0121] As described above, all PRB packets are created by the scheduler (DU 105 or CU 103 in 5G or L2 processing in the baseband controller 104 in 4G) to serve the set of UEs 110. Based on the needs of UE 110 and considering fairness and other factors, a certain number of PRB groups are allocated to that UE. Based on the proximity of UE 110 to RU 106, the set of RUs 106 is assigned to different such PRB groups. The scheduler can obtain this knowledge through uplink measurements, UE 110 feedback information, etc. If PRB groups are used, a particular RU 106 can only be used for packets belonging to its PRB group.

[0122] The reuse layer is entirely created by the scheduler (DU 105 or CU in 5G or L2 processing in the baseband controller 104 in 4G) to serve a set of UEs 110, for example, based on an understanding of the proximity of UEs 110 and RUs 106 according to uplink measurements, UE feedback information, etc. In the downlink, frequency reuse utilizes multiple groups, each containing at least one RU 106, to transmit simultaneously at the same frequency to different UEs 110 (wherein, each RU 106 in the reuse layer is fully RF isolated from each other RU 106 in other reuse layers). In the uplink, each of the multiple UEs 110 can simultaneously transmit at the same frequency to different reuse layers of at least one RU 106 (wherein, each RU 106 in the reuse layer is fully RF isolated from each other RU 106 in other reuse layers).

[0123] As described above, the following transmission types can be used: (1) narrowcasting different datasets to different RU 106s for certain 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), etc.); (2) broadcasting common channels and reference signals (e.g., Physical Broadcast Channel (PBCH) and PDCCH (for 4G and optional 5G), etc.) to all RU 106s; and (3) unicasting or narrowcasting certain channels or reference signals (e.g., Channel State Information Reference Signal (CSI-RS) Group 1 or CSI-RS Group 2, etc.). Therefore, different datasets can be mapped to different sets of RU 106s served by the same DU 105.

[0124] Method 700 may be performed at step 706, wherein at least one processor adds an indicator to each dataset based on a mapping, each indicator indicating each RU 106 to which the corresponding dataset points.

[0125] For example, each indicator can be a RUid bitmask 602 having bits for each of a plurality of RUs 106, where each bit position corresponds to an RU 106. In other words, each RUid bitmask 602 can have at least the same number of bits as the number of RUs 106 connected to DU 105, CU 103, or baseband controller 104. When any specific bit in the RUid bitmask 602 is set (e.g., set to "1"), it indicates that the dataset (e.g., C segment 604 and / or U segment 606) is intended to be received by the specific RU 106 corresponding to the set bit. More than one bit (each bit corresponding to a different RU 106) or all bits can be set in the RUid bitmask 602.

[0126] Each indicator may be included in (or otherwise associated with) the corresponding dataset. In the configuration where C segment 604 and U segment 606 are used to transmit control plane data and user plane data, respectively, a RUid bitmask 602 may be included within each C segment 604 and U segment 606. Alternatively, additional data (e.g., the RUid bitmask) may be associated with the C plane data and U plane data in other ways, such as by appending it.

[0127] Method 700 can be performed at step 708, wherein at least one processor broadcasts a dataset to multiple RUs 106, each dataset having a corresponding indicator. For example, all packets can be broadcast to all RUs 106 via a fronthaul interface from DU 105 or baseband controller 104 (e.g., via Ethernet). Each RU 106 can then identify whether a packet's grouping of packets points to it without decoding all segments (by determining whether a bit in the RUid bitmask 602 corresponding to the respective RU 106 is set). For example, if a bit of an RU is set to "1", then RU 106 will decode the dataset. However, if a bit of an RU is set to "0", then RU 106 will not decode the dataset.

[0128] Method 700 may be performed in optional step 710, wherein at least one processor receives uplink data on a PRB specified in at least one broadcast dataset. For example, the dataset broadcast in step 708 may include commands to one or more RUs 106, which tell RUs 106 which uplink signals (PRBs) they should send back on the uplink. In this case, optional step 710 includes RUs 106 sending back the requested uplink signals.

[0129] In some configurations, multiple RU 106s can send back information for the same PRB because (1) the contributions of RU 106 will be “combined”, i.e., cooperative reception; or (2) RU 106s have RF isolation and the same PRB has been assigned to different UE110s, i.e. reuse.

[0130] Figure 8 This is a flowchart illustrating a method 800 for transmitting data across a fronthaul interface in C-RAN 100. Method 800 can be executed by at least one processor in RU 106. RU 106 can be one of multiple (M) RUs 106 communicatively coupled to either DU 105 (in a 5G configuration) or baseband controller 104 (in a 4G configuration) via a switched network 120. RU 106 and DU 105 (or baseband controller 104) can form C-RAN 100.

[0131] For ease of explanation, it has been arranged in a roughly sequential manner. Figure 8 The flowchart shown is a box; however, it should be understood that this arrangement is merely exemplary and should be recognized that it is not consistent with method 800 (and Figure 8 The processes associated with the boxes shown may occur in different orders (e.g., in the case that at least some of the processes associated with the boxes are executed in parallel and / or in an event-driven manner). Furthermore, for ease of interpretation, most standard exception handling is not described; however, it is to be understood that method 800 is capable of and typically includes such exception handling.

[0132] Method 800 may begin at step 802, wherein at least one processor receives a dataset directed to RU 106 in C-RAN 100. In the example, at least some datasets do not direct to RU 106 implementing method 800. Each dataset may include control plane (C-plane) data and / or user plane (U-plane) data. C-plane data may be transmitted in at least one C-segment 604, each C-segment including at least one packet of I / Q data and optionally including an indication of at least one physical resource block (PRB) on which I / Q data will be transmitted over the air (by at least one RU 106). U-plane data may be transmitted in at least one U-segment 606, each U-segment including at least one packet of I / Q data and optionally including an indication of at least one physical resource block (PRB) on which I / Q data will be transmitted over the air (by at least one RU 106).

[0133] Each dataset may have an associated indicator (e.g., a bitmask) that indicates at least one RU 106 to which the corresponding dataset points. For example, each indicator may be a RUid bitmask 602 that has bits for each of a plurality of RU 106, where each bit position corresponds to an RU 106.

[0134] Method 800 may be performed at step 804, wherein for each dataset, at least one processor interprets and processes the dataset based on whether a corresponding indicator indicates that the dataset is directed to RU 106. When any specific bit in the RUid bitmask 602 is set (e.g., set to "1"), it indicates that the dataset (e.g., C segment 604 and / or U segment 606) is intended to be received by the specific RU 106 corresponding to the set bit. For example, if a bit of the RU is set to "1", then RU 106 will decode and process the dataset. However, if a bit of the RU is set to "0", then RU 106 will not decode and process the dataset.

[0135] Method 800 may be performed at optional step 806, wherein at least one processor transmits uplink data on at least one PRB specified in the received dataset. For example, if the dataset received in step 802 (e.g., from DU 105) includes an instruction to RU 106 (and possibly more than RU 106) implementing method 800, informing RU 106 which uplink signals (PRBs) it should send back to DU 105, then optional step 806 includes RU 106 sending back the requested uplink signals.

[0136] In some configurations, multiple RU 106s can send back information for the same PRB because (1) the contributions of RU 106 will be “combined”, i.e., cooperative reception; or (2) RU 106s have RF isolation and the same PRB has been assigned to different UE110s, i.e. reuse.

[0137] Figure 10 This is a flowchart illustrating method 1000 for transmitting data across the fronthaul interface and fronthaul network in C-RAN 100 using multicast transmission and multicast groups (if possible). Method 1000 is identical to method 700 except as described below, and the corresponding description of method 700 set forth above also applies to method 1000, and for the sake of brevity, it is generally not repeated here.

[0138] Method 1000 may begin at step 702, wherein at least one processor determines a dataset to be transmitted to multiple remote units (RUs) 106 via the fronthaul interface of C-RAN 100. This may be combined as described above. Figure 7 Complete it as described.

[0139] Method 1000 may be performed at step 704, wherein at least one processor determines a mapping from each of the datasets to at least one of a plurality of RUs 106. That is, each of the datasets is mapped to a subset of RUs 106, wherein each such subset of RUs 106 comprises one or more RUs 106. This can be combined as described above. Figure 7 Complete it as described.

[0140] Method 1000 can be performed at optional step 706, wherein at least one processor adds indicators to each dataset based on a mapping, each indicator indicating each RU 106 pointed to by the corresponding dataset. This can be combined as described above. Figure 7 Complete it as described. This step 706 is optional in method 1000.

[0141] Method 1000 may be performed at step 1008, wherein at least one processor determines for each dataset whether at least one multicast group matches a corresponding subset of remote units 106 mapped to that dataset. For each dataset where at least one multicast group matches a corresponding subset of remote units 106 mapped to each dataset, method 1000 may be performed at step 1010, wherein at least one processor transmits the dataset to the corresponding subset of remote units via the fronthaul network by multicasting the dataset to the multicast group that best matches the corresponding subset of remote units mapped to that dataset. When using multicast transmission, only a single version of the downlink fronthaul data is transmitted via the boundary Ethernet link used to couple the relevant central units to the switched network 120. Switches in the switched network 120 (as part of standard Ethernet or IP multicast) replicate the downlink fronthaul data as needed and send it to all RUs 106 included in the multicast group. Any RU 106 that is not a member of the multicast group will not receive the downlink fronthaul data transmitted to the multicast group. Therefore, RU 106 that is not a member of the multicast group will not receive downlink fronthaul data that is not directed to them, which saves bandwidth on the boundary Ethernet links terminating at these RU 106.

[0142] For each dataset where no multicast group matches a corresponding subset mapped to the remote unit 106 of each dataset, method 1000 may proceed in step 1012, wherein at least one processor, as described above, may be used. Figure 7 Box 708 describes broadcasting the dataset to all remote units 106.

[0143] If optional step 706 is performed, each such dataset is multicast or broadcast using the appropriate indicator, as appropriate. The indicator included with the dataset can be used by each RU 106 receiving the dataset to determine whether the dataset points to it, as described above. For example, in the case of multicasting a dataset to a multicast group with additional RU 106, these additional RU 106 will be able to use the indicator included with the dataset to determine whether the dataset points to it. Similarly, in the case where the dataset is broadcast to all RU 106, each RU 106 can use the indicator to determine whether the dataset points to it in the manner described.

[0144] As described above, in one implementation, if a multicast group includes all RU 106s in a subset of RU 106 (even if the multicast group includes additional RU 106s not in the subset of RU 106 to which the fronthaul data is to be sent via fronthaul), then the multicast group "matches" that particular subset of RU 106. If more than one matching multicast group exists, the best matching multicast group for the subset of RU 106 can be determined based on the total number of RU 106s included in each matching multicast group. A matching multicast group that includes the minimum total number of RU 106s can be considered the best match for the subset of RU 106. If multiple matching multicast groups that include the minimum number of RU 106s exist, one of these multiple matching multicast groups can be selected (e.g., randomly or using some other process).

[0145] As described above, an initial set of multicast groups for the switched network 120 is defined, and the switches in the switched network 120 are configured to implement the initial set of multicast groups. Then, as described above, the set of multicast groups used in the switched network 120 can be periodically added (if the switched network 120 can accommodate additional multicast groups) or changed to reflect the actual fronthaul traffic flow and / or the actual location of the UE and the RU 106 used to serve it, and the switches in the switched network 120 can be configured to implement an updated set of multicast groups.

[0146] Figure 11 This is a flowchart illustrating a method 1100 for transmitting data across the fronthaul interface in C-RAN 100 using the second modification described above. When using the second modification described above, deep packet inspection is employed. Method 1100 may be implemented in part by at least one processor in either DU 105 (in a 5G configuration) or baseband controller 104 (in a 4G configuration), and in part by an entity performing deep packet inspection (e.g., an Ethernet switch or another entity, such as the fronthaul manager (FHM) described above in conjunction with the O-RAN shared cell proposal).

[0147] Except as described below, method 1100 is the same as method 700, and the corresponding description of method 700 described above also applies to method 1100, and for the sake of brevity, it will generally not be repeated here.

[0148] Method 1100 may begin at step 702, wherein at least one processor determines a dataset to be transmitted to multiple remote units (RUs) 106 via the fronthaul interface of C-RAN 100. This may be combined as described above. Figure 7 Complete it as described.

[0149] Method 1100 may be performed at step 704, wherein at least one processor determines a mapping from each of the datasets to at least one of the plurality of RUs 106. That is, each of the datasets is mapped to a subset of RUs 106, wherein each such subset of RUs 106 comprises one or more RUs 106. This may be combined as described above. Figure 7 Complete it as described.

[0150] Method 1100 can be performed at step 706, wherein at least one processor adds indicators to each dataset based on a mapping, each indicator indicating each RU 106 pointed to by the corresponding dataset. This can be combined as described above. Figure 7 It is accomplished as described. More specifically, in the example described herein of transmitting fronthaul data in packet form over a fronthaul network, indicators are added to each dataset packet based on a mapping, wherein each such indicator indicates each remote unit to which the corresponding packet and dataset point.

[0151] Method 1100 may be performed at step 1108, wherein at least one processor transmits packets of the dataset to DPI entity 109 via a fronthaul network, each packet of the dataset having a corresponding indicator. Method 1100 may be performed at step 1110, wherein DPI entity 109 is configured to perform a deep packet inspection on each received packet to determine each remote unit 106 to which the packet is directed, and may be performed at step 1112, wherein DPI entity 109 is configured to transmit each packet to each remote unit 106 to which the packet is directed via a fronthaul network.

[0152] As a result, each packet is not forwarded to any RU 106 that the packet is not directed to, which saves bandwidth on the border Ethernet links terminating at these RU 106. As mentioned above, method 1100 does not require the management overhead required by method 1000 (e.g., method 1100 does not require defining multicast groups, or configuring switches to use defined multicast groups, whether at the beginning or periodically thereafter).

[0153] Figure 12 This is a block diagram illustrating an example of a protocol stack 1200 suitable for transmitting I / Q data between each controller 104 (or 5G CU 103 or DU 105) and associated radio unit 106 via a fronthaul network 116. The controller 104 (or CU 103 or DU 105) and each associated radio unit 106 respectively implement corresponding signal processing peer entities 1202 and 1204 that implement the protocol stack 1200.

[0154] like Figure 12As shown, the highest layer of the protocol stack 1200 includes an application layer protocol 1206, which is used to transmit I / Q data between the controller 104 (or CU 103 or DU 105) and each radio unit 106 via a fronthaul 116. As described above, the I / Q data transmitted via the fronthaul 116 is used in digital signal processing performed to implement the radio interface of cell 108.

[0155] In this example, application layer protocol 1206 is also referred to herein as the “SwIQ-DAP” layer 1206. Because many different types of I / Q data can be transmitted between controller 104 (or CU 103 or DU 105) and each radio unit 106 via fronthaul 116, therefore... Figure 13A The Type-Length-Value (TLV) element 1300 shown is used to transmit I / Q data.

[0156] Figure 13A This is a block diagram showing an example of fields in Ethernet packet 534, Internet Protocol (IP) packet 1330, SwIQ-DAP Protocol Data Unit (PDU) 1308, TLV element 1300, and SwIQ-DAP header 1310. Figure 13A -B excludes all fields that may be included in various groups, PDUs, headers, etc. Each TLV element 1300 includes a type field 1302 that identifies what type and format of I / Q data is contained in the element 1300, a length field 1304 that identifies the length of the element 1300, and a value field 1306 that contains the data or payload of the element 1300. The type field 1302 and the length field 1304 have fixed lengths, while the length of the value field 1306 can vary.

[0157] In this example, such as Figure 13AAs shown, one or more TLV elements 1300 are combined into a single SwIQ-DAP Protocol Data Unit (PDU) 1308. Each such SwIQ-DAP PDU 1308 includes a header 1310 and a payload 1312 comprising one or more TLV elements 1300 (the number of which depends on the size of the Maximum Transmission Unit (MTU) specified for the SwIQ-DAP PDU 1308). In this example, the SwIQ-DAP header 1310 includes a source identifier field 1314, which identifies the sender of the PDU 1308. In one example where only one controller 104 (or CU 103 or DU 105) serves each cell 108, the source identifier field 1314 is used only for uplink data to identify which RU 106 has sent the SwIQ-DAP PDU 1308 to that single controller 104 (or CU 103 or DU 105) (because multiple RUs 106 could send such PDU 1308 to controller 104 (or CU 103 or DU 105)). However, downlink SwIQ-DAP PDU 1308 sent from controller 104 remains undefined (because only one controller 104 (or CU 103 or DU 105) serves cell 108). In another example where multiple controllers 104 (or DU 105 or CU 103) serve each cell 108, the source identifier field 1314 is used to identify which RU 106 has sent each uplink SwIQ-DAP PDU... 1308 is sent to controller 104 and identifies which controller 104 (or CU 103 or DU 105) has sent each downlink SwIQ-DAP PDU 1308 to one or more RUs 106. In some examples, the SwIQ-DAP header 1310 does not have a fixed size.

[0158] In this example, the SwIQ-DAP header 1310 also includes a version number field 1316 identifying the version number of the SwIQ-DAP, a TLV number field 1318 specifying the number of TLV elements 1300 included in the PDU 1308, a sequence number field 1320 specifying the transmission sequence number of the PDU 1308, a length field 1322 specifying the length of the PDU 1308, and a timestamp field 1324 containing a timestamp specifying when the PDU 1308 was sent. In this example, the SwIQ-DAP header 1310 also includes an application layer multicast address field 1326, which can be used to specify the multicast group of the radio unit 106 at the application layer level. This can be combined with the above... Figure 3This is accomplished as described above, wherein each bit position of the application layer multicast address field 1326 is associated with a corresponding radio unit 106, wherein the bit position is set if the associated downlink I / Q data points to that radio unit 106, and wherein the bit position is cleared if the associated downlink I / Q data does not point to that radio unit 106. It should be noted that elements 1314-1326 are optional, as an actual implementation of the SwIQ-DAP header 1310 may include fewer than all of them (or none of them).

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

[0160] Optionally, the RUid bitmask 602 needs to be in the first X (e.g., 64, 128, etc.) bytes of the UDP payload 1328, in which case at least some of the SwIQ-DAP header 1310 will be in the first X bytes of the UDP payload. This constraint is optionally implemented based on at least one processor in the Ethernet switch (in the fronthaul network 116) performing deep packet inspection. For example, if at least one processor can analyze up to 64 bytes of the UDP payload 1328 and still meet the system's latency requirements, then the RUid bitmask 602 should be in the first 64 bytes of the UDP payload 1328. However, if at least one processor in the DPI entity 109 can analyze up to 128 bytes of the UDP payload 1328 and still meet the system's latency requirements, then the RUid bitmask 602 may only need to be in the first 128 bytes of the UDP payload 1328. In other words, the exact requirement imposed on the positioning of the RUid bitmask 602 within the UDP payload 1328 can be based on limitations imposed on at least one processor performing deep packet inspection. Alternatively or additionally, the RUid bitmask 602 needs to be located within the first X (e.g., 64, 128, etc.) bytes of the Ethernet payload 1338, in which case at least some of the SwIQ-DAP header 1310 will be located within the first X bytes of the Ethernet payload 1338. Therefore, even if it is shown at the end of the SwIQ-DAP header 1310, the RUid bitmask 602 can be located at different positions within the SwIQ-DAP header 1310.

[0161] like Figure 12 As shown, subsequent layers of the protocol stack 1200 include an optional User Datagram Protocol (UDP) layer 1208 and an optional Internet Protocol (IP) layer 1210. UDP datagrams (or “UDP packets”) encapsulated in IP packets can be transmitted between the controller 104 (or CU 103 or DU 105) and the radio unit 106 via the Internet Protocol layer. Figure 13A In the diagram, each SwIQ-DAP PDU 1308 is shown as a UDP datagram transmitted within a payload 1340 encapsulated in a multicast IP packet 1330. Each IP packet 1330 is also shown as including an IP header 1332 and a UDP header 1333; however, in some configurations, the IP header 1332 and / or the UDP header 1333 may not be included.

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

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

[0164] As described above, the fronthaul 116 is implemented using a standard switched Ethernet network 120. Therefore, the lowest layer (data link layer) of the protocol stack 1200 is ( Figure 12 Ethernet layer 1212, as shown in the figure Figure 13A Ethernet packet 1334 (shown in the diagram) is transmitted via the Ethernet layer through Ethernet network 120 between controller 104 (or CU 103 or DU 105) and radio unit 106. Figure 13AAs shown, each Ethernet packet 1334 includes a standard Ethernet header 1336 and a payload 1338. The Ethernet header 1336 may include an Ethernet source address 1342, an Ethernet destination address 1344, an optional VLAN tag (not shown), an optional VLAN header (not shown), and / or an Ethernet type 1346 field. The Ethernet type 1346 field may indicate the type and format of the Ethernet payload 1338, such as 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 includes 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 indicating that the RUid bitmask 602 exists at a specific 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.

[0165] Protocol stack 1200 is configured to enable I / Q fronthaul data to be transmitted via fronthaul 116 of C-RAN 100 using a standard switched Ethernet network 120 (instead of a conventional synchronous CPRI point-to-point link). Various standard features (e.g., port numbers, IP multicast groups, VLANs, and packet labels) provided by UDP, IP, and Ethernet layers 1208, 1210, and 1212 can be used to help meet the requirements of fronthaul 116, while additional features implemented in application layer 1202 can be used when needed.

[0166] Figure 13B This is a block diagram showing an example of a field in Ethernet packet 534, SwIQ-DAP Protocol Data Unit (PDU) 1308, TLV element 1300, and SwIQ-DAP header 1310. Figure 13B Examples include Figure 13A The example shows many of the same fields, but with some differences.

[0167] Specifically, Figure 13B Examples and Figure 13A The examples are different because Figure 13B The example shows a SwIQ-DAP protocol data unit (PDU) 1308 in the Ethernet payload 1338, without implementing... Figure 13A This refers to IP packets 1330 or UDP datagrams (within IP payload 1340). In this case, deep packet inspection can be performed on another field. For example, Ethernet type 1346 could be a custom type that contains SwIQ packets. The O-RAN specification currently supports I / Q transport via the Extended Common Public Radio Interface (ECPRI).

[0168] In other examples ( Figure 13B (Not shown in the image), IP packet 1330 can be implemented with IP header 1332, but without implementing UDP datagrams internally. In these configurations, another type of header can be used instead of UDP.

[0169] Figure 14A This is a block diagram illustrating an exemplary configuration for performing deep packet inspection in a fronthaul network 116. The fronthaul network 116 can be implemented as an Ethernet network, including one or more switches, routers, and / or other network devices. Specifically, the fronthaul network 116 includes an aggregation switch 111 and optionally includes at least one switch 113. The aggregation switch 111 can transmit data between at least one switch 113 and at least one baseband controller 104 (in 4G) or a DU 105 or CU (referred to as BC 104 / DU 105 / CU 103) (in 5G). For example, the aggregation switch 111 can receive downlink Ethernet packets 1334 from BC 104 / DU 105 / CU 103 and selectively forward at least a portion of these packets to switch 113. In other configurations, the aggregation switch 111 can directly forward packets to RU 106 (without an intermediate switch 113).

[0170] In some configurations, switch 113 is daisy-chained, and only a single switch 113 is coupled to aggregation switch 111. Alternatively, more than one switch 113 may be coupled to aggregation switch 111. Furthermore, the fronthaul network 116 can be implemented using any number of aggregation switches 111 and / or optional switches 113. In some configurations, data may be transmitted between aggregation switch 111 and switch 113 as I / Q data and / or timing and management (TM) data.

[0171] One or more of aggregation switches 111 and / or switches 113 may each include a DP entity 109. If at least one of switches 113 includes a DPI entity, then switches 113 should be able to communicate with each other. Each DPI entity 109 may be implemented using at least one processor that executes executable instructions stored in at least one memory to perform the deep packet inspection function described herein. During deep packet inspection, (e.g., in an Ethernet switch) the DPI entity 109 examines the RUid bitmask 602 (if present) to determine whether to forward Ethernet packets 1334 (e.g., downlink I / Q packets 1308) to the intended RU 106. The RUid bitmask 602 may be of any length suitable for accommodating the number of RUs 106 in the C-RAN 100, such as 32 bits, 64 bits, 128 bits, etc.

[0172] In some configurations, the RUid bitmask 602 in the SwIQ-DAP header 1310 (e.g., the first X bytes of Ethernet packet 1334) is compared with a pre-defined bit pattern to determine whether Ethernet packet 1334 (or a portion thereof) will be dropped or forwarded to its designated RU 106.

[0173] Some switch management functions (such as VLANs, enabling / disabling ports, and adding IP addresses) can be performed via a secure connection. Other management functions can be performed via a regular connection, such as configuring bit modes on the switch.

[0174] In some examples, when destination port 1356 is within the configured port range (or equal to a predetermined value), DPI entity 109 (e.g., in an Ethernet switch) can only check RUid bitmask 602.

[0175] In some examples, such as during a discovery process performed between RU 106 and BC 104, DU 105, or CU 103, a RUid is assigned to each RU 106. RU 106 registers itself with DPI entity 109 (e.g., in an Ethernet switch), requesting that it forward packets on a given multicast address (e.g., abcd) if its RUid bit is set (in RUid bitmask 602). A given RU can request multiple multicast addresses combined with the RUid. Multiple IP addresses can be used for load balancing within a sector. Multiple IP addresses can be used to distinguish traffic belonging to different sectors. Furthermore, RU 106 can serve multiple sectors.

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

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

[0178] Figure 14B This is a block diagram showing additional details of an example of implementing a fronthaul network 116 of C-RAN 100 using a switched Ethernet network 120. Figure 14B The examples in this document include many of the same or similar devices, systems, and / or modules shown in the other figures. Figure 14B In this context, the term controller 104 is used to refer to baseband controller 104, 5G CU 103, or 5G DU 105.

[0179] Typically, a switched Ethernet network 120 includes one or more Ethernet switches. Figure 14B In the example shown, the switched Ethernet 120 includes an aggregation layer and an access layer, the aggregation layer including one or more aggregation Ethernet switches 111, and the access layer including one or more access Ethernet switches 113. Although for ease of illustration... Figure 14B Only one aggregation switch 111 and access Ethernet switch 113 are shown, but other numbers of switches 111 and 113 can be used. Furthermore, other Ethernet network topologies can be used (e.g., additional Ethernet switch layers (or hops) may exist between (or within) the aggregation layer and the access layer, or entirely different topologies may be used). Each radio unit 115, 117 can alternatively be communicatively coupled to the aggregation switch 111 without an intermediate switch 113.

[0180] like Figure 14BAs shown in more detail below, in this exemplary embodiment, controller 104 and radio point 106 communicate with each other via a switched Ethernet network 120, which uses two public Virtual Local Area Networks (VLANs) to implement fronthaul 116. In this embodiment, one VLAN is used to transmit timing information (e.g., IEEE 1588 Precision Time Protocol (PTP) messages used to synchronize controller 104 and RU 106) and management information between controller 104 and radio point 106 (e.g., Simple Object Access Protocol (SOAP) and eXtensible Markup Language (XML) messages). This VLAN is referred to herein as the "Timing and Management" or "TM" VLAN. The second VLAN is used to transmit IQ data between controller 104 and radio point 106, and is referred to herein as the "IQ" VLAN.

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

[0182] exist Figure 14B In the example shown, fronthaul 116 is used to fronthaul data for two clusters 124 serving two respective wireless operators. In this example, a separate VLAN is established for each cluster 124 for inter-controller communication between the controllers 104 included in that cluster 124. Each such VLAN is referred to herein as a "cluster" or "C" VLAN.

[0183] exist Figure 14B In the example shown, each controller 104 includes a method for coupling the controller 104 to a switched Ethernet network 120 (more specifically, to...). Figure 14B The example shown has multiple Ethernet network interfaces 130 of one or more aggregation switches 111).

[0184] exist Figure 14BIn the example shown, some of the Ethernet network interfaces 130 in each controller 104 are dedicated to transmitting timing and management data via timing and management VLANs. Each of these Ethernet network interfaces 130 is also referred to herein as a "Timing and Management" or "TM" Ethernet network interface 130. In this example, some of the Ethernet network interfaces 130 in each controller 104 are dedicated to transmitting IQ data via an IQ VLAN, and are also referred to herein as "IQ" Ethernet network interfaces 130. Furthermore, in this example, some of the Ethernet network interfaces 130 in each controller 104 are dedicated to communication via a cluster VLAN. Each of these Ethernet network interfaces 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) for communicating with the core network 112 via backhaul.

[0185] exist Figure 14A In the example shown in 14B and / or 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, wherein each such Ethernet network interface 184 is used to communicate via both timing and management VLANs and IQ VLANs.

[0186] exist Figure 14A In the example shown in 14B and / or 14B, for each cell 108 served by cluster 124, the controller 104 serving that cell 108 multicasts a timing message via a timing VLAN by using a corresponding timing multicast group defined for that cell 108. That is, each cell 108 served by cluster 124 has a single timing multicast group assigned to it. In this embodiment, for each cell 108 served by cluster 124, RU 106 transmits timing messages via the timing and management VLAN by unicasting a message to the IP address of the timing and management Ethernet interface assigned to the service controller 104 of that cell 108.

[0187] Moreover, in Figure 14B In the example shown, for each cell 108 served by cluster 124, management messages are transmitted between controller 104 and RU 106 via timing and management VLANs by unicasting management messages using the IP address assigned to the timing and management Ethernet interface of controller 104 or the Ethernet interface 184 to which management messages are sent.

[0188] The sets of downlink and uplink IP multicast groups are used to transmit downlink and uplink IQ data, respectively.

[0189] Timing, management, and IQ data can be communicated through other means.

[0190] Generally, when each radio point 106 is started, each radio point instance implemented by that radio point 106 will use a discovery protocol to discover the controller 104 to which the radio point instance should belong. As part of the discovery process, the radio point instance is provided with an IP address for the timing and management Ethernet interface 130 assigned to the discovered controller 104. The radio point instance uses this 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, which the radio point instance should use to transmit downlink and uplink IQ data.

[0191] In a configuration where multiple controllers 104 serve a given radio point instance (e.g., controller 104 acts as a backup controller for another master 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 to the appropriate downlink IP multicast group for cell 108 and transmits data to controller 104 via fronthaul 116 using the appropriate uplink IP multicast group. Because of the use of IP multicast, multiple controllers 104 can register to the same uplink IP multicast group used by the radio point instances of cell 108 to transmit data via fronthaul 116 and receive data using the same uplink IP multicast group, and multiple controllers 104 can use the downlink IP multicast groups to which these radio point instances are registered to transmit data to the radio point instances of cell 108 via fronthaul 116. In other words, due to the use of IP multicast, radio point instances can be transparently served by multiple controllers 104.

[0192] Furthermore, the use of IP multicast does not preclude a single controller 104 from serving multiple cells 108. In a configuration where a single controller 104 serves multiple cells 108 (e.g., primary cell 108 and secondary cell 108), the single controller 104 registers with the uplink IP multicast groups of the primary cell 108 and secondary cell 108, and uses the downlink IP multicast groups of the primary cell 108 and secondary cell 108 to send data to the appropriate radio point instance via fronthaul 116.

[0193] In some examples, downlink IQ data is transmitted UE-by-UE between each controller 104 and its associated radio point 106, while uplink IQ data is transmitted RU-by-RU. In other examples (e.g., O-RAN), both downlink and uplink IQ data are transmitted RU-by-RU. For each UE 112 served by cell 108, the serving controller 104 assigns a subset of RUs 106 of that cell to that UE 112 for downlink radio transmissions to that UE 112. This subset of RUs 106 is referred to herein as the “co-cast area” of that UE 112. The co-cast area for each UE 112 is determined based on received power measurements taken at each RU 106 for certain uplink transmissions from UE 112 (e.g., LTE Physical Random Access Channel (PRACH) and Sounding Reference Signal (SRS) transmissions) and is updated as UE 112 moves throughout cell 108.

[0194] For the uplink, in this embodiment, for each cell 108, the radio point 106 serving cell 108 uses an aggregation of uplink IP multicast groups and multicast load balancing to transmit uplink IQ data to the service controller 104. In this embodiment, multiple link aggregation groups (LAGs) are defined for each cell 108, where each LAG has an associated uplink IP multicast group. Switches 111 and 113 in the switched Ethernet network 120 are configured to use multicast load balancing to load balance uplink IQ data traffic through the various IQ Ethernet interfaces of the service controller 104.

[0195] Similar to the uplink, multiple downlink IP multicast groups are used for load balancing purposes. For the downlink, multiple downlink IP multicast group sets are used to send downlink IQ data to different combinations of RU 106, where the downlink IP multicast group sets are dynamic. For a set of downlink IP multicast groups, each downlink IP multicast group in the set includes all RU 106 serving cell 108. These “all RU” downlink IP multicast groups are used to transmit downlink IQ data of the common logical channel of the radio interface to all RU 106 of cell 108. An example that can accomplish this is for transmitting downlink IQ data for LTE System Information Blocks (SIBs). “All RU” downlink IP multicast groups can also be used when no other suitable set of downlink IP multicast groups exists. For other downlink IP multicast group sets, all constituent downlink IP multicast groups contain fewer than all RU 106 serving cell 108. These additional downlink IP multicast group sets are created as needed so that downlink IQ data (specifically downlink IQ data of the Physical Downlink Shared Channel (PDSCH)) is delivered only to those RU106 within the cocast area of ​​a given UE 112.

[0196] When downlink data needs to be transmitted to a given UE 112 via the radio interface, if an existing set of downlink IP multicast groups “matching” the UE 112’s cocast area exists, one of the downlink IP multicast groups from the matching set is used to transmit the UE 112’s downlink IQ data to RU 106 in the UE’s cocast area. If no set of downlink IP multicast groups matches the given UE 112’s cocast area, a new set of downlink IP multicast groups can be created, where all downlink IP multicast groups in the set include RU 106 in the cocast area, and then one of those newly created downlink IP multicast groups is used to transmit downlink IQ data only to those RU 106 in the cocast area. 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 been created, and no existing downlink IP multicast group can be cleared at this time due to unused data), then one of the previously mentioned “all RU” downlink IP multicast groups can be used.

[0197] However, using a "All RUs" downlink IP multicast group may result in downlink IQ data for a given UE 112 being sent to RU 106 that is not included in the UE's cocast area. To handle this situation, in this example, an application-layer multicast address (described below) included in the IQ data is used to identify which RU 106 the associated downlink IQ data actually points to. In this example, this application-layer multicast address includes an address field that can be considered as multiple bit positions. The corresponding bit positions in the bit positions are assigned to each RU 106 serving cell 108, wherein if the associated downlink IQ data points to the associated RU 106, the bit position is set (i.e., storing a first binary value (e.g., one)), and wherein if the associated downlink IQ data does not point to the associated RU 106, the bit position is cleared (i.e., storing a second binary value (e.g., zero)). For example, all bit positions of the application-layer multicast address would be set for packets containing downlink IQ data for general messages (e.g., SIBs) pointing to all RU 106. For downlink IQ data directed to a UE112 that includes fewer than all RU 106s in its comcast area, only the bit positions corresponding to the application layer multicast address of the RU 106 in that comcast area are set, while the bit positions corresponding to all other RU 106s are cleared. (An example of an application layer multicast address is provided below.) Figure 13A -B describes the application layer multicast address field 1326.

[0198] Figure 15 This is a block diagram of a wireless system with multiple RUs and UEs. In the following description, the wireless system is used to illustrate an example of how downlink IQ data can be transmitted from the service controller 104 to the radio point 106 via a switched Ethernet network 120 using IP multicast groups and application layer multicast groups. Figure 15 The example shown depicts five RU 106s and three UE 112s. RU 106 in... Figure 15 They are referenced individually as RU 1, RU 2, RU 3, RU 4, and RU 5. UE 112 in Figure 15 They are referenced individually as UE A, UE B, and UE C. Figure 15In the example shown, UE A's cocast area includes RU1, RU2, and RU4; UE B's cocast area includes RU4 and RU5; and UE C 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 including RU1, RU2, and RU4 (and in this example, assigned IP address 293.2.1.10); a second downlink IP multicast group including RU4 and RU5 (and in this example, assigned IP address 293.2.1.11); and a third downlink IP multicast group including RU2, RU3, and RU5 (and in this example, assigned IP address 293.2.1.12). However, forming all these "matching" downlink IP multicast groups can take time.

[0199] For example, when UE A first accesses cell 108, and the downlink IP multicast group including RU1, RU2, and RU4 has not yet been created, downlink IQ data can be sent to the RUs in UE A's cocast area (i.e., to RU1, RU2, and RU4) using the "All RUs" downlink IP multicast group (which is assigned IP address 239.2.1.1 in this example). In this case, as... Figure 15 As shown, (using the corresponding IP address 239.2.1.1) a packet containing downlink IQ data pointing to RUs in the comcast area of ​​UE A is sent to the "All RUs" downlink IP multicast group, with the application layer multicast address "11010". The first bit (corresponding to RU 1), the second bit (corresponding to RU 2), and the fourth bit (corresponding to RU 4) are set, while the third bit (corresponding to RU 3) and the fifth bit (corresponding to RU 5) are cleared. In this example, only five bit positions are shown for ease of illustration, but application layer multicast addresses typically use a larger number of bit positions (e.g., 64 bit positions corresponding to an eight-byte address).

[0200] After creating a downlink IP multicast group including RU 1, RU 2 and RU 4, packets containing downlink IQ data of RUs in the cocast area of ​​UE A 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".

[0201] Furthermore, in this example, (using the corresponding IP address 239.2.1.1) packets containing downlink IQ data for general messages (such as SIBs) are sent to the "All RUs" downlink IP multicast group, with the application layer multicast address being "11111" (because the data is directed to All RUs).

[0202] Deep grouping inspection

[0203] Figure 16 This is a flowchart illustrating a method 1600 for transmitting data across a fronthaul interface and fronthaul network 116 in C-RAN 100 using Deep Packet Inspection (DPI). Method 1600 can be executed by at least one processor in an Ethernet switch in the fronthaul network 116 of C-RAN 100. For example, the Ethernet switch can be aggregation switch 111 or switch 113, either of which implements DPI entity 109. The Ethernet switch can be communicatively coupled to BC 104, DU 105, CU 103, and / or RU 106 forming C-RAN 100 (or a portion of C-RAN 100). Furthermore, in some configurations, the Ethernet switch implementing method 1600 can be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1600, it can be communicatively coupled to (1) at least one switch 113; and (2) BC 104, DU 105, and / or CU 103. Alternatively, if aggregation switch 111 implements method 1600, it can be communicatively coupled to (1) at least one RU 106; and (2) BC 104, DU 105, and / or CU 103. As another example, if switch 113 implements method 1600, it can be communicatively coupled to (1) aggregation switch 111; and (2) at least one RU 106. Other configurations are possible. In some examples, method 1600 is performed for each packet received at the Ethernet switch.

[0204] For ease of explanation, it has been arranged in a roughly sequential manner. Figure 16 The flowchart shown is a box; however, it should be understood that this arrangement is merely exemplary and should be recognized that it is not consistent with method 1600 (and Figure 16 The processes associated with the boxes shown may occur in different orders (e.g., in the case that at least some of the processes associated with the boxes are executed in parallel and / or in an event-driven manner). Furthermore, for ease of interpretation, most standard exception handling is not described; however, it is to be understood that method 1600 is capable of and typically includes such exception handling.

[0205] Method 1600 begins at optional step 1602, wherein at least one processor receives packets of data. The packets may be Ethernet packets 1334 including I / Q data. In a first example, Ethernet packet 1334 may include multicast IP packets 1330 having UDP datagrams 1308 within an IP payload 1340, the IP payload including I / Q packets 1308 with a header 1310 (having a RUid bitmask 602 (or other form of RU identifier)), for example... Figure 13A As in the second example, Ethernet packet 1334 may include I / Q packet 1308 (including RUid bitmask 602) and may not include IP header 1332 or UDP header 1333, for example... Figure 13B As in the example. Alternatively, the packet received in step 502 may be a multicast IP packet 1330 or an I / Q packet 1308 itself. The packet may be one of a plurality of received packets, for example, in a stream of Ethernet packets 1334.

[0206] If the Ethernet switch implementing method 1600 is an aggregation switch 111, packets can be received from (1) BC 104, DU 105, or CU 103 in the downlink direction; or (2) switch 113 or RU 106 in the uplink direction. If the Ethernet switch implementing method 1600 is switch 113, packets can be received from (1) BC 104, DU 105, CU 103, or aggregation switch 111 in the downlink direction; or (2) different switches 113 or RU 106 in the uplink direction.

[0207] Method 1600 is performed at optional step 1604, wherein at least one processor identifies at least one bit pattern for each of at least one RU 106 to which the packet is directed. Some RU 106 may host multiple carriers, for example, up to four. When an RU 106 hosts more than one carrier, the RU 106 implements a radio unit instance, or a module implemented by the processor, for each carrier, all of which share the same physical Ethernet port on the RU 106. Moreover, when an RU 106 hosts more than one carrier, each radio unit instance communicates with a different BC 104, DU 105, or CU 103, which assigns an RUid to the radio unit instance. Thus, multiple instance radio units 115 can be assigned multiple RUids, each RUid coming 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.

[0208] However, RUids assigned by different BC 104, DU 105, or CU 103 can overlap. Therefore, the RUid of a radio unit instance is associated with the IP address used by BC 104, DU 105, or CU 103 to communicate with the radio unit instance. In some examples, for each combination of (1) a radio unit instance implemented in RU 106 with which it communicates with an Ethernet switch; and (2) the IP address used by BC 104, DU 105, or CU 103 to communicate with the radio unit instance, at least one bit pattern is stored at the Ethernet switch. In other words, the RUid of a radio unit instance depends on the IP address used by BC 104, DU 105, or CU 103 to communicate with the radio unit instance. Alternatively, a single-instance radio unit 117 may have only a single RUid assigned to it, in which case the RUid does not depend on the IP address used by BC 104, DU 105, or CU 103 to communicate with it. In some examples, the bit pattern can be configured at runtime via a secure connection.

[0209] In the first configuration of optional step 1604, the Ethernet type 1346 of the packet is IP, and the bit pattern is associated with RU 106 identified by the destination IP address 1350 (e.g., a multicast IP address) in the IP packet 1330 of Ethernet packet 1334. In the second configuration of optional step 1604, the Ethernet type 1346 of the packet is a predetermined value (non-IP), and the bit pattern is associated with RU 106 identified by the destination MAC address in Ethernet packet 1334. In other words, the bit pattern for RU 106 can be selected based on the Ethernet type 1346 of the packet using either a multicast IP address or a multicast MAC address. Furthermore, if the Ethernet type is neither IP nor a predetermined value, the packet can be forwarded without looking up the RUid bitmask 602, as described below. Alternatively, the RUid of the radio instance can be associated with the IP address of BC 104, DU 105, or CU 103, which has been assigned the RUid.

[0210] Method 1600 is performed at step 1606, wherein at least one processor performs a deep packet inspection (DPI) on the packet to determine whether a RUid bitmask 602 is present in the packet, the RUid bitmask 602 indicating at least one RU 106 to which the packet points. The deep packet inspection may include hierarchical inspection / analysis of the packet to identify one or more fields in the packet. In some configurations, an I / Q packet 1308 (containing 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. Therefore, the deep packet inspection can be used to determine whether (and at what relative position / offset) the RUid bitmask 602 appears in the received packet.

[0211] Each RUid bitmask 602 can be a set of bits (e.g., each bit has a value of "1" or "0"), with a length at least equal to the number of RU 106 in C-RAN 100 (or a single sector of C-RAN 100). The bits in the RUid bitmask 602 within a packet are set based on whether the RU 106 associated with the bit is needed to decode and / or transmit information in the packet. For example, if all RU 106 are needed to decode and / or transmit the packet's payload (e.g., I / Q payload 1312), all bits are set to one. Alternatively, when a subset of RU 106 is needed to transmit the packet's payload, only the bits corresponding to that subset of RU 106 are set to one. The RUid bitmask 602 can be of any length suitable for accommodating the number of RU 106 in C-RAN 100, such as 32 bits, 64 bits, 128 bits, etc.

[0212] Alternatively, the RU identifier can be transmitted in other ways (instead of a bitmask with bits for each RU 106 in C-RAN 100). For example, the intended RU 106 can be identified using (1) an explicit RUid value in the packet; and / or (2) a variable-length RUid bitmap with a starting offset.

[0213] Method 1600 is performed at step 1608, wherein, when a RUid bitmask 602 is present in the packet, at least one processor transmits at least a portion of the packet to each of at least one RU 106 based on a comparison of the RUid bitmask 602 with the bit pattern of the corresponding RU 106. In some configurations, a bitwise AND operation is used to compare the RUid bitmask 602 in the packet with the bit pattern (from optional step 1604).

[0214] If the bitwise AND of the RUid bitmask 602 and the bit patterns of RU 106 is all zero (indicating that packet 1334 does not point to RU 106 at the specified IP address), then packet 1334 can be discarded by the Ethernet switch. In other words, when none of the bit patterns of at least one RU 106 has a set bit in the same bit position as the set bit in the RUid bitmask 602, at least one processor can discard the packet (without transmitting it to any RU 106).

[0215] On the other hand, if the bitwise AND of the RUid bitmask 602 and the bit pattern of RU 106 is not all equal to zero (indicating that packet 1334 points to RU 106 at the specified IP address), then packet 1334 (or a portion thereof) can be transmitted to RU 106. In other words, for each bit pattern having a set bit in the same bit position as the set bit in the RUid bitmask 602, at least one processor can transmit at least a portion of a packet to the RU 106 associated with that bit pattern.

[0216] 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. Communication may include unicast, broadcast, or multicast as described herein.

[0217] Method 1600 is performed at optional step 1610, wherein when the RUid bitmask 602 is not present in the packet, at least one processor transmits at least a portion of the packet to at least one RU 106 without comparing any RUid bitmask 602 with any bit pattern of the RU 106. The packet may be constructed according to different protocols, many of which will not include the RUid bitmask 602. For example, if Ethernet type 1346 is not IP or another reserved predetermined value, then the RUid bitmask 602 may not be included in the packet. Similarly, if Ethernet type 1346 is IP, but IP type 1352 is not UDP, then the RUid bitmask 602 may not be included in the packet. Similarly, if Ethernet type 1346 is IP and IP type 1352 is UDP, but the destination port 1356 is not in a predetermined range of port numbers, then the RUid bitmask 602 may not be included in the packet. If the deep packet inspection cannot recognize RUid bitmask 602 (because it is not included in the packet or for any other reason), the packet should still be transmitted.

[0218] Figure 17This is a flowchart illustrating method 1700 for performing deep packet inspection (DPI) on packets. Method 1700 can be executed by at least one processor in an Ethernet switch in fronthaul 116 of C-RAN 100. For example, the Ethernet switch can be aggregation switch 111 or switch 113, either of which implements DPI entity 109. The Ethernet switch can be communicatively coupled to BC 104, DU 105, CU 103 and / or RU 106 forming C-RAN 100 (or a part of C-RAN 100). Furthermore, in some configurations, the Ethernet switch implementing method 1700 can be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1700, it can be communicatively coupled to (1) at least one switch 113; and (2) BC 104, DU 105 and / or CU 103. Alternatively, if aggregation switch 111 implements method 1700, it can be communicatively coupled to (1) at least one RU 106; and (2) BC 104, DU 105, and / or CU 103. As another example, if switch 113 implements method 1700, it can be communicatively coupled to (1) aggregation switch 111; and (2) at least one RU 106. Other configurations are possible. In some examples, method 1700 is Figure 16 An example of the deep packet inspection (performed on the received packet) in step 1606 of method 1600.

[0219] For ease of explanation, it has been arranged in a roughly sequential manner. Figure 17 The flowchart shown is a box; however, it should be understood that this arrangement is merely exemplary and should be recognized that it is not consistent with method 1700 (and Figure 17 The processes associated with the boxes shown may occur in different orders (e.g., in the case that at least some of the processes associated with the boxes are executed in parallel and / or in an event-driven manner). Furthermore, for ease of interpretation, most standard exception handling is not described; however, it is to be understood that method 1700 is capable of and typically includes such exception handling.

[0220] Method 1700 begins at step 1702, wherein at least one processor determines the Ethernet type 1346 of Ethernet packet 1334. Ethernet packet 1334 may include (1) an Ethernet header 1336 having 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 the type of payload 1338, such as IP packet 1330 or a payload according to some other protocol. For example, Ethernet type 1346 may indicate that Ethernet payload 1338 includes IP packet 1330. In some configurations, predetermined values ​​(other than IP) may be reserved to indicate the inclusion (and byte offset) of RUid bitmask 602 in Ethernet packet 1334 that does not include IP packet 1330 or (e.g., within IP packet 1330) UDP datagrams. In other words, the reserved predetermined value, when included in the Ethernet Type 1346 field, can specifically indicate that the RUid bitmask 602 exists in the Ethernet payload 1338 at an offset of one byte from the Ethernet header 1336 or Ethernet Type 1346. This reserved predetermined value can be obtained by BC 104 (or DU 105 or CU 103), Ethernet switches 111, 113, DU 105, and / or RU 106 in the system.

[0221] Method 1700 is performed at step 1704, wherein at least one processor determines whether Ethernet type 1346 is IP. If not, method 1700 is performed at step 1705, wherein at least one processor determines whether Ethernet type 1346 is a reserved predetermined value, such as 0x4321. If yes, then method 1700 is performed at step 1718, wherein at least one processor determines the RUid bitmask 602 in Ethernet packet 1334 at a first predetermined offset, for example specifically at a first predetermined byte offset from Ethernet header 1336 or Ethernet type 1346. In other words, in response to determining that Ethernet type 1346 is a reserved predetermined value, at least one processor can interpret a set of bits (offset from the Ethernet type 1346 field) as the RUid bitmask 602. If Ethernet type 1346 is not IP or a reserved predetermined value, method 1700 proceeds at step 1706, where at least one processor exits method 1700 without determining RUid bitmask 602 (after which at least a portion of the packet is transmitted without comparing RUid bitmask 602 with any bit pattern).

[0222] However, if Ethernet type 1346 is IP, then method 1700 proceeds at step 1708, wherein at least one processor determines IP type 1352 in IP packet 1330. 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. IP type 1352 indicates the type 1352 of IP payload 1340. For example, IP type 1352 may indicate that IP payload 1340 includes UDP datagrams. Alternatively, IP type 1352 may indicate that IP payload 1340 includes data in some other protocol (e.g., Transmission Control Protocol (TCP)). Method 1700 proceeds at step 1710, wherein at least one processor determines whether IP type 1352 indicates UDP. If IP type 1352 is not UDP, then method 1700 is performed at step 1706, where at least one processor exits method 1700 without determining RUid bitmask 602.

[0223] If IP type 1352 is UDP, then method 1700 proceeds at step 1712, wherein at least one processor determines the destination port 1356 in the UDP datagram. The UDP datagram (in IP payload 1340) may include a UDP header 1333 having a source port 1354 and / or a destination port 1356; and (UDP payload 1328). Some UDP port numbers may be reserved for certain standard functions, while others may be customized for specific application purposes. Method 1700 proceeds at step 1714, wherein 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 specifically identify whether the RUid bitmask 602 exists at a certain byte offset from the UDP header 1356 or the UDP destination port 1356. In other words, (1) the UDP port number falls within the predetermined range or (2) the UDP destination port 1356 is equal to the predetermined UDP port number. Specifically, the RUid bitmask 602 will be located in the UDP payload 1328 at an offset of a certain byte from the UDP header 1356 or the UDP destination port 1356.

[0224] If the UDP destination port 1356 (1) falls within a predetermined range of UDP port numbers or (2) is equal to a predetermined UDP port number, then method 1700 is performed at step 1716, wherein 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 that the UDP destination port 1356 (1) falls within a predetermined range of UDP port numbers or (2) is equal to a predetermined UDP port number, at least one processor may interpret a set of bits (specifically, offset from UDP header 1333 or UDP destination port 1356) as the RUid bitmask 602. If the UDP destination port 1356 does not (1) fall within a predetermined range of UDP port numbers or (2) is equal to a predetermined UDP port number, then method 1700 is performed at step 1706, wherein at least one processor exits method 1700 without determining the RUid bitmask 602.

[0225] IP / UDP DPI pseudocode example

[0226] The following pseudocode is an exemplary implementation of DPI using IP / UDP:

[0227]

[0228]

[0229] Where ETH_TYPE is Ethernet type 1346; IP_TYPE is IP type 1352; Curr_RUID is the bit pattern of RU 106; RP_RUID is the RUid of RU 106 indicated by the multicast IP address in Ethernet packet 1334; and Packet_RUID is the RUid bitmask 602.

[0230] The following pseudocode is an exemplary implementation of DPI based on Ethernet packet transmission (without using IP / UDP):

[0231]

[0232] Where X is a reserved predetermined value that indicates the inclusion of RUid bitmask 602 in Ethernet packet 1334, which does not include IP packet 1330 or UDP datagram.

[0233] Forwarding rules

[0234] Figure 18This is a flowchart illustrating a method for establishing multicast rules in an Ethernet switch. Method 1800 can be implemented by each of the following radio unit instances: an Ethernet switch, at least one BC 104 (or CU 103 or DU 105), and RU 106. For example, the Ethernet switch can be an aggregation switch 111 or a switch 113, either of which implements DPI entity 109. The Ethernet switch can be communicatively coupled to BC 104, DU 105, CU 103, and / or RU 106 forming a C-RAN 100 (or a portion of a C-RAN 100). Furthermore, in some configurations, the Ethernet switch implementing method 1800 can be communicatively coupled to at least one other switch. For example, if aggregation switch 111 implements method 1800, it can be communicatively coupled to (1) at least one switch 113; and (2) BC 104, DU 105, and / or CU 103. Alternatively, if the aggregation switch 111 implements method 1700, it can be communicatively coupled to (1) at least one RU 106; and (2) BC 104, DU 105 and / or CU 103. As another example, if the switch 113 implements method 1800, it can be communicatively coupled to (1) the aggregation switch 111; and (2) at least one RU 106. Other configurations are possible.

[0235] For ease of explanation, it has been arranged in a roughly sequential manner. Figure 18 The flowchart shown is a box; however, it should be understood that this arrangement is merely exemplary and should be recognized that it is not consistent with method 1800 (and Figure 18 The processes associated with the boxes shown may occur in different orders (e.g., in the case that at least some of the processes associated with the boxes are executed in parallel and / or in an event-driven manner). Furthermore, for ease of interpretation, most standard exception handling is not described; however, it is to be understood that method 1800 is capable of and typically includes such exception handling.

[0236] Method 1800 begins at step 1802, where the RU (e.g., upon power-up) initiates the discovery process and sends Ethernet broadcast packets. At step 1804, each Radio Unit Instance (RPI) is assigned an RUid by one or more BC 104 (or DU 105 or CU 103), for example, via a SOAP connection to one of the RPIs. Additionally, the E-UTRA Absolute Radio Channel Number (EARFCN), individual L1 and Ethernet parameters of the RPIs can be configured. At step 1806, each RPI informs the Ethernet switch of its range of downlink multicast IP addresses of interest, its range of UDP port numbers of interest, and its RUID (32 / 64-bit value). In some examples, filtering rules (e.g., forwarding rules) are set for each RPI, for example, using IGMP to join a multicast group. If the switch receives a request to join, it updates its tables (e.g., routing tables). At step 1808, the Ethernet switch periodically polls each RPI to determine if its rule still exists. The RU responds to retain the rule. At step 1810, when the connection to BC 104 (or CU 103 or DU105) is lost or the carrier is removed, the RU will notify the Ethernet switch to release the rule it has set. If the Ethernet switch's periodic polling does not respond, it will delete the rule.

[0237] The methods and techniques described herein can be implemented in digital electronic circuits, or using programmable processor firmware, software, or a combination thereof (e.g., a dedicated or 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 executable by the programmable processor. Processes embodying these techniques can be performed by a programmable processor executing instruction programs to perform a desired function by manipulating input data and generating appropriate output. These techniques can advantageously be implemented in one or more programs executable on a programmable system including at least one input device, at least one output device, and at least one programmable processor coupled to receive data and instructions from and transmit data and instructions to a data storage system. Generally, the processor receives instructions and data from read-only memory and / or random access memory. For example, in the case where a computing device is described as performing an action, the computing device may use at least one processor that executes instructions stored in at least one memory to perform this action. Storage devices suitable for tangibly representing computer program instructions and data include all forms of non-volatile memory, such as semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; hard disks, such as internal hard disks and removable hard disks; magneto-optical disks; and DVDs. Any of the foregoing may be supplemented or incorporated into them by specially designed application-specific integrated circuits (ASICs).

[0238] the term

[0239] The following provides brief definitions of the terms, abbreviations and phrases used throughout this application.

[0240] The term "determine" and its variations can include calculation, extraction, generation, operation, processing, derivation, modeling, research, searching (e.g., searching in a table, database, or another data structure), ascertainment, etc. Furthermore, "determine" can also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Additionally, "determine" can include parsing, selecting, choosing, building, etc.

[0241] Unless otherwise explicitly stated, the phrase “based on” does not mean “based on only.” In other words, the phrase “based on” describes both “based on only” and “based on at least”. Additionally, 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” can mean “A alone,” “B alone,” “C alone,” “A and B,” “A and C,” “B and C,” or “A, B, and C.”

[0242] The terms “connection,” “coupling,” and “communicatively coupled,” and related terms, may refer to a direct or indirect connection. If the specification indicates that “may,” “can,” “could,” or “might” includes a component or feature or has a characteristic, then it is not necessary to include that particular component or feature or to have that characteristic.

[0243] The term "response" or "in response to" can indicate that an action has been performed, either fully 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).

[0244] The methods disclosed herein include one or more steps or actions for implementing the described methods. Unless the specific order of the steps or actions is required for the proper functioning of the described methods, the order and / or use of particular steps and / or actions may be modified without departing from the scope of the claims.

[0245] In summary, this disclosure provides novel systems, methods, and arrangements for fronthaul interfaces used with C-RAN. While detailed descriptions of one or more configurations of this disclosure have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without departing from the spirit of this disclosure. For example, while the above-described configurations refer to specific features, functions, processes, components, elements, and / or structures, the scope of this disclosure also includes configurations having different combinations of features, functions, processes, components, elements, and / or structures, as well as configurations excluding all described features, functions, processes, components, elements, and / or structures. Therefore, the scope of this disclosure is intended to cover all such alternatives, modifications, and variations, as well as all their equivalents, that fall within the scope of the claims. Consequently, the above description should not be considered limiting.

[0246] Exemplary embodiments

[0247] Example 1 includes a cloud radio access network (C-RAN) comprising: a plurality of remote units, each remote unit 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, wherein the fronthaul network is configured to implement a plurality of multicast groups, each of the multicast groups comprising a corresponding group of the remote units, the central unit being configured to: determine a dataset to be transmitted via the fronthaul network to a corresponding subset of the remote units; determine a mapping of each of the dataset to a corresponding one of the subsets of the remote units; and for each of the datasets, if at least one of the multicast groups completely contains a corresponding subset of the remote units mapped to the dataset, transmit the dataset via the fronthaul network to the corresponding subset of the remote units mapped to the dataset by multicasting the dataset to the multicast group that best matches the corresponding subset of the remote units mapped to the dataset.

[0248] Example 2 includes the C-RAN according to Example 1, wherein, for each of the datasets, the multicast group that best matches the corresponding subset of remote units mapped to the dataset includes a multicast group that completely contains the corresponding subset of remote units mapped to the dataset and includes a minimum total number of remote units.

[0249] Example 3 includes a C-RAN according to any one of Examples 1-2, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth-generation communication system.

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

[0251] Example 5 includes a C-RAN according to any one of Examples 1-4, wherein the central unit is configured to add a corresponding indicator to each dataset based on the mapping, wherein each corresponding indicator indicates each remote unit to which the corresponding dataset points.

[0252] Example 6 includes the C-RAN according to Example 5, wherein each corresponding indicator is a corresponding bitmask including a plurality of bit positions, wherein each bit position corresponds to a corresponding remote unit among the plurality of remote units.

[0253] Example 7 includes a C-RAN according to any one of Examples 5-6, wherein the central unit is configured to transmit the dataset to the corresponding subset of the remote units via the fronthaul network for each of the datasets if no multicast group matches the corresponding subset of the remote units mapped to the dataset.

[0254] Example 8 includes a C-RAN according to any one of Examples 1-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 an updated plurality of multicast groups are periodically defined and the fronthaul network is configured to implement the updated plurality of multicast groups.

[0255] Example 9 includes the C-RAN according to Example 8, wherein the C-RAN is configured such that: each updated plurality of multicast groups are defined based on the most recent fronthaul traffic flow and / or the nearest location of the user equipment and the remote unit for serving the user equipment.

[0256] Example 10 includes the C-RAN according to Example 9, wherein the location of the user equipment and the remote unit for serving the user equipment is determined by one or more of the following: sounding reference signal (SRS), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), and / or physical random access channel (PRACH) uplink measurements performed on each remote unit; preferred beam information determined by the user equipment; and channel state information reference signal (CSI-RS) measurement reports received from the user equipment.

[0257] Example 11 includes a C-RAN according to any one of Examples 8-10, and further includes a management system, wherein at least one of the central unit and the management system is configured to define the initial and each updated plurality of multicast groups, notify one or more of the management system, the central unit and the remote unit of the defined initial and each updated plurality of multicast groups, and enable the fronthaul network to implement the defined initial and each updated plurality of multicast groups.

[0258] Example 12 includes the C-RAN according to Example 11, wherein management plane (M-plane) communications are used to perform at least one of the following operations: notifying one or more of the management system, central unit, and remote unit of a defined initial and each updated plurality of multicast groups; and enabling the fronthaul network to implement the defined initial and each updated plurality of multicast groups.

[0259] Example 13 includes the C-RAN according to Example 12, wherein the M-plane communication includes O-RAN M-plane communication.

[0260] Example 14 includes a method performed by a central unit in a cloud radio access network (C-RAN), the cloud radio access network further including a plurality of remote units, each remote unit 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, wherein the fronthaul network is configured to implement a plurality of multicast groups, each of the multicast groups including a corresponding group of the remote units, the method comprising: determining a dataset to be transmitted to a corresponding subset of the remote units via the fronthaul interface; determining a mapping of each of the datasets to a corresponding one of the subsets of the remote units; and for each of the datasets, if at least one of the multicast groups matches a corresponding subset of the remote units mapped to the dataset, transmitting the dataset via the fronthaul network to the corresponding subset of the remote units by multicasting the dataset to the multicast group that best matches the corresponding subset of the remote units mapped to the dataset.

[0261] Example 15 includes the method according to Example 14, wherein, for each of the datasets, the multicast group that best matches the corresponding subset of remote units mapped to the dataset includes a multicast group that completely contains the corresponding subset of remote units mapped to the dataset and includes a minimum total number of remote units.

[0262] Example 16 includes a method according to any one of Examples 14-15, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth-generation communication system.

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

[0264] Example 18 includes the method according to any one of Examples 14-17, further comprising: adding a corresponding indicator to each dataset based on the mapping, wherein each corresponding indicator indicates each remote unit to which the corresponding dataset points.

[0265] Example 19 includes the method according to Example 18, wherein each corresponding indicator is a corresponding bitmask including a plurality of bit positions, wherein each bit position corresponds to a corresponding remote unit among the plurality of remote units.

[0266] Example 20 includes the method according to any one of Examples 18-19, further comprising: for each of the datasets, if no multicast group matches a corresponding subset of remote units mapped to the dataset, transmitting the dataset over the fronthaul network to the corresponding subset of the remote units by broadcasting the dataset.

[0267] Example 21 includes a method according to any one of Examples 14-20, wherein: an initial plurality of multicast groups are defined for the C-RAN, wherein the initial plurality of multicast groups are implemented by the fronthaul network; and an updated plurality of multicast groups are periodically defined for the C-RAN, wherein the updated plurality of multicast groups are implemented by the fronthaul network.

[0268] Example 22 includes the method according to Example 21, wherein multiple multicast groups for each update are defined based on the most recent fronthaul traffic flow, the nearest location of the user equipment and the remote unit for serving the user equipment, or some combination thereof.

[0269] Example 23 includes the method according to Example 22, wherein the location of the user equipment and the remote unit for serving the user equipment is determined by one or more of the following: sounding reference signal (SRS), physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH) and / or physical random access channel (PRACH) uplink measurements performed on each remote unit; preferred beam information determined by the user equipment; and channel state information reference signal (CSI-RS) measurement reports received from the user equipment.

[0270] Example 24 includes a method according to any one of Examples 21-23, wherein at least one of the central unit and the management system defines the initial and each updated plurality of multicast groups, notifies one or more of the management system, the central unit and the remote unit of the defined initial and each updated plurality of multicast groups, and enables the fronthaul network to implement the defined initial and each updated plurality of multicast groups.

[0271] Example 25 includes a method according to any one of Examples 21-24, wherein management plane (M-plane) communication is used to perform at least one of the following operations: notifying one or more of the management system, central unit, and remote unit of an initial and each updated plurality of multicast groups defined; and enabling the fronthaul network to implement the defined initial and each updated plurality of multicast groups.

[0272] Example 26 includes the method according to Example 25, wherein the M-plane communication includes O-RAN M-plane communication.

[0273] Example 27 includes a cloud radio access network (C-RAN) comprising: a plurality of remote units, each remote unit 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 being communicatively coupled to the central unit via the fronthaul network; wherein the central unit is configured to: determine a dataset to be transmitted to the plurality of remote units via the fronthaul network; determine a mapping from each of the datasets to at least one of the plurality of remote units; add a corresponding indicator to a packet of each dataset based on the mapping, wherein each corresponding indicator indicates the corresponding packet and each remote unit to which the dataset points; and transmit the packets of the datasets, each packet of the dataset having a corresponding indicator, to the entity via the fronthaul network; wherein the entity is configured to perform deep packet inspection on each of the packets to determine each remote unit to which the packet points, and transmit the packet to each remote unit to which the packet points via the fronthaul network.

[0274] Example 28 includes the C-RAN according to Example 27, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth-generation communication system.

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

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

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

[0278] Example 32 includes a C-RAN according to any one of Examples 27-31, wherein each corresponding indicator is a corresponding bitmask including a plurality of bit positions, wherein each bit position corresponds to a corresponding remote unit among the plurality of remote units.

[0279] Example 33 includes a method performed in a cloud radio access network (C-RAN) comprising a plurality of remote units, each remote unit configured to exchange radio frequency signals with at least one user equipment (UE), the C-RAN further 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 being communicatively coupled to the central unit and the remote units via the fronthaul network. The method includes: determining a dataset to be transmitted to the plurality of remote units via the fronthaul network; determining a mapping from each of the datasets to at least one of the plurality of remote units; adding a corresponding indicator to a packet of each dataset based on the mapping, wherein each corresponding indicator indicates the corresponding packet and each remote unit to which the dataset points; transmitting the packets of the datasets, each packet having a corresponding indicator, to the entity via the fronthaul network; and having the entity perform deep packet inspection on each of the packets to determine each remote unit to which the packet points, and transmitting the packet to each remote unit to which the packet points via the fronthaul network.

[0280] Example 34 includes the method according to Example 33, wherein the central unit is a distributed unit (DU) configured to operate in a 3GPP fifth-generation communication system.

[0281] Example 35 includes a method according to any one of Examples 33-34, wherein the central unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

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

[0283] Example 37 includes a method according to any one of Examples 33-36, wherein the entity includes a Forward Manager (FHM).

[0284] Example 38 includes the method according to any one of Examples 33-37, wherein each corresponding indicator is a corresponding bitmask including a plurality of bit positions, wherein each bit position corresponds to a corresponding remote unit among the plurality of remote units.

Claims

1. A system comprising: Multiple remote units (RUs), each configured to exchange radio frequency signals with at least one user equipment (UE); A centralized unit having circuitry and communicatively coupled to the plurality of remote units via a fronthaul network; and An entity having at least one processor configured to perform deep packet inspection, the entity being communicatively coupled to the centralized unit via the fronthaul network; The centralized unit is configured to transmit datasets across the fronthaul network in packets, each dataset being mapped to at least one of the plurality of remote units, and each packet including a corresponding indicator indicating each remote unit to which the associated packet is targeted, wherein each indicator includes a plurality of bit positions, wherein each bit position is mapped to a different remote unit among the plurality of remote units. The entity is configured to perform deep packet inspection on packets to determine each remote unit to which the packet is targeted without decoding all segments of the packet, and to transmit each packet to each remote unit to which the packet is targeted via the fronthaul network.

2. The system as claimed in claim 1, wherein, The centralized unit is a distributed unit (DU) configured to operate in the 3GPP fifth-generation communication system.

3. The system as described in claim 1, wherein, The centralized unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

4. The system as claimed in claim 1, wherein, The entity includes one or more switches in the fronthaul network.

5. The system as claimed in claim 1, wherein, The entity includes the Forward Manager (FHM).

6. The system as claimed in claim 1, wherein, The fronthaul interface is a switched Ethernet network.

7. The system as claimed in claim 1, wherein, The multiple remote units and the centralized unit are part of the same cell.

8. The system as claimed in claim 1, wherein, Multiple remote units within the same cell transmit to different UEs at the same time and at the same frequency.

9. The system of claim 5, wherein, The entity is configured to combine uplink packet streams from the plurality of remote units before sending them to the centralized unit.

10. The system of claim 1, wherein, The plurality of remote units perform Layer 1 processing on the air interface used for communicating with at least one UE.

11. A method performed in a system comprising a plurality of remote units configured to exchange radio frequency signals with at least one user equipment (UE), the system further comprising a centralized unit communicatively coupled to the plurality of remote units via a fronthaul network, and an entity configured to perform deep packet inspection, the entity being communicatively coupled to the centralized unit and the plurality of remote units via the fronthaul network, the method comprising: Data sets are transmitted from the centralized unit across the fronthaul network in packets to the plurality of remote units, each data set being mapped to at least one of the plurality of remote units, and each packet including a corresponding indicator indicating each remote unit to which the associated packet is targeted, wherein each indicator includes a plurality of bit positions, wherein each bit position is mapped to a different remote unit among the plurality of remote units. and The entity performs a deep packet inspection on the packets to determine each remote unit to which the packet is addressed without decoding all segments of the packet, and transmits each packet to each remote unit to which the packet is addressed via the fronthaul network.

12. The method of claim 11, wherein, The centralized unit is a distributed unit (DU) configured to operate in the 3GPP fifth-generation communication system.

13. The method of claim 11, wherein, The centralized unit is a baseband controller configured to operate in a 3GPP Long Term Evolution (LTE) communication system.

14. The method of claim 11, wherein, The entity includes one or more switches in the fronthaul network.

15. The method of claim 11, wherein, The entity includes the Forward Manager (FHM).

16. The method of claim 11, wherein, The fronthaul interface is a switched Ethernet network.

17. The method of claim 11, wherein, The multiple remote units and the centralized unit are part of the same cell.

18. The method of claim 11, wherein, Multiple remote units within the same cell transmit to different UEs at the same time and at the same frequency.

19. The method of claim 15, further comprising combining uplink packet streams from the plurality of remote units at the entity before transmission to the centralized unit.

20. The method of claim 11, further comprising performing Layer 1 processing on the air interface for communicating with at least one UE at the plurality of remote units.

Images