Testing 1588v2 (PTP) Transparent Clocks and Boundary Clocks

Introduction

Pour avoir le document complet (avec photos), n'hésitez pas à nous contacter : contact [@] infractive.fr

Introduction

Although Ethernet has been the technology of choice for a range on LAN and WAN applications for decades, using it in the mobile backhaul network presents a major challenge. Here, accurate synchronisation of base stations to nanoseconds accuracy is critical to minimise service disruptions and eliminate dropped connections as calls move between adjacent cells. Highly accurate synchronisation also ensures that the radio spectrum is not spread into the adjacent channels. Plus, without stringent phase synchronisation, the multiple signals in LTE‟s multiple-input/multiple-output (MIMO) architecture can simply cancel one another out. And this is where IEEE1588v2 comes in.
IEEE1588v2 (also known as Precision Time Protocol, PTP) is an industry-standard protocol that enables the precise transfer of frequency and time to synchronise clocks over packet-based Ethernet networks. It synchronises the local slave clock on each network device with a system Grandmaster clock and uses traffic time-stamping, with sub-nanoseconds granularity, to deliver the very high accuracies of synchronisation needed to ensure the stability of base station frequency and handovers. Timestamps between master and slave devices are sent within specific PTP packets and in its basic form the protocol is administration-free.
Of course, the precision and performance of the IEEE 1588v2 protocol is based on the precision of the timestamp. The timestamps of incoming and outgoing packets clearly need to be recorded and assessed to ensure synchronisation of master and slave devices. Differences in time and frequency between clocks and subsequent equipment corrections need to be evaluated, while clocks must be measured to ensure they are within their specified limits. Further, delays and drifts in sync and their effect on the transfer of timing through the network need to be considered too.
This application guide examines the various methods you can use to characterise and measure the precision of timestamp synchronisation, as well as the accuracy and functionality of transparent and boundary clocks.

Different Types of PTP Devices

In a packet transport system, clocks communicate with each other over the communication network using PTP. All clocks, whether master or slave, lead back to – and ultimately derive their time from – the „Grandmaster‟ clock. There are 5 types of PTP clock devices:

Tableau1
(For more information on 1588v2 PTP, please refer to the document „Technical Brief – IEEE 1588v2 PTP.)

Potential Issues with Transparent Clocks

Transparent Clock (TC) devices measure the delay the PTP packet resides in the TC device and increments Correction Field (CF) in the PTP header (byte offset 8). 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. Let‟s look at the basic architecture of a switch or router with TC functionality (see following diagram).
Photo 1

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. However, in a network where congestion occurs and packets are regularly going out the PHY, it is likely that a packet has already begun transmission hence the PTP packet must wait until 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 technical issue in mind, there should always be inaccuracies in the correction field value. The inaccuracy will 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.)
In addition to the last queue problem described above, PDV can be introduced depending on the switch/router vendor‟s implementation. Inaccuracies in the correction field can be due to
 Varying sized packets are not corrected to the same accuracy.
 Correction field calculation is based on an average value instead of a packet-to-packet correction.
 A fixed delay correction is being used instead of an average or packet-to-packet correction.
 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 Transparent Clocks

The functionality and accuracy of a transparent clock can be tested by constructing the following test bed and following the test procedure below:
Test Procedure:
1. Connect Paragon between the Master and TC under test. Note the magnitude of PDV and check it is stable i.e. no sporadic spikes or variations.
2. Connect Paragon as shown and inject Congestion Traffic using the Traffic Generator. Configure Paragon to use the Correction Factor in calculating the Sync PDV.
3. Start Paragon capturing the output from the TC under Test. Display the Sync PDV.
4. In a perfect TC, the magnitude of the Sync PDV should be the same as that measured in Step 1.
5. As bidirectional congestion traffic is added by the traffic generator, the reverse direction Del_Req PDV can also be measured and characterized.

Characterizing Transparent Clocks and Creating Modified G.8261 Profiles

The G.8261 test bed (G.8261 Appendix VI, Figure VI.10) defines a network of ten Gigabit Ethernet switches that is used to create PDV to test the Unit under Test. If a network is built using Transparent (and/or Boundary) clocks, then the resulting PDV at the end of the chain of switches will be different to that produced by Ethernet switches that do not perform these special 1588v2 operations. It is likely that the level of PDV that exists at the end of the chain will be significantly reduced. Instead of using G.8261 profiles to test a slave clock, vendors and operators should use modified G.8261 profiles to test. The G.8261 test case profiles can be scaled down to correctly represent a chain of TCs used in the network design. Using the test bed in the previous section and using the test procedures below, vendors and operators can create a set of reduced G.8261 profiles tailored for their network design.
Test Procedure:
1. Connect Paragon as shown and inject Congestion Traffic using the Traffic Generator. Measure the following;
 Peak-to-Peak Sync (and Del_Req) PDV;
a. With Correction Field (Results 1)
b. Without Correction Field (Results 2)
 Scaling Factor = Results_1 / Results_2 x (max # of TCs used in network design)
2. Create TC-Reduced G.8261 Test Cases
 Use the Scaling Factor to reduce the amplitude of the standard G.8261 Test Case PDV Profiles
 Primary tests are Test Cases 12, 13b, 14b in G.8261
3. Test the slave clock using the TC-Reduced G.8261 Test Cases and ensure the recovered clock from the slave clock passes the relevant G.823/G.824 MTIE/TDEV mask.

Potential Issues with 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 regenerates the 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 Slave devices at the end of a chain of BCs:
The first 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. 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.
The second 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. 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 and hence lead to increasing levels of low frequency wander in the resulting packet PDV.
In summary, there are two sources of PDV that will exist on the output of the BC;
1. Output Queue PDV
• PDV from Output Buffer Queue from previous BC (Same as the final buffer problem in TC)
• Maximum 12 μsec of delay for 1514 byte packet, (G.8261)
• Maximum 525 μsec of delay for 64K jumbo byte packet

2. 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.

Testing Boundary Clocks

To comprehensively test a boundary clock‟s capability to recover and regenerate the PTP packet flows, the network configuration that the device will be utilization in needs to be considered e.g. how many BCs, how many TCs exist between BCs, are Ethernet switches being used, etc.
Considering the case when all devices are TCs or BCs, the test scenarios that need to be considered are:
1. Wander Generation (introduce zero PDV)
2. Wander Tolerance
 Network: Chain of TCs (use TC-Reduced G.8261 profiles)
 Network: Chain of BCs
a. BC PDV only
b. Clock Wander only
c. BC PDV + Clock Wander
BC-Reduced G.8261 profiles can be produced from the standard set of G.8261 profiles by simply scaling the amplitude by 1/9th (0.11). In the standard G.8261 test bed, there are 9 points of congestion, (there is no congestion traffic out of the tenth switch in the chain). As described earlier in the document, as the 1588 is terminated and regenerated, the PDV on the output is that produced by the BC generating the 1588 flow.

BC Functional Test: Test 1 – Wander Generation (No PDV)

Purpose:
Test with no congestion traffic on the Packet interface.
Test Diagram:
Pass/Fail Criteria:
Pass MTIE/TDEV Mask under G.823 Synchronisation Interface Output Wander Limit Clause 6.2.2 (Clock) or Clause 5.2.1 (Traffic)

BC Functional Test: Test 2.A – TC Chain Wander Tolerance

Purpose:
Test with TC-Reduced G.8261 profiles developed in the section (Characterizing Transparent Clocks and Creating Modified G.8261 Profiles). Testing with these profiles ensures that a BC will perform to standards when a chain of TCs are used in the network design.
Test Diagram:
Test Procedures:
 Test Case 12, 13 and14 with Traffic Model 2.
 Use PDV Editor scaling function to obtain reduced G.8261 PDV profiles.
Pass/Fail Criteria:
Pass MTIE/TDEV Mask under G.823 Synchronisation Interface Output Wander Limit Clause 5.2.1 (Traffic)

BC Functional Test: Test 2.B.1 – BC Chain – BC PDV Only

Purpose:
Test with BC-Reduced G.8261 profiles. Testing with these profiles ensures that a BC will perform to standards when a chain of BCs is used in the network design.
Test Diagram:
Test Procedures:
 Test Case 12, 13 and14 with Traffic Model 2.
 Use PDV Editor to scale down the G.8261 profiles by 1/9.
Pass/Fail Criteria:
Pass MTIE/TDEV Mask under G.823 Synchronisation Interface Output Wander Limit Clause 5.2.1 (Traffic)

BC Functional Test: Test 2.B.2 – BC Chain – Clock Wander Only

Purpose:
Test with a low frequency sine-wave PDV to emulate PDV accumulation in a BC Chain. Wander accumulation will manifest itself as low frequency PDV on the packet side. Testing with these sine-wave PDVs ensures that a BC will perform to standards when a chain of BCs are used in the network design.
Test Diagram:
Test Procedures:
 Test with Clock Wander
1. Emulate Clock Wander using a sine-wave PDV profile.
2. Repeat test for each Wander frequency listed below (PDV profile provided by Calnex): Frequency Amplitude
0.1 Hz
8.8 μsec
10 mHz
8.8 μsec
4.88 mHz
18 μsec
Pass/Fail Criteria:
Pass MTIE/TDEV Mask under G.823 Synchronisation Interface Output Wander Limit Clause 5.2.1 (Traffic)

BC Functional Test: Test 2.B.3 – BC Chain – BC PDV + Clock Wander

Purpose:
Test with a combination of BC PDV and the low frequency sine-wave PDV. This combination emulates the actual PDV conditions that a BC will encounter in a real network designed only with BCs.
Test Diagram:
Test Procedures:
 Test with Clock Wander
1. Generate composite PDV profiles by combining
A. BC-Reduced Test Case 12 (Scale PDV profile by 1/9 using PDV editor)
B. Sine wave profile
2. Repeat test for each Wander frequency listed below (PDV combine capability provided by Calnex): Frequency Amplitude
0.1 Hz
8.8 μsec
10 mHz
8.8 μsec
4.88 mHz
18 μsec
Pass/Fail Criteria:
Pass MTIE/TDEV Mask under G.823 Synchronisation Interface Output Wander Limit Clause 5.2.1 (Traffic)

Calnex Solutions Ltd
Springfield, Linlithgow
West Lothian EH49 7NX
United Kingdom
tel: +44 (0) 1506 671 416
email: info@calnexsol.com
www.calnexsol.com