introduction.tex

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

\part{Introduction}

\chapter{How to read this document}

Before going into details about what is a software-radio, and what it
can be used for, I will give an overview of this document, so that you
know where to start first.

This document is separated into six parts:
\begin{itemize}
\item {Introduction} - this is what you're reading right now. It gives
some basic definitions and ideas about the signal-processing part as
well as the chosen implementation.
\item {Architecture} - here you'll learn more about the design of
the different aspects of the software-radio
\item {Reference Manual} - when you need to know about a certain function
how to use it or what it does, this is the place to go. Usually you'll
need the knowledge from the \emph{Technical Documents} to know
everything.
\item {How-to} - a more practical approach, this could also be called
\emph{tutorial}, as you learn how to use the software-radio
step-by-step, without an explanation for the gory details.
\item {Tipsntricks} - a collection of common pitfalls and how to avoid
them, plus some help on how to do more unusual things.
\item {Future Thoughts} - lots of things I wanted to do with the
software-radio, both technically and experimentally, but that I didn't
have any time left. Wanna go for it?
\end{itemize}

At the beginning of each part, you will find a short overview of the
different chapters and what they talk about.

\section{Overview of this part}
\begin{itemize}
\item Motivation - why we want to have a software-radio
\item System Overview - the basic building blocks of the software-radio
\item Usage - what we are doing with it right now
\item Outlook - possible future enhancements
\end{itemize} 

\chapter{Motivation}

This introduction describes our motivation for building a transceiver
based on software-radio, hereafter called \emph{software-radio testbed,}
and gives an overview of the general philosophy.

\section{Why Software-Radio?}

\index{Software-radio!Definition}
\begin{quote}
We talk about Software Radio when the map between the data (sending
and receiving) and the data-carrying antenna signal are completely
(within hardware limits) specified by the software. Any map that conforms
with the hardware limitations (power, bandwith, hardware imperfections)
may be implemented by means of an appropriate code. (B.Rimoldi, 2003)
\end{quote}
If you like the idea of a flexible transceiver and are not too concerned
with size and energy consumption, then you want your transceiver to
be software-radio based. For instance, let us say that you have a
software radio mobile phone. This mobile phone is a general purpose
communication device with a piece of software that makes it behave
like a mobile phone. You can turn your mobile phone into a GPS receiver,
or a TV receiver, or a Wi-Fi interface, just by down-loading a piece
of software (assuming there is a server that has the software you
need).

For the technically oriented person: in a software-based transmitter,
the software creates the samples corresponding to the signal to be
transmitted. A general purpose hardware converts these samples into
the signal that will be sent to the antenna. Similarly, in a software-based
receiver, the general purpose hardware takes the signal captured by
the antenna and produces the corresponding samples. The software does
the rest. The hardware is not aware of the standard you are using:
it just converts back and forth between samples and waveforms.

Fig.\ref{cap:Intelligent-hardware-vs.} shows the two main components
of a software-defined transceiver. The hardware implements a two-way
mapping between waveforms and samples. Except for the possibility
of controlling the power of the transmitted signal, the amplification
of the received signal, as well as some other parameters that are
not relevant for this discussion, this mapper performs the same operation
regardless of the standard implemented by the transceiver.

%
\begin{figure}
\begin{center}\includegraphics[%
  width=60mm,
  keepaspectratio]{figures/dumb_hardware}\end{center}


\caption{\label{cap:fig_dumb_hardware}Dumb hardware and
intelligent software}
\end{figure}


\chapter{System Overview}

\index{Simulation mode!Overview}
\index{Real-time mode!Overview}
The software-radio helps to make it possible to implement
a signal-processing algorithm which works on samples that are
transmitted and received over the air.

Because the debugging is an important part of the implementation of a
signal-processing algorithm, the software-radio can be run in either
\emph{simulation mode} or in \emph{real-time mode}. Fig. 
\ref{fig:simulation_real-time} shows the software-radio in both modes.

\begin{figure}
   \centering
\includegraphics[scale=1]
{figures/simulation_real-time}
   \caption{Structure of the software-radio in both modes}
   \label{fig:simulation_real-time}
\end{figure}

\index{Visualize!Overview}
The \emph{Graphical User Interface} (GUI) is the only visible part of
the software-radio and allows the user to visualize the state of the
different \emph{Modules} as well as to change their configuration. The
\emph{Channel} is a general interface that represents either a
\emph{Simulation} or has access to the \emph{Hardware}.

\section{Simulation Mode}

In simulation mode no hardware is used, and the whole transmission is
simulated in software, including Gaussian noise and multi-path fading.
There are no real-time constraints which makes it very easy to debug
the algorithm to be implemented.

Of course, if you don't have access to the right hardware, this is the
only possibility to use the software-radio. However, the
\emph{channel-server} which links multiple channels together, is
written to simulate a real channel with high enough accuracy to test
and verify signal-processing algorithms.


\section{Real-Time Mode}

In real-time mode only the Graphical User Interface runs on Linux,
while the rest of the software-radio runs in Real-Time mode, made
available through the use of RTLinux. This is necessary, as the
transmission and reception of the samples has to meet time-constraints
that are not possible to meet in simple Linux.

As of spring 2004, there exists two hardware-platform that allow the
software-radio to do actual transception of samples over the air. The
older one, produced by STMicroelectronics, offers a simple
SISO-interface, that is, one antenna at each end of the transmission.
The newer interface, produced by ICS-Ltd, allows the software-radio to
take advantage of a MIMO-channel, with up to four antennas at each end
of a transmission. A MIMO-channel is defined as a channel that has more
than one transmitting antenna and more than one receiving antenna.
These channels have very interesting properties, mainly the possibility
to multiply the available channel-capacity by a function of the
available antennas.


\section{Communication}

\index{Channel-server!Overview}
The software-radio is built to have a two-way communication. So, if you
have more than one instance of a software-radio running, they can
communicate together.
 
 If the software-radio is run in real-time mode,
only one instance of a software-radio can run on a computer. So if you
want to communicate in real-time, you need at least two computers.

 In simulation mode, the number of instances per computer is only
limited by its calculation-power (and the patience of the user ;). A
\emph{Channel-Server} connects all channels of all instances of the
software-radio together and makes it possible that everybody can listen
to what the other radios are sending.


%    This should go somewhere in the \part{architecture}
% For this
%reason we implemented a frame-based, slotted Time Division Duplex (TDD)
%approach. This means, that at each given moment in time, the
%software-radio is either transmitting or receiving. A number of
%samples are taken together to form \emph{slots}. Several slots together
%form a \emph{frame}, which is the largest entity in the software-radio.


\chapter{\label{chap:Usage}Usage}

At EPFL, the Federal Institute of Technology in Lausanne, Switzerland,
we use the software-radio both in class and for research purposes.

This chapter gives an overview of what we did with the software-radio
until the end of 2003, what we are doing now in winter/spring 2004, and
what we are planning to do during the rest of this year.

\section{Past}
 In class, it has been used to demonstrate the different parts of a
radio-transmission, such as modulation, spreading, coding and matched
filtering.

 For research, we used it succesfully to demonstrate the usability of
LDPC-codes over the air and to verify their theoretical performance.

\section{Present}

 We are looking in the challenges arising from MIMO transmission that
is coded with LDPC-codes. There are timing constraints to be solved, as
well as theoretical challenges with regard to the MIMO channel to be
met.

\section{Future}

 Different projects for the software-radio are in preparation. These
include a better matched filter (channel estimation), ZigBee
implementation and the obligatory GPS-decoder.


\chapter{Outlook}

 For the time being, the software-radio is taking a direction towards
point-to-point communications in MIMO-channels. We would very much like
to study the implications of multi-point to multi-point communications,
as well as low-tech implementations of a communication.

\section{Multi-point to Multi-point}

 Point-to-point communications are quite well known. In fact, every
commercially available transmission technology today only works in a
point-to-point configuration, usually surrounded with a method to be
sure that only one person is sending at the same time on the same
frequency.

 Different theories describe the possiblity of having more than one
sender at the same time and being able to reconstruct the signal at the
other end. It would be very interesting to study these theories in a
real environment in order to give a feed-back about problems arising
when implementing such theories.

\section{Low-Tech Communication}

 The current hardware in use is capable taking advantage of several MHz
of spectrum to transmit and receive. HAM-radios only have a couple of
kHz of spectrum available for the transcpetion. It would be interesting
to study transmission using a sound-card and a HAM-radio, perhaps to
propose a better and faster transmission than AX.25.