abstract.lyx

软件无线电的平台

\layout LyX-Code

include $(BASE)/Include/module.mk
\layout Standard

The more easy solution, setting an environment variable, is a disadvantage
 as soon as there are different development trees for the same user.
 Using the above approach allows to have different branches called 
\emph on 
SRadio.Main
\emph default 
, 
\emph on 
SRadio.Linus
\emph default 
 and so on without having to change the environment variable whenever you
 change directory.
\layout Standard

The Makefile in 
\emph on 
Include/module.mk
\emph default 
 is responsible for
\layout Itemize

setting up dependencies using 
\begin_inset Quotes eld
\end_inset 

gcc -MM file.c
\begin_inset Quotes erd
\end_inset 

, an often forgotten option of gcc
\layout Itemize

compiling the module for user-space
\layout Itemize

compiling the module for RT-Linux, if available
\layout Itemize

keeping a nice output, not showing the whole gcc-line
\layout Standard

There are also additional functionalities in the Makefile that come in handy
 when working on a test or on a radio-part:
\layout Itemize

re-compiling parts of the tree
\layout Itemize

starting the current module in the debugger (gdb or ddd)
\layout Itemize

using the visualization-tool on the current module
\layout Itemize

cleaning up the test-environment
\layout Itemize

unloading all RT-Linux-modules
\layout Itemize

starting the current module in RT-Linux-mode
\layout Standard

Using this very simple mechanism of having one central Makefile allows to
 manage most of the tasks using the 
\emph on 
make
\emph default 
 command.
\layout Subsection

Real-Time and Simulation
\layout Standard

As described above, one of the main features of the software-radio is the
 capability of writing one source-code that is compiled into a user-space
 module and a kernel-module for real-time capabilities.
 Without going into all the gory details of the software-radio implementation,
 the following description focuses on the system-specific requests that
 have to be met.
\layout Standard

The main functionality of all these tricks is achieved by using a central
 include-file called 
\emph on 
system.h
\emph default 
 that has one big 
\layout LyX-Code

#ifdef USER_SPACE
\layout LyX-Code

...
\layout LyX-Code

#else
\layout LyX-Code

...
\layout LyX-Code

#endif
\layout Standard

This file has to be included in every .c-file that is to be compiled for
 the software-radio.
 
\layout Subsubsection

Mechanisms to Load Modules
\layout Standard

RT-Linux uses the kernel-module loader to put the modules into the kernel-space.
 For the simulation-mode, every module is compiled as a shared library and
 is loaded using the dlopen function-call.
\layout Subsubsection

Setup and Cleanup Handlers
\layout Standard

Whenever a module is loaded into the computer, a handler has to be called
 that properly initialises the module and makes it ready for first use.
 On removal of the module, appropriate handlers have to be called to clean
 up the module before unloading it from memory.
\layout Standard

For the insmod-mechanism in the Linux-kernel, there exist two macros that
 define these two handlers:
\layout List
\labelwidthstring 00.00.0000

module_init for the function that has to be executed when loading the module
\layout List
\labelwidthstring 00.00.0000

module_exit upon removal of the module
\layout Standard

Fortunately, something very similar exists for shared libraries:
\layout List
\labelwidthstring 00.00.0000

_init whenever the shared library is loaded for the first time
\layout List
\labelwidthstring 00.00.0000

_fini when the shared library is removed from memory
\layout Standard

The chosen solution is to define 
\emph on 
module_init
\emph default 
 and 
\emph on 
module_exit
\emph default 
 in the modules that need it, and put a
\layout LyX-Code

#define module_init(x) void _init(){ x(); }
\layout LyX-Code

#define module_exit(x) void _fini( void ){ x(); } 
\layout Standard

in the 
\emph on 
system.h
\emph default 
 file.
 Like this, whether a module is loaded using the 
\emph on 
insmod
\emph default 
 mechanism, or whether we chose to use 
\emph on 
dlopen
\emph default 
, the corresponding functions are executed.
\layout Subsubsection

Local and Global Name-space
\layout Standard

In C there is one big global name-space.
 If you chose to divide your project into multiple files and link them all
 together at the end, you have to be very careful not to have two different
 variables with the same name.
 The same goes also for the modules in kernel-space: all modules share a
 big global name-space.
 The first step to avoid name-clashes is to chose a prefix for all software-radi
o symbols: 
\emph on 
swr_
\layout Standard

The second step is to only export the needed symbols and keep the other
 symbols local to the module.
 For kernel-modules, there exists a standard way to assure only 
\emph on 
swr_some_function
\emph default 
 is visible to the kernel:
\layout LyX-Code

// Put this at the beginning of the file
\layout LyX-Code

#define EXPORT_SYMTAB
\layout LyX-Code

\layout LyX-Code

// This line belongs to the very end of the file
\layout LyX-Code

#define EXPORT_SYMBOL(swr_some_function)
\layout Standard

It is more difficult for shared-libraries.
 While searching through the big Linux-documentation (mailing-lists), I
 stumbled upon somebody from opera that tried to achieve exactly this in
 order to hide some proprietary implementations from the outside.
 He was happily rewriting the GNU-binutils when somebody told him that from
 version 12.13.90 onward, there exists a well-defined way to do exactly this:
 the VERSION command.
 In its full glory, this commend does much more than we need: version-controlled
 renaming of different symbols.
 To know the full details, do a 
\layout LyX-Code

info ld
\layout Standard

For our task, however, we just use the command to hide everything that is
 not explicitly defined as being exported:
\layout LyX-Code

VERSION{ { global: _init; _fini; swr_some_function;
\layout LyX-Code

           local: *; }; }
\layout Standard

The only thing to do is to parse the .c-files, search for EXPORT_SYMBOL and
 including all symbols found into this file, called 
\emph on 
.ld.conf
\emph default 
 in the software-radio.
 Using some Unix-tools, this can be done in one line:
\layout LyX-Code

@grep -h EXPORT_SYMBOL *.c | 
\backslash 

\layout LyX-Code

  sed -e "s/EXPORT_SYMBOL(
\backslash 
(.*
\backslash 
))/
\backslash 
1/" >> 
\backslash 

\layout LyX-Code

  .ld.vers 
\layout Standard

Then we can append this file to the linker-command to achieve what we want:
\layout LyX-Code

gcc ($LFLAGS) ...
 .ld.conf
\layout Standard

If we run 
\emph on 
nm
\emph default 
 on the resulting object-file, we can see that all non-exported symbols
 are local (lower-case letter) and that everything else is global (upper-case
 letter).
 One last thing to do is to tell the 
\emph on 
dlopen
\emph default 
 command that it should remember all global symbols, as well as to resolve
 all unsolved symbols right now:
\layout LyX-Code

dlopen( path, RTLD_NOW | RTLD_GLOBAL );
\layout Standard

This is done in the user-space simulation program from the software-radio,
 that takes as an argument all libraries to load.
\layout Subsubsection

Communication with the Outside
\layout Standard

In both cases the modules need to communicate with the visualisation program.
 A first version of the software-radio implemented a directory in the 
\emph on 
proc
\emph default 
-file-system to communicate to the user-space.
 Because of the nature of RT-Linux, this solution is very difficult to implement
, as it's dangerous to call Linux-kernel functions from a RT Linux-thread.
 A much cleaner solution can be achieved by using RT-FIFOs, simple input/output
 streams that are real-time safe.
\layout Standard

The interaction with this two kind of FIFOs is done again using an abstraction
 that hides the specialities of either the RT-FIFOs or the user-space FIFOs.
\layout Standard

For the program that has to interpret these FIFOs, it doesn't matter whether
 it's a user-space or a RT-FIFO.
 Only the location in the file-system changes.
\layout Subsection

Channel-Simulator
\layout Standard

From a signal-point of view, the channel simulator does nothing else than
 to simulate a static flat-fading channel with some Gaussian noise.
 Using some additional tool, one can change the taps of this channel, in
 order to change the conditions of the transmission.
\layout Standard

The channel-simulator acts as a server that listens to a certain port.
 Every radio that wants to enter the channel connects to this port and sends
 the radio-packets that it wants to transmit over the air.
 The simulator adds up all incoming packets adds some Gaussian noise and
 sends the packets back to the different radios.
\layout Standard

In order to change the channel-parameters, one has to start an additional
 program that communicates with the channel-simulator using a FIFO-interface.
\layout Subsection

Visualization
\layout Standard

A very important aspect of the software-radio project is to visualize and
 store signals as well as change configurations, show internal states and
 track them.
 This tool is used for demonstration purposes, teaching as well as taking
 measurements on a running system.
\layout Standard

Of course the tool has to be easy to use, yet powerful in the display of
 the different signals and data.
 As we wanted to take an object-oriented approach, Qt was one of the only
 possibilities to achieve our goal.
 For all the plotting-functions, we rely on the qwt-library, that gives
 us all the functions we need.
\layout Standard

The visualization tool searches for the presence of a real-time software-radio,
 and if it doesn't find one, it searches for simulation-radios.
 The architecture of the simulation is done such that different software-radios
 may run on the same computer in simulation mode.
 Each radio-simulation gets its own tab in the display, so that the user
 can easily swap between the different displays.
\layout Standard

In figure 
\begin_inset LatexCommand \ref{cap:Screenshots-from-the}

\end_inset 

 you can see the visualize-tool in action as it displays the internal state
 of a radio.
 The white bar in the lower half depicts the channel (here in simulation-mode).
 The modules that are above it are used for sending, while the modules below
 it are used for reception.
 The image on the right shows measurements of the number of erroneous bits
 versus the SNR (signal-to-noise ratio, the quality of the transmitted signal).
 These measurements have been ongoing for about an hour, and can be saved
 or exported as postscript-file.
\layout Standard


\begin_inset Float figure
wide false
collapsed false

\layout Standard
\align center 

\begin_inset Graphics
	filename snapshot_sradio_1.eps
	lyxscale 40
	width 70mm
	keepAspectRatio

\end_inset 


\begin_inset Graphics
	filename snapshot_sradio_3.eps
	lyxscale 70
	width 70mm
	keepAspectRatio

\end_inset 


\layout Caption


\begin_inset LatexCommand \label{cap:Screenshots-from-the}

\end_inset 

Screen-shots from the software-radio
\end_inset 


\layout Section

Conclusion
\layout Standard

We showed in this article how it is possible with GNU/Linux tools to create
 quite a complex research-tool that is able to verify or reject theories
 for tomorrows mobile phones.
 The tool-chain is flexible enough to handle customized demands in compilation,
 visualisation and user-handling in general.
 RT-Linux is able to handle the needed latency of about 
\begin_inset Formula $10\mu s$
\end_inset 

 without problem and fits nicely into the system.
\layout Standard

The future of our software-radio includes the ability of driving multiple
 antennas at once, enabling research on so called MIMO-channels.
 Be sure to check out http://software-radio.sf.net
\the_end