ECC Report 21 6

Practical guidance for TDD networks synchronisation

August 2014
ECC REPORT 216 - Page 2

0 EXECUTIVE SUMMARY

When more than one TDD network operates in the same geographic area and in the same band, severe
interference may impair network performance if the networks are uncoordinated, i.e. if some equipment is
transmitting while other equipment is receiving in the same time-slots. In that case, guard band and/or additional
filtering and/or other techniques often can be used in order to reduce interference.

However in the case of TDD-TDD coexistence, another way to avoid all BS-BS and UE-UE interferences
without using guard band and specific filtering is to synchronise base stations so that they roughly transmit and
receive in the same time. More precisely, synchronised operation means that no simultaneous uplink and
downlink occur between any pairs of cells which may interfere with each other in the same band. The
word “synchronisation” is often used in several other contexts (e.g. frequency synchronisation for FDD
networks, BS-UE synchronisation, etc.), and this report will focus on phase/time synchronisation for
interference-mitigation purposes, which involves different techniques.

In order to achieve synchronised operation, the following needs to be implemented on all base stations that may
interfere with each other (both within the operator and between other operators in the same frequency band):

 Having a common reference phase clock (e.g. for the start of frame). Unlike FDD technology that
only requires a frequency reference, TDD needs a common phase reference. The desired accuracy
depends on the technology, but the order of magnitude for currently considered IMT technologies is
about 1 to 3µs of clock drift between base stations. In practical deployments UTC is mostly used as a
common time reference.

 Configuring compatible frame structures (e.g. length of frame, TDD ratio, etc.) in order to align
uplink/downlink switching points. This is straightforward in the case of the same technology, but it needs
careful analysis in the case of cross-technology synchronisation. In the case of WiMAX/LTE-TDD
synchronisation, it is straightforward in most cases, even though some specific cases need more work.

The following techniques are currently available for transmitting a reference phase/time clock:

 GNSS: GPS is the main technique used today in TDD macrocells to provide phase/time with the proper
accuracy. This is a mature technology, however it requires sky visibility, and may experience outages
(intentional or unintentional). It is therefore usually not applicable for indoor small cells scenarios as well
as for some particular outdoor small cells scenarios.

 Packet based networks: packet methods such as PTPv2 are seriously considered to transmit a time
clock over packet networks. They require careful network engineering. Several telecom “profiles” have
been defined or are currently discussed at ITU-T SG15/Q13, both for frequency and phase/time clock
transport. At the time of writing, the nearly-finalised (expected in 2014) phase/time profile assumes full
on-path timing support i.e. assumes that all transport equipment between the master and the final slave
clock have dedicated hardware and software support to compensate for the time error introduced by
various effects, such as other traffic load variation. However full on-path timing support is not always
rd
practical in some situations (e.g. because of cost constraints, or because the backhaul belongs to a 3
party operator). Work and tests are still ongoing on other deployment scenarios where only partial on-
path timing support is available i.e. when not all transport equipment supports PTPv2 functions.

 Over-the-air synchronisation: 3GPP has defined a mechanism that allows a slave cell to get the
phase clock from a master cell. This mechanism is currently specified for LTE TDD HeNB up to 4 hops,
and has been tested in the lab with 1 hop. Work is ongoing to extend it to more scenarios. This is likely
to enable indoor small cells to get a reference phase clock in a cost effective way. However a
surrounding macrocell network in the same band with a proper UTC reference is required in order to
obtain UTC traceability.

 LORAN: in contrast to several existing terrestrial synchronisation technologies, LORAN accuracy is on

par with GNSS while having different characteristics (e.g. not affected by GNSS jamming).
Infrastructure is already deployed in some regions of the world such as Europe, APAC and Russia
 ECC REPORT 216 - Page 3

(towers/transmitters based on Loran-C or eLoran depending on countries). Its low frequency

theoretically enables it to indoor and submarine coverage, even though additional studies are necessary
to assess whether the antennas could be properly miniaturised while still ensuring proper signal
reception in most indoor scenarios. It is currently used for marine and military positioning, and has not
been specified at ITU for telecom contexts at the time of this writing.

The above 4 techniques are the main ones that allow UTC traceability with accuracy performance that is suited
for IMT deployments at the time of writing. This does not exclude the applicability of potential other / new
techniques for phase synchronisation, although this has not been fully evaluated yet.

In order to deploy synchronised TDD mobile networks in a multi-operator context (without guard bands),
agreement needs to be reached on
 A common phase clock reference (e.g. UTC) and accuracy/performance constraints (e.g. +/- 1.5µs),
either using their own equipment to provide the clock, or sharing the same phase/time clock
infrastructure;
 A compatible frame structure (including TDD UL/DL ratio) in order to avoid uplink/downlink overlapping;
 A commitment not to interfere with each other as any synchronisation issue of one operator may impact
the network of the others (e.g. reliability of the reference clock and protection mechanism have to be
ensured and/or procedure when losing this reference clock has to be defined);
 The terms & conditions where cross-operator synchronisation must apply and/or may not be required
(e.g. geographical zones / isolated eNB, HeNB-only deployments…);
 How to update those parameters.

When multiple operators deploy TDD networks on adjacent bands inter-network synchronisation conditions can
be discussed and agreed at the national level and implemented nationwide or limited to a given area (regional)
as appropriate.
ECC REPORT 216 - Page 4

TABLE OF CONTENTS

0 EXECUTIVE SUMMARY ............................................................................................................................ 2

1 INTRODUCTION: SYNCHRONISATION OF TDD NETWORKS .............................................................. 6

1.1 Context .............................................................................................................................................. 6
1.2 New deployment scenarios ............................................................................................................... 6

2 TDD NETWORK SYNCHRONISATION TECHNIQUES ............................................................................ 8

2.1 Definition for synchronised TDD networks ........................................................................................ 8
2.2 Phase Synchronisation of the reference phase/time clock ............................................................... 9
2.2.1 Accuracy requirements .......................................................................................................... 10
2.2.2 Synchronisation by GNSS ..................................................................................................... 10
2.2.3 Synchronisation over packet networks .................................................................................. 11
2.2.4 Over-the-air synchronisation for LTE-TDD HeNB by network listening ................................ 14
2.2.5 Terrestrial synchronisation networks ..................................................................................... 15
2.2.6 Holdover and resilience ......................................................................................................... 17
2.3 Frame structure coordination .......................................................................................................... 19
2.3.1 Overview ................................................................................................................................ 19
2.3.2 Cross-technology network synchronisation ........................................................................... 19

3 PRACTICAL GUIDANCE FOR INTER-OPERATOR DEPLOYMENTS .................................................. 21

3.1 Clock synchronisation ..................................................................................................................... 21
3.2 Inter-operator synchronisation pre-requisites .................................................................................. 22
3.3 General considerations on Inter-operator agreements ................................................................... 22

4 CONCLUSION .......................................................................................................................................... 24

ANNEX 1: WIMAX AND LTE-TDD FRAME STRUCTURES.......................................................................... 25

4.1 3GPP LTE ....................................................................................................................................... 25
4.2 WiMAX 802.16e............................................................................................................................... 26
4.3 WiMAX/LTE-TDD compatibility matrix............................................................................................. 27

ANNEX 2: ITU-T SG15/Q13 STANDARDS AND WORKPLAN ..................................................................... 29

ANNEX 3: EXISTING EXAMPLES OF CROSS-OPERATOR TDD SYNCHRONISATION ........................... 30

ANNEX 4: LIST OF REFERENCES ............................................................................................................... 31

 ECC REPORT 216 - Page 5

LIST OF ABBREVIATIONS

Abbreviation Explanation
ACIR Adjacent Channel Interference Rejection
APTS Assisted Partial Timing Support
BEM Block Edge Mask
BS Base station
BWA Broadband Wireless Access
CEPT European Conference of Postal and Telecommunications Administrations
CoMP Cooperative Point-to-MultiPoint
DwPTS Downlink Pilot Time Slot
ECC Electronic Communications Committee
EC European Commission
ECO European Communications Office
eNB eNodeB (LTE BS)
EU European Union
E-UTRA Evolved Universal Terrestrial Radio Access
FDD Frequency Division Duplex
FFS For Further Study
GNSS Global Navigation Satellite System (GPS, Galileo, Glonass, BeiDou, etc…)
GPS Global Positioning System
HeNB Home eNodeB (LTE femtocell)
IMT International Mobile Telecommunications
LORAN LOng RAnge Navigation system
LOS Line Of Sight
MBSFN Multicast Broadcast Single Frequency Network
MFCN Mobile/Fixed Communications Networks
MFW Multipoint Fixed Wireless
MTIE Maximum Time Interval Error
OCXO Oven Controlled Crystal Oscillator
OTA Over-the-air
PDV Packet Delay Variation
PMP Point to Multipoint
PNT Positioning, Navigation and Timing
PTP Precision Time Protocol (IEEE-1588)
PTS Partial Timing Support
PRTC Primary Reference Time Clock
SDO Standard developing organization
TCXO Temperature Controlled Crystal Oscillator
TDD Time Division Duplex
TS, SS Terminal Station, Subscriber Station
UE User Equipment (LTE TS)
UL/DL Uplink/Downlink
UTC Universal Coordinated Time
ECC REPORT 216 - Page 6

1 INTRODUCTION: SYNCHRONISATION OF TDD NETWORKS

1.1 CONTEXT

When more than one TDD network operates in the same geographic area, severe interference may happen if
the networks are uncoordinated, i.e. if some equipment is transmitting while other equipment is receiving in the
same time-slots and in the same band (on the same channel or on adjacent channels) while having a poor
isolation (e.g. because of geographical proximity like in co-sited deployments in a multi-operator context, or
because of line of sight situations). Indeed, in this situation, both out-of-band and spurious emission on the
transmitter side and imperfect adjacent channel selectivity on the receiver side can desensitise or block the
neighbour receiver, preventing it from properly listening to desired signals.

Figure 1: Adjacent network interference scenarios for unsynchronised TDD (from [1])
BS-UE interferences (yellow arrows) happen in all cases and are handled as part of the standards
UE-UE and BS-BS interferences (orange arrows) happen in the case of unsynchronised TDD networks

Without inter-operator synchronisation, coexistence may require operator-specific filters at the eNB side both at
the transmitter and receiver to avoid interference. This may prevent economies of scale. Furthermore, additional
filtering at the UE side is usually not feasible.

In the case of TDD-TDD coexistence, one way to avoid all BS-BS and UE-UE interference without using guard
band and specific filtering is to synchronise base stations so that they align their downlink and uplink switching
points, as described in further sections.

Since synchronised operation reduces UE-UE and eNB-eNB interferences compared to unsynchronised
operation, different regulatory constraints (such as block edge masks) may apply to those two different
situations. ECC Report 203 [19] gives an example of different block edge masks for synchronised TDD and
unsynchronised TDD operations.

1.2 NEW DEPLOYMENT SCENARIOS

Most often (except in the case of isolated BS deployments), all TDD equipment from the same operator is
phase/time synchronised in order to avoid self-interference. At the time of writing most TDD networks have been
deployed with outdoor macrocells where BS antenna is installed above the roof-top or on a mast. In this context,
phase/time synchronisation is mostly not a technical issue thanks to GNSS. Besides, they have mostly been
 ECC REPORT 216 - Page 7

deployed in single-technology and single-operator per region context, avoiding issues for cross-operator or
cross-technology common frame structure configuration.

In the near future other deployment scenarios are expected as several frequency bands are available for TDD
networks (e.g.: 1900-1920 MHz, 2010-2025 MHz, 2300-2400 MHz, 2570-2620 MHz, 3400-3600 MHz, 3600-
3800 MHz.

N.B. this report is not limited to a specific band and applies generically to any TDD deployment). More precisely,
this report will consider the following new orthogonal cases that may require different synchronisation
techniques:
 networks deployments using indoor and/or outdoor cells of any kind (macrocell, microcell, picocell,
1
HeNB, HetNets…) and using various types of backhaul links (e.g. Ethernet, Microwave, xDSL, xPON,
etc.);
 networks using different technologies (e.g. WiMAX/LTE-TDD);
 networks from different operators on adjacent channels;
 or a combination of those cases.

1
Those scenarios have also been assessed by white-papers from the Small Cell Forum [18].
ECC REPORT 216 - Page 8

2 TDD NETWORK SYNCHRONISATION TECHNIQUES

2.1 DEFINITION FOR SYNCHRONISED TDD NETWORKS

The word “synchronisation” is used in many different contexts with different meanings. For example, BS-UE
synchronisation within the same network, frequency and phase synchronisation at the carrier level for
demodulation purposes, frequency synchronisation for FDD networks like GSM, etc. This report will only focus
on synchronisation at the frame level between TDD networks for interference mitigation purposes.

Frequency synchronisation, phase synchronisation and time synchronisation can be distinguished, as illustrated
in the following figure:

Figure 2: Frequency, phase and time synchronisation

Frequency synchronisation (also called "syntonisation") means equipment A and B get a common reference
signal and evolve at the same rate within a given accuracy and stability but significant instants of the
signal are not aligned in time.
Phase synchronisation means equipment A and B get a common reference signal and significant instants are
aligned in time within a given accuracy and stability but are not necessary traceable to a reference time
clock (e.g. UTC).
Time synchronisation means equipment A and B are phase-synchronised with a known traceable reference
clock (e.g. UTC, same reference for leap seconds, etc.).

Both FDD and TDD mobile networks usually require frequency synchronisation in order to implement seamless
handovers. In addition to that, TDD networks require aligning UL/DL switching points between cells in
overlapping coverage areas in order to avoid interference. In the context of this report, synchronised
operation means that no simultaneous uplink and downlink occurs between any pairs of cells which
may interfere with each other in the same band (e.g. because of geographical proximity or line-of-sight). This
implies:
 Having a common phase reference
2
 Configuring compatible frame structures , i.e. setting the length of the frame, the TDD uplink/downlink
ratio and guard period in order to align UL/DL switching points, so that the last transmitter stops before
the first receiver starts, taking into account the propagation delay (e.g. in LOS non co-sited cases).
Frame structures do not need to be exactly identical provided this condition is met.

2
For certain scenarios it may not be necessary to align frame structures as other interference mitigation schemes may be sufficient (e.g.
Cell clustering interference mitigation, studied in 3GPP).
 ECC REPORT 216 - Page 9

This definition is valid both within a single operator network (in order to avoid self-interference between
equipment from the same operator), and between operators in the same band (e.g. on adjacent-channels). It
has to be noted:
 In order to avoid interference, only cells in the vicinity of each other that may interfere together need to
be synchronised in phase. Therefore isolated cells may not require to be synchronised with other cells
in the same band if they cannot interfere.
 Only phase synchronisation is required for interference-mitigation, but time synchronisation is generally
implemented practically in order to have a traceable time reference (e.g. UTC).

nd
The following picture illustrates interference when the start of frame is not aligned (2 scenario) or when TDD
rd
UL/DL ratio is not aligned (3 scenario).

Examples of synchronised operations (no TX/RX overlap and no interference, despite slightly different frames)
Operator A
Operator B
OK
Operator C
Operator D

Same frame structure, but not same start of frame

Operator A
Operator B NOK
Interference periods

Same start of frame, but not same frame structure

Operator A
Operator B NOK
Interference periods

Downlink Uplink

Figure 3: Interference scenarios for TDD/TDD systems

“Interference period” as illustrated on the third scenario of Figure 3 may embrace both eNB-eNB (downlink-to-
uplink) and UE-UE (uplink-to-downlink) interference types leading to mutual interferences between operators.
However when only one type of interference is dominant, the interferences may no longer be mutual: if eNB-
eNB interferences are dominant, the operator who has more downlink is an interferer and the operators who
have less downlink are interfered. Conversely, if UE-UE interferences are dominant, the operator who has more
uplink is interferer and the other operators are interfered.

Some advanced features in both FDD and TDD networks, such as CoMP and MBSFN also require phase
synchronisation in order to be effective. The exact values are still under discussion and could be more stringent
than the requirements for TDD. This report focuses on phase/time synchronisation in TDD network for
interference-mitigation purposes.

2.2 PHASE SYNCHRONISATION OF THE REFERENCE PHASE/TIME CLOCK

This section discusses the main techniques, available at the time of writing, to bring a reference phase/time
clock to the TDD base stations with a proper accuracy for the considered IMT technologies and with UTC
traceability. Other synchronisation techniques may also be considered in the future (e.g. restricted to phase
synchronisation without UTC traceability).
ECC REPORT 216 - Page 10

2.2.1 Accuracy requirements

At the time of writing, most IMT technologies have a typical requirement of 50ppb in frequency accuracy for
wide area base stations. When phase synchronisation is required, it is often on the order of 1µs, as illustrated in
the following table:

Table 1: Phase/time accuracy requirements for various technologies

Technology Phase/time accuracy requirements 3

CDMA2000 FDD (C.S0010-B, C.S0002-C) +/- 3 µs with respect to UTC (during normal conditions10. +/-
10 µs of UTC (when the time sync reference is
disconnected)
WCDMA TDD (TS 25.402) 2.5 µs
TD-SCDMA (TS 25.836) 3µs
LTE TDD (TS 36.133 [2]) 3µs (normal cell radius), 10µs (large cells), 1.33µs+Tprop
(HeNB > 500m radius)
WiMAX 802.16e TDD (IEEE 802.16) 1µs

The calculations that lead to the 3µs value between LTE eNB can be found in 3GPP contribution R4-082105 [3].

2.2.2 Synchronisation by GNSS

Description:
GNSS systems such as GPS, Galileo, GLONASS or BeiDou allow a receiver to get time synchronisation with an
accuracy of 100 ns. Standard G.8272 defines those Primary Reference Time Clocks (PRTC) characteristics.

Maturity and current deployment:

Synchronisation by GNSS is suitable for base stations that have an outdoor antenna (with good sky visibility)
and therefore can receive a GNSS signal. Macro-cell outdoor BS should then be able to be synchronised by this
method, which is already widely used for most existing outdoor TDD systems like WiMAX and TD-SCDMA
networks, as well as CDMA2000 FDD networks. It has to be mentioned that at the time of writing some GNSS
system are not yet fully available (e.g. Galileo) or are not worldwide available (e.g. BeiDou).

Implementability:
Currently this method requires sky visibility, which makes it difficult to implement in some situations (e.g. for
indoor cells or in urban canyons). Some progress in chipset sensitivity may make GNSS available indoor in
some situations, but this remains a case-by-case applicability that cannot be generalised.

Using directly a GNSS solution implies some costs (e.g. antenna, lightning arrester, possible amplifier, cable to
the base station that may not be located immediately near). This cost may be small for macro/microcell
compared to the cost of the site and equipment, but may be non-negligible for small cells, depending on
advances on chipsets designed specifically for these cases.

The threat from GPS jamming by commercially available jammers has been extensively researched in the UK
by two UK Government supported projects GAARDIAN and SENTINEL. This threat should not be ignored.
Since the signal from space to earth is extremely low (equivalent to a 20W light bulb at a distance of 20,000
km), it is very easy to jam with a relatively low power jammer, and practical interference events have already
been observed. Besides, more powerful criminal jammers with a far bigger impact radius must also not be
ignored. Other interference effects such as space weather and multipath may also affect GPS reception. As a
consequence, GPS should not be considered 100% reliable and may experience temporary outages.

As an illustration of regular GPS jamming, Figure 4 below shows a histogram of jamming events over 5 seconds
duration at a sensor from the SENTINEL project located in the city of London during the period Feb-Dec 2013.
Most months show in excess of 100 events.

3
Those values are peak-to-peak time error between base stations according to the relevant standards for the air interfaces. One practical
way to implement those is to refer to a reference like UTC (e.g. in the case of LTE-TDD, consider +/- 1.5 µs from UTC)
 ECC REPORT 216 - Page 11

200

150

100

50

1
33
65
97
129
161
193
225
257
289
321
353
385
417
449
481
513
545
577
Figure 4: GPS Jamming Events per Month in the center of London, and pdf of jamming duration

From this data-set, the following statistics could be computed about jamming events (duration is in seconds):

Number of events 1755

Mean duration 44,68
Standard deviation of duration 66,85
Max duration 605
Total sum of durations 1755

This example shows that most jamming events have a duration of about a few seconds or minutes. More
generally GPS regular jamming events are expected to remain mostly localised in time and space. However
longer durations (10 minutes in this example) cannot be excluded even though those events may be rare. Other
type of events (such as military conflicts, terrorist or organised crime activity, antenna outage, space weather
conditions, spoofing, etc.) may also lead to wider or longer GPS outages. It has to be noted that the jamming
duration is not the only parameter to take into account in order to estimate GPS outage, since the event may be
of sufficient power to totally deny GPS reception for a period which then causes the GPS receiver to have to
reacquire signal. The time holdover capability of the base station should therefore also take this reacquisition
time into account. GPS receiver designs should also ensure that they don’t suffer catastrophic failures (e.g.
manual reset) after such events.

2.2.3 Synchronisation over packet networks

Introduction:
Several techniques have been designed in the past in order to ensure clock transport over packet networks:
 NTP [4] is one of the oldest protocols and is widely deployed for non-critical applications with an
accuracy of around 1ms, but in general it is not designed with hardware support in mind and
therefore is not suited for accuracies around 1µs even though some proprietary non-standard
implementations with proper hardware support may achieve this kind of accuracy.
 Synchronous Ethernet (SyncE) [5] has been specified by ITU-T SG15/Q13, reusing many concepts
from SDH (which inherently provides frequency synchronisation). It is only designed for frequency
synchronisation and does not support phase/time synchronisation. It may be used complementary
to a phase/time synchronisation technique in order to improve reliability (time holdover) in case of
time reference failure.
 IEEE-1588v2 (Precision Time Protocol or PTP) [5][6][7] is the main considered technique in order to
transport phase/time by the network with the desired accuracy for IMT purposes. It may be used for
frequency synchronisation and/or for phase/time synchronisation.

It has to be noted that all those methods are only clock transport mechanisms and need to be driven by a proper
clock source that is defined by a global standard. It may be a GNSS receiver (as described in G.8275) or any
other system.
ECC REPORT 216 - Page 12

Considering the accuracy requirements previously defined for IMT deployments, this section will focus on IEEE-
1588v2 (PTPv2) for phase/time synchronisation, possibly assisted with SyncE.

IEEE-1588v2/PTPv2: presentation
Precision Time Protocol (PTP) version 1, also known as IEEE1588, is a standardised protocol defined by the
IEEE in 2002, coming initially from the automation world. The initial objective of this protocol is to deliver time
synchronisation with a very high accuracy (sub-microsecond) in a LAN environment. Therefore, IEEE 1588 is
not a technology dedicated only to telecom. A second version of the standard has been approved by the IEEE in
2008. It provides new features that enable it to be used in telecom applications. However, it is a standard with a
large scope and many options defined for different contexts and not restricted to telecoms, therefore there is a
need to define a subset of the options in order to avoid unnecessary complexity and ensure interoperability in
telecom environments. Additional specifications are also needed in order to define user requirements (e.g.
performance, architecture, reference model, security, management, etc.). These are part of the so-called
"telecom profiles" defined by the ITU-T SG15/Q13 standard group.

Several telecom recommendation series (including profiles) have been or are being specified by ITU-T:

 G.826x: in 2010, ITU-T Q13/SG15 has defined a PTP telecom profile for “end-to-end” frequency
distribution in the Recommendation G.8265.1 [21] “End-to-end” means that the nodes in the
synchronisation path (the path the PTP packets follow from the grandmaster to the slave) do not embed
PTPv2 functions such as TC or BC since their use is prohibited in this profile.

 G.827x: ITU-T Q13/SG15 is currently working on new profiles to address the phase and time
distribution by the network. Different profiles address the situations where either all the nodes embed
PTPv2 functions in the synchronisation path (called full on path timing support) or where only some
nodes implement this (called partial on-path timing support).

Annex 2 summarises the relevant ITU-T standards at the time of writing.

IEEE-1588v2/PTPv2: technical description

The following figure illustrates the basic PTP dialog between master and slave when PTP is used as a two-way
protocol for phase/time recovery (i.e. delay request-response mechanism is used in order to calculate and
compensate the delay that the packets spent through the network):

Figure 5: Principle for PTP algorithm

 ECC REPORT 216 - Page 13

Master and slave have their own internal reference clock, and the purpose is to align slave internal clock on
master reference clock. Thanks to the dialog depicted in the figure above, the slave knows the four timestamps
t1, t2, t3, and t4, and will use them to calculate the offset its internal clock experiences compared to master
reference clock, using the following formula:
(𝑡2 − 𝑡1 ) − (𝑡4 − 𝑡3 )
𝑇𝑂𝑓𝑓𝑠𝑒𝑡 =
2

This calculation assumes that the delays in both directions (delay from Master to Slave and delay from Slave to
Master) are symmetric, or at worst that the asymmetry is fixed and known (otherwise, it is not possible to
determine and compensate the slave internal clock offset).

As we can see, PTP is normally a two-way protocol since messages are exchanged between master and slave
in both directions. It is possible to use PTP as a one-way protocol, using only the "Sync" messages, in order to
deliver only frequency. In this case, the calculation differs from the previous formula and is based in general on
“adaptive clock recovery” principles, which consists in recovering frequency synchronisation via packets. For
phase/time synchronisation, two-way communication is always needed. When PTP is used with the two-way
mode (for phase and time delivery), the slave initiates the path delay calculation, e.g. by issuing "Delay_Req"
messages to the master, which answers by "Delay_Resp" messages, in order to calculate and compensate the
delay that the packets spend through the network

Packet Delay Variation (PDV also called packet jitter) is the main factor impairing PTP solutions when there is
no hardware support from the intermediate nodes. In order to be able to reach the requirements for phase/time,
two mechanisms are defined in the protocol, based on hardware and software PTPv2 functions embedded in
nodes:

 Telecom Boundary Clock (T-BC): it acts like a slave on the ingress port (connected to a master) and
as a master on the egress port (connected to slave(s)). This allows compensating the internal latencies
and jitter of the node.
 Telecom Transparent Clock (T-TC): it measures the time of residence of the PTP packet in the node
by timestamping its arrival time on the ingress port and its departure time on the egress port. The
difference is inserted on the fly in the PTP packet in the correction field. The end application slave will
use this correction field to compensate PDV and calculate its offset.

Those mechanisms, as part of the PTP protocol, will not help to fight against the asymmetry of physical links. In
case of link asymmetry, the protocol is not capable of determining and compensating this asymmetry and there
will be a time error in the calculation of the slave internal clock offset if there is no prior calibration. For instance
over fibre links, it is generally agreed that a meter of length difference between the two ways will generate
roughly 2.5 ns of time error. Potentially this error may accumulate over the links of the synchronisation path.

Asymmetry can be made of:

 Constant time error: if the link asymmetry is static (e.g. when Tx and Rx fibers have different length), it
can be calibrated during the deployment (e.g. using a GPS receiver as a reference clock) and set as a
parameter in order to compensate the asymmetry in T-BCs/T-TCs and slave equipment.
 Dynamic time error: since PTP packets are multiplexed with data packets of different length, and for
many other reasons such as temperature effects on oscillators, PDV (packet jitter) is introduced by the
equipment (even when PTP traffic is prioritised). This is precisely where hardware assistance in BC and
TC helps improve the accuracy.

Maturity and current deployment:

As mentioned previously ITU-T Q13/SG15 is currently defining several telecom profiles for phase and time
delivery:
 G.8275.1 is the phase/time profile assuming full on-path timing support (i.e. assuming that all transport
equipment between the master clock and the slave clock support PTP functions). This recommendation
was formally consented in April 2014 and the approval process of this recommendation has been
initiated. The currently defined mapping occurs at OSI layer 2 (i.e. PTP mapped over Ethernet). The
currently defined mapping occurs at OSI layer 2 (e.g. Ethernet). Deployments are already happening in
ECC REPORT 216 - Page 14

China using this draft profile. It should be noted that interworking with technologies other than Ethernet
(e.g. xPON, xDSL, microwaves, etc.) has to be assessed on a case by case basis.
 G.8275.2 is the phase/time profile assuming Assisted Partial on-path Timing Support (APTS). This is
the current Q13 work item that refers to the case where a GNSS receiver is deployed at the base station
for frequency and time synchronisation, and protected with PTP Partial on-path Timing Support (PTS)
i.e. allowing legacy non PTP-aware equipment between the master and the slave clock. This is
therefore rather a protection scenario than a real phase/time distribution solution that simplifies the
problem of partial timing support, because the asymmetry of the network can be estimated when the
GNSS is working properly. With a proper asymmetry compensation, PTPv2 with partial on-path timing
support is expected to be able to provide timing synchronisation that allows respecting the +/- 1.5 µs
requirement during a GNSS failure that could last several hours. In this case it is expected that the
profile will be based on PTP mapped over IP.
 G.8275.x stands for future profile that is not yet studied but is likely to describe the case of Partial on-
path Timing Support (PTS). The performance of such solution is therefore hard to predict or guarantee.
Indeed, despite static/fixed asymmetry can be corrected by proper calibration, dynamic asymmetry and
other effects such as packed delay variation are much more challenging to handle, even though clock
noise filtering might be able to attenuate some of those effects. Therefore at the time of writing, it is
premature to conclude on the performance or applicability of PTS to deliver phase and time with the
proper quality, and it may also depend on the deployment scenario. Also in this case this profile may be
based on PTP mapped over IP as well as over Ethernet.

Implementability:
Some equipment is already available at the time of writing for phase/time synchronisation, but is not yet
compliant with G8275.1 so interoperability is not fully guaranteed until this equipment is upgraded (it is expected
that software upgrade will be sufficient). These deployments scenarios mostly assume that IEEE-1588v2 is
used over the backhaul, with a full on-path timing support between the master and slave equipment. What is
feasible on various technologies (such as xDSL, xPON, microwaves) is a case-by-case analysis. Some of those
have been assessed in [8].

Other studies are ongoing in some countries (e.g. US and China) to assess other deployment scenarios with a
master clock (e.g. GNSS receiver + PTP grandmaster) closer to the slave equipment, and a limited number of
hops on a non-PTP-enabled network (e.g. 2-3 hops on a gigabit Ethernet LAN). Those scenarios are considered
for TDD small cells deployments, but they are for further studies within ITU-T Q13 standards therefore it is
premature to give conclusions or to guarantee performances at the time of writing.

2.2.4 Over-the-air synchronisation for LTE-TDD HeNB by network listening

Description:
Network listening is presented in 3GPP technical report TR 36.922 §6.4.2 [9], and the corresponding signalling
messages are specified in technical standards TS 36.413 §9.2.3.34 and TS 32.592 §6.1.1.8.1 [10]. Using this
4
technique, a HeNB derives its timing from another synchronised eNB or HeNB.

The cell used as a clock reference is not required to be a macrocell connected to GNSS since the scheme
allows for multi-hop HeNB-to-HeNB. First lab tests have given promising results, suggesting that this technique
has real potential (e.g. 200ns for one hop in some tests). 3GPP has currently defined 4 levels of precedence,
which allow up to 3 hops (in TS-36.413 §9.2.3.34 [10]). More hops may be allowed in the future – especially
considering that HeNB several hops away might be far enough not to interfere with each other.

Two mechanisms are described in the TR 36.922, one that relies on MBSFN subframe, and one that relies on
dwPTS subframe. They both have different merits, as discussed in [11].

4
Assuming HeNB synchronisation is still desired, which may not always the case be considering the low power and high wall penetration
loss and ACIR in case of adjacent channels.
 ECC REPORT 216 - Page 15

Figure 6: Illustration of over-the-air "network listening" mechanism for LTE-TDD

Maturity and current deployment:

At the time of this writing, the network-listening approach has been successfully implemented and tested in the
lab for single-operator LTE HeNB synchronisation [11]. Those reference implementations use the two
approaches described in TR 36.922 §6.4.2.1.3 [9].

A new work-item “small cell enhancements for E-UTRA and E-UTRAN Physical layer aspects” was set up in
5
3GPP RAN#62 for Rel-12 (RP-132073). It will focus on single-operator or multi-operator deployments , may
allow for more hops according to scenarios and may enable the technology to other types of nodes than HeNB.

Implementability:
This solution is restricted to LTE HeNB. The stratum 0 eNB needs to be connected to a proper UTC reference
(e.g. GNSS) in order to get UTC traceability. It currently requires less than 4 hops between the master and the
slave cell. Following current 3GPP work in Release 12, other deployment scenarios may be possible in a near
future.

2.2.5 Terrestrial synchronisation networks

Description:
The LOng RAnge Navigation system (Loran) is a narrowband terrestrial timing and positioning system,
employing pulsed radio signals at 100 kHz, a frequency at which signal propagation is very time-stable. Its
enhancement called eLoran, is replacing the earlier Loran-C which was deployed for civil and military maritime
and aviation navigation. According to International Loran Association [12], "Enhanced Loran (or eLoran) is a
Loran system that incorporates the latest receiver, antenna, and transmission system technology to enable
Loran to serve as a backup and complement to global navigation satellite systems (GNSS) for navigation and
timing. This new technology provides substantially enhanced performance beyond what was possible with
Loran-C. For example, it is now possible to obtain absolute accuracies of 8-20 meters using eLoran for harbour
entrance and approach. Similarly, eLoran can function as an independent, highly accurate source of universal
coordinated time (UTC)”. For timing, eLoran transmissions are synchronised to an accurate source of UTC.
Also, a UTC time message is broadcast to users over an eLoran Data Channel.

According to [13] [14], eLoran has the following benefits (contrary to several other terrestrial systems such as
DCF77):
 UTC traceability, accuracy and stability on a par with GPS and other GNSS (fig. 7) shows accuracies
which degrade to 500ns in the red zone at a 1500 km radius of the transmitter, but the use of differential
corrections could improve accuracy to 50ns.
 Not impacted by GPS jamming, (and therefore can be a possible mitigation solution when GNSS fails).

5
If eNBs of different operators are to be co-located (e.g. in indoor scenarios), then one eNB has to switch to the other eNB’s carrier and
listen to it. This can lead to the received power far exceeding the dynamic range requirements, resulting in inoperability or at the very least
unpredictable behavior. Hence, additional isolation between the eNBs may be required either via locating the two eNBs further apart or by
some other mitigation technique.
ECC REPORT 216 - Page 16

 Better indoor penetration than GNSS with current eLoran antennas in the coverage zone.

Figure 7: Best (Blue) to 500ns (Red) eLoran Coverage for Anthorn, Lessay and Soustons

An indication of the relative accuracy of GPS and eLoran timing references is shown in the following figures
(data provided by Chronos UK). It can be seen that eLoran UTC tracks GPS UTC (USNO UTC ) with a good accuracy.

Figure 8: TIE graph of eLoran (Blue) and GPS (Magenta) 1pps timing signals over 9 days
 ECC REPORT 216 - Page 17

Figure 9: MTIE graph of eLoran (Blue) and GPS (Magenta) 1pps timing signals over 9 days

Drawbacks of eLoran currently are:

 Coverage is regional rather than international, even though several regions in the world have similar
systems (e.g. APAC, Europe, Russia…). It is challenging to deploy new high-power stations in Europe
considering the practical requirements and logistics however low-power stations could be deployed to
enhance land coverage. More generally, eLoran is targeted at maritime PNT users, resulting in uneven
coverage that favours sea areas.
 Loran-C future and maintenance is unclear in some countries, pending arbitrations based on budget
considerations vs Loran’s technical merits as a complementary, independent and dissimilar backup to
GNSS (e.g. in case of jamming or signal unavailability). Potential applicability for civil uses such as
telecoms might also favourably influence those arbitrations.
 The cost, volume and footprint of current receivers may be acceptable for macrocells but not yet for low-
cost small cells; however, developing a dedicated low-cost receiver ASIC is not foreseen to be difficult
technically or commercially given sufficient volume.
 Antenna enhancements are needed in order to lower their footprint for small cell applications. Indoor
coverage with such low-footprint antennas is still to be assessed.
 It has not been formally specified for telecom applications by standards organization such as ITU-T,
therefore its practical applicability needs further studies.

Maturity and current deployment:

In the UK, prototype eLoran has operated for over 3 years and Initial Operational Capability (IOC) has recently
been implemented for maritime positioning, navigation and timing (PNT). The service provides precise timing for
land users across the UK, Ireland and parts of the Continent. These UK eLoran transmissions are backward-
compatible with Loran-C, which remains operational in northwest Europe with transmitters in France, Denmark
(Faroe Islands), Germany and Norway. All Loran-C stations can be modernised to provide eLoran navigation
and timing. Global evolution towards eLoran is anticipated, with integrated eLoran/GNSS receivers aimed at
multiple applications. This technology is also deployed in Russia and APAC. Equipment/towers are also
deployed in the US even though the US government has stopped operating it at the time of this writing (but it is
technically feasible to restart operations).

2.2.6 Holdover and resilience

All oscillators drift over time when they are not disciplined by a reference clock. More expensive oscillators such
as OCXOs drift more slowly than cheaper ones like TCXOs (which are more frequently used in UEs and small
cells), even though new TCXO generations have an increasing quality that may allow them to be used in
situations where an OCXO used to be required. The following tables (from Symmetricom [20]) give indications
ECC REPORT 216 - Page 18

on the typical holdover time for various clocks defined by ITU-T (it does not exclude better performances by
available hardware from the industry):

Table 2: Time to Produce a Particular Error for Various Oscillator Types

500 ns 1 µs 1.5 µs 5 µs 100 µs 500 ms

G.812 Type 1 1.57 hr 2.22 hr 2.72 hr 4.97 hr 22.22 hr 65.47 d
G.812 Type 2 8.16 hr 11.55 hr 14.14 hr 25.82 hr 4.81 d 340.21 d
G.812 Type 3 1.57 hr 2.22 hr 2.72 hr 4.97 hr 22.22 hr 65.47 d
G.812 Type 4 7.84 min 11.09 min 13.59 min 24.81 min 1.85 hr 5.45 d
G.812 Type 5 2.11 hr 2.98 hr 3.65 hr 6.67 hr 29.81 hr 87.84 d
G.812 Type 6 28.28 min 40.00 min 48.99 min 1.49 hr 6.67 hr 19.64 d
G.813 Opt 1 3.46 min 4.90 min 6.00 min 10.95 min 48.99 min 2.41 d
G.813 Opt 2 2.28 min 3.23 min 3.96 min 7.22 min 32.30 min 1.59 d

Table 3: Error Produced in a Particular Time for Various Oscillator Types

15min 1hr 12hr 24hr

Cesium (1E-12)* 86.40 ns
G.811* 864.00 ns
G.812 Type 1 12.66 ns 202.50 ns 29.16 µs 116.64 µs
G.812 Type 2 0.47 ns 7.50 ns 1.08 µs 4.32 µs
G.812 Type 3 12.66 ns 202.50 ns 29.16 µs 116.64 µs
G.812 Type 4 1.83 µs 29.25 µs 4.21 ms 16.85 ms
G.812 Type 5 7.03 ns 112.50 ns 16.20 µs 64.80 µs
G.812 Type 6 140.63 ns 2.25 µs 324.00 µs 1.30 ms
G.813 Opt 1 9.38 µs 150.00 µs 21.60 ms 86.40 ms
G.813 Opt 2 21.56 µs 345.00 µs 49.68 ms 198.72 ms

When base stations lose the reference clock, they can still continue to operate with their local oscillator in a
mode called "holdover". Frequency synchronisation and phase/time synchronisation have different requirements
and therefore maximum holdover duration before respectively frequency or time error exceeds the drift
tolerance — i.e. the maximum acceptable frequency or time error for the considered technology — differs
between them. Considering current accuracy limits for IMT technologies, time holdover is typically shorter than
frequency holdover meaning that some protection mechanism need to be found in order to maintain the proper
accuracy and avoid radio interferences. Some protection mechanism may be used in order to increase the time
holdover duration (e.g. the local base station oscillator can get a proper frequency reference clock in order to
drift more slowly).

Some base station vendors allow to configure a default holdover parameter (e.g. 2 hours for some WiMAX
macro base stations [15], and supposedly significantly better for newer LTE-TDD eNB with more recent
oscillators), and take appropriate measure when they lose the time reference for a duration that exceeds this
configured holdover (e.g. shutdown the radio signal as described in [15]). It should however be noted that the
clock drift does not only depend on oscillator quality, but also on several parameters such as temperature
gradient, so the configured holdover time has to take into account the worst-case drift.

Synchronisation methods described in this report are not exclusive and may be complementary and/or used as
a backup.
For example:
 In case of a localised GNSS jamming, an alternate IEEE-1588v2 path may allow to transport a remote
backup clock if properly engineered that way. Some protection scenarios are described in ITU-T
G.8275.
 ECC REPORT 216 - Page 19

 Despite being focused on frequency synchronisation, SyncE may help to discipline the local oscillator
so that it drifts more slowly in case the reference time clock is lost (this is taken into account in G.8271).
 G.8275.1 defines resiliency features (e.g. to reselect a new master clock in case the primary master
clock fails).

2.3 FRAME STRUCTURE COORDINATION

2.3.1 Overview
Having a common reference phase/time clock is not enough to avoid interference between networks. Since
TDD allows flexibility in the frame length and uplink/downlink ratio, it is necessary to properly align UL/DL
switching points so that the last transmitter stops before the first receiver starts, taking into account the
propagation delay (frame structure do not need to be exactly identical provided this condition is met). In TDD
networks, the frame configuration (i.e. frame length and uplink/downlink ratio) can be set as software
parameters. Therefore cross-operator synchronisation implies agreeing on proper common parameters.

It should be noted that agreement on a common frame structure decreases the flexibility of TDD (e.g. with
respect to the choice of the ratio), maybe leading to some suboptimal parameters at the individual level for each
operator. However synchronised operation also allows saving some spectrum that would otherwise have to be
used in restricted blocks or guard bands, and also makes it unnecessary to implement additional filtering.
Therefore the benefits and drawbacks of synchronised operation have to be balanced taking into account the
waste of spectrum and extra filtering costs in the case of unsynchronised networks. Also, the common TDD ratio
is not restricted to 50:50 but may be a compromise between the needs of the various involved operators, which
may be updated later in time.

2.3.2 Cross-technology network synchronisation

Configuring compatible frame structures is technically straightforward when the base stations use the same
technology. When they use a different technology, the feasibility of synchronisation requires a case-by-case
analysis. This section will assess WiMAX/TD-LTE cross-technology synchronisation as these two technologies
are the two main candidates for MFCN within several TDD bands and there is therefore a possibility that they
are deployed in adjacent channels in the same band.

Based on the current state of the specification exposed in Annex 1, it can be shown that most WiMAX 802.16e
configurations have at least one equivalent TD-LTE set of parameters, giving options for synchronising two
networks implementing different technologies.

Some limitations exist however: current WiMAX Forum profiles only support 5ms frame length and TDD ratios
above 50% for downlink. This study focuses on currently available technologies, therefore only LTE up-down
configurations #1 and #2 are applicable for coexistence with WiMAX [1]. The following table summarises which
LTE frame type and "S" subframe configurations correspond to each WiMAX configurations (details and
calculations are in Annex 1):

Table 4: LTE-TDD equivalent parameters for existing WiMAX frame configurations

LTE frame LTE "S" possible

WiMAX configuration
configuration configurations
10MHz 35:12 2 0,1,5,6
10MHz 34:13 2 0,5
10MHz 33:14 2 0,5
10MHz 32:15 2 0,5
10MHz 31:16 2 0,5
10MHz 30:17 - No exact equivalent
10MHz 29:18 - No exact equivalent
10MHz 28:19 1 0-4
ECC REPORT 216 - Page 20

LTE frame LTE "S" possible

WiMAX configuration
configuration configurations
10MHz 27:20 1 0-8
10MHz 26:21 1 0-2,5-7
7MHz 24:9 2 0,5
7MHz 23:10 2 0,5
7MHz 22:11 2 0,5
7MHz 21:12 - No exact equivalent
7MHz 20:13 1 0-4
7MHz 19:14 1 0-8
7MHz 18:15 1 0-2,5-7
8.75MHz 30:12 2 0,5
8.75MHz 29:13 2 0,5
8.75MHz 28:14 2 0,5
8.75MHz 27:15 - No exact equivalent
8.75MHz 26:16 - No exact equivalent
8.75MHz 25:17 1 0-5
8.75MHz 24:18 1 0-3,5-8

In a few cases (e.g. WiMAX DL/UL ratio 29:18), no direct TD-LTE equivalent parameters exist. However, even
in those cases, only minimal overlap happens, and several technical solutions are applicable in order to solve
this. Taking the example of 29:18 WiMAX DL/UL ratio, the following approaches may be used:
 Blank-out the two last OFDM symbols in the WiMAX frame (making DL/UL ratio effectively 27:18), at the
expense of an 8% capacity loss on the WiMAX side. This can be done in several ways.
 Blank-out a part of the UpPTS field in the LTE “S” subframe. As this carries no payload and the system
can use other slots for RACH and SRS, there is nearly no loss of capacity, however it leads to a
relatively narrow “inter-technology guard period”. The picture below shows an example of such
configuration:

Figure 10: Frame alignment mechanism between WiMAX with 29:18 DL/UL ratio and LTE-TDD

This solution has been successfully implemented by Clearwire US as part of their WiMAX to LTE-TDD
transition.
 ECC REPORT 216 - Page 21

3 PRACTICAL GUIDANCE FOR INTER-OPERATOR DEPLOYMENTS

3.1 CLOCK SYNCHRONISATION

The following table summarizes and compares the assessed techniques for phase/time synchronisation:

Table 5: Summary of assessed techniques for various scenarios

GNSS Packet networks LTE OTA eLoran

Status Mature. G.8275.1 assumes full on- Available for Essentially used in
Implemented path timing support (i.e. all HeNB. Under maritime
in existing equipment between GM study for other navigation and
TDD networks. and slave must have type of cells and military contexts,
May dedicated hardware and scenarios but not yet used for
experience software support for IEEE- IMT
some outages 1588v2). Expected in 2014.
G.8275.2 will address
assisted partial on-path
timing support case (PTPv2
used to backup GNSS
failure). Under
specification.
G.8275.x: partial on-path
timing support. Not yet
defined
Cross- Yes Yes No, LTE-only Yes
technology (e.g.
WiMAX-LTE)
Works indoors Generally not, N/A (not based on RF Yes, up to 3 FFS. The signal is
although some technologies. Applicability HeNB-to-HeNB expected to have
improvements depends on network hops. good indoor
in chipset characteristics). Work and penetration.
Work-item
performance tests are still ongoing on However this has
ongoing for more
may make this indoor small cells scenarios not yet been tested
hops and for more
applicable on with low-cost low-
deployment
a case-by- footprint chipsets
scenarios
case basis and antennas
(which also require
further studies)
ECC REPORT 216 - Page 22

3.2 INTER-OPERATOR SYNCHRONISATION PRE-REQUISITES

In order to deploy synchronised TDD mobile networks in a multi-operator context (without guard bands),
agreement needs to be reached on:
 a common phase clock reference (e.g. UTC) and accuracy/performance constraints (e.g. +/- 1.5 µs),
either using their own equipment to provide the clock, or sharing the same phase/time clock
infrastructure;
6
 a compatible frame structure (including TDD UL/DL ratio) in order to avoid uplink/downlink overlapping ;
 a commitment not to interfere with each other as any synchronisation issue of one operator may impact
the network of the others (e.g. reliability of the reference clock and protection mechanism have to be
ensured and/or procedure when losing this reference clock has to be defined);
 the terms & conditions where cross-operator synchronisation must apply and/or may not be required
(e.g. geographical zones / isolated eNB. HeNB-only deployments…);
 how to update those parameters.

3.3 GENERAL CONSIDERATIONS ON INTER-OPERATOR AGREEMENTS

For different unpaired frequency bands, the least restrictive technical conditions (BEM, guard bands, etc.) have
been defined in different ECC reports, for example, the least restrictive technical conditions for the frequency
bands 3400-3600 MHz and 3600-3800 MHz are described in ECC Report 203 [19]. TDD network in a given
unpaired frequency band can be deployed following the least restrictive technical conditions described in the
corresponding ECC report.

Inter-operator TDD network synchronisation as described in this report allows deployment without guard bands
and to implement a relaxed BEM (Block Edge Mask) between synchronised equipment. However, it may also
introduce new operational constraints and additional costs. For instance, inter-operator synchronisation may
lead to a less flexible UL/DL ratio selection, resulting in suboptimal spectrum utilisation for an individual
operator.

As described above, for different network deployment scenarios (macrocell, microcell, picocell, femtocell), some
network synchronisation methods could be more appropriate than others. Therefore, technical and operational
aspects described in §3.2 need to be taken into account by concerned operators aiming to reach a common
bilateral/multilateral agreement.

It should be anticipated that inter-operator agreement may not be straightforward in some situations, for
example:

 Lack of mutual incentive: when eNB-eNB interference is dominant compared to UE-UE interference,
the operator who has more downlink may be interferer and the operator(s) who has less downlink are
interfered if no additional filtering is implemented to prevent blocking even if the interferer complies with
its block edge mask. The same issue happens with the operator that configures more uplink if UE-UE
interference is dominant. Unlike when interference is mutual, the interferer has little incentive to
compromise on parameters such as UL/DL ratio in those situations, and the negotiations to find an
agreement on a common UL/DL ratio may be biased.

 Unanimity required: operator-specific filters may be required to comply with unsynchronised operation
both on the transmitter and receiver. Avoiding such operator-specific filters may be desirable in order to
get economies of scale. However, this may require unanimity on synchronised operation as defined in
section 3.2.

6
If UE-UE interference can be considered negligible compared to eNB-eNB interferences and the start of frame is properly synchronised,
then the operator that has the smallest amount of downlink will not interfere with the other operator(s), and may therefore be considered as
having a “compatible” frame structure with those others operators. The same rationale applies to the operator that has the highest amount of
downlink if UE-UE interferences are dominant compared to eNB-eNB interferences.
 ECC REPORT 216 - Page 23

• Sustainability of the synchronised arrangement: when operators deploy synchronised networks

(e.g. avoiding operator-specific filters), challenging situations may occur if the synchronised operation is
disrupted at a later point in time (e.g. if a new operator deploys without agreeing on synchronised
operation) as the already deployed equipment from the former operator(s) may not be compliant with
unsynchronised operation (BEM and blocking requirements and regulation).

Inter-network synchronisation conditions can be discussed and agreed at the national level and implemented
nationwide or limited to a given area (regional) as appropriate.

Some inter-operator TDD network synchronisations have been implemented in various countries; examples are
given in Annex 3.
ECC REPORT 216 - Page 24

4 CONCLUSION

In this report synchronisation for TDD networks has been assessed as a solution to avoid UE-UE and BS-BS
interferences between networks in the same geographic area and represents a possible alternative solution to
the use of guard bands or extra filtering. Synchronised operation has been defined as a mode where no
simultaneous uplink and downlink occurs between any pairs of cells which may interfere with each other in the
same band. Two orthogonal topics have been discussed:
 reference phase clock (order of magnitude of 1µs);
 compatible frame configuration.

For the first topic, the usual GNSS-based phase/time synchronisation solution is generally used in existing TDD
deployments, which are mostly outdoor macrocells with one single operator per geographic zones. This report
addresses new scenarios where GNSS cannot always be used. Therefore other techniques have also been
assessed: IEEE-1588v2 on packet networks, over-the-air synchronisation and terrestrial networks (eLoran). The
following deployment scenarios can be addressed by existing or under development synchronisation
techniques:

 Outdoor cells: can be synchronised by all considered techniques, both for intra-network and cross-
operator network synchronisation. GNSS is generally the most used and mature solution for this
scenario. IEEE-1588v2 is considered as an alternative when GNSS is not usable or in order to avoid
implementing a GNSS receiver at each site. eLoran may be assessed as a complementary or backup
solution. Over-the-air synchronisation is not yet fully specified for non-HeNB scenarios but may be used
in a near future.
 Indoor micro/picocells: GNSS requires sky visibility and is mostly not usable in that context. IEEE-
1588v2 can be considered if full on-path support is available. It may be also usable when only partial on
path support is available, although studies and standardization are still ongoing, so performance cannot
yet be guaranteed. eLoran may be assessed as a complementary or backup solution. Over-the-air
synchronisation is not yet fully specified for this scenario but may be used in a near future.
 Indoor HeNB: Over-the-air "network listening" has been specified and evaluated in labs environment for
intra-network 1-hop HeNB synchronisation. The specifications allow HeNB-HeNB synchronisation up to
3 hops. Additional work is currently ongoing at 3GPP to extend this technique.

Nevertheless, further studies are still needed regarding:

 over-the-air synchronisation in a multi-operator context and/or with other types of cells than HeNB
and/or in HeNB-only scenarios;
 eLoran in a telecom context, especially for indoor uses with low-footprint antennas;
 partial on-path support for IEEE-1588v2, e.g. for small cell deployments with a GNSS receiver a few
hops away on an Ethernet LAN;
 potential use of other RF signals as a phase reference;
 behaviour and resilience of TDD technologies when imperfect synchronisation is implemented (e.g. due
to synchronisation error, or slightly different start of frame or frame structure), leading to a limited
interference zone in the frame.

Regarding frame structure configuration, it has been shown that most WiMAX configurations have at least an
equivalent LTE-TDD one (however the opposite is not true since LTE also allows for more uplink than downlink,
contrary to WiMAX except in some non-standard vendor-specific cases). Specific fine-tuning at the frame level
may be required in some cases (e.g. to align the 29:18 WiMAX configuration to the closest corresponding LTE-
TDD configuration).

When multiple operators deploy TDD networks on adjacent bands, inter-network synchronisation conditions can
be discussed and agreed at the national level and implemented nationwide or limited to a given area (regional)
as appropriate.
 ECC REPORT 216 - Page 25

ANNEX 1: WIMAX AND LTE-TDD FRAME STRUCTURES

This annex details the supported parameters in LTE and WiMAX specifications at the time of this writing.

4.1 3GPP LTE

TS 36.211 (§4.2) [16] defines the following frame structure for TDD-LTE (frame type 2).

One radio frame, Tf = 307200Ts = 10 ms

One half-frame, 153600Ts = 5 ms

One slot,
Tslot=15360Ts 30720Ts

Subframe #0 Subframe #2 Subframe #3 Subframe #4 Subframe #5 Subframe #7 Subframe #8 Subframe #9

One subframe,
30720Ts

DwPTS GP UpPTS DwPTS GP UpPTS

Figure 11: LTE-TDD frame structure

Each subframe has a 1ms length, and can be used in the 3 following modes: "D" (downlink), "U" (uplink) and "S"
(switching point). The LTE superframe supports the following configurations:

Table 6: LTE TDD uplink-downlink configurations

Downlink-to-Uplink
Uplink-downlink
Switch-point Subframe number %DL (min-max)
configuration
periodicity
0 1 2 3 4 5 6 7 8 9
#0 5 ms D S U U U D S U U U 24% - 37%
#1 5 ms D S U U D D S U U D 44% - 57%
#2 5 ms D S U D D D S U D D 64% - 77%
#3 10 ms D S U U U D D D D D 62% - 69%
#4 10 ms D S U U D D D D D D 72% - 79%
#5 10 ms D S U D D D D D D D 82% - 89%
#6 5 ms D S U U U D S U U D 34% - 47%

The "S" subframe itself is made of 3 parts: DwPTS (downlink pilot and data timeslot), GP (guard period) and
UpPTS (uplink pilot timeslot). The following configurations are defined for this "S" subframe (where Ts = 32.55
ns):
ECC REPORT 216 - Page 26

Table 7: LTE-TDD "S" subframe configurations (values are in number of Ts)

Normal cyclic prefix in downlink Extended cyclic prefix in downlink

Special UpPTS UpPTS
subframe Normal Extended
DwPTS DwPTS Normal cyclic Extended cyclic
configuration cyclic prefix cyclic prefix
prefix in uplink prefix in uplink
in uplink in uplink
#0 6592 7680
#1 19760 20480
2192 2560
#2 21952 2192 2560 23040
#3 24144 25600
#4 26336 7680
#5 6592 20480 4384 5120
#6 19760 23040
4384 5120
#7 21952 - - -
#8 24144 - - -

4.2 WIMAX 802.16E

In WiMAX 802.16e (as defined in the WiMAX Forum System Profiles [4, 5], based on [17]), the frame length is
always 5ms. The TTG/RTG must be above 5µs, but the current WiMAX Forum profiles define a fixed value of
60µs for the RTG (or 74.4µs for the 8.75 MHz channel size). The TTG is taking the remaining part of the frame
(which allows a cell radius of ~8km for the 5 MHz and 10 MHz channel size, and ~16km for the 3.5 MHz and
7 MHz channel size. If it is required, it is still possible to blank some OFDM symbols in order to increase the TTG
to allow a greater cell radius).

Figure 12: IEEE-802.16e (WiMAX) frame structure (figure 8-46 in [1])

 ECC REPORT 216 - Page 27

Table 8: WiMAX 802.16e parameters

BW 10 MHz 7 MHz 5 MHz 3.5 MHz 8.75 MHz

Min TDD ratio (DL:UL) 35:12 24:09 35:12 24:09 30:12
Max TDD ratio (DL:UL) 26:21 18:15 26:21 18:15 24:18
Sampling factor 1.12 1.142857143 1.12 1.142857143 1.142857143
FFT size 1024 1024 512 512 1024
Fs (sampling frequency) 11200000 8000000 5600000 4000000 10000000
Carrier spacing (Hz) 10937.5 7812.5 10937.5 7812.5 9765.625
Useful OFDM symbol length (µs) 91.4 128 91.4 128 102.4
Cyclic prefix length (µs) 11.4 16 11.4 16 12.8
Total OFDM symbol length (µs) 102.8 144 102.8 144 115.2
Useful OFDM symbols / frame 47 33 47 33 42
RTG 60µs 60µs 60µs 60µs 74.4µs
TTG 105.7µs 188µs 105.7µs 188µs 87.2µs

4.3 WIMAX/LTE-TDD COMPATIBILITY MATRIX

The next table shows the gap/overlap between the WiMAX and the LTE-TDD frame. "Ratio" shows how much
downlink there is in % of the total 5ms frame. "DL_length", "UL_length" and "UL_start" are in µs, as well as the
other values, which are computed with the following formula:

Overlap == min( (wimax_ul_start-lte_dl_length), (lte_ul_start-wimax_dl_length) )

When this computation is positive (green values), it means there is no overlap, and the extra time is similar to a
guard period. On the other hand, scenarios where only negative values (red values) appear in the corresponding
line (or column) means that the standards do not allow straightforward cross-technology synchronisation as there
is no exact compatible frame structure between the two technologies without using some specific technical
measures (like offsetting start of frame, or blanking out some OFDM symbols, as described in section §2.3).

In order to be compatible, the amount of time in the gap should not only be positive, but also leave enough time
for TX ramp-up/ramp-down (17µs in the case of LTE-TDD. Yellow values in the table are positive values which
are below this 17µs duration).

N.B. in order to practically implement WiMAX-LTE cross-technology synchronisation and considering the frame
structures of the two technologies, it is necessary to specify an offset (e.g. if the WiMAX frame is aligned on
multiple of 1s+k*5ms boundaries, then the neighbour TD-LTE network has to align its frame on 1s+1ms+k*5ms
boundaries when using type 1 configuration or 1s+2ms+k*5ms boundaries when using configuration type 2).

N.B. WiMAX 5 MHz uses the same timing as 10 MHz, and WiMAX 3.5 MHz uses the same timings as 7 MHz.
 ECC REPORT 216 - Page 28

Table 7: 802.16e/LTE-TDD coexistence

LTE U-D conf 1 2

"S" frame 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8

Ratio 44,3% 52,9% 54,3% 55,7% 57,1% 44,3% 52,9% 54,3% 55,7% 64,3% 72,9% 74,3% 75,7% 77,1% 64,3% 72,9% 74,3% 75,7%
DL length 2215 2643 2715 2786 2857 2215 2643 2715 2786 3215 3643 3715 3786 3857 3215 3643 3715 3786
TTG / GP 714 285 214 143 71 643 214 143 71 714 285 214 143 71 643 214 143 71
UL length 2071 2071 2071 2071 2071 2143 2143 2143 2143 1071 1071 1071 1071 1071 1143 1143 1143 1143
UL start 2929 2929 2929 2929 2929 2857 2857 2857 2857 3929 3929 3929 3929 3929 3857 3857 3857 3857
Conf WiMAX
10MHz 35:12 74,5% 3600 106 1234 3706 -671 -671 -671 -671 -671 -743 -743 -743 -743 329 62 -9 -80 -152 257 62 -9 -80
10MHz 34:13 72,3% 3497 106 1337 3603 -568 -568 -568 -568 -568 -640 -640 -640 -640 388 -40 -112 -183 -254 360 -40 -112 -183
10MHz 33:14 70,2% 3394 106 1440 3500 -466 -466 -466 -466 -466 -537 -537 -537 -537 285 -143 -215 -286 -357 285 -143 -215 -286
10MHz 32:15 68,1% 3291 106 1543 3397 -363 -363 -363 -363 -363 -434 -434 -434 -434 183 -246 -317 -389 -460 183 -246 -317 -389
10MHz 31:16 66,0% 3189 106 1646 3294 -260 -260 -260 -260 -260 -331 -331 -331 -331 80 -349 -420 -492 -563 80 -349 -420 -492
10MHz 30:17 63,8% 3086 106 1749 3191 -157 -157 -157 -157 -157 -228 -228 -228 -228 -23 -452 -523 -595 -666 -23 -452 -523 -595
10MHz 29:18 61,7% 2983 106 1851 3089 -54 -54 -54 -54 -54 -126 -126 -126 -126 -126 -555 -626 -697 -769 -126 -555 -626 -697
10MHz 28:19 59,6% 2880 106 1954 2986 49 49 49 49 49 -23 -23 -23 -23 -229 -658 -729 -800 -872 -229 -658 -729 -800
10MHz 27:20 57,4% 2777 106 2057 2883 152 152 152 97 26 80 80 80 80 -332 -760 -832 -903 -974 -332 -760 -832 -903
10MHz 26:21 55,3% 2674 106 2160 2780 254 137 65 -6 -77 183 137 65 -6 -435 -863 -935 -1006 -1077 -435 -863 -935 -1006
8,75MHz 30:12 71,4% 3456 87 1382 3543 -527 -527 -527 -527 -527 -599 -599 -599 -599 329 -100 -171 -243 -314 329 -100 -171 -243
8,75MHz 29:13 69,0% 3341 87 1498 3428 -412 -412 -412 -412 -412 -484 -484 -484 -484 213 -215 -287 -358 -429 213 -215 -287 -358
8,75MHz 28:14 66,7% 3226 87 1613 3313 -297 -297 -297 -297 -297 -368 -368 -368 -368 98 -330 -402 -473 -544 98 -330 -402 -473
8,75MHz 27:15 64,3% 3110 87 1728 3198 -182 -182 -182 -182 -182 -253 -253 -253 -253 -17 -446 -517 -588 -660 -17 -446 -517 -588
8,75MHz 26:16 61,9% 2995 87 1843 3082 -67 -67 -67 -67 -67 -138 -138 -138 -138 -132 -561 -632 -704 -775 -132 -561 -632 -704
8,75MHz 25:17 59,5% 2880 87 1958 2967 49 49 49 49 49 -23 -23 -23 -23 -247 -676 -747 -819 -890 -247 -676 -747 -819
8,75MHz 24:18 57,1% 2765 87 2074 2852 164 164 137 66 -5 92 92 92 66 -363 -791 -863 -934 -1005 -363 -791 -863 -934
7MHz 24:9 72,7% 3456 188 1296 3644 -527 -527 -527 -527 -527 -599 -599 -599 -599 429 1 -71 -142 -213 401 1 -71 -142
7MHz 23:10 69,7% 3312 188 1440 3500 -383 -383 -383 -383 -383 -455 -455 -455 -455 285 -143 -215 -286 -357 285 -143 -215 -286
7MHz 22:11 66,7% 3168 188 1584 3356 -239 -239 -239 -239 -239 -311 -311 -311 -311 141 -287 -359 -430 -501 141 -287 -359 -430
7MHz 21:12 63,6% 3024 188 1728 3212 -95 -95 -95 -95 -95 -167 -167 -167 -167 -3 -431 -503 -574 -645 -3 -431 -503 -574
7MHz 20:13 60,6% 2880 188 1872 3068 49 49 49 49 49 -23 -23 -23 -23 -147 -575 -647 -718 -789 -147 -575 -647 -718
7MHz 19:14 57,6% 2736 188 2016 2924 193 193 193 138 67 121 121 121 121 -291 -719 -791 -862 -933 -291 -719 -791 -862
7MHz 18:15 54,5% 2592 188 2160 2780 337 137 65 -6 -77 265 137 65 -6 -435 -863 -935 -1006 -1077 -435 -863 -935 -1006
 ECC REPORT 216 - Page 29

ANNEX 2: ITU-T SG15/Q13 STANDARDS AND WORKPLAN

7
Figure 13 : Frequency, phase and time synchronisation profiles from ITU-T SG15/Q13

7
This figure is only given for information and is only valid at the time of writing. It is likely to evolve to reflect ITU-T on-going work.
ECC REPORT 216 - Page 30

ANNEX 3: EXISTING EXAMPLES OF CROSS-OPERATOR TDD SYNCHRONISATION

Successful inter-operator synchronisation deployments have already been implemented. As an example:

 In China, both 2.6GHz (3GPP band 41) and 2.3GHz band have been allocated for multiple operators
in December 2013, e.g. 2.6GHz band for China Mobile (CMCC), China Unicom(CU) and China
Telecom(CT), and 2.3GHz band for CMCC and CU with adjacent channels. Full Synchronisation is
mandatory between multiple operators within the same band and no guard band is reserved. It is
agreed under the RRB (Radio Regulatory Bureau) coordination that the exact synchronisation
configurations should be applied among operators, including coordination on frame starting time,
UL/DL configuration and special sub frame configuration. Moreover, it also set a rule to coordinate
the unsynchronised interference caused by out of sync.
 In Italy [15] , “In both Linkem and Aria network each single Base Station is synchronised by GPS
that, according to WiMAX Forum specification, receives 1pps (one pulse per second) with precision
of 2ppm. The Base Station’s GPS board generates 1µs clock to synchronise the frames. Both the
networks use 32:15 downlink/uplink ratio that reflects the current traffic profile of broadband internet
access services. This ratio will allow full compatibility with LTE TDD 10 ms frame configuration type
2 ensuring no loss of capacity. The plan is to set GAP at 63.05 µs which can provide 19 km safe
distance. It means that 2 Base Stations at 19 km, potentially mutually interfered, will be still
synchronised. This best practice is in place since middle 2011 without evidence of interferences or
service degradation”
 From ECC PT1(11)103: “In the Asia Pacific region Malaysian operators in the 2300MHz band
operate synchronised TDD systems (frame timing and DL/UL transmission) in unpaired blocks
through a voluntarily agreed cooperation agreement. The agreed DL/UL ratio is 29:18 but there is a
possibility to agree alternative ratios. Internationally, the 29:18 DL/UL ratio is a very common and
popular ratio for the uplink and downlink sub-frames in TDD mode.”
 In Japan, according to the operator Softbank: PHS is using 3GPP band #39 (1880-1920). Three
operators (DDI-P, NTT-P, ASTEL) share the frequency. So, there are no guard bands between
operators. PHS requires one dedicated Control Carrier for each operator, but share all the traffic CH.
among operators and also unlicensed PHS devices. PHS has a fixed 1:1 uplink-downlink ratio, so
there was no discussion regarding this area.
 The KT/SKT synchronisation on their TDD WiBRO 802.16e network is another example of inter-
operator agreement on all aspects discussed in this report – including UL/DL ratio. According to
Korea Telecom: “For the decision of TDD ratio, Operators made a task force including KCC (Korea
Communications Commission, government organization). Through the result of operators
harmonization, government made a regulation for the TDD ratio”.

Figure 14: Band plan for WiBRO in Korea

 ECC REPORT 216 - Page 31

ANNEX 4: LIST OF REFERENCES

[1] WiMAX Forum, Service Recommendations to Support Technology Neutral Allocations, FDD/TDD
Coexistence, 10 April 2007
[2] 3GPP TS 36.133, V12.2.0 (2013-12), Evolved Universal Terrestrial Radio Access (E-UTRA);
Requirements for support of radio resource management; (Release 12), §7.4
[3] 3GPP TSG-RAN WG4 #48, document R4-081908 “Analysis on Cell synchronization accuracy
requirement” by CATT
[4] David L. Mills, The Network Time Protocol (NTP) project (Network Time Foundation)
[5] Mike Gilson, Sebastien Jobert, Michael Mayer, Laurent Montini, Michel Ouellette, Silvana Rodrigues,
Stefano Ruffini Jean-Loup Ferrant, Synchronous Ethernet and IEEE 1588 in Telecoms: Next Generation
Synchronization Networks
[6] Kishan Shenoi, Synchronisation and Timing in Telecommunications
[7] John C. Eidson, Measurement, Control, and Communication Using IEEE 1588
[8] Small Cell Forum, Release Three, Synchronisation for LTE Small cells
[9] 3GPP TS 36.922, V9.1.0 (2010-06), Evolved Universal Terrestrial Radio Access (E-UTRA); TDD Home
eNode B (HeNB); Radio Frequency (RF) requirements analysis; (Release 9)
[10] 3GPP TS 36.413, V11.0.0 (2012-06), Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
S1 Application Protocol (S1AP) (Release 11), §9.2.3.34
[11] Global TD-LTE Initiative (GTI), GTI White Paper on TDD Synchronization, 2013-09-13
[12] International Loran Association, web-materials
[13] Chronos Technology Ltd. Long Term Time & Timing Trials with eLoran
[14] International Loran Association, The Enhanced Loran (eLoran)
[15] Linkem, Aria, Issues relevant to a preferred frequency arrangement for the 3.4-3.6 GHz band - Italy,
Best Practice on Synchronization for 3.4-3.6 GHz band, document ECC PT1(13)043 Annex 3.6 to ECC
PT1#43 meeting, 2-3 May 2013, Berlin, Germany
[16] 3GPP TS 36.211, Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and
Modulation (Release 9)
[17] IEEE. 802.16 Local and Metropolitan Area Network Standards
[18] Small Cell Forum, Release Three, SCFXXX documents
[19] ECC Report 203, Least Restrictive Technical Conditions suitable for Mobile/Fixed Communication
Networks (MFCN), including IMT, in the frequency bands 3400-3600 MHz and 3600-3800 MHz
[20] Symmetricom, Document WD45 “Time Holdover for Unassisted Oscillators”, ITU-T, Q13/SG15, WP3,
meeting 9-13 December 2013, Copenhagen
[21] ITU-T Recommendation G.8265.1 Precision time protocol telecom profile for frequency synchronization.