Software%20Defined%20Radio

1
Software Defined Radio
GSC9/GRSC_013
SOURCE ETSI ERM-TG32
TITLE Software Defined Radio
AGENDA ITEM GRSC2 Item 5
CONTACT Phillipe Mege (philippe.mege_at_EADS-TELECOM.COM)

• Activities within Europe in the European
  Commissions TCAM Committee and ETSI

1
GSC-9, Seoul
2
The European Commission's TCAM Committee (1)

• The Commissions TCAM Committee is responsible
  for the regulatory environment created by the
  RTTE Directive
• TCAM established a specialist ad hoc group to
  consider how Software Defined Radio (SDR)
  products should be handled under the RTTE
  Directive
• The ad hoc group produced a questionnaire On the
  Impact of SDR on the RTTE Directive
• The aim of this consultation was to obtain
  comments from interested parties on a variety of
  issues relating to Software Defined Radio
• The questionnaire was published on the official
  European Commission Web Pages last autumn

3
The European Commission's TCAM Committee (2)

• The Questionnaire covered four areas
• Questions related to when SDR equipment is likely
  to appear on the market at the earliest (Q1, Q2)
• Questions related to what SDR is likely to change
  in the applicability of RTTE (Q3 Q9)
• Questions related to possible changes in the
  RTTE Directive (Q10, Q11)
• Standardisation (Q12 Q13)

4
The European Commission's TCAM Committee (3)

• General Summary of the Answers to the
  Questionnaire
• Under the New approach guide the product is
  considered a new product if the software effects
  the essential requirements
• The provisions of RTTE Directive are adequate as
  it requires an entity (manufacturer) to take
  responsibility for the placing of product on the
  market
• For the Software provider the same requirements
  should apply as to hardware manufacture
  concerning the RTTE-Directive

5
ETSI Activities

• Software Defined Radio
• ETSI activities centre around Task Group32 of
  TC-ERM (EMC and Radio Spectrum Matters)
• Link and impact to coexistence standards,
  methods of measurements and limits

6
What is Software Defined Radio ?

• Objective Give more flexibility on Radio
  Front-End
• For
• Using the same Hardware Platform for different
  systems
• Different standards
• Different frequency bands and frequency
  bandwidths
• Providing more easily interoperability
• Downloading the air interface through the air for
  automatic reconfiguration
• By
• Transferring the maximum of radio functions from
  analogue to digital
• Sharing the radio function between analogue and
  digital
• Digitising at high sampling rate as close as
  possible to the antenna
• instead of classically sampling at moderate rate
  in Intermediate Frequency or in Baseband

7
Classical Heterodyne architecture (Receiver chain)

Radio Domain ltgt Analogue Domain Baseband
Domain ltgt Digital Domain
8
The Normative Environment

• SDR Forum co-ordinates the activities world-wide
• A generic approach mainly devoted to military
  applications
• Definition of software development approaches for
  simplifying portability (SCA Standard
  Communication Architecture)
• Hardware implementation with FPGAs apart Baseband
  and with general purpose processors for Baseband
  (for maximum flexibility and reconfigurability)
• Software development cost effectiveness is the
  target
• Due to the huge amount of different systems and
  standards to be implemented on the universal
  Hardware platform
• Equipment cost is not the major considered aspect

9
General Context

• Software Defined Radio is pushed strongly for
  military applications
• Due to the difficulties of interoperability with
  legacy equipment
• Need to communicate with a very large number of
  different types of systems between the different
  armed forces, different Countries, different
  components of the armed forces (Air, Navy, Land
  forces, security forces)

10
Software Radio for PMR

• Software Radio is also of primary interest for
  Private Mobile Radio (PMR)
• PMR is characterised by a large number of
  different systems and standards in different
  frequency bands and with different bandwidths
• Analogue systems
• Narrowband (6.25 kHz)
• DMR (12.5 kHz)
• TETRAPOL (12.5 kHz, 10 kHz)
• TETRA 1 (25 kHz)
• APCO 25 Phase 1 (12.5 kHz)
• APCO 25 Phase 2 (12.5 kHz equivalent 6.25 kHz)
• Wideband Data TETRA 2 TEDS (25, 50, 100, 150, 200
  kHz)
• Wideband Data TIA SAM/IOTA (50, 100, 150 kHz)
• And interest for PMR/PAMR/Public systems with GSM
  also (or with other systems) on the same equipment

11
Software radio for PMR Objectives

• Objectives
• Reduce the development costs
• A single Hardware Platform for several standards
  and systems
• Reduce the equipment costs
• Use as much as possible Off the Shelf
  Components
• Develop highly integrated components (ASICs) for
  specific functions (and applicable for the
  different systems and standards)
• Additional benefits
• Reduction of size and weight of equipment
• Improved autonomy of equipment
• Capability of evolution of systems and equipment

12
Constraints for coexistence (Classical case)

• Narrowband filtering early in the receiver chain
  means that
• most of the interferers are rejected
• only closest ones are important (adjacent,
  alternate, )
• blocking shall also be considered (Broadband
  noise of the LO)
• useful signal is dominant in the signal that
  comes into the Analogue/Digital Converter

13
Constraints for coexistence(Software Radio case)

• Analogue/Digital Conversion is applied close to
  the antenna
• a whole band is then digitised
• not only the useful signal
• but also all the signals going through the
  wideband filter placed before the ADC
• Then contributors to interference are all the
  signals that are digitised
• not necessarily only adjacent and alternate
• many interference signals can be present
• This means a need of large dynamic of the ADC
  because saturation of the wideband digital signal
  can damage dramatically the useful signal
• So the approach for measurement applied in PMR
  (LMR) standards is not totally well suited for
  Software Radio case

14
Constraints for coexistence(Software Radio case)

• We need to avoid over-specification and
  over-testing
• The constraints of the base co-existence standard
  EN 300 113 are in practise relevant only when
  applied to an uncoordinated environment (Direct
  mode, or small systems with only few bands
  allocated for example)
• In a large system, a bloc of channels is
  allocated to the whole system
• Interference (co-channel, adjacent channel, )
  is limited thanks to adequate radio planning and
  frequency reuse
• the protection limits (especially at receiver
  side) can be in practise relaxed in this case
• Then, for a software radio structure for example,
  the constraints in the whole digitised band are
  not necessarily the addition of the most
  stringent constraints of EN 300 113
• The number of channels effectively contributing
  to interference needs also to be taken into
  account

15
The Transmitter Chain case

• A similar problem can appear with the
  transmitter, for example, the following
  conditions
• Combination at the Base station of several
  channels in digital before Digital/Analogue
  Conversion and Power Amplifier
• Multi-channel modulations (e.g. OFDM) where each
  sub-channel is modulated and all sub-channels are
  combined in the same transmitted signal
• In these case problems of saturation in the DAC
  can also appear.

16
Conclusion

• The Regulatory environment established in Europe
  under the RTTE Directive applies equally to
  Software Defined Radio products
• Software Defined Radio products have the
  capability of providing both flexibility in their
  application and early market access for new
  products
• Software Defined Radio products have the
  potential to combined radio systems to facilitate
  interoperability between potentially incompatible
  systems