Transceiver PIM Towards a Digital IF Revised Submission

1
Transceiver PIMTowards a Digital IF Revised
Submission

• Report on THALES progress
• Eric NICOLLET Frédéric LAFAYE
• Embedded Digital Systems

2
Introduction
3
Problem description

• Any Radio application uses a Transceiver
  Sub-system
• Reconfigurability
• A flexible Transceiver is to be realized
• The exhaustive sets of dependencies to and from
  the hosted Waveform software is needed
• ? A unified way to characterize Transceiver
  configuration states is needed
• Portability
• The Transceiver has very specific implementation
  choices
• The Waveform software needs to make abstraction
  of such choices
• ? The border between the two is to be clarified
• As of today
• Hardware-level standardization ?
  platform-specific
• No structured API effort on this matter
• Existing ones not aligned with existing SDR
  achievements (e.g. device management framework)

4
The vision

• MDA approach
• A Platform Independent Model (PIM) of Transceiver
  Sub-system
• Defining an Abstraction Layer
• For management components
• For waveform processing components
• Interface package containing Properties,
  Real-time interfaces (towards and from),
  Real-time constraints,
• The starting point for implementations
• Architecture of the solution will always be
  implementation-specific Reception structure,
  HW/SW breakdown, SW processing choices,
  flexibility management choices, targetted
  evolutivity
• Selected interfaces will have specific
  implementations
• Depending on the processor they execute in
• Depending on the component model they execute in
• Formal PSM are possible options, but not
  mandatory
• Close relationship to OMG SWRadio Spec
• Management via Device interface, A future
  Facility integrated as a Spec volume
• A way to take advantage of the Reconfiguration
  Infrastructure

5
Basic business case

• An enabler to structure the market more
  horizontally
• Overall efficiency improved
• Greater innovation possibilities
• Reduced costs of ownership
• Increased cooperation possibilities
• Military domain mainstream interests
• A key to expand the WF-PF paradigm into embedded
  processing
• Customer view trusted procurment on both sides
  (WF and PF)
• WF-provider view dependencies clarified,
  facilitates portability, development
  anticipation,
• Integrator view cornerstone spec to structure
  the collaborations
• Commercial domain mainstream interests
• Single API to write for Transceiver HW drivers,
  reconfiguration method defined and consistent
  with standard means (SWRadio Spec),
• PIM a Transceiver-suited grammar for Functional
  Descriptions

6
Possible other usages

• Certification of Transceiver compliance for
  Waveform configuration
• Verification of any defined feature
• Usage of
• SW test suite to link in replacement of the
  waveform
• RF measurement means
• Flexible Spectrum Management
• Dedicated feature possibly introduced
• Operation band declaration
• Regulation oriented features
• Dedicated feature possibly introduced
• A transmit issue
• Properties for Co-channel interference
  characterization
• Smart antennas expansion
• Vectorized samples instead of scalar
• Introduction of dedicated features (calibration,
  positioning for DoA, )

7
About the Initial submission

• Submitted in April 2005
• By THALES and Mercury
• Supported by PrismTech,

8
The Radio Domain Service Transceiver Sub-system

• Transceiver Sub-system is a Specialized Radio
  Service any Modem needs
• Connected to Waveform Management Components
  through Management Interfaces
• Connected to Modem Resources through Real-time
  interfaces

9
Characteristics of proposed Transceiver Sub-system

• Key features
• Half-Duplex
• I-Q base-band samples
• Gain controlled
• Frequency Hopping (FH)
• SCA Management Interfaces
• Interface Device
• Building-block ErrorSignal
• Non Real-time Properties
• Templates for overall Channel Transfers Functions
  (HRx(f) and HTx(f))
• Modem / Transceiver I-Q interface
• Sample rate, number of bits, nominal level, level
  dynamic range
• Real-time Data Control APIs
• Half-Duplex and Frequency-Hopping Control
  interface
• Data interfaces (Tx Rx)
• FIFO status reporting interface (Tx flow control)

10
Static Properties of Transceiver HRx(f)
Template Example

• Transfer Function of any compliant Transceiver
  shall fit into the template
• Gain domain reference taken at nominalLevel -
  Asymetrical rejection zones
• Group delay domain Max Latency is latency of
  the whole sub-system

11
Real-time APIs Half-Duplex FH Control
Interface

• Semantics setState(), setDwellProfile(),
  shiftDwellProfile(), addFrequency()
• Real-time Interaction types and QOS (based on CP
  278 concepts)
• Direct asynchronous Message
• QOS Attributes
• Maximum Return Time
• Client Minimum Inter-Arrival Time
• Specific requirements to characterize Transceiver
  reactivity
• From Modem call to application by Transceiver
• Asynchronous control the moment where the call
  occurs is not significant

12
PSM Real-time API specification
C language example

• Header source codes for each grand class of
  processing environments
• Instruction Set Architectures (e.g. DSP) C or
  C
• Configurable Logic Architecture (e.g. FGPA) VHDL

13
Main limitations of the initial submission

• Limitations in the structure
• No clear way to define modular compliance or
  usage
• Derived from to reduced set of waveforms
• No logical association between properties and
  interfaces
• Real-time constraints
• No structured way to express such constraints
  (free text in operation documentation)
• Hard values in the spec instead of general
  properties
• Insufficient characterization of interaction
  types
• Limitation in waveform compliance
• Only half-duplex
• Insufficient Time Management capabilities
• No time stamping of commands
• No explicit time relationship between Rx and Tx
  dwells
• Only provisions in gain control (Tx / Rx)
• C-based PSM of few relative added value regarding
  PIM

14
Current Transceiver PIM
15
Main improvements

• Introduction of Features
• The first-level compliance point to the
  specification
• Logical groupings of specification items
• Interfaces
• Properties
• Can have hierarchical dependency (second level
  features)
• Stereotype applicable to PIM packages
• Package _Common
• Support artifacts to enable realization of
  feature packages
• Transceiver specific notions
• General notions supporting any such PIM
• Introduction of Time Machine and TimeManagement
• A side sub-system Time Machine
• A corresponding API for WF usage TimeManagement
• Compulsory to consistently address
  frequency-hopping waveforms
• Significant effort to improve the proposed vision
• Gain control interfaces for Transmit and Receive

16
How to use the Transceiver PIM

• The Transceiver PIM a modelling toolbox
• Modular feature-level compliance points
• Extendable always possible to add specific
  requests
• For each waveform
• Characterization of the expected Transceiver
  configuration
• Starting from the Transceiver PIM
• Identifying requested features and unused ones
• Defining properties values templates values,
  limits of real-time performance expectations,
• For a given product (elementary example, many
  variations possible)
• Identification of target waveforms
• Identification of associated configuration
  requirements
• Transceiver is developed (platform-specific
  effort)
• XCVR internal architecture
• API ports mapped into a platform-specific set of
  processing nodes
• Waveforms integrated with the Transceiver set in
  appropriate configurations

17
Transceiver and Time Machine
18
Overview of Primary Features
19
Feature DeviceManagement
20
Feature Transmit
ltltInterfacegtgt TransmitControl This interface
enables Waveform Ressource to have a real-time
command on the beggining of transmission. The
beginning could be linked with the Hopping Mode
Control (through a Dwell Number) or a Time
Mangement sub-system. ltltInterfacegtgt
SignalTransmit Enable the subscriber to
transfer base-band samples to the Transceiver for
transmission
21
Feature Receive
ltltInterfacegtgt ReceiverControl This interface
enables Waveform Ressource to have a real-time
command on the beggining of reception. The
beginning could be linked with the Hopping Mode
Control (through a Dwell Number) or a Time
Mangement sub-system. ltltInterfacegtgt
SignalReceive Enable the Transceiver to
transfer base-band samples to its subscriber in
reception
22
Feature HalfDuplexControl
ltltInterfacegtgt DuplexControl This interface
enables Waveform Ressource to switch to Receive
State,Transmit State and Idle State.
23
Feature FrequencyHoppingControl
ltltInterfacegtgt DwellSetting  Enable the
subscriber to define a new Transceiver dwell
profile and specifies when it should be applied.
ltltInterfacegtgt DwellTuning  Enables subscriber
to correct dwell profile temporal positioning
without redefining dwellProfile. Namely used by
an equipment in reception to mitigate clock
drifts with the transmitting equipments it
receives. ltltInterfacegtgt FrequencyFeeding 
Enables subscriber to change the RF frequency
24
Feature RxAdaptiveGainControl
ltltInterfacegtgt GainControl  This interface is
activated by Modem onto Transceiver for
realisation of AGC
25
Feature TxAdaptiveLevelControl
ltltInterfacegtgt LevelControl  This interface is
activated by Modem onto Transceiver for
realisation of ALC in transmission in fixed
frequency Mode or in Hopping Mode(operations
named _HM) In Hopping Mode, the Waveform
Resource could specify a Level per Dwell.
26
Feature Error management
ltltInterfacegtgt TransceiverErrorSignal  used by a
Transceiver to notify that an error relative to
transceiver management has been detected.
27
Feature AsynchronousFlowControl (secondary)
ltltInterfacegtgt flowSignaling  Enable the
Transceiver to notify status relative to
transceiver Status values shall be returned in
the following situations -UNDERFLOW_RISK
when an underflow risk in about to occur in
base-band samples FIFO, -EUNDERFLOW when an
underflow has occurred in base-band samples FIFO.
-END_OVERFLOW when an overflow situation is
terminated in base-band samples FIFO.
28
Package _Common
contain artifacts used for features specification
The Channel Class encompasses all Signal
Processing Properties of the Transceiver assuming
there is a channel for each transmission
direction
29
End of the presentation

• Thank you for your attention
• eric.nicollet_at_fr.thalesgroup.com
• Tel [phone]
• Fax [phone]

30
Backup slides

• Transceiver Sub-system APIsApplication-Level
  PIMPSM for Specialized Processors
• Summary of Change Proposal 277
• Eric NICOLLET
• Signal Processing Department

31
Some foreseen improvements

• Support of multiple channelisation templates
• How The Channel attributes could be properties
  (configurable and queryable)
• Specification of a phase noise template
• Hopping Mode
• Decay time of the equivalent bandpass filter,
  especially relevant for fading situations and
  small inter-dwell intervals
• Also of interest could be the time the
  synthesizer takes to reach a certain locked
  state,
• within a certain frequency and/or phase interval
  of the correct dwell frequency.
•   Include a dwell profile for AGC management
• There may exist also a dwell profile for AGC
  management. AGC may be always
• free, always blocked, or slotted, with a free
  running time at the beginning of the dwell
• and a blocked time afterwards. There may also be
  systems where part of the AGC computations
• are done in the modem. AGC system using history
  in the transceiver should also be able to take
• into account interference detection information
  from the modem
•          Dynamic Range of Properties
• Relation between the Time Machine and the
  Transceiver

32
Real-time characterization of dwell positioning
33
characterization of channel mask
Captured at PIM level