Synchronisation for Mobile

Networks: SyncE and PTP

Telecom Profiles

Paul Norris,
April 2017 www.calnexsol.com
Synchronisation in the Mobile Network

• Frequency Sync
• SyncE
• PTP Frequency Profile

• Time Sync
• PTP Time Profile for Full Timing Support
• PTP Time Profile for Partial Timing Support

Company Confidential 2
 Frequency Sync

Company Confidential 3
G.8261: Frequency over Packet Interfaces

Approach 1: Use the physical layer clock

• Synchronous Ethernet invented to replicate the traditional sync chain
• SyncE clocks (EEC) made identical to SECs in performance terms
• G.8261 reference chain allowed SECs to be interchanged with EECs:
Up to 10 SSUs

PRC Up to 20 SECs SSU Up to 20 SECs SSU SSU Up to 20 SECs End

(G.811) or EECs* (G.812) or EECs* (G.812) (G.812) or EECs* Equipment
(G.813/G.8262) (G.813/G.8262) (G.813/G.8262)

* No more than 60 SECs or EECs allowed in any one chain

4
Synchronous Ethernet (SyncE)

Company Confidential 5
G.8262: Synchronous Ethernet Clock (EEC)
• Based on synchronising the physical layer of the Ethernet
• Identical in performance to SONET/SDH Equipment Clock (SEC)
• Directly replaces SEC in the synchronisation chain
• Standard defines:
• Free run frequency accuracy
• Wander performance: generation, tolerance and transfer
• Jitter performance: generation and tolerance
• Transient behaviour: reference switching and entry into holdover
• Interface types
• New revision (January 2015):
• Includes jitter specification for 40 and 100Gbit/s interfaces

Company Confidential 6
Synchronous Ethernet (SyncE)

Features
• Line rate of the Ethernet Interface used to transfer timing.
• No impact/demand on packet layers.
• Defines the use of a high stability oscillator to generate line frequency.
• Ethernet ‘Classic’: ±100ppm.
• Synchronous Ethernet: ±4.6ppm
• ITU-T Standards in place.
• G.8262: Timing Characteristics for Synchronous Ethernet Equipment
• G.8261: Timing & Synchronisation in Packet Networks
• G.8264: Distribution of Timing Through Packet Networks (ESMC)

7
Synchronous Ethernet (SyncE)

Challenges
• Cost: All interfaces need to be Sync-E compatible.
• Can not be used with existing Ethernet equipment when
transferring synchronisation.

~
PRC

~
PRC

8
Ethernet Synchronisation Message Channel
ESMC
• ESMC PDU transmitted once per
second on the Slow Protocol Channel
• Point to Point Protocol.
• Each network element generates and
terminates ESMC messages

• ESMC PDU contains the QL TLV for

Synchronous Ethernet
• EEC uses the QL in the EEMC PDU to
select the best quality clock
• Enables protection switching if a Sync
source becomes unavailable

9
Wander and Jitter
• Low speed variations in a signal or clock (10Hz down to uHz)
are termed Wander.
• Wander affects the ability of the internal clocking function to
lock to and track the up-stream reference. Wander therefore
impacts the distribution of clock references across networks

• High-speed variations (phase variations above 10 Hz) in signal

timing through a system are called Jitter.
• Jitter directly causes bit errors at device inputs by the eye-
closure mechanism These bit errors then result in dropped
packets.

Company Confidential 10
What causes Wander
• Each EEC is locked to the frequency of the
PRC by recovering the clock from the PRC

incoming physical layer signal. Number of G.812

G.812 type I Type I
clocks < 10 (SSU)

• The action of recovering and regenerating SEC SEC

the clock reference is a major source of Number of G.813 SEC EEC

wander in a network.
option 1 clocks <
20
SEC EEC

Total number of
• Wander is also caused by G.813 clocks in a
sychronisation
SEC SEC

• very slight differences in reference clocks trail should not

exceed 60
G.812
Type I
between network segments (SSU)

• Slow changes in the relative phase of two clock G.8262 is Compatible with G.813
signals due to climatic temperature changes.
• low-frequency phase noise in a clock oscillator.
Company Confidential 11
What causes Jitter
• Jitter is always present at the output port of any network
element (NE), even if it originates a signal or an entirely jitter-
free digital signal or clock is applied to its input.

• This is known as Device jitter generation

• Also known as output jitter, or intrinsic jitter.

• Device Jitter Generation arises from

• Clock oscillator behaviour, noise, spurs, crosstalk and drift
• Pattern-dependent delay in scramblers and encoders
• Laser and modulator pattern dependency

Company Confidential 12
 Sync-E Jitter

Tx Rx Tx

• In both Ethernet and Synchronous Ethernet, pulse edges carry timing information
• The timing information is recovered in the Rx and used to sample the data
• In Sync-E, the timing information is also passed on to the Tx side

Clock Packet
recovery
Sampler Data processing

Clock
13
Inside the sampler

•If jitter exceeds device tolerance, sampling moves away from eye
centre towards edges
•The input sampler mistakes 1s for 0s and vice-versa – bit errors
•The packet processing in the device then drops any packet with one
or more bit errors
14
How Sync-E passes the clock on

Rx

Clock Packet
recovery
Rx
Sampler Data processing

Sync-E output has some jitter

Clock
•Phase noise in Tx clock
•PHY behaviour

Tx
Frequency lock
Narrowband
clock Tx clock PHY
filtering

15
G.8261: Frequency over Packet Interfaces

Approach 2: Use a packet timing protocol

• Packet timing protocols such as PTP or NTP used to deliver frequency
• Aims to deliver at least same quality of timing
• Used to replace one segment of the sync chain (typically the last):
Up to 10 SSUs

Packet
M Network
S

PRC Up to 20 SECs SSU Up to 20 SECs SSU SSU Packet Master and Slave End
(G.811) or EECs* (G.812) or EECs* (G.812) (G.812) (slave: G.8263) Equipment
(G.813/G.8262) (G.813/G.8262)

* No more than 60 SECs or EECs allowed in any one chain

Company Confidential 16
 PTP Telecom Profile for
Frequency (G.8265.1)

Company Confidential 17
Prime Objectives
• To permit the distribution of frequency using PTP over existing
managed, wide-area, packet-based telecoms networks
• To allow interoperability with existing synchronization networks
(such as SyncE and SDH)
• To define message rates and parameter values consistent with
frequency distribution to the required performance for telecom
applications
• To allow the synchronization network to be designed and
configured in a fixed arrangement
• To enable protection schemes to be constructed in accordance
with standard telecom network practices

Company Confidential 18
Key design decisions
• No on-path support (e.g. boundary and transparent clocks)
• Must operate over existing networks
• IP adopted as the network layer
• Ubiquitous and end-to-end
• Unicast transmission adopted over multicast
• Guaranteed to work over wide-area telecoms networks
• Upstream multicast often not enabled in carrier networks
• Continuity of SSM with SONET/SDH and SyncE
• PTP Announce message adapted to carry the Quality Level (QL) indications
• BMCA (Best Master Clock Algorithm) replaced by static provisioning
• Planned synchronization and protection flows, rather than dynamic
adjustment

Company Confidential 19
General Packet Timing Architecture – G.8265

~ PRC

PTP
Master
Packet Timing Signals

PTP
Slave
PTP
Slave

PTP
Slave

Company Confidential 20
Unicast negotiation - G.8265.1
• Slave requests service from master
• Unicast only no multicast
• Slave requests message rate
• Grants are for limited duration
• Default 300 seconds
• Adjustable 60 – 1000 secs
• Slave can request
• Announce messages
• Sync Messages
• Delay-Resp messages

Company Confidential 21
Rate of Timing Messages
• The rate of timing messages required is dependent on several factors
• Amount of noise in the network
• Local oscillator stability
• Efficiency of clock servo algorithm
• The Telecom Profile defines the range of message rates that Masters
and Slaves should support:
Message rates Minimum Maximum Default
Announce 1 msg. every 16s 8 messages/s 1 msg. every 2s
Sync 1 msg. every 16s 128 messages/s Not defined
Delay_Request 1 msg. every 16s 128 messages/s Not defined

• It is not expected that a slave will achieve the required performance

at all message rates
• Slave must request the message rates needed to maintain performance
Company Confidential 22
Mapping of SSM QL to PTP ClockClass – G.8265.1
ITU-T G.781 PTP
SSM QL Option I Option II Option III ClockClass
0001 QL-PRS 80
0000 QL-STU QL-UNK 82
0010 QL-PRC 84
0111 QL-ST2 86
0011 88
0100 QL-SSU-A QL-TNC 90
0101 92
0110 94
1000 QL-SSU-B 96
1001 98
1101 QL-ST3E 100
1010 QL-ST3/ QL-EEC2 102
1011 QL-SEC/ QL-EEC1 QL-SEC 104
1100 QL-PSMC 106
1110 QL-PROV 108
1111 QL-DNU QL-DUS 110

Company Confidential 23
Source Traceability
• Encodes QL values in the clockClass field of the Announce
message
• Provides end-to-end traceability of the reference source along the
synchronization chain
• Informs the slave clock (and subsequent devices) of the quality of the
timing source
• Allows the timing chain to be managed in a similar way to existing
synchronization networks
End-to-End Source Traceability

SSM: QL-PRC [0010] clockClass: QL-PRC [84] SSM: QL-PRC

PTP PTP
GM Slave

PRC Physical Layer PTP Packet Network PTP Slave End

Synchronization Network Grandmaster Equipment
Company Confidential 24
General Packet Timing Protection – G.8265
~ PRC

Protection Packet Timing PTP

Signals Master
(Primary)
Working Packet Timing
~ PRC Signals

PTP
Master
(secondary) PTP
Slave

Company Confidential 25
Master Selection and Protection
• Telecom slave clock consists of several logical protocol instances,
each communicating with a different grandmaster
• Selection process follows G.781 selection rules:
• Availability, Traceability, Priority

Slave Telecom
PTP GM
1
Protocol
Instance 1
Slave Clock

G.781-
Slave based
PTP GM Packet
Protocol Master
2 Network Instance 2 Selection
Process

Slave
PTP GM
Protocol List of N
N Instance N
Grandmasters
Company Confidential 26
Separate PTP domains
Example of how PDV affects OCs
PDV Accumulation

Master Router Router Router Router Slave

Clock Clock

• In a network with non 1588-aware switches, PDV, Asymmetry, Re-routing

can be significant.
• Slave clock recovery is a challenge.
• Slave normally works by using the lucky packets – the packets with
minimum delay
Company Confidential 27
PDV - Unpredictable delay is the problem

Timing packets have to fight there way through network devices against traffic

28
Packet Delay Variation
• “Green Light” protocol
• Some (small) number of cars will drive through a town with every traffic
light at green, and arrive at their destination with the least delay
• This “minimum delay” is consistent, and cannot be improved (at least,
not without breaking the speed limit)
• The number of cars achieving this “minimum delay” reduces with
congestion
• Same applies to packets in a network
• Queuing in a network element is like waiting at a traffic light
• The more congestion on the network, the less chance there is to avoid
queuing

Company Confidential 29
 Packet Delay Distribution
Frequency of Cluster
occurrence range

Low
congestion

Medium
congestion

High
congestion

Minimum Packet Delay

Delay
Company Confidential 30
Measure PDV
– Is PDV within required limits?

Ideally Capture for >24 hours to see the changes in PDV throughout a day and
capture any intermittent issues 31
 PDV Metrics
Floor Packet Population (G.8261.1)
• Packet Delay Variation network limit at
point C of figure 3/G.8261.1 (for HRM-1)
• Floor Packet Percent (FPP)
• Window interval W = 200s
• Fixed cluster range δ = 150µs (from floor delay)
• At least 1% of packets must fall in this cluster.
PDV Metrics
Vendor Specific
Requirement A

Node B requirements:
• The Node B will lock within a 16 minute period if either
a) 1% of packets within 20µsec of Noise Floor, or
b) 99% of packets with <0.3msec spread.
Requirement B
• If case b) is greater than 0.3msec, then
• If 99% with <3msec spread, will lock
within 60 minutes.
• If 99% with <10msec spread, will lock
within 180 minutes.

Reference Point Reference Point Reference Point Reference Point

A B C D

PEC-M PEC-S-F

PRC Packet Network PTP Slave End

PTP Grandmaster
Equipment
Company Confidential 33
Packet Timing System
 Time/Phase Sync

Company Confidential 34
 PTP Telecom Profile for Time
using Full Timing Support
(G.8275.1)

Company Confidential 35
Prime Objectives
• To facilitate interoperability between clocks designed for the
ITU-T time/phase architecture (G.8275)
• To permit the distribution of time and phase using PTP over
managed, wide-area, packet-based telecoms networks
• To allow the synchronization network to be designed and
configured in a fixed arrangement
• To enable protection schemes to be constructed in accordance
with standard telecom network practices; specifically the ability
to use multiple geographically separate T-GM clocks
• To define message rates and parameter values consistent with
time/phase distribution to the required performance for
telecom applications
Company Confidential 36
Key design decisions
• Uses a boundary clock at every node in the chain between PTP
Grandmaster and PTP Slave
• Reduces time error accumulation through the network
• Boundary clocks defined with a filter bandwidth of 0.1Hz
• Recommends the use of Synchronous Ethernet to syntonise
each boundary clock to a stable frequency
• Defines Sync and Delay_Request message rate of 16 messages/s
• Operates over a Layer 2 Ethernet network
• Uses Ethernet multicast addresses identified in IEEE1588-2008 Annex F
• Support of unicast IP not agreed due to potential for insertion of non
PTP-aware equipment
• Supports multiple active grandmasters for redundancy
Company Confidential 37
Hypothetical Reference Model
Up to 20 BCs in a chain

Time reference Time Plane End Application

(PRTC) (e.g. eNodeB)
PTP GM PTP PTP BC PTP PTP BC PTP PTP BC PTP PTP TSC
EEC EEC EEC EEC EEC

SyncE SyncE SyncE SyncE SyncE

SyncE
frequency
distribution
networks

PRC
frequency
references
[PRCs may be separate or common]
Frequency Plane
Company Confidential 38
Source Traceability
Uses clockClass attribute to determine phase/time traceability:
defaultDS. Input Frequency Time
Phase/time traceability description
clockClass SyncE QL Traceable flag Traceable flag
T-GM connected to a PRTC in locked mode
6 n/a TRUE TRUE
(e.g. PRTC traceable to GNSS)
PRC / PRS TRUE TRUE
T-GM in holdover, within holdover specification 7
Non-PRC FALSE TRUE

PRC / PRS TRUE TRUE

T-BC in holdover, within holdover specification 135
Non-PRC FALSE TRUE

140 PRC / PRS TRUE FALSE

SSU-A /
T-GM in holdover, out of holdover specification 150 FALSE FALSE
Stratum 2
SSU-B /
160 FALSE FALSE
Stratum 3E
T-BC in holdover, out of holdover specification 165 n/a
(depends on QL
T-GM or T-BC without time ref. since start-up 248 n/a of input SyncE if FALSE
Company Confidential available) 39
Slave only OC (does not send Announce msgs.) 255 n/a
Holdover In and Out of Specification
• Holdover is based on the whole chain being in or out of
specification
• i.e. the 250ns or 400ns budgets for holdover in G.8271.1 Appendix V,
scenarios (a) and (b)
• Clocks use timers and knowledge of frequency stability to
estimate when they are out of holdover specification
• Once a T-GM has gone “out of specification”, the whole chain is
“out of specification”
• A T-BC can only become master if it loses connectivity to the T-GM
• Some operators ignore the “in specification” concept by setting
the timers to zero
• If the clock is in holdover, then it is not assumed to be accurate
Company Confidential 40
PTP with Full Timing Support
Reference Reference Reference
Point Point Point
B All switches/routers on the path C D
between T-GM and T-TSC contain a T-BC
GNSS

T-GM T-TSC
T-BC T-BC T-BC T-BC

PRTC PTP Packet Network End clock

Grandmaster (e.g. eNodeB)

Features
• Every element in the path must be “PTP aware”
• T-BC case covered in standards, T-TC case under development
• Uses a combination of SyncE and PTP, where SyncE provides the
frequency and PTP the phase/time
Company Confidential 41
PTP with Full Timing Support
Benefits
• Controlled, deterministic environment suitable for both
frequency and time/phase transfer
• “Building block” approach to network construction,
with example time error budgets in G.8271.1
• Profile, architecture and clock performance defined by ITU-T,
published May 2014
Challenges
• All equipment in path needs to be PTP aware
• No control of asymmetry in the network
!
Company Confidential 42
 G.8271.1: Time Error Budget Example
G.8271.1 Network Reference Points

A, B C D
±100ns
(PRTC/T-GM) cTE uses up 70% of the
±200ns dTE
(random network network equipment budget
variation)
±550ns cTE ±250ns cTE
(node asymmetry, (link asymmetry
±50ns per node) compensation)
Class A T-BCs:

Class B T-BCs:
±250ns
±420ns cTE ±380ns cTE (short term holdover)
(21 nodes, ±20ns per node) (link asymmetry
±150ns
compensation)
(end application)

±1.1µs network equipment budget

Company Confidential 43
±1.5µs end-to-end budget
BC Performance
• Chinese Vendors don’t necessary meet G.8273.2
• China Mobile spec in contradiction to ITU-T spec
• Albert to give more info during presentation
• Tolerance and Transfer
• Phase transient and Holdover

• Very important to test performance of BC’s before deployment

• Otherwise you may not meet G.8271.1 budget
• Lab on Tues/Wed

Company Confidential 44
Relevant Standards for FTS
Published recommendations related to full timing support:
• G.8271 – General considerations for time synchronization
• G.8275 – General network architecture for time synchronization
• G.8275.1 – PTP Profile for full timing support
• G.8271.1 – Network limits for full timing support
• G.8272 – Primary Reference Time Clock Specification
• G.8273.2 – Telecom Boundary Clock Specification

Standards complete and published.

Company Confidential 45
 Partial Timing Support

Company Confidential 46
G.8275.2 “Partial Timing Support” Profile
• Why a second time/phase profile?
• Some service providers need to operate time/phase synchronization over
existing networks
• Reduces barriers to entry into LTE-A systems; don’t need to build an
entirely new network
• Allows operation over 3rd party network providers (given appropriate
quality guarantees)
• Requested by four large service providers (Sprint, AT&T, Verizon, T-Mobile)
• Not every network element needs to include a BC or TC
• Much smaller, localised network than for full timing support
• Intended to support both pure PTP case and PTP backup to GNSS

Company Confidential 47
Partial Timing Support Use Cases - 1
PTP backup to GNSS (“assisted partial timing support”, or APTS)
Reference Reference
Point Point
C D
Not all switch/routers on the path between
GNSS T-GM and AP-TSCP contain a T-BC
GNSS

T-GM T-BC
AP-TSC

PRTC PTP Packet Network End clock

Grandmaster (e.g. eNodeB)

Features
• Objective is backup to GNSS, i.e. “assisted holdover”
• GNSS monitors PTP service quality and network asymmetry
• PTP can maintain timebase when GNSS is out of service
(e.g. due to jamming or antenna failure)
Company Confidential 48
PTP with Assisted Partial Timing Support
Benefits
• Mutual co-operation between GNSS and PTP
• PTP provides an initial time fix to assist the GNSS during signal acquisition
• GNSS calibrates the PTP asymmetry, and monitors its suitability for service
• PTP can monitor GNSS timing quality, e.g. antenna failure, spoofing, jamming
• Operates over existing networks, including third party access networks
that may not have built-in PTP support
• Profile now agreed, architecture and clock performance still under
definition in ITU-T
Challenges
• Less deterministic path from T-GM to APTSC, because not every
network element assists in the timing flow
• May need constraints on traffic load and span of the packet network
• Little agreement in ITU-T on the scope of the network
49
Partial Timing Support Use Cases - 2
PTP distribution over a local LAN (“partial” or “no timing support”)
Time distribution from rooftop
antenna to multiple small cells,
using PTP over the building LAN

Features
• Objective is to distribute time over a small PTP-unaware (or
partially unaware) network
• Small network, potentially only a single in-building network
• Places GNSS source as close to the end clock as possible
Company Confidential 50
Partial Timing Support Use Cases - 3
Network Bridging

Operator A transport Operator B transport Operator A transport

network with full PTP network with no PTP network with full PTP
GNSS timing support timing support timing support

T-GM T-TSC
T-BC T-BC T-BC T-BC

PRTC PTP End clock

Grandmaster Packet Network (e.g. eNodeB)

Features
• Objective: bridge between two full timing support networks
• Example: a mobile operator may not own the access network,
and need to bridge across a third party network
Company Confidential 51
PTP with Partial Timing Support
Benefits
• Simple deployment over existing networks
• Operators do not need to own or manage the network
• Can be leased from a third party, e.g. building owner
• Profile now agreed, architecture and clock performance still under
definition in ITU-T
Challenges
• Less deterministic path from T-GM to T-TSC, because not every
network element assists in the timing flow
• Switches/routers not designed with PTP asymmetry in mind, so
device asymmetry is uncontrolled
• May need constraints on traffic load and span of the packet network
• Little agreement in ITU-T on the scope of the network
52
Relevant Standards for APTS and PTS
Published recommendations related to partial support:
• G.8271 – General considerations for time synchronization
• G.8275 – General network architecture for time synchronization
• G.8272 – Primary Reference Time Clock Specification
• G.8275.2 – PTP Profile for partial timing support

Recommendations under development related to partial support:

• G.8271.2 – Network limits for partial timing support
• G.8273.4 – Assisted Partial Timing Support Clock (APTSC)
• G.8273.x – Partial Timing Support Slave Clock (T-TSC-P)

Key standards still under development or not started

Company Confidential 53
G.8275.2 Profile Details

54
Prime Objectives
• To allow interoperability between the various phase and time clocks
used in the architecture defined in G.8275
• To permit the distribution of phase and time using PTP over existing
managed, wide-area, packet-based telecoms networks
• To define message rates and parameter values consistent with
phase/time distribution to the required performance for telecom
applications
• To allow the synchronization network to be designed and configured
in a fixed arrangement
• To enable protection schemes to be constructed in accordance with
standard telecom network practices, including the use of multiple
geographically separated reference clocks
• To allow reference source selection based on traceability information
supplemented by local priority, as well as automatic establishment of
topology
55
Key design decisions
• Operates over existing switches and routers, using unicast IP
• Allows use of boundary and transparent clocks at some nodes in the
chain between PTP Grandmaster and PTP Slave
• Cleans up time signal as it passes through the network
• Supports multiple active grandmasters for redundancy
• Mixture of both G.8265.1 and G.8275.1 profiles, with necessary
modifications for time/phase operation
• IPv4/IPv6 support as in G.8265.1
• Unicast messaging and negotiation as in G.8265.1
• Message rates similar to G.8265.1 (Sync/Delay_req 1 to 128 msgs/s)
• Uses end-to-end messaging (Sync/Delay_req) for delay estimation
• ClockClass scheme and ABMCA from G.8275.1
Currently in Last Call: expected publication May 2016 if no objections
56
Rate of Timing Messages
• The rate of timing messages required is dependent on several factors
• Amount of “noise” in the network (e.g. caused by other traffic)
• Local oscillator stability
• Efficiency of clock servo algorithm
• The profile defines the range of message rates permitted:
Message rates Minimum Maximum
Announce 1 message/s 8 messages/s
Sync (and follow-up) 1 message/s 128 messages/s
Delay_Request 1 message/s 128 messages/s

• It is not expected that a slave will achieve the required performance

at all message rates
• Slave must request the message rates needed to maintain performance
• Masters must support the full range of message rates
57
Alternate BMCA
• Similar to G.8275.1, based on default IEEE1588-2008 BMCA:
• Allows multiple simultaneously-active grandmasters in the same domain
• New per-port attribute “masterOnly”, TRUE for T-GM-only devices
• New per-port attribute “localPriority”, which can be used to define the
network architecture

• State decision algorithm based on IEEE1588-2008 Fig. 26, with

addition of the “masterOnly” parameter

• Dataset comparison algorithm based on IEEE1588-2008 Fig. 27,

with the removal of priority1, and addition of localPriority
• Order of comparison: signalFail, clockQuality, priority2, localPriority,
stepsRemoved

58
Source Traceability
Uses clockClass attribute to determine phase/time traceability:
defaultDS Frequency Time
Phase/time traceability description
clockClass Traceable flag Traceable flag
T-GM connected to a PRTC in locked mode
6 TRUE TRUE
(e.g. PRTC traceable to GNSS)
T-GM in holdover, within holdover specification 7 TRUE/FALSE* TRUE

T-BC in holdover, within holdover specification 135 TRUE/FALSE* TRUE

T-GM in holdover, out of holdover specification 140/150/160+ TRUE/FALSE* FALSE

T-BC in holdover, out of holdover specification 165 TRUE/FALSE* FALSE

T-GM or T-BC without time reference since start-up 248 TRUE/FALSE* FALSE

Slave only OC (does not send Announce messages) 255 n/a n/a

* Depends if there is a PRC-traceable source of frequency, e.g. SyncE

+ Depends on the QL of any external source of frequency,
or on the quality of the local oscillator 59
 Timing Budget

Company Confidential 60
PDV - Unpredictable delay is the problem

Timing packets have to fight there way through network devices against traffic

61
Packet Delay Variation
• “Green Light” protocol
• Some (small) number of cars will drive through a town with every traffic
light at green, and arrive at their destination with the least delay
• This “minimum delay” is consistent, and cannot be improved (at least,
not without breaking the speed limit)
• The number of cars achieving this “minimum delay” reduces with
congestion
• Same applies to packets in a network
• Queuing in a network element is like waiting at a traffic light
• The more congestion on the network, the less chance there is to avoid
queuing

Company Confidential 62
 Packet Delay Distribution
Frequency of Cluster
occurrence range

Low
congestion

Medium
congestion

High
congestion

Minimum Packet Delay

Delay
Company Confidential 63
Network Limits for Time and Phase Sync

• For networks that don’t have BCs or TCs at every node (known
as “Partial Timing Support” (PTS), the network limit will use the
metric pktSelected2WayTE:

Forward Forward Packet Averaging of

packet delays Selection selected packets
Two-Way pktSelected
Combination 2WayTE
Reverse Reverse Packet Averaging of
packet delays Selection selected packets

Selects fastest N% of Averages delays of Combines the

packets in a Ws-wide the selected packets averaged points
window in each window using the PTP 2-way
offset calculation

Company Confidential 64
 Provisional Time Error Budget for APTS
• Provisionally agreed values for pktSelected2WayTE:
• Percentile selection: 0.5%
• Window size: 100s
• Peak-to-peak Limit: 1150ns
±100ns
• Implicit asymmetry budget: 200ns after calibration by GNSS
(PRTC/T-GM)

±1050ns dTE
(random network variation)

±200ns cTE
(GNSS calibration uncertainty)

±150ns
(end application)

±1.15µs network equipment budget

Company Confidential 65
±1.5µs end-to-end budget
 Possible Time Error Budget for PTS
• Proposed values (not yet agreed) for pktSelected2WayTE:
• Percentile selection: 0.5%
• Window size: 100s
• Maximum Absolute Limit: 1100ns
±100ns
• Asymmetry included within this value
(PRTC/T-GM)

±1000ns dTE
(random network variation)

±250ns cTE
(reference switching)

±150ns
(end application)

±1.1µs network equipment budget

Company Confidential 66
±1.5µs end-to-end budget
INTEGRITY
PTP TIME MEASUREMENTS REQUIRE TRUE PRECISION

Paul Norris
Paul.norris@calnexsol.com
+44 (0) 1506-671-416