075 Synchronization For LTE Small Cells

www.scf.io/ www.smallcellforum.
org
DOCUMENT
Synchronisation for LTE small cells
December 2013
075.04.01
Produced in partnership with the
Metro Ethernet Forum (MEF)
scf.io/
SMALL CELL FORUM
RELEASE Four
If you would like more information about Small Cell Forum or would
like to be included on our mailing list, please contact:
Email info@smallcellforum.org
Post Small Cell Forum, PO Box 23, GL11 5WA UK
Member Services memberservices@smallcellforum.org
SMALL CELL FORUM
RELEASE Four
Small Cell Forum supports the wide-scale deployment of small cells. Its mission
is to accelerate small cell adoption to change the shape of mobile networks and
maximise the potential of mobile services.
Small cells is an umbrella term for operator-controlled, low-powered radio access nodes,
including those that operate in licensed spectrum and unlicensed carrier-grade Wi-Fi. Small
cells typically have a range from 10 metres to several hundred metres. These contrast with
a typical mobile macrocell that might have a range of up to several tens of kilometres. The
term small cells covers residential femtocells, picocells, microcells and metrocells.
Small Cell Forum is a not-for-prot, international organisation. Its membership is open
to any legally established corporation, individual rm, partnership, academic institution,
governmental body or international organisation supporting the promotion and worldwide
deployment of small cell technologies. At the time of writing, Small Cell Forum has around
150 members, including 68 operators representing more than 3 billion mobile subscribers
46 per cent of the global total as well as telecoms hardware and software vendors,
content providers and innovative start-ups.
Small Cell Forum is technology-agnostic and independent. It is not a standards-setting
body, but works with standards organisations and regulators worldwide to provide an
aggregated view of the small cell market.
This document forms part of Small Cell Forums Release Four: Urban. Urban small cells
are at an earlier stage in their commercial development than their more mature residential
and enterprise counterparts. As such, the present Release focuses on establishing the need,
evaluating the business case and identifying key barriers to commercial deployment. It
offers shared deployment learnings from leading operators and vendors, further renement
of our technical works and reporting progress on our activities to strengthen the ecosystem
through improved multivendor interoperability.
Release Four also contains works clarifying market needs and addressing barriers to
deployment of residential, enterprise and rural small cells.
Small Cell Forum Release website can be found here: www.scf.io and an overview of all the
material in Release Four: Urban can be found here: www.scf.io/doc/104
All content in this document including links and references are for informational purposes only and
is provided as is with no warranties whatsoever including any warranty of merchantability, tness
for any particular purpose, or any warranty otherwise arising out of any proposal, specication, or
sample.
No license, express or implied, to any intellectual property rights is granted or intended hereby.
2007-2014 All rights reserved in respect of articles, drawings, photographs etc published in
hardcopy form or made available in electronic form by Small Cell Forum Ltd anywhere in the world.

Report title: Synchronization for LTE Small Cells
Issue date: 03 December 2013
Version: 075.04.01
Scope
A previous Small Cell Forum white paper, Femtocell Synchronization and Location [1],
outlined the timing and synchronization needs for femto and small cells, and covered
many of the methods used to meet those needs with some technical detail.
As LTE and LTE-Advanced are deployed in place of or along side 2G and 3G
technologies, there are additional requirements on synchronization, including the
wider need for very tight time synchronization.
This paper describes these new requirements and the technologies available to fulfil
those needs.
Note: Small cells may be based on distributed or centralized baseband architecture.
In case of centralized baseband architecture the remote radio units can be connected
to a common baseband unit, e.g. via CPRI. Unless specifically mentioned, this white
paper focuses on the distributed baseband architecture.

Version: 075.04.01
Executive summary
All cellular radio base stations require synchronization, including small cells. This may
be frequency synchronization, phase alignment to other base stations, or in the case
of CDMA and CDMA2000, time synchronization. In earlier 3GPP releases
synchronization was delivered using TDM network or GNSS. Today, with the all IP
asynchronous networks and indoor small cells deployments operators need to rethink
their synchronization delivery strategy.
Section 1 of this paper introduces the relevant requirements for the various types of
radio technology, including LTE and LTE-Advanced, referencing the appropriate 3GPP
technical specifications. Broadly speaking, FDD systems require only frequency
synchronization of 50 250ppb (parts per billion), but TDD systems have an
additional requirement for phase alignment of less than 3s, relative to other cells
with overlapping coverage.
For some LTE-Advanced features (e.g. eICIC, CoMP and MBSFN), no synchronization
requirements have been specified, but that does not mean no requirements exist.
Rather, there is a soft limit based on vendor implementation and operator
deployment type. This limit is in the region of 1-5s relative phase alignment.
For LTE small cells, the level and type of synchronization required depends as much on
the cell location as it does on the technology used. For example, a small cell using
TDD technology, but located in a remote area with no overlapping macrocell coverage
will only need frequency synchronization, since there is no reference for any phase
alignment. Similarly, FDD small cells in less dense environments will not require LTE-
Advanced features such as eICIC or CoMP, and may therefore only require frequency,
while a small cell in a dense urban environment may require both phase and
frequency to support LTE-A.
Section 2 of the paper describes several different types of small cell deployment, and
identifies which LTE and LTE-Advanced features each are likely to use. It summarises
the level and type of synchronization required for each type of small cell deployment.
Sections 3 and 4 introduce the different techniques that may be used to synchronise
small cells, and list the advantages and disadvantages of each. These sections do not
cover any given technique in detail, but provides an introduction and relevant
references that may be consulted for further information.
The techniques covered include:
Precision time protocol (PTP)
Network time protocol (NTP)
Synchronous ethernet (SyncE)
Global navigation satellite systems (GNSS, e.g. GPS)
Cellular network listening
PTP/NTP combined with assisted GNSS
Cellular network listening combined with assisted GNSS
SyncE combined with assisted GNSS
PTP combined with SyncE
Section 5 discusses the synchronization capabilities of different backhaul
technologies, and examines how they affect the choices for small cell synchronization.
Section 6 covers the impact on the service caused by degraded or lost
synchronization. In other words, what are the consequences of having poor

Version: 075.04.01
synchronization? In the case of FDD systems, if base station frequency is more than
250ppb out it could mean that any user equipment is simply unable to use that base
station, i.e. a complete inability to provide service. Smaller errors may lead to a
minor degradation in the data throughput. For TDD systems, again a reduction in
data throughput will begin to accumulate, along with a potential to interfere with
reception of the PCFICH (primary control format indicator channel), and consequent
loss of an entire sub-frame of data.
Section 7 describes some of the deployment use cases for synchronization delivery by
either the mobile operator or the backhaul provider. Finally, section 8 discusses
network maintenance and troubleshooting in the event that the service issues
described in Section 6 are experienced. It also describes solutions for synchronization
monitoring and assurance.

Version: 075.04.01
Contents
1. LTE synchronization requirements ...................................1
1.1 General cellular radio synchronization requirements................. 1
1.2 LTE co-ordination requirements ............................................. 3
1.3 Holdover requirements of LTE small cells ................................ 4
2. Small cell use cases and deployment scenarios ................5
2.1 Targeted capacity hotspot .................................................... 5
2.2 Indoor coverage .................................................................. 6
2.3 Outdoor coverage ................................................................ 8
2.4 Non-targeted capacity (quality of experience enhancement) ..... 9
2.5 Summary ........................................................................... 9
3. Synchronization technology options ............................... 10
3.1 IEEE1588 precision time protocol ........................................ 10
3.2 Network time protocol (NTP) ............................................... 15
3.3 Synchronous Ethernet (SyncE) ............................................ 17
3.4 GNSS for telecom timing .................................................... 19
3.5 Cellular network listen ........................................................ 21
3.6 Miniature atomic frequency references ................................. 24
4. Hybrid technology options .............................................. 25
4.1 PTP/NTP and assisted GNSS ................................................ 25
4.2 Cellular network listen and assisted GNSS ............................ 26
4.3 Use of SyncE to allow enhanced GNSS holdover .................... 26
4.4 PTP and SyncE .................................................................. 27
5. Synchronization capabilities of backhaul technologies ... 29
5.1 Millimetre wave: 60, 70-80 GHz .......................................... 29
5.2 Microwave: 6-60 GHz ......................................................... 30
5.3 Sub-6 GHz licensed spectrum ............................................. 30
5.4 Satellite ........................................................................... 31
5.5 FTTX (e.g. EPON, GPON) .................................................... 31
5.6 Fiber (active components) .................................................. 32
5.7 Digital subscriber line (XDSL) .............................................. 32
5.8 Leased connectivity ........................................................... 33
6. Service impact ................................................................ 34
6.1 LTE-FDD ........................................................................... 34
6.2 LTE-TDD .......................................................................... 36
6.3 Holdover .......................................................................... 37
7. Synchronization deployment use cases .......................... 42

Version: 075.04.01
7.1 Synchronization services implemented by mobile operators .... 42
7.2 Synchronization services offered by backhaul providers .......... 42
7.3 Synchronization services implemented by mobile operators
and backed-up by backhaul providers .................................. 43
8. Synchronization maintenance and service assurance ..... 45
8.1 Synchronization maintenance .............................................. 46
8.2 Synchronization service assurance ....................................... 46
9. Conclusions and future work .......................................... 48
References ................................................................................ 49

Tables
Table 1-1 Frequency and phase synchronization requirements for different ran
standards ...................................................................................... 2
Table 2-1 Targeted capacity use cases ............................................................. 6
Table 2-2 Indoor coverage cases ..................................................................... 8
Table 2-3 Outdoor coverage cases .................................................................. 9
Table 3-1 Synchronization techniques ............................................................. 10
Table 6-1 Oscillator phase stability ................................................................. 41

Figures
Figure 3-1 IEEE 1588 protocol ........................................................................ 12
Figure 3-2 Physical layer clock distribution ....................................................... 18
Figure 4-1 Reference model architecture from G.8271.1..................................... 27
Figure 6-1 Subset of the time/frequency downlink map ...................................... 34
Figure 6-2 Sub-carrier overlap with frequency difference between cells ................ 35
Figure 6-3 Special sub-frame .......................................................................... 37
Figure 7-1 Synchronization service implemented at the mobile operators access
network ........................................................................................ 42
Figure 7-2 Synchronization service implemented by the backhaul provider ........... 43
network and a backup service implemented by the backhaul provider .. 44
network and a backup service implemented by the mobile operator ..... 44
Figure 8-1 deployment case 1 network limits measurement, option A .................. 45
Figure 8-2 Deployment case 1 network limits measurement, option B .................. 45
Figure 8-3 Deployment case 1 network limits measurement, option C .................. 46
Figure 8-4 Upper/lower KPIs ........................................................................... 47

Acknowledgements
We would particularly like to thank the following members that provided significant contributions
to this paper. In alphabetical order: ADVA Optical Networking, Airvana, AT&T, BlinQ Networks,
Calnex Solutions, CBNL, Ceragon, Comcast, Ericsson, iDirect, ip.access, Nokia-Siemens
Networks, Perpetual Solutions, Rakon, Siklu, Sprint, Symmetricom, u-Blox

Issue date: 8 November 2013
Version: 0.40
1
1. LTE synchronization requirements
1.1 General cellular radio synchronization requirements
In frequency-division duplex (FDD) systems the downlink transmission and the uplink
transmission take places in separated frequency bands. Frequency synchronization
was needed for second and third generation air interfaces, and continues to play a
critical role in LTE FDD systems. The LTE downlink air interface relies on the
orthogonal frequency division multiple access (OFDMA) transmission technique in the
downlink. Single carrier-frequency division multiple access (SC-FDMA) has been
selected for the uplink direction. OFDMA presents tremendous benefits in terms of
high spectral efficiency, minimal implementation complexity, support of advanced
features such as frequency selective scheduling, multiple-input multiple output (MIMO)
transmission, immunity to multipath interference and interference coordination.
However, these advantages require that the orthogonality between subcarriers is
strictly preserved. In OFDMA systems, synchronization is required between the
eNodeB and the user equipment (UE) because the sample timing errors can destroy
the orthogonality between the subcarriers. The orthogonality between the subcarriers
prevents overlapping of the subcarriers spectra, which would result in interference
between subcarriers. Any mismatch between the eNodeB and the UE oscillators
and/or Doppler shift due to the mobility of the UE generates frequency offsets
between the UE and eNodeB and a misalignment between the reference frequencies of
the eNodeB and the UE.
A frequency offset can also lead to dropped calls during handover between eNodeBs.
During the handover procedure a UE needs to determine the timing and frequency
parameters of the eNodeB in order to be able to demodulate the downlink signal and
also to transmit correctly on the uplink. One of its first steps is to go through a cell
search procedure, which includes finding the centre frequency of the RF carrier from
those defined by the standard. The frequency stability tolerance of the UE oscillator is
typically maintained at 0.1 ppm to minimise cost. Its stability is maintained by
tracking the eNodeB carrier frequency.
In time-division duplex (TDD) systems, downlink and uplink transmission occur in the
same channel but in different time slots. Phase synchronization is therefore required
in LTE TDD to avoid interference between the uplink and the downlink transmissions
on neighbouring eNodeBs.
The general synchronization requirements for both frequency and phase and time are
listed in Table 1-1 below. Note that these are the requirements of the radio
technology, and not the budget allocated to the synchronization system, which will be
correspondingly lower. While the focus of this white paper is on the requirements for
LTE small cells, the requirements are broadly similar to those of predecessor
technologies, such as GSM, UMTS and CDMA. The synchronization requirements of
those technologies are shown in Table 1-1 for reference.

Version: 0.40
2
Radio
technology
BTS type
Frequency
accuracy
Phase
difference
Time
accuracy
Technical
specification
Notes
GSM
Macro BTS 50ppb
3GPP TS 45.010 [2]
Clause 5.1
Frequency
accuracy at the air
interface
Pico BTS 100ppb
All
3.69s
(optional)

3GPP TS 45.010 [2]
Clause 5.2
Optional BTS
alignment of 1
symbol period
CDMA2000
Macro 50ppb
3GPP2 C.S0010 [3]
Clause 4.1
Frequency
accuracy at the air
interface
Pico/Femto 100ppb
All
3s (norm)
10s
(max)
3GPP2 C.S0010 [3]
Clause 4.2
Pilot time
alignment error to
CDMA system time
WCDMA-
FDD
Wide Area 50ppb
3GPP TS 25.104 [4]
Clause 6.3.1
Frequency
accuracy at the air
interface, over one
timeslot period
(0.67ms)
Med. Range 100ppb
Local Area 100ppb
Home 250ppb
WCDMA-
TDD
(including
TD-SCDMA)
Wide Area 50ppb
3GPP TS 25.105 [5]
Clause 6.3.1
Frequency
accuracy at the air
interface, over one
timeslot period
(0.67ms)
Local Area 100ppb
Home 250ppb
All 3s
3GPP TS 25.123 [6]
Clause 7.2
Maximum
deviation in frame
start times at the
air interface
All 2.5s
3GPP TS 25.402 [7]
Clause 6.1.2.1
Relative phase
difference at the
synchronization
input
WCDMA
MBSFN
12.8us
3GPP TS 25.346 [8]
Clause 7.1B.2.1
Optional feature -
Release 8 onwards
LTE
(FDD and
TDD)
Wide Area 50ppb
3GPP TS 36.104 [9]
Clause 6.5.1
Frequency
accuracy at the air
interface, over one
sub-frame period
(1ms)
Med. Range 100ppb
Local Area 100ppb
Home 250ppb
LTE-TDD
Wide area,
>3km radius
10s
3GPP TS 36.133
[10] Clause 7.4.2
Maximum
deviation in frame
start times at the
air interface
(for cells on the
same frequency
with overlapping
coverage areas)
Wide area,
3km radius
3s
Home BS,
>500m rad.

1.33 +
Tprop s
1

Home BS,
500m rad.
3s
LTE
handoff to
CDMA2000
(if req'd.)
10s
3GPP TS 36.133
[10] Clause 7.5.2
Maximum time
difference between
eNodeB frame
boundaries and
CDMA system time
Table 1-1 Frequency and phase synchronization requirements for different ran standards

1
Tprop is the propagation delay between the Home BS and the cell selected as the network listening
synchronization source

Version: 0.40
3
1.2 LTE co-ordination requirements
OFDMA offers high spectral efficiency by N=1 reuse of the entire radio channel in all
cells, but can also suffer from high inter-cell interference (ICI) at the edge of the cells.
This reduces user throughput. Coordinated multipoint (CoMP) is a set of techniques
that has been designed to increase data throughput, especially at cell edges where
interference can be significant. These techniques can be applied between eNodeBs
(i.e. distributed baseband architecture) or, in case of the centralized baseband
architecture (e.g. remote radio units connected via CPRI to the common baseband
unit), between the radio units connected to the common baseband unit.
In case of both the distributed and centralized baseband architectures, CoMP requires
a cooperation mechanism between radio units, and can be applied to both downlink
and uplink. For a given time, frequency resource, CoMP may result in transmissions
from (or to) just one radio unit (coordinated scheduling/coordinated beamforming), or
from (or to) several radio units (joint processing). The CoMP technique requires the
radio units to be synchronised in frequency to avoid inter-carrier interference and also
in phase to avoid inter-symbol interference. Co-operating radio units should be close
enough in order to avoid signals with differential propagation delay arriving outside of
the OFDM cyclic prefix. Note that for some of the CoMP features very stringent
latency requirements between the cooperating radio units also apply (e.g. sub-
millisecond).
Inter-cell interference coordination (ICIC) was introduced in 3GPP release 8 to
mitigate interference from neighbouring cells. Early ICIC in 3GPP Release 8 and 9
deals only with the interference between data channels. 3GPP release 10 takes into
account the interference between the control channels as well. It introduced improved
interference management features, named enhanced ICIC (eICIC), and additional
functionality to manage interference between macro-eNodeB and pico-eNodeBs in
heterogeneous network (HetNet) scenarios. eICIC requires the eNodeBs to transmit
with phase-aligned carriers.
MBSFN is a transmission mode where multicast or broadcast data may be transmitted
as a multi-cell transmission over a synchronised single-frequency network (SFN). It is
typically expected to be used for mobile TV broadcasts of live events. The
transmissions from the multiple cells must be synchronised such that they arrive at
the UE within the OFDM cyclic prefix, avoiding inter-symbol interference.
The phase synchronization requirements associated with CoMP, eICIC and MBSFN
features have not been agreed by 3GPP, although values between 1 and 5s have
been suggested in some contributions. However, in a liaison statement to ITU-T (RP-
120884, RAN56, June 2012), it was stated that Currently no studies are on-going in
RAN WG4 and RAN WG4 has currently not defined any new synchronization related
requirement with a potential impact on the solutions for synchronization in packet
networks (i.e. frequency error on the transmitted signal as per TS 36.104, or cell
phase synchronization accuracy as per TS 36.133 still apply).
The main reason for this is that there is no hard limit where these techniques stop
working that can be defined in a standard specification. The limit is to some extent
dependent on the implementation. Therefore, certain vendor-specific requirements
may apply for phase synchronization of LTE co-ordination technologies.

Version: 0.40
4
1.3 Holdover requirements of LTE small cells
Traditionally, the clocks required for the base stations are derived from physical layer
connections or references like global navigation satellite systems (GNSS). When all
synchronization references from the network are lost or declared unusable, the
synchronization mechanism enters into a holdover state where the system generates
clocks from the last known good reference, with the last good frequency and phase
information available. It is assumed that there is no major frequency offset before
entering the holdover. The holdover state maintains the frequency stability and phase
accuracy requirements within the specified limits for a period of time.
In general, the standards requirements suggest distributing the effect of holdover
impairments across to various system elements. The holdover requirements in the
telecom standards (e.g. G.8263, [11]) budget for a transient phase change and for an
initial holdover accuracy related to the synchronization and servo algorithms. They
also include other parameters such as the effect of temperature variations, aging and
frequency drift at constant temperature relating to the oscillators.
For CDMA2000, C.S0010 [12] defines that the base station should maintain the
transmit timing accuracy to within 10s of CDMA system time for a period of eight
hours following loss of the synchronization reference (clause 4.2.1.1). For other
technologies, including LTE, the length of time during which the frequency and phase
accuracy must be maintained during holdover is not defined in standards, but depends
on the service provider's operational requirements.

Version: 0.40
5
2. Small cell use cases and deployment scenarios
From the Small Cell Forums Backhaul requirement white paper [13], small cell use
cases are grouped into four major categories comprising of targeted capacity hotspot,
indoor coverage, outdoor coverage and quality of experience enhancement (non-
targeted capacity). The use cases and related deployment/synchronization scenario
examples are described in the following sections.
2.1 Targeted capacity hotspot
A hotspot is deployed to add capacity to networks and fill spectrum gap, ease
congestion from the macrocell in congested traffic areas such as urban downtown,
traffic intersections, etc. and utilise existing spectrum effectively.
Example use cases include:
Dense urban underlay in congested outdoor urban deployments. This
provides offload to specific macrocells, but requires new backhaul access to
street furniture i.e., street lamps, traffic lights, CCTV sites, payphones or
notice boards. A typical area would be any concentrated traffic with peak
hours such as Times Square in New York or Oxford Street in London. Other
candidate locations would be urban access highways at rush hour or local
commuting at airports/train stations where a high-turn-over of customers is
expected.
Wi-fi complement complements the existing public Wi-Fi access points,
i.e. those deployed in hotspots with nomadic (non-mobile) characteristics
such as at Starbucks, McDonalds, and other contracted locations. It allows
normal voice traffic to route via a more economical network than the macro,
and offloads data traffic via Wi-Fi.
This hotspot use case is a primary driver for an urban or enterprise type of small cell
deployment, instead of residential. The synchronization requirements are therefore
different. For example, a residential small cell may require 250 parts per billion (ppb)
for frequency accuracy, an enterprise small cell may require a more demanding 100
ppb standard and an urban small cell, emulating the macro cell, may have an even
more stringent requirement of 50 ppb.
Dense urban underlays are provided to enhance capacity, and therefore may utilise
full co-ordination techniques such as eICIC and CoMP. As noted in section 1.2, time
and phase requirements have not yet been agreed, although values between 1 and
5s have been suggested by some vendors.
PTP, GNSS and cellular network listening are possible synchronization techniques for
this class of use cases.

Version: 0.40
6
Targeted
capacity
use case
Co-ordination
requirements
(e.g. eICIC,
CoMP)
Backhaul
type
View of sky
(GNSS
availability)
Macrocell
visibility
Sync requirements
Frequency Time/phase
Dense urban
underlay
Yes max
capacity
required
NLOS/LOS
microwave,
wired
(e.g. DSL,
GPON)
Restricted
(may be
urban
canyon)
Yes 100ppb
3s phase for
TDD
1-5s phase
for co-
ordination
10s time for
CDMA
fallback
Wi-Fi
complement
No Wi-Fi/LAN
Restricted
(may be
indoor)
Yes 100ppb
3s phase for
TDD
10s time for
CDMA
fallback
Table 2-1 Targeted capacity use cases
2.2 Indoor coverage
The indoor coverage use case is deployed to improve indoor public spaces with steady
daily nomadic (non-mobile) traffic and occasional peaks. Indoor deployments may
include enclosed structures that are isolated from the macrocell outdoor coverage,
buildings with limited macrocell coverage, and open structures such as stadiums.
Examples of indoor use cases are:
Dense urban indoor venues such as stadiums, convention centres,
shopping malls, office atriums, multi-tenant buildings, small to medium
offices, casinos/hotels or college campuses. While this could also be a
candidate for a distributed antenna system (DAS) system, the cost may be
excessive to run new fibre. Generally, Ethernet cabling exists throughout the
building and would be ideal for deployment of either small cell or enterprise
femtocell. As these venues are generally made of glass and metal, external
penetration from macrocells is problematic to impossible.
Dense suburban residences, such as large multi-family apartment
complexes provide particular challenges because of the closely packed nature
of the small cells. This may require interference co-ordination and therefore
time/phase synchronization.
Distributed suburban facilities, such as individual houses, shops or offices
have lower interference challenges because the small cells will be more
widely spaced.
Mobile small cells, covering indoor coverage in moving public
transportation systems such as buses, trains and planes. This is somewhat
similar to a relay node in that the penetration loss from the exterior of the
vehicle can be prevented. Also, by adopting the appropriate backhaul
method, the high-speed mobile users can be supported with seamless
handover. Backhaul placement (e.g. in a high-speed train) can be in the
form of wireless solutions with static hubs on fixed light poles spaced a
certain distance apart (along the high-speed train track) and a mobile remote
unit on each cars rooftop.
The traditional backhaul delivery could prove to be a challenge for an indoor use case.
For example, small cells may have no direct line of sight to satellites or there may be
a weak GNSS signal inside the building, making GNSS-based synchronization difficult.

Version: 0.40
7
Packet-based synchronization techniques like IEEE 1588 require that the PTP
grandmaster is close to the building entry points to reduce network asymmetry and
the consequent time error.
For dense urban venues, it may be possible to place the GNSS receiver on top of the
building, using the same GNSS receiver to generate PTP packets (i.e. the GNSS unit
itself becomes the local PTP grandmaster). The synchronization packets can then be
distributed over Ethernet LAN to multiple small cells.
Residential developments such as apartment blocks are unlikely to have the same
building LAN, therefore each small cell will be backhauled and synchronised
independently. The closely packed nature of the small cells may require interference
co-ordination. As GNSS capability may be restricted due to being indoors, PTP may
need to be used. Placing the PTP grandmaster as close as possible to the building
(e.g. at the local network aggregation point), will be important to minimise asymmetry
and accumulated time error.
For more distributed environments, small cells may be used to cover local not-spots
caused by terrain or building shadows. Such small cells will have lower interference
issues because they are more widely spaced.

Version: 0.40
8
Indoor
coverage
use case
Co-ordination
requirements
(e.g. eICIC,
CoMP)
Backhaul
type
View of sky
(GNSS
availability)
Macrocell
visibility
Sync requirements
Dense
urban
indoor
venue
Yes max
capacity
required
LAN
No indoors
Yes single
external point
No indoors
Yes single
external
point
100ppb
3s phase for
TDD
1-5s phase
for co-
ordination
Small office
Yes ICIC or
eICIC
(in dense office
blocks)
LAN
Restricted
(may be
indoor)
Possible
(may be
restricted
indoors)
250ppb
3s phase for
TDD
1-5s phase
for co-
ordination
Dense
suburban
residences
Yes ICIC or
eICIC
Wired
(DSL,
GPON)
Restricted
(may be
indoor)
No
(no need for
small cell if
visible)
250ppb
3s phase for
TDD
1-5s phase
for co-
ordination
Distributed
suburban
residences
No
Wired
(DSL,
GPON)
Restricted
(may be
indoor)
No
(no need for
small cell if
visible)
250ppb
3s phase for
TDD (if
overlapping)
Mobile
(train,
plane)
No
NLOS/LOS
wireless,
satellite
Yes Intermittent 100ppb TBD
Table 2-2 Indoor coverage cases
2.3 Outdoor coverage
The outdoor coverage use case is deployed to provide coverage in concert with
existing macrocell coverage or in isolation of the macrocells (in disaster recovery
support, say). Examples of outdoor use cases are:
Exclusive/restricted development such as a country club (golf
community) with high-end residences that do not, or have not previously,
allowed traditional cell site structures in or adjacent to the property.
Obviously, this creates problems in covering the location, especially in the
home, as customers expect.
Rural/notspot area, i.e. small cells deployed in an isolated town or village
with no macrocell coverage.
2

Distributed suburban environment and/or hilly terrain (with customer
or operator provided transport) such as residential areas, restaurants or
small businesses). Small cells may be used to cover local not-spots caused
by terrain or building shadows. The suburban neighbourhood is an example
supporting dynamic upgrade of residential areas with recurring high evening
peak traffic on mobile devices. Deployment is challenging with minimal
locations available due to zoning variance and neighbourhood resistance.
Such situations may require stealth sites in limited locations such as church

2
As defined by population density (not the size of localities).
According to the FCC Code of Federal Regulations (Title 47, parts 22 and 27), a rural area is defined as the
service area with population density of no more than 100 persons per square mile.
Similarly, EU and ITU defines a rural area as a place with 150 inhabitants per square km or less.
http://www.itu.int/dms_pub/itu-d/opb/ind/D-IND-WTDR-2010-PDF-E.pdf

Version: 0.40
9
steeples, flag poles, and tree poles. Backhaul placement could also be via
aerial cables, street light fixtures, etc.
Disaster recovery support (utilising MW or any available, deployable
broadband backhaul) providing rapid mobilisation of mobile services to a
disaster HQ or staging area while awaiting possible traditional cell-on-wheels
(COW) deployment, if necessary. Most immediate initial needs are for
command-post communications and COW deployment, which typically takes
several hours to days (depending on backhaul, availability, access, etc.).
Backhaul placement options are CCTV sites, notice boards, building walls, etc.
Outdoor
coverage use
case
Co-ordination
requirements
(e.g. eICIC,
CoMP)
Backhaul
type
View of sky
(GNSS
availability)
Macrocell
visibility
Sync requirements
Exclusive
development
No Wired Yes No 100ppb
3s phase for
TDD
Rural
notspot
No
Microwave,
wired
Yes No 100ppb
Distributed
suburban
No
Microwave,
wired
Yes Patchy 100ppb
3s phase for
TDD
10s time for
CDMA fallback
Disaster
recovery
No
Microwave,
wired
Yes No 100ppb
Table 2-3 Outdoor coverage cases
2.4 Non-targeted capacity (quality of experience enhancement)
This use case is engineered to enhance user perceived experience with respect to
service availability and not primarily designed for targeted capacity. The use case can
be thought of as a range extension for macrocells where peripheral coverage areas at
cell edge required quality of service (QoS) and enhanced data throughput. The cell
type could be a HetNet underlay coordinated as a seamless part of the macrocells.
This is sometimes referred to as peppered capacity.
Dense urban, suburban, and dense suburban in both indoor and outdoor and
exclusive/restricted properties exhibit the quality of experience (QoE)
enhancement examples that allow better customer perceived experience on service
availability. Frequency and phase synchronization are required for hotspot use case.
These cases are all summarised in the tables above.
2.5 Summary
To understand the synchronization requirements, typical use cases of small cell types
and their characteristics were given. This section identified different backhaul and
synchronization protocols that are required to support various small cell networks.

Version: 0.40
10
3. Synchronization technology options
There are a number of different technologies available to allow frequency, phase and
time synchronization between base stations. Some of these are network based, while
others are satellite or radio based techniques, and hence do not impact the backhaul
network.
Table 3-1 lists some of the available techniques. These are described in more detail in
the subsequent sections. In some cases, hybrid schemes may be deployed, combining
two or more of the individual techniques. These may help improve reliability and
accuracy, addressing the weaknesses of the individual techniques. Hybrid schemes
are discussed in Section 4.
Technique
Frequency
sync capable
Phase sync
capable
Time sync
capable
Synchronization distributed over the backhaul network:
Precision Time Protocol, PTP (IEEE1588) [14]

Network Time Protocol, NTP [15]

Synchronous Ethernet, SyncE [22] X X
Synchronization not using the backhaul:
GNSS (Global Navigation Satellite Systems)

Cellular Network Listening X
Miniature Atomic Frequency References

X X
Table 3-1 Synchronization techniques
3.1 IEEE1588 precision time protocol
The IEEE1588 precision time protocol (PTP, defined in IEEE1588, [14]) enables the
accurate distribution of time and frequency over a packet network (e.g. Ethernet or
IP). It was originally introduced to synchronise networked computer systems by using
a master reference time source and a protocol by which slave devices can estimate
their time offset from the master time reference. It achieves this by sending a series
of timestamped messages between the master and the slave devices, and vice versa.
3.1.1 Technology introduction
PTP was introduced to synchronise networked computer systems using a master clock
reference time and a protocol by which slave clocks can estimate their offset from the
master clock. The clock servo of a PTP slave uses a series of time-offset estimates to
co-ordinate the local slave time with the master reference master time.
A sequence of timestamped messages is used to estimate the time offset from the
master to the slave. There are four basic messages, described below and shown
pictorially in Figure 3-1.
SYNC message A message transmitted at a regular rate from the
master to all slaves. Contains a timestamp

Version: 0.40
11
identifying the time of message transmission from
the master measured in nanoseconds from a
known point in time known as the epoch. Most
PTP systems use the time 00.00.00 1 January
1970 as the epoch.
FOLLOW_UP message A message transmitted after each SYNC message,
containing a more precise version of the
timestamp, obtained by measuring the exact time
of transmission.
Some PTP clocks are capable of modifying the
timestamp in the SYNC message on-the-fly as it
is transmitted, and therefore do not need to
transmit the FOLLOW_UP message. Such clocks
are called one-step clocks. Clocks that need to
use the FOLLOW_UP message are called two-step
clocks.
In systems where a security protocol is used to
guarantee the integrity of the timing messages, it
may be necessary to use FOLLOW_UP messages,
since security protocols prohibit modification of
messages after transmission.
DELAY_REQ message (Delay Request) A message from the slave to the
master, requesting that the master inform the
slave of the precise time of arrival of the message
at the master. This is used to calculate the round-
trip time of the master-slave route.
DELAY_RESP message (Delay Response) A message from the master to a
specific slave in response to the DELAY_REQ,
containing the time of arrival of the DELAY_REQ
message at the master.

Version: 0.40
12

Figure 3-1 IEEE 1588 protocol
The messages yield four timestamps (t
1
, t
2
, t
3
and t
4
) as shown in Figure 3-1. From
these it is possible to calculate the round trip time for messages from the master to
the slave, and back to the master (assuming that the slave clock is advancing at a
similar rate to the master). The time offset is then estimated using the assumption
that the one-way delay is half the round trip delay, and used to correct the slave
timebase to align to the master. Note that if the forward and reverse paths are of
different lengths, then this will introduce an error into the time offset estimate. There
is no information within the PTP protocol itself that allows the offset to be corrected for
this asymmetry, although the slave may be able to make use of other information
available to infer the size of the offset.
Round trip delay = (t
2
t
1
) + (t
4
t
3
)
Oneway delay estimate = round trip delay
2
= (t
2
t
1
) + (t
4
t
3
)
2
Slave time offset estimate = t
2
(t
1
+ one-way delay)
Slave Clock Time
Data at Slave
Clock
Follow_Up message
containing true value of t1
Delay_Resp message
containing value of t
4
Sync message
Delay_Req message
time
t1, t2, t3, t4
t1, t2
t2
t1, t2, t3
t2
t3
t1
t4
Master Clock Time

Version: 0.40
13
= (t
2
t
1
) (t
4
t
3
)
2
Although PTP is intended for use to distribute a time reference around a network, it
may also be used to distribute frequency (i.e. syntonization of a slave node to a
master reference clock). It achieves this by observation of how fast the master clock
is advancing (as seen in the timestamps of the SYNC or DELAY_RESP messages), and
adjusting the slave clock frequency to match this rate.
3.1.2 PTP performance
There are several sources of noise in a PTP system that can lead to time and/or
frequency errors in the output. These include:
Jitter and wander in the reference clock source
Timestamp errors at the grandmaster
Packet delay variation in the network
Timestamp errors at the slave
Local oscillator noise at the slave
Asymmetrical delays (different downstream to upstream delay)
The accuracy of the recovered time and/or frequency depends on the ability to filter
out these disparate sources of noise. PTP grandmasters are normally locked to a
primary reference source, such as GNSS engine, providing an extremely accurate time
source to begin with. Timestamp errors are minimised by using hardware
timestamping at the MAC layer of the network interface. This eliminates the additional
delay that would be introduced by the software stack in a wholly software-based
system. Local oscillator noise can be reduced by using precision, stable oscillators
such as temperature-compensated crystal oscillators (TCXOs) or oven-compensated
crystal oscillators (OCXOs).
The main issue affecting the accuracy and stability of slave clocks when using packet
timing protocols is the packet delay variation (PDV) in the network. The variation in
delay from packet to packet through the network induces noise in the slaves
perception of the time at the master. Constant delay would cause a fixed offset.
However, variable delay causes a varying estimate of the offset. The performance of
the slave is affected by both the magnitude of this variation, and how effective the
slaves filter is at removing this noise. Intelligent filtering algorithms for removing
packet delay variation can deliver time accuracies in the sub-microsecond range over
a suitable network.
ITU-T Recommendation G.8260 [16] describes several metrics for characterising the
amount of PDV in a network, in terms relevant for a PTP clock recovering a stable
frequency from the network. Bi-directional metrics are currently being discussed to
quantify the ability to produce an accurate time or phase reference.
3.1.3 On-path support
While PTP can be run end-to-end, the IEEE1588-2008 standard defines three means of
reducing the PDV-induced error through the provision of on-path support. These are
either strategically-placed devices along the path from grandmaster to client, or
intelligent switches or routers that can measure the transmission delay of timing
packets along the path.
Boundary clocks
Boundary clocks recover the clock from the PTP flow, and re-generate the

Version: 0.40
14
flow, essentially acting as masters to all the clients on the network below the
boundary clock. Boundary clocks were introduced in PTP version 1 to allow
the flows to traverse routers onto different network domains, but without
impairing the quality of the clock.
End-to-end transparent clocks
End-to-end transparent clocks forward all messages in the PTP flow
transparently, exactly like a conventional switch device. However, they also
calculate a residence time, which is the length of time the packet takes to
traverse the switch. This residence time is added to a correction field as the
packet leaves the switch.
When the packet arrives at the client, this correction field contains the sum of
all the residence times through each transparent clock. This allows the client
to compute the delay through the network, removing much of the uncertainty
caused by packet delay variation.
Peer-to-peer transparent clocks
Peer-to-peer transparent clocks also calculate the delay along each network
link, in addition to the residence time measured through the device. They
achieve this by exchanging peer delay messages (Pdelay_req and
Pdelay_resp) with the corresponding peer-to-peer transparent clock at the
other end of the link. This link delay is added into the correction field with
the residence time, such that by the time the message reaches the client
device, the correction field contains the full path delay for the message.
3.1.4 ITU profiles for frequency, time and phase
IEEE1588-2008 [14] introduces the concept of a PTP profile. The idea is to specify
particular combinations of options and attribute values to support a given application,
e.g. the synchronization of audio/video equipment in a broadcast studio environment.
The purpose of the profile is described in IEEE1588-2008, clause 19.3.1.1:
The purpose of a PTP profile is to allow organisations to specify specific selections
of attribute values and optional features of PTP that, when using the same
transport protocol, inter-work and achieve a performance that meets the
requirements of a particular application.
A PTP profile is a set of required options, prohibited options, and the ranges and
defaults of configurable attributes. Profiles specifications shall be consistent with
the specifications in 19.2.1 and 19.2.2.
ITU-T Recommendation G.8265.1 [17] defines a profile, colloquially known as the
telecom profile, aimed at distribution of accurate frequency over packet networks.
This is primarily intended for use with synchronization of cellular base stations, where
the main requirement is to operate the radio interface at a frequency accuracy of
within 50 parts per billion.
The ITU-T is also working on two profiles for accurate time distribution in draft
Recommendations G.8275.1 and G.8275.2. The first profile requires the use of
boundary clocks at every node in the network between the grandmaster and the slave.
This significantly reduces the accumulation of noise along the path, although at the
expense of requiring the entire network to be replaced. The second profile requires
more limited support, allowing it to be used over existing networks without on-path
support. The second profile boundary clocks requires boundary clocks only in some
strategic locations along the path.

Version: 0.40
15
3.2 Network time protocol (NTP)
The term NTP confusingly refers to both a protocol (currently at version 4, as defined
in RFC 5905 [18] and its related RFCs) and to a software implementation that uses the
protocol to provide time synchronization between computer hosts. The RFC includes
both the on-the-wire protocol and the definition of the processing in the client of the
received timestamp information (the servo or filter algorithm in IEEE1588-speak).
Both the protocol and the software originate from an R&D project that started in the
early days of the networked hosts with the aim of synchronising the time clocks of
nodes connected to a general wide-area network.
The home page of the project is www.ntp.org.
3.2.1 The NTP protocol
The NTP protocol is typically used as a client-server protocol (although it is common
for a client to also act as a server for other clients, and it may be used in both
broadcast and symmetric modes too).
NTP is based on a classical clock hierarchy: a stratum 0 clock is a device (e.g. GNSS)
which provides a clock source to a stratum 1 server to which it is connected and which
runs an NTP-compliant server. Each client NTP server is then a stratum level higher
than the server it synchronises. In this way it is also possible for a set of NTP peers to
be defined and for them to automatically sort out which are to be clients to which
servers, based on the stratum information carried in the protocol.
The protocol in client-server mode is based on a single request/response message
pair, initiated by the client. The messages are carried over UDP on the IANA-assigned
port 123. The client and server note and exchange in the relevant messages:
1. The client timestamps when the request is sent
2. The server timestamps when the request is received
3. The server timestamps when the response is sent
4. The client timestamps when the response is received
The response includes all four timestamps and the client uses the timestamps to
estimate current time error from the server. The estimate is accurate if the delay
paths are symmetrical. The timestamps may be applied in software or in NTP-aware
Ethernet adapter hardware to increase accuracy (although in a WAN environment the
local software timestamping errors in a client or a server tend to be small compared to
the jitter introduced by the network hops through the WAN). The messages also
contain a reference timestamp of when the system clock was last adjusted.
The protocol timestamps are conformant to the earlier NTP version 3 specification
(RFC 1305, [19]). The latter uses a 32 bit field to represent the number of seconds
since January 1, 1900. This representation will wrap around on Tuesday 19 January
2038, but it is planned to reuse the MSB zero for time after the wrap point. A second
32 bit field is used to represent fractions of a second, giving a resolution of about 232
picoseconds. NTP version 4 also introduces a 128 bit date and timestamp format with
greater range and flexibility in extension fields in the messages.
The protocol messages include:
A header with protocol version, mode of operation, stratum (of server)

Version: 0.40
16
A leap second indicator, warning of impending leap second insertion/removal
A precision field which describes the underlying clock precision as a signed
power of two seconds (e.g. the value -20 is used for a clock derived from a
1MHz crystal)
A root delay field indicating the estimated total round-trip delay from the
primary reference source (16 bit seconds and 16 bit fractions of a second)
A root dispersion field, which provides an estimate of the unsigned maximum
error due to clock frequency tolerance (16 bit seconds and 16 bit fractions of
a second)
A reference identifier field, which identifies the type of the root primary
reference (e.g. GNSS) or the IPv4 address (or IPv6 hash of the address) of
the server with which this server synchronises.
The protocol also includes an optional authentication of the packets using a 128 bit
message digest based on pre-shared keys between client and server(s), together with
a 32 bit key identifier to allow servers to work with multiple keys.
The protocol allows for server discovery using broadcast and multicast packets.
3.2.2 The NTP algorithm
The NTP algorithm is based on filtering a set of measurements taken from a set of
possible servers. Unlike PTP, a filter algorithm is defined in the RFC and is based on
the needs of accurate time synchronization of clocks of varying precision and accuracy
over a general WAN. There are many magic numbers and heuristic limits applied at
stages of the algorithm that are the result of a lot of experience in real-world
scenarios by the algorithm designers. SNTP frees the designer to implement an
alternative algorithm optimized for particular backhaul characteristics whilst
maintaining general compatibility with NTP servers. Examples of performance of such
algorithms are provided in the previous Small Cell Forum whitepaper, Femtocell
synchronization and location [1], and in presentations made at synchronization-
related conferences (e.g. Packet synchronization in IP radio access networks,
reference [20]).
The client performs a poll of all configured servers with a poll period varying from 2
4

seconds (16s) to 2
17
seconds (~36h), with the poll period being derived by the
algorithm, and extending as the local clock and server clock both become accurate
enough that clock drift is estimated to be small over the poll period.
A key concept in the algorithm is that of the dispersion, defined as a maximum error
due to both frequency tolerance and time since the last update.
Time samples from each server are filtered initially by ordering the last eight samples
in increasing round trip delay (on the premise that the smaller the round trip delay the
smaller the likely jitter, and thus overall error), and the estimated dispersion
measurements from each server are derived by weighting the dispersions of this
ordered list, and a time and frequency offset calculation is performed. The results are
then combined with and compared to results from other servers, and a single current
peer is selected as the primary source, with the estimate of actual accuracy being
dependant on how close this peer is to the combined result.
A local clock is then updated in either PLL or FLL mode, but for high accuracy local
clocks the PLL mode is always used. The actual adjustment is based on the overall
filtered and combined errors measured to all monitored servers, but is heavily
influenced by the selected peer accuracy.

Version: 0.40
17
In order to speed convergence, the initial time accuracy is improved by using a set of
measurements at start-up, and starting with a small initial poll period.
3.2.3 Performance
Although NTP is designed for time synchronization, it has been designed to achieve
this by accurately aligning clock frequencies too. The use of highly non-linear
heuristic-based filters to derive the estimates of frequency and time errors copes with
a wide variety of underlying network conditions and performance, and can do this with
very infrequent message exchanges. Generally speaking when both the server and
the client each have highly stable clocks, and the client clock is pulled to within
100ppb of the server clock, the poll period has been extended by the algorithm to
several hours, and typically up to the maximum allowed, and as the client clock
stability decreases, so does the poll period. NTP copes well with WANs that have a
small number of points of congestion (which introduce significant independent jitter),
but degrades as the number of congestion points increase (but this is mainly an
inherent timing synchronization issue for all such network-based synchronization
methods).
With very minor adjustments to both the filter algorithm and to the manner in which
the PLL adjustment is applied to a VCXO (as opposed to a software clock model that
the NTP software uses), NTP is capable of disciplining an oscillator to an accuracy
significantly better that its inherent accuracy, and doing so with relatively low packet
rates (and thus also server load). The main weaknesses of NTP are its start-up
performance (for an uncalibrated crystal it can take many hours to achieve 100ppb),
and the way its performance degrades as the client crystal inherent accuracy degrades
(it essentially provides a roughly constant improvement in performance for a given
network condition).
3.3 Synchronous Ethernet (SyncE)
Synchronous Ethernet (SyncE for short) builds on the existing Ethernet standards and
is backward compatible with them. The basic difference between native Ethernet and
SyncE is the transmit PHY transmit clock. In SyncE the transmit clock is synchronised
to a traceable Stratum-1 clock, instead of a free-running crystal oscillator, providing a
timing signal with a long-term frequency accuracy of better than one part in 10
11
.
Synchronous Ethernet is standardized in a series of ITU-T recommendations:
G.8261 Introduction and basic concepts [21]
G.8262 Ethernet equipment clock definition [22]
G.8264 Synchronization status messaging (SSM) and functional modelling
[23]
3.3.1 Physical layer clocking
Both NTP and PTP use packets (or frames) to transmit time information through the
network. Any variation in the time taken for those packets to reach the client nodes
creates an error in the time as perceived by the client device. Therefore the client
requires smart filtering algorithms to reduce the effect of this noise to a minimum.
Synchronous Ethernet (or SyncE) avoids this error by transmitting the clock over the
physical layer. Full-duplex Ethernet transmits a continuous clock through the network
medium (e.g. copper or fibre). Typically this clock is driven from a free-running
crystal oscillator, which may have a frequency error of up to 100ppm. However, if it
is driven from a known frequency reference (e.g. a timing signal traceable to a PRC),

Version: 0.40
18
it can be used to transmit an accurate frequency from one node to the next. This can
be used to create a synchronization chain, distributing a traceable frequency reference
throughout the network.

Figure 3-2 Physical layer clock distribution
It should be noted that SyncE can be operated over any medium, provided that
medium transmits a continuous clock (e.g. fibre, copper, microwave, etc.). Where the
medium is half duplex, or the clock is squelched between packets (e.g. energy-
efficient Ethernet, IEEE802.3az), then the clock frequency is not preserved and the
SyncE chain is broken.
3.3.2 Compatibility with SONET/SDH
This use of the physical layer clock is comparable to SONET/SDH, where the physical
layer clock is also used to distribute a traceable frequency reference through the
network. The properties of the SyncE clock in each node (known as the Ethernet
equipment clock, or EEC) have been specified to be precisely the same as the
SONET/SDH Equipment Clock (SEC). This means the design rules for a
synchronization chain involving SyncE are the same as those for SONET/SDH, and
makes it possible to create a hybrid network with some SyncE and some SONET/SDH
segments. Each SONET/SDH link in the synchronization chain may be directly
replaced by a SyncE link.
3.3.3 Management
Synchronous Ethernet uses the same 4-bit message synchronization status message
(SSM) codes as SONET/SDH, allowing message compatibility in hybrid networks. This
allows the traceability of the clock to be determined and for information on the status
of the clock at each stage in the chain to be passed on down the chain. These
messages are sent in specially defined OAM frames utilising the Ethernet slow
protocol, defined in G.8264 [23]. The messages use a type length value (TLV)
structure to allow new message extensions to be defined in the future.
The same SSM codes are also used in the PTP-based frequency synchronization
mechanism described in G.8265.1 [17], allowing mixed chains of SONET/SDH, SyncE
and PTP to be created while maintaining full traceability back to the PRC.
3.3.4 Pros and cons
Pros:
Traceable to a primary reference clock, with nominal fractional frequency
accuracy of 1 x 10
-11

Unaffected by PDV, and factors such as congestion or traffic load
Compatible with traditional synchronization systems such as SONET/SDH

Rx Tx
<100ppm
oscillator
Rx Tx
EEC
Ethernet Equipment
Clock (EEC)
Native Ethernet PHY
Clocking
Frequency
reference

Version: 0.40
19
Compatible with PTP synchronization based on the G.8265.1 profile [17]
Cons:
Frequency distribution only, not time and phase
Requires every node in the chain to be SyncE-capable
3.4 GNSS for telecom timing
GNSS systems such as GPS have been deployed to provide accurate location and time
reference anywhere on earth. They are designed to work in all weather conditions to
provide position and time provided there is an unobstructed view of four or more
GNSS satellites. In practice, even under obstructed conditions, attenuated and
reflected signals can be used by modern receivers, albeit with reduced accuracy,
although assisted GNSS (AGNSS) techniques are typically needed. Moreover, when
position is known, (either supplied as assistance or obtained as a fix) specialised
timing receivers can provide or maintain time to an accuracy commensurate with the
position uncertainty using a single GNSS signal.
The first GNSS system, GPS, began development in 1973 and became fully operational
in 1994. It now consists of 24 satellites with up to seven additional spare satellites in
orbit that can be placed into operation as required. All GPS satellites broadcast a
CDMA spread-spectrum signal (in the 1.5GHz and 1.2GHz frequency bands) with low
bit-rate message data that is used by the GPS receivers to calculate location and
absolute time.
GPS time is theoretically accurate to about 14 nanoseconds. However, taking into
account receiver accuracy, propagation of the GPS RF signals, and other factors, most
receivers provide about 100 nanoseconds timing accuracy.
Historically the use of GPS for determining location and time reference has been
limited to outdoor deployments or indoor deployments where a remote GPS receiver
or GPS antenna can be installed on the roof or on the side of the building. Also while
to date most consumer and commercially available GPS receivers require direct sky
visibility to the GPS satellites, over the past few years several GPS receiver vendors
now offer commercially available high sensitivity receivers that are capable of
receiving and using non-direct no-sky visibility multi-path bounce GPS signals. These
high sensitivity GPS receivers can allow a GPS time reference of 500 nanoseconds or
better to be recovered even in urban canyons where there may be little or no direct
sky visibility. Some vendors are providing assisted GPS solutions that use network
connectivity to provide additional information about the orbit and speed of the
satellites. Such information enables the receivers to detect the signal at lower power
levels, allowing them to provide some level of service in the outer portions of buildings
where there is some window or skylight visibility to the outdoors (though not deep
inside the building).
Other global navigation satellite systems in use or various states of development
include:
Glonass Russian global navigation satellite system, which is fully
operational worldwide. It consists of three orbital planes spaced 120 degrees
apart from each other with eight satellites in each plane for a total of 24
satellites.
Galileo a GNSS being developed by the European Union and other partner
countries. As of 2012, 4 satellites are in operation and the constellation of 27

Version: 0.40
20
operational + three spare satellites is planned to be fully deployed by 2019 or
2020.
Beidou navigation satellite system (BDS) China's GNSS system,
currently provides region service within 55
o
S~55
o
N, 55
o
E~180
o
E, covering
most of the Asia-Pacific region and plans to provide full global passive service
by 2020. BDS is designed to consist of five geostationary earth orbit (GEO)
satellites, 27 Medium Earth Orbit (MEO) satellites, and three inclined
geosynchronous satellite orbit (IGSO) satellites. BDS construction was
initiated in 2004 and provides regional passive services by the end of 2012.
BDS currently has 14 in-orbit satellites, and the constellation consist of five
GEO satellites, five IGSO satellites, and four MEO satellites. Since December
2012, BDS provides free-of-charge location, velocity and timing with
horizontal positioning accuracy of ten metres, vertical positioning accuracy of
ten metres, velocity accuracy of 0.2 metres/second and timing accuracy of 20
nanoseconds.
IRNSS India's regional navigation system launched its first navigational
satellite on 1 July 2013. IRNSS is intended to cover India and the Northern
Indian Ocean.
QZSS quasi-zenith satellite system - Japans regional system covering
East Asia and Oceania. Currently about four satellites are in operation with a
goal of having a seven-satellite constellation in the future.
The capability and accuracy of these other GNSS systems is beyond the scope of this
white paper. However, some GPS receiver vendors are now beginning to offer dual
mode or multi-mode GNSS solutions that are capable of receiving multiple GNSSs
concurrently (e.g. GPS/GLONASS or GPS/Galileo) and provide an even more robust
time solution due to the fact that there is an increased likelihood of being able to see
even more satellites in any particular challenging environment. Also being able to
receive and use multiple GNSSs concurrently provides a higher degree of fault
tolerance in the very unlikely event that one particular GNSS is temporarily
unavailable or impaired.
GNSS technology is ideal as a primary synchronization source for both phase and
frequency owing to its absolute accuracy, global geographic availability and non-
reliance on the backhaul link. However, as with other wireless technologies, GNSS
receivers are susceptible to both unintentional and illegal sources of interference and
jamming. While usually transient in nature, a robust synchronization subsystem
should take into account the potential holdover requirements imposed by signal loss
through jamming and interference for example by appropriately specified reference
oscillators or, ideally, reliable backhaul-based phase or frequency control.
Vendor solutions are beginning to emerge that support the simultaneous reception of
multiple GNSS satellite signals (e.g. simultaneous use of GPS + GLONASS) to further
enhance the robustness and accuracy of the recovered sync signals. However, for
obstructed environments such as deep inside a building, a hybrid solution involving,
for example, SyncE for extended holdover or a backup synchronization source such as
PTP or CNL will provide a more robust solution.
Pros:
Better than 100ns accuracy (direct sky visibility to satellite)
Global coverage for GPS, GLONASS, Galileo and BDS
Does not rely on specially engineered transport network (as 1588v2 or SyncE
does)
Low cost (though cost could be impacted if remote GNSS or remote GNSS
antenna is required)

Version: 0.40
21
Proven reliability (GPS is primary sync source for 3GPP2 CDMA 1X/DO BTSs
since 1990s)
Cons:
Requires line of site visibility to satellites (though new receivers are emerging
that do not)
May be problematic in urban canyons and in-building applications. However,
some hybrid solutions are starting to emerge that do not require direct sky
visibility, or have better in-building reception. Solutions such as this have
been deployed for several years now, for example for in-building installation
of CDMA femtocells since ~2009 timeframe.
Some locations may have too weak, or no satellite visibility (e.g. subways,
underground shopping malls, pedestrian tunnels). However, remote GNSS
receivers or remote GNSS antennas may solve this problem in certain
situations. Where the use of remote GNSS equipment is not practical, other,
non-GNSS methods should be used.
May be susceptible to high frequency interference or jamming. However,
solutions are emerging that mitigate and can ride through and hold over
during such temporary interruptions or degradation.
3.5 Cellular network listen
Cellular network listen (CNL) uses the downlink transmission of surrounding cellular
base stations to provide synchronization sources for the small cell. It has also been
called network monitor mode and cell sniffing. The cells being listened to may be of
any suitable cellular technology, but are typically other LTE, WCDMA, CDMA or GSM
cells, as such cells are commonly available.
The technique involves implementing essentially a small subset of UE functionality in
the small cell, which may be used to detect adjacent cells, determine their relative
timebase frequency error (and, if of a compatible technology, their relative system
frame sequence phase or timing error). These adjacent cells may be intra-frequency,
inter-frequency (including inter-band), or inter-RAT.
The basic premise behind the use of CNL is that some cells have an accurate
frequency source, and indeed some adjacent cells are of a higher power class than the
small cell, and so have a more strict frequency accuracy requirement. As such it is
possible for the small cell to synchronise its timebase frequency clock to the timebase
frequency of these adjacent cells and still meet its own frequency stability
requirements when there may be some (small) errors in this synchronization.
The basic scanning and synchronization technique follows that of a UE (UEs generally
have relatively poor stability oscillators over anything other than short term):
1. Determining which cells can be received (e.g. by scanning the band to
determine RSSI levels, using previous historical scan information, or from
OAM configuration)
2. Synchronising to the frame structure of the transmission using the relevant
synchronization channels (which may also be used to provide a (very) coarse
estimate of frequency error if the small cell oscillator is likely to be a long
way from its required frequency).
3. Attempting to decode the basic broadcast channel and deriving the timebase
frequency error from this decode process (e.g. by tracking the symbol phase
error across one or more data bursts).

Version: 0.40
22
The synchronization and decode of the basic broadcast information may also be used
to estimate whether the cell is a femtocell (and therefore also of lower accuracy than a
macrocell). In UTRAN, for example, this would be done by determining the primary
scrambling code (PSC), and comparing that to the range of frequencies and PSCs
known to be allocated to femtocells.
Furthermore, this downlink receiver may decode system information from these
adjacent cells, and use the information not just to assist with the synchronization, but
for other SON-related features (such as automatic neighbour relations). Examples to
which the system information may be put for the purposes of synchronization include:
Determining the cell system frame number for long-term time tracking of the
adjacent cell to improve frequency accuracy and to achieve system frame
time or phase synchronization
Determining the cell identifiers for long-term tracking of the timing of a given
cell e.g.:
For filtering measurements from a single cell
For determining the relative stability of particular cells by comparing
them to the stability of other surrounding cells
For tracking the system frame sequence drift to provide high-accuracy
long-term estimation of relative error
Estimating the cell class (e.g. for UTRAN from its announced CPICH power in
SIB5, or from the inclusion of CSG Id information in the MIB and SIB3) to
determine its frequency accuracy
Note that the use of CNL for phase sync must be implemented with care as the time of
flight from the adjacent cell may impose unacceptable errors. For example, two TD
femtocells synchronised to different macrocells via CNL may interfere. This problem
can be overcome if the locations of the femtocells are known to a sufficient degree of
accuracy and this knowledge is used to determine and compensate for the time of
flight. Alternative strategies may involve cellular network listen between the
femtocells (e.g. residential femtocells in an apartment complex or enterprise
femtocells in an office building) since their separation will generally be small. (See
sub-sections 4.1 and 4.2 in this document.)
Pros:
Cellular transmissions are commonly receivable in most of the locations small
cells are to be deployed (as the implication of cellular is that you have
neighbours)
Cellular transmissions have better building penetration than GNSS
Inter-frequency, and especially inter-band and inter-RAT receivers may be
able to continue to detect neighbours even during normal operation of the
small cell (although inter-frequency neighbours will almost certainly not be
due to the small cell transmitter.
It is possible to implement this function with reuse of existing radio parts and
processing that the small cell already requires for its normal operation, and
thus the incremental cost, space and power requirements of this can be very
small, and possibly even zero in some cases (although that may limit the
continuous operation during normal operation).
Network listen is supported by an existing standard OAM data model in TR-
196 (although not the synchronization aspects of it).

Version: 0.40
23
Cons:
The whole point of deploying the small cell maybe due to the lack of coverage
of cellular technologies (e.g. underground, very rural)
Adjacent cells may be receivable by a UE at your cell edge, but not by the
small cell itself at cell centre
Techniques must be used to avoid the possibility that groups of small cells all
using this technique will all synchronise to each other and not to any better
source, and so all drift together.
There is no link to an actual wall-clock for wide area time synchronization.
Time of flight may impose unacceptable phase errors.

Version: 0.40
24
3.6 Miniature atomic frequency references
Miniature atomic frequency references are capable of meeting the frequency
requirements of mobile base stations directly, without requiring an external frequency
reference input. Some operators have deployed Rubidium-based oscillators in base
stations for this purpose.
Atomic oscillators are based on either Rubidium or Caesium, and miniature versions
are available with comparable size, weight and power to the larger double oven quartz
oscillators (DOCXO). Typical frequency accuracies are around 0.1ppb initially, with
drift and aging of about 1ppb over a year of operation.
Pros:
Meets frequency requirements directly
No need for an external sync infrastructure to provide frequency
Cons:
Frequency distribution only, not time and phase
Cost: several times more expensive than a stable OCXO or similar technology

Version: 0.40
25
4. Hybrid technology options
Each of the techniques described in section 3 has its advantages and disadvantages,
and no one technique is capable of meeting the requirements of every small cell
deployment. Often, these techniques may be deployed in conjunction with each other,
providing a more robust and reliable solution. Some of these hybrid techniques are
described in this section. It should be noted that these are just examples, and other
hybrid combinations may be implemented.
4.1 PTP/NTP and assisted GNSS
The signal strength of GNSS signals arriving at the earth's surface is around -130dBm,
or about 30dB below the general noise floor. This may be reduced still further by
obstructions such as trees, buildings or terrain. GNSS signals use code division
multiplexing, allowing the signal to be recovered from the noise by correlating with the
correct code. Since the frequency of the signal is modulated by Doppler shift due to
the moving satellites, a GNSS receiver may have to search through a matrix of
frequencies and phase offsets to detect the signal.
An assisted GNSS receiver (AGNSS) receives information over the network about the
satellite orbits and velocities. The receiver then knows which satellites are overhead,
and enables it to predict the Doppler-shifted frequency, reducing the search space,
and hence to locate the signal quicker. This process is aided still further if the receiver
also has a good estimate of frequency and current time, which can be provided
through PTP or NTP. These estimates reduce the time needed to detect the signal,
allowing the receiver to correlate for longer periods of time, and hence increasing the
effective signal-to-noise ratio. This allows the receiver to work in places where the
signal may be partially obstructed.
Since the power of a GNSS signal is so low, it is also vulnerable to interference from
adjacent signals, or from deliberate jamming. This may mean that the GNSS receiver
is temporarily unable to recover the signal, creating short outages. The second
advantage of having time assistance from PTP or NTP is that the time may be
maintained using PTP or NTP during these periods. This increases the reliability of the
overall system.
An alternative but related strategy especially for LAN-backhauled enterprise femtocells
is for the femtocells on the same LAN to synchronise each other. This scheme is
described in detail commencing on Page 30 of Ref 19. The basic concept is that
femtocells with access to GNSS signals act as PTP masters and those without GNSS
signals act as PTP slaves.
Pros:
Reduces time to acquire the GNSS signal
Can be used to increase the sensitivity of the GNSS receiver
Increases the reliability of the system by providing an alternative time
transfer mechanism, protecting against GNSS outages and interference
Allows both the access vendor and the mobile operator to monitor
performance while the GNSS is active
Cons:
Two infrastructures need to be maintained
Increases the complexity of the timing receiver

Version: 0.40
26
4.2 Cellular network listen and assisted GNSS
Cellular network listen (CNL) can be employed in exactly the same way as NTP or PTP
to assist a GNSS receiver to acquire signals more quickly and to maintain phase or
frequency during GNSS holdover periods resulting from obstruction, interference or
deliberate jamming.
Furthermore a similar strategy to that described in Section 4.1 for LAN-backhauled
femtocells on the same LAN to synchronise each other can be adopted but without
the requirement for the femtocells to be LAN-backhauled or to be on the same LAN.
This scheme is described in a little more detail commencing on page 45 of Ref 19. The
basic concept is that femtocells without access to GNSS signals synchronise via CNL to
those with GNSS signals.
Pros:
Increases the reliability of the system by providing an alternative time
transfer mechanism, protecting against GNSS outages and interference
Cons:
4.3 Use of SyncE to allow enhanced GNSS holdover
As noted above, a good estimate of current frequency assists a GNSS receiver by
reducing the spread of frequencies that it must search through in order to detect the
GNSS signal. SyncE provides a good, stable estimate of that frequency, and enables
the correlator to both reduce the search space, and to integrate the signal for a longer
period of time, increasing sensitivity.
Secondly, during GNSS outages (of the sort caused, for example, by interference or
jamming), that stable frequency may be used to maintain the timebase of the
receiver. A traceable SyncE signal has a long-term frequency accuracy of about one
part in 10
11
, derived from the primary reference clock it is locked to. Therefore, if the
GNSS input is disconnected, the SyncE signal will limit the drift of the timebase away
from correct time to around 1s per day.
Pros:
Increases the reliability of the system by providing a stable frequency to
maintain the timebase, protecting against GNSS outages and interference
Cons:

Version: 0.40
27
4.4 PTP and SyncE
PTP and SyncE may be used co-operatively to deliver frequency, time and phase to
the eNodeB, taking advantage of the physical layer to transport traceable frequency-
based information. For example, the draft recommendation G.8271.1 describes a
reference model for an architecture where SyncE is used to synchronise each PTP
boundary clock in a chain of boundary clocks from the PTP Grandmaster to the
eNodeB. This architecture is shown in Figure 4-1.

Figure 4-1 Reference model architecture from G.8271.1
This architecture ensures that both the eNodeB itself, and each of the chain of
boundary clocks distributing the time reference through the network have a stable,
accurate frequency reference. The stability of the frequency reference reduces the
dynamic time error accumulated in the chain of boundary clocks, allowing PTP to
deliver a time reference accurate to a few hundred nanoseconds. Secondly, if the
chain was broken for some reason, and no connection was available to a PTP
Grandmaster, the stable frequency reference can be used to maintain accurate time at
the eNodeB for a period until the time reference is restored. This is known as time
synchronization holdover. A further advantage is the faster restoration of traceable
time after an extended interruption in the PTP distribution.
The drawback of providing two types of synchronization solutions in a network is an
increase in complexity and management. However, it could be argued that the
advantages outweigh the drawbacks.
Alternatively, other physical layer synchronization methods like SONET/SDH/ or PDH
signals common to telecommunications networks can be used to support PTP to
improve stability and provide time synchronization holdover.
End Application
(e.g. eNodeB)
PTP GM
EEC
PTP BC
EEC
PTP BC
EEC
PTP BC
EEC
PTP TSC
EEC

Time reference
Up to 21 PTP nodes
SyncE
frequency
distribution
networks
PRC
frequency
references
[PRCs may be separate or common]
SyncE SyncE SyncE SyncE SyncE
PTP PTP PTP PTP

Version: 0.40
28
Pros:
Reduces dynamic time error accumulation through the PTP chain
Increases the reliability of the system by providing a stable frequency to
maintain the timebase, protecting against PTP outages
Fast restoration of time following extended PTP interruption
Cons:

Version: 0.40
29
5. Synchronization capabilities of backhaul technologies
This section discusses the capability of the different types of small cell backhaul to
support the various synchronization mechanisms.
In many instances, it is not possible to carry synchronization signals natively across
the backhaul network. For example, SyncE is carried at the physical layer of an
Ethernet signal. This is often imitated in backhaul technologies by providing a SyncE
input at the head-end equipment. The frequency is carried at the physical layer of the
backhaul technology (e.g. microwave carrier frequency, xDSL NTR signal), and a new
SyncE signal generated at the remote end. A similar technique may be used with PTP
for frequency.
For phase and time, some backhaul technologies have built in phase or time
synchronization capabilities (e.g. VDSL ToD-TC signal, GPON ToD signal, DOCSIS over
EPON v2.0), and this may be used in a similar manner to regenerate the PTP at the
remote end. Not all these technologies are fully standardized, and are therefore
vendor-specific features that may be implemented in a given piece of equipment.
They rely on standard behaviour, but provide an extra level of capability around the
basic functions.
All the technologies listed in this section may also be used to transport an Ethernet
service. MEF has defined Ethernet services applicable to mobile backhaul in MEF 22.1.
This service is an MEF EVC demarcated by MEF UNIs that is realized with a variety of
technologies (including those in this section). MEF services allow the specification of
service level agreements so that a service provider may offer standard Ethernet
services to mobile operators for RAN backhaul. SLAs for these MEF services would
include performance objectives per class of service, to support the varied
requirements represented by LTE QCIs.
MEF 22.1 Mobile backhaul implementation agreement, Phase 2 identifies the
requirements for MEF defined Ethernet services and MEF defined external interfaces
(EIs such as UNIs) for use in mobile backhaul networks based on MEF specifications.
This includes frequency synchronization with either SyncE or packet based methods
like PTP. The services and requirements on the metro Ethernet network (MEN) are
based on the services defined in MEF 6.1 as well as the attributes defined in MEF 10.2,
in MEF 10.2.1 and MEF 22.1.
5.1 Millimetre wave: 60, 70-80 GHz
Millimetre wave systems, operating at the 60 and 70-80 GHz bands can be used to
provide line-of-sight connectivity for wireless backhaul of both macrocells and small
cells. The point-to-point connections can be built up to provide chains or rings for
resilient connectivity.
Two main techniques may be used to carry synchronization over millimetre wave
backhaul. These may be used in concert to improve the reliability of the
synchronization:
1. Physical layer frequency synchronization, by locking the carrier frequency of
the radio to a reference frequency. This may be used to provide SyncE
service, for example.
2. Packet-based synchronization such as PTP or NTP. Hardware based
timestamping should be supported in case of time and phase requirements.

Version: 0.40
30
SyncE service should meet the ITU requirements at the SyncE interfaces, and include
support for the ESMC channel carrying standard SSM QL values. For ring structures to
be used, the SyncE solution must be capable of changing the direction of distribution.
PTP packets should have the appropriate QoS levels to provide high priority service
with a minimum of packet delay variation. This may be provided through the VLAN
priority bits, DSCP bits for IP traffic, or the EXP bits for MPLS. The vendor may
recommend specific QoS treatment.
Similarly, appropriate security should be provided, potentially including encryption of
the radio link. Any encryption/decryption should not create variation in delay, since
that would affect packet-based synchronization schemes.
Adaptive modulation may introduce dynamic asymmetrical delays. (when modulation
drops in one direction more than at the other direction). In addition Adaptive
modulation may introduce dynamic asymmetrical delays (when the two directions are
not using the same modulation and coding).
Adaptive modulation should be hitless to h the effect on the delay of packets through
the system. Millimeter wave (MMW) links should support a compensation mechanism
like transparent clock or boundary clock to overcome the adaptive modulation
impairments.
5.2 Microwave: 6-60 GHz
Microwave links have been used for many years to backhaul both FDD and TDD
systems, demonstrating a general capability to provide both frequency and phase
synchronization. Support of specific technologies varies from product to product, but
examples of both physical layer (SyncE) and packet-based (PTP) support can be
found.
Similar considerations apply as outlined for millimetre wave technology above.
5.3 Sub-6 GHz licensed spectrum
System latency and jitter are dependent on both underlying technology and
implementation. FDD will offer much lower latency with less jitter as its full-duplex
mode of operation is inherently free of the delay more common with half duplex
technologies. However, many modern sub-6 GHz near/non-line-of-sight systems are
TDD. Single-hop TDD systems may experience two to 20ms of latency with varying
degrees of jitter; both are again dependent on implementation. Some solutions offer
tighter jitter control by leveraging deterministic media access, akin to TDMA.
One method available in TDD systems is to use a hybrid scheme based on the physical
layer aspects of the radio system. The backhaul master in both point-to-point and
point-to-multipoint systems must have an accurate source of synchronization and can
use either the PTP and SyncE hybrid method or the GNSS.
Similar to the cellular network, the wireless backhaul physical layer is capable of
transporting a precise trimming reference over the air. The receiver will always be in
frequency synchronization with the hub, and being a TDD system, a proprietary
method may be used to transport phase synchronization and ToD at the wireless
frame level. The synchronization phase is compensated at the receiver for the air trip
delay using the physical layers time offset adjustment. The precision of this
adjustment is well below 1s.

Version: 0.40
31
Being synchronized using the physical layer as described, the receiver site can
regenerate PTP (and/or SyncE) traffic and pass it to the base station with high
accuracy, and immune to wireless link variations. Having the PTP (and/or SyncE)
timestamp generator placed next to the base station eliminates uncertainties related
to the packet delay variation and uplink/downlink asymmetry.
5.4 Satellite
A TDMA satellite system uses a shared outbound carrier and time division access to
the inbound carrier(s). Therefore the jitter characteristics are typically much more
challenging than on a terrestrial link. Typical values to be expected on the outbound
link would be 5ms of jitter with a maximum of 25ms. Similarly on the inbound
carriers the jitter may average 10ms with a maximum of 50ms.
For delay there are two components. One of these is the fixed speed of light delay in
the signal travelling from the ground to the satellite and back to the ground. For
geostationary satellites typical values here are 240 260ms depending on the exact
geographic locations of remote site, hub site and satellite. In addition there are the
packetization and processing delays which add 35ms 50ms, leading to typical one-
way trip times of 275 310ms.
The most common forms of synchronization used today for small cell connections over
satellite are either to use NTP (or a proprietary flavour of NTP) from the core network
over the satellite link and thus delivered to the small cell. This can deliver adequate
frequency stability for 2G and 3G small cells. The disadvantage is the on-going
continuous consumption of satellite bandwidth to deliver the NTP traffic. For this
reason it is not uncommon to use a GNSS-derived timing source either integrated
or external to the small cell to deliver timing. While this has a higher capital cost the
on-going cost is zero apart from maintenance.
For future systems, including LTE, the industry is moving towards PTP support.
Running PTP over satellite links is challenging because the jitter is typically greater
than the 5ms maximum required to achieve frequency stability. In addition, as for
NTP, there is also a cost issue in operating PTP over the air. New solutions are coming
to market that support PTP master clocks incorporated in the satellite remote,
synchronised from the downstream satellite carrier frequency. This allows the use of
PTP with good frequency accuracy and stability (<15 ppb), and without the overhead
of sending PTP packets over the air.
Current systems do not meet the tight phase synchronization requirements; however,
since satellite backhaul is often deployed for rural access where there is no
overlapping macrocell coverage, only frequency synchronization is generally needed.
5.5 FTTX (e.g. EPON, GPON)
PON systems are based on a shared fibre medium. The downstream transmissions
from the optical line terminal (OLT, the head-end) are common, but the upstream
transmissions from each optical network unit (ONU) are time-division multiplexed.
Each ONU is scheduled to specific timeslots, to avoid them all transmitting at once.
This creates an inbuilt asymmetry in packet delays that can cause problems for packet
timing algorithms if uncorrected.
However, the delay to each ONU is known precisely due to an inbuilt ranging
mechanism. This ranging delay must be measured to allow the ONU to transmit in the
correct timeslot. An amendment to the original GPON standards, (G.984.3

Version: 0.40
32
Amendment 2), describes a time-of-day distribution mechanism for GPON systems
that makes use of the ranging delay. Provided the OLT has an accurate time
reference initially, G.984.3 specifies that the time accuracy at the ONU should be
1s, although in practice it is estimated to be much better than this. This knowledge
of time could be used to re-generate the PTP packets, or to directly drive a time-of-
day interface such as a 1 pps (1 pulse-per-second) interface with an associated time
information channel. However, such use is outside the scope of the GPON standards,
and may not be implemented by every GPON terminal vendor.
Next generation GPON systems (NGPON) specify the use of boundary clocks in both
the OLT and the ONU. This will enable the system to participate in the PTP protocol
directly, while compensating for the inherent asymmetry of the system.
5.6 Fiber (active components)
Active fiber backhaul systems connect small cell sites with dedicated fiber. Packet-
based aggregation systems such as switches and routers are deployed further back in
the network to aggregate upstream traffic originating from user equipment and
distribute downstream information. While the transmission speed is symmetrical
1Gbps in general bandwidth allocated to each small cell can be asymmetric and
lower, depending on requirements and configuration. Multiple service classes enable
simultaneous provisioning of guaranteed bandwidth and overbooked best-effort
services.
Synchronization information for frequency and phase alignment is transported using
SyncE, PTP or a combination of both. While SyncE allows for accurate frequency
recovery independent of the actual network load, PTP frames need to be forwarded
with highest priority to minimize jitter and delay. Separating user traffic from PTP
flows and assigning strict forwarding priority to PTP flows minimizes statistical effects.
Handling multiple classes of service (CoS) is therefore a key requirement for all
aggregation and network termination devices to allow for network efficiency and
synchronization accuracy at the same time.
The timing signal is recovered either by a by a standalone/embedded slave or
boundary clock device or an standalone/embedded edge master located next to the
small cell base station or directly by the base station itself. In the first case, standard
timing interfaces are used to hand-over the timing signal to the small cell base
station.
Active fiber backhaul is a prevalent cost-effective, high capacity solution to provide
packet-based backhaul services. Mobile operators are turning to optical backhaul
strategies for simplified high-capacity infrastructure that brings significant operational
value.
5.7 Digital subscriber line (XDSL)
XDSL systems (including ADSL, SHDSL and VDSL) carry an 8kHz timing signal which
may be synchronised to a traceable reference frequency, called the network timing
reference (NTR). This can be used to carry a frequency reference at the physical layer
over the DSL link. However, in many deployments (particularly for ADSL), the NTR
signal is not enabled, and therefore cannot be used for base station synchronization.
The VDSL2 standard (G.993.2) also defines a mechanism for carrying time-of-day
across the link. This may be used to provide PTP services (e.g. by terminating PTP at

Version: 0.40
33
the VTU-O (office end), and re-generating it at the VTU-R (remote end). Such support
is vendor specific.
5.8 Leased connectivity
A number of mobile network operators do not operate access networks and often do
not have access to physical fiber, copper or coax infrastructure or may not own an
access network in some geographical areas. As a consequence, fixed-network small
cell backhaul services are often leased from a 3
rd
party network operator. In most
cases, these leased services are MEF Ethernet services with the demarcation being
the MEF UNI. This is different to the situation where micro or millimeter wave
technology is utilized for backhaul, which is typically operated by the mobile network
operator itself.
With the stringent requirement for delivering accurate frequency and phase
synchronization to small cell site locations, timing distribution needs to be intrinsically
supported by the backhaul service. Such functionality becomes most critical when PTP
on-path support is required. Boundary clock and transparent clock functionality needs
to be provided by the backhaul service provider at each individual aggregation and
service termination point.
When providing PTP clock functionality by a 3
rd
party, PTP performance assurance
becomes part of the SLA profile in addition to the traditional data service SLAs.

Version: 0.40
34
6. Service impact
The design of LTE in its FDD, TDD and CoMP forms, and the interference coordination
features of ICIC and eICIC have all been developed so that if the frequency, time and
frame synchronization requirements described earlier are all met, then the services
are delivered as specified. That is to say, if the synchronization requirements are met,
then the impact on service conformance to specification is zero. This section is more
concerned with the effects on user services that synchronization errors may have if
they fall outside the limits set by the specifications.
In doing so, this section focuses on service impact in terms of degradation in data
throughput and voice (VoLTE) quality, in call drop and handover failure statistics. At a
high level, it discusses some protocol effects that lead to these gross service
degradations, but does not delve deeply into the protocol operation. Also, the section
assumes that the synchronization between the UE and its serving cell is good. The
only reason the UE might fall out of synch with its serving cell is that the serving cell is
too weak to detect the synchronization channel, in which case it is too weak to offer
service. The synchronization errors this section is concerned with are those between
two neighbour eNodeBs interacting either cell-edge to cell-edge, or in an underlay-
overlay geometry.
6.1 LTE-FDD
6.1.1 Frequency misalignment
Looking at the time/frequency grid that characterises the LTE downlink, there are two
key attributes:
Sub-carrier spacing
= 15kHz
Sub-frame duration
= 1ms

Figure 6-1 Subset of the time/frequency downlink map
At the maximum frequency offset for the Home eNodeB (250ppb at a 2.6GHz carrier
frequency) the centre frequency error is about 650Hz a bit less than 5%.

Version: 0.40
35
Of course, the sub-carrier to sub-carrier interference in general is only apparent when
there is power scheduled in both sub-carriers, so that a UE receives power on a sub-
carrier that is intended for a different UE. In a full-buffer scenario, that is likely to be
the case.
In a situation where sub-carrier allocations are provisioned centrally (like traditional
cell-planning for TDMA networks) or where ICIC is active, then the errors in frequency
alignment translate more or less linearly into downlink SINR degradations. With
perfect frequency alignment between adjacent eNodeBs, two UEs will see their serving
cell transmissions on perfectly non-overlapping sub-carriers.
Referring to Figure 6-2, if the sub-carrier overlap is zero, and ICIC (or central
planning) is effective, the UE being served from Cell A will see signal power in sub-
carrier A.1, and no interference from sub-carrier B.1, since Cell B will not schedule
power to this sub-carrier.
The 3GPP specifications allow for frequency alignment errors. Movement of the UE
creates Doppler shifts, resulting in apparent offsets in frequency between
neighbouring cells. For example, the serving cell may be upshifted as the UE moves
towards it, and the neighbour cell simultaneously downshifted in frequency.
Stationary users may see in-specification frequency errors in the master clock of a
small cell of up to 250ppb.
If the frequency error is increased above this limit, the SINR impact increases more or
less linearly in the full-buffer case, as each sub-carrier encroaches on its neighbour in
proportion to the frequency error, whether that arises from Doppler effects or from
intrinsic frequency error in the small cell. Referring again to Figure 6-2, with the
frequency misalignment between the cells and non-zero sub-carrier overlap, the UE
being served by cell A will suffer interference from sub-carrier B.2, even if B.1 is quiet.
B.1 B.2
Sub-carrier overlap
A.1 A.2
Cell A (serving)
Cell B (interfering)

Figure 6-2 Sub-carrier overlap with frequency difference between cells
The effect of such SINR degradation on service can be calculated as a worst case from
the test specification 3GPP 36.141, where the SINR is related to BLER, which is, in
turn, related to minimum UE throughput.

Version: 0.40
36
However, in practice, the most important service-affecting attribute here is even
simpler. If the frequency error in the base station is greater than specification, then
the UE is not guaranteed to be able to synchronise to the cell. All other discussions on
the effects of frequency error are moot, if the UE cannot actually gain any service
from the network at all.
6.1.2 Time misalignment
Potentially of greater significance to service is the effect of time misalignment between
cells. At the beginning of every sub-frame, one OFDMA symbol (approx. 70s,
including its cyclic prefix) is dedicated to the LTE PCFICH (primary control format
indicator channel). This channel tells the receiver the format of the rest of the sub-
frame. If it is received in error, then the whole of the sub-frame will be received in
error.
To overcome this, the PFICH is very heavily protected by coding, with less than 2 bits
of information spread across 16 sub-carriers, each of which is carrying one QPSK
symbol.
For HetNet deployment where one cell may be 10km and its underlay cells may be
anywhere within it, with a range of 100m or so, even with heavy coding, it is possible
for a macro transmission to overwhelm an underlay small cell to the point where the
PCFICH bits cannot be decoded, and the small cell cannot be used without other
measures.
To overcome this, the eICIC feature was introduced at R10, to allow cells to switch off
transmissions in repeating patterns (exchanged between neighbours over x2),
reducing the chance of PFICH clashes in HetNet deployments.
However, if the time alignment of the cells is out, then the eICIC pattern signalling will
also be out by a similar value. It is important therefore, in order to maintain any
service at all at the cell edges between small cells and macrocells, that the frame
alignment of the two layers is maintained within a few microseconds. Since the time
slot length is 0.5ms, then to be below 1% interference the timing accuracy should be
better than 5us.
6.2 LTE-TDD
In TDD, in addition to the PCFICH timing issue described above, the key timing issue
is in the timing of the transition between transmit and receive. If one cell begins
transmitting when its neighbour is still receiving, or similarly, if a UE begins
transmitting to one cell when a nearby UE is receiving from its neighbour, then user
data will be lost and signalling delayed because of HARQ and potentially higher layer
retries.
The system is designed to accommodate differences between cells caused by time of
flight, by use of a special sub-frame with shorter-than-normal transmission periods.
The beginning of the special sub-frame is guaranteed to accommodate transmit to the
whole of the cell. The end of the special sub-frame is guaranteed to accommodate
receive from UEs in the whole of the cell. The middle of the sub-frame (the guard
period) is essentially quiet, to allow the base station and the UE to switch from
transmit to receive (and vice versa) for all values of time-of-flight, without overlapping
each other.

Version: 0.40
37

Figure 6-3 Special sub-frame
The guard period is configurable from one to ten OFDM symbols (~70s to ~700s).
One service affecting misconfiguration here is to set the guard period too small for the
cell range. For small cells with a range of 2km or less, a guard period of one symbol is
almost certainly sufficient. But for larger cells, keeping the guard period short (to
maximise usable time in the special sub-frame) results in degradations to the system
throughput because of simultaneous transmit mechanism outlined above.
It is possible to view frame synchronization errors in TDD in a similar way, with similar
effects to under-provisioning the guard period between transmit and receive.
The reality is, however, that unless the frame synchronization is grossly out, the effect
on TDD throughput is low. For instance, if the guard period were set to one instead of
ten, and all nine OFDMA symbols were lost because of adjacent cell or adjacent UE
transmissions, only nine out of 2048 symbols are lost in two sub-frames out of ten
an effective BER of 0.1% or less, which will translate into an infinitesimal BLER
difference.
If you go beyond these values in terms of frame misalignment, then it is possible to
create bigger effects. However, the message is consistent: if you keep within the
specs, your system will work as advertised. The key point is make sure you know that
the synchronization properties of the larger system are as you expect them, and to
ensure the system provides the counters and alarms to make it manageable to those
limits.
6.3 Holdover
When all synchronization references are lost or declared unusable, the synchronization
mechanism enters into a holdover state where the system generates clocks from the
last known good reference, with the last good frequency and phase information
available. The holdover state maintains the frequency stability and phase accuracy
requirements within the specified limits for a period of time.
CDMA2000 defines that the base station should maintain a transmit-timing accuracy
to within 10s of CDMA system time for a period of eight hours following loss of the

Version: 0.40
38
synchronization reference. For other technologies, the length of time during which the
frequency and phase accuracy must be maintained during holdover is not defined in
standards, but depends on the service provider's operational requirements.
Note that different holdover requirements may apply in different nodes of the network.
For example, macro base stations usually provide frequency holdover through their
high quality oscillator. For small cells, this may no longer be the case due to cost
reasons.
In the case of time synchronization, long holdover periods would generally require the
use of support from a secondary stable frequency reference, e.g. SyncE.
This section discusses the relationship between the oscillator performance and the
operational requirements.
6.3.1 Impact of the oscillator
Cost-effective and high performance oscillators are required for small cells. Base-
station clocks are generated by performing disciplining corrections to oscillators using
servo algorithms. The synchronised clocks can either be synthesised from a constant
reference oscillator clock or a controllable oscillator (like VCXO) that is directly
incorporated in the timing generation loop.
In start-up or the acquiring mode of the synchroniser, the oscillator needs to achieve
a certain frequency accuracy state within a defined period of time. Along with the
servo bandwidth implementation, the linearity of the oscillator implementation and
oscillators initial frequency accuracy performance are important in this regard.
In locked mode, where the disciplining of the oscillator takes place, the impact of the
performance of the algorithms dominates output clock performance of the
synchronization system. However, the algorithms themselves assume stable clock
references, which in turn are derived from the oscillators. Therefore frequency drift of
the oscillator across temperature variations becomes the important factor in locked
mode.
In holdover mode the servo algorithms handle the initial phase error and the initial
frequency offset. However, the overall stability of the system heavily depends on the
oscillator. The performance of the oscillator over temperature variations and the
aging of the oscillator play a major part in determining the frequency stability and
phase error accuracy of the system clock during holdover.
It is important to understand the temperature variations - the range of temperature
variations as well as the rate of ramp of the temperature - to select the right
oscillator. The temperature profiles for testing the performances of the system are
defined (for example in ITU-T SG15) in ways that specify the constrained temperature
excursion and ramp rate. Commercial implementations are available with frequency
stabilities within 10s of ppbs when temperature variations of -45 to +85
o
C are applied
with a rolling temperature window of 20
o
C at a temperature ramp rate of 0.5
o
C/min.
6.3.2 Holdover components
When the input to the control system is abruptly or deliberately removed, the
traditional PLL implementation will skew the output frequency to the free running
frequency of the local oscillator. The holdover mechanism generates a virtual

Version: 0.40
39
reference to the system that continuously drives the loop essentially trying to
generate the clocks that used to be present before the system had lost its reference.
Ideally, a holdover mechanism aims for a perfect transition from a situation of
reference signal to one without any input reference signal. However, in an
implementation scenario there are many deviations from the ideal. Thus the holdover
requirements of standards specify the limits of such deviations at different levels of
synchronization quality.
For example, the phase error, T, at the output of an Ethernet Equipment Clock
(EEC), relative to the input at the moment of loss of reference should not, over any
period of S > 15 s, exceed the following limit:
T(S) = {(a
1
+ a
2
) S + 0.5 b S
2
+ c} [ns] G.8262, clause 11.2 [11]
Lets look at each of these components in detail.
The constant and one time error c is the phase error the system may incur on the
transition and entering into the holdover phase. Depending on the implementation,
there could be a delay in detecting the failure of the clock and engaging the holdover
mechanism leading to a phase error, or simply engaging the holdover mechanism
itself could generate an error. It is a phase movement at the output of the clock and
in general there is no phase slope that is defined to this error. An instant, infinite
slope movement at the output within the given limit is still a valid transition (though
there could, in practice, be a limited slope in the actual implementation).
The first-degree error a
1
allows for any error in estimating the value of the holdover
frequency. This depends on the implementation of the synchroniser mechanism. For
G.8262, a budget of 50ppb is allowed for a
1
.
The remaining error components, a
2
and b are largely contributed by the local
oscillator of the system. The factor a
2
accounts for the frequency offset caused by
temperature variations after the clock has gone into holdover. Crystals typically
produce a response based on a third order polynomial in the output frequency
depending on the temperature variations. In general an oven-controlled oscillator
selects its oven temperature based on a turnover point to select maxima or minima
(df(T)/dT = 0) of the frequency variation with respect to the temperature. The
crystals define overall temperature variation effects on frequency over a defined
temperature range such as -20 to 60 or -40 to +85 and so on. If we go further to
determine the rate of change of frequency with time, the temperature drift rate also
becomes a part of it. The crystals are defined with a variation of frequency in ppb/
o
C
variation. The application can determine the maximum rate of temperature variation
that can happen, which can be identified as, say, 10
o
C/min or 1
o
C/min.
Combining the above factors, the frequency variation over a period of time can be
observed. In applications where the temperature variation is not a consideration, then
the factor a
2
should not have an impact on the phase error defined. Some standards
bodies are working on modelling temperature variations to closely associate the ramp
rate and amount of variation at one stretch. Some of the recommended values are a
ramp rate of 1
o
C/min for a maximum of 20
o
C with some recommended steady
intervals where temperature changes do not occur.
The term b refers to the aging effects of the crystal. Aging is usually referred as the
systematic change in frequency with time due to internal changes in the oscillator
when factors external to the oscillator (environment, power supply, etc.) are kept
constant. The main reason for the aging seems to be the absorption and removal of

Version: 0.40
40
mass from the resonator layers. Aging is defined as frequency variation with time;
therefore, for a phase variation it becomes a second-degree error with respect to time.
Some of the standards also define a drift, which is another kind of systematic change
in frequency with time of an oscillator. In general, drift is considered to be the result
of all internal and external factors, including a combination of factors such as the
aging plus changes in the environment and other factors external to the oscillator.
Many standards specifications have already moved away from defining drift or are in
the process of doing so.
6.3.3 Service impact
Service providers and system integrators have varying views on the holdover
requirements and performance limits of small cells. Depending on the type (home,
enterprise, urban or rural) of small cell, the requirements may also vary. For
example, in a small cell for the home, where the primary objective is offload and
capacity, service outages for a specific period of time may not impact the user
because there could be a macro base station the user equipment can switch to. But
where the coverage is the primary objective and there is no fall-back macro base
station, the small cell may warrant holdover to specific time periods, depending on the
service levels provided by the service provider. The technological complexity versus
cost targets may also be a major factor in the selection of holdover requirements.
The frequency accuracy requirements of LTE systems can be maintained confidently
with disciplining algorithms and properly designed oscillators. Once the servo
accuracy is determined and the operating ambient temperature variation of the
system is studied (e.g. indoor installation with restricted temperature operation
variation versus outdoor ambient temperature operation) the stability of the oscillator
over the temperature range and the aging parameters can be considered for the
selection of the oscillator.
For illustration, if the turnaround time on a service call is assumed to be one day, for a
service that requires 250ppb of accuracy while operating at 0 to 80
o
C, assuming that
servo accuracy is 50ppb, an oscillator with stability performance at 100ppb at 0 to
80
o
C and an aging performance of 20ppb give sufficient margin for operation.
The phase accuracy requirements of the LTE air interface are much more challenging
to meet for long-term holdover requirements. The temperature change, the rate of
change of temperature, or the nature of the ambient variation can determine the
frequency variation and in turn the phase variation. The following table gives an
approximation on the oscillator performance on service impact, with an indication of
the relative costs. The performance numbers below are given as a general indication
and the performance of a specific oscillator may be different. The performance
numbers were derived from frequency measurements on oscillators and the
corresponding phase simulations. The initial accuracies of the timing systems are not
included.

Version: 0.40
41
Oscillator
type
Oscillator
parameters
Time to reach phase error limit
(20
o
C temp. variation at 10
o
C/hour)
Constant
temp,
calm air
Relative
cost
indicator
Freq. v temp
daily aging
1s 3s 7s 24 hours
OCXO
0.1ppb
0.05ppb/day
12 Hours 48 hours 144 Hours <1s $10x
OCXO
0.5ppb
0.1ppb/day
3 Hours 12 Hours 36 Hours 3s $4x
OCXO
(Traditional
St 3E)
5ppb
1ppb/day
30 min 2 Hours 4 Hours 50s $2.5 x
OCXO
(New
Technology
St 3E)
5ppb
1ppb/day
30 min 2 Hours 4 Hours 50s $1.5 x
OCXO
(Restricted
Temp Range
St 3E)
5ppb
1ppb/day
30 min 2 Hours 4 Hours 50s $1x
Low Power
OCXO
10ppb
2ppb/day
20 Min 35 Min 55 Min 100s $0.5x
TCXO
100ppb
40ppb/day
5 Min 10 Min 15 Min 1000s $0.25x
Table 6-1 Oscillator phase stability
System integrators are considering the direct output of the synchronization block
driving the radio blocks, thus avoiding additional jitter filter components. Thus for the
oscillators, a key consideration is low phase noise to drive the radio blocks directly.

Version: 0.40
42
7. Synchronization deployment use cases
There are several deployment use cases that are possible to deploy synchronization.
It should be noted that while synchronization as a service is a new concept that is not
well defined, MEF 22.1 has included frequency synchronization as part of its definition
of Ethernet services for mobile backhaul. All of these use cases can leverage the
service definition indicated in MEF 22.1 for frequency synchronization and in a future
revision for time/phase synchronization
7.1 Synchronization services implemented by mobile operators
Some mobile operators may have to rely on a fairly large number of backhaul
providers to reach out-of-franchise small cell locations. This situation makes it
impractical to get from all these backhaul providers a uniform synchronization
services. In other cases, the mobile operators may decide that Internet services using
DSL or GPON access networks are the most economical viable mechanisms to connect
the pico base stations.
The public Internet is one of the most challenging infrastructures to deploy
synchronization services that meet the frequency and phase requirements of small
cells. The asymmetrical nature of most of DSL services, the lack of QoS guarantees
and the unpredictability of the number of hops between the PTP grand master and the
slaves introduce time error and noise that is almost impossible to correct. Even some
Ethernet lease line services may present an amount of asymmetries that can be hardly
corrected in practice when the asymmetries are related to the physical infrastructure
(e.g., different fibre lengths).
In those scenarios, a PTP Grand Master deployed by the Mobile operator very close to
the small cell site infrastructures or on a nearby macrocell site to serve a limited
number of pico base stations (less than twenty) may constitute a reasonable solution.

Figure 7-1 Synchronization service implemented at the mobile operators access network
7.2 Synchronization services offered by backhaul providers
Some mobile operators have a large backhaul and access infrastructure between the
radio access network network controller (RAN NC) and a multi-picocell site. These
operators can choose to not deploy a packet synchronization on-path support.
Alternatively, they can decide to lease a full or partial on-path packet synchronization
service from the backhaul provider. Note that this PTP service might be optionally
complemented with a synchronous Ethernet service. The backhaul provider may also

Version: 0.40
43
offer the synchronization service as an additional commercial service to other mobile
operators.

Figure 7-2 Synchronization service implemented by the backhaul provider
7.3 Synchronization services implemented by mobile operators and
backed-up by backhaul providers
Even when a mobile operator deploy a PTP Grand Master close the small cell locations,
it may decide to use a synchronization service offered or transported by the backhaul
operator as a back-up synchronization service. A PTP grand master is typically
equipped with a GNSS receiver and it has been recognized for times now that the
GNSS signal can be easily jammed intentionally or unintentionally.
When it reaches the earth the GNSS signal is approximately 1x10
16
Watts. With such
a low signal, small and inexpensive jammers can cause a GPS receiver to lose lock at
long ranges. Some tests indicated that a 1 Watt jammer can put out of operation a
commercial GNSS receiver at a distance of 22 km [24].
In some cases, the GNSS antenna is placed in a location where it experiences
intermittent loss of signal. The mobile operator (Figure 7-3) may decide to lease a
back-up service offered by the backhaul operator or it can deploy itself this service
from its nearest central office or RNC site for holdover purposes (Figure 7-4).
For the case of GNSS at the end location this is an ideal opportunity to use a known
reference traceable to UTC to validate the back-up service or the capability of the on-
path access network. Active performance will provide assurances that the PTP path
meets SLA requirements in the event of a GNSS outage.

Version: 0.40
44

and a backup service implemented by the backhaul provider

and a backup service implemented by the mobile operator

Version: 0.40
45
8. Synchronization maintenance and service assurance
Since frequency, phase and time requirements are stringent (as outlined in sections
1.1 and 1.2), it is essential to have the ability to test, verify and analyse
synchronization in the network in case service quality issues occur as described in
Section 6.
In addition, a way to monitor the synchronization performance delivered by the
service provider is beneficial. Such a monitoring function can be deployed in chosen
locations (i.e. in centralized location). The monitoring function can use a GNSS
reference to monitor the quality of synchronization delivered by the network.
In G.8271.1, the ITU-T has defined deployment cases for the measurement of network
limits of a network with full timing support and a boundary clock (T-BC) as the last
equipment of the chain. Three alternative options are defined, depending on whether
the timing signal is generated by the last equipment of the chain or from
tapping/exchanging the PTP frame flow after the reference point. With the passive
technique in option B, a packet-based test device monitors packet exchanges over the
communication link. In this way, the monitoring device acts as an observer and it does
not directly participate in the packet timing protocol.
In option C the monitoring device acts as an active T-TSC and exchanged packet with
the last T-TBC in the chain.

Figure 8-1 Deployment case 1 network limits measurement, option A

Figure 8-2 Deployment case 1 network limits measurement, option B
|TE|<1100nsec

Version: 0.40
46

Figure 8-3 Deployment case 1 network limits measurement, option C
The test points described in Figure 8-1, Figure 8-2 and Figure 8-3 above can apply to
both networks deploying frequency synchronization as well as phase synchronization.
As described in Section 6, network service impact can occur as a result of
synchronization issues. Ultimately these issues have an impact on service quality and
user experience. These are notoriously difficult to troubleshoot, as they can be
intermittent in nature.
8.1 Synchronization maintenance
To analyze synchronization issues, long-term tests must be performed. Long-term
tests are not an option at turn-up as the circuits need to go live as quickly as possible.
As such, handheld Ethernet turn-up testers are used for these tests.
If particular cells experience the service impact described in Section 6, the operator
can then deploy a 2-pronged maintenance and troubleshooting approach:
1. Use a dedicated sync analyzer to measure the network for:
Frequency stability/wander by analysing MTIE and TDEV according to
ITU-T limits
Phase accuracy/time error by measuring the 1PPS phase output
Frame delay variation by looking at raw network PDV and performing
Packet delay distribution and floor packet percentile metrics
2. If issues are seen with above tests, the measurement results from the sync
analyzer can then be sent to the network equipment vendor to replay the
measurements and reproduce the issue and work on fixes
8.2 Synchronization service assurance
Since the network limits shall be met at all times and for all operating conditions, an
on-going, in service synchronization monitoring and analysing tool can be used for
synchronization service assurance.
The synchronization monitoring function can calculate the relevant clock performance
metrics. Such a metrics can include:
Frequency stability/wander by analysing MTIE according to ITU-T limits
(I.e. G.8261.1 and G.8271.1)
Phase accuracy/time error by measuring the 1PPS phase output (option a)
or the packet timing signals embedded in PTP packets (options B and C).

Version: 0.40
47
Network performance metrics
Packet delay variation (PDV)
Floor packet percentile (FPP)
PTP event massages packet loss
Network asymmetry
What is not shown in traditional monitoring functions is wander. ITU-T Rec. G.810 [8]
defines wander as phase variations at a rate less than 10Hz. Metrics such as
maximum time interval error (MTIE) & time deviation (TDEV) are useful for
quantifying wander. However, MTIE & TDEV are used mostly for measuring frequency
transfer. Metrics used for time transfer and measurement techniques are currently
under study.
Wander really makes us think about the problem in a different way. As an example,
the unique response of time drift (wander), which is a type of low frequency noise, is
not instantaneous. A service provider must observe wander over time. Therefore, as
seen in figure X, it is advantageous to introduce an upper limit and a lower limit key
performance indicator (KPI). This will result in an alarm warning KPI state that
service providers can use to their advantage.

Figure 8-4 Upper/lower KPIs
The relevant metric can be calculated by testing the recovered physical signal (i.e.
1PPS/BITS) or by testing the packet timing signal (using the timestamps embedded in
the 1588v2 event massages) against the reference.
For Figure 8-1, Figure 8-2, and Figure 8-3, synchronization service assurance and
therefore clock accuracy testing is in-service to continuously generate and report
synchronization performance data. Compiling MTIE statistics and comparing the
results to desired masks allows for accurate assessment of the timing accuracy. In
addition the time error should be compared against the relevant time/phase
performance target. The timing reference signal can either come from GNSS or an
alternative signal such as Sync-E.
For increased network visibility and simplified troubleshooting, similar test points
should to be established at each individual hop. This provides full visibility of the
synchronization architecture and allows backhaul service providers to put strict SLAs
behind the timing service they provide to the MNO customers.

Version: 0.40
48
9. Conclusions and future work
All cellular radio base stations require synchronization, including small cells. This may
be frequency synchronization, phase alignment to other base stations, or in the case
of CDMA and CDMA2000, time synchronization.
This paper has introduced the synchronization requirements for LTE small cells, and
their application to different small cell deployment types. It has also covered different
synchronization techniques, and their relationship with various types of backhaul
technologies.
Future versions of the document will include more analysis of potential backhaul
solutions and network issues, particularly in respect of the enterprise, metro and rural
deployments that are the focus of the Small Cell Forum's upcoming release categories.

Version: 0.40
49
References

1 Network Time Protocol (Version 3): Specification, Implementation and Analysis,
IETF RFC1305, March 1992
2 GSM/EDGE Radio Access Network: Radio subsystem synchronization, 3GPP TS
45.010
3 Recommended Minimum Performance Standards for cdma2000 Spread Spectrum
Base Stations, 3GPP2 C.S0010
4 Radio Access Network: Base Station (BS) radio transmission and reception
(FDD), 3GPP TS 25.104
5 Radio Access Network: Base Station (BS) radio transmission and reception
(TDD), 3GPP TS 25.105
6 Radio Access Network: Requirements for support of radio resource management
(TDD), 3GPP TS 25.123
7 Radio Access Network: Synchronization in UTRAN Stage 2, 3GPP TS 25.402
8 Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio
Access Network (RAN), 3GPP TS 25.346
9 Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio
transmission and reception, 3GPP TS 36.104
10 Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of
radio resource management, 3GPP TS 36.133
11 Timing characteristics of packet-based equipment clocks, ITU-T Recommendation
G.8263
12 Recommended Minimum Performance Standards for cdma2000 Spread Spectrum
Base Stations, 3GPP2 C.S0010
13 Network Time Protocol (Version 4): Protocol and Algorithms Specification, IETF
RFC5905, June 2010
14 Network Limits for Time Synchronization in Packet Networks, ITU-T
G.8271.1/Y.1366.1, (Consent, July 2013)
15 IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems, IEEE Standard 1588TM-2008, 24 July 2008
16 Definitions and terminology for synchronization in packet networks, ITU-T
Recommendation G.8260, February 2012
17 Precision time protocol telecom profile for frequency synchronization, ITU-T
Recommendation G.8265.1, October 2010
18 Network Limits for Time Synchronization in Packet Networks, ITU-T
G.8271.1/Y.1366.1, (Consent, July 2013)
19 Mobile Backhaul Implementation Agreement, MEF-22.1
20 Femtocell Synchronization and Location, Small Cell Forum 037.01.01, May 2012
21 Timing and synchronization aspects in packet Networks, ITU-T Recommendation
G.8261, April 2008
22 Timing characteristics of a synchronous Ethernet equipment slave clock, ITU-T
Recommendation G.8262, July 2010
23 Distribution of timing information through packet networks, ITU-T
Recommendation G.8264, October 2008
24 [Jamming Danger Raises Doubts About GPS, Aviation Week & Space Technology,
October 19,1992, p. 61.]

075 Synchronization For LTE Small Cells

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

075 Synchronization For LTE Small Cells

Uploaded by

Copyright:

Available Formats

www.scf.io/ www.smallcellforum.

You might also like