Software Communication Architecture and HPEC all the worlds

  • Slides: 28
Download presentation
Software Communication Architecture and HPEC “all the world’s a network and its people are

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

Agenda Introduction to Software Defined Radio l SCA Explained l w w w l

Agenda Introduction to Software Defined Radio l SCA Explained l w w w l Relation to SDR Definition, Motivation and Goals Overlap with HPEC SCA Description and Example Relation to HW/SW Standards Future Work Summary © 2001 Mercury Computer Systems, Inc. 2

Software Defined Radio l Radio HW functions replaced in SW w New technologies can

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

Software Radio Functional Architecture BLACK RED High-Speed Switch Fabric Software Modem Antenna Interface d

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

Why SDR? Multi-Billion Dollar Market for … An SDR base station can communicate with

Why SDR? Multi-Billion Dollar Market for … 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. An SDR terminal can be used for any wireless communication by downloading new software 5

The SCA is an Open, Non-Proprietary Specification Sponsored by the Joint Tactical Radio System

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: w Increase operational flexibility and interoperability of globally deployed systems w Reduce supportability costs w Provide upgradeability with easy technology insertion and capability upgrades w Reduce system acquisition and operation cost l The SCA has been structured to: w Provide for portability of applications software between different SCA implementations w Leverage commercial standards to reduce development cost w Reduce development time of new waveforms through reuse of design modules w Build on evolving commercial frameworks and architectures l Designed to meet commercial and military application requirements © 2001 Mercury Computer Systems, Inc. 6

The SCA Specification … l l l Specifies SW, HW, security and networking architecture

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

The SCA Specification … l Supports JTRS requirements w Operator reconfigurable w Multiple legacy

The SCA Specification … l Supports JTRS requirements w Operator reconfigurable w Multiple legacy and new waveforms (33) w Simultaneous multichannel operation (up to 10) l l Specifies SW Interfaces to support the installation and use of distributed applications for flexible, reprogrammable communication capabilities Specifies a common framework to build-up, configure, connect and tear-down distributed, embedded radio applications Current version is 2. 1 (www. jtrs. saalt. army. mil) Is morphing into an OMG form (swradio. omg. org) © 2001 Mercury Computer Systems, Inc. 8

Standard Reference Models Responsibility OMG, SDRF Levels Architectural Contained Information Interfaces, DTDs (components, properties,

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

Software Radio Standards l Object Management Group w Mercury is actively leading • •

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

Why SCA? l l Firm requirement for SDR Addresses many SDR problems w Constraints

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

SCA Goal Summary Goal Description Common Open Architecture Use open, standardized architecture for promoting

SCA Goal Summary Goal Description 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 Security Provide basis for solving issues related to tactical communications systems security (e. g. programmable cryptographic capability, MLS, streamlined security certification) Networking Support legacy network protocols and emerging wideband networking capabilities for voice, data and video Waveform SW Allow for the maximum possible reuse of SW and the use of common & Reuse waveform software among various implementations and with waveforms being portable between implementations © 2001 Mercury Computer Systems, Inc. 12

Overlap Between SDR and HPEC l Complex waveform generation/receipt, interference cancellation and adaptive processing

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

Computational Complexity Channel Modem DSP (Multiple) + Interference Cancellatio n (Co-site/ Co-channel) + Other

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

Scalable Channel Modem Provide a switch-fabric interface directly on the channel modem FPGA Wide/Narrow

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

DSP- or ASIC-specific interface used for Comm. CORBA CCM API for CORBA or SCE

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

SCA Software Structure Applications Operating Environment (OE) Non-CORBA Modem Components RF Core Framework (CF)

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

Example Message Reception Flow With and Without Adapters (1) Non-CORBA Modem (2) Modem Adapter

Example Message Reception Flow With and Without Adapters (1) Non-CORBA Modem (2) Modem Adapter M RF (1) CORBA Modem. Device M (2) (3) Security Adapter (4) Waveform Link. Resource (5) Security Adapter S S S (3) Message Reception Path (with Adapters) (1) RF Interface to Modem (2) non-CORBA Modem Interface (3) CORBA Interface to Waveform Link M (4) CORBA Interface to Security Adapter S (5) Black-side non-CORBA Security Interface (6) Red-side non-CORBA Security Interface (7) CORBA Interface to Waveform Network S (8) CORBA Interface to Host Adapter H (9) non-CORBA Host Interface © 2001 Mercury Computer Systems, Inc. (6) Non-CORBA Security. Device S (4) (7) Host Adapter (8) Waveform Network. Resource (9) Non-CORBA Host H H CORBA (5) Host. Resource Message Reception Path (without Adapters) (1) RF Interface to Modem (2) CORBA Interface to Waveform Link M (3) CORBA Interface to Security S (4) CORBA Interface to Waveform Network S (5) CORBA Interface to Host H Note: The design goal of a CORBA gateway “Adapter” is to define the CORBA side of the gateway such that the eventual replacement of the non-CORBA device and its Adapter does not change the Core Framework CORBA interface. 18

SCA Core Framework Definition l l The Core Framework (CF) is the essential, “core”

SCA Core Framework Definition l 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 CF interfaces consist of: w Base Component Interfaces - a common set of interfaces for exchanging information between software application components w Framework Control Interfaces - interfaces for the start-up, control and tear-down of software application components and the allocation and control of hardware assets w Framework Service Interfaces - interfaces for distributed file access services and event logging services to software application components © 2001 Mercury Computer Systems, Inc. 19

Core Framework Relationships <<Interface>> Port <<Interface>> Life. Cycle Testable. Object Property. Set inherits from

Core Framework Relationships <<Interface>> Port <<Interface>> Life. Cycle Testable. Object Property. Set inherits from uses <<Interface>> Resource 0. . * devices Base Component <<Interface>> Device <<Interface>> Application uses <<Interface>> Application. Factory 0. . * app lica tio ns <<Interface>> Device. Manager log 0. . 1 application. Factories Framework Control Domain. Manager 1. . * device. Managers <<Interface>> Framework Services File Logger Legend <<Interface>> File. System 0. . Mg r gr 1 1 file <<Interface>> 0. . * <<Interface>> String. Consumer <<Interface>> Resource. Factory f M ile Implemented by Non-Core Applications Core Framework Interface Implemented as Core Application Services <<Interface>> File. Manager Core Framework Interface © 2001 Mercury Computer Systems, Inc. 20

SCA Domain Profile l A Domain Profile consists of a set of files that

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

Domain Profile XML DTD Relationships Profile Access Software Profile Hardware Profile HW or SW

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

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

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

SCA Metamodel Refined into PIM Operational User Interface SW Radio Reference Architecture System Monitoring

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

Domain Profile Parts Describe SCA Metamodel Components Domain. Manager 1 0. . n Application.

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

Programming SCA Compliant SW Application. Factory determines applicable Device(s) on which to load application

Programming SCA Compliant SW Application. Factory determines applicable Device(s) on which to load application code defined in Domain Profile UI asks for all Application. Factory(s) ~~~~~ ~~ ~~~ XML Files ~~~~ ~~ • Application to instantiate is chosen • UI issues create( ) on Application. Factory Domain Profile load/execute, allocate capacities Application. Factory connects the Port(s) to form 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. Device Resource(s) bring Port(s) into existence Resource 1 Physical Device 1 Connects resource ports Resource 3 Resource 2 Physical Device 2 Resources are then configured, initialized and started © 2001 Mercury Computer Systems, Inc. 26 Bring resources into existence on physical devices

HW/SW Standards Under Development l At 9/11 -15/01 meeting, reported on w Overlap between

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

Summary l Large market w All military SW radio procurements require SCA compatibility w

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