075 Synchronization for LTE Small Cells

8/11/2019 075 Synchronization for LTE Small Cells

1/56

www.scf.io/ www.smallcellforum.org

DOCUMENT

Synchronisation for LTE small cells

December 2013

075.04.01

Produced in partnership with theMetro Ethernet Forum (MEF)

scf.io/

SMALL CELL FORUM

RELEASE Four


2/56

If you would like more information about Small Cell Forum or wouldlike to be included on our mailing list, please contact:

[email protected]

PostSmall Cell Forum, PO Box 23, GL11 5WA UK

Member [email protected]

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-profit, international organisation. Its membership is open

to any legally established corporation, individual firm, 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 refinement

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: Urbancan 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, fitness

for any particular purpose, or any warranty otherwise arising out of any proposal, specification, 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 inhardcopy form or made available in electronic form by Small Cell Forum Ltd anywhere in the world.


3/56

Report title: Synchronization for LTE Small CellsIssue 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 coveredmany 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 3Gtechnologies, there are additional requirements on synchronization, including thewider need for very tight time synchronization.

This paper describes these new requirements and the technologies available to fulfilthose 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 whitepaper focuses on the distributed baseband architecture.
http://scf.io/doc/036http://scf.io/doc/036http://scf.io/doc/036http://scf.io/doc/036


4/56


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 caseof CDMA and CDMA2000, time synchronization. In earlier 3GPP releasessynchronization was delivered using TDM network or GNSS. Today, with the all IPasynchronous networks and indoor small cells deployments operators need to rethinktheir synchronization delivery strategy.

Section 1of this paper introduces the relevant requirements for the various types of

radio technology, including LTE and LTE-Advanced, referencing the appropriate 3GPPtechnical specifications. Broadly speaking, FDD systems require only frequencysynchronization of 50 250ppb (parts per billion), but TDD systems have anadditional requirement for phase alignment of less than 3s, relative to other cellswith overlapping coverage.

For some LTE-Advanced features (e.g. eICIC, CoMP and MBSFN), no synchronizationrequirements have been specified, but that does not mean no requirements exist.Rather, there is a soft limit based on vendor implementation and operatordeployment 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 onthe cell location as it does on the technology used. For example, a small cell usingTDD technology, but located in a remote area with no overlapping macrocell coveragewill 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 2of the paper describes several different types of small cell deployment, andidentifies which LTE and LTE-Advanced features each are likely to use. It summarisesthe level and type of synchronization required for each type of small cell deployment.

Sections 3 and 4introduce the different techniques that may be used to synchronisesmall cells, and list the advantages and disadvantages of each. These sections do notcover 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 5discusses the synchronization capabilities of different backhaul

technologies, and examines how they affect the choices for small cell synchronization.

Section 6covers the impact on the service caused by degraded or lostsynchronization. In other words, what are the consequences of having poor


5/56


Version: 075.04.01

synchronization? In the case of FDD systems, if base station frequency is more than250ppb out it could mean that any user equipment is simply unable to use that basestation, 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 indata throughput will begin to accumulate, along with a potential to interfere with

reception of the PCFICH (primary control format indicator channel), and consequentloss of an entire sub-frame of data.

Section 7describes some of the deployment use cases for synchronization delivery byeither the mobile operator or the backhaul provider. Finally, section 8 discussesnetwork maintenance and troubleshooting in the event that the service issues

described in Section 6 are experienced. It also describes solutions for synchronizationmonitoring and assurance.


6/56


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 ........................................................................... 93. 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 ........................................................................... 315.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


7/56


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 .................................. 438. 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 ...................................................................................... 2Table 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 ....................................................... 18Figure 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 accessnetwork ........................................................................................ 42

Figure 7-2 Synchronization service implemented by the backhaul provider ........... 43

Figure 7-3 Synchronization service implemented at the mobile operators accessnetwork and a backup service implemented by the backhaul provider .. 44

Figure 7-4 Synchronization service implemented at the mobile operators accessnetwork 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

AcknowledgementsWe would particularly like to thank the following members that provided significant contributionsto 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


8/56

Report title: Synchronization for LTE Small CellsIssue 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 uplinktransmission take places in separated frequency bands. Frequency synchronization

was needed for second and third generation air interfaces, and continues to play acritical role in LTE FDD systems. The LTE downlink air interface relies on theorthogonal frequency division multiple access (OFDMA) transmission technique in thedownlink. Single carrier-frequency division multiple access (SC-FDMA) has been

selected for the uplink direction. OFDMA presents tremendous benefits in terms ofhigh spectral efficiency, minimal implementation complexity, support of advancedfeatures 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 theeNodeB and the user equipment (UE) because the sample timing errors can destroythe orthogonality between the subcarriers. The orthogonality between the subcarriers

prevents overlapping of the subcarriers spectra, which would result in interferencebetween subcarriers. Any mismatch between the eNodeB and the UE oscillatorsand/or Doppler shift due to the mobility of the UE generates frequency offsetsbetween the UE and eNodeB and a misalignment between the reference frequencies ofthe 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 frequencyparameters of the eNodeB in order to be able to demodulate the downlink signal andalso 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 fromthose defined by the standard. The frequency stability tolerance of the UE oscillator istypically maintained at 0.1 ppm to minimise cost. Its stability is maintained bytracking the eNodeB carrier frequency.

In time-division duplex (TDD) systems, downlink and uplink transmission occur in thesame channel but in different time slots. Phase synchronization is therefore requiredin LTE TDD to avoid interference between the uplink and the downlink transmissionson neighbouring eNodeBs.

The general synchronization requirements for both frequency and phase and time are

listed inTable 1-1 below. Note that these are the requirements of the radio

technology, and not the budget allocated to the synchronization system, which will becorrespondingly lower. While the focus of this white paper is on the requirements forLTE small cells, the requirements are broadly similar to those of predecessortechnologies, such as GSM, UMTS and CDMA. The synchronization requirements ofthose technologies are shown inTable 1-1 for reference.


9/56


10/56


11/56


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 allsynchronization references from the network are lost or declared unusable, thesynchronization mechanism enters into a holdover state where the system generates

clocks from the last known good reference, with the last good frequency and phaseinformation available. It is assumed that there is no major frequency offset beforeentering the holdover. The holdover state maintains the frequency stability and phaseaccuracy 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 thetelecom standards (e.g. G.8263, [11]) budget for a transient phase change and for aninitial holdover accuracy related to the synchronization and servo algorithms. Theyalso include other parameters such as the effect of temperature variations, aging andfrequency drift at constant temperature relating to the oscillators.

For CDMA2000, C.S0010 [12] defines that the base station should maintain thetransmit timing accuracy to within 10s of CDMA system time for a period of eighthours following loss of the synchronization reference (clause 4.2.1.1). For othertechnologies, including LTE, the length of time during which the frequency and phaseaccuracy must be maintained during holdover is not defined in standards, but dependson the service provider's operational requirements.


12/56


Version: 0.40 5

2. Small cell use cases and deployment scenarios

From the Small Cell ForumsBackhaul 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 scenarioexamples are described in the following sections.

2.1 Targeted capacity hotspot

A hotspot is deployed to add capacity to networks and fill spectrum gap, easecongestion 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 underlayin congested outdoor urban deployments. Thisprovides offload to specific macrocells, but requires new backhaul access tostreet furniture i.e., street lamps, traffic lights, CCTV sites, payphones ornotice boards. A typical area would be any concentrated traffic with peakhours such as Times Square in New York or Oxford Street in London. Othercandidate locations would be urban access highways at rush hour or localcommuting at airports/train stations where a high-turn-over of customers isexpected.

Wi-fi complement complements the existing public Wi-Fi access points,i.e. those deployed in hotspots with nomadic (non-mobile) characteristicssuch 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 celldeployment, instead of residential. The synchronization requirements are thereforedifferent. 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 100ppb standard and an urban small cell, emulating the macro cell, may have an evenmore stringent requirement of 50 ppb.

Dense urban underlays are provided to enhance capacity, and therefore may utilisefull 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 and5s have been suggested by some vendors.

PTP, GNSS and cellular network listening are possible synchronization techniques forthis class of use cases.
http://scf.io/doc/049http://scf.io/doc/049http://scf.io/doc/049http://scf.io/doc/049


13/56


Version: 0.40 6

Targetedcapacityuse case

Co-ordinationrequirements(e.g. eICIC,

CoMP)

Backhaultype

View of sky(GNSS

availability)

Macrocellvisibility

Sync requirements

Frequency Time/phase

Dense urbanunderlay

Yes maxcapacityrequired

NLOS/LOSmicrowave,

wired(e.g. DSL,

GPON)

Restricted(may beurban

canyon)

Yes 100ppb

3s phase for

TDD

1-5s phasefor co-

ordination

10s time forCDMA

fallback

Wi-Ficomplement

No Wi-Fi/LANRestricted(may beindoor)

Yes 100ppb

3s phase forTDD

10s time forCDMA

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 steadydaily nomadic (non-mobile) traffic and occasional peaks. Indoor deployments mayinclude 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 mediumoffices, casinos/hotels or college campuses. While this could also be a

candidate for a distributed antenna system (DAS) system, the cost may beexcessive to run new fibre. Generally, Ethernet cabling exists throughout thebuilding and would be ideal for deployment of either small cell or enterprise

femtocell. As these venues are generally made of glass and metal, externalpenetration from macrocells is problematic to impossible.

Dense suburban residences,such as large multi-family apartmentcomplexes provide particular challenges because of the closely packed natureof the small cells. This may require interference co-ordination and thereforetime/phase synchronization.

Distributed suburban facilities,such as individual houses, shops or officeshave lower interference challenges because the small cells will be morewidely spaced.

Mobile small cells, covering indoor coverage in moving publictransportation systems such as buses, trains and planes. This is somewhat

similar to a relay node in that the penetration loss from the exterior of thevehicle can be prevented. Also, by adopting the appropriate backhaulmethod, the high-speed mobile users can be supported with seamlesshandover. 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 acertain distance apart (along the high-speed train track) and a mobile remoteunit 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.


14/56


15/56


Version: 0.40 8

Indoorcoverageuse case


CoMP)

Backhaultype

View of sky(GNSS

availability)

Macrocellvisibility

Sync requirements


Denseurbanindoorvenue

Yes maxcapacityrequired

LANNo indoors

Yes singleexternal point

No indoorsYes single

externalpoint

100ppb

3s phase for

TDD

1-5s phasefor co-

ordination

Small office

Yes ICIC oreICIC

(in dense officeblocks)

LANRestricted(may beindoor)

Possible(may berestrictedindoors)

250ppb

3s phase forTDD

1-5s phasefor co-

ordination

Densesuburban

residences

Yes ICIC oreICIC

Wired(DSL,GPON)

Restricted(may beindoor)

No(no need forsmall cell if

visible)

250ppb

3s phase forTDD

1-5s phasefor co-

ordination

Distributedsuburban

residencesNo

Wired(DSL,GPON)

Restricted(may beindoor)

No(no need forsmall cell if

visible)

250ppb3s phase for

TDD (ifoverlapping)

Mobile(train,plane)

NoNLOS/LOSwireless,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 withexisting macrocell coverage or in isolation of the macrocells (in disaster recoverysupport, say). Examples of outdoor use cases are:

Exclusive/restricted development such as a country club (golfcommunity) 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 orsmall businesses). Small cells may be used to cover local not-spots causedby terrain or building shadows. The suburban neighbourhood is an example

supporting dynamic upgrade of residential areas with recurring high eveningpeak traffic on mobile devices. Deployment is challenging with minimallocations available due to zoning variance and neighbourhood resistance.Such situations may require stealth sites in limited locations such as church

2As 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 theservice 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
http://www.itu.int/dms_pub/itu-d/opb/ind/D-IND-WTDR-2010-PDF-E.pdfhttp://www.itu.int/dms_pub/itu-d/opb/ind/D-IND-WTDR-2010-PDF-E.pdfhttp://www.itu.int/dms_pub/itu-d/opb/ind/D-IND-WTDR-2010-PDF-E.pdf


16/56


Version: 0.40 9

steeples, flag poles, and tree poles. Backhaul placement could also be viaaerial cables, street light fixtures, etc.

Disaster recovery support (utilising MW or any available, deployable

broadband backhaul) providing rapid mobilisation of mobile services to adisaster HQ or staging area while awaiting possible traditional cell-on-wheels

(COW) deployment, if necessary. Most immediate initial needs are forcommand-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.

Outdoorcoverage use

case


CoMP)

Backhaultype

View of sky(GNSS

availability)

Macrocellvisibility

Sync requirements


Exclusivedevelopment

No Wired Yes No 100ppb3s phase for

TDD

Rural

notspotNo

Microwave,

wiredYes No 100ppb

Distributedsuburban

NoMicrowave,

wiredYes Patchy 100ppb

3s phase forTDD

10s time forCDMA fallback

Disasterrecovery

NoMicrowave,

wiredYes 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 toservice availability and not primarily designed for targeted capacity. The use case canbe thought of as a range extension for macrocells where peripheral coverage areas atcell 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 andexclusive/restricted propertiesexhibit the quality of experience (QoE)enhancement examples that allow better customer perceived experience on serviceavailability. 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 typesand their characteristics were given. This section identified different backhaul andsynchronization protocols that are required to support various small cell networks.


17/56


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 backhaulnetwork.

Table 3-1 lists some of the available techniques. These are described in more detail inthe subsequent sections. In some cases, hybrid schemes may be deployed, combiningtwo or more of the individual techniques. These may help improve reliability andaccuracy, addressing the weaknesses of the individual techniques. Hybrid schemes

are discussed in Section 4.

TechniqueFrequency

sync capablePhase sync

capableTime synccapable

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 orIP). It was originally introduced to synchronise networked computer systems by usinga master reference time source and a protocol by which slave devices can estimatetheir time offset from the master time reference. It achieves this by sending a seriesof 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 clockreference time and a protocol by which slave clocks can estimate their offset from themaster clock. The clock servo of a PTP slave uses a series of time-offset estimates toco-ordinate the local slave time with the master reference master time.

A sequence of timestamped messages is used to estimate the time offset from themaster to the slave. There are four basic messages, described below and shownpictorially inFigure 3-1.

SYNC message A message transmitted at a regular rate from themaster to all slaves. Contains a timestamp


18/56


Version: 0.40 11

identifying the time of message transmission fromthe master measured in nanoseconds from aknown point in time known as the epoch. Most

PTP systems use the time 00.00.00 1 January1970 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 timeof transmission.Some PTP clocks are capable of modifying thetimestamp in the SYNC message on-the-fly as itis transmitted, and therefore do not need totransmit the FOLLOW_UP message. Such clocksare called one-step clocks. Clocks that need to

use the FOLLOW_UP message are called two-stepclocks.In systems where a security protocol is used to

guarantee the integrity of the timing messages, itmay be necessary to use FOLLOW_UP messages,since security protocols prohibit modification ofmessages after transmission.

DELAY_REQ message (Delay Request) A message from the slave to themaster, requesting that the master inform theslave of the precise time of arrival of the messageat 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 aspecific slave in response to the DELAY_REQ,

containing the time of arrival of the DELAY_REQ

message at the master.


19/56


Version: 0.40 12

Figure 3-1 IEEE 1588 protocol

The messages yield four timestamps (t1, t2, t3and t4) as shown inFigure 3-1. Fromthese it is possible to calculate the round trip time for messages from the master tothe slave, and back to the master (assuming that the slave clock is advancing at asimilar 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 slavetimebase to align to the master. Note that if the forward and reverse paths are ofdifferent lengths, then this will introduce an error into the time offset estimate. Thereis 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 informationavailable to infer the size of the offset.

Round trip delay = (t2 t1) + (t4 t3)

Oneway delay estimate = round trip delay2

= (t2 t1) + (t4 t3)2

Slave time offset estimate = t2 (t1+ one-way delay)

Slave Clock Time

Data at Slave

Clock

Follow_Upmessage

containing true value of t1

Delay_Respmessage

containing value of t4

Syncmessage

Delay_Reqmessage

time

t1, t2, t3, t4

t1, t2

t2

t1, t2, t3

t2

t3

t1

t4

Master Clock Time


20/56


Version: 0.40 13

= (t2 t1) (t4 t3)2

Although PTP is intended for use to distribute a time reference around a network, itmay 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 clockis advancing (as seen in the timestamps of the SYNC or DELAY_RESP messages), andadjusting 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/orfrequency 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 aprimary reference source, such as GNSS engine, providing an extremely accurate timesource to begin with. Timestamp errors are minimised by using hardwaretimestamping 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-basedsystem. Local oscillator noise can be reduced by using precision, stable oscillatorssuch as temperature-compensated crystal oscillators (TCXOs) or oven-compensatedcrystal 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 indelay from packet to packet through the network induces noise in the slavesperception 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 ofthe slave is affected by both the magnitude of this variation, and how effective theslaves filter is at removing this noise. Intelligent filtering algorithms for removingpacket delay variation can deliver time accuracies in the sub-microsecond range overa 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 stablefrequency from the network. Bi-directional metrics are currently being discussed toquantify 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 ofreducing the PDV-induced error through the provision of on-path support. These are

either strategically-placed devices along the path from grandmaster to client, orintelligent switches or routers that can measure the transmission delay of timingpackets along the path.

Boundary clocksBoundary clocks recover the clock from the PTP flow, and re-generate the


21/56


Version: 0.40 14

flow, essentially acting as masters to all the clients on the network below theboundary clock. Boundary clocks were introduced in PTP version 1 to allowthe 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 flowtransparently, exactly like a conventional switch device. However, they also

calculate a residence time, which is the length of time the packet takes totraverse the switch. This residence time is added to a correction field as thepacket leaves the switch.When the packet arrives at the client, this correction field contains the sum ofall the residence times through each transparent clock. This allows the clientto compute the delay through the network, removing much of the uncertaintycaused by packet delay variation.

Peer-to-peer transparent clocksPeer-to-peer transparent clocks also calculate the delay along each networklink, in addition to the residence time measured through the device. They

achieve this by exchanging peer delay messages (Pdelay_req andPdelay_resp) with the corresponding peer-to-peer transparent clock at theother end of the link. This link delay is added into the correction field withthe residence time, such that by the time the message reaches the clientdevice, 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 specifyparticular 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 selectionsof attribute values and optional features of PTP that, when using the sametransport protocol, inter-work and achieve a performance that meets therequirements 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 withthe specifications in 19.2.1 and 19.2.2.

ITU-T Recommendation G.8265.1 [17] defines a profile, colloquially known as thetelecom profile, aimed at distribution of accurate frequency over packet networks.

This is primarily intended for use with synchronization of cellular base stations, wherethe main requirement is to operate the radio interface at a frequency accuracy ofwithin 50 parts per billion.

The ITU-T is also working on two profiles for accurate time distribution in draftRecommendations G.8275.1 and G.8275.2. The first profile requires the use ofboundary 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 theexpense of requiring the entire network to be replaced. The second profile requiresmore limited support, allowing it to be used over existing networks without on-pathsupport. The second profile boundary clocks requires boundary clocks only in somestrategic locations along the path.


22/56


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 theprotocol to provide time synchronization between computer hosts. The RFC includesboth the on-the-wire protocol and the definition of the processing in the client of thereceived 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 theearly days of the networked hosts with the aim of synchronising the time clocks ofnodes connected to a general wide-area network.

The home page of the project iswww.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 bothbroadcast 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 higherthan the server it synchronises. In this way it is also possible for a set of NTP peers tobe defined and for them to automatically sort out which are to be clients to whichservers, 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 sent2. The server timestamps when the request is received3. The server timestamps when the response is sent4. The client timestamps when the response is received

The response includes all four timestamps and the client uses the timestamps toestimate current time error from the server. The estimate is accurate if the delaypaths are symmetrical. The timestamps may be applied in software or in NTP-aware

Ethernet adapter hardware to increase accuracy (although in a WAN environment thelocal software timestamping errors in a client or a server tend to be small compared tothe 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 secondssince January 1, 1900. This representation will wrap around on Tuesday 19 January2038, but it is planned to reuse the MSB zero for time after the wrap point. A second32 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 withgreater range and flexibility in extension fields in the messages.

The protocol messages include:

A header with protocol version, mode of operation, stratum (of server)
http://www.ntp.org/http://www.ntp.org/http://www.ntp.org/http://www.ntp.org/


23/56


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 signedpower 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 ofa second)

A reference identifier field, which identifies the type of the root primaryreference (e.g. GNSS) or the IPv4 address (or IPv6 hash of the address) ofthe server with which this server synchronises.

The protocol also includes an optional authentication of the packets using a 128 bitmessage digest based on pre-shared keys between client and server(s), together witha 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 ofpossible servers. Unlike PTP, a filter algorithm is defined in the RFC and is based onthe needs of accurate time synchronization of clocks of varying precision and accuracyover a general WAN. There are many magic numbers and heuristic limits applied atstages of the algorithm that are the result of a lot of experience in real-worldscenarios by the algorithm designers. SNTP frees the designer to implement analternative 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, Femtocellsynchronization 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 24seconds (16s) to 217seconds (~36h), with the poll period being derived by thealgorithm, and extending as the local clock and server clock both become accurateenough 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 errordue to both frequency tolerance and time since the last update.

Time samples from each server are filtered initially by ordering the last eight samplesin increasing round trip delay (on the premise that the smaller the round trip delay thesmaller the likely jitter, and thus overall error), and the estimated dispersion

measurements from each server are derived by weighting the dispersions of thisordered list, and a time and frequency offset calculation is performed. The results arethen combined with and compared to results from other servers, and a single currentpeer is selected as the primary source, with the estimate of actual accuracy beingdependant 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 localclocks the PLL mode is always used. The actual adjustment is based on the overallfiltered and combined errors measured to all monitored servers, but is heavily

influenced by the selected peer accuracy.


24/56


Version: 0.40 17

In order to speed convergence, the initial time accuracy is improved by using a set ofmeasurements 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 achievethis by accurately aligning clock frequencies too. The use of highly non-linearheuristic-based filters to derive the estimates of frequency and time errors copes witha wide variety of underlying network conditions and performance, and can do this with

very infrequent message exchanges. Generally speaking when both the server andthe client each have highly stable clocks, and the client clock is pulled to within100ppb 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 clockstability decreases, so does the poll period. NTP copes well with WANs that have asmall number of points of congestion (which introduce significant independent jitter),but degrades as the number of congestion points increase (but this is mainly aninherent timing synchronization issue for all such network-based synchronization

methods).

With very minor adjustments to both the filter algorithm and to the manner in whichthe PLL adjustment is applied to a VCXO (as opposed to a software clock model thatthe 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 packetrates (and thus also server load). The main weaknesses of NTP are its start-upperformance (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 givennetwork condition).

3.3 Synchronous Ethernet (SyncE)

Synchronous Ethernet (SyncE for short) builds on the existing Ethernet standards andis backward compatible with them. The basic difference between native Ethernet andSyncE 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 atiming signal with a long-term frequency accuracy of better than one part in 1011.

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 thenetwork. 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 clientrequires 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 thephysical layer. Full-duplex Ethernet transmits a continuous clock through the networkmedium (e.g. copper or fibre). Typically this clock is driven from a free-runningcrystal 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),


25/56


Version: 0.40 18

it can be used to transmit an accurate frequency from one node to the next. This canbe used to create a synchronization chain, distributing a traceable frequency referencethroughout the network.

Figure 3-2 Physical layer clock distribution

It should be noted that SyncE can be operated over any medium, provided thatmedium 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 theSyncE chain is broken.

3.3.2 Compatibility with SONET/SDH

This use of the physical layer clock is comparable to SONET/SDH, where the physicallayer clock is also used to distribute a traceable frequency reference through thenetwork. 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 theSONET/SDH Equipment Clock (SEC). This means the design rules for asynchronization chain involving SyncE are the same as those for SONET/SDH, andmakes 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 directlyreplaced 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. Thisallows the traceability of the clock to be determined and for information on the statusof 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 slowprotocol, 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 synchronizationmechanism described in G.8265.1 [17], allowing mixed chains of SONET/SDH, SyncEand 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


26/56


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 timereference anywhere on earth. They are designed to work in all weather conditions toprovide position and time provided there is an unobstructed view of four or moreGNSS satellites. In practice, even under obstructed conditions, attenuated andreflected 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) specialisedtiming receivers can provide or maintain time to an accuracy commensurate with theposition uncertainty using a single GNSS signal.

The first GNSS system, GPS, began development in 1973 and became fully operationalin 1994. It now consists of 24 satellites with up to seven additional spare satellites inorbit that can be placed into operation as required. All GPS satellites broadcast aCDMA spread-spectrum signal (in the 1.5GHz and 1.2GHz frequency bands) with lowbit-rate message data that is used by the GPS receivers to calculate location andabsolute 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, mostreceivers provide about 100 nanoseconds timing accuracy.

Historically the use of GPS for determining location and time reference has beenlimited to outdoor deployments or indoor deployments where a remote GPS receiveror 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 skyvisibility to the GPS satellites, over the past few years several GPS receiver vendorsnow offer commercially available high sensitivity receivers that are capable of

receiving and using non-direct no-sky visibility multi-path bounce GPS signals. Thesehigh sensitivity GPS receivers can allow a GPS time reference of 500 nanoseconds orbetter to be recovered even in urban canyons where there may be little or no directsky visibility. Some vendors are providing assisted GPS solutions that use network

connectivity to provide additional information about the orbit and speed of thesatellites. Such information enables the receivers to detect the signal at lower powerlevels, 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 deepinside the building).

Other global navigation satellite systems in use or various states of developmentinclude:

Glonass Russian global navigation satellite system, which is fullyoperational worldwide. It consists of three orbital planes spaced 120 degrees

apart from each other with eight satellites in each plane for a total of 24satellites.

Galileo a GNSS being developed by the European Union and other partnercountries. As of 2012, 4 satellites are in operation and the constellation of 27


27/56


Version: 0.40 20

operational + three spare satellites is planned to be fully deployed by 2019 or2020.

Beidou navigation satellite system (BDS) China's GNSS system,

currently provides region service within 55oS~55oN, 55oE~180oE, coveringmost 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 wasinitiated in 2004 and provides regional passive services by the end of 2012.BDS currently has 14 in-orbit satellites, and the constellation consist of fiveGEO satellites, five IGSO satellites, and four MEO satellites. Since December2012, BDS provides free-of-charge location, velocity and timing withhorizontal positioning accuracy of ten metres, vertical positioning accuracy often 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 agoal 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 dualmode or multi-mode GNSS solutions that are capable of receiving multiple GNSSsconcurrently (e.g. GPS/GLONASS or GPS/Galileo) and provide an even more robusttime 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 toreceive and use multiple GNSSs concurrently provides a higher degree of fault

tolerance in the very unlikely event that one particular GNSS is temporarilyunavailable or impaired.

GNSS technology is ideal as a primary synchronization source for both phase andfrequency owing to its absolute accuracy, global geographic availability and non-reliance on the backhaul link. However, as with other wireless technologies, GNSSreceivers are susceptible to both unintentional and illegal sources of interference and

jamming. While usually transient in nature, a robust synchronization subsystemshould take into account the potential holdover requirements imposed by signal lossthrough jamming and interference for example by appropriately specified referenceoscillators 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 furtherenhance the robustness and accuracy of the recovered sync signals. However, forobstructed environments such as deep inside a building, a hybrid solution involving,for example, SyncE for extended holdover or a backup synchronization source such asPTP 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)


28/56


Version: 0.40 21

Proven reliability (GPS is primary sync source for 3GPP2 CDMA 1X/DO BTSssince 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 skyvisibility, or have better in-building reception. Solutions such as this havebeen deployed for several years now, for example for in-building installationof 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 certainsituations. 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 overduring such temporary interruptions or degradation.

3.5 Cellular network listen

Cellular network listen (CNL) uses the downlink transmission of surrounding cellularbase stations to provide synchronization sources for the small cell. It has also beencalled network monitor mode and cell sniffing. The cells being listened to may be ofany suitable cellular technology, but are typically other LTE, WCDMA, CDMA or GSMcells, 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 relativetimebase 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 accuratefrequency source, and indeed some adjacent cells are of a higher power class than thesmall 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 timebasefrequency of these adjacent cells and still meet its own frequency stabilityrequirements 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 fromOAM configuration)

2. Synchronising to the frame structure of the transmission using the relevant

synchronization channels (which may also be used to provide a (very) coarseestimate of frequency error if the small cell oscillator is likely to be a longway from its required frequency).

3. Attempting to decode the basic broadcast channel and deriving the timebasefrequency error from this decode process (e.g. by tracking the symbol phaseerror across one or more data bursts).


29/56


Version: 0.40 22

The synchronization and decode of the basic broadcast information may also be usedto estimate whether the cell is a femtocell (and therefore also of lower accuracy than amacrocell). In UTRAN, for example, this would be done by determining the primary

scrambling code (PSC), and comparing that to the range of frequencies and PSCsknown to be allocated to femtocells.

Furthermore, this downlink receiver may decode system information from theseadjacent cells, and use the information not just to assist with the synchronization, butfor other SON-related features (such as automatic neighbour relations). Examples towhich the system information may be put for the purposes of synchronization include:

Determining the cell system frame number for long-term time tracking of theadjacent cell to improve frequency accuracy and to achieve system frametime or phase synchronization

Determining the cell identifiers for long-term tracking of the timing of a givencell 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 inSIB5, or from the inclusion of CSG Id information in the MIB and SIB3) todetermine its frequency accuracy

Note that the use of CNL for phase sync must be implemented with care as the time offlight from the adjacent cell may impose unacceptable errors. For example, two TD

femtocells synchronised to different macrocells via CNL may interfere. This problemcan be overcome if the locations of the femtocells are known to a sufficient degree ofaccuracy and this knowledge is used to determine and compensate for the time of

flight. Alternative strategies may involve cellular network listen between thefemtocells (e.g. residential femtocells in an apartment complex or enterprisefemtocells in an office building) since their separation will generally be small. (Seesub-sections 4.1 and 4.2 in this document.)

Pros:

Cellular transmissions are commonly receivable in most of the locations smallcells are to be deployed (as the implication of cellular is that you haveneighbours)

Cellular transmissions have better building penetration than GNSS

Inter-frequency, and especially inter-band and inter-RAT receivers may beable to continue to detect neighbours even during normal operation of thesmall cell (although inter-frequency neighbours will almost certainly not bedue to the small cell transmitter.

It is possible to implement this function with reuse of existing radio parts andprocessing that the small cell already requires for its normal operation, andthus the incremental cost, space and power requirements of this can be very

small, and possibly even zero in some cases (although that may limit thecontinuous 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).


30/56


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 thesmall cell itself at cell centre

Techniques must be used to avoid the possibility that groups of small cells allusing 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.


31/56


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 frequencyreference input. Some operators have deployed Rubidium-based oscillators in basestations 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 quartzoscillators (DOCXO). Typical frequency accuracies are around 0.1ppb initially, withdrift 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


32/56


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 aredescribed in this section. It should be noted that these are just examples, and otherhybrid 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 byobstructions such as trees, buildings or terrain. GNSS signals use code divisionmultiplexing, allowing the signal to be recovered from the noise by correlating with thecorrect 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 offrequencies and phase offsets to detect the signal.

An assisted GNSS receiver (AGNSS) receives information over the network about thesatellite 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 receiveralso has a good estimate of frequency and current time, which can be providedthrough 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 theeffective signal-to-noise ratio. This allows the receiver to work in places where thesignal may be partially obstructed.

Since the power of a GNSS signal is so low, it is also vulnerable to interference fromadjacent signals, or from deliberate jamming. This may mean that the GNSS receiver

is temporarily unable to recover the signal, creating short outages. The secondadvantage of having time assistance from PTP or NTP is that the time may bemaintained using PTP or NTP during these periods. This increases the reliability of theoverall 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 isdescribed in detail commencing on Page 30 of Ref 19. The basic concept is thatfemtocells with access to GNSS signals act as PTP masters and those without GNSSsignals 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


33/56


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 orfrequency during GNSS holdover periods resulting from obstruction, interference ordeliberate 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 withoutthe 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. Thebasic concept is that femtocells without access to GNSS signals synchronise via CNL tothose with GNSS signals.

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 timetransfer mechanism, protecting against GNSS outages and interference

Cons: Two infrastructures need to be maintained Increases the complexity of the timing receiver

4.3 Use of SyncE to allow enhanced GNSS holdover

As noted above, a good estimate of current frequency assists a GNSS receiver byreducing the spread of frequencies that it must search through in order to detect theGNSS 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 longerperiod of time, increasing sensitivity.

Secondly, during GNSS outages (of the sort caused, for example, by interference orjamming), 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 onepart in 1011, derived from the primary reference clock it is locked to. Therefore, if theGNSS input is disconnected, the SyncE signal will limit the drift of the timebase awayfrom correct time to around 1s per day.

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 a stable frequency to

maintain the timebase, protecting against GNSS outages and interference

Cons:

Two infrastructures need to be maintained Increases the complexity of the timing receiver


34/56


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 areference 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 theeNodeB. This architecture is shown inFigure 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 ofboundary clocks distributing the time reference through the network have a stable,

accurate frequency reference. The stability of the frequency reference reduces thedynamic time error accumulated in the chain of boundary clocks, allowing PTP todeliver 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 PTPGrandmaster, the stable frequency reference can be used to maintain accurate time atthe eNodeB for a period until the time reference is restored. This is known as timesynchronization holdover. A further advantage is the faster restoration of traceabletime after an extended interruption in the PTP distribution.

The drawback of providing two types of synchronization solutions in a network is anincrease in complexity and management. However, it could be argued that theadvantages outweigh the drawbacks.

Alternatively, other physical layer synchronization methods like SONET/SDH/ or PDHsignals 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

SyncEfrequencydistributionnetworks

PRCfrequencyreferences

[PRCs may be separate or common]

SyncE SyncE SyncE SyncE SyncE

PTP PTP PTP PTP


35/56


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: Two infrastructures need to be maintained


36/56


Version: 0.40 29

5. Synchronization capabilities of backhaul technologies

This section discusses the capability of the different types of small cell backhaul tosupport the various synchronization mechanisms.

In many instances, it is not possible to carry synchronization signals natively acrossthe backhaul network. For example, SyncE is carried at the physical layer of anEthernet signal. This is often imitated in backhaul technologies by providing a SyncEinput at the head-end equipment. The frequency is carried at the physical layer of thebackhaul technology (e.g. microwave carrier frequency, xDSL NTR signal), and a newSyncE signal generated at the remote end. A similar technique may be used with PTPfor frequency.

For phase and time, some backhaul technologies have built in phase or timesynchronization 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 theremote 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 thebasic functions.

All the technologies listed in this section may also be used to transport an Ethernetservice. 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 ofservice level agreements so that a service provider may offer standard Ethernetservices to mobile operators for RAN backhaul. SLAs for these MEF services wouldinclude performance objectives per class of service, to support the variedrequirements represented by LTE QCIs.

MEF 22.1 Mobile backhaul implementation agreement, Phase 2 identifies therequirements 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) arebased 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 smallcells. The point-to-point connections can be built up to provide chains or rings forresilient connectivity.

Two main techniques may be used to carry synchronization over millimetre wavebackhaul. These may be used in concert to improve the reliability of thesynchronization:

1. Physical layer frequency synchronization, by locking the carrier frequency of

the radio to a reference frequency. This may be used to provide SyncEservice, for example.

2. Packet-based synchronization such as PTP or NTP. Hardware basedtimestamping should be supported in case of time and phase requirements.


37/56


Version: 0.40 30

SyncE service should meet the ITU requirements at the SyncE interfaces, and includesupport for the ESMC channel carrying standard SSM QL values. For ring structures tobe 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 VLANpriority bits, DSCP bits for IP traffic, or the EXP bits for MPLS. The vendor mayrecommend specific QoS treatment.

Similarly, appropriate security should be provided, potentially including encryption ofthe radio link. Any encryption/decryption should not create variation in delay, sincethat would affect packet-based synchronization schemes.

Adaptive modulation may introduce dynamic asymmetrical delays. (when modulationdrops in one direction more than at the other direction). In addition Adaptivemodulation may introduce dynamic asymmetrical delays (when the two directions arenot 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 mechanismlike transparent clock or boundary clock to overcome the adaptive modulationimpairments.

5.2 Microwave: 6-60 GHz

Microwave links have been used for many years to backhaul both FDD and TDDsystems, demonstrating a general capability to provide both frequency and phasesynchronization. Support of specific technologies varies from product to product, butexamples of both physical layer (SyncE) and packet-based (PTP) support can befound.

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 andimplementation. FDD will offer much lower latency with less jitter as its full-duplexmode of operation is inherently free of the delay

075 Synchronization for LTE Small Cells

Documents