5 Packet Synchronization of NGN Networks

Packet based synchronisation
of Next Generation Networks
Viktor Szigeti
PolyNet Ltd.
Definitions of network synchronization
 A set of techniques to enable the frequency and
phase and time of the equipment clocks in a network
to constrain within specified limits.
 The specified limits are the limit curves in ITU, ETSI,
EN, ANSI standards of synchronization.
 The set of techniques:
 The use of network timing sources - use of master clocks,

 The best quality distribution of bit timing in a network,
 Timing backups for automatic network failure repair,
 Timing signal regeneration in stand alone synchronization
equipment (SSU, Edge Master, APTS, etc.).
PolyNet Ltd. 2016 Safaricom Sync Training

Viktor Szigeti
Definitions of network synchronization

Viktor Szigeti
Time and Frequency
• Aligning two time clocks (synchronization) implies:
• Make frequency B = frequency A (syntonization)
• Make phase B = phase A (e.g. roll-over instant of 10 7 counter)
• Make seconds B = seconds A (elapsed time equal; same time origin)
• Choose same formatting convention (and time-zone, etc.)
Clock A Clock B
“Time” Time alignment (“local time”) “Time”
Time alignment (UTC)
Seconds Seconds
Counter Time alignment (equal # of seconds) Counter
1Hz 1Hz
10,000,000 Phase alignment (roll-over coincident) 10,000,000
Counter (equality to within 1 clock cycle of 10-100ns may suffice) Counter
10MHz Frequency alignment (syntonization) 10MHz

Viktor Szigeti
What is Time?
 Time is a fundamental physical dimension
 Allows ordering and scheduling of events
 Enables sharing of resources (e.g. time division muxing)
 Passage of time measured by counting a
regularly repeating event
 Astronomical events, e.g. day/night, year
 Physical events, e.g. pendulum swing,

quartz resonance or atomic transitions
Viktor Szigeti
Common Time
 Common time requires a reference point
 Time at an instant has no meaning without a reference
 Need to start counting from a common point, or epoch
 Example: the Gregorian calendar counts years from the
birth of Christ
 A time reference clock counts at a constant frequency

from a known epoch
 Sending time in a message...

 Need to know how long the message takes
 A letter – might be usable for setting the date
 A phone call – could use to set hour/minute/seconds
 A packet – millisecond level accuracy

Viktor Szigeti
TAI and UTC

Viktor Szigeti
The evolution of Time and Frequency standards

Viktor Szigeti
Timing Alignment in Wireless
f = frequency offset between BSs

T = time offset between BSs
BS - A BS - B
Mobile in motion; speed = X m/s

 When hand-over occurs, the mobile must reacquire carrier frequency
 Mobile in motion (X m/s) introduces a Doppler shift (X/c)
 Loop bandwidth wide enough to handle (f + X/c +LO) (LO = local
oscillator offset)
 Loop bandwidth should be small from a noise rejection viewpoint
 Large f compromises the reliability of hand-over; 50 ppb typical
requirement
 TDD networks require time/phase alignment between A & B
 To control interference between uplink and downlink
 Requirement in the microsecond range
 LTE-Advanced require T to be small (microsec) for providing the
more bandwidth intensive features
PolyNet Ltd.
2016 Safaricom Sync Training
Viktor Szigeti
Current Timing Issues
 Networks are being migrated to packet switching as

opposed to circuit-switched (i.e. based on TDM)
 Significant impact of variable delay (packet delay variation)
 Timing requirements remain
 Going “IP” does not mean that real-time services or mobile
networks no longer need synchronization!
 Transition Phase:
 Hybrid Networks (IP/TDM islands)
 Circuit Emulation
 Timing over Packet Networks (packet-based methods)
 PTP, NTP, adaptive clock recovery
 Monitoring and Testing
 Metrics for packet-based timing methods (quantifying PDV)
PolyNet Ltd.
2016 Safaricom Sync Training
Viktor Szigeti
Architecture comparison 2G, 3G, LTE

Viktor Szigeti
Requirements for sync

Viktor Szigeti

Viktor Szigeti

Viktor Szigeti
Time Error Function
Time error varies with time and can be expressed as a function*:
If clocks are locked in phase, frequency offset and drift are eliminated, and time error reduces to two
Time error
components:
Constant time error or offset
Frequency
Dynamic time error or random variations
offset Random variations
Frequency(dynamic time error)
Constant time error drift
* Equation defined in ITU-T Recommendation G.810

Viktor Szigeti
Measuring Time Error
Time Error
Max|TE|
dTE
cTE
0
Time
 Need an accurate time reference – time error has no meaning without

a reference
 Maximum Absolute Time Error (Max|TE|) is the maximum distance
from zero of the time error function
 Sign doesn’t matter: excursions may be positive or negative
 Constant Time Error (cTE) is the mean of the time error fn.
 Period over it is measured is not specified; depends on signal
 Dynamic Time Error (dTE) is the change of the time error fn.
 Phase or time wander, analyzed using MTIE and TDEV

Viktor Szigeti
Synchronization trough packet networks
CEoP Sync Ethernet NTP PTP
( Pseudo Wire, ( Network Time ( Precision Time
TDMoE ) protocol ) Protocol,
IEEE1588V2 )
Basic service Bit timing Bit timing TOD TOD, Bit timing
Source accuracy 10-50 ns 10-50 ns 1-2 µs 10-50 ns

range
Must be hardware no yes no Theoreticaly no*
supported
User accuracy 5-15 µs 10-500 ns 1000-5000 µs 10-500 ns
range
Delay variation N/A Protocol Protocol Protocol

compensation
Prevalence General New General New
NTP: Network Time Protocol (V4 RFC 5905)

PTP: Precision Time Protocol IEEE 1588V2
IEEE 1588 – 2008, ToP ( Timing over Packet )
Sync Ethernet: ITU-T 8261, ITU-T 8262, ITU-T 8264
Viktor Szigeti
Pseudowire

Viktor Szigeti
Synchronization in packet transport environment 1
Network synchronous operation
CE IWF IWF CE
Packet
TDM TDM
network
RNC MGW MGW NodeB
Sync Sync
network network
PRC PRC
PRC: it may indicate the same or independent PRC quality sources
IWF: Interwork Function G.8261 CE: Customer Equipment

Viktor Szigeti
Differential methods
Differential timing messages
CE IWF IWF CE
Packet
TDM TDM
network
RNC MGW MGW NodeB

CLK
Sync Sync
network network
TDM Service Clock
PRC PRC

Viktor Szigeti
Adaptive methods
Recovered TDM
timing based on the
adaptive clock
CE IWF IWF recovery CE

Packet
TDM TDM
network
RNC MGW MGW Node B

CLK
TDM Service Clock

Viktor Szigeti
Reference clock available at the TDM end systems
CE IWF IWF CE
Packet
TDM TDM
network
RNC MGW MGW NodeB
Sync Sync
network network
PRC PRC

Viktor Szigeti
Autonomous operation
CE IWF IWF CE
Packet
TDM network
TDM
RNC NodeB
TOD Sync MGW MGW Sync TOD
GPS GPS

Viktor Szigeti
IEEE
1588
master
CE IWF IWF CE
TDM Packet TDM
network
RNC Node B
TOD MGW MGW Sync TOD
Sync
IEEE IEEE
1588 1588
slave slave
Realization of G.8261 by IEEE 1588 timing network

IWF: Interwork Function CE: Customer Equipment
Viktor Szigeti
Packet transfer delay and delay variation
• Random delay variation (e.g., queuing delays)
• Low frequency delay variation (e.g., day/night patterns)
• Systematic delay variation (e.g., store-and-forward
mechanisms in the underlying transport layer)
• Routing changes
• Congestion effects
• Link asymmetry

Viktor Szigeti
PDV caused by queuing
High priority
queue
Egress link G
Mbit/s
Output
Module
Low priority
queue MTU size = M

Viktor Szigeti
Systematic delay variation
Systematic delay variation caused by network with timeslots

Viktor Szigeti
Systematic delay variation
Systematic delay variation caused by beating packet streams

Viktor Szigeti
Synchronous Ethernet ( SyncE)
Synchronous Ethernet according to ITU-T G.8261, G.8262, G.8264
recommendation
Synchronous Ethernet is the ability to provide PHY-level frequency

distribution through an Ethernet port
Main target is the transport of synchronization information over packet

networks.
The packet networks that are in the scope of this recommendation are
currently limited to the following scenarios:
Ethernet [IEEE 802.3], [IEEE 802.1D], [IEEE 802.1ad], [IEEE 802.1Q] and
[b-IEEE P802.1Qay]
• MPLS [IETF RFC 3031] and [ITU-T G.8110]
• T-MPLS [ITU-T G.8110.1]
• IP [IETF RFC 791] and [IETF RFC 2460]

Viktor Szigeti
SyncE Overview
 How is SyncE different from normal Ethernet? TX TX
 Existing Ethernet PHY (Physical Layer) RX RX
 IEEE 802.3 defines Ethernet PHY 100 ppm
 Rx uses incoming line timing. Tx uses free-running 100ppm

oscillator.
 No relationship between the Rx & Tx.
TX TX
 SyncE PHY (Physical Layer) RX RX
 Rx disciplines the internal oscillator 4.6 ppm
 Tx uses the traceable clock reference, creating end-to-end

scheme.
 PRC can provide the reference. SSUs filter jitter/wander.
 SyncE and asynchronous switches cannot be mixed.
TX Traceabl TX TX Inaccurat TX
e e
RX RX RX RX
100 ppm
Ext.Sync 4.6 ppm
SyncE Element Asynchronous

Element

Viktor Szigeti
Synchronization sub-system selection
mechanism

Viktor Szigeti
Synchronized Ethernet Network
PRC fed SyncE example network

Viktor Szigeti
SSM and ESMC
 Synchronization Status Message:
 Network elements use Synchronization Status Messages (SSM) to inform the
neighboring elements
 about the Quality Level (QL) of the clock. The key benefits of the SSM
functionality:
 • Prevents timing loops.
 • Provides fast recovery when a part of the network fails.
 • Ensures that a node derives timing from the most reliable clock source.
 Ethernet Synchronization Messaging Channel

 • Ethernet Synchronization Messaging Channel (ESMC) based on IEEE 802.3
 Organization Specific Slow Protocol standards. ESMC relays the SSM code
that represents the quality level of the Ethernet Equipment Clock (EEC) in a
physical layer.
 The ESMC packets are received only for those ports configured as clock
sources and transmitted on all the SyncE interfaces in the system.
Viktor Szigeti
SSM and ESMC

Viktor Szigeti
SSM and ESMC

Viktor Szigeti
Avoiding timing loops in SyncE

Viktor Szigeti
Hybrid equipment selection function

Viktor Szigeti
Precision Time Protocol
IEEE1588V1 and V2
Topics
 Status
 PTPv1 overview
 PTPv2 major additions
 Transparent clocks
 PTP 1588v2

Viktor
The Precision Time Protocol (PTP)
 PTPv1 published in 2002
 Industries involved:
 v1: Industrial Automation, T&M, Military, Power Generation and
Distribution
 v2 : Audio-Visio Bridges (802.1AS), Telecom and Mobile
 Symposia in 2003, 2004, 2005, and 2006. 2007 in Vienna
 Products: Microprocessors, GPS Linked Clocks, Boundary Clocks,
NIC Cards, Protocol Stacks, RF Instrumentation, Aircraft Flight
Monitoring Instruments, etc.
 Information: http://ieee1588.nist.gov
 Version 2 PAR approved March 2005. Technical work
completed. Standard in 2008

Viktor
PTPv1 objectives
 Sub-microsecond synchronization
 Intended for relatively localized systems
 Applicable to networks supporting multicast
 Simple, administration free installation
 Support heterogeneous systems of clocks with varying
precision, resolution and stability
 Minimal resource requirements on networks and host
components

Viktor
IEEE 1588-2008 PTPv2 Overview
 The Grandmaster “reference clock” sends a series of time-stamped
messages to slaves.
 Slaves eliminate the round-trip delay & synchronize to the
Grandmaster.
 Frequency is recovered from an accurate time of day reference.
 Accuracy is enhanced by:
 Frequent packet send rate (up to 128 per second)
 Hardware time-stamping (eliminate software processing delays)
 Best Master Clock Algorithm (optional, “best” master voted by nodes)
Embedded
Slave
1588
Grandmaster 1588 Packets External

(Server) Slave

Viktor Szigeti
Protocol overview
 Timing Protocol
 Align slaves to master time
 Measure delay between master and slave
 Measure per-link delay (v2)
 Synchronization Hierarchy ‘routing’ Protocol
 Automatic Best Master Clock Algorithm
 Determines the master-slave synchronization clock
tree hierarchy
 Management Protocol
 Configuration and performance monitoring
Viktor
ITU-T Standards overview

Viktor
PTP Master-Slave Hierarchy
*Clock symbols taken from ITU-T
SG15 ‘synchronization modeling
components – time’ contribution
#249 Geneva-2007 by Mike
Gilson of BT

Viktor
How precision is possible?
 Message Exchange Technique
 Frequent “Sync” messages broadcast between PTP Entity
master & slaves, and…
 Delay measurement between slaves and master. Transport
Network
 Hardware-Assisted Time Stamping
 Time stamp leading edge of IEEE 1588 message Data
Precision
as it passes between the PHY and the MAC. TimeStamp
 Removes O/S and stack processing delays. Generator
 Master & Slave use hardware Physical
assisted time stamping.

Viktor Szigeti
PTP IEEE 1588V2 principle
Syntonization
Viktor Szigeti
PTP IEEE 1588V2 principle
Offset and Delay measurment

Viktor Szigeti
Precision using HW time-stamping
Doesn’t conform to OSI model

Viktor
1-step and 2-step clocks
 1-step clock updates accurate timestamp
(t1) in Sync message
 2-step clock sends accurate timestamp (t1)
in a Follow_Up message
 Simplify design while avoiding queuing noise
 Ease integration of security extensions

Viktor
PTPv2 major additions
 Synchronization accuracies better than 1
nanosecond
 Higher sampling/message rates
 Unicast communication
 Correction for asymmetry
 Transparent clocks
 Redundancy
 Configurable synchronization hierarchy
 Decouple sync messaging from hierarchy signaling
 Formal mechanisms for message extensions
 Mappings to UDP/IPv4&6, Ethernet w/o VLAN,
(also DeviceNet™, PROFINET, ControlNet™)
Viktor
PTP IEEE 1588V2
IEEE 1588-2008 introduces the concept of profiles to specify
particular combinations of options and attribute values to
support a given application.
The “Telecom Profile for frequency synchronization”,
G.8265.1. This profile addresses the application of the PTP to
the frequency synchronization of GSM, UMTS and LTE-FDD
base stations.
The “Telecom Profile for time synchronization”, released by

the ITU-T as recommendation G.8275.1. This profile
addresses the application of the PTP for time
synchronization of GSM, UMTS and LTE-FDD base stations.

Viktor Szigeti
NTP message format

Viktor
Sync and Delay-Req formats

Viktor
End-to-End Transparent Clocks
E2E TCs cancel queuing and processing delays

Viktor

Viktor

Viktor
Peer-to-Peer Transparent Clocks
P2P TCs cancel queuing, processing and propagation delays

Viktor

Viktor

Viktor
Peer Delay Measurement (Optional)

Viktor
E2E TC Enabled PSN
Packet queuing and processing time error is removed

Viktor
P2P TC Enabled PSN
Topology change does not effect slave performance

Viktor
Comparison between switches
Boundary Clock E2E TC P2P TC
Clock Synchronized Syntonized Syntonized
State • Per port state • Temporal message • Per link state

maintained • Per unicast state for 2-step TCs • Temporal
contract state message state for
2-step TCs
Slave √ Hierarchical Master sees all √ Hierarchical
scalability slaves (multicast Sync)
Linear Wander accumulation √ √
scalability Problem
Topology Measure new delay Measure new delay √ Pre-compute link
change delays
*restriction can be relieved using P-delay over MPLS

Viktor
PTP 1588V2
Requirements Description
Services Frequency, Phase, Time and meta-Time services
Precision Nano-seconds accuracy demonstrated
Sub nano-seconds granularity
Incremental Add Transparent clocks or Boundary clocks to improve
performance if required in critical junctions
Performance Telecom grade performance has been demonstrated over
non-PTP-aware networks
Scalable Use of boundary clocks and/or transparent clocks to scale
and maintain performance limits
Robust to master Smart slaves synchronizing to two domains or two masters
failures in a single domain.
Alternate master takes over when master fails
Robust to P2P mechanism allows to pre-compute link-delays to
topology changes minimize effect of topology change

Viktor
PTP 1588V2
Derived Description
Requirements
HW friendly Correction field is scaled nano-seconds. All computations by
transparent clocks are performed on correction field
Correction field is in a fixed position from beginning of PTP

header
Single Timestamp in fixed position immediately after PTP
header for master and slave HW setting
Heterogonous 2-step clocks simplify master designs
design options 1-step transparent clocks do not need to maintain per master-
slave message states
Slave friendly Timescale (Timestamps) is continuous. Timestamps do not
‘jump’ or ‘miss’ one second when leap event occurs
Time-stamps do not roll over

Viktor
PTP protocol extensions
 Define a profile that selects optional feature set,
default and range of values
 Define TLV extension to messages
 Define flag-fields to be carried in event messages
 Define alternate management scheme (SNMP)
 Define alternate synchronization hierarchy selection
(routing) algorithm
 Define additional transport mapping (PTP over
MPLS)
 Define alternate clock quality levels and attributes

Viktor
G.8265.1. Telecom profile
1. To permit operation over existing managed, wide-area,
packet-based telecoms networks.
2. To define message rates and parameter values consistent
with frequency distribution to the required performance for
telecom applications.
3. To allow interoperability with existing synchronization
networks (such as SyncE and SDH).
4. To allow the synchronization network to be designed and
configured in a fixed arrangement.
5. To enable protection schemes to be constructed in
accordance
with standard telecom network practices.
Viktor Szigeti
G.8265.1. Telecom profile for frequency
synchronization
It was decided not to use on-path support, such as boundary
clocks and transparent clocks, because this is not available in
existing networks.
• IPv4 was adopted as the network layer due to its ubiquity, rather
than operation directly over Ethernet or other lower-layer
protocols
• Unicast transmission was adopted over multicast, since it could
be guaranteed to work over wide-area telecoms networks.
• The default BMCA (Best Master Clock Algorithm) described in
IEEE 1588-2008 was replaced by static provisioning. This allows
the synchronization flow to be planned, rather than dynamically
adjusting itself.
• The clockClass indication was adapted to carry the Quality Level
(QL) indications defined in G.781 [3], for continuity with SDH and
SyncE synchronization status messaging.

Viktor Szigeti
G.8265.1. Telecom PTP domains
4 5 N
Each master is active and considered isolated

in a different PTP domain by the network

Viktor Szigeti
G.8265.1. Telecom slave model

Viktor Szigeti
SSM and PTP Interworking with existing SDH
synchronization systems

Viktor Szigeti
SSM and PTP clockClasses

Viktor Szigeti

Viktor Szigeti

Viktor Szigeti

Viktor Szigeti
SSM and PTP clockClass in Telecom profile G.8265.1

Viktor Szigeti
G.8265.1 Packet timing signal fail
– PTSF-lossSync: lack of reception of PTP timing messages

from a master
– PTSF-lossAnnounce: lack of reception of PTP Announce

messages from a master (loss of the channel carrying the
traceability information)
– PTSF-unusable: unusable PTP packet timing signal received

by the slave, exceeding the input tolerance of the slave (noisy
packet timing signal, violates the slave input tolerance because
of excessive PDV noise

Viktor Szigeti
G.8265.1 Packet timing signal fail - Additional protection
functions
- Temporary master exclusion: exclude temporarily a master from
the list of grandmasters
- Slave wait-to-restore time function
- Forced traceability of master function: force the SSM QL value

at the input of the grandmaster by configuration
( eg: 2MHz signal )
- Packet slave clock QL hold off function: where sufficient

holdover performance exists within the telecom slave, it must
be possible to delay the transition of the QL value
- Slave output squelch function: in failure conditions (e.g., the

QLs received are all going under a certain threshold, or PTSF
conditions are raised), the output timing signal could be cut off
Viktor Szigeti
G.8275.1 telecom profile for time synchronization.
“Precision time protocol telecom profile for

phase/time synchronization with full timing support
from the network”
-Every node in the network should support BC functionality
-Based on L2 multicast model
-Fixed message rates: 16 packet per second sync, del. requ,
del. resp
-Clock domains: 24-43
-Clock Classes: 6,7,135, 140, 150, 160, 165, 248, 255
-Other specialties

Viktor Szigeti
G.8275.1 telecom profile for time synchronization.

Viktor Szigeti
Time synchronization for LTE-A according
to ITU-T 8271.1
For TDD-LTE applications, the network limits applicable at reference

point C are expressed in terms of two quantities:

Viktor Szigeti
to ITU-T 8271.1

Viktor Szigeti
8271.1 Time measurement results on MPLS
network trough microwave connection
+/- 1100ns limit for LTE-A

Viktor Szigeti
to ITU-T 8271.1
Network limit for reference point C is specified in term og MTIE below

Viktor Szigeti
Network limits according to G.8261.1

Viktor Szigeti
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%.

Viktor Szigeti
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.

Viktor Szigeti
Synchronization Distribution Architecture
for LTE Networks
- Guidelines:
- 1. Use an independent source for sync

- – Upgrade already existing PRC’s
- – Efficient operation in a multi -vendor network
- 2. Protect your sync for service assurance

- – GPS, PTP & Stable frequency source
- – High performance holdover
- 3. Deploy PTP Grandmaster where the network needs it for

accuracy
- – Backhaul supports accuracy: allows deployment closer to the
core
- – Noisy, high PDV network: requires deployment “at or near the
edge”
Viktor Szigeti
LTE Network Scenarios
1. LTE frequency , managed Ethernet backhaul

– Consistent, known backhaul performance
2. LTE frequency , high PDV, noisy backhaul

– Diverse transport technologies, 3rd Parties, many hops
3. LTE phase, retrofitted or new Ethernet backhaul

– SyncE and Boundary Clocks in every network element
4. LTE phase, existing backhaul, possibly high PDV, noisy

– No BC, probably no SyncE, diverse transport, 3rd party

Viktor Szigeti
LTE Frequency: G.8265.1 Basic Architecture

Viktor Szigeti
LTE Frequency: G.8265.1 Overlay Architecture

Viktor Szigeti
LTE Phase: G.8275.1 Architecture

Viktor Szigeti
LTE Phase: G.8275.2 Hybrid GPS/PTP. Partially assisted
support. (pre -standard)

Viktor Szigeti
LTE Phase: G.8275.2 Hybrid GPS/PTP. Partially assisted
support (pre -standard)

Viktor Szigeti
Applicability of different timing solutions for
NodeB, eNodeB synchronization
 NTP 500-10000 µs Not
recommended

 Pseudo wire 1-15 µs Not recommended
 Physical synchronisation SEC quality,

 (0,1..1 µs) applicable
 Synchronous Ethernet
 G.8262 PRC/SSU quality
(0,01…0,1 µs applicable for
frequency sync
 IEEE 1588V2 Precision

 Time Protocol PRC/SSU quality
(0,01…0,1 µs applicable for
time and frequency sync

Viktor Szigeti
Physical synchronisation through PTN elements
Gbit ETH
SSU
Ext Synch
PTN main PTN slave
Gbit ETH T4
Wander
Analyzer

Viktor Szigeti
Synchronous Ethernet Multivendor Interwork
STM-1
Synch
RTN 910 8605 MSN
Gbit ETH T4
Wander
Analyzer

Viktor Szigeti
NodeB timing with local GPS clock
TIE, MTIE and TDEV result
on the E1 output of Node-B
when autonomous GPS
1,25µs
synchronization used 5xE-8
Synchronization quality
using integrated GPS
receiver in Node-B for autonomous
synchronization
Viktor Szigeti
High quality timing transfer through STM-n transport bit
timing and the timing regenerator feature of the Node-B
Sync ATM-STM-1
ATM switch ATM-E1 Node-B

Viktor Szigeti
Timing transfer through an additional route
TDM-E1
BTS ATM-34Mbit/s
Ext Synch
ATM switch ATM-E1 Node-B
Data
df/f 7.48E-11
Viktor Szigeti
Node-B timing through IP (low PDV)
Best 10 = 3
PM counter values: Best 1 = 2
Best 50 = 6 PDV: Packet Delay Variation

Viktor Szigeti
Node-B timing through IP (Medium PDV)

Viktor Szigeti
Node-B timing through IP (High PDV)

Viktor Szigeti
Node B timing through E1 over IP (pseudo wire)
TIE, MTIE and TDEV results
Measured on Node-B’s E1 input
The timing signal is recovered from
1,25µs
packet transported signal
5xE-8
Solution: Node-B synchronization

by a T4 output of station transport
element as it is available
+ timing control and backup to
reach 1,25µs limit
Viktor Szigeti
Internal clock measurement of switching from
SyncE to 1588V2 on eNodeB

Viktor Szigeti
1588V2 Time measurement results on MPLS
network (2 hop from the clock)

Viktor Szigeti
1588V2 Time measurement results on MPLS
network trough microwave connection
+/- 1100ns limit for LTE-A

Viktor Szigeti
Conclusions – what to do?
• If the BTS/NodeB equipped with integrated GPS clock use it
for timing
• If TDM network element available at a given station use its
external sync output for Node-B timing
• If non of the above available, implement standalone GPS
clock or IEEE 1588V2 slave clock for NodeB synchronization
• In case of sync Ethernet backhaul make sure that its quality
is in line with rec. ITU-T 8262
• Use IEEE 1588V2 precision time protocol if it is available and
accepted in the existing transport/access media
• For best result use SyncE and PTP together in hybrid mode
• Control the synchronization of the network, by NMS and
wander measurement

Viktor Szigeti
Recommendations for TDM hierarchies
 G.803 (03/2000), Architecture of transport networks based on the

 synchronous digital hierarchy (SDH)
 G.803Amd1(06/2005)
 G.810 (08/1996), Definitions and terminology for synchronization networks
 G.810 Corr1(10/2001)
 G.811 (09/1997), Timing requirements of primary reference clocks
 G.812 (06/2004), Timing requirements of slave clocks suitable for use as node clocks
in synchronization networks
 G.813 (03/2003), Timing requirements of SDH equipment slave clocks (SEC)
 G.813 Corr1(06/2005)
 G.822 (11/1988), Controlled slip rate objectives on an international digital Connection
 G.823 (03/2000), The control of jitter and wander within digital networks which are
based on the 2048 kbit/s hierarchy
based on the 1544 kbit/s hierarchy
based on the synchronous digital hierarchy (SDH )
 G.825 Amd1 (05/2008)
 G.781 (09/2008), Synchronization layer functions

Viktor Szigeti
Recommendations for timing over packet networks
 G.8260 rev(02/2012), Definitions and terminology for
synchronization in packet networks
 G.8260 Amd1 (8/2013), Amd2 (5/2014)
Recommendations for Synchronous Ethernet
 G.781 (09/2008), Synchronization layer functions

 G.8261 rev(08/2013), Timing and Synchronization aspects in Packet
Networks
 G.8262 (07/2010), Timing characteristics of synchronous Ethernet
Equipment slave clock
 G.8262 Amd1 (02/2012), Amd2 (10/2012)
 G.8263 (02/2012), Timing characteristics of packet-based equipment
clocks
 G.8263 Amd1 (08/2013), Amd2 (05/2014)
 G.8264 rev(05/2014), Distribution of timing information through
packet networks

Viktor Szigeti
Recommendations for the telecom profile for time and phase
G.8271 (02/2012), Time and phase synchronization aspects of packet networks

 G.8271 Amd1 (08/2013)
G.8271.1(08/2013), Network Limits for Time Synchronization in Packet
Networks
 G.8271.1 Amd1 (5/2014)
G.8272 (10/2012), Timing characteristics of primary reference time clocks

 G.8272 Amd1 (8/2013)
G.8273 (08/2013), Framework of phase and time clocks
 G.8273 Corr1 (5/2014)
G.8273.2 (05/2014) Timing characteristics of telecom boundary clocks and
telecom time slave clocks
G.8275 (11/2013), Architecture and requirements for packet-based time and
phase distribution
G.8275.1 (07/2014), Precision time protocol telecom profile for phase/time
synchronization with full timing support from the network

Viktor Szigeti
Recommendations for OTN
 G.8251 (09/2010), The control of jitter and wander within the optical transport
network (OTN)
 G.8251 Amd1 (04/2011),Amd2 (02/2012), Amd3 (10/2012)
 G.8251 Corr1 (02/2012)
Recommendations for the telecom profile for frequency only
 G.8261 rev(08/2013), Timing and Synchronization aspects in Packet Networks

 G.8261.1 (02/2012), Packet Delay Variation Network Limits applicable to Packet
Based Methods (Frequency Synchronization)
 G.8261.1 Amd1 (5/2014)
 G.8263 (02/2012), Timing characterisctics of packet based equipment clocks
 G.8263 Amd1 (8/2013), Amd2 (5/2014)
 G.8265 (10/2010), Architecture and requirements for packet based frequency
delivery
 G.8265.1 rev(07/2014), Precision time protocol telecom profile for frequency
synchronization

Viktor Szigeti
Future recommendations ( provisional titles)
G.8266 Timing characteristics of telecom grandmaster clocks

for frequency synchronization
G.8273.1 Timing characteristics of packet master clocks
G.8273.3 Timing characteristics of telecom transparent clocks
G.8273.4 Timing characteristics of assisted partial timing
support slave clocks
G.8275.2 Precision time Protocol Telecom Profile for time/phase
synchronization with partial timing support from the network

Viktor Szigeti
Recommendation on Jitter and wander tests equipments
 O.171 (04/1997), Timing jitter and wander measuring equipment for digital
systems which are based on the plesiochronous digital hierarchy (PDH)
 O.172 (04/2005) , Jitter and wander measuring equipment for digital systems
which are based on the synchronous digital hierarchy (SDH)
 O.173 (02/2012), Jitter measuring equipment for digital systems which are
based on the Optical Transport Network
 O.174 (11/2009), Jitter and wander measuring equipment for digital system
based on synchronous Ethernet network

Viktor Szigeti
Thank You!

Viktor Szigeti

5 Packet Synchronization of NGN Networks

Uploaded by

Copyright:

Available Formats

5 Packet Synchronization of NGN Networks

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5 Packet Synchronization of NGN Networks

Uploaded by

Copyright:

Available Formats

Packet based synchronisation

of Next Generation Networks

 The use of network timing sources - use of master clocks,

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

10MHz Frequency alignment (syntonization) 10MHz

PolyNet Ltd. 2016 Safaricom Sync Training

 Physical events, e.g. pendulum swing,

 A time reference clock counts at a constant frequency

 Sending time in a message...

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

f = frequency offset between BSs

Mobile in motion; speed = X m/s

 Networks are being migrated to packet switching as

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

* Equation defined in ITU-T Recommendation G.810

 Need an accurate time reference – time error has no meaning without

PolyNet Ltd. 2016 Safaricom Sync Training

Source accuracy 10-50 ns 10-50 ns 1-2 µs 10-50 ns

Delay variation N/A Protocol Protocol Protocol

Prevalence General New General New

NTP: Network Time Protocol (V4 RFC 5905)

PolyNet Ltd. 2016 Safaricom Sync Training

RNC MGW MGW NodeB

PRC: it may indicate the same or independent PRC quality sources

IWF: Interwork Function G.8261 CE: Customer Equipment

RNC MGW MGW NodeB

PRC: it may indicate the same or independent PRC quality sources

IWF: Interwork Function G.8261 CE: Customer Equipment

timing based on the

CE IWF IWF recovery CE

RNC MGW MGW Node B

TDM Service Clock

IWF: Interwork Function G.8261 CE: Customer Equipment

RNC MGW MGW NodeB

PRC: it may indicate the same or independent PRC quality sources

IWF: Interwork Function G.8261 CE: Customer Equipment

IWF: Interwork Function G.8261 CE: Customer Equipment

Realization of G.8261 by IEEE 1588 timing network

• Random delay variation (e.g., queuing delays)

• Low frequency delay variation (e.g., day/night patterns)

• Systematic delay variation (e.g., store-and-forward

mechanisms in the underlying transport layer)

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

PolyNet Ltd. 2016 Safaricom Sync Training

Systematic delay variation caused by beating packet streams

PolyNet Ltd. 2016 Safaricom Sync Training

Synchronous Ethernet is the ability to provide PHY-level frequency

Main target is the transport of synchronization information over packet

PolyNet Ltd. 2016 Safaricom Sync Training

 Existing Ethernet PHY (Physical Layer) RX RX

 IEEE 802.3 defines Ethernet PHY 100 ppm

 Rx uses incoming line timing. Tx uses free-running 100ppm

 Rx disciplines the internal oscillator 4.6 ppm