path: root/sfn.tex
diff options
authorMatthias P. Braendli <matthias.braendli@mpb.li>2015-07-30 22:05:01 +0200
committerMatthias P. Braendli <matthias.braendli@mpb.li>2015-07-30 22:08:32 +0200
commitd3e242095e79a1930141b3f3a1394d0e4993dcf3 (patch)
tree81dab03e2d7d73b05a496bfa591600b64d9b974c /sfn.tex
parentbc47e885abeda7203d1ddbc4f53f3db945730f60 (diff)
Fix minor mistakes, start SFN chapter
Diffstat (limited to 'sfn.tex')
1 files changed, 149 insertions, 0 deletions
diff --git a/sfn.tex b/sfn.tex
new file mode 100644
index 0000000..febdc1f
--- /dev/null
+++ b/sfn.tex
@@ -0,0 +1,149 @@
+\section{Single-Frequency Networks}
+The DAB standard has been designed to enable the creation of transmission
+networks where several transmitters share the same frequency, and send the same
+signal synchronously. Such networks are called ``Single-Frequency Networks''.
+Each transmitter needs to be fed the same multiplex stream, which must include
+timing information required for synchronisation. This timing information implies
+that a time reference must be installed at each transmitter.
+The requirements for a SFN can therefore be summarised in three points:
+ \item The signal must be \emph{identical} for each transmitter. This
+ requires a common multiplexers, and a distribution network that carries
+ the ETI to all modulators.
+ \item All transmitters must transmit on the \emph{same frequency}. The modulators
+ require a frequency reference.
+ \item The signal must be transmitted at the \emph{same time}, which requires
+ a time reference at each site. It also implies that the ETI stream must
+ contain timestamps.
+The figure~\ref{fig:txchain-sfn} shows a SFN setup with two transmitters.
+ \includegraphics[width=\textwidth]{figures/txchain-sfn.pdf}
+ \caption{This outline for a SFN shows two transmission sites.}
+ \label{fig:txchain-sfn}
+\sidenote{Explain requirements on system time, NTP}
+\subsection{Multiplexer Configuration}
+On the ODR-DabMux configuration, there are not many options that are specific to
+an SFN setup.
+Most importantly, the timestamp feature must be enabled using the ``tist'' option in
+the ``general'' section.
+Furthermore, it is recommended to use the ZeroMQ transport between the
+multiplexer and the modulators, which can be enabled in the ``outputs'' section.
+Care has to be taken to have an output that slows ODR-DabMux down to nominal
+rate. The ZeroMQ output alone does not enforce this. The following listing shows
+the relevant options we just covered.
+general {
+ tist true
+ ...
+outputs {
+ ; Accept connections on all interfaces, on port 9100
+ zmq "zmq+tcp://*:9100"
+ ; This throttles muxing down to nominal rate
+ throttle "simul://"
+\subsection{Modulator Configuration}
+Since the modulator has to ensure that the three SFN requirements are satisfied,
+its configuration is more complex.
+We will assume, in this explanation, that one of the following USRP devices is
+used: USRP2, USRP B100, USRP B200. Other devices also support the necessary time
+and frequency synchronisation, but they have not been well tested. These USRP
+devices can accept different sources for the reference clock:
+ \item The default ``internal'' source uses the non-disciplined
+ clock generator inside the USRP. It is not suitable for SFN.
+ \item The ``external'' source corresponds to the SMA connector on
+ the USRP. A 10MHz signal from an external source must be connected to
+ it.
+ \item The optional GPSDO that can be mounted inside the USRP, and is
+ selected as source with the ``gpsdo'' setting.
+For the time reference, the ``pps\_source'' option is used. Possible values are
+``none'', ``external'' and ``gpsdo'', with analogous meaning as for the
+reference clock.
+In case the USRP is connected to external references, the relevant configuration
+would be as follows:
+These settings alone do not tell the modulator to enable synchronisation of the
+transmission, they only select how the USRP is configured. To enable timestamp
+decoding and the frame synchronisation logic in ODR-DabMod, the following
+settings must also be set:
+; The constant offset to be added to the TIST, in seconds
+The ``offset'' setting deserves some further explanations. The ETI data stream
+contains TIST information, from which a time-stamp for each ETI frame can be
+derived. Each ETI frame ($24$\ms interval) is therefore associated with a
+precise point in time that defines the time of transmission of the corresponding
+transmission frame.\footnote{It is slightly more complex, because one
+ transmission frame is composed of several ETI frames in some
+ transmission modes, but the principle stays the same. It suffices for this
+ explanation that we can derive the transmission time from the TIST
+information.} The TIST information is set to current time at ETI frame
+generation, and does not take in account the propagation delay across the
+distribution network. Therefore, we need to add an offset, called $\delta$, to
+the TIST to define transmission time.
+t_{transmission} = t_{TIST} + \delta
+If this offset is set to a higher value, there will be a bigger delay (measured
+in absolute time) between the point in time a frame is multiplexed and the point
+in time the frame is transmitted. More frames therefore will be buffered in
+the ODR-DabMod ZeroMQ input, increasing robustness against network latency
+The offset already has two functions: it compensates for network delay and
+allows a trade-off between delay and robustness. But it also serves a third
+purpose: When doing coverage planning for an SFN, it is necessary to be able to
+control the relative delay between transmitters in the order of milliseconds.
+This tuning of relative delay is included in the ``offset'' setting. We can
+therefore rewrite the above equation as:
+ t_{transmission} = t_{TIST} + \delta_{network} + \delta_{planning}
+ \delta = \delta_{network} + \delta_{planning}
+\sidenote{Explain relationship with ZeroMQ max buffer size}
+\subsection{Using Ettus GPSDO}
+\subsection{Using ODR LEA-M8F GPSDO board}
+\sidenote{Give example}
+% vim: spl=en spell tw=80 et