Skip to content

W
White Rabbit Standardization
Commit a54d4399 authored by Maciej Lipinski's avatar Maciej Lipinski
Browse files
Options

[ISPCS-HA] cleaned up the text from commented-out stuff (should have done it before...)

parent 29dd3cb1
Hide whitespace changes
Inline Side-by-side
Showing with 11 additions and 274 deletions
documents/ISPCS2015-HA/L1SynOp.tex
View file @ a54d4399
......@@ -47,15 +47,12 @@ formulation into standard language as a "Layer 1 Syntonization Option" (L1SynOp)
few months of HA SC work and a few iterations, this paper proposes an outline of L1SynOp.
\end{abstract}
% \date{\today}
\section{Introduction: High accuracy basic dependencies}
High accuracy is a link-based affair. It can be achieved if a number of dependencies,
described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
% \begin{itemize}
% \item \textbf{Asymmetry calibration}
\subsection{Asymmetry calibration} Knowledge of the \textit{asymmetry introduced on the link}
is required to precisely calculate the master-to-slave delay from
the round-trip measurement. Such asymmetry can introduce tens --~or hundreds~-- of
......@@ -85,8 +82,6 @@ described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
can be set in such a way that the asymmetry of any two connected ports
cancels out, through some kind of calibration process.
\end{enumerate}
% The asymmetry between Tx and Rx delays must be known.
\item \textbf{Medium asymmetry} is introduced by the difference of transmission
delays in the two directions in the medium alone. It must be
known and depends on the medium.
......@@ -121,25 +116,8 @@ described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
This can be the case if the two clock signals are indirectly syntonized or if they are
syntonized to independent Primary Reference Clocks (PRCs), such as caesium or rubidium.
Both cases will be presented later.
The \textit{precise round-trip measurement} requires some level of syntonization between the
PTP and L1 clock signals, which would allow a meaningful measurement of phase offsets between them.
% as well as the knowledge of phase offsets between these clocks signals.
% This means that translates into small and constant frequency offset (y, the derivative of phase
% offset), and some level of syntonization between L1clk and PTPclk.
% Two types of
% syntonization are distinguished in this article: direct and indirect. If the frequency
% offset is zero, syntnization is direct. If the frequency offset is non-zero but
% small enough for phase detection, the syntonization is called indirect.
%
% directly syntonized. If it's sufficiently small, it is said (in this article) to be indirectly syntonized.
% Direct or indirect syntonization is required for precise round-trip measurement
% (this is the assumption for this article).
% \end{itemize}
......@@ -150,8 +128,6 @@ described below and presented in Figure~\ref{fig:HAdependency}, are fulfilled.
\textit{Precise round-trip measurement} is tackled in the High Accuracy SC as
the \textit{Layer 1 Syntonization Optional Feature} (L1SynOp). Most
of its "workload" is on the implementation.
% which typically requires dedicated
% hardware support
However, it requires cooperation
of two connected PTP nodes\footnote{The term \textit{PTP node} is used to mean a network element
that acts as Boundary, Ordinary or Transparent Clock. A node can have several \textit{PTP ports}.} to ensure proper syntonization of their
......@@ -167,7 +143,6 @@ Figure~\ref{fig:refModel} depicts a single link between two PTP nodes. In each
node three clock signals are distinguished:
\begin{itemize}
\item \textit{PTP clock signal} ($clk_{PTP\_A}$, $clk_{PTP\_B}$) -- used for time-keeping
% of the \textit{PTP timescale}. Its edge marks the time of day. It might be either a physical signal
of the \textit{timescale} distributed by PTP. Its edge marks the time of day. It might be either a physical signal
or a "paper clock".
\item \textit{L1 Tx clock signal} ($clk_{L1\_Tx\_A}$, $clk_{L1\_Tx\_B}$) --
......@@ -194,43 +169,11 @@ is marked as $x_{Rx\_A}$ and $x_{Rx\_B}$ for \textit{Node A} and \textit{Node B}
\label{fig:refModel}
\end{figure}
%
% The measurement of precise part of the round trip requires knowledge of all the phase
% offsets between PTP and L1 clocks, i.e. $x_{Tx\_A}$, $x_{Rx\_A}$, $x_{Tx\_B}$, $x_{Rx\_B}$.
% Therefore, syntonization between this clock is required .
% Consequently, the phase offset
% between these clocks ($x_{Tx\_A}$, $x_{Rx\_A}$, $x_{Tx\_B}$, $x_{Rx\_B}$) is constant or
% slowly changing, thus measurable. The change rate of phase offset is quantified as
% frequency offset:
% \begin{equation}
% \label{eq:freqOffset}
% y(t)= \frac{d}{dt}x(t)
% \end{equation}
% The frequency offset can be derived from subsequent samples of phase offsets, thus it
% is a mathematically redundant information. However, it is used in the model out of the
% following reasons:
% \begin{itemize}
% \item distinguish between the case where phase difference is important and when it is
% not. If frequency offset is mentioned, it means that phase \& time is not considered
% \item simplification of description (e.g. it is easier to say that frequency offset between
% clock A and B should be 1ppm)
% \item it is commonly used and understood in Telecom
% \item phase offset can be a control information, whereas phase difference is retrospective
% information
% \end{itemize}
% In a generic case, provided the L1 and PTP clock signals are syntonized, the fine part of the
% round-trip can be calculated knowing all the phase offset values, i.e. $x_{Tx\_A}$, $x_{Tx\_B}$,
% $x_{Rx\_A}$, and $x_{Rx\_B}$. \color{gray}
The fine part of the round-trip can be calculated when the values of all the phase offsets,
i.e. $x_{Tx\_A}$, $x_{Tx\_B}$, $x_{Rx\_A}$, and $x_{Rx\_B}$, are known for the appropriate
instances (i.e the transmission and reception time of the relevant event messages). \color{gray}
% is:
% \begin{equation}
% \label{eq:phaseOffset}
% x= x_{Tx\_A} + x_{Rx\_A} + x_{Tx\_B} + x_{Rx\_B}
% % x= (x_{Tx\_A} - x_{Rx\_A}) + (x_{Tx\_B} - x_{Rx\_B})
% \end{equation}
Therefore, both nodes participating in the link must "know" their phase offsets.
The PTP Slave must be informed about the phase offsets of the PTP Master.
"Knowing" can take different forms. For example, if the \textit{L1 Rx clock signal} is used
......@@ -241,13 +184,7 @@ zero (i.e. $x_{Rx}=0$). Similarly, if the
(i.e. $x_{Tx}=0$). If not known by design, the phase offset must be measured
or derived in some other way.
% It is the PTP slave port to use the "knowledge" about all phase offsets, therefore the slave
% must be provided with the following information:
% \begin{itemize}
% \item whether PTP master port knows the value of its offsets
% \item what are the values of offsets (i.e. $x_{Tx}$ and $x_{Rx}$) -- these are possibly
% embedded into the timestamps
% \end{itemize}
The reference model relies on the following requirements:
\begin{itemize}
......@@ -282,13 +219,6 @@ As an example, the \textit{reference model} is applied to White Rabbit:
\section{High Accuracy in multi-domain PTP networks}
\label{HAinMultiDomain}
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.4\textwidth]{figs/MultiDomainSynt.eps}
% \caption{xxxxx.}
% \label{fig:MultiDomainSynt}
% \end{figure}
PTP networks can support many \textit{domains}. The time for a \textit{domain} is established
by a grandmaster. In other words, all the PTP nodes in the \textit{domain} are synchronized
to the time provided by the grandmaster, \textit{GM time}. The \textit{GM time} specifies
......@@ -324,34 +254,6 @@ PTP master to the PTP slave.\\
\color{gray}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5
% PTP networks can support independent \textit{timescales}, each in a separate \textit{domain}.
% The \textit{timescale} for a \textit{domain} is established by a grandmaster.
% Many \textit{timescales} can be independently propagated in separate domains over the
% same physical network of PTP nodes. In such case, PTP message
% communication and synchronization are performed for each \textit{domain} separately.
% Effectively, each PTP node participates in multiple domains and synchronizes to multiple
% timescales. Frequency offsets between such \textit{timescales} exist.
%
% The primary syntonization method in PTP networks uses timestamps to measure
% the \textit{Sync message} rate. This information is then used to control the frequency of
% the slave. The method
% is limited by the timestamping precision and the control loop frequency.
%
% SyncE achieves more precise syntonization by using the \textit{L1 clock signal} in the physical layer.
% However, a single SyncE network can be used to syntonize precisely only one
% PTP \textit{domain}. Many \textit{timescales} can only be transported over SyncE networks
% by using timestamp-based syntonization.
%
% It has been noticed that the knowledge of the phase offset between the PTP and the L1 clock
% signals in the HA nodes can be used to recreate precisely many \textit{timescales}.
% Effectively, a single physical \textit{L1 clock signal} can provide precise syntonization for
% \textit{PTP clock signals} in different domains.
% This can be decoupled from the direction of propagation of the L1 syntonization.
% The SyncE spanning tree in the network is irrelevant as long as the
% information required to recreate the \textit{PTP clock signal} is distributed from the
% PTP master to the PTP slave.\\
\section{(Non-) Congruency between L1 syntonization and PTP synchronization}
......@@ -386,14 +288,6 @@ The rate of change of the phase offset between the blue and red clock signals mu
enough for the offset to be measurable and useful. This is true if the references of
the red and the blue frequencies are caesium or rubidium standards.
%
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.5\textwidth]{figs/NonCongruency2.eps}
% \caption{xxxxx 2.}
% \label{fig:nonCongruency}
% \end{figure}
\section{Indirect L1 syntonization}
\begin{figure}[!t]
......@@ -403,10 +297,6 @@ the red and the blue frequencies are caesium or rubidium standards.
\label{fig:BackupLink}
\end{figure}
% The blue and red frequencies in the example from the previous section are required to be indirectly
% syntonized for the described mechanism to work. In particular, the change rate of the phase offset must
% be small enough for it to be measurable and useful. This is an example of indirectly
% syntonized frequencies originating from reference sources.
A redundant link is an example of indirect syntonization. Figure~\ref{fig:BackupLink}
shows a grandmaster node A connected to two nodes, B and C, which are synchronized and
......@@ -447,18 +337,11 @@ shall enable:
\item confirmation that both \textit{L1SynOp ports} know their phase offsets,
\item exchange of the phase offset values so that the \textit{L1SynOp port} in the PTP Slave
state can use them in its calculations.
% exchange of the phase offset values so that the \textit{L1SynOp port} in the PTP Slave state
% can correct its calculations.
\end{itemize}
The \textit{L1SynOp port} in the PTP Master state can embed its phase
offsets into timestamps by correcting their values. If phase offsets are embedded,
the $t_1$ shall be corrected with $x_{Tx}$ and $t_4$ with $x_{Rx}$.
% Optionally, the exchanged information shall include:
% \begin{itemize}
% \item relation between the different \textit{PTP timescales} based on the \textit{L1 clock signal},
% \item verification of the quality of the \textit{L1 clock signal}.
% \end{itemize}
\subsection{L1SynOp information exchange}
......@@ -489,10 +372,10 @@ interval accordingly.
A Boundary or Ordinary Clock (BC \& OC) sends
the Announce-L1InfoTLVs on its \textit{L1SynOp ports} which are in the PTP Master or
Uncalibrated state. It can be sent in other states if defined by the profile.
% new
A Transparent Clock (TC) sends Announce-L1InfoTLV on all its \textit{L1SynOp ports}
periodically.
%
A profile that uses L1SynOp defines the condition to activate the L1SynOp implementation-specific mechanisms
which enable precise round-trip measurement. This condition uses the information provided
......@@ -506,7 +389,6 @@ by the L1SynOp.
\begin{tabular}{| c | c | } \hline
\textbf{Name} & \textbf{Values} \\ \hline
& \\ \hline
% Sequence Number & \textit{Integer} \\ \hline
Type ID & Announce, Response \\ \hline
Response Request flag & True, False \\ \hline
Link-verified flag & True, False \\ \hline
......@@ -514,7 +396,6 @@ by the L1SynOp.
Congruent & True, False \\ \hline
Coupled & True, False \\ \hline
L1 status & Master, Slave, Not syntonized \\ \hline
% L1 locked & True, False \\ \hline
L1 configuration & Master, Slave, Both \\ \hline
Timestamps corrected & True, False \\ \hline
Parameter(s) & \textit{Integer}(s) \\ \hline
......@@ -530,28 +411,7 @@ by the L1SynOp.
Table~\ref{tab:L1InfoTLV} presents the information that is sent
in the L1InfoTLV. Each field is described below.\\
% \begin{table}[ph!]
% \subsubsection{Profile-specific information}
% The exchanged information can be divided into 3 groups:
% \begin{itemize}
% \item profile-specific configuration which shall be the uniform for all the nodes using
% L1SynOp within a single profile, i.e.
% \textit{Congruent}, \textit{Coupled}, \textit{Parameter Dynamic Flag}
% \item information reflecting operational state or configuration of the port, i.e.
% \textit{Link-verified flag},\textit{Phase offsets known flag},\textit{L1 status},
% \textit{L1 locked},\textit{L1 configuration},
% \item
% \end{itemize}
%
%
% This parameters can be seen as profile-specific configuration which shall be the uniform for
% all the nodes using L1SynOp within a single profile. This is because the parameters have
% effects which exceed single link, e.g. influence syntonization spanning tree or require
% proper hardware support.
% \subsubsection{Operational information}
\textbf{Type ID} ensures distinction between the Announce-L1InfoTLV
% that can be specified by the
% profile to be either suffixed to the PTP Announce or sent in a Signaling Messages,
and Response-L1InfoTLV. The former is specified by the profile to be either suffixed to the
PTP Announce or sent in the Signaling Message. The latter
is required to be sent on request in the Signaling Message to a link-limited address, regardless of
......@@ -587,38 +447,13 @@ occurs when PTP synchronization happens.
The status is obtained from a media-dependent mechanism (e.g. ITU-T-SyncE or WR-SyncE)
via a media-independent interface, detailed in section~\ref{mediaIndependentIF}.
The following \textit{L1 status} values are defined: \textit{L1 Slave}, \textit{L1 Master} and \textit{Not syntonized}.\\
% \begin{itemize}
% \item \textit{L1 Slave} -- the \textit{PTP clock signal} is syntonized to the \textit{L1~Rx~clock~signal}
% on the sending \textit{L1SynOp port}.
% \item \textit{L1 Master} -- the \textit{L1 Tx clock signal} on the sending \textit{L1SynOp port} is syntonized to the
% \textit{PTP clock signal}. The \textit{PTP clock signal} is locked to a source,
% such as \textit{L1 clock signal} on another port or an external source.
% \item \textit{Not syntonized} -- otherwise.
% \end{itemize}
% In the congruent mode, the \textit{L1 status} should reflect the setting provided by the L1SynOp according
% to BMCA. In the
% non-congruent mode, it informs about the settings decided by a PTP-independent
% mechanism/protocol, such as SyncE algorithm based on hand
% configuration and Ethernet Synchronization Message Channel (ESMC).
% \\
\textbf{L1 configuration} informs about whether the sending \textit{L1SynOp port}
can act as an L1 Master, or an L1 Slave, or both.
This information is foreseen for congruent mode when the PTP spanning tree controls
the L1 spanning tree and an L1-specific protocol is not used. This could be the case e.g. if ESMC is disabled.
% If the new revision of 1588 allows configuration of PTP ports to be slave-only or master-only,
% it will do the same work. However, such configuration in a
% boundary
% \textit{Master} means that
% the port is an active source of frequency. \textit{Slave} means that the PTP clock of
% the node should be locked to the L1 clock recovered on the sending port. Otherwise,
% \textit{non} is sent.
% \\
% \textbf{L1 locked} -- it informs whether the sending node is locked to a source of
% frequency, i.e. if the sending port is L1 Slave, \textit{L1 locked} is set to True if
% the PTP clock is locked to the L1 clocked recovered on the sending port; if the sending
% port is L1 Master, \textit{L1 locked} is set to True if another port of the node is in L1
% Slave state and locked.
\\
\textbf{Timestamps corrected} informs about whether the sending \textit{L1SynOp port}
embeds its phase offsets into timestamps by correcting their values.
\\
......@@ -626,8 +461,7 @@ embeds its phase offsets into timestamps by correcting their values.
\textit{L1 clock signal} used for transmitting data and the \textit{PTP clock signal}
in the domain in which the PTP messages are exchanged.
These parameters can enable an optional multi-domain syntonization.
% They are
% described in more details in section~\ref{parameters}.
\\
\textbf{Parameters Flag} informs that the \textit{Parameters} are provided by the
sending \textit{L1SynOp port}.
......@@ -662,7 +496,6 @@ dashed red lines. The generation of events is implementation-specific. An event
example, a transmission of the PTP message, such as a Sync Message or a Signaling Message. In
principle, an event can be virtual, especially if the \textit{PTP clock} is a "paper clock"
which is only calculated.
% If possible and applicable, an event might be defined in future to facilitate control aspects.
The frequency of events shall be such that the difference between the consecutive (measured)
phase offsets is much smaller than the period of the \textit{PTP clock signal}, i.e.
$x_{n+1}-x_n < T_0$.
......@@ -671,7 +504,6 @@ $x_{n+1}-x_n < T_0$.
The following values are proposed to be sent in the L1InfoTLV as \textit{Parameters}:
\begin{itemize}
\item \textbf{timestamp ($t_n$)} of each event, captured using the \textit{PTP~clock},
% \item \textbf{interval} between consecutive events, captured using the \textit{L1~clock~signal}:~$T_n$,
\item \textbf{phase offset ($x_n$)} at the event occurrence, between the rising edge of the
\textit{PTP clock signals} and the following rising edge of the \textit{L1 clock
signal}, measured using the \textit{PTP~clock signal} definition of the
......@@ -742,30 +574,18 @@ should never be used and new frequency classes should be added in the reserved s
(values greater than 0x0000). The \textit{No L1} class represents a node with a free-running
oscillator. In between \textit{Ideal} and \textit{No L1}, different \textit{L1 clock signal}
characteristics are mapped into \textit{Frequency Class} values.
% This includes mapping of the
% ITU-T clocks, PTP-base syntonization and characteristics required to achieve sub-ns synchronization
% (WR).
% Likewise,
% if a profile specifies WR SyncE to be used by the L1SynOp as the syntonization mechanism, the
% the \textit{Frequency Class} represents WR characteristics which need to be specified somewhere.
\begin{table}[!t]
\centering
\begin{tabular}{| c | c | c | } \hline
\textbf{Value} & \textbf{Name} & \textbf{Specification} \\ \hline
% & & \\ \hline
0x0000 & Ideal & \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0x0010 & WR & IEEE1588-201x Appendix \\ \hline
% \textcolor{gray}{Reserved}& & \\ \hline
% 0x0100--0x0200 & Enhanced SyncE & ITU-T Recommendations \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0x0100--0x0200 & SyncE & ITU-T Recommendations \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
0xF000 & PTP & No specification \\ \hline
\textcolor{gray}{Reserved}& & \\ \hline
% 0xFF00 & Unknown & No specification \\ \hline
% \textcolor{gray}{Reserved}& & \\ \hline
0xFFFF & No L1 & \\ \hline
\end{tabular}
\caption{Frequency Classes -- initial proposal, to be finished.}
......@@ -795,17 +615,10 @@ The \textit{L1InfoTLV} carries a dynamic list of 2-tuples which trails the path
source. Each 2-tuple contains two values: \textit{Frequency Class}, and \textit{Counter}
of the \textit{L1SynOp nodes} of that \textit{Frequency Class} in the path from the source
of frequency.
% \begin{itemize}
% \item \textit{Frequency Class},
% \item Counter of the \textit{L1SynOp nodes} of that \textit{Frequency Class} in the path from
% the source of frequency.
% \end{itemize}
% The list is dynamic and contains only the \textit{Frequency Classes} of the nodes that are
% in the path.
An \textit{L1SynOp node} is required to update the \textit{Frequency Class} list by either (1)
incrementing the counter in an existing 2-tuple, or (2) adding a new tuple with its
\textit{Frequency Class}.
% The list trails the syntonization spanning tree.
A profile that uses \textit{L1SynOp} defines how the information is used. For example, a WR
Profile would not use the path that contains non-WR nodes. A different profile could define
an algorithm that uses the \textit{Frequency Class} list to compare different paths; then, the
......@@ -856,8 +669,6 @@ with the Response-L1InfoTLV. Such an exchange is possible since Signaling Messag
by PTP on ports in the Passive state.
The mutual exchange of information on the "passive link" enables to verify the link and
the applicability of the \textit{reference model}; the L1SynOp information can be kept up to date.
% There profile can specify that the PTP Passive port sends periodically
% Announce-L1InfoTLVs to update the adjacent node on its state.
\section{A White Rabbit profile using L1SynOp}
......@@ -903,17 +714,9 @@ The White Rabbit HA profile that uses L1SynOp can be defined as follows (see Fig
If the conditions above are not fulfilled, PTP synchronization is performed without activating L1SynOp-related mechanisms.
\end{itemize}
% ADD
% - disabled SSM, use config
\section{A Telecom profile to use L1SynOp}
% \begin{figure}[!t]
% \centering
% \includegraphics[width=0.3\textwidth]{figs/MessageExchangeWR.eps}
% \caption{xxxxx 2.}
% \label{fig:nonCongruency}
% \end{figure}
A Telecom PTP \textit{time and phase profile} that uses L1SynOp can be defined as follows:
\begin{itemize}
......@@ -939,12 +742,6 @@ A Telecom PTP \textit{time and phase profile} that uses L1SynOp can be defined a
activating L1SynOp-related mechanisms. If they are fulfilled, L1SynOp is activated
immediately.
\end{itemize}
% \section{Conclusions}
% \label{conclusions}
% This paper presents a proposal which is not an official HA SC proposal. It is an
% alternative to previously presented proposals which attempts to abstract and decouple
% protocol mechanisms from the hardware implementation and simplify things.
\color{black}
\section{Potential applications of the information exchanged in the L1SynOp TLV}
......@@ -1001,22 +798,6 @@ network arrangements. The \textit{Option to explicitly configure port state}
\cite{ExPortConfig}, if specified, might be considered instead of the
\textit{L1 configuration}.
% - L1 config - only for congruent, only because we have no mean to control L1, so we need
% to do it from ptp
% - Phase known - more for non-congruent cases, where we have no control over L1 but need to
% somehow adjust to the situation
% This is used in WR to enable interoperability between \textit{L1SynOp nodes} and PTP
% nodes implementing default (or other) profile. For example, a \textit{L1SynOp node} can
% switch to the default PTP profile if connected to the PTP node not supporting \textit{L1SynOp}.
% While the IEEE1588-2008 does not provide proper\footnote{It is possible to
% use management messages to query PTP device about the profile, but this feature is not
% obligatory and therefore unreliable.} means of recognizing profiles, the current revision
% will likely introduce \textit{Profile ID TLV} to do the job. In such a case, the
% L1InfoTLV can be still useful to add some flexibility, however profile recognition will fall
% onto the Profile ID TLV. For example, it can enable to define
% profiles that optionally use L1SynOp. It can also enable using the L1SynOp without
% implementing any profile.
\subsection{Media-specific link verification}
......@@ -1048,20 +829,6 @@ the L1 spanning tree configuration. The \textit{Phase offsets known} flag indica
whether phase offset values are available to a \textit{L1SynOp port} in a given
L1 and PTP states, configuration and with the provided hardware support.
% The hardware support required for an \textit{L1SynOp node} to act as a slave or a master
% differs. For example, if properly configured, an ITU-T SyncE switch with upgraded PTP stack
% can suffice to act as an \textit{L1SynOp slave node}. This is possible if the L1 clock signal
% is configured to be directly looped back at the slave, and the phase measurement is done
% on the \textit{L1SynOp master node}, provided a proper hardware support.
% On the other hand, the same ITU-T SyncE switch cannot become a \textit{L1SynOp master node},
% since it provides no hardware to measure phase.
%
% While the \textit{L1 Config} flag is used
% to influence the spanning tree and prevent an \textit{L1SynOp port} from entering that
% it has no mean to support, the \textit{Phase offsets known flag} informs the other
% \textit{L1SynOp port} whether the already entered state is provides enough information
% (i.e. phase offset knowledge) to satisfy the reference model and perform \textit{L1SynOp}
% enhancements.
\subsection{L1SynOp configuration and interoperability between profiles using L1SynOp}
......@@ -1080,33 +847,6 @@ allows to define profiles which enable:
\item potential interoperability between different profiles using \textit{L1SynOp}.
\end{itemize}
% \begin{itemize}
% \item defining values of this flags in the profile,
% \item defining values of this flags as configuration by operators,
% \item defining profiles which interoperate with other profile where the values can vary.
% \end{itemize}
%
% The \textit{L1 status} provides a \textit{L1SynOp node} with the information about the
% status of L1 syntonization, its own and that of the \textit{L1SynOp node} connected to it.
% This information have a number of applications (Used in WR profile):
% \begin{itemize}
% \item An \textit{L1SynOp node} that is required to be "coupled", knows when it can start
% locking to the L1 Master.
% \item An \textit{L1SynOp node} that is required to be "congruent", knows whether the
% L1 configuration is applied
% \end{itemize}
%
% The \textit{L1 configuration} parameter enables to define a port to be Master-- or Slave--only.
% It can be used in the following use cases:
% \begin{itemize}
% \item Reflect limitation of the hardware. For example, implementation of L1 Slave
% requires much more effort and might be provided only on chosen ports. This ports
% are then configured to be Master-only.
% \item Hand-configuration of topology to avoid automatic reconfiguration
% \end{itemize}
\subsection{Media-flexibility}
\label{MediaFlexibility}
......@@ -1158,6 +898,3 @@ timestamping node, as described in Section~\ref{MediaFlexibility}.
\end{document}
% LocalWords: PPSi picoseconds SyncE CERN WRPTP Kconfig struct TimeInternal
% LocalWords: tstamp recv send init
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment