architecture.tex

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

\chapter{Antenna}
\index{Antenna!Architecture|(}

The antenna-part of the software-radio has the structure as shown in fig.
@Antenna-blowup: Common/Driver/HW/Server@ Their respective functions are as
follows:

\begin{itemize}
\item{Common} is the interface towards the signal processing part
\item{Driver} implements a certain hardware or simulation
\item{Hardware or Simulation} the actual transmission system
\end{itemize}

\section{Common}
\index{Antenna!Common}
The interface of the antenna offers the following parameters to the
signal-processing part:

\begin{itemize}
\item{DMA-region} a place where the received samples are written to and the
samples to be sent are read from
\item{RF-parameters} frequency, amplitude and other config-parameters
\item{Timing} an function is available that tells about the actual timing of
the RX/TX part
\end{itemize}


\section{Driver}
\index{Antenna!Driver}
This is the implementation of a certain way to transmit and receive samples.
It has to take care about all initialisations and correct handling of all
exceptions. The following drivers are functional:

\begin{itemize}
\item{RF} interfaces the old, STMicroelectronics based RF-system
\item{ICS} interfaces the new, ICS-based RF-system that is capable of
MIMO-transmission
\item{Simul} for simulations of the RF-system
\item{Simul\_ics} for simulations of the ICS-system
\item{Emul} does a simple copy of the data to be transmitted to the next slot
\item{NOP} does nothing, for debugging purposes
\end{itemize}


\section{\label{sec:HWorSimul}Hardware or Simulation}

The final part of the software-radio defines the channel. The \emph{Emul}
driver, for example, implements a flat single-tap channel with no noise. The
\emph{Simul} drivers need a channel-server that takes multiple radios
together, mixes their signal, and sends back the calculated signal.

The most interesting parts are the RF and ICS hardware, because they offer a
real channel to test the transmission with.

\subsection{Hardware}
\index{Antenna!Hardware}
In the following table you can find a comparison of the two hardware-systems
available.

\begin{center}
\begin{tabular}{|l|l|l|}
\hline  & RF & ICS \\ 
\hline Max. number of antennas & 1 & 4 \\ 
\hline Frequency [GHz] & 1.9 & 2.4-2.48 \\ 
\hline Bandwith [MHz] & 3.8 & 1 \\ 
\hline Resolution & 12 & 14 \\ 
% \hline  &  &  \\ 
\hline 
\end{tabular} 
\end{center}

\subsection{Simulation}
\index{Antenna!Simulation}
In simulation-mode, a channel-server accepts connections from different
radios, as can be seen in fig. @channel-server with two radios@. The
channel-server can simulate multi-tap channels and add gaussian noise to the
transmitted signals. This allows for easy simulation of real-world signals,
before taking the modules on the air.

\index{Antenna!Architecture|)}

\chapter{Operating System}
\index{Operation System}
One very important aspect of a software-radio is it's real-time
capability. In our implementation, we transmit and receive slots of a
duration of about 1ms. If we want to make sure that there is no blank in
the transmission, we need to make sure to do our calculations
in this short time-span and to do it at the right moment.

 In a modern operation system, lots of things are happening at the same
time: graphics, sound, network, disk-access and more. A normal program
will have to wait for these tasks to finish, before it can do it's
work. This means that it's nearly impossible for a normal program to
meet sub-ms precision. Different approaches exist to bring a solution
to this problem. We chose RTLinux because of it's stability,
availability and because it is licensed under the GPL which means that
other people can use this solution without having to pay high
software-costs.

 In short, RTLinux allows to meet time-constraints of a couple of $\mu
s$, the precision-constraint that is given by todays hardware. It does
this by running a real-time aware micro-kernel which is principally
responsible for scheduling. One of the default tasks that runs with the
lowest priority is the linux-kernel. This makes sure that even if the
kernel is busy doing one of the not-so important things, RTLinux may
put it to sleep, execute the real-time task, and resume the
linux-kernel.


\chapter{Modes of Operation}
\index{Modes of Operation|(}
As the signal-processing part and the framework is very flexible, different
operating-modes are possible:

\begin{itemize}
\item{Test} which includes just a simple chain that is run a limited number
of times
\item{Simulation or Real-Time} modes which are possible for both Local-Loop
and the Two-Radio System
\item{Local-Loop} where a radio 'talks' to itself by receiving every sample
sent
\item{Two-Radio System} a set of two radio, where each one talks to the other
\end{itemize}

In the following sections, the advantages of each of these are listed.

\section{Test}
\index{Modes of Operation!Test}
 As the name indicates, this is used to test the basic functionality of a
module. Usually it includes a simple chain that has only the most basic
components in it in order to test the module. Like this one can test the
module in a simple environment, before going through the more real and more
complete test in a real-time communication.

 To test a mapper-module that maps bits into complex symbols, it would be
enough to have the chain as depicted in fig. @show modules:
source->mapper->block->slicer->sink@ For convenience, the \emph{source} can
contain readable text-messages that are printed by the \emph{sink} and can be
verified by hand.

 The \emph{block} module exists in different variants, where MIMO channels
and multi-tap fading channels can be simulated, both in a convenient,
deterministic manner.


\section{Simulation or Real-Time}
\index{Modes of Operation!Simulation or Real-Time}
As already described in section \ref{sec:HWorSimul}, the software-radio can
be run either locally without the RF-hardware and in a user-space mode, or it
can be run in real-time using special RF-hardware for transmission and
reception. While the former is much more easy to debug, only the latter
allows to make real-world measurements and confirmation of theoretical
results.

In the software-radio, both modes are transparent to the user, as the
decision between the simulation or the real-time mode only has to be taken
when running it. For the user, in either case, the channel is represented by
the STFA.


\section{Local-Loop}
\index{Modes of Operation!Local-Loop}
Sometimes it is too complicated to take care about all the synchronisation
and fading-problems. Then you can chose to run your modules to test in a
local-loop, and thus always be synchronised.
 
 When running in simulation-mode, the channel-server makes sure that the sent
samples are received at the same time. If you run the radio in real-time
mode, then you have to make sure to connect the output of the cards with the
input through a cable.


\section{Two-Radio System}
\index{Modes of Operation!Two-Radio System}
\index{Two-Radio System}
TODO: update for ICS-example

This section describes a basic system with two radios, following the example
of the radio found in \emph{Radios/Simple/BS} and \emph{Radios/Simple/MS}. It
is important to know about this if you want to do more than just run
the examples. You will learn about the most important modules, how
to put them together and what make the thing going.


\subsection{Setup}
\index{Two-Radio System!Setup}
%
\begin{figure}
\begin{center}\includegraphics[width=10cm,keepaspectratio]
{figures/simple_setup}\end{center}


\caption{\label{cap:The-most-simple}The most simple two-way communication
example}
\end{figure}


Looking at fig. \ref{cap:The-most-simple}, you can see two parts:
a master and a client%
\footnote{Historically, the master is called BS (for BaseStation) and the client
is called MS (for MobileStation). %
}. The communication channel in this example consists of three slots,
of which only two are occupied%
\footnote{There are three slots in order to allow for a more relaxed timing.%
}. The part in the middle, where the tree slots reside, is called STFA,
which means Slot To Frame Allocation. This is the most basic module
that you will find in mostly all of the software-radio. The input of the STFA
are sent through the antenna, while the received signal from the antenna
is passed through the output of the STFA. As you can see in \ref{sub:Overview},
the antenna is a placeholder for either a real channel or just a simulation.


\subsection{Modules}
\index{Two-Radio System!Modules}
This is a short overview of the different modules:

\begin{lyxlist}{00.00.0000}
\item [sch\_send]Synchronisation CHannel. This module generates data that
is used to communicate the configuration of the other clients. This
includes the configuration about which slot to use for sending, which
slot to use for receiving, and gain-control. Most of it is not used
in a two-radio case. 
\item [modulator]Takes bits as inputs and creates complex symbols. In its
default-configuration, it outputs QPSK symbols. 
\item [spread]Spreads the input-symbols with a given sequence. Usually
this is used to have more than one radio sending during the same slot,
in this example it is used to give some protection to the data, as
a spreader may act as a simple coder. 
\item [midamble]Inserts a training-sequence into the signal. This sequence
is known at the receiver-end, which uses it then to estimate the channel
and to create the matched-filter. 
\item [synch\_send]Adds a synchronisation-sequence to the signal. The sequence
is done in a special way so as to make it possible to retrieve the
synchronisation-signal with as less calculation as possible. 
\item [rrc]The Root Raised Cosine pulse-shape filter. Takes the complex
signal, upsamples by a factor of two and generates a real output. 
\item [stfa]Slot To Frame Allocation, takes the slots and prepares them
to be sent over the channel. 
\item [matched\_filter]The counterpart to \emph{midamble}, calculates the
channel-estimation and the matched-filter, and applies it to the input-signal. 
\item [demodulator]Makes a hard decision on the received signals. 
\item [sink]Prints to the screen the received sequence of bits. 
\item [synch\_rcv]Keeps up the synchronisation with the master. 
\item [despread]Undos the operation introduced by the spreader, and offers
a cleaner signal. As coding module this is suboptimal. 
\item [sch\_rcv]Decodes the synchronisation-channel and sets the tx-amplitude
according to it's information. 
\end{lyxlist}

\subsection{Master}
\index{Two-Radio System!Master}
The masters task is to send out the synchronisation-signal on it's
slot 1, combined with the data-signal that tells an eventual client
its required tx-gain. The tx-gain of the client is calculated with
the power received on slot 2. If it is below a certain threshold,
the master considers that no client is sending, and puts the tx-power
to 0. If the receiving-power is above a certain threshold, the tx-gain
is adjusted to what the master would like to hear. This task in fact
is done automatically by the sch\_send module.


\subsection{Client}
\index{Two-Radio System!Client}
While the master is quite static, the client has to do lots more:

\begin{enumerate}
\item Search for the synchronisation-signal 
\item Set up the synch-slot and uplink-slot 
\item Keep the synchronisation 
\end{enumerate}
The first point is necessary because the client doesn't know beforehand
the time-frame of the master. So, in order to get it, the mobile sets
up a \emph{synch\_rcv} module on each slot, and choses the one that
has the highest probability of a successful synchronisation. After
this, it updates the offset of the STFA, so that it is in synch with
the master, and keeps one \emph{synch\_rcv} module active, to allow
for further synchronisation. All this is done in a macro-module called
\emph{macro\_synch}.

Once the primary synchronisation is achieved, it will set up some
modules to decode and demodulate the synchronisation-channel, as well
as set up a tx-channel on slot 2.

After this it has to keep up the synchronisation, because the master
and the client don't have exactly synchronised clocks.
\index{Modes of Operation|)}

\chapter{Hardware}
\index{Hardware!Architecture}
The current hardware is composed of three parts, as can be seen in fig.
@figure of layout with ICS-rx and tx, as well as RF-cards@ This setup is
optimized towards a 4x4 MIMO-system at 2.4GHz.


\chapter{Code}
\index{Code!Architecture}
Once you untar the SRadio-*.tar.gz file, you find a directory in the form of
\emph{SRadio-1.0.0}\footnote{the name has to start with SRadio, or else
the Makefiles won't work!} under which all the code is placed.

\section{\label{sub:Directory-structure}Directory Structure}

\begin{lyxlist}{00.00.0000}
\item [Base]CDB, SDB and the channel implementations are found here, as
well as some general helping functions to the MSR. 
\item [Conventions]template files that can be copied to new projects and
then be filled in 
\item [Modules]all user-written modules are found in here, put into different
categories: Coding, Channel, Data, General, Macro, Signal 
\item [Test]simple chains that are used to test the basic functionalities
of the modules 
\item [Radios]full-fledged two way transmission parts 
\item [User]place for all compiled user-libraries 
\item [Kernel]place for all compiled kernel-libraries 
\item [Documentation]where you find this manual as well as some presentations 
\end{lyxlist}