Geneva, 28 May 2010

Q13 Activities on Time Synchronization

Jean-Loup Ferrant,Calnex, Q13 Rapporteur

Stefano RuffiniEricsson, Q13 Associated Rapporteur

Joint ITU-T/IEEE Workshop on The Future of Ethernet Transport

(Geneva, 28 May 2010)

Transport of frequencyin Q13/15

In 2004, Q13 started working on transport of timing on PSN

Interworking with TDM was requiredFDD was the mostly deployed mobile technology (only frequency sync required)

Focus on Frequency synchronization1- Transport of frequency in CES applications2- Transport of frequency via SyncEFirst series of recommendations: G.8261, G.8262, G.8264

Initial discussion on time synchronizationTransport of time on SyncE was also proposed, but 1588 was preferred

2

Transport of time in Q13/15

Transport of time became important with TDD and new applications (e.g. MBSFN)

Q13 has chosen to focus on 1588-2008 for the transport of time and frequency (NTP also briefly mentioned)

Q13 worked on a first « telecom profile » (consent planned next week)Q13 workplan has been rearranged to align frequency and time recommendations

3

Structure of documents in Q13/15

4Q13-NGN-Sync-Requirements-Structure

*) Due to the premature status of phase/time in Q13 this structure may be modified later according to the ongoing work

G.8265.1PTP profile Frequency 1

G.8275.1PTP profile ToD/phase 1

Basics

Clock

Methods

Profiles

Frequency: G.826x Time/Phase: G.827x*)

G.8265.2PTP Telecom Profile 2

G.8261.1Network PDV for frequency

G.8271.1Network Requirements for time/phase

Network requirements

SyncE Network Jitter/Wander: Included in G.8261 (may G.8261.2 for future)

G.8261G.pactiming

G.8271(G.pactiming-bis)

G.8272(G.paclock-time)

G.8273G.paclock-time-xy

G.8275 G.pacmod-Packet-architecture-for time

G.8262G.paclock-SyncE

G.8263G.paclock-bis-Packet

G.8264G.pacmod-SyncE-architecture

G.8265G.pacmod-Packet-architecture-Frequency

G.8275.2PTP profile ToD/phase 2

G.8271.2may be needed in future

Definitions /terminology

G.8260 G.pacSyncDefinition

San Jose March 2010

5

Time-Phase Requirements

Application Time/Phase synchronization accuracy

CDMA2000(3GPP2 C.S0010-B, 3GPP2 C.S0002-C )

+/- 3 s with respect to UTC (during normal conditions)+/- 10 s of UTC (when the time sync reference is disconnected)

W-CDMA (TDD mode)(3GPP TS 25.402)

2.5 s phase difference between Base Stations.

TD-SCDMA (TDD mode)(3GPP TR 25.836)

3 s phase difference between Base Stations.

LTE (TDD)(3GPP TS 36.133)

3 s time difference between Base Stations (small cell).10 s time difference between Base Stations (large cell).

MBSFN (e.g. over LTE) < +/- 1 s with respect to a common time reference (continuous timescale)

WiMAX (TDD mode)(IEEE 802.16)

Depend on several parameters. As an example +/-0.5 s and +/-5 s have been mentioned for a couple of typical cases.

IP Network delay Monitoring

Depends on the level of quality that shall be monitored. As an example +/- 100 s with respect to a common time reference (e.g. UTC) may be

required. +/- 1 ms has also been mentioned.

Billing and Alarms +/- 100 ms with respect to a common time reference (e.g. UTC)

Example in Wireless Application

Phase Sync needed to Synchronize transmission from different base stations

To optimize bandwidth usage and enhance network capacityIn TDD mode uplink and downlink are separated in time

LTE-TDD: 3 s time difference between Base Stations (small cell)

“phase synchronization” requirement of 1.5 s between the master and the slave, according to ITU-T definitions (see G.8260)

eNodeBeNodeB+/- 3 s

+/- 1.5 s+/- 1.5 s

6

7

G.8271

The G.8271, Time and Phase synchronization aspects in packet networks

First Q13 recommendation in the G.827x series;Draft already available

ScopeOverall performance objectives (see applications in previous slide)Methods to distribute phase synchronization and/or time synchronization (GNSS, Packet-based)Network ModelInitial focus: Ethernet physical layer

Detailed Network Limits are proposed to be included in a separate document (to be defined, e.g. G.8271.1)

8

IEEE defines a profile as “The set of allowed precision time Protocol (PTP) features applicable to a device”

The first purpose of a profile is to allow interworking between PTP master and slavesITU-T Q13/15 agreed to define telecom profiles based on IEEE 1588-2008

First profiles will address the transport of frequencyNext profiles will address the transport of phase, time and frequency

IEEE1588 Telecom Profiles

Frequency telecom profile

First profile for end to end application, no support from intermediate nodes

Frequency synchronization onlyPDV is not controlled in intermediate nodesAbsolute delay is not an issue for frequency

No asymmetry issue

Network architecture as per G.8265

9

Network

Packet Slave Clock

Packet Slave Clock

PacketSlave clock

Packet Network

PacketMaster clock

Reference1

Fi

Fout +Fout +

Fout +

1: Note, the reference may be from a PRC directly, GPS or via a synchronization network

Packet Timing Signals

NetworkNetwork

Packet Slave Clock

Packet Slave Clock

PacketSlave clock

Packet NetworkPacket Network

PacketMaster clock

Reference1

Fi

Fout +Fout +

Fout +

1: Note, the reference may be from a PRC directly, GPS or via a synchronization network

Packet Timing Signals

Frequency distribution without timing support from the network (Unicast mode)

Selected optionsUnicast is the selected mode

Mix unicast and multicast mode is for further study and may be specified in future profiles

Mapping:IEEE-2008 annexD (UDP over IPV4)One-way vs two ways

Masters must support bothSlaves may select one

One-step vs two-steps Both allowed

BMCA (best master clock algorithm)Definition of a specific BMCA by ITU-T

10

IEEE1588 Time Profile

The distribution of accurate time/phase (e.g. < 1 microsecond) can be challenging without timing support from the network

PDV impacting accurate frequency distributionAsymmetry due to different traffic load on forward and reverse directionAsymmetry due to particular transport technologies

A network with timing support is generally required

E.g. Boundary Clock in every node

Master

PTP Master

BaseStation

PTP packets

Boundary Clock

Master

PTP Master

BaseStation

PTP packets

Boundary Clock11

Related Aspects

Several aspects need to be addressed by Q13Telecom Profile (e.g. PTP mapping, Unicast vs. Multicast, packet rate, BMC, etc.)Is the Transparent Clock allowed in Telecom ?Performance aspects (e.g. Clock characteristics, Holdover, etc.)Architecture (e.g. Sync Reference chain), redundancyCombination with SyncEInterworking with the access technologies

Time Sync Master

(e.g. PTP Master)

GPON/XG-PON/VDSL

End User(e.g. Base Station)

End User(e.g. Base Station)

End User(e.g. Base Station)

Packet Network

Time Sync Master

(e.g. PTP Master)

GPON/XG-PON/VDSL

End User(e.g. Base Station)

End User(e.g. Base Station)

End User(e.g. Base Station)

Packet Network

12

Additional Slides

Phase and TimeRelevant Terms are defined in G.8260

Phase: significant events occur at the same instant Time: nodes get information about time and share a common timescale and related epoch

t

t

timing signal recovered by system A

timing signal recovered by system B

System A

System BB

Reference timing signalto system A

Reference timing signalto system B

t

t

timing signal recovered by system A

timing signal recovered by system B

System A

System BB

Reference timing signalto system A

Reference timing signalto system B

System A System B

t

t

timing signal recovered by system A

timing signal recovered by system B

00:01:0200:01:0100:01:00

00:01:0200:01:0100:01:00

Ex.: UTC, UTC + n x hoursGPS Time, Local arbitrary Time

System A System B

t

t

timing signal recovered by system A

timing signal recovered by system B

00:01:0200:01:0100:01:00

00:01:0200:01:0100:01:00

Ex.: UTC, UTC + n x hoursGPS Time, Local arbitrary Time

TimePhase

14