2007 International IEEE Symposium on Precision Clock Synchronization (ISPCS)for Measurement, Control and CommunicationVienna, Austria, October 1-3, 2007.

Provision of Precise Timing via IEEE 1588 Application Interfaces

John EidsonAgilent Technologies, Inc.

5301 Stevens Creek Boulevard, MS: 54U-SMSanta Clara, CA 95051-7201j ohn_eidson@ agilent.com

Geoffrey M. GarnerSamsung Advanced Institute of Technology

(SAIT)196 Ambassador Drive

Red Bank, NJ 07701, USA.gmgLarnler@comncast.nlet

Abstract

The protocol specified in IEEE 1588, together with aprofile, define a timing system that may be used tosupply precise timing to applications. However, IEEE1588 does not say anything about the interface to theapplications. In designing this interface, the applicationperformance requirements (e.g., jitter, wander, timesynchronization) must be considered. For example, anapplication that requires microsecond or better timesynchronization needs a hardware or firmwareinterface; a software interface can result in exceedingthe synchronization requirement by a factor of 1000 ormore. This paper describes the performancerequirements of example applications. It then describesa general application interface in abstract terms.Finally, it describes realizations of the interface that canmeet the performance requirements for selectedapplications.

1. Introduction

IEEE 1588 contains detailed specifications of thePrecision Time Protocol (PTP) which, together withspecification of a PTP profile, defines a timing systemthat may be used to supply precise timing toapplications. However, IEEE 1588 does not sayanything about the interface to the applications. Indesigning this interface, the application performancerequirements (e.g., jitter, wander, time synchronization)must be considered. For example, an application thatrequires microsecond or better time synchronizationneeds a hardware or firmware interface to theapplication; a software interface can result in exceeding

John MackayProgeny Systems Inc.

106 Simko Boulevard Suite 107Charleroi, PA 15022

Veselin SkendzicSchweitzer Engineering Laboratories

2350 NE Hopkins Court,Pullman, WA 99163, USA

Veselin_Skendzic@ selinc.com

the synchronization requirement by a factor of 1000 ormore.

The protocol and profile together must specify asystem of clocks that meets the application performancerequirements. Any timing errors introduced by theapplication interface to the clocks must not result in thefailure to meet these application requirements. Theapplication interface is beyond the scope of IEEE 1588and PTP profiles, although the specification of such aninterface is not excluded from inclusion in a PTP profile.

This paper is organized as follows. First, theperformance requirements of selected exampleapplications are described. Then, general applicationinterfaces are described in abstract terms. Next, examplerealizations of some of the interfaces, that can meet theperformance requirements for selected applications, aredescribed. Finally, conclusions are given.

2. Application performance requirements

A number of planned applications of IEEE 1588 willhave stringent jitter, wander, and/or time synchronizationrequirements. As a first example, synchronization forAudio/Video Bridging (AVB) networks will be providedusing the emerging IEEE 802.1AS standard [1], whichwill include a PTP profile. Jitter and wanderrequirements for selected video and audio applicationsthat are expected to be carried by AVB networks aresummarized in Table 1, which is derived from [2].Figure 1 shows these requirements in the form ofmaximum time interval error (MTIE) masks. MTIE fora timing signal is defined as peak-to-peak phase error forall observation intervals of a given length, expressed as afunction of observation interval (see [2] for thederivation of the MTIE masks from the jitter/wanderrequirements). The uncompressed digital video signals

1-4244-1 064-9/07/$25.00 ©2007 IEEE 1

have the most stringent requirements, i.e., peak-to-peakjitter less than 1 ns and wander of 1 gs or less forintervals of 10 s or less. The requirements for digitalaudio signals are slightly less stringent, i.e., peak-to-peakhigh-band jitter less than 10 ns and peak-to-peak wide-band jitter on the order of 400 ns, though with differentranges of observation interval for consumer andprofessional applications due to their different jittertolerance requirements (see [2] and references cited therefor details). Finally, AVB networks will be required toprovide time synchronization of 1 gs over 7 hops [3].

As a second example, telecommunications serviceproviders have traditionally provided syntonization towireless base stations via dedicated facilities (mainlyPDH and SONET/SDH) or GPS where it is practical touse. However, service providers are increasinglyintroducing Ethernet into their networks; an alternativemeans of syntonizing the base stations is needed insituations where use of GPS is not practical. Finally,some of the wireless technologies require that the basestations be synchronized as well as syntonized; theseinclude CDMA, CDMA2000, WCDMA TDD, as well asWiMax, High Speed Downlink Packet Access, andwireless networks that use pico- and femto-base stationswith smaller cell sizes. The base station timingrequirements for various wireless technologies aresummarized in Table 2, and equivalent MTIE masks aregiven in Figure 2. Figure 2 also shows, for comparison,the uncompressed HDTV MTIE mask from Figure 1. Itis seen that the jitter and short-term wander requirementsfor the wireless base station technologies (with theexception of TDMA) are on the same order as those forthe most stringent AVB applications.

As a third example, in the field of test andmeasurement it is useful to generate a timestamp when ameasurement is made to facilitate post-collection dataanalysis. The required timestamp accuracy ranges frommilliseconds for thermal measurements to a fewnanoseconds or better for high speed digitizers, networkanalyzers, and RF instruments. For example, modernA/D converters can sample at 40GS/s. A timestampindicating the starting time of a 512 point sample used togenerate a spectrum should be accurate to a fewnanoseconds to unambiguously identify the sample.

Test instrumentation often requires the distribution ofsignals, typically 10 MHz, used to generate time orfrequency-based measurement. It is highly advantageousfor these signals to be synchronous with the PTP clocksso that all instrumentation shares the same measure ofthe second. This permits correlation of measurementssuch as the timing on a scope display, the frequencymeasured with a spectrum analyzer, and the output of acounter. In many applications there is a legal or industryrequirement that these measurements be traceable tointernational standards.

As a fourth example, hardware-in-the-loop (HITL)testing requires time synchronization between real-time

physical events and data logging software functions towithin 100 ns. Multi-sensor data sampling andcorrelation functions require frequency offset within±0.10 ppm and high frequency jitter in the sub-ns rangefor sample clocks, with time synchronization among dataprocessors to within 1 ns.

Finally, some applications also need access toprecision timer based services with which external actionmay be initiated at a predetermined absolute time or at apredetermined offset from some run time event.Examples include switch closures in high powersystems, mechanical actuators in high-speed machinery,and test signal generation in stimulus-responsemeasurements. The required temporal accuracies aretypically 1-50 gs for mechanical applications to sub-sfor electronic applications.

Application timing tolerances can be expected tobecome more stringent as new applications of timedistribution systems emerge. This will require increasingattention to the application-time distribution interface.

3. Abstract application service interfaces

Figure 3 [4] illustrates a basic abstract serviceinterface between an application that receives time fromPTP, and the PTP layer of a network element. Theservice primitives that flow across this interface aremeant to show only the information transferred; theprimitives are not an API and say nothing about theimplementation (hardware, software, etc.). Theapplication sends a request primitive to the PTP layer,and the PTP layer provides the application the time in anindication primitive. The request primitive contains noparameters; its purpose is to signal an event. Theindication primitive contains one parameter, namely, thetime of the event.

Figure 4 illustrates a similar exchange of primitivesfor the case where the PTP layer receives timing from anexternal timing source (e.g., GPS) through a means otherthan PTP. The application sends a request primitive tothe PTP layer. The request primitive contains a singleparameter, namely, the time of the event signalled by thesending of the primitive.

In the abstract service interfaces of Figures 3 and 4,the service primitives are sent from the sender to thereceiver in zero time. This means that in the case wherethe PTP layer provides time to the application, it canprovide the time of the event that constitutes its receiptof the request primitive. In the case where the PTP layerobtains time from the application, the application canprovide the time of the event that constitutes the sendingof the request primitive. However, in real hardware orsoftware interfaces the transmission of information froma higher layer to a lower layer (or vice-versa) does notoccur in zero time. To ensure that the respectiveperformance requirements are met, the respectivestandard for the application must clearly define each

2

request event, and specify the timing requirements forthe interface and/or detailed hardware requirements forthe interface.

The above interface for the providing of time by PTPto an application is referred to as an event captureinterface [1], because it provides the time of a signalledevent. Alternatively, an application can ask for the PTPlayer to signal an event at a time specified by theapplication. This is referred to as a trigger-generationinterface [1]. If Figure 3 is used to represent thisinterface, the request primitive carries a singleparameter, namely, the time that the application desiresthe event to be signalled, and the indication primitivesignals the event and contains no parameters. Theindication primitive is assumed to be sent from the PTPlayer to the application in zero time in the abstractinterface; the application standard must specify detailedtiming and/or hardware requirements for the interface toensure that the timing requirements are met.

The trigger-generation interface must consider twosituations that do not arise for the event captureinterface: (a) the time carried in the request primitive isearlier than the time the PTP layer receives the request,and (b) the time carried in the request primitive is veryfar in the future relative to the time the request is sent. Ifthe above description for the trigger-generation interfaceis used, the first situation results in no indication beingsent, and the second situation results in the applicationwaiting a potentially long time for the indication. If thisbehavior is not desired, the application must clearlyspecify the desired behavior (and, if necessary, defineadditional primitives and/or parameters).

One example of the use of the event capture andtrigger-generation interfaces is given by the mapping ofa digital audio stream into frames for transport across anAVB network. The PTP clock is used to generate atimestamp that corresponds to the mapping of aparticular byte position in the frame. This timestamp iscarried in the frame, and is used at the egress to computethe presentation time for the information. Thepresentation is made at that time using the PTP clock.At the ingress, the transition associated with the arrivalof the leading edge of the byte that will map into therespective position in the frame constitutes an event thatis signalled using the event capture interface. The valueof time corresponding to this event can be provided in aregister, as a realization of the indication primitive of theevent capture interface. At the egress, the computedpresentation time is provided to the PTP layer via theindication primitive of a trigger-generate interface. Anevent is generated at that time, and signalled to theapplication via the indication primitive of the trigger-generate interface.

The above interfaces allow the time of a single event,or the single event corresponding to a given time value,to be provided. Interfaces that have additionalfunctionality are possible. For example, the application

may request a sequence of periodic events. In a clock-generator interface [1], the application provides, in arequest primitive, the desired rate at which it wants toreceive events, and a time offset used to determine whenthe sequence of events should start. The PTP layer sendsa sequence of indication primitives, with each containingthe time of the event that constitutes the sending of thatprimitive. In [1], the indication primitives are sent bythe PTP layer when the PTP time minus the time offsetis equal to an integral number of periods as determinedby the desired rate provided by the application.Reference [1] also describes a cross-timestamp interface,where an application provides a sequence of events(which are not necessarily periodic) and the PTP layertimestamps these events. The PTP layer provides to theapplication the time and event index of the most recentevent when the application sends a separate requestprimitive (i.e., separate from the stream of requestprimitives signalling the events that are time stamped).

4. Example interface realizations

Figure 5 shows an example where the event captureinterface is implemented in hardware to achieve the besttiming accuracy. In this example, the basic mechanismof Figure 3 is used to provide a timestamp marking thestarting time of a 512 point sample used to generate aspectrum. Although conceptually simple, such aninterface can be quite difficult to implement. Foraccuracies in the ns range, the propagation delaybetween the request event which occurs at the A/Dconverter and the latch must be accounted for. Therepetition rate of request primitives is also critical. In thisexample it is very common for the interval betweenrequest primitives to be less than the achievable reactiontime to the indication primitives since the latter isusually a function of operating system timing. This willrequire the indication primitive mechanism to includesome sort of buffering and event identification strategyand in some cases an exception strategy. Considerationmust also be given to request primitive duration, i.e.pulse width, and rise times.

Similar concerns arise in implementing the trigger-generation model illustrated in Figure 6. The applicationmust specify the behavior when the requested triggertime or, worse yet, trigger times are in the past. Forexample, if the comparator is based on greater-than logicthen past times will generate an indication. There willalso be application requirements on indication durationthat will necessitate either additional circuitry after thecomparator or modification of the comparator itself.Using a comparator based on equal-to logic mustaccount for possible missing codes in the IEEE 1588clock, which may occur if clock rate adjustment isimplemented using pulse addition or swallowingtechniques. Event times in the future will, in general,require not only the generation of the event as an

3

external hardware signal but also notification to thesoftware portion of the application that the event hasoccuffed.

In many applications the required timestamp ortrigger event generation accuracy will exceed theresolution of the IEEE 1588 clock, which is typicallylimited by the frequency of the oscillator driving thecounter forming the clock time register. This can be done(for example, in oscilloscopes that measure picosecondswithout being equipped with terahertz oscillators), butwill further complicate the application-clock interfacedesign.

In some applications, the times at which the requestprimitive of Figure 3 is invoked are syntonized to thePTP clock. For example, an application may involve thesampling of data at a rate syntonized to a PTP clock, andthe time stamping of each sampling event. In this case,the request primitive is implicitly invoked with eachsampling event. Both the timestamp and the samplemarker are synchronized and syntonized, respectively, tothe PTP clock. To ensure that the respectiveperformance requirements are met, the respectivestandard for the application must clearly define therequest, i.e., sampling event, and specify the timingrequirements for the interface and/or detailed hardwarerequirements for the interface. Figure 7 illustrates anexample of this, in which a multi-channel continuousdata source must be synchronously sampled. The PTPclock is used both to generate a timestamp thatcoffesponds to the start of the sample period, and togenerate the sample trigger. The marker signal is arealization of the request primitive, and the timeprovided by the latch to the application is a realization ofthe indication primitive. Sampled data is buffered acrossall channels one sample at a time, with the buffer taggedwith the corresponding timestamp. This timestamp isused at the egress to correlate the sampled data duringsignal processing. This permits the sampling andbuffering process to be distributed across severalprocessing elements, or the sampling of multiple datasources synchronously. In a similar fashion, a timecompare service can be used to initiate time scheduledevents (including both single and repetitive eventscheduling services).

5. Conclusion

This paper has outlined the performance requirementsof typical applications using high precision timingservices. Abstract models of the application-clockinterfaces and practical realizations of these have beendiscussed. At the present time there are three primitiveinteraction models common to applications: thetimestamping of events, the generation of time triggers,and the generation of periodic signals synchronized tothe timing service clock.

While the interface design for each of theseinteractions for a given level of accuracy is relativelystraightforward, individual applications are morecomplex and include issues of multiple interfaces to theclock, small time intervals between request andindication primitives, exception handling, andinteractions between application software andapplication hardware.

As application timing accuracy requirementsinevitably become more stringent, it becomes moredifficult to implement the IEEE 1588 clock andassociated timing services. The basic timing elementsused in IEEE 1588, or any other network-based timeservice, will be required to move as close as possible tothe network interface to reduce the effects of jitter in theprotocol stack. This shift will require rethinking thearchitectural boundaries between the applicationsoftware and hardware components and between theapplication and the IEEE 1588 clock. The currentgeneration of vendor silicon ranges from all applicationservices internal to the silicon to silicon that providesonly the basic signals to implement IEEE 1588 witheverything else external.

The experience gained in the first round ofapplications based on the emerging silicon will becrucial in optimizing the architectural trade-offs and thedesign of the application to clock interfaces discussed inthis paper.

6. Acknowledgment

The authors would like to acknowledge ChuckHarrison for having provided information in clause 9 of[1] and in [4] that is used here in section 3.

References

[1] IEEE P802.1AS/Dl.0, Draft Standard for Local andMetropolitan Area Networks - Timing andSynchronization for Time-Sensitive Applications inBridged Local Area Networks, Draft DI.0, July 27, 2007.

[2] Geoffrey M. Garner, End-to-End Jitter and WanderRequirements for ResE Applications, Samsungpresentation at May, 2005 IEEE 802.3 ResE SG meeting,Austin, TX, May 16, 2005. Available via

[3] Don Pannell, Audio/Video Bridging (AVB) Assumptions,July 17, 2007, available at

[4] Chuck Harrison, Information on application serviceinterfaces provided to the IEEE 802.1 AVB TG, April,2007 (available at

4

Table 1. End-to-end jitter and wanderrequirements for A/V applications (see [2] andreferences given there)Require- Uncom- Unco- MPEG-2, MPEG-2, Dgia Digitalrnent pressed pressed with no network audio, audio,

SDTV HDTV network transport consurer professionaltransport interface interface

Wide-band 0.2 1.0 50 is 1 pLs 0.25 0.25jitter (UIpp) peak-to- peak-to-

peak peakWide-band 10 10 piae phse 200 8000

Jitternneas vanation variationfiIt (Hz) requirenent requirennentHigh-band 0.2 0.2 (no (no 0.2 Nojitter (UIpp) measure- measure- req uirerent

nnent nnentHigh-band 1 100 filter filter 400 Nojitter neas specified) specified) (approx) requirenentfilt (kHz)

Frequency ±2.79365 +1 0 +30 +30 +50 ±1 (Gradeoffset (NTSC) (Level 1) 1)(ppn) +0.225549 +1000 ±10 (Grade

(PAL) (Level2) 2)

Frequency 0.027937 No 0.000278 0.000278 No Nodrift rate (NTSC) require- require- requirement(ppm/s) 0.0225549 ment ment

(PAL) I_I

Table 2. Timing requirements for wireless basestationRequirement TDMA CDMA GSM CDMA200 WCDMA WCDMA

0 FDD TDD

Maxiumm 05 005 005 005 005 005FrequencyOffset (ppm)Maximum No + 10 48/13 + 10 No 2.5P hase Offset requ ire- (relative (GSM (relative to requ ire- (relative to(jlS) ment to UTC) COMPACT; UTC) ment otherbase

relative to stations)other basestations)

Desired No + 3 No + 3 No NoMaximum objective (relative objective (reative to o bjective objectivePhaeOOset to UTC) UTC)(not strictrequiremetr)(p )

Maximum Not 28800 (8 Not 28800 (8 aot NotObservation Applicable hr) specified h r) Applicable ApplicableintervalforPhase Offset(s) II

nc mpressed SDTV (SDI signal)Uncompressed HDTV (SDI signal)

---- MPEG-2, after netwk transportMPEG-2, no netwktransportDigital Audio, Consumer Interfaces (S/P-DIF)Digital Audio, Professional Interfaces (AES3)

Network Interface MTIE Masks for Digital Video and Audio Signals

le+11-

1le+10 ,t

1e+7-651 +6 -

Fig 1. Jter4 an wade MTI mak for _______wielesbs taintmn

e+3-1, z

e+2 -.

1 e- 9-

e- e- e- e- e2 1e1 ell le, le, le, le le6 7

Obseivation Interval (s)

Fig. 1. Jitter and wander MTIE masks forwireless base station timing

TDMA (IS-136)CDMA (IS-95) and CDMA-2000CDMA/CDMA-2000, objectiveGSM, WCDMA FDD ModeGSM COMPACTWCDMA TDD ModeUncompressed HDTV (SDI signal)

MTIE Requirements for (1) Synchronization Signalat Wireless Base Station, for Various WirelessStandards, and (2) Uncompressed HDTV (SDI signal)

e+0 - xZ~

1e-1 -

1e-2-1 e-3 1 e-2 1 e-1 1e+0 le+1 le+2 le+3 le+4 le+5 le+6

Observation Interval (s)

Fig. 2. Jitter and wander MTIE masks fordiaital video and audio aDDlications

Indication primitiveApplication ayer that receives tim e from PTP ayer(s}

equ est p rim iti ve

PTP layver(s)

=~~~~~~~~~~Service interface primiti,

Transport layver(s)(e.g., Ethernet, UDP/lPv4/Ethernet, UDP/lPv6/Ethernet)

Fig. 3. Basic abstract service interface foran application that receives time from PTP

|Application ayerthat provides time to PTP ayer(s)(e.g., external time source)

quest prim itive

1-= ........ = .............Service interface primitives

Transport layver(s)(e.g., Ethernet, UDP/lPv4/Ethernet, UDP/lPv6/Ethernet)

Fig. 4. Basic abstract service interfacefor an application that provides time to P

e+8T-

e,6

e,5

e14

LLj e,3F-!!.; e,2

AL z Indication primitive:- Programmatic access to/ captured timestamp

Latch

Request primitive: Initial '

trigger signal from A/Dconverter circuits

IEEE 1588 Clock

Fig. 5. Example of a high-accuracytimestamD (event caDture) interface

Request primitive: Time oftrigger event

( RegisterIndication primitive:Trigger signal toapplication

( Comparator

(~~ IEEE 1588 Clock

Fig. 6 Example of a high-accuracy timetriaaer (event aeneration) interface

Service Primitive Based onContinuous Sampling

N Data Channels

Fig. 7. Example of an interface for an applicationthat receives time from PTP and both synchronizesand syntonizes to PTP

6

T