Field Test Plan for Frequency

Synchronization using PTP

Calnex Sentinel

Frequency synchronization is critical for all mobile

technologies. PTP synchronization to NodeB or
eNodeB devices must meet tight ITU-T standard
specifications as well as vendor specific limits.

This test plan provides field test procedures to

ensure high quality synchronization for 3G or LTE
mobile backhaul networks running the PTP protocol.

This test plan is applicable to ALu, Ericsson, Huawei,

NSN, and ZTE base stations, and to Huawei, ALu,
Cisco, Tellabs, ZTE, Juniper, Ericsson and other
cell-site routers/PTN equipment.
Contents
1 Background ..................................................................................................................................................... 3
2 Test Setup ........................................................................................................................................................ 4
2.1 Pseudo-slave Mode: Sentinel connects to cell site router. ........................................................................ 4
2.2 Monitor Mode: Sentinel connects to TAP or splitter. ................................................................................. 4
3 Test Configuration........................................................................................................................................... 5
3.1 Operating Mode ........................................................................................................................................ 5
3.2 Measurement Mode .................................................................................................................................. 5
3.3 Time Base ................................................................................................................................................. 6
3.4 Physical Interface Setup ........................................................................................................................... 7
3.5 PTP Setup ................................................................................................................................................. 8
3.6 Packet Selection for FPP Measurements to G.8261.1 .............................................................................. 9
3.7 Vendor Specific Network PDV Distribution (PDD) Pass/Fail Criteria ........................................................ 9
3.8 Select Recovered Clock Mask ................................................................................................................ 10
3.9 Signal Check ........................................................................................................................................... 10
3.10 Start the Test .......................................................................................................................................... 11
4 Measurement Results Display ...................................................................................................................... 12
5 Test Cases ..................................................................................................................................................... 13
5.1 Network PDV to ITU-T G.8261.1 ............................................................................................................. 13
5.2 Recovered Clock Stability to ITU-T G.8261.1 ......................................................................................... 16
5.3 PTP Packet-to-Packet PDV Capture ....................................................................................................... 17
5.4 Packet Delay Distribution (PDD) Analysis ............................................................................................... 17
5.5 MAFE (Maximum Average Frequency Error) .......................................................................................... 19
6 Test Results Interpretation ........................................................................................................................... 20
6.1 With Slave Clock Output ......................................................................................................................... 20
6.2 Without Slave Clock Output .................................................................................................................... 20
7 Offline Analysis and Report Generation using CAT ................................................................................... 21
7.1 Overview ................................................................................................................................................. 21
7.2 Selecting ITU-T G.8261.1 Metrics in CAT ............................................................................................... 21
7.3 Selecting Metrics ..................................................................................................................................... 22
7.4 Generating a Report................................................................................................................................ 24
Appendix A: PTP (1588) Synchronization Technology .................................................................................... 25
Appendix B: ITU-T Recommended Network Limits for Packet Networks ...................................................... 26
Appendix C: ITU-T Recommended Slave Clock Network Limits..................................................................... 28
Appendix D: Example Generated Report .......................................................................................................... 29

Note: All measurement data shown can be imported to the Calnex Analysis Tool (CAT) 1 for detailed analysis.

1 Sentinel includes a single copy of CAT

Page 2 of 3
1 Background
Frequency synchronization is critical for all mobile technologies.

The requirements for different mobile technologies are listed in the table below.

Application Frequency Time Packet Backhaul Spec

CDMA2000 ±50 ppb ±3 to 10 µs

TD-SCDMA ±50 ppb ±1.5 µs

GSM ±50 ppb n/a ±16 ppb (G.8261.1)

WCDMA ±50 ppb n/a ±16 ppb (G.8261.1)

LTE (FDD) ±50 ppb n/a ±16 ppb (G.8261.1)

±16 ppb (G.8261)

±1.5 µs (<3 km cell radius)
LTE (TDD) ±50 ppb ±1.1 µs (for ±1.5 µs
±5 µs (<3 km cell radius)
G.8271.1)

LTE-A MBSFN ±50 ppb

±16 ppb (G.8261.1)
±1 to 5 µs
LTE-A CoMP ±50 ppb ±1.1 µs (for ±1.5 µs
Implementation dependent
G.8271.1)
LTE-A eICIC ±50 ppb

n/a (FDD) ±33 ppb

Small Cells ±100 ppb ±1.5 µs (TDD) ±1.1 µs (for ±1.5µs
±1 to 5 µs (eICIC) G.8271.1)

±100 ppb
n/a (FDD)
Home Cells ±250 ppb ±1.1 µs (for ±1.5 µs
±1.5 µS (TDD)
G.8271.1)

Note: The 50 ppb frequency stability requirement is at the Air interface. For the mobile backhaul, it is
accepted that this translates to a requirement of 16 ppb. For small cells, the requirements are 100 ppb at the
Air interface and 33 ppb for the mobile backhaul.

Page 3 of 4
2 Test Setup
Sentinel works as a PTP 2 pseudo slave connecting to a switch or a router in the network. It can also
work in Monitor Mode, connecting between the PTP master and slave via an optical splitter or electrical
TAP. It measures the performance of the network and the performance of the recovered clock
simultaneously. Common interfaces for recovered frequency measurements are
E1/T1/2MHz/10MHz.Typical field test setups using Sentinel are shown below.

2.1 Pseudo-slave Mode: Sentinel connects to cell site router.

2.2 Monitor Mode: Sentinel connects to TAP or splitter.

2 See Appendix A

Page 4 of 5
3 Test Configuration
Before performing any measurements, follow the steps below.

3.1 Operating Mode

From the Mode page configure Sentinel operating mode. For Pseudo PTP slave operation select one channel
as SyncE / PTP Slave, for monitor mode select PTP Monitor Mode. For each recovered clock being tested,
select a CLOCK channel.

NOTE: Each clock module supports the simultaneous measurement of 2 input clocks with frequencies
ranging from 0.5Hz to 200MHz.

NOTE: Running in monitor mode requires 2 packet modules.

NOTE: If not operating in monitor mode packet modules can be configured for any combination of NTP Client
or PTP Slave operation.

NOTE: Sentinel automatically measures the TIE of the SyncE recovered clock of any configured PTP / NTP
channel.

3.2 Measurement Mode

From the main GUI display window, select Settings > Measurement > Common.

Set Mode to TIE + PDV and set the required test duration. The recommended test duration is 24 hours for
normal network performance test. If intermittent issues occur in the network, a longer test duration may be
required in order to capture the intermittent issues.

Page 5 of 6
 3.3 Time Base

Set Sentinel to use the Internal clock as time base reference and choose GNSS signal as the Internal
Reference Disciplining Source. Set Measurement Start Behavior to Wait till Timebase Reference is
ready, and Internal Reference Disciplining Mode to Always if a GNSS reference is available.
Otherwise, set to Not during the measurement if no reference is available.

For other options of time configurations, please consult Sentinel user manual 3

NOTE: From a cold start, it takes around 15 minutes for the internal Rubidium timebase to warm up.
With the GNSS antenna connected, the GNSS receiver needs to lock to at least 3 satellites before it can
output a valid reference to the Rubidium for disciplining. If less than 3 satellites are locked, the Rubidium
will go into holdover.

NOTE: If no GNSS signal is availabile at the test site, the internal Rubidium can be disciplined in
advance by applying a GNSS signal in the lab before going on site. The embedded battery on the
Sentinel will keep the Rubidium in holdover during the transportation from lab to the field by setting
Sentinel into transport mode. To achieve high accuracy, it is recommended to train the Rubidium in the

3 Calnex Document CX3001

Page 6 of 7
 lab for at least 12 hours. If Sentinel was last disciplined less than a week ago, this time can be shortened
to 6 hours.

NOTE: To put Sentinel in Transport Mode, press the button on the front panel. The following
window will be displayed. Click on Transport Mode.

NOTE: Without mains power supply, the battery can keep the internal Rubidium powered for up to 3 hours.
Once mains power is supplied again, the Rubidium will be powered by the main supply and the battery will
start to re-charge.

3.4 Physical Interface Setup

Each packet module that is being used should be configured to match the media that it is connected to.
For PTP Pseudo Slave mode this is done through the Settings > Channel x > Ethernet page.

Ensure that the physical media properties match the properties of the port being connected to. Any
required VLAN configuration should be entered. If a DHCP server is not being used then the IP properties
should be manually entered.

NOTE: Prior to testing, an IP address should have been provisioned by the operator along with details of
the network mask and gateway address.

For monitor mode the media properties can be set through the Settings > Monitered Channels >
Ethernet page.

Page 7 of 8
 There is an Ethernet page for both channels used and these should be set to the same values. Electrical
TAPs may require Auto-Negotiation to be Enabled while optical splitters generally require a fixed rate
to be entered.

3.5 PTP Setup

In Pseudo Slave mode, select G.8265.1 Frequency Profile on the Settings > Channel x > PTP page,
then configure the PTP slave related parameters i.e. Domain, Master address, and packet rates as
required. Ensure Normalize delays is On.

NOTE: Ensure the IP address of the Sentinel pseudo-slave is provisioned before going out into the field.

NOTE: ITU-T G.8265.1 profile requires the slave to negotiate the message rates with the IEEE1588 GM.
Ensure that the message rates entered for Sentinel can be supported by the IEEE1588 GM.

In monitor mode the PTP GM / Slave pair to be monitored can be configured on the Settings >
Monitored Channels > Monitor Mode page. This can be configured manually or the Discover function
used. Pressing the Discover button will bring up a pop-up box with a list of all PTP flows detected.
Selecting the appropriate flow will cause the Monitored Domain, Master IP and Slave IP boxes to be
automatically populated along with the appropriate protocol and transport options.

Page 8 of 9
 Ensure Normalize delays is set to On.

3.6 Packet Selection for FPP Measurements to G.8261.1

From the Settings > Channel x > Selection or Settings > Monitored Channels > Selection page,
configure the packet selection parameters as follows.

1. Select Fwd PDV (Sync) from the Apply selection to dropdown box.
2. Set the parameters for packet selection.
3. Set Pass/Fail FPP mask level to 1% for FPP analysis. Please refer to appendix C for the ITU-T
definition of FPP

3.7 Vendor Specific Network PDV Distribution (PDD) Pass/Fail Criteria

Configure the Pass/Fail criteria for Packet Delay Distribution (PDD) analysis. This Pass/Fail criteria is
vendor specific. Please consult vendors for parameters. If vendor has no specification for network PDV,
then there is no need to configure this page.

Page 9 of 10
3.8 Select Recovered Clock Mask

Select clock metric related masks from the Masks tab. Mask G.8261.1 Case 3 is recommended for
network conformance test. This mask is explained in Appendix B.

3.9 Signal Check

1. Click on the Health Check > Signal Check button.

Page 10 of 11
 2. Make sure the signal check detects the expected signals. An example screen shot is shown below.

3.10 Start the Test

1. Click on the Start button.

2. Sentinel will prompt you to select where to store the measurement results. The results can be either
saved on Sentinel or external USB sticks.

NOTE: For longer term measurements, it is always recommended to use external USB memory sticks to
ensure sufficient storage space.

Page 11 of 12
4 Measurement Results Display
Once the measurement starts, the TIE graphs of the recovered clock and SyncE will be displayed on the main
GUI window. All TIE graphs will be displayed in the same window, but highlighted in different colors.

If the PTP GM and the Sentinel emulated Slave establish the session successfully, the negotiated parameters
will be displayed in the channel specific widget as below and on the information page accessed by pressing
the button.

Page 12 of 13
 Pressing the top left button on the channel widget gives the option of hiding the graph or bringing it to the
foreground.

The PDV for the forward direction (from GM > slave) is also graphed. To view PDV for forward direction click
on the Fwd PDV button.

NOTE: Sentinel also graphs the PDV for the reverse direction (Slave > GM). If Normalize delays is set to
Off, Sentinel can also calculate Path Delay and 2Way Time Error. These metrics are not required or
quantified for frequency synchronization.

5 Test Cases
The following Test Cases 5.1 and 5.2 evaluate the performance of the network and the recovered clock
against the ITU-T G.8261.1 recommendation. Test Cases 5.3, 5.4 and 5.5 provide further troubleshooting and
debugging information to perform further analysis on the results of 5.1 and 5.2.

Note: All test cases can run at the same time, that is, ONE single test.

5.1 Network PDV to ITU-T G.8261.1

The Floor Packet Percent (FPP) metric is specified in ITU-T G.8260 and is used to evaluate the Network
PDV. Pass/Fail evaluation is compared against the limit specified in ITU-T G.8261.1. Please refer to the
Appendix for more information.

5.1.1 FPP Measurement and Analysis

To view FPP, click on the FPP button on the metrics menu. The Pass/Fail mask and the FPP graph will
be displayed in the same window. The test fails if the FPP value ever falls below the mask.

Page 13 of 14
Page 14 of 15
 5.1.2 Sample FPP Test Results

Example
Results

Above FPP limit - Pass FPP close to limit FPP below limit - Fail

• Priority setting wrong • Priority setting wrong

Possible • Network congestion • Network congestion
n/a
Causes • Re-route event • Re-route event
• Network equipment failure • Network equipment failure

• Congestion causes • Congestion causes

depopulation of the floor delay depopulation of the floor
Possible • Re-routes move the floor, delay
n/a
Impact reducing “headroom’ for the • Re-routes move the floor,
FPP analysis eliminating all packets within
the cluster range

• Visual inspection for re-routes • Visual inspection for re-routes

and/or congestion and/or congestion
• If re-route event occurs, • If re-route event occurs,
segment the data into segment the data into
separate data sets separate data sets
• Apply FPP analysis separately • Apply FPP analysis
Next
n/a to each data set separately to each data set.
Action • If congestion, check PTP • If congestion, check PTP
running at highest priority. running at highest priority
• Check for over-subscription of • Check for over-subscription of
allocated data rate allocated data rate
• Measure further back in the • Measure further back in the
network network

Page 15 of 16
 5.2 Recovered Clock Stability to ITU-T G.8261.1 4

5.2.1 Compare with MTIE Mask

To view MTIE and compare with the mask, click
on the MTIE button. The G.8261.1 mask will also
appear in the same display area as a dashed
line. Multiple masks can be selected at the same
time for comparison. The screenshot shows the
10MHz and SyncE recovered clocks wander
measurement. The test passes if the clock MTIE
is always below the mask.

5.2.2 Sample G.8261.1 Test Results

Example
Results

Within G.8261.1 limits Close to G.8261.1 limits Outside G.8261.1 limits

• The network PDV is • The network PDV is too

stressing the slave to its limit stressful for the slave
with the current network • The priority setting for PTP
configuration packets may be too low
Possible • Network equipment failure • The traffic level in the
n/a
Causes network may be too high
• Temperature variation may
impact the performance of
clocks
• Network equipment failure

• Interference at air interface • Interference at air interface

Possible • Drop calls • Drop calls
n/a
Impact • Handover failure • Handover failure
• Slow data transmission • Slow data transmission

• Share the PDV capture with • Share the PDV capture with
the PTP slave vendor (and PTP slave vendor (and
NodeB vendor if external NodeB vendor if external
slave is used) slave is used)
• Replay the PDV in the lab to • Replay the PDV using
troubleshoot and adjust the Paragon-X in the lab to
slave algorithm to increase troubleshoot and adjust
Next
n/a margin Client algorithm to enable it
Action • Consider re-routes and/or to pass mask
re-engineering the network • Consider re-routes and/or re-
to reduce PDV stress engineering the network to
• Measure further back in the reduce PDV stress
network • Measure further back in the
• Re-test network
• Re-test

4 ITU-T G.8261.1 specifies the wander limit at the clock out interface of a PTP client

Page 16 of 17
5.3 PTP Packet-to-Packet PDV Capture

The PTP PDV graph gives information such as:

• Average/standard deviation of PDV

• Delay jumps due to routing changes

From the PDV graphs, post-analysis can be performed on the data such as packet metrics. These PDV
files can be sent back to the operator’s lab or the vendor’s R&D center’s to reproduce the exact same
PDV conditions experienced by the slave in the network and take remedial action.

5.3.1 View PDV Graph

To view the PDV graphs for Sync, Del-Request and Path Delay, click on Fwd PDV (Sync), Rev PDV
(Del-Req), and Path Delay from the measurement menu.`

5.4 Packet Delay Distribution (PDD) Analysis

Performing PDD analysis is important for many vendor’s NodeB equipment. Many NodeB devices have a
specification where the distribution of the packets should meet particular limits.

5.4.1 Analyze and View PDD

To analyze PDD on the Sentinel, select Distr/Fwd PDV metrics menu.

Page 17 of 18
 5.4.2 Sample PDD Test Results

Example
Results

Within PDD limits - Pass PDD close to limits PDD outside limits - Fail

• Priority setting wrong • Priority setting wrong

Possible • Network congestion • Network congestion
n/a
Causes • Re-route event • Re-route event
• Network equipment failure • Network equipment failure

• Congestion causes
• Congestion causes
depopulation of the floor
depopulation of the floor delay
Possible delay
n/a • Re-routes move the floor,
Impact reducing “headroom’ for the
• Re-routes move the floor,
eliminating all packets within
PDD analysis.
the cluster range.

• Visual inspection for re-routes • Visual inspection for re-routes

and/or congestion and/or congestion
• If re-route event occurs, • If re-route event occurs,
segment the data into segment the data into
separate data sets separate data sets
• Apply PDD analysis • Apply PDD analysis
Next
n/a separately to each data set separately to each data set
Action • If congestion, check PTP • If congestion, check PTP
running at highest priority. running at highest priority.
• Check for over-subscription of • Check for over-subscription of
allocated data rate. allocated data rate.
• Measure further back in the • Measure further back in the
network network

NOTE: Consult each vendor for their specific Pass/Fail PDD limits.
These limits are not available from the ITU-T standards.

Page 18 of 19
5.5 MAFE (Maximum Average Frequency Error)

MAFE is a metric specified in ITU-T G.8260 that can be used to analyze the Network PDV further. In
particular, this is a metric used to evaluate Network PDV when PTP Slaves integrated into Nokia Systems
Networks’ FlexiBTS are used.

5.5.1 MAFE Calculation and Analysis

Before performing PDV capture, configure
the packet selection parameters and select
packet metrics related to masks.

5.5.2 Sample MAFE Test Results

Example
Results

Within MAFE limits MAFE close to limits MAFE outside limits

• Priority setting wrong • Priority setting wrong

Possible • Network congestion • Network congestion
n/a
Causes • Re-route event • Re-route event
• Network equipment failure • Network equipment failure

• Congestion causes • Congestion causes

depopulation of the floor delay depopulation of the floor
Possible • Re-routes move the floor, delay.
n/a
Impact reducing “headroom’ for the • Re-routes move the floor,
MAFE analysis. eliminating all packets within
the cluster range.

• Visual inspection for re-routes • Visual inspection for re-routes

and/or congestion. and/or congestion.
• If re-route event occurs, • If re-route event occurs,
segment the data into segment the data into
separate data sets. separate data sets.
• Apply MAFE analysis • Apply MAFE analysis
Next separately to each data set. separately to each data set.
n/a
Action • If congestion, check PTP • If congestion, check PTP
running at highest priority. running at highest priority.
Also check for over- Also check for over-
subscription of allocated data subscription of allocated data
rate. rate.
• Measure further back in the • Measure further back in the
network network

Page 19 of 20
6 Test Results Interpretation

6.1 With Slave Clock Output

Slave Clock Output (5.2)

Pass Fail
Network PDV (5.1)

Contact PTP Slave vendor *

Pass OK Please refer to the “next

action” in section 5.2

Network re-route or re-

engineer may be required.
Network PDV is high but PTP
Fail slave can work OK with it **
Please refer to the “next
action” in sections 5.1 and 5.2

* Network PDV has been deemed to meet FPP limits. However, Network PDV packet-to-packet
analysis as well as Packet Delay Distribution (5.3, 5.4, and 5.5) should also be analyzed and sent to
the PTP Slave vendor to allow troubleshooting.

** Although the PDV is OK for this PTP slave, any software update to the slave or using a different PTP
slave in the network, may cause a failure. It is advised that further testing is performed to validate the
slave’s performance.

6.2 Without Slave Clock Output

In case of no clock output from the slave, always check the measurement results from section 5.3, 5.4 and
5.5 for further actions.

Note: This test procedure focusses on frequency synchronization using PTP. Please refer to other test
documents from Calnex for frequency synchronization using NTP 5 and synchronization test for TDD-LTE. 6

If any files other than those required for the metric were loaded then they can be de-selected or closed
from the Select File page.

5 Calnex Document number CX5017

6 Calnex Document number CX5019

Page 20 of 21
7 Offline Analysis and Report Generation using CAT

7.1 Overview

The Calnex Analysis Tool (CAT) is standalone software for MTIE/TDEV, MAFE, FPP and PDD analysis.
The captured raw data from Sentinel 7 can be imported to CAT for comprehensive metric analysis,
including pass/fail masks. Reports are easily generated with a single click from CAT, presenting results to
your customers/colleagues in a professional manner.

7.2 Selecting ITU-T G.8261.1 Metrics in CAT

By default CAT will determine which metrics to display based on the type of measurement files that are
loaded. This can lead to clutter and may indicate a false failure on metrics and limits that are not specific
to ITU-T G.8261.1.

Copy the measurement files from Sentinel to the PC that CAT is running from. Either open all the .dset
files from CATs Select File tab or drag and drop all the .dset files onto the CAT window.

Sentinel generates the following .dset files:

• channelX.dset – Raw TIE data for a clock or reference channel

• channelX_ESMC_QUALITY.dset – SyncE SSM message transitions
• channelX_FWD_PDV.dset – Raw PDV calculated from PTP Sync messages
• channelX_REV_PDV.dset – Raw PDV calculated from PTP Delay Request / Delay Response messages
• channelX_PATH_DELAY.dset – calculated PTP path delay.

Where X is the associated measurement channel A to F.

NOTE: Only channelA.dset and channelC_FWD_PDV.dset need to be loaded to generate the ITU-T
G.8261.1 metrics for this test setup. If the SyncE recovered clock is to be verified then channelC.dset
should also be loaded.

7 Data can also be imported from Calnex Paragon-X and Calnex Paragon-t products

Page 21 of 22
 If any files other than those required for the metric were loaded then they can be de-selected or closed
from the Select File page

7.3 Selecting Metrics

Select required metrics for analysis from Application > Select Metrics after the measurement files
have been imported.

The clock measurements box should enable MTIE for the 10MHz recovered clock (A TIE) and SyncE
recovered clock (C – SyncE) if that is being tested.

Page 22 of 23
FPP should be enabled in the packet measurements box.

All other metrics should be cleared. Press the Calculate button to generate the metric data.

The ITU-T G.8261.1 recovered clock mask is set on the MTIE tab on the View Results page.

The FPP results can be viewed on the FPP tab. By default the parameters are set for the ITU-T
G.8261.1 limits but can be adjusted if necessary. A summary of the Pass / Fail status of each metric is
shown in the top right corner.

Page 23 of 24
 7.4 Generating a Report 8

To create a report, simply click on “Generate Report” from CAT GUI.

Front cover shows General and Test Configuration, with Pass/Fail clearly indicated.

8 See Appendix D for an example report

Page 24 of 25
Appendix A: PTP (1588) Synchronization Technology

PTP (Precision Time Protocol) is an industry-standard protocol that enables the precise transfer of frequency and
time to synchronize clocks over packet-based Ethernet networks. It synchronizes 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 synchronization 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 PTP is based on the precision of the timestamp. The timestamps of
incoming and outgoing packets clearly need to be recorded and assessed to ensure synchronization 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.
Here, we examine the precision of timestamp synchronization, as well as the accuracy of clocks under various
network scenarios, before deploying equipment in an operational network.

There are two types of message in the PTP protocol: Event Messages and General Messages. Event messages
are timed messages whereby an accurate timestamp is generated both at transmission and receipt of the
message. General messages do not require timestamps but may contain timestamps for their associated event
message.

Events messages include Sync, Follow-up, Delay-Request and Delay-Response. The PTP workflow is shown
below.

Once the Slave knows the timing of t1, t2, t3, and t4, it can calculate the mean propagation delay (Tmpd) of the
messages path and slave clock offset. This can be calculated by:

• Tmpd = ((t2-t1) + (t4-t3)) / 2

• Offset = t2-t1-Tmpd

Page 25 of 26
Appendix B: ITU-T Recommended Network Limits for Packet Networks

Maximum average time interval error (MATIE) and Maximum average frequency error (MAFE)

MATIE and MAFE describes maximum phase or frequency deviations. MATIE/MAFE include a noise averaging
function similar to TDEV.

MATIE can be estimated by the following formula:

where xi is the packet time error sequence (and is a random sequence), nτ0 is the observation window length, n
is the number of samples in the window, τ0 is the sample interval, N is the number of samples in the data set,
and k is incremented for sliding the window. MATIE describes the maximum of average time changes between
adjacent windows of length nτ0.

There is a simple relationship between MATIE and MAFE:

MAFE may be estimated as:

which is the average of MATIE over the observation window length.

Floor Packet Percent (FPP) by definition is the percentage of packets that fall into the given fixed cluster range
starting at the observed floor delay.

MATIE, MAFE and FPP are applicable to defining the network limits.

Page 26 of 27
Network Limits

ITU-T G.8261.1 defines different level of reference points and their network limits in packet networks for
frequency synchronization as follows.

Network limits are specified at different level of reference points. At reference point C, the packet network limits
are expressed in terms of the relevant PDV based metric as follows:

With window interval W = 200s and fixed cluster range δ = 150μs starting at the floor delay, the network transfer
characteristic quantifying the proportion of delivered packets that meet the delay criterion should satisfy

FPP (n, W, δ) ≥ 1%

That is the floor packet percentage must exceed 1%.

MAFE and FPP are packet based network limits at reference point C which are mentioned in this document as
test procedure 5.1 and 5.5.

Page 27 of 28
Appendix C: ITU-T Recommended Slave Clock Network Limits

Per the above network reference model, ITU-T also defines the network limit in terms of frequency wander at
reference point D. This is to measure the accuracy or wander of the recovered Slave clock normally done at the
frequency output interface on Slave (NodeB), such as 2MHz, 2Mbits or 10MHz.

The output wander network limit applicable at reference point D is provided by the graph below. It is in terms of
MTIE. This is discussed in section 5.2 in this document.

Page 28 of 29
Appendix D: Example Generated Report
Calnex Solutions Ltd
Oracle Campus
Linlithgow
West Lothian EH49 7LR
United Kingdom

t: +44 (0) 1506 671 416

e: [email protected]

calnexsol.com

© Calnex Solutions Ltd, 2019

This document is subject to change without notice.

CX5018 v1.1, January 2019