Implementing IEEE 1588v2 for Use in the Mobile Backhaul

8/6/2019 Implementing IEEE 1588v2 for Use in the Mobile Backhaul

1/22

White Paper

WEBSITE: www.jdsu.com

Implementing IEEE 1588v2 or usein the mobile backhaul

For most, the migration to an all-Ethernet or all-IP network will be a gradual process as network operatorsendeavour to maximise the li espan o their existing DM assets. However, the pace is quickening with the devel-opment o the IEEE 1588v2 standard. his standard enables the backhaul network to migrate to all-Ethernet,which provides much-required bandwidth at a ar lower cost-per-bit. It is o signi icant interest to network oper-ators seeking to grow their revenue by capitalizing on bandwidth-hungry applications like mobile broadband,music and video downloads. his document provides a brie overview o IEEE 1588v2 and looks at how you cancharacterise devices that will implement the standard.

Introduction

Although Ethernet has been the technology o choice or a rangeon LAN and WAN applications or decades, using it in the mobilebackhaul network presents a major challenge. Here, accurate syn-chronisation o base stations to nanoseconds accuracy is critical tominimise service disruptions and eliminate dropped connections ascalls move between adjacent cells. Highly accurate synchronisationalso ensures that the radio spectrum is not spread into the adjacentchannels. Plus, without stringent phase synchronisation, the multiplesignals in L Es multiple-input/multiple-output (MIMO) architec-ture can simply cancel one another out. And this is where IEEE1588v2comes in.IEEE1588v2 (also known as Precision ime Protocol, P P) is an

industry-standard protocol that enables the precise trans er o re-quency and time to synchronize clocks over packet-based Ethernetnetworks. It synchronizes the local slave clock on each network devicewith a system Grandmaster clock and uses tra ic time-stamping, withsub-nanoseconds granularity, to deliver the very high accuracies o synchronisation needed to ensure the stability o base station requen-cy and handovers. imestamps between master and slave devices aresent within speci ic P P packets and in its basic orm the protocol isadministration- ree.O course, the precision and per ormance o the IEEE 1588v2 protocolis based on the precision o the timestamp. he timestamps o incom-ing and outgoing packets clearly need to be recorded and assessed to

ensure synchronisation o master and slave devices. Di erences in time and requency between clocks and sub-sequent equipment corrections need to be evaluated, while clocks must be measured to ensure they are withintheir speci ied limits. Further, delays and dri ts in sync and their e ect on the trans er o timing through the net-work need to be considered too.Here, we examine the various methods you can use to characterise and measure the precision o timestamp syn-chronisation, as well as the accuracy o clocks, network devices and topology, be ore deploying equipment in anoperational network.

Calnex Solutions Ltd


2/22

White Paper: Implementing IEEE 1588v2 or use in the mobile backhaul 2

Maintaining Sync using IEEE1588v2In a packet transport system, clocks communicate with each other over the communication network using P P. All clocks, whethermaster or slave, lead back to and ultimately derive their time rom the Grandmaster clock. here are 5 types o P P clock devices:Ordinary Clock A single port device that can be a Master or Slave clock.Boundary Clock A multi port device that can be a Master or Slave clock.End-to-end ransparent Clock A multi port device that is not a Master or Slave clock but a bridge between the two. Forwards and

corrects all P P Messages. Correction achieved by addition o the bridge residence time into acorrection ield within the header o the message.

Peer-to-peer ransparent Clock A multi port device that is not a Master or Slave clock but a bridge between the two. Forwardsand corrects Sync and Follow_Up messages only. Correction achieved by addition o the bridgeresidence time + the peer-to-peer link delay, into a correction ield within the header o themessage.

Management Node A device that con igures and monitors clocks.

Table 1 PTP Device Types

Master and slave network devices are kept synchronized by the transmission o timestamps sent within the P P messages. here are twotypes o message in the P P protocol: Event Messages and General Messages. Event messages are timed messages whereby an accuratetimestamp is generated both at transmission and receipt o the message. General messages do not require timestamps but may containtimestamps or their associated event message.Event Messages General MessagesSyncDelay_ReqPdelay_ReqPdelay_Resp

AnnounceFollow_UpDelay_RespPdelay_Resp_Follow_UpManagement

Signaling Table 2 PTP Messages

Propagation Delay Measurement Mechanismshere are two mechanisms used in P P to measure the propagation delay between P P ports:Te Delay Request-Response MechanismTis mechanism uses the messages Sync, Delay_Req, Delay_Resp and, i required, Follow_Up.Te Peer Delay MechanismTis mechanism uses the messages Pdelay_Req, Pdelay_Resp and, i required, Pdelay_Resp_Follow_Up.

It is restricted to topologies where each peer-to-peer port communicates P P messages with, at most, one other such port.Ports on Ordinary or Boundary clocks can use either mechanism; ports on end-to-end transparent clocks are independent o thesemechanisms, and ports on peer-to-peer transparent clocks use only the peer delay mechanism. It should also be noted that the twomechanisms do not inter-work on the same communication path.


3/22


Synchronisationhere are two phases in the normal execution o the protocol:Phase 1 establishes the Master-Slave hierarchy.Phase 2 synchronizes the clocks using either o the two mechanisms described above.

Establishing the Master-Slave Hierarchy In each port o any Ordinary or Boundary clock there is a P P state machine. hese state machines use the Best Master Clock Algo-rithm (or BMCA) to establish the Master or the path between two ports. he statistics o the remote end o a path are provided to eachstate machine by the Announce message. Since the local clocks statistics are already known by the state machine, a comparison can bemade as to which is the best Master.A simple Master-Slave hierarchy is shown in the ollowing diagram. Paths 1, 2, 3, 4, and 5 may contain transparent clocks, but theseclocks do not participate in the Master-Slave hierarchy.

Figure 1 Simple Master-Slave Hierarchy

Synchronizing Ordinary and Boundary Clocks (using the delay request-response mechanism)Method 1.A ter the Master-Slave hierarchy has been established the clock synchronisation phase can start. his consists o the exchange o P Ptiming messages on the communications path between the two clocks.

here are two parts to this synchronisation method:

Measuring the propagation delay between Master and Slave. Per ormed using the delay request-response 1. mechanism.1.Per orming the clock o set correction. Once the propagation delay is known the Master can send Sync 2. and optional Follow_Up2.messages containing its master timestamp. hese are actually sent in part 1 also, but the ratio o propagation delay measurement toSync message would usually be quite low, that is, the propagation delay will be measured less than the clock o set correction.


4/22


(1) Measuring Propagation Delay in Clocks supporting the Delay Request-Response Mechanism

Figure 2 Propagation Delay Message Exchange

t1 = Master ime at point o sending Sync Message.t2 = Slave ime at point o receiving Sync Message.t3 = Slave ime at point o sending Delay_Req Message.t4 = Master ime at point o receiving Delay_Req Message.


5/22


Once the Slave knows the timing o t1, t2, t3, and t4, it can calculate the mean propagation delay (tmpd) o the messages path. his iscalculated rom:

he Sync and optional Follow_Up 1 messages give the master to slave message propagation time (t-ms).he Delay_Req and Delay_Resp messages give the slave to master message propagation time (t-sm).

Any asymmetry between t-ms and t-sm introduces an error into the clock o set correction.

(2) Performing the Clock Offset Correction

Once the Master to Slave propagation delay is known by the Slave, the clock correction can occur in the Slave device.

Figure 3 Basic Synchronisation Message Exchangehe Slave uses the Sync message and the optional Follow_Up message to calculate the clock o set rom Master to Slave. his is calcu-

lated rom(t2 t1) + (t4 t3)

he above is a simple model that does not show any end-to-end transparent clocks. End-to-end transparent clocks do not serve as Mas-ter or Slave clocks but they do insert/update a correction ield into event messages that allows adjustment o timestamps at the Slavedevice to remove residence times through any transparent clock devices/bridges. he above model would not include any peer-to-peertransparent clocks as these cannot coexist on the same communications path as the delay request-response mechanism.

1 The Follow_Up message is optional as the t1 timestamp may be sent in the Sync message meaning that the Follow_Up message is not required.


6/22


Method 2.A ter the Master-Slave hierarchy has been established the clock synchronisation phase can start.

here are two parts to this synchronisation method:Peer-to-peer ports maintain a measurement o the link propagation to each peer. hey do this using the 1. peer delay mechanism.1.Per orming the clock o set correction. Once the link propagation is known the master can send Sync and 2. optional Follow_Up2.messages containing its master timestamp.

(1) Measuring Link Propagation Delay in Clocks Supporting Peer-to-Peer Path Correctionhe link delay between two ports that implement the peer delay mechanism can be measured using the ollowing exchange o messages.

Figure 4 Link Delay Measurement

t1 = Port 1 ime at point o sending Pdelay_Req Message.t2 = Port 2 ime at point o receiving Pdelay_Req Message.t3 = Port 2 ime at point o sending Pdelay_Resp Message.t4 = Port 1 ime at point o receiving Pdelay_Resp Message.


7/22


Once Port 1 knows the timing o t1, t2, t3, and t4, it can calculate the mean link delay (tmld). his is calculated rom:

It then uses this value when calculating the correction ield or each Sync or Follow_Up message that passes through the bridge. he out-going correction ield will be the sum o the residence time, the mean link delay and any correction ield rom upstream ports.

he Pdelay_Req, Pdelay_resp and optional Pdelay_Resp_Follow_Up 2 messages allow the round trip link delay to be calculated (t-ms +t-sm).Any asymmetry between t-ms and t-sm introduces an error into the clock o set correction.

(2) Performing the Clock Offset Correction

Figure 5 Basic Synchronisation Message Exchange

he Slave uses the Sync message and the optional Follow_Up message to calculate the clock o set rom Master to Slave. his is calcu-lated rom

t2 t1 correction FieldA bene it o peer-to-peer path correction is that the path delay o each individual Sync or Follow_Up message is calculated as it travelsalong the communication path. It is there ore not a ected by a change to the path. When using this mechanism the clock synchronisa-tion does not require the return path to be calculated as it does in the basic exchange, i.e. the Delay_Req, Delay_Resp messages shown inFigure 1 do not occur. he path delay between the Master and Slave in this mechanism is simply contained within the correction ield o each Sync or Follow_Up message.An added bene it is that the Master has less processing to do as it will not receive any Delay_Req messages. his can be a major bene it inlinear topologies, when many slave clocks are connected to a single master.2The Pdelay_Resp_Follow_Up message is optional as the di erence between the t2 and t3 timestamps can be returned solely in the Pdelay_Resp message meaning that the Pdelay_Resp_Follow_Up message would not be required.


8/22


TopologiesDi erent applications avour di erent topologies. he three main topologies Hierarchal, Linear and Multiply Connected are shownin the ollowing diagrams (with cyclic paths that should be avoided):

Figure 6 Hierarchical Topology

Figure 7 Linear Topology


9/22


Figure 8 Multiply Connected Topology

Transport of PTP MessagesP P messages can be transported over several types o protocol. hese are listed below.

ransport ypeP P over UDP over IPv4P P over UDP over IPv6P P over IEEE 802.3/ EthernetP P over DeviceNEP P over ControlNEP P over IEC 61158 ype 10 (Field bus)

Table 3 PTP Transport Protocols

he mapping o each P P message into the lower layer protocols is shown in the ollowing sections.


10/22


PTP over UDP over IPv4 over EthernetWhen carried over UDP the irst byte o the P P message immediately ollows the inal byte o the UDP header. he UDP port number

ield identi ies the UDP datagram as a P P message.

Figure 9 PTP Message within UDP over IPv4 over Ethernet

PTP over UDP over IPv6 over EthernetWhen carried over UDP the irst byte o the P P message immediately ollows the inal byte o the UDP header. he UDP port number

ield identi ies the UDP datagram as a P P message.

Figure 10 PTP Message within UDP over IPv6 over Ethernet


11/22


PTP over IEEE 802.3/EthernetWhen carried over Ethernet the irst byte o the P P message occupies the irst byte o the client data ield o the Ethernet rame. heEthernet type ield is set to 0x88F7 and identi ies the client data ield as a P P message.

Figure 11 PTP Message within an Ethernet Frame

PTP Message FormatsAll P P Messages consist o a header, body and optional su ix.

Figure 12 Basic PTP Message Format


12/22


Headerhe header is common to all P P messages. It is 34 bytes long and its ormat is shown below.P P Message Header Format

BitsOctets O set

7 6 5 4 3 2 1 0transportSpeci ic message ype 1 0

Reserved version P P 1 1messageLength 2 2domainNumber 1 4

Reserved 1 5Flags 2 6

correctionField 8 8Reserved 4 16

source PortIdentity 10 20sequenceID 2 30controlField 1 32

logMessageInterval 1 33

Table 4 PTP Header Format

he messageType ield de ines which type o message is contained in the body o the message, or example Sync, Delay_Req, Delay_Resp etc.

he messageLength ield de ines the ull length o the P P message, i.e. including the header, body and any su ix (but excluding any padding).

he domainNumber ield identi ies the domain the P P message belongs to. A domain is a logical grouping o clocks that synchronize

to each other using the protocol, but that are not necessarily synchronised to clocks in another domain.he flags ield contains various lags to indicate status.he correctionField contains a correction value in nanoseconds or residence time within a transparent clock and will also include the

path delay or peer-to-peer transparent clocks.he sourcePortIdentity ield identi ies the originating port or this message.he sequenceID ield contains (with some exceptions) a sequence number or individual message types.he controlField is a historical ield whose value depends on the message type; it con orms to version 1 o the standard. he ield is simi-

lar to the message ype ield but with less options.he logMessageInterval ield is determined by the type o the message.

Further in ormation on the speci ic details o each ield can be ound in standard IEEE P1588.


13/22


BodyAs previously discussed there are several di erent types o P P message. Each is discussed below.

Announce Messagehe announce message is used to indicate the capabilities o a clock to the other clocks on the same domain. his allows the Master-Slave

hierarchy to be established. (See the IEEE 1588 standard or the speci ic ield details.)

Announce Message FormatBits

Octets O set7 6 5 4 3 2 1 0

header (13.3) 34 0origin imestamp 10 34currentUtcO set 2 44

Reserved 1 46grandmasterPriority1 1 47

grandmasterClockQuality 4 48grandmasterPriority2 1 52grandmasterIdentity 8 53

stepsRemoved 2 61timeSource 1 63

Table 5 Announce Message Format

Sync Messagehe sync request message is sent by a Master clock and contains the Master time when the Sync message was sent. I the Master clock is

a two-step clock, the timestamp in the Sync message will be set to zero and the actual sending timestamp will be sent a terwards in theassociated Follow_Up message. Sync messages are sent in both types o P P delay measurement mechanism.

Sync Message FormatBits

Octets O set7 6 5 4 3 2 1 0

header (13.3) 34 0origin imestamp 10 34

Table 6 Sync Message Format

Delay_Req Messagehe ormat o the Delay_Req message is identical to the Sync message. he Delay_Req message is sent by a Slave clock and contains the

Slave time when the Delay_Req message was sent. Delay_Req messages are sent only in the delay request-response mechanism.Delay_Req Message Format

BitsOctets O set

7 6 5 4 3 2 1 0header (13.3) 34 0

origin imestamp 10 34

Table 7 Delay_Req Message Format


14/22


Follow_Up Messagehe Follow_Up message is optionally sent by a Master clock and contains the Master time when the Sync message was sent. It is used

when the Master clock is a two-step clock, i.e. two steps Sync message and Follow-Up message. Follow_Up messages are sent in bothtypes o P P delay measurement mechanism.

Follow_Up Message FormatBits

Octets O set7 6 5 4 3 2 1 0

header (13.3) 34 0preciseOrigin imestamp 10 34

Table 8 Follow_Up Message Format

Delay_Resp Messagehe Delay_Resp message is sent by the Master clock and contains the Master time when the Delay_Req message was received. Delay_

Resp messages are sent only in the delay request-response mechanism.

Delay_Resp Message FormatBits

Octets O set7 6 5 4 3 2 1 0

header (13.3) 34 0receive imestamp 10 34

requestingPortIdentity 10 44

Table 9 Delay_Resp Message Format

he requestingPortIdentity ield contains the sourcePortIdentity ield ( rom the header o the associated Delay_Req message) o theSlave that requested this Delay_Resp message.

Pdelay_Req Messagehe Pdelay_Req message is sent by a delay requester peer-to-peer clock and contains the delay requester peer-to-peer clock time when

the Pdelay_Req message was sent. Pdelay_Req messages are sent only in the peer delay mechanism.Pdelay_Req Message Format

BitsOctets O set

7 6 5 4 3 2 1 0header (13.3) 34 0

origin imestamp 10 34reserved 10 44

Table 10 Pdelay_Req Message Format


15/22


Pdelay_Resp Messagehe Pdelay_Resp message is sent by a delay responder peer-to-peer clock and contains the delay responder peer-to-peer clock time

when the Pdelay_Req message was received. Pdelay_Resp messages are sent only in the peer delay mechanism.Pdelay_Resp Message Format

BitsOctets O set

7 6 5 4 3 2 1 0header (13.3) 34 0

receiveReceipt imestamp 10 34requestingPortIdentity 10 44

Table 11 Pdelay_Resp Message Format

he requestingPortIdentity ield contains the sourcePortIdentity ield ( rom the header o the associated Pdelay_Req message) o the

delay requester peer-to-peer clock that requested this Pdelay_Resp message.I the delay requester peer-to-peer clock is a two-step clock, the timestamp in the Pdelay_Resp message will be set to zero and the actualsending timestamp will be sent a terwards in the associated Pdelay_Resp_Follow_Up message 3.

he reserved ield is used to make the message length the same as the Pdelay_resp message as some networks have di erent transmittimes or di erent bridge message lengths which would introduce asymmetry errors.

Pdelay_Resp_Follow_Up Messagehe Pdelay_Resp_Follow_Up message is optionally sent by a delay responder peer-to-peer clock and contains the delay responder

peer-to-peer clock time when the Pdelay_Resp message was sent. It is used when the delay responder is a two-step clock, i.e. two steps Pdelay_Resp message and Pdelay_Resp_Follow_Up message. his message also has the option o sending a turnaround time instead o the sending timestamp. he turnaround time o receiving the Pdelay_Req to sending back the Pdelay_Resp. Pdelay_Resp_Follow_Upmessages are sent only in the peer delay mechanism.Pdelay_Resp_Follow_Up Message Format

BitsOctets O set

7 6 5 4 3 2 1 0header (13.3) 34 0

responseOrigin imestamp 10 34requestingPortIdentity 10 44

Table 12 Pdelay_Resp_Follow_Up Message Format

he requestingPortIdentity ield contains the sourcePortIdentity ield ( rom the header o the associated Pdelay_Req message) o thedelay requester peer-to-peer clock that requested this Pdelay_Resp message.

Signalling Message

Signalling Message FormatBits

Octets O set7 6 5 4 3 2 1 0

header (13.3) 34 0targetPortIdentity 10 34One or more LVs N 44

Table 13 Signalling Message Format

he targetPortIdentity ield contains the address o the target port/ports o this message.LV = ype, Length, Value Identi ier

3 There is also the option o sending a turnaround time instead o the sending timestamp.


16/22


Management MessageP P management messages are used to transmit in ormation rom a clock to a node manager and rom a node manager to one or moreclocks.Management Message Format

BitsOctets O set

7 6 5 4 3 2 1 0header (13.3) 34 0

targetPortIdentity 10 34startingBoundaryHops 1 44

boundaryHops 1 45Reserved actionField 1 46

Reserved 1 47management LV M 48

Table 14 Management Message Format

he targetPortIdentity ield contains the address o the target port/ports o this message.he startingBoundaryHops ield contains the number o boundary clocks that this message is allowed to be retransmitted by.he boundaryHops ield contains the number o remaining boundary clock retransmissions le t or this particular management mes-

sage request or reply. his ield is an identical value to the startingBoundaryHops ield or the initial transmission rom the issuing clock/node.

he actionField contains the type o action that this management message is required to per orm. he types are Get, Set, Response,Command and Acknowledge.

he managementTLV ields are shown below.

BitsOctets LVO set7 6 5 4 3 2 1 0

tlv ype 2 0lengthField 2 2

managementID 2 4dataField N 6

Table 15 ManagementTLV feld Format

he tlvType ield shall be set to MANAGEMEN (0x0001).he lengthField is the length o the LV. he ormat is 2+N where N is an even number.he managementID ield de ines the type o management message. Examples o which are Initialize, Enable_Port, Disable_Port. See

the IEEE 1588 standard or the ull list o management IDs.he dataField is managementID dependant. See the IEEE 1588 standard or details.


17/22


Testing and Introducing ImpairmentsWhile IEEE 1588v2 P P uses an exchange o specially designed packets to calculate the di erence in time and requency between twoclocks, the overall precision o an Ethernet-based mobile backhaul is dependant on many actors. Di erent topologies, equipment andtra ic management introduce di erent amounts o latency and synchronisation jitter. Servicing delays impact the accuracy o the time-stamp which, in turn, reduces the precision o the clock adjustment calculations. Synchronisation between clocks can dri t when the

requency o set between the master and the slave is being corrected. Additionally network equipment such as switches, routers, andgateways can all introduce latency and wander errors.Clearly, there is a need to test network synchronisation be ore and a ter the deployment o a network and/or equipment. One way is touse Calnex Solutions Paragon Sync test solution, con igured as shown below:

Figure 13 IEEE 1588v2 Example Test Setup

Con igured in this way, the Calnex Paragon can:

Per orm analysis o 1588v2 messages and timestamps as shown in the graphs below.Run all the I U- G.8261 test cases.Capture a PDV profle rom a real network or trial network over long periods (many days) and replay the same profles back in thelab during testing.Add impairments to P P messages: Lost P P message ability to delete a speci ic P P message type. Duplicated P P message ability to duplicate a speci ic P P message type. Mis-ordered P P message ability to mis-order speci ic P P message types or mis-order between types, e.g. swap order o a

Sync and Follow_Up message.Insert PDVs onto a specifc P P message type on orward and reverse path. Tis allows path asymmetry to be tested. Ability to insert an equivalent delay value into the correction ield o the P P message header. his allows the emulation o a

transparent clock.


18/22


Two-way Timing Protocol, PDVs and Wander

Sync PDV (1-step and 2-step)

he Sync PDV (Packet Delay Variation) graph plots the PDVbased on the Sync message arrival time and its embeddedtimestamp. (When using a 2-step clock, the timestamp in the Fol-low_Up message is used instead o the timestamp in the Sync.)

his determines the PDV rom the Master to the Slave. I capturednext to the Slave device, this shows the actual PDV experienced by the Sync message as it travels rom Master to Slave.


19/22


Delay_Request PDV

he Delay_Req PDV is calculated using the arrival time o theDelay_Req messages and the embedded timestamp in the corre-sponding Delay_Resp messages (t4). his graph shows the PDV

rom the Slave to the Master, as experienced by Delay_Req mes-sages travelling to the Master clock.

Follow_Up PDV

he Follow_Up PDV graph plots the variation in arrival timebetween Sync and Follow_Up messages. his can indicate whetheror not there is a regular gap between these messages and whetherthe gap can a ect the operation o the Slave clock recovery. Anexcessive gap may lead to the Slave discarding the correspondingSync message as it time-outs waiting or its arrival, hence leadingto a reduction in the number o timing events received by the Slaveclock recovery circuit.

Slave Clock Wander

he Slave Clock Wander is a measurement o the stability o therecovered Slave clock. he embedded timestamp in the Delay_Req message ( 3) is plotted while synchronised to the Master.

his gives the ability to monitor the Slave clock wander on theEthernet inter ace without needing access to the actual recoveredclock signal.


20/22


Round rip Delay Variation

he Round rip Delay (R D) variation graph plots the variationin {(t2-t1)+(t4-t3)}/2, which is the R D calculation per ormed by the Slave. his indicates the stability o this R D, and allows theuser to assess whether changes in R D are impacting the Slaveclock recovery and stability. Signi icant variation will stress theSlaves clock recovery circuit to determine the true path delay.Floor delay is an important parameter in some Slave clock imple-mentations. I the loor delay moves up or long periods, this may cause wander in the recovery clock. Other designs are reported touse certain bands o delay e.g. only the message pairs that exhib-it a R D between x% and y% o the total range measured. I thedensity there ore changes, this may cause wander in the recovered

clock.

Asymmetry in Path Delay

he Asymmetry graph plots the di erence between Master >Slave delay and Slave > Master delay. his variation is e ectively a variation in symmetry, which is a basic assumption o IEEE-1588.I a variation is detected, the user can assess its impact on Mas-ter and Slave clock operation. As the slave assumes symmetry,changes in symmetry will cause errors in the calculation o time.Signi icant, sustained changes in path symmetry may lead to wan-der in the recovered clock.

Sync IPG

he Sync Inter-Packet Gap (IPG) graph shows the variation inarrival time o the Sync messages. here is no requirement or themessages to arrive in a regular spacing as each carries a timestamp.However, excessive variation will lead to periods where the num-ber o Sync messages being received is signi icantly reduced. I thisoccurs at the same time as excessive PDV in the network, the pre-selection algorithms in some Slave devices may lead to very ewSync messages being selected to be passed to the clock recovery circuit. his can lead to increased wander on the output.


21/22


Delay_Resp Round rip Delay

he Delay-Resp Round rip Delay (R D) graph shows the in timetaken by the Master to respond to the Delay_Req message witha Delay_Resp message. here is no speci ication or this param-eter. he Slave must wait or the Delay_Resp message to arrive inorder to be in ormed o the t4 time. Without this in ormation, itcan not determine the Round rip Delay. he Slave will not wait

orever or the response to arrive and will have a time-out imple-mented. Should the Masters response time signi icantly increase(e.g. when multiple Slaves all send Delay_Req messages concur-rently), a time-out may be invoked. his will lead to a signi icantreduction in the number o R D calculation events available to theSlave and hence lead to increased wander on the recovered clock.

he 1588v2 Header capture on the Calnex Paragon can also help troubleshoot issues with Master and Slave clocks. he screen aboveshows a deviation to the normal Sync-Delay_Req-Delay_Resp sequence o messages. In this case, a Delay_Req message (Seq ID 44687)has not had a Delay_Resp response. A batch o Sync messages is also sent by the Master with no response; this can give insight into theoperation and interaction between Master and Slave devices.


22/22

Test & Measurement Regional Sales


Implementing IEEE 1588v2 for Use in the Mobile Backhaul

Documents

Transcript of Implementing IEEE 1588v2 for Use in the Mobile Backhaul