meeting the 1µs challenge · 2013-07-15 · the ‘1µs challenge’ results from requirements of...

1

Meeting the 1µs Challenge: Testing Boundary Clocks and Transparent Clocks

Application Note

1. Introduction .......................................................................................................................... 2.

2. IEEE 1588v2 Devices ............................................................................................................ 3.

3. Testing IEEE 1588v2 Devices to Meet the 1µs Challenge ................................................. 5.

4. Boundary Clock Test Plan .................................................................................................. 6.

5. Transparent Clock Test Plan .............................................................................................21.

6. Appendix I - More on Boundary Clocks .............................................................................25.

7. Appendix II - More on Transparent Clocks ........................................................................27.

8. Appendix III - Recommended BC Test Limits ....................................................................29.

9. Appendix IV - Generating Sinusoidal PDV Profiles ...........................................................31.

2

Meeting the 1µs Challenge: Testing 1588v2 (PTP) Transparent

Clocks (TC) and Boundary Clocks (BC)

1: Introduction

Although Ethernet has been the technology of choice for a range of LAN and WAN applications for decades, its

capability to transfer data at high bandwidths has led to its introduction into applications which also require a

high level of synchronisation accuracy such as video distribution and mobile phone networks. As Ethernet was

not originally intended to carry timing and frequency information, this presents a major challenge.

Long Term Evolution (LTE) TDD base stations must be phase synchronised to up to 1µs accuracy.

In addition, without stringent phase and frequency synchronisation, the multiple signals in LTE’s multiple-

input/multiple-output (MIMO) architecture can simply cancel one another out.

For Mobile Backhaul, frequency accuracy must be better than 16ppb.

This minimises service disruptions and eliminates dropped connections as calls move between adjacent cells.

Highly accurate synchronisation also ensures that the radio spectrum is not spread into the adjacent channels,

allowing narrower guard bands; which in turn frees up valuable radio spectrum.

High Frequency Trading (HFT) requires 1µs timestamping accuracy.

HFT needs very low latency through a network, and high precision transfer of timestamp information. Gains in

effectiveness come from higher power processing and decreasing time granularity for these processes. As the

requirements for more precise timestamping increase, the need for higher precision synchronisation through a

network follows suit.

For Power Substation applications, standards specify maximum time variation in a system of 1µs.

These applications require accurate time synchronization and timing quality information for phase vector

estimations relative to UTC time, sample synchronization, event time stamping, and other functions.

The ‘1µs Challenge’ results from requirements of these sectors and from an increasing variety of others.

Timing information must pass through a network and deliver synchronisation accuracy to 1µs.

Fig. 1 IEEE 1588v2 is the method of choice to transfer synchronisation through an Ethernet network with high

accuracy.

3

2: IEEE 1588v2 Devices

IEEE 1588v2 is widely deployed today for frequency transfer, with a ratified ITU-T profile (G.8265.1).

The protocol uses hardware timestamps in 1588v2-specific packets to recover time and phase. Frequency can

then be derived from this.

Packet Delay Variation (PDV) and Asymmetry are key network challenges to transporting

synchronisation using 1588v2.

The ability of the protocol to recover timing can be affected by variations in the delay of packets, which

accumulate through each device in a network. This stresses the recovery mechanisms of a slave device.

Similarly, as the protocol makes assumptions about the symmetry of bi-directional delays in a network, any

asymmetry can be an additional challenge to accurate clock recovery.

Fig. 2 – Accumulation of Packet Delay Variation (PDV) in a network

(For more information on 1588v2 PTP, please refer to the document ‘Technical Brief – IEEE 1588v2’ available

at www.calnexsol.com)

Boundary Clocks (BCs) and Transparent Clocks (TCs) help overcome these network challenges for the

transfer of frequency.

BCs and TCs serve to reduce the overall effects of PDV and asymmetry in a network, aiding frequency

recovery.

To allow networks and network devices to meet the 1µs challenge for time and phase, it is widely

accepted that the addition of BCs and TCs to reduce the impact of network effects is essential.

Recovering not only accurate frequency information, but also precise top of second and time of day is a greater

challenge for slave devices, and thus more sensitive to network effects. These effects must be reduced to

ensure accurate performance.

Boundary Clocks

Boundary Clocks terminate the PTP flow, recover the clock and time information, and regenerate the PTP flow.

Effectively, there is a slave clock to the upstream device and also a master clock regenerating the PTP packets

to the downstream devices.

4

In a network where every switch/router on the PTP path performs the BC function, the only PDV contribution

(per hop) is that of the BC and the link itself. Cumulative PDV, and hence also asymmetry, are greatly reduced.

Fig. 3 – BCs minimize the accumulation of PDV in the network

Transparent Clocks

Transparent Clocks aid clock recovery by calculating the time a PTP packet resides in the TC device (in nsec)

and adding the value into the CorrectionField within the PTP header.

By using the CorrectionField, the Slave or terminating BC can effectively remove the PDV introduced by TCs.

In a network where every switch/router on the PTP path performs the TC function, (figure 4), at the end point of

a network, the final CorrectionField value should be equal to the cumulative packet delay introduced by all the

TCs. TCs which work in this way are known as End-to-End TCs, compared to Peer-to-Peer TCs, which will

also compensate for link delays.

Fig. 4 – TCs report their delays to the Slave clock, which can then correct for network PDV

5

3: Testing 1588v2 Devices to Meet the 1µs Challenge

The 1µs accuracy target is for a network as a whole – but each network element contributes to

inaccuracies.

Network accuracy is based on the sum total of all timing errors, therefore any element to be included in a

network must have a defined accuracy, so that network planning can budget for this appropriately. Therefore,

individual BCs and TCs have performance limits that are a fraction of the network 1us limit.

Standards bodies are creating performance specifications for individual BCs and TCs –

ITU-T is currently drafting the G.8273 family of documents. G.8273.2 will specify performance of BCs.

G.8273.3 will specify performance of TCs.

Errors in each BC or TC can only be fractions of the 1µs limit.

Standards such as IEEE C.37.238 propose limits of 50ns error for a single network element.

To verify device performance to these levels of accuracy, test equipment must have ns accuracy.

Larger uncertainties in measurements would obscure the pass/fail performance of a device. Testing to this

level of accuracy requires high-precision equipment - Traffic Generators and Packet Generators have 100s of

ns inaccuracy inherent in their architecture and hence are not fit for purpose. This is true even if these devices

are locked to GPS, etc.

Using a specialist impairment and measurement tool such as the Calnex Paragon-X allows test

procedures to be accurate enough to meet this ns requirement.

As Paragon-X is fit for purpose, it is possible to verify performance of BCs and TCs to meet stringent network

limits.

For more information on the specific applications and possible sources of uncertainty in Boundary and

Transparent Clocks, please see the relevant appendices to this document.

6

4: Boundary Clock Test Plan

To comprehensively test a Boundary Clock, the capability of the device to recover and regenerate PTP

packet flows under different network conditions must be considered.

The ITU-T is currently working on a set of requirements for Boundary Clock performance, to appear in

ITU-T G.8273.2.

These requirements are designed to give visibility of performance limits and characteristics of Boundary

Clocks, with testing intended to reflect the variety of network effects likely to be encountered in a real-world

network.

ITU-T G.8273.2 specifies BC performance under the following section headings:

6. Noise Generation

7. Noise Tolerance

8. Noise Transfer

9. Transient Response and Holdover Performance

Additionally, the Boundary Clock should be tested in the presence of PDV as a result of varying traffic

conditions, as these would also be encountered in a deployment scenario. Conditions to consider are:

a. Varied traffic packet size

b. Varied traffic priority

c. Varied traffic utilisation

The following section contains overviews of possible test scenarios for the requirements as given

above.

(For further information on the functionality of and potential issues with Boundary Clocks, please refer to

Appendix I - More on Boundary Clocks.)

7

Boundary Clock Test Plan:

Test 1a - Noise Generation (G.8273.2 Section 6)

Purpose:

To analyse noise generated by a Boundary Clock and verify the accuracy of the recovered clock.

Testing should be under controlled conditions: no additional traffic loading and negligible PDV to ensure there

is a solid packet noise floor.

G.8273.2 will give performance requirements for BCs. As this is currently under development, it is

recommended to use existing frequency and phase limits. (For more information on the appropriate limits for

particular applications, please see Appendix III)

If there is no clock output from the BC under test, refer to Test 1b.

Test Diagram:

Test Procedure:

1. Set up equipment as shown.

2. Traffic should be 1588v2 packets only. Paragon-X can be connected upstream of the BC to verify that

PDV is close to zero, and that there is a solid noise floor, prior to testing.

3. Test recovered clock signal from BC to ITU-T limits (frequency) or application limits (phase).

8

Pass/Fail Criteria:

1. The recovered frequency should pass the relevant ITU-T MTIE/TDEV masks, e.g. G.823/G.824

(E1/T1), G.8262 (Sync-E).

2. The recovered phase should have an accuracy determined by the application (e.g. 1µs).

For more information on the appropriate limits for particular applications, please see Appendix III.

9


Test 1b - Noise Generation (G.8273.2 Section 6) - No Clock Output

From BC

Purpose:

To analyse noise generated by a Boundary Clock and verify the accuracy of the recovered clock.






With no direct frequency or phase output from the BC under test, frequency accuracy should be determined by

using packet filtered metrics (pktfilteredMTIE/TDEV), which allow recovered clock performance to be calculated

from received 1588v2 packets. Phase accuracy can be determined by monitoring the output from a slave

device.

Test Diagram:


2. Traffic should be 1588v2 packets only. Paragon-X can be connected upstream of the BC to verify that

PDV is close to zero, and that there is a solid noise floor, prior to testing.

3. Capture PDV output from BC.

4. Test pktfilteredMTIE/TDEV to ITU-T limits, from analysis of the packet layer.

5. Test recovered phase accuracy from output of slave clock to application limits.

10

Pass/Fail Criteria:

1. The pktfilteredMTIE should pass the relevant ITU-T MTIE/TDEV masks, e.g. G.823/G.824 (E1/T1),

G.8262 (Sync-E).



11


Test 2 - Noise Tolerance (G.8273.2 Section 7)

Purpose:

To confirm the noise tolerance of a BC, which is its ability to remain locked to the upstream Master Reference

in the presence of noise.

PDV noise profiles for device testing are specified in ITU-T G.8263 (Currently under development).

Test Diagram:

Test Procedure:

1. Connect as shown, and apply ITU-T G.8263 defined PDV profiles to 1588v2 traffic.

2. Monitor status and alarms of BC under test to determine if lock is maintained, e.g. BC does not enter

holdover or switch reference input.

Pass/Fail Criteria:

1. The BC under test should remain in lock to the incoming PTP signal when G.8263 defined PDV

profiles are applied, e.g. does not go into holdover, etc.

12


Test 3 - Noise Transfer (G.8273.2 Section 8)

Purpose:

To confirm the noise transfer of a BC, and that any noise gain is within limits.

ITU-T G.8273.2 will specify PDV to be applied, and acceptable gain levels.

To test the BC response to low frequency components that may affect the accuracy of the internal clock, it is

recommended that sinusoidal PDV should be applied to 1588v2 traffic between a Master Clock and BC under

test, and PDV on the output from the BC measured to make a gain calculation. A recommended pass level is

gain of under 0.2dB, as specified for a synchronisation node in ITU-T G.8262, Section 10.

Test Diagram:

Test Procedure:

1. Connect equipment as shown.

2. ITU-T G.8273.2 has not yet defined input PDV for this test. It is recommended that Sinusoidal PDV be

used as an input stimulus, to verify BC response to low frequency wander.*

3. Note Input Peak-to-Peak PDV on Paragon PDV graph (Overall Max PDV - Overall Min PDV).

4. Measure Sync message PDV between BC and Slave; determine Output Peak-to-Peak PDV as in step

3.

5. Perform a differential calculation between applied and captured PDV to determine noise gain of the

BC:

Wander Gain (dB) = 20log (Output PDV amplitude/Input PDV amplitude)

Pass/Fail Criteria:

1. Noise gain should meet the limit specified in G.8273.2, Section 8.

2. Prior to specification, it is recommended to test to a gain limit of 0.2dB (As per ITU-T G.8262, Section

10.)

*For more information on generating Sinusoidal PDV profiles, please see Appendix IV.

13


Test 4a - Transient Response (G.8273.2 Section 9)

Purpose:

To determine the ability of a BC to maintain performance when switching master clock reference.






If there is no clock output from the BC under test, refer to Test 4b.

Test Diagram:

Test Procedure:


2. Traffic should be 1588v2 packets only.

3. Generate an event to cause the BC under test to switch reference:

Configure the Master to stop responding

Change the Master Priority or clockClass.

Pull the connecting cable.

4. Confirm BC has switched reference.

14

5. Test pass/fail of recovered clock from BC to the ITU-T limits, ensuring performance is maintained

during switching of master.

Pass/Fail Criteria:


(E1/T1), G.8262 (Sync-E), with a switching event during the measurement period.

2. The recovered phase should have an accuracy determined by the application (e.g. 1µs), with a

switching event during the measurement period.


15


Test 4b - Transient Response (G.8273.2 Section 9) - No Clock Output

From BC

Purpose:

To determine the ability of a BC to maintain performance when switching master clock reference.






With no direct frequency or phase output from the BC under test, frequency accuracy should be determined by

using packet filtered metrics (pktfilteredMTIE/TDEV), which allow recovered clock performance to be calculated

from received 1588v2 packets. Phase accuracy can be determined by monitoring the output from a slave

device.

Test Diagram:

Test Procedure:


2. Traffic should be 1588v2 packets only.

16

3. Generate an event to cause the BC under test to switch reference:

Configure the Master to stop responding

Change the Master Priority or clockClass.

Pull the connecting cable

4. Confirm BC has switched reference.

5. Capture PDV output from BC.

6. Test pktfilteredMTIE/TDEV to ITU-T limits, from analysis of the packet layer.

7. Test recovered phase accuracy from output of slave clock to application limits.

Pass/Fail Criteria:

1. The pktfilteredMTIE should pass the relevant ITU-T MTIE/TDEV masks, e.g. G.823/G.824 (E1/T1),

G.8262 (Sync-E), with a switching event during the measurement period.

2. The recovered phase should have an accuracy determined by the application (e.g. 1µs), with a

switching event during the measurement period.


17


Test 5 – Holdover Performance (G.8273.2 Section 9)

Purpose:

To determine the ability of a BC to maintain lock when there is a frequency offset in the input signal.

The current draft of G.8273.2 does not currently give a test specification or limits for holdover performance.

ITU-T G.8262 Section 7 specifies holdover performance testing parameters for a slave node in a

synchronisation network - Pull-in, Hold-in and Pull-out ranges. These give conditions under which a device

should achieve, maintain and potentially lose lock respectively. As it has a slave clock component, it is

recommended that a BC should be tested for the same performance characteristics until the G.8273.2

recommendation is complete.

Test Diagram:

Test Procedure:


2. It is suggested that traffic should be 1588v2 packets only.

3. Determine clock is locked (e.g. does not enter holdover, etc.) by monitoring BC management port, or

recovered clock outputs. Lock can also be determined by analysing stability of Sync message PDV

from the BC.

4. Add frequency offset to the reference to the master, and determine if clock is locked.

18

Pass/Fail Criteria:

As the G.8273.2 test specifications and limits are not currently defined, it is recommended to follow the

test plan as specified in G.8262, Section 7:

Pull–in Range (As in G.8262 Section 7.1)

The Pull-in range is defined as the largest offset between a slave clock's reference frequency and a specified

nominal frequency, within which the slave clock will achieve locked mode.

Input Stimulus Pass/Fail Criteria Notes

Apply a large Frequency

offset ensuring BC is in

holdover. Reduce offset

until BC locks.

BC starts unlocked with large offset applied

BC locks before offset reaches +/- 4.6ppm

Lock can also be

monitored by

observing BC clock

output, or Sync PDV

stability.

Hold–in Range (As in G.8262 Section 7.2)

Hold-in range is defined as the largest offset between a slave clock's reference frequency and a specified

nominal frequency, within which the slave clock maintains lock as the frequency varies arbitrarily slowly over

the frequency range.


BC is locked to the Master

Clock. The Reference

Frequency is then offset

to +/-4.6ppm

BC should remain locked at an offset of +/-4.6ppm

Lock can also be

monitored by observing

BC clock output, or Sync

PDV stability.

Pull–out Range (As in G.8262 Section 7.3)

Pull-out range is defined as the offset between a slave clock's reference frequency and a specified nominal

frequency, within which the slave clock stays in the locked mode and outside of which the slave clock cannot

maintain locked mode, irrespective of the rate of the frequency change.


BC is locked to the Master Clock. The Reference Frequency is then offset until the BC unlocks

BC should remain locked at an offset of +/-4.6ppm but lock should extend beyond this.

Lock can also be monitored by observing BC clock output, or Sync PDV stability.

19


Test 6 - High Frequency PDV from congestion

Purpose:

To characterise the performance of a BC under varying traffic conditions.

By loading the BC with conditions matching ITU-T G.8261 VI.2.2, the effects of varying packet sizes can be

determined. Loading using G.8261 VI.5.2.2 (Test Case 12) and VI.5.2.3 (Test Case 13) models varying traffic

utilisation.

As traffic conditions will affect the output from the master component of a BC, testing should involve

measurements downstream of the BC under test.

Peak-to-Peak PDV on 1588v2 flows from the BC should be compared to any limits specified by design teams.

Additionally, slave recovered clock can be measured to confirm that the slave is not impacted by traffic effects

on the BC.

Test Diagram:

Test Procedure:


2. Measure Peak-to-Peak PDV on 1588v2 flow between BC and Slave.

20

3. Test recovered clock signal from Slave to ITU-T limits (frequency) or Application limits (phase).

4. Monitor the effect of policing and buffer mechanisms under varying conditions: Load BC with traffic

conforming to G.8261, as described above. Run with Test Case 12, and again with Test Case 13

5. In addition, test with varying traffic priority - test with 1588v2 packets as the only high priority traffic,

and again with a traffic flow also as high priority.

6. Testing can be for 1-Step and 2-Step modes.

Pass/Fail Criteria:

1. Peak-to-Peak PDV should conform to limits specified by design team.


(E1/T1), G.8262 (Sync-E).



21

5: Transparent Clock Test Plan

Testing a transparent clock is essentially testing the accuracy of the CorrectionField value under

network conditions.

The ITU-T is currently working on a set of specifications for testing a Transparent Clock, to appear in ITU-T

recommendation G.8273.3.

IEEE C.37.238 specifies that a Transparent Clock must contribute less than 50ns error to a network.

In other words, the CorrectionField value inserted by a TC must be accurate to at least 50ns.

The CorrectionField must be accurate in the presence of network effects.

Hence this accuracy must be tested in a way which reflects this:

In the presence of traffic

Forward path (Sync) and return path (Del-req)

1-Step and 2-Step methods (Note these methods differ in the location of the CorrectionField)

Tests should also be done with varying congestion traffic:

Packet size

Traffic priority

Traffic utilisation

The following section contains overviews of the possible test scenarios, as given above.

(For further information on the functionality of and potential issues with Transparent Clocks, please refer to

Appendix II - More on Transparent Clocks.)

22

Transparent Clock Test Plan:

Test 1 - CorrectionField Accuracy

Purpose:

To measure the accuracy of the TC CorrectionField by comparison to actual delay measured across the TC.

This test should be conducted under a variety of traffic conditions. ITU-T G.8273.3 will define traffic profiles to

be used. As this definition is not yet complete, it is recommended that currently identified traffic conditions for

testing 1588v2 be used until otherwise specified.

By loading the TC with conditions matching ITU-T G.8261 VI.2.2, the effects of varying packet sizes can be

determined. Loading using G.8261 VI.5.2.2 (Test Case 12) and VI.5.2.3 (Test Case 13) models varying traffic

utilisation.

Test Diagram:

Test Procedure:


2. Apply bi-directional traffic loading and 1588v2 traffic into the TC on one port pair, and additional traffic

loading on another port pair.

23

3. Set Paragon-X filters to capture Sync messages on ports 1 and 2 (Note: these will be displayed as

Sync message flows with the same header address, identified by opposing flow directions on the

Paragon-X GUI)

4. Delay through TC can be calculated by comparing differences in arrival times of 1588v2 packets at

Ports 1 and 2. Compare measured delay through TC to CorrectionField values and calculate offset.

(For more information on measuring delay and calculating CorrectionField accuracy, please see

Result Interpretation section below for information on how to use a built-in tool in the Calnex Paragon

instruments to simplify the calculation.)

5. Confirm the accuracy of the CorrectionField under varying traffic conditions: Load TC with traffic

conforming to G.8261, as described above. Run with Test Case 12, and again with Test Case 13

6. In addition, test with varying traffic priority - test with 1588v2 packets as the only high priority traffic,

and again with a traffic flow also as high priority.

7. Repeat steps 3-6 for Del_Req messages to test CorrectionField accuracy in the reverse direction.

8. Testing can be for 1-Step and 2-Step modes.

Pass/Fail Criteria:

1. When complete G.8273.3 will define performance limits for TCs.

2. CorrectionField accuracy should be defined in the specifications of any TC under test.

3. IEEE C.37.238 (Annex B) Specifies that CorrectionField error must be under 50ns for Power

Applications.

24

Result Interpretation:

The resulting packet capture appears in raw form on the Paragon capture display like this:

The error indications are due to apparent sequence number duplication, which in this setup are intentional and of no consequence. From the arrival time and correction field information in each message pair, it’s possible to calculate latency through the TC, correctionfield delta (between ingress and egress CF value) and hence correctionfield accuracy (difference between measured latency and CF delta). The calculation would be impractical manually, hence the automation provided by the tool. Note: It’s possible to filter the displayed message types (for both table and graph) using the main GUI select graph -> graph display mode menu. However, if using this feature, launch the TC latency tool first, then filter the display on the main GUI. Failure to do it in this sequence will corrupt the latency tool result. To use the tool, launch it from the tools menu

At launch, the tool will display a control window and default CF accuracy graph

Configure the tool using the drop-down lists, and press Plot to generate a graph:

25

The graph can be zoomed by clicking and dragging:

The graph can be printed or copied using the File and Edit menu.

If desired, perform a calibration measurement with the DUT replaced by a short connection. The mean latency result can then be subtracted from the measured latency. The standard deviation of the calibration measurement should be close to zero, confirming that the taps are non-aggregating and therefore not distorting the measurement.

26

Appendix I - More on Boundary Clocks

Unlike Transparent Clocks where only the correction field in the PTP header is modified (hence the

term ‘Transparent’), a Boundary Clock (BC) terminates the PTP flow, recovers the clock and timestamp,

and generates a new PTP flow.

Effectively, there is a slave clock to recover the clock and also a master clock to regenerate the PTP packets.

There are two sources of PDV produced in a BC that need to be considered when testing performance:

The first source of PDV comes from the process of recovering the clock.

The recovered clock will not be a perfect match to the original source clock in the grand master. There will be

wander in the recovered clock compared to the grandmaster’s clock. This wander will result in low frequency

components in the output PDV. Note that this is the same conceptual source of wander that is known to occur

in technologies that use purely physical layer techniques to transfer timing e.g. SyncE, SDH, etc.

If a chain of BCs are used, like any chain of equipment where the clock is recovered and regenerated in

each piece of equipment, then it is expected there will be an accumulation of wander from this source

of PDV, leading to increasing levels of low frequency wander in the resulting packet PDV.

The second source of PDV is the internal queues, and in particular, the final queue.

The timing packets will be generated inside the Boundary clock device. There will be no PDV coming from the

timing packets received by the Boundary Clock as these have been terminated. The queues that the new

timing packets will pass through before being output from the switch will introduce PDV dependent on the

implementation methods employed. Note that in a chain of BCs, there will be no accumulation of PDV from this

source because each timing flow is terminated on arrival and not passed through to the output.

27

In summary, there are two sources of PDV that will exist on the output of the BC:

1. Clock Wander Accumulation

Each BC recovers the clock and re-generates a new timing signal. This can lead to the introduction of

low frequency clock wander,

Chains of BCs can lead to the accumulation of low-frequency clock wander.

2. Output Queue PDV - PDV from Output Buffer Queue of previous BC. Examples of the potential PDV

generated are;

Maximum 12 µsec of delay for 1514 byte packet, (G.8261)

Maximum 525 µsec of delay for 64K jumbo byte packet

Ultimately, BC testing must characterise the device’s ability to cope with variations in input quality,

and any inaccuracies in the output, due to the mechanisms outlined above.

28

Appendix II - More on Transparent Clocks

Transparent Clock (TC) devices measure the time a PTP packet resides in the TC device and

increments the Correction Field (CF) in the PTP header (byte offset 8) with this time.

By doing so, the slave clock or Boundary Clock (BC) further down the line can determine how long the PTP

packet resided in the TC devices before it. Hence, it can reduce packet jitter effects.

A perfect TC would not contribute to Packet Delay Variation (PDV) because the correction field

completely cancels out the PDV.

Practically, it is technically very challenging to implement a perfect TC because the TC functionality is usually

implemented inside a networking device such as a switch or router.

The basic architecture of a switch or router with TC functionality is outlined in the following diagram:

Inside a switch or router, many queues exist in order to buffer, manage and prioritize packets.

The final queue (Qn) that sits just before the physical interface (PHY) is of major concern. It is technically very

challenging to change the content of a packet when it is about to go out the PHY. So once the correction field

had been calculated and inserted into the PTP packet, the packet theoretically should immediately go out the

PHY. Hardware Timestamping techniques can be used to maximise the accuracy.

In a network where congestion occurs and packets are regularly going out of the PHY, it is likely that a

packet has already begun transmission.

Hence the PTP packet must wait until the current packet is fully transmitted before going out. In this situation,

Quality of Service (QoS) prioritization doesn’t help because you cannot stop a packet from going out after the

first byte has been transmitted.

With this potential technical issue in mind, there could always be inaccuracies in the correction field

value, to varying degrees.

Inaccuracies from this source would depend on transmission rate and the largest allowable Ethernet frame

size. For example, at Gigabit Ethernet rates, it takes 12 µsec to transmit a 1518 byte packet and 525 μsec to

transmit a 64K byte jumbo packet. (Note: the ITU-T G.8261 recommendation defines traffic models which

include “maximum sized packets” defined as being 1518 bytes in length.)

29

In addition to the last queue problem described previously, PDV can be introduced depending on the

switch/router vendor’s implementation.

Inaccuracies in the correction field can be due to:

Varying sized packets not being corrected to the same accuracy.

CorrectionField calculation not being timestamped exactly on arrival time.

CorrectionField calculation cannot accurately predict exactly when the packet will start to exit the

device.

TC correction is different in both directions leading to asymmetry issues.

When PDV is not completely removed from a TC, the PDV will propagate to the next TC in the line. Hence

when a chain of TCs exist in a network, PDV accumulation will occur.

Testing for TCs must therefore determine the accuracy of the CorrectionField, and hence how much PDV is

passed on from the device without information to allow for compensation at a terminating device.

30

Appendix III - Recommended BC Testing Limits - Frequency/Phase

ITU-T G.8273.2 will give performance specifications for BCs once completed. Datasheets should also

be consulted for design limits of a device.

While the ITU-T G.8273.2 specification is under development, this appendix provides further information on

recommended performance limits.

III.1: Selection of Pass/Fail Criteria for BC Test Plans

Any testing to determine the suitability of a device to deliver frequency and phase in a network must verify the

ability to recover and pass on this timing information.

The datasheet for any device under test should provide specifications and guidance on design limits.

In the absence of limits specified by ITU-T G.8273.2 or clear guidance from datasheets, it is suggested that

limits should align with the following:

1. E1:

MTIE/TDEV synchronisation interface limit masks are defined in ITU-T G.823. The particular limit mask

to apply depends on the desired Clock standard: PRC, SSU, SEC or PDH. The relevant

synchronisation interface masks are given in G.823 Section 6, figures 4-11.

2. T1:

MTIE/TDEV synchronisation interface limit masks are defined in ITU-T G.824. The particular limit mask

to apply depends on the desired Clock standard: PRC, 1544kb/s reference or SEC. The relevant

synchronisation interface masks are given in G.824 Section 6, figures 2-5.

3. 2MHz/10MHz:

As synchronisation interface wander limits are specified for time, these limits do not need to vary

based on the signal frequency. Therefore limits for these interfaces should match those for E1

frequency outputs. Limit masks are defined in ITU-T G.823. The particular limit mask to apply depends

on the desired Clock standard: PRC, SSU, SEC or PDH. The relevant masks are given in Section 6,

figures 4-11.

4. Phase (1pps):

Limits for recovered phase are application specific, depending on the phase accuracy requirements.

For example, Mobile Base Stations for TDD applications require up to 1µs phase accuracy. Any

recovered phase should meet the accuracy requirements for the intended application.

III.2: Test Set-up Guidelines for Monitoring BC Performance.

Depending on the configuration of a particular BC under test, the recovered frequency and phase can be

analysed in one of 3 ways:

1. Frequency/Phase Output from Device Under Test:

The most accurate measure of clock performance for a device. Frequency and/or phase clock outputs

can be tested directly.

31

2. Packet Filtered Analysis:

Recovered clock performance can be calculated from 1588v2 packet flow emerging from the BC.

Frequency and/or phase performance can be determined from analysis of the packet timing.

3. Frequency/Phase Output from Slave Device:

If options 1 and 2 are not available, the clock output from a Slave device downstream of the device

under test can be used to verify that 1588v2 packets are being transmitted without negatively affecting

the recovery at the output of the end device.

32

Appendix IV - Generating Sinusoidal PDV Profiles

For testing Noise Transfer of a BC (ITU-T G.8273.2, Section 8), the gain on the low frequency

component of a PDV profile should be tested.

When complete, G.8273.2 will specify suitable stimulus PDV. Until complete, it is recommended that Sinusoidal

PDV profiles are used.

It is suggested that input stimuli should match the corner frequencies of the desired mask in G.823/G.824, as

these masks specify acceptable wander at certain points in a network. (For more information on the mask to

use for a particular application, please refer to Appendix III)

How to generate a Sinusoidal PDV Profile:

1. Contact Calnex to obtain the Calnex Sinusoidal PDV profile generator (MS Excel spreadsheet).

2. Open the spreadsheet.

3. Follow the On-Screen instructions to generate a Sinusoidal PDV profile; Specify Packet Rate,

Frequency, Peak-to-Peak Amplitude and Message Type (Sync or Del_Req).

4. Once PDV profile has been generated, locate and rename the profile as desired.

5. The saved profile can then be selected, imported and replayed in the Paragon GUI Add Impairments

and Delay tab.

For more information on the Calnex Paragon-X and to take advantage of Calnex’s extensive

experience in sync and packet testing technologies, please contact Calnex Solutions on +44 (0)

1506 671 416 or email: [email protected]

Calnex Solutions Ltd Herkimer House Mill Road Enterprise Park Linlithgow West Lothian EH49 7SF United Kingdom Tel: +44 (0) 1506 671 416 Email: [email protected]

www.calnexsol.com

This information is subject to change without notice

v8 May 2012

meeting the 1µs challenge · 2013-07-15 · the ‘1µs challenge’ results from requirements of...

Documents