Overview
The reconfigurable platform consists of a network of highly reconfigurable nodes. We use the term Reconfigurable Node rather than software radio to emphasize that we are concerned with communication systems that are reconfigurable from application to physical layer rather than physical layer only. A node in our network consists of heterogeneous software components that sit on top of physical layer radio components (e.g. frequency agile frontends, wideband antennas etc.). A software component in our system can be anything from a higher layer of a communication stack to some signal processing element of the PHY layer. The reconfigurable nodes use a general-purpose-processor based architecture framework that facilitates the linking together of these varied components in a modular fashion and their real-time reconfiguration and control. The current hardware is a gnu radio frontend using our own antennas. The nodes in the network are contolled using policy based management techniques, details of which can be found here. The testbed is remotely accessible via our web interface.

The diagram below shows the main entities in the testbed. The central entitiy is the reconfigurable node. More details of the platform are given below.

The Nodes
Components in the Reconfigurable Node tend to have greatly varying levels of granularity. For example, a component may encapsulate an entire node layer ( Network or Physical layer of the OSI model) within a network stack architecture or may contain a subsection of such a layer (such as a filter or digital modulator). Each component will have a number of associated parameters which control its operation (such as the cache timeout of an ad-hoc routing layer or the tap values of a filter). A significant advantage of adopting such a component-based design is the ability to manage a very high degree of complexity. By encapsulating the implementation of specific parts of the node in components, it is possible for a node designer to effectively build a wide range of complex systems without detailed knowledge of every aspect of each component used. To facilitate this we have designed a universal component container or shell which is used to wrap the unique functionality of each heterogeneous component and allow it to be handled in a generic manner.

The Components
Two specific component types make up the fundamental building blocks of the Reconfigurable Node. These are the
Layer Component and the Radio Component.The Layer Component is, as it says, a layer of the stack. The Radio Component is typically the type of component which features within the physical layer and is used to encapsulate a single signal processing step of an isochronous signal chain. A number of interfaces have been designed to control the components. The Inter-Component Interface permits components to be linked together to form a network stack structure and facilitates the flow of data upwards and downwards over this link. The Component Lifecycle Interface is provided to allow an external controller to start, suspend, resume and stop the operation of the component as well as initialize and destroy the component itself. The Parametric Reconfiguration Interface facilitates the manipulation of a component’s operating parameters in a generic manner and the Component Event Interface is used to notify an external listener of any significant occurrences within the component. The relevance of each of these interfaces will become obvious in later sections.

The System
Figure 2 illustrates the principal elements of the framework involved in the process of creating and managing the node network stack. These elements are the Stack Manager, the Configuration Parser and the Component Manager, each of which is presented in turn below. The entity on the rightmost side of the figure is meant to represent the inventory of components, the grey representing layer components and the green representing radio components.

The key controlling entity of the reconfigurable node is the Stack Manager. A user of the system creates a radio/node configuration of choice by stringing a set of components together. If the desired component does not exist in our inventory of components, then a new component must be created by the user. A particular radio/node implementation is defined in a configuration file which is a simple XML file Given a radio/node configuration, the Stack Manager identifies, creates and initializes the required components. The components are then linked together to form the structure of the node’s network stack and the operation of each is started. Throughout the operating period of the network stack, the Stack Manager is responsible for handling and reacting to any events signalled by the components as well as performing any reconfiguration required. When the operation of the network stack ceases, the Stack Manager halts the operation of each component, unlinks them to break up the stack structure and destroys them. In order to carry out these tasks successfully, the Stack Manager uses a Configuration Parser to handle the parsing of the XML configuration file. The Configuration Parser is the element of the reconfigurable radio with the responsibility of translating the network stack configuration into a lightweight data structure which can be read by the Stack Manager. The Configuration Parser also provides the ability to create a full XML configuration document from the stack data structure and thus capture the stack state at any time. The system uses what is known as the Component Manager to manage the components. The Component Manager maintains an inventory of components which may be used by the Stack Manager to build the node network stack.

Making Observations
Two observation mechanisms exist. Together these mechanisms permit observations to be both pushed by the Reconfigurable Node to the entity controlling the stack (CTVR Controller in Figure 1) and pulled from the Reconfigurable Node by the controller. The first of these mechanisms allows any component within the node network stack to notify the Stack Manager of a significant occurrence. These Events may be defined by the designer of the individual component and can be used to highlight any occurrences that the designer considers of use to the Cognitive Engine. Examples include the crossing of a given threshold for the bit error rate within a Reed-Solomon decoder component or for the link change rate of an ad-hoc routing component. By signalling a given event, the component makes the Stack Manager aware of the specific occurrence and allows it in turn to inform the controller. The second mechanism, referred to above, permits observations of the outside world to be pulled from the Reconfigurable Node by the controlling entity. This mechanism consists of a shared database referred to as the Reconfigurable Node Blackboard. The Blackboard permits each of the components of the network stack to expose any information which may be used to inform decisions made by the Cognitive Engine. Examples of such information could be the power spectral density obtained at the FFT stage of an OFDM receiver or the routing table of a network layer routing protocol. By providing both a push and pull mechanism for the exchange of observations between the Reconfigurable Node and the controlling entity, both reactive and proactive approaches to decision-making may be facilitated.

Taking Actions
In general three types of actions (i.e. reconfigurations) are possible within the platform. The first, parametric reconfiguration, involves the dynamic alteration of individual parameters of any of the components (e.g. change of a filter coefficient, change of cache size in routing tables). The second, structural reconfiguration, involves the alteration of some component of the node while still performing the same overall application (e.g. change of modulation scheme, change of MAC layer). The third, application reconfiguration involves completely replacing the software of the node with an entirely different Reconfigurable Node configuration (e.g. change from WiMAX to WLAN). At the most fundamental level of reconfiguration is the ability to alter individual parameters within each layer of a structure and to this end the Parametric Reconfiguration Interface (PRI), as described in section III-A is used. By specifying the reconfigurable parameter label and providing an associated value, the PRI may be used in a generic manner to alter parameters of any layer in a given configuration. Although this interface is common to each layer, the reconfiigurable parameters are layer-specific so a process involving metadata and automatic code generation is used to provide the specific functionality needed at each layer. A dedicated script uses metadata tags inserted in the layer code to generate the reconfiguration code required. This code is then included in the layer implementation. Two additional common component interfaces play vital roles in facilitating structural reconfiguration of the node network stack. Firstly the Inter-Component Interface (ICI), as described in section III-A has a role. This forms the link between adjacent components of the network stack. In order to permit alteration of the network stack structure, it is essential that this ICI can be rapidly torn down and re-established. With these requirements in mind, a layer-neutral packet structure was implemented to encapsulate the data flowing between components of the network stack. The use of this packet structure greatly reduces the complexity needed for the ICI and simplifies the process of linking and unlinking components to form the node network stack structure. Secondly the Component Lifecycle Interface (CLI), also introduced in section III-A, is used to externally control the operation of the individual component and is essential in the process of structural reconfiguration. As the links between components are altered, the CLI is used to suspend and resume component operation in order to avoid potential conflicts, as well as to start the operation of inserted components and stop that of components which are being removed. The Stack Manager, introduced in section III-B is a key enabling feature of full application reconfiguration of the reconfigurable core of the platform. The description in section III-B of how the stack is created and started by the Stack Manager is also how the Stack Manager reconfigures the stack. In order to permit external reconfiguration of the stack, the Stack Manager provides a Stack Control Interface (SCI) which acts as an API for the reconfigurable core. Using the SCI, an external controller (e.g. the Cognitive Wrapper) may trigger a reconfiguration by passing a new XML configuration to the Stack Manager. This configuration is parsed and the resulting data structure compared with that of the existing stack. Each difference between the two will trigger a reconfiguration on one of the levels discussed above, the sum total of which may result in a completely new stack structure and application.

The License
We have a test license from ComReg, the Irish Regulators, which faciliates our experimentation. We have 50 MHz of dedicated spectrum at our disposal as illustrated in the diagram below.

The Policy Based Management
Details of this can be found here.

---