Modes of Operation

As the signal-processing part and the framework is very flexible, different operating-modes are possible:

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

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

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 source can contain readable text-messages that are printed by the sink and can be verified by hand.

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

Simulation or Real-Time

As already described in section 9.3, 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.

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.

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 Radios/Simple/BS and 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.

Setup

**Figure 11.1:** The most simple two-way communication example
$\includegraphics[width=10cm,keepaspectratio]{figures/simple_setup.eps}$

Looking at fig. 11.1, you can see two parts: a master and a client^11.1. The communication channel in this example consists of three slots, of which only two are occupied^11.2. 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 , the antenna is a placeholder for either a real channel or just a simulation.

Modules

This is a short overview of the different modules:

[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.
[modulator]Takes bits as inputs and creates complex symbols. In its default-configuration, it outputs QPSK symbols.
[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.
[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.
[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.
[rrc]The Root Raised Cosine pulse-shape filter. Takes the complex signal, upsamples by a factor of two and generates a real output.
[stfa]Slot To Frame Allocation, takes the slots and prepares them to be sent over the channel.
[matched_filter]The counterpart to midamble, calculates the channel-estimation and the matched-filter, and applies it to the input-signal.
[demodulator]Makes a hard decision on the received signals.
[sink]Prints to the screen the received sequence of bits.
[synch_rcv]Keeps up the synchronisation with the master.
[despread]Undos the operation introduced by the spreader, and offers a cleaner signal. As coding module this is suboptimal.
[sch_rcv]Decodes the synchronisation-channel and sets the tx-amplitude according to it's information.

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.

Client

While the master is quite static, the client has to do lots more:

Search for the synchronisation-signal
Set up the synch-slot and uplink-slot
Keep the synchronisation

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 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 synch_rcv module active, to allow for further synchronisation. All this is done in a macro-module called 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.

Linus Gasser 2004-04-14