Need of Synchronization for Telecom Network

based on
IEEE 1588v2 PTP (Precion Time Protocol)
Telecommunication networks are evolving from TDM networks based on circuit-switched
technology to so-called Next Generation Networks (NGN) based on packet-switching. The driver
of this evolution is cost reduction; the technical goal is the transport of all telecommunication
services over a unified and packet-switched platform. Ethernet is already playing an important
role in the network convergence scenario. Ethernet started as a LAN technology for enterprise
networks, and is now being used in base station backhaul and aggregation networks, and even
in metro networks. It turns out that many access network technologies require some form of
synchronization. This is the case for all cellular mobile networks which require their base
stations to be synchronized. Some of these technologies require synchronization of their
equipment clocks in frequency, some in phase.
Traditional Ethernet is not designed for the transport of synchronization. Therefore the use of
Ethernet in aggregation and backhaul networks is problematic for all access technologies in
need of synchronization. The answer to the problem is addressed through new synchronization
technique called as: PTP (Precision Time Protocol) and Synchronous Ethernet (SyncE). ITU-T
has published new recommendations for synchronization need which are described more in
detail in below section.
The Precision Time Protocol (PTP), also known as IEEE1588, is a standardized protocol
defined by the IEEE, coming initially from the automation world. The initial objective of this
protocol is to deliver time synchronization with a very high accuracy (sub-microsecond) in a LAN
environment. Therefore, IEEE 1588 is NOT a technology dedicated only to telecom.
Two versions of PTP have been released. Version 1 exists since quite a long time, and is really
targeting applications others than telecom. The version 2, approved by IEEE in 2008
(IEEE1588-2008), provides new features that can be useful to telecom applications. However,
there is a need to define in details the options and parameters of PTPv2 in order to enable this
protocol to be used in a telecom environment. This is part of the so-called "telecom profiles"
definition.
ITU-T has defined a PTP telecom profile for end-to-end frequency distribution in the
Recommendations G.8265 and G.8265.1, released in 2010. End-to-end means that the nodes
in the synchronization path (the path the PTP packets follow from the grandmaster to the slave)
do not embed PTPv2 functions.

Other PTP telecom profiles are currently under definition at the ITU-T to address the phase and
time distribution by the network in the Recommendations G.827x. These profiles will rely on the
fact that all the nodes (full on path support) or only some nodes (partial support) in the
synchronization path embed PTPv2 functions.
According to IEEE1588-2008 standard : The PTP protocol is a distributed protocol that specifies
how the real-time PTP clocks in the system synchronize with each other. These clocks are
organized into a master-slave synchronization hierarchy with the clock at the top of the
hierarchy - the grandmaster clock - determining the reference time for the entire system. The
synchronization is achieved by exchanging PTP timing messages, with the slaves using the
timing information to adjust their clocks to the time of their master in the hierarchy.
The following figure illustrates the basic PTP dialog between master and slave when PTP is
used as a two-way protocol and Delay_request / Delay_response messages are used:

Figure 1: Principle for PTP algorithm

Master and slave have their own internal reference clock, and the purpose is to align slave
internal clock on master reference clock. Thanks to the dialog depicted in the figure above, the
slave knows the four timestamps t1, t2, t3, and t4, and will use them to calculate the offset its
internal clock experiences compared to master reference clock, using the following formula:
Toffset = [ (t2 - t1) (t4 - t3) ] / 2
This calculation assumes that the delays in both directions (delay from Master to Slave and
Delay from Slave to Master) are symmetric, and at worst that the asymmetry is fixed and known
(otherwise, it is not possible to determine and compensate the slave internal clock offset).
PTP is therefore normally a two-way protocol, since messages are exchanged between master
and slave in both directions. However, it is possible to use PTP as a one-way protocol, using
only the "Sync" messages, in order to deliver only frequency. In this case, the calculation differs
from the previous formula, and is based in general on adaptive clock recovery principles,
which consists in recovering frequency synchronization via packets.

As described in figure 1, the basic PTP dialog consists for the master to send "Sync" messages
containing timestamps to the slave. Note that "Follow-up" messages are optional; when used,
they are combined to the "Sync" messages in order to deliver more accurate time stamps (this
feature is especially used in case of software implementation in the master, or in case the
implementation is not fast enough to insert the precise timestamp in the "Sync" message on the
fly). These two approaches correspond to the notions of "one step clock" when the precise
timestamp is directly inserted in the "Sync" messages, and "two-steps clock" when a "Follow-up"
message is used to transmit the precise timestamp.
When PTP is used with the two-way mode (for phase and time delivery), the slave initiates the
path delay calculation, e.g. by issuing "Delay_Request" messages to the master, which answers
by "Delay_Response" messages, in order to calculate and compensate the delay that the
packets spend through the network. In case of asymmetry in the links, the protocol is not
capable to determine and compensate it and there will be a time error in the calculation of the
slave internal clock offset. For instance over fibre links, it is generally agreed that a meter of
length difference between the two ways will generate roughly 2.5 ns of time error. Potentially
this error may accumulate over the links of the synchronization path.
In order to fight against Packet Delay Variation (PDV also called packet jitter) two mechanisms
are defined in the protocol, based on hardware and software PTPv2 functions embedded in
nodes:

Telecom Bounday Clock (T-BC): it acts like a slave on the ingress port (connected to a
master) and as a master on the egress port (connected to slave(s)). This allows to
compensate the internal latencies and jitter of the node.

Telecom Transparent Clock (T-TC): it measures the time of residence of the PTP packet
in the node by time stamping its arrival time on the ingress port and its departure time on
the egress port. The difference is inserted on the fly in the PTP packet in the correction
field.

It has to be remembered that those mechanisms, as part of the PTP protocol, will not help to
fight against links asymmetry.
As mentioned previously ITU-T is currently defining two telecom profiles for phase and time
delivery:

G.8275.1 is the phase/time profile assuming full on-path support i.e. assuming that all
equipments between the master clock and the slave clock support PTPv2 functions (T-BC
or T-TC), most likely the selection could be for T-BC. This profile is expected to be
finalized very soon (Probably in April 2014). A combination with Synchronous Ethernet is
possible in order to improve the performance and the time holdover in case of PRTC
failure.
G.8275.2 is the phase/time profile assuming partial on-path support i.e. assuming that not
all equipments between the master clock and the slave clock support PTPv2 functions.
The discussion have only started on this profile and its feasibility has first to be
demonstrated before any work starts on this recommandation. Therefore at this point of
time, this solution should not be considered as an applicable solution to deliver phase and
time with the proper quality.

Evolving Synchronization Need:

Mobile subscribers demand more and more bandwidth to support high-speed data and
multimedia applications. Text messaging no longer satisfies subscribers needs. Unlike voice
services, mobile broadband is always-on and considered to be always available. To satisfy this
demand, reduce costs and improve operating efficiencies, mobile operators around the world
are evolving their Radio Access Networks (RAN). Various capacity-enhancing techniques
enable them to squeeze more out of their macro cell networks. These techniques, however, do
not sufficiently scale in dense urban areas where data traffic is rapidly increasing. Public access
small cells have emerged as a cost-effective way to improve coverage and capacity of mobile
services in such locations. Small cells are low-power wireless access points that operate in
licensed spectrum, are operator-managed and feature edge-based intelligence.
based on packet protocols like IEEE 1588v2 Precision Time Protocol (PTP) have been Mobile
network operators face many challenges when starting to rollout small cells, upgrading to LTEAdvanced and utilizing unpaired spectrum. One challenge is synchronizing base station clocks
to operate in phase. In the past, a centralized primary reference clock or distributed primary
reference clocks using Global Navigation Satellite Systems (GNSS) such as Global Positioning
System (GPS) were the technologies of choice for synchronization. With the emerging
requirement for precise phase synchronization and concerns about relying only on GNSS,
methods developed to deliver an accurate synchronization signal over mobile backhaul
networks. Clock synchronization is trivial, in principle. The problem is that packet-based
backhaul networks introduce delay that can be unpredictable, asymmetrical and highly variable.
The key challenge is to be able to cope with these variations and to robustly and precisely
negate the errors caused by delay variability.
As explained above, IEEE 1588v2 PTP specifies different types of clocks and acts as a master
to slave protocol exchanging packets in both directions that carry time stamps for recovering
frequency, phase and time-of-day information. A slave clock in an end device is known as an
Ordinary Slave Clock (OC-S), a clock in a transmission component like a Carrier Ethernet
aggregation or network demarcation device is a Boundary Clock (BC) or Transparent Clock
(TC). A Grandmaster (GM) linked to a Primary Reference Time Clock (PRTC), which is
controlled ideally by a radio clock or a GNSS receiver, synchronizes the respective slaves
connected to it. Operators tend to use PTP to provide synchronization directly across any
packet network. However, it is to be ensured that the synchronization flow is not distorted by
packet loss, asymmetrical delay or delay variation beyond the filtering capabilities of the slave
clock.

On-Path Timing Support:

The new LTE-Advanced functions require base station clocks to be in phase with accuracy in
the range of few hundred nanoseconds to efficiently operate eICIC (Inter-Cell Interference
Coordination), CoMP (Coordinated Multipoint Transmission) and ensure location based
services. This clock accuracy is difficult to achieve without on-path support, i.e. backhaul
networks need to participate actively in timing distribution. With Recommendation G.8275.1, the
ITU-T is going to define a Telecom Profile facilitating end-to-end frequency and phase
synchronization across packet-based backhaul networks with on-path support. G.8275.1 will
indicate the deployment of BCs wherever there is a network component that inserts significant

delay fluctuation. A BC has multiple network connections and can accurately bridge
synchronization from one network segment to another. BCs improve the accuracy of clock
synchronization by filtering network jitter and deliver better scale on the master.

Hybrid Technology Option:

Synchronization techniques may be deployed in conjunction with others, providing a more
robust and reliable solution. The PTP and Synchronous Ethernet (SyncE) may be used cooperatively to deliver a frequency and time-of-day signal, taking advantage of the physical layer
to transport traceable frequency information. ITU-T Recommendation G.8271.1 is going to
describe a reference model where SyncE is used to syntonize a chain of BCs from the master to
the slave. The stability of the frequency reference reduces the dynamic time error accumulated
in the chain of BCs, allowing PTP to deliver a time reference accurate to a few hundred
nanoseconds. In addition, the stable frequency reference can be used to maintain accurate time
synchronization for a certain period of time if the connection to the GM was broken.

Summary about 1588v2 Telecom Profiles:

ITU-T Recommendation G.8265.1 defines a telecom profile aimed at the distribution of accurate
frequency over packet networks. This is primarily intended for use with synchronization of radio
base stations, where the main requirement is to operate the radio interface at a frequency
accuracy of within 50 parts per billion, which requires the recovered clock to operate within 16
parts per billion. 1588v2 PTP phase and time distribution across packet networks will be
addressed by the telecom profile defined in ITU-T Recommendation G.8275.1. The upcoming
standard mandates the deployment of a BC at each intermediate node in conjunction with the
use of SyncE to syntonize the chain of BCs from the master to the slave. It is targeted to fulfill
the stringent requirements for phase synchronization imposed by interference coordination and
radio spectrum control in LTE-Advanced. Delivering phase accuracy in the range of few hundred
nanoseconds is envisaged. The approach anticipated in the ITU-T Recommendation G.8275.2
aims at time and phase distribution with partial support from the backhaul network in contrast to
full on-path support. Both architecture and performance aspects of this telecom profi le still need
to be specified. Partial network support would allow for simpler design of mobile
backhaul networks.
The