Overview of Recent
Advances in SDR
Standardization
“SDR for Everyone”
A. Tansu Demirbilek, Dr. Jeffrey E. Smith– Mercury Computer Systems
Dr. Jean Belzile – Ecole de Technologie Superieure
David Roberge – ISR Technologies
© 2004 Mercury Computer Systems, Inc.
What does this tutorial offer?
An overview of:
 Recent advances in SDR
community
 Current enabling technologies and
state of art
 Where SDR standards are evolving
 What is meant by “SDR for
everyone”
© 2004 Mercury Computer Systems, Inc.
2
Agenda
1. Introduction
1. SDR Background
2. Ongoing SDR Standardization Activities
3. JTRS SCA
2. Enabling Technologies
1.
2.
3.
4.
UML
Component Based Distributed Applications
Model Driven Architecture
Heterogeneous Processing Platforms
© 2004 Mercury Computer Systems, Inc.
3
Agenda
3. OMG Software Radio Standard
1.
2.
3.
4.
Introduction
UML Profile
Platform Independent Model
Platform Specific Model
© 2004 Mercury Computer Systems, Inc.
4
Section 1.1
“SDR Background”
© 2004 Mercury Computer Systems, Inc.
What is SDR?

Acronym for “Software Defined Radio”
Provides:
• Interoperability
• Reconfigurability
• Portability
of component based waveform applications

Promises achieved by “Software
Communications Architecture”,
mandated by the Army’s Joint Program
Office (JPO)
© 2004 Mercury Computer Systems, Inc.
6
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
Processing
Security
Adaptive
Proc.
c
c
Control
Interface
© 2004 Mercury Computer Systems, Inc.
c
c
Control Bus
7
c
Control
Interface
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
© 2004 Mercury Computer Systems, Inc.
An SDR terminal can be used
for any wireless communication
by downloading new software
8
Why SDR?



The rapid pace of technological advances
render communications devices obsolete
shortly after production
Interoperability is needed between devices
that are implemented in different
technologies
Increasing traffic rates and decreasing
amounts of spectrum require more
sophisticated signal processing
algorithms
© 2004 Mercury Computer Systems, Inc.
9
SDR Goals






Interoperability of different SDR systems
Portability of applications software
between different SDR implementations
Upgradeability in terms of easy technology
insertion
Reduced development time of new
waveforms through the ability to reuse
design modules
Reduced system acquisition, operation and
supportability costs
ANSWER: Standard Interfaces (APIs)
© 2004 Mercury Computer Systems, Inc.
10
Section 1.2
“Ongoing SDR Activities”
© 2004 Mercury Computer Systems, Inc.
Ongoing SDR Activities







GLOMO (Not active anymore)
OBSAI
(www.obsai.org)
CPRI
(www.cpri.info)
Digital IF
(www.digitalif.org)
SDRF
(www.sdrforum.org)
SCA
(jtrs.army.mil)
OMG Specs
(www.omg.org)
© 2004 Mercury Computer Systems, Inc.
12
Section 1.3
“JTRS Software
Communications
Architecture”
© 2004 Mercury Computer Systems, Inc.
Software Communications
Architecture








An open, standard, well-defined architecture
Component based approach to waveforms
Improves interoperability by sharing waveform
components between radios
Supports multiple domains and multiple bands
Increases operational flexibility
Maximizes independence of software from
hardware
Provide upgradeability with easy technology
insertion and capability upgrades
Extendible to new waveforms and hardware
© 2004 Mercury Computer Systems, Inc.
14
SCA Components
HCI
Binary
XML
Waveform
Core Framework:
Framework Control &
Framework Service Interface
SCA Interfaces
(UML/IDL)
CORBA ORB
and Services
Application
Environment
Profile
OS (function) that supports SCA
Hardware
© 2004 Mercury Computer Systems, Inc.
15
SCA Structural Details



Specifies APIs to support distributed applications for flexible,
re-programmable communication capabilities
Specifies a common framework to build-up, configure, connect
and tear-down distributed, embedded radio applications
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
© 2004 Mercury Computer Systems, Inc.
16
Joint Tactical Radio System
(JTRS)
Homeland Security
Space
Subsurface
Cluster 4 (Airborne)
Cluster 3 (Maritime/Fixed site)
Cluster 2/5 (Handheld, Manpack, Embed)
Cluster 1 (Ground Vehicle, Helicopters)
< 2 MHz
2 MHz – 2 Ghz
2 - 6 GHz
6–15/55 GHz
and beyond
Object Management Group (OMG) (approx. 800 Int’l members)
Software Defined Radio Forum (SDRF) (Approx. 130 members)
SCA Foundation
Definition SCA 1.0
SCA 2.0
Source: JTRS JPO, Joint Program Status Update, 30 June 2003
© 2004 Mercury Computer Systems, Inc.
SCA 2.1
SCA 2.2
17
SCA X…n
Software Radio Standards
TAG/CCB
Software
Working
Radio
Groups
DSIG
SCA
SCA
© 2004 Mercury Computer Systems, Inc.
18
Business Model
J T R S W a v e fo rm S o ftw a re D e v e lo p e r
W a ve fo rm S o ftw a re
N e tw o rk
C o n tro l a n d
A d m in
S o ftw a re
W a v e fo rm
HMI
S o ftw a re
IN F O S E C
HW
D ependent
C ode
G FE
C o m p u te r
P o rta b le
C ode
J T R S T e c h n o lo g y L a b o ra to ry (J T e L )
W a v e fo rm
T&E
JTR
S y s te m
In te g ra to r
In fo rm a tio n
R e p o s ito ry
O E /J T R S e t
T&E
W a ve fo rm
R e p o s ito ry
J T R S e t M a n u fa c tu re r
O p e ra tin g E n viro n m e n t (O E )
R e d S id e
(p ro ce ss in g ,
vo co d e rs ,
b a se b a n d
In te rfa c e s , … )
E xte rn a l B a se b a n d
E q u ip m e n t
© 2004 Mercury Computer Systems, Inc.
IN F O S E C
B la c k S id e
(P ro ce s sin g ,
m odem , R F
in te rfa ce s, … )
co u p le r
E x te rn a l R F E q u ip m e n t
R a d io
19
JTeL Primer by SPAWAR
SCA Evolution

Now: SCA is a fairly large specification
covering broad aspects of a system
 Hard to have commercial implementations
 Hard to control evolution of the spec

Future: SCA has been sliced into pieces
for OMG standardization
 “OMG Suite of Specs”
 SWRadio, D&C, Lw CCM, Lw Log, Lw
Services
© 2004 Mercury Computer Systems, Inc.
20
Section 2
“Enabling Technologies”
© 2004 Mercury Computer Systems, Inc.
Enabling Technologies Overview




UML
Component Based Distributed
Applications
Heterogeneous Processing
Platforms
MDA
© 2004 Mercury Computer Systems, Inc.
22
Section 2.1
“UML”
© 2004 Mercury Computer Systems, Inc.
What is UML



UML = “Unified Modeling
Language”
Graphical modeling language
Does not specify design
methodology
 Rational Unified Process (RUP) developed as
one methodology for using UML
 Successor to many Object Oriented (OO)
Design & Analysis methods

Standardized by the OMG
© 2004 Mercury Computer Systems, Inc.
24
What is UML used for?

Provides a common language for
functional specifications
 Natural language is not precise enough
 Code is too detailed

Highlight important details
 Provide overall view of a system

Logical decomposition of large projects
 Focus on details without losing overall goals
 Separate implementation task into parts
 Build individually testable components
© 2004 Mercury Computer Systems, Inc.
25
UML Diagram Hierarchy
UML
Package
Use Case
Structure
Behavior
Class
Deployment
Activity
Component
State
Sequence
Interaction
Collaboration
© 2004 Mercury Computer Systems, Inc.
26
Interaction
How is it used?

Graphical notation to communicate
design
 Diagrams highlight particular aspect of design

Assist in communication
 Customer
 Other developers


Documentation of design process
CASE tools
 Code generation
 Reverse engineering
 Code merging
© 2004 Mercury Computer Systems, Inc.
27
What does it look like?
1
Interface
Abstract
Client
Place Order
Salesperson
Customer
Check Status
Fill Order
Implementing
Establish Credit
Original
Create
New
Mesage
Self-Destruct
Return
Delete
© 2004 Mercury Computer Systems, Inc.
28
Shipping Clerk
Supervisor
Section 2.2
“Component Based
Distributed Applications”
© 2004 Mercury Computer Systems, Inc.
What’s the idea?
The idea is simple:
 If we build the parts of our system to welldefined specification, then it should be
easy to assemble these pieces to create a
system
 It should also be relatively easy to replace
one part of a system with another part that
meets the same specification, after the
system is built
© 2004 Mercury Computer Systems, Inc.
30
What’s new?

This doesn’t sound so new!? Even in
1995.
 But “well-defined” enough to “easily assemble”
requires more specification than an interface in a
header file at compile time!
 True replaceability (plug & play) requires last-moment
and fine-grained linkages between pieces of software
 Assembly out of parts from different sources requires
a new way to describe and deploy the software
 None of this is accomplished with “object oriented
languages” or “client/server systems”.
© 2004 Mercury Computer Systems, Inc.
31
What’s a component?

A software package which offers services through interfaces

A reusable part that provides the physical packaging of
implementation elements

An independently deliverable package of software operations
that can be used to build applications or larger components

A unit of software that is pre-built, packaged, self-describing,
which can be individually deployed or updated or replaced in
the field. It can be sent as an email attachment
© 2004 Mercury Computer Systems, Inc.
32
Component Packaging
“Engineering”
IDL
User
Code
Compiler
Generated
Code
Shared
Library or
Executable
IDL/CIDL
Compiler
Component
Descriptor
Packaging
Tool
CIDL
© 2004 Mercury Computer Systems, Inc.
Default
Configuration
33
Component
Package
.zip
Component Assembly
“Manufacturing”
Component
Package
Component
Package
Component
Package
Instance
Creation
Port
Connections
Assembly
Archive
.aar (ZIP)
Assembly
Tool
Deployment
Configuration
Values
Tool
...
© 2004 Mercury Computer Systems, Inc.
34
Related OMG Specifications

CORBA
 Distributed system, middleware

CORBA Component Model (CCM)
 Based on CORBA
 Component Model, Component
Implementation Definition Language,
Container Programming Model, Packaging
and Deployment

Deployment & Configuration
 Based on CCM
 Deployment system, assemblies
© 2004 Mercury Computer Systems, Inc.
35
Section 2.3
“Model Driven
Architecture”
© 2004 Mercury Computer Systems, Inc.
What is MDA?




“Model Driven Architecture”
Defines a software lifecycle that
minimizes duplicate efforts
Enables mappings between
Platform Independent Models (PIM),
Platform Specific Models (PSM) to
actual code
Crucial for SDR technology where
portability is a big issue
© 2004 Mercury Computer Systems, Inc.
37
MDA Concepts
Meta-Language
UML
(Language)
CORBA IDL
(Language)
Transformation
PSM in
CORBA IDL
PIM in UML
Transformation
Tool
© 2004 Mercury Computer Systems, Inc.
38
Section 2.4
“Heterogeneous
Processing Platforms”
© 2004 Mercury Computer Systems, Inc.
SCA Compliant Radios
Component-Centric Architecture
Customer Application
•Software defined
handsets
•Layered approach
maximizes COTS
content and use of
legacy equipment
•Hardware
transparent to
software
•Air-programmable
•Vendor
independent
© 2004 Mercury Computer Systems, Inc.
(NATO Waveform)
Application Environment
Object-Oriented Application Environment
And API Tool Kit
(SCA)
Component Middleware
Adapter for Specific Tool Kit to
Component Middleware
Mercury
Component
Middleware
SW Components
SW Drivers
Processing Resource
Embedded RISC, DSP, FPGA
ASIC, Sensor I/O, etc.
40
Heterogeneous Radio
Architecture
Pool of Processors
•No bounds on processor usage
•Scale to zero
•Dynamic rescheduling
•Load balancing
Slice – based Radio System
•Number of waveforms limited
•Waveform complexity limited
•Not reconfigurable
•No load balancing
© 2004 Mercury Computer Systems, Inc.
41
Platform Architecture
•Fabric handles congestion
management and priority based
routing
•Middleware provides transparent
communication
Comp
B
Comp
A
Container
A
© 2004 Mercury Computer Systems, Inc.
Memor
y
Buffer
. 1
.
.
Memory
Buffer 1
.
.
.
Mercury
Fabric
Memory
Buffer N
Memory
Buffer N
42
Container
B
Section 3
“OMG Software Radio
Activities ”
© 2004 Mercury Computer Systems, Inc.
SWRadio OMG

Work at Software Based Communication (SBC) Domain
Task Force (DTF) of the OMG

Lead by Mercury, Raytheon and Thales

Effort to convert SCA into a commercial standard by
recasting it as an OMG standard like CORBA, UML, etc.

Final submission will be voted for adoption at the April
’04 OMG meeting in St. Louis this week

Will likely become new mandate for future procurements
(SCA 3.0?)

Will be more broadly acceptable outside JTRS and
outside DoD
© 2004 Mercury Computer Systems, Inc.
44
Next Generation SCA
Lightweight
Services
Deployment
and Configuration
Lightweight
CCM
Lightweight
Logging
SCA
Personality
COTS Content
SCA NG



Morphing into an OMG form, as an umbrella spec of
standards
Each change go through the TAG in order to be a part of
SCA
Advantage: Leverage existing and emerging
specifications
 Increase COTS content in SCA specification
 Inherit advanced features (e.g. Component Model, heterogeneous
deployment)
© 2004 Mercury Computer Systems, Inc.
45
Next Generation SCA
SCA - NG
SCA


D&C
LCCM SWRadio
ORB
ORB
RTOS
RTOS
SCA already points to existing
standards such as DLPI, POSIX
SCA is getting more lightweight by
pointing to open OMG specifications
© 2004 Mercury Computer Systems, Inc.
46
Section 3.1
“Design Rationale ”
© 2004 Mercury Computer Systems, Inc.
SWRadio Specification

MDA based approach





UML Profile for SWRadio Domain
Platform Independent Model (PIM)
Platform Specific Model (PSM) for CORBA, XML
Transformation mechanism for PIM to PSM mapping
Several compliance points
 Waveform developer
 Infrastructure developer
 Tool developer
© 2004 Mercury Computer Systems, Inc.
48
Design Rationale
© 2004 Mercury Computer Systems, Inc.
49
Design Rationale, cont’d
1.
2.
© 2004 Mercury Computer Systems, Inc.
50
Conformance Criteria
Conformant on the part of a:
If:
Waveform application
Waveform
Waveform
applications applications
PSM
PSM
Waveform
applications
PIM
SWRadio infrastructure
SWR Infra- SWR Infrastructure
structure
PSM
PSM
SWR Infrastructure
PIM
Model of SWRadio
components
Satisfies all constraints of profile
package
SWRadio tool
Simple: Supports profile constructs in and UML 2 XMI
exchange mechanism
CORBA/XML-based: Supports Profile-WaveformPIM
and PIM-PSM mappings and conformant waveform
apps.
© 2004 Mercury Computer Systems, Inc.
51
SWRadio Products Overview
Infrastructure
Providers
Radio Management
(from Infrastructure)
RadioSet
Device Providers
1..*
Application
Providers
+commEquipment
1
RadioSystem
CommEquipment
+deviceDriver
Service Providers
Radio Control
Facilities
(from Facilities PIM)
1
PIM Facility
DeviceDriver
1..*
1..*
1..*
LogicalCommunicationChannel
+deviceDriver
Hardware
Abstractions
*
Radio Services
Element Definitions
(from Radio Services)
Application Deployment
(from SWRadio Deployment)
+logicalDevice
1..*
DeviceComponent
*
*
ApplicationResourceComponent
Common Radio
Facilities
(from Facilities PIM)
© 2004 Mercury Computer Systems, Inc.
Data Link Layer
Facilities
(from Facilities PIM)
+componentAssembly
+appComponent
Application
1..*
*
Common Layer
Facilities
(from Facilities PIM)
52
Physical Layer
Facilities
(from Facilities PIM)
Section 3.2
“UML Profile ”
© 2004 Mercury Computer Systems, Inc.
UML Profile


Defines a language for specifying
SWRadio elements (HW & SW)
Organized according to 3 viewpoints:
• Application and device developers
– Application and Device Components
• SWRadio platforms providers
– Communication Equipment
• Infrastructure and middleware providers
– Infrastructure

Standardize interfaces and components
• Enable COTS SWRadio development.
© 2004 Mercury Computer Systems, Inc.
54
Applications and Devices

Set of component and
interface stereotype definitions
used for the development of
applications, logical devices,
and components.
 Base Types –basic types
• String, octet, exceptions…
 Properties –stereotypes for
configure, query, testable, service
artifact (capability and capacity)
and executable properties
 Resource Components –
stereotypes for interfaces and
components of the
ResourceComponent.
 Device Components –stereotypes
for the logical device components
that represent devices.
 Application Components – defines
stereotypes for the
ResourceComponents.
© 2004 Mercury Computer Systems, Inc.
55
CommEquipment Package

SWRadio ≡ Computer
 This is represented in the basic classes
<<modelLibrary>>
RequiredTypes
<<stereotype>>
CommEquipment
<<stereotype>>
PowerSupply
© 2004 Mercury Computer Systems, Inc.
<<stereotype>>
CryptoDevice
<<stereotype>>
IODevice
56
<<stereotype>>
Processor
Modeling Concepts

Key concepts
 Properties
• Express fundamental attribute of element
• Used by software to learn about or configure
element
 Ports
• Use to collect the properties related to the
interconnections
 Devices
• Used to collect the properties related to the
devices
• Can have an arbitrary number of ports
• Capable of intelligence
© 2004 Mercury Computer Systems, Inc.
57
Properties

CharacteristicProperty
<<metaclass>>
Property
 Indicates a static and nonqueryable attribute.
 Constraints based on physics
limitations.
(from UML)
• Impedance, Noise figure, Size,
Weight, Max, Min,…

<<extension>>
QueryProperty
 Indicates a queryable but nonconfigurable attribute.
 Constraints that may change but
not by software.
• Operating environment, RAM size,
Temperature,…

<<extension>>
<<stereotype>>
ConfigureProperty
queryable : Boolean
maxLatency : Time [0..1]
stepSize : Single [0..1]
<<stereotype>>
CharacteristicProperty
maxLatency : Time [0..1]
ConfigureProperty
 Indicates a dynamic attribute.
 Constraint usually associated
with an API.
<<stereotype>>
QueryProperty
• Frequency response, Gain, Center
frequency,…
© 2004 Mercury Computer Systems, Inc.
58
Ports
Information exchange
between devices.
 Modeling of entire
transmission and
reception chains.
 Analog ports for analog
signal input/output.
<<metaclass>>
Port
(from UML)
<<extension>>
<<extension>>
<<extension>>
• VSWR, Power handling,
Impedance,…
 Digital ports for digital
signal input/output.
<<stereotype>>
DigitalPort
<<characteristicproperty>> quantizationNoise : QuantizationNoiseDensity
<<characteristicproperty>> dataFlowDirection : Direction
<<characteristicproperty>> streaming : Boolean
• Throughput, Quantization
noise,…
© 2004 Mercury Computer Systems, Inc.
<<stereotype>>
AnalogOutputPort
<<characteristicproperty>> maxOutputLevel : Power
<<characterisiticproperty>> outputImpedance : Impedance
<<characterisiticproperty>> outputVSWR : VSWR [0..1]
59
<<stereotype>>
AnalogInputPort
<<characterisiticproperty>> inputImpedance : Impedance
<<characteristicproperty>> inputLevel : Power
<<characteristicproperty>> maxInputLevel : Power
<<characteristicproperty>> insertionLoss : Decibel
<<characterisiticproperty>> inputVSWR : VSWR [0..1]
SWRadio Products Overview
Infrastructure
Providers
Radio Management
(from Infrastructure)
RadioSet
Device Providers
1..*
Application
Providers
+commEquipment
1
RadioSystem
CommEquipment
+deviceDriver
Service Providers
Radio Control
Facilities
(from Facilities PIM)
1
PIM Facility
DeviceDriver
1..*
1..*
1..*
LogicalCommunicationChannel
+deviceDriver
Hardware
Abstractions
*
Radio Services
Element Definitions
(from Radio Services)
Application Deployment
(from SWRadio Deployment)
+logicalDevice
1..*
DeviceComponent
*
*
ApplicationResourceComponent
Common Radio
Facilities
(from Facilities PIM)
© 2004 Mercury Computer Systems, Inc.
Data Link Layer
Facilities
(from Facilities PIM)
+componentAssembly
+appComponent
Application
1..*
*
Common Layer
Facilities
(from Facilities PIM)
60
Physical Layer
Facilities
(from Facilities PIM)
Infrastructure Package

Defines the language to specify software
components, services and applications
within a radio infrastructure for SWRadio
applications, and to manage the radio’s
domain, services, and devices.

This set of stereotypes includes
RadioManager, DeviceManager,
Application, and ApplicationFactory
components.
© 2004 Mercury Computer Systems, Inc.
61
Infrastructure Package
Radio Management - Domain

Domain Registration Management
 Provides the mechanism for registering and
unregistering services within a radio.

Domain Installation Management
 Provides the mechanism for installing and uninstalling
applications within a radio.

Domain Retrieval
 Provides the mechanism for retrieving radio’s
components.

Domain Event Management
 Provides the mechanism for receiving asynchronous
radio’s domain event changes.
© 2004 Mercury Computer Systems, Inc.
62
Infrastructure Package
Radio Management - Node
 Service
Registration Management
 Provides the mechanism for registering and
unregistering services within a node.
 Node
Retrieval
 Provides the mechanism for retrieving radio’s
node components.
© 2004 Mercury Computer Systems, Inc.
63
Infrastructure Package
Platform Services

Stereotypes representing SWRadio
platform services.
 Middleware services
 Radio services
• Event service
• Naming service
• Cosite service
• GPS service
• Fault management
service
• Measurement service
• Preset service
• Retransmission
service
• Scanner service
 Framework services
•
•
•
•
OS environment
File service
Installer service
Log service
 More to come from
SBC DTF
© 2004 Mercury Computer Systems, Inc.
64
Infrastructure Package
Deployment



Interface to the OMG Deployment &
Configuration spec
Stereotypes required to deploy
services and applications
Executable artifacts
 Applications and waveforms
 Logical devices
 Services
© 2004 Mercury Computer Systems, Inc.
65
UML Profile Summary



Simple but powerful
Flexible but manageable
Attains its objectives:
 Ability to model the physical components of a
communication equipment.
 Provide a set of parameters to check for compatibility
between waveform and platform.
 Capture platform requirements
 Ability to model and simulate a SWRadio.

Future:
 Commercial block set tools?
© 2004 Mercury Computer Systems, Inc.
66
Section 3.3
“Platform Independent
Model”
© 2004 Mercury Computer Systems, Inc.
SWRadio Products Overview
Infrastructure
Providers
Radio Management
(from Infrastructure)
RadioSet
Device Providers
1..*
Application
Providers
+commEquipment
1
RadioSystem
CommEquipment
+deviceDriver
Service Providers
Radio Control
Facilities
(from Facilities PIM)
1
PIM Facility
DeviceDriver
1..*
1..*
1..*
LogicalCommunicationChannel
+deviceDriver
Hardware
Abstractions
*
Radio Services
Element Definitions
(from Radio Services)
Application Deployment
(from SWRadio Deployment)
+logicalDevice
1..*
DeviceComponent
*
*
ApplicationResourceComponent
Common Radio
Facilities
(from Facilities PIM)
© 2004 Mercury Computer Systems, Inc.
Data Link Layer
Facilities
(from Facilities PIM)
+componentAssembly
+appComponent
Application
1..*
*
Common Layer
Facilities
(from Facilities PIM)
68
Physical Layer
Facilities
(from Facilities PIM)
Platform Independent Model

Objective
 Provide PIM interfaces that waveform applications use
across all platforms.
 Provide PIM interfaces that software radio
infrastructures supply as standard facilities
 Define example component definitions that realize the
specified interfaces to provide SWRadio services

Independent from:
 Distributed component middlewares (CORBA, .NET)
 Programming languages (C++, Java)
 Information formatting technologies (XML)
© 2004 Mercury Computer Systems, Inc.
69
Platform Independent Model

Strategy
 Signal processing APIs according to OSI Model.
 Control and management APIs span across all Layers
 Create ‘common layer’ and ‘common radio’ groupings

Viewpoints
 Software Radio Infrastructure - defines interfaces &
architecture
 Waveform Application Components – specifies
waveform related interfaces

Potential usage
 Provides coherent and standard APIs for waveform
portability.
 Specifies clean interfaces for
simulation packages.
© 2004 Mercury Computer Systems, Inc.
70
PIM for Waveform Layering

Link
 LLC and MAC

Physical
 Modem, IF/RF, IO

Common
 QoS, Flow control,
Measurement, Error
control, PDU, Stream

Management
 Configure and get
status
 Control
communication
channels
© 2004 Mercury Computer Systems, Inc.
71
Platform Independent Model - PIM




Defines the SDR system model following the
OSI layers
Independent of implementation details (WHAT,
NOT HOW)
Defines common APIs for waveform
applications
Consists of packages:






Common Layer Facilities
Common Radio Facilities
Data Link Layer Facilities
I/O Facilities
Physical Layer Facilities
Radio Control Facilities
© 2004 Mercury Computer Systems, Inc.
72
Common Layer Facilities Package
Flow Control
Facilities
PDU Facilities
QoS Management
Facilities
Error Control
Facilities
Stream
Facilities
Measurement Facilities
• Interfaces that cross-cut through
waveform layers
© 2004 Mercury Computer Systems, Inc.
73
Common Radio Facilities Package

File Facilities
 File system
 File management
 Files

Scheduling Facility
 Timers and scheduling certain events
© 2004 Mercury Computer Systems, Inc.
74
Link Layer Control (LLC) Facilities
Package



Defines the LLC facilities as a part
of Data Link Layer
Based on the DLPI spec
Provides facilities for





Local Management
Connectionless Link
Ack Connectionless Link
Connection Oriented Link
Reuses some of the common layer
facilities
© 2004 Mercury Computer Systems, Inc.
75
Example ConnectionlessLink
Component
<<swrapi>>
IQualityOfServiceConnectionless
<<swrapi>>
IFlowControlManagement
(from QoS Management Facilities)
(from Flow Control Facilities)
<<swrapi>>
IRequestPdu
© 2004 Mercury Computer Systems, Inc.
<<LinkLayerControlResource>>
ConnectionlessLinkComponent
76
<<swrapi>>
ILocalLinkManagement
(from LocalLinkManagement)
<<swrapi>>
IIndicatorPdu
MAC Layer Facilities Package



Defines interactions between a MAC
Layer user (service user) and a MAC
Layer (service provider)
List of facilities populated after a
long waveform survey
Several facilities include:




Transec
Channel Access
QoS
MAC addressing etc.
© 2004 Mercury Computer Systems, Inc.
77
I/O Facilities Package



Acknowledges the fact that I/O can
occur at every waveform layer.
Defines the configuration properties
for Audio and Serial Facilities
Contains several interfaces




Virtual resource Control
Device Control
Security control
Flow Control
© 2004 Mercury Computer Systems, Inc.
78
Physical Layer Facilities Package



Interfaces on both control and data
planes
Used to control the communication
equipment device attributes defined
in the UML Profile
Partitioned into:
 Modem Facilities
 RF/IF Facilities
© 2004 Mercury Computer Systems, Inc.
79
Radio Control Facilities Package


Alarms and Alerts
Radio Management Facility
 Management of the radio (domain
management)
 Management of devices and services within a
radio (device management)
© 2004 Mercury Computer Systems, Inc.
80
Conclusion – PIM




Provides waveform portability
through standard software
interfaces Organized as in OSI
model
Does not require layered
implementation
Coherent with key characteristics of
UML model
Can be extended to create vertical
I/O models
© 2004 Mercury Computer Systems, Inc.
81
SWRadio Products Overview
Infrastructure
Providers
Radio Management
(from Infrastructure)
RadioSet
Device Providers
1..*
Application
Providers
+commEquipment
1
RadioSystem
CommEquipment
+deviceDriver
Service Providers
Radio Control
Facilities
(from Facilities PIM)
1
PIM Facility
DeviceDriver
1..*
1..*
1..*
LogicalCommunicationChannel
+deviceDriver
Hardware
Abstractions
*
Radio Services
Element Definitions
(from Radio Services)
Application Deployment
(from SWRadio Deployment)
+logicalDevice
1..*
DeviceComponent
*
*
ApplicationResourceComponent
Common Radio
Facilities
(from Facilities PIM)
© 2004 Mercury Computer Systems, Inc.
Data Link Layer
Facilities
(from Facilities PIM)
+componentAssembly
+appComponent
Application
1..*
*
Common Layer
Facilities
(from Facilities PIM)
82
Physical Layer
Facilities
(from Facilities PIM)
Section 3.4
“Platform Specific Model”
© 2004 Mercury Computer Systems, Inc.
Platform Specific Model


Automatic PSM generation from PIM
and profile definitions
Platform Specific to
 CORBA
 XML
 POSIX

Other PSMs could be defined (J2EE,
.NET, etc.)
© 2004 Mercury Computer Systems, Inc.
84
Summary



Provides the infrastructure to deploy and host
Software Radio components.
Provides a set of services and facilities that
represent typical Communication device
functionality.
SBC DTF (and other interested groups) will
continue to enhance the suite of available
services and facilities.
 Working on the submission for over year
 Has the backing of many supporters
 Based upon existing specifications

Forms the basis for the upcoming SBC workshop
this September
© 2004 Mercury Computer Systems, Inc.
85
Thanks!
A. Tansu Demirbilek
Dr. Jean Belzile
David Roberge
© 2004 Mercury Computer Systems, Inc.
Section 4
“Backup Slides”
© 2004 Mercury Computer Systems, Inc.
GLoMo






Stands for “Global Mobile
Information Systems “
A Past DARPA initiative
Defines standard interfaces for
communicating between algorithm
components
Specifies a hardware infrastructure
Experimential
Not a standard
© 2004 Mercury Computer Systems, Inc.
88
&




OBSAI – Open Base Station
Architecture Initiative
CPRI – Common Public Radio
Interface
Led by Base Station vendors
Both define a standard 3G Base
Station Architecture for plug-andplay HW/SW module capability.
© 2004 Mercury Computer Systems, Inc.
89
Digital IF


Led by Mercury Computer Systems,
Inc.
Defines standard hardware and
software interfaces and the physical
link between tuners and processing
platforms
© 2004 Mercury Computer Systems, Inc.
90



A vendor-neutral consortium led by
the SDR community activists
Issues recommendations on SDR
specifications
Issues RFI for reference
implementations (SCARI – SCA v2.2
Reference Implementation)
© 2004 Mercury Computer Systems, Inc.
91
SCA




“Software Communications Architecture”
Non-Proprietary Specification Sponsored
by the Joint Tactical Radio System (JTRS)
program
Current version is 2.2 (jtrs.army.mil)
Change by Technical Advisory group (TAG)
and Change Control Board (CCB)
© 2004 Mercury Computer Systems, Inc.
92




Open membership, not-for-profit
organization
Produces and maintains freely available
computer industry specifications
Commercial industry implements specs
as COTS Software (e.g CORBA, D&C,
CCM)
Software Based Communication DTF and
SWRadio DSIG specifying new standards
based on SCA 2.2
© 2004 Mercury Computer Systems, Inc.
93
OMG RFPs Schedule
S W R A D IO
RFP
L igh tw eigh t
S ervices R F P
GNS RFP
2-6/02
5 -6/02
11/03
11/03 -01/04
H igh
A ssu ran ce
O RB RFP
11/03 -01/04
6/02
6/02
11/03
02/04
02/04
6 /0 2
6/02
11/03
02/04
02/04
6/03
L O I to s u b m it to R F P d u e
10/02
8/02
01/04
4/05
4/05
8/03
In itia l s u b m is s io n s d u e *
1 /0 3
1 0 /0 2
03/04
10/05
10/05
10/03
V o te r re g is tra tio n c lo s e s
1 /0 3
1 1 /0 2
04/04
10/05
10/05
10/03
In itia l s u b m is s io n p re s e n ta tio n s
1 /0 3
1 1 /0 2
04/04
10/05
10/05
1 0 /0 3
R e v is e d s u b m is s io n s d u e *
4 /0 4
1 1 /03
10/04
01/06
01/06
03/04
R e v is e d s u b m is s io n p re s e n ta tio n s
4 /0 4
1 1 /03
11/04
01/06
01/06
03/04
5 /0 4
1 2 /03
11/04
2/06
2/06
B O D v o te s to a d o p t s p e c ific a tio n s
6/04
2/04
1/05
4/06
4/06
F in a liz a tio n T a s k F o rc e
6/04
2/04
1/0 5
6/06
6/06
A c tiv ity
P re p a ra tio n o f R F P b y T F
P ow er
A w are R F P
R e v ie w b y T C ,
A p p ro v a l o f R F P b y A rc h ite c tu re
C C M S trea m s
RFP
6/03
6/03
B o a rd *
T C v o te s to is s u e R F P *
P u b lic C o m m e n ts d u e
P re lim in a ry e v a lu a tio n b y T F
F in a l e v a lu a tio n a n d s e le c tio n b y T F
R e c o m m e n d a tio n to A B a n d T C
R e v ie w b y T C ,
A p p ro v a l b y A rc h ite c tu re B o a rd
T C v o te s to re c o m m e n d
s p e c ific a tio n s
shaded areas indicate completed task
* “Three week rule”
© 2004 Mercury Computer Systems, Inc.
94
Class Diagram


Provides overview
of system
Defines software
classes
 Attributes
 Operation signatures

Abstract
© 2004 Mercury Computer Systems, Inc.
Client
Implementing
Shows
relationships
between classes
 Uses
 Extends
 Realizes
Interface
Client
Abstract
Interface
Implementing
95
Use Case Diagrams
Use case represents a
set of actions in the
system
Actors are objects
outside the system that
communicate with it
Diagram shows how use
cases interact with
actors
Details of a use case can
be specified by text or
as a sequence diagram.

Place Order
1
Salesperson
Customer
Check Status
Fill Order
Shipping Clerk
Establish Credit

Supervisor

Supply Customer Data
Order Product
<<include>>
<<include>>
<<include>>
Arrange Payment

1
Customer
Place Order
<<extend>>
Other Payment
© 2004 Mercury Computer Systems, Inc.
96
Sequence Diagram



Interactive diagram
Shows interactions of
actors and objects
Provides details of an
operation or use case
Start
Create
Self-Destruct
Return
Organized according to
time
Delete
 Progresses as it moves
down the page
 Show relationship of
operations to time
© 2004 Mercury Computer Systems, Inc.
New
Mesage
 Who starts the operation
 How performed
 Messages sent

Original
Actor : Actor
97
State Diagram


State defined by
activity or
condition
Diagram shows
 Possible states of an
object
 Conditions that cause
state change

© 2004 Mercury Computer Systems, Inc.
98
Focus on object
changing between
discrete states
Activity Diagram
User
Workstation

Serv er
 Separate actions by
entity
Start
Press Power
Button
Display Logon
Screen
Incorrect Username
Password Incorrect
Enter Name
Send Name to
Server
Verify Username

Correct Username
Enter Password
Send Password
to Server
Verify Password

Password Correct
Complete Login
© 2004 Mercury Computer Systems, Inc.
Fancy flowchart
99
Related to state
diagram
Focus on flow of
activity to
complete a
process
Connecting the Pieces
Place Order
1
Interface
Abstract
Client
Salesperson
Customer
Check Status
Fill Order
Implementing
Shipping Clerk
Establish Credit
Original
User
Workstation
Supervisor
Serv er
Start
Create
New
Press Power
Button
Display Logon
Screen
Mesage
Incorrect Username
Password Incorrect
Self-Destruct
Enter Name
Return
Send Name to
Server
Correct Username
Enter Password
Delete
Send Password
to Server
Password Correct
Complete Login
© 2004 Mercury Computer Systems, Inc.
Verify Username
100
Verify Password
UML Key Points

Technical communication language
 Read documents written by developers
 Read technical articles published in journals



Shows opportunities for component
reuse
Benefits of modeling before coding
Write documentation for future
maintenance of designed product
© 2004 Mercury Computer Systems, Inc.
101
Fundamentals

Component-based software has become a
buzzword since mid ’90’s.

“The industrialization of software delivery”

OO technologies provide the technical
framework
The contract of a component defines

 Deployment dependencies
 Interfaces
 How the component can be deployed, instantiated

Explicit context dependencies
 Specification of deployment environment
 “Bridges” to other component worlds
© 2004 Mercury Computer Systems, Inc.
102
What’s a component?
Component Definition
Ports that provide service

Defined for its “users” by:



Ports that provide a service via an interface/protocol
(component acting as server)

Ports that require (use) a service via an interface/protocol
(component acting as client)

Configuration (instantiation) parameters.

An overall functional behavior
Config params:
- Color: red (default)
Ports that require a service
Packaged as a combination (e.g. zip archive) of
compiled code files (e.g. DLLs)
and descriptive metadata (e.g. XML).
Metadata allows tools and runtime
environments to know how to use it, configure,
run it, after it is compiled and packaged.
Component Package
(e.g. ZIP file)
Definition
Metadata
Implementation
Metadata
Compiled
Code
© 2004 Mercury Computer Systems, Inc.
103
Compiled
Code
Component-based Development
Environment


Components
Assemblies





Built from components
Connections between the ports of components
May be hierarchical (an assembly can be a component)
Expressed as metadata
Containers
 Execution environment for components
 Provides for communication between components
 May have multiple per computer for different component types (Java, C++)

Distributed system
 Collection of computers with containers
 The target of deployment for component-based applications

Deployment system




Runs applications on a distributed system
Talks to all the containers
May decide how/where to run all the components
Deals with packaged components, and software distribution
© 2004 Mercury Computer Systems, Inc.
104
Typical Case

System Engineers
 Design & simulate the system using
scientific simulation tools
 (Possibly) Model the system using UML
 Document the requirements

Software Engineers
 Read the requirements
 Develop code from scratch
 Re-develop the code every time it needs to
be ported
© 2004 Mercury Computer Systems, Inc.
105
Model Driven Architecture (MDA)



Provides a software development life-cycle
that can be automated for code-generation
Code generation is the end goal
UML is used as the modeling language
Syste
m
Modeling
Mapping 2
Mapping 1
PIM
© 2004 Mercury Computer Systems, Inc.
Code
PSM
106
How?




MDA provides suite of specs for those
transformations to happen
Meta Object Facility (MOF) is a Meta
Language that any language can be formally
represented
XML Metadata Interchange (XMI) or CORBA
Interface Definition Language (IDL) allows
interchange of models between languages
Unified Modeling Language (UML) is a MOF
based visual language for defining models
© 2004 Mercury Computer Systems, Inc.
107
MOF Meta-Language Concept



A model can be written in any language
A language can be represented in MOF
format, as a formal language
Transformations exist between formally
represented languages, as well as models
written in those languages
Written in
MODEL
© 2004 Mercury Computer Systems, Inc.
Written in
LANGUAGE
108
META
LANGUAGE
Language Transformation


Envision UML model as the PIM language and the CORBA
Interface Definition Language (IDL) as the PSM language
Define a transformation from UML to CORBA IDL, which has
now been represented by meta-language elements
Meta-Language
UML
(Language)
CORBA IDL
(Language)
Transformation
© 2004 Mercury Computer Systems, Inc.
109
Defining the Language
Transformation

Common API definitions are needed

An official transformation definition
language is not there yet. MOF QVT
(Query – View – Transformation) spec is
still in the works. 5 teams are competing
for the spec.
© 2004 Mercury Computer Systems, Inc.
110
Model Transformation Tool



Once the language transformation is defined, a
model transformation tool should be developed
to carry out the actual transformation
Considering the non-standard internal data
representation of UML CASE tools, first an XML
Schema (using XMI) should be created from the
PIM
This XML Schema can be transformed using the
model transformation tool.
© 2004 Mercury Computer Systems, Inc.
111
Intercomponent/Interprocessor
Comm Timing
•Each container has a single processing element
•Components with different timing requirements
can run on different containers
Container
B
Container
A
© 2004 Mercury Computer Systems, Inc.
112
Intercomponent/Interprocessor
Comm Timing
Comp
A
•Runs once every 20ms
•Each execution takes 8ms
Container
B
Container
A
© 2004 Mercury Computer Systems, Inc.
113
Intercomponent/Interprocessor
Comm Timing
Comp
A
Container
B
Container
A
© 2004 Mercury Computer Systems, Inc.
114
Intercomponent/Interprocessor
Comm Timing
•Runs once every 2ms
•Each execution takes 1.2ms
Comp
B
Comp
A
Container
B
Container
A
© 2004 Mercury Computer Systems, Inc.
115
Intercomponent/Interprocessor
Comm Timing
Comp
B
Comp
A
Container
B
Container
A
© 2004 Mercury Computer Systems, Inc.
116
Intercomponent/Interprocessor
Comm Timing
•Multiple memory buffers
enable components to run
independently, without waiting
for buffers to fill
Comp
B
Comp
A
Container
A
© 2004 Mercury Computer Systems, Inc.
Memor
y
Buffer
. 1
Memory
Buffer 1
Memory
Buffer N
Memory
Buffer N
.
.
.
.
.
117
Container
B
Descargar

No Slide Title