Docstoc

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
    Overview
   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


                                                                           2
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
    (photography)
        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

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


                                                          5
JTRS
   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)
    specifications

                                                     6
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…

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


                                                           8
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
        objects
   OOP better suited to mimic the functionality of a physical
    radio
       Well suited for event driven processing
   Blur the distinction between software and hardware
    objects
                                                                        9
CORBA can Serve an Important
Role in the SCA
   Common Object Request Broker Architecture
    (CORBA)
   Used to tie-in different objects together
    (middleware)
   Provides an architecture-independent
    implementation
     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
                                                            10
CORBA*
   Common Object Request Broker
    Architecture
     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
         components
             Seamless handling of HW
              and SW
    Open-source
     implementations
     available
        OSSIE
             C++ by MPRG
        SCARI
             Java by Communications
              Research Centre


                                                              12
Is the SCA Suitable for Commercial
Implementations?
   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
           establishments

                                                                    13
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

                                                           14
               Background

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
             ...
             RF_stream=get_ADC_output(ADC_1);
             ...
           }
     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


                                                                    16
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
      application
          Integrating C++ on DSP and VHDL on FPGA not a trivial
           endeavor
   Difficult to upgrade
     New functionality not readily integrated
        More issues related to “sloppy” code




                                                                   17
Linear Programming and the
Wireless Industry
   The issues created by linear software (logic/action-
    oriented) generally trivial for small-scale (or closed)
    developers
       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

                                                                         18
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
                                                19
      What is UML used for?
SCA,CORBA and related specs, and waveforms are all described in UML.


   Provides a common language for functional
    specifications
     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
Representation
   Name                       Class Name
 Compartment
                     attribute
  Attributes         attribute : data_type
 Compartment         attribute : data_type = init_value
                     … (continuation)
   (Variables)
                     «Stereotype»
  Operations         operation
 Compartment         operation(arg_list) : result_type
   (Functions)       …
 Stereotype – A logical grouping of similar
 modeling elements                                       21
UML Class Representation
Options
  Optional visibility icons
                         Attributes Operations
      Public
      Private

      Implementation

  Representation option             FIR
  Only the name compartment
                                                 22
Example Class Diagram

                  FIR
     «Characteristics»
       h[N]
       w[N]
        update_w(x)
        calculate_y()
     «Interfaces»
        input_new_samp(x)
        Rtn_type retrieve_output()
                                     23
UML Indicating
Class Relationships
 Association A Relationship Between Two
 Objects
 Represented by a line in UML. Association
 can be explicitly written, or denoted
 symbolically

  Explicit Association Example
            employee     employer
   Person                           Company

                                              24
UML Dependency Relationship

 Dependency A Directional Relationship
 Between Two Classes

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

                 «friend»
      Class A                Class B

                                             25
UML Multiplicity

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


           employee      employer
  Person                            Company

                                               26
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

                                              27
Aggregation

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

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

     Person                    Heart


                  Person

                   Heart
                                               29
Nesting

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


   Vertebrates                 Backbone



                                              30
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
  interfaces
  Describes an “is a” relationship.
                    Filter         (Parent)


              FIR            IIR   (Children)
                                                 31
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
      Protected


                                                 32
Abstract Class

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

   Specialization            Generalization

     Instance                   Abstract
                                                  33
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
    network
        Distributed object deployment
        Networking is transparent to client/server




                                                          34
Approaches to
Achieving the Ideal
SDR
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




                                       36
Scalable and Modular Software
Structure
   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
      objects
     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

                                                             37
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


                                                     38
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


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

        w[N-1]
                     hN-1    h[N] - Constant
                             w[N] - Variable
                                            - Function
                             Update w - Function
                                                           40
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
 function
 Public – Variables or functions that can be
 used by elements internal and external to the
 object

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


                                                  42
OOP Visibility Example


                        FIR
             h[N]
             w[N]
   Private   update_w(x)
             calculate_y()
             input_new_samp(x)
   Public    Rtn_type retrieve_output()



                                          43
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
        functionality
            Can easily map to classes
             and objects




                                         44
Inheritance
   It is possible to derive a class from a parent
    class
    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




                                                           45
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




                                       46
Common Interface/language
Independence
   Interface between objects in the same language
    is trivial
    demodulator.inStream(LNA.outStream());
         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


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


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

                                                       49
CORBA*
   Common Object Request Broker
    Architecture
     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
IDL
   Interface Definition Language
     Provides  a standardized way to describe object
      interfaces
   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


                                                            51
IDL Usage: Example Create a RS
Coder




     IDL compiler
                                 52
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
    language-specific
     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
           compiler



                                                            54
Example of IDL Compiler (1/6)
   Consider ACE TAO IDL Compiler,
    TAO_IDL.EXE
     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); };


                                                   55
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.




                                                              56
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)



                                                      57
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;
     }
                                                                           58
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 :




                                                                 59
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
      transparent

                                60
Polymorphism through IDL and
CORBA




                               61
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



                                            62
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



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




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

                                                                 API

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



                                                                                              65
CORBA Support
   Two ways for platform independence to be
    supported
     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



                                                             66
CORBA continued
   In this case CORBA is used as an illustrative
    example
     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
    middleware)
     Consumes      disproportionately large amount of
      resources
     Designed to support a very large number of
      applications
          Far more complicated than needed by an SDR

                                                                  67
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



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



                                                  69
SDR Software Architecture
Philosophies
    Dataflow
        Control loops, batch sequential, pipes and filters
    Call-and-return
        Functional decomposition (classical), layered (OSI), client-server,
         object-oriented
    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
     likely)

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




                                            71
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
      middleware
   Standardized set of waveform
    operation/management calls makes the software
    far more portable

                                                            72
    Application Programming Interface
    (API)
   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
      tasks
          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-
      dependent
                                                                  73
Example: Packet Transmission API
(from SCAv2.2)
   API describes
    specific names
    and types for
    the different
    aspects of a
    specific
    implementation
       In this case,
        transmit packet
        control




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




                                            75
The SCA

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




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



                                                              78
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


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


                                                      80
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




                                                            81
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



                                                      82
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


                                                      83
What kind of software is needed?
(1/4)
   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




                                                             84
What kind of software is needed?
(2/4)
   Some standardized way of storing relevant
    information
     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
      this
          Dynamic RAM, hard drive, FLASH, other



                                                                 85
What kind of software is needed?
(3/4)
   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
           software



                                                           86
What kind of software is needed?
(4/4)
   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
    installed
     Ideally,   this will bind the whole thing together




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

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




                                                           89
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
                                                             90
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
      Manager
   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

                                                         91
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




                                                 92
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


                                                     93
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
      needed
          Place where CORBA resides (GPP or maybe DSP)
           must act as a driver
   Direct ramification is a star architecture for
    each node‟s software

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




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




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


                                                      97
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




                                                                                           98
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
      deployment
          Number and layout of components on hardware


                                                         99
Container Example
   Container code for single component on
    hardware




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




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




                        102
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

                                                103
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



                                                                 105
Classes




          106
Platform Independent and
Dependent Elements
  Platform                     Platform
Independent                   Dependent




                                                                        107
  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
program.
AggregateDevice – Provides interfaces for supporting a collection of Devices as a logical unit.
DeviceManager – Provides management functions methods for one or more Logical Devices.

  Platform
Independent

 Platform
Dependent




                                                                                       108
       Adapted from Lee Pucker, SCA Boot Camp, 2004 SDR Forum, Phoenix, AZ
Hardware that may or may not be
configured
   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
    functionality

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

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

                                                     111
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




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


                                                         113
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
           software




                                                            114
DeviceManager
 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

                                                    115
 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.




                                                                                        116
    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
  DomainManager

                                        117
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
      attributes

                                                        118
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

                                                       119
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
    concept
     Variety      of usage models
          Handheld, embedded, aircraft, ships, ground
           vehicles
               Single user interface would not be appropriate


                                                                 120
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




                                                                     121
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


                                                             122
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
       created)
      Connects all Ports
      Informs any objects listening that it has successfully created waveform
      Return Application object




                                                                            123
Application
 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
               ApplicationFactory


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


                                                                  125
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
      pointer
        Loss of pointer results in memory leak
        Framework equivalent is loss of ability to
         deallocate capacities in hardware
              Requires reboot of environment




                                                      126
ApplicationFactory Example: GSM Vocoder




                                     127
ApplicationFactory
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

                                                                     128
      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
        allocated).
                                                                       129
   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.




                                                                                        130
      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
    hardware
     i.e.:
          A hard drive, a block of memory
     The File Manager can then be used to create an
      amalgamation of these File Systems




                                                              131
File System Usage
   A File System is generally associated with a
    single piece of hardware or single operating
    system
     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
      Manager
           File Manager behaves as File System of File Systems
     Single    interface and structure for all storage

                                                                  132
    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




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


                                                  134
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




                                                                            135
Port
   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
      implementation


                                                                    136
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
           software


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


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




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




                                                  139
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
      Component


                                                         140
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



                                                                        141
Connect to other Components
   Connection to other Components
    performed through the PortSupplier parent
    class
     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



                                                                      142
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



                                                              143
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)



                                                          144
Implementing Systems
   Classes and components were presented in this
    tutorial in stand-alone form
     In reality, a shell is needed for these program
      constructs
     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




                                                                                145
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
     do
     {
        ORB_WRAP::orb->perform_work(orb_time_out);          // service CORBA requests
     } while( decoder->is_running() );

     delete decoder;

     return 0;
};




                                                                                            146
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


                                                                               147
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
         events
               The location and approach to modifying these methods are
                application-specific
     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
                modified



                                                                           148
Final Modifications to Component
   Beyond these generic modifications, the only aspect left is
    functionality
   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
         functionality
             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




                                                                                            149
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




                                                                       150
SCA Class
Management and
Configuration
Assembly Controller
   There is a special component whose sole
    job is to provide a start/stop point of entry
    into the Waveform, the Assembly
    Controller
     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



                                                             152
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


                                                    153
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


                                                                         154
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




                                                        155
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




                                                           156
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
           object
                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
                 waveforms




                                                                                158
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


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




                                         160
Configuration
   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



                                                        161
XML
   eXtensible Markup Language
     Application
                of the Standard Generalized
      Markup Language (SGML)
          HTML also has its roots in SGML
     Explicit
             structure for the description of
      information
        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
language
   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
           attributes
                                                               163
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


                                                                         164
Elements
   Elements are marked as tags
        <my_element>my_value</my_element>
         or
        <my_element  />
     Attribute   values must be in quotes
          <my_element
           id=“my_id”>my_value</my_element>
     Comments      created by changing tag
          <!--my_element>my_value</my_element-->


                                                    165
    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>
         <value>1000</value>
         <kind kindtype="configure"/>
   </simple>                                                             2 sub element
   <simple id="VARIANCE" type="double">
         <description>Size of the array buffer.</description>
         <value>0.05</value>
         <kind kindtype="configure"/>
   </simple>
</properties>




                                                                             166
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


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

        Component connections

        Names of appropriate pieces

        Location for relevant files




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




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




                                                          170
Domain Manager Configuration (1/2)

   The Domain Manager needs configuration
    files
     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



                                                             171
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
        (_PRF.xml)
   DomainManager_SCD.xml
       Contains a list of the interfaces making up the
        component
   DomainManager_PRF.xml
       Contains the information that populates Property Set
            Recall that Resource, Domain Manager, and Device Manager
             all inherit from Property Set




                                                                    172
XML Pattern
   The same general pattern applies to all
    pieces
    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)




                                                   173
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
         example
             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
              waveform

                                                                               174
SCA Application
Program Interfaces
(APIs)
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


                                                        176
SCA API
   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”

                                                               177
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
         components
               Non-real-time control
               Setup and initialization
          These do not necessarily describe the connection between
           components



                                                                  178
Relationship Example




                       179
    General API Usage

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




                              180
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



                                                                181
Services
 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



                                                    182
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
        components
            Attributes
                  maxPayloadSize
                  minPayloadSize
                  numOfPriorityQueues
            Methods
                  pushPacket()
                  spaceAvailable()
                  enableFlowControlSignals()
                  enableEmptySignal()
                  setNumOfPriorityQueues()
   The API specifications are full of such building blocks


                                                                      183
Security
   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
      specifications
     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



                                                                              184
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
               Factory
     Domain Manager




                                                        185
Security
   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


                                                 186
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



                                                        187
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
    method)
       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



                                                                        188
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




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




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



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




                                              192
Security API – Allowable Sequences

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




                                           193
Example: Allowed Crypto Channel
State Machine




                                  194
Security API Example




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




                                                         196
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
                                               197
Framework Structure




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




                                          199
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




                                                                           200
Summary: What kind of software is
needed? (2/4)
   Some standardized way of storing relevant
    information
     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



                                                                       201
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



                                                           202
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



                                                          203
OSSIE
   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: http://ossie.mprg.org
       Development by team composed largely of volunteers
           Undergraduate and graduate students
       Designed to be simple yet functional




                                                             204
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




                                                               205
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
        processor
           Using DSP BIOS as the OS


                                                        206
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
      systems
          Must support needed functionality
   Goal supported with fundamentally simple
    framework


                                                       207
Portable SDR Prototype
                                USRP Data Acquisition
                                Board



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

      Small form factor low power device

                                                        208
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.




                                                    209
Conclusion
   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

                                                  210

				
DOCUMENT INFO