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.8271/Y.1366
TELECOMMUNICATION (03/2020)
STANDARDIZATION SECTOR
OF ITU

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Packet over Transport aspects – Synchronization, quality
and availability targets
SERIES Y: GLOBAL INFORMATION
INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS,
NEXT-GENERATION NETWORKS, INTERNET OF
THINGS AND SMART CITIES
Internet protocol aspects – Transport

Time and phase synchronization aspects of

telecommunication networks

Recommendation ITU-T G.8271/Y.1366

 ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

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

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

 Recommendation ITU-T G.8271/Y.1366

Time and phase synchronization aspects of telecommunication networks

Summary
Recommendation ITU-T G.8271/Y.1366 defines time and phase synchronization aspects in packet
networks. It specifies the suitable methods to distribute the reference timing signals that can be used
to recover the phase synchronization and/or time synchronization according to the required quality.
The requirements for the synchronization 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 Unique ID*
1.0 ITU-T G.8271/Y.1366 2012-02-13 15 11.1002/1000/11527
1.1 ITU-T G.8271/Y.1366 (2012) Amd. 1 2013-08-29 15 11.1002/1000/12033
1.2 ITU-T G.8271/Y.1366 (2012) Amd. 2 2015-01-13 15 11.1002/1000/12391
2.0 ITU-T G.8271/Y.1366 2016-07-07 15 11.1002/1000/12812
2.1 ITU-T G.8271/Y.1366 (2016) Amd. 1 2017-08-13 15 11.1002/1000/13322
3.0 ITU-T G.8271/Y.1366 2017-08-13 15 11.1002/1000/13383
3.1 ITU-T G.8271/Y.1366 (2017) Amd. 1 2018-03-16 15 11.1002/1000/13549
3.2 ITU-T G.8271/Y.1366 (2017) Amd. 2 2018-11-29 15 11.1002/1000/13767
4.0 ITU-T G.8271/Y.1366 2020-03-15 15 11.1002/1000/14209

Keywords
Methods and interfaces, time and phase synchronization requirements.

* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11
830-en.

Rec. ITU-T G.8271/Y.1366 (03/2020) 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 2020
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.8271/Y.1366 (03/2020)

 Table of Contents
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 2
4 Abbreviations and acronyms ........................................................................................ 2
5 Conventions .................................................................................................................. 4
6 The need for time and phase synchronization .............................................................. 4
7 Time and phase synchronization methods .................................................................... 6
7.1 Distributed PRTC ........................................................................................... 7
7.2 Packet based methods with timing support of intermediate nodes................. 8
8 Network reference model ............................................................................................. 9
8.1 Access section of HRM with PTP/native access IWF.................................... 11
9 Time and phase synchronization interfaces .................................................................. 12
Annex A – One pulse-per-second (1PPS) time and phase synchronization interface
specification .................................................................................................................. 13
A.1 1PPS ITU-T V.11 interface ............................................................................ 13
A.2 1PPS 50  phase synchronization measurement interface ............................ 20
Appendix I – Time and phase noise sources in time distribution chains ................................. 21
I.1 Noise introduced by a primary reference time clock (PRTC) ........................ 21
I.2 Noise introduced by a packet master clock function ...................................... 21
I.3 Noise introduced by a packet slave clock function ........................................ 21
I.4 Noise introduced by a telecom transparent clock ........................................... 22
I.5 Noise introduced by a link .............................................................................. 22
I.6 Derivation of delay asymmetry ...................................................................... 22
I.7 Characteristics of the noise sources ................................................................ 24
I.8 Time error accumulation in a chain of clocks ................................................ 26
Appendix II – Time and phase end application synchronization requirements ....................... 27
Appendix III – Asymmetry compensation for use of different wavelengths........................... 31
Appendix IV – Link and network asymmetry compensation .................................................. 32
Appendix V – Delay asymmetry resulting from interface rate change in PTP-unaware
network elements .......................................................................................................... 35
Appendix VI – Time synchronization aspects in TDD based mobile communication
systems.......................................................................................................................... 38
VI.1 An overview of radio-interference in TDD systems ...................................... 38
VI.2 Signal frame format of TDD systems ............................................................. 39
VI.3 Base station to base station interference ......................................................... 40
VI.4 User equipment to user equipment interference ............................................. 41

Rec. ITU-T G.8271/Y.1366 (03/2020) iii

 Page
Appendix VII – Time scales .................................................................................................... 42
VII.1 Time scales ..................................................................................................... 42
VII.2 Relationship between time scales ................................................................... 43
Bibliography............................................................................................................................. 44

iv Rec. ITU-T G.8271/Y.1366 (03/2020)

Recommendation ITU-T G.8271/Y.1366

Time and phase synchronization aspects of telecommunication networks

1 Scope
This Recommendation defines time and phase synchronization aspects in telecommunication
networks. It specifies the suitable methods to distribute the reference timing signals that can be used
to recover the phase synchronization and/or time synchronization according to the required quality.
It also specifies the relevant time and phase synchronization interfaces and related performance.
The telecommunication networks that are in the scope of this Recommendation are currently limited
to the following scenarios:
– Ethernet ([IEEE 802.3] and [IEEE 802.1Q]);
– multiprotocol label switching (MPLS) ([IETF RFC 3031] and [ITU-T G.8110]);
– internet protocll (IP) ([IETF RFC 791] and [RFC 2460]);
– optical transport network (OTN) ([ITU-T G.709]).
The physical layers that are relevant to this Recommendation are the Ethernet media types, as defined
in [IEEE 802.3], and, for OTN, the optical OCh layer with optical transport network (OTU) frame as
defined in [ITU-T G.709].

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.703] Recommendation ITU-T G.703 (2016), Physical/electrical characteristics of
hierarchical digital interfaces.
[ITU-T G.709] Recommendation ITU-T G.709/Y.1331 (2016), Interfaces for the optical
transport network.
[ITU-T G.810] Recommendation ITU-T G.810 (1996), Definitions and terminology for
synchronization networks.
[ITU-T G.8110] Recommendation ITU-T G.8110/Y.1370 (2005), MPLS layer network
architecture.
[ITU-T G.8260] Recommendation ITU-T G.8260 (2020), Definitions and terminology for
synchronization in packet networks.
[ITU-T G.8261] Recommendation ITU-T G.8261/Y.1361 (2019), Timing and synchronization
aspects in packet networks.
[ITU-T G.8272] Recommendation ITU-T G.8272/Y.1367 (2018), Timing characteristics of
primary reference time clocks.
[ITU-T V.11] Recommendation ITU-T V.11/X.27 (1996), Electrical characteristics for
balanced double-current interchange circuits operating at data signalling
rates up to 10 Mbit/s.

Rec. ITU-T G.8271/Y.1366 (03/2020) 1

[IEEE 802.1Q] IEEE 802.1Q-2018, IEEE Standard for Local and metropolitan area
networks – Bridges and Bridged Networks.
<https://standards.ieee.org/standard/802_1Q-2018.html>

[IEEE 802.3] IEEE 802.3-2018, IEEE Standard for Ethernet.

<https://standards.ieee.org/standard/802_3-2018.html>

[IEEE 1588] IEEE 1588-2008, IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems.
<https://standards.ieee.org/standard/1588-2008.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.
http://www.ietf.org/rfc/rfc2460.txt?number=2460

[IETF RFC 3031] IETF RFC 3031 (2001), Multiprotocol Label Switching Architecture.
http://www.ietf.org/rfc/rfc3031.txt?number=3031

3 Definitions
The terms and definitions used in this Recommendation are contained in [ITU-T G.810],
[ITU-T G.8260] and [IEEE 1588].

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
1PPS One Pulse Per Second
ARP Antenna Reference Point
BIPM International Bureau of Weights and Measures
BBU Base Band Unit
CA Carrier Aggregation
CDMA Code Division Multiple Access
CoMP Co-ordinated Multi-Point
CRC Cyclic Redundancy Check
CU Centralized Unit
DCF Dispersion Compensating Fibre
DU Distributed Unit
eNB E-UTRAN Node B
EN-DC E-UTRAN New radio – Dual Connectivity
ERA Earth Rotation Angle
E-UTRAN Evolved Universal Terrestrial Radio Access Network
FCS Frame Check Sequence
FDD Frequency Division Duplexing
FR1 Frequency Range 1
FR2 Frequency Range 2
GBAS Ground Based Augmentation System

2 Rec. ITU-T G.8271/Y.1366 (03/2020)

GLONASS GLObalnaya NAvigazionnaya Sputnikovaya Sistema (Global Navigation Satellite
System)
GMT Greenwich Mean Time
gNB 5G (NR) Node B
GNSS Global Navigation Satellite System
GPS Global Positioning System
HRM Hypothetical Reference Model
HRPD High Rate Packet Data
IP Internet Protocol
IRNSS Indian Regional Navigation Satellite System
IWF Interworking Function
LTE Long Term Evolution
LTE-A Long Term Evolution – Advanced
MAC Medium Access Control
MBMS Multimedia Broadcast Multicast Service
MBSFN MBMS based on Single Frequency Network
MIMO Multiple Input Multiple Output
MRTD Maximum Received Time Difference
M2M Machine to Machine
NR New Radio
NTP Network Time Protocol
OTDOA Observed Time Difference of Arrival
OTN Optical Transport Network
PDV Packet Delay Variation
PHY Physical Layer Protocol
PON Passive Optical Network
PRTC Primary Reference Time Clock
PSN Packet Switched Network
PTP Precision Time Protocol
QZSS Quasi-Zenith Satellite System
RTT Radio Transmission Technology
RX Receive
SBAS Satellite Based Augmentation System
SI International System of Units
SMTC SSB Measurement Timing Configuration
SSB Synchronization Signal Block
TAE Time Alignment Error

Rec. ITU-T G.8271/Y.1366 (03/2020) 3

TAI International Atomic Time
TDD Time Division Duplexing
TD-SCDMA Time Domain Synchronized CDMA
T-BC Telecom Boundary Clock
T-GM Telecom Grandmaster
T-TC Telecom Transparent Clock
T-TSC Telecom Time Slave Clock
TX Transmit
UDP User Datagram Protocol
UE User Equipment
UT Universal Time
UTC Universal Time Co-ordinated
UTRA Universal Terrestrial Radio Access
WCDMA Wideband CDMA
WDM Wavelength-Division-Multiplexing
WiMAX Worldwide Interoperability for Microwave Access

5 Conventions
Within this Recommendation, the following conventions are used: The term precision time protocol
(PTP) is the protocol defined by [IEEE 1588]. As an adjective, it indicates that the modified noun is
specified in or interpreted in the context of [IEEE 1588].

6 The need for time and phase synchronization

Time synchronization has traditionally been required to support billing and alarm functions
(maintenance or fault isolation). In this context, synchronization must in general be accurate to within
hundreds of milliseconds.
Another time synchronization application is the monitoring of delays in Internet protocol (IP)
networks. In this case, the requirement is accuracy to within some hundreds of microseconds
(the actual requirement depends on the application).
Stringent time synchronization requirements (i.e., in the range of a few microseconds) apply to the
generation of signals over the air interface of some mobile systems, such as code division multiple
cccess (CDMA)2000 or long term evolution frequency division duplexing (LTE FDD) unicast, when
it is required to support synchronous CDMA2000 interworking.
Phase synchronization is often needed to support requirements for the air interface of some mobile
systems, as in the case of time division duplexing (TDD) systems (for instance, LTE TDD), or when
supporting multimedia broadcast/multicast service (MBMS). Note that ordinary wideband CDMA
(WCDMA) MBMS does not require accurate phase synchronization since it has been specified and
designed to work properly in networks that satisfy the 50 ppb frequency accuracy requirement. This
requirement, which is guaranteed by the WCDMA node synchronization function (see
[b-3GPP TS 25.402]), limits phase drift to between 10 and 20 ms. But when MBMS is based on
single-frequency network (MBSFN) mode, timing must be accurate to within a few microseconds.
This is because identical waveforms are transmitted simultaneously from multiple cells. The signals
from these cells are then combined as the multipath components of a single cell. Terminals must thus

4 Rec. ITU-T G.8271/Y.1366 (03/2020)

perceive the signals of an entire group of transmitting cells as though they came from a single cell.
Therefore, all transmissions must be very tightly synchronized and deliver exactly the same content
to each base station.
The main requirements applicable at the output of the application (e.g., on the radio interface in the
case of a wireless application) are summarized in Appendix II.
Based on Table II.1, it is possible to classify the applications into classes of requirements, as shown
in Table 1 below.
NOTE – In the case of mobile applications as described in Table II.1, the requirements are generally expressed
in terms of phase error between base stations. In the case of a centralized master, the requirement could be
expressed as  half of the accuracy requirement applicable to the specific technology. Table 1 presents the
requirement in this format in order to allow the analysis of time error budgeting as distributed from a primary
reference time clock (PRTC) towards the end application.

Table 1 – Time and phase requirement classes

Class level of Time error requirements Typical applications
accuracy (Note 1) (for information)
1 500 ms Billing, alarms.
2 100 – 500 s IP delay monitoring.
Synchronization signal block (SSB)-
measurement timing configuration (SMTC)
window.
3 5 s LTE TDD (large cell).
Synchronous Dual Connectivity (for up to 7
km propagation difference between
eNBs/gNBs in FR1). (Note 2)
4 1.5 s UTRA-TDD, LTE-TDD (small cell),
NR TDD, WiMAX-TDD (some
configurations).
Synchronous dual connectivity (for up to 9 km
propagation difference between eNBs/gNBs in
FR1) (Note 2).
New radio (NR) intra-band non-contiguous
and inter-band carrier aggregation, with or
without multiple input multiple output
(MIMO) or transmit (TX) diversity.
5 1 s WiMAX-TDD (some configurations).
6 x ns Various applications, including location based
(Note 4) services and some coordination features.
(Note 3)
NOTE 1 – The requirement is expressed in terms of time error with respect to a common reference. Some
of the original requirements were expressed in terms of relative time error.
NOTE 2 – FR1: 410 MHz – 7.125 GHz; FR2: 24.25 – 52.6 GHz
NOTE 3 – The performance requirements of some of these features are under study. For information
purposes only, values between 500 ns and 1.5 s have been mentioned for some features. Depending on
the final specifications developed by 3GPP, these applications may be handled in a different level of
accuracy.
NOTE 4 – For the value x, refer to Table 2 and Table II.2 of Appendix II.

Based on Table II.2, it is possible to classify the class 6 level of accuracy into a further three
sub-classes, as shown in Table 2.

Rec. ITU-T G.8271/Y.1366 (03/2020) 5

 Table 2 – Time and phase requirements for cluster based synchronisation
Maximum relative time
Class level of Typical applications
error requirements
accuracy (for information)
(Note 1)
3A 5 s LTE MBSFN.
4A 3 s NR intra-band non-contiguous (FR1 only) and
inter-band carrier aggregation; with or without
MIMO or TX diversity.
6A 260 ns LTE intra-band non-contiguous carrier aggregation
with or without MIMO or TX diversity, and inter-
band carrier aggregation with or without MIMO or
TX diversity.
NR intra-band contiguous (FR1 only) and Intra-
band non-contiguous (FR2 only) carrier
aggregation, with or without MIMO or TX
diversity.
6B 130 ns LTE intra-band contiguous carrier aggregation,
with or without MIMO or TX diversity.
NR (FR2) intra-band contiguous carrier
aggregation, with or without MIMO or TX
diversity.
6C 65 ns LTE and NR MIMO or TX diversity
(Note 2) transmissions, at each carrier frequency.
NOTE 1 – The maximum relative time error requirements represent the largest timing difference measured
between any two elements of the cluster. See Appendix VII of [b-ITU-T G.8271.1] for illustration of how
requirements are specified in a cluster. In 3GPP terminology this is equivalent to time alignment error
(TAE).
NOTE 2 – Level 6C is an internal equipment specification, and does not result in a synchronization
requirement on the transport network.

This Recommendation deals mainly with the class 4, 5, and 6A levels of accuracy requirement, as
indicated in Table 2.

7 Time and phase synchronization methods

Packet-based methods (typically using the network time protocol (NTP)) without timing support from
the network are traditionally used to support applications with less strict time and phase
synchronization requirements (class 1 according to Table 1).
This Recommendation focuses on applications corresponding to classes 4, 5, and 6 according to
Table 1.
For these applications, the following options are considered in this Recommendation:
– a distributed primary reference time clock (PRTC) approach, implementing a global
navigation satellite system (GNSS) receiver in the end application (a global positioning
system (GPS) receiver, for example);
– packet-based methods with timing support of intermediate nodes.
NOTE 1 – Additional solutions may be considered as a complement to the above solutions. As an example,
timing may be carried over the radio interface of mobile systems. Applicability to the general hypothetical
reference model (HRMs) is for further study.

6 Rec. ITU-T G.8271/Y.1366 (03/2020)

NOTE 2 – The use of packet-based methods with limited timing support, or without timing support of
intermediate nodes, is considered capable of addressing applications corresponding to class 4.
The following clauses provide details on the synchronization methods based on the distributed PRTC
approach, and packet based methods with timing support of intermediate nodes.

7.1 Distributed PRTC

One method to achieve time and phase synchronization is to distribute a synchronization signal
directly to each clock in the network. This method is referred to as a distributed primary reference
time clock and, in general, is feasible with radio distribution because a network-wide wire-based
distribution would require a complete extra network, which may be impractical. However, in some
cases, a remote distribution of the PRTC signal via cables might also be possible. The radio
distribution is normally achieved by means of GNSS, as for instance the GPS. Other radio systems
may also be used.
The main objective of a synchronization network is to synchronize the end applications which require
a timing reference. If there are several end applications in one site, a single PRTC reference can be
deployed in the site and the time/phase reference can be further distributed within the site from a
centralized function. The details of the centralized function are for further study.
Figure 1 below gives a generic representation of the distributed PRTC method. In the case of
GNSS-based synchronization, the reference timing signal is distributed by the satellite signals and
the GNSS receiver acts as the PRTC of the network. The receiver (RX) in Figure 1 processes the
GNSS signal and extracts a reference signal for the end applications.

Radio distributed PRTC, e.g., GNSS or

distribution via cables

Rx Rx
PRTC limits PRTC limits
PRTC limits
End End
application End End End application
application application application
G.8271-Y.1366(12)_F01

Time or phase synchronization distribution via cable

Time or phase synchronization distribution via radio

Figure 1 – Example of a distributed PRTC synchronization network

7.1.1 Main characteristics
One of the main advantages for a distributed PRTC approach is that the reference timing signals are
available world-wide in the case of GNSS. This approach also allows for a flat distribution hierarchy
with no risk of timing loops. In general, the overall network planning is also easier.
The main disadvantages of this approach are the dependency on the operator of the navigation system,
the requirements for an antenna with a wide-angle view to the sky, the need to address lightning
protection and, in general, the issues related to the antenna cabling.
Finally, GNSS-based systems present a risk of interference, e.g., by television (TV) systems,
saturation and jamming.
It should be mentioned, however, that evolution of the technology reduces some of the main
drawbacks (e.g., installation, reliability, etc.). Moreover, it should be possible to secure the GNSS

Rec. ITU-T G.8271/Y.1366 (03/2020) 7

receivers, for instance when an accurate frequency reference, such as a synchronous Ethernet signal,
is available. The options for securing GNSS receivers are for further study.
In terms of performance, the accuracy that can be achieved by means of a PRTC system is defined in
[ITU G.8272].

7.2 Packet based methods with timing support of intermediate nodes

Time synchronization can be distributed via timing protocols such as PTP (see [IEEE 1588]).
This Recommendation currently focuses on the cases where the timing reference is carried with
support from the network.
The timing support in the intermediate nodes (e.g., Ethernet switches) concerns specific hardware as
well as software timing functions (see Figure 2).

Figure 2 – Example of packet-based method with support from network nodes

In the case of PTP, these functions can correspond either to the telecom boundary clock (T-BC) or to
the telecom transparent clock (T-TC), with hardware timestamping at the related interfaces.
The T-BC terminates and regenerates timestamp messages.
The T-TC provides a means of measuring the delays that have been added by the network element
and by the links connected to the network element. This Recommendation considers only T-BC
support in this version. The use of T-TC in telecom applications is for further study.
The Figure 3 shows an example of phase/time synchronization distributed via packet-based methods
with timing support from the network. A packet master clock function in a telecom grandmaster
(T-GM) having access to a reference timing signal compliant with the PRTC limits originates the
packet timing distribution, and every transport node implements a T-BC.

8 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Radio distributed PRTC, e.g., GNSS or
distribution via cables

Rx
PRTC limits PRTC limits
Packet
End Packet master
application master
clock Packet timing
clock
distribution network
Transport
Packet timing Transport Transport node
distribution network node node

Packet
Packet Packet slave
slave slave clock
clock clock

End End
End End End End application application
application application application application
G.8271-Y.1366(12)_F03

T-BC
Time or phase synchronization distribution via cable
Time or phase synchronization distribution via radio

Figure 3 – Example of time synchronization distributed via packet based methods

7.2.1 Main characteristics
The main advantage of a time synchronization distribution solution via packet-based methods is the
significantly reduced number of GNSS receivers. Note that if the PRTC is based on GNSS, then
GNSS receivers would be required at the PRTC locations.
Among the disadvantages, it can be noted that the network planning is in this case more complex
(e.g., with risk of timing loops). In addition, noise accumulation has also to be taken into account.
Finally, another issue with this methodology is the time error due to asymmetries in the network that
needs to be controlled (e.g., implying calibration of fibre lengths).

8 Network reference model

Figure 4 describes the network reference model used to define the time and phase synchronization
performance objectives when the reference timing signal is carried over the transport network:

Rec. ITU-T G.8271/Y.1366 (03/2020) 9

 Figure 4 – Network reference model

The following reference points are defined. All the requirements related to these reference points are
defined with respect to a common time reference, i.e., any recognized time reference such as GPS
time.
– A: PRTC output;
– B: Packet master clock output;
– C: Packet slave clock input;
– D: Packet slave clock output;
– E: End application output.
Some specific access technologies may need to be considered in the network reference model in some
cases. For instance, the network between points B and C can be composed in some cases of a transport
part and an access part. Each part would then have its own phase/time budget derived from the media
specific mechanisms that have been developed to transport frequency and time synchronization.
NOTE 1 – In Figure 4 the packet master clock could correspond to a T-GM and the packet slave clock could
correspond to a telecom time slave clock (T-TSC).
NOTE 2 – The performance studies documented in [b-ITU-T G.8271.1] are based on a full timing support in
the network with hardware timestamping (e.g., T-BC in every node in the case of [IEEE 1588]) and with
physical layer frequency synchronization support (e.g., synchronous Ethernet support). The case of partial
timing support, where some or all of the nodes are not capable of providing timing support to the PTP layer,
is covered in [b-ITU-T G.8271.2].
NOTE 3 – In some cases, specific access technologies may need to be considered in the network reference
model. For instance in some cases, the packet network between points B and C can be composed of a transport
part and an access part. Each part would then have its own phase/time budget. In some radio access networks
(RAN) scenarios, for instance when the RAN is split based on different radio functions, from the point of view
of timing, the starting point for the RAN may be present between points B and C shown in Figure 4.
Alternatively, the entire network model may be present within the RAN. Details are for further study.
NOTE 4 – Additional detail for the network reference model of Figure 4 for the case of PTP over non-packet
technologies (e.g., OTN, gigabit passive optical network (GPON), microwave) is for further study.
The overall budget relates to measurement point 'E' (i.e., the time error at E with respect to the
common time reference).
'A', 'B', 'C' and 'D' define the other relevant measurement reference points and related network limits,
that also indicate the budget of the noise that can be allocated to the relevant network segments
(e.g., 'A to C', 'A to D', etc.).
The measurement points that are of interest for a specific application may depend on where the
network administrative domain borders apply.

10 Rec. ITU-T G.8271/Y.1366 (03/2020)

Also, as described above, the measurement in some cases needs to be performed on a two-way timing
signal, which would require a specific test set-up and metrics to be used.
The measurement set-up for two-way timing signals as well as the noise that can be added by the
measurement test equipment is an item for further study.
Another possibility is to perform the measurement using an external dedicated output phase/time
reference, such as a one pulse per second (1PPS) interface. Annex A provides guidance about this
type of interface.

8.1 Access section of HRM with PTP/native access IWF

The general network reference model in Figure 4 can be further expanded to illustrate different types
of access technology that may be used at the edge of the network such as microwave, digital
subscriber line (DSL) or passive optical network (PON).
Generally access technologies can be categorized as either point-to-multipoint shared technologies or
point-to-point technologies. An example of a point-to-multipoint shared media technology is a PON
with a single multi-port head end and multiple end devices. An example of a point to point technology
is a microwave system. Figure 5 expands the access section to show the media conversion that occurs
between the Ethernet technology that forms the existing synchronization HRM of the transport section
and the technologies in the access section of the HRM. The time error budget of this section may
depend on the specific type of technology.

Figure 5 – Network reference model with access section

For example, between B.0 and B.1 the transport section consists of a network chain from
[b-ITU-T G.8271.1] comprised of full timing aware ITU-T G.8273.2 T-BCs using PTP & SyncE.
Between B.1 and C of the access section, there may also be T-BCs, and in this case they are connected
to and from native access clocks. These native access clocks provide the direct connection to the
medium. Essentially, the T-BC and native access clock provides an interworking function (IWF) that
converts between Ethernet carrying PTP and the access medium.
The access section will have a time error that is a combination of the constant and dynamic
components of the medium as well as contribution from the clocks in the access section.

Rec. ITU-T G.8271/Y.1366 (03/2020) 11

9 Time and phase synchronization interfaces
Time and phase synchronization interfaces are needed for the following two purposes:
1) measurement interface:
in order to allow network operators to measure the quality of the time/phase synchronization
distributed along a synchronization chain, each PRTC, T-GM, T-BC and T-TSC must have
a dedicated external phase/time output interface implemented;
a one pulse-per-second (1PPS) interface is an adequate measurement interface, and should
be implemented according to one of the interfaces specified in Annex A. Additional
measurements interfaces are for further study.
2) distribution interface:
time and phase synchronization interfaces are sometimes needed to connect systems
belonging to a time/phase synchronization distribution chain;
a typical application is the case of a T-TSC connected to an end-application, such as a base
station, which is equipped with an existing input 1PPS interface. The details of the
distribution interfaces are for further study.
Figure 6 shows examples of both types of time and phase synchronization interfaces: measurement
interfaces (reference point 1) and distribution interfaces (reference point 2). Different requirements
may apply to these points.

Figure 6 – Possible locations of external time and phase interfaces in a chain

of telecom-boundary clocks

12 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Annex A

One pulse-per-second (1PPS) time and phase synchronization

interface specification
(This annex forms an integral part of this Recommendation.)

A.1 1PPS ITU-T V.11 interface

The 1PPS time/phase interface uses a point-to-point ITU-T V.11 interface as specified in
[ITU-T V.11] with an additional requirement on the rise/fall times of the 1PPS signal as defined in
[ITU-T G.703]. This is needed to provide the accuracy required for the 1PPS signal.
This interface can be used for time synchronization distribution as well as for time measurement.
The interface is a balanced interface that can tolerate significant common mode noise.
The 1PPS interface consists of a balanced 100 ohm 1PPS differential signal that can be used to
connect to the next clock or to measurement equipment.
Performance measurement point

DRIVER TWISTED CABLE RECEIVER

+ +
CONN

CONN
PPS_OUT PPS_IN
– –
100 ohm
Cable length load
L

G.8271-Y.1366(12)-Amd.1(13)_FA.1

Figure A.1 – Balanced 1PPS V.11 interface

A.1.1 Interface signals
The signals of this interface are defined in this clause as follows:
– 1PPS_OUT+/1PPS_OUT-: This output signal pair indicates the significant event occurring
on the leading edge of the signal and is generated by the time master;
– 1PPS_IN+/1PPS_IN-: This input signal pair indicates the significant event occurring on the
leading edge of the signal and is used by the time slave;
– TX+/TX-: This output signal pair is used for a serial communication channel for transfer of
time messages and status messages between the time master and the time slave;
– RX+/RX-: This input signal pair is used for a serial communication channel for transfer of
messages between the time master and the time slave.
The connector is defined in [ITU-T G.703], which specifies the physical aspects of this interface.
The connection requires the use of a crossed cable that connects the signal pairs as specified in
Table A.1.

Table A.1 – Cable connections

Connector A Connector B
1PPS_OUT+/1PPS_OUT- 1PPS_IN+/1PPS_IN-
1PPS_IN+/1PPS_IN- 1PPS_OUT+/1PPS_OUT-
TX+/TX- RX+/RX-
RX+/RX- TX+/TX-

Rec. ITU-T G.8271/Y.1366 (03/2020) 13

 Table A.1 – Cable connections
NOTE – Not all the signals in Table A.1 will necessarily be needed at the same time (e.g., one direction
only might be sufficient in some cases). The backward direction of the messaging channel is for further
study.

A.1.2 Automatic cable delay compensation (optional)

The 1PPS ITU-T V.11 interface can optionally support automatic cable delay compensation. The
enhanced 1PPS ITU-T V.11 interface adds support for automatic cable and ITU-T V.11 transceiver
compensation using a feedback loop that allows the time master to measure the round-trip delay of
the 1PPS signal and compensate for the path delay when generating the 1PPS signal.
The 1PPS signal is initially generated by the timing master at the 1-second boundary, T1. This signal
is delayed through the cable before it arrives at the timing slave. The 1PPS signal is looped back at
the slave and sent to the time master. The time master captures the time of reception of the 1PPS
signal from the time slave, T2, and measures the round-trip delay as the time since the generation of
the 1PPS signal.
Assuming that the path is symmetrical, the time master calculates the mean cable delay as:
(T2 − T1)/2 and either compensates for the cable delays by advancing the 1PPS signal by the mean
cable delay or alternatively informs the time slave about the mean cable delay through the
ITU-T V.11 serial communication channel so that the slave can perform the compensation.
The protocol used on the serial communication channel is defined in clause A.1.3 below.
The time slave performs a loopback of the 1PPS signal at some point after the ITU-T V.11 transceiver.
A.1.3 Serial communication channel
A.1.3.1 Transmission characteristics
The following characteristics apply to the serial communication channel:
1) the default baud rate is 9600, without parity check;
2) when every byte data is sent, it shall include one start bit denoted by low voltage level, eight
bits data and one end bit denoted by high voltage level. During non-data interval, it should
be kept at high voltage level;
3) the message data should be sent no sooner than 1ms after the rising edge of 1PPS and must
be finished within 500 ms;
4) the message represents the time at which the current 1PPS starts;
5) the messages should be sent once per second.
A.1.3.2 Message structure
The message structure is defined in Figure A.2.

Figure A.2 – Time of day message structure

14 Rec. ITU-T G.8271/Y.1366 (03/2020)

Each message is a multiple of 8 bits (octets) with frame check sequence (FCS). The messages are
identified by the message CLASS and message ID. The transmission order of octets within multi-octet
fields should comply with "big endian" rules, i.e., from the most significant octet first to the least
significant octet last. The transmission of bits within one octet should be from bit 0 to bit 7. The
transmission of the payload should start from offset 0 (see Tables A.3, A.5 and A.7).
Multiple messages may be sent on the serial communications channel. The messages can be sent with
either no delay between messages or with a non-zero delay between messages. However the
transmission of all messages must be completed within the time period indicated in clause A.1.3.1.
The interpretation of each message field is as follows:
1) start of message:
The start of a message has two octets: SYNC CHAR 1 and SYNC CHAR 2. These two octets
are used for message alignment. A common value of 0x43 and 0x4D has been given to each
octet representing the ASCII characters "C" and "M" respectively.
2) header:
The message header includes the sub-fields CLASS (1 octet) and message ID (1 octet).
CLASS shows the basic type of the message. ID is encoded as the subtype of each class of
message.
3) length:
The length field has two octets which indicates the length of the payload (not including the
length of Sync Char 1, Sync Char 2, Header, Length and FCS field).
4) payload:
The payload field contains the contents of the message. This field may vary in length,
depending on the message type.
5) FCS:
The FCS has one octet, consisting of a cyclic redundancy check (CRC)-8 calculated over the
header, length and payload fields of each message type (excluding Sync Chars 1 and 2). The
CRC-8 uses the generator polynomial G(x) = x8 + x5 + x4 + 1, and is calculated as follows:
(a) the input bits are taken in network transmission order, i.e., the most significant octet first,
and within each octet the least significant bit first, to form an N-bit pattern representing
the coefficients of a polynomial M(x) of degree N-1 (where N is the number of bits in the
message);
(b) M(x) is pre-pended with the hexadecimal value 0xFC, then multiplied by x8. The result
is then divided (modulo 2) by G(x), producing a remainder R(x);
(c) the coefficients of R(x) are considered to be an 8-bit sequence, where x7 is the most
significant bit;
(d) this 8-bit sequence is the CRC-8 where the first bit of the CRC-8 to be transmitted is the
coefficient of x7 and the last bit transmitted is the coefficient of x0.
The de-mapper process performs the above calculation in the same manner as the mapper process,
except that here, the M(x) polynomial of step (a) includes the CRC-8 bits of the FCS field, resulting
in M(x) having degree N+7. In the absence of bit errors, the remainder shall be 0000 0000.
Alternatively, the de-mapper may exclude the FCS field in which case, in the absence of bit errors,
the remainder shall be equal to the value of the FCS field.
Figure A.3 shows an example of a time-of-day time event message. Using the CRC-8 calculation
method defined above, the calculated CRC-8 value in network transmission order is 1010 0100.
Represented as an octet field, the FCS value is 0x25.

Rec. ITU-T G.8271/Y.1366 (03/2020) 15

NOTE – In step (b), the polynomial M(x) is pre-pended with the value 0xFC. In the optimized implementation
used by most actual CRC-generators, this is the mathematical equivalent of setting the initial value to 0xFF
for the generator polynomial defined, but without pre-pending the value 0xFC.
Field Sync Char Sync Char Class ID Length
1 2
Hexadecimal Value 43 4D 01 01 00 0E
Transmission order 1100 0010 1011 0010 1000 0000 1000 0000 0000 0000 0111 0000
(first bit on left)

Field Payload
Time R F cUTCO R
Hexadecimal Value 00 00 59 09 DF B8 00 06 16 0F 00 00 00 00
Transmission order 0000 0000 0000 0000 1001 1010 1001 0000 1111 1011 0001 1101 0000 0000 0110 0000 0110 1000 1111 0000 0000 0000 0000 0000 0000 0000 0000 0000
(first bit on left)

Field FCS

Hexadecimal Value 25
Transmission order 1010 0100
(first bit on left)

Figure A.3 – Example time of day message

A.1.3.3 Message contents
There are three message types defined for the serial communication channel of the 1PPS V.11
interface:
– time event message – timestamp and basic traceability information:
This message is typically transmitted by all clock types using this interface;
– time announce message – virtual PTP announce message:
This message is typically transmitted by a PTP clock;
– GNSS status message – provides information about the status of a GNSS timing receiver:
This message is typically transmitted by a GNSS-based clock.
A.1.3.3.1 Time event message
This message is used to output the time of day across the 1PPS V.11 interface.

Table A.2 – Time event message

Name Time event message

Description Time event information
Type Reported every second
Sync Sync Class ID Length Payload FCS
Char 1 Char 2
Frame structure See
See Table
0x43 0x4D 0x01 0x01 0x000E clause
A.3
A.1.3.2

16 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Table A.3 – Time event message payload

Length
Offset Name Notes
(octets)

0 6 Time PTP seconds (unsigned 48-bit integer)

6 1 Reserved Reserved
Bit 0: leap61 – Positive Leap Second pending
Bit 1: leap59 – Negative Leap Second pending
Bit 2: UTC offset valid
Bit 3: Reserved
7 1 Flags Bit 4: timeTraceable – time traceable to a primary
time standard
Bit 5: frequencyTraceable – frequency traceable to a
primary frequency standard
Bits 6, 7: Reserved
Current value of the offset between TAI and UTC
8 2 currentUTCOffset
(i.e., TAI – UTC)
10 4 Reserved Reserved

A.1.3.3.2 Time announce message

This message is used to output the quality and traceability of the time delivered across the
1PPS V.11 interface of equipment containing a PTP clock.
Use of this message on an output interface of a PRTC is for further study, unless the equipment
containing a PRTC also contains a T-GM.
The fields of this message are direct copies of the equivalent named fields of the PTP announce
message, as described in [IEEE 1588]. A PTP clock receiving the time of day (ToD) information may
treat this information as having been received on a virtual PTP port according to the relevant PTP
profile (e.g., [ITU-T G.8275.1]).

Table A.4 – Time announce message

Name Time announce message

Provides information on the quality and traceability of the time source, equivalent to
Description
that contained in a PTP announce message.
Type Reported every second
Sync Sync Class ID Length Payload FCS
Char 1 Char 2
Frame structure 0x43 0x4D See
See Table
0x01 0x02 0x0020 clause
A.5
A.1.3.2

Rec. ITU-T G.8271/Y.1366 (03/2020) 17

 Table A.5 – Time announce message payload
Offs Length
Name Notes
et (octets)
0 1 versionPTP PTP version number
1 1 domainNumber PTP domain number
2 2 flagField PTP flag field (see Note)
4 8 sourcePortIdentity.clockIdentity clockIdentity of the sending clock
12 2 sourcePortIdentity.portNumber Port number of the sending virtual PTP port
14 1 grandmasterPriority1 Priority1 value of the PTP Grandmaster
15 1 grandmasterPriority2 Priority2 value of the PTP Grandmaster
grandmasterClockQuality
16 1 clockClass of the PTP Grandmaster
.clockClass
grandmasterClockQuality
17 1 clockAccuracy of the PTP Grandmaster
.clockAccuracy
grandmasterClockQuality offsetScaledLogVariance of the PTP
18 2
.offsetScaledLogVariance Grandmaster
20 8 grandmasterClockIdentity clockIdentity of the PTP Grandmaster
28 2 stepsRemoved StepsRemoved from the PTP Grandmaster
Type of the source of time provided by the PTP
30 1 timeSource
Grandmaster
31 1 Reserved Reserved
NOTE – This is copied directly from the flagfield in the header portion of the PTP announce message,
even though some of the flags are not relevant.

A.1.3.3.3 GNSS status message

This message is used to output the status or alarms of GNSS receivers across the 1PPS V.11 interface
of a PRTC. It is not normally produced by a PTP clock, unless they are contained within the same
equipment as a GNSS timing receiver.

Table A.6 – GNSS status message

Name GNSS status message
Description Current status of GNSS timing receiver
Type Reported every second
Sync Sync Class ID Length Payload FCS
Char 1 Char 2
Frame structure See
See Table
0x43 0x4D 0x01 0x03 0x0008 clause
A.7
A.1.3.2

18 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Table A.7 – GNSS status message payload
Length
Offset Name Notes
(octets)
0x00: Beidou (Compass)
0x01: GPS
0x02: PTP
0x03: Galileo
0x04: Glonass
0x05: QZSS
0 1 Types of time source 0x06: IRNSS
0x07: GNSS (Combination of constellations)
0x08: Unknown (in case there is no information
about which GNSS timescale is really used and
no possible action to compel the module to
work with a specific GNSS timescale)
0x09 ~ 0xFF: Reserved
GNSS Fix Type:
0x00: Position unknown
0x01: dead reckoning only (see Note 1)
0x02: 2D-fix
0x03: 3D-fix
1 1 Status of time source 0x04: GNSS + dead reckoning combined
0x05: Time only fix
0x06: A-GNSS
0x07: GNSS + SBAS
0x08: GNSS + GBAS
0x09 ~ 0xFF: reserved
Time source alarm status:
Bit 0: Reserved
Bit 1: Antenna open
Bit 2: Antenna shorted
Bit 3: Not tracking satellites
Bit 4: Reserved
Bit 5: Survey-in progress
Bit 6: no stored position
2 2 Alarm Status Monitor
Bit 7: Leap second pending
Bit 8: In test mode
Bit 9: GNSS solution (i.e., derived position and
time) is uncertain (see Note 2)
Bit 10: Reserved
Bit 11: Almanac not complete
Bit 12: PPS was generated
Bit 13 ~ Bit 15: Reserved
4 4 Reserved Reserved
NOTE 1 – Dead Reckoning Only – Position from GNSS is lost. Current position is estimated from the
last-known position, plus knowledge of the velocity and acceleration of the antenna since the GNSS-based
position was known.

Rec. ITU-T G.8271/Y.1366 (03/2020) 19

NOTE 2 – GNSS solution is uncertain. When this bit is 1, it indicates that the accuracy of the position derived
from GNSS is uncertain, possibly due to not being able to see enough satellites. This alarm may indicate that
the antenna has been moved or fallen from place since the unit completed the last self-survey.

A.2 1PPS 50  phase synchronization measurement interface

The 1PPS interface consists of an unbalanced 50-ohm 1PPS signal that can be used to connect to
measurement equipment (see Figure A.4).
The physical characteristics of this interface are defined in [ITU-T G.703].

Figure A.4 – Unbalanced 1PPS 50  measurement interface

The system must compensate for the internal delays in the system to ensure that the 1PPS signal
timing is met at the edge of the box.
The measurement equipment is expected to compensate for the delays associated with the
interconnection of the 1PPS interface.

20 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Appendix I

Time and phase noise sources in time distribution chains

(This appendix does not form an integral part of this Recommendation.)

Quantifying the sources of errors in the time distribution chain is essential in the process to defining
noise budget in the network reference model.
The sources of errors listed in this appendix are based on a network with full timing support provided
by telecom boundary clocks (T-BCs).
In the case of no timing support in some of the nodes, (or in all the nodes), additional sources of noise
should be considered. This is for further study.
The sources of noise due to timing support provided by telecom transparent clocks (T-TCs) are also
for further study.

I.1 Noise introduced by a primary reference time clock (PRTC)

Table I.1 provides the sources of errors in a PRTC.

Table I.1 – Source of errors in a primary reference time clock

Source of error Explanation/Assumptions
1 Reference time error See clause I.7.1

I.2 Noise introduced by a packet master clock function

Table I.2 provides the sources of errors in a packet master clock function. The packet master clock
function may be a part of a T-GM or a T-BC.

Table I.2 – Source of errors in a packet master clock function

Source of error Explanation/Assumptions
1 Physical layer protocol (PHY) See clause I.7.2
latency asymmetry internal to
the nodes

I.3 Noise introduced by a packet slave clock function

Table I.3 provides the sources of errors in a packet slave clock function. The packet slave clock
function may be part of a T-TSC or a T-BC.

Table I.3 – Source of errors in a packet slave clock function

Source of error Explanation/Assumptions
1 Local oscillator phase noise See clause I.7.4
2 PHY latency asymmetry See clause I.7.2
internal to the nodes
3 Timestamping granularity See clause I.7.3
4 Frequency reference phase See clause I.7.5
error
5 Time transients See clause I.7.6

Rec. ITU-T G.8271/Y.1366 (03/2020) 21

I.4 Noise introduced by a telecom transparent clock
The sources of error in a telecom transparent clock are for further study.

I.5 Noise introduced by a link

Table I.4 provides the sources of errors in a link.

Table I.4 – Source of errors in a link

Source of error Explanation/Assumptions
1 Link asymmetry See clause I.7.7

I.6 Derivation of delay asymmetry

Figure I.1 illustrates the delays between a packet slave clock function, or requestor (denoted as slave
throughout this clause), and a packet master clock function, or responder (denoted as master
throughout this clause). The mean propagation delay is measured at the slave after exchange of event
messages. If the Delay Request and the Delay Response mechanism is used (see [IEEE 1588]),
the slave sends Delay_Req and the master sends Delay_Resp and, separately, Sync and Follow_Up
(i.e., the sending of Sync and Follow_Up are not part of the Delay_Req/Delay_Resp exchange; the
Follow_Up message is sent if, and only if, the clock is two-step). If the Peer Delay mechanism is used
(see [IEEE 1588]), the slave sends Pdelay_Req and the master sends Pdelay_Resp and, if the clock
is two-step, Pdelay_Resp_Follow_Up.
The figure shows the effective points in the protocol stack of each clock where timestamps are
generated, after any corrections for ingress and egress latencies are made (see clause 7.3.4 and
Figure 19 of [IEEE 1588]). These points would ideally be at the reference plane, i.e., the boundary
point between the PHY and the network physical medium. However, in practice, the corrections for
ingress and egress latencies are not perfect, and the effective points at which the timestamps are
generated differ from the reference plane. The delays between the effective points where timestamps
are taken and the reference plane are denoted dtxPHY,M and drxPHY,M for egress and ingress, respectively,
at the master, and dtxPHY,S and drxPHY,S for egress and ingress, respectively, at the slave. In this notation,
the subscript t (transmit) is used for egress and the subscript r (receive) is used for ingress. In general,
these four quantities can all be different.
The figure also shows the link delays, which are measured from the reference plane of one clock to
the reference plane of the other clock. The delay from the master to the slave is denoted dmslink, and
the delay from the slave to the master is denoted dsmlink.

22 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Figure I.1 – Illustration of delays between a packet slave clock function, or requestor,
and a packet master clock function, or responder

The total delay from the master to the slave, tms, is the sum of the delays in that direction:

t ms = d txPHY , M + d ms
link
+ d rxPHY , S (I-1)
Similarly, the total delay from the slave to the master, tsm, is the sum of the delays in that direction:

t sm = d txPHY , S + d sm
link
+ d rxPHY , M (I-2)
For the sign convention for the delay asymmetry, the same convention as in clause 7.4.2 of
[IEEE 1588] is adopted. Let Dmean denote the measured mean path delay (i.e., the measured result of
the exchange of Delay_Req and Delay_Resp or of Peer Delay messages), and Dasym denote the total
delay asymmetry. Then, Dasym is defined to be positive when the delay from the master to the slave is
larger than the delay from the slave to the master. Likewise, Dasym is defined to be negative when the
delay from the master to the slave is smaller than the delay from the slave to the master. Then:
t ms = Dmean + Dasym
(I-3)
t sm = Dmean − Dasym

Equations (I-3) imply that:

t ms + t sm
Dmean = (I-4)
2
as required. Substituting equations (I-1) and (I-2) into equation (I-4) gives:

(d txPHY , M + d ms
link
+ d rxPHY ,S ) + (d txPHY , S + d sm
link
+ d rxPHY , M )
Dmean = (I-5)
2

Rec. ITU-T G.8271/Y.1366 (03/2020) 23

Either of the two equations (I-3) may be used with equation (I-4) to obtain the delay asymmetry in
terms of the component delays. Using the first of equations (I-3) produces:
Dasym = t ms − Dmean
(d txPHY , M + d ms
link
+ d rx
PHY , S
) + (d txPHY , S + d sm
link
+ d rx
PHY , M
)
= (d txPHY , M + d ms
link
+ d rx
PHY , S
)−
2
d txPHY , M − d rx
PHY , M
d link − d sm
link
d PHY , S − d txPHY , S
= + ms + rx
2 2 2
= eM
phy + elink − asym − e phy
S

(I-6)
where:

d txPHY ,M − d rxPHY ,M
eM
phy = (I-7)
2
link
d ms − d sm
link
elink −asym = (I-8)
2
d txPHY ,S − d rxPHY ,S
e Sphy = (I-9)
2

Equations (I-7) and (I-9) are the errors due to PHY latency asymmetry at the master and slave
respectively. Equation (I-8) is the error due to link asymmetry. Equation (I-6) indicates that, in
computing the total asymmetry, the errors due to PHY latency at the master and due to the link are
added, while the error due to PHY latency at the slave is subtracted.

I.7 Characteristics of the noise sources

Each of the sources of noise identified in previous clauses has different characteristics in terms of
modelling and accumulation. As an example, the noise due to cascaded T-BC could be analysed
according to the traditional approach followed in ITU-T for a chain of clocks.
The following clauses analyse the noise sources listed in the table above.
I.7.1 Reference time error
The packet master clock function of the T-GM receives a reference time to distribute. The error can
be attributed to:
GNSS time error. Distribution schemes that use different GNSS systems (e.g., both GPS and future
Galileo) might have an inherent time error due to the difference between the atomic clock ensembles
that drive the systems.
GNSS implementation limitations. A GNSS receiver may produce a time signal that has an offset
from another GNSS receiver that uses the same satellite system.
This noise source is applicable to PRTCs only.
The way the noise source, eref, is modelled is for further study.
I.7.2 PHY latency variation and asymmetry
This noise source is related to the hardware timestamping function, i.e., to the difference between the
timestamp measurement point and the interface to the medium (e.g., [IEEE 802.3] defines the
minimum and maximum transmit and receive values possible for each PHY supporting

24 Rec. ITU-T G.8271/Y.1366 (03/2020)

[IEEE 802.3]). For a proper implementation, this will typically be in the range of nanoseconds. The
PHY latency asymmetry is defined as (dtx–drx)/2, where dtx is the delay on the transmit path and drx is
the delay on the receive path, as indicated in clause I.6 and Figure I.1.
The delays (dtx, drx) discussed here can be further divided into static delays, which may change based
on triggers such as link status reset and power reset, and dynamic delays, which may vary from packet
to packet based on triggers such as varying traffic. Depending on the characteristics of any particular
delay component, it may or may not be possible to measure and compensate for it. Further detail
about the different types of delays involved and their impact on PTP performance of a system is for
further study.
This noise source is applicable to the packet master clock function (in a T-GM or a T-BC) and packet
slave clock function (in a T-BC or in a T-TSC).
The way the noise source, ephy, is modelled is for further study.
I.7.3 Timestamping granularity
The timestamping granularity depends on the rate of the timestamping clock. The timestamping
granularity error is limited in extent by Tts,rx, the increment in the timestamp counter at the receiver:
0  ets  Tts, rx (I-10)

If the timestamping clock rate at the receiver is an integer multiple/submultiple of the rate at the
sender then the beating effect may be observed and the error ets is almost static and cannot be reduced
by the low-pass filtering inherent in phase-locked loops. If the rates are relatively prime then the error
ets is randomized and is well modelled as white noise (flat spectrum).
This noise source is applicable to time-of-arrival measurements at the packet master and packet slave.
The same model may apply for the time-of-departure measurements.
I.7.4 Local oscillator phase noise
The packet slave clock function uses the master timing data as reference to filter out its local reference
phase noise, so as to produce a time error as small as possible. The better the local oscillator, the less
noise it produces. Not all of the phase noise can be filtered out.
This noise source is applicable to the packet slave clock function (in a T-BC or in a T-TSC) when the
frequency is recovered from the PTP messages (i.e., there is no physical layer frequency
synchronization support).
The way the noise source, eφ, is modelled is for further study.
I.7.5 Frequency reference phase error
The packet slave clock function (in a T-BC or in a T-TSC) may use an external frequency reference
instead of its local oscillator to help with the recovery of time. The frequency reference will have
much better timing characteristics than the local oscillator, but it will not be perfect.
This noise source is applicable to packet slave clock.
This noise source, esyncE, is defined by the network limits in clause 9.2 of [ITU-T G.8261]. The way
this noise source is modelled is for further study.
I.7.6 Time transients
Reference switches or short interruptions may cause time transients. Failure in the grandmaster or in
a link may produce network rearrangement. During such period, time error can accumulate due to
some form of holdover functionality.
This noise source is applicable to packet slave clock.

Rec. ITU-T G.8271/Y.1366 (03/2020) 25

The way the noise source, etransient, is modelled is for further study.
I.7.7 Link asymmetry
Packet timing protocols (such as the network time protocol and the precision time protocol (PTP))
measure the round-trip delay through a network, i.e., the delay from a server to a client and back
(or vice versa). The one-way delay is then estimated using the assumption that the forward delay
through a network is the same as the reverse delay. Any difference between the forward and reverse
delay, (known as delay asymmetry), creates an error in the estimate of the client clock's offset from
the server.
The use of full timing support (such as T-BC or T-TC in every node) can eliminate delay asymmetry
due to packet delay variation (PDV), and different traffic load on the two traffic directions and
asymmetry caused by packets taking different routes in each direction (in this case an end-to-end
transparent clock however would not solve the issue). However, it is unable to correct delay
asymmetry on point-to-point links between network elements. This asymmetry arises because the
forward and reverse paths travel down different fibres or copper pairs in the same cable. These fibres
or pairs may have different lengths and different electrical or optical characteristics which are
sufficient to create delay differences.
Delay asymmetry created by fibre links can have several nanoseconds per metre of difference in each
direction. When used over multiple fibre links, the magnitude of this error can become significant
relative to the very tight tolerances required by some of the applications being considered.
The link asymmetry is defined as (dms–dsm)/2, where dms is the delay on the path from the master clock
or responder to the slave clock or requestor, and dsm is the delay on the path from the slave clock or
requestor to the master clock or responder, as indicated in clause I.6 and Figure I.1.
This noise source is applicable to links.
The way the noise source, elink-asym, is modelled is for further study.
I.7.8 Error in distributing time inside a node
This error is due to various internal delays when distributing a time reference from a centralized
location in a node (e.g., system card) to other locations in a node (e.g., line card). This error might be
attributed, for example, to the length of backplane traces, connectors, and various logic functions.
NOTE – These delays might be non-negligible and proper design and compensation should be performed.
This noise source is defined as eintranode, and is for further study. This noise source is applicable to
T-GM, T-BC and T-TSC.

I.8 Time error accumulation in a chain of clocks

The total time error can be viewed as the sum of a constant time error component and a dynamic time
error component.
NOTE – It is assumed that frequency offset and drift components are not present; therefore, only random
components are included in the dynamic time error.
These two components have different characteristics in terms of modelling and accumulation.
See Appendix IV of [b-ITU-T G.8271.1] for further details.

26 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Appendix II

Time and phase end application synchronization requirements

(This appendix does not form an integral part of this Recommendation.)

The following table summarizes the main requirements applicable at the output of the application
(e.g., on the radio interface in the case of wireless application).

Table II.1 – Time and phase end-application requirements

Application/ Accuracy Specification
Technology
CDMA2000 ±3 µs with respect to CDMA System Time, which uses [b-3GPP2 C.S0002]
the GPS timescale (which is traceable and synchronous clause 1.3
to UTC except for leap second corrections). [b-3GPP2 C.S0010]
±10 µs with respect to CDMA System Time for a clause 4.2.1.1
period not less than 8 hours (when the external source
of CDMA system time is disconnected).
TD-SCDMA 3 µs maximum deviation in frame start times between [b-3GPP TS 25.123]
(NodeB TDD any pair of cells on the same frequency that have clause 7.2
mode) overlapping coverage areas.
WCDMA-TDD In TDD mode, to support Intercell Synchronization [b-3GPP TS 25.402]
(NodeB TDD and Handoff, a common timing reference among clauses 6.1.2 and 6.1.2.1
mode) NodeB is required, and the relative phase difference of
the synchronization signals at the input port of any
NodeB in the synchronized area shall not exceed
2.5 s.
W-CDMA 12.8 µs for MBMS over a single frequency network, [b-3GPP TS 25.346]
MBSFN where the transmission of NodeB is closely time clauses 7.1A and 7.1B.2.1
synchronized to a common reference time.
LTE MBSFN The cell phase synchronization accuracy measured at [b-3GPP TS 36.133]
BS antenna connectors shall be better than 5 s. clause 7.25.2
W-CDMA Microsecond level accuracy (no hard requirement [b-3GPP TR 25.866]
(Home NodeB listed). clause 8
TDD mode)
WiMAX 1) The downlink frames transmitted by the serving [b-IEEE 802.16]
base station and the Neighbour base station shall be Table 6-160,
synchronized to a level of at least 1/8 cyclic prefix clause 8.4.13.4
length (which is equal to 1.428 µs).
[b-WMF T23-001]
At the base station, the transmitted radio frame shall
clause 4.2.2
be time-aligned with the 1PPS timing pulse.
2) The base station transmit reference timing shall be
time-aligned with the 1PPS pulse with an accuracy
of ± 1 µs.
LTE-TDD 3 µs for small cell (< 3 km radius). [b-3GPP TS 36.133]
(Wide-Area Base 10 µs for large cell (> 3 km radius). clause 7.4.2
station) maximum absolute deviation in frame start timing
between any pair of cells on the same frequency that
have overlapping coverage areas.

Rec. ITU-T G.8271/Y.1366 (03/2020) 27

 Table II.1 – Time and phase end-application requirements
Application/ Accuracy Specification
Technology
LTE-TDD 1) 3 µs for small cell (< 500m radius). For large cell [b-3GPP TS 36.133]
(home-area base (> 500 m radius), 1.33 + Tpropagation s time clause 7.4.2
station) difference between base stations, [b-3GPP TR 36.922]
where Tpropagation is the propagation delay between clause 6.4.1.2
the Home base station and the cell selected as the
network listening synchronization source. In terms
of the network listening synchronization source
selection, the best accurate synchronization source
to GNSS should be selected. If the Home base
station obtains synchronization without using
network listening, the small cell requirement
applies.
2) The requirement is 3.475 µs but in many scenarios
a 3 µs sync requirement can be adopted.
LTE-TDD to eNB shall be synchronized to GPS time. With external [b-3GPP TS 36.133]
CDMA 1xRTT source of CDMA system time disconnected, the eNB clause 7.5.2.1
and HRPD shall maintain the timing accuracy within ±10 µs with
handovers respect to CDMA system time for a period of not less
than 8 hours.
NR TDD The cell phase synchronization accuracy measured at [b-3GPP TS 38.133]
BS antenna connectors shall be better than 3 µs. clause 7.4.2
IP network delay The requirement depends on the level of quality that No standard requirement is
monitoring shall be monitored. As an example ±100 µs with currently defined.
respect to a common time reference (e.g., UTC) may Requirements are operator
be required. ±1 ms has also been mentioned. dependent (depending on
the application).
Billing and alarms ±100 ms with respect to a common time reference
(e.g., UTC).
NOTE 1 – In the case of mobile applications, the requirements are generally expressed in terms of phase
error between base stations. In the case of a centralized master, the requirement could be expressed as ±
half of the accuracy requirement applicable to the specific technology.
NOTE 2 – The requirements are generally valid during normal conditions. The applicable requirements
during failure conditions are for further study.

Table II.2 – Other time and phase requirements

Typical applications Synchronization Specification
(for information) requirements
(MRTD or TAE)
(Note 1)
LTE asynchronous dual connectivity (Note: applicable No network [b-3GPP TS 36.133]
only for FDD–FDD inter-band dual connectivity). synchronization clause 7.15.2
requirement
(Note 2)
LTE synchronous dual connectivity. 33 µs MRTD [b-3GPP TS 36.133]
clauses 7.13 and 7.15.2

28 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Table II.2 – Other time and phase requirements
Typical applications Synchronization Specification
(for information) requirements
(MRTD or TAE)
(Note 1)
Inter-band asynchronous EN-DC (E-UTRAN NR Dual No network [b-3GPP TS 38.133]
Connectivity) (Note 3) synchronization clause 7.6.2
requirement
(Note 2)
Inter-band synchronous EN-DC (E-UTRAN NR Dual 33 µs MRTD [b-3GPP TS 38.133]
Connectivity) (Note 3). clause 7.6.2
NR Inter-band carrier aggregation. 33µs MRTD (FR1) [b-3GPP TS 38.133]
8 µs MRTD (FR2) clause 7.6.4
25µs MRTD (FR1-
FR2)
(Notes 4)
NR Intra-band synchronous EN dual connectivity 3 µs MRTD [b-3GPP TS 38.133]
(Note: applicable for E-UTRA TDD – NR TDD and (Note 6) clause 7.6.3
E-UTRA FDD – NR FDD).
NR Inter-band carrier aggregation; with or without 3 µs TAE [b-3GPP TS 38.104]
MIMO or TX diversity. clauses 9.6.3.2, 9.6.3.3
NR Intra-band non-contiguous carrier aggregation, 3 µs TAE (FR1) [b-3GPP TS 38.104]
with or without MIMO or TX diversity. 260ns TAE (FR2) clauses 9.6.3.2, 9.6.3.3
(Note 7)
NR Intra-band contiguous carrier aggregation, with or 260 ns TAE (FR1) [b-3GPP TS 38.104]
without MIMO or TX diversity. 130 ns TAE (FR2) clauses 9.6.3.2, 9.6.3.3
(Notes 4, 7, 8)
LTE Intra-band non-contiguous carrier aggregation 260 ns TAE [b-3GPP TS 36.104]
with or without MIMO or TX diversity, and inter-band (Notes 9, 10) clause 6.5.3.1
carrier aggregation with or without MIMO or TX
diversity.
LTE Intra-band contiguous carrier aggregation, with or 130 ns TAE [b-3GPP TS 36.104]
without MIMO or TX diversity. (Notes 8, 9) clause 6.5.3.1
Location-based services using OTDOA. x ns
(Note 11)
NR MIMO or TX diversity transmissions, at each 65 ns TAE [b-3GPP TS 38.104]
carrier frequency. (Notes 5, 8) clauses 9.6.3.2, 9.6.3.3
LTE MIMO or TX diversity transmissions, at each 65 ns TAE [b-3GPP TS 36.104]
carrier frequency. (Notes 5, 8) clause 6.5.3.1

Rec. ITU-T G.8271/Y.1366 (03/2020) 29

 Table II.2 – Other time and phase requirements
Typical applications Synchronization Specification
(for information) requirements
(MRTD or TAE)
(Note 1)
NOTE 1 – The synchronization requirements in the 3GPP specifications are expressed in terms of either
maximum received timing difference (MRTD) or time alignment error (TAE):
– In case of dual connectivity, MRTD concerns the maximum absolute timing mismatch between
subframes which are transmitted by Master eNB/gNB (MeNB/MgNB) and Secondary eNB/gNB
(SeNB/SgNB) and are scheduled for the same user equipment (UE). For carrier aggregation, MRTD is
between the Primary Cell (PCell) and Secondary Cell (SCell). This means that part of this budget
should be allocated to propagation time difference between MeNB/MgNB and SeNB/SgNB (in case of
dual connectivity) or between PCell and SCell (in case of carrier aggregation). As an example, a 9 km
propagation difference accounts for approximately 30 µs, which leaves 3 µs time error between the
eNBs. A 7 km propagation difference accounts for approximately 23 µs, which leaves 10 µs time error
between the eNBs. The same is applicable for NR.
– TAE is defined in [b-3GPP TS 36.104] and [b-3GPP TS 38.104] as the largest timing difference
between any two radio signals at the antenna connectors of the base stations. For further details, refer
to the relevant 3GPP specifications. In ITU-T terminology, this is equivalent to the maximum relative
time error between the two radio signals.
NOTE 2 – For asynchronous dual connectivity there is no network synchronization requirement implied
for the base stations. The MRTD values indicated in the 3GPP specification are tolerance requirements on
the UE to accept MRTD of up to half of the corresponding time slot length (e.g., half of 1 ms). This is the
maximum possible delay difference, since if it is larger than this, the next time slot would be referenced.
NOTE 3 – For inter-band dual connectivity, it is mandatory for the UE to support the asynchronous mode.
For intra-band FDD-FDD dual connectivity, it is optional for the UE to support asynchronous mode.
NOTE 4 – FR1: 410 MHz – 7.125 GHz; FR2: 24.25 – 52.6 GHz.
NOTE 5 – The 65ns TAE requirement for MIMO and TX Diversity is an internal equipment specification,
and does not result in a requirement on the transport network.
NOTE 6 – Intra-band synchronous EN-DC is defined for co-located deployments only (therefore no
budget related to the propagation time differences is allocated to the MRTD in this case).
NOTE 7 – For NR intra-band carrier aggregation, only co-located deployment is applicable.
NOTE 8 – The requirement assumes co-located deployments (e.g., antennas installed on the same roof).
NOTE 9 – Although phase/time accuracy requirements for CA and CoMP are generic and are not defined
for any particular network topology, this level of phase error budget in general could be achieved by
antennas that are co-located with or connected to the same base band unit (BBU) or centralized unit/
distributed unit (CU/DU) via direct links. The support of some of these synchronization requirements for
scenarios where the antennas are neither co-located (e.g., as related to Inter-site carrier aggregation) nor
connected via direct links to the same BBU or CU/DU is for further study.
NOTE 10 – For the cases of LTE Intra-band non-contiguous carrier aggregation and inter-band carrier
aggregation, MRTD requirements are also provided (30.26 µs, see [b-3GPP 36.133] clauses 7.9.2 and
7.9.3).
NOTE 11 – The synchronization accuracy requirements depends on the applicable location accuracy
requirements. As an example, to achieve a location accuracy of 40-60m, a max|TER| of 200ns is required
when using OTDOA with a minimum of three basestations as per [b-3GPP TR 37.857]

30 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Appendix III

Asymmetry compensation for use of different wavelengths

(This appendix does not form an integral part of this Recommendation.)

The compensation of asymmetry due to the use of different wavelengths is obtained by calculating
the group delay applicable to wavelengths used in the forward and in the reverse direction.
Indicating with A the asymmetry, the following applies:
A = df – dr = L * (nr – nf)/c
Where L is the distance, c is the speed of light, df and dr are the forward and reverse transmission
delay, and nr and nf are the group refractive indexes applicable at the wavelength used in the forward
and reverse direction, respectively.
The evaluation of the refractive indexes can be done either using known chromatic dispersion data
(e.g., from the optical fibre data-sheet) or, in the case that the dispersion in unknown, making a direct
delay measurement at three different wavelengths (the refractive index for an arbitrary wavelength
can then be derived by quadratic interpolation).
These data can then be used to derive the group delay of a generic wavelength. In particular, in the
case of an ITU-T G.652 compliant fibre, the group delay at the applicable wavelengths can be
calculated making use of the Sellmeier equations as described in [b-ITU-T G.652].

Rec. ITU-T G.8271/Y.1366 (03/2020) 31

 Appendix IV

Link and network asymmetry compensation

(This appendix does not form an integral part of this Recommendation.)

In order to compensate for link delay asymmetry, it might be desirable to have in place some
automatic link asymmetry calibration procedure. This could be based on calculating the propagation
delays by means of two-way measurements made on the fibres used by the traffic.
The procedure can be done separately on both fibres (in the fibre used in the forward direction and in
the fibre used for the reverse direction) providing the forward propagation delay df and the reverse
propagation delay dr. This is shown in Figure IV.1.

Figure IV.1 – Link asymmetry calibration process (performed separately on both fibres)

Alternatively, the round trip measurement could be done in two steps on both fibres by reversing the
direction of transmission. This is shown in Figure IV.2.

Figure IV.2 – Link asymmetry calibration process (performed on both fibres

at the same time)
NOTE 1 – In the case of the connection between master and slave, as shown in Figure I.1, the following would
apply:
df = dms
dr = dsm
The link asymmetry calibration mechanism must meet an accuracy objective for df and dr estimations.
This limit is for further study.

32 Rec. ITU-T G.8271/Y.1366 (03/2020)

NOTE 2 – In the case during the asymmetry calculation procedure where one node enters holdover
(e.g., caused by the fibres-swapping if this is required by the procedure), the effect of the frequency holdover
needs to be taken into account as it might impact the accuracy of the measurement.
Several implementations are possible, e.g., based on optical switches or fixed or tunable add drop
filters. Depending on the implementation, it may not be required to interrupt the traffic during the
calibration process and hence in-service operation might be possible. However, the asymmetry
compensation is a process that is only required at start-up or during rearrangements in the network.
This measurement is applicable for wavelength-division-multiplexing (WDM) systems
(including optical transport network (OTN)) and non-WDM systems. In the case of
wavelength-division-multiplexing systems, this measurement should also take into account possible
delay due to dispersion-compensating fibre (DCF).
NOTE 3 – In the case of WDM systems, the asymmetry due to the use of different wavelengths in the two
directions should also be taken into account. Indeed, the use of different wavelengths on the two fibres,
(or in a single fibre in the case of a transmission system using a single fibre), would result in different delays
even if the fibres have the same length. Note also that a compensation related to the same aspect would be
required if the wavelength used during the link asymmetry calibration process is different from the wavelength
used by the traffic. Suitable methodologies to address this point are introduced in Appendix III.
The difference (df – dr) can be used in the evaluation of the delay asymmetry to be used in the time
recovering process. In particular the delayAsymmetry parameter as defined in clause 7.4 of
[IEEE 1588] would be half of that difference.
NOTE 4 – If a T-BC is implemented in every node, the compensation can be triggered directly by the T-BC,
which would know the difference (df – dr). If this is not the case, some means have to be provided in order to
make the difference (df – dr) available at the points in the network where the precision time protocol (PTP)
messages are processed. This is for further study.
NOTE 5 – In the case of a time synchronization carried by PTP, the PTP connection may have asymmetry due
to a variety of reasons, including network paths, loading levels or cable lengths. The asymmetry of a PTP
connection may be evaluated at a PTP network element, if the network element has access to a second time
synchronization source that is not significantly impacted by asymmetry (such as a GNSS receiver, or a time
synchronization reference carried via timing protocols such as PTP with proper accuracy) as shown in
Figure IV.3. If the asymmetry of the PTP connection is evaluated using such a second time synchronization
source, then the offset caused by the asymmetry may be compensated by the network element. The same
principle could be applied between network elements in a chain.

Figure IV.3 – PTP slave evaluating PTP connection asymmetry

There are cases when asymmetry is generally static but can change over time due to rare network
rearrangements, or the re-start of network nodes. This could happen, for example, in the case of OTN

Rec. ITU-T G.8271/Y.1366 (03/2020) 33

networks. In these cases, it has been reported that clients carried over OTN may be impacted by
changes in the asymmetry whenever a network node is re-started or there are network rearrangements.
These can be considered relatively rare events (e.g., in the order of weeks/months), but with an impact
that could be on the order of microseconds. Similar events may happen in packet networks
(e.g., re-routing).
These cases can be referred to as "semi-static asymmetry".
For these cases, assuming the phase change in one of the references is sufficiently large compared
with the relevant level of accuracy (see Table 1), and sufficiently fast compared with the relevant
clock bandwidth, changes in semi-static asymmetry may be controlled when at least 2 independent
timing references are available, with the assumptions that only one at the time is impacted by such
changes. This is illustrated in Figure IV.4.
In this example, it is assumed that the asymmetry from all links is first compensated at the start-up
by means of a trusted synchronization reference (e.g., via temporary connection to a GNSS reference,
or via availability of the GNSS reference as a regular synchronization input).

Figure IV.4 – Monitoring of semi-static asymmetry

The PTP network in this example could be based on full timing support or (assisted) partial timing
support.
Assuming only one reference at the time is impacted by changes of network asymmetry (and that, as
mentioned earlier, the phase step is sufficiently large and fast), the second reference (not experiencing
significant and sudden changes of the relevant parameters, e.g., meanPathDelay, offsetFromMaster)
can be used to correct for changes in asymmetry and/or issue an alarm. This may assume that full
exchange of PTP messages is present also on the PTP port which is not in the SLAVE state.
The correction for asymmetries during normal operation requires proper operation in the slave as to
control phase transients, according to the relevant clock specification.
NOTE 6 – Correction for asymmetry may not be sufficiently accurate after several compensations. Therefore,
recalibration with a trusted source would be required.
NOTE 7 – The PTP slave shown in Figures IV.3 and IV.4 could be implemented in a T-BC (i.e., there could
be downstream nodes connected to the node correcting for asymmetries in the network).
NOTE 8 – The procedures for scheduled or on-demand measurement of asymmetry are for further study.

34 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Appendix V

Delay asymmetry resulting from interface rate change in PTP-unaware

network elements
(This appendix does not form an integral part of this Recommendation.)

In case the master and slave are not connected to a PTP aware network element (e.g., boundary clock
(BC) or transparent clock (TC)) and are not using the same Ethernet line speed, a delay asymmetry
can be generated due to the "store and forwarding" nature of Ethernet switches, meaning the switch
needs to receive the entire frame before starting transmission on port with a faster line speed, to ensure
that the packet data is available for transmission. The minimal time necessary to transfer the packet
across the switch depends on the length of the packet and the ingress line rate. Sync and Delay_Req
PTP packets have been defined to have the same length in order to reduce delay asymmetry caused
by different transition delay, however Ethernet speed mismatch will generate asymmetry.
The expected asymmetry can be estimated based on the PTP event message packet size and interfaces
speed.
In case the static asymmetry caused by the speed mismatch is known, it can be compensated by the
slave using asymmetric delay compensation mechanism defined in [IEEE 1588], clause 11.6.
The following example is used to illustrate the asymmetry generated by a speed mismatch:
– packet format uses UDP/IPv4/Ethernet header, giving total packet size of 86 bytes
(excluding preamble and FCS);
– preamble is 8 bytes;
– FCS is 4 bytes;
– PTP Grand Master timestamp event interface is GE (1000 Mbit/s);
– PTP slave timestamp event interface is FE (100 Mbit/s);
– the packet switched network (PSN) delay is assumed to be symmetrical.

Rec. ITU-T G.8271/Y.1366 (03/2020) 35

 Figure V.1 – Speed mismatch example

This yields the following equation for delay between the timestamp event points.
In the forward direction from the master to the slave, the delay between the timestamp event points
is:
t 2 = ( LPKT + LFCS )bytes  8bits / byte  GEns / bit + DPSN + ( LPr e − amble )bytes  8bits / byte  FEns / bit +t1 (V-1)

In the reverse direction from the slave to the master, the delay between the timestamp event points is:
t 4 = ( LPKT + LFCS )bytes  8bits / byte  FEns / bit + DPSN + ( LPr e − amble )bytes  8bits / byte  GEns / bit +t 3 (V-2)

The <meanPathDelay> formula from equation (V-2) is:

 meanPathDelay  =
(t 2 − t1) + (t 4 − t 3) (V-3)
2
Substituting (t 2 − t1) for equation (V-1) and (t 4 − t 3) for equation (V-2) then:
( LPKT + LFCS + LPr e − amble )  8  (GE + FE )ns + 2  DPSN
 meanPathDelay  = (V-4)
2
GE + FE
 meanPathDelay  = ( LPKT + LFCS + LPr e − amble )  8  + DPSN (V-5)
2 ns

By convention the <delayPathAsymmetry> is positive when the forward path is longer than the
reverse path.
The delay path asymmetry is then the difference between equations (V-1) and (V-5).
GE − FE FE − GE
 delayPathAsymmetry  =( LPKT + LFCS )  8  ( )ns + ( LPr e − amble )  8  ( )ns (V-6)
2 2
or as the difference between equations (V-5) and (V-2)

36 Rec. ITU-T G.8271/Y.1366 (03/2020)

 GE − FE FE − GE
 delayPathAsymmetry  =( LPKT + LFCS )  8  ( )ns + ( LPr e − amble )  8  ( )ns (V-7)
2 2
Substituting for real values into equation (V-6) we obtain:
1 − 10 10 − 1
 delayPathAsymmetry  =(86 + 4)  8  ( )ns + (8)  8  ( )ns
2 2
 delayPathAsymmetry  = − 2952ns

The general term for the delay asymmetry caused by the speed mismatch:
VMaster − VSlave V − VSlave
 delayPathAsymmetry  =( LPKT + LFCS )  8  ( ) + ( LPre−amble )  8  ( Master ) (V-8)
2 2
Where:
LPKT is the length of the packet (excluding the preamble and FCS) in bytes
LFCS is the length of the packet FCS in bytes
LPre −amble is the length of the packet preamble in bytes
VMaster is the timestamp interface bit period on the PTP Master Clock in seconds/bit
VSlave is the timestamp interface bit period on the PTP Slave Clock in seconds/bit

Rec. ITU-T G.8271/Y.1366 (03/2020) 37

 Appendix VI

Time synchronization aspects in TDD based mobile communication systems

(This appendix does not form an integral part of this Recommendation.)

In TDD-based mobile communication systems (hereafter, TDD systems), uplink (UL) signals which
are transmitted from user equipment (UE) to base stations (BS), and downlink (DL) signals which
are transmitted in the opposite direction, are multiplexed along the time axis alternately on a common
frequency channel. Interference in TDD systems occur when signals from adjacent cells overlap a
UL time slot at a base station or DL time slot at a UE.
Synchronization errors at a single base station can lead to performance degradation of neighbouring
base stations, whether the base stations are of the same operator or different operators. This is due to
the interference caused by the neighbouring base station. Hence, in TDD systems, it is essential that
base stations receive accurate synchronization.
The frequency allocation for TDD systems operated by multiple mobile operators usually includes
guard frequency bands between frequency bands assigned to different operators to avoid interferences
resulting from spurious noises as shown in Figure VI.1. If TDD systems are operated without guard
frequency bands, not only intra-operator time synchronization but also inter-operator time
synchronization to a common timing standard is required. One possibility is to make it explicit that
the reference must be traceable to a specific common recognized time standard source. Co-ordinated
Universal Time (UTC) might be a good candidate. In fact, as per Recommendation [b-ITU-R TF.460]
all standard-frequency and time-signal emissions should conform to UTC. Further information is
provided in [b-3GPP TS 38.401].
NOTE – Given the 3GPP requirement for a continuous timescale, the actual implementation in this case could
make use of the content of the distributed UTC information that is not impacted by leap seconds, e.g., GPS
time in case the reference is carried by a GPS signal.
It should be mentioned that in addition to having synchronization references traceable to a common
recognized time standard source, adopting common TDD signal frame patterns is also required.

Figure VI.1 – Examples of frequency allocation for TDD systems with and without guard
frequency bands

VI.1 An overview of radio-interference in TDD systems

As shown in Figure VI.2, TDD systems have two types of interference conditions: BS-to-BS and
UE-to-UE. Interferences occur in TDD systems due to propagation delay of signals in each scenario
described below. The propagation delay of a DL signal is higher in large cells than in small cells.

38 Rec. ITU-T G.8271/Y.1366 (03/2020)

Moreover, the propagation delay of a DL signal is not proportional to the cell radius in inter-operator
interference, unlike in intra-operator interferences as shown in Figure VI.3. Thus, in addition to the
relative time error between cells, there are other aspects that should be considered regarding the
occurrence of interferences in TDD systems.

Figure VI.2 – Overview of interference patterns in TDD systems

Figure VI.3 – Relationship between intra- and inter-operator interference

VI.2 Signal frame format of TDD systems

Guard periods (GPs) in the signal frame format of TDD systems are provided at the switching point
around DL-to-UL and UL-to-DL switching as shown in Figure VI.4. Guard periods are not used for
signal transmission but contribute to reducing interference during DL to UL switching. TDL_UL is

Rec. ITU-T G.8271/Y.1366 (03/2020) 39

defined to allow sufficient time for the BTS and UE transceivers to switch between sending and
receiving. The guard period allocated for UL to DL switching is guaranteed by the TAoffset,
which is added to the RF air delay-dependent timing advance (see [b-3GPP TS 38.211] and
[b-3GPP TS 38.133]) for controlling the transmission timing of the UL radio frames.

Figure VI.4 – Signal frame format of TDD systems

VI.3 Base station to base station interference

VI.3.1 Downlink to uplink switching point
The time synchronization error between base stations (TSync) is defined as the timing error at the
Antenna Reference Point (ARP). If the propagation time between interfering and interfered base
stations is represented as Tprop_BS2BS, and power ramp-down time at the base station transmitter as
Tbts_rampdown, BS-to-BS interference at DL-to-UL switching occurs under the following condition
(see Figure VI.5):
TSync > TDL_UL – Tprop_BS2BS – Tbts_rampdown (VI-1)

Figure VI.5 – BS to BS interference at DL to UL switching point

Note that the interference decays as the path loss increases with increased Tprop_BS2BS, so that at after
certain distance it will not be significant.
VI.3.2 Uplink to downlink switching point
BS-to-BS interference at the UL-to-DL switching point occurs under the following condition where
Tbts_rampup is the power ramp-up time at the base station transmitter (see Figure VI.6):
Tsync > TAoffset + Tprop_BS2BS – Tbts_rampup (VI-2)
Propagation delay may take a smaller value in inter-operator interference than in intra-operator
interference, so this type of interference may have a greater possibility of occurring.

40 Rec. ITU-T G.8271/Y.1366 (03/2020)

 Figure VI.6 – BS to BS interference at UL to DL switching point

VI.4 User equipment to user equipment interference

Reachability of the signal from interfering UE to interfered UE is lower in the case of UE-to-UE
interference than in the case of BS-to-BS interference. Thus, only the condition under which both
UEs are located close to the cell edge can cause intra-operator interferences. On the other hand,
UE-to-UE interference may occur anywhere in the cell in the case of inter-operator interference.
Similar relationships can be derived for BS-to-BS interference, where time synchronization error
between base stations exceeding a certain threshold would cause interference between the UEs.

Rec. ITU-T G.8271/Y.1366 (03/2020) 41

 Appendix VII

Time scales
(This appendix does not form an integral part of this Recommendation.)

This appendix gives some introductions on time scales and the relationship between them.

VII.1 Time scales

Universal Time (UT)
UT is a time standard based on Earth's rotation. It is a modern continuation of Greenwich Mean Time
(GMT), i.e., the mean solar time on the Prime Meridian at Greenwich, England. UT1 is the principal
form of UT with the Earth Rotation Angle (ERA) adjustment.
A mean solar day is 24 mean solar hours, and is 86400 mean solar seconds, which means a UT second
is 1/86400 of a mean solar day.
International Atomic Time (TAI)
In October 1967, the General Conference on Weights and Measures redefined the International
System of Units (SI) second to be based on the hyperfine resonance of Cesium. The latest definition
of SI second is provided in [b-SI System] published by the International Bureau of Weights and
Measures (BIPM).
International Atomic Time (TAI) is a continuous time scale counted with the SI second, with the
latest definition also provided in [b-SI System]. The beginning time or epoch of TAI is 0h 1st Jan.
1958 (UT), which means that TAI was synchronized with UT at the time. The two timescales have
drifted apart ever since, due to the irregular rotation of Earth.
TAI is maintained by the BIPM using data from some 400 atomic clocks in over 80 national
laboratories that maintain the best primary Cesium standards.
Coordinated Universal Time (UTC)
TAI is a uniform metering system, which is very important for measuring time intervals. UT, on the
other hand, always reflects the position of Earth in space, and corresponds to the four seasons and
day and night. It is a time that is familiar in daily life. To balance these two needs, UTC was
introduced.
UTC time includes two concepts:
– UTC second is TAI second, i.e., SI second as measured using Cesium atoms;
– UTC day is UT day, i.e., mean solar day as measured by the rotation of the earth.
UTC is based on TAI with leap seconds added at irregular intervals to compensate for the slowing
rotation of Earth. Leap seconds keep UTC within 0.9 second of UT1. The dates of application of the
leap second are decided by the International Earth Rotation Service (IERS).
NOTE – This means that the UT second has a longer duration to the SI second used in the TAI and
UTC timescales.
UTC is also maintained by the BIPM. Physical realizations of UTC, UTC(k), are maintained in
national metrology institutes or observatories contributing with their clock data to the BIPM. These
time laboratories then use UTC to steer their clock. Values of UTC-UTC(k) at five-day intervals are
published in the monthly BIPM Circular T [b-Circular-T], which gives official traceability of UTC
to its representations UTC(k).

42 Rec. ITU-T G.8271/Y.1366 (03/2020)

[b-ITU-R TF.460] recommends that all standard-frequency and time-signal emissions should
conform to UTC.

VII.2 Relationship between time scales

The atomic time scales TAI and UTC are disseminated monthly through the BIPM Circular T
[b-Circular-T]. After the leap second on 1st January 2017, the difference between the time scales
was 37s.

Rec. ITU-T G.8271/Y.1366 (03/2020) 43

 Bibliography

[b-ITU-T G.652] Recommendation ITU-T G.652 (2016), Characteristics of a single-mode

optical fibre and cable.
[b-ITU-T G.8271.1] Recommendation ITU-T G.8271.1/Y.1366.1 (2020), Network limits for
time synchronization in packet networks.
[b-ITU-T G.8271.2] Recommendation ITU-T G.8271.2/Y.1366.2 (2017), Network limits for
time synchronization in packet networks with partial timing support from
the network.
[b-ITU-R TF.460] Recommendation ITU-R TF.460 (2002), Standard-frequency and time-
signal emissions.
[b-IEEE 802.16] IEEE 802.16-2017, IEEE Standard for Air Interface for Broadband
Wireless Access Systems.
https://standards.ieee.org/standard/802_16-2017.html

[b-WMF T23-001] WMF-T23-001-R015v03 (2012), WiMAX Forum® Air Interface

Specifications – Mobile System Profile Specification – Common Part.
<http://wimaxforum.org/sites/wimaxforum.org/files/technical_document/2012/04/WMF-T23-001-
R015v03_MSP-Common-Part.pdf>

[b-3GPP TR 25.836] 3GPP TR 25.836 (2001), Node B synchronization for TDD.

https://itectec.com/archive/3gpp-specification-tr-25-836/

[b-3GPP TR 25.866] 3GPP TR 25.866 (2010), 1.28 Mcps TDD Home NodeB (HNB) study item
technical report.
https://itectec.com/archive/3gpp-specification-tr-25-866/

[b-3GPP TR 36.814] 3GPP TR 36.814 (2017), Evolved Universal Terrestrial Radio Access
3GPP TS 25.123 (2019 (E-UTRA); Further advancements for E-UTRA
physical layer aspects.
https://itectec.com/archive/3gpp-specification-tr-36-814/

[b-3GPP TR 36.922] 3GPP TR 36.922 (2018), Evolved Universal Terrestrial Radio Access
(E-UTRA); TDD Home eNode B (HeNB) Radio Frequency (RF)
requirements analysis.
https://itectec.com/archive/3gpp-specification-tr-36-922/

[b-3GPP TR 37.857] 3GPP TR 37.857 (2016), Study on indoor positioning enhancements for
UTRA and LTE.
https://itectec.com/archive/3gpp-specification-tr-37-857/

[b-3GPP TS 25.123] 3GPP TS 25.123 (2019), Requirements for support of radio resource
management (TDD).
https://itectec.com/archive/3gpp-specification-ts-25-123/

[b-3GPP TS 25.346] 3GPP TS 25.346 (2018), Introduction of the Multimedia

Broadcast/Multicast Service (MBMS) in the Radio Access Network
(RAN); Stage 2.
https://www.etsi.org/deliver/etsi_ts/125300_125399/125346/15.00.00_60/ts_125346v150000p.pdf

[b-3GPP TS 25.402] 3GPP TS 25.402 (2018), Universal Mobile Telecommunications Systems

(UMTS); Synchronization in UTRAN Stage 2.
https://www.etsi.org/deliver/etsi_ts/125400_125499/125402/15.00.00_60/ts_125402v150000p.pdf

[b-3GPP TS 36.104] 3GPP TS 36.104 (2019), LTE; Evolved Universal Terrestrial Radio
Access (E-UTRA); Base Station (BS) radio transmission and reception.
https://www.etsi.org/deliver/etsi_ts/136100_136199/136104/15.05.00_60/ts_136104v150500p.pdf

44 Rec. ITU-T G.8271/Y.1366 (03/2020)

[b-3GPP TS 36.133] 3GPP TS 36.133 (2019), LTE; Evolved Universal Terrestrial Radio
Access (E-UTRA); Requirements for support of radio resource
management.
https://www.etsi.org/deliver/etsi_ts/125400_125499/125402/15.00.00_60/ts_125402v150000p.pdf

[b-3GPP TS 38.104] 3GPP TS 38.104 (2019), 5G; NR; Base Station (BS) radio transmission
and reception.
https://www.etsi.org/deliver/etsi_ts/138100_138199/138104/15.05.00_60/ts_138104v150500p.pdf

[b-3GPP TS 38.133] 3GPP TS 38.133 (2019), 5G; NR; Requirements for support of radio
resource management.
https://www.etsi.org/deliver/etsi_ts/138100_138199/138133/15.06.00_60/ts_138133v150600p.pdf

[b-3GPP TS 38.211] 3GPP TS 38.211 (2019), 5G; NR; Physical channels and modulation.
https://www.etsi.org/deliver/etsi_ts/138200_138299/138211/15.02.00_60/ts_138211v150200p.pdf

[b-3GPP TS 38.401] 3GPP TS 38.401(2019), 5G; NG-RAN; Architecture description.

https://www.etsi.org/deliver/etsi_ts/138400_138499/138401/15.05.00_60/ts_138401v150500p.pdf

[b-3GPP2 C.S0002] 3GPP2 C.S0002-F v2.0 (2014), Physical layer standard for cdma2000
Spread Spectrum Systems.
https://www.3gpp2.org/Public_html/Specs/C.S0002-D_v2.0_051006.pdf

[b-3GPP2 C.S0010] 3GPP2 C.S0010-E v2.0 (2014), Recommended Minimum Performance

Standards for cdma2000 Spread Spectrum Base Stations.
http://www.arib.or.jp/english/html/overview/doc/STD-T64v7_00/Specification/ARIB_STD-T64-
C.S0010-Ev2.0.pdf

[b-SI System] BIPM, 9th Edition (2019), The International System of Units.
<https://www.bipm.org/en/publications/si-brochure/>

[b-Circular-T] BIPM, Circular -T (published monthly).

https://www.bipm.org/en/bipm-services/timescales/time-ftp/Circular-T.html>

Rec. ITU-T G.8271/Y.1366 (03/2020) 45

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

GLOBAL INFORMATION INFRASTRUCTURE

General Y.100–Y.199
Services, applications and middleware Y.200–Y.299
Network aspects Y.300–Y.399
Interfaces and protocols Y.400–Y.499
Numbering, addressing and naming Y.500–Y.599
Operation, administration and maintenance Y.600–Y.699
Security Y.700–Y.799
Performances Y.800–Y.899
INTERNET PROTOCOL ASPECTS
General Y.1000–Y.1099
Services and applications Y.1100–Y.1199
Architecture, access, network capabilities and resource management Y.1200–Y.1299
Transport Y.1300–Y.1399
Interworking Y.1400–Y.1499
Quality of service and network performance Y.1500–Y.1599
Signalling Y.1600–Y.1699
Operation, administration and maintenance Y.1700–Y.1799
Charging Y.1800–Y.1899
IPTV over NGN Y.1900–Y.1999
NEXT GENERATION NETWORKS
Frameworks and functional architecture models Y.2000–Y.2099
Quality of Service and performance Y.2100–Y.2199
Service aspects: Service capabilities and service architecture Y.2200–Y.2249
Service aspects: Interoperability of services and networks in NGN Y.2250–Y.2299
Enhancements to NGN Y.2300–Y.2399
Network management Y.2400–Y.2499
Network control architectures and protocols Y.2500–Y.2599
Packet-based Networks Y.2600–Y.2699
Security Y.2700–Y.2799
Generalized mobility Y.2800–Y.2899
Carrier grade open environment Y.2900–Y.2999
FUTURE NETWORKS Y.3000–Y.3499
CLOUD COMPUTING Y.3500–Y.3999
INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES
General Y.4000–Y.4049
Definitions and terminologies Y.4050–Y.4099
Requirements and use cases Y.4100–Y.4249
Infrastructure, connectivity and networks Y.4250–Y.4399
Frameworks, architectures and protocols Y.4400–Y.4549
Services, applications, computation and data processing Y.4550–Y.4699
Management, control and performance Y.4700–Y.4799
Identification and security Y.4800–Y.4899
Evaluation and assessment Y.4900–Y.4999

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 Tariff and accounting principles and international telecommunication/ICT economic and
policy issues

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 Environment and ICTs, climate change, e-waste, energy efficiency; 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 Telephone transmission quality, telephone installations, local line networks

Series Q Switching and signalling, and associated measurements and tests

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, next-generation networks,

Internet of Things and smart cities

Series Z Languages and general software aspects for telecommunication systems

Printed in Switzerland
Geneva, 2020