Proceedings of the SDR ’10 Technical Conference and Product Exposition, Copyright © 2010 Wireless Innovation Forum, Inc. All Rights Reserved INTERFACING A REASONER WITH AN SDR USING A THIN, GENERIC API: A GNU RADIO EXAMPLE * Jakub Moskal (Northeastern University, Boston, MA, USA; jmoskal@ece.neu.edu); Mieczyslaw M. Kokar (Northeastern University, Boston, MA, USA; mkokar@ece.neu.edu); Shujun Li (Northeastern University, Boston, MA, USA; shli@ece.neu.edu) * Approved for Public Release, Distribution Unlimited ABSTRACT We present a Cognitive Radio Framework (CRF), an extension of the Ontology-Based Radio, which makes use of the LiveKB [5] component to interface an inference engine with a SDR. LiveKB provides a generic, SDR-independent interface for accessing radio's knobs and meters, which enables the CRF to support knowledge reusability across different SDRs. We explain how the SDR experts can benefit from this design; we describe the challenges encountered while implementing the prototype, and demonstrate how we integrated the CRF with the GNU Radio toolkit. 1. INTRODUCTION Developing the Cognitive Radio (CR) architecture on top of a SDR platform requires two features: 1) access to the radio's contextual information (meters) that comes from its self-awareness and from sensing its environment, and 2) the ability to alter the radio's operational behavior by modifying its parameters (knobs). Since different SDRs offer different knobs and meters, and different ways to access them, it is a challenge to design a CR architecture that would work with all or at least with most of the radio platforms. A common solution to the problem of interfacing multiple software components is to introduce a public Application Programming Interface (API). This allows the developers to implement just one API and enable their software to interface with many components, developed independently. To ensure the quality of the API and to attract the majority of a community, APIs are standardized by organizations, rather than by single companies. Despite their obvious benefits, there are at least two drawbacks of using the standard APIs: 1) it takes a significant effort to change them, and 2) creating a new version that is not backwards-compatible results in losing the interface among the components that implement different versions of the standard. Currently, there is no standard API for the interface between a cognitive engine and SDR, though different groups in the community have published public APIs to serve this purpose. Among them is CR API [1] from the VTCROSS framework, the PAAL [2,3] layer from the Community-Based CR Architecture and Open Source Cognitive Radio (OSCR) Radio Interface (ORI) [4]. We proposed [5] the LiveKB architecture – a platform- independent extension of the Ontology-Based Radio (OBR) architecture, which utilizes ontologies and policies to enable the CR paradigm. Although the OBR was never fully implemented, it has been shown that it can be used to analyze the multipath structure [6], negotiate the length and structure of the equalizer training sequences [7], and dynamically extend network coverage and reachback [8]. Instead of relying on radio-specific APIs to interface the reasoner, the proposed architecture requires a thin, generic API for connecting with the inference engine that uses the software model of the radio platform to identify access paths to particular radio parameters (variables). This architecture is capable of maintaining the interface with the SDRs that change their APIs without the need of recoding the reasoner API due to the fact that the interface information is provided dynamically via the software model. In this paper we present an improved design of the architecture, now called the Cognitive Radio Framework (CRF), with the focus on the reusability of expert knowledge. We describe the challenges encountered during its implementation and demonstrate how it can be used with a GNU Radio toolkit [9] and the Universal Software Radio Peripheral (USRP). 2. THE COGNITIVE RADIO FRAMEWORK (CRF) The CRF architecture (Figure 1), although initially designed as an extension of the OBR [7], introduces numerous improvements to its predecessor. It consists of the following components: Monitor Service (MS), Reasoning Component (RC), Data In/Out (DIO) and LiveKB. The first two are inherited from the OBR: MS is responsible for passing