In legacy networks the frequency and time synchronization is achieved

from 2MHz or 2Mbps clock or line clock derived from PCM. In case of GSM and WCDMA , base stations
need to have accurate frequency and phase synchronization , since frequency alignment in air interface
is crucial in case of handovers. In TDM backhaul networks, BTS/NodeBs receive clock through E1 from
RNC/BSCs which are synchronized to SDH clock through direct connectivity to 2Mbps (BITS) or 2Mhz
clock from SDH equipments or SSUs. Where as in case of All IP networks the base stations need to
extract synchronization from the underlying packet network itself. For synchronization of packet
networks, the available methods are Synchronous Ethernet (SyncE), NTP and IEEE 1588 V2 (Precision
Time Protocol version 2).

The Synchronous Ethernet provides frequency synchronization only, while it

does not support phase synchronization which is also important in the case of wireless access
elements especially when LTE is introduced. The SyncE distributes a frequency on the physical Ethernet
layer from a primary reference source which may be typically referring to signals from a GPS unit. In
SyncE, the synchronization is provided in the physical layer (frequency generated from hardware
interrupt in L1 known as PHY -level) and hence implementing SyncE in the network relies on support of
SyncE in every node along the synchronization path. Though SyncE provides a relative time reference, it
does not carry absolute time information. The SyncE is mainly used for frequency synchronization of
packet networks. [ In DTR nothing is mentioned about SyncE. But in Sl no 6 of addendums
mentioned in the tender document regarding Clarifications to Queries raised earlier, Query No 875
mentions about DTR clause 13.4.27 (viii) which states that Synchronization shall be supported
through external 2.048 Mhz signal, GPS, Timing over packet as per IEEE 1588v2, BITS and Synchronous
Ethernet ( all methods to be supported). The hardware for GE interface shall support Synchronous
Ethernet. For clarification sought by vendors for adoption of any one suitable method for
synchronization according to the type of equipment (whether all-IP or TDM based), BSNL had
responded that this clause will be governed by DTR clause 1.26, by which availability of
synchronization through IEEE 1588v2 (PTP v2) is a must for IP interfaces and networks. But clause
13.4.27 (viii) is not available in Section 5 PART B of the DTR, though it appears in the addendum.]

The IEEE 1588v2 standard was introduced in 2007 and it defines algorithms for
both frequency and time synchronization through Precision Time Protocol version2 (PTP v2). It follows
a master slave synchronization technique and does carry absolute time information. The
synchronization is done at the packet layer rather than at the physical layer as compared to SyncE. The
PTP packets containing Time-Stamp information is sent from a Time-Stamp master (master clock
source: PTP master or server ) to a Time-Stamp slave (PTP client). The PTP client recovers the accurate
Time-Stamp from the master by using a round trip time calculated from the mean delay measured for
each of the directions through the network. Thus PTP provides an absolute time reference. Based on a
proportion factor calculated at the slave device , the PTP calculates a frequency reference also. The PTP
typically is implemented in the master source node and in the client node where the synchronization is
recovered. The PTP event packets can be tunneled through the switches and routers in between the
master and the client node without processing the Time-Stamps. The PTP packets will be processed
only at the end nodes, that is at the master node and at the client node. The accuracy of PTP depends
on the transport properties of the PTP packets over the network between the master and the client. If
the forward and return paths are not symmetric (not the same path), the accuracy will be sacrificed.
Also variations in packet delay along the path (Packet Delay Variation) also affects the PTP accuracy.
Hence any asymmetry in delay or Packet Delay Variation needs to be compensated. The Packet Delay
Variations along the PTP path can be compensated by implementing PTP in switches and routers
residing in the PTP packets traversal path. These switches and routers will act as Transparent Clocks
(TC), providing correction mechanisms to provide more PTP accuracy. [ Presently PTP is disabled in
ZTE Edge and Core routers and switches such that the PTP packets will be tunneled through them
without further processing. In the case of Kerala Circle, the IP nodeBs are connected to RNCs via NIB
backbone. So the functioning of PTP needs to be ascertained in this case through NIB. If we use the
in built IP clock server in RNC, we may allow connecting nodeBs to RNC via our core network MPLS
backbone so that we may test ZTE routers and switches as Transparent Clocks (TC), which correct
Time-Stamps from master clocks to compensate for the Packet Delay Variations towards PTP
clients(BTSes). But in the tender addendum for clarification Query No: 1877 for DTR clause 12.1.3,
which states that IP Clock servers in redundant mode shall be provided in each LSA and BSS
network synchronization shall be achieved as per IEEE 1588v2, BSNL had responded that 1) The
requirement to have in built IP clock servers for each RNC is dropped. 2) The IP clock servers shall be
capable for serving the BTSs, Node-Bs, eNode-Bs in the LSA which shall be assumed as
2000(minimum). In case one clock server has limitation to serve so many, multiple clock servers in
1+1 configuration shall be proposed suitably. From this clarification it is clear that the vendor has to
supply central IP clock servers with GPS reference. In present set up, even if the IP clock servers are
distributed in BSCs/RNCs they are not referring to any reference source like GPS. So each RNC/BSC
and its BTSs/nodeBs may be in PTP synchronization, but two adjacent BTSs/nodeBs belonging to
different BSC/RNC may not in PTP sync and this may affect inter BSC/RNC handovers. ]

[ The governing DTR clause 1.26 is furnished below.]

(i) The non IP interfaces of all the network elements shall support both of
the following synchronization methods:
1.26 i) (a) Extraction of embedded clock of the traffic carrying E1.
(b) Synchronizing to the external 2MHZ clock OR Synchronizing to the
external 2Mbps non+traffic carrying clock.
 (ii) The requirement at the IP interfaces of all the network elements are
below:.
a. Availability of synchronisation through IEEE 1588 V2+2008 standard is
a must for IP interfaces and networks.
b. The management of the IP Clock server IEEE+1588 +2008 [either
distributed in RNCs etc or centralised in the LSA] shall be provided centrally.
It shall be possible to connect the management functions to an NMS through
standard interfaces.
c. The redundancy of the IP clock server shall be 1+1. In case the Clock
servers are co+located with RNCs and BSCs it shall be possible for the clients
to switchover automatically to the best available alternate synchronisation
1.26 ii) clock sources.
d. The clock servers shall have redundant rubidium holdover. They shall
be provided with GPS system/antenna with a minimum of 90m cable and
associated lightning protection.
e. The PTP server to client inter+operability with different equipment
shall be available so that smooth integration with network elements of
existing network is possible.
f. The capacity in terms of packet rate shall be sufficient for catering
to the new 2G & 3G network and the existing 3G network. The capacity shall
be explicitly stated in the bid response. But, the IP clock servers shall be
capable of serving the core network, BTSs & Node+Bs in the LSA which shall
be assumed as minimum 4000