Patent Description:
Typically, each radio point is associated with a single baseband unit and supports a single carrier provided by a wireless operator. If more than a single carrier's worth of capacity needs to be provided in a given coverage area or if multiple carriers are needed to provide service within a given coverage area, multiple remotes units would typically be deployed within the same coverage area.

<CIT> discloses a compound remote radio unit, CRRU, that implements multiple separate logical remote radio units LRRUs. That is, it teaches implementing multiple conventional RRUs in a single unit in order to achieve economies of scale by sharing some hardware (for example, network interfaces, RF modules, and mechanical enclosures) among the LRRUs. Each LRRU is effectively a separate "standalone" RRU that is pre-instantiated with dedicated resources assigned to it and can be treated in the same way as a standalone RRU.

<CIT> discloses a RAN comprising a network infrastructure and a plurality of C-RAN domains, each comprising a BBU pool. An orchestrator in the network infrastructure is configured to receive resource configuration instructions from respective support systems of the C-RAN domains and issue resource allocation requests to a software defined resource radio head, SD-RRH, controller and front-haul, FH, controller of the network infrastructure. Accordingly, the orchestrator coordinates the resource allocation between shared a RRH pool and the FH network of the network infrastructure.

One embodiment is directed to a multi-carrier radio point for a central radio access network (C-RAN) comprising a plurality of controllers and a plurality of radio points. The multi-carrier radio point comprises at least one programmable device configured to provide processing resources for providing wireless service to a plurality of items of user equipment (UEs) using multiple bi-directional radio frequency carriers. The multi-carrier radio point further comprises at least one network interface configured to communicatively couple the multi-carrier radio point to a front-haul network in order to communicate with the plurality of controllers. The multi-carrier radio point further comprises a plurality of radio frequency modules configured to wirelessly communicate using one or more antennas. At least one programmable device is configured to: perform a discovery process in order for the multi-carrier radio point to be associated with one or more of the controllers; receive requests from one or more controllers for the processing resources and the radio frequency modules; assign the processing resources and the radio frequency modules to the one or more controllers based on the requests; and configure the processing resources and the radio frequency modules to instantiate one or more radio points instances. Each radio point instance is homed to a respective one of the controllers, each radio point instance implementing a respective carrier configuration.

Another embodiment is directed to a method for a multi-carrier radio point used with a central radio access network (C-RAN) comprising a plurality of controllers and a plurality of radio points. The multi-carrier radio point comprises at least one programmable device configured to provide processing resources for providing wireless service to a plurality of items of user equipment (UEs) using multiple bi-directional radio frequency carriers and a plurality of radio frequency modules configured to wirelessly communicate using one or more antennas. The method comprises performing a discovery process in order for the radio point to be associated with one or more of the controllers; receiving at the radio point requests from one or more controllers for the processing resources and the radio frequency modules; assigning the processing resources and the radio frequency modules to the one or more controllers based on the requests; and configuring the processing resources and the radio frequency modules to instantiate one or more radio points instances. Each radio point instance is homed to a respective one of the controllers, each radio point instance implementing a respective carrier configuration.

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 radio access network (RAN) system <NUM> in which the multi-carrier radio points described here can be used. The system <NUM> is deployed at a site <NUM> to provide wireless coverage and capacity for one or more wireless network operators. The site <NUM> may be, for example, a building or campus or other grouping of buildings (used, for example, by one or more businesses, governments, or other enterprise entities) or some other public venue (such as a hotel, resort, amusement park, hospital, shopping center, airport, university campus, arena, or an outdoor area such as a ski area, stadium or a densely-populated downtown area).

In the exemplary embodiment shown in <FIG>, the system <NUM> is implemented at least in part using a C-RAN architecture that employs multiple baseband units <NUM> and multiple radio points (RPs) <NUM>. The system <NUM> is also referred to here as a "C-RAN system" <NUM>. Each RP <NUM> is remotely located from the baseband units <NUM>. Also, in this exemplary embodiment, at least one of the RPs <NUM> is remotely located from at least one other RP <NUM>. The baseband units <NUM> and RPs <NUM> serve at least one cell <NUM>. The baseband units <NUM> are also referred to here as "baseband controllers" <NUM> or just "controllers" <NUM>.

Each RP <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.

Each controller <NUM> and RP <NUM> (and the functionality described as being included therein), as well as the system <NUM> more generally, and any of the specific features described here as being implemented by any of the foregoing, can be implemented in hardware, software, or combinations of hardware and software, and the various implementations (whether hardware, software, or combinations of hardware and software) can also be referred to generally as "circuitry" or a "circuit" configured to implement at least some of the associated functionality. When implemented in software, such software can be implemented in software or firmware executing on one or more suitable programmable processors. Such hardware or software (or portions thereof) can be implemented in other ways (for example, in a field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.). Also, the RF functionality can be implemented using one or more RF integrated circuits (RFICs) and/or discrete components. Each controller <NUM> and RP <NUM>, and the system <NUM> more generally, can be implemented in other ways.

The system <NUM> is coupled to the core network <NUM> of each wireless network operator over an appropriate back-haul. In the exemplary embodiment shown in <FIG>, the Internet <NUM> is used for back-haul between the system <NUM> and each core network <NUM>. However, it is to be understood that the back-haul can be implemented in other ways.

The exemplary embodiment of the system <NUM> shown in <FIG> is described here as being implemented as a Long Term Evolution (LTE) radio access network providing wireless service using an LTE air interface. LTE is a standard developed by 3GPP standards organization. In this embodiment, the controllers <NUM> and RPs <NUM> together are used to implement one or more LTE Evolved Node Bs (also referred to here as an "eNodeBs" or "eNBs") that are used to provide user equipment <NUM> with mobile access to the wireless network operator's core network <NUM> to enable the user equipment <NUM> to wirelessly communicate data and voice (using, for example, Voice over LTE (VoLTE) technology). These eNodeBs can be macro eNodeBs or home eNodeBs (HeNB).

Also, in this exemplary LTE embodiment, each core network <NUM> is implemented as an Evolved Packet Core (EPC) <NUM> comprising standard LTE EPC network elements such as, for example, a mobility management entity (MME) and a Serving Gateway (SGW) (all of which are not shown). Each controller <NUM> communicates with the MME and SGW in the EPC core network <NUM> using the LTE S1 interface. Also, each controller <NUM> communicates with other eNodeBs using the LTE X2 interface. For example, each controller <NUM> can communicate via the LTE X2 interface with an outdoor macro eNodeB (not shown) or another controller <NUM> in the same cluster <NUM> (described below) implementing a different cell <NUM>.

If the eNodeB implemented using one or more controllers <NUM> is a home eNodeB, the core network <NUM> can also include a Home eNodeB Gateway (not shown) for aggregating traffic from multiple home eNodeBs.

The controllers <NUM> and the radio points <NUM> can be implemented so as to use an air interface that supports one or more of frequency-division duplexing (FDD) and/or time-division duplexing (TDD). Also, the controllers <NUM> and the radio points <NUM> can be implemented to use an air interface that supports one or more of the multiple-input-multiple-output (MIMO), single-input-single-output (SISO), single-input-multiple-output (SIMO), multiple-input-single-output (MISO), and/or beam forming schemes. For example, the controllers <NUM> and the radio points <NUM> can implement one or more of the LTE transmission modes using licensed and/or unlicensed RF bands or spectrum. Moreover, the controllers <NUM> and/or the radio points <NUM> can be configured to support multiple air interfaces and/or to support multiple wireless operators.

The controllers <NUM> are communicatively coupled the radio points <NUM> using a front-haul network <NUM>. In the exemplary embodiment shown in <FIG>, the front-haul <NUM> that communicatively couples each controller <NUM> to one or more RPs <NUM> is implemented using a standard switched ETHERNET network <NUM>. However, it is to be understood that the front-haul between the controllers <NUM> and RPs <NUM> 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 RPs <NUM>, for example, via the Internet <NUM> and ETHERNET network <NUM> (in the case of the RPs <NUM>).

In the exemplary embodiment shown in <FIG>, the management system <NUM> communicates with the various elements of the system <NUM> using the Internet <NUM> and the ETHERNET 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 RPs <NUM>. The management system <NUM> can comprise a proprietary management system provided by the vendor of the C-RAN system <NUM> or a Home eNodeB management system (HeNB MS) (or other eNodeB management system) used by an operator to manage Home eNodeBs (or other eNodeBs) deployed in its network.

Each controller <NUM> can also implement a management interface by which a user is able to directly interact with the controller <NUM>. This management interface can be implemented in various ways including, for example, by implementing a web server that serves web pages that implement a web-based graphical user interface for a user to interact with the controller <NUM> using a web browser and/or by implementing a command-line interface by which a user is able to interact with the controller <NUM>, for example, using secure shell (SSH) software.

In the exemplary embodiment shown in <FIG>, the system <NUM> comprises multiple controllers <NUM> that are grouped together into a cluster <NUM>. Each cluster <NUM> has an associated set of RPs <NUM> that have been assigned to that cluster <NUM> and that are served by the controllers <NUM> included in that cluster <NUM>. The association of radio points <NUM> with cells <NUM> is implemented using a "white list" that associates a radio point identifier (for example, a media access control (MAC) address) with an identifier associated with each cell <NUM> (for example, a logical or virtual cell identifier used within the context of the C-RAN <NUM>).

Generally, for each cell <NUM> implemented by the C-RAN <NUM>, the corresponding controller <NUM> performs the air-interface Layer-<NUM> (L3) and Layer-<NUM> (L2) processing as well as at least some of the air-interface Layer-<NUM> (L1) processing for the cell <NUM>, where each of the radio points <NUM> serving that cell <NUM> perform the L1 processing not performed by the controller <NUM> as well as implementing the analog RF transceiver functions.

Different splits in the air-interface processing between each controller <NUM> and the radio points <NUM> can be used. In one example, each baseband controller <NUM> can be configured to perform all of the digital Layer-<NUM>, Layer-<NUM>, and Layer-<NUM> processing for the air interface, while the RPs <NUM> implement only the analog RF transceiver functions for the air interface and the antennas <NUM> associated with each RP <NUM>. In that case, in-phase and quadrature (IQ) data representing time-domain symbols for the air interface is communicated between the controller <NUM> and the RPs <NUM>. Other splits can be used and data can communicated between the controllers <NUM> and the radio points <NUM> in other formats. In the following the description, the fronthaul data communicated between the controllers <NUM> and the radio points <NUM> for the air interface is generally referred to as "IQ data" even though such fronthaul data can take many forms, including forms that are not IQ data.

Also, the form in which front-haul data is communicated in the downlink direction (that is, the direction from the controller <NUM> to the RPs <NUM>) can differ from the form in which front-haul data is communicated in the uplink direction (that is, the direction from the RPs <NUM> to the controller <NUM>). Also, for a given direction (downlink or uplink), not all front-haul data needs to be communicated in the same form (that is, the front-haul data for different channels or for different resource blocks can be communicated in different ways).

In this example, at least some of the RPs <NUM> are implemented as multi-carrier radio points <NUM>. For ease of explanation, all of the RPs <NUM> shown in <FIG> are described here as being implemented as multi-carrier radio points <NUM>. However, it is to be understood that the C-RAN <NUM> can be implemented using both single-carrier radio points and multi-carrier radio points <NUM> and a given cell <NUM> can be served both single-carrier radio points and multi-carrier radio points <NUM>.

<FIG> is a block diagram illustrating one exemplary embodiment of a multi-carrier radio point <NUM>. As shown in <FIG>, each multi-carrier radio point <NUM> comprises a plurality of radio frequency (RF) modules <NUM>. Each RF module <NUM> comprises circuitry that implements the RF transceiver functions for an air interface and interfaces to one or more antennas <NUM> associated with that RF module <NUM>. More specifically, in the exemplary embodiment shown in <FIG>, each RF module <NUM> interfaces with a respective two antennas <NUM>.

Those RF modules <NUM> that are implemented as "single-wide" RF modules <NUM> comprise circuitry that implements two downlink signal paths, one for each of the two antennas <NUM>, and two uplink signals paths, one for each of the two antennas <NUM>. Each single-wide RF module <NUM> is configured to be assigned a single carrier, where the two downlink signal paths and two uplink signal paths perform radio functions for that carrier. That is, for such a single-wide RF module <NUM>, the two antennas <NUM> are used for sending and receiving two RF signals for two corresponding spatial streams communicated using the assigned single carrier. Those RF modules <NUM> that are implemented as "double-wide" RF modules <NUM> comprise circuitry that implements four downlink signal paths, two for each of the two antennas <NUM>, and four uplink signals paths, two for each of the two antennas <NUM>. Each double-wide RF module <NUM> is configured to be assigned two carriers, where a respective two of the four downlink signal paths and a respective two of the four uplink signal paths perform radio functions for a respective each of the two assigned carriers. That is, for such a double-wide RF module <NUM>, the same two antennas <NUM> are used for sending and receiving two RF signals for two corresponding spatial streams communicated using each of the two assigned carriers.

In one exemplary implementation, each downlink signal path comprises a respective digital-to-analog converter (DAC) to convert downlink digital samples to a downlink analog signal, a respective frequency converter to upconvert the downlink analog to a downlink analog RF signal at the desired RF frequency, and a respective power amplifier (PA) to amplify the downlink analog RF signal to the desired output power for output via the antenna <NUM> associated with that downlink signal path. In one exemplary implementation, each uplink signal path comprises a respective low-noise amplifier (LNA) for amplifying an uplink analog RF signal received via the antenna <NUM> associated with the uplink signal path, a respective frequency converter to downconvert the received uplink analog RF signal to an uplink analog intermediate frequency signal, a respective analog-to-digital converter (ADC) to convert the uplink analog intermediate frequency signal to uplink digital samples. Each of the downlink and uplink signal paths can also include other conventional elements such as filters. Each RF module <NUM> can be implemented using one or more RF integrated circuits (RFICs) and/or discrete components.

Each multi-carrier radio point <NUM> further comprises at least one network interface <NUM> that is configured to communicatively couple the radio point <NUM> to the front-haul network <NUM>. More specifically, in the exemplary embodiment shown in <FIG>, each network interface <NUM> comprises an ETHERNET network interface that is configured to communicatively couple that radio point <NUM> to the switched ETHERNET network <NUM> that is used to implement the front-haul <NUM> for the C-RAN <NUM>.

Each multi-carrier radio point <NUM> further comprises one or more programmable devices <NUM> that execute, or are otherwise programmed or configured by, software, firmware, or configuration logic <NUM> (collectively referred to here as "software"). The one or more programmable devices <NUM> can be implemented in various ways (for example, using programmable processors (such as microprocessors, co-processors, and processor cores integrated into other programmable devices), programmable logic (such as field programmable gate arrays (FPGA), and system-on-chip packages)). Where multiple programmable devices <NUM> are used, all of the programmable devices <NUM> do not need to be implemented in the same way.

The software <NUM> can be implemented as program instructions or configuration logic that are stored (or otherwise embodied) on an appropriate non-transitory storage medium or media <NUM> from which at least a portion of the program instructions or configuration logic are read by one or more programmable devices <NUM> for execution thereby or configuration thereof. The software <NUM> is configured to cause one or more devices <NUM> to carry out at least some of the functions described here as being performed by the radio point <NUM>. Although the storage medium <NUM> is shown in <FIG> as being included in the radio point <NUM>, it is to be understood that remote storage media (for example, storage media that is accessible over a network) and/or removable media can also be used. Each radio point <NUM> also comprises memory <NUM> for storing the program instructions or configuration logic and/or any related data while the functions implemented by the software <NUM> are performed.

The multi-carrier radio point <NUM> is configured to enable processing resources provided by the one or more programmable devices <NUM> and the hardware resources provided by the RF modules <NUM> to be flexibly assigned and associated with various carriers and cells <NUM> used for providing wireless service to UEs <NUM>. As used herein, a "carrier" refers to a logical bi-directional RF channel used for wirelessly communicating with the UEs <NUM>. Where frequency division duplexing (FDD) is used, each "carrier" comprises a respective physical downlink RF carrier used for downlink transmissions and a respective physical uplink RF carrier used for uplink transmissions. Where time division duplexing (TDD) is used, each "carrier" comprises a single physical RF carrier that is used for both downlink and uplink transmissions.

In the exemplary embodiment shown in <FIG>, the one or more programmable devices <NUM> comprises a set of application processing units (APUs) <NUM>, a set of real-time processing units (RPUs) <NUM>, and programmable logic <NUM>. In this embodiment, the RPUs <NUM> and programmable logic <NUM> are configured to perform latency sensitive functions, and the APUs <NUM> are used to perform all other functions.

The APUs <NUM> and RPUs <NUM> are implemented using one or more processors or processor cores (for example, using one or more ARM processors or processor cores), and the programmable logic <NUM> is implemented by programming or configuring one or more programmable logic devices (such as one or more FPGAs or CPLDs). The software <NUM> comprises software <NUM> executed by the APUs <NUM>, which is also referred to here as "APU software" <NUM>. The software <NUM> also comprises software <NUM> executed by the RPU <NUM>, which is also referred to here as "RPU software" <NUM>. The APU software <NUM> and the RPU software <NUM> can communicate with each other, for example, using conventional inter-process communication (IPC) techniques. The APU software <NUM> and RPU software <NUM> can communicate with the programmable logic <NUM> using suitable application programming interfaces (APIs) and device drivers.

The APU software <NUM> comprises one or more of an operating system, device drivers, networking protocol clients (not shown) as well as application layer functionality (referred to here as "applications"). The APU software <NUM> comprises a radio point manager <NUM> that orchestrates the execution of the other APU and RPU applications, including coordinating their initiation, monitoring their health, and taking corrective actions as needed.

The APU applications also include a configuration manager <NUM> that is configured to manage the configuration of the radio point <NUM>. The configuration manager <NUM> is configured to communicate with the management system <NUM> and the management interfaces implemented by each of the controllers <NUM> assigned to that the radio point <NUM>.

The APU applications also include a controller discovery application <NUM> that is configured to participate in a discovery process used for discovering controllers <NUM> and radio points <NUM> and for homing the radio point <NUM> to one or more controllers <NUM>. In this example, the discovery process comprises the RP <NUM> sending discovery messages to all controllers <NUM> in the cluster <NUM> via the front-haul <NUM> that announce the presence of that RP <NUM>. As noted above, each controller <NUM> that is serving a cell <NUM> is configured with a whitelist that identifies which RPs <NUM> the controller <NUM> should send a discovery response message to when a discovery message is received from those RPs <NUM> as a part of the discovery process. The RP <NUM> is homed to (that is, is associated with) each of the controllers <NUM> that sends a discovery response message to it.

The discovery response message that is sent from a controller <NUM> to the RP <NUM> includes an address or other identifier (for example, an Internet Protocol (IP) address) assigned to the controller <NUM> that is to be used by the RP <NUM> in communicating with the controller <NUM>.

In one implementation, only a single instance of the controller discovery application <NUM> is instantiated and used for all of the controllers <NUM> assigned to that multi-carrier radio point, where that instance maintains a separate context or state machine for each controller <NUM> associated with the multi-carrier radio point <NUM>. In other implementations, a separate instance of the controller discovery application <NUM> is instantiated and used for each of the controllers <NUM> assigned to that multi-carrier radio point, where each instance maintains a respective context or state machine for one of the controllers <NUM> associated with the multi-carrier radio point <NUM>.

In this exemplary embodiment, the APU applications also include a multi-carrier manager application <NUM> and per-carrier manager applications <NUM> and radio controller applications <NUM>. Only one instance of the multi-carrier manager application <NUM> is instantiated at any time. The multi-carrier manager application <NUM> is configured to bind instances of the per-carrier manager applications <NUM>, the radio controller application <NUM>, and L1 software instances to the associated carrier and hardware resources. The per-carrier manager application <NUM> is assigned to a particular carrier of the RP <NUM> and is configured to act as the primary peer entity for the controller <NUM> that is associated with that carrier for all operation, administration, and management communications (including, for example, configuration communications and reporting and monitoring communications). The per-carrier manager application <NUM> is also configured to control and act as the master for the one or more instances of the radio controller application <NUM> that are assigned to the same controller <NUM>. For each RF module <NUM> assigned to a controller <NUM>, a respective instance of the radio controller application <NUM> is instantiated in order to configure and control that RF module <NUM>.

In the exemplary embodiment shown in <FIG>, the Layer <NUM> (L1) processing resources are used to implement a L1 processing chain for each carrier of the RP <NUM>. The Layer <NUM> (L1) processing resources include a manager application <NUM> that runs on the set of APUs <NUM> included in the RP <NUM>. This manager application is also referred to here as the "APU L1 manager application" <NUM>. An instance of the APU L1 manager application <NUM> is instantiated for each carrier of the RP <NUM> (and the associated L1 processing chain) and is configured to configure the L1 processing that is performed by L1 processing resources provided by the RP <NUM> (including applications running on the set of APUs <NUM> and on the set of RPUs <NUM> and the programmable logic <NUM>). The Layer <NUM> (L1) processing resources also include a manager application <NUM> that runs on the set of RPUs <NUM> included in the RP <NUM>. This manager application is also referred to here as the "RPU L1 manager application" <NUM>. An instance of the RPU L1 manager application <NUM> is instantiated for each carrier of the RP <NUM> (and the associated L1 processing chain) and is configured to perform various latency sensitive L1 signal processing tasks for that carrier using the set of RPUs <NUM>. Also, in this exemplary embodiment, the Layer <NUM> (L1) processing resources also include an L1 co-processor application <NUM> that runs on the set of APUs <NUM> included in the RP <NUM>. An instance of the L1 co-processor application <NUM> is instantiated for each carrier of the RP <NUM> (and the associated L1 processing chain) and is configured to perform various L1 signal processing tasks for that carrier using the set of APUs <NUM>.

Also, in this exemplary embodiment, the Layer <NUM> (L1) processing resources also include Layer <NUM> (L1) baseband functions logic <NUM> implemented by the configuration logic <NUM> for the programmable logic device <NUM>. In this embodiment, a respective instance of the L1 baseband logic <NUM> is created at system start-up for each of the possible carriers that can be supported by the radio point <NUM>. For example, where the radio point <NUM> can support up to four carriers (such as in the examples shown in <FIG>), four instances of the programmable logic <NUM> are created at system start-up. The instances of the L1 baseband logic <NUM> are bound to other parts of the radio point <NUM> as needed as described below.

The various instances of the applications that are associated with different controllers, carriers, and RF modules <NUM>, as the case may be, are isolated from one another. Also, it is to be understood that the various instances may be implemented using shared physical or logical resources.

The multi-carrier radio point <NUM> is configured so that the processing and hardware resources provided by the radio point <NUM> can be associated with controllers <NUM> in the cluster <NUM> in a flexible manner. A single multi-carrier radio point <NUM> can be used with multiple controllers <NUM> to serve multiple cells <NUM>, where the processing and hardware resources used for the multiple controllers <NUM> need not be configured and used in the same way. The multi-carrier radio point <NUM> is not "hardwired" to operate in certain radio point configurations. Instead, the multi-carrier radio point <NUM> can be configured at run-time to use the desired radio point configurations. Each controller <NUM> that is used with the multi-carrier radio point <NUM> automatically discovers the radio point <NUM> and claims and configures the resources it needs from those that are provided by the radio point <NUM>.

For example, an RF plan can be developed for the site <NUM> that identifies where the coverage areas of the various cells <NUM> need to be located and where radio points <NUM> need to be deployed in order to provide the desired coverage areas. The association of radio points <NUM> and cells <NUM> can be configured by specifying which radio points <NUM> are to be associated with each cell <NUM>. The association of radio points <NUM> with cells <NUM> is implemented using a "white list" that associates a radio point identifier (for example, a media access control (MAC) address) with an identifier associated with each cell <NUM> (for example, a logical or virtual cell identifier used within the context of the C-RAN <NUM>). When a controller <NUM> in the cluster <NUM> is configured to serve a particular cell <NUM>, the controller <NUM> uses the white list to determine which radio points <NUM> should be homed to that controller <NUM> in order to serve that cell <NUM>. The controller <NUM> then uses this information to claim and configure the relevant resources of the assigned radio points <NUM> at run time. In this way, the various radio points <NUM> do not need to be individually manually configured. Instead, the controllers <NUM> can automatically discover, claim, and configure the resources provided by the multi-carrier radio points <NUM>.

Additional examples and details regarding this are provided below in connection with <FIG> and <FIG>.

<FIG> comprises a high-level flowchart illustrating one exemplary embodiment of a method <NUM> of configuring a multi-carrier radio point <NUM> used in a C-RAN <NUM>. The embodiment of method <NUM> shown in <FIG> is described here as being implemented 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.

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.

The particular radio point <NUM> for which method <NUM> is described here as being performed is referred to here as the "current" radio point <NUM>.

Method <NUM> is performed when the current radio point <NUM> is initially powered on and when the radio point rebooted.

Method <NUM> comprises performing a discovery process in order for the current radio point <NUM> to be discovered by the controllers <NUM> in the C-RAN <NUM> (block <NUM>). In this exemplary embodiment, the discovery process comprises the current radio point <NUM> sending a discovery messages to all controllers <NUM> in the cluster <NUM> via the front-haul switched ETHERNET network <NUM> that announce the presence of the current radio point <NUM>. As noted above, there is a whitelist that associates each cell <NUM> provided by the C-RAN with a set of radio points <NUM> used to serve that cell <NUM>. When each controller <NUM> that is currently serving a cell <NUM> receives a discovery message from a radio point <NUM>, the controller <NUM> uses the whitelist to check if the radio point <NUM> that sent the discovery message is assigned to that cell <NUM>. If the radio point <NUM> that sent the discovery message is not assigned to that cell <NUM>, the serving controller <NUM> does not send a response to the discovery message. If the radio point <NUM> that sent the discovery message is assigned to that cell <NUM>, the serving controller <NUM> sends a discovery response message to that radio point <NUM> indicating that the radio point <NUM> should be homed to that controller <NUM>. The discovery response message that is sent from a controller <NUM> to the RP <NUM> includes an address or other identifier (for example, an Internet Protocol (IP) address) assigned to the controller <NUM> that is to be used by the radio point <NUM> in communicating with the controller <NUM>. The current radio point <NUM> can be homed to multiple controllers <NUM> in order to serve multiple cells <NUM>.

In this exemplary embodiment, the discovery process is done by the instance of the controller discovery application <NUM>.

Method <NUM> further comprises receiving, from each controller <NUM> homed to the current radio point <NUM>, a request to use certain carriers and processing and hardware resources provided by the current radio point <NUM> in a particular configuration (block <NUM>), assigning carriers and processing and hardware resources provided by the current radio point <NUM> to each controller <NUM> based on the received requests (block <NUM>), and configuring the carriers and processing and hardware resources assigned to each controller <NUM> in order to instantiate a radio point instance based on the received requests (block <NUM>).

As used here, a "radio point instance" refers to the processing and hardware resources assigned to a particular controller <NUM> in order to implement a radio point entity.

In this exemplary embodiment, each controller <NUM> that is homed to the current radio point <NUM> sends one or more messages to the current radio point <NUM> that requests the use of certain carriers and processing and hardware resources provided by the current radio point <NUM> in a particular configuration to instantiate a radio point instance. The requests for carrier and processing and hardware resources received at the current multi-carrier radio point <NUM> are processed by the multi-carrier manager <NUM>. For each controller <NUM> homed to the current radio point <NUM> that sends a request to the current radio point <NUM>, the multi-carrier manager <NUM> assigns to that controller <NUM> the requested one or more carriers and requested one or more RF modules <NUM>, if available. The multi-carrier manager <NUM> instantiates a respective instance of the per-carrier manager <NUM>, APU L1 manager <NUM>, RPU L1 manager <NUM>, and (if used) APU L1 co-processing application <NUM> for each carrier assigned to a requesting controller <NUM>. Moreover, the multi-carrier manager <NUM> assigns one of the instances of L1 baseband logic <NUM> to each carrier assigned to a requesting controller <NUM>. Also, the multi-carrier manager <NUM> instantiates a respective instance of the radio controller application <NUM> for each RF module <NUM> assigned to a requesting controller <NUM>. The multi-carrier manager <NUM>, for each requesting controller <NUM>, then binds the various instances associated with that controller <NUM> to each other and to the assigned carriers and RF modules <NUM> (and configures the various instances) in order to implement the requested configuration and radio point instance. If the requested carriers and processing and hardware resources are not available, an error is signaled.

In this way, the carriers and processing and hardware resources provided by the multi-carrier radio point <NUM> can be configured in a flexible manner by having the controllers <NUM> automatically discover, claim, and configure the resources provided by the multi-carrier radio points <NUM>.

<FIG> are block diagrams illustrating various configurations of the multi-carrier radio point <NUM> shown in <FIG>. In the examples illustrated in the <FIG>, the multi-carrier radio point <NUM> is configured to support up to four bi-directional carriers and includes four RF modules <NUM>, with each RF module <NUM> including two downlink and two uplink signal paths and two antennas <NUM>. Also, in these example, L1 APU co-processing applications <NUM> are not used. It is to be understood, however, that other embodiments can be implemented in other ways.

Moreover, <FIG> illustrates a "homogenous" configuration in which all of the radio point instances implemented by the multi-carrier radio point <NUM> are configured in the same way, whereas <FIG> all illustrates different "heterogenous" configurations in which at least one of the radio point instances implemented by the multi-carrier radio point <NUM> differs from at least one of the other radio point instances implemented by that multi-carrier radio point <NUM>.

In the example shown in <FIG>, the multi-carrier radio point <NUM> is homed to four controllers <NUM> and instantiates four respective radio point instances <NUM> (individually referenced in <FIG> using the suffixes "-A", "-B", "-C", and "-D", respectively). Each controller <NUM> is assigned a single carrier and RF module <NUM>. Each of the four carriers implements a respective 2x2 MIMO LTE channel. The baseband streams for each 2x2 MIMO LTE channel are processed by a respective single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffixes "-A", "-B", "-C", and "-D", respectively) assigned to the associated carrier.

In this example, the multi-carrier manager <NUM> instantiates four instances of each of the per-carrier manager <NUM>, APU L1 manager <NUM>, and RPU L1 manager <NUM> (individually referenced in <FIG> using the suffixes "-A", "-B", "-C", and "-D", respectively), and binds one of each of the four instances to a respective one of the four assigned carriers (and to the controller <NUM> associated with the assigned carrier). Moreover, the multi-carrier manager <NUM> binds one instance of both the APU L1 manager <NUM> and the RPU L1 manager <NUM> to a respective one of the L1 processing chains <NUM> (and the software and programmable logic resources <NUM> and <NUM> used therein). The APU L1 manager <NUM> and the RPU L1 manager <NUM> both interact with the software and programmable logic <NUM> (if used) and <NUM> of the associated L1 processing chain <NUM> in connection with configuring and managing the L1 processing implemented by that chain <NUM>. Also, in this example, the multi-carrier manager <NUM> instantiates four instances of the radio controller application <NUM> (individually referenced in <FIG> using the suffixes "-A", "-B", "-C", and "-D", respectively) and binds one of the four instances to a respective one of the four assigned RF modules <NUM> (and to the controller <NUM> associated with the assigned RF module <NUM>). The multi-carrier manager <NUM> then configures the instances of the per-carrier manager <NUM>, APU L1 manager <NUM>, RPU L1 manager <NUM>, and radio controller application <NUM> assigned to each controller <NUM> to implement a 2x2 MIMO LTE configuration, where each cell is served using a respective one of the RF modules <NUM>.

The two downlink and uplink antennas streams for each 2x2 MIMO channel are processed by the L1 signal processing chain <NUM> (and the software and programmable logic resources <NUM> and <NUM> included therein) assigned to the associated carrier. Also, the two downlink antenna streams for each 2x2 MIMO channel are processed by a respective two downlink signal paths in a respective one of the RF modules <NUM>-A, <NUM>-B, <NUM>-C, and <NUM>-D for transmission from a respective one of the antennas <NUM>. Likewise, the two uplink antenna streams received via a respective one of the antennas <NUM> for each 2x2 MIMO channel are processed by a respective two uplink signal paths in a respective one of the RF modules <NUM>-A, <NUM>-B, <NUM>-C, and <NUM>-D.

In the example shown in <FIG>, the multi-carrier radio point <NUM> is homed to three controllers <NUM> and instantiates three respective radio point instances <NUM> (individually referenced in <FIG> using the suffixes "-A", "-B", and "-C", respectively). As with the example shown in <FIG>, each of two controller <NUM>-A and <NUM>-B is assigned a single carrier and single RF module <NUM>-A and <NUM>-B, respectively, and each of the two carriers implements a respective 2x2 MIMO LTE channel. The baseband streams for each 2x2 MIMO LTE channel are processed by a respective single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffixes "-A" and "-B", respectively) assigned to the associated carrier. The processing and hardware resources for each 2x2 MIMO LTE channel are bound and configured in the same way shown in <FIG>, the description of which is not repeated here for the sake of brevity.

The third controller <NUM>-C is assigned two carriers and two RF modules <NUM>-C and <NUM>-D. Each of the two carriers implement a respective 2x2 MIMO LTE channel. In this example, the two 2x2 MIMO LTE channels are aggregated using LTE carrier aggregation. The baseband streams for each 2x2 MIMO LTE channel are processed by a respective single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffixes "-C" and "-D", respectively) assigned to the associated carrier.

In this example, for the third controller <NUM>-C, the multi-carrier manager <NUM> instantiates two instances of each of the per-carrier manager <NUM>, APU L1 manager <NUM>, and RPU L1 manager <NUM> (individually referenced in <FIG> using the suffixes "-C" and "-D") and binds one of each of the two instances to a respective one of the two assigned carriers (and to the third controller <NUM>-C, which is assigned the two carriers). Moreover, the multi-carrier manager <NUM> binds one instance of both the APU L1 manager <NUM> and the RPU L1 manager <NUM> to a respective one of the L1 processing chains <NUM> (and the software and programmable logic resources <NUM> and <NUM> used therein). The APU L1 manager <NUM> and the RPU L1 manager <NUM> both interact with the software and programmable logic <NUM> (if used) and <NUM> of the associated L1 processing chain <NUM> in connection with configuring and managing the L1 processing implemented by that chain <NUM>. Also, in this example, the multi-carrier manager <NUM> instantiates two instances of the radio controller application <NUM> (individually referenced in <FIG> using the suffixes "-C" and "-D") and binds one of the two instances to a respective one of the two assigned RF modules <NUM>-C and <NUM>-D (and to the third controller <NUM>-C, which is assigned the two RF modules <NUM>-C and <NUM>-D). The multi-carrier manager <NUM> then configures the instances of the per-carrier manager <NUM>, APU L1 manager <NUM>, RPU L1 manager <NUM>, and radio controller application <NUM> assigned to the third controller <NUM>-C to implement a two-carrier carrier aggregation LTE configuration, where the associated cell is served using the two RF modules <NUM>-C and <NUM>-D. In this carrier aggregation configuration, each of the two aggregated carriers both implement a respective 2x2 MIMO LTE channel, which are then aggregated. Each of these 2x2 MIMO LTE channels are configured in the same general manner described above with respect to the carriers assigned to controllers <NUM>-A and <NUM>-B.

In the example shown in <FIG>, the multi-carrier radio point <NUM> is homed to three controllers <NUM> and instantiates three respective radio point instances <NUM> (individually referenced in <FIG> using the suffixes "-A", "-B", and "-C", respectively). As with the example shown in <FIG>, each of two controller <NUM>-A and <NUM>-B is assigned a single carrier and single RF module <NUM>-A and <NUM>-B, respectively, and each of the two carriers implements a respective 2x2 MIMO LTE channel. The baseband streams for each 2x2 MIMO LTE channel are processed by a respective single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffixes "-A" and "-B", respectively) assigned to the associated carrier. The processing and hardware resources for each 2x2 MIMO LTE channel are bound and configured in the same way shown in <FIG>, the description of which is not repeated here for the sake of brevity.

In the example shown in <FIG>, the third controller <NUM>-C is assigned one carrier and two RF modules <NUM>-C and <NUM>-D. A single carrier is used to implement a single 4x4 MIMO LTE channel. The baseband streams for the single 4x4 MIMO channel are processed by a single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffix "-C") assigned to the associated carrier.

For the third controller <NUM>-C, the multi-carrier manager <NUM> instantiates one instance of each of the per-carrier manager <NUM>, APU L1 manager <NUM>, and RPU L1 manager <NUM> (individually referenced in <FIG> using the suffix "-C") and binds each of the instances to the assigned carrier (and to the third controller <NUM>-C, which is assigned the carrier). Moreover, the multi-carrier manager <NUM> binds the instance of both the APU L1 manager <NUM>-C and the RPU L1 manager <NUM>-C to the respective L1 processing chain <NUM>-C (and the software and programmable logic resources <NUM>-C and <NUM>-C used therein). The APU L1 manager <NUM>-C and the RPU L1 manager <NUM>-C both interact with the software and programmable logic <NUM>-C (if used) and <NUM>-C of the associated L1 processing chain <NUM>-C in connection with configuring and managing the L1 processing implemented by that chain <NUM>-C. Also, in this example, the multi-carrier manager <NUM> instantiates two instances of the radio controller application <NUM> (individually referenced in <FIG> using the suffixes "-C" and "-D") and binds both of the instances to the assigned carrier. Moreover, the multi-carrier manager <NUM> binds one of the two instances of the radio controller application <NUM> to a respective one of the two assigned RF modules <NUM>-C and <NUM>-D (and to the third controller <NUM>-C, which is assigned the two RF modules <NUM>-C and <NUM>-D). The multi-carrier manager <NUM> then configures the instances of the per-carrier manager <NUM>, APU L1 manager <NUM>, RPU L1 manager <NUM>, and radio controller application <NUM> assigned to the third controller <NUM>-C to implement a single-carrier 4x4 MIMO LTE configuration, where the associated cell is served using the two RF modules <NUM>-C and <NUM>-D. Each of the two RF modules <NUM>-C and <NUM>-D provide two downlink signal paths, for a total of four downlink signal paths, each of which is used to process one of the four downlink antenna streams for transmission from a respective one of the antennas <NUM>. Likewise, each of the two RF modules <NUM>-C and <NUM>-D provide two uplink signal paths, for a total of four uplink signal paths, each of which is used to process one of the four uplink antenna streams received via a respective one of the antennas <NUM>.

In the example shown in <FIG>, the multi-carrier radio point <NUM> is homed to two controllers <NUM> and instantiates two respective radio point instances <NUM> (individually referenced in <FIG> using the suffixes "-A" and "-B", respectively). One controller <NUM>-A is assigned a single carrier and single RF module <NUM>-A. The assigned carrier implements a 2x2 MIMO LTE channel. The baseband streams for the 2x2 MIMO LTE channel are processed by a single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffix "-A") assigned to the associated carrier. The processing and hardware resources for the 2x2 MIMO LTE channel are bound and configured in the same way shown in <FIG>, the description of which is not repeated here for the sake of brevity.

The second controller <NUM>-B is assigned three carriers and two RF modules <NUM>-B and <NUM>-C. The second controller <NUM>-B uses the three carriers to implement a LTE Licensed Assisted Access (LAA) configuration, where one carrier is used as the licensed primary carrier for implementing a single-carrier 2x2 MIMO LTE channel and the other two carriers are used as unlicensed supplemental carriers. The baseband streams for the 2x2 MIMO LTE channel are processed by a single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffix "-B") assigned to the associated carrier. Also, the baseband streams for each of the two supplemental unlicensed carriers are processed by a respective single L1 signal processing chain <NUM> including appropriate software and programmable logic resources <NUM> (if used) and <NUM> (all of which are individually referenced in <FIG> using the suffixes "-C" and "-D", respectively).

In this example, for the second controller <NUM>-B, the multi-carrier manager <NUM> instantiates three instances of each of the per-carrier manager <NUM>, APU L1 manager <NUM>, and RPU L1 manager <NUM> (individually referenced in <FIG> using the suffixes "-B", "-C", and "-D") and binds one of each of the three instances to a respective one of the three assigned carriers (one of which is a licensed carrier and the other two of which are unlicensed carriers). Moreover, the multi-carrier manager <NUM> binds one instance of both the APU L1 manager <NUM> and the RPU L1 manager <NUM> to a respective one of the L1 processing chains <NUM> (and the software and programmable logic resources <NUM> and <NUM> used therein). The APU L1 manager <NUM> and the RPU L1 manager <NUM> both interact with the software and programmable logic <NUM> (if used) and <NUM> of the associated L1 processing chain <NUM> in connection with configuring and managing the L1 processing implemented by that chain <NUM>. Also, in this example, the multi-carrier manager <NUM> instantiates two instances of the radio controller application <NUM> (individually referenced in <FIG> using the suffixes "-B" and "-C") and binds one of the two instances to a respective one of the two assigned RF modules <NUM>-B and <NUM>-C (and to the second controller <NUM>-B, which is assigned the two RF modules <NUM>-B and <NUM>-C). The multi-carrier manager <NUM> then configures one of the instances (the one referenced with the suffix "-B") of the per-carrier manager <NUM>, APU L1 manager <NUM>, RPU L1 manager <NUM>, and radio controller application <NUM> assigned to the second controller <NUM>-B to use one carrier as the licensed primary carrier for implementing a single-carrier 2x2 MIMO LTE channel. The carrier implements a 2x2 MIMO LTE channel using the associated L1 processing chain <NUM>-B and is configured in the same general manner described above with respect to the example shown in <FIG>.

The multi-carrier manager <NUM> also configures the others instances (the ones referenced with the suffixes "-C" and "-D") of the per-carrier manager <NUM>, APU L1 manager <NUM>, and RPU L1 manager <NUM> assigned to the second controller <NUM>-B and the other instance (the one referenced with the suffix "-C") of the radio controller application <NUM> assigned to the second controller <NUM>-B to use the other two carriers as unlicensed supplemental carriers. In this example, the RF module <NUM>-C assigned to the unlicensed supplemental carriers is a double-wide RF module <NUM>-C that can be assigned two carriers and comprises four downlink signal paths and four uplink signal paths. In this configuration, the double-wide RF module <NUM>-C is able to implement the radio functions for the respective two downlink and uplink baseband streams for each of the two assigned unlicensed carriers, where the corresponding two downlink and uplink RF signals for each of the two assigned unlicensed carriers are sent and received using one of the same two antennas <NUM>. The multi-carrier manager <NUM> binds the two supplemental unlicensed carriers (and the related software instances) to this RF module <NUM>-C. One L1 processing chain <NUM>-C processes the two downlink and uplink baseband streams for one of the assigned unlicensed carriers, and another L1 processing chain <NUM>-D processes the two downlink and uplink baseband streams for the other assigned unlicensed carrier.

The methods and techniques described here may be implemented in digital electronic circuitry, or with a programmable processor (for example, a special-purpose processor or a general-purpose processor such as a computer) firmware, software, or in combinations of them. Apparatus embodying these techniques may include appropriate input and output devices, a programmable processor, and a storage medium tangibly embodying program instructions for execution by the programmable processor. A process embodying these techniques may be performed by a programmable processor executing a program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may advantageously be implemented in one or more programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Generally, a processor will receive instructions and data from a read-only memory and/or a random-access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and DVD disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs).

Claim 1:
A multi-carrier radio point (<NUM>) for a central radio access network comprising a plurality of controllers (<NUM>) and a plurality of radio points (<NUM>), the multi-carrier radio point (<NUM>) comprising:
at least one programmable device (<NUM>) configured to provide processing resources for providing wireless service to a plurality of items of user equipment (<NUM>) using multiple bi-directional radio frequency carriers;
at least one network interface (<NUM>) configured to communicatively couple the multi-carrier radio point (<NUM>) to a front-haul network (<NUM>) in order to communicate with the plurality of controllers (<NUM>); and
a plurality of radio frequency modules (<NUM>) configured to wirelessly communicate using one or more antennas (<NUM>);
the multi-carrier radio point (<NUM>)
characterized in that
at least one programmable device (<NUM>) is configured to:
perform a discovery process in order for the multi-carrier radio point (<NUM>) to be associated with one or more of the controllers (<NUM>);
receive requests from one or more controllers (<NUM>) for the processing resources and the radio frequency modules (<NUM>);
assign the processing resources and the radio frequency modules (<NUM>) to the one or more controllers (<NUM>) based on the requests; and
configure the processing resources and the radio frequency modules (<NUM>) to instantiate one or more radio point instances (<NUM>), each radio point instance (<NUM>) homed to a respective one of the controllers (<NUM>), each radio point instance (<NUM>) implementing a respective carrier configuration.