ITUPublications International Telecommunication Union

Recommendations Standardization Sector

Recommendation
ITU-T G.8275 (01/2024)

SERIES G: Transmission systems and media, digital

systems and networks
Packet over Transport aspects – Synchronization, quality
and availability targets

Architecture and requirements for packet-

based time and phase distribution
 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 ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH G.400-G.449
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
Mobile network transport aspects G.8300-G.8399
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.8275

Architecture and requirements for packet-based time and phase distribution

Summary
Recommendation ITU-T G.8275 describes the architecture and requirements for packet-based time
and phase distribution in telecom networks. The architecture described is mainly applicable to the use
of IEEE 1588. Details necessary to utilize IEEE 1588 in a manner consistent with the architecture are
defined in other Recommendations.

History*
Edition Recommendation Approval Study Group Unique ID
1.0 ITU-T G.8275/Y.1369 2013-11-22 15 11.1002/1000/12011
1.1 ITU-T G.8275/Y.1369 (2013) Amd. 1 2015-01-13 15 11.1002/1000/12396
1.2 ITU-T G.8275/Y.1369 (2013) Amd. 2 2016-04-13 15 11.1002/1000/12814
2.0 ITU-T G.8275/Y.1369 2017-08-13 15 11.1002/1000/13328
2.1 ITU-T G.8275/Y.1369 (2017) Amd. 1 2018-11-29 15 11.1002/1000/13771
2.2 ITU-T G.8275/Y.1369 (2017) Amd. 2 2019-08-29 15 11.1002/1000/14016
3.0 ITU-T G.8275/Y.1369 2020-10-29 15 11.1002/1000/14509
3.1 ITU-T G.8275/Y.1369 (2020) Amd. 1 2021-05-29 15 11.1002/1000/14627
3.2 ITU-T G.8275/Y.1369 (2020) Amd. 2 2022-02-13 15 11.1002/1000/14905
3.3 ITU-T G.8275/Y.1369 (2020) Amd. 3 2022-11-13 15 11.1002/1000/15155
4.0 ITU-T G.8275 2024-01-13 15 11.1002/1000/15845

Keywords
Architecture, IEEE 1588, packet, phase, PTP, synchronization, time.

* To access the Recommendation, type the URL https://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID.

Rec. ITU-T G.8275 (01/2024) 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/software copyrights, 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 appropriate ITU-T databases available via the ITU-T website at http://www.itu.int/ITU-T/ipr/.

© ITU 2024
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.8275 (01/2024)

 Table of Contents
Page
1 Scope............................................................................................................................. 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 2
4 Abbreviations and acronyms ........................................................................................ 2
5 Conventions .................................................................................................................. 3
6 General introduction to packet-based time/phase distribution ..................................... 4
6.1 Requirements for packet-based time and phase distribution .......................... 4
7 Architecture of packet-based time/phase distribution .................................................. 4
7.1 Packet-based time and phase distribution....................................................... 5
7.2 Time/phase protection aspects ........................................................................ 6
7.3 Packet network partitioning ............................................................................ 16
8 Security aspects ............................................................................................................ 17
9 Management aspects ..................................................................................................... 17
Annex A – Time/phase models based on ITU-T G.805 .......................................................... 18
Annex B – Inclusion of a virtual PTP port on a PTP clock ..................................................... 20
Annex C – Options to establish the PTP topology with the alternate BTCA .......................... 22
Annex D – Synchronization uncertain indication (optional) ................................................... 23
Annex E – Use of the timeTransmitterOnly and notTimeTransmitter parameters in the
networks ........................................................................................................................ 24
Annex F – Performance monitoring (optional) ........................................................................ 27
F.1 Data storage .................................................................................................... 29
F.2 Use cases when local PTP clock is not used for timestamping ...................... 31
F.3 Considerations for [ITU-T G.8275.2] ............................................................ 31
F.4 Time reference information ............................................................................ 31
Appendix I – Architecture for time and phase distribution over a packet network providing
PTS at the protocol level............................................................................................... 33
I.1 Architecture for PTS....................................................................................... 33
Appendix II – An example of PRTC switching by the BTCA in a ring network .................... 37
Appendix III – Generic IWF node ........................................................................................... 39
III.1 Introduction .................................................................................................... 39
III.2 Inter-working between the [ITU-T G.8275.1] and [ITU-T G.8275.2]
profiles ............................................................................................................ 40
III.3 Generation of the physical layer frequency signal by the IWF ...................... 42
III.4 Mapping IWF to telecom PTP clocks ............................................................ 43
Appendix IV – Use cases for mapping from PTP clockClass values to quality levels............ 44
IV.1 Use case I ........................................................................................................ 44
IV.2 Use case II ...................................................................................................... 44

Rec. ITU-T G.8275 (01/2024) iii

 Page
Appendix V – Deployment examples and the use of partially aware deviceTypes ................. 46
Appendix VI – cnPRTC functional architecture ...................................................................... 48
Appendix VII – cnPRTC deployment scenarios ...................................................................... 49
Appendix VIII – Description of PTP clock modes and associated contents of Announce
messages ....................................................................................................................... 51
VIII.1 Purpose of this appendix ................................................................................ 51
VIII.2 Description of the modes ................................................................................ 51
VIII.3 Example of mapping between PTP port states and PTP clock modes for a
3-port T-BC/T-BC-P/T-BC-A ........................................................................ 52
VIII.4 T-GM Announce message contents based on the internal PTP clock modes 53
VIII.5 T-BC/T-BC-P/T-BC-A Announce message contents based on the internal
PTP clock modes ............................................................................................ 54
Appendix IX – Considerations on the use of [IEEE 1588-2019] ............................................ 56
Appendix X – Flexible synchronization network based on cnPRTC ...................................... 57
Appendix XI – Information that can be used in the analysis of the performance monitoring
data ................................................................................................................................ 60
Appendix XII – Updated terminology for PTP clocks and PTP profiles................................. 61
Bibliography............................................................................................................................. 62

iv Rec. ITU-T G.8275 (01/2024)

Recommendation ITU-T G.8275

Architecture and requirements for packet-based time and phase distribution

1 Scope
This Recommendation describes the general architecture of time and phase distribution using packet-
based methods. This version of the Recommendation focuses on the distribution of time and phase
using the standard for precision time protocol (PTP) [IEEE 1588]. The requirements and architecture
form a base for the specification of other functionalities that are needed to achieve packet-based time
and phase distribution in a carrier environment. The architecture described covers the case where
protocol interaction is at all nodes, between a packet timeTransmitter (pTT) clock and a packet
timeReceiver (pTR) clock, or only a subset of the nodes between a pTT clock and a pTR clock. Details
of the necessary profiles are described in other Recommendations.

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.805] Recommendation ITU-T G.805 (2000), Generic functional architecture of
transport networks.
[ITU-T G.810] Recommendation ITU-T G.810 (1996), Definitions and terminology for
synchronization networks.
[ITU-T G.8260] Recommendation ITU-T G.8260 (2022), 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.8261.1] Recommendation ITU-T G.8261.1/Y.1361.1 (2012), Packet delay variation
network limits applicable to packet-based methods (Frequency
synchronization).
[ITU-T G.8262] Recommendation ITU-T G.8262/Y.1362 (2018), Timing characteristics of a
synchronous equipment slave clock.
[ITU-T G.8262.1] Recommendation ITU-T G.8262.1/Y.1362.1 (2022), Timing characteristics of
enhanced synchronous equipment slave clock.
[ITU-T G.8263] Recommendation ITU-T G.8263/Y.1363 (2017), Timing characteristics of
packet-based equipment clocks.
[ITU-T G.8264] Recommendation ITU-T G.8264/Y.1364 (2017), Distribution of timing
information through packet networks.
[ITU-T G.8265] Recommendation ITU-T G.8265/Y.1365 (2010), Architecture and
requirements for packet-based frequency delivery.
[ITU-T G.8265.1] Recommendation ITU-T G.8265.1/Y.1365.1 (2022), Precision time protocol
telecom profile for frequency synchronization.

Rec. ITU-T G.8275 (01/2024) 1

[ITU-T G.8271] Recommendation ITU-T G.8271/Y.1366 (2020), Time and phase
synchronization aspects of telecommunication networks.
[ITU-T G.8271.1] Recommendation ITU-T G.8271.1/Y.1366.1 (2022), Network limits for time
synchronization in packet networks with full timing support from the network.
[ITU-T G.8271.2] Recommendation ITU-T G.8271.2/Y.1366.2 (2021), Network limits for time
synchronization in packet networks with partial timing support from the
network.
[ITU-T G.8272] Recommendation ITU-T G.8272/Y.1367 (2018), Timing characteristics of
primary reference time clocks.
[ITU-T G.8275.1] Recommendation ITU-T G.8275.1/Y.1369.1 (2022), Precision time protocol
telecom profile for phase/time synchronization with full timing support from
the network.
[ITU-T G.8275.2] Recommendation ITU-T G.8275.2/Y.1369.2 (2022), Precision time protocol
telecom profile for phase/time synchronization with partial timing support from
the network.
[IEEE 1588] References either [IEEE 1588-2008] or [IEEE 1588-2019] depending on the
specific implementation. See clause 5, Conventions, for further details.
[IEEE 1588-2008] IEEE Std 1588-2008, Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems.
[IEEE 1588-2019] IEEE Std 1588-2019, Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems.

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

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
APTS Assisted Partial Timing Support
APTSC Assisted Partial Timing Support Clock
BC Boundary Clock
BTCA Best TimeTransmitter Clock Algorithm
cnPRTC Coherent Network PRTC
DS Data Set
EEC Synchronous Ethernet Equipment Clock
ePRTC Enhanced PRTC
ESMC Ethernet Synchronization Messaging Channel
FTS Full Timing Support
GM Grandmaster
GNSS Global Navigation Satellite System
HRM Hypothetical Reference Model

2 Rec. ITU-T G.8275 (01/2024)

IWF Inter-working Function
LTE Long-Term Evolution
NTP Network Time Protocol
OTN Optical Transport Network
PDV Packet Delay Variation
PPS Pulse Per Second
PRC Primary Reference Clock
PRTC Primary Reference Time Clock
PTP Precision Time Protocol
PTS Partial Timing Support
pTR Packet timeReceiver
pTT Packet timeTransmitter
QL Quality Level
SDH Synchronous Digital Hierarchy
SF Signal Fail
SSM Synchronization Status Message
SSU Synchronization Supply Unit
T-BC Telecom Boundary Clock
T-GM Telecom Grandmaster
T-TC Telecom Transparent Clock
T-TSC Telecom Time Synchronous Clock
TC Transparent Clock
ToD Time of Day
TR timeReceiver, TimeReceiver, or TIME_RECEIVER
TT timeTransmitter, TimeTransmitter, or TIME_TRANSMITTER
UTC Coordinated Universal Time
WCDMA Wideband Code Division Multiple Access

5 Conventions
The architecture within this Recommendation applies to profiles that are specified in other
Recommendations. Within those Recommendations, some requirements are stated as requiring
compliance to the [IEEE 1588]. For implementations compliant to [IEEE 1588-2008], the reference
to [IEEE 1588] means compliance to [IEEE 1588-2008]. For implementations compliant to
[IEEE 1588-2019], the reference to [IEEE 1588] means compliance to [IEEE 1588-2019]. Some of
these references to [IEEE 1588] include a specific clause number. In these cases, the clause number
is the same in both [IEEE 1588-2008] and [IEEE 1588-2019]. If the requirements are in different
clauses in the two versions of IEEE 1588, then the text of this Recommendation shall include the
specific clause for [IEEE 1588-2008] and the specific cause for [IEEE 1588-2019].
Within this Recommendation, the term PTP refers to the PTP version 2 protocol defined in
[IEEE 1588].

Rec. ITU-T G.8275 (01/2024) 3

6 General introduction to packet-based time/phase distribution
The distribution of accurate time and phase is necessary to support certain telecom-based services
and in particular the underlying infrastructure. While traditional network synchronization has relied
on the accurate distribution of frequency, evolving wireless networks require the distribution of
accurate time and phase.
As the network evolves from a primarily TDM-based network infrastructure to one using
packet-based technology, the ability to distribute synchronization is also changing.
In order to enable timing distribution in packet-based networks, the ITU-T developed specifications
([ITU-T G.8261], [ITU-T G.8262] and [ITU-T G.8264]) for synchronous Ethernet, which allowed
the use of the Ethernet physical layer to be used as a mechanism to distribute frequency analogous to
the methods used with synchronous digital hierarchy (SDH)-based network synchronization. In this
regard, synchronous Ethernet, by appropriate specification of network equipment clocks provided
support for the existing frequency-based synchronization network over both existing TDM and new
packet-based technology.
In the absence of the ability to utilize the physical layer, the ITU also developed Recommendations
covering frequency distribution using packet-based methods such as precision time protocol (PTP)
and network time protocol (NTP). The use of packet-based methods also enabled new frequency
synchronization scenarios to be considered. These, as well as other aspects specific to packet-based
frequency distribution, resulted in the development of an architectural specification [ITU-T G.8265].
This Recommendation describes the architecture for packet-based time and phase distribution.

6.1 Requirements for packet-based time and phase distribution

Packet-based mechanisms for time and phase distribution must meet the following five requirements:
1) mechanisms must be specified to allow interoperability between the various phase/time
clocks defined in this architecture;
2) mechanisms must permit consistent operation over managed wide area telecom networks;
3) packet-based mechanisms must allow the synchronization network to be designed and
configured in a fixed arrangement;
4) protection schemes used by packet-based systems must be based on standard telecom
operational practice and allow telecom time synchronous clocks (T-TSC) the ability to take
phase and time from multiple geographically separate telecom grandmaster (T-GM) clocks;
5) phase/time reference source selection based on received phase/time traceability and local
priority should be permitted. Automatic establishment of the phase/time synchronization
network topology may also be possible.

7 Architecture of packet-based time/phase distribution

In contrast to physical layer synchronization where the significant edges of a data signal define the
timing content of the signal, packet-based methods rely on the transmission of dedicated "event
packets". These "event packets" form the significant instants of a packet timing signal. The timing of
these significant instants is precisely measured relative to a timeTransmitter (TT), and this timing
information is encoded in the form of a timestamp, which is a machine-readable representation of a
specific instance of time. The timestamp is generated via a pTT function and is carried over a packet
network to a pTR clock.
A protocol is used between the timeTransmitter and the timeReceiver (TR) clocks to adjust for
transmission and other delays, resulting in both having the same time reference.
As time is the integral of frequency, the timestamps can also be used to derive frequency. This case
is covered in [ITU-T G.8265] and [ITU-T G.8265.1].

4 Rec. ITU-T G.8275 (01/2024)

7.1 Packet-based time and phase distribution
A time reference is initially obtained from a primary reference time clock (PRTC). If the time across
the system is required to be referenced to the coordinated universal time (UTC) or to some other
universal standard source of time, the PRTC itself may require a time reference input such as a global
navigation satellite system (GNSS) signal.
For the purposes of time and phase synchronization transport, the pTT delivers its reference to the
pTR clock using a packet timing signal (see [ITU-T G.8260]).
In order to achieve better accuracy, protocol-level timing support may be used at various network
nodes. Specifically, for the [IEEE 1588] PTP protocol, these intermediate devices are termed
boundary clocks (BCs) or transparent clocks (TCs).
The architecture described in this Recommendation describes two cases; the first case is where timing
support is provided by all the nodes in the network (e.g., telecom boundary clocks (T-BCs)) with
physical layer frequency support ("full timing support to the protocol level" (FTS) (see
[ITU-T G.8260]) and the second case is where the intermediate nodes do not provide timing support,
but timing support is provided by the GNSS at the network edge, with PTP acting as a backup. This
is termed assisted partial timing support (APTS). The node providing support at the edge of the
network is called an assisted partial timing support clock (APTSC).
Other architectures where not all of the nodes need to provide timing support by participating in the
timing protocol are termed "partial timing support to the protocol level" (PTS) (see [ITU-T G.8260]).
Some additional considerations for this topic are documented in Appendix I.
In both types of architectures, the physical layer frequency support may be available to stabilize the
operation of the T-BCs or telecom transparent clocks (T-TCs).
The time-transfer protocol operating between the nodes allows the same time to be recovered or
corrected at all the nodes participating in the timing protocol, subject to some degradation ().
In some deployments, especially in the access part of the network, it may be convenient to provide
timing support from the protocol via T-TC functions. One typical example is in the case of the
microwave connections.
NOTE 1 – The T-TCs are typically connected in tree architectures. Rings composed entirely of T-TCs can
raise issues in terms of PTP packets loops.
The general network topology for time/phase distribution from a PRTC to a T-TSC is shown in
Figure 1. The synchronization flow is from the timeTransmitter clock to the timeReceiver clock,
although the timing messages will flow in both directions. Individual nodes are T-BCs or T-TCs in
the case of full support from the network.
NOTE 2 – The following Figure does not imply any hypothetical reference model (HRM).

Rec. ITU-T G.8275 (01/2024) 5

 Figure 1 – Time distribution to timeReceiver clocks

Additional aspects related to performance are also covered in [ITU-T G.8271] and [ITU-T G.8271.1].

7.2 Time/phase protection aspects

Protection is required to optimize the performance of the services. Protection is defined as the
mechanisms that allow maintaining the phase/time reference delivered to the end application (e.g., a
base station) to an acceptable level during failure events. It includes redundancy of the phase/time
primary reference sources (time-plane rearrangement) and phase/time holdover (time-plane
holdover). Protection is described in the following clauses in terms of protection of the pTT /PRTC
and protection of the pTR.
7.2.1 Packet timeTransmitter (pTT) protection
PRTC location
When considering phase/time distribution, the PRTC functions can be located at different positions,
depending on the overall architecture that the network operator wishes to follow. However, these can
be summarized into the four generic locations described in this clause.
These are the main scenarios; others may be considered.
Case A: centralized PRTC collocated with a primary reference clock (PRC)

Figure 2 – Architecture with centralized PRTC functions collocated with the PRC

6 Rec. ITU-T G.8275 (01/2024)

Figure 2 only shows a primary path to the base stations, other protection mechanisms may be present,
but are not shown. Some details may be hidden.
This architecture is compatible with PRTC redundancy (e.g., to protect against GNSS failures): in
case one of the PRTCs fails, another PRTC would deliver the reference to the nodes that have
previously been receiving the reference from the PRTC in failure.
This architecture requires the links of the core network to be properly calibrated to avoid the
accumulation of excessive time errors due to link asymmetry.
Case B: centralized PRTC not collocated with the PRC

Figure 3 – Architecture with centralized PRTC functions not collocated with the PRC

The architecture, shown in Figure 3, is also compatible with the PRTC redundancy. In addition, the
PRTC function may receive a PRC-traceable physical layer frequency reference (e.g., synchronous
Ethernet) in order to provide additional protection against GNSS failures, or to participate in the
generation of the reference provided by the PRTC under nominal conditions.
This architecture also requires the links of the core network to be properly calibrated to avoid the
accumulation of excessive time errors due to link asymmetry.
Case C: distributed PRTC in the aggregation sites

Figure 4 – Architecture with PRTC functions distributed in the aggregation sites

Rec. ITU-T G.8275 (01/2024) 7

In this architecture, shown in Figure 4, the PRTC function is located in an aggregation site; typically,
a GNSS receiver is added to one of the last synchronization supply units (SSUs) of the physical layer
frequency chain. This implies the deployment of a higher number of GNSS receivers than in the
centralized PRTC architecture. However, the advantage is that the links of the core network do not
have to be calibrated to compensate for the link asymmetry.
PRTC redundancy schemes require connectivity between these aggregation sites; this may not always
be possible. Control of the precision time protocol (PTP) hierarchy (e.g., to limit the segment of a
network that can be synchronized by a specific PRTC) should be guaranteed by the proper setting of
PTP parameters (e.g., timeTransmitterOnly, notTimeTransmitter).
When the PRTC redundancy is considered between different aggregation sites, it implies that some
nodes of the core network would support PTP clocks (e.g., T-BC to be supported by the nodes
between the PRTC functions), as well as proper calibration of some of the links of the core network.
When the PRTC redundancy is not used, it is recommended that GNSS failures be secured by other
means; typically, the use of a PRC-traceable physical layer frequency reference delivered to the PRTC
function allows extending the phase/time holdover period during the GNSS failures.
Case D: distributed PRTC at the cell sites

Figure 5a – Architecture with PRTC functions distributed at the cell sites

In this architecture, shown in Figure 5a, the PRTC function is now located directly at the cell site;
typically, a GNSS receiver is directly connected to the base stations. This implies the deployment of
a higher number of GNSS receivers than in the "centralized PRTC" and "distributed PRTC in an
aggregation site" architecture. However, the advantage is that the links of both the core and the
backhaul networks do not have to be calibrated to compensate for the link asymmetry.
PRTC redundancy schemes with this architecture require connectivity between different cell sites.
Control of the PTP hierarchy (e.g., to limit the sites synchronized by a specific PRTC) should be
guaranteed by a proper setting of the PTP parameters (e.g., timeTransmitterOnly,
notTimeTransmitter).
If these connections are not possible, GNSS failures could be secured by other means; typically, the
use of a PRC-traceable physical layer frequency reference delivered to the PRTC function allows
extending the phase/time holdover period during the GNSS failures.
A combination of T-BC case C and case D is a possible option to minimize the number of GNSS
receivers deployed at cell sites, and to provide further PRTC redundancy options.

8 Rec. ITU-T G.8275 (01/2024)

Case E: APTSC at the cell sites with distributed PRTC + GM protection in the aggregation sites

Figure 5b – APTS architecture with PRTC functions distributed in the aggregation sites

In this architecture, shown in Figure 5b, the assisted partial timing support clock (APTSC) function
is located directly at the cell site; in addition, PRTC + GMs are located at the aggregation sites and
distribute PTP streams to the APTSCs. These PTP streams are used by the APTSC in case of a
PRTC/GNSS outage. This architecture implies deployment of a higher number of GNSS receivers
than in the "centralized PRTC" architectures. However, PTP unaware or partially aware networks can
be kept as short as possible to decrease the asymmetry and packet delay variation (PDV) introduced
by the network.
Case F: APTSC at the cell sites with distributed PRTC protection at the cell sites

Figure 5c – APTS architecture with PRTC+GM functions distributed at the cell sites

In this architecture, shown in Figure 5c, the APTSC function is located directly at the cell site; in
addition, grandmasters (GMs) are located at selected cell sites and distribute PTP streams to the
adjacent APTSCs. These PTP streams are used by the APTSC in case of a PRTC/GNSS outage. This
architecture implies deployment of a higher number of GNSS receivers than in the "centralized
PRTC" architectures. However, PTP unaware or partially aware networks can be kept as short as

Rec. ITU-T G.8275 (01/2024) 9

possible to decrease the asymmetry and PDV introduced by the network. In addition, the Global
Navigation Satellite System (GNSS) signal available to the APTSC in the cell site is used by the
collocated GM.
Case G: centralized PRTC at the core network and distributed PRTC in aggregation sites

Figure 5d – Centralized PRTC at the core network and distributed PRTC

in the aggregation sites

In this architecture, shown in Figure 5d, the PRTC is deployed at the core layer and the aggregation
site. In the normal operation, the nodes of the backhaul network selects the PRTC at the aggregation
as its primary reference. When the aggregation PRTC fails, one possibility is that the nodes of the
backhaul network selects the PRTC at the core network as a backup; other options are also possible.
This architecture deployment can be achieved via some parameter configurations, e.g., the priority2
or localPriority parameters.
In addition, if network timing isolation is required, e.g., the timing topology of two aggregation/access
networks of Figure 5d need to be separated, the PTP port parameters (i.e., timeTransmitterOnly,
notTimeReceiver) could be useful.
Applicable PRTC models depending on the PRTC location
The first PRTC model, illustrated in Figure 6, where no physical layer frequency input is present,
may be applicable to case A introduced earlier. It corresponds to the case where PRTC and PRC
functions are merged in the same equipment, and coherency between the frequency and phase/time
planes is therefore ensured.

Figure 6 – PRTC model with no physical layer frequency input

NOTE – In addition to being connected to a T-GM, a PRTC may be connected to a T-BC by the 1 pulse per
second (PPS) + time of day (ToD) interface. This is useful for some applications such as achieving protection
in a ring network, see Appendix II.

10 Rec. ITU-T G.8275 (01/2024)

The second PRTC model, illustrated in Figure 7, where a physical layer frequency input is present
and may be applicable to cases A, B, C, and D introduced earlier. It corresponds to the case where
PRTC and PRC functions are implemented in separate equipment and coherency between the
frequency, and phase/time planes is not always ensured.

Figure 7 – PRTC model with a physical layer frequency input

NOTE – In addition to being connected to a T-GM, a PRTC may be connected to a T-BC by the 1 PPS+ToD
interface. This is useful for some applications such as achieving protection in a ring network, see Appendix II.
The case where the PRTC and T-GM are combined is shown in Figure 8. The Ethernet interface that
supplies PTP may also supply frequency (i.e., it operates as a synchronous Ethernet interface).

Figure 8 – Combined PRTC and T-GM

There are other network architectures under study based on an enhanced PRTC (ePRTC) that provide
the ability to maintain network-wide time accuracy (see Appendix VI). Additional details are for
further study.
7.2.2 Packet timeReceiver (pTR) protection
This clause deals with the various schemes that may be considered for providing redundancy in the
distribution of a time synchronization reference.
Three protection scenarios for phase/time synchronization of the pTR are described. The scenarios
are:
1) phase/time long-term holdover with a physical layer frequency synchronization support;
2) switching to a backup reference with a physical layer frequency synchronization support;
3) switching to a backup reference without a physical layer frequency synchronization support.
Protection scenarios 2 and 3 involve time-plane rearrangements, while protection scenario 1 involves
time-plane holdover. In protection scenario 2, the frequency reference during the rearrangement is
provided via physical layer support, i.e., synchronous Ethernet. In protection scenario 3, the frequency
reference during the rearrangement is provided via the end application clock in holdover. In protection
scenario 1, the phase/time holdover is provided by a physical layer support.
The three scenarios are described in the following clauses.

Rec. ITU-T G.8275 (01/2024) 11

7.2.2.1 Protection scenario 1
Protection scenario 1 involves holdover with a physical layer frequency support (i.e., synchronous
Ethernet), where the period of holdover is generally much longer than the period of the rearrangement
of protection scenario 2 (see clause 7.2.2.2). Three sub-scenarios may be considered for protection
scenario 1. It is assumed that there is no backup timeTransmitter (TT) in this case:
1) scenario 1.1: The synchronous Ethernet reference used during the holdover is available at the
end application;
2) scenario 1.2: The synchronous Ethernet reference used during the holdover is available at the
PRTC, and it is the PRTC that enters the holdover by losing its GNSS reference. The end
application receives its timing from the PRTC via PTP;
3) scenario 1.3: The synchronous Ethernet reference used during the holdover is available at the
PRTC, and it is the PRTC that enters holdover by losing its GNSS reference. The end
application is collocated with and receives its timing directly from the PRTC.
Three holdover periods are of interest for protection scenarios 1.1, 1.2 and 1.3:
1) short holdover period, on the order of minutes (e.g., up to 5 minutes, maximum);
2) long holdover period, on the order of hours (e.g., up to 8 hours);
3) very long holdover periods, on the order of days (e.g., up to 3 days).
The short holdover period is assumed to cover cases where the GNSS signals become unavailable for
a short period of time. The long holdover period is assumed to cover cases where the GNSS signals
remain unavailable for a longer period of time, possibly without the need for an on-site operator
intervention. The very long holdover period covers the cases of very long failures, for which an on-
site operator intervention is necessary.
Protection scenario 1.1 is illustrated in Figure 9. In this protection scenario, the phase/time
synchronization path fails and the end application (e.g., the base station) is informed that the reference
signal is no longer traceable to a PRTC so that it would switch to the holdover. Relying on only a
free-running local clock, even of good quality, may not allow addressing the long and very long
holdover periods mentioned above. Instead, the local clock in the end application must be locked to
an accurate and stable physical layer frequency reference, such as the synchronous Ethernet.
The phase/time long-term holdover function is assumed to be supported in a PTP clock capable of
adequately filtering the noise that may be present on the synchronous Ethernet reference. The same
function can be used in a base station receiving both a 1 PPS input signal and a synchronous Ethernet
reference. During the holdover period, any timing signal delivered to the application by PTP is not
used.

12 Rec. ITU-T G.8275 (01/2024)

Figure 9 – Illustration of protection scenario 1.1 at the T-TSC (phase/time long-term holdover
at the T-TSC embedded in the end application)

Protection scenario 1.2 is illustrated in Figure 10. In this case, the phase/time long-term holdover
function is supported by the PRTC/T-GM. Like protection scenario 1.1, this holdover function
includes a clock that is capable of providing a high-quality frequency reference (e.g., high quality
local oscillator or a synchronous Ethernet equipment clock (EEC)). When the PRTC connected to the
T-GM has lost its reference (e.g., GNSS signal is lost), the PRTC may continue to deliver time
synchronization using this frequency reference.

Figure 10 – Illustration of protection scenario 1.2 at the PRTC/GM, (phase/time long-term

holdover at the PRTC/GM, with the PRTC/GM not collocated with the end application)

Rec. ITU-T G.8275 (01/2024) 13

Protection scenario 1.3 is illustrated in Figure 11. In this case, as in protection scenario 1.2, the
phase/time long-term holdover function is supported by the PRTC, which is also assumed to have a
good oscillator embedded, for instance, in case of problems with the GNSS signals reception. When
the PRTC has lost its reference (e.g., GNSS signal is lost), the PRTC may continue to deliver time
synchronization either using the internal oscillator or an external frequency synchronization reference
(e.g., synchronous Ethernet). However, now the PRTC is collocated with the end application.
Network time reference
(e.g., GNSS)

Time/phase
PRTC distribution interface End
Frequency reference application
G.8275-Y.1369(13)_F11

Figure 11 – Illustration of protection scenario 1.3 at the PRTC (phase/time long-term

holdover at the PRTC, with the PRTC collocated with the end application)
7.2.2.2 Protection scenario 2
Protection scenario 2 is illustrated in Figure 12. In this protection scenario, a telecom boundary clock
(T-BC) in the chain detects a failure in the primary PTP phase/time synchronization path, e.g., it stops
receiving PTP time-stamp messages on its timeReceiver port, or the information on the signal
indicates a degraded reference. This T-BC informs the downstream PTP clocks (T-BC, T-TSC) that
the reference is no longer traceable to a PRTC. This triggers the best timeTransmitter clock algorithm
(BTCA) and a new PTP path is determined.

14 Rec. ITU-T G.8275 (01/2024)

 Figure 12 – Illustration of protection scenario 2 (switching to a backup reference with
physical layer frequency synchronization support)

Immediately after the failure has been detected, the end application (e.g., a base station) is therefore
informed that the reference signal is no longer traceable to a primary reference time clock (PRTC)
and switches to the holdover. It may take some time to propagate this information down the chain,
depending on the position of the T-BC which has detected the failure. The local clock in the end
application is locked to an accurate and stable physical layer frequency reference, such as the
synchronous Ethernet, since this support is used.
The BTCA is run to determine a new PTP synchronization path.
The phase/time holdover function is assumed to be supported in the T-TSC embedded in the base
station. The same function can be used in a base station receiving both a 1 PPS input signal and a
synchronous Ethernet reference (in this case, the 1 PPS signal should be squelched during the failure).
The T-BC must be able to inform about the loss of the PRTC traceability.
7.2.2.3 Protection scenario 3
Protection scenario 3 is illustrated in Figure 13. In this protection scenario, a T-BC in the chain detects
a failure in the primary PTP phase/time synchronization path, e.g., it stops receiving PTP time-stamp
messages on its timeReceiver port, or the information on the signal indicates a degraded reference.

Rec. ITU-T G.8275 (01/2024) 15

This T-BC informs the other PTP clocks of the chain downstream (T-BC, T-TSC) that the reference
is no longer traceable to a PRTC.
It may take some time for the information of the failure to propagate down the chain, depending on
the position of the T-BC which detected the failure. Once the T-TSC is informed of the upstream
failure, it enters the holdover.
The holdover in the end application is based on a local clock of good quality not locked to an external
reference, since the physical layer frequency synchronization support is not available. During the
holdover period, any timing signals delivered to the end application by the PTP are not used.
The BTCA is run to determine a new PTP synchronization path.
The holdover function is assumed to be supported in the T-TSC embedded in the base station. The
same function can be used in a base station receiving a 1 PPS input signal (in this case, the 1 PPS
signal should be squelched during the failure).
The T-BC must be able to inform about the loss of the PRTC traceability.

Figure 13 – Illustration of protection scenario 3 (switching to a backup reference without

physical layer frequency synchronization)

7.3 Packet network partitioning

Operation over multiple domains may need to be considered, especially in the case of the mobile
backhaul. This is for further study.

16 Rec. ITU-T G.8275 (01/2024)

8 Security aspects
Unlike traditional timing streams where frequency is carried over the physical layer, packet-based
timing streams may be observed at different points in the network. There may be cases where timing
packets flow across multiple network domains which may introduce specific security requirements.
There may also be aspects of security that may be related to both the network (e.g., authentication
and/or authorization) and to the PTP protocol itself.
It is important to permit the operation with existing standards-based security techniques to help ensure
the integrity of the synchronization. Examples may include encryption and/or authentication
techniques, or network techniques for separating traffic, such as virtual local area networks (VLANs)
or label-switched paths (LSPs).
It may not be possible to implement some of these requirements without actually degrading the overall
level of timing or the system performance.
Certain aspects of security are for further study; however, some critical aspects are:
− timeReceivers should be prevented from connecting to rogue timeTransmitters (this could be
either by an authentication process or by using a network separation to prevent rogue
timeTransmitters from accessing the timeReceivers);
− a T-BC port that is connected to a "customer" must never enter the TIME_RECEIVER (TR)
state;
− timeTransmitters should be prevented from providing services to unauthorised
timeReceivers.

9 Management aspects
Network management aspects are for further study.

Rec. ITU-T G.8275 (01/2024) 17

 Annex A

Time/phase models based on ITU-T G.805

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

[ITU-T G.8264] provides descriptions of timing flows related to packet network synchronization.
Specifically, timing flows are shown which cover the case of the circuit emulation and physical layer
frequency synchronization based on the synchronous Ethernet.
This annex shows the timing flows appropriate to packet-based time mechanisms.
Network models help to ensure that interoperable systems can be developed. What follows is a
discussion of [ITU-T G.805] as a modelling technique, as this is what was used in the initial
development of [ITU-T G.8264]. [ITU-T G.805] has been used for many years to describe the
behaviour of the time-division multiplexing (TDM) systems. Since the development of
[ITU-T G.8264], further work has been undertaken within ITU-T to extend the models to cover packet
networks. However, for the purposes here, it is sufficient to refer to the [ITU-T G.805] models.
[ITU-T G.805] provides the modelling "language" to describe transport networks and it describes at
the high level, the functional blocks that form a transport network. These define the overall
"architecture" in a manner that is implementation independent. A key aspect of the architecture is the
concept of network layers. Typically, networks are managed on a per-layer basis, and interactions
between the layers follow client / server relationships. For telecom applications, OAM is defined on
a per-layer basis.
For a modelling construct such as [ITU-T G.805], a key aspect of the model is that there are
well-defined interactions between the functions. Common constructs in [ITU-T G.805] models
include trails (which support the end-to-end transfer of information and the various adaptation,
termination, and connection functions). The newer ITU-T, models to define packet networks describe
"flows". The work in [ITU-T G.8264] had anticipated this and thus it describes the timing flows.
The major benefit of the architectural modelling is that if properly specified and followed, functional
interactions are fully understood from the network level and therefore a complete specification of the
equipment consistent with the capabilities of the network is possible. Additionally, this results in a
network that has a high level of interoperability and is fully manageable.
The model to support time/phase
Extension of the [ITU-T G.8264] models to cover time/phase becomes conceptually straightforward
and is shown in Figure A.1. Here the output of the adaptation function is time/phase. The format of
time/phase is not considered at this point. The important aspects are that the input to the source
adaptation function must have additional information (time/phase), rather than simply being a
frequency reference. The information that is carried across the network remains, from the network
perspective, the same as in the frequency only case. The network carries the PTP packets. The
adaptation functions would be responsible for producing the appropriate outputs. This only shows the
timing path and traverses multiple packet network elements. This is illustrative of the model only.
In the case where frequency output is also required, this could be via the adaptation function. For
simplicity, this is not shown in the Figure, but it could be described (i.e., an additional frequency
output could be provided).

18 Rec. ITU-T G.8275 (01/2024)

 E1 E1

GNSS (time/phase)

Ext. Ref. Time

Phase

ETH
ETH_CI

ETY

Free run Free run

Ext. Ref. G.8275-Y.1369(13)_FA.1

Figure A.1 – Extension of basic [ITU-T G.8264] model to support time/phase

Packet time/phase with frequency support by the network
Figure A.2 shows how time/phase can be assisted with the frequency. In this specific example, the
frequency reference is provided via a synchronous Ethernet. A similar model could be developed
where the input is via an external interface. This model begins to illustrate the independence of
time/phase with frequency.
E1 E1

GNSS (time/phase)

Ext. Ref. Time

Phase

ETH
ETH_CI

Frequency
ref., provided
by SyncE

ETY

Free run
Ext. Ref. G.8275-Y.1369(13)_FA.2

Figure A.2 – Time/phase with frequency support provided by the network

(e.g., synchronous Ethernet)

Rec. ITU-T G.8275 (01/2024) 19

 Annex B

Inclusion of a virtual PTP port on a PTP clock

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

This annex describes the model for inclusion of a unidirectional, phase/time interface on a precision
time protocol (PTP) clock. High-level principles are introduced in this annex.
This interface will be referred to as a virtual PTP port. This virtual PTP port may be used to model:
– An external input signal of the clock (e.g., coming from a PRTC, such as 1 PPS + ToD);
– An external output signal of the clock (e.g., going to an end application, such as 1 PPS + ToD);
– An internal input (i.e., an input that originates within the node and is not accessible
externally) to a PTP clock that is coming from a source outside of the PTP clock's domain;
– An internal output (i.e., an output that originates within the node and is not accessible
externally) of a PTP clock that is going to a sink outside of the PTP clock's domain.
When associated with an input signal, a virtual PTP port allows this interface to participate in the PTP
protocol. As an input, this port can participate in the source selection with an associated virtual Erbest
or D0 using the associated virtual PTP port. As an input, the virtual PTP port may be used as part of
the "interfaces enabling interdomain interactions" defined in clause 18 of [IEEE 1588-2019] and
illustrated in Annex O of [IEEE 1588-2019], most applicably as the source adapter block providing
meta-data.
When associated with an external output signal, a virtual PTP port allows the communication of the
PTP clock information to other equipment.
Not all parameters supported by the virtual PTP port are required to be supported by the PTP clock.
The parameters grouped as locally set are not transmitted across the virtual PTP port but are set
internally by the receiver of the virtual PTP port information. The parameters supported by a virtual
PTP port are listed below.
− Time properties data set (DS)
○ Leap61
○ Leap59
○ currentUtcOffsetValid
○ ptpTimescale
○ timeTraceable
○ frequencyTraceable
○ timeSource
○ currentUtcOffset
− Parent data set
○ grandmasterIdentity
○ grandmasterClockQuality
▪ clockClass
▪ clockAccuracy
▪ offsetScaledLogVariance
○ grandmasterPriority1
○ grandmasterPriority2

20 Rec. ITU-T G.8275 (01/2024)

− Other parameters
○ stepsRemoved
○ versionPTP
○ domainNumber
○ Time of day (ToD)
− Locally set
○ Signal fail (SF)
○ localPriority
○ portNumber
NOTE 1 – The stepsRemoved attribute is set to zero in the case where a PRTC is connected to a virtual PTP
input port.
NOTE 2 – The SF is a locally set property of the PTP port. Signal fail is set to TRUE when the PTP clock
determines the input virtual PTP port (e.g., 1 PPS, GNSS) is not useable. When SF is TRUE the portDS.SF
parameter is set to TRUE.
NOTE 3 – When the external input virtual PTP port is a local external physical clock source, such as the GNSS,
the grandmasterIdentity assigned to the input virtual PTP port is the clockIdentity of the PTP clock itself.
NOTE 4 – The portNumber assigned to the virtual PTP port is set to a value different from the portNumber
values already assigned to the other PTP ports of the PTP clock.

Rec. ITU-T G.8275 (01/2024) 21

 Annex C

Options to establish the PTP topology with the alternate BTCA

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

For the ITU-T PTP telecom profiles [ITU-T G.8275.1] and [ITU-T G.8275.2] which include a
localPriority attribute, the alternate best timeTransmitter clock algorithm (BTCA) of those profiles
allows two main approaches to set up the topology of the phase/time synchronization network:
– Automatic topology establishment: When configuring the localPriority attributes to their
default value, the PTP topology is established automatically by the alternate BTCA based on
the Announce messages exchanged by the PTP clocks. A synchronization tree with the
shortest paths to the T-GMs is built after this operation. In this mode, during failure events
and topology reconfiguration, the alternate BTCA will be run again and result in a new
synchronization tree. This alternate BTCA operation ensures that no timing loop will be
created without requiring manual intervention or prior analysis of the network. The
convergence time to the new PTP topology depends on the size of the network, and on the
specific configuration of the PTP parameters.
– Manual network planning: The use of the localPriority attributes with different values than
their default value allows building manually the synchronization network topology, in a
similar way as synchronous digital hierarchy (SDH) networks are typically operated based
on the synchronization status message (SSM). This option allows full control on the actions
during failure events and topology reconfiguration, based on the configured local priorities
of the system. However, careful network planning is required prior to the deployment in order
to avoid timing loops.

22 Rec. ITU-T G.8275 (01/2024)

 Annex D

Synchronization uncertain indication (optional)

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

This annex is used in the ITU-T PTP telecom profiles [ITU-T G.8275.1] and [ITU-T G.8275.2]. It is
optional, but if implemented, it is necessary for the equipment to conform to the requirements
contained herein. When a PTP clock selects a new parent as a synchronization time source, the PTP
port associated with that new parent is placed in the UNCALIBRATED state. This PTP port state
indicates that the PTP clock is in the process of synchronizing to the time source. The duration and
functionality of this state is implementation specific. During this period, the PTP clock may have
large or fast changes in frequency and phase, and while it is desirable that the updated parent
information be propagated downstream to allow the topology to settle, it may not be desirable for the
downstream PTP clocks to use the timing information. Therefore, communicating to downstream
PTP clocks about the UNCALIBRATED state would be beneficial.
The local synchronizationUncertain Boolean, used with Announce messages transmitted from an
egress port is FALSE except under the following conditions for which it shall be TRUE:
• the synchronizationUncertain flag of the Announce message received from the parent clock
is TRUE; or
• the ingress port is in the UNCALIBRATED state; or
• implementation specific criteria.
When the synchronizationUncertain condition is TRUE then in the transmitted Announce message,
the flagField – octet 1, bit 6 is set to 1. Otherwise, when the synchronizationUncertain condition is
FALSE, the bit is set to 0.
The default value for the synchronizationUncertain flag was picked so that the value transmitted out
of a PTP clock that does not have the synchronizationUncertain functionality indicates that its timing
information can be used. This allows a downstream clock that does support the functionality to use
an upstream parent clock that does not support this functionality. The downstream clock considers
the timing information from the upstream clock as usable and performs synchronization processing
using this timing information. As this situation can lead to the misinterpretation of the actual
synchronization quality at the end of the network clock chain, it is not recommended to depend on
this synchronizationUncertain indication unless all the PTP clocks in the network support this
functionality.

Rec. ITU-T G.8275 (01/2024) 23

 Annex E

Use of the timeTransmitterOnly and notTimeTransmitter parameters

in the networks
(This annex forms an integral part of this Recommendation.)

There are two portDS members that may be used to control the network topology –
portDS.timeTransmitterOnly and portDS.notTimeTransmitter.
The portDS.timeTransmitterOnly operation is specified in clause 9.2.2.2 of [IEEE 1588-2019]. This
applies to the implementations of this profile based on [IEEE 1588-2008] and those based on
[IEEE 1588-2019]. For a telecom boundary clock (T-BC), the ports for which the
timeTransmitterOnly attribute is FALSE it is allowed to enter into the TIME_RECEIVER state and
therefore may be used to receive timing into the T-BC. The use of the timeTransmitterOnly is
intended primarily to be used in the following scenarios:
• A PTP port of a T-GM.
• A PTP port of a T-BC that is facing the 'downstream' direction towards the access portion of
a tree hierarchy.
• A PTP port of a T-BC that is facing an end application. Note that if an end application
includes a timeReceiverOnly ordinary clock, then by definition, it will not send Announce
messages.
The use of the timeTransmitterOnly (TTOnly) parameter in other scenarios, such as on PTP ports
participating in a ring architecture, may result in an unintended operation, especially during re-
configuration or topology changes.
One typical use case where this parameter should remain TRUE is the prevention of timing
propagating from the access portion of the network to the core portion of the network as shown in
Figure E.1.
This may also be applicable at a user network interface (UNI) or a network node interface (NNI)
between the two operators where the flow of synchronization is known.
In addition, this may also be applicable for an inter-working function (IWF) where the direction of
the timing is known in advance, or similarly for uni-directional timing flows through the native access
equipment.

Figure E.1 – PTP timing propagation from core to access

Another typical use case where this parameter should remain TRUE is where:
a) there is a need to prevent timing from propagating from the end application to the transport
network, and
b) the PTP clock in the end application is not a timeReceiverOnly clock, as shown in Figure E.2.

24 Rec. ITU-T G.8275 (01/2024)

 Figure E.2 – PTP timing propagation from the transport network to the end application

The portDS.notTimeTransmitter is in some measure the opposite effect of the

portDS.timeTransmitterOnly. If notTimeTransmitter is TRUE, the port is never placed in the
PRE_TIME_TRANSMITTER or TIME_TRANSMITTER (TT) state, and, if the recommended state
by the alternate BTCA is BTC_TIME_TRANSMITTER, then the PTP port should instead be placed
in the PASSIVE state. The notTimeTransmitter attribute does not affect the state of the PTP port if
the recommended state is BTC_TIME_RECEIVER or BTC_PASSIVE (e.g., if notTimeTransmitter
is TRUE and the recommended state is BTC_TIME_RECEIVER, the PTP port will be placed in the
TIME_RECEIVER state). The notTimeTransmitter attribute is set via portDS.notTimeTransmitter.
The portDS.notTimeTransmitter primarily gives control to an individual PTP clock itself to avoid the
propagation of synchronization, and also indirectly provides the ability to monitor its peers.
One use case for the notTimeTransmitter attribute is for the PTP clocks located at the end of the clock
chain where it is known in advance that their PTP ports will not be re-transmitting timing further
downstream (such as a daisy chain). In the situation shown in Figure E.3, the PTP clock is located
with a PRTC/T-GM connected to port 2, which is selected by the BTCA as the best source (perhaps
due to the smallest stepsRemoved value) and is placed into the TIME_RECEIVER state. Ordinarily,
that may result in port 1 of the PTP clock to be placed into the TIME_TRANSMITTER (TT) state
and the upstream telecom boundary clock (T-BC) being placed into the TIME_RECEIVER state (e.g.,
perhaps due to the stepsRemoved comparison, in this case shown the stepsRemoved from the upper
PRTC/T-GM via the PTP network is 10). That outcome would result in where the upper PTP network
selects the timing from the lower PRTC/T-GM connecting to the PTP clock and prevent port 1 in the
TIME_TRANSMITTER state of the PTP clock from monitoring the upper PTP network. However,
if port 1 enables the notTimeTransmitter attribute, then instead Port 1 is placed into the PASSIVE
state, and the peer PTP port X is placed into the TIME_TRANSMITTER state. As a result, it avoids
the upper PTP network to select the lower PRTC/T-GM as its reference. Meanwhile, port 1 in the
PASSIVE state can monitor the timing from the upper PTP network (see Annex G of
[ITU-T G.8275.1]).

Rec. ITU-T G.8275 (01/2024) 25

 Figure E.3 – PTP clock with notTimeTransmitter enabled

This notTimeTransmitter attribute may also be useful for the inter-working function (IWF) where the
direction of the timing is known in advance with multiple PTP ports, or similarly for uni-directional
timing flows through the native access equipment.

26 Rec. ITU-T G.8275 (01/2024)

 Annex F

Performance monitoring (optional)

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

This annex is used in the ITU-T PTP telecom profiles [ITU-T G.8275.1] and [ITU-T G.8275.2]. It is
optional, but if implemented, it is necessary for the equipment to conform to the requirements
contained herein.
A T-BC, T-TSC, T-BC-P, T-BC-A, T-TSC-P or T-TSC-A implementing this option collects the
performance monitoring data as listed in Table F.1.
This is based on Table J.1 from clause J.2 of [IEEE 1588-2019].

Table F.1 – PTP instance performance monitoring parameters

Parameter name Definition Data type
averageTT-TR-Delay Average of the TT-TR-Delay for TimeInterval
each 15 minute and 24 h interval.
minTT-TR-Delay Minimum of the TT-TR-Delay for TimeInterval
each 15 minute and 24 h interval.
maxTT-TR-Delay Maximum of the TT-TR-Delay for TimeInterval
each 15 minute and 24 h interval.
stdDevTT-TR-Delay StdDev of the TT-TR-Delay for TimeInterval
each 15 minute and 24 h interval.
averageTR-TT-Delay Average of the TR-TT-Delay for TimeInterval
each 15 minute and 24 h interval.
minTR-TT-Delay Minimum of the TR-TT-Delay for TimeInterval
each 15 minute and 24 h interval.
maxTR-TT-Delay Maximum of the TR-TT-Delay for TimeInterval
each 15 minute and 24 h interval.
stdDevTR-TT-Delay StdDev of the TR-TT-Delay for TimeInterval
each 15 minute and 24 h interval.
averageMeanPathDelay Average of the <meanPathDelay> TimeInterval
for each 15 minute and
24 h interval.
minMeanPathDelay Minimum of the <meanPathDelay> TimeInterval
for each 15 minute and
24 h interval.
maxMeanPathDelay Maximum of the <meanPathDelay> TimeInterval
for each 15 minute and
24 h interval.
stdDevMeanPathDelay StdDev of the <meanPathDelay> TimeInterval
for each 15 minute and
24 h interval.
averageOffsetFromTT (see Note 1) Average of the <offsetFromTT> for TimeInterval
each 15 minute and 24 h interval.
minOffsetFromTT (see Note 1) Minimum of the <offsetFromTT> TimeInterval
for each 15 minute and
24 h interval.

Rec. ITU-T G.8275 (01/2024) 27

 Table F.1 – PTP instance performance monitoring parameters
Parameter name Definition Data type
maxOffsetFromTT (see Note 1) Maximum of the <offsetFromTT> TimeInterval
for each 15 minute and
24 h interval.
stdDevOffsetFromTT (see Note 1) StdDev of the <offsetFromTT> for TimeInterval
each 15 minute and 24 h interval.
NOTE 1 – When the main usage of the statistics is to be compared against a threshold level crossing alarm, it
might be more convenient to display an absolute value, for example, the observed abs (average offset from
TimeTransmitter), instead of the related signed value. This is implementation specific.
A T-BC, T-TSC, T-BC-P, T-BC-A, T-TSC-P or T-TSC-A clock implementing this option collects
the additional parameters as listed in Table F.2 below. The applicability of these parameters to T-TC
is for further study.
These are based on Table J.3 from clause J.3 in [IEEE-1588-2019], excluding the following counters:
pDelayReqTx, pDelayReqRx, pDelayRespTx, pDelayRespRx, pDelayRespFollowupTx,
pDelayRespFollowupRx.

Table F.2 – Additional parameters

Parameter name Definition Data type
announceTx Counter indicating the number of Announce UInteger32
messages that have been transmitted for each
15 minute and 24 h interval.
announceRx Counter indicating the number of Announce UInteger32
messages from the current GM that have been
received for each 15 minute and 24 h interval.
announceForeignTTRx Counter indicating the total number of UInteger32
Announce messages from the foreign
TimeTransmitter that have been received for
each 15 minute and 24 h interval.
syncTx Counter indicating the number of sync UInteger32
messages that have been transmitted for each
15 minute and 24 h interval.
syncRx Counter indicating the number of sync UInteger32
messages that have been received for each
15 minute and 24 h interval.
followUpTx Counter indicating the number of Follow_Up UInteger32
messages that have been transmitted for each
15 minute and 24 h interval.
followUpRx Counter indicating the number of Follow_Up UInteger32
messages that have been received for each 15
minute and 24 h interval.
delayReqTx Counter indicating the number of Delay_Req UInteger32
messages that have been transmitted for each
15 minute and 24 h interval.
delayReqRx Counter indicating the number of Delay_Req UInteger32
messages that have been received for each
15 minute and 24 h interval.

28 Rec. ITU-T G.8275 (01/2024)

 Table F.2 – Additional parameters
Parameter name Definition Data type
delayRespTx Counter indicating the number of Delay_Resp UInteger32
messages that have been transmitted for each
15 minute and 24 h interval.
delayRespRx Counter indicating the number of Delay_Resp UInteger32
messages that have been received for each 15
minute and 24 h interval.
NOTE 2 – [IEEE 1588-2019] Table J.2 is not applicable to [ITU-T G.8275.1] and [ITU-T G.8275.2] because
it deals with a peer-to-peer delay mechanism. Counters for signalling messages (related to unicast negotiation
used by the [ITU-T G.8275.2] PTP telecom profile) are for further study.
Record data types are based on clause J.4 of [IEEE 1588-2019] and data sets for performance
monitoring are specified in clause J.5 of [IEEE 1588-2019].
As per [IEEE 1588-2019] Annex J, data collection periodicity is with a single record every 15 minutes
and a single record for the full period (24 hours). This is indicated as "Regular data storage" in
clause F.1.1.
In addition, a second set of data collection ("Simplified data storage" as indicated in clause F.1.2) is
based on a single record every 3 minutes and a single record for the full period of 1 hour. The related
data sets specified in [IEEE 1588-2019] Annex J.5 should be adapted accordingly in this case.
Both sets of data collection (clauses F.1 and F.2) should be supported. An exemption is possible for
smaller equipment to support one of them.
NOTE 3 – A PTP instance implementing [IEEE 1588-2019] Annex J is interoperable with an implementation
supporting this Annex. The time-of-day clock used to build the record should be reliable and preferably based
on a timing reference that is not impacted by the same type of failures that can impact the recovered PTP clock.
The collected data can be used by a network management system for monitoring analysis. As an
example, when an assisted partial timing support (APTS) is used, it could provide information on the
network asymmetry. As a second example, sudden change in the value of some of the parameters,
such as maxMeanPathDelay, can indicate that there has been network rearrangements in a specific
link. By having information on the synchronization network topology, it should be possible to identify
the end applications that may be impacted by these changes and perform further analysis if needed.

F.1 Data storage

Two options apply for the data storage as specified in clauses F.1.1 and F.1.2 respectively.
F.1.1 Regular data storage:
Data is stored over the past 24 hours.
This results in a list of records as defined in [IEEE 1588-2019] Annex J.4, composed by:
96 for the 15-minute sets of statistics, plus the current values; 1 x 24-hours sets of statistics, plus the
current value.
This results in 99 sets of values in total.
The data buffers are numbered between 0 and 98 as shown in the following Figure F.1.

Rec. ITU-T G.8275 (01/2024) 29

 Figure F.1 – Performance monitoring data collection for the regular data storage
F.1.2 Simplified data storage:
Data is stored over the past 1 hour.
This results in a list of records as defined in [IEEE 1588-2019] Annex J.4 and adapted to the 3 minutes
granularity and 1 hour period, composed by:
20 for the 3-minute sets of statistics, plus the current values; 1  1-hour sets of statistics, plus the
current value.
This results in 23 sets of values in total.
The data buffers are numbered between 100 and 122 as shown in the following Figure F.2.

Figure F.2 – Performance monitoring data collection for the simplified data storage

30 Rec. ITU-T G.8275 (01/2024)

NOTE – The numbering of data buffers allows to identify unique types of data; regular data storage based on
standard [IEEE 1588-2019] Annex J (from 0 to 98), with 15 minutes and 24 h granularity and simplified data
storage (from 100 to 122) with 3 minutes and 1 hour granularity.

F.2 Use cases when local PTP clock is not used for timestamping
There are several use cases where the local precision time protocol (PTP) clock is not used for
timestamping. For example, when the system has access to an alternative accurate and reliable
reference, the performance monitoring data is calculated with reference to this accurate and reliable
reference.
In particular, the following use cases are currently addressed:
– When a local GNSS is used as a primary reference (not modelled as a virtual PTP port), and
the PTP reference is used as a back up (the selection is made outside the PTP);
– When a PTP node has access to an active [ITU-T G.8275.1], PTP reference and a
[ITU-T G.8275.2] reference is used for back up.
Additional use cases (e.g., GNSS local reference modelled via a virtual PTP port or, in general, when
the PM data is collected from ports that are not in the TIME_RECEIVER state) are for further study.

F.3 Considerations for [ITU-T G.8275.2]

In the case of the unicast profile [ITU-T G.8275.2], additional care should be taken with the PTP
event messages used to compute the TR-TT-Delay and TT-TR-Delay parameters. The intention is for
the statistics based on the TR-TT-Delay and TT-TR-Delay to be readily used to compare against the
network limits specified in [ITU-T G.8271.2]. In this way it is possible for a network operator to
compare in a consistent way the results of the measurements performed by the different
implementations. As such, the use of a subset of all the PTP event messages that approximates the
network limit selection criteria is helpful (refer to [ITU-T G.8271.2] clause 7.3.1.1). If this is not
possible, and with the assumptions that the monitoring based on the packet selection criteria of the
specific implementation would not provide significant differences if compared with the
[ITU-T G.8271.2] principles, the TR-TT-Delay and TT-TR-Delay parameters should be calculated
every 15 or 3 minutes by using the packets selected by the clock recovery during this interval. The
statistics representing the number of various PTP messages are counted over the full data set.
NOTE – In the case of APTS, when the GNSS is available, the performance monitoring data is calculated with
reference to the local reference clock (locked to GNSS). In this way it is possible to measure the network
performance with respect to a local accurate reference. As an example, the offsetFromTT based statistics can
provide an indication of the asymmetry caused by the PTP-unaware network.

F.4 Time reference information

To inform the network management system about which reference is used for the PM measurement
defined in Table F.1, the ClockPerformanceMonitoringDataRecord data type is amended to include
the PMref parameter as shown below:
Struct ClockPerformanceMonitoringDataRecord
{
UInteger16 index;
Boolean measurementValid;
Boolean periodComplete;
PMTimestamp PMTime;
TimeInterval <parameter 1>
..

Rec. ITU-T G.8275 (01/2024) 31

TimeInterval <parameter 16>;
Boolean PMref;
};
Where PMref is defined as follows:
– TRUE: the Local PTP Clock (as per [IEEE 1588-2019]) is used to compute the statistics in
Table F.1
– FALSE: the Local PTP Clock (as per [IEEE 1588-2019]) is not used to compute the statistics
in Table F.1
NOTE – Only when a PTP instance has a port in TIME_RECEIVER state, the PM data collection is performed.

32 Rec. ITU-T G.8275 (01/2024)

 Appendix I

Architecture for time and phase distribution over a packet network

providing PTS at the protocol level
(This appendix does not form an integral part of this Recommendation.)

This appendix describes an alternative to the architecture for time and phase distribution using the
full timing support (FTS) described in this Recommendation, where not every network element is
required to provide timing support. It will operate over a unicast IP network, in a similar manner to
the existing frequency distribution architecture, but adapted to carry time and phase, as well as
frequency. The architecture and its associated PTP profile are still under development and the
accuracy and stability of time and phase distribution using this architecture is not yet known.
This future architecture is expected to address use cases where the operator wants to distribute
accurate time and phase over an existing network and cannot upgrade the network to provide timing
support in every network node. Additionally, a portion of the network may be provided by a third
party and outside the administrative scope of the primary operator. The performance aspects and
impacts of these use cases are still under study.
This appendix presents the initial concepts.

I.1 Architecture for PTS

The following four architectural aspects are covered in this appendix:
1) general packet-based timing distribution architecture;
2) timing protection aspects and functions;
3) partitioning across multiple administrative domains;
4) use of multiple underlying technologies.
I.1.1 Timing distribution architecture
[ITU-T G.8265] describes an architecture for frequency distribution using packet timing protocols.
In this architecture, a frequency reference is connected to a pTT clock and distributed to the pTR
clock using packet timing signals. The packet network itself is "timing unaware", i.e., it does not
contain any elements that provide assistance or correction to the packet timing signals.
The same method can be considered and adapted to distribute time and phase to the pTR clock. This
requires changing the frequency reference to a time reference derived from a PRTC (PRTC, normally
a GNSS receiver referencing time back to UTC). It also requires the timing protocol to operate in a
two-way mode, i.e., to send event messages in both directions. If the PTP protocol is used, this means
using both sync and delay_request messages.
The applications requiring accurate time and phase distribution described in [ITU-T G.8271] place a
much more stringent requirement on the network and the pTR clock performance than for the
frequency distribution. The objective is to address some of the classes described in [ITU-T G.8271].
To achieve this, it may be required to reduce the number and type of network elements that can be
traversed compared to [ITU-T G.8265.1] / [ITU-T G.8261.1] while still meeting the performance
requirements.
There are two main ways to accommodate this reduction:
1) use boundary clocks to break the network up into smaller segments (boundary clocks recover
and filter the timing from the original packet timing signal and generate a new packet timing
signal to forward the timing downstream);
2) move the PRTC and pTT clock closer to the pTR clock (i.e., a more distributed architecture).

Rec. ITU-T G.8275 (01/2024) 33

These approaches are shown in Figure I.1:

Figure I.1 – Modified architecture to support time and phase distribution

In both the cases, the stability and performance of the boundary clocks and pTR clock may be
enhanced by the provision of a stable physical layer frequency reference, such as a synchronous
Ethernet, if available, as shown in Figure I.2:

Figure I.2 – Use of a physical layer frequency reference (if available)

The specification of the boundary clock in Figure I.2 is not identical to the boundary clock for FTS.
Similarly, the specification of the packet timeReceiver (pTR) clock in Figure I.2 is not the same as
the pTR clock for FTS or the pTR clock for frequency described in [ITU-T G.8263].
Performance specifications for the clocks described in this appendix are for further study.
I.1.2 Timing protection aspects
One method of providing protection in case of a network failure is to provide access to an alternative
packet timeTransmitter (pTT) clock or a boundary clock. The details of the TT selection mechanism
are under study.

34 Rec. ITU-T G.8275 (01/2024)

A second method of protection is based on the use of a frequency reference (if available) to maintain
the time base of the various clocks. For example, [ITU-T G.8272] describes the use of a frequency
reference (such as a synchronous Ethernet) to maintain the PRTC output during periods when the
GNSS signal is unavailable.
This method can be applied to both the boundary clock and the pTR clock. A physical layer frequency
reference, if available, can be used to maintain the time output of the boundary clock and/or pTR
clock during periods when the packet timing signal is either unavailable or unusable. This is shown
in Figure I.3:

Figure I.3 – Protection using physical layer frequency references

I.1.3 Partitioning across multiple administrative domains
In some cases, operators purchase services from other operators in order to provide access to remote
equipment or networks. The use of the partial timing support (PTS) architecture permits the
distribution of time and phase across such alternative access vendors, even where such vendors may
not provide timing support, although the performance of such timing distribution schemes may be
undefined.
For example, Figure I.4 shows an example of such an alternative access provision. In this example, a
boundary clock is used to ensure a clean hand-off point to the second network operator.

Figure I.4 – Timing transmission over a second operator's network

Passing accurate phase/time between administrative domains is for further study. Issues surrounding
the demarcation of the packet timing flow and the transferred performance between operators may
exist. It may be difficult to determine the location of the performance problems especially if the packet
timing is passing through multiple administrative domains.

Rec. ITU-T G.8275 (01/2024) 35

When multiple administrative domains are involved, other methods may be required to deliver
accurate phase/time reference to the mobile network operator. For instance, a carrier operator may
provide a phase/time reference as a service. The details of these other methods are for further study.
I.1.4 Use of multiple underlying technologies
Packet networks are built on a number of different underlying technologies. Some technologies not
only create a packet delay variation (PDV), but also introduce significant asymmetry or difference in
delay between the forward and reverse paths. If uncorrected, this asymmetry will cause an error in
the pTR clock estimate of the correct time or phase.
Where such technologies are used, it will be necessary to verify that they are suitable for accurate
time and phase transfer, or that appropriate timing support has been built into the equipment. Details
of the PDV and the asymmetry contributions of individual transport technologies and their suitability
for accurate time and phase distribution are for further study.

36 Rec. ITU-T G.8275 (01/2024)

 Appendix II

An example of PRTC switching by the BTCA in a ring network

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

Figure II.1 and Figure II.2 show the normal and abnormal application scenarios. In the figures, the
working primary reference time clock (PRTC) has a higher priority than the backup PRTC.
Normally, the working PRTC (i.e., PRTC-1) sends frequency via a 2 048 kHz or 2 048 kbit/s signal
and phase/time via a 1 PPS + ToD signal to the T-BC that it is connected to. This T-BC is the GM,
and all the network elements including the T-BC connected to the backup PRTC (i.e., PRTC-2) track
the phase/time of the working PRTC, as shown in Figure II.1.

Figure II.1 − Normal state (T-BC connected to working PRTC is working as a GM)

If, at some time, PRTC-1 is degraded (e.g., the GNSS signal is lost), or the connection between
PRTC-1 and the T-BC it is connected to fails, PRTC-2 becomes the working PRTC. All the network
elements will then track the phase/time of PRTC-2, and the T-BC initially connected to PRTC-1 will
no longer be the GM, as shown in Figure II.2.

Rec. ITU-T G.8275 (01/2024) 37

 Figure II.2 – Abnormal state (the working PRTC has failed)

The above operation can be obtained using the best TimeTransmitter clock algorithm (BTCA) by
setting the clockClass of PRTC-1 and PRTC-2 to 6 when they are operating normally (i.e., when they
are traceable to a GNSS) and setting priority2 for PRTC-1 to be better (i.e., to have a smaller value)
than priority2 for PRTC-1. Both PRTC-1 and PRTC-2 are attached to the respective T-BCs via virtual
PTP ports (see [ITU-T G.8275.1]), and the respective PTP attributes, which include clockClass and
priority2 are transferred via the 1 PPS+ToD interfaces to the virtual PTP ports (see [ITU-T G.8271]).
With these values for clockClass and priority2 (and with clockAccuracy and
offsetScaledLogVariance of PRTC-1 and PRTC-2 the same) PRTC-1 will win the BTCA when it is
operating normally because its clockClass will be the same or better than the clockClass of PRTC-2
and its priority2 will be better than priority2 of PRTC-2. If PRTC-1 degrades, its clockClass will be
worse than that of PRTC-2 and PRTC-2 will win the BTCA. If PRTC-1 is lost (i.e., the connection
from PRTC-1 to the T-BC it is attached to is cut), there will be no input to the virtual PTP port and
PRTC-2 will win the BTCA.

38 Rec. ITU-T G.8275 (01/2024)

 Appendix III

Generic IWF node

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

III.1 Introduction
In some deployment scenarios, an inter-working function (IWF) may be used to connect
synchronization network segments that are running different precision time protocol (PTP) profiles.
An example is shown below in Figure III.1 where an IWF node, containing a clock among other
functions, would be needed to translate from the FTS profile ([ITU-T G.8275.1]) to the PTS
([ITU-T G.8275.2]) going downstream from the T-GM towards the end application. In this case, the
IWF node may be denoted as IWF F-P to indicate the direction of the profile translation from full to
partial. Similarly, IWF P-F indicates the direction of the profile translation from partial to full.

Figure III.1 – Deployment case requiring IWF node

A model for the IWF node is shown in Figure III.2. This IWF node uses a virtual PTP port to inter-
connect PTP clocks from different PTP profiles. The IWF node consists of several aspects.
− IWF PTP clock A, running profile A
○ several PTP ports
○ output virtual PTP port
○ clock A datasets
− IWF PTP clock B, running profile B
○ several PTP ports
○ input virtual PTP port
○ clock B datasets
− IWF profile translation

Rec. ITU-T G.8275 (01/2024) 39

 Figure III.2 – Model of a telecom profile IWF node

Figure III.2 profile IWF node represents the same concept that was later introduced in
[IEEE 1588-2019] as a "PTP profile gateway" in Annex O, specifically Figure O.7 of
[IEEE 1588-2019], with
– Output virtual PTP port block seen as the "sink adapter block",
– Profile translator block seen as the "profile / domain adapter block",
– Input virtual PTP port seen as the "source adapter block".
A typical scenario would have a uni-directional timing service flowing from one profile (profile A)
to the other profile (profile B). The performance of such a node may be defined in a Recommendation
and may be built as a timeReceiver clock of profile A and a grandmaster clock of profile B, where
profile A and profile B are participating in different PTP domains. Continuing the description of the
typical scenario, the IWF PTP clock A, configured with profile A, would operate as a
timeReceiverOnly clock, while the IWF PTP clock B, configured with profile B, would operate as a
grandmaster clock with timeTransmitterOnly PTP ports. The IWF PTP clock A would comply with
all the requirements defined for profile A and the IWF PTP clock B would comply with all the
requirements defined for profile B.
For IWF F-P and P-F, the node performance limits mainly consider the type of network used on the
timeReceiver port, regardless of the one used on the timeTransmitter port.
– For a synchronization interworking function IWF F-P translating from the FTS profile
([ITU-T G.8275.1]) to the PTS profile ([ITU-T G.8275.2]), the performance limits may be
the same as those for a T-BC in [b-ITU-T G.8273.2].
– For a synchronization interworking function IWF P-F translating from the PTS profile
([ITU-T G.8275.2]) to the FTS profile ([ITU-T G.8275.1]), the performance limits may be
the same as those for a T-BC-A or T-BC-P in [b-ITU-T G.8273.4].
However, application-specific implementations with different limits are also allowed. It is the
responsibility of the operator to choose the appropriate type of IWF node based on the network
configuration.

III.2 Inter-working between the [ITU-T G.8275.1] and [ITU-T G.8275.2] profiles
The interworking function translating between the [ITU-T G.8275.1] and [ITU-T G.8275.2] profiles
is simplified due to the many common aspects shared between these two profiles. Table III.1 outlines
the areas of commonality as well as differences between the two profiles.

40 Rec. ITU-T G.8275 (01/2024)

 Table III.1 – Common aspects and differences between
the [ITU-T G.8275.1] and [ITU-T G.8275.2] profiles
Functionality [ITU-T G.8275.1] [ITU-T G.8275.2]
Network support FTS from network PTS from the network
Transport layer Transport of PTP over [b-IEEE PTP transport over UDP/IPv4
802.3]/Ethernet PTP transport over UDP/IPv6
Transport of PTP over optical transport
network (OTN).
Domain 24-43 44-63
deviceTypes (BC) T-BC T-BC-P, T-BC-A
(synchronized by another PTP clock, or
can become T-GM)
Message rates Fixed rates Negotiated rates
• Sync: 16 pkts/s • Sync: 1-128 pkts/s
• Delay_req: 16 pkts/s • Delay_req: 1-128 pkts/s
• Announce: 8 pkts/s • Announce: 1-8 pkts/s
• Signalling FFS • Signalling: used for unicast rate
• Management FFS negotiation
• Management FFS
Network architecture Use-cases and architecture per ITU-T G.8275 (this Recommendation)
BTCA Common (same) ABTCA
Fields ignored controlField,
(common behaviour) priority1,
PTP profile specific 1,2 = FALSE,
Reserved = FALSE
Fields ignored unicastFlag –
(different behaviour)
Fields used • ptpTimescale must be TRUE (not ignored, it must actually be true)
(common behaviour) • twoStepFlag, leap61, leap59, currentUtcOffsetValid same definition as
[IEEE 1588]
• timeTraceable, frequencyTraceable
Fields used unicastFlag must be FALSE unicastFlag must be TRUE
(different behaviour)
Asymmetry control – Static asymmetry controlled using
assisted PTS
Physical layer Physical layer frequency support using Physical layer frequency support is
SyncE/E1/T1 optional
Unicast negotiation No (not allowed) Yes (allowed – must be supported)
support
VLAN allowed No Yes
When the PTP profiles are part of an IWF node, they may be modelled as inter-connected using a
virtual PTP port that is described in Annex B through an IWF profile translation block. Table III.2
provides information on how these parameters can be set or translated between profiles in the IWF
profile translation block. This Table does not define that these must be the values used on the internal
virtual PTP port inside the equipment.

Rec. ITU-T G.8275 (01/2024) 41

 Table III.2 – Translation between the [ITU-T G.8275.1] and the [ITU-T G.8275.2] profiles
Group Field In profile A: In profile A:
[ITU-T G.8275.1] [ITU-T G.8275.2]
Out profile B: Out profile B:
[ITU-T G.8275.2] [ITU-T G.8275.1]
Time properties DS Leap61 Direct mapping Direct mapping
Time properties DS Leap59 Direct mapping Direct mapping
Time properties DS currentUtcOffsetValid Direct mapping Direct mapping
Time properties DS ptpTimescale No translation; set No translation; set TRUE
TRUE
Time properties DS timeTraceable Direct mapping Direct mapping
Time properties DS frequencyTraceable Direct mapping Direct mapping
Time properties DS timeSource Direct mapping Direct mapping
Time properties DS currentUtcOffset Direct mapping Direct mapping
Parent DS grandmasterIdentity Note 1 Note 1
Parent DS grandmasterClockQuality.c Direct mapping Direct mapping
lockClass
Parent DS grandmasterClockQuality.c Note 2 Note 2
lockAccuracy
Parent DS grandmasterClockQuality.o Note 2 Note 2
ffsetScaledLogVariance
Parent DS grandmasterPriority1 Direct mapping Direct mapping
Parent DS grandmasterPriority2 Direct mapping Direct mapping
Other stepsRemoved 0 0
Other version No translation; set by No translation; set by
'Profile B' 'Profile B'
Other domain number No translation; set by No translation; set by
'Profile B' 'Profile B'
Other Time of day From 'Profile A' clock From 'Profile A' clock
Local Signal Fail (SF) See Annex B, Note 2 See Annex B, Note 2
Local localPriority No translation, set by No translation, set by
'Profile B' 'Profile B'
Local port number See Annex B, Note 4 See Annex B, Note 4
NOTE 1 – The grandmasterIdentity assigned to the input virtual PTP port is the clockIdentity of the PTP
clock profile B.
NOTE 2 – The clockQuality.clockAccuracy and clockQuality.offsetScaledLogVariance should reflect the
actual (degraded) clockQuality of the PTP connection at reference point B2P (see Figure III.1), if known.
Otherwise, clockQuality.clockAccuracy and clockQualtiy.offsetScaledLogVariance are directly mapped.

III.3 Generation of the physical layer frequency signal by the IWF

A synchronization IWF F-P node has an input PTP reference timing signal carried over an FTS
synchronization network that includes a mandatory physical layer frequency signal (e.g., SyncE,
SDH, etc.), and delivers a PTP reference timing signal carried over a PTS synchronization network.

42 Rec. ITU-T G.8275 (01/2024)

NOTE 1 – The physical layer frequency signal generation is optional on the PTS port(s). If used, it is specified
by the physical layer-based frequency synchronization requirements ([b-ITU-T G.812], [ITU-T G.8262], and
[ITU-T G.8262.1] for frequency and time error, [b-ITU-T G.781] and [ITU-T G.8264] for SSM QL-TLV).
A synchronization IWF P-F node has an input PTP reference timing signal carried over a PTS
synchronization network that includes an optional physical layer frequency signal (e.g., SyncE, SDH,
etc.), and delivers a PTP reference timing signal carried over an FTS synchronization network.
NOTE 2 – The physical layer frequency signal generation is mandatory on the FTS port(s). If a valid physical
layer frequency signal is delivered by the upstream PTS network and if the synchronization IWF P-F node
supports the distribution of such a signal, then this distribution is specified by the physical layer-based
frequency synchronization requirements ([b-ITU-T G.812], [ITU-T G.8262], [ITU-T G.8262.1] for frequency
and time error, [b-ITU-T G.781] and [ITU-T G.8264] for SSM QL-TLV). Otherwise, the quality level to be
used on the physical layer frequency signal shall be generated following the rules defined in Annex F of
[ITU-T G.8275.2].

III.4 Mapping IWF to telecom PTP clocks

An IWF F-P is used to denote an IWF node that translates from the FTS profile ([ITU-T G.8275.1])
to the PTS profile ([ITU-T G.8275.2]); the direction of the profile translation is full to partial. In this
case the IWF F-P may be modelled as a combination of a T-TSC or T-BC (represented by the inner
element IWF PTP clock A in Figure III.2) from [ITU-T G.8275.1] and a T-GM (represented by the
inner element IWF PTP clock B in Figure III.2) from [ITU-T G.8275.2].
An IWF P-F is used to denote an IWF node that translates from the PTS profile ([ITU-T G.8275.2])
to the full timing support (FTS) profile ([ITU-T G.8275.1]); the direction of the profile translation is
partial to full. In this case the IWF P-F may be modelled as a combination of a T-TSC-A or T-TSC-
P (represented by the inner element IWF PTP clock A in Figure III.2) from [ITU-T G.8275.2] and a
T-GM (represented by the inner element IWF PTP clock B in Figure III.2) from [ITU-T G.8275.1]).
The modelling of the IWF F-P and the IWF P-F as telecom clocks from [ITU-T G.8275.1] and
[ITU-T G.8275.2] does not imply that the IWF node is compliant with all the requirements for those
equipment clocks, which are designed to be used as a standalone equipment.

Table III.3 – Mapping between IWF node type, [ITU-T G.8275.1], [ITU-T G.8275.2]
deviceTypes and IEEE 1588 clockTypes
IWF PTP deviceTypes from clockTypes from
node type profile [ITU-T G.8275.1] and [ITU-T G.8275.2] [IEEE 1588]
IWF F-P A T-TSC or T-BC OC or BC
(ITU-T G.8275.1)
B T-GM OC or BC
(ITU-T G.8275.2)
IWF P-F A T-TSC-P or T-TSC-A OC or BC
(ITU-T G.8275.2)
B T-GM OC or BC
(ITU-T G.8275.1)

Rec. ITU-T G.8275 (01/2024) 43

 Appendix IV

Use cases for mapping from PTP clockClass values to quality levels
(This appendix does not form an integral part of this Recommendation.)

This appendix provides use cases for mapping from PTP clockClass values to quality levels (QLs)
for use by synchronization status message (SSM) and Ethernet synchronization messaging channel
(ESMC) when using the PTP time profile for frequency recovery.

IV.1 Use case I

Due to the evolution from 3G to 4G, base stations of different generations coexist. In some situations,
two different base stations, such as where a wideband code division multiple access (WCDMA)
station and a long-term evolution (LTE) station are connected to the same node. As shown in
Figure IV.1, a WCDMA station and an LTE station are connected to the same [ITU-G.8275.2]
T-TSC-P/T-TSC-A node. The WCDMA station requires a frequency signal from the T-TSC-P/T-
TSC-A node. However, in the scenario of partial-PTP timing support, the node can only get PTP
messages through the middle network that does not support PTP and SyncE functions. Therefore, to
provide a frequency signal to the WCDMA station, the T-TSC-P/ T-TSC-A node has to transform the
PTP clockClass values into QLs. In this case, the mapping from PTP clockClass values to QLs is
required.

Figure IV.1 – Use case I

IV.2 Use case II

To provide frequency and time service to a local network area (e.g., to deploy the small cells in a
building) and meet the stringent accuracy requirement, one possible convenient solution is to deploy
a boundary clock with a global navigation satellite system (GNSS) input close to an access network
area rather than rely on the grandmaster (GM) in the core network.
This type of boundary clock with a GNSS input usually supports at least two types of input sources:
GNSS or PTP input from the upstream network. The boundary clock with a GNSS input also provides
the PTP output and frequency output (e.g., SyncE or 2 048 kHz / 2 048 kbit/s) simultaneously, to
support various applications.
When the boundary clock with a GNSS input chooses the PTP input and provides the frequency
output, it should support transforming the PTP clockClass values into QLs. For example, in
Figure IV.2, the boundary clock with the GNSS input is deployed close to the small cells and provides
services for users within a certain area. The boundary clock with the GNSS input may get a time
source via a full- or partial-PTP path. At the same time, the boundary clock with the GNSS input
offers time and frequency services to the small cells. To provide frequency service for the small cells,
the mapping from PTP clockClass values to QLs is also required for the boundary clock with the
GNSS input.

44 Rec. ITU-T G.8275 (01/2024)

Figure IV.2 – Use case II

Rec. ITU-T G.8275 (01/2024) 45

 Appendix V

Deployment examples and the use of partially aware deviceTypes

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

This Recommendation includes several partially aware deviceTypes: T-TSC-A, T-TSC-P, T-BC-A
and T-BC-P. Figure V.1 illustrates the potential use of these clocks in example network deployments.
The examples included in the figure are not meant to be exhaustive of all the possible network
deployments, but it shows a few simple examples that provide clarity between the partially aware
deviceTypes.
– Example 1 shows a T-GM with a direct PTP connection to a T-TSC-P, without any
intermediate T-BC-P or T-BC-A.
– Example 2 shows a T-GM with a direct PTP connection to a T-TSC-A that has local time
reference (LTR) support for asymmetry compensation, without any intermediate T-BC-P or
T-BC-A.
– Example 3 shows a T-GM with a PTP connection to a T-BC-P, which in turn has a PTP
connection to a T-TSC-P.
– Example 4 shows a T-GM with a PTP connection to a T-BC-P, which in turn has a PTP
connection to a T-TSC-A. The T-TSC-A has local time reference support for asymmetry
compensation.
– Example 5 shows a T-GM with a PTP connection to a T-BC-A, which in turn has a PTP
connection to a T-TSC-P. The T-BC-A has local time reference support for asymmetry
compensation.
– Example 6 shows a T-GM with a PTP connection to a T-BC-A, which in turn has a PTP
connection to a T-TSC-A. The T-TSC-A has local time reference support for asymmetry
compensation.

Figure V.1 – Scenarios showing T-BC-A and T-BC-P in PTS and APTS

46 Rec. ITU-T G.8275 (01/2024)

NOTE 1 – The PRTC and the T-GM may be embedded in the same equipment.
NOTE 2 – The T-TSC-A or T-TSC-P and the end application clock may be embedded in the same equipment.
NOTE 3 – The local time reference may be in a separate, co-located equipment, or embedded within the same
equipment, as the T-BC-A or T-TSC-A.
NOTE 4 – The examples show no or one T-BC-P or T-BC-A between the T-GM and the T-TSC-P or T-TSC-A;
other numbers of T-BC-P or T-BC-A are also possible.

Rec. ITU-T G.8275 (01/2024) 47

 Appendix VI

cnPRTC functional architecture

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

The contents of this appendix have been moved into Appendix I of [b-ITU-T G.8272.2].

48 Rec. ITU-T G.8275 (01/2024)

 Appendix VII

cnPRTC deployment scenarios

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

For coherent network PRTC (cnPRTC) network deployment, the following scenarios are proposed
for a step-by-step deployment approach. The scenarios can be regarded as network migration
guidelines.
The network specific deployment depends on many factors, such as specific network architecture,
availability of time transfer links, network size, etc. Therefore, using the specific scenarios for a
specific network is up to the network operator.

Scenario 1:
• As basis: To deploy stand-alone enhanced PRTC (ePRTC) functions according to
[b-ITU-T G.8272.1].
• This scenario would allow a network operator to start with several ePRTC functions
according to [b-ITU-T G.8272.1] at centralized locations. Connecting time transfer links are
not needed.

Scenario 2:
• To mesh neighbourhood cnPRTC location with time transfer links.
• This scenario introduces time transfer links from / to neighbourhood locations which allow
measurement between them, in order to have the performance under control and have an early
fault detection mechanism. Depending on the network operator's implementation strategy
and roll-out time frame, this scenario may not be needed for specific networks.

Scenario 3
• Active usage of all available sources for local timescale generation.
• Scenario 3 provides the full cnPRTC functionality according to the architectural concept as
part of [ITU-T G.8275] in a very robust way to overcome any GNSS issues or any system
defects.
All sources will be used for local timescale generation including frequency, phase, and time
according to their individual assigned weight.
Table VII.1 provides an overview of the three deployment scenarios:

Rec. ITU-T G.8275 (01/2024) 49

 Table VII.1 – Summary of deployment scenario capabilities

Used sources and logical functions

Local sources Remote sources Logical functions

De-
ploy- UTC(k)
Time Transfer links
ment 1) from/to neigh-
Clock Descriptions
sce- borhood e/cnPRTC Measure- GNSS
PRC/ from a Com- Output
nario PRTC nodes ment Common
ePRC remote biner function
function view
# UTC(k) function
for for local
lab
measure- ensem-
ment bling 2)
Stand-alone ePRTC according to
1 YES YES NO NO Optional YES YES
G.8272.1
Like cnPRTC, but monitoring the
2 YES YES YES NO
Optional
YES YES YES
Optional remote sources only

Final cnPRTC architecture ,

3 YES YES YES YES YES YES YES
remote sources are actively used

1) e. g. IEEE1588v2.1 (High-accuracy profile), or ITU-T PTP-FTS/SyncE

2) to contribute to local time

50 Rec. ITU-T G.8275 (01/2024)

 Appendix VIII

Description of PTP clock modes and associated contents of Announce messages

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

VIII.1 Purpose of this appendix

This appendix provides information related to possible T-GM, T-BC, T-BC-P, and T-BC-A clock
modes. The intention of the clock mode information is to provide a high-level indication of the
operational status of the entire clock as opposed to just individual precision time protocol (PTP) ports.
It provides a mapping between the clock modes and the PTP port states as defined in [IEEE 1588].
In addition, it provides a table showing the content of the Announce message fields that will occur in
the various clock modes.
The acquiring clock mode, if included in an implementation, allows a T-GM, T-BC, T-BC-P, or T-
BC-A to delay the distribution of grandmaster (GM) information transmitted by the clock. The
purpose of this acquiring clock mode is to allow a T-GM T-BC, T-BC-P, or T-BC-A some time to
establish a timescale with acceptable accuracy before using it for the clock's node time.
NOTE − The procedures defined within this appendix for the Acquiring clock mode are not compliant with
the procedures of [IEEE 1588] and the delay introduced by this mode can impact the overall settling time
during PTP topology rearrangements.
Network deployments including clocks using the procedures of this appendix are under the operator's
responsibility.

VIII.2 Description of the modes

– Free-Run mode
The PTP clock has never been synchronized to a time source and is not in the process of
synchronizing to a time source.
As it relates to the PTP port state defined in [IEEE 1588], a clock is in free-run mode if there
are no PTP ports in: PRE_TIME_TRANSMITTER, PASSIVE, UNCALIBRATED or
TIME_RECEIVER states.
– Acquiring mode
The PTP clock is in the process of synchronizing to a time source. The duration and
functionality of this mode is implementation specific. This mode is not required in an
implementation.
As it relates to the PTP port state defined in [IEEE 1588], a clock is in acquiring mode if
there is a PTP port in the UNCALIBRATED state.
– Locked mode
The PTP clock is synchronized to a time source and is within some internal acceptable
accuracy.
As it relates to the PTP port state defined in [IEEE 1588], a clock is in locked mode if there
is a PTP port in the TIME_RECEIVER state.
– Holdover-in-specification mode
The PTP clock is no longer synchronized to a time source and is using information obtained
while it was previously synchronized or other information sources were still available, in
order to maintain performance within the desired specification. The node may be relying
solely on its own facilities for holdover or may use something like a frequency input from
the network to achieve a holdover of time and/or phase.

Rec. ITU-T G.8275 (01/2024) 51

 As it relates to the PTP port state defined in [IEEE 1588], a clock is in holdover-in-
specification mode if there are no PTP ports in: INITIALIZING, LISTENING,
UNCALIBRATED or TIME_RECEIVER states, and performance is within the desired
specification.
– Holdover-out-of-specification mode
The PTP clock is no longer synchronized to a time source and, while it may be using
information obtained while it was previously synchronized or other information sources were
still available, it is unable to maintain performance within the desired specification.
As it relates to the PTP port state defined in [IEEE 1588], a clock is in holdover-of-out-
specification mode if there are no PTP ports in: INITIALIZING, LISTENING,
UNCALIBRATED or TIME_RECEIVER states, and performance is not within the desired
specification.

VIII.3 Example of mapping between PTP port states and PTP clock modes for a 3-port
T-BC/T-BC-P/T-BC-A

Table VIII.1 − PTP port state vs clock mode mapping

Telecom boundary clock
Port state Clock mode
Trigger event Port 1 Port 2 Port 3 Notes
INITIALIZING INITIALIZING INITIALIZING Free-run No port in TT,
PASSIVE,
Power up of PTP
UNCALIBRATED,
or TR
LISTENING LISTENING LISTENING Free-run No port in TT,
Clock completes PASSIVE,
initialization UNCALIBRATED,
or TR
Qualified Announce UNCALIBRATED LISTENING LISTENING Acquiring A port is in
received from foreign UNCALIBRATED
TT on port P1 state
ANNOUNCE_RECEI UNCALIBRATED TT TT Acquiring
A port is in
PT_TIMEOUT_EXPI
UNCALIBRATED
RES event on ports P2 state
and P3
Calibration finished on TR TT TT Locked A TR port exists on
port P1 the node
TT TT TT Holdover-in- Start holdover timer
ANNOUNCE_RECEI specification No port in TR,
PT_TIMEOUT_EXPI UNCALIBRATED,
RES event on port P1 LISTENING, or
INITIALIZING
Holdover timer expires TT TT TT Holdover-out-of- Holdover timer
specification expired and no port
in TR,
UNCALIBRATED,
LISTENING, or
INITIALIZING
Port P3 receives TT TT UNCALIBRATE Acquiring A port is in
qualified Announce D UNCALIBRATED
with clockClass = 7 state
Calibration finished on TT TT TR Locked A TR port exists on
port P3 the node

52 Rec. ITU-T G.8275 (01/2024)

 Table VIII.1 − PTP port state vs clock mode mapping
Telecom boundary clock
Port state Clock mode
Trigger event Port 1 Port 2 Port 3 Notes
Port P1 receives UNCALIBRATED TT PRE_TT Acquiring A port is in
qualified Announce UNCALIBRATED
with clockClass = 6 state
QUALIFICATION_TI UNCALIBRATED TT TT Acquiring A port is in
MEOUT_EXPIRES UNCALIBRATED
event on port P3 state
Calibration finished on TR TT TT Locked A TR port exists on
port P1 the node

VIII.4 T-GM Announce message contents based on the internal PTP clock modes

Table VIII.2 − T-GM Announce message contents

Free-run Acquiring Locked Holdover-in- Holdover-out-of-
Announce message fields
mode mode mode specification mode specification mode
sourcePortIdentity Local clockId Local clockId of Local Local clockId of the Local clockId of the
(header.sourcePortIdentity) of the T-GM the T-GM + Port clockId of T-GM + Port T-GM + Port number
+ Port number the T-GM + number
number Port number
leap61 (header.flagField) FALSE From time From time TRUE / FALSE TRUE / FALSE
source source (Note 2) [Implementation
specific]
(Note 2)
leap59 (header.flagField) FALSE From time From time TRUE / FALSE TRUE / FALSE
source source (Note 2) [Implementation
specific]
(Note 2)
currentUtcOffsetValid FALSE TRUE / FALSE TRUE TRUE / FALSE TRUE / FALSE
(header.flagField) [Implementation (Note 2) [Implementation
specific] specific]
(Note 2)
ptpTimescale TRUE TRUE TRUE TRUE TRUE
(header.flagField)
timeTraceable FALSE TRUE / FALSE TRUE TRUE FALSE
(header.flagField) [Implementation
specific]
frequencyTraceable TRUE/ TRUE / FALSE TRUE TRUE / FALSE TRUE / FALSE
(header.flagField) FALSE based on based on frequency based on frequency
based on frequency source source lock source lock
frequency lock
source lock
currentUtcOffset As per PTP Based on input Based on Last known Last known
reference UTC input UTC offset UTC offset
offset reference (Note 2) (Note 2)
UTC offset
grandmasterPriority1 128 (default) 128 (default) 128 128 (default) 128 (default)
(default)
grandmasterClockQuality.cl 248 Implementation 6 7 140/150/160
ockClass specific,
generally
previous state

Rec. ITU-T G.8275 (01/2024) 53

 Table VIII.2 − T-GM Announce message contents
Free-run Acquiring Locked Holdover-in- Holdover-out-of-
Announce message fields
mode mode mode specification mode specification mode
7/140/150/160/2
48
grandmasterClockQuality.cl Unknown Unknown 0x21, Unknown (0xFE) Unknown (0xFE)
ockAccuracy (0xFE) (0xFE) 0x20
grandmasterClockQuality.o 0xFFFF 0xFFFF (default) 0x4E5D, 0xFFFF (default) 0xFFFF (default)
ffsetScaledLog (default) 0x4B32
Variance
grandmasterPriority2 Configured Configured Configured Configured Configured priority2
priority2 of priority2 of the priority2 of priority2 of the of the T-GM
the T-GM T-GM the T-GM T-GM
grandmasterIdentity Local clockId Local clockId of Local Local clockId of the Local clockId of the
of the T-GM the T-GM clockId of T-GM T GM
the T-GM
stepsRemoved 0 0 0 0 0
timeSource INT_OSC INT_OSC As per PTP INT_OSC (0xA0) INT_OSC (0xA0)
(0xA0) (0xA0)
synchronizationUncertain TRUE TRUE FALSE FALSE (Note 3) TRUE (Note 3)
(header.flagField) (Note 3) (Note 3)
NOTE 1 – Time properties (leap61, leap59, currentUtcOffsetValid, currentUtcOffset) can be obtained from time source (GNSS or
ToD) or user configuration.
NOTE 2 − Refer to Table A.8 of [ITU-T G.8275.1] or Table A.6 of [ITU-T G.8275.2].
NOTE 3 – Or as defined in Annex D.

VIII.5 T-BC/T-BC-P/T-BC-A Announce message contents based on the internal PTP clock
modes

Table VIII.3 − T-BC/T-BC-P/T-BC-A Announce message contents

Holdover-in-
Acquiring Locked Holdover-out-of-
Announce message fields Free-run mode specification
mode mode specification mode
mode
sourcePortIdentity Local clockId Local clockId of Local clockId Local clockId Local clockId of the
(header.sourcePortIdentity) of the T-BC/T- the T-BC/T-BC- of the of the T-BC/T- T-BC/T-BC-P/T-BC-A +
BC-P/T-BC-A P/T-BC-A + T-BC/T-BC- BC-P/T-BC-A Port number
+ Port number Port number P/T-BC-A + + Port number
Port number
leap61 (header.flagField) FALSE (Note 1) (Note 1) TRUE / TRUE / FALSE
FALSE [Implementation
(Note 2) specific]
(Note 2)
leap59 (header.flagField) FALSE (Note 1) (Note 1) TRUE / TRUE / FALSE
FALSE [Implementation
(Note 2) specific]
(Note 2)
currentUtcOffsetValid FALSE Implementation (Note 1) TRUE / TRUE / FALSE
(header.flagField) specific, FALSE [Implementation
generally (Note 2) specific]
previous state. (Note 2)
TRUE / FALSE
ptpTimescale TRUE TRUE (Note 1) TRUE TRUE
(header.flagField)
timeTraceable FALSE Implementation (Note 1) TRUE FALSE
(header.flagField) specific,

54 Rec. ITU-T G.8275 (01/2024)

 Table VIII.3 − T-BC/T-BC-P/T-BC-A Announce message contents
Holdover-in-
Acquiring Locked Holdover-out-of-
Announce message fields Free-run mode specification
mode mode specification mode
mode
generally
previous state.
TRUE / FALSE
frequencyTraceable TRUE / TRUE / FALSE (Note 1) TRUE / TRUE / FALSE based on
(header.flagField) FALSE based on FALSE based Frequency source lock
Frequency on frequency
based on
Source lock source lock
frequency
source lock
currentUtcOffset As per PTP Last known (Note 1) Last known Last known UTC offset
UTC offset UTC offset (Note 2)
grandmasterPriority1 128 (default) 128 (default) (Note 1) 128 (default) 128 (default)
grandmasterClockQuality. 248 Implementation (Note 1) 135 165
clockClass specific,
generally
previous state.
135/165/248
grandmasterClockQuality. Unknown Unknown (Note 1) Unknown Unknown (0xFE)
clockAccuracy (0xFE) (0xFE) (0xFE)
grandmasterClockQuality. 0xFFFF 0xFFFF (Note 1) 0xFFFF 0xFFFF (default)
offsetScaledLogVariance (default) (default) (default)
grandmasterPriority2 Configured Configured (Note 1) Configured Configured priority2 of
priority2 of the priority2 of the priority2 of the the T-BC/T-BC-P/
T-BC/T-BC- T-BC/T-BC- T-BC/T-BC- T-BC-A
P/T-BC-A P/T-BC-A P/T-BC-A
grandmasterIdentity Local clockId Local clockId of (Note 1) Local clockId Local clockId of the
of the T-BC/T- the T-BC/T-BC- of the T-BC/T- T-BC/T-BC-P/T-BC-A
BC-P/T-BC-A P/T-BC-A BC-P/T-BC-A
stepsRemoved 0 0 Received 0 0
stepsRemove
d +1 (Note 6)
timeSource INT_OSC INT_OSC (Note 1) INT_OSC INT_OSC (0xA0)
(0xA0) (0xA0) (0xA0)
synchronizationUncertain TRUE (Note 5) TRUE (Note 4) (Note 4) (Note 4)
(header.flagField)
NOTE 1 − The value sent in the Announce message corresponds to the value of the current grandmaster or time interface (as per
[ITU-T G.8272] Appendix III) in case T-BC/T-BC-P/T-BC-A has selected a virtual port as the best timeTransmitter.
NOTE 2 − Refer to Table A.8 of [ITU-T G.8275.1] or Table A.6 of [ITU-T G.8275.2].
NOTE 3 – Valid UTC offset is one advertised by timeTransmitter with currentUtcOffsetValid value TRUE. In case there is no
such value available, either default initializing UTC offset or one advertised by timeTransmitter with currentUtcOffsetValid as
false can be used.
NOTE 4 − The value sent in the Announce message corresponds to the value received from the current parent clock or as defined
in Annex D.
NOTE 5 – Or as defined in Annex D.
NOTE 6 – Or an implementation may send zero if the T-BC is locked to an embedded PRTC. (Refer to [IEEE 1588]
clause 8.2.2.2 currentDS.stepsRemoved)

Rec. ITU-T G.8275 (01/2024) 55

 Appendix IX

Considerations on the use of [IEEE 1588-2019]

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

As per clause 19 in [IEEE 1588-2019], an [IEEE 1588-2019] compliant implementation is fully

interoperable with an [IEEE 1588-2008] compliant version, provided that no new [IEEE 1588-2019]
options are used.
There are a few minor additions in the precision time protocol (PTP) header specified by [IEEE 1588-
2019], on bits that were earlier reserved: the minorVersionPTP and the minorSdoId. In this respect,
the following apply for the telecom profiles:
• for an [IEEE 1588-2008] compliant implementation, on transmit these fields are reserved and
are set to zero.
• for an [IEEE 1588-2019] compliant implementation, on transmit for these fields the
minorVersionPTP is set to 1 and the minorSdoId is set to zero.
• for an [IEEE 1588-2008] compliant implementation, on receive these fields are reserved and
ignored.
• for an [IEEE 1588-2019] compliant implementation, on receive these fields are not ignored,
but are properly handled according to the value.

56 Rec. ITU-T G.8275 (01/2024)

 Appendix X

Flexible synchronization network based on cnPRTC

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

Mobile networks are critical infrastructure; they must be protected to overcome risks due to improper
timing and synchronization. The coherent network PRTC (cnPRTC) architecture itself is a very
resilient system and can overcome many threats, hazards, or disruptions even if they occur over an
extended time. Specific situations with unavailability of timing and synchronization sources or
limited network availability may require the flexibility of the synchronization network architecture.
A re-configuration may be needed depending on the specific situation.
With coordinated universal time UTC(k) insertion at one or more cnPRTC clock combiners, the entire
cnPRTC architecture becomes more flexible. For example, the neighbouring cnPRTC nodes could
use the signals coming from cnPRTC nodes with UTC(k) insertion with higher priority by
configuration.
Upon operational request, parts of the system could be reconfigured in a hierarchical structure, still
maintaining the resilience of a cnPRTC. In an emergency, the entire system could be reconfigured as
fully hierarchical.
A few examples follow:
(1) cnPRTC architecture, using UTC(k) at one location
Figure X.1 shows a cnPRTC architecture, using one UTC(k) at one location. The red line is used to
indicate the UTC(k) connection in the figure; the blue lines refer to regular cnPRTC operation. In this
example, only one local cnPRTC system is set to UTC(k).

Figure X.1 – cnPRTC architecture, using actively one UTC(k) at one location
(2) cnPRTC architecture, using UTC(k) at three locations
Figure X.2 shows a cnPRTC architecture using one UTC(k) at three locations. In this case, one local
cnPRTC system is set to UTC(k). The red lines indicate UTC(k) connections and the blue lines
indicate regular cnPRTC operation. For the cnPRTC system in the middle, it is a local UTC(k) source.

Rec. ITU-T G.8275 (01/2024) 57

For the other two, it is via remote high-accuracy time transfer according to [ITU-T G.8271.1], which
is specified with a maximum time error of 1 ns (Class B).

Figure X.2 – cnPRTC architecture with three UTC insertion nodes as an example
(3) cnPRTC architecture, using UTC(k) at three locations for active further hierarchical
synchronization
Figure X.3 shows a cnPRTC architecture, as before, using one UTC(k) actively at three locations. In
addition, a section is configured for further hierarchical distribution.

Figure X.3 – cnPRTC architecture with three UTC insertion nodes

with further hierarchical synchronization

58 Rec. ITU-T G.8275 (01/2024)

(4) In the case of massive primary source and / or network problems, the theoretical end point of
such a reconfiguration could be a full hierarchical structure for the reachable part of the
network. This would be at the expense of cnPRTC resilience.

Rec. ITU-T G.8275 (01/2024) 59

 Appendix XI

Information that can be used in the analysis of

the performance monitoring data
(This appendix does not form an integral part of this Recommendation.)

When analysing the PM data specified in Annex F of this Recommendation, there is some additional
information that is typically also available in the device (e.g., because related to standard SyncPHY
and PTP datasets) and could allow a more complete and accurate correlation analysis.
Some of this information could be collected periodically (e.g., at the same time when the performance
monitoring data is collected) or when some event happens (e.g., alarms).
As an example, the information from the defaultDS can provide important details on the
characteristics of the PTP clock itself (e.g., deviceType, profileIdentifier clockIdentity, clockClass,
etc.). Information from the currentDS and parentDS, can provide details on the reference (being
tested), e.g., grandmasterIdentity, grandmasterClockQuality, stepsRemoved. From the portDS it is
possible to get information on the state of the port (portState).
How some of this information changes over time (e.g., changes in the grandmasterIdentity,
stepsRemoved) can be compared with changes in the PM data happening at the same time.
Additional datasets outside PTP are required to provide information on a non-PTP reference for the
clock, e.g., local GNSS (when this is not modelled via a virtual PTP port).
How synchronization information outside PTP is handled is for further study (e.g., type of references
being used as candidate synchronization reference, active reference, etc.).
SyncPHY dataset from [ITU-T G.781] Annex B, is also relevant as it provides information on the
characteristics of the physical layer reference and this can have an important role on the overall clock
performance (e.g., clock identity of the SyncE master from the parentDS.systemClockSourceID or
Quality level from the parentDS.systemClockSourceQL).

60 Rec. ITU-T G.8275 (01/2024)

 Appendix XII

Updated terminology for PTP clocks and PTP profiles

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

The terminology related to partial timing support (PTP) clocks and PTP profiles has been revised
based on [b-IEEE Std 1588g]. Some documents may still present the legacy terms. The following
table summarizes the application of [b-IEEE Std 1588g] to the terms used in the ITU-T related
Recommendations and that can be as a reference when legacy documents are used.

Table XII.1 − TimeTransmitter-related terms

Legacy terminology New terminology
master timeTransmitter
Master TimeTransmitter
MASTER TIME_TRANSMITTER
Abbreviation for master TT
Abbreviation for packet master pTT
BMCA BTCA

Table XII.2 − TimeReceiver-related terms

Legacy terminology New terminology
slave timeReceiver
Slave TimeReceiver
SLAVE TIME_RECEIVER
Abbreviation for slave TR
Abbreviation for packet slave pTR

Rec. ITU-T G.8275 (01/2024) 61

 Bibliography

[b-ITU-T G.781] Recommendation ITU-T G.781 (2024), Synchronization layer functions for
frequency synchronization based on the physical layer.
[b-ITU-T G.812] Recommendation ITU-T G.812 (2004), Timing requirements of slave clocks
suitable for use as node clocks in synchronization networks.
[b-ITU-T G.8272.1] Recommendation ITU-T G.8272.1 (2024), Timing characteristics of
enhanced primary reference time clocks.
[b-ITU-T G.8272.2] Recommendation ITU-T G.8272.2 (2024), Timing characteristics of
coherent network primary reference time clocks.
[b-ITU-T G.8273.2] Recommendation ITU-T G.8273.2/Y.1368.2 (2023), Timing characteristics
of telecom boundary clocks and telecom time synchronous clocks for use
with full timing support from the network.
[b-ITU-T G.8273.4] Recommendation ITU-T G.8273.4/Y.1368.4 (2020), Timing characteristics
of telecom boundary clocks and telecom time slave clocks for use with
partial timing support from the network.
[b-IEEE 802.3] IEEE 802.3-2022 – IEEE Standard for Ethernet.
<https://ieeexplore.ieee.org/document/9844436>
[b-IEEE Std 1588g] Amendment to IEEE Std 1588g-2022, IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control Systems
Amendment 2: Master-Slave Optional Alternative Terminology.
<https://standards.ieee.org/ieee/1588g/10478/>

62 Rec. ITU-T G.8275 (01/2024)

 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

Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation and
Series L
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

Global information infrastructure, Internet protocol aspects, next-generation networks, Internet of

Series Y
Things and smart cities

Series Z Languages and general software aspects for telecommunication systems

Published in Switzerland
Geneva, 2024