Software Communication Architecture and HPEC

© 2001 Mercury Computer Systems, Inc.

Software Communication Architecture and HPEC

Software Communication Architecture and HPEC

Dr. Jeffrey E. SmithMurat Bicer

Mercury Computer Systems, Inc.

HPEC – November 2001

“all the world’s a network and its people are merely nodes…”

2© 2001 Mercury Computer Systems, Inc.

AgendaAgenda

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


Software Defined RadioSoftware 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.


High-Speed Switch Fabric

Software Radio Functional ArchitectureSoftware Radio Functional Architecture

Source: SDR Forum, modified by Mercury Computer Systems Inc.

RF/IFA/D & D/A

RF/IFA/D & D/A SecuritySecurity Message

ProcessingMessage

ProcessingAntennaInterfaceAntennaInterface

c c c

d d d

Control Bus ControlInterface

BLACK

ControlInterface

LinkProcessing

LinkProcessingModemModem

c

d

SoftwareModem

SoftwareModem

AdaptiveProc.

AdaptiveProc.

d

c

RED

Net


Why SDR?Multi-Billion Dollar Market for …

Why SDR?Multi-Billion Dollar Market for …

An SDR terminal can be used for any wireless communication by downloading new software

An SDR base station can communicate with any

kind of terminal (i.e. Cellular, Telephone,

PDA) by downloading new software


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

Radio System (JTRS) program

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


The SCA Specification …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


The SCA Specification …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)


Co-chair

Carleton/Oversight board

Standard Reference ModelsStandard Reference Models

New contract Design Behavior (states, sequences/roles)

Responsibility Levels Contained InformationOMG, SDRF Architectural Interfaces, DTDs

(components, properties, relationships)

PIM Action semantics, opsCRC Implementation

PSM Platform specific code


Software Radio StandardsSoftware 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

Mobile

Working

Group

SCA

Software

Radio

SIG

SCA

TAG/CCB


Why SCA?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


SCA Goal SummarySCA Goal SummaryCommon 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 & Reuse

Allow for the maximum possible reuse of SW and the use of common waveform software among various implementations and with waveforms being portable between implementations

Goal Description


Overlap Between SDR and HPECOverlap 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


Computational ComplexityComputational Complexity

Combat Net RadioTactical Vehicle

Network RadioAccess Node(Base Station)

Narrowband Waveform

Wideband Waveform

LPI/LPD Waveform

Channel Modem DSP

(1-4)

Channel Modem DSP(Multiple)

+InterferenceCancellation

(Co-site/Co-channel)

Channel Modem DSP(Multiple)

+InterferenceCancellation

(Co-site/Co-channel)

+Other

AdaptiveProcessing

(SmartAntennas)

PlatformComplexity

WaveformComplexity


Scalable Channel ModemScalable Channel Modem

A/D D/A

FPGA(ASIC)

DSP DSP

Searcherreceiver

kq, q = 1:4

User #K

Finger receiver Finger receiver

yk4

4ˆkaFinger receiver Finger receiver

yk3


yk2


yk1

1ˆka

MRCMRC

yk

Searcherreceiver

kq, q = 1:4

User #2

Finger receiver Finger receiver

yk4


yk3


yk2


yk1

1ˆka

MRCMRC

yk

DatafromA/D

RakeSearcherreceiver

kq, q = 1:4

User #1

Rake

MRC

Rake

MRCyk

InterferenceCanceller

ykq

yk

kq

kqa

User codes, SF, ...Rake Receiver FPGA

kb

Single User Rake Receiver

Adaptive ProcessorQuad PPC/G4 CN’s

Wideband CDMAbase station example



Provide a switch-fabric interface directly on the channel modem FPGA

PPCG4

POSIX RTOSCORBA, SCA, >3 GFLOPS

POSIX RTOSCORBA, SCA, >3 GFLOPSRich Connection

to other Resources

Non-POSIX RTOSNo CORBA or SCA

Wide/Narrow Band

Up/Down Conversion

Finger receiver

yk1

1ˆka

yk4

4ˆkayk3

3ˆkayk2

2ˆka


Software ArchitectureSoftware Architecture

CORBA ORB or SCE

OS that supports SCA Application Environment Profile (AEP) including PAS/MPI API and algorithm libraries. This includesMC/OS on target and VxWorks on host.

Applications (OFDM, interference cancellation, smart antenna) and Tools

OS access limitedto SCA AEP OS access

unlimitedOS access unlimited

Core Framework (from Harris,BAE, Motorola, Raytheon, etc.)

Device Drivers

File access

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

MC/OS and SAL/VSIPL function calls HW-specific device drivers provide access to device for OS


SCA Software StructureSCA Software Structure

Core Framework (CF)

Commercial Off-the-Shelf (COTS)

Applications

OperatingEnvironment (OE)

Red Hardware Bus

CFServices &

Applications

CORBA ORB &Services

(Middleware)

Network Stacks & Serial Interface Services

Board Support Package (Bus Layer)

Black Hardware Bus

CFServices &

Applications

CORBA ORB &Services

(Middleware)

Network Stacks & Serial Interface Services

Board Support Package (Bus Layer)

Operating System

Core Framework IDL

Non-CORBAModem

Components

Non-CORBASecurity

Components

Non-CORBA I/O

Components

RF

ModemComponents

Link, NetworkComponents

SecurityComponents

ModemAdapter

SecurityAdapter

SecurityAdapter

I/OAdapter

I/OComponents

MAC API LLC/Network API LLC/Network API

Link, NetworkComponents

Security API

Operating System

Physical API

I/O API

(“Logical Software Bus” via CORBA)


CORBASecurityDevice

HostAdapter

RF

Non-CORBAHost

CORBA HostResource

WaveformNetworkResource

Waveform LinkResource

Non-CORBAModem

CORBAModemDevice

S

S

S

SM

M

(2) (3) (4) (5)

(1)

(1)

(2)

(3) (4)

(5) (6)

(7) (8)

(9)

Message Reception Path (with Adapters) (1) RF Interface to Modem (2) non-CORBA Modem Interface (3) CORBA Interface to Waveform Link (4) CORBA Interface to Security Adapter (5) Black-side non-CORBA Security Interface (6) Red-side non-CORBA Security Interface (7) CORBA Interface to Waveform Network (8) CORBA Interface to Host Adapter (9) non-CORBA Host Interface

Message Reception Path (without Adapters) (1) RF Interface to Modem (2) CORBA Interface to Waveform Link (3) CORBA Interface to Security (4) CORBA Interface to Waveform Network (5) CORBA Interface to Host

M

S

S Note: The design goal of a CORBA gateway “Adapter” is todefine the CORBA side of the gateway such that the eventualreplacement of the non-CORBA device and its Adapter doesnot change the Core Framework CORBA interface.

ModemAdapter

SecurityAdapter

SecurityAdapter

H

H

H

M

S

S

H

Non-CORBASecurityDevice

Example Message Reception Flow With and Without Adapters

Example Message Reception Flow With and Without Adapters


SCA Core Framework DefinitionSCA 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


Core Framework RelationshipsCore Framework Relationships

inheritsfrom

uses<<Interface>>

Resource<<Interface>>

ResourceFactory

<<Interface>>

TestableObject<<Interface>>

PropertySet<<Interface>>

LifeCycle<<Interface>>

Port

Base Component

<<Interface>>

Logger

<<Interface>>

FileManager

<<Interface>>

File

<<Interface>>

StringConsumer

<<Interface>>FileSystem

Core Framework Interface

Implemented asCore Application Services

Legend

Core Framework Interface

Implemented byNon-Core Applications

Framework Services

deviceManagers

uses

<<Interface>>

Device

<<Interface>>

DomainManager

<<Interface>>

ApplicationFactory

1..*

devices

0..* applicationFactories

fileMgr1

applications

0..*

fileMgr

0..1

log0..1

<<Interface>>

Application

<<Interface>>

DeviceManager

Framework Control

0..*


SCA Domain ProfileSCA 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.


Domain Profile XML DTD RelationshipsDomain Profile XML DTD Relationships

Software Assembly Descriptor<<XML DTD>>

Domain Profile<<Abstract>>

0..n0..n

Device Configuration Descriptor<<XML DTD>>

Profile Descriptor<<XML DTD>>

1

SoftwareProfile

1 DeviceConfigurationProfile

Device Package Descriptor<<XML DTD>>

Software Package Descriptor<<XML DTD>>

1..n1..n1..n1..n

1..n1..n

11SoftwareProfile

Properties Descriptor File<<XML DTD>>0..n0..n

0..n0..n

Software Component Descriptor<<XML DTD>>

0..10..1

0..10..1

0..10..1

Profile Access

Software Profile

Hardware Profile

HW or SW Profile

Class of a device Properties applicable to a SW or device package

Components to start device & to find a Domain Manager

CORBA SW Components w/interfaces

Specific component implementation

Deployment char. & component connectivity

Reference to SAD, SPD or DCD instance


Current SCA Problem Metamodel Defines Minimal CORBA Environment

Current SCA Problem Metamodel Defines Minimal CORBA Environment

CF::Services

SW Component HW Device

HW Device

0..*0..*

has

0..*0..*

responsible for

Capacity

HW Device

1..*1..*

command & control and/or data messaging

SW Application

HW Device

0..*0..* 0..*0..*

SW Application

0..*0..* 0..*0..*

0..*

0..*

0..*

0..*

Port

SW Component

1..*1..*

has dependencies to other

0..*0..*

Propertrydefinitionvalue

0..*0..*

2..n2..n

Port

0..*0..*

2..n2..nCF::Resource CF::ResourceFactory CF::Device

CORBA Services Non-CF

Event

InformationEventeventLeveltimeproducermsg

ThresholdEvent

PerformanceEvent

StateEventstatestatusalarms

uses

executes on

consumes

may issue

QOSEvent

producersconsumers


Protocol

OutPortInPort

Connection

Node

Dependency

Port<<Interface>>

Interface

Property

Device

* 1*port ID portID 1

IsConnectedTo

2..*

1

2..*

1

Specif ies

1..*1..*

DomainWaveform

Assembly Software

*

1

*

1Defines

*1 *1IsInstalledOn

*

1

*

1

HasExternal

ImplementedBy

Component<<Interface>>* 1* 1Provides

2..*2..*

1

1..*

Implements

*

1

*

1Has

Agent

*

1SystemMonitor

* 1* 1

Manages

Resource*1 *1

*

1

*

1

Defines

DomainManager

*

1

*

1

Coordinates

* 1* 1Allocates

Applicat ion<<Interface>>

1* 1*

InstanceOf

Applicat ionFactory

1..*

1

1..*

1

Installs

*

1

*

1

Instantiates

DeviceManager* 1* 1Manages

*

1

*

1

AllocatesDevice

*

1

Queries*

1

View

Monitors

*

1

1

1..*

SW Radio Reference Architecture

Waveform Applications

Deployment and Configuration

System Monitoring

Operational User Interface

SCA Metamodel Refined into PIMSCA Metamodel Refined into PIM

SW Radio Reference ArchitectureOperational User Interface

System Monitoring

Deployment and Configuration

Waveform Applications


Domain Profile Parts Describe SCA Metamodel Components

Domain Profile Parts Describe SCA Metamodel Components

DomainManager

ApplicationFactory

1

0..n

1

0..n

Non-CORBA Component SW Component

Descriptor

CORBA Component

11 11

described by

ResourceFactory

SW Assembly Descriptor

Application<<create>>

11 11

described by

SW Package Descriptor

SW Component

1..n

1

1..n

+Proxy 1

11 11

described byProperties

11..n 11..n

Properties Descriptor 11 11

described by

Consumer

Resource

Uses Port

0..n0..n

1..n1 1..n1

are used to access the Provides ports

of a producer ProducerProvides

Port

0..n0..n

connection

11..n 11..n

are provided by

described by a connection interface element within the SAD

Types

Types

DeviceDevice Package Descriptor 11 11

described by


Programming SCA Compliant SWProgramming SCA Compliant SW

DeviceDeviceDevice

ApplicationFactory

~~~~~~~~~~XMLFiles~~~~~~

Domain Profile

Resource2

Resource1

Resource3

Physical Device 1

Physical Device 2

load/execute,allocate capacities

ApplicationFactory determines applicable Device(s) on which to load application code defined in Domain Profile

Bring resources into existence on physical devices

Resource(s) bring Port(s) into existence

Connects resource ports

ApplicationFactory connects the Port(s) to form Application

Resources are then configured, initialized and started

UI asks for all ApplicationFactory(s)

• Application to instantiate is chosen

• UI issues create( ) on ApplicationFactory

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.


HW/SW Standards Under DevelopmentHW/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


SummarySummary

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

Documents

Software Communication Architecture and HPEC