© 2003 Mercury Computer Systems, Inc.

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

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

Jeff Smith, Jim Kulp, Murat Bicer, Tansu DemirbilekMercury Computer Systems, Inc.

199 Riverneck Road, Chelmsford, MA 01824

John Anton, Kestrel Technology

Military Communications Conference“Mobile Communications and Military Transformation”

Washington, D.C. - March 25, 2003

2

ProblemProblem 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” SDRElements 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. SIGINT

and C4I

4

Portability IssuesPortability 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” SDRElements 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. SIGINT

and C4I

6

Scalable CCM/Embedded Standards Issue Scalable CCM/Embedded Standards Issue

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)

Issue Solution

7

SCA extensions can address issuesSCA extensions can address issues

WDEs, Tool Kits

SCA

SCA extensions

CommonPrim. Ctrl.

Device Def.D&C

Answer

8

SDR Middleware 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

A. CORBA interfacesB. CCM ServicesC. Embeddable (Lite)D. ScaleableE. Data Streaming/FlowF. Data ReorgG. D&C

A,B,G

A,B,E,G

CCM

SCA

C,D,E,F,GSCE

9

Data Parallel Middleware Embedded Computer Support

Data Parallel Middleware Embedded Computer Support

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

Need Solution

10

Scalable Heterogeneous Components

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

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” SDRElements 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. SIGINT

and C4I

12

Lt. Log, Lt. CCM, Lt. Services, Deployment & Config., SWRadio, Parts of UML 2.0,

CORBA Variants, …

13

Software Radio StandardsSoftware 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 SpecsRoadmap of Primary Specs

Activity

Deployment & Configuration

RFP SWRADIO

RFP

Lightweight Services

RFP

Lightweight Log Service

RFC

Lightweight CCM RFP

**

Preparation of RFP by TF 11/01 2-6/02 5-6/02 5-6/02 7-11/02

Review by TC,

Approval of RFP by Architecture Board * 1/02 6/02 6/02 6/02 11/02

TC votes to issue RFP * 1/02 6/02 6/02 6/02 11/02

Public Comments due 9/02

LOI to submit to RFP due 4/02 10/02 8/02 2/03

Initial submissions due * 8/02 1/03 10/02 3/03

Voter registration closes 9/02 1/03 11/02 3/03

Initial submission presentations 9/02 1/03 11/02 3/03

Preliminary evaluation by TF

Revised submissions due * 3/03 5/03 3/03 5/03

Revised submission presentations 3/03 6/03 3/03 6/03

Final evaluation and selection by TF

Recommendation to AB and TC

Review by TC,

Approval by Architecture Board

TC votes to recommend specifications 5/03 8/03 5/03 10/02 7/03

BOD votes to adopt specifications 6/03 9/03 6/03 11/02 8/03

Finalization Task Force 6/04 9/04 6/04 11/03 8/04

shaded areas indicate completed task

* “Three week rule”

** LW CCM RFP dates are estimated; RFP content dependent on Deployment RFP.which may affect timing

15

Co-chair

Collaboration

Standard Reference ModelsStandard Reference Models

Proposed Design Behavior (states, sequences/roles)

Responsibility Levels Contained InformationOMG, SDRF Architectural Interfaces, DTDs

(components, properties, relationships)

CRC, SDRF Implementation Platform-specific code

Required to validate OMG spec and behavior Early reference implementation already used for SCA compliance testing SCA Interoperability

16

Elements of a “Softer” SDRElements 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. SIGINT

and C4I

17

18

SW Radio Definitions Have Increasing Levels of Reprogramability

SW Radio Definitions Have Increasing Levels of Reprogramability

DynamicDeployment,

Plan &Reconfig

Waveform Air prog.

Static Config &Plan

Up/downConversion

withinFabric

ReconfigWaveforms

WithinFabric

Waveform/Channel

Waveform/Modem

Waveform/Prog.

Modem

Cluster A

The Future…Today’s

Technology

Waveform/Prog.

Receiver

19

Elements of a “Softer” SDRElements 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. SIGINT

and C4I

20

Motivation for “Softer” Waveform Generation Technology & Reusable Components

Motivation for “Softer” Waveform Generation Technology & Reusable Components

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

If you are a: You get:

21

Characteristic ConceptualizationCharacteristic 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

Air interface (x1=5)

Packet content (x2=2)

Connection type (x3=3)

Access mode (x4=3)

Signal type (x5=2) …

FDMA voice networking hopping analog

CDMA data point-to-point non-hopping digital

TDMA broadcasting direct sequence

DAMA

Push-to-talk

Trunked

…

…

A

B

22

x 5 = sig

nal type

analog

digital

x2 = packetcontent

CDMAFDMA TDMA

data

voice

DAMA x1 = air interface

Waveform configuration in N dimensionsWaveform configuration in N dimensions

consistent attributes

inconsistent attributes

x2 = packetcontent

CDMAFDMA TDMA

data

voice

DAMA x1 = air interface

analog

digital

with analog data, QPSKmodulation cannot be used

23

Next 3 dimensionsNext 3 dimensions

x6 = source coding

x4 = spectral maskx 7 = ch

annel coding

x1 = TDMAx2 = digitalxN = data

24

Larger View of Waveform Characteristics Ontology Used at OMG

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 & dataConnection type: networking, point-to-point, broadcast, multicastSwitching type: circuit, packetLOS: yes, beyondAccess mode: push to talk, trunked, DAMA,TDMA,CDMA (direct sequence, multi-carrier), CSMA, FDMASecurity: transmission, communication, noneSpectral mask: center frequency, instantaneous frequency, bandwidth, powerChannel coding: convolutional, turbo, Reed Solomon, CRC, noneRouting: RF packets, IO packetsSource coding: yes, noChannel estimation: adaptive, trained, blind, nonePower control: open loop, closed loop, none

25

FM3TR ExampleFM3TR Example

Packet Content

Transmission Type

Connection Type

LOS Access Mode

Security Freq Hopping

Channel Coding

Source Coding

Channel Estimation

Power Control

Transmit Diversity

Voice

Analog Networking Exist PTT Transmission Yes Convolutional CVSD Adaptive Open Loop

STTD

Data Digital Point to Point

Beyond FDMA Communication No Turbo MPEG Trained Closed Loop

None

Voice & Data

Broadcast TDMA None Reed Solomon

MP3 Blind None

Multicast CDMA None None None

Packet Content

Transmission Type

Connection Type

LOS Access Mode

Security Freq Hopping

Channel Coding

Source Coding

Channel Estimation

Power Control

Transmit Diversity

Voice

Analog Networking Exist PTT Transmission Yes Convolutional CVSD Adaptive Open Loop

STTD

Data Digital Point to Point

Beyond FDMA Communication No Turbo MPEG Trained Closed Loop

None

Voice & Data

Broadcast TDMA None Reed Solomon

MP3 Blind None

Multicast CDMA None None None

FM3TR Data Transmission Mode

FM3TR Voice Transmission Mode

26

Each Point in 2-Space Has OSI Level Meanings

Each Point in 2-Space Has OSI Level Meanings

Characteristic type

Characteristicparam

Protocol stack Protocol stack

App

licat

ion

App

licat

ion

App

licat

ion

Symbol streams Symbol streams

SDR equipment

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Sof

twar

eH

ardw

are

Software

Hardware

Phy

sica

l

Phy

sica

l

Link

Net

wor

k

Tra

nspo

rt

Ses

sion

Pre

sent

atio

n

App

licat

ion

Link

Net

wor

k

Tra

nspo

rt

Ses

sion

Pre

sent

atio

n

Antenna

Waveform channels

Info procchannels

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

Characteristic constraints can partitioned for parallel optimization

Characteristic constraints can partitioned for parallel optimization

A waveform space of N dimensions can be represented as, x1,x2, … ,xN}, where the set of N vectors need to be determined according to the constraint set 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. such that:

opt = {arg min J( ) |, arg min J( ) |

}, P1 P2 Pm

s.t. Ki are independent, mutually exclusive & cover all constraints, partitions Pn are therefore mutually exclusive where,

J( ) |J(Pj) |jj=1

m

28

Reformulation of Problem…Reformulation of Problem…

A/D

Access mode

All All

A D

A AD D

TDMA FDMA CDMA

TDMA FDMA

InfoSecno

InfoSecyes

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

x1

x2

x3

x4

xn

P1

P2

29

Spec and Implementation GenerationSpec and Implementation Generation

Requirements

Waveform Specification

Waveform Implementation

Other Alternatives

Other Alternatives

Formally Validatable

Automated Process

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

Waveform Generation Technology Summary 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” SDRElements 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. SIGINT

and C4I

32

SCA Implementation Viewpoints for Interoperability and Portability

SCA Implementation Viewpoints for Interoperability and Portability

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

Types of software written to use an SCA-compliant environment: For each we describe:

No viewpointNo viewpointBut UIBut UI

CF or PlatformCF or PlatformDeveloperDeveloper

PlatformPlatformDeveloperDeveloper

WaveformWaveformDeveloperDeveloper

SCA Dev.GuideViewpoints

33

Roadmap to Implement SCA Partitioned by Viewpoint

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

None Port, LifeCycle, TestableObject, Port Supplier, PropertySet, Resource, Resource Factory

DomainMgr., DeviceMgr.

DeviceMgr (used); Device, ExecutableDevice & LoadableDevice (implemented)

None Create SAD, reference SPD

IDL, SCD & SPD files SPD, 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

KnowledgeRequired

Use-case

CFInterfacesUsed

Meta-dataFormatsUsed

TestingIssues

Viewpoint:

34

Elements of a “Softer” SDRElements 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. SIGINT

and C4I

35

SDR Forms Lower Levels of One Projected C4I Protocol Stack

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. C4I information (registry database)

Coalition waveform architecture leverages standards, communication, networking and modeling investments.

36

COMINT ReceiverCOMINT Receiver

37

RWR/ESM/ELINT ReceiverRWR/ESM/ELINT Receiver

38

Summary Summary

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

Issues Suggestion