NF: As wireless networks become more pervasive, thanks to heterogeneous networks (HetNets), can you tell us about the new demands facing network operators?

MN: HetNets have the ability to dramatically enhance coverage and capacity of wireless networks once fully implemented. The three biggest hurdles are real estate, backhaul, and cost. Ultimately, we expect anywhere from 5X to 10X the density of small cells compared to the number of current macro cells. So these small cells need to be highly cost effective to fit into the operators’ fairly constant CapEx profile model—and that applies to the cost of backhaul as well. Excluding perhaps China and fiber-rich countries in Asia, everybody expects that backhaul will be largely wireless in the form of microwave and millimeter-wave technology. The availability of cost-effective, low-power, and small-form-factor backhaul technology will therefore be key as well. Lastly, small-cell deployments can often feel more like a real estate than a technology problem, with multiple service providers trying to get on top of the same lamppost.  

NF: Time synchronization is especially tricky, given the increasing vulnerability of GPS. Why is GPS more vulnerable?

MN: GPS has always been vulnerable to jamming and spoofing, but that susceptibility is becoming amplified for small cells that are located at street level on top of lampposts and traffic signals. GPS also relies on line-of-sight visibility to multiple GPS satellites, and that is likely not available for small cells in urban corridors. So while GPS was very viable as a timing source for macro base stations, it is generally not considered an option for small cells—not even as a backup.

Martin Nuss, Vitesse Semiconductor

NF: A solution has emerged in IEEE standard 1588v2, which provides an alternative or backup to GPS timing. Can you explain to us how that technology works?

MN: IEEE 1588 uses “Sync Packets” that are time stamped by a master clock and carry their own Ethertype. These packets traverse the network until they get to what is called an ordinary clock, which uses the time stamps to produce a physical clock signal. For frequency delivery, this can be a unidirectional process from the master to the ordinary clock. A software algorithm—also often called “servo”—can filter out the effect of packet delay variations. For phase and time-of-day synchronization, 1588 uses a two-way message exchange mechanism involving Sync, Delay_Request, and Delay_Response messages to derive the local time. Because it is a two-way mechanism, the 1588 protocol needs to assume a completely symmetric delay in upstream and downstream direction, which can never be guaranteed in packet networks. That is why boundary clocks and transparent clocks have been defined that provide hardware-supported time stamping in every node and can eliminate any variable asymmetries within each network element down to the nanosecond accuracy level.

NF: Can you provide some background on the standard and how it evolved?

MN: IEEE 1588 started in the test-and-automation industry as a way to synchronize and precisely control equipment. The 2008 version of the standard—often and incorrectly called 1588v2—was enhanced to be more telecom-friendly in defining clock hierarchies and different clock classes mirroring the timing hierarchy used in SONET/SDH telecom networks. It introduced the concept of 1588 boundary and transparent clocks. IEEE 1588 allows for different so-called profiles for various applications across industries. For telecom, the ITU-T has completed its work for a profile to deliver frequency using IEEE 1588. It is in the midst of completing its work on a profile for delivering phase and time-of-day. The latter profile is particularly urgent and important, as all TD-LTE and LTE-Advanced (LTE-A) networks require phase and time-of-day, not just frequency synchronization. 

NF: Do you expect this standard to provide a solution for at least the next five years? Or will there be more versions in the near future to face new demands?

MN: 1588v2, or more accurately 1588-2008, is a perfectly viable packet timing solution for both frequency and phase/time-of-day delivery. It just requires that network elements consistently support time stamping to enable boundary or transparent clocks as they are being specified by the ITU-T profiles for phase and time-of-day delivery. There are a few things we need to clean up, enhance, and clarify in the standard, which is why we started working on the next version (likely to be called 1588-2016). This version will be completely backward-compatible to the 2008 standard, but include enhancements for chassis-based systems and distributed time stamping while clarifying relationship to other standards. There also are groups in the research community that would like to be able to achieve picosecond accuracy with IEEE 1588, so that is a topic of discussion as well.

NF: What other issues have to be confronted with the rollout of newer networks, like LTE?

MN: With the large number of small cells to be deployed—especially in urban environments—connecting those back to a central aggregation router can be a challenge. So we see small cells often connected in a linear (daisy) chain or partial mesh topology. That means you need a fair amount of sophisticated networking capability in each small cell or small-cell backhaul equipment. That capability has to fit into a small power envelope, as most small cells and small-cell backhaul equipment tries to stay within a 10-to-15-W power envelope.

NF: What stands in the way of success for HetNets in particular?

MN: The small-cell real-estate issue I mentioned will likely require a different approach to small-cell deployments—especially in the US and Europe, where there are many different wireless service providers vying for the same customers and therefore the same small-cell real estate. We think that may open an opportunity for third-party small-cell deployment and backhaul operators, which deal with all of the real-estate and municipal regulatory issues and lease back small-cell capacity and connectivity to multiple service providers. At Vitesse, we have specifically designed our silicon solutions to enable such models for multi-domain, multi-operator services, connectivity, OAM, and timing capabilities. Such capabilities have the potential to significantly drop the cost of HetNet deployments for each individual service provider.