Is your network PhaseReady?

attend the Phase Ready Seminar from Chronos

Phase Ready?

As you think about the evolution of your network, don't limit your thoughts to the frequency stability you need now. We want to help ensure that network roll-outs today will still be relevant come the explosion of HetNets and Small Cells.

GPS Timing - coming to the edge of a Network near you?

This may seem a strange title for many readers - if you have a CDMA network you've been working with GPS at cell sites for many years. Here in Europe however we have tended in the past to use the E1 used for backhaul to deliver the sync quality we need to deliver 15ppb at the air interface. We've also more recently delivered this frequency performance from the core of Carrier Ethernet networks using PTP and SyncE.
Should your GPS have a problem, the holdover oscillator (lets say an OCXO) kicks in and gives you time to get out to site and make a fix. Likewise the PTP client devices usually use OCXO for holdover, and although the time to fix is usually shorter than is the case for GPS there is still adequate time to mobilise for a fix.

So why consider GPS at the edge now? Well we're probably a year or so away from having to roll out TD-LTE, or LTE-A features, that require adjacent cells (Macro or Small Cells) to be within +/-1.5us of each other. Packet based timing from the core is still being tested and standardised; microwave radio manufacturers have a real challenge to make this work well (and they're doing great work to get there);and you may not have end to end control of the backhaul network in any case. These issues may or may not be performance affecting enough to put a brake on considering PTP supported by SyncE for phase, but you'd be a fool not to consider the alternatives.

So we examine GPS at the edge; its been done successfully for years, right? Trouble is the game has changed - its got a lot harder. We're all OK with your GPS timing solution locked and running as it should, but what about failure? As in frequency networks the holdover technology kicks in - but OCXO will only hold the +/-1.5us for probably four HOURS, not four DAYS! Have you got the budget, or indeed available power in the cabinet, to use OCXO? TCXO performance continues to improve in leaps and bounds so perhaps using the latest TCXO could give you three hours to mobilise. How is Ops going to handle this? Will you need vehicles parked at strategic motorway junctions waiting for equipment to fail?
On a practical level where can you put the antenna? Have you mast space and the personnel required to roll this out at thousands of locations? Can you hide the antenna in the cabinet? Will it see enough of the sky to work there? Could you roll out Assisted GPS (A-GPS) to help here? If you deploy antennas at low level how long before they're vandalised? Does your network design allow for other cells to provide backup sync? If your timing is embedded in the eNodeB do you have to swap out a whole box to solve a GPS or sync issue?

These issues are real and need addressing, but none of them are necessarily show stoppers to delivering a robust network with adequate phase performance. The trick is to know what the issues are and to address them head on. Don't hope things won't go wrong because they will. Examine the cases of Edge GPS and Phase from the Core from a position that with the right planning and testing they will work.

Make sure you and your network are Phase Ready!
Continue reading
2058 Hits

Symbiosis in Sync?

There’s currently lots of focus in the synchronisation industry on the concept of "on-path support" - making network elements timing aware and treating timing protocols (e.g. PTP packets) differently to other services. This typically means implementing a "Boundary Clock" or a "Transparent Clock", in which efforts are made to mitigate or eliminate the variable delays that timing packets experience when being switched through a network element. These types of techniques are seen as necessary to achieve the sort of phase-sync performance levels that the ITU-T and 3GPP are working on to support some of the LTE-A technologies talked about elsewhere on this blog. Increasingly there is a realisation that on-path support can also extend to "frequency assistance" from the physical layer. This implies a PRC-traceable frequency is somehow available to the element, either through classical SDH/SONET or Synchronous Ethernet sync trails, or possibly even a co-located or integrated GNSS timing receiver - integrating the SETS function from the physical layer with the time/phase functions from the packet-layer clocks. 

When "Next Generation Networks" were first mooted in the mid-00s, it seemed like there was a need for a new implementation of a single synchronisation technology to solve all the problems, as if either one of SyncE OR PTP would win the day. What is becoming more and more apparent is that both SyncE AND PTP AND now even GNSS technologies are part of the overall sync solution; techniques available for deployment in the toolbox of the network planners & designers. Some of the more elegant & sophisticated sync services I’ve seen recently are provided by integrating 2 or more of whatever sync technologies are available.

“Symbiosis” in a term usually applied to biological species that somehow live together for mutual benefit, but I’ve often seen it applied in a technological sense - and seems to fit right here - e.g SyncE and PTP can and do work together to increase the performance of the phase & time services that are being delivered.

SyncE is used as a source of long-term PRC-level stability that can drive a timebase with which packet timestamps are measured and hence network delays are estimated. Consider the usual implementation of a PTP Slave - its timebase is its local oscillator and the budget for this component will dictate the stability available to the algorithms that are time-stamping the PTP packets, estimating network delays and hence synthesising or steering that local timebase. Generally, the locking process of a PTP Slave is a two stage process: first, frequency lock is achieved with the master, and then phase lock is achieved. If physical layer frequency stability is available, then one immediate benefit is it speeds up the initial locking stage, as frequency-lock can generally be achieved much quicker with the physical layer signals than the packet layer. Once frequency and phase time lock is reached, having a stable frequency can holdover the phase/time lock through brief periods of packet loss, or through large step-changes in measured network delay (e.g. caused by network topology change/packet re-routes) hence vastly increasing the available performance available to network operators without having to deploy (relatively more expensive) atomic clocks.

Continue reading
1640 Hits

If the clock delivers, who cares about packets?

The most direct, and often least complicated, way to give visibility of whether packet timing technologies are delivering the expected synchronisation performance is to measure the produced or synthesised signals at the slave clock. Whether sync is delivered across a Carrier Ethernet, Microwave, or IP/MPLS network using IEEE 1588v2 (PTPv2) the ‘business end’ and proof of slave clock performance can be ascertained via the frequency, pulse, or time-code produced by it.

Connecting to a frequency, 1PPS or time-code output of a slave clock is often much quicker to perform and the, subsequent results simpler to analyse, than the more complicated procedures required to measure the performance or Packet Delay Variation (PDV) of an Ethernet or IP timing flow.

If the measured output performance is within specification for that part of the network, it doesn’t matter that PTPv2 packets may be occasionally dropped in the network or that the PDV sometimes strays outside the nominal quality levels because as long as the application is getting the quality of clock it requires then packet performance is of secondary importance.

Packet Delay Variation of the PTPv2 flow worries some engineers and they can, and do, invest valuable time and resources trying to unnecessarily find and solve perceived issues. From experience and sync monitoring projects, Chronos experts know that well engineered networks and PTPv2 clients will produce in-specification clock in many types of network conditions and this can be verified by monitoring the frequency, pulse or time-code from a test point. Of course if the measured clock is not within specification then investigation into the incoming flow is required but it does not need to be the first step.

Continue reading
2701 Hits