reference.tex

This a framework to test new ideas in transmission technology. Actual development is a LDPC-coder in

improve the received quality of the signal. The output of this module is the
filtered signal without the midamble. This module usually produces also
information used by other modules, such as \emph{SNR} or \emph{amplitude} of
the signal.

Now that the received signal is filtered, it is ready to be sliced.
\emph{Slicing} denotes the fact of taking a hard decision on the received
symbols. For a QPSK-signal, the quadrant of the symbol gives directly the two
bits. If the signal-alphabet is bigger, one has to calculate the distances
between the received symbol and all possible emitted symbols, and then taking
the smallest distance. A hard decision is usually the worst thing to do.
For example the LDPC-decoder takes the complex symbols directly from the
matched filter and achieves much better results.

After the slicing, we have again a block of bits, which run through the
\emph{Decoder}, where an algorithm tries to correct for transmission errors.
As noted before, decoding on bits is not ideal, but it is what happens in
most school-book examples...

The decoder ouputs again a block of bits that should contain no errors
anymore. This block can now be either used for the network-transmission,
reception of an image, or just to count the number of residual errors, in
order to evaluate a code/decoder-pair.

\section{Hardware}

 The hardwares job is to take the signal at it's sampling frequency,
something around 1-10MHz, and to mix it so that it falls in the
carrier-frequency, 1.9GHz, or 2.4-2.48GHz. In order to relieve the hardware
of some very difficult filtering, it is important that the signal sent to the
hardware does not occupy the whole sampling-frequency bandwith, but rather
just a portion of it.

 Furthermore it is important that, as the outgoing signal is filtered, as less
as possible intersymbol interference is produced. For this reason, we apply a
root-raised cosine filter, whose Fourier transform is the square root
of the commonly used raised-cosine spectrum. If a root-raised cosine filter is
used at both the transmitter and the receiver, the product of the  transfer 
functions will be a raised cosine that will give rise to an output having a
minimal inter-symbol interference at the receiver.

 The ICS- and STM-hardware differ mostly in two aspects:
\begin{itemize}
\item{Band} while the ICS-hardware wants to have the signal in baseband, the
STM-hardware needs the signal in passband
\item{Signal Unit} the ICS-hardware works with complex samples, while the
STM-hardware only works with real samples
\end{itemize}

\begin{figure}
\begin{center}
\begin{tabular}{cc}
\begin{minipage}{70mm}
\includegraphics[width=70mm, keepaspectratio]
{figures/hardware-base}
\caption{\label{fig:hardware-baseband}The signal preparation for ICS}
\end{minipage}
&
\begin{minipage}{70mm}
\includegraphics[width=70mm,keepaspectratio]
{figures/hardware-passband}
\caption{\label{fig:hardware-passband}The signal preparation for STM}
\end{minipage}
\end{tabular}
\end{center}
\end{figure}

The figures \ref{fig:hardware-baseband} and \ref{fig:hardware-passband}
depict the steps done to the signal from the fourier-transform point of
view. The range of the fourier-transform has been chosen to be
$-\frac{1}{2}..\frac{1}{2}$, but one could have $-\frac{f}{2}..\frac{f}{2}$
or $-\frac{\pi}{2}..\frac{\pi}{2}$ without changing the meaning at all.


\subsection{ICS-hardware}

In figure \ref{fig:hardware-baseband}, you can see the preperation necessary
for sending the signal to the ICS-hardware. The signal is first upsampled by
a factor of two. This is done by inserting a zero in between two complex
symbols.

Next we apply the lowpass RRC-filter and now we have a signal that occupies
half the bandwith, but at double the symbol rate. Thus, we didn't loose
information.

On the receiving side, exactly the contrary needs to be done: first we apply
the RRC-filter, then we downsample by a factor of two. The filtering is
necessary, as there might be some other signal next to ours. And, because the
reception sample-rate is twice the symbol-rate, we have to downsample by a
factor of two.


\subsection{Philips-hardware}

The latest hardware that is not yet installed has been developed by Philips. It
contains the A/D- and D/A-converters directly on the same board as the RF-part.
The connection to the PC is made via two SCSI-cables, and the PCI-card only
contains simple glue logic to put the data on the PCI-bus or to read it from
there.

This hardware works at 1.9GHz and has a bandwith of 5MHz.

\subsection{STM-hardware}

Looking at figure \ref{fig:hardware-passband}, you can see that for the
STM-hardware, we need to upsample by a factor of four. The filter chosen for
the pulse-shaping is a passband-filter, that has a bandwith of 1/4.
 
 Because the hardware accepts only real samples, we can't keep the signal at
baseband, as a loss of the signal would happen. You can see that by taking
the real-part of the signal, it gets mirrored at the axis. If you do this
with a baseband signal, information loss occurs.

 These three operations are done using advanced MMX-operations that manage to
take advantage of the special structures of the filters and the signal.



\chapter{Modules}

In this chapter you'll learn about some of the most important modules in the
software-radio. They represent the basic functionality and should be known by
everyone that wants to handle the software-radio.


\section{STFA}

STFA stands for Slot To Frame Allocator. Its main purpose is to map the RX- and
TX-slots to the correct moment in time. First of all you need to understand the
principles of a slotted TDD transmission using frames. In figure
\ref{fig:stfa_frames_slots} you can see a transmission of 3 frames. Each frame
takes the same amount of time. Normally the frame-structure stays the same
during the transmission. Of course this wouldn't be the case in a multi-user
environment, where a frame contains the structure of the up- and downlink
slots, which would change during connection and disconnection of users.

\begin{figure}[h]
\begin{center}
\includegraphics[width=70mm, keepaspectratio]
{figures/stfa_frames_slots}
\caption{\label{fig:stfa_frames_slots}The frames and slots}
\end{center}
\end{figure}

 The STFA represents this frame-structure. It is a module with $N$ inputs and
$N$ outputs, where $N$ is the number of slots per frame. The purpose of the
STFA is to calculate the slots so that they are sent at the correct moment in
time. To understand figure \ref{fig:stfa_in_out} correctly, it helps to imagine
yourself the STFA as a representation of the channel. So the inputs of the STFA
are the inputs to the channel, which corresponds to the TX-part. The outputs of
the STFA are what comes out of the channel, which is the RX-part.

\begin{figure}[h]
\begin{center}
\includegraphics[width=70mm, keepaspectratio]
{figures/stfa_in_out}
\caption{\label{fig:stfa_in_out}Inputs and outputs of the STFA}
\end{center}
\end{figure}

 Internally, the STFA has two large sample-buffers that hold one complete frame
in memory. One buffer is read continously \footnote{the transmission is
done in blocks using DMA} from by the D/A converter, while the other buffer is
written to continously \footnotemark[\value{footnote}] by the A/D converter. For this
reason, it is important that the result of one slot is computed before the D/A
converter needs it. It is also important that a RX-slot is processed before the
next frame.

\subsection{Synchronisation}

 A common problem in a slotted TDD-environment is the synchronisation of two
stations. If we consider two participants in a communication, called BS and MS
(for Base Station and Mobile Station), one has to define at what instant in
time the first frame starts. If we call this time-instant $t_{frame}(0)$, then
all consecutive frames will start at $t_{frame}(n) = t_{start} + n d_{frame}$
where $n$ is a positive integer and $d_{frame}$ is the time-duration of one
frame. This also defines all slots, as $t_{slot}(m) = t_{frame}(n) + m
d_{slot}$ with $d_{slot}$ the time-duration of one slot and $0<m<slots$.

 We can't know beforehand $t_{frame}(0)$, and also $d_{frame}$ is only known up
to a certain $\delta t$, because of clock-drifts between the two stations. One
solution is to send a synchronisation-signal in slot 0, so that one can know
$t_{slot}(0)$ for every frame. Then we can find $t_{slot}(m)$ for all
the other slots of the frame, supposing that the error in $d_{slot}$ is
negligible when calculating the time-instants of one slot.

\begin{figure}[h]
\begin{center}
\includegraphics[width=15cm, keepaspectratio]
{figures/stfa_typical}
\caption{\label{fig:stfa_typical}A typical set-up of the STFA}
\end{center}
\end{figure}

 This setup is shown in figure \ref{fig:stfa_typical}. In a real system, the MS
starts out with synchronisation modules attached to all its STFA-outputs. The
reason for this is that upon startup, we don't have any information about
$t_{slot}(0)$, so we have to expect the synchronisation-signal on any slot.
Once the synchronisation-signal is found on a given slot, the buffers are
adjusted so that the synchronisation-signal falls into slot$_0$. Then, each
time slot$_0$ is received, the buffer is adjusted again, so that all
$t_{slot}(m)$ are accurate and in synchronisation with the BS again.


\subsection{Important Parameters}

 There are three groups of parameters in the STFA:
\begin{itemize}
\item{Structural} which define the size of the different parts of the STFA
\item{Timing} everything that got to do with preparation of slots and
synchronization
\item{RF} the parameters of the RF-part are also reflected in the STFA
\end{itemize}

\subsubsection{Structural}
 These are quite important, as they define the basic structure and size of the
STFA. You can't change these parameters once the STFA has been started, as the
DMA-transfer would be disturbed greatly by this. An overview of the parameters
is given in figure \ref{fig:stfa_size_params}.

\begin{figure}[h]
   \centering
   \includegraphics[width=7cm, keepaspectratio]
   {figures/stfa_size_params}
   \caption{The different size-parameters}
   \label{fig:stfa_size_params}
\end{figure}

 The \emph{blocks\_per\_slot} parameter has a unit of 128 symbols. By taking the
default value of 20, this gives a slot-length of 2560 symbols. Substracting the
guard-period, we get a useable slot-length of 2470 symbols.
 
 To make things even more complicate, the total number of \emph{blocks} has to
be a multiple of 16. This is due to the fact that the DMA-transfer is done in
blocks with a size of 16 * 128 symbols \footnote{This is defined in
Base\/Antenna\/ICS/ics\_dev.h}. Taking a smaller block-size for the DMA-transfer
would result in more interrupts and thus a higher system-load.

 As we have a TDD-system, TX and RX slots are stacked up in time. Without any
special handling, the RF-system would have to be able to switch off the
transmit-chain from one symbol to another. Because this is very difficult to
do, a \emph{guard-period} has been inserted. During this time, the state of the
RF-cards is not defined, and no useful data is transmitted.

\subsubsection{Timing}

 Usually you don't have to change these parameters. They are taken into account
by the synchronisation-macro module. 

\subsection{Attaching Chains}

 The STFA on its own doesn't do anything. The mode of operation and the kind of
mapping done over the air is defined by attaching chains to it. If a chain is
attached to an input of the STFA, we talk about a transmit-chain, or TX-chain.
A receive-chain or RX-chain is attached to the output of the STFA.

\begin{figure}[h]
   \centering
   \includegraphics[width=7cm, keepaspectratio]
   {figures/stfa_tx_rx_example}
   \caption{Two transmit and one receive-chain as an example}
   \label{fig:stfa_tx_rx_example}
\end{figure}

 In figure \ref{fig:stfa_tx_rx_example} you see a picture of some
example-chain. In the middle is the STFA that is responsible to alert all
modules as soon as there is some data to proceed. Looking at the RX-chain, you
see that it is very simple for the STFA to know when to alert the RRC-module of
the chain. The right moment is when this slot has been received.

 For the TX1-chain, the right moment to alert the source-module is
$t_{alert}=t_{slot}(0)-d_{calc_chain_tx1}$. Unfortunatly the
$d_{calc_chain_tx1}$ is not known in advance and might change during the run of
the software-radio. One way to tackle this problem is to put an upper
time-limit on the calculation-duration, and call the top-module that much in
advance. In the actual STFA-implementation, $d_{calc_chain_tx_max}=2*d_{slot}$,
so that the first module of the TX1-chain is called at the beginning of slot 0.

 Another problem arises when we have constructs as in the TX2-chain
\footnote{The two branches may also fall into two different STFAs}. Although it
is not optimal\footnote{See \ref{future_stfa_chains}}, we applied the same
reasoning as with the TX1-chain, that is, we call the top module of the
TX2-chain two slots in advance. The disadvantage is, that the whole chain has
to finish in the time $2*d_{slot}$. 


\subsubsection{Overcoming the Time-Limits}

 In an ideal setup, you'll be able to calculate every slot in a frame fast
enough, so that it can be sent on time over the air. Unfortunatly, this is not
always the case. Sometimes you want to trade in some of the real-time with the
possibility to do some more calculations than the time allows. The problem is
different on the sending- and on the receiving side.

 The only time you'd want to send a slot that takes a very long time to
calculate is when you want to do repeated measurements on the slot. So what you
can do is to calculate the slot once, and then send it again and again. You can
do this by setting the notice-point not to the top-module, but rather to the
RRC-module only. Like this only the pulse-shape will be done, taking care of an
eventual desynchronisation between the two radios \footnote{Remember that the
MS moves in time}.

 On the receiver side, the only reason for taking more than the allocated time
is about the same. But you may easily take up more time than $2*d_{slot}$, if
the total amount of all receiving chains is not bigger than one frame. If this
might be the case, then you can use the following command:

\begin{quotation}
\begin{texttt}
make\_thread( rrc\_id );
\end{texttt}
\end{quotation}

 This means that every time the STFA has data that needs to be processed, it
checks whether the chain is still working, and only notifies the top-module, if
no work is done. If the chain is still working, the STFA doesn't send the
request, and waits for the next frame to check back again.

 Here at EPFL we use these two techniques to measure code-qualities, especially
LDPC-coding schemes. It is important to us that we get an actual transmission,
but analyzing 10 slots per second is good enough for our case.


\section{RRC}



\section{Midamble}



\chapter{TODO}


\section{Tests}


\section{Radios}


\chapter{Antenna}

\section{Driver}

\section{Channel-Server}