For the first Iris blog post, I thought it would be a good idea to briefly discuss the Iris architecture and the various elements which make it up.
Iris is a program and a set of libraries written in C++ which can be used to build software radios. A software radio is a wireless system in which many of the tasks for generating a signal for transmission, or receiving and extracting data from a transmitted signal are carried out in software, often on general-purpose processors such as those found in PCs or laptops. Here, a radio is any device which sends or receives data wirelessly (this could be anything from a digital TV receiver to an 3GPP LTE modem used in modern mobile phones). One of the major advantages of building a radio in software is the flexibility it provides. In software, it’s very easy to dramatically change the properties of the radio (for example, switching from a garage door opener to an 802.11 wifi access point or vice versa). Iris is designed to support and exploit this flexibility or reconfigurability.
Iris is built using a plugin architecture. Each plugin is a library which does a specific job (e.g. data scrambling, OFDM modulation etc.) and which provides a generic API for the core Iris program to use. These libraries can be dynamically loaded at runtime and used within a software radio design. The main type of Iris plugin is called a component. Components typically process streams of data. They have input and output ports and work by reading data from one or more of their inputs and writing data to one or more outputs. In Iris, components run within an engine. The engine is responsible for loading the component library, initialising the component, providing input data to it, calling it to work on that input data, taking output data from it, destroying it and unloading the library when the radio is shut down. Typically, a component in an Iris radio will run in a loop, repeatedly processing sets of data before it is destroyed and unloaded. Components can expose parameters which control how they operate and these parameters may be used to reconfigure a radio while it is running.
Iris currently has two types of engines (and thus two types of components) – the Phy engine and the Stack engine. Phy components typically operate on a stream of signal data which flows in one direction from input to output and execute only when called by their Phy engine. Examples include modulators and demodulators, channel coders and decoders, data scramblers etc. Stack components on the other hand may support bidirectional data, coming both from above and below. They run their own threads and can generate sets of data at any time, in addition to processing data coming from above and below. Stack component examples include complete MAC layers, network routing layers and data encryption layers.
In order to run a radio in Iris, an XML configuration file is used. This file tells the core Iris program which engines will be used to create the radio, and which components will run within those engines. It also includes the initial parameter settings for each component.
An example XML configuration file for a simple OFDM transmitter is shown below:
<softwareradio name="Radio1">
<engine name="phyengine1" class="phyengine">
<component name="filerawreader1" class="filerawreader">
<parameter name="filename" value="testdata.txt"/>
<parameter name="blocksize" value="140"/>
<parameter name="datatype" value="uint8_t"/>
<port name="output1" class="output"/>
</component>
<component name="ofdmmod1" class="ofdmmodulator">
<port name="input1" class="input"/>
<port name="output1" class="output"/>
</component>
<component name="signalscaler1" class="signalscaler">
<parameter name="maximum" value="0.9"/>
<port name="input1" class="input"/>
<port name="output1" class="output"/>
</component>
<component name="usrptx1" class="usrptx">
<parameter name="frequency" value="5010000000"/>
<parameter name="rate" value="1000000"/>
<parameter name="streaming" value="false"/>
<port name="input1" class="input"/>
</component>
</engine>
<link source="filerawreader1.output1" sink="ofdmmod1.input1" />
<link source="ofdmmod1.output1" sink="signalscaler1.input1" />
<link source="signalscaler1.output1" sink="usrptx1.input1" />
</softwareradio>
This XML configuration specifies 4 Phy components which will run within a single Phy engine. In this radio, data is read from the file “testdata.txt”, modulated into an OFDM signal, scaled in magnitude and transmitted with a specific carrier frequency and bandwidth by a radio front-end, in this case an Ettus Research Universal Software Radio Peripheral (USRP). The resulting radio looks like this:
You can see that some initial parameter values are provided for some of the components in the radio. If a component has parameters which are not specified in the XML configuration, these are set to default values (as is the case for the OFDM modulator here). An XML configuration file specifies the structure of an Iris radio when it is initially loaded and run. However, it can also be used to reconfigure a radio while it is running. This can be done for example by changing the value of a parameter in the file, saving it and prompting Iris to reload it. Iris will compare the configuration in the file with that of the running radio, find that one of the parameters has changed and reconfigure that parameter as required.
Using the XML configuration file, an Iris user can easily reconfigure a running radio. However, we often need a radio to reconfigure itself instead of relying on user input. This might be the case for example, when we wish to design a receiver which scans a set of channels for signals of interest. We have already discussed the main type of Iris plugin – the component. The second type of plugin which is used in the Iris architecture supports this self-configuring behaviour – the controller. Controllers are libraries which are loaded at runtime, just like components. However, a controller does not run in an engine and typically does not operate on streams of data. Instead, a controller has a global view of a running radio and can reconfigure any component in the radio at any time.
In my next post, I’ll discuss the role that controllers can play in an Iris software radio and show some examples of how controllers can be used to make a “smarter” radio which reconfigures itself as required.
Iris 