IRIS (CTVR, Trinity College Dublin)

Important note: For a more detailed and up to date description of Iris and the Iris testbed, please consult the CREW portal. A high-level overview of Iris and the testbed is given below.

The reconfigurable radio consists of a general-purpose processor software radio engine, known as IRIS (Implementing Radio in Software) and a minimal hardware frontend. IRIS can be used to create software radios that are reconfigurable in real-time.

wireless backhaul system operating in the UHF band (TV whitespace)
IRIS running on a laptop with the USRP frontend and a CTVR antenna

The fundamental unit for building reconfigurable radios in the IRIS Radio Architecture is the Radio Component (a unit of radio functionality). A user of IRIS creates a radio from an existing suite of Radio Components or by creating new components when necessary. These basic building blocks of the system are key to its ability to reconfigure. The Radio Components are designed to encapsulate radio functionality in a way that would facilitate their reuse among many applications and permit ultimate flexibility in the design of the overall system. In all there are six major entities:

1. Radio Component

A Radio Component is the basic unit of an IRIS implementation and comprises an individual stage in the signal-processing chain of an IRIS reconfigurable radio. The actual level of functional complexity that a Radio Component may encapsulate is at the discretion of the Radio Component designer. A wide range of components exist. Of interest to this project are components that are used for sensing, OFDM communication components, data logging components and other dynamic spectrum access related components.

2. XML Parser

Any give radio implementation is defined in an XML configuration file as a set of interconnected Radio Components. An XML parser is used to interpret the radio design specified in the XML configuration file and convert this information into a form that may be processed by the Component Manager and Radio Engine

3. Component Manager

The Component Manager loads the Radio Components specified in the XML configuration file and unloads a previously loaded radio configuration. The Component Manager also compiles an inventory of Components which may be located either on the host PC or from a remote location connected via Ethernet or internet, and these comprise the available Components that may be used as part of a radio implementation.

4. Radio Engine

The Radio Engine is the core of the IRIS framework. This implements the radio design to create an actual reconfigurable radio using the IRIS framework as the management and controlling entity. The Radio Engine relies on the Component Manager and control interface known as Control Logic.

5. Control Logic Manager

IRIS uses a Control Logic Manager (CLM) which is the main means of reconfiguring a radio configuration when the radio is in operation. This radio management feature can access the structure and parameters of all the Components and modify them as required. The CLM is independent of the Components (i.e. the CLM is a separate process that connects to the radio using a common interface and is fixed by any particular Component) and therefore may externally modify the operation and parameters of any of the Components that comprise the radio implementation.


The API used in IRIS is used to integrate an IRIS reconfigurable radio application into other applications. Specific functions that manipulate and control the IRIS Framework are abstracted from the core of the IRIS system enabling the sophisticated IRIS features to be accessed using a simple programming interface.

Overview of the IRIS system

Reconfigurability within IRIS

As stated above IRIS can be reconfigured in real-time. There are many definitions of reconfigurability so it is useful to explain in a little more detail as to what we mean. A software radio can be viewed as a number of signal processing stages that are linked together in a certain order to deliver the functionality required. With this in mind three levels of reconfiguration have been defined:

Level 1 - Parametric Reconfiguration involves the dynamic alteration of individual parameters of signal processing functionality. An example of parametric reconfiguration is a change in filter coefficients. An example specific to dynamic frequency management is the change of frequency setting in accordance with change of spectrum allocated to that particular radio.

Level 2- Structural Reconfiguration involves the alteration of the layout of the radio system or the replacement of some aspect of the software of the system while still performing the same overall application. For example structural reconfiguration occurs when the way in which a signal is processed is altered as in the case of the introduction of two stages of filtering instead of one. In this case the radio will still perform the same function but the reconfiguration may have the benefits of improving signal quality, power consumption or performance. An example specific to alternative frequency management regimes would be in the insertion of some new extra functionality within the existing software radio configuration, to make decisions about which frequencies the radio should use.

Level 3 - Application Reconfiguration involves completely replacing the software of the software radio with an entirely different software radio configuration. This type of reconfiguration allows a radio to completely change the application it performs. The same hardware being reconfigured from being a two-channel analogue FM transceiver to being a 10 channel digital BPSK transceiver is an example of application reconfiguration. Software download also falls into this category of reconfiguration. In terms of dynamic spectrum allocation it may be necessary for a radio to use an entirely different communication means to best take advantage of the new band of frequencies it has been allocated.

IRIS facilitates Parametric Reconfiguration, Structural Reconfiguration and Application Reconfiguration.


IRIS interfaces with the USRP. It can in principle use any RF frontend. It simply needs a software component that can read from and write to that hardware (akin to a driver).