SDR – “Do You Care to Buy the Softest?”

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

2. Problem • Waveform portability vs. performance • Implementation 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 • Technology lifecycle • Implementation-neutral components • Fabric/infrastructure immunity to lifecycle “kinks” – PNP HW • Scope • ELINT and COMINT superset of SR • SCA compatible Coalition Waveform used as layer in proposed C4I approach • Waveform development productivity • Reuse and verification of waveforms vs. waveform parts • Application to SIGINT

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

4. Portability Issues • CORBA waivers • Ports - components do not communicate through CORBA • Communication paths can avoid CORBA messaging • Efficiency • Legacy • Too much of the waveform is not implemented in component software • Proprietary code • Logic in FPGA, DSPs and ASICs • Richness of Domain Profile • CF must support all potential XML configurations • Inhibits full spec implementation

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

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

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

8. SDR Middleware • What • CCM interface • SCA compliant • Revised GUI • Streamlined to this app • Why • FPGA connection • Infrastructure for Data Reorg and multiprocessors • Visualization and test interface • CORBA interfaces • CCM Services • Embeddable (Lite) • Scaleable • Data Streaming/Flow • Data Reorg • D&C SCE CCM C,D,E,F,G A,B,G  SCA A,B,E,G

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

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

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

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

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

14. Roadmap of Primary Specs

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

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

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

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

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

21. Characteristic Conceptualization • Characterize waveforms into waveform attributes such that one could describe a waveform by combinations of types and parameters: • Unfolded table dimension = x1* x2 * x3*…* xN • Waveforms can be thought of as unique paths in this 2-space • Maximum size is cross-product of columns A B

22. digital analog x2 = packet content x2 = packet content voice voice digital data data analog x5 = signal type FDMA CDMA TDMA DAMA x1 = air interface FDMA CDMA TDMA DAMA x1 = air interface with analog data, QPSK modulation cannot be used Waveform configuration in N dimensions consistent attributes inconsistent attributes

23. Next 3 dimensions x6 = source coding x1 = TDMA x2 = digital xN = data x7 = channel coding x4 = spectral mask

24. Larger View of Waveform Characteristics Ontology Used at OMG Signal:SWRI classification (see http://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. FM3TR Example FM3TR Voice Transmission Mode FM3TR Data Transmission Mode

26. 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 Info proc channels IO channels Waveform channels From École de technologie supérieure, Jean Belzile Each Point in 2-Space Has OSI Level Meanings

27. Characteristic constraints can partitioned for parallel optimization • A waveform space of N dimensions can be represented as, c = {x1,x2, … ,xN}, where the set of N vectors need to be determined according to the constraint set K. A waveform may be represented as p(x1(3), x2 (5), x3 (2), …, xN (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. K, such that: • copt = {arg min J( c) |K1, arg min J( c) |K2, ...}, • P1 P2 Pm • s.t.Ki are independent, mutually exclusive & cover all constraints, partitions Pn are therefore mutually exclusive where, • J( c) |K = J(Pj) |Kj m j=1

28. x1 P1 x2 x3 x4 P2 xn Reformulation of Problem… 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 A/D Access mode 2. By choosing different root nodes, the mesh network can be viewed as a different tree All All A D TDMA FDMA CDMA A A D D D FDMA TDMA Info Sec no Info Sec yes

29. Spec and Implementation Generation 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 Requirements Other Alternatives Waveform Specification Formally Validatable Automated Process Other Alternatives Waveform Implementation Automated Process

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

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

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

33. Roadmap to Implement SCA Partitioned by Viewpoint Viewpoint: Client Waveform Component System boot/mgt Device Knowledge Required Use-case CF Interfaces Used Meta-data Formats Used Testing Issues

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

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

36. COMINT Receiver

37. RWR/ESM/ELINT Receiver

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