Software Defined Cognitive Radio - PowerPoint

Document Sample
Software Defined Cognitive Radio - PowerPoint Powered By Docstoc
					       SDR Software Architecture:
       Issues and Approaches

Dr. Jeffrey H. Reed
Dr. Max Robert
   Motivation and General Approach
       JTRS Program
       High Level Overview of Software Communication Architecture (SCA)
   Background Info.
       Quick Overview of Unified Modeling Language (UML)
       Problems with Traditional Linear Programming
   Approaches to Achieving the Ideal SDR
     Scalable and modular software structure
     Common interface/language independence
     Platform independence
     Common software architecture
     Standardized function calls
   The Software Communication Architecture (SCA)
     Software needs of an SDR
     SCA class structure
     Configuration management
     The SCA API
     Virginia Tech‟s Open Source SCA: OSSIE

Motivation and
General Approach
Software Architectures
   “The sheer ease with which we can produce a superficial image often leads
    to creative disaster.” Ansel Adams [1902-1984], American artist
        Traditionally has been neglected
        Poor architectural design is leads to significant inefficiencies
        Source of significant bugs and cost issues
   A good architectures provide multiple benefits
        Clear way to implement system: Software or hardware components
        Reuse --- modularity
        Quality control and testing
        Portability – one radio to another
        Upgradability
        Outsourcing/managing development
        Language independence
        More potential for Over-the-Air Programming
        Standardized interfaces
              Standard technology interface using middleware
              Standard semantic – API
              Software independent of hardware

Military Needs
   DoD faced with operational and logistical
     Need    to support advanced services
          Every component on the battlefield has an IP
     Need to simplify procurement and
          Reduce the number of disparate systems that
           need to be supported

   To resolve issues, DoD (through JPO)
    established the Joint Tactical Radio System
    (JTRS) program
     JTRS  is “designed to provide a flexible new
      approach to meet diverse warfighter
      communications needs through software
      programmable radio technology”
   At the core of the JTRS program are the
    Software Communications Architecture (SCA)

SCA (Software Communication Architecture)
   Supported and mandated by Joint Tactical Radio System (JTRS)
   Based on CORBA & POSIX, but can bypass CORBA
   NOT an “implementation architecture”
        Minimum set of mandatory requirements
        Encourage innovation and protect proprietary technology
   Targeted at (embedded) software radio applications
   Applicable outside JTRS and SDR
   Stable, with user base in JTRS program and SDR
   SCA/ Object Management Group (OMG)
        JTRS effort to convert SCA into a commercial standard by recasting it as an
         OMG standard like CORBA, UML, etc.
        May become new mandate for future procurements (SCA 3.x?)
        May be more broadly acceptable outside JTRS and outside DoD
   Expanding to support DSPs and FPGAs…

SCA Goals
   Specs for an open distributed-component
   Encapsulate components and capabilities
   Define common interfaces
     Load
     Configure
     Monitor
     Control
   Define services and service interfaces
     Common        services across platforms to improve

SCA Has a Scalable and
Modular Software Structure
   Component-based Architecture based on Object-
    Oriented Programming (OOP)
   Components-based programming structure
       Not logic-based like linear programming
   “objects” declared in software like variables
       Program is based on modifying the attributes of these objects
       Program execution is based on the transaction between these
   OOP better suited to mimic the functionality of a physical
       Well suited for event driven processing
   Blur the distinction between software and hardware
CORBA can Serve an Important
Role in the SCA
   Common Object Request Broker Architecture
   Used to tie-in different objects together
   Provides an architecture-independent
     Objects running on different devices “seem” to the
      developer to be running in the same environment
     Makes it easier for a program running on one device
      to execute functionality on a separate device
   Common Object Request Broker
     ORB     (Object Request Broker)
          Independent piece of software that performs data
           management between two separate objects

     *CORBA is far more complex that just this – more on this later   11
Software Communications
Architecture (SCA) -- A Preview
    Processor-centric
     structure                          Non-secure   Secure
        Standardized interface for
             Seamless handling of HW
              and SW
    Open-source
        OSSIE
             C++ by MPRG
        SCARI
             Java by Communications
              Research Centre

Is the SCA Suitable for Commercial
   Maybe
     No
          Current version is GPP-centric, hence heavy
     Yes
        Basic architectural principles are sound
               Unlikely anyone will come up with anything better
          SCA 3.0 is a first step in dealing with GPP-centric
           communications within the radio
          Significant momentum ($$$ and time) within defense-
           related industry
          Being adopted by several other nations‟ defense

A Side Issue: Java for SDR
   Difficult history with wireless
       Requires Java Virtual Machine (JVM)
          JVM leads to significant inefficiencies

   Java well suited to some aspects of wireless
       Interface design
           Customized and flexible interfaces

   Two technologies that may be relevant
       Realtime Java
          Provides guarantees for execution time
                Several implementations available today
       JavaBeans
          Component-based Java
                Can easily plug into architecture


1. Problems with traditional linear programming.
2. Unified Modeling Language to help with the introduction of
   object oriented programming (OOP).
Programming for a Radio
   Traditional software
     Linear code
        Instruction-based
           main() {
             float     *RF_stream;     // pointer to data
             HANDLE    ADC_1;          // handle to device
     Functionality dictates what/how software is written
        A developer is likely to be asked to write a convolutional
         encoder with some arbitrary, specific and custom function I/O

Problems with Linear Programming
   Not easily reusable
     Extremely    difficult to avoid “sloppy” code
   No clear boundaries for code
     Easy  to write “global” functionality or variables
     Difficult to integrate multiple languages into a single
          Integrating C++ on DSP and VHDL on FPGA not a trivial
   Difficult to upgrade
     New functionality not readily integrated
        More issues related to “sloppy” code

Linear Programming and the
Wireless Industry
   The issues created by linear software (logic/action-
    oriented) generally trivial for small-scale (or closed)
       Small-scale: universities, small applications
       Closed: embedded software for toy cars
   Problems arise in large-scale users/developers
       Managing Development
            Large number of small teams working in parallel
            Procurement (purchasing) becomes very inefficient
            Each device is supported by a different software suite
       Maintenance/upgrade is expensive
            Difficult to integrate multiple vendors‟ wares
            May tie user/developer to a fixed supply chain (monopoly)
            Validation: Star Wars example

Unified Modeling Language (UML)
can Be Used to Understand OOP
  • A language for specifying, visualizing,
  constructing, and documenting software
  systems, particularly object oriented
  programming (OOP)
  • Commonly Used To Document / Specify
  Software Radio Designs
  • Can also be used to model any system that
  can be abstracted into objects

  • Can be viewed as text or graphics
      What is UML used for?
SCA,CORBA and related specs, and waveforms are all described in UML.

   Provides a common language for functional
     Naturallanguage is not precise enough
     Code is too detailed

   Highlight important details
     Provide    overall view of a system

   Logical decomposition of large projects
     Focus  on details without losing overall goals
     Separate implementation task into parts
     Build individually testable components                       20
How to read UML - Class
   Name                       Class Name
  Attributes         attribute : data_type
 Compartment         attribute : data_type = init_value
                     … (continuation)
  Operations         operation
 Compartment         operation(arg_list) : result_type
   (Functions)       …
 Stereotype – A logical grouping of similar
 modeling elements                                       21
UML Class Representation
  Optional visibility icons
                         Attributes Operations


  Representation option             FIR
  Only the name compartment
Example Class Diagram

        Rtn_type retrieve_output()
UML Indicating
Class Relationships
 Association A Relationship Between Two
 Represented by a line in UML. Association
 can be explicitly written, or denoted

  Explicit Association Example
            employee     employer
   Person                           Company

UML Dependency Relationship

 Dependency A Directional Relationship
 Between Two Classes

 Shown by a dashed arrow
 Type of dependency usually indicated by a

      Class A                Class B

UML Multiplicity

 Multiplicity A Numerical Correspondence
 Between Objects, e.g. one-to-one or one-to-
 Can be indicated by stacking objects or
 explicitly written

           employee      employer
  Person                            Company

UML Explicit Multiplicity

  Explicitly Representing Multiplicity
  lower bound … upper bound
  Unbounded is denoted by an asterisk, „*‟.
  Discontinuities denoted by commas, e.g.
  0…4, 6…10
  unlabeled, a one-to-one relationship
                    1      3…*
         Polygon                   Point


 Used For Objects With Component Objects
 A “Has A” Or An “Is A Part Of” Relationship
 Three types of Aggregation
   Aggregation (Least Restrictive)
   Nesting (Most Restrictive)
 Aggregation Component is a part of
 aggregate object, but retains independence
         Club                   Person

 Composition Specific Component is “owned”
 by aggregate object, other types of objects
 may also have this type of component

     Person                    Heart



 Nesting Component object only has scope
 within the Aggregate Object i.e. only this
 type of aggregate can have this kind of

   Vertebrates                 Backbone

OOP Concept -Inheritance

 Inheritance One object (Child) extends the
  functionality of another object (Parent) by
  adding new characteristics and interfaces to
  the Parent‟s original characteristics and
  Describes an “is a” relationship.
                    Filter         (Parent)

              FIR            IIR   (Children)
Inheritance Concepts

 Inherited Visibility (Protected) - Variables
 or functions that can be used by elements
 internal to the object and by any children of
 the object but not by external objects

                       Attributes Operations

Abstract Class

 Abstract Class A class whose functionality Is
 only implemented through children
 Names of abstract classes typically written in
  Instantiation Implements all functions of
  parent, but does not inherit relationships.

   Specialization            Generalization

     Instance                   Abstract
Key CORBA Points
   CORBA middleware is required by SCA
   Reduced development cost
     Support  additional platforms with one version of code
     ORB handles object communication details
     Integration of new and legacy components

   Increased functionality in heterogeneous
        Distributed object deployment
        Networking is transparent to client/server

Approaches to
Achieving the Ideal
Achieving the Ideal SDR: What
do we need to do?
 Scalable and modular software structure
 Common interface/language independence
 Platform independence
 Common software architecture
 Standardized function calls

Scalable and Modular Software
   Object-Oriented Programming (OOP)
   Component-based programming structure
     Not   logic-based like linear programming
   “objects” declared in software like variables
     Program    is based on modifying the attributes of these
     Program execution is based on the transaction
      between these objects
   OOP better suited to mimic the functionality of a
    physical radio
     Well   suited for event driven processing

OOP Programming Concepts
 An object consists of internal attributes
  (variables) and methods (functions) which
  form characteristics and interfaces (I/O)
 Encapsulation
     Isolationof functionality from outside
     Eases multiparty development
     Allows the object to change implementation
      details while maintaining the same interface
     Protects proprietary information

Overview of Object Oriented
Programming (OOP) Concepts
 Object - A (meaningful) abstraction of some
 thing consisting of internal characteristics
 and interfaces
  Interface   Object Characteristic   Interface

  Interface   Characteristic          Interface
 Characteristics define how inputs to the object
 affect the output or state of the object
 Interfaces provide methods for inputting and
 retrieving information from the object            39
Example object – FIR Filter

 x[n]     FIR Filter        y[n]
        w[0]         h0

        w[1]                 Input New Sample (x[n])
                             Fetch Current Output (y[n])
        w[N-2]               Characteristics

                     hN-1    h[N] - Constant
                             w[N] - Variable
                                            - Function
                             Update w - Function
Classes – Big Picture
•   Object-oriented thinking begins with the
    definition of a class often defined as:
    – template
    – generalized description
    – pattern
    – “blueprint” ... describing a collection of
     similar items
•   A superclass is a collection of classes
•   Once a class of items is defined, a
    specific instance of the class can be
    defined                                        41
OOP Concept - Visibility

 Visibility – The scope of a variable or
 Public – Variables or functions that can be
 used by elements internal and external to the

 Private – Variables or functions that can only
 be used by elements internal to the object

OOP Visibility Example

   Private   update_w(x)
   Public    Rtn_type retrieve_output()

Component-Based Programming
   Can be considered a way
    of implementing object-
    oriented programming
   Base way of thinking for
    using most architectures
       Provides uniform way of
        describing interfaces and
            Can easily map to classes
             and objects

   It is possible to derive a class from a parent
    A  derived class inherits the methods and attributes of
      the parent class
   Provides a good way of maintaining a stable set
    of common methods and attributes between
    related classes

Achieving the Ideal SDR: What
do we need to do?
 Scalable and modular software structure
 Common interface/language independence
 Platform independence
 Common software architecture
 Standardized function calls

Common Interface/language
   Interface between objects in the same language
    is trivial
         Object demodulator, method inStream is executed with
          argument provided by object LNA, method outStream
   Interface between different languages difficult
     Multi-language     platforms very likely
          C/C++ for DSP
          VHDL for FPGA
          Ada for time-sensitive systems

 Ironically, language independence is
  achieved through the selection of a
  common language
 Interface language
     Provides      a common way to describe an
         Common name for data structures and native
              Native types: float, long, short, …

   Middleware
    A layer of software that provides a certain
     level of translation between different pieces of
       Database middleware provides a functionality
       E-commerce middleware provides transactional
        security guarantees
       SDR middleware provides a common interface
        language (among other important things)

   Common Object Request Broker
     ORB     (Object Request Broker)
          Independent piece of software that performs data
           management between two separate objects

     *CORBA is far more complex than just this – more on this later   50
   Interface Definition Language
     Provides  a standardized way to describe object
   Usage:
     IDL  description created for every method whose
      interface is to be described
     IDL “compiler” used to generate source code in the
      same language as the target function
          Generated code designed to interface with ORB
     New   IDL-generated source code file compiled along
      with the rest of the project

IDL Usage: Example Create a RS

     IDL compiler
IDL Code Example: Taken from
SCA 2.2
interface FileSystem { /* object name */

     /* <type> variable_name */
     const string SIZE=``SIZE’’;

     /* exception description */
     exception UnknownFileSystemProperties {
          Properties invalidProperties;

     /* <return type> method_name ( argument list ) */
     File create (
          in string fileName
     raises (InvalidFileName, FileException);
     Note: FileSystem is an object in the SCA            53
IDL Ramifications
   IDL “compiler” is ORB-specific and
     Different
              IDL compiler needed for every
      language that is to be supported
     Data exchange protocol between object and
      ORB is not standardized
          Different ORB will require whole different IDL

Example of IDL Compiler (1/6)
   Consider ACE TAO IDL Compiler,
     C:\tao_idl   –u : print input flag options
   Example IDL code: messenger.idl
     interface Messenger {
        boolean send_message (
        in string user_name,
        in string subject,
        inout string message); };

Example of IDL Compiler (2/6)
   Compile example IDL file using TAO_IDL
       C:\tao_id -GI messenger.idl
   This will generate following C++ codes
       messengerC.cpp and messengerC.h
       messengerS.cpp and messengerS.h
       messengerI.cpp and messengerI.h (due to –GI option)
   C, S and I imply Client, Server and Implementation
   We have to make two extra files for program entry point.
    I.e., messengerClinet.cpp and messengerServer.cpp
    having main() function.

Example of IDL Compiler (3/6)
   We just focus on messageI.cpp for server
    and messageClient.cpp for client

                    user_name, subject
                      (“in” direction)
        Server                               Client
                 Message is “How are you?”
                     Message is “OK”
                     (“inout” direction)

Example of IDL Compiler (4/6)
   Server actual code for messengerI.cpp
    (red marked codes)
     CORBA::Boolean MessengerI::send_message(
     const char* user_name,
     const char* subject,
     char*& message) ACE_THROW_SPEC ((CORBA::SystemException))
       //Display user_name provided by Client
         cout << "Message from: " << user_name << endl;
      //Display subject provided by Cliecnt
         cout << "Subject: " << subject << endl;
      //Display subject provided by Cliecnt
         cout << "Message: " << message << endl;
         CORBA::string_free(message); //Typical method to free memory in CORBA
      //Send OK message to the Client
         message = CORBA::string_dup(“OK");
     return 1;
Example of IDL Compiler (5/6)
   Client actual code for
    messengerClient.cpp inside main()
    (red colored codes)
    CORBA::String_var message = CORBA::string_dup(“How are you?");
    messenger->send_message(“Kim", “SDR", message.inout());

   Results :

Example of IDL Compiler (6/6)
   Summary of IDL
    compile example
     IDL  defines the
      interface between
      server and client
     As we see, client stub
      and server skeleton
      are generated through
      IDL compiler
     The transport between
      client and server is

Polymorphism through IDL and

Achieving the Ideal SDR: What
do we need to do?
 Scalable and modular software structure
 Common interface/Language
 Platform independence
 Common software architecture
 Standardized function calls

Platform Independence
   An SDR is likely to require the support of
    multiple devices
     DSP, FPGA, general-purpose processor,
      reconfigurable architectures
   Software needs to support the transfer of
    information between different platforms
     i.e.:   FPGA→DSP

   Middleware can resolve
    platform independence
     Approach    issue
      as a distributed
   CORBA is the usual
    middleware solution

    Software Communications
    Architecture (SCA)
   Processor-centric structure                                                     Non-CORBA
                                                               Security              (Legacy)
       Standardized interface for                             Boundary
                                                  Non-secure              Secure
        components                                            Black Red                     CORBA
                                              Software                       Software       Adapter
            Seamless handling of HW
             and SW                                              IDL
                                                               CORBA                 Objects
   Open-source                         Adapter
    implementations available                                                       File
       OSSIE                     Non-CORBA


            C++ by MPRG           (Legacy)
       SCARI
            Java by Communications                             Trans.
             Research Centre

CORBA Support
   Two ways for platform independence to be
     Different  IDL compilers used to support
      different languages
          More than likely supporting different platforms
     Two    platforms cannot always share an ORB
          Inter-ORB communications used to maintain
           platform transparency

CORBA continued
   In this case CORBA is used as an illustrative
     Other middleware is capable of supporting the same
      type of functionality
          Jini (design best for JAVA), .NET, DCOM, ICEBERG (IP), …
   Two key points about CORBA (and most other
     Consumes      disproportionately large amount of
     Designed to support a very large number of
          Far more complicated than needed by an SDR

Achieving the Ideal SDR: What
do we need to do?
 Scalable and modular software structure
 Common interface/Language
 Platform independence
 Common software architecture
 Standardized function calls

Common Software Architecture
   Common rationale for the software structure
   Standardized set of class names, methods,
    attributes, and relationships
     Providesa common framework for the
   Architecture generally defines
     Component/connector   vocabulary
     Topology
     Semantics

SDR Software Architecture
    Dataflow
        Control loops, batch sequential, pipes and filters
    Call-and-return
        Functional decomposition (classical), layered (OSI), client-server,
    Virtual Machines
        Interpreters
    Data-centered
        Transactional databases, (central shared data)-based
    Independent components
        Message- or event-based, interrupt-driven, SCA
    Note that a combination of architectures is possible (and

Multiple Problems Need to be
 Scalable and modular software structure
 Common interface/Language
 Platform independence
 Common software architecture
 Standardized function calls

Standardized Function Calls
   Standardized architecture does not specify
    functionality details
     Waveform      calls are specific to the application
          Modulation, FEC, application
          Can be a very large set of possible calls
     System Calls, e.g., operation systems and
   Standardized set of waveform
    operation/management calls makes the software
    far more portable

    Application Programming Interface
   Application Programming Interface
     Provides a set of standardized waveform calls or
      operations (semantics)
          i.e.: encode()
   Should not be confused with a library
     Library     holds code that actually performs the desired
          API describes the interface of this library
                Multiple implementations can share an API
   API will most likely not cover an exhaustive set
    of situations
     Severalcalls will most likely be implementation-
Example: Packet Transmission API
(from SCAv2.2)
   API describes
    specific names
    and types for
    the different
    aspects of a
       In this case,
        transmit packet

Summary: Desirable
Characteristics of the Architecture
 Scalable and modular software structure
 Common interface/language
 Platform independence
 Common software architecture
 Standardized function calls


Overview of the Specifications
 Introduction
 The role of the SCA
 SCA Classes
 Configuration

 SDR can be defined as one whose
  functionality is significantly implemented in
 More than just a radio with some software
     Generally   extended to include additional
       Reusable software
       Contains structure for the integration of disparate
        technologies from different developers

Contrast in Software Approaches
   Traditional software for mobile radios
     Embedded      software
          C, assembly, VHDL
     Rudimentary   or no operating system
     Relatively narrow scope of functionality
   Software Defined Radio (SDR) extends
    this scope
     Broaderfunctionality set
     Reusable code more valuable

Software for SDR
   Still relies heavily on more traditional
     Will still need to carefully manage cycle count
      in DSP
     Will still rely on tight timing tolerances for
   Software for SDR does not replace
    traditional approaches
     Instead,   it extends them into broader scope

Partitioning Software
   Can be largely split into two categories
     Functional        software
          All the software that performs the work
               Filters, FEC, framing, other
          Blends with the traditional development strategies
     Management            software
        Control software and hardware
        Is the principal concern of the SCA

Scope of SCA Discussion
   This tutorial covers aspects of the SCA
     Generaloverview
     Sample waveform design

   The SCA is relatively open-ended
     There  are a variety of ways of implementing
      different aspects of the specifications
          This tutorial covers one of the possible
           implementation paths

Starting Point
   You have some hardware

   And you want to run some waveforms
     GSM, IS-95, or some other technology that the
      hardware is powerful enough to support

What kind of software is needed?
   Something to manage hardware
     Configure       associated devices
          Set devices to known state
               i.e.: Make sure NCO is available and ready
     Initialize    cores
          Make sure programmable devices are ready
             Set memory pointers in DSP
             Set FPGA to known state

What kind of software is needed?
   Some standardized way of storing relevant
     More       than just short-term memory
          Store configuration files
          Store last state of the machine
          Store user-defined attributes
                Identity
                Permissions
          Store functional software
     Should      be able to map any kind of storage device to
          Dynamic RAM, hard drive, FLASH, other

What kind of software is needed?
   Some way of structuring the waveforms
     Standardized   way of structuring “applications”
      so that the radio can “run” them
          In a Windows machine, these are .exe files
     It
       has to be generic enough for it to fit well
      with machines other than GPPs
          Needs to be able to interface with functional

What kind of software is needed?
   Something to actually “run” waveforms
     Install
           functional software in appropriate core
     Generate a start event
   Something to keep track of what is
    available and what can and cannot be
     Ideally,   this will bind the whole thing together

     Summary of Features Needed
 Device Manager
                            Application Factory
   Keep track
   of HW in
                              collection of
   the system
                              resources to
FileSystem Manager            waveform
   Store working
   environment, bit            Application
   images,              Manage waveform operation
   properties, etc.
     Devices                  Capabilities e.g.,
  Boot up and                 Start and stop,
  maintain HW                 test, describe

 Domain Manager
   Keep track of
                           Connections between
   what‟s there
   (installed)                                     88
   Provides a framework for the establishment,
    maintenance, and tear-down of waveforms
     SCA  provides the “glue” that holds a radio system
     The SCA is intended to resolve the waveform
      portability and maintenance needs
   Conceptually, SCA is fundamentally simple
     Complexity   arises from large number of details

The SCA Specifies
    A standard set of interfaces for logical devices
       Device,    LoadableDevice, ExecutableDevice
    A common file system interface and services
    A logging and event service
    A common interface protocol (CORBA)
    A standard method of locating components
     (Naming Service)
    A standard set of interfaces
       Control,   configuration, monitor, installation

    Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
The SCA Specifies (cont.)
   A method for connecting components
     Usersports,   providesports
   A set of components that organizes, manages,
    and controls applications and devices
     DomainManager, Application Factory, Device
   A standard method for specifying components,
    resources, and connections to make a waveform
     Accomplished    using eXtensible Markup Language
      (XML) files
   A high-level guide for API development and
    security management

Operating System
   SCA assumes that there is an underlying
    operating system (OS)
     OS    interface is POSIX compliant
          PSE-52
   Waveform will need limited access to OS
     Largely   confined to process management
        Threads
        Processes

SCA Version
 Most current version is 3.0
 SCA 3.0 is fundamentally like version 2.2
  with some additional HW considerations
     HAL-C
          Hardware Abstraction Layer Connectivity
   SCA 3.1 has been in review and
    preliminary versions are available
     Also   an extension of version 2.2
          Introduces the concept of Containers

Ramifications of using CORBA
   Ability to connect between components is
    limited by implementation of CORBA
     If
       CORBA is not implemented for platform (like
      an FPGA), then a different approach is
          Place where CORBA resides (GPP or maybe DSP)
           must act as a driver
   Direct ramification is a star architecture for
    each node‟s software

Software Layout
   GPP provides a software interface for the
    management of SW and HW components

Data Flow
   When leveraging GPP, data flow is through the
    drivers, OS, and middleware in the GPP

   Clearly, GPP-centric creates a significant
    bottleneck in the system
     High-rate    systems cannot be supported
   SCA 3.0 is intended to alleviate these
     Interfaces   established directly between HW
          GPP-based software used to configure the
           component but not manage the data flow
     Open-ended      interface

SCA 3.0 Interface
   Hardware Abstraction Layer Connectivity (HAL-C) used
    to manage these links
       Four basic calls
            Configure, send, receive, non-blocked receive
       HAL as described can support DSP-based software
            Leaves links established with FPGAs not well defined
            Significant effort required to bring FPGAs into fold
                  Community recognizes these devices as critical for system success
   SCA 3.1 will introduce the concept of Containers
       Designed to better deal with this problem
            The technology is not yet mature
                  Several iterations are likely until an acceptable stable point is achieved

SCA 3.1 -- Proposed
   Containers intended to separate
    functionality from platform
     Provide functional interface
     Provide interface to hardware

   Scalable solution
     Connectivity   makes no assumptions about
          Number and layout of components on hardware

Container Example
   Container code for single component on

Container scalability
   Allow more than one functional block per
     Allows   for efficient inter-block link

Inter-HW Container
   Containers can be
    expanded beyond
    single piece of

Interfacing Containers to CORBA
   Additional software necessary to create
    interaction between CORBA environment
    and container
     Allow   for basic functionality
        Establish connection
        Marshal and transport data

     Integrate containers seamlessly into CORBA-
      type environment
          Ease development process

SCA Class Structure
The Core Framework Classes
   Conceptually, software layout is fairly simple
     Process  for management of data flow similar to that
      used in PC today
   Details for management of waveform go beyond
    basic concepts
     Significant
               infrastructure needed to perform basic
      waveform management
          Replicate most functionality of OS in a generic fashion
           that maintains compatibility
     Infrastructure   is the class structure defined in the SCA


Platform Independent and
Dependent Elements
  Platform                     Platform
Independent                   Dependent

  Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
    Dependent Elements and Devices
Device – Base interface providing a common interface to a hardware device.
LoadableDevice – Extends the device interface for devices on which a code image may be loaded.
ExecutableDevice – Extends LoadableDevice interface to those devices that load and execute a
AggregateDevice – Provides interfaces for supporting a collection of Devices as a logical unit.
DeviceManager – Provides management functions methods for one or more Logical Devices.



       Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
Hardware that may or may not be
   From a control standpoint, this hardware
    can only be configured (partially or in full)
    for specific use
     NCO    set to specific value
     Filter tap values
     A/D converter allocated for a waveform

   Device class used to support this

Device Class
   Inherits from Resource class
     Can    be considered a component
          Conceptually blur the line between hardware and
   Two member methods
     allocateCapacity()
          Set aside a specific HW capacity
               Used by ApplicationFactory in create()
     deallocateCapacity()
          Make specific HW capacity available for use

Hardware onto which an image can
be loaded
   From a control standpoint, this type of
    hardware extends the needs of the Device
     Still
          has to allocate and deallocate capacity
     Extension relates to its ability to load and
      unload images
   LoadableDevice class supports this

LoadableDevice Class
   Inherits from Device Class
     Leverages     all capabilities associated with Device
   Three member methods
     load()
          Load a specific file onto HW
     unload()
          Unload a specific file from HW
     isFileLoaded()
          Check to see if a specific file has been loaded onto the HW

Hardware that can execute programs
   Extends LoadableDevice needs and
     Must      be able to execute loaded images
   ExecutableDevice supports this
     Two    member methods
          execute()
               Run a specific program (returns a PID)
          terminate()
               Terminate a specific PID

Beyond simple hardware
   Aggregate Device is a class that
    represents a collection of Devices
     i.e.:
         a board with many cores that the
      developer wants to treat like a single Device
     Can simplify the deployment of hardware
          Reduce the relative complexity of the configuration

 Its basic role is to manage Devices
 However, role is more subtle
     Creates    and maintains a File System
          Platform-specific storage
     Installs   and maintain associated hardware
   Once DeviceManager has processed the
    associated devices appropriately, it
    informs the DomainManager that its work
    is complete

 Domain Management Elements
                      Application – Base interface for a collection of software
                      implementing a waveform.
                      ApplicationFactory – Provides interfaces to instantiate (load and
                      initialize) a waveform.
  Domain              DomainManager – Provides overall management functionality. Performs
Management            application installation. And receives device registration requests.

    Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
DeviceManager and DomainManager

 DeviceManager mounts its File System (or
  File Manager) onto the DomainManager
  File Manager
 DeviceManager associates all of its
  Devices with the DomainManager
 User has access to HW under
  DeviceManager control through the

Domain Manager
   The central core of the SCA system
     Maintains       a comprehensive list
        All possible waveforms
        All associated HW
               All capabilities of the associated HW
          All installed waveforms
     Maintains       a File Manager
          The root of the system-wide File System
     Significant      number of member methods and

Domain Manager Interface
   Three general categories
     Human    Computer Interface (HCI)
        Configure domain

        Get domain capabilities

        Initiate maintenance

     Registration
        Register/unregister Device Managers, Devices,
         Services, and Applications
     CF administration
        Access interfaces of registered Devices Managers
         and File Managers

User Interaction
   Ironically, Domain Manager does not
    control interfacing with the user
     Instead, provides methods for an external
      user interface to call
   Flexibility well suited for deployment
     Variety      of usage models
          Handheld, embedded, aircraft, ships, ground
               Single user interface would not be appropriate

Starting Domain Manager
   Establishes all necessary part of the system
     Naming     context
          For associating CORBA object references to a human
           readable string
     File   Manager
          Central mounting point for all associated File Systems
     Event    Channels
          To keep track of changes and inform different pieces of
           system updates

Application Factory
   Deployment of a waveform has two steps
     Create      or assemble the waveform
        Make sure all the pieces are available (or create
         them when not)
        Connect all the pieces

   The ApplicationFactory class is used to
    assemble a waveform
     Single     member method
          create()
               Deceptively complex call

Application Factory
   Class that is used to create the waveform
      Reads XML
      Makes sure that required HW can run needed Resources
            Executes waveform software on required hardware (not proxy)
      Creates whatever Resources are needed (that have not already been
      Connects all Ports
      Informs any objects listening that it has successfully created waveform
      Return Application object

 An instance of this class is returned by the
  Application Factory after successful
  creation of the waveform
 This is the handle to the waveform
     Contains      information on the waveform
         Application-specific information
     Allows     the user to terminate the waveform
         Waveform termination is relatively complex
              Reverse process of create() method in

Application Usage
   Provides convenient entry point into
     Single    handle for runtime commands
          Start and stop
     Single    handle for releaseObject
          Waveform-level termination
             Calls all dependent releaseObject methods in associated
             This is an example of where releaseObject is more than
              just a destructor

Application Ramifications
   Once a waveform is deployed, only handle
    to waveform is Application instance
     From  a framework standpoint, loss of
      Application instance equivalent to loss of
        Loss of pointer results in memory leak
        Framework equivalent is loss of ability to
         deallocate capacities in hardware
              Requires reboot of environment

ApplicationFactory Example: GSM Vocoder

2 – Check with Domain Manager
   •   Makes sure that the devices required are available with the
       required capacity
   •   Defined by SAD (software assembly descriptor)
3 – Allocate capacity (needs) in required devices
4,5 – Load & execute application components
     (unconnected waveform parts)
6 – Get name reference to installed components
7:13 – Through ResourceFactory, create all the appropriate
     Resource(s) and connect them through the appropriate
     Port(s) (loop through these steps for all the resources)
14 – Log the installation
15 – inform Domain Manager that installation is complete

      GSM Speech Coder Application
      Factory Example
1.      ApplicationFactory is evolked
2.      (2) Check with Domain Manager to make sure that the C54 has sufficient
        capacity left over to install vocoder.
3.      Allocate capacity in C54
4.      Load vocoder code into C54.
5.      Run code (it will have to wait to do anything until it is connected).
6.      Get name reference : GSMVoCoder1 from naming service for resource
        (name for vocoder).
7-9.    Ask ResourceFactory to create vocoder resource: GSMVoCoder1.
10-11   Initialize and configure GSMVoCoder1.
12.     Connect GSMVoCoder1 to baseband I/O and speaker/microphone
13.     Configure GSMVoCoder1 to class of vocoder that you‟re interested in.
        Loop through steps 7:13 for all the resources to complete the radio.
14.     inform Log that configuration performed.
15.     inform DomainManager that configuration GSMVoCoder1 is complete on
        given devices (so that it knows that the capacity in those devices is
   File Services Interface Elements
                    File – Provides essential file operations interface. Abstracts interface away
File Services       from underlying platform specifics.
                    FileSystem – Provides common file system interfaces to creates, copy,
                    delete, etc., files.
                    FileManager – Provides interfaces and management of multiple file systems.

      Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
File System/File Manager/File
   File is the basic storage entity
     Just    like in an OS
   A File Manager is a File System of File Systems
     Provides   a scalable structure for the creation of a
      unified file system
   A File System is generally limited to one piece of
     i.e.:
          A hard drive, a block of memory
     The File Manager can then be used to create an
      amalgamation of these File Systems

File System Usage
   A File System is generally associated with a
    single piece of hardware or single operating
     Provides common interface for the handling of
      storage on that specific medium
   Hybrid hardware best served through separate
    File Systems
     All
        File Systems then collected onto a single File
           File Manager behaves as File System of File Systems
     Single    interface and structure for all storage

    Basic Application Interfaces
                PropertySet – Provides the capability to query and configure properties for components/resources.
   Base         LifeCycle – Provides common initialization and cleanup interfaces
Application     TestableObject – Provides a common interface for running diagnostics
 Interfaces     PortSupplier – Provides interfaces for obtaining references to ports
                Port – Core mechanism for connecting components together
                Resource – Common high-level start and stop interface for any entity within an SCA radio
                ResourceFactory – Provides a mechanism for constructing multiple resources

       Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
   All components are derived from the
    Resource parent class
     All
        other classes intended to support these
   A component is made up of one or more
     Forsimple applications, there is only one
      Resource per component

Resource Factory
   This is a class that is not necessarily used
     Performs      supporting functionality
   Its task is to create Resources
     Single    member method
          createResource()
               Can be used to deploy components with little or no knowledge
                about the host hardware
               A more traditional way of creating Resources is to request the
                hardware that hosts the running code to spawn the Resource
                   More details on this later

   Port is “used” by Resource
     Resource   will most likely create an instance of a Port
      within the Resource
   Port contains two member methods
     connectPort()
        This is the method that narrows the reference to the object to
         which data is pushed
     disconnectPort()
        Remove CORBA reference

     Note that Port is a component-specific

Test Component
   Parent class TestableObject provides a
    standardized interface to perform
    Resource testing
     Single      member method
          runTest()
               Component-specific functionality
     Note that TestableObject is an inherent part of
      the architecture
          Deployed software can easily include self-test

Component/Resource Mapping
   A Component is made up of at least one

   Component is defined by its interfaces and
     Particular content of Component       largely irrelevant
        Allows for Component scalability

Component Scalability
   Flexible nature of Component allows creation of
    waveform of waveforms

Component Needs
   Needs of Components can be largely parceled
    into four basic categories
     Create or destroy Component
     Connect to other Components
     Configure Component
     Test Component

   Beyond these basic needs is functionality
     Waveformspecific rather than intrinsic aspect of

Create or Destroy Component
   Creation/destruction supported by LifeCycle
    parent class
     Two     member methods
          initialize()
                Perform work needed to bring Resource to well-defined
                 state for functioning
                    Component-specific functionality
          releaseObject()
                Bring Resource to well-defined state for termination
     Not the same as the constructor or destructor
        LifeCycle calls are handles for the framework to
         manage object‟s lifetime

Connect to other Components
   Connection to other Components
    performed through the PortSupplier parent
     Single      member method
          getPort
               Provides a handle to the Resource‟s Port(s)
          Does not connect to other Resources
             This set of methods provide the structure to exchange
              the CORBA pointers
             Connection call performed on the actual Port

Configure Component
   Configuration supported through the PropertySet
    parent class
     Manages unique properties of Resource
     Four member methods
          configure()
               Set a Resource‟s property value(s)
          query()
               Get a vector of properties from Resource
          validate()
               Make sure that a particular property exists
          getProperty()
               Get a specific property‟s value

Abstractions and Reality
 Abstractions serve well for the creation of
  mental models, even roadmaps
 However, to solidify concepts, it is
  important to include concrete examples
     This is the last part of the lecture and is split
     into three sections
       How to build a node booter and a waveform
       OSSIE

       Modifying waveforms in Linux (practical)

Implementing Systems
   Classes and components were presented in this
    tutorial in stand-alone form
     In reality, a shell is needed for these program
     In C++, this shell is a separate thread of execution
          This thread can be either a separate executable or a thread
           of execution within a single executable
                For the sake of clarity, the shell will be a separate executable
          Each piece (node booter or component) has the structure
           seen in the following slide

Sample Shell Around Component
#include "DecodeData.h              // this header includes the prototype and other
                                    // relevant headers

int main( int argc, char** argv )

//    create relevant object
     DecodeData_i *decoder;
     decoder=new DecodeData_i;
     decoder->start_running();      // this is not part of the SCA
                                    // it is a flag to exit the do while loop

     ACE_Time_Value orb_time_out = 1;           // timeout is included to allow non-CORBA
                                                // events
        ORB_WRAP::orb->perform_work(orb_time_out);          // service CORBA requests
     } while( decoder->is_running() );

     delete decoder;

     return 0;

Component Code
   Beyond the shell, the component needs to inherit from CF‟s
    Resource, so the declaration of the class should include

class DecodeData_i :
   public virtual POA_OSSIE::DecodeData,
   public Resource_impl

   Note the inheritance from POA_OSSIE::DecodeData – that denotes
    the inheritance from the IDL-generated code
        All the interfaces declared in the IDL are generated as virtual and hence
         must be populated
   Also, the component will need some code that will change little
    between implementations
        Constructor
        Destructor

Additional Modifications
   Some minor modifications to the component are
    also necessary for basic housekeeping
     Start/stop
        Start and Stop commands are received from the Assembly
         Controller and are used to start or stop the chain of CORBA
               The location and approach to modifying these methods are
     Release Object
        This is the termination call, which requires the program to
         terminate the main() do-while loop
               In this example, the value of currently_running would be

Final Modifications to Component
   Beyond these generic modifications, the only aspect left is
   A couple of key aspects to remember:
        You will probably have to service more than just CORBA events
             i.e.: A/D buffer full, user input
             If following a structure like that shown here, the equivalent of perform_work
              in the do-while loop of main() should not be blocking
        You will have to extend the Resource class to perform additional
             Three files need to be modified: the C++ file with the functional code, the
              header file with the prototypes, and the IDL file describing the interfaces
                   You must include the IDL-generated files in the project or makefile
        Editing your own XML by hand using a simple editor is error-prone –
         most mistakes will be derived from this step

Class Summary
   The classes defined so far are the extent of the SCA
    specifications for classes
       Several details concerning functionality are not covered
   However, several characteristics become apparent
       The classes support:
            Integration of external hardware
            Machine state information
            Create/destroy applications from user input
            Integral file system
       The SCA classes basically supports all the functionality that an
        OS does with the exception of task and thread management

SCA Class
Management and
Assembly Controller
   There is a special component whose sole
    job is to provide a start/stop point of entry
    into the Waveform, the Assembly
     This
         is just a Resource that knows which
      components it needs to tell to start and stop
          One of the XML files (_SAD.xml) describes the
           Assembly Controller
               XML files are described in a later section

Node Booters
   Class behavior has been described in
    fairly abstract ways
     Classes   interacting with other classes or
      installing different HW or SW
   In concrete terms, each of these classes
    resides in some executable code
     Binariesthat the operating system or local
      machine can run
     These binaries are Node Booters

Node Booter Content
   Two basic kinds of Node Booter
     Domain Node Booter
        Contains an instance of the DomainManager
        Is likely to contain an instance of a DeviceManager
               The host computer may contain processing hardware that the
                developer wants to leverage
     Device Node Booter
        The startup program for all other stand-alone machines that
         must be associated with the DomainManager
               Contains one instance of the DeviceManager
   Once these programs are started, the basic SCA
    configuration management software is installed

DomainManager Node Booter Bootup

   Essentially a system bootup
   Create a Naming Context
     Allows for the exchange of CORBA object
      references (pointers) through the use of human-
      readable names
   Creates Main File System
   Re-establishes previous configuration

Device Node Booter Bootup
    The DeviceManager is the main class
     instantiated in this booter
      Installs all relevant HW and SW
      Creates a File System
      Informs the Domain Manager of its existence and
       mounts its File System to the global file manager
    Other associated classes include ones that deal
     with files and devices

Overall Bootup Sequence
   Bootup sequence well defined
     Once  system has booted up, user can request the
      creation of Applications (waveforms)

                     Application Factory Process         157
Building Node Booters (1/2)
   At least one Node Booter is necessary, the
    Domain Node Booter
     The Domain Node Booter is also an executable that
      contains a do-while loop for servicing CORBA events
          The primary difference is that instantiates a DomainManager
                In the case of DomainManager, you will probably have to
                 create a child class that gives you access to certain protected
                 attributes of the DomainManager
          The do-while loop of node booters will most likely need some
           sort of user interface
                This user interface allows for the smooth termination of the
                 booter and also allows the launching and termination of

Building Node Booters (2/2)
   Additional machines, such as PCs, will
    require additional node booters
    A   rule of thumb for node booters is that if it
      requires a different IP address, it should have
      its own node booter
   Additional node booters rely on the
    DeviceManager for control
     Ingeneral, the same rules apply to additional
      node booters as to the Domain Node Booter

Sample Deployment
                UI – User Interface
                Red is data
                Black like is framework control

   Classes describe the reaction to an event
     Boot-up
     User    input
     Error

   Information concerning the reaction to events is
    implied but not necessarily explicitly described
     Allconfiguration information in the system is
      contained within a series of XML (eXtensible Markup
      Language) files

   eXtensible Markup Language
     Application
                of the Standard Generalized
      Markup Language (SGML)
          HTML also has its roots in SGML
     Explicit
             structure for the description of
        Easy for humans to interpret
        Easy for machines to process

           Reference: Andre Bergjolz, “Extending Your Markup: An XML Tutorial”,
           IEEE Internet Computing, pp 74-79, August 2000                         162
XML Syntax -- a description
   Document contains two pieces
     Prolog
          Contains information such as version and
           structural information
     One   root element (may describe properties
      for a component)
          Elements can be nested
             Values associated elements
             Attributes can be attached to elements

          Information is attached to elements through their
Structural Information
   DTD
     Document   Type Definition
     Context-free grammar
          Describes what the document should look like
                List elements that need to be in the document
                List of attributes for each element
                    <ELEMENT CAR (DRIVER+,MAKE,YEAR?)>
          Wildcard for elements and attributes can be used to signify
           additional aspects
                Optional elements or attributes - ?
                Variable length lists - +
     SCA    configuration files will should have a DTD

   Elements are marked as tags
        <my_element>my_value</my_element>
        <my_element  />
     Attribute   values must be in quotes
          <my_element
     Comments      created by changing tag
          <!--my_element>my_value</my_element-->

    XML Example
<?xml version="1.0" encoding="UTF-8"?>                        Prolog
<!DOCTYPE properties SYSTEM "dtd/properties.dtd">             Comment
<properties>                                                  Element Name
   <description>These are the properties for the Channel</description> sub element
   <simple id="ARRAY_SIZE" type="short">
         <description>Size of the array buffer.</description>
         <kind kindtype="configure"/>
   </simple>                                                             2 sub element
   <simple id="VARIANCE" type="double">
         <description>Size of the array buffer.</description>
         <kind kindtype="configure"/>

XML Parser
   XML Parser
     Check  the syntax and grammar of XML
     Provide API to handle the information of XML
     There are several open programs of XML
      parser (e.g. Xerces XML Parser)

    XML Document                      Error Message

                    XML Parser

        DTD                         XML Document Tree

XML Files in the SCA
   Provide variety of information
     Description    of the layout of the system
          Necessary to bootup the appropriate HW and
     Description    of the waveforms
        Components making up Applications
        Component placement

        Component connections

        Names of appropriate pieces

        Location for relevant files

XML Relationships
   Different XML files describe different types of
    framework pieces

XML Usage
 Relationships between XML can be
  abstract and difficult to follow
 A more concrete way to look at it is with an
     Domain    management configuration file
         This example can be extended to the different
          types of configuration files

Domain Manager Configuration (1/2)

   The Domain Manager needs configuration
     There  are generally found in the root directory
      of the File Manager
   Four files are found, namely
     DomainManager_DMD.xml
          This file will contain information about the Domain
           and a link to the software descriptor, _SPD.xml

Domain Manager Configuration (2/2)
   DomainManager_SPD.xml
       Contains information about the software
            Compiler, operating system, target processor
       Also contains a pointer to the software component
        descriptor (_SCD.xml) and the property descriptor
   DomainManager_SCD.xml
       Contains a list of the interfaces making up the
   DomainManager_PRF.xml
       Contains the information that populates Property Set
            Recall that Resource, Domain Manager, and Device Manager
             all inherit from Property Set

XML Pattern
   The same general pattern applies to all
    A  software package descriptor (_SPD.xml)
      describes aspects of the piece of software
      and will hold pointers to the software
      component descriptor (_SCD.xml) and
      property descriptor (_PRF.xml)

XML Starting Points
    In the starting point resides the uniqueness of the
     different configuration files
        The starting point for the Domain Manager is the
         Domain Manager Descriptor (_DMD.xml), as seen in the
             The DMD points to a SPD
        The starting point for the Device Manager is the Device
         Manager Configuration Descriptor (_DCD.xml)
             The DCD points to both an SPD and a DPD
                   The DPD has information on the general class of hardware
        The starting point for a waveform is the Software
         Assembly Descriptor (_SAD.xml)
             The SAD points to the SPD for all the components making
              up the waveform and all the connections necessary for the

SCA Application
Program Interfaces
Interface Description
   CORBA, IDL, and HAL cover (most) of the
    mechanics of connecting components
   Technology falls short of establishing the
    semantics for the connection
     Common     naming guarantees that the correct method
      (function) is called on the relevant component
     Increase portability

   API (Application Programming Interface) needed
    to achieve this level of portability

   Multiple APIs specified
     Generic  Packet
     Physical Real Time
     Physical Non-Real Time
     Medium Access Control (MAC)
     Logical Link Control (LLC)
     I/O
     Network
     Security
   APIs defined as building blocks
     Allows   the APIs to be scalable
          Reduce the likelihood that anyone “re-invents the wheel”

API Groups
   Two distinct groups
     Real-time API
        Describe the exchange of data between components
               Data and real-time control
          These describe connections between components
     Non-real-time API
        Describe the exchange of configuration information between
               Non-real-time control
               Setup and initialization
          These do not necessarily describe the connection between

Relationship Example

    General API Usage

   Generally intended
    as a description of
    interface between
    different layers of the
    OSI protocol stack

Extension of API
        Specifications contain a process for the
         extension of the API
    1.          Use existing API
    2.          Inherit from existing API and extend services
    3.          Translate existing non-JTRS API to IDL
    4.          Create new API based on building blocks
          I.      Use existing building blocks
          II.     Extend existing building blocks
          III.    Generate new building blocks

 Service is the functionality provided by the
  component bound by the API
 Specifications provide a set of standard
  supported services
     Example:
       Antenna control (Tx, Rx)
       Radio mode

       Rx/Tx setup (i.e.: modulation, frequency)

       Forward Error Correction

Sample API
   An example of BB for the API is “pushPacket”
       Part of the Generic Packet API
       Is the standard way for information to be exchanged between
            Attributes
                  maxPayloadSize
                  minPayloadSize
                  numOfPriorityQueues
            Methods
                  pushPacket()
                  spaceAvailable()
                  enableFlowControlSignals()
                  enableEmptySignal()
                  setNumOfPriorityQueues()
   The API specifications are full of such building blocks

   Radio system is split into a red and a black piece
   Beyond separation, there are three general
    security pieces
     Limits on specific functionality for different parts of the
     Security interfaces (API)
          Attempt to standardize the way to access security features
                No attempt to standardize the security features themselves
                   i.e.: encryption, authentication
     Functional       specification

Limits on Functionality
   Aimed at making sure that the framework
    supports some security
     Equivalent    to some security features in Java
   Defined for three classes
     Application
     Application
     Domain Manager

   Security is charged with managing waveform
    security aspects of the SCA
     Port (socket) /data bus security
     Algorithm
     Certificate (identity)
     Cryptography
     Key management
     Policy management
     Data/system integrity
     Alarms/time/GPS

Security and Application
   Application releaseObject method limits
     Can  only disconnect Ports that are authorized by an
      authentication service
     Request removal of Ports‟ access setups from access
      control database
     Logs a Security_Alarm event when authorization is
      not granted by the authentication service
   Application‟s SPD implementation dependency
    propertyref indicates dependency on red or
    black device

Security and Application Factory
   Only components that are authorizes by the
    authentication service are created
   Only component Ports that are authorized by the
    authentication service are connected
   Port connections that need to be access-controlled are
    added to the access control database (by the create
       This operation is performed for all component port connection
        listed in the SAD
   A Security_Alarm event is logged when unable to
    connect Ports or create components due to
    authentication failure

Security and the Domain Manager
   Sends security information (controlled) during
    installation for black-side components accessed
    by red-side components
   Removes security-sensitive information from
    control/status mechanism during uninstall
   Device SPD determine whether it is a red or
    black device

Security API
   Describes
     Services
          Available functionality
     Primitives
          Available parameters
     Allowable     sequence of services and primitives
          Allowed state machines

Security API – Services
   Covers 13 types of service
     Specific   services bundled under type of
   Services summarized as:
     Gaining    access to security service, security
      mgt, fill, algorithm, certificate, crypto, key,
      TRANSEC, policy, integrity & authentication,
      alarm, time, and GPS

Security API – Primitives
 These primitives match the service
  descriptions in the previous slide
 Example
     Crypto   primitives
          CRYPT_DECRYPT, others

Security API – Allowable Sequences

   Essentially state machines described
    allowed states for
     Fill
     Crypto  channel
     TRANSEC channel
     Integrity and authentication

Example: Allowed Crypto Channel
State Machine

Security API Example

Security Functional Specification
   Security requirements matrix contains 96
     Cover  issues such as key control and management
     Matrix supplemented by detailed description of
   Beyond requirements matrix, specifications also
    included for the allocation of functions
     Red,   black, crypto functions

Putting It All Together
   Overview covered:
     Components
     HW  placement
     Link management
     Configuration of system and waveforms
     Core framework
     API
     Security

   Sufficient background to understand most
    abused image in JTRS program
Framework Structure

SDR Criteria
 In the previous section, a set of criteria
  were assembled for the management of
 The following slides describe how the SCA
  meets each of the outlined criteria

Summary: What kind of software is
needed? (1/4)
   Something to manage hardware
     Device     family of classes
          Provides a ready handle for the configuration of three
           types of hardware
               Executable device
                   i.e.: GPP, DSP
               Loadable device
                   i.e.: FPGA
               Device
                   i.e.: NCO
     Device     Manager
          Serves as node booter
               Boots and configures all hardware associated with this nodes

Summary: What kind of software is
needed? (2/4)
   Some standardized way of storing relevant
     File class
        Can be applied to any kind of storage
              Hardware independent
                  Controlled and configured by local Device Manager
     File System
        Device Manager-controlled way to support Files

     File Manager
        File System of File Systems
              Centrally maintained by the Domain Manager
                  Provides Domain-wide access

Summary: What kind of software is
needed? (3/4)
   Some way of structuring the waveforms
     All   waveforms based on Resource Class
           Standardized way to perform variety of tasks
                Start, stop, terminate, connect, test
     Applicationclass is single handle for
      managing waveform
     Devices are Resources
           Seamlessly integrate HW into waveform

Summary: What kind of software is
needed? (4/4)
   Something to actually “run” waveforms
     ApplicationFactory
     User provided with handle to start/stop/terminate
   Something to keep track of what is available and
    what can and cannot be installed
     Domain      Manager
          Maintains the state of the whole domain
               Available HW
               Available SW
                   Waveform availability
               Domain-wide storage

   Open Source SCA Implementation::Embedded (OSSIE)
       Written in C++ for Linux and Windows 2000/XP
       Using open source supporting software
           CORBA (ACE/TAO, omniORB)
           XML Parser (Xerces)
       First version released in July 2004
           Available at:
       Development by team composed largely of volunteers
           Undergraduate and graduate students
       Designed to be simple yet functional

OSSIE Ramifications
   Initially designed for low-power research under DCI
    Postdoctoral Research Fellowship
   Has been very well received by SDR community
       Over 1200 downloads to date
            Downloads by government, industry, and academia
            Released in July 2004
       15+ articles written about it in trade publications
            Including front page in EE Times
       Being evaluated by different entities for active use
   Significantly lowers barrier to entry
       Has served as a catalyst for other SDR research
            Rapid prototyping
            Cognitive radio
            Distributed signal processing
            Integrated testing

OSSIE Development
   Tested on a variety of platforms
       High-end desktop computers
           Linux
           Windows
       Low-end embedded computer
           Texas Instruments OMAP 5912
               GPP
                   ARM 926EJ (192 MHz)
               DSP
                   C55x (192 MHz)
               Using Linux as the OS
       Currently being ported to run on TI TMS320C64
           Using DSP BIOS as the OS

Development Philosophy
   Achieve some fundamental goals
     Provide    a platform with shallow learning curve
          Targeted at entry-level graduate students
     Support    prototypes and proof-of-concept
          Must support needed functionality
   Goal supported with fundamentally simple

Portable SDR Prototype
                                USRP Data Acquisition

                              Texas Instruments OMAP
                              OSSIE framework runs
                              on the ARM processor of
                              TI OMAP

      Small form factor low power device

Base Station SDR Development
           Four TI C6416 DSPs

           Two FPGA Virtex II

           LyrTech Multiprocessor SDR Board

          Generic Platform SDR development. OSSIE will
         be ported to it by November 2005 and SDR board
                will be running WCDMA algorithms.

   Much motivation behind having a unified
    software architecture for SDR
   Many characteristics needed for the architecture
     Scalable and modular software structure
     Common interface/language independence
     Platform independence
     Common software architecture
     Standardized function calls
   Many issues remain
     Portability in power management
     More efficient use of DSPs and FPGAs
     Rapid design mechanisms