Draft ECC REPORT xxx

Electronic Communications Committee (ECC)

within the European Conference of Postal and Telecommunications Administrations (CEPT)

DRAFT ECC REPORT xxx

[Practical guidance for the TDD networks synchronizationCoexistence between adjacent TDD networks]

Place, Month, Year

DRAFT ECC REPORT xxx
Page 2

0 EXECUTIVE SUMMARY

The purpose of the report is to address the synchronization issue for TDD networks for all frequency bands.
Results of the report.

It may also contain a table of assumptions and a table of conclusions in the compatibility/sharing reports.
 DRAFT ECC REPORT xxx
Page 3

Table of contents

0 EXECUTIVE SUMMARY................................................................................................................................................2
LIST OF ABBREVIATIONS..................................................................................................................................................4
1 INTRODUCTION............................................................................................................................................................5
2 SYNCHRONISATION OF NETWORKS.....................................................................................................................6
2.1 SAME TECHNOLOGY NETWORK SYNCHRONISATION...................................................................................................6
2.1.1 Synchronisation of the start of frame.................................................................................................................6
2.1.1.1 Synchronisation by GPS................................................................................................................................................6
2.1.1.2 Synchronisation over IP.................................................................................................................................................6
2.1.1.3 Synchronisation by network listening............................................................................................................................7
2.1.1.4 conclusion...................................................................................................................................................................... 7
2.1.2 Frame structure synchronisation.......................................................................................................................8
2.1.2.1 Common downlink uplink ratios....................................................................................................................................8
2.2 CROSS-TECHNOLOGY NETWORK SYNCHRONISATION.................................................................................................8
2.2.1 Synchronisation of the start of frame.................................................................................................................8
2.2.2 Analysis of the frame structure..........................................................................................................................8
3 OTHER MITIGATION TECHNIQUES FOR UNSYNCHRONIZED NETWORKS..............................................8
3.1 ADDITIONAL FILTERING..............................................................................................................................................8
3.2 SITE COORDINATION...................................................................................................................................................9
3.3 RESTRICTED BLOCKS / GUARD BANDS.......................................................................................................................9
3.3.1 Case of BS to BS interference............................................................................................................................9
3.3.2 Case of TS to TS interference.............................................................................................................................9
4 CONCLUSIONS..............................................................................................................................................................9
ANNEX 1: TITLE..................................................................................................................................................................10
ANNEX 2: REFERENCES....................................................................................................................................................11
ANNEX 3: LIST OF REFERENCES......................................................................................................................................12

Note: Explanation on how to set-up the table of contents:

Use « formal » table of contents (in “Index” scroll down in the list of format / in “Table of Contents” select “formal”)
DRAFT ECC REPORT xxx
Page 4

LIST OF ABBREVIATIONS

Abbreviation Explanation
BS Base station
CEPT European Conference of Postal and Telecommunications
Administrations
TS Wimax Terminal station
UE LTE User Equipment
HeNB Home eNodeB (equivalent to “femtocell”)
 DRAFT ECC REPORT xxx
Page 5

Heading text from front page bold and small letters in here !

1 INTRODUCTION

[Following the approval of ECC DEC(11)HH on … a few open issues were left for study: considering dd

There are several possible techniques for improving coexistence between TDD networks
- synchronisation
- additional filtering
- site coordination
- restricted blocks/guard bands.
The aim of this report is of providing [technical guidance for methods] an evaluation of the techniques that facilitate the
coexistence of TDD networks. The use of restricted blocks/guard bands is obviously a method which leads to spectrum
wastage and is therefore a last resort method.

The candidate MFCN technologies for the 3.5 GHz bands are LTE and WiMAX.]
DRAFT ECC REPORT xxx
Page 6

2 SYNCHRONISATION OF NETWORKS

["Synchronization" means that the two neighbour operators have to transmit and receive in the same time. Thus, more
precisely, this means :
 Synchronizing the beginning of the frame
 Synchronizing the length of the frame
 Synchronizing the TDD uplink/downlink ratio

The main advantage of synchronisation of different networks is to minimise inter-operator guard frequencies.
There are three synchronisation levels: synchronisation within a network, synchronisation of adjacent band networks using
the same technology and synchronisation of adjacent band networks using different technologies (i.e. TD-LTE and
WiMAX). Synchronisation within a network is fully included within standardisation. The other cases of synchronisation are
the object of the analysis below.]

2.1 Introduction

When more than one TDD system operate in the same band (e.g. on adjacent channels) and are deployed in the same
geographic areas (towers, sites), severe interferences may happen if the networks are uncoordinated i.e. if some base
stations (BSs) are transmitting while others are receiving, since out-of-band and spurious emissions from the transmitter
will prevent the neighbour receiver to properly operate. One way to avoid this issue is to synchronize neighbour BSs in
order to make them transmit and receive in the same time. It shall be noted that the word “synchronization” can be
confusing since it is used in many different contexts with different meanings. For example, BS-UE synchronization is fully
included within standardization and is not the scope of this document. Also, the ITU-T SG15/Q13 distinguishes frequency
synchronization, phase synchronization and time synchronization, as illustrated in the following figure :

3GPP has defined "synchronized operation" [15] as "Operation of TDD in two different systems, where no simultaneous
uplink and downlink occur", which means that the neighbour BSs have to transmit and receive in the same time. Thus,
more precisely, this means:
 Synchronizing the beginning of the frame (phase synchronization)
 Synchronizing the frame structure, i.e. configure the length of the frame and the TDD uplink/downlink ratio so
that all transmitters stop transmitting before any other starts receiving (the frame length and TDD ratio do not need
to be exactly identical provided this condition is met)

This problem can be splited in the following cases

 synchronisation within a network
 synchronisation of adjacent band networks using the same technology
 synchronisation of adjacent band networks using different technologies (i.e. TD-LTE and WiMAX).

At the time of this writing, most IMT technologies have a requirement of 50ppb in frequency accuracy. When phase
synchronization is required, it is often on the order of 1µs, as illustrated in the following table.
 DRAFT ECC REPORT xxx
Page 7

Technology Phase/time accuracy

CDMA2000 3µs
WCDMA TDD (TS 25.402) 2.5 µs
TD-SCDMA (TS 25.836) 3µs
LTE TDD (TS 36.133) 3µs (small cells), 10µs (large cells)
MBSFN over LTE (TDD or FDD) 1µs
CoMP over LTE (TDD or FDD) TBD. Likely under 1µs
WiMAX 802.16e TDD 1µs
The following sections explain the technical possibilities (current and in development) for synchronising networks.]

2.2 Same technology network Synchronisation

[Same technology networks synchronisation is within the domain of standardisation. It appears that for both technology
LTE and WiMAX it is possible to synchronise networks in adjacent bands that use the same technology. In the case of
WiMAX there is an actual example of synchronisation as described in document ECC PT1(11)103 (see paragraph below,
assuming the networks were using WiMAX). In the case of LTE, 3GPP RAN4 gave the following indication in an liaison
statement to ECC PT1 (see document ECC PT1(11)077): “for the LTE TDD BS, the 3GPP requirements are defined
assuming synchronisation between blocks assigned to operators”. We can infer from this statement that it is technically
possible to synchronise network of different operators using TD-LTE.

From ECC PT1(11)103: “In the Asia Pacific region Malaysian operators in the 2300MHz band operate synchronised TDD
systems (frame timing and UL/DL 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.”

The following sections explain the technical possibilities (current and in development) for synchronising networks.]

2.2.1 Synchronisation of the start of frame

[There are several methods for synchronisation of the start of frame. According to document ECC PT1(11)117, 3GPP has
mostly identified three mechanisms: GPS (suitable for macro/microcells), IEEE1588v2 (i.e. over (IP)), and "network
listening".

Below three methods for network synchronisation are described.]

0.1.1.1 Synchronisation by GPS

[Synchronisation by GPS is suitable for base stations that have an outdoor component and therefore can receive a GPS
signal. Macro-cell outdoor BS should then be able to be synchronised by GPS, and this method is widely used for most
existing outdoor TDD networks like WiMAX and TD-SCDMA networks, as well as CDMA2000 networks.. However this
method of synchronisation would fail in the case of indoor BS which is often the case for femtocell BS, although some
advances from GPS chipset sensitivity suggest this limitation could be overcomed in a close future. ]

0.1.1.2 Synchronisation over backhaul network IP

Several techniques have been designed in the past in order to ensure synchronization over backhaul networks. ITU-T
SG15/Q13 deals with this topic, and has specified several standards over the past years for frequency synchronization (e.g.
based on SDH and Synchronous Ethernet). The phase/time synchronization requirement is newer, and therefore there is still
ongoing work in Q13. Several SDOs are involved and work in this area:
[ “The Precision Time Protocol (PTP) (IEEE 1588) is a protocol used to synchronize clocks throughout a computer
network. On a local area network it achieves clock accuracy in the sub-microsecond range, making it suitable for
measurement and control systems. IEEE 1588 is designed to fill a niche not well served by either of the two dominant
protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP.
DRAFT ECC REPORT xxx
Page 8

It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are
inaccessible.” [Wikipedia]
- IEEE has specified the IEEE-1588v2 standard. It is a complex standard with many features because it targets
several domains with very different needs (e.g. industry/robotics, telecommunications, etc.). The defined Precision
Time Protocol uses a similar approach to NTP (though it does not define an algorithm for clock recovering). It
defines several concepts like Boundary Clocks (BC) and Transparent Clocks (TC), but it does not define
requirements (e.g. limits for jitter) for specific applications like telecommunications. The protocol might be
implemented directly over Ethernet, or over IPv4 or IPv6.
- Some profiles have been specified by industry groups, and care about selecting subsets of the whole IEEE-1588v2
standard, and defining something consistent. They can also add requirements (e.g. unicast packets instead of
multicast). For telecommunications, ITU-T SG15/Q13 decided to use the IEEE-1588 protocol for the transport of
frequency and time; it has developed a series of recommendations for the transport of the frequency (G.826x) and
is developing a new series for the transport of phase/time (G.827x), which rely on IEEE-1588v2 and synchronous
ethernet together in order to match the required accuracy.
- IETF Tictoc group is working on some other aspects, like security issues, and implementation over IPv4/IPv6.
-
3GPP is analysing the possibility to use the IEEE1588 protocol. However the utilisation is not without some limitations as
described in 3GPP document 36.922:
“Under good backhaul conditions (e.g. operator controlled fiber / Ethernet), IEEE 1588 v2 can provide sub-microsecond
level accuracy. However, such good backhaul conditions may not always be possible. In particular backhauls over cable
and DSL modems have significant jitter and delay variations. Note that the upstream packet delay δ1 is often not equal to
the downstream delay δ2 creating an error of (δ1 – δ2)/2. This resulting error may be up to many milliseconds, rendering
IEEE 1588v2 restricted for the application of TD-LTE synchronization.” [3GPP 36.922]

Limitations were highlighted in document ECC PT1(11)113: “New protocols like IEEE1588/PTPv2 (Precision Time
Protocol) are currently under study by ITU-T in order to provide accurate phase/time synchronisation, but this type of
solution is not fully mature today. Moreover, it will require new hardware support from the network (Boundary Clock,
Transparent Clock) to fight against Packet Delay Variation and network delay asymmetry in order to meet the stringent
phase/time requirements of TDD systems. In particular, standardisation work on a Second ITU-T PTPv2 telecom profile
phase/time-oriented (PTP "link-by-link") is only in the preliminary phase and there would be additional hardware costs
associated.”

The above elements show that work is ongoing for synchronisation over IP and that there is some uncertainty on the
applicability of this synchronisation techniques for TDD networks over legacy equipments and over ADSL networks. It
may be a key feature in a close future for newer networks in urban areas, especially considering the expected deployment
of features like CoMP which require very tight time synchronization.
.]
 DRAFT ECC REPORT xxx
Page 9

ITU-T Requirements for NGN Synchronization (SG15/Q13)

Definitions / G.8260: Definitions and terminology

for synchronization in packet networks
terminology

Frequency Time/phase
Basics G.8261 /Y.1361: Timing and synchronization G.8271 Time and phase synchronization
& aspects in packet networks (frequency) aspects in packet networks

Network G.8261.1: PDV Network Limits appli- G.8271.1

require- cable to Packet Based Methods Network Requirements
ments (frequency synchronization)) for time/phase

SyncE Network Jitter/Wander: G.8271.2

Included in G.8261 (may G.8261.2 for future) may be needed for future

G.8262/Y.1362: Timing characteristics G.8272: PRTC (Primary Reference

Clocks of a synchronous Ethernet equipment Time Clock) Timing characteristics
slave clock (frequency)

G.8263: Timing characteristics of G.8273 Packet Time/Phase Clocks:

Packet based Equipment (PEC) Framework and Clock basics

G.8273.1: Packet Master timing. Charact.

G.8273.2: T-BC timing. Charact

G.8273.x: T-TC timing. Characteristics

G.8273.y: T-TSC timing. Character

G.8264/Y.1364: Distribution of timing

Methods information through packet networks

G.8265: Architecture and requirements G.8275 G.pacmod-bis

for packet based frequency delivery Packet - architecture- for time/phase

G.8265.1: Precision time protocol G.8275.1

Profiles telecom profile for frequency PTP profile for time and phase
synchronization synchronization
G.8265.2 G.8275.2
PTP Telecom Profile #2 PTP profile ToD/phase #2

Supple- G Suppl. x: Simulation of

ments Transport of time over packet network

agreed ongoing Options

DRAFT ECC REPORT xxx
Page 10

0.1.1.3 Over-the-air sSynchronisation by network listening

[Network listening is presented in 3GPP document 36.922. It is described as a possible solution for synchronisation when
other solutions are not available: “Network listening is one essential practical scheme, as it works when GPS doesn't work
(e.g. indoors) and IEEE 1588v2 is not available”.
The principle of the technique is described in 3GPP 36.922 §6.4.2.1: “The technique in which a HeNB derives its timing
from a synchronized eNB or HeNB (which in turn may be GNSS-synchronized) is referred to here as "synchronization
using network listening." A HeNB that uses network listening (say HeNB1) may utilize a synchronization or reference
signal from another eNB (say sync eNB) to derive its timing. […]The HeNB may periodically track one or more signals
from the donor cell (e.g. Primary and Secondary Synchronization Signals, Common Reference Signal, Positioning
Reference Signal) to maintain its synchronization.”
This mechanism allows for a cell (slave) to become synchronized with another cell (master), and does not require a direct
connection to the GPS network. For example, the scheme allows for multi-hop femtocell-to-femtocell synchronization (up
to 3 hops, as defined in TS-36.413 §9.2.3.34 [13]). Obviously, it makes sense in the case that the master and slave BSs
operate in the same band using the same technology (though not necessary the exact same channel).
For the worst case of a femtocell-only deployment this method would fail, however this can be remedied by adding a
receiver that would get the time reference from a macro base station operating in another band (see ECC PT1(11)117). It is
also noted in ECC PT1(11)117 that “for that kind of scenario, it is questionable whether synchronization between operators
is even necessary, considering the expected average distance, probability of interference (i.e. two femtocells on adjacent
channel close to each others), wall penetration loss, etc”.

One can conclude that the “network listening” scheme enables a whole network, including femtocells BS, to be GNSS
synchronised (provided there is a reference macrocell network e.g. to a GNSS-synchronized reference macrocell network).
This could enable allows for the possibility of networks of different operators to be synchronised withto the same time
reference source.
At the time of this writing, this approach is restricted to the LTE technology. It has been successfully implemented and
tested for single-operator single-hop LTE femtocell synchronisation. For this reference implementation (which is not the
only possible mechanism), the slave HeNB uses a part of its dwPTS frame to listen to the master dwPTS frame and
properly adjust its clock. When the HeNB turns on, it listens to the neighbour cells first, then selects the cell with highest
level as synchronization reference in order to establish synchronization, and decide its own synchronization reference level
(1 level lower than reference cell). RAN4 endorses two schemes for indication of synchronisation level and status : blind
detection and backhaul signaling.
eNB HeNB
Need homo-
freq. band Capture
5ms frame
synch.
Capture
10ms frame
synch.
Femto1 Femto2

Macro TA measurement
timing correction
Synch
establish

Even though the solution allows for multi-hop synchronization, the number of hops should not be too high in order to avoid
accumulation of timing errors. 3GPP has defined 4 levels of precedence (0 is high and 3 is low), which allow up to 3 hops.
The timing accuracy of macro eNB is about 50~300ns, for total N hop synch. Over the air, single hop timing accuracy
should be within (3µs-300ns)/2N. For N=3, it means the single-hop accuracy must be less than 0.45µs. According to lab
tests, the synchronisation accuracy can be as low as 189ns, which shows the solution is technically feasible.

Question: is “network listening” included in WiMAX?

Question: These schemes have been designed for intra network synchronisation, but have they already been included in
standardisation dealing with inter network synchronisation (especially the synchronisation by network listening)? ]

0.1.1.4 [Other OTA mechanisms]Conclusion

[Since we only need phase synchronization between close BS rather than time synchronization, we need to explore the
general case of a separate receiver dedicated to synchronization in the slave BS, extracting and using the clock of another
 DRAFT ECC REPORT xxx
Page 11

reference RF signal in another band and another technology. For example, is it possible to get phase synchronization from
SCH in a surrounding GSM network ?]

2.2.2 Frame structure synchronisation

[Frame structure synchronisation means full synchronisation of networks. The base stations of adjacent band networks emit
at the same time and terminal stations also all emit at the same time. This implies a common uplink downlink ratio. As it is
technically clear that once the start of frame are synchronised there is no added technical difficulty for using the same
uplink/downlink ratio across different (same technology) networks, the only issue is one of choosing and agreeing upon a
common ratio.]
Synchronizing the start of the frame is not enough to avoid interference between networks: since TDD allows flexibility in
the frame length and uplink-downlink ratio, they will transmit and receive in the same time except: In TDD network, the
frame structure (i.e. frame length and uplink-downlink ratio) can be configured as software parameter. Therefore
“synchronizing” the frame structure means agreeing on common parameters.

0.1.1.5 Common downlink uplink ratios

[A common uplink downlink ratio can be either agreed by consensus between network operators or chosen by the regulator
after consultation of the network operators. This would probably imply the inclusion of some provision in the licences of
the different operators in the band which enable the regulator to mandate synchronisation when some conditions (e.g. lack
of agreement) are met.

Some operators have argued (see ECC PT1(11)113) that there would be different kind of traffic patterns due to different
applications and different usage behaviour of mobile broadband users. This would create difficulties in agreeing on a
common UL/DL ratio. Additional difficulties at the border of different countries could be expected if operators are expected
to agree on a common uplink downlink ratio.

It should be noted that agreement on a common UL/DL ratio would decreasecancel the flexibility of TDD with respect to
the choice of the ratio, maybe leading to some suboptimal ratio at the individual level for each operator. However thisThis
waste of capacity should be compared and put in the balance with the waste created by resctricted blocks/guard bands in the
case of unsynchronised networks. One can expect that the waste due to a suboptimal ratio would be less important?
Also, the common TDD ratio might still be more efficient than a 50:50 UL:DL ratio technologically enforced by non-TDD
duplexing schemes (e.g. choosing the average UL/DL ratio between ratios asked by each operator). Besides, this common
TDD ratio can always be further modified if the overall DL:UL ratio changes from the macroscopic point of view, and it is
always feasible to choose a common 50:50 ratio in case of no agreement.

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

 From ECC PT1(11)103: “In the Asia Pacific region Malaysian operators in the 2300MHz band operate
synchronised TDD systems (frame timing and UL/DL 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.”
 The KT/SKT synchronization on their TDD WiBRO 802.16e network is another example of inter-operator
agreement on all aspects discussed in this report – including DL/UL 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”.

Need to explore solutions for the case where there is no consensus among operators.]
DRAFT ECC REPORT xxx
Page 12

2.3 Cross-technology network sSynchronisation

Same technology frame structure synchronisation is within the domain of standardisation. It appears that for both
technology LTE and WiMAX it is possible to synchronise networks in adjacent bands that use the same technology. In the
case of WiMAX there is an actual example of synchronisation as described in document ECC PT1(11)103 (see paragraph
below, assuming the networks were using WiMAX). In the case of LTE, 3GPP RAN4 gave the following indication in an
liaison statement to ECC PT1 (see document ECC PT1(11)077): “for the LTE TDD BS, the 3GPP requirements are defined
assuming synchronisation between blocks assigned to operators”. We can infer from this statement that it is technically
possible to synchronise network of different operators using TD-LTE.

[LTE and WiMAX are the two candidate technologies for MFCN networks within the 3.5 GHz bands. There is therefore a
possibility that those two technologies be deployed inby adjacent band by different operatorsnetworks. They have different
frame structures and therefore the technical feasibility has been carefully studied in this section. , however similarities
could enable to achieve some level of synchronisation.]

2.3.1 Synchronisation of the start of frame

[Assuming each network is internally synchronised (using one of the techniques described in §2.1.1) then using a common
time reference (such as one provided by GNSS) should enable to synchronise both networks. The technical implementation
may create some difficulties but in theory it should be feasible.]

2.3.2 Analysis of the frame structure

[Detailed analysis of the overlap of TD-LTE/WiMAX UL and DL frames is needed.
Based on the current state of the specification exposed in annex [4], it can be shown that most WiMAX 802.16e
configurations have at least one equivalent TD-LTE set of parameters, giving options for synchronizing two networks
implementing different technologies

Some limitations exist however: current WiMAX Forum profiles only support 5ms frames length and TDD ratios above
than 50% downlink. This study focuses on currently available technologies, thus only LTE up-down configurations #1 and
#2 are applicable. The following spreadsheet shows how many % of the frame are overlapping (i.e. with WiMAX
transmitting while LTE is receiving, or LTE transmitting while WiMAX is receiving) for each WiMAX vs LTE TDD
configuration. The most desirable scenario is the fully synchronized one, which correspond to a "0%" overlap. Assessing
whether a limited (< 2% of the frame) overlap would be acceptable or would lead to severe interferences is beyond the
scope of this study, which will focus on prefect (0% overlap) cross-technology synchronization.

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 - Overlap 0,5%
10MHz 29:18 - Overlap 1,1%
10MHz 28:19 1 0-4
10MHz 27:20 1 0-8
10MHz 26:21 1 0-2,5-7
7MHz 24:9 2 0,1,5,6
7MHz 23:10 2 0,5
7MHz 22:11 2 0,5
7MHz 21:12 - Overlap 0,1%
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
 DRAFT ECC REPORT xxx
Page 13

8,75MHz 28:14 2 0,5

8,75MHz 27:15 - Overlap 0,3%
8,75MHz 26:16 - Overlap 1,3%
8,75MHz 25:17 1 0-5
8,75MHz 24:18 1 0-3,5-8

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 have the beginning of the frame
aligned on 1s+1ms+k*5ms boundaries when using type 1 configuration or 1s+2ms+k*5ms boundaries when using
configuration type 2).

In a few cases (e.g. WiMAX TDD ratio 29:18), no direct TD-LTE equivalent parameters exist. However, even in those
cases, only minimal overlap happens, so that several technical solutions are applicable in order to solve this. Taking the
example of 29:18 WiMAX ratio, the two following approaches are valid:
 Blank-out the two last OFDM symbols in the WiMAX frame (making it effectively 27:18), at the expense of a 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 and therefore less downsides compared to the
previous approach, except a relatively narrow “inter-technology TTG”. The picture below shows an example of
such configuration:

What are the consequences of near alignment (with remaining overlap) of the frame structures: what is the expected
capacity reduction? [On the Forum discussion a figure of 10% maximum was provided]]
[Ideally this scenario should be avoided. However, for an LTE victim network (i.e. downlink frame smaller than the
neighbour aggressor network), the preliminary study shows that only the data payload will suffer from interference
(proportionally to the percentage of frame overlap), and no control message should significantly suffer. Indeed, the uplink
control channels are the PUCCH, PRACH, SRS and control signaling transmitted with data on PUSCH. PUCCH always
span the entire TTI and is hence not severely impacted by additional interference in the first few OFDM symbols. PRACH
have a special format for TDD where it is placed in the switching subframe with a short duration, that could be severely
impacted by such interference, and Sounding Reference Signals can also be placed there and be jammed. But there is also
an option to configure them to occur in different subframes where they would be protected.]
[complete this information for a WiMAX victim network]

2.4 Conclusion

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

GPS Backhaul (IEEE1588v2) LTE OTA Other OTA

DRAFT ECC REPORT xxx
Page 14

Synchronisation Yes, mature Yes but not straightforward Yes FFS

within a network (depends on the backhaul
network). ITU-T Q13 phase/time
profile ongoing
Synchronisation FFS FFS (results expected
with another before Q4/2012)
operator, same
technology
Synchronisation No
with another
operator, other
technology
Valid for indoor Not yet (pending Case by case. Not yet for ADSL. Yes [Yes]
HeNB improvements in
sensitivity (FFS))

It has been shown that frame structure synchronization is feasible from the technical point of view, including in the cross-
technology scenario. Successful examples of inter-operator TDD network synchronization e.g. in Malaysia, Korea, and
Japan demonstrates the feasibility and the “real world” applicability of such approach.

3 OTHER MITIGATION TECHNIQUES FOR UNSYNCHRONIZED NETWORKS

[Unsynchronised TDD networks will suffer from BS to BS and TS to TS interference scenarios. ]

3.1 Additional filtering

[Additional filtering provides protection for BS in the case of unsynchronised networks.]

3.2 Site coordination

[Site coordination enables to limit BS to BS interference. This is achieved by removing the most stringent scenarios of BS
to BS interference where BS face each other and are in close proximity.
Derivation of gain compared to worst scenario needed.]

3.3 Restricted blocks / Guard bands

[In the case of unsynchronised adjacent band networks all kind of interference scenario may occur. The scenarios that are
not dealt with by standardisation are the BS to BS interference and the TS to TS interference.]

3.3.1 Case of BS to BS interference

[[ECC PT1(11)113] “Initial studies show that a minimum guard band of 10MHz between neighbouring base stations of two
different operators is required at the base station side in case of unsynchronised TDD inter-operators.”

Needs a detailed analysis with derivation of the [10 MHz] figure.]

3.3.2 Case of TS to TS interference

[It was noted on discussion on the ECO Forum that there is a trade of between TS to TS interference and guard bands.
Some noted that it is better for global network capacity to accept some TS to TS terminal interference while keeping
 DRAFT ECC REPORT xxx
Page 15

limited guard bands. It was also pointed out that the probability of terminals to be in close proximity must be taken into
account when assessing the loss of service due to TS to TS interference.
As for a quantitative analysis of UE/UE interference, document ECC PT1(11)113 has pointed to a Nokia contribution to
3GPP RAN4 (R4-111854) that analyses coexistence of TDD and FDD networks. ECC PT1(11)113 mentions a 25 MHz
guard band. This material could be of interest for TDD/TDD network coexistence.
There is a need for an evaluation of necessary guard band for UE/UE protection and of the trade off of less guard band for
more UE/UE interference.]

4 CONCLUSIONS

Conclusions…
DRAFT ECC REPORT xxx
Page 16

ANNEX 1: TITLE

[In case of multiple ANNEXES document, insert a section break at the end of an Annex, copy and past the title of this
ANNEX into a new ANNEX, the update of the numbering will be done automatically and change the title of the new
ANNEX. Then, when updating the Table of Contents, the reference to the new ANNEX will be added to the Table.]
 DRAFT ECC REPORT xxx
Page 17

ANNEX 2: REFERENCES

[1] http://www.3gpp.org/ftp/specs/archive/36_series/36.211/36211-910.zip
[2] http://standards.ieee.org/getieee802/download/802.16-2009.pdf
[3] http://www.wimaxforum.org/technology/downloads/Service_Recs_Tech_Neutrality_-_FDD-TDD_Coexistence.pdf
[4] http://wimaxforum.org/sites/wimaxforum.org/files/technical_document/2009/07/WMF-T23-007-R010v02_MSP-IMT-
2000.pdf
[5] http://wimaxforum.org/sites/wimaxforum.org/files/technical_document/2009/07/WMF-T23-002-R015v01_MSP-TDD.pdf
[6] http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCREP131.PDF
[7] http://www.3gpp.org/ftp/Specs/archive/36_series/36.922/36922-910.zip (§6.4), and TS 36.133 (§7.4)
[8] ECC PT1(11)103 WiMAX Forum
[9] ECC PT1(11)113 BYT-FT-TI
[10] ECC PT1(11)117 Bolloré T
[11] FORUM ECC PT1 SWGA
[12] http://www.3gpp.org/ftp/Specs/archive/36_series/36.828/36828-b00.zip
[13] http://www.3gpp.org/ftp/Specs/archive/36_series/36.413/36413-b00.zip (§9.2.3.34)
[14] http://www.itu.int/dms_pub/itu-t/oth/06/38/T06380000040006PPTE.ppt
[15] http://www.3gpp.org/ftp/Specs/archive/37_series/37.104/37104-b10.zip
[16] http://www.3gpp.org/ftp/Specs/archive/37_series/37.801/37801-a00.zip
DRAFT ECC REPORT xxx
Page 18

ANNEX 3: LIST OF REFERENCES

Contain the list of relevant documents.

NOTE: that this annex should always be the last in case of multi ANNEX document.

It will be used as basis when developing the list of related documents on the http://www.erodocdb.dk/.

ECC PT1(11)103
 DRAFT ECC REPORT xxx
Page 19

ANNEX 4: LTE AND WIMAX FRAME STRUCTURES

DRAFT ECC REPORT xxx
Page 20

LIST OF REFERENCES

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

4.1.1 3GPP LTE

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

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:

Uplink- Downlink-to-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) :

Special subframe Normal cyclic prefix in downlink Extended cyclic prefix in downlink
configuration DwPTS UpPTS DwPTS UpPTS
Normal Extended Normal cyclic Extended cyclic
cyclic prefix cyclic prefix prefix in uplink prefix in uplink
in uplink in uplink
0 6592  Ts 7680  Ts
1 19760  Ts 20480  Ts
2192  Ts 2560  Ts
2 21952  Ts 2192  Ts 2560  Ts 23040  Ts
3 24144  Ts 25600  Ts
4 26336  Ts 7680  Ts
5 6592  Ts 20480  Ts 4384  Ts 5120  Ts
6 19760  Ts 23040  Ts
4384  Ts 5120  Ts
7 21952  Ts - - -
8 24144  Ts - - -
 DRAFT ECC REPORT xxx
Page 21

4.1.2 WiMAX 802.16e

In WiMAX 802.16e (as defined in the WiMAX Forum System Profiles [4, 5], based on [2]), 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).

10 5 3.5 8.75
BW 7 MHz
MHz MHz MHz 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
1,142857 1,142857 1,142857
Sampling factor 1,12
143
1,12
143 143
FFT size 1024 1024 512 512 1024
112000 56000
Fs (sampling frequency) 00
8000000
00
4000000 10000000
10937, 10937,
Carrier spacing (Hz) 5
7812,5
5
7812,5 9765,625
Useful OFDM symbol
91,4 128 91,4 128 102,4
length (µs)
Cyclic prefix length (µs) 11,4 16 11,4 16 12,8
Total OFDM symbol
102,8 144 102,8 144 115,2
length (µs)
Useful OFDM symbols /
47 33 47 33 42
frame
RTG 60µs 60µs 60µs 60µs 74.4µs
105.7µ 105.7µ
TTG s
188µs
s
188µs 87.2µs
 DRAFT ECC REPORT xxx
Page 22
LTE U-D
1 2
config
"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 0,0022 0,0026 0,0027 0,0028 0,0029 0,0022 0,0026 0,0027 0,0028 0,0032 0,0036 0,0037 0,0038 0,0039 0,0032 0,0036 0,0037 0,0038
TTG / GP 0,0007 0,0003 0,0002 0,0001 7E-05 0,0006 0,0002 0,0001 7E-05 0,0007 0,0003 0,0002 0,0001 7E-05 0,0006 0,0002 0,0001 7E-05
UL length 0,0021 0,0021 0,0021 0,0021 0,0021 0,0021 0,0021 0,0021 0,0021 0,0011 0,0011 0,0011 0,0011 0,0011 0,0011 0,0011 0,0011 0,0011
UL start 0,0029 0,0029 0,0029 0,0029 0,0029 0,0029 0,0029 0,0029 0,0029 0,0039 0,0039 0,0039 0,0039 0,0039 0,0039 0,0039 0,0039 0,0039
Conf WiMAX Min
10MHz 35:12 74,5% 0,0036 0,0001057 0,0012343 0,0037057 13,4% 13,4% 13,4% 13,4% 13,4% 14,9% 14,9% 14,9% 14,9% 0,0% 0,0% 0,2% 1,6% 3,0% 0,0% 0,0% 0,2% 1,6% 0,0%
10MHz 34:13 72,3% 0,0034971 0,0001057 0,0013371 0,0036029 11,4% 11,4% 11,4% 11,4% 11,4% 12,8% 12,8% 12,8% 12,8% 0,0% 0,8% 2,2% 3,7% 5,1% 0,0% 0,8% 2,2% 3,7% 0,0%
10MHz 33:14 70,2% 0,0033943 0,0001057 0,00144 0,0035 9,3% 9,3% 9,3% 9,3% 9,3% 10,7% 10,7% 10,7% 10,7% 0,0% 2,9% 4,3% 5,7% 7,1% 0,0% 2,9% 4,3% 5,7% 0,0%
10MHz 32:15 68,1% 0,0032914 0,0001057 0,0015429 0,0033971 7,3% 7,3% 7,3% 7,3% 7,3% 8,7% 8,7% 8,7% 8,7% 0,0% 4,9% 6,3% 7,8% 9,2% 0,0% 4,9% 6,3% 7,8% 0,0%
10MHz 31:16 66,0% 0,0031886 0,0001057 0,0016457 0,0032943 5,2% 5,2% 5,2% 5,2% 5,2% 6,6% 6,6% 6,6% 6,6% 0,0% 7,0% 8,4% 9,8% 11,3% 0,0% 7,0% 8,4% 9,8% 0,0%
10MHz 30:17 63,8% 0,0030857 0,0001057 0,0017486 0,0031914 3,1% 3,1% 3,1% 3,1% 3,1% 4,6% 4,6% 4,6% 4,6% 0,5% 9,0% 10,5% 11,9% 13,3% 0,5% 9,0% 10,5% 11,9% 0,5%
10MHz 29:18 61,7% 0,0029829 0,0001057 0,0018514 0,0030886 1,1% 1,1% 1,1% 1,1% 1,1% 2,5% 2,5% 2,5% 2,5% 2,5% 11,1% 12,5% 13,9% 15,4% 2,5% 11,1% 12,5% 13,9% 1,1%
10MHz 28:19 59,6% 0,00288 0,0001057 0,0019543 0,0029857 0,0% 0,0% 0,0% 0,0% 0,0% 0,5% 0,5% 0,5% 0,5% 4,6% 13,2% 14,6% 16,0% 17,4% 4,6% 13,2% 14,6% 16,0% 0,0%
10MHz 27:20 57,4% 0,0027771 0,0001057 0,0020571 0,0028829 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 6,6% 15,2% 16,6% 18,1% 19,5% 6,6% 15,2% 16,6% 18,1% 0,0%
10MHz 26:21 55,3% 0,0026743 0,0001057 0,00216 0,00278 0,0% 0,0% 0,0% 0,1% 1,5% 0,0% 0,0% 0,0% 0,1% 8,7% 17,3% 18,7% 20,1% 21,5% 8,7% 17,3% 18,7% 20,1% 0,0%
7MHz 24:9 72,7% 0,003456 0,000188 0,001296 0,003644 10,5% 10,5% 10,5% 10,5% 10,5% 12,0% 12,0% 12,0% 12,0% 0,0% 0,0% 1,4% 2,8% 4,3% 0,0% 0,0% 1,4% 2,8% 0,0%
7MHz 23:10 69,7% 0,003312 0,000188 0,00144 0,0035 7,7% 7,7% 7,7% 7,7% 7,7% 9,1% 9,1% 9,1% 9,1% 0,0% 2,9% 4,3% 5,7% 7,1% 0,0% 2,9% 4,3% 5,7% 0,0%
7MHz 22:11 66,7% 0,003168 0,000188 0,001584 0,003356 4,8% 4,8% 4,8% 4,8% 4,8% 6,2% 6,2% 6,2% 6,2% 0,0% 5,7% 7,2% 8,6% 10,0% 0,0% 5,7% 7,2% 8,6% 0,0%
7MHz 21:12 63,6% 0,003024 0,000188 0,001728 0,003212 1,9% 1,9% 1,9% 1,9% 1,9% 3,3% 3,3% 3,3% 3,3% 0,1% 8,6% 10,1% 11,5% 12,9% 0,1% 8,6% 10,1% 11,5% 0,1%
7MHz 20:13 60,6% 0,00288 0,000188 0,001872 0,003068 0,0% 0,0% 0,0% 0,0% 0,0% 0,5% 0,5% 0,5% 0,5% 2,9% 11,5% 12,9% 14,4% 15,8% 2,9% 11,5% 12,9% 14,4% 0,0%
7MHz 19:14 57,6% 0,002736 0,000188 0,002016 0,002924 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 5,8% 14,4% 15,8% 17,2% 18,7% 5,8% 14,4% 15,8% 17,2% 0,0%
7MHz 18:15 54,5% 0,002592 0,000188 0,00216 0,00278 0,0% 0,0% 0,0% 0,1% 1,5% 0,0% 0,0% 0,0% 0,1% 8,7% 17,3% 18,7% 20,1% 21,5% 8,7% 17,3% 18,7% 20,1% 0,0%
5MHz 35:12 74,5% 0,0036 0,0001057 0,0012343 0,0037057 13,4% 13,4% 13,4% 13,4% 13,4% 14,9% 14,9% 14,9% 14,9% 0,0% 0,0% 0,2% 1,6% 3,0% 0,0% 0,0% 0,2% 1,6% 0,0%
5MHz 34:13 72,3% 0,0034971 0,0001057 0,0013371 0,0036029 11,4% 11,4% 11,4% 11,4% 11,4% 12,8% 12,8% 12,8% 12,8% 0,0% 0,8% 2,2% 3,7% 5,1% 0,0% 0,8% 2,2% 3,7% 0,0%
5MHz 33:14 70,2% 0,0033943 0,0001057 0,00144 0,0035 9,3% 9,3% 9,3% 9,3% 9,3% 10,7% 10,7% 10,7% 10,7% 0,0% 2,9% 4,3% 5,7% 7,1% 0,0% 2,9% 4,3% 5,7% 0,0%
5MHz 32:15 68,1% 0,0032914 0,0001057 0,0015429 0,0033971 7,3% 7,3% 7,3% 7,3% 7,3% 8,7% 8,7% 8,7% 8,7% 0,0% 4,9% 6,3% 7,8% 9,2% 0,0% 4,9% 6,3% 7,8% 0,0%
5MHz 31:16 66,0% 0,0031886 0,0001057 0,0016457 0,0032943 5,2% 5,2% 5,2% 5,2% 5,2% 6,6% 6,6% 6,6% 6,6% 0,0% 7,0% 8,4% 9,8% 11,3% 0,0% 7,0% 8,4% 9,8% 0,0%
5MHz 30:17 63,8% 0,0030857 0,0001057 0,0017486 0,0031914 3,1% 3,1% 3,1% 3,1% 3,1% 4,6% 4,6% 4,6% 4,6% 0,5% 9,0% 10,5% 11,9% 13,3% 0,5% 9,0% 10,5% 11,9% 0,5%
5MHz 29:18 61,7% 0,0029829 0,0001057 0,0018514 0,0030886 1,1% 1,1% 1,1% 1,1% 1,1% 2,5% 2,5% 2,5% 2,5% 2,5% 11,1% 12,5% 13,9% 15,4% 2,5% 11,1% 12,5% 13,9% 1,1%
5MHz 28:19 59,6% 0,00288 0,0001057 0,0019543 0,0029857 0,0% 0,0% 0,0% 0,0% 0,0% 0,5% 0,5% 0,5% 0,5% 4,6% 13,2% 14,6% 16,0% 17,4% 4,6% 13,2% 14,6% 16,0% 0,0%
5MHz 27:20 57,4% 0,0027771 0,0001057 0,0020571 0,0028829 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 6,6% 15,2% 16,6% 18,1% 19,5% 6,6% 15,2% 16,6% 18,1% 0,0%
5MHz 26:21 55,3% 0,0026743 0,0001057 0,00216 0,00278 0,0% 0,0% 0,0% 0,1% 1,5% 0,0% 0,0% 0,0% 0,1% 8,7% 17,3% 18,7% 20,1% 21,5% 8,7% 17,3% 18,7% 20,1% 0,0%
3,5MHz 24:9 72,7% 0,003456 0,000188 0,001296 0,003644 10,5% 10,5% 10,5% 10,5% 10,5% 12,0% 12,0% 12,0% 12,0% 0,0% 0,0% 1,4% 2,8% 4,3% 0,0% 0,0% 1,4% 2,8% 0,0%
3,5MHz 23:10 69,7% 0,003312 0,000188 0,00144 0,0035 7,7% 7,7% 7,7% 7,7% 7,7% 9,1% 9,1% 9,1% 9,1% 0,0% 2,9% 4,3% 5,7% 7,1% 0,0% 2,9% 4,3% 5,7% 0,0%
3,5MHz 22:11 66,7% 0,003168 0,000188 0,001584 0,003356 4,8% 4,8% 4,8% 4,8% 4,8% 6,2% 6,2% 6,2% 6,2% 0,0% 5,7% 7,2% 8,6% 10,0% 0,0% 5,7% 7,2% 8,6% 0,0%
3,5MHz 21:12 63,6% 0,003024 0,000188 0,001728 0,003212 1,9% 1,9% 1,9% 1,9% 1,9% 3,3% 3,3% 3,3% 3,3% 0,1% 8,6% 10,1% 11,5% 12,9% 0,1% 8,6% 10,1% 11,5% 0,1%
3,5MHz 20:13 60,6% 0,00288 0,000188 0,001872 0,003068 0,0% 0,0% 0,0% 0,0% 0,0% 0,5% 0,5% 0,5% 0,5% 2,9% 11,5% 12,9% 14,4% 15,8% 2,9% 11,5% 12,9% 14,4% 0,0%
3,5MHz 19:14 57,6% 0,002736 0,000188 0,002016 0,002924 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 5,8% 14,4% 15,8% 17,2% 18,7% 5,8% 14,4% 15,8% 17,2% 0,0%
3,5MHz 18:15 54,5% 0,002592 0,000188 0,00216 0,00278 0,0% 0,0% 0,0% 0,1% 1,5% 0,0% 0,0% 0,0% 0,1% 8,7% 17,3% 18,7% 20,1% 21,5% 8,7% 17,3% 18,7% 20,1% 0,0%
8,75MHz 30:12 71,4% 0,003456 8,72E-05 0,0013824 0,0035432 10,5% 10,5% 10,5% 10,5% 10,5% 12,0% 12,0% 12,0% 12,0% 0,0% 2,0% 3,4% 4,9% 6,3% 0,0% 2,0% 3,4% 4,9% 0,0%
8,75MHz 29:13 69,0% 0,0033408 8,72E-05 0,0014976 0,003428 8,2% 8,2% 8,2% 8,2% 8,2% 9,7% 9,7% 9,7% 9,7% 0,0% 4,3% 5,7% 7,2% 8,6% 0,0% 4,3% 5,7% 7,2% 0,0%
8,75MHz 28:14 66,7% 0,0032256 8,72E-05 0,0016128 0,0033128 5,9% 5,9% 5,9% 5,9% 5,9% 7,4% 7,4% 7,4% 7,4% 0,0% 6,6% 8,0% 9,5% 10,9% 0,0% 6,6% 8,0% 9,5% 0,0%
8,75MHz 27:15 64,3% 0,0031104 8,72E-05 0,001728 0,0031976 3,6% 3,6% 3,6% 3,6% 3,6% 5,1% 5,1% 5,1% 5,1% 0,3% 8,9% 10,3% 11,8% 13,2% 0,3% 8,9% 10,3% 11,8% 0,3%
8,75MHz 26:16 61,9% 0,0029952 8,72E-05 0,0018432 0,0030824 1,3% 1,3% 1,3% 1,3% 1,3% 2,8% 2,8% 2,8% 2,8% 2,6% 11,2% 12,6% 14,1% 15,5% 2,6% 11,2% 12,6% 14,1% 1,3%
8,75MHz 25:17 59,5% 0,00288 8,72E-05 0,0019584 0,0029672 0,0% 0,0% 0,0% 0,0% 0,0% 0,5% 0,5% 0,5% 0,5% 4,9% 13,5% 14,9% 16,4% 17,8% 4,9% 13,5% 14,9% 16,4% 0,0%
8,75MHz 24:18 57,1% 0,0027648 0,0000872 0,0020736 0,002852 0,0% 0,0% 0,0% 0,0% 0,1% 0,0% 0,0% 0,0% 0,0% 7,3% 15,8% 17,3% 18,7% 20,1% 7,3% 15,8% 17,3% 18,7% 0,0%
Min 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0% 0,2% 1,6% 3,0% 0,0% 0,0% 0,2% 1,6%