1 / 28

Software Communication Architecture and HPEC

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. Agenda. Introduction to Software Defined Radio SCA Explained Relation to SDR

lotta
Télécharger la présentation

Software Communication Architecture and HPEC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Introduction to Software Defined Radio • SCA Explained • Relation to SDR • Definition, Motivation and Goals • Overlap with HPEC • SCA Description and Example • Relation to HW/SW Standards • Future Work • Summary

  3. Software Defined Radio • Radio HW functions replaced in SW • New technologies can be adapted quickly, easily and less expensively • Different types of waveforms reuse logic • 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.

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

  5. 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 An SDR terminal can be used for any wireless communication by downloading new software

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

  7. The SCA Specification … • 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 • Application and device portability and reuse (with CORBA) • Rapid technology insertion over time • Is extendible to new waveforms and HW components • Incorporates embedded, programmable INFOSEC

  8. The SCA Specification … • Supports JTRS requirements • Operator reconfigurable • Multiple legacy and new waveforms (33) • Simultaneous multichannel operation (up to 10) • Specifies SW Interfaces to support the installation and use of distributed applications for flexible, re-programmable 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)

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

  10. Mobile Working Group TAG/CCB Software Radio SIG SCA SCA Software Radio Standards • Object Management Group • Mercury 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 • SW Radio DSIG now standardizing Software Communications Architecture (SCA) • JTRS JPO contributed their SCA v2.0 for standard • SDR Forum • Mercury is actively participating in • Software Radio Architecture (SRA) • Liaison between SDR Forum and JTRS JPO TAG – Dave Murotake

  11. Why SCA? • Firm requirement for SDR • Addresses many SDR problems • Constraints 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. • Legacy architectures initially presented obstacles to SCA consensus • Proprietary radio solutions with non-reusable software are the norm • Commercial standards are evolving extremely fast • Third-party development of radio applications and software components introduces new business models to radio manufacturers

  12. SCA Goal Summary GoalDescription

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

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

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

  16. Software Architecture DSP- or ASIC-specific interface used for Comm. CORBA CCM API for CORBA or SCE Applications (OFDM, interference cancellation, smart antenna) and Tools CORBA ORB or SCE File access Core Framework (from Harris, BAE, Motorola, Raytheon, etc.) Device Drivers OS access limited to SCA AEP OS access unlimited OS access unlimited 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. HW-specific device drivers provide access to device for OS MC/OS and SAL/VSIPL function calls

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

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

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

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

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

  22. Domain Profile XML DTD Relationships Profile Access Software Profile Hardware Profile <<Abstract>> HW or SW Profile Domain Profile 0..n 0..n <<XML DTD>> Software Assembly Descriptor 1..n 1..n 1..n 1..n 1 <<XML DTD>> <<XML DTD>> Software Component Descriptor SoftwareProfile Software Package Descriptor 0..1 0..1 SoftwareProfile 1 1 1..n 1..n <<XML DTD>> Profile Descriptor DeviceConfigurationProfile 0..n 0..n 0..1 0..1 0..1 0..1 1 <<XML DTD>> <<XML DTD>> <<XML DTD>> 0..n 0..n Device Configuration Descriptor Device Package Descriptor Properties Descriptor File

  23. Current SCA Problem Metamodel Defines Minimal CORBA Environment

  24. SCA Metamodel Refined into PIM Operational User Interface SW Radio Reference Architecture System Monitoring Deployment and Configuration Waveform Applications

  25. Domain Profile Parts DescribeSCA Metamodel Components DomainManager 1 1 0..n 0..n ApplicationFactory <<create>> Application described by SW Assembly Descriptor 1 1 1 1 1 1 +Proxy 1..n 1..n SW Component described by described by Properties Properties SW Package Descriptor Descriptor 1 1 1 1 1 1 1 1 1..n 1..n 1 1 Types Non-CORBA CORBA described by SW Component Component Component Descriptor 1 1 1 1 Types ResourceFactory described by Device Resource Device Package Descriptor 1 1 1 1 0..n 0..n are used to access 0..n 0..n the Provides ports Uses Provides Consumer connection Producer are provided by of a producer Port Port 1..n 1..n 1 1 1 1 1..n 1..n described by a connection interface element within the SAD

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

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

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

More Related