Download Q13 Activities on Time Synchronization

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Network tap wikipedia , lookup

Deep packet inspection wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Airborne Networking wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Transcript
Joint ITU-T/IEEE Workshop
on The Future of Ethernet Transport
(Geneva, 28 May 2010)
Q13 Activities on Time
Synchronization
Jean-Loup Ferrant,
Calnex, Q13 Rapporteur
Stefano Ruffini
Ericsson, Q13 Associated Rapporteur
Geneva, 28 May 2010
Transport of frequency
in Q13/15
In 2004, Q13 started working on transport of
timing on PSN
Interworking with TDM was required
FDD was the mostly deployed mobile technology
(only frequency sync required)
Focus on Frequency synchronization
1- Transport of frequency in CES applications
2- Transport of frequency via SyncE
First series of recommendations: G.8261, G.8262,
G.8264
Initial discussion on time synchronization
Transport 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
3
recommendations
Structure of documents
in Q13/15
San Jose March 2010
Definitions /
terminology
G.8260
G.pacSyncDefinition
G.8261
Basics
Network
requirements
Clock
Methods
Frequency: G.826x
G.pactiming
G.8271
Time/Phase: G.827x*)
(G.pactiming-bis)
SyncE Network Jitter/Wander: Included
in G.8261 (may G.8261.2 for future)
G.8271.1
Network Requirements for time/phase
G.8261.1
G.8271.2
Network PDV for frequency
may be needed in future
G.8262
G.8272
G.paclock-SyncE
(G.paclock-time)
G.8263
G.8273
G.paclock-bis-Packet
G.paclock-time-xy
G.8264
G.8275
G.pacmod-SyncE-architecture
G.pacmod-Packet-architecture-for time
G.8265
G.pacmod-Packet-architecture-Frequency
Profiles
G.8265.1
G.8275.1
PTP profile Frequency 1
PTP profile ToD/phase 1
G.8265.2
PTP Telecom Profile 2
G.8275.2
PTP profile ToD/phase 2
Q13-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
4
Time-Phase Requirements
Application
Time/Phase synchronization accuracy
CDMA2000
(3GPP2 C.S0010-B,
3GPP2 C.S0002-C )
+/- 3 ms with respect to UTC (during normal conditions)
+/- 10 ms of UTC (when the time sync reference is disconnected)
W-CDMA (TDD mode)
(3GPP TS 25.402)
2.5 ms phase difference between Base Stations.
TD-SCDMA (TDD mode)
(3GPP TR 25.836)
3 ms phase difference between Base Stations.
LTE (TDD)
(3GPP TS 36.133)
3 ms time difference between Base Stations (small cell).
10 ms time difference between Base Stations (large cell).
MBSFN (e.g. over LTE)
< +/- 1 ms with respect to a common time reference (continuous timescale)
WiMAX (TDD mode)
(IEEE 802.16)
Depend on several parameters. As an example +/-0.5 ms and +/-5 ms 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 ms 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)
5
Example in
Wireless Application
Phase Sync needed to Synchronize transmission from
different base stations
To optimize bandwidth usage and enhance network capacity
In TDD mode uplink and downlink are separated in time
LTE-TDD: 3 ms time difference between Base Stations
(small cell)
“phase synchronization” requirement of 1.5 ms between the
master and the slave, according to ITU-T definitions (see
G.8260)
+/- 1.5 ms
eNodeB
+/- 1.5 ms
+/- 3 ms
eNodeB
6
G.8271
The G.8271, Time and Phase synchronization
aspects in packet networks
First Q13 recommendation in the G.827x series;
Draft already available
Scope
Overall performance objectives (see applications in
previous slide)
Methods to distribute phase synchronization and/or time
synchronization (GNSS, Packet-based)
Network Model
Initial focus: Ethernet physical layer
Detailed Network Limits are proposed to be
included in a separate document (to be defined,
e.g. G.8271.1)
7
IEEE1588 Telecom Profiles
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
slaves
ITU-T Q13/15 agreed to define telecom
profiles based on IEEE 1588-2008
First profiles will address the transport of
frequency
Next profiles will address the transport of
phase, time and frequency
8
Frequency telecom profile
First profile for end to end application, no
support from intermediate nodes
Frequency synchronization only
PDV is not controlled in intermediate nodes
Absolute delay is not an issue for frequency
No asymmetry issue
Network architecture as per G.8265
Reference1
Fi
Packet
Master clock
Packet
Slave Clock
F out + 
Packet
Slave Clock
F out + 
Packet Timing Signals
Network
Packet Network
Packet
Slave clock
F out +
1: Note, the reference may be from a PRC directly, GPS or via a synchronization network
9
Frequency distribution
without timing support from the network (Unicast mode)
Selected options
Unicast 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 both
Slaves 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 distribution
Asymmetry due to different traffic load on forward and
reverse direction
Asymmetry due to particular transport technologies
A network with timing support is generally
required
E.g. Boundary Clock in every node
11
Related Aspects
Several aspects need to be addressed by Q13
Telecom 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), redundancy
Combination with SyncE
Interworking with the access technologies
Time Sync Master
End User
(e.g. Base Station)
(e.g. PTP Master)
Packet Network
GPON/XG-PON/VDSL
End User
(e.g. Base Station)
End User
(e.g. Base Station)
12
Additional Slides
Phase and Time
Relevant 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
Phase
Reference timing signal
to system A
Time
System A
System A
Reference timing signal
to system B
System B
B
System B
timing signal recovered by system A
00:01:00
00:01:01
00:01:02
timing signal recovered by system A
t
Ex.: UTC, UTC + n x hours
GPS Time, Local arbitrary Time
timing signal recovered by system B
00:01:00
00:01:01
00:01:02
t
timing signal recovered by system B
t
14