Download Update on ITU-T Q13/15 Activities Tictoc – IETF 78

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

Zero-configuration networking wikipedia , lookup

RapidIO wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

IEEE 1355 wikipedia , lookup

Distributed firewall wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Computer network wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Network tap wikipedia , lookup

Airborne Networking wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Cellular network wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Deep packet inspection wikipedia , lookup

Packet switching wikipedia , lookup

Transcript
Update on ITU-T Q13/15
Activities
TICTOC – IETF 78
Stefano Ruffini, Ericsson
Sync in Packet Networks
Initial Focus: Transport of Frequency
› In 2004, Q13 started working on transport of timing on Packet Networks
– Interworking with TDM was required
– FDD was the mostly deployed mobile technology (only frequency sync)
› Focus on Frequency synchronization
– Transport of frequency in CES applications
– Transport of frequency via SyncE
– Initial informations on the use of PTP and NTP for frequency sync
› First series of recommendations (released between 2006 and 2008;
Revised or Amended in June 2010) :
– G.8261 (General, CES, SyncE, NTP/PTP for frequency, Network Limits)
– G.8262, EEC (SyncE Clock)
– G.8264 (SyncE SSM)
© Ericsson AB 2010
2
2010-07-22
Second Step:
IEEE1588 Profiles and Time Synch
› Transport of time (phase) important with TDD and new
applications (e.g. MBSFN)
– Focus on IEEE 1588-2008 (PTP) for the transport of very accurate
time (< 1 microsecond). Definition of Telecom Profiles required.
– NTP is also mentioned in ITU-T (mainly for traditional ToD
applications and for frequency sync)
– Transport of time over SyncE was also proposed, but the use of
packet protocols has been preferred
– Combination between IEEE1588 and SyncE being considered
› Q13 workplan has been rearranged to align frequency and
time recommendations
© Ericsson AB 2010
3
2010-07-22
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
© Ericsson AB 2010
4
2010-07-22
IEEE 1588 Telecom Profiles
› ITU-T Q13/15 agreed to define telecom profiles based on IEEE 1588-2008
– First profiles address the transport of frequency
– Next profiles will address the transport of phase, time (and frequency)
› First profile without support from intermediate nodes (G.8265.1, consented
in June 2010)
– Frequency synchronization only
– PDV is not controlled in intermediate nodes
– Absolute delay is not an issue for frequency (no asymmetry issues)
› Network architecture for frequency sync as per G.8265 (consented in June
2010)
Reference1
Fi
Packet
Master clock
Packet Timing Signals
Packet
Slave Clock
Network
F out + 
Packet Network
Packet
Slave Clock
F out + 
Packet
Slave clock
F out +
1: Note, the reference may be from a PRC directly, GPS or via a synchronization network
© Ericsson AB 2010
5
2010-07-22
G.8265.1: Frequency distribution
without timing support from the network
› Selected options
– Unicast is the selected mode
› Mix unicast and multicast mode is for further study and may be specified
in future profiles (Annexes of G.8265.1)
– Mapping: IEEE-2008 annexD (UDP over IPV4); Note: this profile could also
be applicable to MPLS (assuming no support from the network is required)
– 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
› Security aspects are for further study
› Management aspects will be specified in a future version of this profile
(Note: management aspects related to digital transmission equipment's
synchronization functionality are defined in G.781).
© Ericsson AB 2010
6
2010-07-22
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)
Main Focus for Q13
Maybe in the future
Out of the scope
© Ericsson AB 2010
7
2010-07-22
ITU-T Recc. G.8271
› The G.8271, Time and Phase synchronization aspects in packet
networks
– First Q13 recommendation in the G.827x series;
– Draft available
› Scope
– Overall performance objectives (see applications in previous slide)
– Methods to distribute phase synchronization and/or time synchronization
(GNSS, Packet-based)
– Initial focus: Ethernet physical layer
Common Time Reference (e.g. GPS time)
– Network Model N
Network Time Reference
(e.g. GNSS Engine)
PRTC
PRTC; Primary Reference
Time Clock
Packet
Master
Packet
Network
E
D
C
B
A
Packet
Slave Clock
End Application
Time Clock
› Detailed Network Limits may be included in a separate document
© Ericsson AB 2010
8
2010-07-22
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 timing 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
› Future studies will also consider network with “partial timing support”
› First profile planned for consent in 2011
© Ericsson AB 2010
9
2010-07-22
Main Time Sync Study Points
› Telecom Profile
– PTP mapping,
– Unicast vs. Multicast,
– packet rate,
– BMC,
– etc.
›
›
›
›
›
Transparent Clock applicability 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)
© Ericsson AB 2010
10
2010-07-22
ITU-T Definitions and PDV Metrics
› Timing related definitions
– G.810 provides the basic definitions and the TDM sync related ones
– G.8260, consented in June 2010, provides the packet timing specific
definitions. Planned to include the PDV metrics definitions
› Careful approach on the PDV Metrics defintion as to avoid
possible misuse of the metrics
› Current proposition on PDV metrics:
– “the goal is to formulate packet-based stability quantities (metrics)
that will provide a means of estimating the physical-based stability
quantities for the packet clock output”
Physical
Packet
Network
Packet
interface
layer timing
interface
PEC slave
PDV stability
quantities
Clock stability
quantities
[Clock stability quantities estimation] = function (PDV stability quantities)
© Ericsson AB 2010
11
2010-07-22
OTN Timing Aspects
› G.8251 (control of Jitter and Wander in OTN) revised in
June 2010
– SyncE clients
– updated OTN hierarchy (new G.709)
› Ongoing discussions on CPRI over OTN
› Initial discussions on Time sync (IEEE1588) over OTN
© Ericsson AB 2010
12
2010-07-22