AN1202: ITU-T Precision Time Protocol Grandmaster ......Title AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode Created Date 20200429150655Z

AN1202: ITU-T Precision Time ProtocolGrandmaster, Boundary Clock, and SlaveClock Mode

ITU-T Precision Time Protocol (PTP) is an extension of IEEE1588 Precision Time Pro-tocol that tailors the use of PTP to telecommunication applications. PTP is a key solutionin transmitting both frequency and time synchronization to achieve 5G network goals.

Telecommunication technology has been shifting to asynchronous protocols such asEthernet to save on cost. However, this has compromised the network’s ability tomaintain timing accuracy.

An obvious solution is to add a Global Poisitioning System (GPS) to every site to allowlocal clocks to synchronize to an accurate clock source. But this is both very expensive,contradicting the industry’s original intent of being cost effective and less reliable than99.999% availabilty.

Another solution is Network Time Protocol (NTP); however, its accuracy is insufficientfor many applications. The need for a higher accuracy protocol is rising as mobile mar-kets approach the challenge of a 5G network.

PTP is perfectly positioned for these applications because it provides the high accuracytime transfer without requiring a hardware change to the entire network. The protocolcan also work in conjunction with SyncE to compensate for nodes that cannot processPTP data.

This Application Note will discuss the generic IEEE1588 PTP features and how ITU-Texpands on these features for telecommunication use, as well as implementationconsiderations.

KEY FEATURES

• There are three critical clock types in theIEEE 1588 standard.

• Grandmaster is the top of thesynchronization chain, the requirement forits accuracy is the most stringent.

• Boundary Clock receives itssynchronization from the grandmasterclock or other Boundary clocks and sendsthe synchronization information todownstream boundary clocks and slaveclocks.

• Slave Clock receives its synchronizationfrom boundary clocks and it is the lastclock in the synchronization chain.

silabs.com | Building a more connected world. Rev. 1.0

1. IEEE 1588 Overview

Although the focus of this paper is the ITU-T application of the IEEE 1588 Precision Timing Protocol, this section will first describe thefoundational elements in terms of IEEE1588 before discussing the extensions in ITU-T. The IEEE1588 discussed here isIEEE1588-2008[1].

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeIEEE 1588 Overview

silabs.com | Building a more connected world. Rev. 1.0 | 2

1.1 Grandmaster, Boundary Clock, Slave Clock, and Transparent Clock

There are four different types of clocks in the IEEE1588 architecture – grandmaster, boundary clock, slave clock, and transparent clock.In the following figure, the grandmaster is referred to as T-GM, boundary clock as T-BC, slave clock as T-TSC, and transparent clockas T-TC. These are the designated shorthand for PTP clocks in ITU-T, and they will be used throughout this Application Note.

As shown in the figure below, the grandmaster receives Time of Day (ToD) and 1 pulse per second (1PPS) information from the GPSand converts it to 1588 timestamp messages. The 1588 messages are passed down to either a telecom time slave clock (T-TSC) or theslave side of a telecom boundary clock (T-BC). If the receiving clock is a T-BC, the master side of the T-BC will then transmit to the nextboundary clock, transparent clock, or slave clock. The T-TSC receives the PTP timing information but is not responsible for transmittingit to downstream clocks.

T-GMGNSS/GPS

ToD1PPS

1588T-TC T-TSC

1588 1588 ToD

1PPSClocksT-BC

ToDClocks1PPS

Figure 1.1. IEEE1588 Architecture Block Diagram

T-BC and T-TSC can also convert the 1588 messages into clock information in the form of ToD, 1PPS, and other relevant clock fre-quencies depending on the network needs.

The telecom transparent clock (T-TC) is another plausible clock type in IEEE1588, it is less common in the ITU-T applications. The roleof the transparent clock is to account for the inherent delay that occurred when packets passed through. The T-TC will record the en-trance and exit time of a packet and add the delay (called “residence time”) to the correction field of the packet. A T-TC does not syn-chronize its clock with the master’s clock.

Table 18 from IEEEStd 1588-2008 represents the basic packet format [1].

Table 1.1. IEEE1588 Common Elements of a Packet

IEEEStd 1588-2008 - Table 18 - Common Message Header

BitsOctets Offset

7 6 5 4 3 2 1 0

transportSpecific messageType 1 0

reserved versionPTP 1 1

messageLength 2 2

domainNumber 1 4

reserved 1 5

flagField 2 6

correctionField 8 8

reserved 4 16

sourcePortIdentity 10 20

sequenceId 2 30

controlField 1 32

logMessageInterval 1 33



1.2 Definition and Derivation of Two-Way Delay and Offset

The most fundamental purpose of PTP is to synchronize the time between clocks, so the foundation of PTP is the Delay Calculation. Tosynchronize between two clocks, the master clock sends timestamps to the slave clock using one of two methods, One-Way Delay orTwo-Way Delay.

One-Way Delay can only achieve frequency synchronization while Two-Way Delay can achieve both frequency and time synchroniza-tion. Frequency synchronization allows each clock to have the same time base, i.e., a second lasts the same amount of time for allclocks. Time Synchronization is more stringent because the clocks also must be at the same clock time. One-Way Delay is used whenthe application only requires frequency synchronization. Two-Way Delay is used in applications with smaller error margins, such as thesub-µs market, where the time synchronization is also critical.

In One-Way Delay, only the master transmits timing messages to the slave, and the transmission delay between them is not consid-ered. In Two-Way Delay, the slave responds to the master with a series of timing messages to calculate the transmission delay be-tween the master and the slave.

For the math derivations in this section, the variable Offset is defined as the time deviance of the slave clock from the master clock; andthe variable Delay is the time spent in transmission.

In One-Way Delay mode depicted in the figure below, the master clock sends its clock information to the slave clock using Sync andFollow-up messages. The slave clock corrects its time offset according to the master’s clock time in the time stamps. There is no con-sideration of the transmission delay in One-Way Delay mode.

Sync

Sync

Follow-up

ta

tb

Master Slave

One-Way

Follow-up

Sync

Delay Request

Follow-upt1

t4

Master Slave

Two-Way

Delay Response

t2

t3

Offset

Delay

Offset

Delay

Figure 1.2. One-Way & Two-Way Delay Synchronization

The Delay can be calculated using Two-Way Delay mode. Two-Way Delay mode requires additional communication between the slaveand the master. A “Delay Request” is sent from the slave and the master responds with a Delay Response. These additional packetsprovide the slave with additional timestamps to subtract Delay from Offset.

Four timestamps are obtained through the Two-Way exchange, t1, t2, t3, and t4. t1 is the time the master transmitted the Sync mes-sage, t2 is the time the slave received it, t3 is the time the slave transmitted the Delay Request message, and t4 is the time the masterreceived it (which is transmitted to the slave via Delay Response). Note: t2 and t3 are measured with the slave’s local clock.

Assuming the transmission is symmetrical, the following equations are true:

Delay + Offset = t2 - t1 Delay - Offset = t4 - t3

When the two equations are added, the two Offset values cancel each other out, leaving the value of twice the Delay:

(Delay + Offset) + (Delay - Offset) = 2Delay + Offset = 2Delay = t2 - t1 + t4 - t3



Again, assuming symmetry, the value of the Delay can be calculated:

Delay = t2 - t1 + t4 - t32

Similarly, for the offset:

(Delay + Offset) - (Delay - Offset) = Delay - Delay + 2Offset = t2 - t1 - (t4 - t3)

Offset = t2 - t1 - (t4 - t3)2 = t2 + t3 - t1 - t4

2

The result is an Offset value the slave clock can adjust itself to without the error from the delay. Therefore, a more accurate clock.



1.3 Two-Step Versus One-Step

In the previous section, the One-Way Delay and Two-Way Delay transmissions both start with the transmission of the Sync message.The Sync message transmits the timing information about the master clock. However, there are two methods in IEEE1588 to transmitmaster timing: One-Step and Two-Step.

The difference between One-Step and Two-Step, is that Two-Step needs a Follow-up message to communicate when the previousSync message was transmitted; while One-Step includes the transmission time of the Sync message in the message itself, as seen inthe figure below.

Sync

Sync

ta

tb

Master Slave

One-Step

Sync

Follow-up

ta

tb

Master Slave

Two-Step

Sync

Follow-up

Figure 1.3. One-Step & Two-Step Timestamp

It is the master clock designer’s choice to produce either One-Step or Two-Step messages. One-Step messages are more challengingfor the hardware because the master clock needs the ability to timestamp the sync message right as it exits the master port. Two-Stepmessaging on the other hand requires software to carry the Sync message’s t1 timestamp to the slave in a separate Follow-up mes-sage.

From a slave clock’s perspective, whether the master is One-Step or Two-Step does not matter. IEEE1588 requires the slave clock toprocess both types of timestamps. From a networking perspective, One-Step messaging consumes less bandwidth and generatesfewer packets.



1.4 Peer-to-Peer Mode

Up to this point, the discussion assumes the network is running in End-to-End mode. In End-to-End mode, only masters and theirslaves exchange messages to establish the current time. There is another operation mode called Peer-to-Peer. In this mode, in additionto its master, the slave clocks communicate to all nearby clocks to establish the delay in the communication path.

In Peer-to-Peer mode, the delay between a slave and its master is calculated by:slavetime = mastertime + networkdelay

The network delay is known by the slave because every clock keeps track of the delay to its immediate neighbors. Since knowing thedelay between every node in the network is critical, Peer-to-Peer mode requires all nodes to be PTP aware and can process Peer-to-Peer messages. Each node maintains its network delay knowledge by periodically sending peer-delay requests to neighboring clocks.When a Sync or Follow up message enters the clock, the clock updates the correction field in the Sync or Follow up message to keepthe time current.

Master

Slave

Transparent

Slave

Transparent

Peer Delay Messages

Peer Delay Messages

Peer Delay Messages

Peer Delay Messages

Peer Delay Messages

Peer Delay Messages

Peer Delay Messages

Figure 1.4. Peer-to-Peer Network Diagram

Peer-to-Peer delay calculation works similarly to End-to-End delay calculation.



t1

t4

Clock A Clock B

Peer-to-Peer

t2

t3

Offset

Delay

Offset

DelayPdelay_Req

Pdelay_Resp

Pdelay_Resp_FollowUp

Figure 1.5. Peer-to-Peer Synchronization

Clock A sends a PDelay_Req message to Clock B and saves the send time as t1. Clock B receives the Pdelay_Req message andsaves the receive time as t2. Clock B then sends a PDelay_Resp message and saves the send time as t3, which it sends to Clock A ina Pdelay_Resp_FollowUp message. Clock A receives the Pdelay_Resp message and saves the receive time as t4.

With these four timestamps the same End-to-End Two-Step derivation can be used where,

Delay = t2 - t1 + t4 - t32 Offset = t2 + t3 - t1 - t4

2

By knowing the delay between every node in the network, Peer-to-Peer mode can decrease time error by 1) knowing the net delay assoon as the network path changes, and 2) eliminating the possibility of the Sync and Delay Request messages taking different networkpaths. In addition, Peer-to-Peer mode decreases the number of messages the master clock must handle, since it only must send Sync/Follow-up messages.

Note: ITU PTP recommendations do not include peer-to-peer operation.

1.5 Packet Rate

Packet rate is another parameter that is critical to how accurate a PTP network is. Packet rate is the number of messages being sentper second. In general, the higher the packet rate the more accurate the time will be, but the higher packet rate will also be more diffi-cult for the master to handle. After a certain message rate, the increase in packet rate brings in diminishing returns and would be morelikely to overburden the master.

The IEEE1588 uses packet rate ranging from 1 packet per 128 seconds to 128 packets per second, represented as 2-7 to 27. In devicessuch as the industry standard compliant Si5389, the packet rate is selected by using the formula:

PacketRate = 2-x

where x is the user input

For example, if the user input is -2, then the select packet rate is:

2-(-2) = 4packets persecond

The packet rate used in deployment is determined by the application and the device itself.



1.6 Unicast Versus Multicast

There are two transmission modes in PTP – Unicast and Multicast. In Multicast mode, the master and slave communicate through aknown multicast address. All slaves and masters in the network can access this address and the slaves use Best Master Clock Algo-rithms to determine which master to connect to.

In Unicast mode, PTP devices must know the address (MAC or IP) of the device it is communicating with. The information about theallowed masters and slaves are saved in the clock’s master discovery table or slave acceptance filter.

By requiring the device to know the address of the devices it speaks to, unicast decreases the amount of traffic in the network. This isparticularly important in networks where not every node is PTP aware, since the master only must send messages to specific slaveswhen requested instead of multicasting at frequent intervals.

Unicast devices must send message requests and grants to establish a connection, these messages are called Signaling messages.They are used to establish a message rate between the master and the slave. For example, a slave could send the master an An-nounce-Request message and ask the master to send announce messages at 1 announce every second and for 60 seconds. The mas-ter can then choose to send back a signaling message called an Announce-Grant to agree to the message contract.

Master Slave

Unicast

Announce RequestAnnounce Grant

Announce

Sync RequestSync Grant

Delay Response RequestDelay Response Grant

Sync

Delay RequestDelay Response

Figure 1.6. Unicast Transmission

The slave initiates the message exchange by sending an Announce-Request message to the master. An Announce message is part ofthe Best Master Clock Algorithm where the master provides information about its accuracy and the slave selects its best master from allthe available masters. Once the message contract is established, the master sends the Announce messages.

If the slave chooses to receive time from this master, then it will send Sync and Delay-Response Request messages. Once the Syncand Delay-Response message contract is established, the master and slave exchange the messages at the agreed upon rate for theagreed upon period. Once the message contract expires, a new set of Requests and Grants are exchanged to establish a new con-tract[2].



1.7 ITU-T PTP Profiles

Up to this point, Precision Timing Protocol has been referred to as IEEE1588. However, the purpose of this paper is not to presentminute details of IEEE1588 PTP but its application in the telecommunication industry. The ITU-T, short for International Telecommuni-cation Union - Telecommunication Standardization Sector, has modified and expanded Precision Timing Protocol and establishedstandards for its use in the telecommunication industry.

These standards include profiles and characteristic recommendations. Characteristic recommendations such as G.8273.2 and G.8261are characteristic requirements for the ITU-T PTP. Device vendors like Silicon Labs provide compliance reports to these recommenda-tions to ensure their device and software quality.

The ITU-T PTP profiles define how to adapt IEEE1588 PTP to specific telecommunication usage. There are three ITU-T PTP profiles –G.8265.1, G.8275.1, and G.8275.2.

G.8265.1 is the telecom frequency profile, it aims to add PTP to existing network infrastructure with minimum impact to the network.Only ordinary(master/slave) clocks are used in G.8265.1[3], boundary clocks and transparent clocks are not allowed which decreasesthe PTP implementation complexity. Other requirements exist for the same reason such as: unicast is the only allowed transmissionmode, and IPV4 is the transport protocol and One-Way delay is allowed. To mitigate the effect having little PTP support, the profileallows transmission rate from 1 packet every 16 second to 128 packets per second.

G.8275.1[4] and G.8275.2[5] are telecom time and phase profiles. G.8275.1 is a full timing support profile (FTS), it provides highly accu-rate synchronization by requiring extensive PTP on-path support. All network equipment in a G.8275.1 structure network must be PTPaware. Transparent clocks are not allowed in this profile, all switches must be T-BC and all end nodes must be T-GM or T-TSC. Theprofile only runs in multicast mode, with Two-Way delay on the ethernet layer for maximum performance. The transmission rate for G.8275.1 is fixed at 16 packets per second for Sync, Follow-up, Delay-Request, and Delay-Response.

G.8275.2 is a partial timing support profile (PTS) and it is also applicable to assisted partial timing support (APTS). PTS and APTS arerelaxed versions of FTS, they do not require every node to be PTP aware. APTS is the most applicable to existing networks with GlobalNavigation Satellite System (GNSS) systems. The PTP aware nodes can be placed at strategic locations to filter the time signal andselect endpoint sites to deliver PTP time to other endpoints. G.8275.2 operating requirement is a mixture of G.8265.1 and G.8275.1. Itallows both One-Way and Two-Way delay modes, and the transmission mode is unicast on IPV4 protocol. The profile allows transmis-sion rate from 1 packet per second to 128 packets per second[6].



2. Role of Grandmaster, Boundary Clock, and Slave Clock

The IEEE1588 hierarchy of grandmaster, boundary clock, slave clock, and transparent clock is preserved in the ITU-T Precision TimingProtocol (PTP). The focus of this section is to discuss how that hierarchy is determined and how time is transmitted. The grandmaster’srole is to receive GPS information and transmit the time information to boundary and slave clocks, while the boundary and slave clocksmust identify the best master clock and process the time information.

2.1 Best Master Clock Algorithms (BMCA)

Another important aspect of IEEE1588 is the best master clock algorithm (BMCA); which is the method of how the slave/boundaryclocks select a master. In Figure 1.1 IEEE1588 Architecture Block Diagram on page 3, the PTP system is straight forward from grand-master to boundary clocks to slave, but that is not the case in real systems. In a real system, a slave/boundary clock can encountermultiple master ports and it needs to determine which one is the best master. To manage these situations, BMCA requires masters tocommunicate announce messages to the slaves.

The master’s announce messages contains the following fields that are used in the BMCA calculation:• Priority 1 Field

• 8-bit user configurable value where the lowest number wins.• The default for master capable devices is 128, and 255 for slave only devices

• Clock Class• An IEEE1588 defined field where the lowest number wins (more information in Definition of SyncE)

• Clock Accuracy• Range of accuracy to UTC

• Clock Variance• A second-order derived value of the clock reference’s accuracy (more information in Time of Day)

• Priority 2 Field• Secondary to priority 1

• Steps Removed• The number of clocks between the master and the grandmaster

• Source Port Id• Unique clock ID

The slave clock will determine the best master clock based on the abovementioned criteria.

Alternate BMCA is used in the time and phase telecom profiles: ITU-T G.8275.1 and ITU-T 8275.2. It does not allow clocks to be ordi-nary clocks where a clock can switch between being T-GM and T-TSC depending on the networks. An ordinary clock stays either T-GMor T-TSC and cannot change its role. By having this requirement, the network can avoid looping. Also, the priority field 1 is not used inAlternate BMCA. Instead a new attribute, Local Priority, is appended to the end of messages. This is part of the effort to increase theweight of the Clock Class attribute, a new QL scale is defined in the alternate BMCA to allow T-GM and T-BC to remain masters whileoperating in partial holdover without a usable time reference.

T-GMGNSS/GPS

ToD1PPS

1588

1588

T-TSC

T-BC

T-BC

T-BC

15881588

Node A

Node B

Node C

Node D

Node E

Passive

1588

1588 ToD

1PPSClock

Figure 2.1. BMCA Architecture Block Diagram

The figure above shows a possible scenario where node E encounters two boundary clock masters and chooses the best master clock.It will choose the boundary clock node C, because both boundary clocks have the same grandmaster and boundary clock node C isone hop closer to the grandmaster. In addition, the passive path between boundary clocks B & C is also a result of BMCA. They areboth connected to the same grandmaster node A, which is a higher quality master than each other, so the path between them is notused.

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeRole of Grandmaster, Boundary Clock, and Slave Clock


2.2 Time of Day (ToD)

As mentioned above, a grandmaster clock receives Time of Day messages while boundary clock and slave clock produce local time ofday clocks. As the name indicates, time of day messages communicate what time it is. However, it is a bit more complicated than that.For accurate data processing, a GPS receiver needs to know where the GPS satellites are and the speed they are travelling at, tocalculate how long the TOD spent in transmission.

Therefore, having a standard format for the time of day is critical for accurate timing. Different Time of Day formats are used in differentparts of the world, two of them are discussed here. NMEA is the primary standard use in the U.S. while ASCII(UTC/local) is the primarytime standard used worldwide.

2.2.1 NMEA

The National Marine Electronics Association 183 (NMEA)[7] is a standard intended to specify the communication protocol between ma-rine electronics for time and location but is now adopted in other applications.

NMEA messages use ASCII characters from 0x20(space) to 0x7e (~), the maximum length is 82 characters. The first character of eachmessage is $ or !, then the next five characters identify the talker and the message type.

For example, it can be GPRMC; the GP identifies the talker as a GPS transmitter and the RMC is the message type. There are manydifferent types of NMEA messages, the two that Si5389 can produce are RMC and ZDA.

RMC is recommended minimum specific GPS/Transit data; as the name suggests RMC provides the bare minimum information to iden-tify the GPS. The message includes the UTC time, validity flag, latitude, longitude, speed over ground, true course, date, magnetic var-iation, and checksum. Si5389 allows the user to change the RMC validity flag behavior by using the command pulsetime void, see com-mand family “pulsetime” for more information.

ZDA is date & time, it provides UTC, day, month, year, and local time zone. Si5389 allows the user to change the local time by usingthe command pulsetime zone, see command family “pulsetime” for more information.

Although RMC and ZDA both provide time and date information, ZDA messages contain local time information while RMC does not.There’s also an option available to print out both types of messages to provide both the GPS identity and local timing.

2.2.2 ASCII (UTC/Local)

UTC is the Coordinated Universal Time; UTC time is the primary time standard used by most countries in the world. UTC time origi-nates at 0° longitude, and world time is calculated by adding or subtracting hours from UTC. In general, UTC time is outputted in theformat of YYYY-MM-DDTHH:MM:SS

UTC has the concept of a leap second. A leap second is an added or skipped second, it is expressed as second 61 and 59. Leapseconds are necessary because UTC needs to compensate for Earth’s rotation slowing down. To date there are 37 UTC leap sec-onds[8].

Local time is derived from the UTC time. Local time add and subtract from the UTC time to produce its local time. For example, thewesternmost time zone uses UTC−12, because it is twelve hours behind UTC; and the easternmost time zone uses UTC+14. UTCdoes not observe change of season, so daylight saving time will cause some places to have a different offset from the UTC duringdifferent seasons.

2.2.3 Time Scale

The previous sections discussed the importance of using a standard time transmission format. To transmit time, the format of time alsoneeds to be standardized. According to IEEE1588, there are two components to a timescale (controlled by the grandmaster of the timedomain): the rate at which time advances and the epoch (the origin time). IEEE1588 allows two timescales, PTP and ARB (arbitrary).

PTP and ATB timescales share the same rate of time change, but PTP has a fixed epoch of January 1, 1972 while ARB determines itsown epoch.

The PTP timescale supports both UTC and International Atomic Time (TAI) time format. UTC and TAI follow the same rate of timechange and epoch. However, UTC observes leap second to compensate for the slowing Earth rotation. The 37 leap seconds makes theUTC time 37 seconds slower than the TAI time. PTP accommodates both time formats by transmitting the TAI time but adding a <cur-rentLeapSeconds> field to communicate the number of leap seconds that have occurred to date. The slave clock can then use the<currentLeapSeconds> field to generate the UTC time.



2.3 Definition of SyncE

Although the topic of this application note is PTP, it is worth noting the use of Synchronous Ethernet (SyncE) in conjunction with PTP.Industry standard compliant devices like the Si5389 uses SyncE to stabilize PTP. By doing so, the device can provide better timingaccuracy and integrate PTP technology seamlessly with existing networks.

2.3.1 ESMC Clock Quality

The Ethernet Synchronization Messaging Channel (ESMC) defined in ITU-T Recommendation G.8264[9] is a crucial component ofSyncE that communicates the Quality Level (QL) of the current SyncE path. ESMC uses Synchronization Status Messages (SSM) tocommunicate QL, which is the same format used by SONET and SDH technology.

The SyncE SSM is transmitted in the QL-TLV field of the ESMC. Table 11-4 from ITU-T G.8264 represents the basic QL-TLV format.

Table 2.1. QL TLV Format

Octet Number Size/Bits Field

1 8 bits Type: 0x01

2-3 16 bits Length: 00-04

4bits 7:4 (Note) 0x0 (unused)

bits 3:0 SSM code

Note: Bit 7 of octet 4 is the most significant bit. The least significantnibble, bit 3 to bit 0 (bits 3:0) contains the four-bit SSM code.

Table 11-8 from ITU-T G.8264 lists the SSM codes for SyncE option 2 networks. The Primary Reference Source (PRS) is the highestquality clock in SSM classified as stratum 1, it has an accuracy of 1 x 10-11. ST2 is traceable to stratum 2 which has an accuracy of 1.6x 10-8, ST3E is traceable to stratum 3E which has an accuracy of 4.6 x 10-6 and so on. See ITU-T Recommendation G.781 for moreinformation about clock quality[10].

Table 2.2. SSM Codes for SyncE in Option 2 Networks

Clock Quality-level SSM Code EnhancedSSM code

PRS QL-PRS 0001 0xFF

(Note) QL-STU 0000 0xFF

ST2 QL-ST2 0111 0xFF

TNC QL-TNC 0100 0xFF

ST3E QLST3E 1101 0xFF

ST3 QL-ST3 1010 0xFF

EEC2 QL-EEC2 1010 0xFF

(Note) QL-PROV 1110 0xFF

(Note) QL-DUS 1111 0xFF

PRTC QL-PRTC 0001 0x20

ePRTC QL-ePRTC 0001 0x21

eEEC QL-eEEC 1010 0x22

Note: There is no clock that corresponds to this quality level.



2.3.2 Synchronous Versus Nonsynchronous

SyncE has two modes of operation – synchronous and nonsynchronous. In addition to generating ESMC messages, synchronousclocks are required to have at least two reference clocks that are higher or similar quality to the clock itself. They must be able to gener-ate their own synchronization signal when they lose their external reference. In nonsynchronous mode, the SyncE does not processESMC messages and therefore does not extract the quality level information. Nonsynchronous clocks can be used if the quality of thenode reference clock is good.



3. Role of Servo Loop

In the first section, the functionalities of boundary clocks and slave clocks are outlined; however, implementing those functionalities isan involved process. To process 1588 messages and produce phase aligned frequencies requires a host stack, a servo loop, and aPLL.

Host stack is the software that controls the processor and it processes the 1588 messages as well as produces Time of Day messages.

Servo loop is the part of the PTP that uses the time received from the packet communication to produce statistics. Statistics from theservo loop algorithm are used to control Phase Locked Loops (PLL).

PLL is a control system that takes in an input and generates a phase aligned output. In a PTP system, PLL is critical to the transmissionof SyncE and the generation of clock frequencies.

3.1 Silicon Labs Si5389

In most cases, servo loop vendors purchase PLLs from PLL vendors to create their PTP module. Silicon Lab’s Si5389 offers a completeIEEE PTP solution that includes both the PTP Servo Loop and PLL.

Si5389 uses Silicon Labs’ industry leading Digital Signal Processing Phase Locked Loops (DSPLL) technology, enabling the product tohave low jitter, high accuracy 1PPS and SyncE, as well as fractional frequencies.

The embedded Silicon Labs’ MCU contains the PTP Servo Loop. The servo loop is the product of a partnership between Silicon Labsand a well-known IEEE PTP industry leader. Silicon Labs invested in the partnership to gain expertise on the PTP algorithm to becomea conversant expert on the implementation of IEEE PTP.

Silicon Labs’ Si5389 reference design utilizes the industry-standard Xilinx ZCU102 or ZCU111 FPGA carrier card as the host process-or, implementing the PTP messaging and timestamping. This reference design demonstrates the performance of the Si5389 and allowsfor ease of implementing on customer selected processors.

An ultra-low noise IEEE PTP solution also depends on the stability of the oscillator. For more information on oscillator selection for theSi5389 see Silicon Labs’ Application Note – ANxxxx: How to Choose the Correct Oscillator to Meet Your 1588-PTP Network Synchroni-zation Holdover Requirements[11].

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeRole of Servo Loop


3.2 MTIE and TDEV

The Maximum Time Interval Error (MTIE) and Time Deviation (TDEV) are both derived from Time Interval Error (TIE). TIE is the differ-ence between the measured clock and the reference clock.

MTIE is the peak to peak TIE in a given observation window. MTIE can only increase or stay constant, therefore a continually increas-ing MTIE results from a large variation of TIE errors and it indicates the oscillator’s traceability to the reference is poor.

TDEV is essentially the standard deviation of TIE as a function of time. If the cause for the time interval error is white noise, then TDEVshould decrease over time. However, if the noise is constant at a certain frequency, the TDEV will remain at the same level.

The oscillator impacts how much noise is generated by the PTP clock, which contributes the network’s packet delay variation, theamount of variance it produces and the holdover performance.

3.3 Servo Loop Accuracy Impact

3.3.1 Servo Loop Impact on PDV

As mentioned in Grandmaster, Boundary Clock, Slave Clock, and Transparent Clock, Two-Way delay calculation is the most accuratewhen the delay path is symmetrical. Unfortunately, this is not usually the case. Packets can often be delayed due to queuing, disrup-tions in the network, and load asymmetry, such delays are referred to as Packet Delay Variation (PDV).

One way to mitigate PDV effects is to increase the sync message packet rate and use PDV filtering to select the packets with the mini-mal delay. However, the effect of increasing the sync message packet rate is limited if the message accuracy is low. It is important tohave a high-quality oscillator to produce more accurate sync messages.

3.3.2 Servo Loop Impact on Variance Algorithm

As mentioned in Two-Step Versus One-Step, one of the Best Master Clock Algorithm criteria is the clock variance. Clock variation iscalculated using the Allan deviation which produces a second-order statistic on the variation of the frequency of the oscillator. There-fore, it is important for a master to have low variance to become the best master. For more information on the Allan deviation, see IEEEStd 1588™ - 2008 Section 7.6.3[1].

There are two types of clock variance estimates – Offset Scaled Log Variance and Observed Parent Offset Scaled Log Variance.

Offset Scaled Log Variance is an estimate produced by a clock that is not synchronized to another clock (free-running or holdover). Theestimate is included in timestamp messages to downstream clocks.

Observed Parent Offset Scaled Log Variance is the slave clock’s estimation of its parent clock’s variance.

3.3.3 Servo Loop Impact on Holdover Performance

Holdover performance is related to how long and how well the reference oscillator can maintain clock stability after the communicationto the master is lost. Holdover performance also depends on other factors such as the servo loop algorithm, but the quality of the oscil-lator reference is a critical component.

The higher a clock is on the timing hierarchy the better its holdover performance should be; i.e., a grandmaster should be better than aboundary clock which should be better than a slave clock. The higher a clock is in the hierarchy, more clocks depend on its accuracy. Atimestamp loses accuracy as it traverses down the clock path; therefore, it is imperative for a grandmaster to have as accurate of areference as possible.

In the BMCA scheme, holdover performance is used to determine the clock class. A clock that loses track to its primary reference de-grades to an associated class until it fails holdover specification.

For example:

A master clock is Clock class 6 when it is synchronized to a PTP primary reference time source.

It becomes Clock Class 7 when it is in holdover mode after losing synchronization.

It becomes Clock Class 52 when it is no longer in holdover after losing synchronization.

As mentioned in section Two-Step Versus One-Step, in clock class the lowest number wins, so a holdover clock is much higher in theclock class hierarchy than a free-running clock.

Moreover, if the oscillator can hold the clock in holdover for enough time, the clock would have a better chance of quickly reconnectingwith the primary clock reference.

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeRole of Servo Loop


4. Conclusion

ITU-T Precision Timing Protocol is a crucial component to achieving 5G mobile network performance. There are many parameters toconsider when implementing a PTP system, such as the ITU-T profile, the BMCA, the timescale, etc. The complexity of the system alsoincreases with the option of SyncE assist. Choosing a vendor to provide an integrated PTP and SyncE solution can significantly simplifythe design process.

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeConclusion


5. References

[1] IEEE 1588-2008, IEEE, 24 July 2008, doi:10.1109/IEEESTD.2008.4579760

[2] Meinberg IEEE1588 blog https://blog.meinbergglobal.com/category/ieee1588/

[3] ITU-T G.8265.1

[4] ITU-T G.8275.1

[5] ITU-T G.8275.2

[6] Albedo PTP Testing Overview http://www.albedotelecom.com/src/lib/WP-PTP-test-guide.pdf

[7] NMEA

[8] IPSES “Standard of time definition: UTC, GPS, LORAN and TAI” https://www.ipses.com/eng/In-depth-analysis/Standard-of-time-def-inition

[9] ITU-T G.8264

[10] ITU-T G.781

[11] ANxxxx: ”How to Choose the Correct Oscillator to Meet Your 1588-PTP Network Synchronization Holdover Requirements”

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeReferences


https://blog.meinbergglobal.com/category/ieee1588/

http://www.albedotelecom.com/src/lib/WP-PTP-test-guide.pdf

https://www.ipses.com/eng/In-depth-analysis/Standard-of-time-definition

https://www.ipses.com/eng/In-depth-analysis/Standard-of-time-definition

6. Glossary

BMCA

BMCA is a protocol for slave clocks to monitor and connect to the most accurate master clock.

ITU-T

The International Telecommunication Union - Telecommunication Standardization Sector publishes standards in the tele-communication field on a worldwide basis. The ITU-T standards are referred to as Recommendations since they do nothave authority to enforce.

OneWay & TwoWay

One-Way & Two Way timestamping describes the amount of time information exchanged between a master and a slave inone set of messages.

OneStep & TwoStep

One-Step & Two Step timestamping describes the mechanism the IEEE1588 master uses to transmit its time information.

Packet Rate

Packet rate is the established number of packets per second rate between an IEEE1588 master and slave.

SyncE

Synchronous Ethernet is an ITU-T standard for transmitting clock signals over the Ethernet physical layer.

T-BC

Telecom - Boundary Clock has multiple PTP ports in a domain, it can serve as either a master or a slave.

T-GM

Telecom- Grandmaster clock is the ultimate source of time in its domain.

T-TSC

Telecom- Time Slave Clock receives timing information from master clocks in the domain.

T-TC

Telecom- Transparent Clock adds its estimated delay to the transmitted timing information and passes the timing packetson to the next clock.

TAI

TAI is the International Atomic Time, it is a precise atomic time based on the Earth’s geoid. It is calculated as a weightedaverage of the time kept by over 400 atomic clocks in over 50 laboratories worldwide.

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeGlossary


7. Revision History

Revision 1.0

March 11, 2019• Initial Release

AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock ModeRevision History


ClockBuilder ProOne-click access to Timing tools, documentation, software, source code libraries & more. Available for Windows and iOS (CBGo only).

www.silabs.com/CBPro

Timing Portfoliowww.silabs.com/timing

SW/HWwww.silabs.com/CBPro

Qualitywww.silabs.com/quality

Support and Communitycommunity.silabs.com

http://www.silabs.com

Silicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701USA

DisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the information supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required, or Life Support Systems without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications.

Trademark InformationSilicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, ClockBuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® , Zentri, the Zentri logo and Zentri DMS, Z-Wave®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.

Documents

AN1202: ITU-T Precision Time Protocol Grandmaster ......Title AN1202: ITU-T Precision Time Protocol Grandmaster, Boundary Clock, and Slave Clock Mode Created Date 20200429150655Z