Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2003 Mercury Computer Systems, Inc. SDR – “Do You Care to Buy the Softest?” Jeff Smith, Jim Kulp, Murat Bicer, Tansu Demirbilek Mercury Computer Systems,

Similar presentations


Presentation on theme: "© 2003 Mercury Computer Systems, Inc. SDR – “Do You Care to Buy the Softest?” Jeff Smith, Jim Kulp, Murat Bicer, Tansu Demirbilek Mercury Computer Systems,"— Presentation transcript:

1 © 2003 Mercury Computer Systems, Inc. SDR – “Do You Care to Buy the Softest?” Jeff Smith, Jim Kulp, Murat Bicer, Tansu Demirbilek Mercury Computer Systems, Inc. 199 Riverneck Road, Chelmsford, MA John Anton, Kestrel Technology Military Communications Conference “Mobile Communications and Military Transformation” Washington, D.C. - March 25, 2003

2 2 Problem l Waveform portability vs. performance wImplementation specific architecture Radios can be mostly ASIC implemented and be SCA compliant Waveforms expect a lightweight component run-time env. that not yet commercially available –Synchronize infrastructure requirements with commercial supply –Motivate commercial SDR to leverage defense work l Technology lifecycle wImplementation-neutral components wFabric/infrastructure immunity to lifecycle “kinks” – PNP HW l Scope wELINT and COMINT superset of SR wSCA compatible Coalition Waveform used as layer in proposed C 4 I approach l Waveform development productivity wReuse and verification of waveforms vs. waveform parts wApplication to SIGINT

3 3 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

4 4 Portability Issues l CORBA waivers wPorts - components do not communicate through CORBA wCommunication paths can avoid CORBA messaging wEfficiency wLegacy l Too much of the waveform is not implemented in component software wProprietary code wLogic in FPGA, DSPs and ASICs l Richness of Domain Profile wCF must support all potential XML configurations wInhibits full spec implementation

5 5 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

6 6 Scalable CCM/Embedded Standards Issue l CCM and services wasn't ready for embedded, so SCA was done out of sync with CCM l Neither CCM nor SCA addresses scalable embedded multiprocessing where a component has a data-parallel implementation l Neither CCM nor SCA address non-GPPs or wideband dataflow in any reusable or interoperable way l CCM and services are being fixed (embedded profiles), so evolution of SCA can be pointers to CCM (lite) l Defining extensions based on experience and working them through standards: wReusable definitions for DSP and FPGA codes wData parallel embedded computer support (building on adopted spec) wWideband interoperable dataflow (front end interoperability and RF/IF processing re-use) Issue Solution

7 7 SCA extensions can address issues WDEs, Tool Kits SCA SCA extensions Common Prim. Ctrl. Device Def.D&C Answer

8 8 SDR Middleware l What wCCM interface wSCA compliant wRevised GUI wStreamlined to this app l Why wFPGA connection wInfrastructure for Data Reorg and multiprocessors wVisualization and test interface A.CORBA interfaces B.CCM Services C.Embeddable (Lite) D.Scaleable E.Data Streaming/Flow F.Data Reorg G.D&C A,B,G A,B,E,G CCM SCA  C,D,E,F,G SCE

9 9 Data Parallel Middleware Embedded Computer Support l Component implementation span multiple processors l Stripe/distribute/ scatter streams across multiple processors - for streams from I/O ports to processors and among processors l Support scalable implementations that can use varying amounts of different speed processors as required l Data parallel CORBA (partial objects and parallel servers) l Alternative assemblies based on QoS and HW l Support for data reorganization standard (DRI) l Components that scale Need Solution

10 10 Scalable Heterogeneous Components l High-performance, scalable middleware l Heterogeneous hardware wG4s, Pentiums l FPGA components l Dynamically scale application-performance based on available resources l Component authoring tool l Data-reorg, data-flow SCA implementation that operates with w Conventional middlewares w Unique CORBA-compliant middleware (SCE) that supports seamless FPGA, DSP, and SW component interoperability and low-level machine standards

11 11 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

12 12 Lt. Log, Lt. CCM, Lt. Services, Deployment & Config., SWRadio, Parts of UML 2.0, CORBA Variants, …

13 13 Software Radio Standards l OMG SWRadio DSIG is working on a PIM for software radios l The SWRadio spec provides an SCA PSM mapping for this PIM l OMG specifications cannot remain specs without implementations (of PSM) l OMG SCA-compliant implementations permit convergence between SDRF and OMG – viz. Harris, Mercury implementations l OMG suite of specs is more abstract – applicable to a greater number of systems l OMG adoption means commercial acceptance (800+ international members)

14 14 Roadmap of Primary Specs

15 15 Co-chair Collaboration Standard Reference Models Proposed Design Behavior (states, sequences/roles) Responsibility Levels Contained Information OMG, SDRF Architectural Interfaces, DTDs (components, properties, relationships) CRC, SDRFImplementation Platform-specific code w Required to validate OMG spec and behavior w Early reference implementation already used for SCA compliance testing w SCA Interoperability

16 16 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

17 17

18 18 SW Radio Definitions Have Increasing Levels of Reprogramability Dynamic Deployment, Plan & Reconfig Waveform Air prog. Static Config & Plan Up/down Conversion within Fabric Reconfig Waveforms Within Fabric Waveform/ Channel Waveform/ Modem Waveform/ Prog. Modem Cluster A The Future… Today’s Technology Waveform/ Prog. Receiver

19 19 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

20 20 Motivation for “Softer” Waveform Generation Technology & Reusable Components l Waveform developer l JTeL l Government l SIGINT l Spec Dev l Spec Implementer l Forward engineering waveform from parts, separation of concerns l Repository and verification of waveform parts l Common understanding, non- redundancy, less money l Working platform to apply constrained search to waveform classification l Check on services, use case identification and reduction and concise uniform description of waveform requirements l Reusable waveform components and capture of waveform design options, parameters and trades If you are a: You get:

21 21 Characteristic Conceptualization Characterize waveforms into waveform attributes such that one could describe a waveform by combinations of types and parameters: Unfolded table dimension = x 1 * x 2 * x 3 *…* x N Waveforms can be thought of as unique paths in this 2-space Maximum size is cross-product of columns Air interface (x 1 =5) Packet content (x 2 =2) Connection type (x 3 =3) Access mode (x 4 =3) Signal type (x 5 =2) … FDMAvoicenetworkinghoppinganalog CDMAdatapoint-to-pointnon-hoppingdigital TDMAbroadcastingdirect sequence DAMA Push-to-talk Trunked … … A B

22 22 x 5 = signal type analog digital x 2 = packet content CDMAFDMATDMA data voice DAMA x 1 = air interface Waveform configuration in N dimensions consistent attributes inconsistent attributes x 2 = packet content CDMAFDMATDMA data voice DAMA x 1 = air interface analog digital with analog data, QPSK modulation cannot be used

23 23 Next 3 dimensions x 6 = source coding x 4 = spectral mask x 7 = channel coding x 1 = TDMA x 2 = digital x N = data

24 24 Larger View of Waveform Characteristics Ontology Used at OMG Signal: SWRI classification ( see )SWRI classificationhttp://www.ece.neu.edu/~mbicer/Mobilecom/doc.html Packet content: voice (analog & digital), data (digital), voice & data Connection type: networking, point-to-point, broadcast, multicast Switching type: circuit, packet LOS: yes, beyond Access mode: push to talk, trunked, DAMA,TDMA,CDMA (direct sequence, multi-carrier), CSMA, FDMA Security: transmission, communication, none Spectral mask: center frequency, instantaneous frequency, bandwidth, power Channel coding: convolutional, turbo, Reed Solomon, CRC, none Routing: RF packets, IO packets Source coding: yes, no Channel estimation: adaptive, trained, blind, none Power control: open loop, closed loop, none

25 25 FM 3 TR Example FM 3 TR Data Transmission Mode FM 3 TR Voice Transmission Mode

26 26 Each Point in 2-Space Has OSI Level Meanings Waveform channels Info proc channels IO channels From École de technologie supérieure, Jean Belzile Characteristics can be realized in  7 OSI layers Layers of characteristic realized as SCA components Layer parts gathered from multiple waveforms & reused to compose a waveform protocol stack Layering of components transparent to the SCA CF Deal with only the Waveform channel but extendable to info proc and IO channels

27 27 Characteristic constraints can partitioned for parallel optimization A waveform space of N dimensions can be represented as,   x 1,x 2, …,x N }, where the set of N vectors need to be determined according to the constraint set  A waveform may be represented as p(x 1 (3), x 2 (5), x 3 (2), …, x N (6) ) = true, s.t. constraints e.g. dead-end, aggregation, etc. The optimal waveform is found by choosing the parameters that minimize the cost function J(.) s.t.  such that:  opt = { arg min J(  ) |   , arg min J(  ) |    }, P 1 P 2 P m s.t. K i are independent, mutually exclusive & cover all constraints, partitions P n are therefore mutually exclusive where, J(  ) |     J( P j ) |  j j=1 m

28 28 Reformulation of Problem… A/D Access mode All A D A A DD TDMAFDMA CDMA TDMA FDMA Info Sec no Info Sec yes 1. The relationship between every possible building block can be seen as a mesh network, where a connected line means an “allowed path” between two nodes 2. By choosing different root nodes, the mesh network can be viewed as a different tree D x1x1 x2x2 x3x3 x4x4 xnxn P1P1 P2P2

29 29 Spec and Implementation Generation Requirements Waveform Specification Waveform Implementation Other Alternatives Formally Validatable Automated Process 3. Application dependent constraint analysis Check feasibility of each application constraint Create search tree given application priorities 4. Automated optimization Use high-performance search technique to find optimal waveform specification that meets application constraints

30 30 Waveform Generation Technology Summary l Refine and publish N-space, testing against JTRS legacy waveforms l Apply search and constraints against refined waveform characteristics wBuild constraints as predicates over characteristics composing the points in waveform configuration space Output power, baud rate, bit error rate, frame error rate wUse high-performance search techniques to identify viable candidates

31 31 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogrammability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

32 32 SCA Implementation Viewpoints for Interoperability and Portability l Clients — software that requests SCA applications to be run and interacts with them l Applications — software that assembles and configures SCA components into a useful structure, in SDR-speak, called a “waveform”. l Components — software that performs some processing function. l System bootstrap/management — software that brings up a pre- configured SCA infrastructure, with various hardware devices l Devices (Drivers/Proxies) software that owns and uses hardware devices l Knowledge required to play this role (write this type of code), to use the SCA system in this way l Basic use case or scenario for playing the role l Core Framework interfaces used l Metadata formats use l Testing issues Types of software written to use an SCA-compliant environment: For each we describe: No viewpoint But UI CF or Platform Developer PlatformDeveloper WaveformDeveloper SCA Dev. Guide Viewpoints

33 33 Roadmap to Implement SCA Partitioned by Viewpoint Application name, port names and interfaces, metadata file locations Available components, their interfaces and descriptor file locations SCA APIs and API Building blocks. POSIX & SCA services & event channels Name of DMD & DMD files to describe how to run bootstrap Component writer’s info + CF interfaces for devices to be uniformly managed/ monitored Find SCA server (via naming service), use CF to run application and use its external ports. SAD is parsed and acted on by the Domain Manager and/or Application Factory App.Factory instantiates, configures & connects components. Apps route client requests for retrieving refs to external ports to components. Parse DMD & start described software that starts a DomainMgr. Partially parse DCD to start DeviceMgrs Devices are used/created according to the DCD processed by the DeviceMgr, creating device at startup time DomainManager, ApplicationFactory, Application NonePort, LifeCycle, TestableObject, Port Supplier, PropertySet, Resource, Resource Factory DomainMgr., DeviceMgr. DeviceMgr (used); Device, ExecutableDevice & LoadableDevice (implemented) NoneCreate SAD, reference SPD IDL, SCD & SPD filesSPD, SCD & DMD files. DCD refs SPD for the device & DPD for the associated HW device Test of skeleton apps that export appropriate interfaces & external ports Apps can be built with non- compliant components Test components independent of actual SCA applications, accessing SCA-limited OE. Use log and event service to test exposure to key interfaces. Test SW launch. A standalone device test or full apps consisting of components deployed on the device Client Waveform Component System boot/mgt Device Knowledge Required Use-case CF Interfaces Used Meta-data Formats Used Testing Issues Viewpoint:

34 34 Elements of a “Softer” SDR l Reduction of SCA loopholes for performance l Lack of scalable CCM/embedded standards l Convergence of SCA specs l Levels of reprogramability l “Softer” waveform specification and (re)generation technology l SCA implementation viewpoints for interoperability and portability l Relation to larger apps e.g. SIGINT and C 4 I

35 35 SDR Forms Lower Levels of One Projected C4I Protocol Stack 6. Content 2. Discovery (linking) waveform - ICS 5. Communications waveform-SCA/FM3TR 4. Networking protocols – TCP/IP 3. Identification process - ALE 1. C 4 I information (registry database) Coalition waveform architecture leverages standards, communication, networking and modeling investments.

36 36 COMINT Receiver

37 37 RWR/ESM/ELINT Receiver

38 38 Summary l SCA letter for “efficiency” vs. spirit for waveform portability l Lack of CCM and embedded standards l Evolution of OMG and SDRF SCA versions l Waveform granularity/level of verification & portability l Levels of SDR reprogramability l Existence proof (remove excuses) + future standards, HW, SW l Component-centric middleware that supports D&C, Lwt. CCM and embedded standards l 1) Ref design model that supports versions & 2) reduce SCA by using OMG portions l 1) Waveform generation tech. & 2) reference design model l Identify/rate levels and phase above per level IssuesSuggestion


Download ppt "© 2003 Mercury Computer Systems, Inc. SDR – “Do You Care to Buy the Softest?” Jeff Smith, Jim Kulp, Murat Bicer, Tansu Demirbilek Mercury Computer Systems,"

Similar presentations


Ads by Google