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.
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.
Perfecting the Vendor/Provider Relationship
NF: Is there a “recipe for success” for keeping up with the telecommunications providers in terms of semiconductor development?
MN: The relationship between telecom providers and semiconductor vendors needs to be symbiotic. Telecommunications providers need to rely on semiconductor suppliers to deliver the technologies requested by the systems OEMs. Otherwise, they will not get these technologies. On the other hand, the semiconductor vendors have the best view of what is possible and cost effective to do in what timeframe. Often, the service providers don’t even know what is possible, so they are not considering technologies that would make their lives a lot easier. So we need to have a constant give and take between service providers and semiconductor companies beyond the direct supplier/customer relationships that exist between semiconductor vendors and systems OEMs—and between the OEMs and the telecommunications providers.
NF: Can you update us on how time errors are now being defined within HetNets?
MN: One of the biggest problems we had identified in the past for HetNet deployments was 1588 timing delivery over mixed fiber/microwave/small-cell/macro-cell radio-access networks. Although there is an overall time error budget of 500 ns maximum between adjacent cell sites [in the case of LTE-Advanced Coordinated MultiPoint (CoMP), for example], operators never were able to determine if their access networks would meet those targets before they were done deploying the networks and were able to test them. And various network elements and backhaul technologies today have very different abilities to maintain 1588 timing, so there would be a significant amount of finger pointing if the network did not meet the specs.
Now, the ITU has stepped in and is in the process of defining time-error equipment classes for each network element. The maximum time error that can be introduced by a 1588-compliant router, switch, or microwave backhaul link is 50 ns. Some operators are pushing to define a second timing equipment class with a maximum time error of 20 ns. This way, operators can literally just add up the time-error classes for each link and know if they are within a specific timing budget before they build their network. This will be particularly important for HetNet deployments (where there could be equipment from many different vendors) and even third-party operators in some segments of the access network, as we discussed.