Patent ID: 12219510

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating one exemplary embodiment of a radio access network (RAN) system100in which the clock synchronization techniques described here can be used. The system100is deployed at a site102to provide wireless coverage and capacity for one or more wireless network operators. The site102may 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 inFIG.1, the system100is implemented at least in part using a C-RAN architecture that employs multiple baseband units104and multiple radio points (RPs)106. The system100is also referred to here as a “C-RAN system”100. Each RP106is remotely located from the baseband units104. Also, in this exemplary embodiment, at least one of the RPs106is remotely located from at least one other RP106. The baseband units104and RPs106serve at least one cell108. The baseband units104are also referred to here as “baseband controllers”104or just “controllers”104.

Each RP106includes or is coupled to one or more antennas110via which downlink RF signals are radiated to various items of user equipment (UE)112and via which uplink RF signals transmitted by UEs112are received.

Each controller104and RP106(and the functionality described as being included therein), as well as the system100more 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 or configuring a programmable device. Such hardware or software (or portions thereof) can be implemented in other ways (for example, in an 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 controller104and RP106, and the system100more generally, can be implemented in other ways.

The system100is coupled to the core network114of each wireless network operator over an appropriate backhaul116(including, for example, a wide area network). In the exemplary embodiment shown inFIG.1, the Internet is used for backhaul116between the system100and each core network114. However, it is to be understood that the backhaul116can be implemented in other ways.

The exemplary embodiment of the system100shown inFIG.1is 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 controllers104and RPs106together 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 equipment112with mobile access to the wireless network operator's core network114to enable the user equipment112to wirelessly communicate data and voice (in the case of 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 network114is implemented as an Evolved Packet Core (EPC)114comprising standard LTE EPC network elements such as, for example, a mobility management entity (MME) and a Serving Gateway (SGW) and a Security Gateway (SeGW) (all of which are not shown). Each controller104communicates with the MME and SGW in the EPC core network114using the LTE S1 interface over an Internet Protocol Security (IPsec) tunnel established with the SeGW. Also, each controller104communicates with other eNodeBs (over the IPsec tunnel) using the LTE X2 interface. For example, each controller104can communicate via the LTE X2 interface with an outdoor macro eNodeB (not shown) or another controller104in the same cluster124(described below) implementing a different cell108.

If the eNodeB implemented using one or more controllers104is a home eNodeB, the core network114can also include a Home eNodeB Gateway (not shown) for aggregating traffic from multiple home eNodeBs.

The controllers104and the radio points106can 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 controllers104and the radio points106can 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 controllers104and the radio points106can implement one or more of the LTE transmission modes using licensed and/or unlicensed RF bands or spectrum. Moreover, the controllers104and/or the radio points106can be configured to support multiple air interfaces and/or to support multiple wireless operators.

The controllers104are communicatively coupled the radio points104using a fronthaul network118(including, for example, a local area network). In the exemplary embodiment shown inFIG.1, the fronthaul118that communicatively couples each controller104to one or more RPs106is implemented using a standard switched ETHERNET network120. However, it is to be understood that the fronthaul between the controllers104and RPs106can be implemented in other ways.

In the exemplary embodiment shown inFIG.1, a management system122is communicatively coupled to the controllers104and RPs106, for example, via the back-haul116and ETHERNET network120(in the case of the RPs106).

In the exemplary embodiment shown inFIG.1, the management system122communicates with the various elements of the system100using the backhaul116and the ETHERNET network120. Also, in some implementations, the management system122sends and receives management communications to and from the controllers104, each of which in turn forwards relevant management communications to and from the RPs106. The management system122can comprise a proprietary management system provided by the vendor of the C-RAN system100or 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 controller104can also implement a management interface by which a user is able to directly interact with the controller104. 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 controller104using a web browser and/or by implementing a command-line interface by which a user is able to interact with the controller104, for example, using secure shell (SSH) software.

In the exemplary embodiment shown inFIG.1, the system100comprises multiple controllers104that are grouped together into a cluster124. Each cluster124has an associated set of RPs106that have been assigned to that cluster124and the cells108served by the controllers104included in that cluster124. The association of radio points106with cells108served by the cluster124is implemented using a “white list”. For each radio point106that is associated with a cell108, the white list includes an identifier (for example, a media access control (MAC) address) for that radio point106that the white list associates with an identifier for that cell108(for example, a logical or virtual cell identifier used within the context of the C-RAN100). When a controller104is configured to serve a particular cell108it can reference the white list to determine which radio points106it should associate with in order to serve that cell108.

In this example, at least some of the RPs106are implemented as multi-carrier radio points106and at least some of the RPs106are implemented as single-carrier radio points106. The C-RAN100can be implemented using various numbers of multi-carrier radio points106and/or single-carrier radio points106(including implementations in which only multi-carrier radio points106are used, implementations in which only single-carrier radio points106are used, and implementations in which combinations of both single-carrier radio points106and multi-carrier radio points106are used).

FIG.2Ais a block diagram illustrating one exemplary embodiment of a multi-carrier radio point106. As shown inFIG.2, each multi-carrier radio point106comprises a plurality of radio frequency (RF) modules202. Each RF module202comprises circuitry that implements the RF transceiver functions for an air interface and interfaces to one or more antennas110associated with that RF module202. More specifically, in the exemplary embodiment shown inFIG.2A, each RF module202interfaces with a respective two antennas110and comprises circuitry that implements two downlink signal paths, one for each of the two antennas110, and two uplink signals paths, one for each of the two antennas110.

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 antenna110associated 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 antenna110associated 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 and additional amplifiers. Each RF module202can be implemented using one or more RF integrated circuits (RFICs) and/or discrete components.

Each multi-carrier radio point106further comprises at least one network interface204that is configured to communicatively couple the radio point106to the fronthaul network118. More specifically, in the exemplary embodiment shown inFIG.2A, each network interface204comprises an ETHERNET network interface that is configured to communicatively couple that radio point106to the switched ETHERNET network120that is used to implement the front-haul118for the C-RAN100.

Each multi-carrier radio point106further comprises one or more programmable devices206that execute, or are otherwise programmed or configured by, software, firmware, or configuration logic208(collectively referred to here as “software”). The one or more programmable devices206can 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 devices206are used, all of the programmable devices206do not need to be implemented in the same way.

The software208can be implemented as program instructions or configuration logic that are stored (or otherwise embodied) on an appropriate non-transitory storage medium or media210from which at least a portion of the program instructions or configuration logic are read by one or more programmable devices206for execution thereby or configuration thereof. The software208is configured to cause one or more devices206to carry out at least some of the functions described here as being performed by the radio point106. Although the storage medium210is shown inFIG.2Aas being included in the radio point106, 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 point106also comprises memory212for storing the program instructions or configuration logic and/or any related data while the functions implemented by the software208are performed.

The software208, in relevant part, comprises clock synchronization software222that is configured to synchronize the local clock220of the radio point106as described in more detail below.

The multi-carrier radio point106is configured to enable processing resources provided by the one or more programmable devices206and the hardware resources provided by the RF modules202to be flexibly assigned and associated with various carriers and cells108used for providing wireless service to UEs112. As used herein, a “carrier” refers to a logical bi-directional RF channel used for wirelessly communicating with the UEs112. 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.

The multi-carrier radio point106is configured so that the processing and hardware resources provided by the radio point106can be associated with controllers104in the cluster124in a flexible manner. A single multi-carrier radio point106can be used with multiple controllers104to serve multiple cells108, where the processing and hardware resources used for the multiple controllers104need not be configured and used in the same way. The multi-carrier radio point106is not “hardwired” to operate in certain radio point configurations. Instead, the multi-carrier radio point106can be configured at run-time to use the desired radio point configurations. Each controller104that is used with the multi-carrier radio point106can be configured to automatically discover each associated radio point106and claim and configure the resources it needs from those that are provided by each radio point106.

For example, an RF plan can be developed for the site102that identifies where the coverage areas of the various cells108need to be located and where radio points106need to be deployed in order to provide the desired coverage areas. The association of radio points106and cells108can be configured by specifying which radio points106are to be associated with each cell108. As noted above, the association of radio points106with cells108can be implemented using a white list. When a controller104in the cluster124is configured to serve a particular cell108, the controller104can be configured to the white list to determine which radio points106should be homed to that controller104in order to serve that cell108. Also, the configuration information maintained with the white list can also specify what resources of each assigned radio point106should be used to serve the associated cell108and how they should be configured. The controller104then uses this information to claim and configure the relevant resources of the assigned radio points106at run time. In this way, the various radio points106do not need to be individually manually configured. Instead, the controllers104can automatically discover, claim, and configure the resources provided by the multi-carrier radio points106. The controllers104and radio points106can be configured to be discovered and configured in other ways.

FIG.2Bis a block diagram illustrating one exemplary embodiment of a single-carrier radio point106. Except as described below, the single-carrier radio point106is implemented in a similar manner as the multi-carrier radio point106shown inFIG.2A, where elements of the single-carrier radio point106shown inFIG.2Bthat correspond to elements of the multi-carrier radio point106shown inFIG.2Aare referenced inFIG.2Busing the same reference numerals used inFIG.2Aand where the description of such corresponding elements set forth above in connection withFIG.2Aalso applies to the single-carrier radio point106shown inFIG.2Band is not repeated below for the sake of brevity. The primary differences between the single-carrier radio point106ofFIG.2Band the multi-carrier radio point106ofFIG.2Aare that the single-carrier radio point106ofFIG.2Bcomprises a single radio frequency (RF) module202that interfaces with a respective two antennas110and the associated processing and other resources of the single-carrier radio point106are scaled and configured to support only a single carrier.

FIG.3is a block diagram illustrating one exemplary embodiment of a controller104. Each controller104further comprises at least one network interface303that is configured to communicatively couple the controller106to the backhaul network116and at least one network interface304that is configured to communicatively couple the controller106to the fronthaul network118. More specifically, in the exemplary embodiment shown inFIG.3, each network interface303and304comprises an ETHERNET network interface that is configured to communicatively couple that controller104, respectively, to the backhaul network116and to the switched ETHERNET network120that is used to implement the front-haul118for the C-RAN100.

Each controller104further comprises one or more programmable devices306that execute, or are otherwise programmed or configured by, software, firmware, or configuration logic308(collectively referred to here as “software”). The one or more programmable devices306can 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 devices306are used, all of the programmable devices306do not need to be implemented in the same way.

The software308can be implemented as program instructions or configuration logic that are stored (or otherwise embodied) on an appropriate non-transitory storage medium or media310from which at least a portion of the program instructions or configuration logic are read by one or more programmable devices306for execution thereby or configuration thereof. The software308is configured to cause one or more devices306to carry out at least some of the functions described here as being performed by the controller104. Although the storage medium310is shown inFIG.3as being included in the controller104, 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 controller104also comprises memory312for storing the program instructions or configuration logic and/or any related data while the functions implemented by the software308are performed.

The software308, in relevant part, comprises clock synchronization software322that is configured to synchronize the local clock125of the controller104as described in more detail below.

Also, in the exemplary embodiment shown inFIG.3, the controller104further comprises a Global Positioning System (GPS) receiver324.

Generally, for each cell108implemented by the C-RAN100, the corresponding controller104(and the associated software308) performs the air-interface Layer-3 (L3) and Layer-2 (L2) processing as well as at least some of the air-interface Layer-1 (L1) processing for the cell108, where each of the radio points106serving that cell108perform the L1 processing not performed by the controller104as well as implementing the analog RF transceiver functions. Different splits in the air-interface L1 processing between the controller104and the radio points106can be used.

For example, with one L1 split, each baseband controller104is configured to perform all of the digital Layer-1, Layer-2, and Layer-3 processing for the air interface, while the RPs106implement only the analog RF transceiver functions for the air interface and the antennas110associated with each RP106. In that case, in-phase and quadrature (IQ) data representing time-domain symbols for the air interface is communicated between the controller104and the RPs106.

In another example, a different L1 split is used in order to reduce the amount of data front-hauled between the controller104and the RPs106. With this L1 split, the data front-hauled between the controller104and the RPs106is communicated as IQ data representing frequency-domain symbols for the air interface. This frequency-domain IQ data represents the symbols in the frequency domain before the inverse fast Fourier transform (IFFT) is performed, in the case of the downlink, and after the fast Fourier transform (FFT) is performed, in the case of the uplink. If this L1 split is used for downlink data, the IFFT and subsequent transmit L1 processing would be performed in each RP106. Also, if this L1 split is used for uplink data, the FFT and subsequent receive L1 processing would be performed in the controller104.

The front-hauled IQ data can also be quantized in order to reduce the amount of fronthaul bandwidth that is required. The quantization can be performed using any suitable quantization technique. Also, quantization can also be used where the front-hauled IQ data comprises time-domain symbols.

Additional details regarding front-hauling frequency-domain IQ data can be found in U.S. patent application Ser. No. 13/762,283, filed on Feb. 7, 2013, and titled “RADIO ACCESS NETWORKS,” which is hereby incorporated herein by reference.

The L1-split used for downlink fronthaul data (that is, data front-hauled from the controller104to the RPs106) can differ from the L1-split used for downlink fronthaul data (that is, data front-hauled from the RPs106to the controller104). Also, for a given direction (downlink or uplink), not all fronthaul data needs to be communicated in the same form (that is, the fronthaul data for different channels or for different resource blocks can be communicated in different ways).

In the exemplary embodiment shown inFIGS.2A and2B, each radio point106further comprises a single local clock220. In particular, each multi-carrier radio point106comprises a single local clock220. Likewise, in the exemplary embodiment shown inFIG.3, each controller104includes a single local clock320. As noted above, each carrier served by a multi-carrier radio point106is associated with one of the controllers104in the cluster124. The processing resources in the multi-carrier radio point106that are assigned to all of the carriers served by the multi-carrier radio point106all use the same clock220even though the processing resources in the multi-carrier radio point106that are assigned to an individual carrier will exchange baseband IQ and control data over the fronthaul network120with the particular controller104that serves that carrier. Thus, a single multi-carrier radio point106will typically interact with multiple controllers104, each of which has its own local clock320.

For a given cell108, the local clocks220of the radio points106serving that cell108must be tightly synchronized in order to ensure good performance when simulcasting from two or more of those radio points106to a given UE112. Furthermore, the processing performed by the processing resources assigned to each cell108in each radio point106is repeated for each 1 ms subframe (TTI), and, for each TTI, relies on timely reception of new blocks (packets) of downlink IQ data from the controller104. Since a single local clock220is used by the processing resources assigned to all of the carriers served by a given multi-carrier radio point106, this local clock220must have good synchronization with the local clocks320of all of the controllers104that the multi-carrier radio point106is served by.

When each of the controllers104has access to GPS signals, each controller104can use the GPS receiver324to independently synchronize its local clock320to the GPS clock and the resulting differential errors between the local clocks320in the various controllers104in the cluster124will be small. Put another way, in this GPS example, the GPS clock serves as the master clock source (also referred to here as the “grandmaster”).

In many installations, the controllers104do not have access to GPS signals (for example, the controllers104are deployed indoors without GPS signal reception) and, instead, must synchronize to a master clock source128that is accessed via a wide area network (WAN) used to implement the back-haul116(for example, the Internet). This synchronization can be done using the Institute of Electrical and Electronics Engineers (IEEE) 1588 Precision Time Protocol (PTP). However, the backhaul116over which the controllers104synchronize to the master clock source128typically experiences high packet delay variation (PDV). This can result in large differential errors among the local clocks320of the various controllers104in the cluster124when the local clocks320of the various controllers104are independently synchronized to the same master clock source128. The resulting large differential errors among the local clocks320of the various controllers104in the cluster124can cause downlink IQ data front-hauled from the controllers104to the various radio points106to be received out of alignment.

In order to address these issues and provide good synchronization the local clocks320of the controllers104and the local clocks220of the various radio points106, the controllers104and the radio points106are configured to implement the clock distribution scheme described below.

FIG.4comprises a high-level flowchart illustrating one exemplary embodiment of a method400of distributing a clock in a C-RAN100. The embodiment of method400shown inFIG.4is described here as being implemented using the C-RAN100, radio points106, and controllers104described above in connection withFIGS.1,2A-2B,3, and5, though it is to be understood that other embodiments can be implemented in other ways.

The blocks of the flow diagram shown inFIG.4have 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 method400(and the blocks shown inFIG.4) 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 method400can and typically would include such exception handling.

In general, the processing associated with method400is performed by each of the controllers104in the cluster124(and, in particular, at least in part by the clock synchronization software322in each controller104).

Method400comprises determining if each controller104should serve as the timing master for the cluster124and the associated radio points106(block402). Details regarding how each controller104makes the determination as to whether or not to serve as the timing master for the cluster124and associated radio points106are described below in connection withFIG.6.

Method400further comprises operating a controller104as the timing master for the cluster124and associated radio points106(block404) if that controller104determines that it should do so. As used here, the “master controller”104refers to the particular controller104that is serving as the timing master for the cluster124and associated radio points106. When a controller104is the master controller104, it synchronizes its clock320with the external master clock source128over the backhaul116(which is a high PDV network) (block406). In this exemplary embodiment, the master controller104uses the IEEE 1588 protocol to synchronize its local clock320with the external master clock source128over the backhaul116. With respect to the synchronization of its local clock320with the external master clock source128, the master controller104acts as an IEEE 1588 “timing slave” with respect to the external master clock source128(with the external master clock source128acting as the “grandmaster”). The master controller104initiates a session with the external master clock source128so that the controller104can receive synchronization messages transmitted from the external master clock source128. The master controller104uses the received synchronization messages to synchronizes its local clock320with the external master clock source128. This is illustrated inFIG.5, which depicts one example of the operation of method400in the RAN system100ofFIG.1.

Method400further comprises synchronizing the local clocks320of the other controllers104in the cluster124and the local clocks220of the associated radio points106to the local clock320of the master controller104over the fronthaul120(which is a low PDV network) (block408). In this exemplary embodiment, the controllers104in the cluster124and the associated radio points106also use the IEEE 1588 protocol over the front-haul switched Ethernet network120. With respect to synchronization of its local clock320with the local clocks320of the other controllers104in the cluster124and the local clocks220of the associated radio points106, the master controller104acts as an IEEE 1588 timing master, with the other controllers104in the cluster124and the associated radio points106acting as IEEE 1588 timing slaves. The master controller104broadcasts synchronization messages to the other controllers104in the cluster124and the associated radio points106over the fronthaul switched Ethernet network120(the low PDV network). The other controllers104in the cluster124and the radio points106use the received synchronization messages to synchronizes their local clocks320and220with the local clock320in the master controller104. This is also illustrated inFIG.5.

Method400further comprises operating each controller104as a timing slave for the cluster124(block410) if that controller104determines that it should not serve as the timing master for the cluster124and associated radio points106. As used here, a “slave controller”104refers to any controller104that is serving as a timing slave for the cluster124and associated radio points106. When a controller104serves as a timing slave for the cluster124, it receives synchronization messages transmitted from the master controller104over the front-haul switched Ethernet network120(the low PDV network) (block412) and uses the received synchronization messages to synchronizes its local clock320with the local clock320of the master controller104(block414). This is also illustrated inFIG.5.

As noted above, the radio points106also receive the synchronization messages transmitted from the master controller104over the front-haul switched Ethernet network120(the low PDV network) and use the received synchronization messages to synchronize their local clocks220with the local clock320of the master controller104.

With the clock distribution scheme illustrated inFIG.4, each of the controllers104in the cluster124need not independently synchronize its local clock320with the external master clock source128over the high PDV network (backhaul116). Instead, one of the controllers104in the cluster124(the master controller104) synchronizes its local clock320with the external master clock source128over the high PDV network, while the other controllers104in the cluster124(the slave controllers104) and the radio points106synchronize their local clocks320and220to the master controller104over a low PDV network (the fronthaul switched Ethernet network120). As a result, the differential errors among the local clocks320and220of the controllers104and the radio points106should be sufficiently small. Also, by having the radio points106synchronize their local clocks220with the local clock320of the master controller104over the low PDV network (the fronthaul switched Ethernet network120), the clocks220of the radio points106will have tight synchronization to the local clock320of the master controller104. This is an improvement over the relatively poor synchronization between the various local clocks220of the radio points106that would result if, in contrast to approach described here, each of the radio points106were to independently synchronize its local clock220with the external master clock source128over the high PDV network (backhaul116).

FIG.6comprises a high-level flowchart illustrating one exemplary embodiment of a method600of designating a timing master for a C-RAN100. The embodiment of method600shown inFIG.6is described here as being implemented using the C-RAN100, radio points106, and controllers104described above in connection withFIGS.1,2A-2B,3, and5, though it is to be understood that other embodiments can be implemented in other ways.

The blocks of the flow diagram shown inFIG.6have 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 method600(and the blocks shown inFIG.6) 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 method600can and typically would include such exception handling.

In general, the processing associated with method600is performed by each of the controllers104in the cluster124(and, in particular, at least in part by the clock synchronization software322in each controller104).

Method600comprises determining, by each controller104, a quality metric for its connection with the external master clock source128over the backhaul116(block602) and communicating it to the other controllers104in the cluster124over the fronthaul118(block604). Although only one controller104at a time serves as the timing master for the cluster124and synchronizes its local clock320with the external master clock source128, each controller104in the cluster124establishes a connection with the external master clock source128over the backhaul network116. Periodically, each controller104determines a quality metric for its connection with the master clock source128. This quality metric is also referred to here as the “connection quality metric.” In one implementation, the connection quality metric is based on the packet delay variation (PDV) for packets that are communicated between that controller104and the external master clock source128. In this exemplary embodiment, each controller104can calculate a moving average of the PDV measurements made during a predetermined period for that controller's104connection with the external master clock source128. Then, each controller104transmits a message including the current value of the moving average to the other controllers104in the cluster124over the front-haul switched Ethernet network120. This is also illustrated inFIG.5.

Method600further comprises receiving, by each controller104, connection quality metrics determined by the other controllers104in cluster124for their connections with the external master clock source128(block606). In this exemplary embodiment, each of the controllers104in the cluster124receives messages from the other controllers104that include the current value of the moving average of the PDV determined by the other controllers104for their connections with the external master clock source128. By doing this, each of the controllers104will have connection quality metrics for itself and each of the controllers104in the cluster124, which can be used to determine a new timing master in the event that it is necessary to do so.

Method600further comprises determining by each controller104, when a new timing master needs to be determined (block608). For example, this determination needs to be made when the timing master for the cluster124fails or is otherwise no longer able to serve as the timing master. In this exemplary embodiment, each controller104can make this determination based on whether or not it has received, within a predetermined timeout period, a predetermined message (for example, a recent IEEE 1588 synchronization message or heartbeat message) from the master controller104.

If a new timing master does not need to be determined at that time, each controller104remains in its current role (block610).

If the master controller104has failed (or if a new timing master otherwise needs to be determined), each slave controller104determines if it should serve as the timing master for the cluster124. In this exemplary embodiment, the slave controller104having the best connection quality metric should serve as the timing master for the cluster124and associated radio points106(assuming that the slave controller104has itself not otherwise failed). That is, each slave controller104compares its current connection quality metric with the current connection quality metrics for the other slave controllers104in the cluster124(as reported in the messages received from those other controllers104). If a slave controller104has the best current connection quality metric among the other slave controllers104in the cluster124(block612), that slave controller104should transition to serving as the time master for the cluster124and associated radio points106(block614) and perform the acts described above in connection with blocks404-408ofFIG.4.

Otherwise, each slave controller104remains a slave controller104and synchronizes itself to the new master controller104(block616). That is, if there has been a failure of a master controller104and a different controller104is now serving as the master controller104, each slave controller104will recognize the new master controller104and synchronize to that master controller104as described above in connection with blocks410-414.

Although a particular connection quality metric (packet delay variation) has been described in connection withFIG.6, it is to be understood that other connection quality metrics can be used in addition to or instead of the one described above.

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).

A number of embodiments of the invention defined by the following claims have been described. Nevertheless, it will be understood that various modifications to the described embodiments may be made without departing from the spirit and scope of the claimed invention. Accordingly, other embodiments are within the scope of the following claims.

EXAMPLE EMBODIMENTS

Example 1 includes a central radio access network (C-RAN) system comprising: a plurality of controllers; and a plurality of radio points; wherein each of the controllers and radio points comprises a respective local clock; wherein each of the radio points is associated with at least one antenna and is remotely located from the controllers, wherein the plurality of radio points is communicatively coupled to the controllers using a fronthaul network; wherein the controllers and the plurality of radio points are configured to implement a plurality of base stations in order to provide wireless service to a plurality of user equipment (UEs); wherein each of the controllers is communicatively coupled to a core network of a wireless service provider over a backhaul network; wherein each of the controllers is communicatively coupled to a master clock source over the backhaul network; wherein each of the controllers is configured to: determine if that controller should serve as a timing master for the controllers and the radio points; if that controller should serve as the timing master, serve, by that controller, as the timing master for the controllers and the radio points; synchronize the local clock of that controller with the master clock source over the backhaul network; and transmit synchronization messages from that controller over the fronthaul network for reception by the other controllers and the radio points and for use by the other controllers and the radio points in synchronizing the local clocks thereof with the local clock of that controller.

Example 2 includes the system of Example 1, wherein each of the controllers is configured to: determine a respective connection quality metric for a respective connection between that controller and the master clock source over the backhaul network; and communicate the respective connection quality metric to the other controllers; and wherein each of the controller is configured to transition to serving as the timing master for the controllers and the radio points if that controller is not currently serving as the timing master, another controller that is currently serving as the timing master has failed, and that controller has the best of the connection quality metrics determined for the controllers.

Example 3 includes the system of Example 2, wherein each connection quality metric is based on a packet delay variation (PDV) metric determined for the respective connection with the master clock source over the backhaul network.

Example 4 includes the system of any of the Examples 1-3, wherein the controllers and the radio points are configured to use the IEEE 1588 protocol for clock synchronization.

Example 5 includes the system of any of the Examples 1-4, wherein at least one of the radio points comprises a multi-carrier radio point.

Example 6 includes the system of any of the Examples 1-5, wherein at least one of the radio points comprises a single-carrier radio point.

Example 7 includes the system of any of the Examples 1-6, wherein the fronthaul network comprises a network having a low packet delay variation (PDV), and the backhaul network comprises a network having a high packet delay variation (PDV).

Example 8 includes the system of any of the Examples 1-7, wherein the fronthaul network comprises a local area network and the backhaul network comprises a wide area network.

Example 9 includes the system of any of the Examples 1-8, wherein the fronthaul network comprises a switched Ethernet network.

Example 10 includes the system of any of the Examples 1-9, wherein the backhaul network comprises the Internet.

Example 11 includes a method of distributing a clock in a central radio access network (C-RAN) system comprising a plurality of controllers and a plurality of radio points, wherein each of the controllers and radio points comprises a respective local clock, wherein each of the radio points is associated with at least one antenna and is remotely located from the controllers, wherein the plurality of radio points is communicatively coupled to the controllers using a fronthaul network, wherein the controllers and the plurality of radio points are configured to implement a plurality of base stations in order to provide wireless service to user equipment, wherein each of the controllers is communicatively coupled to a core network of a wireless service provider over a backhaul network, and wherein each of the controllers is communicatively coupled to a master clock source over the backhaul network, the method comprising: determining if a first of the controllers should serve as a timing master for the controllers and the radio points; if said first controller should serve as the timing master, serving, by said first controller, as the timing master for the controllers and the radio points; synchronizing the local clock of said first controller with the master clock source over the backhaul network; and transmitting synchronization messages from said first controller over the fronthaul network for reception by the other controllers and the radio points and for use by the other controllers and the radio points in synchronizing the local clocks thereof with the local clock of said first controller.

Example 12 includes the method of Example 11, further comprises: determining a respective connection quality metric for a respective connection between said first controller and the master clock source over the backhaul network; communicating the respective connection quality metric to the other controllers; and receiving respective connection equality metrics determined for the other controllers; and wherein said first controller should transition to serving as the timing master if said first controller is not currently serving as the timing master, another controller that is currently serving as the timing master has failed, and said first controller has the best of the connection quality metrics determined for the controllers.

Example 13 includes the method of Example 12, wherein each connection quality metric is based on a packet delay variation (PDV) metric determined for the respective connection with the master clock source over the backhaul network.

Example 14 includes the method of any of the Examples 11-13, wherein the controllers and the radio points are configured to use the IEEE 1588 protocol for clock synchronization.

Example 15 includes the method of any of the Examples 11-14, wherein at least one of the radio points comprises a multi-carrier radio point.

Example 16 includes the method of any of the Examples 11-15, wherein at least one of the radio points comprises a single-carrier radio point.

Example 17 includes the method of any of the Examples 11-16, wherein the fronthaul network comprises a network having a low packet delay variation (PDV), and the backhaul network comprises a network having a high packet delay variation (PDV).

Example 18 includes the method of any of the Examples 11-17, wherein the fronthaul network comprises a local area network and the backhaul network comprises a wide area network.

Example 19 includes the method of any of the Examples 11-18, wherein the fronthaul network comprises a switched Ethernet network.

Example 20 includes the method of any of the Examples 11-19, wherein the backhaul network comprises the Internet.