Transcript Software Communication Architecture and HPEC “all the world’s a network and its people are merely nodes…” Dr.

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
© 2001 Mercury Computer Systems, Inc.
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
© 2001 Mercury Computer Systems, Inc.
2
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.
© 2001 Mercury Computer Systems, Inc.
3
Software Radio Functional Architecture
BLACK
RED
High-Speed Switch Fabric
d
Software
Modem
Antenna
Interface
d
RF/IF
A/D & D/A
d
d
d
Link
Processing
Modem
Message
Net
Processing
Security
Adaptive
Proc.
c
c
Control
Interface
c
c
Control Bus
c
Control
Interface
Source: SDR Forum, modified by Mercury Computer Systems Inc.
© 2001 Mercury Computer Systems, Inc.
4
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
© 2001 Mercury Computer Systems, Inc.
An SDR terminal can be used
for any wireless communication
by downloading new software
5
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
© 2001 Mercury Computer Systems, Inc.
6
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
© 2001 Mercury Computer Systems, Inc.
7
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, reprogrammable 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)
© 2001 Mercury Computer Systems, Inc.
8
Standard Reference Models
Responsibility
OMG, SDRF
Levels
Architectural
Contained Information
Interfaces, DTDs
(components, properties, relationships)
Co-chair
New contract
Design
Behavior (states, sequences/roles)
Carleton/
Oversight board
PIM  Action semantics, ops
CRC
© 2001 Mercury Computer Systems, Inc.
Implementation
PSM  Platform specific code
9
Software Radio Standards

Object Management Group

Mercury is actively leading
•
•
•

SW Radio DSIG now standardizing Software Communications Architecture (SCA)
•

Data parallel/high-performance CORBA – Jim Kulp
Software Radio DSIG – Jeff Smith
Data flow and math framework in UML 2.0 – Jeff Smith
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
TAG/CCB
Mobile
Software
Working
Radio
Group
SIG
SCA
SCA
© 2001 Mercury Computer Systems, Inc.
10
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
© 2001 Mercury Computer Systems, Inc.
11
SCA Goal Summary
Goal
Description
Common
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
© 2001 Mercury Computer Systems, Inc.
12
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
© 2001 Mercury Computer Systems, Inc.
13
Computational Complexity
Channel
Modem DSP
(Multiple)
+
Interferenc
e
Cancellatio
n
(Co-site/
Co-channel)
+
Other
Adaptive
Processing
(Smart
Antennas)
Channel
Modem DSP
(Multiple)
+
Interferenc
e
Cancellatio
n
(Co-site/
Co-channel)
Channel
Modem DSP
(1-4)
Waveform
Complexity
LPI/LPD Waveform
Wideband Waveform
Platform
Complexity
Narrowband Waveform
Tactical Vehicle
Combat Net Radio
© 2001 Mercury Computer Systems, Inc.
14
Network Radio
Access Node
(Base Station)
Scalable Channel Modem
Provide a switch-fabric interface directly
on the channel modem FPGA
Wide/Narrow Band
Rake Receiver FPGA
Single User Rake Receiver
A/D
D/A
Data
from
A/D
Up/Down
Conversion
DSP
DSP
tkq, q = 1:4 User #2
Single User Rake Receiver
Searcher
receiver
tkq, q = 1:4 User #1
Single User
Rake Receiver
Searcher
receiver
tkq, q = 1:4
Rake
Searcher
receiver
Finger
PPC
G4
aˆ
ˆaaˆ
aˆaaˆˆ
ˆ
a
y
ˆ kk1k13
receiveryk2a
Finger yk1 a
ˆ
receiver a
ˆ k1 k 2
tkq
bˆk
MRC
yk
MRC
yk
Rake
MRC
Interference
Canceller
yk
yk
ykq
aˆ kq
Adaptive Processor
Quad PPC/G4 CN’s
Wideband CDMA
base station example
Non-POSIX RTOS
No CORBA or SCA
© 2001 Mercury Computer Systems, Inc.
aˆ
receiver
Finger
yk3 k 4
Finger
receiver
y
Finger
yk2k4k 3
receiver
Finger
k4
receiver yyk3
Finger
yk1k4k 2
receiver
Finger
receiver yk2kk1 3
receiver yk3k 2k 4
Finger
POSIX RTOS
CORBA, SCA,
>3 GFLOPS
Rich Connection
to other Resources
User #K
yk4
FPGA
(ASIC)
User codes, SF, ...
15
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
File access
Core Framework (from Harris,
BAE, Motorola, Raytheon, etc.)
CORBA ORB
or SCE
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.
MC/OS and SAL/VSIPL function calls
© 2001 Mercury Computer Systems, Inc.
16
D
e
v
i
c
e
D
r
i
v
e
r
s
HW-specific device drivers provide
access to device for OS
SCA Software Structure
Applications
Operating
Environment (OE)
Non-CORBA
Modem
Components
RF
Core Framework (CF)
Commercial Off-the-Shelf (COTS)
Non-CORBA
Security
Components
Non-CORBA
I/O
Components
Physical
API
Modem
Modem
Components Adapter
MAC API
Link, Network
Components
Security
Security Security
Adapter Components Adapter
LLC/Network API
Security API
Core Framework IDL
CORBA ORB &
Services
(Middleware)
I/O
I/O
Adapter Components
LLC/Network API
I/O API
(“Logical Software Bus” via CORBA)
CF
Services &
Applications
CORBA ORB &
Services
(Middleware)
CF
Services &
Applications
Operating System
Operating System
Network Stacks & Serial Interface Services
Network Stacks & Serial Interface Services
Board Support Package (Bus Layer)
Board Support Package (Bus Layer)
Black Hardware Bus
© 2001 Mercury Computer Systems, Inc.
Link, Network
Components
Red Hardware Bus
17
Example Message Reception Flow
With and Without Adapters
(1)
Non-CORBA
Modem
(2)
Modem
Adapter
M
RF
(1)
CORBA
ModemDevice
M
(2)
(3)
Security
Adapter
(4)
Waveform
LinkResource
(5)
Security
Adapter
S
S
S
(3)
Message Reception Path (with Adapters)
(1) RF Interface to Modem
(2) non-CORBA Modem Interface
(3) CORBA Interface to Waveform Link M
(4) CORBA Interface to Security Adapter S
(5) Black-side non-CORBA Security Interface
(6) Red-side non-CORBA Security Interface
(7) CORBA Interface to Waveform Network S
(8) CORBA Interface to Host Adapter H
(9) non-CORBA Host Interface
© 2001 Mercury Computer Systems, Inc.
(6)
Non-CORBA
SecurityDevice
CORBA
SecurityDevice
S
(4)
(7)
Host
Adapter
(8)
(9)
Non-CORBA
Host
H
H
Waveform
NetworkResource
CORBA
(5) HostResource
Message Reception Path (without Adapters)
(1) RF Interface to Modem
(2) CORBA Interface to Waveform Link M
(3) CORBA Interface to Security S
(4) CORBA Interface to Waveform Network S
(5) CORBA Interface to Host H
Note: The design goal of a CORBA gateway “Adapter” is to
define the CORBA side of the gateway such that the eventual
replacement of the non-CORBA device and its Adapter does
not change the Core Framework CORBA interface.
18
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
© 2001 Mercury Computer Systems, Inc.
19
Core Framework Relationships
<<Interface>>
<<Interface>>
Port
LifeCycle
<<Interface>>
<<Interface>>
PropertySet
TestableObject
inherits
from
uses
<<Interface>>
Resource
0..*
<<Interface>>
ResourceFactory
Base Component
<<Interface>>
Device
devices
<<Interface>>
<<Interface>>
Application
ApplicationFactory
0..*
Framework Control
<<Interface>>
DeviceManager
log
0..1
applicationFactories
<<Interface>>
1..*
deviceManagers
DomainManager
<<Interface>>
Framework Services
File
<<Interface>>
Logger
Legend
<<Interface>>
Implemented by
Non-Core Applications
FileSystem
Core Framework Interface
<<Interface>>
StringConsumer
Implemented as
Core Application Services
<<Interface>>
FileManager
Core Framework Interface
© 2001 Mercury Computer Systems, Inc.
20
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.
© 2001 Mercury Computer Systems, Inc.
21
Domain Profile XML DTD Relationships
Profile Access
Software Profile
Deployment char. &
component connectivity
Hardware Profile
HW or SW Profile
<<Abstract>>
Domain Profile
0..n
CORBA SW Components
w/interfaces
Specific component
implementation
<<XML DTD>>
Software Assembly Descriptor
1..n
<<XML DTD>>
1..n
1
<<XML DTD>>
Software Component Descriptor
SoftwareProfile
Software Package Descriptor
0..1
1
SoftwareProfile
1..n
Reference to SAD,
SPD or DCD instance
<<XML DTD>>
Profile Descriptor
0..1
0..1
<<XML DTD>>
Device Package Descriptor
Class of a device
© 2001 Mercury Computer Systems, Inc.
0..n
0..n
1
DeviceConfigurationProfile
<<XML DTD>>
<<XML DTD>>
Properties Descriptor File
Device Configuration Descriptor
Components to start device &
to find a Domain Manager
Properties applicable to a
SW or device package
22
Current SCA Problem Metamodel Defines
Minimal CORBA Environment
© 2001 Mercury Computer Systems, Inc.
23
SCA Metamodel Refined into PIM
Operational User
Operational
UserInterface
Interface
SW
SWRadio
RadioReference
Reference Architecture
Architecture
IsConnectedTo
System Monitoring
System
Monitoring
Monitors
Manages
Agent
port ID
portID 1
*
InPort
1
Interface
Protocol
View
SystemMonitor
1
*
*
1
Implements
Dependency
OutPort
Coordinates
*
1..*
<<Interface>>
<<Interface>>
1
* Resource
* Provides 1
Port
Component
1
Defines *
2..*
HasExternal *
Has
2..*
Specif ies
*
1
Property
1
1
Allocates
DomainManager
*
1
1
1
Deploymentand
andConfiguration
Configuration
Deployment
AllocatesDevice
Connection
Installs
*
Defines
1
1
Assembly Software
Device
*
1
*
*
1 DeviceManager
Manages
1..*
*
I sI nstalledOn
Queries
1
Node
1..*
Applicat ionFactory
1
Waveform Applications
Applications
Waveform
I mplement edB y
InstanceOf
DomainWaveform
*
© 2001 Mercury Computer Systems, Inc.
<<Interfac e>>
Applicat ion
1
Instantiates
*
24
Domain Profile Parts Describe
SCA Metamodel Components
DomainManager
1
0..n
ApplicationFactory
<<create>>
Application
described by
1
+Proxy
Properties
Descriptor
described by
1
1
1..n
1
SW Package
Descriptor
1
1..n
SW Component
Properties
1
SW Assembly
Descriptor
described by
1
1
Types
Non-CORBA
Component
CORBA
Component
described by
1
1
SW Component
Descriptor
Types
Device Package
Descriptor
described by
1
Device
1
are used to access
the Provides ports
of a producer
Consumer
1
ResourceFactory
Resource
0..n
0..n
Uses
Port
connection
25
Producer
are provided by
1..n
1..n
described by a connection interface
element within the SAD
© 2001 Mercury Computer Systems, Inc.
Provides
Port
1
Programming SCA Compliant SW
UI asks for all
ApplicationFactory(s)
~~~~~
~~
~~~
XML
Files
~~~~
~~
ApplicationFactory
determines applicable
Device(s) on which to
load application code
defined in Domain Profile
• Application to instantiate
is chosen
• UI issues create( ) on
ApplicationFactory
ApplicationFactory
Domain Profile
load/execute,
allocate capacities
ApplicationFactory
connects the Port(s)
to form Application
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.
Device
Device
Device
Resource(s) bring
Port(s) into existence
Resource
1
Physical Device 1
Connects
resource ports
Resource
3
Resource
2
Physical Device 2
Resources are then configured,
initialized and started
© 2001 Mercury Computer Systems, Inc.
26
Bring resources
into existence on
physical devices
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, realtime 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
© 2001 Mercury Computer Systems, Inc.
27
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
© 2001 Mercury Computer Systems, Inc.
28