075 synchronisation for lte small cells

www.scf.io/ www.smallcellforum.org

DOCUMENT

Synchronisation for LTE small cells

December 2013

075.03.01

Produced in partnership with the Metro Ethernet Forum (MEF)

scf.io/

SMALL CELL FORUM

RELEASE Three

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

Email [email protected]

Post Small Cell Forum, PO Box 23, GL11 5WA UK

Member Services [email protected]

SMALL CELL FORUM

RELEASE ThreeSmall 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-pro t, 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 Three: Urban Foundations. 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. We look at the work underway across the industry to address barriers in the different disciplines of network architecture, radio access, backhaul, deployment, regulatory and services. In Release Four and beyond, we will delve into the detail of the solutions addressing the issues identi ed.

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 Three: Urban Foundations can be found here: www.scf.io/doc/103

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, speci cation, 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: The business case for enterprise small cellsIssue date: December 2013Version: 075.03.01

This document was produced in partnership with the Metro Ethernet Forum (MEF).

This paper is the result of a collaboration between Small Cell Forum and the Metro Ethernet Forum, working together to accelerate the adoption of carrier grade backhaul and synchronization for small cells.

ABOUT THE MEF

The MEF is a global industry alliance comprising more than 220 organizations including telecommunications service providers, cable MSOs, network equipment/software manufacturers, semiconductor vendors and testing organizations. The MEFs mission is to accelerate the worldwide adoption of carrier-class ethernet networks and services for business and mobile backhaul applications. The MEF is the de ning industry body for carrier ethernet, developing technical speci cations and implementation agreements, and educational work to promote interoperability, certi cation and deployment of carrier ethernet worldwide. For more information about the Forum, including a complete listing of all current MEF members, please visit http://www.MetroEthernetForum.org

THE MEF, CARRIER ETHERNET AND MOBILE BACKHAUL

Ethernet adoption has been accepted by the vast majority. The MEFs Carrier Ethernet 2.0 for Mobile Backhaul brings answers to the challenges associated with managing rapid backhaul data growth while scaling costs to new revenues. MEF Mobile Backhaul Phase 2 Speci cation (MEF 22.1) covering use of carrier ethernet services, synchronization 4G/LTE deployment and small cell introduction. The MEF also publishes business, technical and best practices papers and provides presentations on optimizing MBH with multiple classes of service, packet synchronization, resiliency, performance objectives, microwave technologies and converged wireless/wire-line backhaul.

Report title: Synchronization for LTE Small Cells Issue date: 8 Nov 2013 Version: 075.03.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.


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


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.


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


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

network and a backup service implemented by the backhaul provider .. 44 Figure 7-4 Synchronization service implemented at the mobile operators access

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

Report title: Synchronization for LTE Small Cells 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.


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 s1

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


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.


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.


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.


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.


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.


Indoor coverage use case


CoMP)

Backhaul type

View of sky (GNSS

availability)


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)


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)


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


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


CoMP)

Backhaul type

View of sky (GNSS

availability)


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.


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


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.


Figure 3-1 IEEE 1588 protocol

The messages yield four timestamps (t1, t2, t3 and t4) 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 = (t2 t1) + (t4 t3)

Oneway delay estimate = round trip delay 2

= (t2 t1) + (t4 t3) 2

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

Slave Clock Time

Data at Slave Clock

Follow_Up message containing true value of t1

Delay_Resp message containing value of t4

Sync message

Delay_Req message

time t1, t2, t3, t4

t1, t2

t2

t1, t2, t3

t2

t3

t1

t4

Master Clock Time


= (t2 t1) (t4 t3) 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


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.


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)


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 24 seconds (16s) to 217 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.


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 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 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),


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


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


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 55oS~55oN, 55oE~180oE, 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)


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


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


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.


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


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


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: 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


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 1011, 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: 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



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 sup

075 synchronisation for lte small cells

Documents

small cell market

small cell forums

small cell adoption

urban small cells

term small cells

rural small cells

lte small cellsdecember

deployment of residential