# Presentation: 091674

## Clock Synchronization in Audio/Video Bridging Networks using IEEE 1588 Version 2

**Geoffrey M. Garner**
**Kees den Hollander**
**SAIT / SAMSUNG  Electronics**
- _[gmgarner@comcast.net](mailto:gmgarner@comcast.net)_
- _[denhollander.c.j@samsung.com](mailto:denhollander.c.j@samsung.com)__ _
*2006 Conference on IEEE 1588*
- October 2 – 4, 2006
- Gaithersburg, MD, USA

## Outline

- Introduction
- Requirements
- Relation of IEEE 802.1AS and IEEE 1588 V2
- Network examples
- Messages
- Clocks
- Synchronization transport
- Simulation cases and results
- Summary
- Appendices
- References
- Appendix I – End-to-end application reference model example
- Appendix II – Definition of MTIE
- Appendix III – Simulation model details
- Appendix IV - Confidence interval for a quantile of a distribution obtained from samples of the distribution

## Introduction

- Audio/Video Bridging (AVB) refers to a set of standards being developed in IEEE 802.1 to allow the transport of time-sensitive traffic over bridged local area networks (LANs)
- One goal is to allow a single network infrastructure to carry both time-sensitive and non-time-sensitive traffic
- AVB applications will include
- Digital video
- High-fidelity digital audio
- Gaming
- Traditional data traffic (non-time-sensitive)
- Major use (but not the only use) is expected to be in the residence
- Two key AVB requirements
- Guaranteed QoS
- Meet jitter, wander, time synchronization and latency requirements of applications
- Along with end-to-end requirements, must consider reference model(s) to determine allocation to AVB network
- Minimal (or no) administration required by users
- Provisioning should not be required on an ongoing basis

## AVB Standards in IEEE 802.1

- 802.1AS – network synchronization
- PAR approved by NesCom; Draft D0.2 available [2] (many sections still incomplete)
- can be used to transport synchronization in other networks besides AVB networks
- 802.1AU – bandwidth reservation and admission control
- PAR approved by IEEE 802 EC; initial (incomplete) draft available
- Bridge forwarding and queueing behavior
- PAR being developed; planned for 802.1 Chair to submit to EC within 30 days of next meeting
- Guidelines/”Best Practices”
- PAR being developed

## End-to-End Jitter and wander requirements

| Requirement | Uncompressed SDTV | Uncompressed HDTV | MPEG-2, with network
transport | MPEG-2, no networktransport | Digital audio, consumer
interface | Digital audio, professional
interface |
| --- | --- | --- | --- | --- | --- | --- |
| Wide-band
jitter (UIpp) | 0.2 | 1.0 | 50 s
peak-to-peak
phase
variation
requirement
(no
measurement
filter
specified) | 1000 ns
peak-to-peak
phase
variation
requirement
(no
measurement
filter
specified)
 | 0.25 | 0.25 |
| Wide-band
jitter meas
filt (Hz) | 10 | 10 |  |  | 200 | 8000 |
| High-band
jitter (UIpp) | 0.2 | 0.2 |  |  | 0.2 | No
requirement |
| High-band
jitter meas
filt (kHz) | 1 | 100 |  |  | 400 (approx) | No
requirement |
| Frequency
offset (ppm) | 2.79365
(NTSC)
0.225549
(PAL) | 10 | 30
 | 30
 | 50 (Level 1)
1000
(Level 2)
 | 1 (Grade 1)
10 (Grade 2) |
| Frequency
drift rate
(ppm/s) | 0.027937
(NTSC)
0.0225549
(PAL) | No
requirement | 0.000278 | 0.000278 | No
requirement
 | No
requirement
 |

**(see[1] and references given there)**

## End-to-End MTIE requirements

**End-to-End Application Jitter and Wander Requirements**
**Expressed as MTIE Masks [1] (see Appendix II for MTIE definition)**

## Time Synchronization Requirements

- In general, a multi-media stream may contain multiple audio and/or video streams, possibly transported to different locations, e.g.
- Multiple audio tracks from the same program transported to speakers in different locations
- The same audio track transported to multiple speakers simultaneously
- Voice and corresponding video streams from the same program being played simultaneously (lip-synch)
- Video animation with accompanying audio
- Reference [9] describes the results of experiments that investigated the maximum skews that could be tolerated for various types of related streams before degradation in QoS would be perceived
- Lip-synch; Video animation with accompanying audio
- 80 ms
- Tightly coupled audio and images
- 5 ms
- Tightly coupled audio (e.g., audio streams delivered to multiple speakers)
- 10 s

## IEEE 1588 V2 – the basis for IEEE 802.1AS 

- IEEE 1588 Precision Time Protocol (PTP) V2 allows several different network architectures
- Chains of boundary clocks (BCs), possibly with ordinary clocks (OCs) at the endpoints
- Ordinary and/or boundary clocks connected through end-to-end (E2E) transparent clocks (TCs)
- Ordinary and/or boundary clocks connected through peer-to-peer (P2P) TCs
- IEEE 1588 V2 does not support direct connection of P2P and E2E TCs
- Interworking of E2E and P2P TCs must occur through a BC
- IEEE 1588 V2 (like V1) does not contain specifications that guarantee performance (jitter, wander, time synchronization)
- IEEE 1588 V2 allows the definition of profiles for specific applications
- Profile may specify whether certain optional features of IEEE 1588 (e.g., fault tolerance, security enhancements) are used for that application
- Profile may define ranges and default values for various parameters (e.g., clock or port parameters)
- Profile may limit the architectural options that the application may use (e.g., profile may specify that an application shall use only BCs, OCs, and P2P TCs)
- IEEE 1588 V2 (like V1) may be used over a variety of communication technologies
- IEEE 1588 V2 does not address synchronization over wireless networks

## IEEE 1588v2 clock types used in 802.1AS

- Ordinary clock (OC)
- Has a single port
- Can be master or slave; an AVB network will have 1 master (termed the Grandmaster (GM))
- Primary purpose is to provide synchronized time at AV Bridge (wired node) or endpoint (wired or wireless)
- Peer-to-Peer (P2P) Transparent Clock (TC)
- Not part of master/slave hierarchy, but can syntonize (i.e., synchronize in frequency) to Grandmaster
- Primary purposes are to (1) measure residence time of synchronization-related messages that traverse an AVB node (i.e., time between receipt of the message and transmission of the message to another node after any processing), and (2) measure propagation delays between itself and adjacent P2P TCs, BCs, or OCs
- E2E TC
- Not used in 802.1AS
- BC
- Has multiple ports
- At most one port is in slave state; remaining ports are normally in master or passive state
- General 1588 BC is used at interface between 802.1AS and non-802.1AS 1588 network
- Specialized BC (i.e., 1588 BC further specified in 802.1AS PTP profile) used within 802.1AS network, e.g.,
- Interface between wired and wireless 802.1AS network (wireless AP)
- Interface to networks that are not 802 but sufficiently similar that they can use 802.1AS (e.g., MOCA, IEEE 1394)

## Relation of IEEE 802.1AS to IEEE 1588 V2

- IEEE 802.1AS will use a subset of IEEE 1588 V2 to transport synchronization over wired Ethernet (full-duplex, 802.3 links)
- 802.1AS will define a 1588 V2 profile
- Profile will specify which 1588 V2 features and architectural options will be used
- E.g., clocks, messages, optional features, etc.
- Profile will specify ranges and default values for relevant parameters
- IEEE 802.1AS will specify additional requirements to ensure acceptable end-to-end performance for applications
- E.g., node clock requirements, endpoint PLL filter requirements
- IEEE 802.1AS will contain additional specifications for transport of synchronization over 802.11 wireless networks
- IEEE 802.11v messages and procedures will be used to transport synchronization over 802.11 links
- Synchronization will be transported between 802.3 and 802.11 networks through boundary clock
- Wired and wireless networks will use single Best Master Clock Algorithm (BMCA) for Grandmaster (GM) selection; entire 802.1AS network forms a single PTP domain
- See [3] for details of Sync transport in wireless networks (here the focus is on wired networks)
- IEEE 1588 Boundary clock, further specified in 802.1AS profile, will be required at interface between 802.1AS network and non-802.1AS 1588 network

## PTP Devices used in 802.1AS Network 

**A general 802.1AS network**
**does require a P2P TC function**
**to be contained in an AV Bridge**
**A general 802.1AS network in**
**principle need not require an OC **
**function to be contained in an**
**AV Bridge.  In practice an OC**
**function will be present, as the**
**added cost of it is minimal**
**A general 802.1AS network does**
**require a BC function at the**
**interface between an 802.3 and**
**802.11 network (a BC is needed to**
**separate different network**
**Technologies, as various PTP**
**parameters (e.g., Sync interval)**
**may be different)**

## PTP Devices used in 802.1AS Network

- - **An 802.1AS network**
**Requires a BC at the**
**Interface to a non-802.1AS**
**Network**
**The non-802.1AS network**
**might be a PTP network that**
**meets IEEE 1588 V2 but**
**not the particular profile**
**specified in 802.1AS**

## Example Master/Slave Hierarchy in 802.1AS

- -**Entire 802.1AS network**
**forms a single PTP domain**
**-Synchronization hierarchy**
**is determined by BMCA**
**-An OC can be master or slave**
**-A BC port can be master or slave; a BC has at most one port in the**
**PTP_Slave state**
**-A P2P TC is neither master nor**
**slave**
**All devices except P2P TCs**
**process Announce messages**
**-All devices except P2P TCs**
**are capable of issuing Announce**
**messages (and do so when in the**
**PTP_Master state)**

**Note:  the master/slave status at an AV Bridge pertains to**
**the OC or BC function in the**
**Bridge (i.e., not to the P2P TC function)**

## 802.1AS Messages

- PTP message used in 802.3 and 802.11 portions
- Announce (general message)
- PTP messages used in 802.3 portions
- Synch (event message)
- Follow_Up (general message)
- Pdelay_Req (event message)
- Pdelay_Resp (event message)
- Pdelay_Resp_Follow_Up (general message)
- 802.11v messages used in 802.11 portions (see [3] for details)
- Presence Request (message is timestamped)
- Presence Response (message is not timestamped)
- ACK (message is timestamped)

## More on 802.1AS Clocks

- Ordinary Clock
- Peer-to-Peer Transparent Clock
- Boundary Clock
- All clocks will be required to have 100 ppm free-run accuracy
- Not decided yet if there will be a requirement on noise generation and frequency stability for AVB applications
- If there is such a requirement, it will be consistent with the requirement of low cost (e.g., oscillator cost << $1.00) for consumer electronics applications
- For OCs, there will be a single clock quality
- Likely PTP Class 4 (formerly PTP Stratum)
- PTP Clock Identifier will reflect current status of clock, and will be set automatically
- Clock Indentifier indicates local oscillator time source, i.e., source via means other than PTP
- e.g., atomic clock, GPS, NTP, DFLT
- DFLT used for clocks of Class 3 or greater for which the time source is not atomic, GPS, NTP, nor set by hand or by a management procedure of unspecified accuracy
- see 1588 V2 for details

## More on BMCA in 802.1AS

- User will be able to set Priority1 field (externally settable absolute priority)
- User will not set Priority2 field (externally settable priority considered after Priority1, Class, Clock Identifier, Variance, and whether one clock is a BC)
- Best master selection in 802.1AS network will not be influenced by Class, Clock Identifier, Priority2, or Variance
- The extent to which an 802.1AS OC can execute a simplified BMCA yet preserve interoperability with non-802.1AS PTP networks through BCs is being investigated
- May assign default values to Priority2 and Variance

## Measurement of Prop Time on an 802.3 Link

- Propagation times are measured using the Pdelay mechanism
- The mechanism is executed independently in both directions (the figure below (adapted from [7]) shows only one direction to simplify the presentation)

***t******mean-prop***** is the propagation**
**time if the propagation times**
**in the two directions are the**
**same**

## Synchronization through P2P TCs

- In current Draft, both on-the-fly and follow-up operation are allowed
- On-the-fly operation is not required
- However, as will be seen below, allowing on-the-fly operation does add to the operations a follow-up P2P TC must do
- There have been suggestions to only allow follow-up operation (e.g., in AVB, or in all 802.1AS networks)
- The description below assumes on-the-fly operation is allowed
- The holding of a Sync message until a corresponding Follow_Up message arrives (described shortly) is specific to 802.1AS (I.e., is allowed but not required by 1588)
- Master sends Sync, and timestamps it with time *t*1
- If master is not on-the-fly, it places *t**1* value in Follow_Up message (and sets PTP_ASSIST) bit of Sync message to 1
- Each P2P TC timestamps the Sync message when it arrives (with time *t**a*) and the time it eventually departs (with time *t**d*)
- The P2P TC computes the residence time as *t**r* = *t**a* – *t**d*
- The residence time measurement is done for each outgoing link that the Sync message is transmitted on
- 802.1AS will use multicast Sync messages, potentially transmitted to multiple OCs

## Synchronization through P2P TCs

- An on-the-fly P2P TC does the following for each link the Sync message is transmitted on:
- Adds the measured residence time for the Sync message and the measured propagation delay for the link on which the Sync message arrived to the correction field of the Sync message as it is transmitted
- If a corresponding Follow_Up message exists (i.e., if one or more upstream devices are not on-the-fly)
- The Sync message is held until the Follow_Up message arrives (and its measured residence time reflects this)
- The Follow_Up message is transmitted unaltered
- A follow-up TC does the following for each link the Sync message is transmitted on, if the PTP_ASSIST bit of the Sync message is set to 1:
- The Sync message is held until the corresponding Follow_Up message arrives
- The content of the correction field of the Follow_Up message is added to the correction field of the Sync message
- The Sync message is sent and timestamped
- The sum of the measured residence time for the Sync message and the measured propagation delay for the link on which the Sync message arrived is placed in the correction field of a new Follow_Up message

## Synchronization through P2P TCs

- A follow-up TC does the following for each link the Sync message is transmitted on, if the PTP_ASSIST bit of the Sync message is set to 0:
- The Sync message is not held; its PTP_ASSIST bit is set to 1, and it is queued to be sent immediately
- The Sync message is sent and timestamped when it is sent
- The sum of the measured residence time for the Sync message and the measured propagation delay for the link on which the Sync message arrived is placed in the correction field of a Follow_Up message that is generated
- The arrival of the Sync message at the slave is timestamped with time *t*2
- The slave offset is computed as
*t*2* *– *t*1 – (sync_correction_field) – (followup_correction_field) – (prop_time_on_last_link)

## Synchronization through P2P TCs

- Example of timing of transport of Sync and Follow_Up messages through a network, illustrating the holding of a Sync message until the corresponding Follow_Up message arrives

## Synchronization through P2P TCs

- Example of timing of transport of Sync and Follow_Up messages through a network, illustrating the accumulation of multiple Sync messages at P2P TCs if Follow_Up messages are not held
- This accumulation would occur in AVB networks if Sync messages are not held due to much longer processing time for Follow_Up than Sync in potential processor for AVB NE

## Syntonizing a P2P TC to the Grandmaster

- P2P TC will be required to meet specified requirements (e.g., frequency accuracy, etc.)
- Can meet the requirement by syntonizing (I.e., synchronizing in frequency) the P2P TC to the GM
- However, 802.1AS allows the requirement to be met in any manner the designer chooses (e.g., could provide a sufficiently high quality oscillator)
- If the P2P TC is syntonized, it is done as follows:
- The frequency offset of the GM relative to the P2P TC is measured every *M**th** *Sync message (at present, *M* = 10)
- For every *M**th** *Sync message, estimate the GM time when the Sync message is received as the sum of
- The time the Sync message was sent by the GM (contained in its timestamp)
- The total time to reach the current node (computed as the sum of the correction fields in the Sync and corresponding Follow_Up message
- The P2P TC clock time when the Sync message arrives is timestamped
- The frequency offset offset of the GM relative to the P2P TC is measured by computing the elapsed P2P TC clock time and GM clock time for the interval of *M* Sync messages
- The P2P TC frequency is adjusted
- May be implemented in hardware or software

## Endpoint Filtering

- All stringent filtering (e.g., using phase-locked loops (PLLs)) will be performed at endpoints
- This will allow the expense of the filtering to be associated with end applications that require it
- Different applications have different jitter, wander, and time synchronization requirements
- E.g., uncompressed digital video requirements are most stringent, followed by high-fidelity digital audio, followed by compressed (e.g., MPEG-2, MPEG-4) digital video
- Filter requirement will be expressed using a transfer mask, with specified equivalent 3dB bandwidth, gain peaking, roll-off, and frequency range over which the requirement applies

## Endpoint Filtering

**Illustration of transfer requirement mask for endpoint filter**

## 802.1AS Architecture for AV Bridge with Wired Interfaces

**Current 802.1/802.3 layering based on “baggy pants” model**
**Figure and text below is taken from [4], with some modifications**
**Additional modifications are possible (work is in progress)**

- 802.1AE MACsec

- 802.1AE MACsec

- 802.3 MAC

- 802.3 PHY

- 802.3 PHY

- 802.3 MAC

- PTP TS filtering

- PTP TS filtering

- 802.3 Clause 43 Link Aggregation

- Bridge Port Transmit and Receive

- Support of EISS (Q-tagging)

- Queueing

- LLC

- LMI

- oSyncPort

**Notes:**
- 1- No link aggregation for now
- 2- No per VLAN timing distribution (One 1588 domain only)
- 3- Queueing is above the MAC layer, for relay function only
- 4- oSyncPort (ISO/IEC 10040 managed object)
-     a- Generates a TS notification event for every frame header received
-        - Start of frame last bit/destination address first bit
-        - TS notification MUST be generated within specified delay
-     b- TX side: Generates TX complete or TX fail notifications to TS agent
-        - TS agent relays these notifications to PTP TS filtering
- 5- Local TS agent generates timestamp based on local counter/clock
- 6- PTP TS filtering
-    o Filters TS values, passing only  the ones related to specific
-       PTP frames to PTP state machine(s)

- TS

- TS

- agent

- ISO/IEC event notification

- Timestamp based on
- syntonized clock

- PTP Messages

## 802.1AS Architecture for AV Bridge with Wired Interfaces – PTP MAC Client (taken from [4] and modified; work is in progress)

- Bridge Port Transmit and Receive

- Support of EISS (Q-tagging)

- Queueing

- LLC

- PTP relay entity
- and residence time
- measurement

- LMI

- TS

- agent

- PTP msg mux/demux

- PTP TS filtering

- PTP Delay Entity

- PTP syntonization entity

- PTP synchronization entity (includes offset computation)

- PTP BMC selection entity

- Sync,
- Follow_Up

- Pdelay_Req,
- Pdelay_Resp,
- Pdelay_Resp_Follow_Up

- Announce

- PTP Master/ Slave
- Sub-layer (BC / OC)

- PTP TC Sub-layer

- PTP mux/demux

- PTP Messages

- time stamp based
- on syntonized clock
- (syntonized clock
- Must satisfy AVB
- Accuracy
- requirements)

- measured delay
- value

- TS

- ISO/IEC notification

**Dotted entities**
**and arrows may**
**or may not be**
**present**

- syntonized time

- Bridge Port Transmit and Receive

## Simulation Cases

- Parameters common to all simulation cases
- Free-run clock accuracy =  100 ppm
- Initialize frequency offset of each clock randomly within this range
- Phase measurement granularity = 40 ns (25 MHz free-running clocks)
- Frequency measurement granularity = 2.3283 x 10-10 (32 bit accuracy)
- Consider up to 10 hops (AVB will require 7 hops; we exceed that to see how much MTIE increases beyond 7 hops)
- Sync interval = 10 ms
- Frequency update interval = 100 ms
- Pdelay turnaround time (t3 – t2 on slide 10) = 1 ms
- Free running clock has phase noise modeled as in [5]
- Endpoint filter is 2nd order, with 0.1 dB gain peaking
- Asymmetry in PHY latency and cable delay not modeled

## Simulation Cases

- Case 1
- 3 dB bandwidth = 1 Hz
- Case 2
- 3 dB bandwidth = 0.1 Hz
- Case 3
- 3 dB bandwidth = 0.01 Hz
- In all cases, MTIE is computed after the initial phase transient has decayed
- Ran 300 independent replications of each simulation case to obtain confidence intervals for the 0.95 quantile of MTIE
- See Appendix IV for details of estimation procedure

## Case 1 Simulation Results

## Case 2 Simulation Results

## Case 3 Simulation Results

## Comparison of Results – Nodes 1 and 7

## Discussion of Results - 1

- Meeting the requirements for uncompressed digital video requires a filter bandwidth not much more than 0.01 Hz
- Digital audio and compressed digital video requirements are met with 1 Hz filter
- The amount of margin present indicates may be able to use a bandwidth between 1 and 10 Hz
- But note that asymmetry in PHY latency is not modeled; more analysis is needed to determine actual requirement
- Compressed digital video (i.e., MPEG-2, MPEG-4) can likely be met with bandwidth wider than 10 Hz

## Discussion of Results - 2

- Examination of the computed residence times and propagation time errors indicated that the main contribution to phase error is the effect of the 40 ns phase measurement granularity
- The results for a single hop are much better than those for multiple hops because, for a single hop, residence time is not used
- Each residence time measurement is truncated to the next lower multiple of 40 ns
- The truncated errors accumulate; when they reach 40 ns, the residence time measurement jumps by 40 ns
- On the next residence time measurement, i.e., the next sync interval, the residence time jumps back to its previous value, which is 40 ns smaller
- The resulting residence time measurement history is approximately constant, with 40 ns pulses that last for 1 sync interval occurring at some frequency
- In the worst case, we may assume that the time between successive pulses is much longer than the endpoint filter time constant
- Since the pulse time is much shorter than the filter time constant for the bandwidths considered here (e.g., the shortest filter time constant is 1/[(2)(1 Hz)] = 0.16 s, while the pulse width is equal to the sync interval, or 0.01 s), the pulses may be modeled as impulses input to the filter

## Discussion of Results - 3

- Consider a linear, 2nd order filter with undamped natural frequency *n*, damping ratio , and 20 dB/decade roll-off
- The transfer function is given by
- The impulse response may be obtained by taking the inverse Laplace Transform of the transfer function; the result is
- The impulse response of this filter takes on its maximum value at time zero
- The maximum value is equal to 2*n*
- Since the phase measurement is always truncated to the next lower multiple of 40 ns, the filtered phase error contribution of one node is equal, in worst case, to 2*n*(40 ns)

## Discussion of Results - 4

- Can use this as a rule of thumb to conservatively estimate the MTIE contribution from phase measurement granularity at one node
- For example, for a 0.1 Hz filter with 0.1 dB gain peaking, the undamped natural frequency and damping ratio are 0.071781 rad/s and 4.3188, respectively
- The filtered phase error due to a 40 ns impulse is 0.62 ns
- Long-term MTIE for 10 nodes for this case is approximately 2.8 ns for the 0.95 quantile estimate based on 300 runs (slide 29)
- The 300 runs also did not produce any instances where the pulses from all 10 nodes lined up in time
- If the pulses from all 10 nodes lined up in time, the resulting long-term MTIE for node 10 would be on the order of 6.2 ns
- Note that while the rule of thumb gives an estimate of long-term MTIE, it does not give MTIE as a function of observation interval and, in particular, short observation intervals
- Simulation is necessary to obtain the actual MTIE performance for various observation intervals, and also to include other effects (e.g., errors in propagation delay measurement, errors due to asymmetries in cable delay and PHY latency)

## Summary

- IEEE 802.1AS is being developed by the 802.1 AVB TG
- Will use a subset of IEEE 1588 V2, and add
- Specification of various 1588 parameters and which options are used (i.e., specify 1588 profile)
- Guarantee end-to-end application performance
- Transport synchronization over 802.11 wireless network portions
- Transport synchronization in wired network portion using peer-to-peer transparent clock
- Interface between wired and wireless network portions and between 802.1AS and non-802.1AS networks contains a boundary clock
- Initial simulation results show that end-to-end performance requirements for Audio/Video applications in a residence can be met

## References

- Geoffrey M. Garner, *End-to-End Jitter and Wander Requirements for ResE Applications*, Samsung presentation at May, 2005 IEEE 802.3 ResE SG meeting, Austin, TX, May 16, 2005. Available via http://www.ieee802.org/3/re_study/public/index.html.
- IEEE P802.1AS/D0.2, *Draft Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks*, September 10, 2006.
- Kevin Stanton, *Clock Synchronization over 802.11 for Home A/V Applications*, 2006 Conference on IEEE 1588, Gaithersburg, MD, USA, October 2 – 4, 2006.
*Time Synchronization and 802 Models*, contributors include Dirceu Cavendish, George Claseman, Geoffrey Garner, Franz-Josef Goetz, and Kevin Stanton, presentation for IEEE 802.1 AVB wireless group conference calls, available at _[http://www.ieee802.org/1/files/public/docs2006/as-](http://www.ieee802.org/1/files/public/docs2006/as-cavendish-802ModelforTS-060911.pdf)__[cavendish](http://www.ieee802.org/1/files/public/docs2006/as-cavendish-802ModelforTS-060911.pdf)__[-802ModelforTS-060911.](http://www.ieee802.org/1/files/public/docs2006/as-cavendish-802ModelforTS-060911.pdf)__[pdf](http://www.ieee802.org/1/files/public/docs2006/as-cavendish-802ModelforTS-060911.pdf)_.
- Geoffrey M. Garner and Kees den Hollander, *Analysis of Clock Synchronization Approaches for Residential Ethernet*, 2005 Conference on IEEE 1588, Winterthur, Switzerland, October 10 – 12, 2005.

## References

- ITU-T Recommendation G.810, *Definitions and Terminology for Synchronization Networks*, ITU-T, Geneva, August, 1996, Corrigendum 1, November, 2001.
- IEEE P1588TM/D1.2, *Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems*, September 18, 2006.
- Athanasiois Papoulis, *Probability, Random Variables, and Stochastic Processes*, Third Edition, McGraw-Hill, 1991, pp. 254 – 255.
- Ralf  Steinmetz, *Human Perception of Jitter and Media Synchronization*, IEEE JSAC, Vol. 14, No. 1, January, 1996.

## Appendix I - Application Reference Models

**Example Reference Model for Transport of MPEG-2 Video over**
**Service Provider Networks and 802.1AS Network [1]**

## Appendix II – Definition of MTIE

- Jitter and wander requirements can be expressed in terms of Maximum Time Interval Error (MTIE) masks
- MTIE is peak-to-peak phase variation for a specified observation interval, expressed as a function of the observation interval
- An estimate of MTIE may be computed by (see [6])
- The derivation of the MTIE mask on slide 5 from the jitter and wander requirements on slide 4 is given in [1]

## Appendix III - Simulation Model

- The figure below shows synchronization transported from a Grandmaster (GM), through a chain of P2P TCs, to a slave clock (this figure shows the case of a GM and 3 additional nodes)
- The slave offset is computed when a Sync and corresponding Follow_Up message are received by the slave
- Where
*t*2 = time that the Sync message is received by the slave
*t*1 = time that the Sync message is sent by the GM

## Appendix III - Simulation Model

- The total_propagation_plus_residence_time is given by
- The GM time *t*1 is assumed to be perfect (and therefore has zero phase error)
- The times *t**2*, as well as the *t**ri* used to compute residence times, are taken from the syntonized P2P TC time.  This is computed from the free-running P2P TC phase
- The method is summarized on the following 2 slides
- The model requires the free-running P2P TC phase as input
- It is expected that, in practice, timestamps will be based on the syntonized time and not the free-running time
- The model will be modified to take this into account; it is expected to have negligible impact on the results

## Appendix III - Simulation Model

- GM time estimate, corresponding to time Sync is received at TC is
- Let
*t**GM*,*i* = estimated GM time at sync interval *i* based on the received Sync and Follow_Up messages
*t**b*,*i*  = time indicated by free-running oscillator in P2P TC
*y**TC*,*i* = measured frequency offset of GM relative to free-running oscillator in P2P TC
*   **t**f*,*i* = syntonized time, synthesized from the measured frequency offset and the time indicated by the  free-running P2P TC oscillator
- Then

## Appendix III - Simulation Model

- The syntonized time is synthesized by assuming that the frequency offset of the GM relative to the TC has been constant and equal to the current measurement since the last measurement was made.  Then
- May solve for syntonized time
- The syntonized time is used to
- Measure residence time
- Measure propagation delay
- Measure *t**2*

## Appendix III - Simulation Model

- The free-running clock phase error is computed based on frequency offset (initialized randomly at initialization of the simulation run within the input frequency tolerance range), and the clock noise model described in [5] (and based on the references given there)
- The simulation model computes only phase errors relative to the GM, which is assumed to be perfect
*t*2 and the *t**ri* are syntonized clock phase offsets
- Nominal residence time is assumed to be one sync interval
- It is assumed that each Sync message is held at a TC until the corresponding Follow_Up message arrives
- In worst case, the Follow_Up message takes on the order of a Sync interval to arrive (Follow_Up messages must be transported at least at the same average rate as Sync messages, otherwise there would be a monotonically increasing backlog of Sync and Follow_Up messages to process
- Time at each node is shifted by the nominal propagation delay (this is equivalent to setting nominal propagation delay to zero) and only propagation delay measurement error is modeled
- This is valid because, if propagation delay could be measured perfectly, it could be corrected for perfectly.  Any remaining error is due to the propagation delay error
- Using the figure on the next slide (adapted from [7]) to illustrate the exchange of Pdelay messages, the propagation delay error can be modeled

## Appendix III - Simulation Model

- Propagation delay error = 0.5*(t3 –t2) * (frequency offset between the nodes)
- Frequency offset is computed over one sync interval, using the syntonized timer values
- The Pdelay turnaround time, t3 – t2, is specified as an input parameter by the user
- 1 ms is used in the cases here

## Appendix IV – Confidence Interval for a Quantile of a Distribution Obtained from Samples of the Distribution

- Note:  The material in this Appendix is contained in standard references on Probability and Statistics; e.g., see [6]
- Let *X**i*, *i* = 1, 2, ..., *N* be samples of a population.  In the case here , *X**i* is a sample of MTIE for a particular observation interval *S*.  For convenience, we omit writing the *S* dependence explicitly (i.e.,* *we should really write *X**i*(*S*) )
- Assume the samples are independent of each other.  Since the samples are of the same population, they are identically distributed
- Assume the samples have been placed in ascending order, i.e.,
- Let *x**** *be the ***th** *quantile of the population distribution.  The event
- occurs if at least *r* and at most *s*-1 of the samples are less than *x****. *The probability that any sample is less than *x**** *is ***.*

## Appendix II (Cont.)

- Then the probability that *X**r*  *x**** * *X**s* is
*** *= 0.95 for the 0.95 quantile.  For *N* = 300, *r* = 275, and *s* = 294, computation of the above binomial sum gives
- I.e., this is a 99% confidence interval for the 0.95 quantile