Articles Forum Examples Download Open Source
Oct 17, 2007
Copyright(c) 2007 by Pocomatic Software. All Rights Reserved.
In a simplified and conceptual description, a software defined radio (SDR) is a wireless communication device or equipment that, in order to quickly and easily support multiple and/or different radio bands/modes within a wide spectrum, uses reconfigurable software programs running on generic hardware/OSs (such as POSIX platforms) to perform certain or all radio signal processing.
To facilitate the quick composable and reconfigurable requirements, SDR waveform applications are commonly architected as composites wired up from software components. The de facto standard of such architecture is the Software Communication Architecture (JTRS-SCA) from the US Navy Joint Tactical Radio System (JTRS), or its commercial adaptation the Software Radio Architecture (SRA) Software Radio Architecture (SRA) from the SDR forum. The core framework (CF) of this architecture defines a CORBA based component framework for SDR applications.
By the JTRS-SCA component model, components of a single SDR waveform application are assumed to be distributed in multiple POSIX addressing spaces across processes or host boundaries. Therefore, SDR components are simply defined as conventional CORBA objects that can be invoked across nodes. Furthermore, in SCA, the OMG Name Service is specified as the distributed component registry of the assembly controller and the OMG Event Service as the distributed event service.
Although modeling a single SDR waveform application as a composite wired up from distributed components and OMG COS services is claimed to be necessary, it is one of the major obstacles for mainstream adoption of SDR. For radio wireless devices that have all their components resided in a single addressing space, a CORBA middleware layer is only an unnecessary burden of footprint, power consumption, learning curves, and excessive engineering complexities, product vulnerabilities, costs, and risks. This observation has prompted some practitioners to seek alternative component architectures for SDR waveforms without CORBA, for instance by directly using conventional non-CORBA C++ classes developed manually or generated automatically from the middleware platform independent model (PIM) UML diagrams of SDR specification (This is similar to the Parlay/OSA, where the early CORBA based Parlay specifications has been recognized to have unnecessary overhead and complexities and has been replaced with UML based reversion, with the CORBA/IDL as one of its platform specific model (PIM) mappings).
To receive acceptance of mainstream defense and commercial users, the component framework for SDR waveform applications has to take a significant step forward beyond JTRS-SCA and CORBA. The next generation SDR component framework should meet the following criteria:
· Neutral to heterogeneous component models and neutral to middleware platforms: The new component framework should not only be orthogonal and independent to middleware platforms, but more importantly not enforce a particular component model. For instance, it should seamlessly support plain old user defined C/C++ objects (POCO) as SDR components as well as JTRS-SCA core framework components (e.g. CF::Resource objects) based on CORBA (or other PSM mappings of JTRS-SCA).
· Simple core assembly model/schema: The new component framework should not incur steep learning curve, long ramp up time, and high development and maintenance cost. The core model/schema itself should be substantially simple, intuitive, and straightforward to application developers and novice, without relying on any UI and/or other massive code generating tools.
· Easily extensible and customizable assembly schema: Instead of mandating a single rigid “one-size-fits-all” model/schema at a predefined abstraction level or scheme, the core assembly model/schema should be able to be extended and customized not only by framework vendors but more importantly by domain application developers. Domain specific assembly models/schemas, including the JTRS-SCA assembly schema, should be merely domain specific models (DSMs) defined on top of the core model/schema in a matter of a few hours with a few hundreds lines of declarative code by domain users instead of weeks or even months of efforts and thousands lines of code by framework vendors.
· Lightweight and zero overhead: The extra power consumption and IO overhead should be significantly reduced to near zero. The memory footprint should be one or two orders of magnitude smaller than the first generation SCA CF implementations available today. Namely, the footprint should be reduced from one or several megabytes to, for instance, less than 70Kbytes.
PocoCapsule IoC & DSM is an open and customizable component framework that is able to meet all these criteria. A classic SDR example originated from the SCA reference implementation (SCARI) by CRC is used to demonstrate the power, characteristics, and methods of this open framework for SDR applications. In this example, a SDR waveform is wired up from 8 components, as illustrated in the following diagram:
This waveform application is built in several different scenarios (including JTRS-SCA). In the first two scenarios, SDR components are plain-old C++ objects. For application assembling, the core IoC schema and an user-defined DSM schema are used in the first and the second scenarios respectively. In the third scenario, SDR components are CORBA objects supporting interfaces defined by the JTRS-SCA core framework (CF). These JTRS-SCA components are assembled using a JTRS-SCA software assembly descriptor (SAD). Here, the JTRS-SCA assembly model is supported in open source by PocoCapsule out-of-the-box as a straightforward domain-specific-model (DSM).
Full source code of this example can be found in the examples/basic-ioc/sdr directory of PocoCapsule installation.
In this non-CORBA waveform application scenario, mocked SDR components are plain-old C++ objects (POCOs) without any special dependency on an underlying middleware framework or the PocoCapsule container itself. These components represent controlling and signal process devices. Each component could have arbitrary number of facet and receptacle ports. A facet port is merely a getter method on a component that returns a SDR::PushPort* pointer of C++ object, supposedly to be used to push data/commend into this receiving component. A receptacle port is a setter method on a component that injects a SDR::PushPort* pointer to the component, supposedly to be used to connect other data/commend receiving component to this data/commend sending component.
As described in the setup.xml, these components are wired up simply using the PocoCapsule core IoC schema defined in http://www.pocomatic.com/poco-application-context.dtd. For instance, the following description in the core IoC schema connect the AudioIn port of the chorus-resource component to the AudioOut port of the echo-resource component:
|
This connection is illustrated in the following diagram:
Full source code of this example can be found in the examples/basic-ioc/dsm-sdr directory of PocoCapsule installation.
The component programming model in this scenario is exactly same as the previous scenario. Namely, mocked SDR components are plain-old C++ objects (POCOs) without any special dependency on an underlying middleware framework or the PocoCapsule container itself. These components represent controlling and signal process devices. Each component could have arbitrary number of facet and receptacle ports. A facet port is merely a getter method on a component that returns a SDR::PushPort* pointer of C++ object, supposedly to be used to push data/commend into this receiving component. A receptacle port is a setter method on a component that injects a SDR::PushPort* pointer to the component, supposedly to be used to connect other data/commend receiving component to this data/commend sending component.
The component assembly model in this scenario, however, is an user defined domain specific model (DSM). Its schema is defined in the DTD file. The two important elements in this schema are <component> and <wire> elements in the see the DTD file.
The same connection that connects the AudioIn port of the chorus-resource component to the AudioOut port of the echo-resource component is now described in the setup.xml file as follows:
|
Full source code of this example can be found in the examples/corba/jtrs-sca directory of PocoCapsule installation.
In this scenario, the JTRS-SCA core framework component model is used. Namely:
SDR components are simply CORBA objects supporting the CF::Resource IDL interface.
Services (of type CF::Port) provided by these components are also CORBA objects and their references can be retrieved from the JTRS-SCA standardized CF::Resource::getPort(in string service_name) IDL getter method on these components.
These service object references can be injected to their user components through the CF::Port::connectPort(in Object service, in string connection_id) IDL setter method of these user components.
The component assembly model in this scenario is the JTRS-SCA software assembly descriptor (SAD) model as defined in the DTD file. Unlike JTRS-SCA SAD assembler implementations built from scratch with thousands lines of code, the implementation from PocoCapsule is no more than another domain specific modeling (DSM) schema that is built with merely few hundreds lines of code (mostly in the scahelper.C and the jtrs-sca-lite2poco.xsl). The same connection that connects the AudioIn uses-port of the chorus-resource component to the AudioOut provides-port of the echo-resource component is now described by the following <connectinterface> element in the sad.xml file as follows:
|
Notably, JTRS-SCA software assembly model does not define how SDR components are instantiated, activated, and registered to OMG Name Service. In the original SCARI version of this example, these provisioning setup were performed manually using CORBA API. In this example, the PocoCapsule core IoC model is used as a descriptive and reconfigurable solution (see the srv.xml).
Back to the PocoCapsule articles page
This page has been visited:
| free hit counter html code |