CEPT
ECC
Electronic Communications Committee
ECC PT1(13)091
ECC PT1
ECC PT1 #44
Ljubljana, 9-13 September 2013
Date issued:
2013 09 05
Source:
Orange
Subject:
Synchronization of TDD systems
Password protection required? (Y/N)
N
Summary:
This contribution intends to propose some additions and modifications to the Draft Report on
synchronization of TDD networks. Some of these modifications are already included in the Draft
report (enclosed in this contribution) while some others are included in this contribution for the
sake of clarity.
Proposal:
It is proposed that these modifications are introduced into the Draft Report.
Background:
PT1 is studying synchronization of TDD systems with the intention of producing a report that
would be applicable to all frequency bands.
Last version of the draft Report on TDD Network Synchronisation with the Orange proposed
new texts is attached:
WD on TDD network
synchronisation.docx
In addition it is proposed that the draft report is updated with the following remarks:
General remark on figures
Figures should be correctly referenced (some references are dead links).
When using figure from referenced document, the editor should ask the right to use the figure in order
to avoid possible copyright issues.
Page 12, §2.2.3, PTP description
- There are many errors or imprecision in the description of the PTP functions (TC, BC):
o
-
-
-
-
definitions should be provided and acronyms should be T-TC and T-BC when use for the
telecom domain
o T-BC or T-TC cannot handle the network delay asymmetry as it is said
o PTP embedded functions are not only limited to hardware timpestamping but there are
also software timing functions.
o hardware timestamping is not only use to “to quantify the transit delay inside each
equipments”. The transit delay is only relevant in use case of T-TC.
The statement “Because of this, work at ITU-T SG15/Q13 has been splitted in two
standards” is not correct. The reason why a second profile has appeared in discussion in ITU is
mainly economical and not technical.
In G.8275.1 description, the statement “equipments and chipsets have already been
available for several years” is not fully true. Not all manufacturers have implemented PTPv2
functions for phase/time in their equipments but rather a few ones only are available today. And
even if there are some implementations, as standards are not finalized, solutions have to be
considered as proprietary solutions.
The deployment scenario example has nothing to do in the G.8275.1 description. It should be
removed (or placed in section §4.1 but with a better description as it represents a too much very
particular use case and even with this small network approach it is not guarantee at all that the
performance will meet the requirement).
In G.8275.2 description, performance of this kind of solution should not be mentioned as
feasibility has not yet been demonstrated in ITU. This is the first step that has to be achieved.
Considerations about phase/time over technologies like DOCSIS, PON, MW … should be put in
another sections as they sometimes provides others solutions than PTP (sometimes proprietary).
The following text is proposed in order to describe the PTP protocol and its usage in the telecom
domain (it has to be considered as a first draft that can be enhanced):
Precision Time Protocol (PTP), also known as IEEE1588, is a standardized protocol defined by
the IEEE, coming initially from the automation world. The initial objective of this protocol is to
deliver time synchronization with a very high accuracy (sub-microsecond) in a LAN
environment. Therefore, IEEE 1588 is NOT a technology dedicated only to telecom.
Two versions of PTP have been released. Version 1 exists since quite a long time, and is really
targeting applications others than telecom. The version 2, approved by IEEE in 2008
(IEEE1588-2008), provides new features that can be useful to telecom applications. However,
there is a need to define in details the options and parameters of PTPv2 in order to enable this
protocol to be used in a telecom environment. This is part of the so-called "telecom profiles"
definition.
ITU-T Q13/SG15 has defined a PTP telecom profile for “end-to-end” frequency distribution in
the Recommendations G.8265 and G.8265.1, released in 2010. “End-to-end” means that the
nodes in the synchronization path (the path the PTP packets follow from the grandmaster to the
slave) do not embed PTPv2 functions.
Others PTP telecom profiles are currently under definition at the ITU-T Q13/SG15 to address
the phase and time distribution by the network in the Recommendations G.827x. These profiles
rely on the fact that all the nodes (full on path support) or only some nodes (partial support) in
the synchronization path embed PTPv2 functions. They are described here after.
According to IEEE1588-2008 standard:
"The PTP protocol is a distributed protocol that specifies how the real-time PTP clocks in
the system synchronize with each other. These clocks are organized into a master-slave
synchronization hierarchy with the clock at the top of the hierarchy - the grandmaster
clock - determining the reference time for the entire system. The synchronization is
achieved by exchanging PTP timing messages, with the slaves using the timing
information to adjust their clocks to the time of their master in the hierarchy."
2
The following figure illustrates the basic PTP dialog between master and slave when PTP is
used as a two-way protocol and Delay_request / Delay_response messages are used:
Figure 1: Principle for PTP algorithm [32]
Master and slave have their own internal reference clock, and the purpose is to align slave
internal clock on master reference clock. Thanks to the dialog depicted in the figure above, the
slave knows the four timestamps t1, t2, t3, and t4, and will use them to calculate the offset its
internal clock experiences compared to master reference clock, using the following formula:
Toffset = [ (t2 - t1) – (t4 - t3) ] / 2
This calculation assumes that the delays in both directions (delay from Master to Slave and
Delay from Slave to Master) are symmetric, and at worst that the asymmetry is fixed and known
(otherwise, it is not possible to determine and compensate the slave internal clock offset).
As we can see, PTP is therefore normally a two-way protocol, since messages are exchanged
between master and slave in both directions. However, it is possible to use PTP as a one-way
protocol, using only the "Sync" messages, in order to deliver only frequency. In this case, the
calculation differs from the previous formula, and is based in general on “adaptive clock
recovery” principles, which consists in recovering frequency synchronization via packets.
As described on figure 4 [Number to be updated in final document], the basic PTP dialog
consists for the master to send "Sync" messages containing timestamps to the slave. Note that
"Follow-up" messages are optional; when used, they are combined to the "Sync" messages in
order to deliver more accurate time stamps (this feature is especially used in case of software
implementation in the master, or in case the implementation is not fast enough to insert the
precise timestamp in the "Sync" message “on the fly”). These two approaches correspond to
the notions of "one step clock" when the precise timestamp is directly inserted in the "Sync"
messages, and "two-steps clock" when a "Follow-up" message is used to transmit the precise
timestamp.
When PTP is used with the two-way mode (for phase and time delivery), the slave initiates the
path delay calculation, e.g. by issuing "Delay_Request" messages to the master, which
answers by "Delay_Response" messages, in order to calculate and compensate the delay that
the packets spend through the network. In case of asymmetry in the links, the protocol is not
capable to determine and compensate it and there will be a time error in the calculation of the
slave internal clock offset. For instance over fibre links, it is generally agreed that a meter of
length difference between the two ways will generate roughly 2.5 ns of time error. Potentially
this error may accumulate over the links of the synchronization path.
In order to fight against Packet Delay Variation (PDV also called packet jitter) two mechanisms
are defined in the protocol, based on hardware and software PTPv2 functions embedded in
nodes:
3
 Telecom Bounday Clock (T-BC): it acts like a slave on the ingress port (connected to a
master) and as a master on the egress port (connected to slave(s)). This allows to
compensate the internal latencies and jitter of the node.
 Telecom Transparent Clock (T-TC): it measures the time of residence of the PTP
packet in the node by timestamping its arrival time on the ingress port and its departure
time on the egress port. The difference is inserted on the fly in the PTP packet in the
correction field.
It has to be reminded that those mechanisms, as part of the PTP protocol, will not help to fight
against links asymmetry
As mentioned previously ITU-T Q13/SG15 is currently defining two telecom profiles for phase
and time delivery:
 G.8275.1 is the phase/time profile assuming full on-path support i.e. assuming that all
equipments between the master clock and the slave clock support PTPv2 functions (T-BC
or T-TC). This profile is expected to be finalized in March 2014. A combination with
Synchronous Ethernet is possible in order to improve the performance and the time
holdover in case of PRTC failure.
 G.8275.2 is the phase/time profile assuming partial on-path support i.e. assuming that not
all equipments between the master clock and the slave clock support PTPv2 functions.
The discussion have only started on this profile and its feasibility has first to be
demonstrated before any work starts on this recommandation. Therefore at the time of
writing of this document, this solution should not be considered as an applicable solution
to deliver phase and time with the proper quality.
Page 12, §2.2.4, “Over-the-air synchronization for LTE HeNB by network listening”
From our point of view, this technique may be mature for frequency delivery from a macro to a
femtocell but this technique is not fully standardized and fully mature to address the phase/time
delivery especially in small cells context (not only femtocell). A priori work is on-going in 3GPP to
develop specifications for small cells. In consequence labs testing have to be considered with caution
and should not be considered as relevant of the feasibility or performance of one solution. Performance
and reachable accuracy have to be demonstrated.
It is likely that this solution may require specific design (hardware and software) not only on small cells,
but probably also on macro cells.
Page 22, §2.3.4, Commentary [A.D.62]
The Orange commentary is not relevant to this part of the document.
4