software defined radio to enable nnec technical challenges and opportunities for nato l.
Skip this Video
Loading SlideShow in 5 Seconds..
Software defined radio to enable NNEC: Technical challenges and opportunities for NATO PowerPoint Presentation
Download Presentation
Software defined radio to enable NNEC: Technical challenges and opportunities for NATO

Loading in 2 Seconds...

play fullscreen
1 / 32

Software defined radio to enable NNEC: Technical challenges and opportunities for NATO - PowerPoint PPT Presentation

  • Uploaded on

Software defined radio to enable NNEC: Technical challenges and opportunities for NATO. Dr Michael Street. Operational Impact of NNEC. Improved combat identification Improved communications interoperability Improved shared situational awareness

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software defined radio to enable NNEC: Technical challenges and opportunities for NATO' - starbuck

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software defined radio to enable nnec technical challenges and opportunities for nato

Software defined radio to enable NNEC: Technical challenges and opportunities for NATO

Dr Michael Street

operational impact of nnec
Operational Impact of NNEC
  • Improved combat identification
  • Improved communications interoperability
  • Improved shared situational awareness
  • Improved multinational command, control and coordination
  • Reduced risk of fratricide and collateral death and damage
  • Improved mutual support between nations
  • Improved combat effectiveness
sdr to enable nnec
SDR to enable NNEC
  • NNEC needs interoperability
  • Military need many wireless communications capabilities
      • Leads to many NATO radio standards
        • (17 STANAGs for terrestrial radio)
      • Plus national and proprietary systems
    • Interoperability problem for multi-national forces
  • SDR decouples capability from hardware procurement
    • Improve capability rapidly by fielding new software
      • Not by procuring radios (with a 20+ year lifespan)
challenges for sdr

Challenges for SDR






  • Radio interoperability
    • Is what NATO cares about
    • Radio behaviour is defined by software
  • SDRs running the same software should interoperate
    • But SDR software will not be plug and play
  • Radio hardware determined by
    • Size, weight and power supply of the platform
    • Manufacturer preferences - processor families etc
  • Software is determined by hardware so may not be portable
    • A standard for SDR design e.g. SCA, aids portability
  • Multi-national radio interoperability exists due to:
    • Strict requirements e.g. MC 195/6
    • Operational need – and urgent procurements
    • The same standard being available to all
  • And takes a long time to establish
  • SDR reduces interoperability …
  • … unless new SDRs support old ‘legacy’ standards
  • State of the art, expensive, power hungry SDRs, supporting only legacy standards does not give any operational benefit
  • To offer enhanced capability, SDRs need to offer improved capability …
  • … and this capability must be interoperable and secure
    • Interoperable – fielded by all nations
    • Secure – not using any sovereign cryptography
testing sdr
Testing SDR
  • Aims of NNEC require interoperability
    • Currently little testing in NATO, only in nations
  • Only the JTeL (US) can certify SCA compliance
  • What is the scope of required SDR testing ?
    • Interop / compliance
    • Infrastructure
    • Representative tests vs range of scenarios
  • Standards-based products determined by the testing, not by the standards documents
  • Military radio requires security functions for
    • End to end encryption
      • trans-network
    • Link encryption
      • to allow /protect routing & networking
    • Transmission security
      • For robustness
  • SDR is reprogrammable
    • Support different algorithms







  • SCA – a standard for implementing SDR
    • US DoD - developed for JTRS programme
    • Followed by many national SDR programmes
  • Rich, robust, capable
      • Non-military suitability
  • Defined interfaces, APIs
    • But not everything has been released
  • SCA compliant software can be ported to SCA compliant hardware “easily”
    • 70 % software reuse, 90% automated
  • SCA compliant radios and waveforms fielded
    • Including TETRA and APCO-25
legacy interoperability
Legacy Interoperability
  • Software definitions of legacy waveforms will give legacy interoperability
  • Widespread deployment of these waveforms
  • Not technically challenging
  • Lessons learned from
    • STANAG 5066
    • Mil-Std 188-110B
sca based s 5066 implementation
CORBA interface specification

abstract object-oriented interface applicable to any modem

remains constant as modem implementations change

modified earlier hfstack design and implementation:

separate SW modules for hfstack and route56 synchronous serial interface

synchronous serial interface further abstracted as a CORBA resource in accordance with SCA design principles

“SCA-based” S’5066 Implementation
  • towards an SDR modem implementation
    • initial designs encapsulate route56 driver interface to external modem via synchronous-serial port
    • ultimately replaced by SDR modem
  • operates as independent:
    • HF modem server, registered with CORBA name server
    • HF stack, which checks CORBA registry for available HF modem servers
s5066 software overview
S5066 Software Overview
  • Modularized/Object-Oriented Code:
  • SCA design rules dictate modular software structure
  • Module interfaces are a significant part of the software
stanags in software 5066
STANAGs in Software: 5066
  • Subnetwork interface
    • Developed collaboratively within NATO
  • Standard & C code available for download, entirely IPR free
  • Provides an exemplar implementation
    • To test against
    • As a starting point
    • As a basis for further development
  • Software repository established:
  • Need to follow SCA
    • Even for ‘base waveform’ software
    • SCA impacts software design
standards in software 188 110b
Standards in software: 188-110B

Data sequence randomizing generator

(pp. 45,

The data sequence randomizing generator shall be a 12 bit shift register with the functional configuration shown on figure 6. At start of the data phase, the shift register shall be loaded with the initial pattern shown in figure 6 (101110101101 (binary) or BAD (hexadecimal) and advanced eight times. The resulting three bits, as shown, shall be used to supply the scrambler with a number from 0 to 7. The shift register shall be shifted eight times each time a new three bit number is required (every transmit symbol period). After 160 transmit symbols, the shift register shall be reset to BAD (hexadecimal) prior to eight shifts

standards in software 188 110b19
Standards in software: 188-110B

if bpc == 2

pw = [ 2 1];

elseif bpc == 3

pw = [ 4 2 1];

end;% if;

k = 1;

for i = 1 :bpc: Ns

% --| get scrambling sequence (3 bit number )

scrambling_seq = sum(p2vect.* [rnd_shifter(10) rnd_shifter(11) rnd_shifter(12)]);

% --| after 160 symbols, init with the sequence 'bad' and shift 8 times

if (symb_shift_counter == 160)




rnd_shifter = shift_by_8 (rnd_shifter);

end; %if

ri = i + bpc -1;

nu = sum(pw.* input_data(i : ri ));

m = mod(scrambling_seq + nu , 8);

% --| an array in Matlab is from one so we need to add 1 to m

% --| channelphase(m+1) represents phase of the signal

out_data(k) = channel_phase(m + 1);

k = k + 1;

symb_shift_counter = symb_shift_counter + 1;

end; %for


base waveforms and interoperability
Base waveforms and interoperability
  • Text standards can be ambiguous, software is not
  • Single, high-level, generic software description
    • ‘Base waveform’
    • Could be part of the standardisation process
    • Provides a base for porting to a variety of target radio platforms.


























Paper Std Base s/w Target s/w Executable

government and industry roles
Government and industry roles
  • Different role of NC3A and industry
    • NC3A – high level and generic approach
    • Industry – mature, highly optimized and reliable solutions


  • Different type of waveforms
    • Standards on the paper
    • Base waveforms - high level code running on GPP. Non-real time. NC3A is mainly interested in this activity.
    • Target waveforms – highly optimised for a particular radio HW/SW platform. This is the task of the industry.
  • NIAG SDR report on business models for SDR
waveform library
Waveform library
  • Technical issues are probably easiest to resolve
    • Languages used
      • C, C++, Matlab, Python
      • DSP, VHDL, Obj ?
    • Structure of code
      • SCA
      • Design methodology e.g. modularity & conventional software practices
  • Base vs target waveforms
    • Business models and business sectors
current library content
Current library “content”
  • Base waveforms, SCA based (but not SCA certified)
    • STANAG 5066
    • MS 188-110B (but not the complete suite)
  • RF data capture tool
      • RF data format for non real-time waveforms
  • Functional elements
    • RF - STANAGs 4203–5
    • MFSK modem
    • B/Q/8-PSK modem
    • Synchronisation functions
future content
Future content ?
  • Existing standards planned for further work
    • Future narrow band waveform (V/UHF)
    • MS 188-141 (HF ALE) – to complete part of HF house
    • STANAG 4591 – for voice service
  • Full content, see paper on waveform library …
    • Rational assessment of the ‘wish list’
    • 80 or more waveforms  16 or less
  • Existing software waveforms available
    • STANAG 4203/4/5c, 5066, MS 188-110B / 141A, TDLs
    • STANAG 4285 (RTO)
    • STANAG 4538 (BLOSComms AHWG)
    • STANAG 4539 (CRC)
    • STANAG 4444 (FRA) …….
    • TETRA EN 300-39x (SWE / US)
    • [ SATCOM STANAGs – NC3A for procurement tests ]
radio capabilities

Nothing here


Radio capabilities
  • No secure or net-centric tactical radio interoperability between nations




future waveforms
Future waveforms
  • Tactical wireless architecture (TN1246) identified need for secure, networking waveforms
    • Narrow band (land) – voice + data, VHF + UHF
    • Wide band (land) – data, UHF
      • Air-air variants also needed
  • Narrow band waveform (land) in development
    • Draft STANAG for Layer 1 developed, CAN + DEU
    • Layer 2 being designed – NOR
    • Implementation of Layer 1 on SDR – NC3A
    • Layers 1-3 being refined to support RBCI
radio based combat id
Radio based combat ID
  • IFF being established and serves air to air and ground to air
  • Ground to ground, and air to ground not well developed
  • All rely on transmissions i.e. wireless
  • All need interoperability, security and speed
  • RBCID imposes very difficult requirements


A to A

Mode 5

A to G



Mode 5

G to A

G to G


testing sdr28
Testing SDR
  • Growing recognition of testing
  • Lessons learned from other NATO programmes
    • E.g. SCIP
    • Recognition that testing is costly
    • No testing is more costly
  • Opportunities to collaborate
nato security constraints
NATO Security constraints
  • 3 programmable security functions …
  • 100,000 – 1,000,000 lines of code …
  • Network connection to other systems ….
  • A new, pragmatic approach to SDR security accreditation may be necessary
    • Be “risk aware” rather than “risk averse”
  • Nations and vendors recognise the problem
  • Solution needs to be multinational
    • For operational use
    • For export markets
  • No progress, but growing interest
  • SDR enables varied capability: reqs are varied
    • NATO wireless architecture user reqs & operational views
  • SCA exists as an accepted standard to aid porting
    • Developments still needed e.g. Interfaces and security
    • Long term, international management TBD
  • S/w waveform library can aid interoperability
    • Need agreed s/w format
    • Distribution model – industry only, govt supported ?
  • Interoperability defined by testing, not standards
sdr summary
SDR summary
  • Many nations procuring SDR
    • National focus is on national waveforms
    • Legacy support – needs legacy waveforms in software
      • Or will loose interoperability with NATO legacy stds
  • New waveforms are needed
    • For NNEC, efficiency and multi-national interoperability
  • SDR can aid fielding new waveforms
    • Don’t need to replace and refit radio hardware
    • Waveform library saves cost and time
    • Common SDR architecture aids waveform sharing
  • SDR needs cooperation to get the full benefit
thank you
Thank you

NSWAN: NC3A CISD TNSRC Street, Michael

+31 70 374 3444

+31 65 142 1275