T Rec G.8261 201308 I!!pdf e

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n
ITU-T G.8261/Y.1361
TELECOMMUNICATION (08/2013)
STANDARDIZATION SECTOR
OF ITU
SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Packet over Transport aspects Quality and availability
targets
SERIES Y: GLOBAL INFORMATION
INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS
AND NEXT-GENERATION NETWORKS
Internet protocol aspects Transport
Timing and synchronization aspects in packet

networks
Recommendation ITU-T G.8261/Y.1361

ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS
INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER- G.200G.299
TRANSMISSION SYSTEMS
INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.300G.399
SYSTEMS ON METALLIC LINES
GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.400G.449
SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH
METALLIC LINES
COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450G.499
TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600G.699
DIGITAL TERMINAL EQUIPMENTS G.700G.799
DIGITAL NETWORKS G.800G.899
DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900G.999
MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE GENERIC AND USER- G.1000G.1999
RELATED ASPECTS
TRANSMISSION MEDIA CHARACTERISTICS G.6000G.6999
DATA OVER TRANSPORT GENERIC ASPECTS G.7000G.7999
PACKET OVER TRANSPORT ASPECTS G.8000G.8999
Ethernet over Transport aspects G.8000G.8099
MPLS over Transport aspects G.8100G.8199
Quality and availability targets G.8200G.8299
Service Management G.8600G.8699
ACCESS NETWORKS G.9000G.9999
For further details, please refer to the list of ITU-T Recommendations.

Timing and synchronization aspects in packet networks
Summary
Recommendation ITU-T G.8261/Y.1361 defines frequency synchronization aspects in packet
networks. It specifies the maximum network limits of jitter and wander that shall not be exceeded. It
specifies the minimum equipment tolerance to jitter and wander that shall be provided at the
boundary of these packet networks at TDM and synchronization interfaces. It also outlines the
minimum requirements for the synchronization function of network elements.
The requirements for the jitter and wander characteristics that are specified in this Recommendation
must be adhered to in order to ensure interoperability of equipment produced by different
manufacturers and a satisfactory network performance.
History
Edition Recommendation Approval Study Group
1.0 ITU-T G.8261/Y.1361 2006-05-22 15
1.1 ITU-T G.8261/Y.1361 (2006) Cor. 1 2006-12-14 15
2.0 ITU-T G.8261/Y.1361 2008-04-29 15
2.1 ITU-T G.8261/Y.1361 (2008) Amd. 1 2010-07-29 15
3.0 ITU-T G.8261/Y.1361 2013-08-29 15
Rec. ITU-T G.8261/Y.1361 (08/2013) i

FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementers
are cautioned that this may not represent the latest information and are therefore strongly urged to consult the
TSB patent database at http://www.itu.int/ITU-T/ipr/.
ITU 2014
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
ii Rec. ITU-T G.8261/Y.1361 (08/2013)

Table of Contents
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 3
3.1 Terms defined elsewhere ................................................................................ 3
3.2 Terms defined in this Recommendation ......................................................... 4
4 Abbreviations and acronyms ........................................................................................ 5
5 Conventions .................................................................................................................. 6
6 General.......................................................................................................................... 7
6.1 Packet network synchronization requirements ............................................... 7
6.2 TDM timing requirements .............................................................................. 8
6.3 Synchronization network engineering in packet networks ............................. 9
6.4 Timing requirements at edge versus timing requirements in core networks .. 9
6.5 PNT domain and CES domain ....................................................................... 9
7 Reference timing signal distribution over packet networks (PNT domain) ................. 9
7.1 Plesiochronous and network synchronous methods ....................................... 10
7.2 Packet-based methods .................................................................................... 11
8 Timing recovery for constant bit rate services transported over packet networks
(CES domain) ............................................................................................................... 12
8.1 Network synchronous operation ..................................................................... 13
8.2 Differential methods ....................................................................................... 13
8.3 Adaptive methods ........................................................................................... 14
8.4 Reference clock available at the TDM end systems ....................................... 14
9 Network limits .............................................................................................................. 15
9.1 CES network limits......................................................................................... 15
9.2 PNT network limits ........................................................................................ 19
10 Impact of impairments in the packet network on timing distribution and service
clock recovery............................................................................................................... 25
10.1 Packet transfer delay and delay variation ....................................................... 27
10.2 Impacts from packet impairments .................................................................. 31
11 Impact of the reference clock impairment on the service clock recovery .................... 32
11.1 Impairments for the network synchronous operation methods ...................... 32
11.2 Impairments for the differential method......................................................... 33
12 Results and consequences of the different synchronization methods over packet
network reference models ............................................................................................. 34
12.1 CES domain recommendations ...................................................................... 34
12.2 PNT domain recommendations ...................................................................... 36
Annex A Proposed network architecture for synchronous Ethernet ..................................... 38
Rec. ITU-T G.8261/Y.1361 (08/2013) iii

Page
A.1 PRC Location ................................................................................................. 38
A.2 Limiting jitter and wander of synchronous Ethernet ...................................... 38
A.3 Considerations on the design of synchronization network based on
synchronous Ethernet ..................................................................................... 39
A.4 Example of timing distribution via synchronous Ethernet ............................. 40
A.5 Interworking of Ethernet and synchronous Ethernet interfaces ..................... 40
Annex B IWF functional partitioning into CES and PNT IWF and network examples ....... 45
B.1 General ........................................................................................................... 45
B.2 IWF clocks...................................................................................................... 47
B.3 Network examples .......................................................................................... 49
Annex C CES IWF synchronization related requirements ................................................... 51
C.1 Traffic interfaces ............................................................................................ 51
C.2 Synchronization interfaces ............................................................................. 51
C.3 IWF synchronization function ........................................................................ 52
Annex D Network applications and requirements for clocks specified in ITU-T
G.8262/Y.1362 ............................................................................................................. 53
Appendix I Characteristics of Ethernet switches, Ethernet networks, routers and access
technologies .................................................................................................................. 54
I.1 Characteristics of Ethernet switches and networks ........................................ 54
I.2 Delay characteristics of routers ...................................................................... 58
I.3 Delay characteristics of access technologies (Microwave nodes, PON,
DSL) ............................................................................................................... 58
Appendix II Stabilization period ........................................................................................... 59
Appendix III Considerations on packet-based methods ....................................................... 60
Appendix IV Applications and use cases.............................................................................. 61
IV.1 Background.................................................................................................... 61
IV.2 Wireless .......................................................................................................... 61
IV.3 Infrastructure .................................................................................................. 63
IV.4 Media gateway................................................................................................ 63
Appendix V Packet networks reference models ................................................................... 64
V.1 Ethernet networks models .............................................................................. 64
V.2 Other network models .................................................................................... 66
Appendix VI Measurement guidelines for packet-based methods ....................................... 70
VI.1 Measurement reference points ........................................................................ 70
VI.2 Input traffic characteristics ............................................................................. 71
VI.3 Test topologies for adaptive methods ............................................................. 72
VI.4 Test Topologies for differential methods ....................................................... 79
VI.5 Test for two-way protocols ............................................................................. 80
Appendix VII Wander limits in Deployment Case 1 ............................................................ 88
iv Rec. ITU-T G.8261/Y.1361 (08/2013)

VII.1 Limits for the 2048 kbit/s interface ................................................................ 88
Page
VII.2 Limits for the 1544 kbit/s interface ................................................................ 89
Appendix VIII Synchronization status messaging in synchronous Ethernet PHY ............... 90
Appendix IX IWF examples ................................................................................................. 91
Appendix X Considerations on measurement of synchronous Ethernet according to
ITU-T methodologies in comparison with IEEE jitter measurements ......................... 94
Appendix XI Relationship between requirements contained in this Recommendation
and other key synchronization related Recommendations ........................................... 95
Appendix XII Basic principles of timing over packet networks ........................................... 98
XII.1 General ........................................................................................................... 98
XII.2 Packet delay variation mitigation by packet selection ................................... 101
XII.3 Comparison of packet-based and synchronous PHY methods ....................... 101
XII.4 Existing standards ........................................................................................... 102
Appendix XIII Evaluation of the packet delay variation generation in a network node ...... 103
XIII.1 Introduction .................................................................................................... 103
XIII.2 General considerations ................................................................................... 103
XIII.3 General configuration ..................................................................................... 103
Bibliography............................................................................................................................. 105
Rec. ITU-T G.8261/Y.1361 (08/2013) v

Timing and synchronization aspects in packet networks
1 Scope
This Recommendation defines frequency synchronization aspects in packet networks. It specifies
the maximum network limits of jitter and wander that shall not be exceeded. It specifies the
minimum equipment tolerance to jitter and wander that shall be provided at the boundary of these
packet networks at TDM and synchronization interfaces. It also outlines the minimum requirements
for the synchronization function of network elements.
In particular, two main issues are addressed in this Recommendation: the distribution of a
synchronization network clock signal over a packet network (PNT domain), and the distribution of
a service clock signal over a packet network (CES domain).
NOTE The application of the transport of SDH signals over packet networks is only partly covered and
some aspects are for further study.
The packet networks that are in the scope of this Recommendation are currently limited to the
following scenarios:
Ethernet ([IEEE 802.3], [IEEE 802.1DTM], [IEEE 802.1QTM] and [IEEE 802.1QayTM])
MPLS [IETF RFC 3031] and [ITU-T G.8110]
IP [IETF RFC 791] and [IETF RFC 2460]
The physical layer that is relevant to this Recommendation is the Ethernet media types as defined in
[IEEE 802.3]. Other physical layers can be relevant and may be addressed in a future version of this
Recommendation.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T G.691] Recommendation ITU-T G.691 (2006), Optical interfaces for single channel
STM-64 and other SDH systems with optical amplifiers.
[ITU-T G.702] Recommendation ITU-T G.702 (1988), Digital hierarchy bit rates.
[ITU-T G.703] Recommendation ITU-T G.703 (2001), Physical/electrical characteristics of
hierarchical digital interfaces.
[ITU-T G.705] Recommendation ITU-T G.705 (2000), Characteristics of plesiochronous
digital hierarchy (PDH) equipment functional blocks.
[ITU-T G.781] Recommendation ITU-T G.781 (2008), Synchronization layer functions.
[ITU-T G.803] Recommendation ITU-T G.803 (2000), Architecture of transport networks
based on the synchronous digital hierarchy (SDH).
[ITU-T G.811] Recommendation ITU-T G.811 (1997), Timing characteristics of primary
reference clocks.
Rec. ITU-T G.8261/Y.1361 (08/2013) 1

[ITU-T G.812] Recommendation ITU-T G.812 (2004), Timing requirements of slave clocks
suitable for use as node clocks in synchronization networks.
[ITU-T G.813] Recommendation ITU-T G.813 (2003), Timing characteristics of SDH
equipment slave clocks (SEC).
[ITU-T G.822] Recommendation ITU-T G.822 (1988), Controlled slip rate objectives on an
international digital connection.
[ITU-T G.823] Recommendation ITU-T G.823 (2000), The control of jitter and wander within
digital networks which are based on the 2048 kbit/s hierarchy.
digital networks which are based on the 1544 kbit/s hierarchy.
digital networks which are based on the synchronous digital hierarchy (SDH).
[ITU-T G.957] Recommendation ITU-T G.957 (2006), Optical interfaces for equipments and
systems relating to the synchronous digital hierarchy.
[ITU-T G.959.1] Recommendation ITU-T G.959.1 (2008), Optical transport network physical
layer interfaces.
[ITU-T G.8010] Recommendation ITU-T G.8010/Y.1306 (2004), Architecture of Ethernet layer
networks.
[ITU-T G.8110] Recommendation ITU-T G.8110/Y.1370 (2005), MPLS layer network
architecture.
[ITU-T G.8110.1] Recommendation ITU-T G.8110.1/Y.1370.1 (2006), Architecture of Transport
MPLS (T-MPLS) layer network.
[ITU-T G.8260] Recommendation ITU-T G.8260 (2010), Definitions and terminology for
synchronization in packet networks.
[ITU-T G.8261.1] Recommendation ITU-T G.8261.1/Y1361.1 (2012), Packet delay variation
network limits applicable to packet-based methods (Frequency
synchronization).
[ITU-T G.8262] Recommendation ITU-T G.8262/Y.1362 (2010), Timing characteristics of
synchronous Ethernet equipment slave clock.
[ITU-T G.8263] Recommendation ITU-T G.8263/Y.1363 (2012), Timing characteristics of
packet-based equipment clocks.
[ITU-T G.8264] Recommendation ITU-T G.8264/Y.1364 (2008), Timing distribution through
packet networks.
[ITU-T G.8265] Recommendation ITU-T G.8265/Y.1365 (2010), Architecture and
requirements for packet-based frequency delivery.
[ITU-T G.8265.1] Recommendation ITU-T G.8265.1/Y.1365.1 (2010), Precision time protocol
telecom profile for frequency synchronization.
[ITU-T G.8271] Recommendation ITU-T G.8271/Y1366 (2012), Time and phase
synchronization aspects of packet networks.
[ITU-T O.171] Recommendation ITU-T O.171 (1997), Timing jitter and wander measuring
equipment for digital systems which are based on the plesiochronous digital
hierarchy (PDH).
2 Rec. ITU-T G.8261/Y.1361 (08/2013)

[ITU-T O.172] Recommendation ITU-T O.172 (2005), Jitter and wander measuring
equipment for digital systems which are based on the synchronous digital
hierarchy (SDH).
[ITU-T Y.1411] Recommendation ITU-T Y.1411 (2003), ATM-MPLS network interworking
Cell mode user plane interworking.
[ITU-T Y.1540] Recommendation ITU-T Y.1540 (2002), Internet protocol data communication
service IP packet transfer and availability performance parameters.
[ITU-T Y.1561] Recommendation ITU-T Y.1561 (2004), Performance and availability
parameters for MPLS networks.
[ITU-T Y.1731] Recommendation ITU-T Y.1731 (2006), OAM functions and mechanisms for
Ethernet based networks.
[IEEE 802] IEEE 802-2001, IEEE standard for local and metropolitan area networks:
Overview and architecture.
<http://standards.ieee.org/getieee802/802.html>
[IEEE 802.1D] IEEE 802.1D-2004, IEEE Standard for local and metropolitan area networks:
Media Access Control (MAC) Bridges.
<http://standards.ieee.org/getieee802/download/802.1D-2004.pdf>
[IEEE 802.1Q] IEEE 802.1Q-2011, IEEE Standard for local and metropolitan area networks:
Virtual bridged local area networks.
<http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf>
[IEEE 802.3] IEEE 802.3-2008, Part 3: Carrier sense multiple access with collision
detection (CSMA/CD) access method and physical layer specifications.
<http://standards.ieee.org/getieee802/802.3.html>
[IETF RFC 791] IETF RFC 791 (1981), Internet Protocol (IP).
<http://www.ietf.org/rfc/rfc0791.txt?number=791>
[IETF RFC 2460] IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6) Specification.
[IETF RFC 3031] IETF RFC 3031 (2001), Multiprotocol Label Switching Architecture.
3 Definitions
3.1 Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:
3.1.1 adaptive clock recovery: See [ITU-T G.8260].
3.1.2 asynchronous interface: See [ITU-T G.823].
3.1.3 interworking function (IWF): See [ITU-T Y.1411]. More details and examples are shown
in Annex B and Appendix IX.
3.1.4 packet-based method: See [ITU-T G.8260].
3.1.5 packet-based method with timing support from the network: See [ITU-T G.8260].
3.1.6 packet-based method without timing support from the network: See [ITU-T G.8260].
3.1.7 packet network timing function (PNT-F): See [ITU-T G.8260].
3.1.8 synchronous interface: See [ITU-T G.823].
3.1.9 traffic interface: See [ITU-T G.823].
Rec. ITU-T G.8261/Y.1361 (08/2013) 3

3.2 Terms defined in this Recommendation
This Recommendation defines the following terms:
3.2.1 CES IWF: The circuit emulation services (CES) interworking function (IWF) is the set of
functions within the IWF that supports the service clock domain (see Figure B.3). This includes the
function to recover the service clock timing.
3.2.2 circuit emulation services (CES) island: Segment of a network, based on packet-switched
technologies, that emulates either the characteristics of a circuit-switched network or of a
PDH/SDH transport network, in order to carry CBR services (e.g., E1).
3.2.3 frequency source traceability: Frequency source traceability is a relationship where the
frequency of all clocks in a system is referenced back to a single physical clock. Under normal
operating conditions, all clocks will have the same average frequency in a source-traceable system.
Thus, the phase error or maximum time interval error (MTIE) between all clocks in such a system is
bounded.
NOTE A different case is when the clocks have frequency traceability towards accurate master clocks (not
necessarily the same pieces of equipment). This is connected to the concept of plesiochronous as defined in
[b-ITU-T G.810]. An example is when the clocks have the "PRC traceability" (i.e., traceability to
[ITU-T G.811] clocks) in a synchronization network based on the distributed PRC architecture.
3.2.4 network clock: The clock generating the network clock signal.
3.2.5 network clock domain: Set of functions dedicated to support the synchronization network
(network clock).
3.2.6 network clock signal: A reference timing signal that is used as a reference to allow
mapping and demapping of a service clock at ingress and egress points of the network respectively.
In some applications, the signal could be asynchronous and generated by free running clocks with
low requirements in terms of frequency accuracy (e.g., in the Ethernet network, the physical layer
can operate up to 100 ppm). In other applications, an accurate reference timing signal is needed. In
this case, the signal is typically traceable to a PRC under normal conditions, and the distribution of
this signal across the network is accomplished by a synchronization network.
NOTE For the purpose of this Recommendation, it is assumed that a properly high accurate signal is
always involved. Due to that, the network clock signal definition can be considered to coincide with the
definition of synchronization network clock signal, and the two terms are used interchangeably throughout
this Recommendation.
3.2.7 network-synchronous operation: Synchronization of the physical layer (usually by a
timing distribution of a timing signal traceable to a primary reference clock (PRC), see
[ITU-T G.811]).
3.2.8 service clock: The clock generating the service clock signal.
3.2.9 service clock domain: Set of functions dedicated to support the CES timing function
(service clock).
3.2.10 service clock signal: The timing information that is associated with a specific service
supported by a network. For instance, in case of E1 TDM service, the timing shall be 2048 kbit/s
50 ppm.
3.2.11 synchronization network clock: The equipment that provides the timing signal in the
synchronization network.
3.2.12 synchronization network clock signal: The reference timing signal distributed by the
synchronization network. This signal is traceable to an accurate master (e.g., PRC).
4 Rec. ITU-T G.8261/Y.1361 (08/2013)

3.2.13 time division multiplex (TDM): A term that conventionally refers to the isochronous
bitstreams used in telephony networks; in particular, those belonging to plesiochronous digital
hierarchy (PDH) as described in [ITU-T G.705]. The bit rates traditionally used in various regions
of the world are detailed in [ITU-T G.702]. Examples of the signals covered by the TDM definition
are those belonging to PDH and SDH hierarchies.
3.2.14 stabilization period: The period beginning at the point in time when a validated timing
source has been selected by the IWF and ending when the output timing characteristics are within
the output jitter and wander requirements.
3.2.15 wander budget (of a network island): Wander generated at the output of a network island
when an ideal reference timing signal is the input at the first network element of this network island.
4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
3GPP Third Generation Partnership Project
ATM Asynchronous Transfer Mode
BS Base Station
CBR Constant Bit Rate
CDMA Code Division Multiple Access
CE Customer Equipment
CES Circuit Emulation Service
DUT Device Under Test
EEC synchronous Ethernet Equipment Clock
ESMC Ethernet Synchronization Messaging Channel
FDD Frequency Division Duplex
FE Fast Ethernet
GE Gigabit Ethernet
GPS Global Positioning System
GSM Global System for Mobile communications
IP Internet Protocol
IP DSLAM IP Digital Subscriber Line Access Multiplexer
IWF Interworking Function
MAC Medium Access Control
M-CMTS Modular Cable Modem Termination System
MPEG Moving Picture Experts Group
MRTIE Maximum Relative Time Interval Error
MSAN MultiService Access Node
MTIE Maximum Time Interval Error
NTP Network Time Protocol
OLT Optical Line Termination
Rec. ITU-T G.8261/Y.1361 (08/2013) 5

OTN Optical Transport Network
PDH Plesiochronous Digital Hierarchy
PDV Packet Delay Variation
PEC Packet-based Equipment Clock
PHY PHYsical (layer)
PNT Packet Network Timing
PNT-F PNT-Function
PRC Primary Reference Clock
PSC-A Packet-based Service Clock-Adaptive
PSC-D Packet-based Service Clock-Differential
PSTN Public Switched Telephone Network
PTP Precision Time Protocol
QL Quality Level
SASE Stand Alone Synchronization Equipment
SDH Synchronous Digital Hierarchy
SEC SDH Equipment Clock
SLA Service Level Agreement
SNTP Simple Network Time Protocol
SRTS Synchronous Residual Time Stamp
SSM Synchronization Status Message
SSU Synchronization Supply Unit
STM Synchronous Transfer Mode
TCP Transmission Control Protocol
TDD Time Division Duplex
TDEV Time DEViation
TDM Time Division Multiplex
TDM PW TDM PseudoWire
ToD Time of Day
UI Unit Interval
UTC Coordinated Universal Time
WCDMA Wideband Code Division Multiple Access
5 Conventions
The terms "packets" and "frames" are used interchangeably throughout this Recommendation.
Within this Recommendation, the term "Ethernet" refers to an interface as defined in [IEEE 802.3]
and that does not comply with the additional timing requirements of synchronous Ethernet as
specified in this Recommendation, in [ITU-T G.8262] and in [ITU-T G.8264].
6 Rec. ITU-T G.8261/Y.1361 (08/2013)

6 General
Packet switching was originally introduced to handle asynchronous data.
However, for new applications, such as the transport of time division multiplex (TDM) service and
the distribution of synchronization over packet networks, the strict synchronization requirements of
those applications must be considered.
The ongoing evolution in telecommunications increases the likelihood of hybrid packet/circuit
environments for voice and voiceband data services. These environments combine packet
technologies (e.g., asynchronous transfer mode (ATM), IP, Ethernet) with traditional TDM systems.
Under these conditions, it is critical to ensure that an acceptable level of quality is maintained
(e.g., limited slip rate).
Synchronization in TDM networks is well understood and implemented. Typically, a TDM circuit
service provider will maintain a timing distribution network, providing synchronization traceable to
a primary reference clock (i.e., clock compliance with [ITU-T G.811]).
The timing and synchronization aspects addressed in this Recommendation are initially concerned
with networks with physical layer based on Ethernet media types as defined in [IEEE 802.3]
(see Scope, clause 1).
The functional architecture for Ethernet networks is defined in [ITU-T G.8010].
In the context of this Recommendation, the highest layers (e.g., layer 7 in the Open Systems
Interconnection (OSI) model) refer to applications transported over the packet networks. Real-time
applications have relatively tight timing requirements concerning delay and delay variation. Some
applications might resolve their timing issues within higher layers (e.g., MPEG-2); other
applications rely on the timing support provided by one or more of the lower layers (e.g., physical
layer).
This Recommendation aims at describing different methods to obtain the synchronization-related
requirements. Both circuit emulation services (CES) and packet network timing (PNT) domains are
considered, and different requirements are described.
Additionally, the requirements for interfaces and equipments that are part of the Ethernet and
synchronous Ethernet network are described. It also recommends when to apply different types of
synchronization methods.
Some considerations on applicable synchronization requirements in a packet-based network are
summarized in the following clauses.
This Recommendation primarily deals with CES in public network environments. In some private
network applications involving circuit emulation, it may be sufficient to distribute a non-primary
reference clock (PRC) quality level common clock towards CES interworking function (IWF)
nodes. However, the use of synchronization timing below PRC quality level could result in
interworking difficulties between different network domains, such as interconnection involving
multiple public networks providers.
The use of a non-PRC quality level common clock is for further study.
6.1 Packet network synchronization requirements

The nodes involved in packet oriented transmission technology (e.g., ATM network nodes) do not
require any synchronization for the implementation of the packet switching function. In fact, at any
entrance point of a packet switch, an individual device shall provide packet timing adaptation (for
instance, cell timing adaptation in case of ATM switch) of the incoming signal to the internal
timing. For instance, in the case of ATM networks, the principle to cater for frequency differences
is to use idle cell stuffing. Therefore, transmission links, in principle, need not be synchronized with
each other.
Rec. ITU-T G.8261/Y.1361 (08/2013) 7

However, as the packet network evolves to integrate TDM-based applications, i.e., when
transporting a constant bit rate (CBR) stream over a packet network and when interworking with
public switched telephone network (PSTN) networks, the packet network shall provide correct
timing at the traffic interfaces.
This means that the requirements on synchronization functions in packet networks, especially on the
boundary of the packet networks, are dependent on the services carried over the network. For TDM
based services, the IWF may require network-synchronous operation in order to provide acceptable
performance.
6.2 TDM timing requirements

The transport of TDM signals through packet networks requires that the signals at the output of the
packet network comply with TDM timing requirements. This is crucial to enable interworking with
TDM equipment.
These requirements are independent of the type of information (voice or data) transported by the
TDM signal.
The adaptation of TDM signals into the packet network is called circuit emulation services (CESs).
The timing requirements that are applicable are: jitter and wander limits at traffic and/or
synchronization interfaces, long-term frequency accuracy (which can influence the slip
performance), and total delay (which is critical for real-time services, for instance voice service).
6.2.1 PDH timing requirements
The plesiochronous digital hierarchy (PDH) timing requirements for traffic interfaces are mainly
related to jitter, wander and slip performance.
At the input of the network element at the boundary of a packet network, jitter and wander tolerance
requirements apply. At the output of the network element at the egress of the packet network, jitter
and wander generation requirements apply.
These values are specified in [ITU-T G.823] for a network based on 2048 kbit/s hierarchy and
[ITU-T G.824] for a network based on 1544 kbit/s hierarchy.
In addition, [ITU-T G.822] specifies the applicable slip rate objectives. This is the case when the
clock of the equipment that generates the TDM signal and the clock used in the equipment
recovering the TDM signal from the packets are different and the slip buffer is needed in the
application.
6.2.2 Synchronization interfaces requirements
In the case where the PDH signals are defined as synchronization interfaces, the synchronization
requirements are more stringent than those for the 2048 kbit/s and 1544 kbit/s traffic interfaces. The
synchronization interface requirements for PDH interfaces are also defined in [ITU-T G.823] and
[ITU-T G.824].
6.2.3 SDH timing requirements
Any synchronous transfer mode (STM)-N signal must be compliant with [ITU-T G.825]. The
relevant requirements refer to the jitter and wander tolerance applicable at the input of the network
element at the boundary of a packet network that receives the STM-N data, and jitter and wander
generation applicable at the output of the network element generating STM-N traffic at the other
end of the packet network.
In the case of STM-N signals, there are no distinctions between traffic and synchronization
interfaces as all STM-N signals are defined as synchronization interfaces.
8 Rec. ITU-T G.8261/Y.1361 (08/2013)

6.3 Synchronization network engineering in packet networks
The driving force for much of this work is to provide for the synchronization needs of the
application or, in general, the need of certain technologies (such as base stations in global system
for mobile communications (GSM) and wideband code division multiple access (WCDMA)
networks). In order to achieve such a goal, operators have to distribute a reference timing signal of
suitable quality to the network elements processing the application.
One approach is to follow a distributed PRC strategy (e.g., by means of global positioning system
(GPS) technologies). An alternative approach is based on a master-slave strategy. The engineering
rules for designing the synchronization network in these cases are well understood and documented
(e.g., see [ITU-T G.803]) when the underlying transport of the packets (e.g., Ethernet frames) runs
over the existing synchronous technologies (PDH or synchronous digital hierarchy (SDH)
networks). On the other hand, when the underlying transport is based on non-synchronous
technologies (i.e., Ethernet) alternative approaches shall be considered. This is further analysed in
clause 7.
6.4 Timing requirements at edge versus timing requirements in core networks

Different performances can be requested in case the packet network is part of an access network or
is the underlying layer of the core network.
The distribution of a synchronization reference over a portion of a core network may be requested
to comply with strict jitter and wander requirements (i.e., [ITU-T G.823], [ITU-T G.824] for
synchronization interfaces and [ITU-T G.825]).
On the other hand, in an access network, requirements may be relaxed to allow a distribution of a
timing reference signal with performance sufficient (e.g., lower than PRC quality level) to support
the timing requirements of the end node (for instance, a base station, or an ITU-T V.90 modem).
More information is provided in Appendix IV.
6.5 PNT domain and CES domain

This Recommendation addresses two main different issues:
1) how to carry a synchronization network clock signal over a packet network:
this issue is related to the PNT domain, and refers to the network clock (see
definitions).
guidance regarding this issue is provided in clause 7.
2) how to carry a service clock signal:
this issue is related to the CES domain, and refers to the service clock (see definitions).
guidance regarding this issue is provided in clause 8.
Additional information regarding PNT and CES domains is provided in Annex B.
7 Reference timing signal distribution over packet networks (PNT domain)

In order to fulfil the applicable synchronization requirements, it should be possible to distribute a
reference timing signal with proper phase stability and frequency accuracy characteristics.
Two main classes of methods are identified in this Recommendation:
1) plesiochronous and network synchronous methods (i.e., reference timing signal distributed
over the synchronous physical layer).
2) packet-based methods.
Rec. ITU-T G.8261/Y.1361 (08/2013) 9

7.1 Plesiochronous and network synchronous methods
The first class of methods refers to the PRC distributed method (for instance, based on GPS), or the
master-slave method using a synchronous physical layer (e.g., STM-N), see Figure 1. These
methods are widely implemented to synchronize the TDM networks.
Figure 1 Distributed PRC and master-slave methods
Ethernet networks are free-running (100 ppm). However, in case of synchronous Ethernet, it is
possible to design a master-slave synchronization architecture at the physical layer. In this case, the
physical layer can be used to provide reference timing signal distribution over packet networks,
from backbone level to access level. This method can also be used to provide timing recovery at the
IWFs for CBR services transported over packet networks (network synchronous operations). It
could also be used to provide a reference timing signal down to edge access equipment in a pure
Ethernet network supporting synchronous Ethernet.
Clause 7.1.1 details a high-level method of achieving a synchronous Ethernet network.
7.1.1 Synchronous Ethernet networks
The general concept of delivering a physical layer clock from the Ethernet switch over the
synchronous Ethernet is given in Figure 2.
A reference timing signal traceable to a PRC is injected into the Ethernet switch using an external
clock port. This signal is extracted and processed via a synchronization function before injecting
timing onto the Ethernet bitstream. The synchronization function provides filtering and may require
holdover. The clock supporting synchronous Ethernet networks is called synchronous Ethernet
equipment clock (EEC), see [ITU-T G.8262].
As shown in the figure, there may be a number of Ethernet switches involved in the distribution of
the reference timing signal. In such cases, the synchronization function within these Ethernet
switches must be able to recover synchronization "line timing" from the incoming bitstream.
10 Rec. ITU-T G.8261/Y.1361 (08/2013)

PRC traceable
PRC traceable Packet switched reference
reference network timing signal
timing signal
PRC
Ethernet switch supporting synchronous Ethernet
G.8261-Y.1361(13)_F02
Figure 2 Example of master-slave synchronization network over synchronous Ethernet
As part of the architecture, a distinction should be made between the network clock and the service
clock as described below.
The term synchronous Ethernet applies to the network clock that controls the bit rate leaving the
Ethernet switch. This clock shall comply with [ITU-T G.8262].
Within existing Ethernet technology, the service is effectively asynchronous. In synchronous
Ethernet, existing Ethernet services will continue to be mapped into and out of the Ethernet physical
layer at the appropriate rates as generated by the service clocks.
A proposed architecture for the synchronization networks based on synchronous Ethernet is
described in Annex A.
NOTE The synchronous Ethernet equipments have to comply with [ITU-T G.781] that specifies the
synchronization layer, and [ITU-T G.8264] that specifies the synchronization status message (SSM) for
synchronous Ethernet.
7.2 Packet-based methods

The second class of methods relies on timing information carried by the packets. In this case, the
timing could be carried by dedicated time stamp messages as shown in Figure 3. In case the
physical layer is not synchronous, this is the only alternative to a PRC distributed approach. The
principles underlying such methods are outlined in Appendix XII.
The time stamp can be based on several protocols. Examples of protocols are network time protocol
(NTP) and precision time protocol (PTP) (see clause XII.4).
The PTP protocol uses time stamps for synchronizing clocks in the network in a master-slave
hierarchy. It can be used to distribute frequency and/or time of day (ToD) information. PTP was
originally introduced for Industrial Automation and Test and Measurement Industries; however, a
new version (see clause XII.4) has included several updates to allow it to be used for Telecom.
NTP and simple network time protocol (SNTP) are protocols traditionally used to distribute time of
day information. The same packets may be used to distribute frequency information as well.
Packet-based methods are adaptive in nature, since they do not require the support of a network-
wide synchronization reference. Therefore, performance is impacted by packet delay variation in
the network (see clause 10). In order to minimize the impact from the packet network using either
PTP or NTP packets, specific algorithms may need to be implemented at the client side, depending
on the required accuracy (see Appendices III and IV).
Additional requirements on the intermediate nodes in the network can be considered to enhance the
performance of these methods. It should be noted that, especially in cases where legacy equipment
is used, this may not always be feasible.
Rec. ITU-T G.8261/Y.1361 (08/2013) 11

PRC reference
Time stamp Time stamp

master processing
Packet switched
network
Recovered reference
Time stamp timing signal
G.8261-Y.1361(13)_F03
Figure 3 Example of packet-based methods with timing distribution

of the reference timing signal via time stamps
NOTE For further details on packet-based methods and related requirements refer to [ITU-T G.8261.1],
[ITU-T G.8263], [ITU-T G.8265] and [ITU-T G.8265.1]. Additional information and related
Recommendations on packet-based methods are provided in clause 12.2.2.
The clock supporting packet-based methods is called packet-based equipment clock (PEC),
(see Annex B).
8 Timing recovery for constant bit rate services transported over packet networks
(CES domain)
CBR services (e.g., circuit emulated TDM signal) require that the timing of the signal is similar on
both ends of the packet network (CES domain) and is handled by the IWF responsible for delivering
the constant bit rate stream. The notion of service clock preservation is that the incoming service
clock frequency be replicated as the outgoing service clock frequency when considered in terms of
a long-term average. It does not imply that wander on the incoming TDM signal be replicated on
the outgoing TDM signal.
The four operating methods identified within this Recommendation are described in the following
clauses:
1) network synchronous operation
2) differential methods
3) adaptive methods
4) reference clock available at the TDM end systems.
12 Rec. ITU-T G.8261/Y.1361 (08/2013)

8.1 Network synchronous operation
This method refers to the fully network-synchronous operation by using a PRC traceable network
derived clock or a local PRC (e.g., GPS) as the service clock (see Figure 4). This implies the
availability of a PRC reference. It should be highlighted that this method does not preserve the
service timing.
CE IWF IWF CE
Packet switched
TDM network TDM
Synchronization Synchronization
network network
PRC PRC G.8261-Y.1361(13)_F04
The two PRCs may also originate from the same source.
Figure 4 Example of network synchronous operation

NOTE The reference timing signal at the input to the IWF shall comply with synchronization interfaces as
defined in [ITU-T G.823] and [ITU-T G.824].
8.2 Differential methods

According to the differential methods, the difference between the service clock and the reference
clock is encoded and transmitted across the packet network (see Figure 5). The service clock is
recovered on the far end of the packet network making use of a common reference clock. The
synchronous residual time stamp (SRTS) method [b-ITU-T I.363.1] is an example of this family of
methods. It should be highlighted that this method can preserve the service timing.
Recovered
TDM timing
Differential timing based on the
messages differential
CE IWF IWF timing CE
TDM messages
Packet switched TDM
network
TDM service clock network network
PRC PRC G.8261-Y.1361(13)_F05
Figure 5 Example of timing recovery operation based on differential methods

NOTE 1 Differential methods may work with IWF reference clocks that are not PRC traceable. The use of
non-PRC traceable clocks is application-dependent and is not within the scope of this Recommendation.
Rec. ITU-T G.8261/Y.1361 (08/2013) 13

NOTE 2 The reference timing signal at the input of the IWF shall comply with synchronization interfaces
as defined in [ITU-T G.823] and [ITU-T G.824].
8.3 Adaptive methods

In the adaptive method, the timing can be recovered based on the inter-arrival time of the packets or
on the fill level of the jitter buffer. It should be highlighted that this method preserves the service
timing (see Figure 6).
Recovered
TDM timing
based on the
Adaptive clock recovery adaptive
CE IWF IWF clock CE
TDM recovery
Packet switched TDM
network
TDM service clock G.8261-Y.1361(13)_F06
Figure 6 Example of adaptive method
8.4 Reference clock available at the TDM end systems

When a reference clock is available at each TDM end system, this is a trivial case, since both the
end systems have direct access to a timing reference, and will retime the signal leaving the IWF.
Therefore, there is no need to recover the timing.
The use of loop timing in the IWF on the TDM interface is an example of the implementation of
this method (see Figure 7). An example, of when this scenario might apply, is when two PSTN
domains are connected via a packet network. In this case, both the transmitter and receiver are
digital switches where there is a need to control slips.
CE IWF IWF CE
Packet switched
TDM network TDM
network network
PRC PRC
G.8261-Y.1361(13)_F07
Figure 7 Example of PRC reference timing signal available at the TDM end systems
14 Rec. ITU-T G.8261/Y.1361 (08/2013)

9 Network limits
9.1 CES network limits

The network limits on the TDM links at the output of the CES IWF (output of the Reference
selector in the CES IWF in Figure B.4) are defined in this clause.
The jitter and wander network limits currently specified in the relevant ITU-T Recommendations
(i.e., [ITU-T G.823] and [ITU-T G.824]) have to be fulfilled in all the scenarios that are relevant for
this Recommendation.
This clause describes three different deployment scenarios for a CES segment or island. The jitter
and wander limits for TDM traffic interfaces (excluding STM-N signals) carried over the CES
segment in each of these scenarios are defined in this clause.
The network limits, applicable to synchronization interfaces (as specified in [ITU-T G.823] and in
clause 6 of [ITU-T G.824]) and to STM-N signals carried over packet networks, are for further
study.
It should be noted that in some cases, signals with quality, according to clause 5 of [ITU-T G.823]
and clause 5 of [ITU-T G.824] (traffic interfaces), when traceable to a PRC, can be used as
reference timing signals towards an end equipment able to tolerate these signals and to correctly
operate (model for Deployment Case 2 is an example of this scenario).
NOTE The network limits provided by this clause shall be valid under normal conditions (e.g., when
failure conditions or maintenance actions are not present). It is out of the scope of this Recommendation to
specify the proportion of time during which these limits apply.
9.1.1 Network model underlying the network limits
For the transport of PDH signals, the models in Figure A.1 of [ITU-T G.823] and in Figure A.1 of
[ITU-T G.824] are the starting point to consider the insertion of a CES segment. The wander budget
allocation for the CES segment must be only a portion of the entire wander budget as specified in
[ITU-T G.823] or [ITU-T G.824], since the total wander budget has to be shared with the rest of the
network.
Depending on where the CES segment is located, different wander requirements may apply. Several
models of CES deployment have been identified; the models are defined in clauses 9.1.1.1, 9.1.1.2
and 9.1.1.3.
NOTE 1 The figures in this clause do not show the details on how the timing is recovered by the IWF or
how the timing is distributed in the packet network. For further details, refer to clauses 7 and 8.
NOTE 2 Only one CES island is presented in these models, since it aims at allocating wander budget only
for the CES technology segment. There might be several CES systems as long as their accumulated wander
generation is within the budget allocated for CES.
The wander accumulation through multiple islands is for further study.
9.1.1.1 Deployment Case 1
When the CES segment is located at an island between the two switches of the [ITU-T G.823]
reference model, the wander budget is calculated based on the model in Figure 8. The model is
based on Figure A.1 of [ITU-T G.823] and Figure A.1 of [ITU-T G.824] where one of the SDH
islands is replaced by the CES network.
Rec. ITU-T G.8261/Y.1361 (08/2013) 15

Figure 8 Network models for traffic and clock wander accumulation,
Deployment Case 1 and Case 2
The wander budget, expressed in maximum relative time interval error (MRTIE), for 2048 kbit/s
signal is defined in Table 1. The resultant overall specification is illustrated in Figure 9.
Table 1 Deployment Case 1: 2048 kbit/s interface wander budget

Observation Interval MRTIE requirement
(s) (s)
0.05 < 0.2 10.75
0.2 < 32 9 0.24 = 2.15
32 < 64 0.067
64 < 1000 18 0.24 = 4.3
Note that for the asynchronous configuration, the maximum observation interval to be
considered is 80 s.
The specification between 80 s and 1000 s for the asynchronous interfaces is for further
study.
16 Rec. ITU-T G.8261/Y.1361 (08/2013)

10
4.3
2.15
MRTIE ( s)
1
0.5
0.01
0.01 0.1 1 10 100 1000
0.05 0.2 32 64
Observation interval (s) G.8261-Y.1361(13)_F09
Figure 9 Deployment Case 1: 2048 kbit/s interface wander budget
The 2048 kbit/s jitter network limits shall comply with clause 5.1 of [ITU-T G.823].
The wander budget, expressed in maximum time interval error (MTIE), for 1544 kbit/s signal is
defined in Table 2. The resultant overall specification is illustrated in Figure 10.
Table 2 Deployment Case 1: wander budget for 1544 kbit/s interface

Observation interval () MTIE
in seconds in s
0.1 No Requirement (see Note)
0.1 < 0.47 4.5
0.47 < 900 2.1
900 < 1930 2.33 10e3
1930 < 86'400 4.5
NOTE This region is covered by jitter requirements.
10
4.5
2.1
MRTIE ( s)
0.45
0.01
0.01 0.1 1 10 100 1000 10000 100000
0.47 900 1930
Figure 10 Deployment Case 1: wander budget for 1544 kbit/s interface
Rec. ITU-T G.8261/Y.1361 (08/2013) 17

The 1544 kbit/s jitter network limits shall comply with clause 5.1 of [ITU-T G.824].
NOTE The network limits for the other PDH signals (i.e., 34'368 kbit/s, 44'736 kbit/s and 139'264 kbit/s
signals) carried over the CES segments are for further study.
Application A
When the CES segment is located outside the network elements containing the slip buffers (see
Figure 8), the retiming effect of the switch has to be considered. At the output of this equipment, the
timing of the traffic signal will meet the network limit for a synchronization signal which is tighter
than for a traffic signal.
The jitter and wander budget of the CES segment in this case is the difference between the
2048 kbit/s network limit (see Figure 1 of [ITU-T G.823]) and the 2048 kbit/s synchronization
interface network limit (see Figure 10 of [ITU-T G.823]). The limit, expressed in MRTIE, is
provided in Table 3. The resultant overall specification is illustrated in Figure 11.
Table 3 Case 2A: 2048 kbit/s interface wander budget

Observation Interval MRTIE requirement
(s) (s)
0.05 < 0.2 40
0.2 < 32 8
32 < 64 0.25
64 < 1000 (Note) 16
Note that for the asynchronous configuration, the maximum observation interval to be
considered is 80 s.
The specification between 80 s and 1'000 s for the asynchronous interfaces is for
further study.
100
16
10
8
1
0.01 0.1 1 10 100 1000
0.05 0.2 32 64
Figure 11 Case 2A: 2048 kbit/s interface wander budget

In the case of 1544 kbit/s interfaces, Case 1 requirements also apply to Case 2 applications.
NOTE 1 The network limits for the other PDH signals (i.e., 34'368 kbit/s, 44'736 kbit/s and 139'264 kbit/s
signals) carried over the CES segments are for further study.
18 Rec. ITU-T G.8261/Y.1361 (08/2013)

Application B
In this case, the application recovers timing through the TDM signal; therefore, there is no
differential jitter and wander between the clock and the data other than within the bandwidth of the
clock recovery since the data and clock are extracted from the same signal. The wander budget of
the CES segment is only limited by the timing quality requested by the application (e.g., base
station requirements) and not necessarily by [ITU-T G.823].
NOTE 2 This application is valid only for applications with a single signal; if instead two signals are
received, then the jitter and wander for one of those signals may differ from that of the clock extracted from
the other signal.
When retiming is implemented at the output of the SDH islands as shown in Figure 12, the
amplitude of noise on the PDH output is that of a synchronization interface. This allows an increase
in the wander budget up to that of Deployment Case 2 Application A in some configurations. It
should be noted that the service clock is not preserved end-to-end in this case.
Figure 12 Deployment Case 3 scenario
9.2 PNT network limits

The network models and the related network limits are defined separately for the case of the
synchronous Ethernet (EEC interface) and in the case of the packet-based clocks (PEC interface).
In particular, details on the synchronization chains based on the synchronous Ethernet (e.g., number
of the clocks in the synchronization chain) are according to the [ITU-T G.803], [ITU-T G.823] and
[ITU-T G.824] models.
Some examples are provided in Figure D.1. As described in these examples, the network limits are
defined in order to support hybrid implementations as well, where SDH is mixed with synchronous
Ethernet.
NOTE The network limits provided by this clause shall be valid under normal conditions (e.g., when
failure conditions or maintenance actions are not present). It is out of the scope of this Recommendation to
specify the proportion of time during which these limits apply.
Rec. ITU-T G.8261/Y.1361 (08/2013) 19

9.2.1 EEC interface network limits
The network limits at the output of the EEC in a synchronization chain are defined in this clause.
NOTE These limits are generally applicable at all points in the synchronization network. In some
application cases, mainly in the access network, it might be possible to recover timing from an Ethernet
signal that is generating jitter and wander according to the tolerance characteristics of the connected
equipment (see Appendix IV for examples of relevant applications). The usage of an Ethernet link that does
not comply with the limits defined in this clause is the operator's responsibility.
9.2.1.1 EEC-Option 1 interface network wander limits
The network limit for wander at the output interface of an EEC-1, expressed in MTIE, is given in
Table 4. The resultant overall specification is illustrated in Figure 13.
NOTE The values are relative to coordinated universal time (UTC), i.e., they include the wander of the
PRC.
Table 4 Network limit for wander at

EEC-Option 1 interfaces expressed in MTIE
Observation interval MTIE requirement
(s) (ns)
0.1 < 2.5 250
2.5 < 20 100
20 < 2000 2000
0.2
> 2000 433 + 0.01
Figure 13 Network limit for wander (MTIE)

at EEC-Option 1 interfaces
The network limit for wander at the output interface of an EEC-Option 1, expressed in time
DEViation (TDEV), is given in Table 5. The resultant overall specification is illustrated in
Figure 14.
20 Rec. ITU-T G.8261/Y.1361 (08/2013)

Table 5 Network limit for wander at
EEC-Option 1 interfaces expressed in TDEV
Observation interval TDEV requirement
(s) (ns)
0.1 < 17.14 12
17.14 < 100 0.7
100 < 1'000'000 58 + 1.2 0.5 + 0.000 3
Figure 14 Network limit for wander (TDEV)

at EEC-Option 1 interfaces
9.2.1.2 EEC-Option 2 interface network wander limits
The network limit for wander at the output interface of an EEC-Option 2, expressed in TDEV, is
given in Table 6. The resultant overall specification is illustrated in Figure 15.
Table 6 Network limit for wander (TDEV) at EEC-Option 2

Observation interval, TDEV
(s) (ns)
0.05 < 10 10
10 < 1000 3.1623 0.5
Rec. ITU-T G.8261/Y.1361 (08/2013) 21

Figure 15 Network limit for wander (TDEV) at EEC-Option 2
The mask in Figure 15 is taken from Figure 5 of [ITU-T G.824]. This mask is also found in
Figure I.1 of [ITU-T G.813] for Option 2 Network wander limits.
9.2.1.3 EEC interface network jitter limits
See Table 7 for EEC interface network jitter limits.
Table 7 EEC interface network jitter limits

Interface Reference
2048 kbit/s See [ITU-T G.823], clause 6.1: Network limits for output jitter at (Note 1)
2048 kHz synchronization interfaces, SEC requirements
1544 kbit/s See [ITU-T G.824], clause 6.1: Network limits for jitter
STM-n See [ITU-T G.825], clause 5.1: Network limits for jitter
Ethernet (synchronous See Table 7a (Note 2)
Ethernet)
NOTE 1 Jitter limits are taken from [ITU-T G.823], [ITU-T G.824] and [ITU-T G.825] in order to allow
proper interoperability with SEC based synchronization networks and combined EEC-SEC functions.
NOTE 2 In a chain of n (n 20) connected EECs, the accumulated network jitter has to be low enough
to allow all involved EECs to meet the output jitter specification at their synchronization outputs
(e.g., 2048 kHz, 2048 kbit/s, 1544 kbit/s). See Figure 16 showing EECs in a chain; see also Annex D.
22 Rec. ITU-T G.8261/Y.1361 (08/2013)

Table 7a Maximum permissible jitter at synchronous Ethernet network interfaces
Measurement bandwidth, Peak-to-peak amplitude
Interface
3 dB frequencies (UIpp)
1G 2.5 kHz to 10 MHz 1.5
(Notes 1, 2, 4)
10 G 20 kHz to 80 MHz 1.5
(Notes 1, 3, 4)
NOTE 1 There is no specific high band jitter requirement for synchronous Ethernet. The relevant
[IEEE 802.3] jitter requirements shall be met in addition to the specific synchronous Ethernet wideband
jitter requirements specified in this table.
NOTE 2 1 G includes 1000BASE-KX, -SX, -LX; multi-lane interfaces are for further study.
NOTE 3 10 G includes 10GBASE-SR/LR/ER, 10GBASE-LRM, 10GBASE-SW/LW/EW; multi-lane
interfaces are for further study.
NOTE 4 1 G 1 UI = 0.8 ns
10 G (10GBASE-SR/LR/ER,-LRM) 1 UI = 96.97 ps
10 G (10GBASE-SW/LW/EW) 1 UI = 100.47 ps
Figure 16 shows the reference chain of n (n 20) EECs together with their synchronization outputs.
Synchronization Synchronization Synchronization Synchronization

input output output output
2048 kHz or 2048 kHz or 2048 kHz or 2048 kHz or
2048 kbit/s or 2048 kbit/s or 2048 kbit/s or 2048 kbit/s or
1544 kbit/s 1544 kbit/s 1544 kbit/s 1544 kbit/s
EEC 1 EEC 2 EEC 3 EEC n

EHY ETY ETY ETY EHY
traffic syncE syncE syncE traffic
G.8261-Y.1361(13)_F16
Figure 16 EEC chain

9.2.2 PEC interface network limits
The network limits at the output of the PEC (see Figure B.5) are defined in this clause.
This clause describes two different deployment scenarios for a PNT segment or island with
packet-based equipment clocks (PECs). The jitter and wander limits for the PEC interfaces are
defined in this clause for each of these scenarios. Refer to [ITU-T G.8261.1] for network limits
applicable at the input of the PEC.
9.2.2.1 Network model underlying the PEC network limits
For the transport of reference timing signals, the models in Figure 8-5 of [ITU-T G.803] and in
Figure B.3 of [ITU-T G.823] are the starting point to consider the insertion of a PNT segment.
Depending on where the PNT segment is located, different wander requirements may apply. Several
models of PNT deployment have been identified; the models are defined in this clause.
NOTE The figures in this clause do not show the details on how the timing is distributed in the packet
network. For further details, refer to clause 7.
PNT Deployment Case 1
The model for the PNT Deployment Case 1 is shown in Figure 17. This case relates to a
master-slave synchronization network that, instead of using TDM based technologies (e.g., SDH or
PDH), is implemented over packet-based network technologies.
Rec. ITU-T G.8261/Y.1361 (08/2013) 23

The left figure (model A) shows an example where part of the synchronization network is replaced
by a PNT segment, and the right figure (model B) refers to a synchronization network fully
implemented over a PNT segment.
Figure 17 PNT segment replacing part (model A) or all (model B)

of the TDM-based synchronization network
The network limits as defined in clause 9.2.1 (EEC network limits) apply to both models A and B.
PNT Deployment Case 2
The model for the PNT Deployment Case 2 is shown in Figure 18.
This case is related to distributing the timing towards end equipment application (e.g., base
transceiver station (BTS), see Appendix IV).
24 Rec. ITU-T G.8261/Y.1361 (08/2013)

Figure 18 PNT distributing timing towards end applications
In Deployment Case 2, the requirements are set by the end equipment. These are expressed in terms
of tolerance and in terms of level of accuracy that the application requires for the correct operations.
Therefore, the PNT segment in Deployment Case 2 is allowed to generate jitter and wander up to
the limits tolerated by the end applications (e.g., network limits for traffic interfaces as defined by
clause 5 of [ITU-T G.823] or clause 5 of [ITU-T G.824]).
Further examples of network limits specifically applicable to the wireless applications are described
in clause IV.2.3.
10 Impact of impairments in the packet network on timing distribution and service clock
recovery
This clause discusses the different impairments impacting the traffic and its timing information in
packet networks. It is understood that the requirements of emulated circuits and recovered clocks,
which are specified in clause 9, are to be met under operational conditions.
Fundamentally, network synchronization is required in layer 1 networks to manage buffers. Layer 1
buffers as present in PDH, SDH and optical transport network (OTN) networks and its adaptation
functions are simple structures, where the nominal ingress and egress rate is controlled within
specific bounds as given in the related networking standards of these TDM networks. Mechanisms,
such as stuff bytes and pointers, together with system clocks, are the methods used to manage these
buffers and accommodate different clocking domains. The network design constrains the buffer size
to minimize latency. In layer 1 networks, such as SDH, there is a direct linkage between the
network clock and the level of wander or jitter that may be imparted on a client signal.
Rec. ITU-T G.8261/Y.1361 (08/2013) 25

In the case of packet data networks transport, the data is delivered over the network in blocks
(packets, frames), rather than being carried as a continuous stream of constant bit rate. Packets may
be statistically multiplexed and are routed via packet switches which subject a packet to delay due
to processing, buffering and retransmission at intermediate switches. Within a single switch,
multiple packet streams may have to converge onto a single output buffer. The resulting buffer
contention will introduce variable delay. In some cases, packets will be dropped. The clock used to
drive the layer 1 transmission links is likely to be asynchronous to the clock used within the switch.
Any difference in the rate at which packets are presented for transmission and the actual
transmission rate is accommodated by adding padding between packets or discarding packets.
Since packets may traverse different routes, a stream of packets from ingress to egress may exhibit
significant packet delay variation. Additionally, packets may be misordered resulting in additional
buffering. Services that utilize the packet network need to consider these impairments. For packet
networks, large buffers are required to perform packet level processing, in which case only coarse
levels of synchronization are required to support most services.
Unlike a layer 1 network, such as SDH, there is no direct linkage between the network clock and the
packet processing buffers. Thus, network timing cannot be used to control packet delay variation in
these networks. The need to provide network synchronization to a packet switch is generally
required only to meet synchronization requirements for physical layer interfaces to the switch, in
accordance to the related TDM interface requirements, as given by the particular networking
standards such as SDH/PDH.
Timing requirements of services carried at layers above the layer 2 network (e.g., IPTV, MPEG-4)
are specified to accommodate the variations of existing packet networks. Any service specific
timing is encoded at the service layer (e.g., H.264, MPEG-4).
However, there are cases when the physical layer of a packet network is synchronous (e.g., SDH)
and may be utilized by the adaptation layer.
In most cases, the information carried across the packet network, i.e., the characteristic information,
does not include timing information. This has certain ramifications when services require the
transfer of accurate timing. For end-to-end services, the timing characteristics of the server layer
need to support the synchronization requirements of the client. In traditional layer 1 mechanisms
(PDH, SDH and OTN), the network timing adaptation mechanisms are specifically designed to be
compatible with the timing requirements of the client signal. When the server layer is incapable of
supporting the timing of the client, alternate means of providing client timing may be required. This
would be performed at the adaptation layer to the network. An example is ATM AAL1.
Impairments in the packet network may have a detrimental effect on the recovery of the service for
a clock using adaptive methods. This clause explores the levels of such impairments that a clock
recovery process should be capable of withstanding, while maintaining the clock within the relevant
specifications.
The following performance parameters relating to packet network impairments are defined in
[ITU-T Y.1540] (for IP networks) and [ITU-T Y.1561] (for MPLS networks). Similar performance
measures for Ethernet networks are also defined in [ITU-T Y.1731].
1) packet transfer delay and delay variation
2) packet error ratio
3) packet loss ratio
4) packet severe loss block outcomes.
26 Rec. ITU-T G.8261/Y.1361 (08/2013)

10.1 Packet transfer delay and delay variation
10.1.1 Differential methods
Packet transfer delay and delay variation should not affect clock recovery performance when a
network reference clock is available at both ends and differential methods are used.
10.1.2 Adaptive methods
Adaptive recovery of the service clock from a packet stream containing constant bit rate or
timestamp data is, in general, achieved by some computing function of the arrival rate or arrival
times of the packets at the destination node.
If the delay through the packet network is constant, the frequency of arrival of packets at the
destination node is not affected by the network. There may be a phase lag in the recovered clock
due to the delay through the network, but there should be no frequency or phase wander.
If the delay varies, it may be perceived by a clock recovery process as a change in phase or
frequency of the original service clock. Therefore, during the design of a clock recovery process,
the causes of delay variation must be considered carefully.
There are several causes of delay variation on a packet network. These may include:
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.
10.1.2.1 Random delay variation
Random variation in delay results from the behaviour of switches or routers in the packet network.
The primary source of this is output queuing delay, caused when a packet arrives at a switch or
router when the exit port is blocked by other traffic, and the packet has to wait in a queue. Other
factors caused by the internal operation of the switch or router may also delay the packet, as
described in Appendix I.
It is not possible to predict with any certainty the delay of any packet through a switch or router,
although it is likely that the delay will increase with load on the device. Therefore, there will be
some correlation of delay between successive packets with the traffic load in the network.
10.1.2.2 Low frequency delay variation
As described above, the delay through a packet network, although unpredictable, is generally
correlated with the load on the network at the time period in question. Load is a dynamic quantity,
and may contain extremely low frequency components. For example, if a network is more heavily
loaded during the day than at night, this gives a component to the load variation with a 24-hour
period.
This extremely low frequency variation may lead to phase wander in a clock recovered from a
packet stream with the same period. Since many of the relevant clock specifications limit the
permissible phase wander over periods of 24 hours or more (e.g., [ITU-T G.824]), this has to be
compensated for during the design of a clock recovery process.
Rec. ITU-T G.8261/Y.1361 (08/2013) 27

10.1.2.3 Systematic delay variation
Certain types of underlying transport networks can cause systematic variation in packet delay over
time. For example, some types of transport use a "transmission window" or "timeslot", storing
packets for transmission until the window opens. Examples of these include passive optical network
(PON), x-digital subscriber line (xDSL) and worldwide interoperability for microwave access
(WiMAX).
The effect of the transmission window is to impose a systematic "sawtooth" delay profile onto a
packet stream (see Figure 19). For regular rate packet streams, e.g., those containing constant bit
rate data, the period of the transmission window may beat against the packet rate, causing a slow
variation in delay over time. These effects are very similar to the waiting time jitter in TDM
networks. In TDM networks, it is possible to control the waiting time jitter while this is not the case
in packet networks.
Transmission windows
(timeslots)
Incoming stream
Queueing
delay
Transmitted stream
Delay
"Timeslot"
repeat period
Launch
time
Queueing delay experienced by incoming packet stream over time
G.8261-Y.1361(13)_F19
Figure 19 Systematic delay variation caused by network with timeslots
Another type of systematic delay variation that regular rate packet streams may be subject to is
beating against other regular packet streams. Figure 20 shows what happens when two packet
streams of almost the same frequency are combined onto a single packet link by a switch or router.
Time
Slower
1 1 1 1 1
stream:
Faster
2 2 2 2 2
stream:
Queueing
delay
Combined
stream: 1 2 1 2 1 2 1 2 1 2
G.8261-Y.1361(13)_F20
Figure 20 Beating between regular rate packet streams
Stream 1 is the slower stream, and for a time the packets in stream 1 arrive at the switch or router
ahead of those in stream 2. However, the packets in stream 2 start to catch up. Since only one
packet at a time can be output onto the packet link, the packets in stream 2 start to experience
28 Rec. ITU-T G.8261/Y.1361 (08/2013)

queuing delay (see Figure 21). This delay builds up to the point where it is equal to the transmission
time of the packet on the link.
Eventually, the packets in stream 2 start to arrive at the switch or router ahead of those in stream 1,
and the queuing delay is removed. At this point, it is stream 1 which now sees a queuing delay. This
steadily declines until the packets in stream 1 arrive at the switch after the packets in stream 2 have
completed transmission.
Delay
Transmission time
of CES packet
Queueing delay experienced by faster packet stream over time Time

Delay
Transmission time
of CES packet
Queueing delay experienced by slower packet stream over time Time

G.8261-Y.1361(13)_F21
Figure 21 Delay profile experienced by beating packet streams
The duration of time that the packet streams experience queuing delay (i.e., the width of the
triangles in Figure 21) is inversely proportional to the difference in rate between the two packet
streams. Where the packet rates are very close, the duration may be extremely long. This long-term
variation in the delay may cause a slow phase wander in any clock recovered from one of the packet
streams.
Where multiple asynchronous regular rate streams share the same packet link, the effect may be
additive. In the worst case, packets from all streams may line up exactly yielding the maximum
queuing delay, although the frequency of this combined beat will reduce with the number of
streams.
10.1.2.4 Routing changes
The route taken by a stream of packets through a packet network may change at certain instants in
time. This may be due to network errors (e.g., routing around a failed or congested link), protection
switching to use an alternative route, or network reconfiguration.
The net effect of this is a step change in delay through the network. If uncompensated, this may be
seen in the recovered clock as a phase change. Such changes must be detected and accounted for in
the clock recovery process. In general, large changes in delay are relatively easy to detect and
compensate for, but small changes may be masked by the general delay variation, or local oscillator
drift at the clock recovery node.
10.1.2.5 Congestion effects
Congestion is the temporary increase in traffic load in all or part of a network. It may lead to all or
part of the network becoming "overloaded", and packets becoming severely delayed or dropped.
The duration of congestion events is variable, and may last for several seconds or minutes. If the
network experiences frequent severe congestion events lasting longer than 5 minutes, it is an
indication that the network is probably not suitable for running circuit emulation.
Rec. ITU-T G.8261/Y.1361 (08/2013) 29

10.1.2.6 Topology-dependent blocking mechanisms in packet networks
The topology of the network and, in particular, the interaction with other flows in the network can
affect the delay of a packet flow. This is due to the fact that different size packets traverse the
network at different rates. Large packets take longer to traverse a network, because they have to be
fully read into a network element before they can be processed and forwarded to the next hop. CES
and timing packets are typically short and move quickly through a network.
In a network with a shared route topology (e.g., as shown in Figure 22), this can cause additional
delay, even at quite low traffic volumes.
Ethernet
Traffic flow switches
of interest
1 2 3 4 5
Network traffic sharing

same route for several
network elements G.8261-Y.1361(13)_F22
Figure 22 Shared route topology
Where a large packet flow shares the same path for two or more consecutive links, it can begin to
obstruct the transmission of small packets. This is where small packets "catch up" with large
packets, because they propagate more quickly through the network. Figure 23 shows how the effect
works:
Figure 23 Large packet blocking along shared route
30 Rec. ITU-T G.8261/Y.1361 (08/2013)

The effect is such that if the load of big packets is sufficiently high, the small packets are likely to
be delayed at some point in their transit through the network (note this changes with the relative
size of the small to large packets). It causes the minimum possible delay through the network to
increase proportionally above this load.
10.2 Impacts from packet impairments

10.2.1 Packet error and packet loss
Impairments within packet networks have an impact on three distinct elements within the delivery
path, the IWF clock recovery process (note this may not be available to monitor), the service clock
recovery and the TDM service itself. Packet loss and packet misordering limits, and their impact on
the service and clock recovery processes are for further study.
Additional text discussing the relevant issues is given in the following subclauses.
Packet loss and packet misordering do not significantly affect the IWF clock recovery performance
for any of the methods presented in this Recommendation. Specifically, at levels at which the TDM
transport service remains useable, packet loss (both uniform and bursty) and packet misordering
have negligible effect on IWF clock recovery performance.
10.2.1.1 Impact on TDM service
TDM circuits carried over packet networks may be extremely vulnerable to bit errors caused by
packet loss. One of the reasons for this is that bit errors are magnified by the packet transport a
single bit error in the packet leads to the whole packet being discarded, yielding a burst of
consecutive bit errors in the recovered TDM stream. Hence, even moderate levels of packet loss
(from the viewpoint of conventional packet network) may cause unavailability of a TDM circuit.
NOTE The vulnerability of the TDM circuits would mainly depend upon the specific IWF characteristics.
Some IWFs might employ different packet-loss concealment techniques to protect the application from
packet loss.
10.2.1.2 Impact on IWF clock recovery process
The IWF clock recovery combines the packet to clock recovery algorithm, the embedded clock and
the timing recovery method used (i.e., adaptive or differential). Performance of the IWF clock
recovery process is a combination of packet network stress, the algorithm used to overcome
network stress, the clock embedded within the IWF and the timing recovery method used.
NOTE The packet loss and misordering limits for the preservation of IWF clock recovery and service clock
recovery shall be specified to cover all possible packet loss scenarios; these limits are for further study.
10.2.1.3 Impact on service clock recovery
With respect to the service clock recovery process, it is required that the clock recovery has to
withstand much higher packet losses than the TDM circuit itself, such that the service clock remains
within specification beyond the point where the data is declared unavailable. The IWF clock
recovery will directly influence the service clock recovery performance.
10.2.2 Packet severe loss block outcomes
[ITU-T Y.1540] and [ITU-T Y.1561] define a severe loss block outcome as occurring when for a
block of packets observed at an ingress interface during time interval T, the ratio of lost packets to
total packets exceeds a threshold. Similar effects are expected in Ethernet networks.
During these impairments, the timing recovery mechanism has to handle the total loss of packets as
discussed in clause 10.2.1. This subject is for further study.
Rec. ITU-T G.8261/Y.1361 (08/2013) 31

11 Impact of the reference clock impairment on the service clock recovery
11.1 Impairments for the network synchronous operation methods

The clocks involved in the transport of TDM signals through a packet network are shown in
Figure 24.
CE IWF IWF CE
TDM (clk1) TDM (clk4)
Packet switched
network
Network clock (clk2) Network clock (clk3)
network network
PRC PRC G.8261-Y.1361(13)_F24
Figure 24 Clocks involved in the transport of TDM signals

through a packet network for network synchronous operation
The clocks are:

the clock that generates the TDM signal (clk1 in the figure)
the network reference clock used for de-packetization in the left hand IWF (clk2 in the
figure)
the network reference clock used for de-packetization in the right hand IWF (clk3 in the
figure)
the clock that generates the TDM signal after the packet network (clk4 in the figure).
Clk1 has to be traceable to a PRC, this can be either obtained by loop timing as shown in Figure 24,
or by other means. If not, the use of a network clock reference in the de-packetizer (i.e., clk3 in the
figure) will raise severe problems.
In order to have correct timing in the output TDM signal, the clocks generating (i.e., clk1) and
retiming (i.e., clk4) the TDM signals must have the same long-term frequency (or within the PRC
limits); otherwise, an unacceptable rate of slips will be generated (the short-term noise shall be kept
within the applicable limits).
In normal operation, the network reference clock at the TDM source (clk1) and the network
reference clock at the de-packetizer are both locked to a reference timing signal that is traceable to a
PRC. However, during failure conditions in the synchronization network, these clocks may be
locked to a reference timing signal that is traceable to a clock operating in holdover mode. During
failure conditions, these clocks shall provide a suitable holdover that is based on the [ITU-T G.822]
slip performance objectives.
The clock providing this holdover function during failures in the synchronization network may be
either integrated in the equipment itself or available in the site (for instance, integrated in a
transmission network element or in a stand-alone synchronization equipment (SASE)). It is the
responsibility of the network planner to provide the most suitable solution.
32 Rec. ITU-T G.8261/Y.1361 (08/2013)

To summarize, the network synchronous mode of operation requires either the introduction of
precise clocks in the sink IWF or a system that allows to switch to another suitable clock in case of
loss of synchronization from the network clock (PRC).
In order to detect the periods of loss of synchronization, some kind of supervision of the traceability
is needed (e.g., SSM).
11.2 Impairments for the differential method

The clocks involved in the transport of TDM signals through a packet network are shown in
Figure 25.
Figure 25 Clocks involved in the transport of TDM signals through a packet network
for differential method
These are:
the clock that generates the TDM signal, PDH or SDH (clk1 in the figure);
this clock may be plesiochronous although it is considered that most signals are now
synchronous.
the network clock that is used to generate the differential timing messages (clk2 in the
figure).
the network clock (clk3 in the figure) that is used to regenerate the TDM clock (clk4 in the
figure) based on the differential timing messages.
Any phase noise on these clocks will cause phase noise on the timing of the output TDM signal.
In order to have correct timing in the output TDM signal, the clocks generating (i.e., clk1) and
retiming (i.e., clk4) the TDM signals must have the same long-term frequency (or within the PRC
limits); otherwise, an unacceptable rate of slips will be generated (the short-term noise shall be kept
within the applicable limits).
In normal operation, the network clocks generating the differential timing messages and
regenerating the TDM clock (clk2 and clk3 in the figure) are locked to a reference timing signal that
is traceable to a PRC. However, during failure conditions in the synchronization network, these
clocks may be locked to a reference timing signal that is traceable to a clock operating in holdover
mode. During failure conditions, these clocks shall provide a suitable holdover that is based on the
[ITU-T G.822] slip performance objectives.
The clock providing this holdover function during failures in the synchronization network may be
either integrated in the IWF itself or available in the site (for instance, integrated in a transmission
network element or in a SASE). It is the responsibility of the network planner to provide the most
suitable solution.
Rec. ITU-T G.8261/Y.1361 (08/2013) 33

In order to detect the periods of loss of synchronization, some kind of supervision of the traceability
is needed (e.g., SSM).
12 Results and consequences of the different synchronization methods over packet

network reference models
The recommendations on the methodology to distribute synchronization references (PNT domain)
and to recover the timing of a TDM service (CES domain) differ according to the network scenarios
and to the synchronization requirements that are relevant for the specific application.
12.1 CES domain recommendations

The following scenarios have been identified within the scope of this Recommendation (with
reference to the network models in clause 9.1).
12.1.1 Recommendation for the timing recovery of a TDM service (Deployment Case 1)
The network limits for PDH signals in this case are defined in clause 9.1 for Deployment Case 1.
The timing recovery of PDH signals carried over packet network can be performed by means of:
network synchronous operation when a signal traceable to PRC is available at the IWFs,
and it is not required to preserve the service clock.
differential methods when a PRC traceable reference is available at the IWF. With this
method, it is possible to preserve the service clock.
adaptive methods when the delay variation in the network can be controlled. With this
NOTE In these scenarios, the network limits are quite stringent. However, it is assumed that when
the network can be modelled according to model A (at least scenario 2 and scenario 3, see
Appendix V), the adaptive methods should allow the compliance with the network limits as defined
in clause 9.1.
It is for further study if the adaptive method can be used in a network that can be modelled
according to model B (see Appendix V).
The transport of SDH signals in this scenario is for further study. It should be noted that the clock
recovery for SDH signals shall fulfil the quality level, as per synchronization interfaces according to
[ITU-T G.823] for networks based on the 2048 kbit/s hierarchy, and to [ITU-T G.824] for networks
based on the 1544 kbit/s hierarchy. The use of the methods as described in clause 7.1 to support a
network synchronous operation can guarantee that these requirements are fulfilled.
12.1.2 Recommendation for the timing recovery of a TDM service (Deployment Case 3)
The network limits for PDH signals in this case are defined in clause 9.1 for Deployment Case 3.
The timing recovery of PDH signals carried over packet network can be performed by means of:
NOTE In these scenarios, the network limits are less stringent than in the clause 12.1.1 scenarios.
It is assumed that, when the network can be modelled according to model A, the adaptive methods
should allow the compliance with the network limits as defined in clause 9.1.
according to model B.
34 Rec. ITU-T G.8261/Y.1361 (08/2013)

recovery for SDH signals shall fulfil the quality level as per synchronization interfaces according to
12.1.3 Recommendation for the timing recovery of a TDM service (Deployment Case 2
Application A)
The network limits for PDH signals in this case are defined in clause 9.1 for Deployment Case 2
Application A.
The timing recovery of PDH signals carried over packet network in this case can be performed by
means of:
NOTE In these scenarios, the network limits are less stringent than in the clause 12.1.1 scenarios.
It is assumed that, when the network can be modelled according to model A, the adaptive methods
should allow the compliance with the network limits as defined in clause 9.1.
12.1.4 Recommendation for the timing recovery of a TDM service (Deployment Case 2
Application B)
The network limits for PDH signals in this case are defined in clause 9.1 for Deployment Case 2
Application B.
The timing recovery of PDH signals carried over packet network in this case can be performed by
means of:
NOTE In these scenarios, the network limits are dependent on the characteristics of the end
equipment that normally is able to tolerate the [ITU-T G.823] and [ITU-T G.824] traffic interface
limits. It is assumed that, when the network can be modelled according to model A, adaptive
methods should allow compliance to [ITU-T G.823] or [ITU-T G.824] as appropriate.
Rec. ITU-T G.8261/Y.1361 (08/2013) 35

12.2 PNT domain recommendations

The following scenarios have been identified within the scope of this Recommendation (with
reference to the network models in clause 9.2).
12.2.1 Recommendations for reference timing signals distribution over synchronous
Ethernet
The network limits for the reference timing signals in this case are defined in clause 9.2.
The deployment of synchronization networks over the physical layer using a layer 1 technique, such
as synchronous Ethernet described in clause 7.1.1 provides a method of transporting
synchronization which is not subject to any packet based stress (i.e., no impact from packet delay
variation).
The network limits as defined in clause 9.2 are met provided that the design of the synchronization
network follow the same design rules already defined for synchronization networks based on SDH,
i.e., compliance to [ITU-T G.803] synchronization network reference chain, see Figures 8-1 and 8-2
of [ITU-T G.803] where the EEC [ITU-T G.8262] shall replace the SEC. In particular, based on this
model, the longest synchronization network reference chain should not exceed 10 synchronization
supply unit (SSU)s and 60 EECs (Option 1), and between any two SSUs, the number of EECs
should not exceed 20.
NOTE 1 Values for "Option 2" clocks are for further study.
NOTE 2 The use of such technique requires that all network elements in the synchronization chain between
the primary reference clock and the network element that shall be synchronized (e.g., base station) support
Note that the delivery of synchronization signal at layer 1 is possible within one network operator
domain. The interworking between different network operator domains is for further study.
12.2.2 Recommendations for reference timing signals distribution over packets
[ITU-T G.8265] describes the general architecture of frequency distribution using packet-based
methods.
Packet-based methods are based on adaptive clock recovery methods, and therefore the
performances are generally impacted by packet delay variation in the network (see clause 10).
Because of this, when using such techniques, it is preferable to carry timing over a well-engineered
network with the timing flow carried in a channel that minimizes the packet network impairments.
A part of this process may be to assign the highest priority to such a flow.
It should be noted that the shared nature of transmission implies that all flows interfere with each
other to some degree regardless of priority with respect to timing.
What constitutes a well-engineered network to transport timing is currently under study. In
particular, as part of this study, some metrics are being considered. These shall be based on the set
of packet delays and packet delay variations.
NOTE 1 The terms packet delay and packet delay variation (PDV) used in this Recommendation are based
on definitions provided in [ITU-T G.8260].
36 Rec. ITU-T G.8261/Y.1361 (08/2013)

The characteristics of the oscillator implemented in the end equipment are among the key factors
with respect to the performances that can be achieved. Therefore, the characteristics of the oscillator
shall depend on the requirements to be fulfilled by the recovered timing signal, and on the level of
noise (packet delay variation) generated by the network.
The specification for the clocks to be implemented in the clock recovery function of the packet
based methods is outside the scope of this Recommendation.
The actual packet format is not significantly impacting the performance of packet-based methods.
Proper length and basic characteristics in terms of time stamp data format shall, however, be used
(PTP and NTP are two examples of time stamp format).
NOTE 2 Methods involving support from the nodes in packet network to reduce the impact from packet
delay variation (e.g., means to measure the packet delay variations that has been added by each hop in the
packet network) are under study (e.g., as part of the [b-IEEE 1588] Telecom profile studies). Architectural
aspects, scalability, clock requirements, etc., are among the aspects to study.
NOTE 3 This type of approach implies to implement some hardware support in the network equipments
involved in the synchronization path.
12.2.2.1 Recommendations for Deployment Case 1
The network limits for the reference timing signals in this case are defined in clause 9.2.2 for
Deployment Case 1.
The requirements in this case are expressed in terms of very low levels of noise (jitter and wander)
that can be generated in the network.
In this case, packet-based methods can be suitable only in case of low levels of packet delay
variation generated by the network on the packets selected by the timing recovery algorithm.
The clock characteristics, metrics and related limits under which Deployment Case 1 network limits
can be met are under study.
12.2.2.2 Recommendations for Deployment Case 2
The network limits for reference timing signals in this case are defined in clause 9.2.2 for
Deployment Case 2.
In this case, the level of noise that can be generated depends on the tolerance of the end application.
As an example, the typical wander that is tolerated by end applications can be expressed in terms of
[ITU-T G.823] and [ITU-T G.824] traffic masks. [ITU-T G.8261.1] defines the conditions under
which a packet network is suitable to support packet-based methods, and [ITU-T G.8263] specifies
the related clock characteristics.
Further information is provided in Appendix III.
Rec. ITU-T G.8261/Y.1361 (08/2013) 37

Annex A
Proposed network architecture for synchronous Ethernet

(This annex forms an integral part of this Recommendation.)
A.1 PRC Location

A typical synchronous Ethernet architecture will have a PRC located in one of three positions
dependent on the overall architecture that the network operator wishes to follow. However, these
can be summarized into three generic locations.
See Figure A.1, either:
Case A core located The PRC will be located at the core node, see Figure A.1 location
"A". This architecture suggests a few PRC nodes, i.e., centrally located with some form of
distribution to the IWF.
Case B access located The PRC will be located at some point further back within the
network (geographically separate to the IWF) typically at the multiservice access point, see
Figure A.1 location "B". This architecture suggests a greater number of PRC nodes to that
required for Case A, i.e., the PRCs are centrally located with some form of distribution to
the IWF.
Case C IWF located The PRC will be located geographically with the IWF and that there
will be a direct synchronization connection to the IWF, see Figure A.1 location "C". This
suggests many PRC nodes, i.e., one PRC per IWF.
Figure A.1 Reference clock location
Referring to the figure above, the synchronization flow is provided from the core network to
the IWF. It is not intended to distribute the timing from customer equipment (CE) towards the core
network.
A.2 Limiting jitter and wander of synchronous Ethernet

Limiting the jitter and wander production of the synchronous Ethernet solution in a wide area
network environment is a requirement to meet the network limits.
The synchronization function within the Ethernet switch supporting synchronous Ethernet should be
based upon the performance characteristics of an embedded clock. Such a clock shall be compliant
with [ITU-T G.8262] in order to ensure that proper network operation occurs when such a clock is
synchronized from another similar synchronous Ethernet clock or a higher quality clock. Use of
such a network clock ensures synchronization interworking compliance when such a synchronous
38 Rec. ITU-T G.8261/Y.1361 (08/2013)

Ethernet solution is combined with [ITU-T G.812] SSU or SASE, and hence to an [ITU-T G.811]
PRC, as specified in master-slave synchronization modes of operation. It also allows interworking
between existing TDM networks and new packet network architectures.
It should also be noted that this work does not impact any existing [IEEE 802.3] specifications for
frequency tolerance, etc., but refers to the new additional network element clock functionality.
A.3 Considerations on the design of synchronization network based on synchronous

Ethernet
The proper design of the synchronization network is the basic prerequisite to guarantee that a
reference timing signal is distributed according to proper quality and reliability.
This is also applicable in case the synchronization network is based on synchronous Ethernet.
In particular, as the architecture of synchronization networks based on synchronous Ethernet may
be more complex than synchronization networks based on SDH (e.g., due to meshed structure and
due to potential implementation of equipment not supporting synchronous Ethernet), the
synchronization planning activity is even more important.
In particular, the design shall analyse all network elements that are involved in the synchronization
trail.
These shall either implement the EEC or (in case of some simple network elements as the 2 port
devices) at least some through timing function in a similar way as done for the SDH regenerators.
The through-timing function for synchronous Ethernet equipment is for further study.
NOTE 1 The characteristics of the clocks implemented in the equipment deployed at the end of the
synchronization chain depend on the specific application implemented in the end equipment. The
characteristics of these clocks may deviate from some of the EEC specifications. This is for further study.
Another important aspect to consider is related to the proper handling of the SSM in the
synchronization chain.
The synchronization status message provides a mechanism for downstream EECs to determine the
traceability of the synchronization distribution scheme back to the PRC or highest quality clock that
is available. The synchronization function processes the SSM.
Under upstream network failure conditions, the synchronization function takes appropriate action
based on the SSM and pre-set priorities and selects an alternate synchronization feed. This may be
another network feed or an external feed.
The main role of SSM in synchronous Ethernet networks, similarly to the case of SDH networks, is
then to support in the design of the synchronization networks in order to properly handle fault
conditions.
NOTE 2 The SSM can help in the prevention of timing loops, but still a proper planning will be mandatory
to avoid timing loops.
SSM in synchronous Ethernet networks may not always be able to discover if a link is delivered
from an equipment (or link) not supporting synchronous Ethernet (and that, for instance, could be
inserted by mistake in a synchronization trail). As already mentioned, this shall be prevented via the
proper synchronization network design activity.
The definition of more advanced SSM functions in the future (e.g., transporting information on the
full synchronization path) may provide significant benefits.
When designing the synchronization network, it should be provided that the SSM is processed in
every network element that can alter the timing flow (e.g., due to internal clock entering the
holdover state).
It should also be avoided that timing is distributed with good quality, but SSM is not supported.
Rec. ITU-T G.8261/Y.1361 (08/2013) 39

The selection process in the receiving equipment of the reference timing signal can be configured to
use or not the incoming SSM.
Further details on the SSM for synchronous Ethernet are provided in [ITU-T G.8264].
NOTE 3 In addition to the SSM, [b-ITU-T G.781] addresses other degradations, such as loss of signal that
may be used to disqualify timing references.
A.4 Example of timing distribution via synchronous Ethernet

Figure A.2 shows an example of timing distribution over the synchronous Ethernet. The timing is
distributed from the PRC to the IWFs across the packet-switched network.
IWF IWF
TDM TDM
Packet switched
network
PRC traceable
reference timing signal
Ethernet switch supporting synchronous Ethernet

G.8261-Y.1361(13)_FA.2
Figure A.2 Example of timing distribution via synchronous Ethernet
A.5 Interworking of Ethernet and synchronous Ethernet interfaces

A.5.1 Interface type and operation mode definitions
The Ethernet interfaces according to [IEEE 802] are non-synchronous. With the introduction of
synchronous Ethernet, it has to be distinguished between different Ethernet port types together with
the different synchronization-related operation modes.
The following modes are defined (see [ITU-T G.8264]):
non-synchronous operation mode
synchronous operation mode.
The default mode for a synchronous Ethernet interface is non-synchronous operation mode.
See Table A.1.
Table A.1 Interface type and operation mode definitions

Interface type Operation mode QL process ESMC process
Ethernet Non-synchronous mode No No
Synchronous Ethernet Non-synchronous mode No No
Synchronous mode Active, all Yes
(QL-enabled mode) values
Synchronous mode Inactive Optional
(QL-disabled mode)
40 Rec. ITU-T G.8261/Y.1361 (08/2013)

In addition to a synchronous Ethernet port that is capable of both transmitting and receiving timing,
it is possible to consider ports that provide a reduced synchronous Ethernet function. Reduced
synchronous Ethernet functionality means the ability to support synchronization in a single
direction only. There are two possible types of reduced synchronous Ethernet interfaces:
1) synchronous Ethernet transmit only port: such a port performs all synchronous Ethernet
transmit functions, i.e., transmits quality level (QL) messages over Ethernet
synchronization messaging channel (ESMC), and transmits the physical EEC clock via the
Ethernet line.
2) synchronous Ethernet receive only port: such a port performs all synchronous Ethernet
receive functions, i.e., receives and processes QL messages over ESMC and recovers the
physical Ethernet line clock, providing it as a synchronization candidate.
The use of nodes with reduced synchronous Ethernet functionality has to be carefully considered in
the synchronization network planning. Such nodes are expected to be used at the end of a
synchronization chain.
Table A.1a Synchronous Ethernet reduced functionality with QL enabled

Synchronous Ethernet Synchronous mode Active Tx side: Yes
reduced functionality (Tx only) (Tx side only) Rx side: Optional
(QL enabled) Synchronous mode Active Rx side: Yes
(Rx only) (Rx side only) Tx side: Optional
Table A.1b Synchronous Ethernet reduced functionality with QL disabled

Synchronous Ethernet Synchronous mode Inactive Optional
reduced functionality (Tx only)
(QL disabled) Synchronous mode Inactive Optional
(Rx only)
A.5.2 Interworking requirements

Table A.2 shows the requirements for interworking between the different interface types and
operation modes. Any combination must enable the proper transmission of the Ethernet traffic. To
use synchronous Ethernet for network synchronization, synchronous Ethernet ports in synchronous
mode are required at both ends of each synchronization link involved in the synchronization path.
Rec. ITU-T G.8261/Y.1361 (08/2013) 41

Table A.2 Interworking between synchronous Ethernet and Ethernet ports
Traffic interworking Network synchronization
with interworking with
Interface Synchronous Ethernet Synchronous

Ethernet Ethernet
type port Ethernet port
Operation Non-synchronous Synchronous Non-synchronous Synchronous
mode mode mode mode mode
Ethernet Non-
synchronous
mode
Synchronous Non-
Ethernet synchronous
mode
Synchronous Synchronous

Ethernet mode
Interworking is possible
Interworking is not possible
A.5.3 Interworking in frequency

Ethernet works with 100 ppm as maximum frequency offset.
Synchronous Ethernet in synchronization mode uses network synchronization derived from PRC.
The worst case is holdover with 4.6 ppm as maximum frequency offset.
For data recovery, the synchronous Ethernet frequency input tolerance has to be 100 ppm.
Table A.3 shows the requirements for interworking in terms of frequency.
Table A.3 Interworking in frequency

Frequency
Interface Operation Input tolerance

Maximum output
type mode frequency
deviation For data recovery For clock recovery
Ethernet Non- 100 ppm 100 ppm n/a

Synchronous synchronous It might be locked to the EEC
Ethernet mode or, if not, be within 100
ppm
Synchronous Synchronous Locked to the EEC (in the Max. 4.6 ppm
Ethernet mode worst case 4.6 ppm)
(Note)
NOTE For QL-enabled and QL-disabled modes.
A.5.4 Interworking in noise

Ethernet specifies jitter according to IEEE. Wander is not an issue for Ethernet traffic operation.
Jitter and wander for synchronous interfaces is specified according to ITU-T. For Synchronous
Ethernet interfaces in synchronous operation mode, the relevant requirements are specified in
Recommendation [ITU-T G.8261] and [ITU-T G.8262].
42 Rec. ITU-T G.8261/Y.1361 (08/2013)

For data recovery, a synchronous Ethernet interface has to be able to tolerate the jitter from Ethernet
interfaces.
Table A.4 shows the details.
Table A.4 Interworking in noise

Noise
Maximum output
Interface Operation Equipment input noise tolerance
noise generation
type mode
For data recovery For clock recovery
Jitter Wander
Jitter Wander Jitter Wander
Ethernet Non-
According
Synchronous synchronous n/a n/a n/a
to IEEE
Ethernet mode According
n/a
According to G.8261 to IEEE
Synchronous Synchronous
(Network), G.8262 According to G.8262
Ethernet mode
(Equipment)
A.5.5 Related jitter measurement

Jitter measurements of Ethernet ports refer to IEEE. The IEEE jitter measurement uses the method
stressed eye and bath tub diagram. For data recovery interworking, the synchronous Ethernet
interfaces must be measured in the same way.
For synchronization interworking of synchronous Ethernet interfaces in synchronization operation
mode, the jitter specifications are included in Recommendation [ITU-T G.8261] and
[ITU-T G.8262].
Jitter measurements for synchronous Ethernet interfaces in synchronization operation mode are for
further study. See Appendix X.
Table A.5 provides a summary.
Table A.5 Jitter measurement

Interface Operation Jitter input Jitter noise Jitter noise
Network limits
type mode tolerance generation transfer
Ethernet Non-sync According to According to n/a n/a
Synchronous mode IEEE IEEE
Ethernet
Synchronous Sync For further study, see Appendix X for jitter measurements
Ethernet mode
A.5.6 Related wander measurement

Wander requirements are not specified for Ethernet interfaces.
Wander measurements for synchronous Ethernet interfaces in synchronization operation mode are
for further study. See Appendix X.
See Table A.6 for details.
Rec. ITU-T G.8261/Y.1361 (08/2013) 43

Table A.6 Wander measurement
Interface Operation Wander input Wander noise Wander noise
Network limits
type mode tolerance generation transfer
Ethernet Non-sync n/a
Synchronous mode
Ethernet
Synchronous Sync For further study; see Appendix X for jitter measurements
Ethernet mode
NOTE Considerations on interfaces and equipment with reduced synchronous Ethernet functionalities are
provided in [ITU-T G.8264].
44 Rec. ITU-T G.8261/Y.1361 (08/2013)

Annex B
IWF functional partitioning into CES and PNT IWF and network examples
B.1 General
The IWF is the functional block that translates data from a TDM-based network towards a
packet-based network, and vice versa (see Figure B.1).
TDM network side/
Packet network side IWF end equipment application
TDM IWF Packet network IWF TDM
TDM End equipment

TDM IWF Packet network IWF application
G.8261-Y.1361(13)_FB.1
Figure B.1 IWF in the network
In some applications, the function in the IWF may change the layer over which the timing is carried
(i.e., from packet to physical and vice versa), see Figure B.2.
Timing via synchronous Ethernet Timing via packet based methods

Packet network IWF Packet network
G.8261-Y.1361(13)_FB.2
Figure B.2 IWF changing the layer over which the timing is carried
The IWF is defined according to a two-domain structure (see Figure B.3), with a "CES IWF" taking
care of the synchronization aspects of the service clock domain, and a "PNT (packet network
timing) IWF" taking care of the synchronization aspects of the synchronization network clock
domain.
Rec. ITU-T G.8261/Y.1361 (08/2013) 45

Figure B.3 CES and PNT domains in the IWF
The CES IWF, in particular, shall recover the timing of the services that are carried over the packet
network (service clock signal recovery), as well as properly support the generation of the CES
packets towards the packet network.
As described in clause 8, the following operating methods are possible:
network synchronous operation
differential methods
adaptive methods
reference clock available at the TDM end systems.
Depending on the applicable methods, different types of clocks may be needed to be implemented
in the CES IWF.
This is detailed in clause B.3.
The timing distribution to/from the PNT IWF can be done according to traditional or new methods.
In fact, this block may recover the synchronization network timing either from the TDM side
(e.g., from SDH), or from the packet side (e.g., synchronous Ethernet, or new methods based on
dedicated packets).
The following list is an example of the possible cases for timing distribution to/from the PNT:
dedicated external reference (e.g., from SASE)
via synchronous physical layer (e.g., SDH, synchronous Ethernet). Timing carried by
packets (e.g., [b-IEEE 1588], NTP).
In some cases, the PNT IWF shall deliver to the CES IWF an accurate reference timing signal
derived from the synchronization network. In fact, the CES IWF may need this reference to support
the clock recovery mechanism: this applies to the network synchronous and to the differential
methods. Additional details are provided in clause B.2.
46 Rec. ITU-T G.8261/Y.1361 (08/2013)

B.2 IWF clocks
Figure B.4 shows the clocks that could be implemented in the CES IWF. These are:
packet-based service clock-adaptive (PSC-A): clock that recovers the CES service clock
signal from traffic packets according to an adaptive method.
packet-based service clock-differential (PSC-D): clock that recovers the CES service clock
signal from traffic packets according to a differential method.
These clocks are responsible for the CES IWF timing function (including free running, holdover,
filtering, selection, etc.).
Clocks PSC-A and PSC-D are specific per each CES user (i.e., any user has a dedicated clock). The
holdover should not be mandatory (but optionally it could be provided) as, in fact, only some free
running accuracy will be needed to support the PDH minimum requirements (e.g., 50 ppm for
2048 kbit/s signals). They normally handle only one-way packets to support TDM CES.
NOTE 1 New "services" distributing dedicated timing packets could be defined (using one-way or two-
way protocols) and different clocks would be defined. This is for further study.
The details of these clocks are for further study.
Figure B.4 Clocks in the CES IWF and PNT IWF
From a synchronization perspective, the CES IWF on the TDM side is mainly requested to generate
a synchronous physical layer according to defined requirements (e.g., jitter and wander limits), and
to recover the timing according to the applicable jitter and wander tolerance masks.
On the CES IWF packet side, the synchronization function concerns the "user data" packets. For
instance, in the packet-to-TDM direction and in case of adaptive methods, the TDM timing will be
recovered by some filtering algorithm based on the inter-arrival time of the packets (PSC-A is
taking care of this function).
Rec. ITU-T G.8261/Y.1361 (08/2013) 47

Block "R" in the CES IWF is used to regenerate the TDM timing: this can be looped back in case of
loop timing function, and can be used to control the packet flow on the TDM-to-packet direction
(e.g., to generate the timing messages used by the differential method). In particular, the block
"Packet Processing" is responsible for the generation of the timing messages supporting the
differential method (both the network clock and TDM timing are needed for this purpose), and for
the generation of the packets with a rate directly related to the TDM timing (valid for all methods).
Figure B.5 shows the clocks in the PNT-F which support the reference timing distribution over
packet networks (see clause 7).
Figure B.5 Clocks in the PNT-F

NOTE 2 Not all the interactions between the blocks into the PNT are shown in the figure.
NOTE 3 A different clock may be implemented in the PNT in case the timing is carried by TDM only
(e.g., SDH). This clock shall be based on the applicable Recommendations (e.g., [ITU-T G.813]).
According to Figure B.5, the following PNT clocks (synchronization network clocks) are defined:
PEC: clock to recover and send the network timing via dedicated packets.
EEC: clock to support the timing carried via Synchronous Ethernet (see [ITU-T G.8262]).
EXT: timing from an external dedicated reference timing signal (e.g., SASE/GPS).
The details on the PEC are for further study.
PEC and EEC handle the network clock, and therefore one frequency per network. There is one
clock/frequency per equipment. Holdover is requested for these clocks.
The PEC may be able to handle two-way packets (e.g., PTP, NTP).
It can be noticed that the PSC-A and the PEC may be based on a similar implementation as both are
based on an adaptive method, but different requirements may apply. In addition, while the PSC-A
should only terminate the timing distribution (it takes care of the TDM service timing recovery for
further generation of the TDM flow), the PEC may in principle be part of a synchronization
distribution chain.
48 Rec. ITU-T G.8261/Y.1361 (08/2013)

The clock EXT may be based on other relevant ITU-T Recommendations (e.g., [ITU-T G.812], and
[ITU-T G.813]).
It shall be noted that depending on the network application, only some of the functions (and only
some of the clocks) shown in Figures B.4 and B.5 have to be implemented in the IWF. As an
example, clock EXT is not needed if in the PNT there are other clocks implemented (e.g., EEC):
they could take care of receiving the external reference for use in the system instead.
As shown in Figure B.5, a reference timing signal can also be made available for supporting end
equipment applications (e.g., BTS).
The outgoing reference timing signal shown in Figure B.4 could also be carried by a CES signal.
The recovered timing signal could be made available as an external interface (e.g., [ITU-T G.703]
compliant) or could be internal to the system (in this case, the IWF is integrated into the end
application using this timing reference).
Examples of typical IWF applications are provided in Appendix IX.
Examples on the network applications are described in clause B.3.
NOTE 4 In addition to the IWF clocks, there can be clocks implemented in other network elements of the
packet network. A typical example is the EEC in the Ethernet switches which are part of the synchronization
distribution chain. In this case, the network element implements only PNT functions and the synchronization
functions can be represented by the applicable clock (e.g., EEC).
More generally, in case there are no CES functions and the EEC is connected on both sides to the
same type of physical layer (e.g., synchronous Ethernet), there is no IWF.
B.3 Network examples

Some network examples are shown in the following figures in order to get a better understanding of
the model presented in Figures B.1 and B.2.
Figure B.6 shows the TDM service clock recovery based on a network synchronous method: in this
example, the reference timing signal (network clock) is distributed from the PNT IWF having
access to a PRC (e.g., GPS), towards the PNT/CES IWF at the edges of the packet network (e.g.,
via synchronous Ethernet). The TDM service timing is derived from this network clock (i.e.,
network synchronous method).
PRC
PNT Network synchronous (e.g., synchronous PHY)

IWF
CES/PNT CES/PNT
TDM IWF TDM
IWF
Packet network
Timing is carried by the physical layer Timing is carried by the physical layer
Service clock timing flow

Network clock timing flow G.8261-Y.1361(13)_FB.6
Figure B.6 Example on timing recovery based on network synchronous method
Figure B.7 presents the service clock recovery based on the differential method. In this example, the
PNT IWF distributes the reference timing signal to the CES/PNT IWF that will use this signal to
implement a differential method (the flow from the left side IWF to the right side IWF represents
the distribution of the differential information via timing messages).
Rec. ITU-T G.8261/Y.1361 (08/2013) 49

PRC
PNT Differential method

IWF
CES/PNT CES/PNT
TDM IWF TDM
IWF
Packet network

Timing messages supporting the differential method
Figure B.7 Example on timing recovery based on differential method
Figure B.8 shows an example of service clock recovery by means of an adaptive method. In this
case, no reference timing signal is needed (and no PNT IWF is in fact shown in the figure).
Adaptive method
CES CES
TDM IWF IWF TDM
Packet network
Service clock timing flow G.8261-Y.1361(13)_FB.8
Figure B.8 Example on timing recovery based on adaptive method
Finally, Figure B.9 shows a PNT IWF with access to a PRC (primary reference clock) that
distributes the reference timing signal over the packet network (e.g., via synchronous Ethernet)
towards other PNT IWF at the edges of the packet network. In the example, the IWF PNT on the
right side supports the timing requirement of the end equipment. A typical example is to support the
timing requirements of a GSM BTS (e.g., 50 ppb on the radio interface).
PRC
Distribution of reference
timing signal in packet network
PNT
IWF
PNT PNT
IWF IWF
Packet network
e.g., end equipment, BTS
Figure B.9 Reference timing distribution between IWF PNT
50 Rec. ITU-T G.8261/Y.1361 (08/2013)

Annex C
CES IWF synchronization related requirements

C.1 Traffic interfaces

The following requirements have been taken from existing Recommendations (e.g., [ITU-T G.823],
[ITU-T G.824]).
NOTE The SDH interfaces are mentioned in the following clauses only for information purposes as the
transport of the SDH signals over packet network is for further study.
C.1.1 Physical, electrical and optical characteristics
Physical and electrical characteristics of E0 (64 kbit/s), E11 (1544 kbit/s), E12 (2048 kbit/s)
interfaces, all PDH interfaces, 51'840 kbit/s (STM-0) and ES1 (STM-1) interfaces shall comply
with the requirements of [ITU-T G.703].
Physical and optical characteristics of STM-1, STM-4, STM-16 interfaces shall comply with
requirements of the relevant physical interface Recommendations e.g., [ITU-T G.957],
[ITU-T G.691], [ITU-T G.959.1].
C.1.2 Jitter and wander tolerance
The input jitter and wander tolerance for networks based on 2048 kbit/s hierarchy at E0, E12, E22,
E31, E4 traffic interfaces shall comply with requirements of clause 7.1 of [ITU-T G.823].
The input jitter and wander tolerance for networks based on 1544 kbit/s hierarchy at E11, E21,
32'064 kbit/s, E32, 97'728 kbit/s traffic interfaces shall comply with requirements of clause 7.2 of
[ITU-T G.824].
The input jitter tolerance for SDH-based networks at STM-1e, STM-1, STM-4, STM-16 traffic
interfaces shall comply with requirements of clause 6.1.2 of [ITU-T G.825]. The input jitter
tolerance at 51'840 kbit/s traffic interface shall comply with requirements of clause 16.3 of
[ITU-T G.703].
The input wander tolerance for SDH-based networks at 51'840 kbit/s, STM-1e, STM-1, STM-4,
STM-16 traffic interfaces, according to clause 6.1.1 of [ITU-T G.825], shall comply with
requirements of clause 9.1 of [ITU-T G.812] and clause 8.1 of [ITU-T G.813], whichever is
applicable. These requirements are defined for synchronization interfaces (SSU and SEC
respectively) because STM-N traffic interfaces are considered as synchronization interfaces.
Measurement methods are defined in [ITU-T O.171] and [ITU-T O.172].
C.2 Synchronization interfaces

The following requirements have been taken from existing Recommendations
(e.g., [ITU-T G.703]).
C.2.1 Physical and electrical characteristics
Physical and electrical characteristics of T12 (2048 kHz) synchronization interface shall comply
with requirements of clause 13 of [ITU-T G.703].
Physical and electrical characteristics of E12 (2048 kbit/s) synchronization interface shall comply
with requirements of clause 9 of [ITU-T G.703].
Physical and electrical characteristics of E11 (1544 kbit/s) synchronization interface shall comply
with requirements of clause 5 [ITU-T G.703].
Rec. ITU-T G.8261/Y.1361 (08/2013) 51

C.2.2 Jitter and wander tolerance
The input jitter tolerance at T12, E12 synchronization interfaces, according to clause 7.2 of
[ITU-T G.823], shall comply with requirements of clause 9.2, Type I of [ITU-T G.812] for SSU
interfaces and clause 8.2, Option 1 of [ITU-T G.813] for SEC interfaces, whichever is applicable.
The input jitter tolerance at E11 synchronization interface, according to clause 7.3 of
[ITU-T G.824], shall comply with requirements of clause 9.2, Types II and III of [ITU-T G.812] for
SSU interfaces and clause 8.2, Option 2 of [ITU-T G.813] for SEC interfaces, whichever is
applicable.
The input wander tolerance at T12, E12 synchronization interfaces, according to clause 7.2 of
[ITU-T G.823], shall comply with requirements of clause 9.1, Type I of [ITU-T G.812] for
applicable.
The input wander tolerance at E11 synchronization interface, according to clause 7.3 of
[ITU-T G.824], shall comply with requirements of clause 9.1, Types II and III of [ITU-T G.812] for
applicable.
C.3 IWF synchronization function

Details of the IWF synchronization function are provided in Annex B.
Depending on the services to be provided, a suitable subset of the timing function described in
Annex B shall be supported by the IWF.
With reference to the CES IWF in Figure B.4, it is recommended to have slip control in the TDM
Tx direction to control possible over/underflow in the buffer. Slips shall be performed on
n 125 microsecond frames.
When TDM transmitter and/or receiver clocks are in holdover or are traceable to clocks in holdover,
and a synchronous clock recovery technique (differential method or network synchronous
operation) is used, slips (most likely uncontrolled) will occur.
When selecting a new timing source, the output wander may temporarily exceed the output wander
limit. However, the output wander must be within the output wander limit by the end of a period
called the "Stabilization Period". The requirements for the stabilization period are for further study;
more information is provided in Appendix II.
Another characteristic that is relevant for the IWF is the latency. The latency requirements are
normally defined on the network level specifying the total latency in the end-to-end connection.
Requirements on IWF contribution on the total latency is for further study.
The specification of the total noise that can be introduced by a CES segment is defined in
clause 9.1. This also defines the noise transfer characteristics of the total CES segment, including
the IWFs pair that adapts the TDM flow into the packet network.
52 Rec. ITU-T G.8261/Y.1361 (08/2013)

Annex D
Network applications and requirements for clocks specified

in ITU-T G.8262/Y.1362
A synchronization network according to [ITU-T G.803] uses PRC(s), SSUs and SECs. The SSUs
are often stand-alone equipment. The timing information is transferred via SDH network elements
(NEs) from a PRC to an SSU and from an SSU to an SSU of a lower hierarchical level. Two or
more routes are used for resilience. This is illustrated in Figure D.1-a.
With the introduction of synchronization in packet-switched networks (PSN), the packet-switched
NEs supporting synchronous Ethernet must be able to transfer timing information and interwork
with SDH NEs (e.g., containing SEC). The packet-switched network elements containing EEC must
be able to provide synchronization lines between PRC and SSUs and supply synchronization to time
sensitive applications. The new timing links via packet-switched networks must be in line with
existing SDH timing links for inter-operability with the synchronization network. Figure D.1-b
shows two synchronization chains, one formed by SDH NE (circles with "S"), and the other formed
by packet-switched NEs using synchronous Ethernet interfaces (circles with E).
Hybrid NEs are described in Appendix I of [ITU-T G.8262]. Hybrid NEs that offer both STM-N
interfaces with associated SDH-VC cross-connect functions and synchronous Ethernet interfaces
(ETY) with associated packet switching. It should be possible to use such hybrid NEs at any place
in synchronization chains. An example is illustrated in Figure D.1-c. The upper hybrid NE (circle
with H) uses an STM-N interface at the ingress and an ETY interface at the egress. The lower
hybrid NE uses an ETY interface at the ingress and an STM-N interface at the egress. Timing is
transferred from STM-N to ETY and from ETY to STM-N, respectively.
The clock characteristics of EECs may support the construction of timing distribution chains
providing the same behaviour as chains of SECs (see Figure D.1-b).
SSU SSU SSU
S E S
S S S
S E H
S S S
S E H
S S S
S E S
SSU SSU SSU
a) b) c)
G.8261-Y.1361(13)_FD.1
Figure D.1 Synchronization chains implemented with different types of NEs
Rec. ITU-T G.8261/Y.1361 (08/2013) 53

Appendix I
Characteristics of Ethernet switches, Ethernet networks,

routers and access technologies
(This appendix does not form an integral part of this Recommendation.)
I.1 Characteristics of Ethernet switches and networks

I.1.1 Delay characteristics of Ethernet switches
I.1.1.1 Functional operations within an Ethernet switch
From a "black box" perspective, an Ethernet frame passes through four functional operations in a
typical Ethernet switch. These are shown in Figure I.1:
Input Admission Switch Output Output

port Classifier control fabric queue port
G.8261-Y.1361(13)_FI.1
Figure I.1 Typical functions within an Ethernet switch

classification identification of the flow to which the frame belongs, and determination of
the output port and priority.
admission control application of traffic management for the flow (policing, shaping,
marking).
switching forwarding to the appropriate output port.
output queue waiting for a transmission slot on the output port. Typically, queuing
policies, such as strict priority, weighted fair queuing (WFQ) or round robin are applied.
The following clauses discuss the delay properties of the various functions within a switch.
I.1.1.2 Input stage delay
The time required for the classification and admission control stages should be approximately
constant in most cases. However, depending on the switch design and the traffic loading on the
switch, the delay through these functions may vary. For example, in some switches, both
classification and admission control may be performed in software on a network processor. At full
load, the software may not be able to keep up with the number of frames to be processed, hence the
delay may increase, and some frame dropping may occur. The same may also be true of some
hardware-based designs.
Figure I.2 shows a simplistic view of the variation of input stage delay with switch loading. Under
low traffic loads, the switch can cope with the number of frames passing through it without adding
to the delay. As the frame rate increases, while the overall processing capacity of the switch is not
exceeded, the instantaneous frame rate may exceed the available processing rate. This will cause
frames to be buffered awaiting processing, and some extra delay to be incurred. Finally, at some
point, the mean incoming frame rate may exceed the processing capacity, causing the delay to be
increased further, and, in some cases, frames to be dropped due to lack of buffering capacity.
54 Rec. ITU-T G.8261/Y.1361 (08/2013)

Processing
overload
Buffering
required
Incoming
frame rate
No buffering
required
Intrinsic
Minimum intrinsic
propagation delay
propagation delay
G.8261-Y.1361(13)_FI.2
Figure I.2 Variation of input stage delay with loading

I.1.1.3 Switch fabric delay
The delay through the switch fabric itself is also dependent on both switch architecture and traffic
loading. For example, many switches operate scheduling algorithms for switching of frames from
input ports through to output ports, and this may cause a small variation in delay to the frames,
depending on their arrival time relative to the scheduler "tick". However, in most cases, this
variation in delay is small due to the high frequency at which the scheduler works.
At very high incoming data rates, the switch fabric itself may be overloaded, and unable to cope
with the full volume of traffic requiring switching. This will result in frames being dropped.
I.1.1.4 Output queuing delay
The amount of delay added by the output queue will depend on the queuing policy employed, and
the priority of the traffic flow. For example, a high priority flow (such as might be used for a packet
timing flow) in conjunction with a strict priority policy might experience "head-of-line blocking"
delay. This is where, although a frame has highest priority, it arrives at the output port just after a
low-priority frame has started to be transmitted. The high priority frame then has to wait until the
other frame has finished transmitting.
Figure I.3 shows the delay profile experienced by a population of high priority frames in
conjunction with a strict priority queuing policy. For the purposes of simplicity, this diagram
assumes frames experience an approximately constant delay through the other switch functions,
here termed "intrinsic propagation delay through switch". A proportion of frames arrive at the
output queue at a time when there are no other frames currently being transmitted. These frames are
transmitted immediately. The remainder has to wait in the queue while the current transmission
completes. There may also be an additional delay, due to other high priority packets also in the
queue.
Rec. ITU-T G.8261/Y.1361 (08/2013) 55

Figure I.3 Strict priority queuing: Head of line blocking
I.1.1.5 Typical delays in the Ethernet switches
Based on the model described in clause I.1, it is possible to provide a simplified modelling of the
delays caused by an Ethernet switch, identifying two main contributions.
The first type of contributions is related to the classification, admission control and switching
operations; the second type of contribution is related to the output queue and transmission.
The first type of the delay is then mainly related to the processing capacity of the switch, while the
second one depends on the bit rate of the outgoing line (e.g., 1 Gbit/s) and on the queuing
policy/priorities that are implemented.
Assuming that the design of the Ethernet network will not implement Ethernet switches where the
bottleneck is the processing capacity of the Ethernet switch, one could assume that the processing
capacity should contribute with values below 10 microseconds (in fact a 1500 bytes packet in the
output queue takes 12 microseconds on 1 Gbit/s link), and, in addition, the processing overload or
processing buffering should not be an issue (see Figure I.2).
With respect to the second type of delay, these can be calculated according to the model provided in
Appendix V.
The simplified model is shown in Figure I.4.
Packets with zero queueing delay (no overload or processing buffering in the switch)
Number
of frames
Queueing delay (depends on queueing policy and load) (Note)
Internal processing
Total packet delay

through the switch (s)
<10 s
Fixed delay depends on output bit rate and packet size

(e.g., 12 s for 1500 bytes packet over 1 Gbit/s)
NOTE Slope may vary depending on distribution of traffic in network.
G.8261-Y.1361(13)_FI.4
Figure I.4 Simplified model of the delays in the Ethernet switch
56 Rec. ITU-T G.8261/Y.1361 (08/2013)

Referring to Figure I.4, it shall be noted that the queue processing may also impact the shape of the
delay distribution.
I.1.2 Characteristics of switched Ethernet networks
I.1.2.1 Topology of Ethernet networks
Although there are many different possible network topologies, for the purpose of considering a
particular flow through a network, it can be modelled as a chain of Ethernet switches as shown in
Figure I.5. At each switch in the chain, an Ethernet frame has the potential to be delayed due to the
mechanisms described in clause I.1. This delay will be affected by the other traffic flowing through
the switch. Traffic directed to the same output port will affect the output queuing delay, while the
sum total of all traffic flowing through the switch (including that flowing to other ports) will affect
the processing and switch fabric delays.
Traffic flow of
interest Ethernet Switches
Network traffic routed to Network traffic routed to the

other output ports same output port
(affects overload points) (affects output queuing delay)
Figure I.5 Data flows within an Ethernet network
The length of the chain affects the total delay of the system; clearly the more switches there are, the
greater the total delay, also the greater the delay variation. However, in many Ethernet networks,
the length of the chain may be quite small. For example, in a hierarchical network, there may often
be only two or three levels of hierarchy, yielding a chain length of up to five switches.
In some instances, a ring topology may be employed. Typically, these may contain around ten
switches, giving a maximum "distance" around the ring of five switches. Occasionally,
interconnected rings may be used, which could double the "distance" to around ten.
I.1.2.2 Traffic patterns and levels
With the exception of constant bit rate and real-time traffic, most network traffic is extremely bursty
in nature. It has been observed that on almost any level one cares to look, traffic variation can be
observed. For example, at a very small level there is bursting due to the opening and closing of the
transmission control protocol (TCP) window size. At a larger level, there may be bursting due to the
nature of the application (e.g., downloads of large files), while at a larger level still there may be
bursting due to the time of day (e.g., higher activity levels during the day than at night).
When considering the delay performance of a TDM transport flow, the effects of other traffic in the
network have to be considered. For example, in Figure I.5, each of the network traffic flows may be
varying in some form, independently of the other flows.
[b-ITU-T G.1020] proposes the use of four-state Markov models for modelling packet loss
distribution. A similar technique could be applied to burst lengths in each flow, allowing bursts and
Rec. ITU-T G.8261/Y.1361 (08/2013) 57

groups of bursts to be modelled. The longer term (e.g., diurnal variation) could then be applied as a
gradual variation in burst densities.
I.1.2.3 Disruptive events in Ethernet networks
There are several types of "disruptive events" that may cause sudden changes in delay in an
Ethernet network. The resulting delay changes may be permanent or temporary. These disruptive
events include:
routing change, causing a permanent step change in delay
temporary network overload, causing a significant but temporary delay change
temporary loss of service, causing all packets to be lost for a period.
I.2 Delay characteristics of routers

This clause describes the delay characteristics of routers. Similarities exist with Ethernet switches
described in previous clauses.
In order to identify the potential sources of delays in a router, it could be useful to describe the path
that a timing packet uses when being carried across a network node.
A network node can be generically modelled with three main segments:
1) ingress segment: corresponds to all the functions that the timing packets may use in the
network node from the ingress physical port to the entry to the forwarding engine of the
node.
2) forwarding segment: corresponds to the forwarding engine of the network node.
3) egress segment: corresponds to all the functions that the timing packets may use in the
network node from the exit of the forwarding engine of the node to the egress physical port.
The following figure illustrates these three main segments:
Ingress segment Forwarding Egress segment

segment
Reception/ Ingress Ingress Egress

integrity port mux policing QoS
check
Ingress Forwarding Egress

queueing engine queueing
G.8261-Y.1361(13)_FI.6
Figure I.6 Illustration of the three main segments of a router
The models characterizing each of these segments are for further study.
I.3 Delay characteristics of access technologies (Microwave nodes, PON, DSL)

The delay characteristics of access technologies (microwave nodes, PON, DSL) are for further
study.
58 Rec. ITU-T G.8261/Y.1361 (08/2013)

Appendix II
Stabilization period
The stabilization period is a parameter that may be important during the start-up phase (in order to
get a quick installation of the equipment), or when switching between timing references (in order to
limit the phase transient). In case the equipment has been operating in holdover mode for long
periods (e.g., hours), the phase error, when selecting a new clock reference, would be largely
dominated by the phase error caused by the frequency error of the clock in holdover.
In case the adaptive method is used, the requirement on the stabilization period may depend on the
actual phase noise in the packet network. In fact, a high packet delay variation in the packet
network may require a long period before the clock can lock to the timing reference.
The filter implementation and the characteristics of the internal oscillator are important as well. In
fact, depending on the holdover characteristics (e.g., [ITU-T G.812] Type II vs. Type III), longer
time could be accepted when switching from a reference to a second reference, as a good holdover
can allow longer locking periods (the main requirement is to limit the total phase error during
reference switching).
The requirements on the stabilization period are under study.
For the purpose of the tests detailed in Appendix VI, a stabilization period of at least 900 s is
proposed for the adaptive methods as, in order to properly characterize the packet delay variation
statistics in a network, a sufficiently long period might be required.
Rec. ITU-T G.8261/Y.1361 (08/2013) 59

Appendix III
Considerations on packet-based methods

In some applications, it is required to recover reference timing signals that comply with wander that
can be expressed in terms of [ITU-T G.823] and [ITU-T G.824] traffic masks. Under certain
circumstances, these network limits are within the achievable performances of the packet-based
methods in packet networks properly designed (e.g., networks that can be modelled as network
presented in model A, see Appendix V). What constitutes a properly designed packet network is
currently under study, see also clause 12.2.2.
For the case of mobile backhauling, the use of packet-based method to synchronize the BTS/Node
B will depend on a number of complex issues significantly determined by the embedded
functionality of the BTS/Node B.
The following needs to be considered:
1) stability of the oscillator in the BTS/Node_B
2) physical layer interface to the BTS/Node_B (e.g., TDM or Ethernet)
3) tolerance specification at the input of the BTS/Node_B (specified in terms of
[ITU-T G.823]/[ITU-T G.824] traffic interface masks by Third Generation Partnership
Project (3GPP) in case of TDM interfaces).
With respect to point 1), when frequency accuracy is the only concern, a stable oscillator could
allow to relax the requirements on the packet delay variation in the network as longer filtering
period could be designed. It shall be noted that stable oscillators are normally implemented in the
base stations, due to short-term stability required on the radio interface and holdover requirements.
This area is for further study (e.g., time to meet a specific requirement after the oscillator has been
powered on).
60 Rec. ITU-T G.8261/Y.1361 (08/2013)

Appendix IV
Applications and use cases

IV.1 Background
The purpose of this appendix is to provide some explanatory information related to three use case
categories. Special consideration is given to situations where the transport network supporting the
use-case is changed from PDH/SDH to Ethernet.
There are three principal types of synchronization that are of importance. Each particular
application may have different needs, and it is necessary to ensure that the transport network is
capable of providing this functionality or the network operator must provide for alternate methods.
The three synchronization categories are:
1) frequency synchronization
2) phase synchronization
3) time synchronization.
Frequency synchronization relates to the alignment of clocks in frequency, a process that is also
referred to as syntonization. Phase synchronization and time synchronization are defined in
[ITU-T G.8260]. For some applications frequency synchronization may be adequate; for others a
combination of frequency and time/phase may be required. For some applications, the source of
time/timing may be specified, and for others the source could be any one of a set of (master) clocks.
For additional details on phase and time synchronization aspects see [ITU-T G.8271].
The three use case categories considered here are:
1) wireless
2) infrastructure
3) media gateway.
IV.2 Wireless
IV.2.1 Applications
Within this general use case category, there are several applications of importance. Some of these
require just frequency information, and others require time-of-day, and others require phase. The
application, from the viewpoint of timing, is to deliver the appropriate timing information to a base
station (e.g., Node B).
IV.2.2 Examples
IV.2.2.1 GSM base station (frequency synchronization)
The timing requirement applicable to the GSM radio interface can be found in
[b-ETSI TS 145 010]. The radio interface requirement for a GSM base station is frequency accuracy
of 50 ppb. In case of Pico base stations, the accuracy can be relaxed to 100 ppb. The need for this
requirement stems primarily from the need to support handover of mobiles between base stations. It
should be noted that relevant requirements documents do not directly address the (wireline) network
interface. Nevertheless in case of TDM networks, the synchronization requirements on input signals
are normally expressed in terms of output wander masks presented in [ITU-T G.823] and
[ITU-T G.824], and traceability to a PRC source.
Rec. ITU-T G.8261/Y.1361 (08/2013) 61

It should be noted that in case of GSM radio access network, there are not so strict frequency
accuracy requirements related to limit the slip rate. In fact, in these cases, the data of a single user is
stored in relatively large buffer (from 10 to 30 ms) and also assuming 50 ppb frequency accuracy
the data would be lost (buffer empty or full) after long times, much longer if compared with
classical switching network elements where buffers handling the data are much smaller (125 s).
IV.2.2.2 UMTS FDD base station (frequency synchronization)
The timing requirement applicable to the WCDMA frequency division duplex (FDD) radio
interface can be found in [b-ETSI TS 125 104].
The radio interface requirement for universal mobile telecommunications systems (UMTS) FDD
base stations is a frequency accuracy of 50 ppb; for the FDD mode, there are no phase alignment
requirements.
As for the case of GSM networks, there are not so strict frequency accuracy requirements related to
limit the slip rate because of the large buffer used to store data of a single user.
IV.2.2.3 UMTS TDD base station (frequency and phase synchronization)
The timing requirement applicable to the WCDMA time division duplex (TDD) radio interface can
be found in [b-ETSI TS 125 105].
The radio interface requirement for UMTS TDD base stations is a frequency accuracy of 50 ppb;
for the TDD mode, there is the additional requirement for the phase alignment of neighbouring base
stations to within 2.5 s.
As for the case of GSM networks, there are not so strict frequency accuracy requirements related to
limit the slip rate because of the large buffer used to store data of a single user.
IV.2.2.4 3GPP2 CDMA2000 base station (frequency and time synchronization)
The relevant CDMA2000 standards are the [b-3GPP2 C.S0010-B] and [b-3GPP2 C.S0002-C].
According to the CDMA2000 specifications, the average frequency difference between the actual
CDMA transmit carrier frequency and specified CDMA transmit frequency assignment shall be less
than 50 ppb.
In the CDMA2000 specifications, it is also specified that each base station shall use a time base
reference that is time-aligned to CDMA System Time. CDMA System Time is synchronous to
UTC time (except for leap seconds) and uses the same time origin as GPS time. All base stations
use the same System Time (within a small error tolerance). For all base stations, the pilot time
alignment error should be less than 3 s and shall be less than 10 s.
Because of the above requirements, it is a common practice to equip CDMA base stations with GPS
receivers.
IV.2.2.5 TD-SCDMA base station (frequency and phase synchronization)
The timing requirement applicable to the TD-SCDMA radio interface can be found in
[b-3GPP TR 25.836].
The radio interface requirement for TD-SCDMA base stations is a frequency accuracy of 50 ppb;
there is the additional requirement for the phase alignment of neighbouring base stations to within
3 s (this requirement is then measured comparing the phase between adjacent base stations).
Because of the above requirements, it is a common practice to equip TD-SCDMA base stations with
GPS receivers.
62 Rec. ITU-T G.8261/Y.1361 (08/2013)

IV.2.3 Remarks
The requirements listed in the previous clauses apply to the radio interface. When time or frequency
reference is carried by the network, other requirements apply. These depend on several factors such
as radio base station oscillator characteristics, filter capability of the radio base station, etc. As an
example, a long-term frequency accuracy significantly better than 50 ppb may be required for the
reference timing signal carried over the network in case of 50 ppb frequency accuracy requirement
shall be fulfilled on the radio interface. The value of 16 ppb ([ITU-T G.812] Type II frequency
accuracy) has sometimes been mentioned.
In general, in the long term, the reference timing signal may be allowed to drift n ppb provided that
this is sufficiently below the maximum allowed deviation (i.e., n ppb << 50 ppb << 100 ppb, or
<< 250 ppb for the different cases). This would result in a tolerance MTIE mask where the limits on
the short term are set by the [ITU-T G.823] and [ITU-T G.824] traffic masks and in the long term
by an n ppb line (where n shall be below the applicable requirement on the radio interface).
NOTE It has been reported that there are cases of base stations that are less tolerant to wander in the short
term than what is specified by [ITU-T G.823] and [ITU-T G.824] traffic masks.
Similarly, in case accurate time and/or phase shall be distributed to the radio base stations, the
budget to be allocated to the network might be much smaller than the requirements defined by the
wireless standards to be fulfilled on the radio interface. These aspects are for further study.
In several cases, such as the GSM base station situations, such equipment is deployed and working
and capable of deriving its timing needs from the traffic interface to the (wireline) network, such as
PDH or SDH. If the PDH/SDH link is replaced by an Ethernet or synchronous Ethernet link, the
needs of the base station shall still be met.
Distribution of phase/time is not common in the case of PDH/SDH links. Accurate phase and time
is commonly distributed via GPS. Depending on the accuracy requirements and on the network
conditions, methods based on time stamps (see clause 7.2) may be also appropriate for this purpose.
In some implementations, two-way protocols are used.
IV.3 Infrastructure
There are several applications in this use case category including IP digital subscriber line access
multiplexer (IP DSLAM), modular cable modem termination system (M-CMTS), multiservice
access node (MSAN), optical line termination (OLT), etc. This area is for further study.
IV.4 Media gateway

For further study.
Rec. ITU-T G.8261/Y.1361 (08/2013) 63

Appendix V
Packet networks reference models

The packet network reference models that have been used to characterize the performance of packet
networks, in terms of packet delay variations, are shown in Figures V.1 and V.2: model A in
Figure V.1 is related to applications with very strict delay and delay variation requirements,
model B in Figure V.2 refers to scenarios with less strict packet delay variation requirements.
These models do not describe how packet networks have to be designed. The purpose of these
models is purely to provide a general understanding of the characteristics of typical packet
networks.
V.1 Ethernet networks models

The following models have been defined for the case of Ethernet networks (Figures V.1 and V.2).
1 N
GE GE ... FE or GE
Outgoing traffic N = 10
Input traffic according to traffic models GE 1 Gbit/s Ethernet
Flow of interest FE 100 Mbit/s Ethernet
Ethernet switches
G.8261-Y.1361(13)_FV.1
Figure V.1 Packet network reference model A (switched Ethernet network)

1 M
GE GE ... GE
Outgoing traffic M tbd

Input traffic according to traffic models GE 1 Gbit/s Ethernet
Ethernet switches
G.8261-Y.1361(13)_FV.2
Figure V.2 Packet network reference model B (switched Ethernet network)

NOTE 1 With respect to the number of Ethernet switches ("M") in Figure V.2, there is a common
agreement that 20 is a reasonable number. This has to be confirmed.
NOTE 2 10 Gbit/s links could be considered in new models.
The following cases have been considered:
scenario 1: switched Ethernet network, best effort with over-provisioning (single queue);
scenario 2: switched Ethernet network, quality of service according to [IEEE 802.1Q],
[b-IEEE 802.1p] (at least two queues, with one dedicated queue for handling real-time data
and WFQ discipline);
64 Rec. ITU-T G.8261/Y.1361 (08/2013)

scenario 3: switched Ethernet network, quality service according to [IEEE 802.1Q],
[b-IEEE 802.1p] (with one queue dedicated for the handling of data used for timing
recovery, e.g., time stamps).
NOTE 3 In order to understand the applicability of the models in Figures V.1 and V.2, a simple approach
could be to define two main classes of network scenarios: a backbone network, that can also be used to carry
services in the access network (e.g., leasing bandwidth), and a dedicated access network. Model B
(Figure V.2), could be the reference model mainly applicable for the first type of packet network (backbone),
while model A (Figure V.1) could be the reference model mainly applicable to an access network
(e.g., wireless access network).
Referring to the models described in clause 9, this means, that in general (most of the cases), the CE
island in Case 1 and Case 3 could be characterized by packet network reference model B, while the
CE island in Case 2 could be characterized by packet network reference model A. A third case is
when bandwidth is leased by an operator to connect two end points connected via Ethernet switches
(e.g., 100 Mbit/s guaranteed bandwidth over 1 Gbit/s transport). Also in this case, models in this
appendix could be used. With a proper service level agreement (SLA) between the customer and the
Ethernet network operator, one could assume that the interfering traffic in the intermediate nodes
could be considered as traffic with lower priority. The SLA in this case could guarantee bandwidth
and increase priority, since both will be key elements of a premium SLA, such as, for instance, the
cellular operators will require from their Ethernet providers. This could then be considered as a
scenario with traffic handling characteristics between scenario 2 and scenario 3. With respect to the
expected result, when leasing bandwidth in a packet network, better performance could then
normally be achieved if compared with scenarios 1 and 2.
The following are the conditions considered as a basis for the characterization of a packet network:
traffic load: 60% static;
packet rate: 10 packets per second;
observation intervals: 60 minutes;
traffic models: according to Appendix VI;
packet length: 90 octets.
With respect to the conditions listed above, the characteristics of 2 Mbit/s signals may also be
considered, i.e., packets with a payload of 256 octets and a packet rate of 1000 p/s.
Based on the above models, the following parameters describe the typical behaviour of the packet
network in the different cases:
Rec. ITU-T G.8261/Y.1361 (08/2013) 65

Table V.1 Parameters for the relevant network models
min delay + Threshold (Note)
Network model Average delay (s)
(x%) (s)
Model A Scenario 1 1400 800 + 1700 (95%)
800 + 800 (50%)
800 + 20 (10%)
800 + 1 (1%)
Scenario 2 For further study For further study
Model B Scenario 1 For further study For further study
NOTE This value is the maximum delay variation for x% of the packets (95%, 50%, 10% and 1% are
the reference values).
NOTE 4 The values are based on a configuration with only 100 Mbit/s links. This provides a conservative
scenario, especially for packets with higher delay variation. Further work is needed in order to confirm and
complete the table.
Details on the test cases that are needed to test the network in non-static or failure conditions are
also provided in Appendix VI.
Different packet rates may be used in order to test different applications and to improve the
performance of the filtering algorithms (this is relevant for adaptive methods, or more, in general,
when the synchronization is carried over packets).
V.2 Other network models

Other network models can be defined based on the considerations provided by this clause.
In particular, this clause emphasizes the compound networks that may support circuit emulation
services, showing that the various network designs may introduce new variables to timing
transmission, performance and test scenarios.
NOTE 1 The TDM pseudowire (TDM PW) terminology is used in other contexts to describe the
transmission of TDM over packet network, and will be used in this clause as a different way to address the
CES aspects.
In particular, the network scenarios presented here show that:
TDM PW may go over a unique domain made of a unique transport technique (Ethernet, IP
or MPLS);
TDM PW may go over a unique domain made of diverse transport techniques;
TDM PW may go over different domains made of unique or diverse transport techniques;
TDM PW crossing different domains or transport techniques may imply modifying the IWF
packet layers (e.g., IP to MPLS).
For TDM PW timing using adaptive clock recovery model, the diversity of equipment, policy
(e.g., QoS) and transmission methods may impact the recovered timing quality.
The examples given in this clause are the most common, that are expected to be deployed.
However, these do not intend to cover any possible scenarios, such as when using traffic
engineering tunnelling (stacking MPLS labels or [b-IEEE 802.1ah]) or layering (generic framing
procedure (GFP), T-MPLS).
66 Rec. ITU-T G.8261/Y.1361 (08/2013)

Deployed networks are made of different technologies. Considering a TDM PW for instance, a
TDM service set-up between two IWFs may go over multiple transmission technologies and
network domain.
Some examples are provided below.
At access, it may be an Ethernet network made of Ethernet switches only, as described in
Figure V.3.
Figure V.3 Ethernet switches only network

NOTE 2 The scenario shown in this figure can be modelled with the reference models shown in
Figures V.1 and V.2.
It could also be an MPLS network with P devices and IWF at PE (provider edge), as shown in
Figure V.4.
Figure V.4 MPLS PE/P only network
It could also be an IP network with IP routers and IWF in routers as shown in Figure V.5.
Figure V.5 IP routers only network

NOTE 3 The network characteristics in terms of packet delay variation of the scenarios shown in
Figures V.4 and V.5 (except when a software-based forwarder is used) can be based on the results from the
models shown in Figures V.1 and V.2.
However, current networks are often more complex; they may consist of different transport
technologies even within one domain or operator. A TDM PW may also cross different domains.
Five examples are given below.
1) TDM MPLS PW crossing 3rd party MPLS carrier (Figure V.6)
Figure V.6 MPLS network over MPLS network
Rec. ITU-T G.8261/Y.1361 (08/2013) 67

2) TDM MPLS PW terminated on distinct carrier IWF devices (Figure V.7)
Figure V.7 Crossing distinct MPLS networks or domains

NOTE 4 Such a scenario may also depict a change in transport layer as shown in Figure V.8, where the
TDM PW moves from MPLS to IP. In this case, the TDM packet encapsulation payload is not changed; only
the PSN layer changes.
Figure V.8 Swapping the PSN layers

NOTE 5 It may be possible that the TDM stream may have to be recovered at an interconnect point
between two domains or operators, either because the previous scenario is not possible (different TDM PW
encapsulations), or because operators do not agree on the interconnection method (can be with respect to
location or management of the switching node, the encapsulation or control plane). This is shown in
Figure V.9.
Figure V.9 Crossing distinct operator networks with no PW switching function

3) TDM IP PW using MPLS network, optionally using a L3VPN service (Figure V.10)
Figure V.10 IP over MPLS network

4) TDM Ethernet PW using MPLS network for transmission (Figure V.11)
Figure V.11 Ethernet over MPLS or IP network
68 Rec. ITU-T G.8261/Y.1361 (08/2013)

5) TDM IP PW using Ethernet PW service over MPLS network (Figure V.12).
Figure V.12 IP over Ethernet over MPLS network
Some key aspects of such compound networks include:

network equipments will have different characteristics;
network policy (e.g., QoS) may be different if crossing different domains;
timing architecture may be different.
Rec. ITU-T G.8261/Y.1361 (08/2013) 69

Appendix VI
Measurement guidelines for packet-based methods

The guidelines in this appendix are intended to assist in the acquisition of performance
characteristics used to establish benchmarking results.
It is important to consider that, when doing performance comparisons, the configurations of the
systems being compared be as similar as possible.
Results from the test cases provided in this appendix provide no guarantee that equipment will
perform as expected in a complex network situation under a range of complex and changing load
conditions.
Although test cases in this appendix provide a useful guidance on the performance of Ethernet-
based circuit emulation techniques, evaluation in complex network scenarios that mimic the
deployment profile is strongly recommended.
VI.1 Measurement reference points

The measurement reference points are provided in Figure VI.1 (differential clock recovery method)
and Figure VI.2 (adaptive clock recovery method). The two figures of this clause provide two of the
most relevant test scenarios. Additional scenarios may be identified in future versions of this
Recommendation.
Reference timing signal (PRC)
Synthesizer
Jitter,
wander,
Packet delay frequency
variation accuracy
Wander noise Wander noise
Test Test
generator generator
equipment equipment
(ITU-T O.172) (ITU-T O.172)
TDM Reference
CE (TDM signal point 1 Packet switched TDM
traffic generator) IWF IWF signal
network Reference Reference
point 2 point 3
G.8261-Y.1361(13)_FVI.1
Figure VI.1 Measurement reference points in the differential clock recovery method
70 Rec. ITU-T G.8261/Y.1361 (08/2013)

Reference timing signal (PRC) (Note)
Jitter,
Packet delay wander,
variation frequency
accuracy
Test Test
equipment equipment
TDM Reference
CE (TDM signal point 1 Packet switched TDM
traffic generator) IWF network Reference IWF Reference signal
point 2 point 3
G.8261-Y.1361(13)_FVI.2
NOTE The reference timing signal (PRC) is used to represent the TDM service clock.
Figure VI.2 Measurement reference points in the adaptive clock recovery method
NOTE 1 The "Wander noise generator" in Figure VI.1 is inserted to simulate the noise generated by the
synchronization network (as specified in [ITU-T O.172]). The output of the wander noise generation should
comply with the synchronization interface as specified in [ITU-T G.824] and [ITU-T G.823].
NOTE 2 The synthesizer in Figure VI.1 is needed to change the frequency of the asynchronous TDM
signals (within the [ITU-T G.703] limits).
NOTE 3 This appendix contains a suite of tests to evaluate the performance of clock recovery under
different kinds of network topologies, traffic characteristics and impairments. However, the tests defined
here are not exhaustive, and do not cover all possible impairments that may be caused by the packet network.
Further tests may be defined in the future, for example:
clock recovery under the presence of link aggregation, such as [IEEE 802.1ad];
clock recovery under the presence of QoS;
clock recovery under the presence of flow control, such as [b-IEEE 802.3x] pause frames.
NOTE 4 Measurement methodologies for the asynchronous signals are provided in Appendix II of
[ITU-T G.823].
VI.2 Input traffic characteristics

To be able to account for different traffic types in the network, two types of disturbance traffic
models are defined as described in clauses VI.2.1 and VI.2.2 below.
The Network Traffic model 1 is intended to model the traffic in the access network where the
majority of the traffic is voice. The Network Traffic model 2 is intended to model the traffic on
networks where the majority of the traffic is data.
It should be noted that the CES traffic is in addition to the disturbance traffic.
NOTE 1 The details on how traffic is injected have to be provided when performing the tests. The details
should cover aspects such as how the traffic is mixed, which Ethernet switches are receiving the traffic, the
packet rate for the CBR flows, etc. As an example for details on how the traffic is mixed, the following
approach could be followed:
the different packet size profiles will appear in a random manner with probability 0.8, 0.15 and 0.05
respectively. The random generation process will be identically independent distributed
(uncorrelated) based on some pseudo-random binary sequence (PRBS) with a minimal period
of 223-1 frames.
Maximum size packets will occur in bursts lasting between 0.1 s and 3 s. For each burst event, the
burst length will be selected randomly using an identically independent uniformly distributed
random generator between 0.1 s to 3 s.
NOTE 1A Different interpretations, on how the traffic bursts are generated in the following network traffic
models, have been proposed. The test result may depend on the specific interpretation that has been adopted.
Rec. ITU-T G.8261/Y.1361 (08/2013) 71

NOTE 2 The traffic can be injected in serial (into one port of the Ethernet switch) or in parallel (into
multiple ports of the Ethernet switch) and, in general, different behaviour is expected. However, similar
statistical properties of the packet delay variation at the output of the packet network have been observed for
the serial and parallel cases when the statistics of the packets with minimum delay were not significantly
impacted by the load conditions. The following are some of the aspects that may impact the statistics of the
packets with minimum delay:
queuing strategy in the switches
number of switches in chain
static vs. non-static load.
The traffic inserted into the packet-switched network in some of the test cases (such as case 2, 3, 13
and 14) may lead to very low frequency variation on the timing information carried by the timing
packets. In this case, in order to attenuate, filter or suppress such low frequency effects the CES
slave, PSC-A or PEC-S may require a low frequency filtering capability.
VI.2.1 Network Traffic model 1
According to 3GPP, the access traffic is composed by conversational (voice), streaming
(audio-video), interactive (e.g., http) and background (sms, e-mail). It is known that in wireless
network 80% to 90% of the traffic is conversational, with the average call lasting from 1 minute to
2 minutes. To be able to model this traffic, 80% of the load should be based on packets of fixed
small-size constant bit rate, and 20% based on packets with a mix of medium and maximum size.
The packet size profile is:
80% of the load must be minimum size packets (64 octets)
15% of the load must be maximum size packets (1518 octets)
5% of the load must be medium size packets (576 octets).
Maximum size packets will occur in bursts lasting between 0.1 s and 3 s.
VI.2.2 Network Traffic model 2
Bigger packets compared with the Network Traffic model 1 compose the networks that handle more
data traffic. To be able to model this traffic, 60% of the load should be based on packets of
maximum size, and 40% on packets with a mix of minimum and medium size.
The packet size profile is:
60% of the load must be maximum size packets (1518 octets)
30% of the load must be minimum size packets (64 octets)
10% of the load must be medium size packets (576 octets).
Maximum size packets will occur in bursts lasting between 0.1 s and 3 s.
NOTE Traffic model 1 is based on the typical traffic characteristics of wireless access networks that are
based on the first generations of mobile technologies (e.g., GSM, WCDMA 3GPP releases up to Rel. 4).
However, there are cases when, in order to optimize the bandwidth usage during the traffic peak hours, the
packets to/from base stations with Ethernet interface can be bundled in packets of larger size resulting in
traffic characteristics pertaining to those of Traffic model 2 instead. In this case, the traffic models
characteristics may change over time.
VI.3 Test topologies for adaptive methods

The testing topologies described herein include methods for testing the synchronization methods
applicable to this Recommendation.
These tests have been defined in a controlled environment (i.e., not in the field).
72 Rec. ITU-T G.8261/Y.1361 (08/2013)

NOTE The test cases presented in this clause address the test of the CES domain. The test of the PNT
domain when adaptive clock recovery methods are used could be done using the same approach. Some
adaptation of the test cases set-up might be needed for this purpose. This is for further study.
VI.3.1 Baseline test
Baseline test topology is shown in Figure VI.3.
Jitter, wander,
frequency
accuracy
Test
equipment
TDM
CE (TDM signal IWF TDM
traffic generator) IWF (DUT) signal
Reference
point 3
DUT Device Under Test G.8261-Y.1361(13)_FVI.3
Figure VI.3 Baseline test topology
The baseline test should be done under the following conditions:

no packet load
test measurements
measure TIE, MTIE, and MRTIE (as described in [ITU-T G.823] and [ITU-T G.824])
measure frequency accuracy (the value for the frequency accuracy measurement
integration-time is dependent upon the relevant end equipment)
performance should meet the network limits for the relevant cases as defined in
clause 9.
VI.3.2 Performance test
The performance test is equivalent to model A in Appendix V, composed with either 10 gigabit
Ethernet switches or 9 gigabit Ethernet (GE) switches and 1 fast Ethernet (FE) switches. The test
topology is shown in Figure VI.4.
Rec. ITU-T G.8261/Y.1361 (08/2013) 73

Jitter,
wander,
variation accuracy
Test Test
equipment equipment
TDM 1 2 3 4 10
CE (TDM signal
traffic ... IWF TDM
IWF
generator) (DUT) Reference signal
GE GE GE GE FE or GE point 3
reference ... reference
point 1 point 2
Traffic generator G.8261-Y.1361(13)_FVI.4
Disturbance load according to traffic models N= 10

Flow of interest GE 1 Gbit/s Ethernet
FE 100 Mbit/s Ethernet
Ethernet switches
Figure VI.4 Performance test topology
A specific test topology shown in Figure VI.5 is needed to perform the test case on traffic
concentration forming bottleneck. This kind of configuration creates the beating effect
(see Figures 20 and 21).
PRC
f0 Reference timing signal
Jitter,
wander,
variation accuracy
TDM Test Test

CE (TDM signal equipment equipment
Frequency traffic
synthetizer IWF #1
generator)
f1
... ... ... FE IWF TDM
GE FE (DUT) Reference signal
TDM reference point 3
CE (TDM signal point 2
Frequency FE
traffic IWF #m
synthetizer Traffic generator
generator)
fm G.8261-Y.1361(13)_FVI.5
Reference timing signal m= 3

Disturbance load according to traffic models GE 1 Gbit/s Ethernet
Flows of interest FE 100 Mbit/s Ethernet
Ethernet switches
Figure VI.5 Performance test topology for traffic concentration test case
The device under test (DUT) must be tested for stability of operation under disruptive events that
may cause the synchronization to fail or go out of specification. Test cases described in this clause
are performed to test the DUT under load variation, network changes and packet loss.
74 Rec. ITU-T G.8261/Y.1361 (08/2013)

For each of the test cases described in this clause, the following measurements should be
performed:
measure TIE, MTIE, and MRTIE (as described in [ITU-T G.823] and [ITU-T G.824]);
integration-time is dependent upon the relevant end equipment);
measure packet delay variation;
performance should meet the network limits for the relevant cases as defined in clause 9.
NOTE 1 The test set-up, as described in Figure VI.4, provides the starting point towards a common test
scenario.
However, in order to get a test environment that will be simpler to be implemented and in order to
remove any risk for getting different results when using Ethernet switches of different technologies,
a proposal is under discussion to replace the specification as defined in Figure VI.4 with a new test
set-up, where in place of the Ethernet switches and the traffic generator, the delay variation could be
created by a test equipment with a delay variation profile as input.
This delay variation profile could be expressed in terms of delay variation "test vectors" (test
sequence) of duration 15 min, 60 min, and 24 hours. The delay variation shall be expressed with the
proper timing resolution.
The test sequences would be based on the results from the tests performed using the tests topology
as described in Figure VI.4.
NOTE 2 Deterministic test cases may also be considered in addition to the test cases described in this
clause. This is for further study.
VI.3.2.1 Test Case 1
Test Case 1 models the "static" packet load. Test Case 1 must use the following network conditions:
network disturbance load with 80% for 1 hour. The test measurements should start after the
clock recovery is in a stable condition. Guidance on stabilization period is provided in
Appendix II. The disturbance background traffic to load the network must use network
Traffic model 2 as defined in clause VI.2.2.
Test Case 2 models sudden large and persistent changes in network load. It demonstrates stability
on sudden large changes in network conditions, and wander performance in the presence of low
frequency PDV.
Test Case 2 must use the following network conditions:
the packets to load the network must use Network Traffic model 1 as defined in
clause VI.2.1.
allow a stabilization period according to Appendix II for the clock recovery process to
stabilize before doing the measurements.
start with network disturbance load at 80% for 1 hour, drop to 20% for 1 hour, increase
back to 80% for 1 hour, drop back to 20% for 1 hour, increase back to 80% for 1 hour, drop
back to 20% for 1 hour (see Figure VI.6).
Rec. ITU-T G.8261/Y.1361 (08/2013) 75

100
80
Network 60
load, %
40
20
0
0 1 2 3 4 5 6
Time, hours G.8261-Y.1361(13)_FVI.6
Figure VI.6 Sudden network disturbance load modulation

repeat the test using the Network Traffic model 2 as defined in clause VI.2.2 to load the
network.
Test Case 3 models the slow change in network load over an extremely long timescale. It
demonstrates stability with very slow changes in network conditions, and wander performance in
the presence of extremely low frequency PDV.
clause VI.2.1.
vary network disturbance load smoothly from 20% to 80% and back over a 24-hour period
(see Figure VI.7).
80
1% increments,
Network 12 minutes per step
load, %
30
20
0
0 2 12 24
Time, hours G.8261-Y.1361(13)_FVI.7
Figure VI.7 Slow network load modulation

network.
Test Case 4 models temporary network outages and restoration for varying amounts of time. It
demonstrates ability to survive network outages and recover on restoration. It should be noted that
MTIE over the 1000 s interruption will largely be governed by the quality of the local oscillator,
and should not be taken as indicative of the quality of the clock recovery process.
76 Rec. ITU-T G.8261/Y.1361 (08/2013)

clause VI.2.1.
start with 40% of network disturbance load. After a stabilization period according to
Appendix II, remove network connection for 10 s, then restore. Allow a stabilization period
according to Appendix II for the clock recovery process to stabilize. Repeat with network
interruptions of 100 s.
repeat the test using Network Traffic model 2 as defined in clause VI.2.2 to load the
network.
Test Case 5 models temporary network congestion and restoration for varying amounts of time. It
demonstrates the ability to survive temporary congestion in the packet network.
clause VI.2.1.
Appendix II, increase network disturbance load to 100%, (inducing severe delays and
packet loss) for 10 s, then restore. Allow a stabilization period according to Appendix II for
the clock recovery process to stabilize. Repeat with a congestion period of 100 s.
network.
Test Case 6 models routing changes caused by failures in the network.
change the number of switches between the DUTs, causing a step change in packet network
delay.
clause VI.2.1.
Appendix II, re-route the traffic to bypass one switch in the traffic path. This shall be
done by updating the test set-up in Figure VI.4 adding a cable from switch in position
"n" to switch in position "n+2", and either using a fibre spool or adding an impairment
box able to simulate different cable lengths (10 s and 200 s can be simulated as
typical examples). The configuration shall be done so that the traffic flow under test is
routed directly from switch in position "n" via the new link to switch in position "n+2".
After disconnecting the cable from switch "n" to switch "n+2" (so that traffic under test
will then be routed from switch in position "n" to switch in position "n+1"), allow a
stabilization period according to Appendix II for the clock recovery process to stabilize,
and then reconnect the link that was disconnected in order to restore the traffic on the
original path.
Appendix II, re-route the traffic to bypass three switches in the traffic path. This shall
be done by updating the test set-up in Figure VI.4 adding a cable from switch in
position "n" to switch in position "n+4", and either using a fibre spool or adding an
impairment box able to simulate different cable lengths (10 s and 200 s can be
simulated as typical examples). The configuration shall be done so that the traffic flow
Rec. ITU-T G.8261/Y.1361 (08/2013) 77

under test is routed directly from switch in position "n" via the new link to switch in
position "n+4".
After disconnecting the cable from switch "n" to switch "n+4" (so that traffic under test
will then be routed from switch in position "n" to switch in position "n+1"), allow a
stabilization period according to Appendix II for the clock recovery process to stabilize,
and then reconnect the link that was disconnected in order to restore the traffic on the
original path.
network.
Test Case 7 models the beating effect due to traffic concentration with TDM sources of different
frequency. In particular, this test case is referring to CES TDM flows associated with a 2048 Mbit/s
or 1544 Mbit/s bitstream. The test set-up is shown in Figure VI.5 and must use the following
network conditions:
network disturbance load with 60% for the entire test period. The test measurements should
start after the clock recovery is in a stable condition and should run over 24 hours.
Guidance on stabilization period is provided in Appendix II. The disturbance background
traffic to load the network must use Network Traffic model 2 as defined in clause VI.2.2.
apply the following frequencies with the frequency synthesizers to test the case of
asynchronous services:
f1 = f0
f2 = f0 + 1 ppm
f3 = f0 50 ppm (2048 kbit/s signals) or f0 32 ppm (1544 kbit/s signals)
at the output of the IWF on the right (reference point 3), select the TDM output signal sent
by IWF #0 for measurement of the applicable jitter and wander limits and the TDM output
signal sent by IWF #3 for measurement of the asynchronous service clock.
run the test again with the following frequencies to test the case of clocks in holdover
mixed with asynchronous services:
f1 = f0
f2 = f0 + 16 ppb
f3 = f0 50 ppm (2048 kbit/s signals) or f0 32 ppm (1544 kbit/s signals)
NOTE 1 Packet size must be the same for all CES packet streams.
NOTE 2 The same test scenario can be also used to test different CES TDM bitstreams (e.g., DS3 CES).
NOTE 3 Other test cases based on this test case (e.g., non-static tests where the frequency offset drifts over
time) are for further study.
Test Case 8 models a topology-dependent mechanism in packet networks that can delay packets by
more than would be expected from volume-of-traffic considerations alone (see clause 10.1.2.6).
The test network is as given in clause VI.3.2, Figure VI.4, with the following change: there is just
one source of "disturbance traffic", which is injected at switch 1, and traverses the entire network
exiting at switch 10 on a separate port to the time-sensitive traffic.
78 Rec. ITU-T G.8261/Y.1361 (08/2013)

test Case part A
This test case is similar to Test Case 3 (clause VI.3.2.3). It tests for gradual increases and
decreases in traffic load in the presence of the blocking effect as described in
clause 10.1.2.6. It is not thought necessary to go to the same extremely low frequency, and
hence long test runs as Test Case 3 in order to demonstrate resilience to this particular
effect.
Using network traffic model 2, start with 0% disturbance traffic load. Allow an initial
stabilization period, according to Appendix II. Then increase the traffic load in 1%
increments every minute up to 50% load. Reduce the load again in 1% increments back
down to 0%.
test Case part B
This test case is similar to Test Case 2 (clause VI.3.2.2). It tests for sudden increases and
decreases in traffic load in the presence of the blocking effect as described in
clause 10.1.2.6.
Using network traffic model 2, start with 0% disturbance traffic load. Allow an initial
stabilization period, according to Appendix II. Then increase the traffic load up to 50% for
1 hour. Repeat three times.
VI.4 Test Topologies for differential methods

The test topology is shown in Figure VI.8.
Reference timing signal (PRC)
Synthesizer
Wander noise
generator
(ITU-T O.171) Jitter,
wander,
variation accuracy
Wander noise
generator
(ITU-T O.171) Test Test
equipment equipment
...
TDM 1 2 3 GE 4 10
CE (TDM signal
... IWF TDM
traffic IWF
generator) (DUT) Reference signal
GE GE GE GE FE or GE point 3
reference reference
...
point 1 point 2
Traffic generator
G.8261-Y.1361(13)_FVI.8
Disturbance load according to traffic models GE 1 Gbit/s Ethernet

Ethernet switches
Figure VI.8 Performance test topology for differential clock recovery method
NOTE The frequency offset from the PRC introduced by the synthesizer should be + (or ) 50 ppm
(2048 kbit/s) and + (or ) 32 ppm (1544 kbit/s) for all the test cases.
Rec. ITU-T G.8261/Y.1361 (08/2013) 79

VI.4.1 Test Case 9
Test Case 9 models the performance of the differential clock recovery method under the "static"
packet load. Test Case 9 must use the following network conditions:
network disturbance load with 80% for 1 hour. The test measurements should start after the
clock recovery is in a stable condition. Guidance on stabilization period is provided in
Appendix II. The disturbance background traffic to load the network must use Network
VI.4.2 Test Case 10
Test Case 10 models the performance of the differential clock recovery method with noise added
into the reference timing signal into the IWF. It is used to simulate the noise generated by the
Synchronization Network (as specified in [ITU-T O.172]).
inject wander noise according to Annex C of [ITU-T O.172] to simulate the wander noise
generated by the synchronization network. The actual values for the wander noise depend
on the application (e.g., E1, DS1). The applicable wander noise masks are for further study.
network disturbance load with 80% for 1 hour assuming that the clock recovery is in a
stable condition. Allow a stabilization period according to Appendix II for the clock
recovery process to stabilize before doing the measurements. The packets to load the
network must use Network Traffic model 2 as defined in clause VI.2.2.
VI.4.3 Test Case 11
Test Case 11 models the performance of the differential clock recovery method with temporary
network congestion and restoration for varying amounts of time. It demonstrates the ability to
survive temporary congestion in the packet network.
clause VI.2.1.
Appendix II, increase network disturbance load to 100% (inducing severe delays and packet
loss) for 10 s, then restore. Allow a stabilization period according to Appendix II for the
clock recovery process to stabilize. Repeat with a congestion period of 100 s.
NOTE For the differential method, the following test cases have also been identified as relevant: Holdover
(reference timing signal loss); different QoS cases. These are for further study.
VI.5 Test for two-way protocols

The testing topologies described herein include methods for testing two-way synchronization
methods (e.g., time distribution protocols) applicable to this Recommendation.
These tests have been defined in a controlled environment (i.e., not in the field).
VI.5.1 Baseline test
Baseline test topology is shown in Figure VI.9.
80 Rec. ITU-T G.8261/Y.1361 (08/2013)

Reference timing signal (PRC/UTC)
Jitter, wander,
Packet delay frequency and
variation time accuracy
Test Test
equipment equipment
PEC
PEC client Clock
server (DUT) Reference
point 3
G.8261-Y.1361(13)_FVI.9
Flow of interest - forward direction
Flow of interest - reverse direction
Figure VI.9 Two-way baseline test topology
The baseline test should be done under the following conditions:

no packet load
test measurements:
measure peak-to-peak TOD accuracy;
performance should meet the network limits for the relevant cases as defined in
clause 9.
VI.5.2 Performance test
The performance test is equivalent to model A in Appendix V, composed with either 10 GE
switches or 9 GE switches and 1 FE switches. The test topology is shown in Figure VI.10.
Rec. ITU-T G.8261/Y.1361 (08/2013) 81

Jitter, wander,
Reverse channel traffic generator Test Test

equipment equipment
1 2 3 10
PEC
PEC client
server Clock
(DUT) Reference
GE GE GE GE ... GE FE or GE point 3
G.8261-Y.1361(13)_FVI.10
point 1 point 2
Forward channel traffic generator
Disturbance load according to traffic models - forward direction GE 1 Gbit/s Ethernet

Disturbance load according to traffic models - reverse direction FE 100 Mbit/s Ethernet
Ethernet switches
Figure VI.10 Performance test topology for testing two-way protocols
The DUT must be tested for stability of operation under disruptive events that may cause the
synchronization to fail or go out of specification. Test cases in this clause are performed to test the
DUT under load variation, network changes and packet loss.
For each of the test cases described in this clause, the following measurements should be
performed:
measure packet delay variation;
measure peak-to-peak TOD accuracy;
performance should meet the network limits for the relevant cases as defined in clause 9.
NOTE 1 The test set-up, as described in Figure VI.10, provides the starting point towards a common test
scenario.
However, in order to get a test environment that will be simpler to be implemented, and in order to
remove any risk for getting different results when using Ethernet switches of different technologies,
a proposal is under discussion to replace the specification as defined in Figure VI.10, with a new
test set-up where in place of the Ethernet switches and the traffic generator, the delay variation
could be created by a test equipment with a delay variation profile as input.
This delay variation profile could be expressed in terms of delay variation "test vectors" (test
sequence) of duration 15 min, 60 min, and 24 hours. The delay variation shall be expressed with the
proper timing resolution.
The test sequences would be based on the results from the tests performed using the tests topology
as described in Figure VI.10.
NOTE 2 Deterministic test cases may also be considered in addition to the test cases described in this
clause. These are for further study.
82 Rec. ITU-T G.8261/Y.1361 (08/2013)

VI.5.2.1 Input traffic characteristics
The same Traffic Models 1 and 2 defined in clauses VI.2.1 and VI.2.2 will be reused here for the
two-way test cases.
NOTE The definition of specific conditions to test for asymmetry is for further study. A simple test set-up
could also consider constant delay in one direction.
Test Case 12 models the "static" packet load. Test Case 12 must use the following network
conditions:
network disturbance load with 80% for the forward direction (Server to Client) and 20% in
the reverse direction (Client to Server) for 1 hour. The test measurements should start after
the clock recovery is in a stable condition. Guidance on stabilization period is provided in
Appendix II. The disturbance background traffic to load the network must use Network
Test Case 13 models sudden large, and persistent, changes in network load. It demonstrates stability
on sudden large changes in network conditions, and wander performance in the presence of low
frequency PDV.
clause VI.2.1.
in the forward direction: Start with network disturbance load at 80% for 1 hour, drop to
20% for 1 hour, increase back to 80% for 1 hour, drop back to 20% for 1 hour, increase
back to 80% for 1 hour, drop back to 20% for 1 hour. Simultaneously, in the reverse
direction: Start with network disturbance load at 50% for 1.5 hours, drop to 10% for 1 hour,
increase back to 50% for 1 hour, drop back to 10% for 1 hour, increase back to 50% for
1 hour, drop back to 10% for 0.5 hour (see Figure VI.11).
Rec. ITU-T G.8261/Y.1361 (08/2013) 83

Figure VI.11 Sudden network disturbance load modulation for 2-way
network.
NOTE The traffic generators in the test set-up are independent, because of this the shape of the traffic
shown in Figure VI.11 may drift over time.
Test Case 14 models the slow change in network load over an extremely long timescale. It
demonstrates stability with very slow changes in network conditions, and wander performance in
the presence of extremely low frequency PDV.
clause VI.2.1.
in the forward direction: Vary network disturbance load smoothly from 20% to 80% and
back over a 24-hour period. Simultaneously, in the reverse direction: Vary network
disturbance load smoothly from 10% to 55% and back over a 24-hour period
(see Figure VI.12).
84 Rec. ITU-T G.8261/Y.1361 (08/2013)

Figure VI.12 Slow network load modulation for two-way
network.
Test Case 15 models temporary network outages and restoration for varying amounts of time. It
demonstrates the ability to survive network outages and recover on restoration. It should be noted
that MTIE over the 1000 s interruption will largely be governed by the quality of the local
oscillator, and should not be taken as indicative of the quality of the clock recovery process.
clause VI.2.1.
start with 40% of network disturbance load in the forward direction and 30% load in the
reverse direction. After a stabilization period according to Appendix II, remove network
connection for 10 s, then restore. Allow a stabilization period according to Appendix II for
the clock recovery process to stabilize. Repeat with network interruptions of 100 s.
network.
Test Case 16 models temporary network congestion and restoration for varying amounts of time. It
demonstrates the ability to survive temporary congestion in the packet network.
clause VI.2.1.
start with 40% of network disturbance load in the forward direction and 30% load in the
reverse direction. After a stabilization period according to Appendix II, increase network
disturbance load to 100% in both directions (inducing severe delays and packet loss) for
10 s, then restore. Allow a stabilization period according to Appendix II for the clock
recovery process to stabilize. Repeat with a congestion period of 100 s.
Rec. ITU-T G.8261/Y.1361 (08/2013) 85

network.
Test Case 17 models routing changes caused by failures in the network.
change the number of switches between the DUTs, causing a step change in packet network
delay. The packets to load the network must use Network Traffic model 1 as defined in
clause VI.2.1:
update the test set-up in Figure VI.10 adding a cable from switch in position "n" to
switch in position "n+2" (Figure VI.13 shows an example where n=1 and switch 2 is
bypassed). In this way, the traffic is re-routed (in both directions) to bypass one switch
in the traffic path. This shall be done using either a fibre spool or adding an impairment
box able to simulate different cable lengths (10 s and 200 s can be simulated as
typical examples). The configuration shall be done so that the traffic flow under test is
routed directly from switch in position "n" via the new link to switch in position "n+2".
start with 40% of network disturbance load in the forward direction and 30% load in
the reverse direction.
after a stabilization period according to Appendix II, disconnect the cable from switch
"n" to switch "n+2", so that traffic under test will then be forced to go through switch in
position "n+1" (Figure VI.14 shows an example where n=1, the cable from switch 1 to
switch 3 is removed, and the connection to switch 2 is restored in order for the traffic to
go through switch 2).
stabilize, and then reconnect the link that was disconnected in order to restore the
traffic on the original path.
repeat the test in order to create a larger phase step:
update the test set-up in Figure VI.10 adding a cable from switch in position "n" to
switch in position "n+4". In this way the traffic is re-routed (in both directions) to
bypass three switches in the traffic path. This shall be done either using a fibre spool or
adding an impairment box able to simulate different cable lengths (10 s and 200 s
can be simulated as typical examples). The configuration shall be done so that the
traffic flow under test is routed directly from switch in position "n" via the new link to
switch in position "n+4".
apply 40% of network disturbance load in the forward direction and 30% load in the
reverse direction.
after a stabilization period according to Appendix II, disconnect the cable from switch
"n" to switch "n+4" (so that traffic under test will then be forced to go through switch
in position "n+1").
stabilize, and then reconnect the link that was disconnected in order to restore the
traffic on the original path.
86 Rec. ITU-T G.8261/Y.1361 (08/2013)

network.
Jitter, wander,

equipment equipment
1 GE 2 3 10
PEC
PEC client
server Clock
GE GE (DUT) Reference
GE GE ... GE FE or GE point 3
G.8261-Y.1361(13)_FVI.13
point 1 point 2

Ethernet switches
Figure VI.13 Details of Test Case 17

Jitter, wander,

equipment equipment
1 2 3 10
PEC
PEC client
server Clock
(DUT) Reference
GE GE GE GE ... GE FE or GE point 3
point 1 point 2 G.8261-Y.1361(13)_FVI.14

Ethernet switches
Figure VI.14 Details of Test Case 17
Rec. ITU-T G.8261/Y.1361 (08/2013) 87

Appendix VII
Wander limits in Deployment Case 1

VII.1 Limits for the 2048 kbit/s interface

Table 1 has been calculated based on the following considerations with reference to Annex A in
[ITU-T G.823].
The wander budget can be split into three main components:
diurnal wander
asynchronous mapping of 2048 kbit/s
wander caused by clock noise and transients.
Diurnal wander
There is no reason to change it, and its amplitude is small: 1 s.
Asynchronous mapping of 2048 kbit/s
A root mean square (RMS) law has been used to calculate the accumulation of the 2UI per island,
three island will accumulate 3 * 2UI, i.e., 1.7 s, instead of 2 s in the original network model.
Wander caused by clock noise and transients
According to clause I.1.5 of [ITU-T G.823], the accumulation process may be different, depending
on the magnitude of frequency offset, which may result in correlated or uncorrelated effects. It has
been agreed an RMS noise accumulation. This means that each of the four islands is responsible for
half of the wander budget, as currently indicated in this Recommendation. In the new network
model, the three SDH islands are responsible for 3 of one SDH island budget according to the
RMS accumulation law.
The total amount of wander allocated by [ITU-T G.823] is 15 s, and simulations reported 12.6 s.
The accumulation law between SDH and CES is different from that between SDH islands.
The noise generated in the SDH island is the result of VC-12 pointer events, which are infrequent,
at least for a frequency offset in the range of 109 to 1010, as stated in clause I.1.5 of
[ITU-T G.823]; this results in a very low probability that pointers occur at the same time in several
islands.
As for the noise in a CES island, it looks very different from the one observed in SDH islands. This
noise results from PDV.
As it has not been demonstrated that the RMS accumulation law applies between CES and SDH
islands, it is proposed that the new model is assumed to have an RMS accumulation law for the
three SDH island and a linear accumulation for the CES.
Thus, the wander budget that can be allocated to CES would be:
18 (1(diurnal wander) + 3 * 2UI(3 VC-12 mapping) + 12.6/2 * 3(3 SDH islands)) = 4.3 s
A wander of 4.3 s is then allocated to the CES for a period of 24 hours, and the wander template is
reduced by a factor of 4.3/18 (0.24), for the other plateau derived from Table 2 of [ITU-T G.823].
88 Rec. ITU-T G.8261/Y.1361 (08/2013)

VII.2 Limits for the 1544 kbit/s interface
The wander reference model and budget for 1544 kbit/s is specified in [ITU-T G.824] and consists
of eight SDH islands. The wander budget components include switch synchronization, DS1 to DS3
mapping, DS1 to VC-11 mapping, diurnal wander (temperature effects on fibre), NE
synchronization noise and wander due to random pointers. The total budget of 18 microseconds
(over 24 hours) allows 14.3 microseconds of wander between switches (refer to Figure A.1 of
[ITU-T G.824]), and this has been subdivided to accommodate the replacement of one SDH island
with a CES island. The procedure followed assumes that accumulation of mapping wander,
synchronization noise and wander due to pointers is based on RMS addition. Based on RMS
addition, the portion of the 18 microseconds available (i.e., 12.7, see Table VII.1) to each of eight
islands is now 4.5 microseconds (12.7/sqrt(8)).
Table VII.1 1544 kbit/s wander budget component allocation

Budget component Allocation Portion available for subdividing
Switch Synchronization 3.7
E11-E31 mapping 0.3
E11 to VC-11 mapping 2.6 2.6
Diurnal wander (Temp) 1.3
NE sync noise/pointers 10.1 10.1
Total 18.0 12.7
The resulting wander for each island in terms of MTIE over all observation times up to 24 hours is
given in Table 2. This table is based on a uniform reduction of the interface specification in Table 2
of [ITU-T G.824]. Note that this table also considers the mapping jitter requirements for a single
VC-11 island, 0.7 UIpp as specified in [b-ITU-T G.783], (see Table 15-3 of [b-ITU-T G.783]).
The wander accumulation studies that were performed to derive the SDH wander components were
based on extensive simulations to verify that the 18-microsecond requirement could be met over the
SDH reference model. Future simulation work may be required when the CES network models and
mappings are specified in greater detail. These numbers may be revised based on the results of that
work.
Rec. ITU-T G.8261/Y.1361 (08/2013) 89

Appendix VIII
Synchronization status messaging in synchronous Ethernet PHY

Details on SSM for synchronous Ethernet are defined in [ITU-T G.8264].
90 Rec. ITU-T G.8261/Y.1361 (08/2013)

Appendix IX
IWF examples
Examples of typical IWF applications are provided below.

Figure IX.1 shows the case when the service clock timing is handled via adaptive method and there
is no PNT function implemented (no access to network clock).
Figure IX.1 Adaptive method in the CES IWF: no PNT functions
The following figures present an example of the service and network domains in case of the TDM
clock recovery according to the differential method where the common reference is distributed via
Rec. ITU-T G.8261/Y.1361 (08/2013) 91

PRC
EEC EEC
EEC
TDM TDM
IWF IWF
Packet network
Rx Tx
G.8261-Y.1361(13)_FIX.2
Network clock timing flow
Timing messages supporting the differential method
Figure IX.2 Example of differential method using common reference

distributed over synchronous Ethernet
Figure IX.3 Service and network clock domain in the IWF at the transmitting side (Tx)
Figure IX.4 Service and network clock domain in the IWF at the receiving side (Rx)
The next example shows the network timing carried by the TDM network. This timing is then used
to support the differential operation in the CES IWF, and also to synchronize the PEC in order to
generate the time stamps to be delivered over the packet network.
92 Rec. ITU-T G.8261/Y.1361 (08/2013)

Figure IX.5 Differential method in the CES IWF: EEC and PEC in the PNT
Rec. ITU-T G.8261/Y.1361 (08/2013) 93

Appendix X
Considerations on measurement of synchronous Ethernet according to

ITU-T methodologies in comparison with IEEE jitter measurements
The specifications and test methodologies for jitter on Ethernet differ from those for SDH because
different timing methods are used. In synchronous systems such as SDH, the system components
are synchronized to a common clock. In asynchronous systems such as Ethernet, component timing
is provided either by distributed clocks or by clock signals recovered from the data. In this case, the
jitter generated by components must be limited, but the jitter transferred from one component to
another is less important than for synchronous systems where jitter can increase from component to
component.
In SDH systems, three relevant measurements in different test configurations define jitter
performance: band-limited jitter generation, sinusoidal jitter input tolerance, and jitter transfer.
Ethernet uses the approach that there are essentially two mechanisms that cause jitter, namely
deterministic jitter and random jitter. Separate requirements are specified for transmitters and
receivers.
Table X.1 Comparison between ITU-T and IEEE jitter measurements

SDH Ethernet
Network standard [b-ITU-T G.783], [ITU-T G.825] [IEEE 802.3]
Test equipment standard [ITU-T O.172]
Jitter applications Jitter generation (Note 1)
Jitter input tolerance (Note 2)
Jitter transfer
NOTE 1 There are three viable methodologies for measuring jitter output:
1) time domain measurement using an oscilloscope to characterize the data eye.
2) time domain measurement using BERT scan by moving of the data sampling point within the data eye.
3) time interval analysis based on accurate measurement of the time interval between threshold crossings
of the transmitter waveform.
NOTE 2 A stressed receiver sensitivity (SRS) test is performed on receivers. The test is designed to
verify that a receiver can operate at a BER of better than 1012 when receiving the worst-case permitted
signal. This test is analogous to jitter tolerance. The SRS test is also called a "stressed eye test" or
"receiver tolerance test". A SRS test consists of two parts: an eye mask with combinations of impairments
and a sinusoidal jitter template used for step-through measurements.
94 Rec. ITU-T G.8261/Y.1361 (08/2013)

Appendix XI
Relationship between requirements contained in this Recommendation

and other key synchronization related Recommendations
ITU-T has approved the following family of Recommendations (G-series), which describe several
aspects of synchronization functions for TDM:
ITU-T G.803 Architecture of transport networks based on the synchronous digital
hierarchy (SDH) This Recommendation describes the functional architecture of transport
networks, including network synchronization principles for networks that are based on the
SDH.
ITU-T G.810 Definitions and terminology for synchronization networks This
Recommendation provides definitions and abbreviations used in timing and
synchronization Recommendations.
ITU-T G.823 The control of jitter and wander within digital networks which are based on
the 2048 kbit/s hierarchy This Recommendation specifies the maximum network limits of
jitter and wander that shall not be exceeded, and the minimum equipment tolerance to jitter
and wander that shall be provided at any relevant transport or synchronization interfaces
which are based on the 2048 kbit/s hierarchy.
the 1544 kbit/s hierarchy This Recommendation specifies the maximum network limits of
jitter and wander that shall not be exceeded at relevant transport or synchronization network
interfaces, and the minimum equipment tolerance to jitter and wander that shall be provided
at any relevant synchronization or transport interface.
the synchronous digital hierarchy (SDH) This Recommendation specifies the maximum
network limits of jitter and wander that shall not be exceeded, and the minimum equipment
tolerance to jitter and wander that shall be provided at any relevant transport or
synchronization interfaces which are based on the synchronous digital hierarchy (SDH).
ITU-T G.812 Timing requirements of slave clocks suitable for use as node clocks in
synchronization networks This Recommendation outlines minimum requirements for
timing devices used as node clocks in synchronization networks. This Recommendation
includes specifications for three types of clocks in the main body and three other clocks in
Annex A.
ITU-T G.813 Timing characteristics of SDH equipment slave clocks (SEC) This
Recommendation outlines minimum requirements for timing devices, used in
synchronizing network equipment, that operate according to the principles governed by the
synchronous digital hierarchy (SDH).
ITU-T G.781 Synchronization layer functions This Recommendation defines the atomic
functions that are part of the 2 synchronization layers, the synchronization distribution (SD)
layer and the network synchronization (NS) layer. It also defines some atomic functions,
part of the transport layer, which are related with synchronization.
ITU-T G.783 Characteristics of synchronous digital hierarchy (SDH) equipment
functional blocks This Recommendation specifies both the components and the
methodology that should be used in order to specify SDH functionality of network
elements.
Rec. ITU-T G.8261/Y.1361 (08/2013) 95

ITU-T has been working on the following family of Recommendations (G.826x- and
Y.136x-series), which describe several aspects of frequency synchronization functions for packet
networks:
ITU-T G.8261/Y.1361 Timing and synchronization aspects in packet networks This
Recommendation defines synchronization aspects in packet networks. It specifies the
maximum network limits of jitter and wander that shall not be exceeded. It specifies the
minimum equipment tolerance to jitter and wander that shall be provided at the boundary of
these packet networks at TDM and synchronization interfaces. It also outlines the minimum
requirements for the synchronization function of network elements.
ITU-T G.8261.1/Y.1361 Packet delay variation network limits applicable to packet-based
methods (Frequency synchronization) This Recommendation is related to synchronization
aspects in packet networks. In particular it specifies the hypothetical reference model and
the PDV network limits applicable when frequency synchronization is carried via packets
and is recovered according to adaptive clock recovery method as defined in
Recommendations ITU-T G.8261 and [ITU-T G.8260]. It specifies the minimum
equipment tolerance to packet delay variation in terms of the metrics defined in
[ITU-T G.8260] at the boundary of these packet networks.
ITU-T G.8262/Y.1362 Timing characteristics of synchronous Ethernet equipment slave
clock (EEC) This Recommendation outlines the requirements for timing devices used in
synchronizing network equipment that uses synchronous Ethernet.
ITU-T G.8263/Y.1363 Timing characteristics of packet based equipment clocks This
Recommendation outlines requirements for timing devices used in synchronizing network
equipment that operates in the IWF and to other network elements as defined in
Recommendation ITU-T G.8261/Y.1361. This Recommendation defines the requirements
for packet-based clocks.
ITU-T G.8264/Y.1364 Distribution of timing information through packet networks This
Recommendation outlines the requirements on Ethernet networks with respect to frequency
transfer. It specifies the SSM transport channel namely the Ethernet synchronization
messaging channel, protocol behaviour and message format. This Recommendation also
details the required architecture in formal modelling language.
ITU-T G.8265/Y.1365 Architecture and requirements for packet-based frequency
delivery This Recommendation describes the architecture and requirements for packet-
based frequency distribution in telecom networks. Examples of packet-based frequency
distribution include the network time protocol (NTP) and [b-IEEE 1588-2008], briefly
described here. Details necessary to utilize [b-IEEE 1588-2008] in a manner consistent with
the architecture are defined in other Recommendations.
ITU-T G.8265.1/Y.1365.1 Precision time protocol telecom profile for frequency
synchronization This Recommendation contains the ITU-T PTP Profile for frequency
distribution without timing support from the network (unicast mode). It provides the
necessary details to utilize [IEEE 1588-2008] in a manner consistent with the architecture
described in [ITU-T G.8265]. This version of the Recommendation defines the PTP profile
for unicast mode only. Future versions of the Recommendation will contain a separate
profile for a mixed unicast/multicast case.
Table XI.1 shows the relationship between the TDM synchronization Recommendation family and
the packet synchronization Recommendation family.
96 Rec. ITU-T G.8261/Y.1361 (08/2013)

Table XI.1 TDM synchronization Recommendation family versus
the packet synchronization Recommendation family
Requirements TDM network Packet network
Functional architecture and G.803, G.810 G.8261/Y.1361
network synchronization G.823, G.824, G.825 G.8261.1/Y.1361
requirements G.8265/Y.1365
Equipment clock specification G.812 (Type IV), G.813 G.8262/Y.1362
G.8263/Y.1363
Synchronization layer functions, G.783, G.781 G.8264/Y.1364, G.781
functional blocks, timing flow, G.8265.1/Y.1365.1
and SSM. Packet timing protocol
Rec. ITU-T G.8261/Y.1361 (08/2013) 97

Appendix XII
Basic principles of timing over packet networks

XII.1 General
Consider the situation where a slave clock (aka client) derives its timing from a master clock (aka
server). Packet exchanges between master and slave provide measurements of the transit delay and
clock offset between the two. This is explained with respect to Figure XII.1. The principles of
timing over packet networks described here are quite general. These are examples that are
applicable to both one-way and two-way methods. The particular protocol (e.g., [b-IEEE-1588]
or NTP) employed determines the details (method, and underlying conventions), whereby the
measurements ("time-stamps") are communicated between the two entities. It should be noted that
the number of packets transmitted in the two directions need not be equal and, further, there may be
additional packets transmitted that carry information but whose transit delay is not measured.
A fundamental assumption is that packet paths (routes) can be viewed as static over some interval
of time, with fundamental changes occurring infrequently. If the time interval between significant
changes of the transmission path is much larger than the packet exchange interval, the path can be
treated as constant for a given set of measurements. That is, the path taken by the packets is the
same over the measurement interval.
Figure XII.1 Notion of time-stamps in packet exchange between a server and a client
Associated with the packets whose transit time is measured, there are four time-stamps which are
defined as follows:
T1: A time-stamp representing the best estimate of the transmit origination epoch of a packet or
frame originating at the slave clock.
T2: A time-stamp representing the best estimate of the receive termination epoch of packet or
frame terminating at the master clock.
T3: A time-stamp representing the best estimate of the transmit origination epoch of a packet or
frame originating at the master clock.
T4: A time-stamp representing the best estimate of the receive termination epoch of a packet or
frame terminating at the slave clock.
A complete representation of a generic time-stamp value can be constructed as:
TTS (n) = T ( n) + eTS (n) + eCLK (n) (XII-1)
Equation XII-1 reflects the fact that the time-stamp (numerical value) associated with a packet, TTS,
is related to the true time epoch for that packet (T(n)) with two error terms. First, there is the direct
contribution of the local clock error, eCLK. Second, there is the inaccuracy in the time-stamp process,
eTS, which can obscure the behaviour of the clock. The index "n" is included to identify the packet
as being one member of a sequence of packets.
98 Rec. ITU-T G.8261/Y.1361 (08/2013)

With reference to Figure XII.1, the following important timing flow metrics can be defined based
on the time-stamps. These metrics are applicable in both one-way and two-way transfer operations.
First consider the case of one-way (frequency) transfer operation.
One-way transfer is an asymmetrical operation that only requires packet or PDU flow originating in
one direction. For example, consider a timing flow originating at the master clock and terminating
at the slave clock. Of the four time-stamps described in Figure XII.1, only two apply in this mode.
When the master originates the time-stamp flow, convention dictates that the time-stamp pair (T3,
T4) describes the process. The originating time-stamp T3 is with respect to the master view of time
(Master time-scale), while the terminating time-stamp T4 is with respect to the slave time-scale.
The measurement offset, MS, can be calculated as (the subscript "MS" indicates the master-to-slave
direction; "SM" is used for the slave-to-master direction):
MS ( n) = T4 (n) T3 (n) (XII-2a)
where:
T4 (n) = T (n) + MS (n) + e S TS (n) + e S CLK (n) (XII-2b)
where MS(n) is the network delay experienced by the (nth) packet transmitted from the master to
the slave, and:
T3 (n) = T (n) + e M TS (n) + e M CLK (n) (XII-2c)
Thus,
MS (n) = e S CLK (n) e M CLK (n) + MS (n) + e S TS (n) e M TS (n) (XII-2d)
Note that one-way packet transfer between the client clock and server clock is also possible and an
equivalent measurement offset defined for that case. Likewise, the measurement offset, SM, for the
slave-to-master direction, can be calculated as:
SM ( n) = T2 (n) T1 (n) (XII-2e)
and (Equation XII-2f) follows (Equation XII-2d) with the roles of master and slave reversed. SM(n)
is the network delay experienced by the (nth) packet transmitted from the client to the server.
SM (n) = e M CLK (n) e S CLK (n) + SM (n) + e M TS (n) e S TS (n) (XII-2f)
The most important properties of measurement offset are:
1) the measurement offset is biased by the one-way packet delay (). The packet delay cannot
be estimated with a one-way measurement, if the client clock offset is unknown. MS and
SM are estimates of the one-way delay and are rendered imprecise by the clock and time-
stamping errors.
2) by selecting one-way packet transactions with good (stable) delay properties, the
deleterious impact of packet delay bias can be minimized.
3) the residual bias can either be reduced by estimating the one-way delay through some other
means (such as using time-stamps associated with the reverse direction), or ignored in the
case of frequency estimation as frequency offset is simply the rate of change of the phase
offset which is zero for a constant phase bias error.
4) the time-stamping errors at the server and client cannot be eliminated and must be properly
constrained for acceptable operation.
The measurement offset in a one-way packet transfer is analogous to the phase error measurements
obtained with current physical layer one-way synchronization. As such, it is capable of supporting
frequency transfer but not precise time transfer.
Rec. ITU-T G.8261/Y.1361 (08/2013) 99

In contrast to one-way operation, two-way time-stamp operation implies timing packet flow in both
directions. That is, all four time-stamps described in Figure XII.1 are employed. In a two-way
packet time-stamp transaction, the time-stamp flow is initiated by one element (typically the client
in NTP and the server in PTP).
The initiating direction is considered the forward direction, while the return transaction is
considered the reverse direction. However, since each direction can be considered a one-way
transaction, the two-way transaction can be described as follows:
SM (n) = e M CLK (n) e S CLK (n) + SM (n) + e M TS (n) e S TS (n) (XII-3a)
MS (n) = e S CLK (n) e M CLK (n) + MS (n) + e S TS (n) e M TS (n) (XII-3b)

Two key parameters can be estimated from the two-way exchange, namely from SM and MS. For
simplicity, we shall assume for now that the time-stamping errors are negligible. The first key
parameter is termed offset:
offset ( n ) =
MS ( n ) SM ( n ) [ (n) SM (n)]
= e S CLK ( n ) e M CLK ( n ) + MS (XII-4)
2 2
Where offset represents an estimate of the clock correction required to align the client time to the
server time.
The second parameter is round-trip delay (rtd) which represents an estimate of the total round-trip
path delay:
rtd (n) = MS (n) + SM (n) = MS (n) + SM (n) (XII-5)
Obviously, to obtain an unbiased offset estimate, the forward and reverse path delays must either be
known or assumed symmetric. Note that an unbiased estimate of round-trip delay depends on the
clock errors being the same for both directions. Of course, if the time between the two packet
exchanges is low, then the clocks errors can be assumed common to both transactions.
Error in (the estimate of) the client clock, , can be attributed to the following causes:
1) the transit delay in the two directions is not equal. The difference directly affects the client
clock error estimate. The error, , is given by:
1
= ( MS SM ) (XII-6)
2
2) the time-stamp measurements may not be measured precisely. That is, whereas T1 is the
actual time-of-departure of the packet from the server, the value used in the calculation may
be an estimated time-of-departure. Likewise, 2 is meant to be the actual time-of-arrival;
the value used may be an estimate. For the time-stamp values to be accurate, they must be
obtained by means that are as close to the PHY layer as possible and thus the time-of-
departure (time-of-arrival) is not compromised by any (variable) delay attributable to such
entities, as the operating system and interrupt handling. There will still be some residual
errors associated with time-stamp resolution and delay variation in the PHY layer itself.
Time-stamp resolution can be addressed by proper design. PHY noise needs to be either
constrained or filtered depending on the transport.
3) the transit delays MS and SM are not fixed and change from packet to packet because of
the packet delay variation (PDV) associated both with queuing related effects and physical
transport effects in the network.
100 Rec. ITU-T G.8261/Y.1361 (08/2013)

XII.2 Packet delay variation mitigation by packet selection
An important concept is that a clock filter or clock servo operating on the measurement parameters
defined above may select or weight a transaction to optimize overall clock stability. That is, by
suitable classification and selection of packets, the deleterious impact of packet delay variation can
be mitigated.
The assumption that the path is constant over the interval of observation implies a situation where
the packet delay variation will have a distribution function with a slowly changing floor. The floor
is the minimum delay that a packet (or other protocol data unit such as a layer 2 frame) can
experience in a given path. The floor can be viewed as the condition where both output and system
queues (in all equipment that is involved in the flow, including the source, destination, and
intervening elements) are "empty" when the particular packet needs the resource, and thereby do not
delay transmission of the packet. The residual packet delay variation is then associated with
physical layer jitter and wander mechanisms. Under normal non-congested loading conditions, in
many cases, it has been observed that a reasonable fraction of the total number of packets will
traverse the network at or near this floor, even though others may experience significantly longer
delays. This type of behaviour has been addressed in this Recommendation (see Appendix I). In
these cases, the PDV distribution exhibits a high degree of skewness when the network is lightly
loaded. That is, the probability density can be more concentrated near this floor, with a relatively
large fraction of total packets experiencing this "minimum" (or "near-minimum") delay. These
phenomena are under study. A properly designed clock servo or filter can take advantage of the
skewness to mitigate the effects of the instability on the long tail of the PDV distribution.
In principle, floor-based transfer noise is limited by a number of factors such as:
1) physical layer propagation "speed of light" delay;
2) time-stamp resolution;
3) mapping delays over non-Ethernet based physical transport (Ethernet over xDSL, PON,
etc.);
4) other small delay variation mechanisms, such a PHY clock jitter and backplane clock
domain jitter;
5) tilt in the offset of the local clock during the assessment of the floor.
XII.3 Comparison of packet-based and synchronous PHY methods

There are several differences between packet-based methods (e.g., [b-IEEE 1588], NTP) and
synchronous PHY methods such as synchronous Ethernet. Some of these are discussed below.
1) synchronous PHY methods are generally one-way methods and suitable for frequency
alignment. Packet-based methods can be operated in a one-way mode to achieve frequency
alignment and approximate time alignment. Packet-based operation in a two-way mode can
achieve time alignment as well as frequency alignment.
2) since the timing information in synchronous PHY methods is contained in the physical
line-code signal, the information is not dependent on the traffic loading. On the contrary,
packet-based methods are impacted by the traffic patterns, especially if quality-of-service
prioritization schemes are not enforced.
3) synchronous PHY methods are point-to-point. Every intermediate node between PRC and
client clock under consideration must be part of the timing distribution system for timing
chains to be unbroken. Packet-based methods can traverse nodes that are not involved in the
timing distribution.
Rec. ITU-T G.8261/Y.1361 (08/2013) 101

4) the input tolerance of a synchronous PHY clock is expressed in terms of the "clock noise"
in the reference signal and quantified using TDEV and MTIE metrics. The network
impairments that affect the performance of a packet-based clock are packet loss and packet
delay variation (PDV) both from physical layer and queuing delay sources. Suitable metrics
for quantifying packet delay variation from a clock recovery point-of-view are in
development. These include TDEV and minTDEV. MTIE is not a meaningful metric for
quantifying packet delay variation from the viewpoint of clock recovery because not all
packets are necessarily utilized in the recovery algorithms.
XII.4 Existing standards

The published standards for synchronization over packet networks are NTP ([b-IETF RFC 5905],
which obsoletes both [b-IETF RFC 1305] (NTP v3) and [b-IETF RFC 4330] (SNTP)), and
[b-IEEE 1588] (PTP).
NTP and PTP are general protocols for packet networks and do not directly address
telecommunications requirements. Suitable profiles that provide guidelines for deployment in
telecommunications applications are in development.
[ITU-T Y.1731] utilizes time-stamps for establishing some performance criteria in Ethernet
networks. It is instructive to see [ITU-T Y.1731] utilize exactly the 4 time-stamps as described here,
and transports them in operations, administration, and maintenance (OAM) frames between the two
ends of a link.
102 Rec. ITU-T G.8261/Y.1361 (08/2013)

Appendix XIII
Evaluation of the packet delay variation generation in a network node

XIII.1 Introduction
This Appendix provides guidance on the evaluation of the packet delay variation (PDV) generation
in network nodes when using packet based methods without timing support, or with partial timing
support from the network. The type of testing described in this Appendix is applicable to PTP
unaware nodes (i.e., network nodes not supporting boundary clocks or transparent clocks).
PDV noise is relevant to both frequency and phase or time synchronization. Asymmetry is relevant
only to phase or time synchronization, but not to frequency synchronization. This Appendix only
addresses frequency synchronization. The evaluation and analysis related to phase/time
synchronization is for further study and may be defined in a separate Recommendation.
XIII.2 General considerations

The purpose of PDV testing for a single node is to determine the impact of the node on propagation
timing of the timing packets, and therefore, its impact on the packet based timing distribution.
Any feature enabled on equipment like a router or a switch may have an effect on PDV. It is
therefore suggested that a number of configurations may be trialed that represent deployment plans.
For instance, if the equipment is planned to be used as a router, the different packet flows will have
to be routed in the equipment during the tests. If the equipment is planned to be used as a switch,
then the different packet flows will have to be switched during the tests. Mixed scenarios might be
applicable in some cases (e.g., switch/router, where packet timing may be routed and background
traffic switched, or vice versa). Other configurations might be: QoS enabled or not, encapsulation
that is used (e.g., MPLS), accepted customer list.
XIII.3 General configuration

This clause depicts the general configuration to be used when testing the PDV generation of a single
node.
XIII.3.1 General description of the PDV generation tests for a single node
The PDV generation testing for a single node consists in measuring the PDV added to a packet
timing signal (such as [b-IEEE 1588] timing flow) when it is carried over a single network
equipment. The packet timing signal must be ideal at the input of the network equipment (i.e., it
does not have any PDV before entering the node), and the PDV must be measured directly at the
output of the network equipment in order to determine the PDV generated by the node. Stress
conditions are used during the test, for instance background traffic is applied on the network node.
Figure XIII.1 below illustrates the PDV generation testing with a single node. Clause XIII.3 will
detail generic tests that can be applicable.
Stress conditions
(e.g., background traffic)
Ideal packet timing Network Packet timing

signal (no PDV) equipment with PDV noise
G.8261-Y.1361(13)_FXIII.1
Figure XIII.1 General set-up for PDV generation tests for a single node
Rec. ITU-T G.8261/Y.1361 (08/2013) 103

NOTE 1 In order to generate an ideal packet timing signal at the input of the network equipment, a packet
master clock (e.g., PTP master) can be directly connected to the network equipment under stress conditions.
Note that the PDV noise generated by the master has to be very low in order to consider that the input packet
timing signal is free of noise (e.g., negligible compared to the noise measured).
NOTE 2 The PDV of the packet timing signal (e.g., PTP timing flow) can be measured at the output of the
network equipment using a PDV probe in order to determine the PDV generated by the network equipment.
NOTE 3 In order to set up the timing protocol communication (e.g., PTP communication), a packet slave
clock (e.g., PTP slave) can be connected to the network equipment after the PDV probe (note however, that
the purpose is not to measure the performance at the output of the slave, but only the PDV produced by the
equipment).
Details about the different possible configurations (e.g., packet timing flow and background traffic
configuration) and generic tests are for further study.
104 Rec. ITU-T G.8261/Y.1361 (08/2013)

Bibliography
[b-ITU-T G.701] Recommendation ITU-T G.701 (1993), Vocabulary of digital

transmission and multiplexing, and pulse code modulation (PCM) terms.
[b-ITU-T G.707] Recommendation ITU-T G.707/Y.1322 (2000), Network node interface
for the synchronous digital hierarchy (SDH).
[b-ITU-T G.783] Recommendation ITU-T G.783 (2004), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks.
[b-ITU-T G.801] Recommendation ITU-T G.801 (1988), Digital transmission models.
[b-ITU-T G.810] Recommendation ITU-T G.810 (1996), Definitions and terminology for
synchronization networks.
[b-ITU-T G.1020] Recommendation ITU-T G.1020 (2006), Performance parameter
definitions for quality of speech and other voiceband applications
utilizing IP networks.
[b-ITU-T I.363.1] Recommendation ITU-T I.363.1 (1996), B-ISDN ATM Adaptation Layer
specification: Type 1 AAL.
[b-ITU-T T.4] Recommendation ITU-T T.4 (2003), Standardization of Group 3
facsimile terminals for document transmission.
[b-ITU-T V.90] Recommendation ITU-T V.90 (1998), A digital modem and analogue
modem pair for use on the Public Switched Telephone Network (PSTN)
at data signalling rates of up to 56 000 bit/s downstream and up to
33600 bit/s upstream.
[b-ITU-T Y.1560] Recommendation ITU-T Y.1560 (2003), Parameters for TCP connection
performance in the presence of middleboxes.
[b-ETSI TR 101 685] ETSI TR 101 685 (in force), Transmission and Multiplexing (TM);
Timing and synchronization aspects of Asynchronous Transfer Mode
(ATM) networks.
<http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=7595>
[b-ETSI TS 100 594] ETSI TS 100 594 (1999), Digital cellular telecommunications system
(Phase 2+); Base Station Controller Base Transceiver Station
(BSC BTS) interface; Layer 1 Structure of Physical Circuits.
[b-ETSI TS 125 104] ETSI TS 125 104 (in force), Universal Mobile Telecommunications
Systems (UMTS); Base Station (BS) radio transmission and reception
(FDD).
Systems (UMTS); Base Station (BS) radio transmission and reception
(TDD).
Systems (UMTS); Synchronization in UTRAN Stage 2.
Rec. ITU-T G.8261/Y.1361 (08/2013) 105

System (UMTS); UTRAN Iub interface Layer 1.
[b-ETSI TS 145 010] ETSI TS 145 010 (in force), Digital cellular telecommunications systems
(Phase 2+), Radio subsystem synchronization.
[b-IEEE 802.1ah] IEEE 802.1ah-2008, IEEE Standard for local and metropolitan area
network Virtual Bridged Local Area Networks Amendment 7:
Provider Backbone bridges.
<http://www.ieee802.org/1/pages/802.1ah.html>
[b-IEEE 802.1p] IEEE 802.1p-2005, IEEE Standard for Local and Metropolitan Area
Networks: Traffic Class Expediting and Dynamic Multicast Filtering.
[b-IEEE P802.1Qay] IEEE P802.1Qay-REV-2007, Draft Standard for Local and Metropolitan
Area Networks Virtual Bridged Local Area Networks: Amendment
Provider Backbone Bridge Traffic Engineering.
<http://www.ieee802.org/1/pages/802.1ay.html>
[b-IEEE 802.3x] IEEE 802.3x-1997, IEEE Standards for Local and Metropolitan Area
Networks: Supplements to Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications
Specification for 802.3 Full Duplex Operation and Physical Layer
Specification for 100 Mb/s Operation on Two Pairs of Category 3 or
Better Balanced Twisted Pair Cable.
<http://standards.ieee.org/getieee802/802.3.html>
[b-IEEE 1588] IEEE 1588 STD -2008, Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems
<http://ieee1588.nist.gov/>
[b-IETF RFC 1305] IETF RFC 1305 (1992), Network Time Protocol (Version 3)
Specification, Implementation, and Analysis.
[b-IETF RFC 4330] IETF RFC 4330 (2006), Simple Network Time Protocol (SNTP) Version
4 for IPv4, IPv6 and OSI.
[b-IETF RFC 5905] IETF RFC 5905 (2010), Network Time Protocol Version 4: Protocol And
Algorithms Specification.
[b-3GPP2 C.S0010-B] 3GPP2 C.S0010-B (in force), Recommended Minimum Performance
Standards for cdma2000 Spread Spectrum Base Stations.
<http://www.3gpp2.org/Public_html/specs/C.S0010-B_v2.0_021704.pdf>
[b-3GPP2 C.S0002-C] 3GPP2 C.S0002-C (2002), Physical layer standard for cdma2000 Spread
Spectrum Systems.
<http://www.3gpp2.org/Public_html/specs/C.S0002-C_v1.0.pdf>
[b-3GPP TR 25.836] 3GPP TR 25.836 (2001), Node B synchronization for TDD.
<http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_09/Docs/PDFs/RP-000406.pdf>
[b-MEF 3] MEF 3 (2004), Circuit Emulation Service Definitions, Framework and
Requirements in Metro Ethernet Networks.
<http://metroethernetforum.org/Assets/Technical_Specifications/PDF/MEF3.pdf>
106 Rec. ITU-T G.8261/Y.1361 (08/2013)

ITU-T Y-SERIES RECOMMENDATIONS
GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-
GENERATION NETWORKS
GLOBAL INFORMATION INFRASTRUCTURE

General Y.100Y.199
Services, applications and middleware Y.200Y.299
Network aspects Y.300Y.399
Interfaces and protocols Y.400Y.499
Numbering, addressing and naming Y.500Y.599
Operation, administration and maintenance Y.600Y.699
Security Y.700Y.799
Performances Y.800Y.899
INTERNET PROTOCOL ASPECTS
General Y.1000Y.1099
Services and applications Y.1100Y.1199
Architecture, access, network capabilities and resource management Y.1200Y.1299
Transport Y.1300Y.1399
Interworking Y.1400Y.1499
Quality of service and network performance Y.1500Y.1599
Signalling Y.1600Y.1699
Operation, administration and maintenance Y.1700Y.1799
Charging Y.1800Y.1899
IPTV over NGN Y.1900Y.1999
NEXT GENERATION NETWORKS
Frameworks and functional architecture models Y.2000Y.2099
Quality of Service and performance Y.2100Y.2199
Service aspects: Service capabilities and service architecture Y.2200Y.2249
Service aspects: Interoperability of services and networks in NGN Y.2250Y.2299
Enhancements to NGN Y.2300Y.2399
Network management Y.2400Y.2499
Network control architectures and protocols Y.2500Y.2599
Packet-based Networks Y.2600Y.2699
Security Y.2700Y.2799
Generalized mobility Y.2800Y.2899
Carrier grade open environment Y.2900Y.2999
FUTURE NETWORKS Y.3000Y.3499
CLOUD COMPUTING Y.3500Y.3999
For further details, please refer to the list of ITU-T Recommendations.

SERIES OF ITU-T RECOMMENDATIONS
Series A Organization of the work of ITU-T
Series D General tariff principles
Series E Overall network operation, telephone service, service operation and human factors
Series F Non-telephone telecommunication services
Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems
Series I Integrated services digital network
Series J Cable networks and transmission of television, sound programme and other multimedia signals
Series K Protection against interference
Series L Construction, installation and protection of cables and other elements of outside plant
Series M Telecommunication management, including TMN and network maintenance
Series N Maintenance: international sound programme and television transmission circuits
Series O Specifications of measuring equipment
Series P Terminals and subjective and objective assessment methods
Series Q Switching and signalling
Series R Telegraph transmission
Series S Telegraph services terminal equipment
Series T Terminals for telematic services
Series U Telegraph switching
Series V Data communication over the telephone network
Series X Data networks, open system communications and security
Series Y Global information infrastructure, Internet protocol aspects and next-generation

networks
Series Z Languages and general software aspects for telecommunication systems
Printed in Switzerland
Geneva, 2014

T Rec G.8261 201308 I!!pdf e

Uploaded by

Copyright:

Available Formats

T Rec G.8261 201308 I!!pdf e

Uploaded by

Document Information

Original Title

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

T Rec G.8261 201308 I!!pdf e

Uploaded by

Copyright:

Available Formats

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

Timing and synchronization aspects in packet

Recommendation ITU-T G.8261/Y.1361

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100G.199

For further details, please refer to the list of ITU-T Recommendations.

Timing and synchronization aspects in packet networks

Rec. ITU-T G.8261/Y.1361 (08/2013) i

INTELLECTUAL PROPERTY RIGHTS

ii Rec. ITU-T G.8261/Y.1361 (08/2013)

Rec. ITU-T G.8261/Y.1361 (08/2013) iii

iv Rec. ITU-T G.8261/Y.1361 (08/2013)

Rec. ITU-T G.8261/Y.1361 (08/2013) v

Timing and synchronization aspects in packet networks

Rec. ITU-T G.8261/Y.1361 (08/2013) 1

2 Rec. ITU-T G.8261/Y.1361 (08/2013)

3.1 Terms defined elsewhere

Rec. ITU-T G.8261/Y.1361 (08/2013) 3

4 Rec. ITU-T G.8261/Y.1361 (08/2013)

4 Abbreviations and acronyms

Rec. ITU-T G.8261/Y.1361 (08/2013) 5

6 Rec. ITU-T G.8261/Y.1361 (08/2013)

6.1 Packet network synchronization requirements

Rec. ITU-T G.8261/Y.1361 (08/2013) 7

6.2 TDM timing requirements

8 Rec. ITU-T G.8261/Y.1361 (08/2013)

6.4 Timing requirements at edge versus timing requirements in core networks

6.5 PNT domain and CES domain

7 Reference timing signal distribution over packet networks (PNT domain)

Rec. ITU-T G.8261/Y.1361 (08/2013) 9

Figure 1 Distributed PRC and master-slave methods

10 Rec. ITU-T G.8261/Y.1361 (08/2013)

Figure 2 Example of master-slave synchronization network over synchronous Ethernet

7.2 Packet-based methods

Rec. ITU-T G.8261/Y.1361 (08/2013) 11

Time stamp Time stamp

Figure 3 Example of packet-based methods with timing distribution

12 Rec. ITU-T G.8261/Y.1361 (08/2013)

PRC PRC G.8261-Y.1361(13)_F04

Figure 4 Example of network synchronous operation

8.2 Differential methods

PRC PRC G.8261-Y.1361(13)_F05

Figure 5 Example of timing recovery operation based on differential methods

Rec. ITU-T G.8261/Y.1361 (08/2013) 13

8.3 Adaptive methods

TDM service clock G.8261-Y.1361(13)_F06

Figure 6 Example of adaptive method

8.4 Reference clock available at the TDM end systems

14 Rec. ITU-T G.8261/Y.1361 (08/2013)

9.1 CES network limits

Rec. ITU-T G.8261/Y.1361 (08/2013) 15

Table 1 Deployment Case 1: 2048 kbit/s interface wander budget

16 Rec. ITU-T G.8261/Y.1361 (08/2013)

Figure 9 Deployment Case 1: 2048 kbit/s interface wander budget

Table 2 Deployment Case 1: wander budget for 1544 kbit/s interface

Figure 10 Deployment Case 1: wander budget for 1544 kbit/s interface

Rec. ITU-T G.8261/Y.1361 (08/2013) 17

Table 3 Case 2A: 2048 kbit/s interface wander budget

Figure 11 Case 2A: 2048 kbit/s interface wander budget