abstract.lyx

软件无线电的平台

#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single 
\papersize Default
\paperpackage widemarginsa4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Title

A Modular Software Radio using RT-Linux
\layout Abstract

Our software-radio solution is used to test new transmission-technologies.
 This requires a real-time system for which we chose RT-Linux, due to it's
 performance and its openness.
 For the interaction with the user we chose the Qt-library for its performance
 and modularity.
\layout Section

Introduction
\layout Standard

Our definition of a software-radio:
\layout 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, bandwidth,
 hardware imperfections) may be implemented by means of an appropriate code.
\layout Standard

The goal of our project is to make it as simple as possible to apply different
 mappings.
 In order to achieve this, we set up the general architecture that can be
 seen in figure 
\begin_inset LatexCommand \ref{cap:Overview}

\end_inset 

.
\layout Standard

The custom hardware translates the signal we're interested in to baseband
 so that it can be digitised by an analog to digital converter.
 Once the signal is in the computer's memory, signal-processing algorithms
 are used to extract the useful signal.
 As this has to run in real-time, all these algorithms run in the Real-Time
 Linux environment.
 On top of this there is an application that allows the user to interact
 with the signal-processing part.
\layout Standard


\begin_inset Float figure
wide false
collapsed false

\layout Standard
\align center 

\begin_inset Graphics
	filename overview.eps

\end_inset 


\layout Caption


\begin_inset LatexCommand \label{cap:Overview}

\end_inset 

Overview
\end_inset 


\layout Subsection

A Refresher on Signal Theory
\layout Standard

When working with signals, two representations are most widely used: frequency
 and time.
 Without going into too much details, we present the hardware-part of the
 software-radio under these two aspects.
\layout Standard

In the frequency-domain, the software-radio we're using at EPFL has a 
\emph on 
carrier-frequency
\emph default 
 that is centered at 2.4GHz.
 This is in the international ISM-band, also used by 802.11 and bluetooth.
 As can be seen in figure 
\begin_inset LatexCommand \ref{cap:From-RF-to}

\end_inset 

, the 
\emph on 
bandwidth
\emph default 
 of the signal is of 10MHz.
 The custom hardware translates this signal to a lower, 
\emph on 
intermediate frequency
\emph default 
 (IF) of 70MHz.
 Additionally it filters the desired signal, adjusts the amplitude and prepares
 the signal for the A/D conversion.
\layout Standard

The PCI-card used in our project is built by ICS and includes a further
 transformation of the signal into 
\emph on 
baseband
\emph default 
.
 Most signal-processing algorithms have in common that they rely on Q (real)
 and I (imaginary) signals that form a 
\emph on 
quadrature modulation
\emph default 
.
 This transformation doesn't alter the form of the signal, only the format
 of it.
\layout Standard

This pre-processing takes care of the most calculation-intensive tasks without
 loss of any information of the signal.
 In order to transmit, the opposite transformations are done, taking Q and
 I samples, up-converting them to an IF of 70MHz and finally mixing them
 onto a 2.4GHz carrier frequency.
\layout Standard


\begin_inset Float figure
wide false
collapsed false

\layout Standard
\align center 

\begin_inset Graphics
	filename rf_if_bb.eps

\end_inset 


\layout Caption


\begin_inset LatexCommand \label{cap:From-RF-to}

\end_inset 

From RF to base-band
\end_inset 


\layout Standard

On the other hand, in the time-domain, we use a structure that is similar
 to the 3GPP/TDD standard.
 The transmission is divided into 
\emph on 
frames
\emph default 
 that have a duration of 10ms each.
 Each frame is further divided into 15 
\emph on 
slots
\emph default 
.
 In our implementation, slot 0 is used to 
\emph on 
synchronise
\emph default 
 the sending station with the receiving station.
 This means that every 10ms, the receiver has to decode this slot in order
 to correct for an eventual frequency drift in any of the clocks.
 If this timing is not met, de-synchronisation may occur which means that
 the transmission has to be aborted.
\layout Standard

While the 10ms still allow for quite some margin in the calculation, the
 timing gets much more strict if the software-radio has to send a slot.
 In this case, the algorithm is woken up 2 slots in advance and has to calculate
 the complete slot in 660
\begin_inset Formula $\mu s$
\end_inset 

.
 If he misses this deadline, the hardware will transmit an incomplete slot
 over the air, which will result in a corrupted slot.
\layout Standard

A stock Linux-kernel can meet the 10ms 99% of the time.
 But even a low-latency patched kernel has difficulties to meet schedules
 below 1ms.
 In order to achieve the 660
\begin_inset Formula $\mu s$
\end_inset 

 needed, a real-time solution is necessary.
 Using RT-Linux, we can meet deadlines with an accuracy of about 10
\begin_inset Formula $\mu s$
\end_inset 

 in more than 99% of all cases.
\layout Standard


\begin_inset Float figure
wide false
collapsed false

\layout Standard
\align center 

\begin_inset Graphics
	filename frame_slot.eps

\end_inset 


\layout Caption


\begin_inset LatexCommand \label{cap:Frame-and-Slot}

\end_inset 

Frame and Slot structure
\end_inset 


\layout Subsection

Real-Time Linux
\layout Standard

RT-Linux comes in two flavours: commercial and GPLed.
 We chose to go with the GPLed solution, as we wanted to open up our source
 under the GPL itself.
 The fact that RT-Linux is in a controversial state due to an included patent
 didn't touch us, as the license grants the right to use this patent as
 long as we put the resulting program under the GPL.
\layout Standard

The method RT-Linux uses to achieve hard real-time is quite simple: RT-Linux
 itself has a small micro-kernel that includes a task-scheduler, a posix-compati
bility layer and an interrupt abstraction layer.
 The Linux-kernel itself is a thread from RT-Linux, running under the lowest
 possible priority.
 This has two consequences:
\layout Enumerate

Whenever a real-time thread is ready to run, the Linux-kernel has to wait
\layout Enumerate

It is dangerous to directly call Linux-kernel function from a real-time
 thread
\layout Standard

While the first point gives the whole strength to RT-Linux, the second point
 complicates any interaction between real-time threads and the Linux-kernel.
\layout Standard

In order to start a real-time task, the user has to write a kernel-module
 that is inserted into kernel-space using 
\emph on 
insmod
\emph default 
.
 During initialisation, this module can use the 
\emph on 
pthread_create
\emph default 
 function to start a real-time thread that is controlled by RT-Linux.
\layout Subsection

Software-Radio Architecture
\layout Standard

Talking about real-time, there is one big problem encountered when developing
 software under RT-Linux: everything runs in kernel-space.
 So, instead of reading 'segmentation fault', you see a nasty 'kernel Oops'
 on the screen and some register dump which is difficult to understand,
 to say the least.
 Furthermore, if you write to the wrong address, everything can happen,
 up to a deleted hard-disk (happened once during development.
 Long live NFS and backups).
\layout Standard

For this reason, the software-radio developed at EPFL offers a simulation-mode,
 where all the modules run in user-space and where it is much more easy
 to debug new modules.
 Of course it's not possible to use the hardware-part under these circumstances,
 as deadlines couldn't be met.
 The problem is solved by using a channel-interface that either uses a simulatio
n of the channel or accesses the real hardware.
 Using the simulation the modules can be written and tested without crashing
 the computer, and they are only inserted into the real-time system once
 they are known to work good.
\layout Standard

In the figure 
\begin_inset LatexCommand \ref{cap:The-software-architecture}

\end_inset 

 you can see the basic structure of the software-radio.
 The framework does all the job of gluing together the modules, taking care
 of reconfigurations, data-passing and scheduling so that everything arrives
 at the right time.
 It would be an article of its own to describe the different techniques
 that are used to offer a nearly object-oriented environment to modules
 written in C.
\layout Standard

Inside of this framework are the signal-processing modules that take care
 of things like modulation, channel estimation and more interesting topics
 like coding, decoding and everything you can think of that fits into 10MHz
 bandwidth at a carrier-frequency of 2.4GHz.
\layout Standard

In general, there are three kinds of modules:
\layout Enumerate

signal-processing modules, that treat the signal on different levels
\layout Enumerate

test-modules that report on the correct or wrong behaviour of signal-processing
 modules
\layout Enumerate

radio-modules that come in transmitter/receiver pairs and that are used
 to transmit signals over the air
\layout Standard

Each module is composed of 
\begin_inset Formula $0..n$
\end_inset 

 inputs and 
\begin_inset Formula $0..m$
\end_inset 

 outputs as well as configuration-variables to influence the behaviour of
 the module and stats-variables that reflect the actual internal state.
 
\layout Standard

On top of all of this there is the GUI that offers a nice interface to the
 software-radio with the possibility of visualising all signal-flows and
 changing the configuration of the modules while the software-radio is running.
\layout Standard


\begin_inset Float figure
wide false
collapsed false

\layout Standard
\align center 

\begin_inset Graphics
	filename sr_architecture.eps

\end_inset 


\layout Caption


\begin_inset LatexCommand \label{cap:The-software-architecture}

\end_inset 

The software-architecture
\end_inset 


\layout Section

Implementation
\layout Standard

Signal-processing algorithms use lots of computation power, this is why
 we have two DELL poweredge 4600 dual-Xeon servers to do the number-crunching
 for the software-radio.
 On these machines a Linux 2.4.20 kernel with a RT-Linux-3.2 pre3 does its
 service quite happily.
 
\layout Standard

CVS is used for the software, so that each researcher can have it's own
 branch where he works on modules.
 Once a month we try to put everything together and upload the result to
 http://software-radio.sourceforge.net.
\layout Standard

All developers use KDE 3.1.3 for the desktop and either XEmacs or vi for the
 editor.
 The systems are mixed Mandrake/Debian, so that the code-base can be tested
 out on different machines.
 The RT-Linux-machines and the server run Debian/woody, the platform of
 choice for a stable Linux.
\layout Subsection

Makefiles
\layout Standard

Instead of relying on 
\emph on 
autoconf
\emph default 
 to generate our Makefiles, we decided to use a very simple Makefile in
 each subdirectory that includes one of the main Makefiles.
 The main difficulty is to find the path of the Makefile to include:
\layout LyX-Code

MODULE_NAME = ldpc
\layout LyX-Code

\layout LyX-Code

BASE := $(shell pwd | perl -pi -e "s/(.*SRadio[^
\backslash 
/]*).*/
\backslash 
1/")