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

1. Software defined radio to enable NNEC: Technical challenges and opportunities for NATO Dr Michael Street

2. 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

3. Wireless system of systems

4. 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)

5. Challenges for SDR Portability Interoperability Capability Testing Security

6. Portability • 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

7. Interoperability • 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

8. Capability • 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

9. 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

10. Security • 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

11. Security functions

12. Opportunities Portability Interoperability Capability Testing Security

13. Portability • 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

14. 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

15. 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

16. S5066 Software Overview • Modularized/Object-Oriented Code: • SCA design rules dictate modular software structure • Module interfaces are a significant part of the software

17. 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: • https://s5066.nc3a.nato.int/S5066loginreq/software/ • Need to follow SCA • Even for ‘base waveform’ software • SCA impacts software design

18. Standards in software: 188-110B Data sequence randomizing generator (pp. 45, 5.3.2.3.8.1) 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

19. 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) init_PRS_to_defaults; %fprintf('.'); else 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 fprintf('*');

20. 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. 101010101010101 010101010101010 101010101001010 101010101010101 010101010101010 101010101001010 101010101010101 010101010101010 101010101001010 ConfigDSP a=0 Load(a) Process(a) Shift() XOR(mem,b) a++ Std Open(filesys) GetParamaters() ConfigureSubSys LoadInitialData Do BeSDR While(exit_trigger) ClearSubSys Paper Std Base s/w Target s/w Executable

21. Government and industry roles • Different role of NC3A and industry • NC3A – high level and generic approach • Industry – mature, highly optimized and reliable solutions OR • 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

22. 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

23. 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

24. 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 ]

25. Nothing here NATO Radio capabilities • No secure or net-centric tactical radio interoperability between nations Secure Net-centric Interoperable

26. 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

27. 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 RBCI A to A Mode 5 A to G Rev IFF /RBCI Mode 5 G to A G to G BTID

28. 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

29. 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

30. Summary • 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

31. 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

32. Thank you Michael.Street@nc3a.nato.int NSWAN: NC3A CISD TNSRC Street, Michael +31 70 374 3444 +31 65 142 1275