© 2001 Mercury Computer Systems, Inc. Software Communication Architecture and HPEC Dr. Jeffrey E. Smith Murat Bicer Mercury Computer Systems, Inc. HPEC – November 2001 “all the world’s a network and its people are merely nodes…”

© 2001 Mercury Computer Systems, Inc. 2 Agenda l Introduction to Software Defined Radio l SCA Explained wRelation to SDR wDefinition, Motivation and Goals wOverlap with HPEC wSCA Description and Example wRelation to HW/SW Standards wFuture Work l Summary

© 2001 Mercury Computer Systems, Inc. 3 Software Defined Radio l Radio HW functions replaced in SW wNew technologies can be adapted quickly, easily and less expensively wDifferent types of waveforms reuse logic l Air configurable with new functionality l Communicate with many different radios with changes in SW parameters (frequencies, hop rate, symbol rate, etc.) l Derive benefits of WB processing in standard framework, e.g. efficient use of spectrum, security, etc.

© 2001 Mercury Computer Systems, Inc. 4 High-Speed Switch Fabric Software Radio Functional Architecture Source: SDR Forum, modified by Mercury Computer Systems Inc. RF/IF A/D & D/A Security Message Processing Antenna Interface ccc d dd Control Bus Control Interface BLACK Control Interface Link Processing Modem c d Software Modem Adaptive Proc. d c RED Net

© 2001 Mercury Computer Systems, Inc. 5 Why SDR? Multi-Billion Dollar Market for … An SDR terminal can be used for any wireless communication by downloading new software An SDR base station can communicate with any kind of terminal (i.e. Cellular, Telephone, PDA) by downloading new software

© 2001 Mercury Computer Systems, Inc. 6 The SCA is an Open, Non-Proprietary Specification Sponsored by the Joint Tactical Radio System (JTRS) program l A set of rules that constrain the design of SW Radio systems to: wIncrease operational flexibility and interoperability of globally deployed systems wReduce supportability costs wProvide upgradeability with easy technology insertion and capability upgrades wReduce system acquisition and operation cost l The SCA has been structured to: wProvide for portability of applications software between different SCA implementations wLeverage commercial standards to reduce development cost wReduce development time of new waveforms through reuse of design modules wBuild on evolving commercial frameworks and architectures l Designed to meet commercial and military application requirements

© 2001 Mercury Computer Systems, Inc. 7 The SCA Specification … l Specifies SW, HW, security and networking architecture requirements standard for open, programmable SDR systems l Supports a family of interoperable, air programmable, scaleable and affordable radios l Maximizes independence of SW from HW wApplication and device portability and reuse (with CORBA) wRapid technology insertion over time l Is extendible to new waveforms and HW components l Incorporates embedded, programmable INFOSEC

© 2001 Mercury Computer Systems, Inc. 8 The SCA Specification … l Supports JTRS requirements wOperator reconfigurable wMultiple legacy and new waveforms (33) wSimultaneous multichannel operation (up to 10) l Specifies SW Interfaces to support the installation and use of distributed applications for flexible, re- programmable communication capabilities l Specifies a common framework to build-up, configure, connect and tear-down distributed, embedded radio applications l Current version is 2.1 ( l Is morphing into an OMG form (swradio.omg.org)

© 2001 Mercury Computer Systems, Inc. 9 Co-chair Carleton/ Oversight board Standard Reference Models New contract Design Behavior (states, sequences/roles) Responsibility Levels Contained Information OMG, SDRF Architectural Interfaces, DTDs (components, properties, relationships) PIM  Action semantics, ops CRC Implementation PSM  Platform specific code

© 2001 Mercury Computer Systems, Inc. 10 Software Radio Standards l Object Management Group wMercury is actively leading Data parallel/high-performance CORBA – Jim Kulp Software Radio DSIG – Jeff Smith Data flow and math framework in UML 2.0 – Jeff Smith wSW Radio DSIG now standardizing Software Communications Architecture (SCA) JTRS JPO contributed their SCA v2.0 for standard l SDR Forum wMercury is actively participating in Software Radio Architecture (SRA) Liaison between SDR Forum and JTRS JPO TAG – Dave Murotake Mobile Working Group SCA Software Radio SIG SCA TAG/CCB

© 2001 Mercury Computer Systems, Inc. 11 Why SCA? l Firm requirement for SDR l Addresses many SDR problems wConstraints to SW Radio design, resource constraints in embedded systems, demand for high BW, security and QoS, variation of radio domains, lack of mature OS and CORBA products for DSP, etc. l Legacy architectures initially presented obstacles to SCA consensus l Proprietary radio solutions with non-reusable software are the norm l Commercial standards are evolving extremely fast l Third-party development of radio applications and software components introduces new business models to radio manufacturers

© 2001 Mercury Computer Systems, Inc. 12 SCA Goal Summary Common Open Architecture Use open, standardized architecture for promoting competition, interoperability, technology insertion, quick upgrades, software reuse, extendibility and scalability Multiple Domains Support operations in a wide variety of domains – airborne, fixed, maritime, vehicular, dismounted and handheld Multiple Bands/Modes Replace a number of radios over a wide range of frequencies, interoperate with radios operating in disparate spectrum and cross-band between modes and waveforms for radio interoperability Legacy Sys. Compatibility Develop implementations capable of interacting with a wide variety of legacy equipment, minimizing the impact of platform integration Technology Insertion Enable technology insertion to improve performance, reduce cost and time to field and prevent obsolescence SecurityProvide basis for solving issues related to tactical communications systems security (e.g. programmable cryptographic capability, MLS, streamlined security certification) NetworkingSupport legacy network protocols and emerging wideband networking capabilities for voice, data and video Waveform SW & Reuse Allow for the maximum possible reuse of SW and the use of common waveform software among various implementations and with waveforms being portable between implementations Goal Description

© 2001 Mercury Computer Systems, Inc. 13 Overlap Between SDR and HPEC l Complex waveform generation/receipt, interference cancellation and adaptive processing wIncreasing traffic rates and decreasing amounts of spectrum require more sophisticated signal-processing algorithms wIncreasing of variable-QoS, multi-component traffic, requiring complex management of resources allocated in the operation of a user connection l Similar problems wReal-time transformation of dynamically changing streams wSimilar GPP vs. DSP/FPGA issues since DSP/FPGAs merely run as SCA devices

© 2001 Mercury Computer Systems, Inc. 14 Computational Complexity Combat Net Radio Tactical Vehicle Network Radio Access Node (Base Station) Narrowband Waveform Wideband Waveform LPI/LPD Waveform Channel Modem DSP (1-4) Channel Modem DSP (Multiple) + Interferenc e Cancellatio n (Co-site/ Co-channel) Channel Modem DSP (Multiple) + Interferenc e Cancellatio n (Co-site/ Co-channel) + Other Adaptive Processing (Smart Antennas) Platform Complexity Waveform Complexity

© 2001 Mercury Computer Systems, Inc. 15 Scalable Channel Modem A/DD/A FPGA (ASIC) DSP Searcher receiver  kq, q = 1:4 User #K Finger receiver Finger receiver y k4 Finger receiver Finger receiver y k3 Finger receiver Finger receiver y k2 Finger receiver Finger receiver y k1 MRC ykyk Searcher receiver  kq, q = 1:4 User #2 Finger receiver Finger receiver y k4 Finger receiver Finger receiver y k3 Finger receiver Finger receiver y k2 Finger receiver Finger receiver y k1 MRC ykyk Data from A/D Rake Searcher receiver  kq, q = 1:4 User #1 Rake MRC Rake MRC ykyk Interference Canceller y kq ykyk  kq User codes, SF,... Rake Receiver FPGA Single User Rake Receiver Adaptive Processor Quad PPC/G4 CN’s Wideband CDMA base station example Single User Rake Receiver Provide a switch-fabric interface directly on the channel modem FPGA PPC G4 POSIX RTOS CORBA, SCA, >3 GFLOPS POSIX RTOS CORBA, SCA, >3 GFLOPS Rich Connection to other Resources Non-POSIX RTOS No CORBA or SCA Wide/Narrow Band Up/Down Conversion Finger receiver y k1 y k4 y k3 y k2

© 2001 Mercury Computer Systems, Inc. 16 Software Architecture CORBA ORB or SCE OS that supports SCA Application Environment Profile (AEP) including PAS/MPI API and algorithm libraries. This includes MC/OS on target and VxWorks on host. Applications (OFDM, interference cancellation, smart antenna) and Tools OS access limited to SCA AEP OS access unlimited Core Framework (from Harris, BAE, Motorola, Raytheon, etc.) Device DriversDevice Drivers File access CORBA CCM API for CORBA or SCE DSP- or ASIC-specific interface used for Comm. MC/OS and SAL/VSIPL function calls HW-specific device drivers provide access to device for OS

© 2001 Mercury Computer Systems, Inc. 17 SCA Software Structure Core Framework (CF) Commercial Off-the-Shelf (COTS) Applications Operating Environment (OE) Red Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Black Hardware Bus CF Services & Applications CORBA ORB & Services (Middleware) Network Stacks & Serial Interface Services Board Support Package (Bus Layer) Operating System Core Framework IDL Non-CORBA Modem Components Non-CORBA Security Components Non-CORBA I/O Components RF Modem Components Link, Network Components Security Components Modem Adapter Security Adapter Security Adapter I/O Adapter I/O Components MAC APILLC/Network API Link, Network Components Security API Operating System Physical API I/O API (“Logical Software Bus” via CORBA)

© 2001 Mercury Computer Systems, Inc. 18 Example Message Reception Flow With and Without Adapters

© 2001 Mercury Computer Systems, Inc. 19 SCA Core Framework Definition l The Core Framework (CF) is the essential, “core” set of open software interfaces and profiles that provide for the deployment, management, interconnection and intercommunication of software application components in embedded communication systems l CF interfaces consist of: wBase Component Interfaces - a common set of interfaces for exchanging information between software application components wFramework Control Interfaces - interfaces for the start-up, control and tear-down of software application components and the allocation and control of hardware assets wFramework Service Interfaces - interfaces for distributed file access services and event logging services to software application components

© 2001 Mercury Computer Systems, Inc. 20 Core Framework Relationships inherits from uses > Resource > ResourceFactory > TestableObject > PropertySet > LifeCycle > Port Base Component > Logger > FileManager > File > StringConsumer > FileSystem Core Framework Interface Implemented as Core Application Services Legend Core Framework Interface Implemented by Non-Core Applications Framework Services deviceManagers uses > Device > DomainManager > ApplicationFactory 1..* devices 0..* applicationFactories fileMgr 1 applications 0..* fileMgr 0..1 log 0..1 > Application > DeviceManager Framework Control 0..*

© 2001 Mercury Computer Systems, Inc. 21 SCA Domain Profile l A Domain Profile consists of a set of files that describes the components, interconnection and properties of a software application wXML format wCustomized from the OMG CORBA component specification to better address software radio needs wDescribes specific characteristics of software components or hardware devices wDescribes interfaces, functional capabilities, logical location, inter-dependencies and other pertinent parameters Description of applications, startup requirements of devices, etc.

© 2001 Mercury Computer Systems, Inc. 22 Domain Profile XML DTD Relationships Software Assembly Descriptor > Domain Profile > 0..n Device Configuration Descriptor > Profile Descriptor > 1 SoftwareProfile 1 DeviceConfigurationProfile Device Package Descriptor > Software Package Descriptor > 1..n 11 SoftwareProfile Properties Descriptor File > 0..n Software Component Descriptor > 0..1 Profile Access Software Profile Hardware Profile HW or SW Profile

© 2001 Mercury Computer Systems, Inc. 23 Current SCA Problem Metamodel Defines Minimal CORBA Environment

© 2001 Mercury Computer Systems, Inc. 24 SCA Metamodel Refined into PIM SW Radio Reference Architecture Operational User Interface System Monitoring Deployment and Configuration Waveform Applications

© 2001 Mercury Computer Systems, Inc. 25 Domain Profile Parts Describe SCA Metamodel Components DomainManager ApplicationFactory 1 0..n 1 Non-CORBA Component SW Component Descriptor CORBA Component 1111 described by ResourceFactory SW Assembly Descriptor Application > 1111 described by SW Package Descriptor SW Component 1..n 1 +Proxy described by Properties 1 1..n 1 Properties Descriptor 1111 described by Consumer Resource Uses Port 0..n 1..n 1 1 are used to access the Provides ports of a producer Producer Provides Port 0..n connection 11..n1 are provided by described by a connection interface element within the SAD Types Device Device Package Descriptor 1111 described by

© 2001 Mercury Computer Systems, Inc. 26 Programming SCA Compliant SW Device ApplicationFactory ~~~~~ ~~ ~~~ XML Files ~~~~ ~~ Domain Profile Resource 2 Resource 1 Resource 3 Physical Device 1 Physical Device 2 load/execute, allocate capacities ApplicationFactory determines applicable Device(s) on which to load application code defined in Domain Profile Bring resources into existence on physical devices Resource(s) bring Port(s) into existence Connects resource ports ApplicationFactory connects the Port(s) to form Application Resources are then configured, initialized and started UI asks for all ApplicationFactory(s) Application to instantiate is chosen UI issues create( ) on ApplicationFactory Application developers provide implementations of the Base Application Interfaces in their applications, using the Framework Control and Framework Services Interfaces as needed and describe their application with a Software Profile. Core application services developers provide the Framework Control and Framework Services interfaces and process the Domain Profile DTDs.

© 2001 Mercury Computer Systems, Inc. 27 HW/SW Standards Under Development l At 9/11-15/01 meeting, reported on wOverlap between deployment and component, load balancing, CORBA management, data parallel CORBA, wireless CORBA, on-line updates, CCM and smart transducer RFPs wRelated services e.g. naming, logging, security, real- time notification and events wData-flow requirements and metamodel to support software radio processing l SCA continuing evolution with first major application – Cluster 1 l Adding behavioral model to support consistent SCA simulation and validation

© 2001 Mercury Computer Systems, Inc. 28 Summary l Large market wAll military SW radio procurements require SCA compatibility wCommercial cell phone market wBecoming globally and commercially accepted through wider OMG standardization process wNew SDR R&D projects have started in Europe l Problem domain shares HPEC goals l SCA and OMG versions are on consistent path and accelerated by recent events