Patent Description:
A centralized radio access network (C-RAN) can be used to implement base station functionality for providing wireless service to various items of user equipment (UE). Typically, for each cell implemented by the C-RAN, one or more baseband units (BBUs) (also referred to here as "baseband controllers" or simply "controllers") interact with multiple remote units. Each baseband controller is coupled to the remote units over front-haul communication links or a front-haul network.

Historically, data for the wireless interface was communicated between the baseband controller and the remote units over the front-haul as time-domain in-phase and quadrature (I/Q) data (for example, using a front-haul and data that complies with the Common Public Radio Interface (CPRI) specification). When this is done, the processing for the wireless interface is "split" so that the baseband controller would perform all digital baseband processing for Layer-<NUM> of the wireless interface, while the remote units would perform the basic radio frequency (RF) functions such as digital up-conversion (DUC) and digital-to-analog (D/A) conversion (in the downlink) and digital down-conversion (DDC) and analog-to-digital (A/D) conversion (in the uplink), and analog functions (for example, any analog frequency conversion, filtering, and amplification).

However, using the functional split between the baseband controller and remote unit noted above results in data being communicated between the baseband controller and the remote units as time-domain I/Q data, which requires a relatively high amount of bandwidth and low-latency from the front-haul.

While other functional splits between the baseband controller and the remote units have been proposed and used, the functional split is typically fixed. That is, the baseband controller and remote units are all designed to use single functional split. Background art is represented by the <CIT> and <CIT>.

One embodiment is directed to a system according to independent claim <NUM>.

Another embodiment is directed to a method according to independent claim <NUM>.

The details of various embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will become apparent from the description, the drawings, and the claims.

<FIG> is a block diagram illustrating one exemplary embodiment of a centralized radio access network (C-RAN) <NUM>.

The C-RAN <NUM> (also referred to here as a "C-RAN system" <NUM> or just "system" <NUM>) shown in <FIG> comprises, for each cell <NUM> served by the C-RAN <NUM>, a baseband controller <NUM> and multiple remote units (RUs) <NUM>. Each remote unit <NUM> is remotely located from the baseband unit <NUM>. Also, in this exemplary embodiment, at least one of the remote units <NUM> is remotely located from at least one other remote unit <NUM>. Each remote unit <NUM> includes or is coupled to one or more antennas <NUM> via which downlink RF signals are radiated to various items of user equipment (UE) <NUM> and via which uplink RF signals transmitted by UEs <NUM> are received.

The system <NUM> is coupled to a core network <NUM> of the associated wireless network operator over an appropriate back-haul. Also, each baseband controller <NUM> is communicatively coupled to the remote units <NUM> served by it using a front-haul network <NUM>. The baseband controllers <NUM> and the remote units <NUM> include one or more network interfaces (not shown) in order to enable the baseband controllers <NUM> and remote units <NUM> to communicate over the front-haul network <NUM>.

In one implementation, the front-haul <NUM> that communicatively couples each baseband controller <NUM> to the remote units <NUM> is implemented using a switched ETHERNET network. In such an implementation, each baseband controller <NUM> and remote unit <NUM> includes one or more ETHERNET interfaces for communicating over the switched ETHERNET network used for the front-haul <NUM>. However, it is to be understood that the front-haul between each baseband controller <NUM> and the remote units <NUM> served by it can be implemented in other ways.

In the exemplary embodiment shown in <FIG>, a management system <NUM> is communicatively coupled to the controllers <NUM> and remote units <NUM>, for example, via the Internet (or another network used to implement the back-haul to the core network <NUM> and an Ethernet network (for example, an Ethernet network used to implement the front-haul network <NUM>). Also, in some implementations, the management system <NUM> sends and receives management communications to and from the controllers <NUM>, each of which in turn forwards relevant management communications to and from the remote units <NUM>.

Generally, for each cell <NUM> implemented by the C-RAN <NUM>, the corresponding based controller <NUM> serving the cell <NUM> performs the LAYER-<NUM> and LAYER-<NUM> functions for the particular wireless interface used for that cell <NUM>. Also, for each cell <NUM> implemented by the C-RAN <NUM>, the corresponding based controller <NUM> serving the cell <NUM> performs some of the LAYER-<NUM> functions for the particular wireless interface used for that cell <NUM>. Each of the remote units <NUM> serving that cell <NUM> perform the LAYER-<NUM> functions not performed by the baseband controller <NUM> as well as implementing the basic RF functions.

In the particular embodiment shown in <FIG>, the C-RAN <NUM> is configured to use one or more Fifth Generation (<NUM>) wireless interfaces and associated protocols. However, it is to be understood that other embodiments can be implemented in other ways -- for example, the C-RAN <NUM> can be configured to use other wireless interfaces and protocols such as the Long-Term Evolution (LTE) wireless interfaces and protocols and/or to support multiple wireless interfaces and protocols.

In the exemplary embodiment shown in <FIG>, the functions of the baseband controller <NUM> are partitioned into a Central Unit (CU) <NUM> and a Distributed Unit (DU) <NUM> consistent with the architecture defined in the <NUM> standards.

In this embodiment, the CU <NUM> implements the Layer-<NUM> Control Plane functions <NUM> and the Layer-<NUM> User Plane functions <NUM> for the wireless interface. In this exemplary embodiment, the Layer-<NUM> Control Plane functions <NUM> include Stream Control Transmission Protocol (SCTP) functions, S1 Application Protocol (S1-AP) functions for communicating with the core network <NUM> (which in this example comprises an Evolved Packet Core (EPC) core network), and X2 Application Protocol (X2-AP) functions for communicating with other base stations. The Layer-<NUM> Control Plane functions <NUM> also include Radio Resource Management (RRM) functions, Self-Organizing Network (SON) functions, Radio Environment Map (REM) functions, and Radio Resource Control (RRC) functions.

In this exemplary embodiment, the Layer-<NUM> User Plane functions <NUM> include evolved General Packet Radio Service (GPRS) Tunneling Protocol (eGTP) functions.

In this exemplary embodiment, the CU <NUM> also implements less time critical Layer-<NUM> User Plane functions <NUM> for the wireless interface. The less time-critical Layer-<NUM> User Plane functions <NUM> implemented in the CU <NUM> include Packet Data Convergence Protocol (PDCP) functions.

In this exemplary embodiment, the CU <NUM> also implements various management and configuration functions -- including Operation, Administration, and Management (OAM) functions <NUM> for managing the baseband controller <NUM> and communicating with the management system <NUM> and a timing subsystem <NUM> configured to synchronize the local clocks of other nodes in the C-RAN <NUM> to a master clock. In the embodiment shown in <FIG>, the timing subsystem <NUM> is configured to use the Precision Time Protocol (PTP) to do this.

The various management and configuration functions implemented by the CU <NUM> also comprise remote unit interface management functions <NUM> that are configured to discover what functional splits and associated interfaces the various remote units <NUM> support, decide which split and associated interface to use, configure the Layer-<NUM> functions in the baseband controller <NUM> and remote units <NUM> to use the selected split and interface, and configure the DU-RU application layer protocols in the baseband controller <NUM> and remote units <NUM> accordingly.

In this embodiment, the DU <NUM> implements the Layer-<NUM> Control Plane functions <NUM> for the wireless interface as well as time-critical Layer-<NUM> User Plane functions <NUM> for the wireless interface. The Layer-<NUM> Control Plane functions <NUM>, in this example, include a MAC scheduler ecosystem. The time-critical Layer-<NUM> User Plane functions <NUM>, in this example, include Radio Link Control (RLC) functions and MAC functions.

The DU <NUM> also implements some of the Layer-<NUM> functions <NUM> for the wireless interface as well as Femto Application Platform Interface (FAPI) functions <NUM> that provide an interface between the Layer-<NUM> functions <NUM> and <NUM> and Layer-<NUM> functions <NUM>. The DU <NUM> also implements DU-RU Application Protocol functions <NUM> that provide an interface between the DU <NUM> and the remote units <NUM>.

Each remote unit <NUM> implements the Layer-<NUM> functions <NUM> for the wireless interface that are not implemented in the DU <NUM>. Each RU <NUM> also implements the basic RF and antenna functions <NUM> for the wireless interface. In the exemplary embodiment shown in <FIG>, the basic RF and antenna functions <NUM> include digital up-conversion (DUC) for the downlink and digital down-conversion (DDC) for the uplink, digital-to-analog conversion for the downlink and analog-to-digital conversion for the uplink and analog frequency conversion (implemented in a RF integrated circuit (RFIC) in this example), a power amplifiers (PA) for the downlink and a low-noise amplifier (LNA) for the uplink, and any beam steering functions.

Each remote unit <NUM> also implements DU-RU Application Protocol functions <NUM> that provide an interface between the DU <NUM> and the remote units <NUM>. Each remote unit <NUM> also includes Operation, Administration, and Management (OAM) functions <NUM> for managing that remote unit <NUM> and communicating with the management system <NUM> and the OAM functions <NUM> in the serving baseband controller <NUM>. In the exemplary embodiment shown in <FIG>, some of the remote units <NUM> also implement a timing client <NUM> configured to synchronize the clock of the remote unit <NUM> to the master clock used for in the C-RAN <NUM>. In the embodiment shown in <FIG>, the timing client <NUM> is configured to use the PTP to do this.

The 3GPP has promulgated <NUM> specifications identifying various options for a functional split processing between the processing performed in the baseband controller and the processing performed in the remote units. In the embodiments described here, the baseband controller <NUM> is configured to support various functional splits including Option <NUM> (where the functional split occurs at various places within the Layer-<NUM> digital baseband processing chain) and Option <NUM> (where the functional split occurs at the interface between the Layer-<NUM> digital baseband processing chain and the basic RF functions).

In order to support the various intra-Layer-<NUM> functional splits (that is, the various Option <NUM> splits), the Layer-<NUM> functions <NUM> and <NUM> are partitioned into upper Layer-<NUM> functions <NUM>, lower Layer-<NUM> functions <NUM>, and lowest Layer-<NUM> functions <NUM>. In this example, the upper Layer-<NUM> functions <NUM> comprise coding, rate matching, scrambling, modulation, layer mapping, and precoding in the downlink and channel estimation, diversity combining, equalization, de-modulation, de-scrambling, rate matching, and decoding in the uplink. The lower functions <NUM>, in this example, comprise resource element mapping and beamforming port expansion in the downlink and port reduction and resource element de-mapping in the uplink. The lowest functions <NUM>, in this example, comprise the inverse Fast Fourier Transform (iFFT) and Cyclic Prefix (CP) insertion in the downlink and CP removal and the Fast Fourier Transform (FFT) in the uplink.

In one example, the C-RAN <NUM> is configured to provide <NUM> wireless service using one or more millimeter wave (mmWave) RF carriers. In such a configuration, relatively higher throughput will typically be provided via the wireless interface and, as a result, it may only be possible to perform the lowest Layer-<NUM> functions <NUM> in the remote units <NUM>. As a consequence, in such a configuration, the functional split between the baseband controller <NUM> and the remote units <NUM> would need to occur between the lower Layer-<NUM> functions <NUM> and the lowest Layer-<NUM> functions <NUM>, with the upper and lower Layer-<NUM> functions <NUM> and <NUM> being performed in the baseband controller <NUM> and only the lowest Layer-<NUM> functions <NUM> being performed in the remote units <NUM>. In <FIG>, one of the remote units <NUM> (individually referenced in <FIG> as "remote unit <NUM>-A") is shown as being configured to use this functional split between the baseband controller <NUM> and the remote units <NUM>.

In another example, the C-RAN <NUM> is configured to provide <NUM> wireless service using the sub-<NUM> Gigahertz (GHz) (for example, using Citizens Broadband Radio Service (CBRS) shared spectrum or re-farmed LTE spectrum). Such a configuration may not have the same throughput as the mmWave configuration and, as a result, it may be possible to perform both the lower and lowest Layer-<NUM> functions <NUM> and <NUM> for the wireless interface in the remote units <NUM>. As a consequence, in such a configuration, the functional split between the baseband controller <NUM> and the remote units <NUM> can occur between the upper Layer-<NUM> functions <NUM> and the lower Layer-<NUM> functions <NUM>, with only the upper Layer-<NUM> functions <NUM> being performed in the baseband controller <NUM> and both the lower and lowest Layer-<NUM> functions <NUM> and <NUM> being performed in the remote units <NUM>. Doing so can reduce the demands on the front-haul network <NUM> since the data communicated between the baseband controller <NUM> and the remote units <NUM> over the front-haul network <NUM> in this configuration can be communicated in a more bandwidth-efficient format using this functional split than in the mmWave configuration. In <FIG>, one of the remote units <NUM> (individually referenced in <FIG> as "remote unit <NUM>-B") is shown as being configured to use this functional split between the baseband controller <NUM> and the remote units <NUM>.

The DU-RU Application Protocol functions <NUM> can be configured to support one or more interfaces between the baseband controller <NUM> and the remote units <NUM> including, for example, a proprietary interface and/or a standardized interface. In the example shown in <FIG>, the DU-RU Application Protocol functions <NUM> in a first one of the remote units <NUM> (individually referenced in <FIG> as remote unit <NUM>-A) supports only a standardized interface between the baseband controller <NUM> and that remote unit <NUM>, a second one of the remote units <NUM> (individually referenced in <FIG> as remote unit <NUM>-B) supports only a proprietary interface between the baseband controller <NUM> and that remote unit <NUM>, and a third one of the remote units <NUM> (individually referenced in <FIG> as remote unit <NUM>-C) supports both a proprietary interface and a standardized interface between the baseband controller <NUM> and that remote unit <NUM>.

<FIG> comprises a high-level flowchart illustrating one exemplary embodiment of a method <NUM> of configuring an interface between a baseband controller and at least one remote unit of a C-RAN. The embodiment of method <NUM> shown in <FIG> is described here as being implemented by the baseband controller <NUM> (for example, in the remote unit interface management functions <NUM>) for use in the C-RAN <NUM> described above in connection with <FIG>, though it is to be understood that other embodiments can be implemented in other ways. For example, the processing associated with method <NUM> can also be implemented (at least in part) in another node that is a part of the C-RAN <NUM> or external to the C-RAN <NUM> (for example, by the management system <NUM> or one of the remote units <NUM>).

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

Method <NUM> can be performed, for example, whenever the configuration of the C-RAN <NUM> changes (for example, when the C-RAN <NUM> is powered on and whenever a new baseband controller <NUM> or remote unit <NUM> is added to the C-RAN <NUM> or restarted). Method <NUM> can also be performed in response to other events (for example, in response to a significant change in the front-haul bandwidth or latency or a significant change in a key performance indicator associated with the cell <NUM>).

Method <NUM> comprises determining which functional splits between the baseband controller <NUM> and the remote unit <NUM> each remote unit <NUM> supports (block <NUM>).

One way the baseband controller <NUM> can be configured to do this is by using a discovery protocol and process. For example, in some embodiments, the baseband controllers <NUM> and remote units <NUM> are configured to use a discovery protocol and process in order to discover baseband controllers <NUM> and remote units <NUM> and to home the remote units <NUM> to a serving baseband controller <NUM>. In these embodiments, the discovery process comprises each remote unit <NUM> sending discovery messages for reception by any baseband controllers <NUM> in the C-RAN <NUM> via the front-haul <NUM>. The discovery messages announce the presence of that remote unit <NUM>. Each baseband controller <NUM> that is serving a particular cell <NUM> can be configured with a list of remote units <NUM> that have been assigned to that cell <NUM>. This list is also referred to here as the "whitelist. " When the baseband controller <NUM> serving a particular cell <NUM> receives a discovery message from a remote unit <NUM> that is included on the whitelist for the cell <NUM>, the baseband controller <NUM> sends a discovery response message to that remote unit <NUM> indicating that the remote unit <NUM> should be homed to that baseband controller <NUM>. Each remote unit <NUM> can be configured to include in the discovery messages it sends as a part of this discovery process information identifying which functional splits that the remote unit <NUM> supports. Then, the baseband controller <NUM> can use this information included in such discovery messages to determine which functional splits all the remote units <NUM> assigned to that cell <NUM> support by collecting such information from the discovery messages it receives from the remote units <NUM> it serves.

In other embodiments, other discovery protocols and processes can be used (for example, a discovery process that is used only for discovering which functional splits the remote units <NUM> support).

Another way that the baseband controller <NUM> can be configured to determine the supported functional splits for each remote unit <NUM> is to receive this information from the management system <NUM>. The management system <NUM> can be used to manually enter this information and communicated to it. For example, the management system <NUM> can be used to enter this information into the whitelist for the cell <NUM> (which as noted above identifies the remote units <NUM> assigned to the cell <NUM>). In this way, the baseband controller <NUM> can be explicitly configured so that it has information about which functional splits the remote units <NUM> assigned to the cell <NUM> support.

Another way that the baseband controller <NUM> determine the supported functional splits for each remote unit <NUM> is to include a look-up table in the baseband controller <NUM> that contains information identifying the functional splits supported by the various makes and models of remotes units <NUM> that could possibly be used with the baseband controller <NUM>. Then, to determine the supported functional splits for a given remote unit <NUM>, the baseband controller <NUM> determines the make and model of each remote unit <NUM> assigned to the cell <NUM> via the discovery process described above or by having the make and model of each remote unit <NUM> manually entered into the whitelist for the cell <NUM>.

A combination of approaches for determining which functional splits the remote units <NUM> support can also be used. For example, one approach (for example, one that uses a discovery process) can be used with remote units <NUM> that are supplied by the same manufacturer as the baseband controller <NUM>, and another approach (for example, one that uses the management system <NUM> to explicitly configure the baseband controller <NUM> with such information) can be used with remote units <NUM> that are supplied by a manufacturer other than the one that supplies the baseband controller <NUM>.

Method <NUM> further comprises determining at least one functional split to use for communicating between the baseband controller <NUM> and the remote units <NUM> over the front-haul network <NUM> (block <NUM>).

In the exemplary embodiment described here in connection with <FIG>, a single functional split is used for all remote units <NUM> assigned to a given cell.

In one example, the baseband controller <NUM> identifies a functional split that all of the remote units <NUM> support. If there is no functional split that all of the remote units <NUM> support, then an error can be signaled (for example, via the management system <NUM>). If there is only one functional split that all of the remote units <NUM> support, then that functional split is used. If there are multiple functional splits that all of the remote units <NUM> support, then a functional split can be selected based on a number of factors. For example, such factors can include how the C-RAN <NUM> will be configured to provide wireless service to the cell <NUM> (for example, whether a mmWave configuration or a sub-<NUM> configuration will be used and what <NUM> Numerology configuration is used) and information related to the front-haul network <NUM> (for example, the bandwidth and latency that can be provided by the front-haul network <NUM>). How the C-RAN <NUM> will be configured to provide wireless service to the cell <NUM> determines the Layer-<NUM> processing constraints that apply to the remote units <NUM> as well as bandwidth and latency requirements for the front-haul network <NUM>. Any functional splits that are not able to satisfy the Layer-<NUM> processing constraints for the desired C-RAN configuration are eliminated from further consideration. Then each of the remaining functional splits can be evaluated to determine if the bandwidth and latency requirements associated with using that functional split with the desired C-RAN configuration can be satisfied by the front-haul network <NUM>, and, if that is not the case, then that functional split is eliminated from further consideration. Then, a functional split to be used is selected from the remaining functional splits (for example, using a ranking scheme). Again, if no functional split is able to satisfy all constraints, an error can be signaled (for example, via the management system <NUM>).

In other embodiments, the functional split that is used for communicating between the baseband controller <NUM> and the remote units <NUM> over the front-haul network <NUM> is determined in other ways.

Moreover, in other embodiments, instead of using a single functional split for all remote units assigned to the cell <NUM>, different functional splits are used for different remote units <NUM> or groups of remote units <NUM> assigned to the cell <NUM>.

Method <NUM> further comprises, for each functional split to be used and each remote associated with that functional split, configuring the processing performed in the baseband controller <NUM> and the processing performed in that remote unit <NUM> to use that functional split (block <NUM>).

In the exemplary embodiment described here in connection with <FIG> where a single functional split is used for all remote units assigned to the cell <NUM>, configuring the processing performed in the baseband controller <NUM> and the processing performed in the remote units <NUM> to use the single selected functional split involves configuring the Layer-<NUM> functions <NUM> and <NUM> in the baseband controller <NUM> and the remote units <NUM>, respectively, to use the single functional split selected for use with the cell <NUM>. In this exemplary embodiment, the remote unit interface management functions <NUM> in the baseband controller <NUM> configures the Layer-<NUM> functions <NUM> in the baseband controller <NUM> to use the selected functional split and sends configuration messages (for example, over a management virtual local area network (VLAN) provided over the front-haul network <NUM> for communicating management data) to the remote units <NUM> instructing the remote units <NUM> to use the selected functional split. In response to receiving such configuration messages, the remote units <NUM> configure the Layer-<NUM> functions <NUM> in them to use the selected functional split indicated in the configuration message.

The Layer-<NUM> functionality <NUM> and <NUM> in the baseband controllers <NUM> and the remote units <NUM> can be configured to support different functional splits in various ways.

One way in which the Layer-<NUM> functionality <NUM> and <NUM> can be configured to support different functional splits is to use a "brute force" approach in which completely separate processing chains are provided for each of the different functional splits the Layer-<NUM> functionality <NUM> and <NUM> support.

Another way is to provide functional split options on a per air-interface channel (for example, Physical Uplink Shared Channel (PUSCH), Physical Random Access Channel (PRACH), etc.) basis. The functional split options could then be selected by the controller <NUM> according to the overall interface needs. This approach is likely to be more extensible and require a smaller software footprint.

Another way in which the Layer-<NUM> functionality <NUM> and <NUM> can be configured to support different functional splits is to make use of "stackable" or "configurable" processing chains in which various stages of the processing chain can be omitted if those stages are performed in the "other" unit (that is, the remote unit <NUM>, in the case of the baseband controller <NUM>, or the baseband controller <NUM>, in the case of the remote unit <NUM>).

Moreover, the approach used in the baseband controller <NUM> can differ from the approach used in the remote units <NUM>, and all remote units <NUM> need not use the same approach.

Method <NUM> further comprises, for each functional split to be used and each remote unit <NUM> associated with that functional split, configuring a respective interface between the baseband controller <NUM> and that remote unit <NUM> for communicating front-haul data therebetween using that functional split (block <NUM>).

In this exemplary embodiment, this involves configuring the application layer protocol to use an appropriate baseband controller/RU interface and to support communicating data in a format suitable for the selected functional split. This can be done in conjunction with configuring the Layer-<NUM> functions <NUM> and <NUM> in the baseband controller <NUM> and the remote units <NUM>, respectively, to use the selected functional split as described above in connection with block <NUM>.

In the embodiment shown in <FIG>, the baseband controller <NUM> is configured to work with remote units <NUM> that support different baseband controller/RU interfaces for communications between the baseband controller <NUM> and remote units <NUM> -- including one or more proprietary interfaces and one or more standardized interfaces (such as the standardized interfaces promulgated by the extensible Radio Access Network (xRAN) Forum or by the IEEE <NUM> working group). The remote unit interface management functions <NUM> in the baseband controller <NUM> configures the DU-RU Application Protocol functions <NUM> in the baseband controller <NUM> to use the appropriate baseband controller/RU interface for each remote unit <NUM> served by the baseband controller <NUM> and to configure the selected baseband controller/RU interface for use with the selected functional split. Also, each remote unit <NUM> configures the DU-RU Application Protocol functions <NUM> to use the appropriate baseband controller/RU interface and to configure that baseband controller/RU interface for use with the selected functional split.

After configuring the Layer-<NUM> functions <NUM> and <NUM> and the DU-RU Application Protocol functions <NUM> and <NUM> in the baseband controller <NUM> and the remote units <NUM>, respectively, to use the selected functional split and an appropriate controller/RU interface, the baseband controller <NUM> and remote units <NUM> use the selected functional split and controller/RU interface for front-hauling data between the baseband controller <NUM> and the remote units <NUM> and to provide wireless service to the UEs <NUM>.

By using a flexible functional split and controller/RU interface, a single version of a baseband controller <NUM> can work with a variety of remote units <NUM> in a variety of environments to support a variety of wireless-interface configurations. Thus, a supplier of the baseband controller <NUM> does not need create and support different versions of the baseband controller <NUM> for each different type of remote unit <NUM>, environment, or wireless interface configuration. Also, wireless operators will be able to use such a baseband controller <NUM> in variety of usage scenarios, which is more convenient and economical for the operator.

In the exemplary embodiment described above in connection with <FIG>, the baseband controller <NUM> is described as using a single functional split for all of the remote units <NUM> served by the baseband controller <NUM>. However, other embodiments can be implemented in other ways. For example, the baseband controller <NUM> can be configured to select and configure a different functional split for different networking slices, different groups of remote units <NUM> used with a given cell <NUM> or networking slice, or even on per-remote-unit basis. In such an embodiment, a high capacity broadband controller <NUM> implemented using a virtualized platform can be used. A separate instance of the baseband controller functionality of portions thereof (such as the DU <NUM>) can be instantiated for each networking slice served by the baseband controller <NUM>. In such an embodiment, the baseband controller <NUM> can be configured to select and configure a different functional split for each networking slice served by the baseband controller <NUM> since each networking slice is being served by a separate instance running in the virtualized environment and can independently use a process like the one described above in connection with <FIG> to select and configure a functional split and controller/RU interface to use with that networking slice.

Moreover, in the exemplary embodiment described above in connection with <FIG>, the baseband controller <NUM> is described as performing the processing of method <NUM>. However, other embodiments can be implemented in other ways. For example, a node or entity other than the baseband controller <NUM> (for example, a management entity such as the management system <NUM> or an entity running on one of the remote units <NUM>) can perform such processing.

Other embodiments can be implemented in other ways.

Claim 1:
A system (<NUM>) comprising:
a baseband controller (<NUM>) to communicatively couple the system (<NUM>) to a core network (<NUM>); and
remote units (<NUM>), communicatively coupled to the baseband controller (<NUM>), to wirelessly transmit and receive radio frequency signals to and from user equipment (<NUM>) using a wireless interface, each of the remote units (<NUM>) associated with at least one antenna (<NUM>) and located remote from the baseband controller (<NUM>);
wherein at least one of the baseband controller (<NUM>), a management system (<NUM>), and one of the remote units (<NUM>) is configured to:
determine which functional splits between processing performed in the baseband controller (<NUM>) and processing performed in the remote units (<NUM>) each of the remote units (<NUM>) supports;
determine at least one functional split of the functional splits in the processing performed in the baseband controller (<NUM>) and the processing performed in the remote units (<NUM>) to use; and
for the at least one functional split and each of the remote units (<NUM>) associated with the at least one functional split:
configure the processing performed in the baseband controller (<NUM>) and the processing performed in each of the remote units (<NUM>) associated with the at least one functional split to use the at least one functional split; and
configure a respective interface between the baseband controller (<NUM>) and
each of the remote units (<NUM>) associated with the at least one functional split for communicating front-haul (<NUM>) data therebetween using the at least one functional split.