EULER 4 1 ESRA recommendations - v1Deliverable 4.1 – ESRA recommendations extensions and maturity...

FP7-Security EULER

Deliverable 4.1 – ESRA recommendations extensions and maturity – Public 1/108

EULER

Deliverable 4.1

ESRA recommendations extensions and maturation

Version 1.0

Deliverable manager Contributors Checked by

Alejandro Sanchez (TCF)

Alejandro Sanchez (TCF), Colin Wigham (Prismtech), Andrew Foster

(Prismtech), Christophe Moy (SUPELEC), Aad Onderwater (TNO), Ruediger Leschhorn (R&S), Julio Diez Ruiz (INDRA), Raul Dopico

Lopez (INDRA)

Bruno Calvet (TCF)

FP7-Security EULER


Document lifecycle

Revision

number

Date Contributor Evolution

0.1 30th of March, 2010 Jean-Julien SABIANI (TCF) Document creation 0.2 1st of March, 2011 Alejandro SANCHEZ (TCF) Document update

0.3 4th of March, 2011 Alejandro SANCHEZ (TCF) Small modification of the work share following IND remarks.

0.4 29th of March, 2011 Alejandro SANCHEZ (TCF) Aad ONDERWATER (TNO)

TNO Contribution inserted

0.5 5th of May, 2011 Alejandro SANCHEZ (TCF) Ruediger LESCHHORN

(R&S)

Chapter 3 removed R&S Contribution added

(section 4.5.10)

0.6 6th of May, 2011

Alejandro SANCHEZ (TCF) Ruediger LESCHHORN

(R&S) Julio DIEZ RUIZ (IND)

INDRA contribution merged (sections 3.3 and 4.1)

Second R&S contribution added (section 4.5.9)

0.7 Alejandro SANCHEZ (TCF) ESRA profile definition elaborated

Overall document review

0.8 6th of June, 2011 Alejandro SANCHEZ (TCF),

Andrew Foster (PRI) Prismtech and SUPELEC

contributions added

0.9 9th of June, 2011 Alejandro SANCHEZ (TCF),

Colin Wighan (PRI) Section 4.4 added

1.0 23th of August, 2011 Alejandro SANCHEZ (TCF) Overall review for publication

FP7-Security EULER


Table of contents

1 INTRODUCTION ............................................................................................................. 8

1.1 TASK 4.1 OVERVIEW ............................................................................................................ 8 1.2 DOCUMENT SCOPE ............................................................................................................... 8 1.3 ABBREVIATIONS .................................................................................................................. 8

2 ESRA OVERVIEW, GOAL AND CURRENT STATUS ......................................................... 11

3 ESRA PROFILES............................................................................................................ 13

3.1 ESRA PROFILE DEFINITION...................................................................................................13 3.2 ESRA PROFILE FOR SPECIALIZED DEVICES.................................................................................14

3.2.1 POSIX: “Portable Operating System Interface for Unix” ............................................................ 15 3.2.2 MRAPI: “Multicore Resource API” ............................................................................................. 15 3.2.3 MCAPI: “Multicore Communications API” ................................................................................. 16

3.3 ESRA SECURITY PROFILE......................................................................................................16 3.3.1 Overview ....................................................................................................................................... 16 3.3.2 Security features............................................................................................................................ 17 3.3.3 Interfaces....................................................................................................................................... 19 3.3.4 Behaviours .................................................................................................................................... 21

4 ESRA RECOMMENDATIONS EXTENSION...................................................................... 23

4.1 SECURITY .........................................................................................................................23 4.1.1 Overview ....................................................................................................................................... 23 4.1.2 Guidelines for the definition of security requirements .................................................................. 23 4.1.3 Guidelines for security features .................................................................................................... 23 4.1.4 Guidelines for cryptographic operations ...................................................................................... 23

4.2 COMPUTING DEVICE(S) ........................................................................................................24 4.2.1 ASICs............................................................................................................................................. 24 4.2.2 GPPs and DSPs............................................................................................................................. 24 4.2.3 FPGAs........................................................................................................................................... 25 4.2.4 Computing devices interfaces........................................................................................................ 26

4.2.4.1 Ethernet ..................................................................................................................................... 26 4.2.4.2 Serial Port.................................................................................................................................. 26 4.2.4.3 Gps ............................................................................................................................................ 26 4.2.4.4 I/O Facilities.............................................................................................................................. 27 4.2.4.5 USB........................................................................................................................................... 27

4.3 COMPONENT PORTABILITY.....................................................................................................27 4.3.1 Portability versus Optimality ........................................................................................................ 28 4.3.2 Development Guidelines ............................................................................................................... 28

4.3.2.1 SDR Standards .......................................................................................................................... 28 4.3.2.2 General Development Guidelines.............................................................................................. 28 4.3.2.3 Consideration of Intended Use of the Waveform...................................................................... 30 4.3.2.4 Use of Third-Party Software ..................................................................................................... 30 4.3.2.5 Development Tools and Debug Code........................................................................................ 30 4.3.2.6 Modeling ................................................................................................................................... 31

4.3.2.6.1 PIM/PSM Modeling and Transformation........................................................................... 31 4.3.2.6.2 Signal Processing Code Modeling...................................................................................... 31 4.3.2.6.3 GPP Code Modeling........................................................................................................... 32

4.3.2.7 Waveform Architecture............................................................................................................. 32 4.3.2.8 Inline Documentation................................................................................................................ 34 4.3.2.9 C/C++ Programming Practices.................................................................................................. 34

4.3.3 GPP Guidelines............................................................................................................................. 39 4.3.3.1 GPP Performance ...................................................................................................................... 39

FP7-Security EULER


4.3.3.2 POSIX Compliance ................................................................................................................... 39 4.3.3.3 Use of SCA Standard APIs ....................................................................................................... 39 4.3.3.4 Device Interface Abstractions ................................................................................................... 39

4.3.4 DSP Guidelines ............................................................................................................................. 41 4.3.5 FPGA Guidelines .......................................................................................................................... 42 4.3.6 Domain Profile Guidelines............................................................................................................ 43 4.3.7 Documentation Guidelines............................................................................................................ 43

4.3.7.1 Waveform Design Specification................................................................................................ 44 4.3.7.2 Software Requirements Specification ....................................................................................... 44 4.3.7.3 Software Design Description..................................................................................................... 45 4.3.7.4 Interface Design Descriptions ................................................................................................... 46 4.3.7.5 Software Version Description ................................................................................................... 46 4.3.7.6 Waveform Porting Plan............................................................................................................. 47 4.3.7.7 Waveform Porting Report ......................................................................................................... 47

4.4 WF INTERFACES GUIDELINES. ................................................................................................47 4.4.1 Introduction................................................................................................................................... 48 4.4.2 Modelling Approaches associated with Component Model Architectures ....................................49

4.4.2.1 ESRA Case Study...................................................................................................................... 50 4.4.3 Software Communications Architecture (SCA) and associated Standards ...................................50

4.4.3.1 ESRA Case Study...................................................................................................................... 51 4.4.4 The SCA Component Model and the SDR environment ................................................................ 52

4.4.4.1 ESRA Case Study...................................................................................................................... 52 4.5 RADIO INTERFACE(S)...........................................................................................................53

4.5.1 Introduction................................................................................................................................... 53 4.5.2 Philosophy on Interfaces............................................................................................................... 56 4.5.3 Generic interfaces ......................................................................................................................... 58 4.5.4 Interfaces in detail......................................................................................................................... 59

4.5.4.1 Frequency reference interface ................................................................................................... 60 4.5.4.2 Link Layer................................................................................................................................. 60 4.5.4.3 Antenna interface ...................................................................................................................... 60 4.5.4.4 MHAL API................................................................................................................................ 61 4.5.4.5 I/Q Baseband & Control Interface............................................................................................. 62

4.5.4.5.1 Introduction ........................................................................................................................ 62 4.5.4.5.2 Common Public Radio Interface CPRI V4.2...................................................................... 64

4.5.4.5.2.1 General ........................................................................................................................ 64 4.5.4.5.2.2 Physical Layer ............................................................................................................. 65 4.5.4.5.2.3 Link Layer ................................................................................................................... 66 4.5.4.5.2.4 Time synchronisation .................................................................................................. 68 4.5.4.5.2.5 Frequency Synchronisation ......................................................................................... 68 4.5.4.5.2.6 Link Synchronisation and Maintenance ...................................................................... 68

4.5.4.5.3 WINNF IQ Baseband Interface .......................................................................................... 68 4.5.4.5.3.1 General ........................................................................................................................ 68 4.5.4.5.3.2 Physical Layer ............................................................................................................. 70 4.5.4.5.3.3 Link Layer ................................................................................................................... 70 4.5.4.5.3.4 Application Layer ........................................................................................................ 71 4.5.4.5.3.5 Time Synchronisation.................................................................................................. 73 4.5.4.5.3.6 Frequency Synchronisation ......................................................................................... 75

4.5.4.5.4 Digital RF interface ............................................................................................................ 75 4.5.4.5.5 SDR Forum (Wireless innovation forum) Transceiver Facility.......................................... 76

4.5.4.5.5.1 Transceiver Subsystem definition................................................................................ 76 4.5.4.5.5.2 Transmit channel ......................................................................................................... 78 4.5.4.5.5.3 Receive channel........................................................................................................... 81 4.5.4.5.5.4 Time management ....................................................................................................... 84

4.5.4.5.6 Assessment for EULER Use............................................................................................... 84 4.5.5 I/O radio subsystems ..................................................................................................................... 85

4.5.5.1 Logical Devices......................................................................................................................... 86 4.5.5.2 Façades...................................................................................................................................... 87

4.5.6 Digital transceiver chain............................................................................................................... 87

FP7-Security EULER


4.5.7 Transceiver Components............................................................................................................... 90 4.5.7.1 Component-Based Development (CBD)................................................................................... 90 4.5.7.2 CORBA..................................................................................................................................... 90 4.5.7.3 GPP and DSP Component Models............................................................................................ 91 4.5.7.4 FPGA Component Models ........................................................................................................ 92

4.5.7.4.1 Dynamic Partial Reconfiguration ....................................................................................... 94 4.5.7.4.2 High bandwidth waveforms requiring FPGA usage........................................................... 95

4.5.7.5 Multi-cores processors .............................................................................................................. 95 4.5.7.6 Real-Time Engineering ............................................................................................................. 95 4.5.7.7 Reconfiguration......................................................................................................................... 96

4.5.8 Radio Domain Devices & Services ............................................................................................... 98 4.5.9 Architecture Evaluation and Certification .................................................................................... 98

4.5.9.1 Why certification? ..................................................................................................................... 99 4.5.9.2 Important terms ......................................................................................................................... 99 4.5.9.3 What to certify......................................................................................................................... 100 4.5.9.4 The standardization/certification process and the players 0 .................................................... 101 4.5.9.5 A Concrete Example ............................................................................................................... 104

5 CONCLUSION ............................................................................................................. 106

6 REFERENCES .............................................................................................................. 107

FP7-Security EULER


Table of tables Table 1: ESRA features for specialized devices ...............................................................................14 Table 2: ESRA Profile security features ..........................................................................................17 Table 3: ESRA Profile security features interfaces inputs .................................................................19 Table 4: ESRA Profile security features behaviours .........................................................................21 Table 5: Portable C/C++ Language Features .................................................................................34 Table 6: Non-Portable C/C++ Language Features ..........................................................................36 Table 7: IQ sample formats ..........................................................................................................66 Table 8: IQ sample formats ..........................................................................................................70 Table 9: link modes and data throughput.......................................................................................70 Table 10: Certification terms and definitions ..................................................................................99 Table 11: Objects to be standardized/certified .............................................................................101

FP7-Security EULER


Table of figures Figure 1: Example of Platform Abstraction .....................................................................................40 Figure 2: SCA 2.2.2 Device Model..................................................................................................40 Figure 3: CORBA Everywhere Model ..............................................................................................41 Figure 4: from Functional abstraction to Implementation of Platform Support ..................................54 Figure 5: SDR implementation of Front-end electronics...................................................................55 Figure 6: High Level System..........................................................................................................56 Figure 7: Considered Interfaces.....................................................................................................57 Figure 8: MHAL API ......................................................................................................................61 Figure 9: MHAL API Reference Deployment Diagram ......................................................................62 Figure 10: separation of a BS into BS server and RRH [].................................................................63 Figure 11: position of digital base band interface in a radio base station system...............................65 Figure 12: chain, tree and ring topology, supported by CPRI...........................................................65 Figure 13: frame hierarchy of CPRI................................................................................................66 Figure 14: AxC container mapping.................................................................................................67 Figure 15: Example of protocol stack .............................................................................................67 Figure 16: position of digital base band interface in a SDR..............................................................68 Figure 17: connecting one BBU to multiple transceiver modules ......................................................69 Figure 18: tree topology of TRX ....................................................................................................69 Figure 19: principal frame set-up...................................................................................................70 Figure 20: message header set-up ................................................................................................71 Figure 21: control payload structure ..............................................................................................72 Figure 22: TX BBU TX payload structure standard sampling format .................................................72 Figure 23: transceiver module TX payload structure standard sampling format.................................72 Figure 24: downsampling by factor 4 for mode A ...........................................................................73 Figure 25: Timing offset receiver samples ......................................................................................74 Figure 26: timing offset commands ...............................................................................................75 Figure 27: DigRF v1.12 interface signals .......................................................................................76 Figure 28: Transceiver Subsystem within a functional radio implementation chain ............................77 Figure 29: Transceiver Subsystem and related capabilities ..............................................................77 Figure 30: External interfaces of a Transceiver Subsystem..............................................................78 Figure 31: Internal structure of a Transceiver ................................................................................78 Figure 32: Overview of a Transmit Channel....................................................................................79 Figure 33: States and transitions of the Up-conversion Chain ..........................................................80 Figure 34: Time profile of Transmit Cycle.......................................................................................81 Figure 35: Overview of a Receive Channel .....................................................................................82 Figure 36: States and transitions of the Down-conversion Chain......................................................83 Figure 37: Time Profile of a Receive Cycle......................................................................................83 Figure 38: Platform Sub-system implementation with Logical Device ...............................................86 Figure 39: Radio subsystem with façade ........................................................................................87 Figure 40: Generic SDR constituents..............................................................................................88 Figure 41: Elements in transceiver architecture ..............................................................................88 Figure 42: Tuner architecture........................................................................................................89 Figure 43: Double super tuner.......................................................................................................89 Figure 44: Spectrum sensing options .............................................................................................90 Figure 45: Component Model communications with CORBA layer.....................................................91 Figure 46: Typical high data rate SDR platform architecture with FPGA............................................93 Figure 47: parallel execution of modules........................................................................................94 Figure 48: Functional waveform decomposition ..............................................................................95 Figure 49: Overview of Reconfiguration Infrastructure role .............................................................97 Figure 50: Standardization phase ................................................................................................102 Figure 51: Certification preparation phase....................................................................................103 Figure 52: Certification execution phase ......................................................................................104

FP7-Security EULER


1 Introduction

1.1 Task 4.1 overview This task was initially consisting in the revision and update of the set of recommendations and specifications generated by the WINTSEC project. Chapter 2 delves on the rationale for the modifications introduced in the document regarding its initial objectives. However, it can be already stated that the goal are achieved following basically two directions : • Clarifying WINTSEC terminology: clarifications are obtained thanks to the implementation of some

of the WINTSEC principles, implementation done within EULER, • Finalizing and completing definitions in areas not or partly addressed by WINTSEC. The work is likely to fall in the following topics: • ESRA profiles for specialized computing devices (DSPs, FPGAs): support for full components

portability, real-time execution, waveform components interfaces guidelines, definition of Radio-Devices interfaces (e.g interface to the antenna subsystem, but also input/outputs)

• ESRA security profile: definition of interfaces and associated semantics to configure and use security solutions.

1.2 Document scope The document is organized in chapters as described here: Chapter 1: This introduction. Chapter 2: Discusses in detail the motivations, goals and specific issues of the present deliverable. Chapter 3: Introduces the concept of ESRA profile and then extends the definition for specialized devices. The security related features that an ESRA profile should address are also described in detail. Chapter 4: It is core of the document. It elaborates on the ESRA recommendations and draws some requirements when identified. It discusses computing devices choices and delves into the important topic of Portability. It provides an overview of interfaces and addresses the certification issue.

1.3 Abbreviations 3GPP Third Generation Partnership Project AGC Automated Gain Control ALU Arithmetic Logic Unit AEP Application Environment Profile API Application Programming Interface ARP Address Resolution Protocol ASIC Application Specific Integrated Circuit BER Bit Error Rate BSP Board Support Package BBU Base Band Unit CCM Corba Component Model CISC Complex Instruction Set Computer CE Computational Element CF Core Framework COMSEC Communications Security CORBA Common Object Request Broker Architecture COTS Commercial Off the Shelf CPRI Common Public Radio Interface CR Cognitive Radio CRC Cyclic Redundancy Check CSCI Computer Software Configuration Item CSMA/CD Carrier Sensing Multiple Access/Collision Detection

FP7-Security EULER


DPR Dynamic Partial Reconfiguration DSL Domain Specific Languages DSM Domain Specific Modelling DSP Digital Signal Processor DTD Document Type Definition FDD Frequency Division Duplexing ESRA European Software Radio Architecture ETF Extensible Transport Framework EULER European software defined Radio for wireless in joint security operation EWF EULER WaveForm FDD Frequency Division Duplex FEC Forward Error Correction FPGA Field-Programmable Gate Array GIOP General Inter ORB Protocol GPP General Purpose Processor HDL Hardware Description Languages HDLC High Level Data Link Control IDD Interface Design Description IDL Interface Definition Language IEEE Institute of Electric and Electronic Engineering IIOP Internet Inter ORB Protocol IP Internet Protocol IP Intelectual Property ISA Instruction Set Architectures JPEO Joint Program Executive Office JTEL JTRS Test and Evaluation Laboratory JTRS Joint Tactical Radio System LAN Local Area Network LLC Link Layer Control MAC Medium Access Control, Multiply Accumulate MDA Model Driven Architecture MDD Model Driven Development MHAL Modem Hardware Abstraction Layer MIMO Multiple Input Multiple Output MIPS Millions of Instructions per Second OE Operating environment OMG Object Management Group OO Object Oriented ORB Object Request Broker ORD Operational Requirements Document OS Operating System OSI Open Systems Interconnection OTA Over-the-Air PHY Physical Layer PIM Platform Independent Model P&GS Public and Government Security PKCS Public Key Cryptographic Standards POSIX Portable Operating Systems Interface PR Partial Reconfiguration PRF Properties File PS Public Safety PSM Platform Specific Model PPVT Post Port Verification Test RE Radio Equipment REC Radio Equipment Control

FP7-Security EULER


RISC Reduced Instruction Set Computer RRH Remote Radio Head RT/E Real-Time/Embedded SAT Satellite SCA Software Communications Architecture SCD Software Component Descriptor SDD Software Design Description SDP Software Development Plan SDR Software Defined Radio SDR-PF Software Defined Radio Platform SiS Signal in Space SPD Software Package Descriptor SRS Software Requirements Specification SVD Software Version Description SWAP Size Weight and Power TDMA Time Division Multiple Access TETRA Terrestrial Trunked Radio TRANSEC Transmission Security UML Unified Modelling Language UMTS Universal Mobile Telecommunications System UTRA/E-UTRA

UMTS Terrestrial Radio Access/Enhanced UTRA

UUIDs Universal Unique Identifiers VLIW Very Long Instruction Word WDS Waveform Design Specification WI Waveform Integrator WiMAX Worldwide Interoperability for Microwave Access WINNF Wireless Innovation Forum WPP Waveform Porting Plan WPR Waveform Porting Report WF WaveForm XCVR Transceiver XML eXtensible Markup Language

FP7-Security EULER


2 ESRA overview, goal and current status ESRA or “European Software radio Architecture” was an endeavor of WINTSEC project to come up with a complete SDR architecture built on top of the SDR state of the art at that time (i.e three years ago). Together with a complete state of the art review, the main output of the work accomplished was a high level architecture together with a set of guidelines, recommendations and development path for the SDR in Europe [1] [2] [3]. ESRA dug into the details of the main SDR architectures paying particular attention to the SCA 2.2.2 specification. At the present time, ESRA approach and principles may be considered as obsolete or not applicable anymore, due to recent advances in the domain and essentially (from an European perspective) owing to the current Euopean new ESSOR “European Secure SOftware Radio” program launched and funded by the OCCAR (Organisation Conjointe de Coopération en matière d'ARmement). ESSOR is a much more focused effort for producing a shared architecture and a common waveform for up to six national platforms (France, Italy, Spain, Poland, Sweden and Finland). Therefore ESRA goal of maturating SDR technology and its final objective of defining a new standard for the European Software Radio Architecture are mostly superseded by ESSOR. It is also worth noting that, still in Europe, other countries (not involved in ESSOR, typically Germany) are designing their own architectures through national programs. Additionally, the SCA 2.2.2 specification that was an important input for the analysis ESRA carried out, is as well undergoing a major revision known under the name of “SCA next”. “SCA next” should mitigate many of the drawbacks and shortcomings that ESRA identified. For a complete overview of the JTRS SCA look at the references [4] [5] [6] [7] [8] [9] [10]. In spite of all these new recent evolutions both in Europe and North-America, the ESRA documents remain a fundamental reference for SDR approaches and architectural principles. A significant amount of ESRA concepts and principles are included and considered by ESSOR and SCA Next. Typically ESRA pointed out the SCA standard limitations in terms of performance, functionalities and a lack of generic implementation of WF applications:

• Among SCA performances limitations, ESRA highlighted that the CORBA technology (which is required for SCA 2.2.2 compliance) leads to poor real-time characteristics and complex solutions since CORBA support is not always available for all processing components (DSP, FPGA, ASICS). For that reason, ESRA proposed a different approach, imposing fewer constraints, and it defined just an “IDL top level compatibility” requirement. As a consequence, the middleware technology is free and the way to implement IDL interfaces is also left to the implementer choice. These issues do not affect portability because container generation is any case a porting issue. Having a “middleware-free” technology based on IDL compatibility allows a performance increase and, as a bonus, fosters competition for third party middleware offerings.

• Among SCA functionally limitations, ESRA pinpointed that there is no “WF generic

architecture” or no “standard component”. Real-time impacting mechanisms, which are platform dependent, are not part of any standardization (Time machine, WF application synchronization). As a consequence, a WF has to re-implement these mechanisms for each new platform porting. ESRA outlines a different approach for that, more specific, and that defines “standard component” or “standard behaviour” concepts, such as “Transceiver Device”, in order to increase WF portability.

• Regarding the lack of generic implementation, it was noted that many SCA-based WF use only

the GPP as “SDR platform”, and do not integrate fully other sorts of processors such as DSP and FPGA into the SDR platform. Often, DSP and FPGA are used as “specialized devices” by

FP7-Security EULER


the SCA-based WF running on the GPP. A main goal of ESRA was to make generic all sorts of processors. This target set additional constraints because all SDR platform processor has to embed a middleware layer.

FP7-Security EULER


3 ESRA Profiles

3.1 ESRA Profile definition The ESRA profile concept was introduced together with the whole ESRA approach. An ESRA profile is defined as a set of requirements an ESRA platform shall meet. According to this definition, the concept of ESRA profile applies to a given SDR radio set or platform, referred to hereinafter as SDR-PF. Different profiles gather requirements for functionalities and processing units. Depending on the set of supported functionalities and available resources, an SDR-PF will meet a given number of ESRA profiles. From a high level point of view ESRA profiles may be classified in scenario categories in accordance to the SDR-PF potential final applications. From the SDR-PF standpoint ESRA profiles draw constraints for the configuration that essentially encompasses both, provided functionalities and processing resources of an SDR-PF:

• Example functionalities are security, radio, audio, video • The processing units are GPP, DSP, FPGA, ASICs

ESRA profile may fall in one or several of the following classes:

• Mobile profile: The main requirement is the SDR-PF supporting mobility. Other requirements stemming from mobility are low power consumption for battery operation, light weight and reduced form-factor (handheld, manpack, on-board vehicle)

• Airborne profile: This profile is intended for air vehicles. It typically includes especial

certification requirements for aviation communications, redundant features and ruggerized features for operation in hostile conditions (temperature, vibrations)

• Naval profile: A profile for SDR-PF on surface and submarine vessels.

• Satcom profile: The outstanding requirement for SDR-PF is redundancy and resilience for

space operation with very limited or no at all human maintenance support. Like airborne systems ruggerized features are required.

• Military profile: A profile for warfare and tactical SDR-PF. Military standardization certification

(SCA) is typically a requirement for this kind of equipment.

• Civil profile: The main requirements for civil SDR-PF usually lay on the interference and power emission constraints for operation in regulated bands in crowded spectrum bands.

• Public safety profile: It is aiming at law-enforcement and first respondent equipment.

Supporting interoperability and reconfiguration capability are typical requirements for this profile.

• Safety critical profile: For transportation systems in which human lives are at stake.

Certification with safety standards are the most common requirements for this profile (DO-178, DO-254)

FP7-Security EULER


3.2 ESRA profile for specialized devices Within this document the term “specialized device” refers to a DSP or a FPGA. Specialized devices are typically constrained environments devoted to very specific functionalities. Owing to the very specific tasks these devices are in charge of, performance is often a fundamental requirement. The next table lists (not exhaustively) the main features that a specialized device should provide.

Table 1: ESRA features for specialized devices

Feature Description Comments Low power The capability to operate in low power

modes is usually a key feature for DSPs. Low power enables device integration in battery operated equipment. Depending upon the low power category into which the device falls, hanheld, manpack or on-board vehicle form factors are possible

Excellent low power characteristics are typical of DSPs. FPGAs are less energy efficient devices.

Signal processing coprocessors

As a matter of performance co-processors are built-in DSPs to increase data throughput. The coprocessor implement in hardware widely spread and well-known signal processing algorithms (FEC processing like Viterbi are common)

The downside of co-processors is slightly added programming complexity and cost. Co-processors are available in DSP, the concepts makes no sense for FPGAs where an specialized IP hardwired block fulfils the functionality

Encryption coprocessor

Similarly, dedicated coprocessors for advanced encryption may be provided by DSPs. FPGAs use specialized IPs to address this capability.

The same previous remarks of costs and programming complexity for signal processing co-processor are applicable.

Timers For real-time operation timers are a mandatory feature. Timers are present in DSPs as specialized peripherals.

Specific hardware interfaces

Specialized devices interact closely among themselves and with other dedicated hardware (RF Transceivers, I/O devices, clock circuitry). To handle the wide variety of existing interfaces peripherals implementing the mechanical, electrical and software protocol to exchange data are needed.

SPI, I2C, HPI, DigRF, EMIF to name a few are the hardware interfaces DSPs and FPGAs shall feature

Synchronization interfaces

Within given architectures additional timing interfaces may be requested to convey accurate timing signals.

Some radio standards where timely air interface access constraints are stringent may require such interfaces.

Multicore architecture

An architectural choice to attain high performance with reasonable low power features

Multicore architectures are opposed to single core architectures. Many core architectures are a different breed of processors with a large number of very simple cores. These architectures should support multicore programming interfaces for the sake of harnessing the

FP7-Security EULER


great programming complexity of these architectures.

BSP and drivers support

In order to reduce programming complexity and speed up time-to-market, DSPs with a rich set of drivers integrated in a complete board support package is a must-have feature.

Nowadays is very uncommon to find “bare-metal” offerings for DSP products without any elaborated drivers support.

RTOS support Lightweight optimized real-time operating systems are tightly coupled with DSPs. In order to master the great complexity applications for new modern radiocommunications standards a DSP featuring a RTOS is a common characteristic.

The huge number of available RTOS, implementing their own set of services each makes the POSIX interfaces support a sought feature in order to simplify programming and enhance portability.

Regarding interfaces, the next paragraphs deal with the main application programming interfaces in a non exhaustive way. Special attention is paid to multicore/manycore programming interfaces. Supporting those interfaces is becoming a fundamental requirement in order to take full benefit of the processing power of new multicore processors without incurring in an expensive development cycle.

3.2.1 POSIX: “Portable Operating System Interface f or Unix” POSIX is a family of IEEE standards primarily defining a set of Application Programming Interfaces for operating systems. POSIX aims at standardization of interfaces for recurrent and common programming tasks. POSIX standards cover functionalities like:

• Core functionalities: Process Creation and Control, Signals, Segmentation / Memory Violations, Timers, File and Directory Operations, Pipes, I/O Port Interface and Control.

• Real-time: Priority Scheduling, Real-Time Signals, Clocks and Timers, Semaphores, Message Passing, Shared Memory, Asynch and Synch I/O, Memory Locking Interface.

• Threads: Thread Creation, Control, and Cleanup, Thread Scheduling, Thread Synchronization, Signal Handling.

DSP with built-in RTOS POSIX interface boosts portability and productivity with a well-know family of standards shared by a large community.

3.2.2 MRAPI: “Multicore Resource API” MRAPI [11] defines an API for application-level management of shared resources in multicore embedded systems. It supports queries regarding static and dynamic resources, and it supports system-level event notification such as power-savings states, device failures, and hypervisor repartitioning. The managed resources include cores or chips, hardware accelerators, memory regions, and I/O. MRAPI supports the ability to declare and allocate or destroy shared memory regions, and to identify nodes which have access to each region. MRAPI also provides application-level synchronization primitives for coordinating access to shared resources. The multiple cores may be homogeneous or heterogeneous and located on a single chip or on multiple chips in a circuit board. MRAPI is scalable and can support virtually any number of cores, each with a different processing architecture and each running the same or a different operating system, or no OS at all. As such, MRAPI is intended to provide source-code compatibility that allows applications to be ported from one operating environment to another well into the future.. The set of features of MRAPI includes:

• Primitives for synchronization: Mutexes, Semaphores, Writer and Reader locks. • Memory primitives: Shared Memory and Remote Memory. • Metadata primitives.

FP7-Security EULER


3.2.3 MCAPI: “Multicore Communications API” MCAPI [12] is an applications program interface (API) for passing data between cores in an Asymmetrical Multiprocessor system. It was first published by the Multicore Association (MCA) in 2008. The key objective is to provide source code compatibility across multiple operating systems, while providing the flexibility to tune for performance or footprint in true embedded software fashion. Aiming at portable application code, a typical MCAPI implementation exhibits low latency and high performance, supports multiple channels and facilitates prioritization of communications. MCAPI is built around the fundamental concepts of nodes and domains. A system includes one or more domains and each domain includes a number of nodes. A node may broadly be seen as a stream of code execution (process, thread, task). An endpoint is a destination to which messages may be sent or to which a connection may be established. Specialized multicore devices providing implementations of MCAPI feature an enhance portability and ease of programming. MCAPI offers different alternatives for the transfer of data. Basically, there are three options:

• Messages in datagrams – chunks of data – sent from one endpoint to another. No connection needs to be established to send a message.

• Packet channels: first-in/first-out unidirectional stream of data packets of variable size, sent from one endpoint to another, after a connection has been established.

• Scalar channel: similar to a packet channel, but processes single words of data, where a word may be 8, 16, 32, or 64 bits of data.

3.3 ESRA security profile

3.3.1 Overview The ESRA security profile specifies:

• security functions required for an ESRA secured SDR-PF, • security interfaces • behaviors related to functions and interfaces.

The identification and definition of the security features of a SDR-PF is a complex activity which has to take into account aspects such as:

• P&GS Scenarios • SDR-PF environment & threat analysis • Supported WF Applications • Other constraints (SWaP, certifications, etc)

The P&GS scenarios highlight the communications needs for public safety forces. WINTSEC and EULER projects analyse, among other topics, how the SDR technology can be used in crisis scenarios for enhancing interoperability between different agencies, at different levels (PAN, IAN, etc) and with different roles (terminal and/or base station). Furthermore these scenarios determines the type of interconnected services required for an optimal inter equipment integration (user authentication vs terminal authentication, network interconnection and gateways, extension of a wireless network service to other interconnected networks, core network services offered to every interconnected network, etc) The SDR-PF environment extends the P&GS scenarios with other requirements such as the ones obtained from the threat analysis for the SDR technology, as described in section “10.1.2 SDR threat scenario” from [13]. The countermeasures to mitigate these threats are part of the design of the SDR equipment. The associated policies, which can determine how the equipment is configured, managed, etc., may impose complementary security requirements on the SDR-PF.

FP7-Security EULER


The WF applications use the SDR-PF capabilities as a support to complete the implemented wireless standard. The separation between WF and PTF logic is frequently one of the main discussions when different teams are involved in the design and development of an SDR equipment (SDR-PF+WF). In addition each WF application, which implements a different wireless communication standard, requires different security capabilities support (e.g. session key negotiation, OTAx services, etc).These needs may be quite heterogeneous thus the list of supported WFs should be an input for SDR-PF definition. Additional WFs can of course be ported into an already existing SDR-PF later on, but certain re-engineering may be foreseen. Other constraints can also impact on the security aspects of a SDR-PF. For example:

• SWaP can limit the usage of HW elements (e.g. powerful processors vs energy-efficient ones, cryptographic coprocessors, etc)

• Security and cryptographic certifications impose a set of requirements which depend on the required level of security associated to the pursued certification (e.g. Common Criteria, FIPS 140-21, etc)

All these issues, and probably others which are not considered in this analysis (e.g. national regulations, target customer’s specific needs, etc), have to be taken into account for the definition of the security mechanisms included within a SDR-PF. The aim of the ESRA security profile is therefore to define a common set of features to be considered as a guideline by the SDR-PF designer without preventing further decisions on the detailed design. In addition, the ESRA security profile can be used as a first verification point in order to check if a WF can be ported to a specific SDR-PF. The final match between the WF and the SDR-PF shall be addressed as part of the porting activities.

3.3.2 Security features In the following table the ESRA security profile is introduced:

• The ‘Feature’ column identifies the security function. • The ‘Description’ column explains the security feature. This column may be later removed for

the ESRA security profile of a specific SDR-PF. • ‘Support’ field identifies the scope of the security feature. In the table the possible values are

introduced. Note that not all the values may be applicable to every security feature and that the ones reported in the table are considered as maximums • N/A - Not supported or not applicable. This value is only used by specific SDR-PFs when

claiming an ESRA Security profile. • WS – Waveform Support. Function is available for WF applications, but not used for

protecting the SDR-PF. • PS – SDR-PF Support. Function is implemented within the SDR-PF and used to protect it,

but it can not be used by WF applications. • W&PS – Waveform and SDR-PF support. Function can be used for WF and already in used

for protecting the SDR-PF. • ‘Comments’ field can be used to provide additional information when applicable (such as the

supported encryption algorithms).

Table 2: ESRA Profile security features

Feature Description Support Comments User Authentication

Validation of the identity of the user of the terminal

W&PS Each SDR-PF should describe here how this function is achieved (algorithms, protocols, required infrastructure, etc).

1 The Federal Information Processing Standard (FIPS) Publication 140-2, is a U.S. government computer security standard used to accredit cryptographic modules. The title is Security Requirements for Cryptographic Modules. Initial publication was on May 25, 2001 and was last updated December 3, 2002.

FP7-Security EULER


Terminal Authentication

Validation of the identity of the terminal


User Authorization Verification of the actions that a user can perform


Terminal Authorization

Verification of the actions that a SDR-PF can perform


User Accountability

Registration of the actions performed by a user


Terminal Accountability

Registration of the actions performed by a terminal


Digital certificates Support of digital certificates for implementing any of the security functions

W&PS Each SDR-PF should describe here how digital certificates support is achieved (e.g. PKI, etc) as well as any other relevant information (such as format, etc).

Data Encryption Limits the access to the information by ciphering it

W&PS Each SDR-PF should describe here the list of supported algorithms, modes and any relevant information associated to them (key length, etc).

Data Integrity Assures the correctness of the information


Data Authentication

Assures the correctness of the sources of the information


Random numbers Generation of random and/or pseudo random numbers

W&PS Each SDR-PF should describe here the list of supported algorithms and any relevant information associated to them.

Session keys Obtaining temporary keys for protecting the communications


Secure Remote Management

Allows the remote management of the system in a secure way


Availability Mechanisms to prevent Denial of Service

W&PS Each SDR-PF should describe here the mechanisms to prevent denial of service attacks.

SDR-PF integrity Protection mechanisms to identify the manipulation of

PS Each SDR-PF should describe here the mechanisms on which SDR-PF

FP7-Security EULER


the SDR-PF integrity is based. Secure management of WF applications

Prevention of the execution of malicious applications

PS Each SDR-PF should describe here the mechanisms to manage the WF applications in a secure way.

Security domains Processing of the information in different security domains (e.g. red/black domains)

W&PS Each SDR-PF should describe here the supported security domains and how they can be used by the WF application.

3.3.3 Interfaces The previously defined security features can rely on different mechanisms to achieve the pursued security functions. For example, user authentication can be based on a username and a password, a digital certificate stored in a smartcard or even a dedicated HW token. This openness in the design and implementation of a SDR-PF increases the difficulty of defining a detailed reference interface. In addition, a strict interface would impose certain constraints on the SDR-PFs and would limit the adoption of ESRA security profile as common security reference for SDR technology stakeholders. For these reasons this section identifies the main inputs for each security function, allowing the designer to decide the interface which better fits the target SDR-PF needs (SCA JTRS, PKCS, etc). Even if it is true that this approach does not maximize WF portability, it assures a common understanding of the security functions related to each SDR-PF. For simplicity complementary inputs such as cryptographic algorithms, keys and similar parameters are not reported. Management of these elements is also out of the security profile because although they are assumed, the way they are implemented can widely differ for each SDR-PF. Unlike the identified security functions, the management operations are highly dependent on the detailed design and thus comparing different implementations goes beyond the scope and aim of ESRA security profiles. The following table includes the identification of the principal input for the most representative security function associated to the security feature. Comments column identifies some of the possible solutions or mechanisms for implementing the corresponding security function. The final interface implemented in a specific SDR-PF shall consider the needs of the selected mechanism.

Table 3: ESRA Profile security features interfaces inputs

Feature Main Input Comments User Authentication

User Credentials User Credentials can be username+password, digital certificates, biometric information, etc.


Terminal Credentials Terminal Credentials can be based on a device serial number, a digital certificate, etc.

User Authorization User action to be validated User authorization can be implemented by different mechanisms such as discretionary, role based or mandatory access control.


Terminal action to be validated

Terminal authorization can be implemented by different mechanisms such as network access control.

User Accountability

Action requested by the user to be registered

User actions can, for example, be registered locally (within the SDR-PF) or remotely (a dedicated server) and can be split into two levels (WF applications and SDR-PF).

Terminal Action requested by the Terminal actions can, for example, be registered

FP7-Security EULER


Accountability terminal to be registered locally (within the SDR-PF) or remotely (a dedicated server) and can be split into two levels (WF applications and SDR-PF).

Data Encryption Data to be protected. Different algorithms and modes may require specific input parameters. How the encryption function is used may impact also on the interface (e.g. session oriented vs packet oriented).

Data Integrity Data to be protected Different algorithms and modes may require specific input parameters. How the integrity function is implemented may impact also on the interface (e.g. message authentication codes, digital signatures).

Data Authentication

Data and headers to be protected

Different algorithms and modes may require specific input parameters. How the authentication function is implemented may impact also on the interface (e.g. message authentication codes, digital signatures).

Random numbers N/A Different algorithms may require specific input parameters.

Session keys N/A Different session key schemes, protocols, algorithms and modes may require specific input parameters (e.g. key generation, key distribution, key negotiation, etc).

Digital certificates N/A Operations based on digital certificates may vary on each SDR-PF. Management capabilities (e.g. on expiration or revocation), their organization (e.g. hierarchy) and interaction with external elements (e.g. PKI) may impact also on the interface. No inputs are reported because there is not a single specific function associated to the security feature; digital signatures could be one representative function but it is allocated to data authentication for example.


N/A Different protocols (e.g. SNMP, SSH, etc) may require specific input parameters. No inputs are reported because there is not a single specific function associated to the security feature.

Availability N/A Different mechanisms can be used for assuring availability (e.g. robust implementations, redundancy, etc).

SDR-PF integrity N/A Different mechanisms can be used for assuring SDR-PF integrity (e.g. anti-tamper HW, digital signature of SW files, etc).

Secure management of WF applications

N/A Different mechanisms can be used for assuring the secure management of WF applications (e.g. control of downloaded SW, control of executed SW, secure storage of SW files, etc).

Security domains N/A Different domains can be implemented in a SDR-PF (e.g. red/black domains). These domains are not associated to a primitive, thus no inputs are reported.

FP7-Security EULER


3.3.4 Behaviours The following table includes the general behaviours expected for each security function. Nevertheless, these behaviours are just an initial reference which may be detailed by each SDR-PF.

Table 4: ESRA Profile security features behaviours

Feature Typical achieved behaviour Behaviour when a failure occurs User Authentication

User is authenticated User is not authenticated. Countermeasures may be included when multiple failures occur.


Terminal is authenticated Terminal is not authenticated. Countermeasures may be included when multiple failures occur.

User Authorization User action is authorized User action is not authorized, thus it can not be performed.


Terminal action is authorized Terminal action is not authorized, thus it can not be performed.

User Accountability

The user action is registered If the user action can not be registered multiple behaviours are possible:

- action is cancelled - action is performed but

registered later - an error, exception or alarm

is raised - others, if required

Terminal Accountability

The terminal action is registered If the terminal action can not be registered multiple behaviours are possible:

- action is cancelled - action is performed but

registered later - an error, exception or alarm

is raised - others, if required

Data Encryption Ciphertext/Plaintext is obtained (ciphering/deciphering)

An error, exception or alarm is raised.

Data Integrity Integrity tag is obtained/verified An error, exception or alarm is raised. Data Authentication

Authentication tag is obtained/verified An error, exception or alarm is raised.

Random numbers A random number or a sequence of random numbers is obtained


Session keys Session keys are available for their use within other security functions


Digital certificates Digital certificates can be used for generating or verifying digital signatures



The SDR-PF can be managed remotely in a secure way

No remote management is possible in a secure way. Alternative methods and their related actions will depend on the design of the SDR-PF.

Availability The SDR-PF and the WF are executed without disruptions of the services

Availability of the system services is not assured. If availability is not assured:

- inspection or auditory may be

FP7-Security EULER


required - the SDR-PF may be used but

services might be interrupted during operation

- usage of the SDR-PF may be limited to certain scenarios

SDR-PF integrity The SDR-PF has not been modified without authorization

When integrity verification fails: - the SDR-PF may stop - errors, exceptions or alarms

may be raised - Other actions may be taken

(e.g. SDR-PF inspection or auditory)

Secure management of WF applications

The WF can be executed with confidence

There is no assurance on the correctness of the WF files. When a SDR-PF which includes secure management of WF application detects a failure:

- WF should not be executed - WF files may be quarantined - Other actions may be taken

(e.g. SDR-PF inspection or auditory)

Security domains Information can be isolated into different security domains

There is no assurance on the correct isolation of the different types of information. In these circumstances:

- SDR-PF may stop current operations

- errors, exceptions or alarms may be raised

- Other actions may be taken (e.g. SDR-PF inspection or auditory)

FP7-Security EULER


4 ESRA recommendations extension This chapter complements the WINTSEC ESRA recommendations with additional new recommendations and the extension/maturation of the existing WINTSEC base. This document is not intended to analyze one by one the ESRA recommendations, the approach followed is rather pragmatic and prefers to build on the EULER implementation experience to highlight the main issues encountered:

• The security • The diversityof computing devices • The programming and portability issues

4.1 Security

4.1.1 Overview ESRA recommendations, such as Real time constraints or connectivity mechanisms, can be extended to security aspects of a SDR-PF. Nevertheless none of the ESRA recommendations has been identified as security specific. This section complements ESRA recommendations with a set of security specific guidelines, intermediate between the ESRA recommendations and ESRA requirements levels.

4.1.2 Guidelines for the definition of security req uirements Both, WF applications and SDR-PF, need to consider operational, functional and assurance security requirements during the whole lifecycle (specification, design, implementation and maintenance). When porting a WF application into a SDR-PF, the consistency and fulfillment of the combination of each set of the security requirements needs to be verified. Security requirements may be complemented by national regulations.

4.1.3 Guidelines for security features The Waveform engineering process is in charge of identifying and describing the waveform security protocols and their associated operations. The SDR-PF is in charge of describing the security operations that can be used by the Waveform applications as well as the SDR-PF protection mechanisms. When porting a WF application into a SDR-PF, the security protocols will use the security operations provided by the SDR-PF if possible. If a security operation provided by the SDR-PF does not fulfill the needs of the protocols of the WF application then:

• the function may be implemented by the WF application • the SDR-PF may be upgraded to support such operation • the WF application can not be ported to the target SDR-PF

The WF application may take advantage of specialized security devices (e.g. cryptographic coprocessor) included in the SDR-PF if feasible.

4.1.4 Guidelines for cryptographic operations Cryptographic operations:

• will be performed according to defined standards and implemented considering existing recommendations, if available and applicable,

• may be configured with different algorithms and modes, • may support WF application security protocols, including key management if applicable, • may be used for protecting the SDR-PF,

FP7-Security EULER


• may support security domains separation, when applicable, • Their implementation may be validated or certified.

4.2 Computing device(s) Software radio, as firstly tackled by Joe MITOLA [14], consists in taking benefit of very flexible hardware architecture, typically general purpose processors (GPP), to handle various types of waveform processing chains. Software defined radio (SDR) however, relaxes this constraint by considering the use of any flexible processing unit when possible, and even sometimes ASICs, to cope with the constraints of each application context [15]. Reconfigurability [16] is a crucial point of SDR and should be privileged as much as possible. That is the reason why SDR platforms in general, and ESRA approach in particular, focus on programmable or reconfigurable processing units such as DSPs and FPGAs, but considering also ASICs when no flexible solution is available (as often for RF processing, for instance). Anyway, an heterogeneity of processing units is often required on SDR systems, which makes SDR design a particularly hard issue [17]. That is the reason why modeling needs are necessary for these processing units in the ESRA perspective, as stated in 4.5.7.1. Section 4.5.7.3 addresses the modeling of GPP and DSP devices, and section 4.5.7.4 is about FPGA components model. This chapter will try to explain the features and differences between the different kinds of processing units that will be found in an ESRA platform.

4.2.1 ASICs Dedicated circuits, called Application Specific Integrated Circuit (ASIC), are specialized circuits to perform a given processing. The algorithm is physically wired in the form of a set of logic gates. They are generally used for high speed intensive computing. For each application, a different circuit is created. The advantage of ASICs is their speed, since the logic connections are physically created and optimized in that goal. The counterpart is a very long development cycle and a high production cost and it only becomes profitable to use ASICs if the number of produced pieces is large. In general, the use of an ASIC leads to several other benefits, primarily related to reduction in system size and power consumption. Compared to a flexible solution, a dedicated solution is always better in a specific use case. Flexibility should bring other advantages in a system in order to justify its value.

4.2.2 GPPs and DSPs The principle of operation of a processor is based on sequential execution of instructions by a control unit, which implements the instruction processing to an arithmetic logic unit (ALU). The ALU then performs the requested processing on data that is read from memory. Changing the instruction sequence enables to change the processing operations. We may distinguish several architectures, depending on the parallelism degree of the processor: Complex Instruction Set Computer (CISC), Reduced Instruction Set Computer (RISC), superscalar architectures that may apply both RISC and CISC approaches, Vector architectures, Very Long Instruction Word (VLIW). But a more important differentiation is made between DSPs and GPPs. DSPs are specialized units for signal processing applications with a better ratio between the number of instructions per second and the number of consumed power in watts. A typical operation to be made in signal processing applications is a multiplication followed by an addition (called MAC: multiply accumulate) which is a combined operation usually made in one cycle in a DSP. MAC operation is typically done many times for filtering or convolution. DSPs are particularly targeting the real-time embedded market for reasons of processing speed and power consumption. This is the kind of processors used in digital camera and video camera, set top boxes, etc. DSPs have been inserted in mobile phones for a while to perform application level processing. But DSPs are now also entering the radio processing itself, as software radio progresses in designers’ habits. However, current status is not a generalized DSP use for phones baseband processing, even less at IF or RF where ASICs are still used. Baseband processing is performed by System on Chip, a middle stage between ASIC and DSP, merging in a single chip, processors and hardware accelerators.

FP7-Security EULER


GPPs are an alternative of DSPs, when power consumption is not critical, as they have been benefiting these past 10 years of Moore’s law in terms of processing power. However, the portability, as well as the benefit of using high level programming languages and design flows makes it an interesting opportunity when possible.

4.2.3 FPGAs FPGA structure allows the FPGA to emulate any circuit, provided only that the FPGA has enough logic and routing resources available. However, this flexibility in programmability comes at the expense of reduction in circuit performance. Although FPGAs are designed with the same technology as general-purpose processors running at several giga-hertz, the clock frequency of FPGAs does not exceed a few hundreds mega-hertz. Nevertheless, the architectural freedom of the FPGA makes it the most interesting target to implement fine-grain parallelism, which largely compensates the relatively low operating frequencies. FPGA is made of a matrix of cells that are independent of each other; they may well perform their calculations in parallel. The FPGA allows fine application-level optimizations by varying their parallelism. Current FPGAs integrate tens of millions of gates. Originally designed to check the application behavior for ASIC integration, the role of FPGAs has changed considerably since then. Once used only to integrate the logic glue for digital boards in the 1990’s, FPGA has been then used to emulate ASICs and check design before final implementation. But FPGA size expansion in the late 1990’s and early 2000’s has turned FPGA as real processing units, enabling the integration inside a single FPGA chip of a complete system, and a FPGA to support a System on Chip (SoC). More and more FPGA chips also integrate now hard-cores or can implement soft-cores of processors, from PowerPC to ARM cores. A specific tooling is provided by FPGA vendors in order to design softcores, such as MicroBlaze (Xilinx) or Nios (Altera) for instance. A new feature may give new perspectives to FPGA use in SDR domain [18]. It is the capability of changing a sub-part of a FPGA while letting the rest of the FPGA run. This is called partial reconfiguration (PR) or dynamic reconfiguration as reprogramming (the word reconfiguring is used in the hardware domain) a sub-part takes less time as changing it in totality. As Xilinx has been a pioneer in that market, we consider here the Xilinx technology and names [19]. Reconfiguring a FPGA or a sub-part of a FPGA consists indeed in loading a new bitstream into the configuration plane of the FPGA, through a specific interface. Xilinx provides several interfaces:

• JTAG and SelectMap ports for loading a total or partial bitstream from outside the FPGA, • ICAP interface for loading a partial bitstream from inside the FPGA itself.

SelectMap and ICAP interfaces to reach the configuration plane have the same characteristics in terms of bandwidth performance. For Xilinx Virtex 5 and 6 families, they reach a 100 MHz frequency on a 32 bits bus, enabling a 3.2 Gbps transfer rate in the configuration plane [19]. However access to PR capability has only been included in Xilinx ISE tool suite very shortly (year 2010). It was only a technology reached by a few researchers working in the SDR domain [20], previously. However, if PR is now accessible for any designer, the theoretical configuration speed of 3.2 Gbps is still not something directly obtained with current Xilinx ISE. Here again, only researchers working in this area for years may obtain such limits today [21]. This means that PR is a very promising feature permitting to combine the processing speed of hardware processing through high parallelism, with the versatility of software. This is now a feature open to industry, thanks to recent years tooling progresses, but still only prototyped at research stage.

FP7-Security EULER


4.2.4 Computing devices interfaces

4.2.4.1 Ethernet It is the most commonly used LAN (Local Area Network) standard in the world. While it initially used a coaxial cable and CSMA/CD for multiple access, very early it was replaced by the modern 4-twisted-pairs, switched full-duplex system we know today. The initial speed was 10Mbps, but in 1995 Fast Ethernet (100Mbps), in 1999 Gigabit Ethernet (1Gbps) and in 2002 10-Gigabit Ethernet (10Gbps) became commercially available. Devices identify themselves by a 48bit MAC address (Media Access Control). In most use cases the Ethernet Device will not be used directly, but instead either via Ipv4 or Ipv6, in any case through a network stack. There is a complicated design choice to be made on how a radio set shall access networking facilities. The major alternatives are:

• Consider networking as part of the application (waveform) and offer it raw access to the physical interfaces. This is what the EthernetDevice suggests,

• Use the network stack embedded in the OS and use common APIs (typically socket). If the first case is selected, it is highly recommended that APIs are defined for the network stack so as to de-correlate the various physical layers as much as possible from the network application. There are two good reasons for that: a) application vendors do not want to rebuild a network stack, it would not be cost effective; and b) network configuration is critical for the user and must be unified across waveforms. Following this, Ethernet would then be one particular case of many “network interfaces” of which the radio link itself can be one. Having a specific Ethernet API becomes irrelevant. Furthermore, the analysis of the SCA API shows that it is both over-designed for congestion control and lacking some functionality any modern OS would expect from a network interface. In particular, there doesn’t seem to be a way to retrieve your own MAC address necessary for the ARP protocol, nor something to allow Wake-On-LAN.

4.2.4.2 Serial Port The most common serial architecture for communication with external devices is the RS-232-C, defined by the EIA (Electronics Industries Association) in 1969, but since 1988 it is maintained and updated by the TIA (Telecommunications Industry Association). In the computer world it has been largely replaced by the USB bus and many modern computers do not include an RS-232-C port anymore. It is interesting to note than even though quite similar to the Ethernet device, almost everything is different. The result is more or less the same interface, showing that the published interfaces come from different stages of maturity in the building blocks.

4.2.4.3 Gps The complexity of this interface relies both in the definition of the PVT information structure and the three different modes of operation. Generally speaking, it’s a useful device that many applications will want to use, however GPS is only a particular positioning device. This interface should be generalized to accommodate different positioning devices such as Europe's Galileo, but also composite information from various physical devices (north-finder, inertia, atomic clock, etc.).

FP7-Security EULER


4.2.4.4 I/O Facilities Inside a radio set, the IO subsystem has the mission to establish bidirectional connections, termed I/O channels, between a waveform stack and a physical radio set wired line. Those wired I/Os may serve several purposes such as:

• Connecting the radio set with a human operator through a microphone and a headset, • Linking a radio set with a Local Area Network (LAN) to provide a bridge between LAN stations

and mobile equipments, • Connecting peripheral sensor devices to the radio set, • Clustering radio sets together to offer scalable and/or fault-tolerant capabilities, • Providing a means to upload/download software from/to the radio set.

In the past, waveforms stacks were plugged to dedicated serial lines using single or half-duplex protocols and each additional I/O physical channel required an additional physical slot (one-to-one relationship). Today, wired radio sets can be connected to multiplexed serial lines and/or buses (Ethernet, USB) and a single physical IO slot may virtually support an unlimited number of virtual channels (one-to-many relationship).

4.2.4.5 USB The Universal Serial Bus (USB) 1.0 standard was released in 1996 by the USB Implementers Forum (USB-IF), with USB 1.1 following in 1998. They supported a maximum transfer speed of 12Mbit/s. USB 2.0 came out in 2000, supporting a maximum transfer speed of 480Mbit/s. They both allow for hot-swapping of devices, and allow low-power devices to be supplied over the USB bus, offering 5V DC to a maximum current of 500mA. The USB standard defines various device classes, through which a peripheral identifies its capabilities to the host. All modern operating systems include support for USB host controllers.

4.3 Component portability. This section describes practices that a waveform developer should follow to ensure that an SCA waveform exhibits the maximum portability achievable within the required performance parameters of that waveform. Waveform portability is a key objective of the JTRS program and the SCA. In programmatic terms this means developing waveform application software in a form that can be ported (rehosted or transferred) to different SCA platforms at a cost considerably lower than that for new development. Ensuring maximum portability of the Euler Waveform (EWF) between the different SCA SDR platforms used in the EULER project is also a key objective. Portability is necessary if large SDR development projects are to meet key goals such as:

• Reduced cost through maximized reuse of waveform software across multiple platforms • Faster insertion of new technologies • Interoperability of radio systems between services • Reduced training requirements due to commonality of platforms

This section details guidelines that should be part of the natural development process for software and documentation necessary to enable portability success. Current best practice assumes that the waveform is not solely an executable binary, but instead is a set of source files proven to operate according to a set of performance and functional requirements in a specified environment or set of environments. In addition the waveform design and implementation documentation, including models, is considered equally important to meeting the portability objective as the software itself. The

FP7-Security EULER


documentation and models assume this degree of importance because one of the ultimate goals of a program such as JTRS is to enable a 3rd party organization to port or extend/enhance a waveform without support from the original developer. Beyond just capturing the design of the waveform, these documentation and modeling artifacts must also capture the motivations. This will allow the Waveform Integrator to understand the rationale behind certain engineering decisions and how those decisions might need reconsideration for optimizing the waveform for operation on different platforms.

4.3.1 Portability versus Optimality The two concepts of portability and optimality are both very important to the success of Software Defined Radio (SDR) programs such as JTRS, but they can often be in opposition to one another. Portability calls for the generic application possible, so that it can move from one environment to another with minimal changes. Conversely, optimality call for an application tailored to a specific platform in order to maximize efficiency and performance. Satisfying all of the requirements for the waveform requires that a developer reaches a compromise between these two concepts. A program such as JTRS targets each waveform at a subset of the specified platforms and the waveforms are developed for characteristics that are common to all of their target platforms. The waveform design must be generic enough so that those characteristics that differ among target platforms do not present an unacceptable obstacle to porting between them. During the ports, the combined waveform and platform can be optimized to the degree necessary for best performance.

4.3.2 Development Guidelines

4.3.2.1 SDR Standards Developing waveforms applications in accordance with appropriate SDR standards can help support the objective of portability. For example, the JTRS program specifies the following documents that an SCA waveform must comply with:

• JTRS ORD – The Operational Requirements Document. This describes the overall requirements that the JTRS program is expected to implement.

• SCA Specification – The Software Communications Architecture specification for the basic architecture used in all JTRS radios and waveforms.

• JTRS MHAL Standard – The JTRS Modem Hardware Abstraction Layer (MHAL) standard describing the interfaces between specialized hardware components (e.g., Digital Signal Processors (DSPs) and Field Programmable Gate Arrays (FPGAs) used in JTRS radios and waveforms.

• JTRS MHAL On Chip Bus Application Programming Interface (API) – An Extension to the MHAL interface that describes a parallel interface between specialized hardware components (e.g., Digital Signal Processors (DSPs) and Field Programmable Gate Arrays (FPGAs) used in JTRS radios and waveforms.

• JPEO JTRS Standards Standardization Plan – The JTRS program-wide plan for standardizing commonly used APIs between JTRS waveforms and radios.

• JTRS JPEO – Software Standards – JTRS Test and Evaluation Laboratory (JTEL) standards for coding, documentation and code delivery.

4.3.2.2 General Development Guidelines Waveform developers should adhere to the following general development guidelines for waveform portability:

• Logically subdivide the waveform into components that have well-defined interfaces between them. This design practice will facilitate hosting of these components on different Computational Element (CE) types (GPP, DSP, or FPGA) and will support changing the type of element hosting a given component if necessary for porting to a new platform. These are multi-processor applications and should not have components tightly coupled to one another

FP7-Security EULER


unless necessary to fulfill performance requirements. In such an instance, the developer must provide justification for any tightly coupled components.

• In general, having one component per CE (e.g., one red GPP component, one black GPP

component, one DSP component) is not an acceptable level of modularity in design unless the waveform is extraordinarily simple.

• Provide as much unit test material (test vectors, documentation, etc.) as practical, along with

high-level math models for any code related to signal processing. This is not a requirement for additional development, but for delivery of such materials already created and utilized by the developers. Where possible, test vectors should be capable of being used to exercise individual waveform components in stand-alone form as an aid in unit testing.

• Standards compliance is a necessity. These standards will include compliance to the SCA and

the JPEO API standards as verified by the JTEL test procedures.

• Design the waveform so that, whenever practical, it has no requirements for Radio Services that are not available on all identified target platforms. If such a Radio Service is necessary, the service must be delivered as part of the original waveform and must follow the portability guidelines in this document.

• If source code generating tools are used, provide the generated source for evaluation, as if

the waveform developer wrote it manually. Automatically generated code must be documented and models/artifacts provided along with the waveform source such that the Waveform Integrator (WI) can port it. The code-generating tool must also be commercially available for use by the WI 2.

• Code and documentation must agree with respect to the details of waveform design and

implementation.

• Avoid basing the waveform design on strict timing expectations that could vary between platforms. The developer should document the rationale in the Software Design Description (SDD) if unable to conform to this guideline.

• Establish performance characteristics (threshold and objective) for individual components to

aid in understanding rehosting on different CEs. Include these characteristics in the delivered documentation.

• Develop naming conventions for variables, functions, classes, and other software constructs,

and use them consistently. Provide documentation on these notations -preferably in the Software Development Plan (SDP).

• Use file naming conventions that comply with the rules set forth in the JTRS JPEO Software

Standards. Provide documentation on these notations — also preferably in the Software Development Plan

• Ensure proper memory partitioning and identify the contents of each partition. This is

necessary for documentation of the waveform structure.

• Build in as much debug capability as practical. When possible, this should be in the form of SCA logging as such code is SCA-compliant and should be designed and implemented so that

2 Note: This does not include Common Object Request BrokerArchitecture (CORBA) stubs and skeletons generated by an JDL compiler. In This context, “model” refers to a formal model than can be processed by a commercially available modeling tool such as Primtech’s Spectra CX or Zeligsoft Component Enabler (CE).

FP7-Security EULER


it can be turned on and off as needed. Log entries should include identification of the source file and line number whenever possible. In such cases where SCA logging is not practical, temporary debug code can be added. include loopback capabilities to enable individual component testing. Debug code should be designed so that it can be removed from the executable using conditional compilation.

4.3.2.3 Consideration of Intended Use of the Waveform Above all else, the waveform must fulfill the capabilities for which it was developed. Under some circumstances, doing so will require compromises in portability, but that is preferable to a waveform that cannot be hosted on those platforms most suitable for its application. The goal of portability should always be considered during development but some waveform design decisions may necessarily limit portability for reasons of performance, power limitations, etc. An example of this would be designing a waveform intended to function for an extended period on an internal battery power supply. Developers of such a waveform would need to be cognizant of the power consumption characteristics of the CEs available to them, and should allocate functionality accordingly. In this example, they might choose to allocate large parts of the waveform to a DSP. While a DSP-based design might be less portable in an absolute sense, the ability to port to the intended target platforms and fulfill the purpose of its development is improved.

4.3.2.4 Use of Third-Party Software Use of third-party software, including freeware and shareware, is a common development practice that often returns benefits in schedule, cost and functionality; however these benefits can come at a cost of reduced portability. Many third-party software packages targeted for GPPs and DSPs deliver as object libraries that are linked in when building the executable. This makes it difficult if not impossible to port the third-party components to other platforms. The main reason for this difficulty is the lack of visibility into the library implementation. Without the library source code, there is no way to verify the adherence to portability enhancing programming practices. There is also no way to verify the compliance with applicable standards such as the SCA. Finally, third-party software delivered as object code is always built for a specific processor, and usually built for a specific operating system, either of which is a significant barrier to portability. If the third-party software is available as source code, many of these objections may be put aside. Third-party code targeted at FPGAs is usually in the form of Intellectual Property (IP) cores provided by the component vendor. These will rarely work on different FPGA components and are discouraged for that reason. The same objections apply for third-party software not available as source code for the GPP and DSP components. Another form of third-party software is legacy waveform code contained within an SCA-compliant wrapper. While such code may provide the necessary functionality it is rarely optimized for the target platform(s) and can often contain barriers to portability. There will be occasions where the benefits for inclusion of third-party software outweigh the disadvantages discussed in this document. In such circumstances the waveform documentation Design Specification (WDS), Software Design Descriptions, Interface Design Descriptions (IDDs), or Waveform Porting Plans (WPPs), as appropriate must include a discussion of any portability issues related to the use of such software on the target platforms identified for this waveform.

4.3.2.5 Development Tools and Debug Code The waveform developer shall provide a fully documented build process along with the identification and configuration of the development tools in the Software Development Plan. This permits reproduction of the executable during the assessment process and porting activities.

FP7-Security EULER


In addition to all source code, the developer shall ensure that all debug code harnesses, project files, test benches, and simulations are included in the delivered software. These items are not part of the waveform source, but are valuable, and in some cases necessary, tools in the development and integrations processes.

4.3.2.6 Modeling Commercially available software modeling systems exist to develop some or all of the waveform in a Platform Independent Model (PIM) for conversion to a Platform Specific Model (PSM). The value of tools such as MatLab and SimuLink when developing and porting the signal processing software has been widely recognized, and has become commonplace. For other aspects of the development process, the use of modeling tools varies between organizations. The usual method of using such tools is to generate prototypes of the mathematical models of the signal processing algorithms and test them to ensure that the model produces the desired output under a variety of conditions. The developer then uses the model as a basis for the actual software and/or HDL. Some of the tools can generate the source code for the GPP (in C++), the DSP (in C), or the FPGA in [Very High Speed Integrated Circuit (VHSIC) Hardware Description Language (VHDL)]. Should the waveform developer use modeling tools to generate source, they should ensure that the source code conforms to the standard conventions of the appropriate language and must be compliant with the guidelines and standards outlined in this document. Other commercial domain specific modeling tools such as Spectra CX or Zeligsoft CE allow developers to model higher level waveform abstractions such as those defined by the SCA. These tools allow developers to model SCA waveform components, their interfaces and connections to other components in the form of a PIM which can be converted to a set PSM artifacts for the actual target radio platform.

4.3.2.6.1 PIM/PSM Modeling and Transformation Designing a waveform as a PIM allows the developer to create a generic model that captures the necessary waveform functionality in a manner completely independent of the actual implementation of the radio. The available tools for transformation of a PIM into a PSM should create a working model for the chosen target platform without requiring changes to the original PIM. The reality is that there are only a few such tools available, and none of them can perform the entire transformation into a fully functional waveform optimized for the platform for which it is targeted. In addition, industry has not yet widely embraced the use of these tools in this manner. Still, the creation of a generic PIM as a part of waveform design and implementation has a great deal of value, even now, as a means of expressing the functionality of the waveform in a manner that another engineering team can easily grasp. The PIM also provides an insight into the motivations of the waveform designers. If the WI has access to appropriate modeling tools, the PIM can be used to model waveform behavior, and can also be transformed into a representative PSM. The transformation process is where the waveform can be optimized for the target platform.

4.3.2.6.2 Signal Processing Code Modeling The prototyping aspect of models is helpful in providing an understanding of the signal processing operation of the waveform. This understanding is valuable to the assessment team, as well as to a WI. As stated in the previous paragraph, the PIM provides a view of the structure of the waveform, as well as an insight into the motivations of the designers. The PSM provides a functioning view of the waveform on the development platform, but to be truly valuable, it must match the implementation in a bit-exact manner, that is, they must produce exactly the same output for the same input. This allows the WI to compare the performance of the ported waveform to the original reference model, isolating any inaccuracies induced during the port. Note that the developer should deliver the models with the design documentation that includes detailed descriptions of the models and tools. This documentation shall also include the specific versions and configurations of the tools.

FP7-Security EULER


The developer should use simulation tools to perform system simulation at multiple levels. The simulations should include the test methodology, test benches, test vectors, verifiers, report generators, math models, and any other test material used. The developer should perform these tests and simulations at boundary conditions, as well as under normal operation, and should provide documentation of these simulation runs. Some general guidelines describing what the waveform developer should include in models include:

• The high-level math models of the signal processing software should agree with the delivered waveform implementation in a bit-exact manner (i.e., test vectors injected into both the delivered software and the model must yield the same output vector).

• The waveform developer should provide as much unit test material (test vectors, documentation, etc.) as practical so that the WI can execute the models and compare the output to that from the code.

• FPGA simulations should include the test methodology, test benches, test vector stimulus files, verifiers, report generators, math models, and any other test material used. If these simulations are generated using elements that are considered company IP, the developer must provide some means for the simulation to be run without these elements. This is not likely to be possible, so the use of such elements is discouraged.

4.3.2.6.3 GPP Code Modeling Modeling tools for components that are hosted on the GPP can be used for design only, or for the actual implementation. Artifacts from the design phase, such as Unified Modeling Language (UML) class diagrams, are usually included in the design documents. Tool vendors have developed modeling tools that can take models created graphically and generate complex applications in third-generation languages such as C++. Such tools enable platform-independent development at a high level and can sometimes generate the platform specific implementation. The model produced is useful both as a design artifact and potentially as a method of delivery for the waveform. Such a policy change is unlikely to occur until there have been more advances in modeling tools and more widespread acceptance of them by the industry. When machine-generated source code is included in a waveform delivery, it must conform to the same portability guidelines expressed in this document as manually developed code.

4.3.2.7 Waveform Architecture One of the most important aspects of the overall waveform design success is its architecture - that is, how the individual components of the waveform are designed to implement certain functions required for the waveform, how these components are allocated to the target platform hardware, and how data and control move between the components. Note the use of the phrase "target platform hardware." This is an instance where environmental conditions may outweigh abstract portability standards. In such instances, the desire for timely porting of a waveform between two similar platforms may make compromises in abstract portability acceptable. This section is intended to be a high-level discussion of architectural concepts and considerations rather than a complete and exhaustive treatise on these topics. The grouping of functionality and the allocation of these grouped functions across platform computational elements is closely related to the concept of software modularity. It is safe to say that most programmers believe that they fully understand the concept of modularity and how to apply it; however, the degree to which any given waveform can be subdivided into separate components has proven to be open to interpretation. C/C++ programmers and VHDL developers sometimes use these terms in different manners, resulting in confusion between them. For this discussion, on the GPP, the term "component" is synonymous with an SCA Resource, and the term "module" applies to an individual C++ class. On a DSP, "component" will be used to describe major functional blocks, while "module" will refer to closely associated functions usually contained in one source file. Typically, a component, as defined here, will operate as an individual process on the GPP and DSP. On the FPGA,

FP7-Security EULER


"component" better describes the individual building blocks contained within the top-level "entities". These components are akin to C++ classes. Consider the following four major software characteristics when allocating functionality to waveform components.

• Cohesion — A measure of how strongly related and focused are the responsibilities of a single component.

• Coupling — The degree to which each program component relies on each one of the other components.

• Control flow complexity — A measure of how many conditional clauses exist in a software component.

• Data/Control interfaces — The interconnections between components. It is difficult to establish a set of "one size fits all" rules for waveform architecture, as each waveform's requirements will differ; however, some general guidelines can be proposed.

• Combine modules whose purposes are closely associated into components. Many modules may exist within a component.

• Place modules into separate components if there is likelihood that they will need to be hosted on different CEs on one or more of the target platforms identified for this waveform.

• The determination regarding component boundaries and component allocation to a platform CE should include consideration of: • Waveform instantiation time • Latency • Platform CE performance capabilities across all targeted platforms • Platform CE interconnection characteristics across all targeted platforms. This includes

consideration of the performance capabilities of the hardware implementing these interconnections, as well as the software used to support them.

• Avoid designing unnecessary or excessive SCA port connections, as these will increase waveform startup time and consume excess memory. Try refactoring software components to balance portability with performance.

• Do not use SCA Ports for interconnections between modules within a GPP component. • C++ modules (classes) should follow rules of cohesion, encapsulation, coupling, etc., such as in

the C++ Programming Language. • Design interrupt handlers to complete execution as quickly as possible. Use interrupt handlers to

schedule work in threads rather than doing all of the work in the handler itself. Note that interrupt handlers are platform-specific and generally should not be a part of the waveform - especially in the GPP code. There is a great possibility that such code may be needed in the DSP code, but the necessary tight coupling to the platform means that it should only be a last resort.

• Communication between components shall be compliant with the JTRS APIs. Additionally, use the interface as it was intended, e.g., do not use configure() when query() would be more appropriate.

• Wrapping a non portable legacy waveform in a thin, SCA-compatible layer does not produce a waveform that is any more portable than the original. Avoid this practice.

• Avoid custom SCA::Devices. Such devices are not required to be SCA compliant with the SCA Application Environment Profile (AEP). The waveform should not use those SCA::Devices provided by the platform unless absolutely necessary. If a waveform developer feels that the development of a custom SCA::Device is necessary, they shall provide documentation that supports their position.

• Avoid developing components with high cyclomatic complexity scores and complex test paths. Doing so supports maintainability and understandability, and thus enhances portability. Code with high cyclomatic complexity is only acceptable if no substitute design can be found.

FP7-Security EULER


4.3.2.8 Inline Documentation Properly written software includes inline comments that provide the readers with additional information useful to gaining an understanding of the source code at which they are looking. This documentation is commonly referred to as source code comments. Some basic guidelines regarding source code comments include: • Source code comments shall be technically correct and current to the latest implementation of the

code. • Inline comments shall agree with the design and implementation described in the waveform

design documentation. • Both quantity and quality of inline comments are important to the understanding of the code.

Adequate quantity is relatively easy to characterize. • Each source file shall have a comment header that, along with configuration management

information, includes a description of the function of the source code within the file. This description shall include the purpose of the source module, inputs and outputs, preconditions, postconditions, and any special notes particular to this source module. An example of such a note is an indication that the files contain platform-specific software that is likely to require changes during porting.

• Each function within a source file shall have a comment header that describes any input variables, output variables, the function algorithm, etc.

• Any areas within a source file that the developer thinks may have portability implications should be clearly marked. A simple way to make these areas easily located is to add a specific tag in a header. This allows for keyword searches.

• Developers should include particularly detailed comments in any areas where algorithm implementations may be obtuse or difficult to understand.

• Logical blocks, such as if—else statements, for statements, switch statements, etc., should have a comment block above them that describes their purpose and how data and control flow processing takes place within them.

• It is more difficult to characterize comment quality, but a few common sense rules are: • Comments should provide information describing the function and structure of the code in

which it is located in a manner that is clear and readable. • Comments should be concise and should avoid requiring the reader routinely to refer to other

documents. • Comments must be maintained so that they are in agreement with the code. All of these

guidelines apply to all CE types, including DSPs, FPGAs, and GPPs.

4.3.2.9 C/C++ Programming Practices This section describes those recommended C and C++ programming practices that enhance application portability (Table 5) and those practices that are detrimental to portability (Table 6). Below are several standards that a waveform developer should follow.

• For C++, use the international standard ISO/IEC 14882, published by the American National Standards Institute (ANSI) as ISO/IEC 14882:2003(E).

• For C, use the standard published by ANSI as ISO/IEC 9899:1999, second edition 1999-12-01. • When using an Object Request Broker (ORB), C++ source code shall adhere to the C++

binding standard for CORBA 2.3 [22]. This applies to any processor type on which C-I-I- is used.

• When using an ORB, C source code shall adhere to the C binding standard for CORBA 2.3 [23]. This applies to any processor type on which C is used.

• The use of the Standard Template Library (STL) and C++ Standard libraries, where appropriate, is preferred over the use of proprietary libraries.

Bias in the following tables is toward the most portable programming practices. Some of the guidelines contained below maybe less applicable as language standards evolve. The tables will evolve as necessary.

Table 5: Portable C/C++ Language Features

FP7-Security EULER


Recommended Programming Practice

Notes

Use of abstractions Protects against changes propagating through code due to platform interface differences. Use of service and device abstractions hides platform interface details

Safe serialization and de-serialization (applies when SCA persistence mechanisms cannot be used)

Ensures that data is completely persisted and restored in a thread- safe manner, and that factors such as system and object state are taken into account

Segregate platform-dependent files from platform-independent files

Avoids confusion and allows for separation of build processes

Use careful naming procedures such as the use of prefixes

Helps assure uniqueness

Encapsulate message construction and parsing. Abstract the mechanics of data transportation and the characteristics of each participant of a data path

This will insulate the application software from the transport layers and from changes to the makeup of transport connection points

main () must be in a C++ file Prevents problems caused by the use of different startup sequences by the two languages. In addition to the C startup sequence, C++ calls the constructors for static objects.

Use the "common denominator" between members of C/C++ compiler families

Some development systems differ in how they handle some types between the C and C++ compilers

Put a new line at end of file Not having this breaks some compilers (and even some editors)

Always declare and define a default constructor

Some compilers simply will not work with classes that do not have these. To avoid inadvertent instantiation, declare the constructor as private

Declare local aggregates (such as arrays) uninitialized, and then initialize in code

The only way to avoid loader errors in some compilers is to define such aggregates as static; however, doing so is not thread-safe. Initializing in code after the declaration is safe under all circumstances

Use virtual declaration on all subclass virtual member functions

Include virtual declarations in subclasses as well as the parents. This

avoids warnings in some compilers and provides better documentation

Always declare a copy constructor and assignment operator

Avoids automatic generation of copy constructors by compiler; auto-

generated ones are usually not optimal

Type scalar constants to avoid unexpected ambiguities

Avoids ambiguous function calls in overloaded functions

Use the .cpp filename extension Supported by all C++ compilers, while .cc is not

Avoid implicit object construction.

Declare constructors with a single

argument as explicit

Constructors that take a single argument are also known as "implicit

type conversion operators." They can be used to implicitly convert

one data type to another ("implicitly' means "without the developer”)

explicitly coding it'). Declaring the constructor as explicit prevents Use compiler control flags that enforce ANSI C/C++ practices

Encourages compliance with ANSI standards

FP7-Security EULER


Use extern "C" to prototype C functions that will be called from C++

Improves readability and avoids compiler problems

Implementing the practices outlined in Table 5 will improve the chances of a waveform being truly portable, but that improvement can be negated by other programming practices that inhibit portability. Table 6 below lists commonly used programming practices that are known to inhibit portability.

Table 6: Non-Portable C/C++ Language Features

Discouraged Programming Practice Notes

Use of pragmas Typically used to select language extensions or alignment changes; interpretation varies between compilers. As such, these are often platform-specific. if pragmas must be used, they must be thoroughly documented in the SDD

Use of bit fields Appear as structures with colons and may cause problems due to differences in endian-ness. As such, these are often platform-specific. If bit fields must be used, they must be thoroughly documented in the SDD

Use of unions Alignment dependent. Also could cause problems with endianness. As such, these are often platform-specific. If unions must be used, they must be thoroughly documented in the SDD

Use of native types Often compiler-specific; the identifier int is 16-bit or 32 bit, depending on compiler. Should always use typedef INT_32 or INT 16, etc.

Floating point equality or in-equality Floating point should always be compared to some epsilon. Variances between compilers may cause floating point math to produce very small residual values. Comparing such values to constants, such as 0, can produce unforeseen results. Example: Instead of if (f == o) , a programmer should say if (abs (f) < epsilon) where epsilon is defined as a very small number

Pointer greater than or less than Memory location-specific; the only pointer comparisons allowed are equality or in-equality

Use of Object Request Broker(ORB)-

specific calls

Different CORBA ORBs often have differing calls for functions, such as initialization and exception handling; these can be masked by the use of macros

Use of "friend" mechanism in C++ This creates an instance of "overt coupling" wherein one class has access to the internal implementation of another, thereby, creating a dependency

Public data members in C++ classes This can create an instance of "surreptitious coupling" wherein one class has access to the internal implementation of another, thereby creating a dependency. All data members should be accessible from outside the class only through "set" and "get" methods

FP7-Security EULER


Defining macros with trailing punctuation such as "," or';"

Macros should generally behave as a constant, a program statement, or a function. Macros that behave as program statements or functions should tolerate the addition of a semicolon at the end at the time of use. Many compilers will not tolerate two semicolons

C++ templates other than those defined in the STL

Not universally supported; implemented differently amongst compilers; results in code bloat. Templates often cannot be completely avoided, but programmers should be careful when using them and must thoroughly document their use

Embedded assembly language Search for the keyword "asm"; allowed by the SCA, but still a portability risk; absolutely machine-specific and should be avoided In the GPP. Any use on the DSP should be thoroughly documented

Use of nested C-style comments Not interpreted the same by all compilers

Nesting of namespaces beyond depth of two

Namespaces increase the size of linker symbols, whose length may be restricted on some platforms

Unnecessary top-level semicolons, i.e.,

do not put unnecessary semicolons in

global scope

Some compilers will not accept unnecessary semicolons

Mixing of varargs and inlines Not consistently implemented by all compilers

Use of nested classes Implemented differently by some compilers depending on whether they follow the 1998 C++ standard or the 2003 C++ standard

Declaration of iterator variables inside for () statements

Prevents code compilation when using tools that lack support for "for-scoping"

Use of complex inline constructs Unpredictable behavior from compiler to compiler; keep inlines short

Use of the mutable keyword Leads to code that is difficult to debug

Definition of constants using simple names such as ERROR, FOREVER, and

TRY that are the same as language key

words

Such names may conflict with definitions in libraries used by the

development system; such definitions should include something to identify the context in which they apply

Use of vendor-specific preprocessor directives

Not portable to other development environments

Absolute pathnames for included header files

Not likely to be portable to other development systems without change

Allocation of automatic variables whose

size cannot be determined at compile time

Some compilers will allow automatic variables (e.g., buffers) to be allocated with a size based on the value of some other variable. This is not ANSI compliant and is not accepted by many compilers. Besides being non-portable, this is simply bad programming practice

using directives and using declarations in header files

Including a using directive in a header file will cause problems for anyone including the file. It can cause namespace collisions when included by other developers

Use of vendor-supplied macros Macros supplied by compiler, ORB, and CF vendors are not likely to

be portable

Use of C-style type casts in C++ Use of C++ static casts is preferred due to type safety and readability

FP7-Security EULER


Use of native C++ exception handling Not portable to platforms that do not support native exceptions. Can adversely impact performance and increase code size

FP7-Security EULER


4.3.3 GPP Guidelines

4.3.3.1 GPP Performance The waveform developer shall verify the extent of processor utilization in terms of Millions of Instructions per Second (MIPS) and memory requirements - both under peak processing load. The waveform shall be capable of execution on all target platforms with a specific minimum margin in terms of processing resource consumption on the least of these platforms. MIPS allocations must include the GPP used determine processor utilization and the associated clock rate being used on the processor. The developer shall provide documentation for the capacity numbers, including their derivation, in the SDD.

4.3.3.2 POSIX Compliance Waveform use of GPP Operating System (OS) services is constrained to the use of Portable Operating System Interface (POSIX) functions identified in the Application Environment Profile (AEP) defined in the SCA Specification. The SCA standard prohibits the use of any other OS functions, as the use constitutes a serious threat to portability.

4.3.3.3 Use of SCA Standard APIs GPP interfaces between the waveform and the devices and services provided by the target platform shall be through APIs standardized in the SCA where possible. Use of these APIs enhances the portability by ensuring that the waveforms and platforms speak the same language for these services.

4.3.3.4 Device Interface Abstractions One of the characteristics of the SCA is its reliance on abstractions of radio-specific devices to insulate the waveform-specific code from platform details. This is particularly common between waveform components hosted on the GPPs and hardware devices on the radio. The usual boundaries between waveform and platform software locate the abstraction for the device on the GPP and present interfaces for interaction with the waveform. The abstraction, implemented as an SCA Device, sits above a device- and platform-specific driver. The interface will hide details of the communication path between the waveform and the hardware Refer to Figure 1 an example of portable design. At the bottom of the figure are low-level devices connected to the GPP through either the FPGA or DSP. Below the waveform component is an SCA Device abstraction that implements the API for the device. This abstraction communicates to the device via the MHAL (or MOCB) layers on the GPP and the FPGA or DSP, as shown. Note that in no case does the waveform application ever interface with the low-level drivers. All communications occur through abstraction layers. As a result, waveform software communicating with the low-level device is insulated from changes to that device. The device interface software can be ported either to DSPs from another vendor, or hosted on a different device such as an FPGA.

FP7-Security EULER


Figure 1: Example of Platform Abstraction

Figure 1 is a generic figure and does not represent the only possible configuration. Some configurations may include waveform components within the DSP and/or the FPGA The arrangement shown in Figure 1 is based on the Device model specified in the current version of the SCA (2.2.2). The logical model for this is shown below in Figure 2.

Figure 2: SCA 2.2.2 Device Model

MHAL provides a low level standard API by which waveform components can interface with each other and with the underlying transport mechanisms provided by the platform. However, as is illustrated in Figure 1 in order to communicate with a processing element hosting a HAL component, a CORBA

FP7-Security EULER


MHAL Device proxy component is hosted on a GPP with the port on CORBA proxy component connected to the HAL endpoint on the specialized hardware (DSP or FPGA). Although this approach provides a degree of portability, currently the format and content of control and data messages sent to the HAL components are not standardized and must be written by the waveform developer. This approach has two obvious limitations, first the MHAL approach still requires a waveform developer to write custom marshalling and message handling code and therefore introduces portability issues and secondly the use of proxy CORBA objects hosted on the GPP introduces additional latencies in to the communication chain. This picture changes when the platform uses an ORB on the DSP and/or FPGA. This change allows the abstraction to move closer to the actual device and removes the need for the use of MHAL APIs. One of the goals of the Euler project is to develop and deploy a full CORBA infrastructure that can be hosted on not only the GPP but also on the DSP and in hardware on the FPGA processing elements of a radio. Figure 3 below show the proposed CORBA Everywhere Device Model that in being prototyped as part of the ESRA Basestation platform implementation.

Figure 3: CORBA Everywhere Model

The CORBA Everywhere approach has a number of potential benefits, for a start a unified and fully standardized communication infrastructure can be used throughout the signal processing chain. This has a significant potential impact on improving overall waveform portability, it also minimizes the call latencies in the system by removing the requirement to use component proxies hosted on the GPP. These statements can lead to the establishment of a requirement, already proposed as a recommendation or guideline by WINTSEC ESRA.

EULER_REQ 1: Waveform Application Resources interfaces shall be defined in IDL

4.3.4 DSP Guidelines This section lists some guidelines for DSP development. • Verify the extent of processor utilization in terms of MIPS and memory requirements at peak

processing load. The waveform shall be capable of execution on all platforms for which this waveform is targeted with a specific minimum margin in terms of processing resource consumption on the least of these platforms. MIPS allocations must include the DSP used to

FP7-Security EULER


determine processor utilization, the associated clock rate being used on the processor, any internal clock multipliers, or the core clock rate used. Provide documentation for these numbers, including their derivation, in the SDD. Note that there may be platform hardware requirements for DSP performance and memory margins that override this guideline. The developer should research the target platforms identified for this waveform and identify any such issues.

• If CORBA connectivity does not exist in the DSP, ensure that all interfaces to other CEs and remote devices comply with either the SCA MHAL or MOCB standards.

• Limit use of processor specific OS functions. If use of such functions is mandatory, abstract them through local functions. Limit use to basic functions that other DSP operating systems are likely to support. The developer should research the target platforms identified for this waveform and document any portability issues related to differences in DSP OSs.

• Avoid assembly language unless it is necessary to meet performance requirements. The waveform developer shall provide justification for the use of assembly language. The developer should fully document the purpose and execution of any embedded assembly language and include a version of the algorithm written in a portable, high-level language.

• The waveform developer shall put in place a set of DSP coding standards requiring that they abide by all language rules, provide a common look and feel to the code across all modules, and be readable and maintainable.

• Exercise caution in the use of mathematical operations where the C++ standard and the C standard are ambiguous and permit the developer to be "implementation-specific", such as in the case with the modulo/remainder operation on negative numbers in the C++ standard. The developer shall implement the code in a way that does not rely on the operation of a specific compiler in these cases.

• Exercise caution when using chip support libraries or other similar processor-specific APIs or functions within waveform DSP code. Whenever possible, avoid functions that are not likely to be commonly available across multiple component's support libraries. The waveform developer shall fully document the purpose and execution of any processor-specific (i.e., chip support) APIs or functions.

4.3.5 FPGA Guidelines This section lists some guidelines for FPGA development Note: VHDL written for the waveform and required for its operation is normally considered to be software, and to be a deliverable along with the GPP and DSP source. • Source code shall conform to active VHDL standards, 1076 and 1164, set forth by the Institute of

Electrical and Electronics Engineers (IEEE). • If CORBA connectivity does not exist ensure that all interfaces to other processors and remote

devices comply with either the SCA MHAL or MOCB standards. • When an IP core is used, documentation describing all input parameters used to generate the IP

core shall be provided. In general, the more generic IP cores (e.g., simple adders, multipliers) are more acceptable as the WI can reasonably expect them to be available on devices other than the original target. If the IP core in question is known to be available on components from other FPGA manufacturers, its use is acceptable.

• The VHDL system architecture should use modular components that provide a logical scope of functionality. Each entity should have a clear and defined role in providing functionality to the system.

• Verify the extent of FPGA resource utilization at peak processing load. Ensure that there is sufficient margin (at least 25%) remaining. Provide documentation for these numbers, including their derivation. Note that there may be platform hardware requirements for FPGA performance and memory margins that override this specific guideline.

• Abstract or eliminate the use of off-chip resources. Off-chip resources include anything from memory, Analog to Digital Converter (ADC), or even a serial interface to a DSP or GPP. The idea is to create a component driver for each off-chip resource to abstract the component from the waveform or core FPGA processing using MHAL or MOCB. This approach allows porting of the code to a new platform, changing only the individual components, and leaving the core unmodified. Still, it is best to eliminate the need for such off chip resources, if practical, such as

FP7-Security EULER


those resources that may not exist on other platforms. If system performance requirements cannot be satisfied without tightly coupling the waveform FPGA code to the platform, the developer must provide the rationale for this, and must thoroughly document the structure and functionality of the interface to the off-chip resource.

• Use of vendor specific primitives should be avoided unless absolutely necessary. If such primitives must be used, the developer must document them thoroughly and provide rationale for their use.

• Retain simulation portability by avoiding the use of simulation tool-specific simulation control language or APIs.

• Minimize the number of clock domains to reduce/eliminate hardware dependence on multiple clocks; this practice will reduce design size, complexity, and resources and lower power consumption. Documentation of the clock domains must be included in either the SDD, or a separate firmware design document.

• Use generics as component parameters to help eliminate platform-specific buried constants and optimize code.

• Use `type' objects to enhance the ability to use generics and simplify code. • The waveform developer shall put in place a set of VHDL coding standards requiring that they

abide by all VHDL language rules, provide a common look and feel to the code across all modules, be readable and maintainable, and avoid obsolete VHDL constructs.

Any software hosted on embedded GPP or DSP cores shall be implemented following the guidelines described previously.

4.3.6 Domain Profile Guidelines The Domain Profile is a collection of eXtensible Modeling Language (XML) files that the radio uses as a list of instructions of how to load, configure, and start up the waveform. The list below contains some guidelines for Domain Profile development. • Adhere to Appendix D of the SCA for format and content of the Domain Profile XML. • There are commercially available Domain Profile editing tools oriented toward the SDR industry.

Using one of these tools will aid in the development of error-free XML. • Use care when assigning Universally Unique Identifiers (UUIDs) as the assignment process can be

error prone. Use either a script to keep track of the UUIDs and then run it to input the correct UUID into each field, or alternatively use a graphical Domain Profile editing tool.

• Validate XML files in accordance with SCA Document Type Definition (DTD) files. • Define all waveform configurations and properties inside the XML Properties Files (PRF). • Define memory requirements for each component in the Software Package Descriptor (SPD)

file(s). • Provide a properly formatted and written Software Component Descriptor (SCD) file(s). Even

though the SCD is not required by all SCA Core Frameworks (CF), it is still good documentation for understanding the waveform.

4.3.7 Documentation Guidelines Waveform documentation serves three important functions related to enhancing waveform portability. First, it provides all parties with a clear understanding of the expectations from each respective party. Second, it provides anyone involved in porting or assessing the waveform a clear understanding of how the waveform is structured and how it functions. Third, it identifies and discusses issues related to porting to a specific target platform. The Waveform Design Specification (WDS), and the Software Requirements Specification (SRS) embody the first function. The WDS, SRS, SDD, and Interface Design Descriptions (IDDs) embody the second function. The WPP and Waveform Porting Report (WPR) embody the third, along with contributions from the design documents.

Several of the documents discussed in this section benefit from the inclusion of UML diagrams. State diagrams, sequence diagrams, and timing diagrams (added in UML 2) are particularly good at conveying information regarding program flow and module interactions. Class diagrams, component diagrams, and object (also known as instance) diagrams are useful in describing

FP7-Security EULER


program structure. All of these are more useful in the WDS, SDD, and IDD documents as these are the ones that provide the most information on the waveform design and implementation.

Documentation deliverables include everything necessary to recreate the design and its motivation without the need to consult the waveform designer. The specific documents detailed below represent the current best practice as the minimum required.

4.3.7.1 Waveform Design Specification The WDS is a top-level design document describing how waveform functional, operational, and performance requirements translate into hardware and software specifications. The document specifies requirements for the integrated system of waveform and platform—such as tuning range and accuracy, receiver sensitivity, dynamic range, timing requirements, Communications Security (COMSEC) modes, Transmission Security (TRANSEC) latency, and Over-the-Air (OTA) protocols—to hardware and software sub-systems. Perform this allocation and underlying analysis for all intended target platforms. Clearly identify constraints and restrictions that reduce the set of operational requirements achievable in any intended environment. In most waveform acquisitions, the WDS is the primary document from which requirements are derived for inclusion in the SRS. Some acquisitions reverse the process and generate the WDS from the SRS. In either case, the WDS provides the context necessary for a WI to understand the rationale for the requirements. The WDS does not capture design details. In some instances, it maybe necessary to assign some waveform functionality to hardware rather than software in order to meet system requirements. The waveform developer should explicitly identify and explain instances where a system requirement cannot be satisfied without an adverse impact on portability. The WDS shall comply with the following guidelines: • List any requirements placed on the target platform(s) by the waveform. • Describe the functionality of the overall system, such that a reader not familiar with this particular

waveform can understand it clearly. • Clearly define all protocols and data translations in a manner that focuses on the necessary

functionality and is not implementation-specific. Include all timing requirements, packet formats, etc., that are specific to the protocol, but not to the waveform's implementation of it.

• Clearly identify constraints that impede test coverage. • Clearly separate the waveform components from the platform components required by the

waveform. • Identify the types (GPP, DSP, and FPGA) of CEs required by the waveform and what waveform

functions will be hosted on what CEs. • Describe the technologies the developer intends to use for waveform component developments;

including programming languages, code generators, modeling tools. • Identify and discuss those properties of the waveform and/or platform constraints that are likely

to impede portable design. • Identify all of the programmatic requirements applicable to the waveform, such as compliance

with the SCA and adherence to these portability guidelines.

4.3.7.2 Software Requirements Specification The SRS lists the requirements that are usually derived from the WDS. The SRS for a portable waveform should state waveform requirements for all intended environments. The SRS shall comply with the following guidelines:

• Require that the waveform components must be able to fit within the device capacity, such as memory and gates, of the hosting CEs for all of the intended target platforms.

• Indicate applicability across all intended target platforms for each requirement. • Clearly separate software requirements allocated to the waveform from those that the

waveform software requires of the platform. • List the timing requirements for each waveform component. • Provide the requirements traceability and analysis used in requirements flowdown.

FP7-Security EULER


4.3.7.3 Software Design Description The SDD describes the design of a Computer Software Configuration Item (CSCI). It describes the CSCI wide design decisions, the CSCI architectural design, and the detailed design needed to implement the software. In a typical development, design documentation is available long before software source code. Many software development process manuals indicate that the majority of the life cycle leading up to test and delivery is dedicated to the design phase. For portable software, it is essential that attributes of the design that give rise to portability are manifest throughout the design documentation. Elements of the SDD are a description of the CSCI-wide design decisions and architectural design, and a decomposition of the software design. It should also include a description of SCA interfaces, APIs, communication protocols and Devices, and a description of how the design supports all intended target platforms. The SDD shall comply with the following guidelines: • Provide an overall view of the structure of the waveform, including visibility into the DSP and

FPGA components. This must include illustration of the allocation of waveform resources and components to CEs, and the connections between them.

• Discussion of approaches considered and rationale for decisions made. • Include a complete end-to-end description of user data and control flow through the system,

including details on the translations that occur along the way. The information highlighted in bold italics is particularly important.

• Identify the distinct adaptation components that allow the waveform to overcome different hardware device interfaces among target platforms.

• Contain the descriptions of the MHAL or MOCB abstractions used for all non-GPP computational nodes not already provided by the target platform as radio services or radio devices, e.g., FPGA, DSP, Antenna(s), Low Noise Amplifier (LNA), Automatic Gain Control (AGC), ADC, serial and audio ports, Digital to Analog Converter (DAC). Refer to the MHAL Standard or the MOCB Standard for details regarding the use of these interfaces for such devices.

• Clearly differentiate between waveform components (Resources) and platform components (Devices).

• Identify all expected "uses" and "provides" port connections between waveform components and between waveform components and the platform.

• Identify any non-CORBA connections between waveform components and the platform that do not comply with either the MHAL or MOCB standard. If any such connections exist, the SDD should provide a rationale for them.

• Describe, in detail, any non-CORBA and non-MHAL/MOCB interfaces. Include protocol definitions. • Provide justification for implementation of waveform components in an FPGA that could be

implemented in the DSP or GPP. Generally, a GPP or DSP implementation of a component is more portable than an FPGA representation of the same component.

• Clearly describe hardware dependencies, including memory usage, MIPS requirements, latency limits for any platform-related APIs or signaling, specialized interprocessor interfacing, specialized system clocking mechanisms. Describe the rationale behind these dependencies.

• Point out areas that are likely to have portability implications and discuss those implications. • Define all configuration parameters, their ranges, and their default values. • Contain DSP and FPGA design documentation that includes the following:

• Description of the data and control signal flow paths, including sampling rates at all internal and external interfaces, number of samples used to represent the signal and numerical representation of the signal at all internal and external interfaces, associated buffer/memory usage, and any control interfaces to the signal path

• High level architecture design diagram • Detailed diagrams and descriptions of individual components, including a description of the

clock frequencies used. If multiple frequencies are used, the documentation must include a description of the clock boundaries

• Detailed descriptions of all state machines • Detailed descriptions of adaptive types of algorithms and analysis behind adaptive loop

parameters used and decisions reached • Schematics of VHDL designs

FP7-Security EULER


• Detailed descriptions of the method of synchronization, including, but not limited to, frame -level synchronization, slot-level synchronization, bit level synchronization, and interprocessor synchronization

• Indication of where component vendor-specific code was used and why. This includes descriptions of the functionality of such code, as well as the method(s) and parameter(s) for its generation

• Detailed register definitions • Detailed description of timing considerations and use of interrupts • Detailed description of the timing of any other critical events • Interface timing diagrams • Static timing analysis • File hierarchy and/or diagram indicating boundary between waveform and platform

components; files containing platform functionality should be distinct from those with waveform functionality

• Design hierarchy showing section number in WDS that each item implements • Wrapper/Interface descriptions

4.3.7.4 Interface Design Descriptions The waveform developer should identify all devices, services, interfaces, libraries, and macros considered external to the waveform (i.e., provided by the platform) and should describe, in detail, the interactions between these external entities and the waveform. The waveform developer will create one or more IDDs to provide these descriptions. Waveform-specific SCA Device abstractions that are instantiated with the waveform are considered to be part of the waveform and to present significant portability issues. Despite the portability risk, some waveform developers have chosen to include them. This practice is discouraged. The waveform developer should adhere to the following API guidelines: • Use SCA standard APIs for waveform/platform interfaces where possible. • Non-CORBA waveform interfaces should conform to the MHAL and/or MOCB standards • In accordance with the SRS, verify for each porting target that all waveform operations required

by each waveform SCA uses port can be satisfied by the available operations on the platform services SCA provides ports. All waveform required uses operations should have a corresponding platform or external device SCA provides API.

• For GPP waveform components, every interaction with the DSP/FPGA should use either the MHALDevice or MOCBDevice interface. The API documents must address the impact of whichever of these interfaces is used on latency of command and user data.

• The IDD should include the IDL for all CORBA interfaces. • The IDD should include the sequence of commands necessary for the entities on both sides of an

interface to reach their operational state. This will aid in independent testing of waveform components.

4.3.7.5 Software Version Description The Software Version Description (SVD) serves the dual purpose of a shipping list and set of build instructions for a specific waveform software delivery and should comply with the following guidelines: • Contain a complete inventory of the files used to build the waveform. This includes all GPP, DSP,

and FPGA source. It also includes all IDL files, as well as any other files used in the build process. This inventory must also include the size of each file and their version numbers.

• List all XML files necessary to deploy the waveform. • Indicate which Software Assembly Descriptor (SAD) file is used for waveform instantiation. • Completely describe the target environment on which the release of the waveform being assessed

is intended to function. • List all documents relevant to this version of the software. This must include version and release

dates for each.

FP7-Security EULER


• Include a detailed description of the build environment, including version numbers for each tool used.

• Provide instructions for building the waveform application that are complete and correct. • Contain a list of problems or limitations that apply to this software release. • List any and all dependencies on the OE so that WI will know what OE components (ORB stubs

and skeletons, header files, etc.) are required to build the waveform.

4.3.7.6 Waveform Porting Plan The WPP contains information that describes the steps that a WI must take in order to rehost the waveform on a platform other than that on which it was developed. The WPP shall include a comparison between the original development platform and the target for which they write the document. This comparison will identify issues that could impede the port, allowing for their mitigation, if possible. The WPP shall comply with the following guidelines: • Describe a waveform structure matching the one described in the WDS, SDD, and IDD. • Include sizing and timing analysis for both the original and target platforms for the waveform

components hosted on the GPP(s), DSP(s), and FPGA(s). • Include gap analysis for those cases where the original and target platforms have different

hardware. • Specify what changes are required for each waveform or platform component. • Address any issues where the target platform may not have sufficient resources to support the

waveform. If such issues exist, the WPP should provide a mitigation strategy. • Identify the requirements that the Post Port Verification Test (PPVT) will verify. • Describe how the PPVT will be performed. • Identify the resources required to port the waveform; include personnel, laboratory facilities,

equipment, and tools both Commercial-off-the-Shelf (COTS) and vendor-developed. • Identify any licensing issues regarding waveform components or those platform components that

may be present in the development platform but not in the target platform, and that are required by the waveform.

• Provide a detailed schedule of the port.

4.3.7.7 Waveform Porting Report The WPR describes how the waveform port proceeded, including discussion of any unforeseen issues that may have come up, how close the WPP was to the actual port, and the results of the PPVT. The WI should include in the WPR metrics that describe the number of lines of code that they reused, changed, and added during the port. This information will quantify the amount of rework required on the waveform. The WPR shall comply with the following guidelines: • Describe, in detail, any required changes not identified in the WPP. • Describe, in detail, any changes identified in the WPP that were not required. • Describe the functionality of any new waveform or platform components developed as a part of

the port. • Describe, in detail, any structural changes required as a part of the port. • List the results of the PPVT, providing explanation for those tests that failed. • Provide details of the actual schedule of the port, describing any variances from the schedule

included in the WPP. • List any unplanned resources required for the port. List tools and/or methods used to generate the metric included in the WPR. This should preclude any confusion due to differences in measurement methods.

4.4 WF interfaces guidelines. The waveform interface guidelines presented here are largely influenced by the adoption of component-model standards for developing the EULER HDR (WiMAX-like) waveform and platform infrastructure; namely the SCA and a lightweight variant of the CCM, and supporting CORBA middleware, and the adoption of modeling tools for the design/definition, development, component

FP7-Security EULER


integration and deployment of the waveform assembly components for/on the selected EULER radio hardware platforms. The text elaborates Case Studies in each topic relating to developments in EULER that impact the recommendations set out in the ESRA Framework core description document 1.

4.4.1 Introduction Generally, the reuse of software units within the scope of an organization or collaborating parties is an engineering practice known to increases cost-effectiveness in development and consequently improves time-to-market for resulting products. However, in order to exploit such advantages, an appropriate level of granularity as necessary for the decomposition of application code into re-usable functional units needs to be identified. In the case of conventional Object Oriented (OO) programming, difficulties can arise due to the assumption that different entities in a software system have interfaces that are amenable to inheritance and aggregation, and are written in the same programming language. Moreover, developing systems by composition based purely on an OO programming model, involves the inherent complexities associated with connecting large numbers of relatively homogeneous units using detailed coding conventions and styles, which can be error prone and expensive. Such complexities can also attract an expensive overhead when domain experts; who ideally would only be exposed to developing business logic, are required to understand the mechanics associated with assembling complex systems. In the case of SDR, most middleware functionality supporting waveform applications has been developed to provide common API layers to abstract the underlying utility of hardware in an attempt to standardise interfaces to functional units comprising waveform implementations. However, this presents particular difficulties when designing an API to expose common semantics across the diverse architectures typical of RT/E environments used in SDR. Consequently, a component-model based approach to software development is now established in the SDR domain. This is notable if not remarkable given that the traditional approach to developing real-time embedded systems (RT/E) has traditionally been driven by the overall goal of maximizing performance whilst absorbing minimum resources at the sacrifice of generally accepted software engineering productivity goals such as reuse, portability, and reduced complexity through modularization. Indeed, the outlook for component-model technology insertion in SDR is now characterised by complex heterogeneous environments for waveform application development and deployment. Finding an optimum degree of granularity for the modularization of waveform functionality is an important consideration; equally important both when using software components and in conventional programming. Here, the challenge is to achieve the right checks and balances in meeting runtime constraints and maintaining an effective degree of re-usability. Unlike in traditional programming however, component-model based programming enforces a formal definition of component dependencies using easily understood description languages. These are applied at component assembly level and packaging; the latter including binary modules. Generally therefore, the use of components strengthens the visibility of dependencies between software units by enforcing formalised rules for matching component interfaces when composing application assemblies. This has the overall effect of minimizing any ambiguity when selecting software units for re-use, thereby increasing cost-effectiveness in development, and reducing the time to market of developed products. The above considerations has motivated the application of component-model based software development techniques fairly comprehensively in a broad range of enterprise-level solutions, but also more recently standardised for use in SDR by way of the Software Communications Architecture (SCA), and the OMG CORBA Component Model (CCM). Importantly, the OMG has also published a specification called “PIM and PSM for Software Radio Components” which orientates the definition of a component model specifically for SDR. This is closely aligned with the SCA, but it uses a neutral format based on common modelling concepts and notation (also evolved through standardisation efforts) to express the architecture definition. This naturally leads to the use of modelling tools for defining applications and platform execution environments based on component models for use in SDR.

FP7-Security EULER


4.4.2 Modelling Approaches associated with Componen t Model Architectures

Modelling languages such as UML have been used in the past to design software radios where the development process followed OO programming guidelines and was aligned generally with accepted OO methodologies. More recently however, so-called Domain Specific Modelling tools have emerged to more naturally support this process in the context of the required vertical application development domain. In the case of SDR, such DSM tools use Domain Specific Languages (DSLs) and are underpinned by meta-models that reflect the component model architectures standardised in today’s software radios. As in the general case, SDR DSM tools are interactive in nature and provide graphical editors that allow radio waveform developers and system designers alike to more easily express the design intent of a radio platform and waveform, but unlike UML, these allow the codification or reuse of design patterns commonly used in the SDR space and as such allow end-users to more quickly and accurately develop and deploy workable systems. SDR DSM tools represent a class of application supported by a so-called Model Driven Development (MDD) approach. Essentially the MDD process encapsulates a software development or “forward engineering” process where graphical modelling is used as the primary expression of a design focused entirely on architecture that relies on the automatic generation of code and other supporting artefacts from the model. This allows end-users to design and develop at higher levels of abstraction providing a focus on the problem space (the design of their systems) rather than on the solution space (the source code they need to produce to realise the end system). As such MDD potentially addresses the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts more effectively. The OMG has developed a set of MDD standards called Model Driven Architecture (MDA) by building a foundation for this advanced architecture-focused approach that enforces the separation between Platform Independent Models (PIM) from Platform Specific Models (PSM). A Platform Independent Model (PIM) is a model (as described above) that is independent of the specific technology used to implement it. The principle here is that from such a model it should be possible to use a set of transformation rules to transform (using a model transformation engine) a platform-independent model into a platform-specific model that has specific dependencies on the underlying execution environment (RTOS/processor). Generally speaking, engineering of executable software has historically evolved in this way; for example, source code compilers use a set of rules to transform source code into an assembly language specific for a particular microprocessor that is in-turn transformed by an assembler (using another set of transformation rules) into machine code. Therefore, even the most fundamental software engineering processes can be seen as a chain of transformations from abstract requirements to make the executable system. The notion of Platform Independent Modelling raises the development visibility to a level at which software designers can capture the essence of a design without consideration of the nuances or intricacies of how the system is actually implemented or assembled. Therefore providing a PIM abstraction in the model makes it possible to promote design re-use more effectively where different sets of transformation rules can be used on the model to produce the same functional system but on a different target platforms. The process of modelling the association of transformation rules to the PIM is referred to as Platform Specific Modelling (PSM). This concept of a PIM – more specifically, the PIM/PSM split, is entirely aligned with that facilitated by various standardised component model frameworks, where a so-called “separation of concerns” is achieved at the architecture level affecting the execution environment where the domain-specific implementation can be developed in isolation and without prior knowledge of the platform. Therefore, the case where MDD tools can be applied at the Platform Independent level and at the Platform Specific Level is ideally suited to modelling the constraints and semantics associated with component models, but is particularly useful as a productivity tool, promoting re-use and portability, where these comply with some form of standardised component framework.

FP7-Security EULER


The ability to effectively model constraints, or to develop a standard compliant model with implicit constraints enforced by the meta-model describing the standard, provides a superior, less error-prone, and more efficient mechanism for developing waveform components that have formalised and consistent interfaces, and the necessary properties enabling the validation of the deployment readiness of waveform components into a particular platform by matching the required resources e.g., processor types, capacities etc., and the relevant radio characteristics, e.g., sample rate, flow control etc.

4.4.2.1 ESRA Case Study In the case of EULER Platform #2 (SDR4000), the Spectra CX SCA modelling tool was applied consistently to support the EWF HDR (WiMAX-like) waveform design/development/integration process, including forward and round-trip engineering, and for establishing the SCA 2.2.2 compliant platform model. The benefits described above were endorsed by the collaboration between partners involved in waveform integration activities. Consequently the process fully supported the ESRA recommendation for the waveform engineering mid-term vision (1 Section 5.2), specified as follows, General MDD processes applied to SDR component models:

• Enforcement of Waveform / Platform paradigm, • Usage of Model Driven Engineering techniques, based on OMG MDA,

Notions of Waveform Specification, Base Waveform and Target Waveform

4.4.3 Software Communications Architecture (SCA) an d associated Standards

In order to attain a degree of “openness” the SCA mandates a number existing communications and operating system infrastructure standards. Most notably these include the OMG Common Object Request Broker Architecture (CORBA) including Interface Definition Language (IDL), and the Portable Operating System Interface (POSIX) standards for distributed communications and Operating System (OS) API conformance respectively. In addition, the configuration of SCA Core Framework components is defined using descriptors, generally referred to as the domain profile, expressed according to the eXtensible Markup Language (XML) specification. The SCA was initially based on the Object Management Group (OMG) standard for a CORBA Component Model (CCM). However, the SCA, needing to better address Software Radio, was specialized in its finalization phase to adopt different deployment principles [24], but has retained much of the CCM features including core technologies from the OMG, namely:

• Object Request Broker (ORB), within the capabilities of Minimum CORBA [25]. Today (2011) Minimum CORBA has been re-factored to form the so-called embedded profiles providing lightweight implementations suitable for application in RT/E referred to as CORBA/e3.

• Lightweight Naming Service, Common Object Service (COS) Naming [26]. The Naming Service is used in the SCA as the global location (look-up) mechanism to support the resolution of CORBA object references within the SCA radio platform.

• Lightweight Log Service: Common Object Service (COS) LwLog. The Log Service is used by the SCA radio platform to asynchronously persist operational data.

• Lightweight Event Service: Common Object Service (COS)[27]. The Event Service is used by the SCA radio platform as the asynchronous de-coupled form of message passing between platform components.

3 Note: CORBA/e also embodies the Real-Time (RT) CORBA specification describing the programming model for distributed real-time systems priority mapping/management, thread-pools, and associated connection mechanisms.

FP7-Security EULER


CORBA is therefore fundamental to the SCA providing the essential cross-platform distributed object model and services capability within the radio platform Operating Environment (OE). The SCA was devised to leverage the following principal tenets of CORBA:

• Language neutrality: a CORBA component can be implemented in any programming language for which there exists an OMG IDL language mapping. Although IDL lends itself neatly to mapping based on Object Oriented programming languages (C++/Java), other language mappings exist (example C) which are generally considered more fit-for-purpose when applied to embedded application development.

• Location transparency: a remote call appears as local to the native language implementation. • Interoperability: CORBA applications can interoperate across conformant ORB

implementations (implemented in any language) using a message scheme normalized by the OMG abstract General Inter-ORB Protocol (GIOP). The OMG mandates the Internet Inter-ORB (IIOP) as the concrete implementation of GIOP for TCP/IP (combined message/transport protocol). However, the Extensible Transport Framework (ETF) proposed by the OMG provides a pluggable framework in-order for end-users to program specialized mechanisms for the transport of GIOP messages between ORBs. ETF therefore provides a candidate mechanism to abstract the transport infrastructure details away from application-level considerations, and is obviously suited to scenarios where highly rationalized/optimized transport interconnects and native APIs are available on fabrics between SDR target devices.

• Portability: the portability of CORBA applications across ORB vendor products is implicit in the level of standards compliance adopted – today (2011) full transparency can easily be achieved. POSIX compliance at the ORB and application level is also important, and it is incumbent on the application developer to ensure an acceptable level of compliance offered by the ORB implementation. In some cases, ORB vendors will provide a POSIX API abstraction layer built from available native primitives, e.g. thread/task and semaphore as is for example commonly required to ensure ORB portability over RTOSs running on a range and diversity of Digital Signal Processors (DSP) devices.

This last point reflects one of the challenges in the development of component models generally; that is the difficulty to define a level of OS compatibility needed that will suit all systems. The emergence of a POSIX subset for Software Defined Radio – the so-called Application Environment Profile (JTRS SCA AEP subset) illustrates an excellent example where not only a hard real time requirement was anticipated, but in recognition that at some stage in the future, a requirement might emerge for safety and security certification of that subset. As a result, SCA conformant systems must comply with a standard set of interfaces to the operating system services. The set of POSIX standards established by the IEEE defines such standard interfaces and is the only existing standard for real-time operating systems (RTOS) interfaces that is implemented wholly or in part by multiple operating systems. POSIX was therefore selected as the basis for RTOS compatibility.

4.4.3.1 ESRA Case Study In the case of EULER Platform #2 (SDR4000), the Spectra e*ORB CORBA ORB was used to provide a CORBA communications over all high speed data bus connections, and as such IDL was used to define all interfaces for the EWF HDR (WiMAX-like) waveform application components deployed to all processing units (including the transceiver sub-system running on the FPGA) available on the platform. Mixed implementation languages were adopted primarily supporting the C programming language on the DSP, and C++ on the GPP using the e*ORB C and C++ Editions of the CORBA ORB product respectively. Additionally, the SDR4000 native high speed packet data transport mechanism (referred to as QuicComm) was used via ETF for all inter-device communications, whereas the default IIOP (TCP/IP) ETF plug-in was used for inter-process communications on the GPP. The recommendations of ESRA in respect of Execution Support ([1] Section 5.3) and architecture area synthesis were supported as follows, • DSP Component Models: The SCA POSIX AEP subset requirements were fully met using the POSIX

abstraction available in the CORBA ORB infrastructure - principally providing the mapping of threads and timers for the EWF HDR WiMAX-like Modem Component to the underlying RTOS primitives capability.

FP7-Security EULER


• Connectivity Mechanisms: An ORB based on OMG CORBA for the C language mapping was used on the DSP in-order to provide a lightweight middleware infrastructure. This provided full transparent interoperability between components deployed on the GPP (C++) and FPGA (VHDL) using a mixture of native data transport fabrics made accessible by use of the appropriate ETF plug-in developed for the platform.

4.4.4 The SCA Component Model and the SDR environme nt SDR includes software for execution in all or part of the digital communications signal path; thus in general referring to functionality within the physical and data link layers and perhaps parts of the network layer of the OSI reference model. However, the software functionality in SDR is ubiquitous in the form of so-called “waveform applications” that deal with specific radio protocols principally at the physical layer where the transmission of a physical signal converted from raw bits (rather than packets) over a data-link “medium” connecting network nodes is performed. As such waveforms manipulate data in the form of a bit-stream as for example that applied in a modulation scheme, where crucially this may be changed in software without requiring any attendant hardware modifications, thus allowing the same radio hardware to receive and transmit a different form of radio protocol. In a similar way, the adaptability of SCA is also beneficial when it is required to reconfigure the deployment scheme for the same arrangement of processors in order to yield a less expensive and/or a more optimal component assembly. The requirements for portability, interoperability and re-configurability in SDR has led to the consideration of a unified component model applicable to all SDR devices including FPGA as well as ISA (GPP and DSP) devices. The main difficulties encountered in defining a unified component model arise due to the conceptual gap and heterogeneity that exist in hardware/software models of interaction, programming, computation and execution, languages of specification and implementation, and the environments for simulation and execution. In the domain of software engineering, developers typically use high level languages (e.g., C, C++) and possibly rely on standard APIs (e.g., POSIX) and standard middleware technologies (e.g., CORBA) supported by Operating System capabilities. Here, the mechanisms involved in an operation or procedure call are implicit and fixed by a calling convention between a programming language, a compiler and a CPU instruction set architecture and opportunities for optimization of operation call execution latency or memory resource usage is transparently handled by the chosen compiler. In contrast, hardware description languages (HDL) used in the FPGA development tool-chain imposes an inherent trade-off between size and performance (bandwidth, latency) in addition to the power consumption required by hardware modules. FPGA IP core interfaces are explicitly defined as hardware wires and IP functionality is requested via an application/user-defined protocol. There is no calling convention or API for processing, synchronization, or state retrieval. Moreover, hardware processing can be achieved on-the-fly using pipelining. In contrast with developments in the software domain, no component model actually exists for direct application to FPGA. The main reason for this is that hardware modules are very often seen as slave processing accelerators which are static in nature, controlled by high level services managed in software. However, an SCA conformant approach has been developed for FPGA that utilizes a hardware ORB for use with FPGA devices allowing software objects located on ISA devices (DSP/GPP) to communicate with the waveform objects running on the FGPA without the need for a proxy adapter pattern or embedded soft-core processor.

4.4.4.1 ESRA Case Study In the case of EULER Platform #2 (SDR4000), the Spectra ICO CORBA ORB was used to provide CORBA style communications between the platform transceiver subsystem (XCVR) on the FPGA and the SCA compliant modem component (Resource) running on the DSP. As such IDL was used to define all interfaces for the EWF HDR (WiMAX-like) waveform application components including the XCVR. Similarly, Proxy SCA Devices were developed to translation functions as necessary to execute

FP7-Security EULER


the modem and transceiver component binary executable onto the DSP and FPGA respectively, and in the case of the DSPProxyDeviceAdapter, channel requests to/from the modem from the GPP (MAC). Consequently, the recommendations of ESRA in respect of Execution Support ([1] Section 5.3 and 5.5) mid-term vision and architecture area synthesis applied to the following were affected,

• Connectivity Mechanisms: CORBA deployed on all ISA devices and FPGA affecting the signal processing data path.

• FPGA Component Models: Realisation of CORBA ORB on FPGA

• Characterisation of waveform components for SDR platforms: Given the parameterisation of transceiver properties developed for Platform #2 (SDR4000), it is recommended that SCA properties relating to the SCA ExecutableDevice Component representing the transceiver facility are standardised in order to characterise the radio facility for the deployment validation of foreign waveform components relating to,

• Waveform ID • Sample Rate • Signal Level • Signal Type Identifier (I/Q)

The use of SCA Components acting as Proxy Adapters should be endorsed whereby an SCA device can be deployed to a processing unit to act as a proxy for a different (target) processing unit. The proxy will provide translation functions as necessary to load and/or execute deployable binary Components (e.g., SCA Waveform Application Components) onto the target processing unit, and if necessary channel requests to/from the deployed Component to other waveform Components acting in the signal processing chain.

4.5 Radio interface(s). Radio interfaces are considered to be the interfaces of the Radio Domain Device(s). According to ESRA Radio Domain Devices form an Intermediate Architecture Area that is constitutive of the Functional Support provided by a SDR Platform.

4.5.1 Introduction The Architecture Area “Radio Domain Devices” is addressing the Radio Platform Sub-systems. The SDR Forum Transceiver facility is used as a basis to specify the interface within EULER, however is unfortunately of little use due to the largely dedicated solutions chosen. In Figure 4 the interface mapping between the PIM level and the Platform Support Implementation is given.

FP7-Security EULER


FS

FA Functional Application Module (waveform)

Functional Support Module (platform)

Waveform Functional Decomposition

PIM

PSM

FA

FA

FS FS

FS

FA

FS

FSX

X

X

X Waveform Abstract External Interfaces

Functional Support (platform)

Platform Support

FA

X

X

FA

X

FS

X

X Logical Device

Functionally equivalent perimeters

Logical Interfaces Mapping

Platform Sub-system

Platform ServicePlatform Sub-system

Waveform External Interfaces

X

Façade

Figure 4: from Functional abstraction to Implementation of Platform Support

The upper part of Figure 4 is depicting a Waveform Functional Decomposition, with Functional Support and associated External Interfaces identified. Three functional scopes are implemented in this example:

• The Platform Sub-systems are depicted with the introduction of Logical Devices and Façades as the software parts of the sub-system implementation which are presenting the Implementation Interfaces towards the possibly executed applicative components. The corresponding interfaces are potentially running on different execution units, as it is the case for the Sub-system on the right hand side.

• The Platform Service is integrally executed in a given Execution Environment, and is similarly to the sub-system presenting an interface for the Applicative component that exactly derives from the initial Functional External Interface.

• The Logical Interfaces mapping is realized between the Functional Descriptions and the implementation languages of the selected Execution Environments. Typically this is what an IDL compiler is realizing between an IDL file attached to a functional interface and the target implementation language interface files, which are in the case automatically generated.

The relation between execution environment, functional environment and execution unit is given in Figure 5. The execution unit here is the analog front-end (including frequency conversion) and the digital RT front-end processing is also included.

FP7-Security EULER


Figure 5: SDR implementation of Front-end electronics

The digital front-end processing comprises issues like frequency translation, channel filtering, sample rate conversion, modulation and demodulation. The Baseband and Intermediate Frequency (IF) Processing of a SDR Waveform Application is performed by the GPP, FPGA & DSP components of the SDR Platform. However a Waveform needs to utilize a much larger spectrum of hardware components of the SDR Platform in order to accomplish the required functionality – one or several RF front-ends, I/O devices and Support devices. The Logical Device generic interface provides the base capabilities to instantiate, initialize, configure, connect and start a Radio Platform Subsystem when required and to stop, disconnect, release and terminate it when it's no longer needed; additional functionalities may be provided in additional ports. A Logical Device typically also maintains the overall state of the related hardware. The simplest Platform Subsystem would be composed of a single hardware device, in which case all the functionality of the abstraction layer (interface serving the Reconfiguration Architecture and ports serving the Waveform Application Resources) would be contained in a single Logical Device executing on a GPP. A more complex (aggregated) Platform Subsystem would contain several hardware devices; in this case only one Logical Device would realize the functionality required for the Reconfiguration Architecture, whereas one Platform Façade for each of the individual hardware devices would execute on a DSP/FPGA.

ExecutionUnitCPU, Peripherals, Memory, Registers…

Component BinaryCode

OperatingEnvironment

FunctionalEnvironment

Platform components(Façades & Radio Services)

• Execution Units• Techical Services• Reconfiguration Infrastructure• ImplementedFunctionalities• Execution Resources Sharing

ExecutionEnvironment

Interface mapping















Interface mapping

FP7-Security EULER


4.5.2 Philosophy on Interfaces The ultimate top level approach to interfacing is to consider the overall system as a black box; only specifying input / output in a behavior model. In this case only two interfaces are present, the air interface (“antenna”) and the user interface (for example a microphone, a loudspeaker and some switches). One level more in detail is achieved by separating platform (PF) and waveform (WF). In its most elementary form this would only add one interface: the platform-waveform interface. One should allow more than one waveform running on the same platform simultaneously, and those multiple waveforms should be allowed to interact (for example in a relay station or for connection of two radio networks). This requires a WF to WF interface. Moreover in military systems provisions have to be present for Infosec (“red black separation”). This requires one more interface, the Infosec interface, as is depicted in Figure 6. This results in 5 interfaces.

Figure 6: High Level System

Having this platform/waveform separation, the easiest is to focus on the interfaces of the system: user/air interface and HW/SW interface. With the inclusion of the WF-WF interface definition (waveform to waveform and intra-waveform, to allow for standard WF components) and the Infosec interface we have a universal set of interfaces. Components are a higher level of abstraction than objects, in the sense that they do not share states, and instead communicate only by exchanging messages. This separation allows for each component to be designed, implemented and tested separately. A component can be software-only, or even a hybrid of hardware and software; other components should be indifferent to the internal structure of a component. The component-based philosophy calls for the definition of interfaces between components. Components then communicate with each other exchanging messages that comply with the defined interfaces. Components are extensible and maintainable, and all that is necessary is that they continue to comply with the interfaces. What is intended with the term "interfaces" is a set of APIs and inter-process communication protocols, allowing components to advertise and request services from other components. Furthermore, it includes a description of the expected behaviour from a component, when a certain method is invoked. For example, a vocoder component should advertise specific interfaces, but one should also verify that the output stream is in fact the desired encoding of the input voice stream. This is a black-box approach, since we don't look at the internals of a component, we don't care how it implements the intended behaviour, but only want to make sure that the intended behaviour is followed.

waveform

platform

Waveform – platform interface

waveform

platform

Waveform – platform interface

User InterfaceUser Interface

WF-WF Interface

INFOSEC InterfaceAir Interface

FP7-Security EULER


An additional requirement of embedded real-time systems - as is a software-defined radio - is the timeliness of a component's output, in addition to its correctness. In a real-time system the time at which an answer arrives matters as much as the actual correctness of an answer, to the extent that a correct answer that arrives too late is no longer useful and it is dropped (soft real-time), or even that the lateness of an answer could have catastrophic consequences (hard real-time). It is more probable for a software-defined radio to be soft, rather than hard real-time. The design of these interfaces should take this need for timeliness into account. The robustness and reliability of a component is not only measured when it receives manageable amounts of correct input signals, but also when it receives erroneous inputs, or when placed under the stress of high amounts of input. The interfaces should explicitly define the desired response signals from a component when it receives erroneous input or when it receives more requests than it can satisfy while maintaining real-time constraints. These behaviours should be verifiable for each possible erroneous input vector.

Figure 7: Considered Interfaces

A depicted in Figure 7,we identified 5 different user classes of interfaces in an SDR system: • Waveform-Platform interface: This is the interface between Waveform Components and

Platform Components. It is the main enabler of Waveform Portability among diverse SDR Platforms.

• Waveform-Waveform interface: This is the interface between different waveforms running on the same platform. It would enable bridging of the same or of different waveforms, as well as other secondary functionalities, like cosite interference mitigation.

• Air interface: This is the over-the-air interface between different radios. It is the enabler of Wireless Interoperability. In the strict sense meant here it only addresses the interface between platform and air, so the “classical antenna interface”. In a more general sense, the air interface defines also the “signal in space” (SiS). The “signal in space” is defined by the Waveform, whether it is implementing an existing wireless standard, or inventing a new one. The waveform has to meet the air interface standard.

• User interface: This is the interface with devices implementing the human-machine interface (e.g. microphone, speaker, dialpad, push-to-talk, screen, etc). This interface is not SDR specific, for example a computer might have the same interface.

Platform – waveform interface

SOFTWARE RADIO PLATFORMFeatured for Waveform Performances

CS

/S

I / O

Bla

ck C

ontr

ol

Rou

ting

RF/IF

Universal Transceiver

Modem

Red

Con

trol

B

ridgi

ng

PowerAmplifier

&Antenna

Core Framework

(COTS)

OS (COTS) & BSP

LogicalDevicesFacilities

TransportORB, OCP

(COTS)

Waveform

Air interface User

interface

INFOSEC interface

WaveformIntra waveform

interfaceWF – WFinterface

Intra platform interface

Platform – waveform interface

SOFTWARE RADIO PLATFORMFeatured for Waveform Performances

CS

/S

I / O

Bla

ck C

ontr

ol

Rou

ting

RF/IF

Universal Transceiver

Modem

Red

Con

trol

B

ridgi

ng

PowerAmplifier

&Antenna

Core Framework

(COTS)

OS (COTS) & BSP

LogicalDevicesFacilities

TransportORB, OCP

(COTS)

Waveform

Air interface User

interface

INFOSEC interface

WaveformIntra waveform

interfaceWF – WFinterface

Intra platform interface

FP7-Security EULER


• Infosec interface: This is the interface to the platform component (whether software-only or hybrid hardware-software) implementing the information security functionalities: confidentiality, integrity and authentication. The interface should allow the use of programmable hardware devices that support new cryptographic algorithms and protocols. These devices might be used among multiple waveforms and can also support user-specific encryption.

These classes are called user classes because they have to be present from a user perspective. The user will have antenna and for example microphone, he also wants to select waveforms and use his own InfoSec. This will result in the following requirements for ESRA:

EULER_REQ 2: ESRA SDR PF has to support embedded middleware compatible with IDL.

EULER_REQ 3: ESRA SDR PF has to support common4 air interfaces.

EULER_REQ 4: ESRA SDR PF has to support common user interfaces.

EULER_REQ 5: ESRA SDR PF has to support WF to WF interfaces. (in case of multiple

waveform occurrences) This aspect is not elaborated in EULER.

EULER_REQ 6: ESRA SDR PF has to support Infosec interfaces. This aspect is not elaborated in EULER.

From a manufacturer perspective it might be advantageous to have intra waveform and intra platform interfaces. For example multiple waveforms might use FM or QPSK, these modulation schemes might be available as a plug in supplied by a third party. Also given platform modules might be supplied by a third party. The ESRA framework defines the various components within the platform and possible interfaces between them.

4.5.3 Generic interfaces The interfaces described in paragraph 4.5.2 are elaborated shortly in this paragraph. The elaboration is by no means exhaustive or complete. The Waveform-Platform Interface: Several Waveform-Platform (i.e. software-hardware) Interfaces are available like:

• The JTRS APIs were released as a companion to the SCA Architecture. They satisfy our definition of interfaces, since they not only define the form of the APIs (parameters, return values), but also the expected behavior and possible exceptions. MHAL (the Modem Hardware Abstraction Layer) is one of these APIs.

• OMG SWRadio defines a Component Framework that is based on the separation between a Platform-Independent Model (PIM) and Platform-Specific Models (PSM). The PIM is designed in the Unified Modeling Language (UML), while the PSM is done in a Domain Specific Language (DSL), e.g. CORBA Interface Description Language (IDL) and eXtensible Markup Language (XML).

• POSIX (or Portable Operating System Interface) is an IEEE standard of software APIs and user interfaces to the Unix Operating System.

• JVM (or Java Virtual Machine) is a Hardware Abstraction Layer (HAL) that allows Java Bytecode to run on any machine for which a JVM is available.

The Waveform-Waveform Interface: General software interconnect interfaces are available like:

4 Not SDR specific

FP7-Security EULER


• CORBA is the Common Object Request Broker Architecture, an OMG standard that allows transparent communication between components independent of their location. It is part of the SCA Architecture mentioned above.

• MHAL (Modem Hardware Abstraction Layer) JTRS API • D-Bus is an Inter-Process Communication (IPC) bus, used for sending messages between

applications. Conceptually, it fits somewhere in between raw sockets and CORBA in terms of complexity.

The User Interface: The user interface is not SDR specific. Examples are:

• Military user interfaces like MIL-STD_1553B, MIL-STD_1760 and MIL-STD_1397. • USB is a widely deployed (2 billion devices) serial bus standard that supports several types of

peripheral devices: audio (class 01h), human interface device (class 03h), mass storage (class 08h), video (class 0Eh), etc. The standard incorporates device type or in other words the generic behavior of the device connected with the USB interface.

• Numerous other user interfaces exist but they do not specify the behavior model of the interface. These interfaces will not be listed, given the fact that there are no SDR specificities to the list. These interfaces can be used as user interface as well.

The Infosec Interface: Examples of Infosec interfaces are:

• MITRE CICM (Common Interface to Cryptographic Modules) • SCA JTRS Security Supplement. This document is no longer supported by JTRS. However it

can still be used as a reference thereby providing a starting point for the development of standards.

• Many OS have their own Cryptography Framework (APIs) that allow applications to use cryptography services, e.g. Windows, Linux, Solaris, and OpenBSD.

Other Interfaces: Various “other interfaces” are available. These are not specific for SDR (they apply equally to the equivalent legacy equipment). Examples of possible applicable interface descriptions are:

• Power supply / battery: Reference levels should be taken into account for maximum power consumption or battery life.

• Environmental: temperature, humidity, shock, vibration etc. Control Interfaces: This interface is an additional layer that is physically supported by one of the other interfaces. When locally operated, this interface is the same as the user interface, but remote control can be performed over the air interface. Air interface: This interface is described by the waveform, apart from the antenna. Antennas are usually available with 50 Ohm impedance. The waveform can be in concordance to any existing radio standard. Intra platform and intra waveform interfaces: Usually proprietary interfaces are used.

4.5.4 Interfaces in detail Interfaces and interface descriptions are numerous within SDR. The topic interfaces will address the requirements needed to operate the specific components of the radio domain devices, like FPGA and DSP. Also the reconfiguration interface requirements needed for reconfiguration of the analog path are discussed. Interfaces related to physical layer services and subsystems, in particular Transceiver and Time Machine are of strategic importance. Unfortunately, until now, a possibility for this capability to be implemented as a general purpose radio subsystem is not achieved. It is recognized that time management require its own interfaces. In this paragraph some of the more important interfaces are elaborated.

FP7-Security EULER


4.5.4.1 Frequency reference interface A device compliant to this interface provides a port implementing the frequency reference. A waveform might want an accurate time reference or an accurate frequency reference but certainly not to access the internals of these functions itself.

4.5.4.2 Link Layer The Link Layer Control (LLC) layer provides functionalities to the upper layers for management of communication links between two or more radio sets. The LLC interface supports three modes of communication: connection, connectionless and acknowledged connectionless. The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. After the link parameters are negotiated and the link is established, a data provider can send a data stream through the link. Data may be lost or corrupted in this service mode, however, due to provider-initiated resynchronization or connection aborts. The connectionless mode is message-oriented and supports data transfers in self-contained units (PDUs) with no logical relationship required between units. Because there is no acknowledgement of each data unit transmission, this service mode can be unreliable in the most general case. However, a specific logical link provider can provide assurance that messages will not be lost, duplicated, or reordered. The acknowledged connectionless mode provides the means by which a data link user can send data and request the return of data at the same time. By this way, the transmitter knows which data packets made it through, and retransmits the required packets. Although the exchange service is connectionless, in-sequence delivery is guaranteed for data sent by the initiating station. The data unit transfer is point-to-point.

4.5.4.3 Antenna interface The OMG SWRadios Antenna class represents the RF radiating elements necessary for transmission / reception of radio energy through the ether. The Antenna class inherits the SWRadios CommEquipment and RFDevice classes. It consists of both a simple passive radiating element as well as an antenna array with possibly some dedicated intelligence. The OMG SWRadios Antenna API includes the interface to calibration information of the antenna, the current radiation pattern that is configured in the device, the configurable orientation of the RF energy radiated from the antenna, physical type of the antenna, the maximum radiation pattern that the device is able to achieve, the minimum radiation pattern that the device is able to achieve and the orientation capability of the RF energy radiated from the antenna. A Smart Antenna is an antenna array system that is designed for a part of a radio system that processes the signals received or transmitted by the array using suitable algorithms. An antenna array consists of a set of distributed antenna elements which are arranged in certain geometry where the distance and spacing between the antenna array elements can change. The received signals are collected from the antenna array elements and are processed in a manner that reduces interference and increases the certain signal strength. As a Smart Antenna can be seen a set of antenna array elements that transmit and receive signals by using certain algorithms. A software-defined Smart Antenna is a smart antenna array with algorithms which can change certain operating parameters by software, e.g., the operating frequency etc. There are three interfaces which are used to control the entire Smart Antenna Subsystem:

FP7-Security EULER


• Interfaces for Control Facilities, including synchronization control interface, algorithm mcontrol interface, and RF control interface.

• Interfaces for synchronization facilities, including calibration interface and synchronization interface

• Interfaces for algorithm facilities.

4.5.4.4 MHAL API Joint Tactical Radio System (JTRS) has published a standard Modem Hardware Abstraction Layer Application Program Interface (MHAL API). The standard makes an abstraction of the radio channel modem interface for the application software. The MHAL API supports communication between application components hosted on Computational Elements (CE). The concept of the MHAL API is to provide a consistent host environment for waveform applications and waveforms across different platforms. See Figure 8: MHAL API. Because the waveform-side interfaces are presented by the MHAL API, abstraction elements remains the same from platform to platform, thus waveform and application components can be ported readily between different radio sets. The platform-side interfaces of the MHAL are defined by the radio set platform for its particular architecture and mission. The MHAL API defines a common set of services and interfaces required by most radio platforms.

MHALLibrary

Computational Elements

MHAL Interface

ElementA

ElementB

RFAmplifier

CositeResource

AntennaResource

Figure 8: MHAL API

From one MHAL CE, it is possible access to any of the other CE using the MHAL Communication Service for the routing. The abstraction layer defines the MHAL Message Structure which defines the same message format for all MHAL CEs. Because the DSP environment does not necessarily readily support dynamic linkable objects, the MHAL DSP is a library of standardized components that are linked into the waveform code at build time. The external interfaces and transport are platform defined, but the public interfaces to DSP waveform components should be consistent. The MHAL DSP API defines the interfaces. The MHAL API does specify the MHAL protocol interfaces of different CEs for communication between the waveform and hardware. See a reference deployment in Figure 9. The MHAL API does not specify the number of CEs, the platform specific transport or hardware architecture.

FP7-Security EULER


Computational Element

MHAL DSP Library

ModuleX ModuleY

Dat

a S

ink

Fun

ctio

ns

Dat

a S

ourc

eFu

nctio

ns

Platform Specific Transport

MHAL_Comm

RFAmplifier

CositeResource

AntennaResource

MHAL GPP MHAL FPGA Library

Figure 9: MHAL API Reference Deployment Diagram

This will result in the following requirements for ESRA:

EULER_REQ 7: ESRA will support MHAL, for interoperability.

MHAL RF Chain Coordinator API extension

The JTRS (Joint Tactical Radio System) MHAL (Modem hardware Abstraction Layer5) API (Application Programming Interface) is a specification for abstracting the channel modem interfaces from the application software. The API supports communication between application components hosted on GPPs, DSPs and FPGAs. The JTRS MHAL API aims at easy porting of waveform and application components between different JTR sets by specifying a common set of MHAL services and interfaces. The MHAL is platform independent and specifies neither the number of computational elements nor the platform specific data transport, nor hardware architecture. The JTRS MHAL API specifies a generic message structure between the different computational elements of a JTR platform and it also specifies the protocol interfaces of the different computational elements. The MHAL RF chain coordinator API consists of a set of sink and source functions that provide coordinated control of a JTRS communication channel’s RF resources. This API presents command messages for setup and preset purposes in the RF frontend section. It contains a set of channel configuration, delayed execution and immediate execution command messages for data sinksI/Q Baseband & Control Interface

4.5.4.5 I/Q Baseband & Control Interface

4.5.4.5.1 Introduction In cellular radio communication, a strong trend towards splitting of a base station into base station server and remote radio head RRH is visible. This splitting has several advantages • Higher power at the downlink can be achieved with the same installed RF power

5 http://jpeojtrs.mil/

FP7-Security EULER


• Better RF performance in the uplink • Elimination of bundles of antenna cable between standard base station and antenna • Lowering of cooling requirements and power consumption • 1 BTS server for multiple remote radio heads in simulcast or in multicast fashion

Figure 10: separation of a BS into BS server and RRH [28]

These advantages, along with the desire to interchange BTS component suppliers, led to the development of multiple digital I/O standards for the interconnection of the base station server and the RRH. Two main standards are defined and are used, OBSAI and CPRI. The specification of a digital interface leads to a natural partitioning of the HW, where the base station server is used to provide the base band processing of the standard/waveform. The RRH incorporates mainly the frequency conversion, DAC and ADC, filtering, amplification in the TX part and low noise amplification in the RX part including AGC. Both OBSAI and CPRI are dedicated to the cellular mobile communication. OBSAI supports the air-interface standards GSM/EDGE, WCDMA/LTE, 802.16d-e, CDMA2000. CPRI supports 3GPP UTRA FDD, WiMAX Forum Mobiles System Profile v1.1.0 and LTE, recently with enhancements for MIMO. Common to both standards is the necessity of enhancement in case a new air interface standard or an enhancement of an existing standard is introduced. In 2010, a new standard called ORI (Open Radio Equipment Interface) was originated by ETSI [29]. The interface is built on top of CPRI, where required new functions are added or options are removed. The goal of the new initiative is a fully interoperable interface. Due to the adoption of CPRI by ETSI, we give a short overview of the standard as a possible interface within EULER. The description below is mainly extracted from [30]. Base stations and transceiver sites for public safety and military applications also benefit from such splitting of the HW. In PS cellular systems like TETRA, high antenna positions are advantageous for achieving a large coverage. Thus, RRHs and base station server also eases the installation, operation and maintenance of PS systems. Some military sites use split site configurations, where transmitters and receivers are separated in space to achieve better collocation performance. Furthermore, security aspects may inhibit the operation of transceivers hosting classified information, for example on top of mountains. In fact, such classified information processing shall be only performed within dedicated secured areas. Such

FP7-Security EULER


situations clearly require digital interfaces, where only non classified information is transferred to the remote site. Classified information may comprise encryption schemes including keys as well as TRANSEC processing like frequency hopping, where the FH algorithm as well as the frequency set is classified. 6 A Software Defined Radio in the EULER and military context shall process narrow band PS waveforms like analogue voice and TETRA with bandwidth of 25kHz as well as high data rate and wide band waveforms like WiMAX and the EULER waveform with bandwidth of more than 5 MHz. Up to now it is not clear if one frontend can serve all required operating frequency ranges. A suitable digital IF interface protocol shall thus provide • Universal, transparent interface not tailored to certain (civil cellular )standards • Large variations of signal bandwidth (sampling rates) to support both narrow band and wideband

signals in the same base band unit • Point-to-point and point-to-multipoint connections • Support or multiple antennas (MIMO) with dedicated transmitter and receiver modules per antenna • Large instantaneous bandwidth to support cognitive schemes and allowing of bandspreading,

especially frequency hopping, using mainly digital signal processing techniques in the base band • Large dynamic range to cope with cosited operations To meet the requirements, at least in parts, German Fraunhofer Institute for Integrated Circuits has established a specification of the IQ Baseband Interface, which is available as version 0.0.0 on the Wireless Innovation Forum (formerly SDR Forum) under SDRF-08-I-0014-V0.0.0 [31], which will be described in greater detail below. An analysis about maturity, suitability and suggested enhancements/modifications of CPRI and the WINNF interface for EULER is performed at the end of this section.

4.5.4.5.2 Common Public Radio Interface CPRI V4.2

4.5.4.5.2.1 General The Common Public Radio Interface specification CPRI is mainly dedicated to cellular mobile standards 3GPP UTRA FDD, WiMAX specification 2009-08-01 and 3GPP E-UTRA. The radio base station system is divided into the Radio Equipment Control REC and the Radio Equipment RE, which are interconnected by the CPRI interface.

6 The actual frequency in use at a certain time instant has much lower classification level and the information can be transferred via the interface.

FP7-Security EULER


Figure 11: position of digital base band interface in a radio base station system

The interface supports the user data (user plane), control and management data (C-plane) and serves to synchronize the RE both in time and frequency. Beside point-to-point connectivity, CPRI is also suitable for chain, tree and ring architectures.

Figure 12: chain, tree and ring topology, supported by CPRI

Using such topologies, multiple antenna carriers7 AxC can be served. In fact, CPRI allows up to 24 antenna carriers per logical connection for UTRA FDD. Thus, sectorized antenna arrays and MIMO as well as multi-standard REs are supported. The digital interface allows the transmission of IQ samples with line rates between 614.4 Mbps and up to 9830.4 Mbps. The rates are selected to best match to UMTS chip rate of 3.84 Mbps.

4.5.4.5.2.2 Physical Layer

7 Antenna carrier is defined as the amount of digital base band (IQ samples) U-plane data necessary for either reception or transmission of one carrier at one independent antenna element.

FP7-Security EULER


CPRI defines multiple line data rates, { }614.4 , 1,2,4,5,8,10,16i Mbps i⋅ ∈ , with highest rate of

9830.4 Mbps. Coding is 8B/10B according to IEEE 802.3-2005, which also serves as error detection. Certain command and management messages have additional error detection checks. Allowable BER

is 1210BER −< . The line data rates are chosen to match with the UMTS chip rate of 3.84 Mbps. The

1228.8 Mbps line rate results in a payload bit rate of 983.04 Mbps. 8 bits of sample size results in 122.88 Msamples/s, which is just the factor 32 of UMTS chip rate. The following IQ sample formats are defined

Table 7: IQ sample formats

Downlink 8, 9. 10,…20 Uplink 4, 5, 6, …20 Mixed sample format within one basic frame is not forbidden.

4.5.4.5.2.3 Link Layer The data stream is partitioned into basic frames. The basic frame has a fixed length of 260.42 ns, corresponding directly to the UMTS chip rate. 256 basic frames build a hyperframe of length 66.67 us. 150 hyperframes build a CPRI 10 ms frame.

Figure 13: frame hierarchy of CPRI

Depending on the line data rate and the sample size, different numbers of words per frame can be transmitted. The IQ samples for one carrier and one antenna element are put into the containers AxC. Each container is sent as a block. Either consecutive transmission in a basic frame (packet position) or at a certain address (flexible position) is supported. The selection is made by the application.

FP7-Security EULER


Figure 14: AxC container mapping

WiMAX/E_UTRA AxC carry S IQ samples within an AxC container block, which is transmitted over K basic frames. The size of the container, the number S of samples and the number K of basic frames are dependent on the sample size, the sampling rates, the chip rate and the number of symbols in WiMAX. The standard defines how to compute these values. Not used parts in a container or container block are filled with stuffing bits. The assignment of the containers to the individual antenna elements and carriers is not specified. A suitable MUX/DEMUX in both REC and RE shall perform this task. The assignments need to be agreed in advance and shall be known to both REC and each RE within the CPRI link.

Figure 15: Example of protocol stack

256 control words are contained in each hyperframe, organized in sub channels. They comprise synchronisation and timing information, hyper frame separation, slow and fast command and monitoring, L1 inband protocol and vendor specific information. Each hyperframe is headed by a separation byte, indicating the start of the hyperframe, followed by the synchronization sequence. The synchronisation sequence indicates the hyperframe number and the CPRI frame number. Depending on the line data rate, the standard specifies multiple replications of the synchronisation control word within the hyperframe. ([30],§4.2.7.3) Slow C&M channel is based on HDLC protocol and fast C&M channel is based on Ethernet.

FP7-Security EULER


4.5.4.5.2.4 Time synchronisation The CPRI frame structure allows the direct derivation of exact timing for UMTS. UTRA and E-UTRA frame is identical to the CPRI 10 ms frame. WiMAX timing can also be derived from the CPRI frame structure. Normally the WiMAX frame is also aligned to the 10 ms CPRI frame. If not, the REC can inform the RE about timing offset, which can then derive the WiMAX timing. We note, that the WiMAX frame is an integer multiple of the CPRI frame, e.g. 5ms WiMAX corresponds to 19200 CPRI basic frames or 75 hyperframes or a half CPRI 10 ms frame. The CPRI interface provides the basic mechanisms for delay calibration, especially cable delay calibration. ([30], §4.2.9) Thus, the REC and RE can derive the overall delays, knowing the internal processing and signal propagation delays for proper alignment of the AxC to the air interface timing.

Cable delays are determined to an accuracy of 16.276ns≤ , corresponding of 1/16 of the basic frame

length of 260.42 ns. Commands in the cellular mobile world are not time critical and asynchronous. Thus, there is no need for time critical commands (e.g. frequency change). The standard does not specify such event processing with accurate time alignment. The IQ base band samples provide exact time and frequency information for the transceiver module. The hyperframe header can provide a 1pps like signal with an accuracy, which is better than 16.3 ns.

4.5.4.5.2.5 Frequency Synchronisation Form the line data rate, the transceiver module can derive a reference frequency. Using appropriate filtering, the phase noise can be eliminated and the resulting signal can be used to discipline an oscillator in the module, which subsequently serves as the reference frequency source for sampling clocks, oscillators etc.

4.5.4.5.2.6 Link Synchronisation and Maintenance The CPRI standard specifies auto bauding and the auto-negotiation of the C&M plane type and bit rate on layer 1. Link health state is continuously monitored and maintained. Detection of losses is reported and mitigation attempts are performed.

4.5.4.5.3 WINNF IQ Baseband Interface

4.5.4.5.3.1 General The interface specification is mainly dedicated to military SDR radios. These radios normally have very large operating frequency ranges and shall host multiple waveforms with completely different signal bandwidth and modulation schemes. This situation is quite similar to EULER, but somewhat different from the civil cellular world.

Figure 16: position of digital base band interface in a SDR

FP7-Security EULER


The baseband unit (BBU) performs the complete base band processing including INFOSEC (encryption and band spreading calculations). The transceiver module is responsible for frequency conversion, filtering and amplification. Of course, A/D and D/A conversion of the digital baseband is also performed in this module. The interface is strictly point-to-point. That means, the BBU connect to multiple transceiver modules via multiple interfaces. This set-up is different from. CPRI. (cf. Figure 17)

Figure 17: connecting one BBU to multiple transceiver modules

In order to cope with multiple transceiver modules, controlled by one BBU, multiple interfaces need to be implemented. This strict p-2-p connectivity poses some restrictions to enhancements, as a further installed transceiver requires an additional interface at the BBU. Using the MIMO feature, one connection can be maintained in the BBU, but a MUX in the transceiver module is necessary to further route the traffic to the multiple TRX. Separate MUX units can be used to connect multiple transceiver modules.

Figure 18: tree topology of TRX

FP7-Security EULER


The digital interface allows transmission of IQ samples with rates between 1.2 and 72 MSamples per second. This gives rise to signal bandwidth of theoretically up to 70 MHz (in reality limited due to filtering to less than 60 MHz). While this signal bandwidth is more than sufficient for normal communication signals, transmission of multiple carriers spread in frequency by one transceiver is not possible. Furthermore, frequency hopping completely performed in the digital baseband may demand a higher overall signal bandwidth. Such a situation could occur in EULER, if both WiMAX and the EULER backbone waveform shall be transmitted by one transceiver and the carriers are separated by more than 50 MHz. Cognitive Radio techniques in the backbone may also suffer from this limitation, if the link between the nodes of the EULER backbone shall be dynamic in frequency and transmission and reception will occur simultaneously on different frequencies. The specification supports the division of the samples into up to 8 transmitters and receivers in the TRX module (see section 0), giving rise to the mentioned p-2-mp connectivity and support of multiple antenna systems. By such a splitting, the signal bandwidth is reduced. Additionally, the signal bandwidth is influenced by the definition of the number of bits per sample.

4.5.4.5.3.2 Physical Layer

The specification defines three line data rates, 768 , 1,2,4i Mbps i⋅ = . 8B/10B coding according to

IEEE 802.3-2002 is used, resulting in a net data rate of 614.4 , 1,2,4i Mbps i⋅ = . The 8B/10B coding

also serves as error detection. No additional error detection or FEC is specified. Also, allowable BER is not yet stated. The following IQ sample formats are defined:

Table 8: IQ sample formats

TX direction (standard) 24 integer 48 bits of IQ sample size RX direction (standard) 22 bit mantissa and 4 bits

common exponent 48 bits of IQ sample size

TX and RX (optional) 16 bit integer 32 bit of IQ sample size

4.5.4.5.3.3 Link Layer The complete data stream is formatted into messages, building a frame. Each message consists of a header, followed by a fixed amount of control and payload data. The messages have fixed length of

5 1.6673 s sµ µ≈ .

Figure 19: principal frame set-up

Within each frame, payload and control data are transmitted. This set-up gives rise to the following transmission capacity

Table 9: link modes and data throughput

Mode A B C D Line rate [Mbps] 768 1536 3072 3072 IQ sample length [bits] 48 48 48 32 Net control payload per frame [bytes] 24 56 24 24 Net control payload [Mbps] 14.4 33.6 14.4 14.4 Net data payload per frame [bytes] 96 192 480 480 Net data payload [Mbps] 460.8 921.6 2304 2304

FP7-Security EULER


Sample rate [MS/s] 9.6 19.2 48 72 Every message contains a header with a fixed length of 6 bytes, which is also 8B/10B coded. The header is used to signal transmission and to achieve and maintain synchronisation. Link synchronisation is governed by the BBU. When establishing a connection, it starts by transmitting valid messages (normally K28.5 IDLE bytes) to synchronize the transceiver module, which in turn starts to transmit to synchronize the BBU receiver. When no payload data are to be exchanged, IDLE message are exchanged to maintain synchronisation (see section 7.3.2 of [31] for details) The link supports auto bauding. When the line rate is not predefined, the BBU starts with the synchronisation process using the lowest rate. It waits until the transceiver modules responds. If a predefined time elapses without response, the BBU restarts the synchronisation process with the next line rate etc. Once synchronized, the line rate can be changed by exchanging control messages.

4.5.4.5.3.4 Application Layer Message Header The message header set-up is shown in the following figure.

Figure 20: message header set-up

It consists of a SOM byte according to K28.7, followed by 6 bits of protocol version. The message counter is used to indicate the alignment to the second. Thus, message counter of length 20 bit ranges from 0 to 599.999. It restarts every second. Data type field indicates the format if the IQ samples and the number of transmitters and receivers within the transceiver module. Control Payload

The set-up of the control payload is shown below. Within the foreseen field, multiple control packages can be transmitted. Not used parts are filled with padding information.

FP7-Security EULER


Figure 21: control payload structure

Type and length field indicates the type and length of the control package. Critical (TC) and non critical (TU) packets can be transmitted. Critical packets are considered to be time critical and shall have a guaranteed transmission bandwidth. In contrast to non critical packets, they cannot be distributed over multiple messages. Control payload part is protected by a CRC to detect errors. Corrupted control messages are thus detected and will not lead to false commanding. Data Payload

Standard IQ data format is transmitted by the BBU in the following format.

Figure 22: TX BBU TX payload structure standard sampling format

In RX direction, a similar set-up is used.

Figure 23: transceiver module TX payload structure standard sampling format

FP7-Security EULER


In the high sampling rate case, sample size is 2 byte per I or Q sample in both directions. In order to cope with AGC for the optional high data rate mode D in the receive case, the control payload contains an eight bit exponent, containing the actual AGC value. In order to track the AGC value within the message, a counter is used to indicate, at which sample within the payload the new AGC value is valid. No change or change at the beginning of a message is indicated by a counter value 0. Data Payload for several transmitters or receivers and sampling rate reduction

In order to cope with multiple transmitters or receivers, for example in a MIMO system, the IQ samples for/of the individual transmitters or receivers are multiplexed in the payload message. BBU and Transceiver Module need to agree in advance, which sample shall belong to which transmitter/receiver. The standard does not specify how this arrangement shall be exchanged. The number of transmitters and receivers may differ. In this case, the non used samples contain dummy data and will be discarded at the receiver. In the same way, sample reduction in the normal p2-p communication can be performed. The specification allows a downsampling of factor 2, 4 and 8, where only every second, fourth or eight sample is considered. For example, if operating in mode A and having a sampling reduction factor of 4, only the 0th, 4th, 8th … sample is considered and the sampling rate results in 2.4 MSamples/s instead of the original 9.6 MSamples/s. all other samples are discarded.

Figure 24: downsampling by factor 4 for mode A

4.5.4.5.3.5 Time Synchronisation Time synchronisation is a critical issue in modern radio communication. The transmitted signal shall be radiated at the right time instant. Thus, the BBU need to have knowledge about all delays in the chain, BBU transmitter, baseband signal transmission media (cable length) and the delay within the transceiver module. This overall delay is normally known in advance for a certain configuration. Thus, the waveform processing in the BBU needs to perform the required time advance. In the receiving case, similar delays exist and are also known to the BBU. TX and RX messages have a nominal offset of half a message length. An additional offset, which can be negative, occurs due to the difference in TX and RX delay.

FP7-Security EULER


Figure 25: Timing offset receiver samples

Commands are often sensitive to delays. For example, keying a transmitter or changing a frequency in frequency hopping mode of operation requires a precise activation of the transmitter component related to the air interface timing. Thus, the relavant control packet comprises a time delay, which indicates to the transceiver module when the commanded event shall take place. This is shown in the following figure, where the first sample within message n shall be transmitted at

time ,TA nT

FP7-Security EULER


Figure 26: timing offset commands

The IQ base band samples can provide exact time for the transceiver module. The SOM header and message counter can provide a 1pps like signal. The absolute accuracy of this 1pps signal is strongly dependent on the exact determination of the overall signal delay, especially the cable length and processing delays of link transmitter and receiver modules. The standard does not provide any functionality about measurement of these delays.

4.5.4.5.3.6 Frequency Synchronisation From the line data rate, the transceiver module can derive a reference frequency. Using appropriate filtering, the phase noise can be eliminated and the resulting signal can be used to discipline an oscillator in the module, which subsequently serves as the reference frequency source for sampling clocks, oscillators etc.

4.5.4.5.4 Digital RF interface The DigRF v1.12 digital baseband / RF interface carries the following functional signals:

• Transmit symbol information from the baseband to the RF IC • Receive sample information from the RF IC to the baseband • Control information in both directions • Precise timing signal from the baseband to the RF IC • System clock from the RF IC to the baseband • System clock on/off control from the baseband to the RF IC

The physical connections compliant with the DigRF v1.12 standard are depicted in Figure 27. In the version 3 specification the number of signals was reduced to 6 lines. The transmit and receive paths are Low-Voltage Differential Signaling (LVDS) and the bit rate is specified as 312 Mb/s for version 3. For version 4 the bit rate is increased to 1.5 Gbit/s in order to support Long Term Evolution and WiMAX standards that also use multiple-input multiple-output (MIMO).

FP7-Security EULER


Figure 27: DigRF v1.12 interface signals

The DigRF standard defines a packet based protocol for transmitting data and control information.

4.5.4.5.5 SDR Forum (Wireless innovation forum) Transceiver Facility

The SDR forum8 transceiver facility is a standard specification for transceiver subsystems. This specification describes the necessary information for interoperability between waveforms and the transceiver subsystems. It includes generic and abstract requirements for transceiver subsystem properties and programming interfaces but it also includes real-time aspects which form the architectural base of a transceiver subsystem. By abstract it is meant that the specification proposes a Transceiver subsystem characterization without any implementation specific assumptions. By generic it is meant that the specification aims to fulfill the needs of the widest possible range of waveform capabilities. The on-going development of SDR, where radio capabilities are increasingly implemented using software and or hardware description language, results in a need for a further standardization between the transceiver subsystem and the associated actors like the waveform functional application, configuration agent and reconfiguration infrastructure. Standardization is boosting interoperability between implementation components and therefore results in waveform portability, platform openness and integration efficiency. The necessity for a time machine in the transceiver facility is discussed in paragraph 4.5.7.6.

4.5.4.5.5.1 Transceiver Subsystem definition The Transceiver Subsystem is defined as the stage of the radio chain which performs the transformation of the discrete baseband signals SBB[n] into the time continuous RF signal SRF(t) during transmit, and the transformation from RF to baseband signals during receive operation, as shown in Figure 28.

8 http://www.sdrforum.org/ http://www.wirelessinnovation.org The SDR Forum™ / Wireless Innovation forum is a non-profit international industry association dedicated to promoting the success of next generation radio technologies.

FP7-Security EULER


Transceiver Sub-system

Base-band Signal

Radio Signal

sBB[n] sRF(t)

sBB[n] sRF(t) Air

interface To I/O

Antenna Modem …

Figure 28: Transceiver Subsystem within a functional radio implementation chain

Together with the Modem, which represents the baseband processing module, the Transceiver Subsystem forms the physical layer of the depicted radio capability in a SDR. A Transceiver Subsystem implementation is composed of a digital segment and an analogue segment separated by a conversion stage. The breakdown between the digital and analogue segment is one of the most essential architectural choices of a transceiver design. Figure 29 illustrates the Transceiver Subsystem positioning within a typical radio implementation inside a SDR set.

PHY

Transceiver Sub-system

Platform Functional Support

Modem MAC …

Waveform Application

Reconfiguration Infrastructure

Deployment puts Transceiver Sub-system in the required mode, initializes it and connects it to the Waveform Application

Control interfaces enable Waveform Application to interact in real-time

with Transceiver-Sub-system

Antenna

Configuration enables to dynamically modify or read Transceiver Sub-system properties

deployment

ConfigurationAgent

configuration

control

data

Data interfaces enable Waveform Application to exchange baseband signal with Transceiver-Sub-system

Air interface

Waveform Functional Application

Figure 29: Transceiver Subsystem and related capabilities

The abstraction and characterization of the transceiver subsystem is made through the internal structure and external interfaces. The external interfaces consist of the following categories, as depicted in Figure 30.

• Programming interfaces • Analogue interfaces • Properties

FP7-Security EULER


Transceiver Subsystem

Baseband Signal

RF Signal

Real-time Control

(Deployment)

Analogue Interfaces

Programming interfaces

Properties

R

W

R/W access granted to Configuration

Figure 30: External interfaces of a Transceiver Subsystem

The transceiver facility classifies characteristics or properties of the transceiver by notions and constraints. Notions represent characteristics of the transceiver which are observable. Constraints are non-observable characteristics and satisfied by a given transceiver subsystem implementation and are therefore depending on the implementation. The internal structure of the transceiver subsystem consists of a receive-channel and transmit-channel, the so called core features of a transceiver, see Figure 31.

Transceiver

Base-band Signal

RF Signal

Real-time control

Receive Channel

Transmit Channel

(Deployment)

R W

R/W properties access

Figure 31: Internal structure of a Transceiver

The SDR forum transceiver facility is based on the baseline specification of these transmit-channel and receive-channel core features, for which it provides a conceptual description. This concept is used as the base for identifying the generic programming interfaces, the characteristics and real-time requirements.

4.5.4.5.5.2 Transmit channel The transmit channel is the part of the transceiver subsystem which is up converting the baseband bursts into RF signal bursts. This process is comprised by a transmit cycle. The implementation of the transmit channel is composed by a baseband FIFO and an up-conversion chain. The up-conversion chain performs filtering and up-sampling of the baseband signal burst and

FP7-Security EULER


outputs it as an RF signal burst, see

AntennaWaveform Application

Transmit Channel

Packets handling

Up-conversion Chain

Baseband FIFO

Production Consumption

notifiesTransmitDataPush

Burst of Baseband Signal - sBB[n] Burst of RF Signal - sRF(t)

Pushed packet

RF Output

TransmitControl

controls

prepares

takes in charge

EndStart

part of

propagates towards

EndStart

controlsTransmit cycles control

up-converted intocarries

.

AntennaWaveform Application

Transmit Channel

Packets handling

Up-conversion Chain

Baseband FIFO

Production Consumption

notifiesTransmitDataPush

Burst of Baseband Signal - sBB[n] Burst of RF Signal - sRF(t)

Pushed packet

RF Output

TransmitControl

controls

prepares

takes in charge

EndStart

part of

propagates towards

EndStart

controlsTransmit cycles control

up-converted intocarries

Figure 32: Overview of a Transmit Channel

Two programming interfaces are identified in the transmit channel: the TransmitDataPush and TransmitControl:

• The TransmitDataPush programming interface enables the sample packets to be pushed out by the waveform application.

• The TransmitControl enables the waveform application to manage when and how the transmit cycles occur. It manages the start and stop control of the RF burst transmission.

The waveform application pushes baseband sample packets through the TransmitDataPush programming interface into the baseband FIFO. The up conversion chain consumes these samples real-time to up-convert them to the RF output signal. For a proper operation these baseband samples

FP7-Security EULER


need to be available on time in the baseband FIFO and need to be continuously stored in the FIFO to prevent gaps in the real-time streaming to the up-conversion chain. The transceiver facility specification provides analysis requirements for the transmit channel, the baseband FIFO and the up-conversion stage. It also contains requirements for error situations like FIFO underflow situations and a thorough description about the states and transitions of the up conversion chain with respect to the active transmit cycle. A transmit cycle steps through four states (Activation, Active, Deactivation, Unactive), and identifies timestamps associated with the state transitions, see Figure 33. The most important analysis requirements, definitions and their relationship with the transmit channel are captured in the time profile of the transmit cycle which is shown in Figure 34. As can be observed, the timestamps identified in the transmit state diagram can be used to calculate the delays in the transmit process.

DeployedEntry transition

Unactive

SamplesConsumptionStart

Active Transmit Cycle

[@ TransmitStartTime]

[@ TransmitStopTime]

Active• Samples being consumed

• RF signal being produced

RFTransmitStart

RFTransmitStop

SamplesConsumptionStop

[@ ConsumptionStartTime]

[@ ConsumptionStopTime]

Activation• Samples being consumed

• No RF signal

Transient

Deactivation• No Samples being consumed

• RF signal being produced

Transient

Figure 33: States and transitions of the Up-conversion Chain

FP7-Security EULER


t

t

sRF(t)

|sBB|[n]

ConsumptionStartTime ConsumptionStopTime

TransmitStartTime TransmitStopTime

Active Transmit Cycle

UpconversionLatency

Active

As consumed by Up-conversionchain in FIFO

Activation Deactivation

TuningStartTime

Tuning

TuningDuration

UpconversionLatency

Undefined Undefined

No signal No signal

Baseband Burst

RF Burst

TransmitStartTime

TransmitStopTime

Time Profile

Figure 34: Time profile of Transmit Cycle

4.5.4.5.5.3 Receive channel The receive channel is the part of the transceiver subsystem which is down-converting the RF signal into bursts of the output baseband signal. This process is comprised by a receive cycle which denotes the phases corresponding to the down-conversion of a particular RF signal burst. The implementation of the receive channel is composed of a down-conversion chain and a baseband FIFO, as depicted in Figure 35. The down-conversion chain performs filtering and down-sampling of the RF signal burst and outputs it as a baseband signal burst. The receive channel has two programming interfaces; the ReceiveDataPush and a ReceiveControl interface:

• The ReceiveDataPush programming interface enables the sample packets to be retrieved by the waveform application.

• The ReceiveControl enables the waveform application to manage when and how the receive cycles occur. It manages the start and stop control of the RF burst reception.

FP7-Security EULER


Receive ChannelAntenna


Receive cycles control

Down-conversion Chain

Base-band FIFO

Production

ReceiveControl

Pushed packet

packet copies

controls

Packets preparing

ReceivetDataPush

propagates towards

Burst of Baseband Signal - sBB[n]

Start

part of

Burst of RF Signal - sRF(t)

Start

RF Input

controls

Retrieval

Figure 35: Overview of a Receive Channel

The transceiver facility provides analysis requirements of the receive channel, the baseband FIFO, baseband signal and the down-conversion chain. It handles overflow and error conditions with respect to the baseband FIFO flow control. The conceptual behavior of the receive cycle is captured by states and transitions of the down conversion chain and illustrated by Figure 36. A receive cycle steps through four states (Activation, Active, Deactivation, Unactive), and identifies timestamps associated with the state transitions. The timestamps can be used by the waveform to deduce timing information. All important analysis requirements and relationships for the receive channel are captured in Figure 37, which shows the time profile of the receive cycle. As can be observed, the timestamps identified in the receive state diagram can be used to calculate the delays in the receive process.

FP7-Security EULER


DeployedEntry transition

Unactive

RFReceiveStart

Active ReceiveCycle

[@ ProductionStartTime]

[@ ProductionStopTime]

Active• RF signal being consumed

• Samples being produced

BBProductionStart

BBProductionStop

RFReceiveStop

[@ ReceiveStartTime]

[@ ReceiveStopTime]

Activation• RF signal being consumed

• No sample produced

Transient

Deactivation• No RF signal being consumed

• Samples being produced

Transient

Figure 36: States and transitions of the Down-conversion Chain

t

|sBB|[n]

ProductionStartTime ProductionStopTime

As produced by Down-conversionchain in FIFO

Undefined Undefined

Baseband Burst

t

sRF(t)

ReceiveStartTime ReceiveStopTime

Active Receive Cycle

DownconversionLatency

ActiveActivation Deactivation

TuningStartTime

Tuning

TuningDuration

DownconversionLatency

No signal No signal

RF Burst

ReceiveStartTime

ReceiveStopTime

Time Profile

Figure 37: Time Profile of a Receive Cycle

FP7-Security EULER


4.5.4.5.5.4 Time management Time management is essential for control in receive and transmit channels. The SDR forum transceiver facility describes two time domain types, absolute time and event-based time. The absolute time as defined in the transceiver facility represents the duration between an absolute time reference and the event time. The absolute time reference is equal to the beginning of year 2000. The absolute time count is realized by a 32 bit unsigned data type complemented by a second 32 bit unsigned data type which represents counting in nanosecond resolution. Event based time uses a time representation convention which identifies the requested Event Time using a reference event available within the platform, from which a time shift enables accurate identification of the desired Event Time. An advantage of Event-based time is that the Waveform Application does not need to realize control operations on the Transceiver Sub-system. Also, the Transceiver Sub-system itself does not need to have knowledge of the absolute date. The necessity for a time machine in the transceiver facility is discussed in paragraph 4.5.7.6.

4.5.4.5.6 Assessment for EULER Use The EULER SDR node will host both base stations for PS cellular systems as well as for civil cellular networks. Furthermore, Satellite (SAT) terminal can be installed within the node. The following paragraphs discuss the use of CPRI and WINNF IQ Baseband interfaces. However EULER selected interface between waveform and platform is the Transceiver Facility. Owing to fast prototyping implementation constraints, the interface between analogue and digital parts of the front-end is customized and by no means fulfils compliancy with any of the standards described above. CPRI is completely dedicated to the civil cellular networks and thus ideally suited for these waveforms’ base stations. SAT terminal normally provides a continuous up- and downlink data stream. TDMA may be supported, but probably with different timing than used in the cellular networks. TETRA, TETRAPOL and analogue voice systems have very narrow bandwidth and thus require only low sampling rates. All waveforms have in common, that the dynamic range of the receiving signals is limited. Thus, 20 bits of sampling size is considered to be sufficient also for TETRA, TETRAPOL and analogue voice. From this short discussion, CPRI can be used to interface REC and RE for all PS waveforms as well in the EULER case. The use in SAT terminal needs to be evaluated for the specific waveform. It is anticipated that the RE can perform the adaptation of the SAT timing to the CPRI timing and vice versa. On issue with CPRI is the low sampling rate of existing PS waveforms, which is in the range of 100 kSamples/s. In order to cope with the high sampling rates of UTRA (basic rate 3.84 Msamples/s) etc., a high interpolation/decimation factor should be foreseen to adapt to the CPRI interface. Alternatively to interpolation/decimation, a kind of band spreading on the link could be used to easily adapt to the CPRI data rates. With such band spreading, a transmitted byte can be spread over multiple bytes on the link, in the easiest case using repetition. Non integer up/down sampling factors can be easily handled with todays technology. Thus, incommensurate sampling rates do not provide problems. Also, differences in TDMA timing can be easily handled due to the exact 10 ms CPRI frame timing. WINNF standard also has a fairly high minimum sampling rate (1.2 MSamples/s), which is much higher than the required ones for the PS systems. The WINNF standard is mainly dedicated to military SDR and is not primarily designed for civil cellular systems. Thus, at a first glance, it seems to be

FP7-Security EULER


equally well suited for EULER use, especially for the PS systems. As EULER hosts multiple civil waveforms, a high adaptation effort within both BBU and transceiver modules is required to match to the civil data rates and timings. Furthermore, advanced cellular configurations with sectorized antenna and multiple carriers for one antenna may require higher line data rates than actually specified. The maximum number of eight different transmitters/receivers can also limit the use in EULER. For example, we can design an EULER node with standard WiMAX (or LTE) with three antenna sectors, TETRA, using two carriers and a three sector antenna, and the EULER backbone, also with three sectors. Thus, we require at least three sectors, each serving four carriers. The WINNF interface allows greater flexibility for cognitive radio use, e.g. scanning of large bands to find suitable frequencies9. However, the maximum line rate of 3.072 Gbps limits the frequency band to be searched in one step. The scanning is greatly supported by the sample formats, which give rise to a very high dynamic range. Such a high dynamic range is not supported by CPRI. CPRI is very much mature and can be used without any modification within an EULER SDR node.10 Standard implementations in FPGA exist and the IP cores can be used. Some adaptation effort is required to match the CPRI framing and sampling rates to the PS cellular systems. The WINNF specification is at the very first stage. Up to now, no implementation in FPGA is freely available. Substantial effort is considered to be necessary to adapt the REC and RE to the interface. Assuming acceptance by the SDR community in the future, it is anticipated that the specification will become mature and IP core solutions for FPGA will exist in the time frame of an EULER SDR node realisation. CPRI has a wide acceptance. In combination with the ORI initiative of ETSI, even a wider acceptance is anticipated. Thus, we assume that is will become the future standard in civil cellular base stations. New waveforms or enhancements of a waveform will probably lead to advanced standard versions. Considering SDR, this is not an issue, as new code can be easily loaded into the platform, if the new waveforms shall be supported. WINNF should be enhanced for the EULER use to cover higher line data rates. Similar data rates as CPRI (9.83 Gbps) should be specified. By such an enhancement, also the number of transmitters/receivers can be enhanced, fitting to the number of antenna and number of carrier per antenna requirement within EULER. Even with these enhancements, the adaptation effort for the cellular civil base stations will be higher than when using CPRI. Thus, a tendency to use CPRI/ORI for the digital base band interconnection can be derived, provided, that a civil SDR standard will be established and the waveforms will be implemented, based on this standard. If the EULER node will also be based on this civil SDR standard instead of the actual existing SCA, CPRI/ORI is the preferred solution for digital base band IF interconnection in the EULER context. Also not directly required by the actual EULER SDR node concept, CPRI shall be enhanced to cope with larger sample word size for the EULER application. Furthermore, an event mechanism such as in the WINFF proposal should be specified and implemented. 11

4.5.5 I/O radio subsystems So far, dedicated IO solutions have been used. Activities to develop alternatives based on OS drivers are likely and might be considered one time.

9 This functionality was shortly sketched in Euler, ‘EULER D3_2_General_design_v1.0.doc’, deliverable, 4. Jan 2010 ,section 4.2.5.2. Cognitive techniques are suitable to find new frequency bands, when the PS bands are jammed. Especially for the EULER backbone, such functionality can enhance the availability of the radio link. 10 The suitability for SAT terminal needs to be evaluated based on the actual used waveform. 11 Actual events in the cellular civil waveforms are tied to the frame timing, e.g. 10 ms. Thus, the RE are capable to perform events like PA keying or TX/RX change by themselves.

FP7-Security EULER


The SDR Forum Transceiver Facility Specification is paving the way. Its development should be carefully monitored and eventually supported to ensure European interests are safeguarded on this aspect. It may though in the end be superseded by other approaches. Timing is still performed using dedicated solutions; a generic time machine definition set is needed to make the interface generic. The necessity for a time machine in the transceiver facility is discussed in paragraph 4.5.7.6. For radio subsystems, only a part of the subsystem is realized in the functional environment, the rest being implemented externally to the execution unit, by a composition of hardware and software artifacts. The functional environment can be implemented with or without a reconfiguration interface, in other words as logical device or as façade.

4.5.5.1 Logical Devices Those implementation interfaces are, in the nominal case, implemented by software executing in a single software module, which is as well implementing the reconfiguration interface. This software module is the logical device attached to the radio subsystem. The rest of the implementation is made of hardware and software isolated by the logical device. This situation is depicted in Figure 38.

X Funct ional Platform Interfaces

Reconfigurat ion Interface

Logical Device

Sub-system Core

R

Radio Subsystem Implementat ion

R X

XX

X

Reconfigurat ion Interface

R

Simplified representation Detailed representation

Execution Environment

Operating Environment

Reconfigurat ion Port

Funct ional Ports

Figure 38: Platform Sub-system implementation with Logical Device

In the depicted example, the radio subsystem implementation is providing two functional interfaces and one reconfiguration interface towards the reconfiguration infrastructure. The detailed representation on the right hand side of Figure 38 is introducing a software module, the logical device, which is supporting the two functional interfaces and the reconfiguration interface. Two applicative components of an user applicative software are depicted, as well as the reconfiguration infrastructure, assumed to run in a remote execution environment. On the simplified representation, the logical device is not represented, the complete radio subsystem being abstracted as a separate module. The ports connections are not specifically described, but the useful connections remain depicted, with both the reconfiguration infrastructure and the applicative components. Only the execution environment (excluding the functional environment) is represented, using the simple border representation. The presented case is the most common case, where a single logical device is implementing all the useful connections towards the radio subsystem.

FP7-Security EULER


4.5.5.2 Façades All the interfaces attached to a given radio subsystem are not exposed into a unique execution environment. Several software parts of the subsystem implementation are thus available, one in each concerned execution environment, in order to present the necessary interfaces. The one among those software parts which is implementing the reconfiguration interface remains denoted the logical device part of the subsystem implementation. The other ones are denoted as façades. Figure 39 is illustrating such a case.

X W avefor m E xterna l In t erfaces

Lo gica l D ev ice

Su b-sy ste m C ore

R

Platfor m Su b-s ystem Im plem entat io n

R X

XX

X

Recon fig urat io n Int er fa ce

R

Sim p lified rep resen ta tion D eta iled represen ta tion

X

X

XX

Fa çade

Figure 39: Radio subsystem with façade

As depicted in the detailed representation, the logical device is executing in the bottom execution environment in a similar fashion as in previous case. Additionally, two other functional interfaces are implemented in the execution environment hosting the reconfiguration infrastructure. The corresponding software module is denoted a Façade. The logical device can be seen as a special case of a façade, which implements the reconfiguration interface. The simplified representation is abstracting away those considerations simply depicting the functional interactions and the reconfiguration interface.

4.5.6 Digital transceiver chain The generic platform and waveform constituents are given in Figure 40.


Specific SW WF Meta DataFunctional Application

Φ Φ

Executive Environment Sub-systeme.g. Radio Domain Device


Specific SW WF Meta DataFunctional Application

Φ Φ

Executive Environment Sub-systeme.g. Radio Domain Device

FP7-Security EULER


Figure 40: Generic SDR constituents

The transceiver in Figure 40 is given in more detail in Figure 41. As shown, the digital functionality of the transceiver is laid down in a combination of FPGA and DSP. The digital functionality constitutes of fixed (or native) functionality, which is used to connect to the hardware bus and to operate in conjunction with the “board support package” and the “radio domain interface service” (connectivity mechanisms) which can make the transceiver accessible via CORBA. Second part of the digital functionality is the flexible part that is loaded by the core framework as DSP software or as FPGA configuration file. Specific functions might also be implemented as ASICs. ASICs might be available from the consumer market (for example GSM, GPS, UMTS, ….). However, these ASIC solutions will be bound to specific bands, jeopardizing full band coverage.

Figure 41: Elements in transceiver architecture

Various options exist for red-black separation. The transceiver might be used to place the black red separation. Here a separation can be realized that does not need to be crossed by the CORBA software bus. The transceiver has multiple tuners. On the right end of Figure 41 the analog part is connected to the antenna, on the left hand part, the digital parts of the tuners are part off the digital functionality. The tuners can be equal or unequal. Equal tuners might be used for example in electronically steered antennas (phased array antennas). Unequal tuners might be supportive for platforms that support both wideband surveillance (for example for CR) and narrowband links. The transceiver will have more than one tuner. The architecture of the tuners depicted in Figure 41 is given in Figure 42. It shows a receiver chain having:

• Low noise filter-amplifier • a mixer and IF filter-amplifier • analog to digital conversion • digital down conversion, providing also digital filtering and propagation time compensation • decimation and preprocessing, providing also compensation for analog receiver artefacts.

The transmitter chain is of the same architecture, in opposite order:

• preprocessing and up-sampling, providing also compensation for power amplifier non linearities

• digital up conversion, providing also digital filtering and propagation time compensation • digital to analog conversion

FlexibleFunctionality

ReconfigurableFPGA & DSP

Fixed/NativeFunctionality

Tuner 1

Tuner 2

Tuner NASIC

Front-ends

Radio Security

Cf Figure 24

FlexibleFunctionality

ReconfigurableFPGA & DSP

Fixed/NativeFunctionality

Tuner 1

Tuner 2

Tuner NASIC

Front-ends

Radio Security

Cf Figure 24

FP7-Security EULER


• Analog up-conversion and filtering • RF Power amplifier

For more demanding waveforms (more demanding in transceiver specifications) feedback and calibration might be applied. In this case Figure 42 shows only a receiver channel, the transmission channel being used for calibration. Or in opposite direction, it shows only a transmission channel, the receiver channel being used for calibration or feedback loop.

Figure 42: Tuner architecture

More demanding transceiver specifications, like a high degree of analog filtering, protection of receiver input, low inter-modulation products might require specific adaptations to the receiver to allow for better filtering performance, as is given in Figure 43 as an example.

Figure 43: Double super tuner

Cognitive radio in its smallest sense is the sensing of the spectrum and the selection of a frequency and modulation that best suits the user. So spectrum sensing is a basis for cognitive radio. In its broadest sense “cognitive” relates to “cognition” this means the system knows (or even can learn) what is going on and might give priority to important communication. For the near future especially the spectrum sensing aspects of CR are important. It can be divided in several sub-aspects, as is shown in Figure 44:

• Transmitter detection (non-cooperative): Used and unused bands should be distinguished by the cognitive radio. In order to achieve this, the radio has to determine if a signal from a primary transmitter is present in a certain band. Three schemes are generally used for the transmitter detection:

o Matched filter detection o Energy detection approach o Cyclostationary feature detection

• Co-operative detection: The most efficient way to detect spectrum holes is to detect the primary users that are receiving data within the communication range of a CR user.

• Interference based detection: This is even one step beyond co-operative detection. Only if mutual use of the frequency causes interference use of the frequency should be avoided. This in essence already requires learning.

Decimation & Preprocessing

Upsampling & Preprocessing

DUC DAC

DDC ADC

X

~

XDecimation & Preprocessing

Upsampling & Preprocessing

DUC DAC

DDC ADC

X

~

X

Decimation & Preprocessing

DDC ADC

~

X

~

XDecimation & Preprocessing

DDC ADC

~

X

~

X

FP7-Security EULER


Spectrum Sensing

Transmitter Detection Cooperative Detection Interference Based

Detection

Matched FilterDetection

EnergyDetection

CyclostationaryFeature Detection

Figure 44: Spectrum sensing options

For proper operation of multiple waveforms simultaneously, including the waveforms for spectrum sensing, it is necessary that the various platform RF channels are robust against mutual influences. The receivers need to be robust against own platform transmissions. Suppression / desensitization can take place in the frequency (filtering) as well in the time domain (receiver blanking). Proper information to accomplish this should be exchanged over the WF-WF interface. This will result in the following requirements for ESRA:

EULER_REQ 8: ESRA Will allow for concurrent use of multiple waveforms, and provide proper mechanisms in the WF-WF interface to support it.

4.5.7 Transceiver Components

4.5.7.1 Component-Based Development (CBD) Target capabilities like the radio domain device can enhance the usage of component-based design. From the developments observed from the defense, public safety and commercial sectors, solutions tailored for a high variety of families of processing units are in process of being available. The most constrained environments from the SWAP (Size Weight And Power) viewpoint are in particular the radio interfaces and their related RF hardware. Specific topics are the reconfigurable analog front-end technology. Flexibility for various waveforms can be achieved by moving functionality from the analog to the digital domain. This will in general increase the power consumption while decreasing the size and weight. This paradigm is already well understood from the commercial communication community. ETSI standardization effort is already preparing standards and associated processing architectures for the most demanding classes of radio sets, like commercial handset terminals. The current SDR solutions are proposing a limited coverage in terms of processing environments. Especially in radio domain devices the need for DSP and FPGA component models is high. These processing elements can provide the necessary processing power to fuel digital front-end processing. A large number of initiatives and research efforts are targeting a near term industrially supported solutions executed on DSP or PLA. The market for future “handsets” will most certainly fuel this development.

4.5.7.2 CORBA The Common Object Request Broker Architecture (CORBA) specification is aiming to distributed communications and is a major interface to connect application components. The CORBA reference model provides interfaces that are conceptually linked by an Object Request Broker (ORB). The ORB is positioned in the context of the component execution environment, as shown in Figure 45, which also indicates real-time & ETF capabilities:

FP7-Security EULER


Figure 45: Component Model communications with CORBA layer

The purpose of an Interface Description Language (IDL) is to allow object interfaces to be defined in a manner that is independent of any particular programming language. This arrangement allows applications implemented in different programming languages to interoperate as part of the same logical application. This independence or language transparency is crucial to the OMG CORBA goal of supporting heterogeneous systems and the integration of separately developed functional units that can be combined in an interface-centric paradigm. This will result in the following requirements for ESRA:

EULER_REQ 9: ESRA will support CORBA, for interoperability

4.5.7.3 GPP and DSP Component Models GPP and DSP Component Models are addressing “classical” software programmable Execution Units. GPP is standing for General Purpose Processor; DSP is standing for Digital Signal Processor. They differ in the associated software programming features, and especially the underlying technical services. Digital Signal Processors, in contrast to General Purpose Processors, are specialized to perform mathematical operations on continuous signals. A constraint for the DSP Component Models is the fact, that a DSP typically has limited resources (especially random access memory and computational performance) available for other tasks. Critical elements for design of radio domain devices are Real-Time and Embedded (RTE) constraints, which are playing a key role in the engineering process. As far as Real-Time constraints are concerned, the constraints are increasing for radio domain technical services. Also, new waveforms are taking advantage of the increased processing power in order to provide higher data rates, increasing the degree of real-time constraints imposed to the processing chain. The main driver for SWAP constraints is the form factor of the target Radio Set. The smaller is the Radio Set, the more importance Size and Weight constraints are. Battery-powered Radio Sets are affecting the SWAP constraints by a supplementary order of magnitude due to the need for Power Supplies, and the need to maximize the battery life of the Set.

RTOS (OSEck)

ORB (C)

RTOS (VxWorks)

ORB (C++) ETF plug-in ETF plug-in

data

Waveform application

FP7-Security EULER


Strictly inferring from the names only Component Models for the associated processors types should be addressed. Such differentiation, if meaningful in general tendencies, is not applicable from a strict technical viewpoint, since what counts to differentiate the models are the associated software programming features, and especially the underlying technical services. The retained differentiation between the so-called “GPP” and “DSP” Component Models is thus not the execution units, but the technical services on top of which the Component Models are relying. Here, “GPP Component Models” are addressing existing standardized component models for SDR execution support, while “DSP Component Models” are addressing emerging Component Models for RTE (Real-Time and Embedded) constrained environments, where GPP Component Models are not applicable. The main difference turns out to be the capability for the execution unit to run an ORB compliant with the CORBA profiles attached to existing standardized component models (typically minimumCORBA):

• If the Execution Environment supports minimumCORBA, the Component Model is considered to belong to the Architecture Area “GPP Component Model”,

• If the Execution Environment is not supporting MinimumCORBA, it is considered as belonging to the Architecture Area “DSP Component Models”. This includes the specific CORBA profiles defined for RTE-constrained environments.

This will result in the following requirements for ESRA:

EULER_REQ 10: ESRA will support the use of DSP to meet stringent processing requirements

4.5.7.4 FPGA Component Models FPGA Component Models are addressing the programmable logic Execution Units (FPGAs). FPGA based approach is used in EULER due to their ease of adaptation of RT constraints. The missing standards and tools have led to a widely use of dedicated solutions. The confusion should not be made between the “FPGA Execution Unit”, which are the programmable matrix of reconfigurable logic subject to Component Models definitions, and the “FPGA chips”, which can put in a same package a system-on-chip offering one classical processor core (e.g. an ARM) coupled to an FPGA Execution Unit. A Field-Programmable Gate Array (FPGA) is a semiconductor device containing programmable logic elements called "logic blocks". These can be programmed to perform basic logical functions that can be arranged by the use of so-called programmable interconnects into a hierarchy to provide the required device functionality. FPGA devices are usually slower and less sophisticated than their Application Specific Integrated Circuit (ASIC) counterparts, however the FPGA can be manufactured with a shorter time to market and can be re-programmed in the field - hence the description “field-programmable”. The FPGA therefore represents a COTS device that affords the versatility appropriate in SDR in support of re-configurable radio functionality. Figure 46 illustrates the role of the FPGA in a typical SDR configuration where high-speed data processing is required at the digital/analogue interface:

FP7-Security EULER


Figure 46: Typical high data rate SDR platform architecture with FPGA

Currently, the requirement for a “software defined” capability with potential for re-configurability limits the choice of hardware to FPGA devices. The requirements for portability, interoperability and reconfigurability in SDR, has led to the consideration of a unified component model applicable to all SDR devices including FPGA. The main difficulties encountered in defining a unified component model arise due to the conceptual gap and heterogeneity that exist in hardware/software models of interaction, programming, computation and execution, languages of specification and implementation, and the environments for simulation and execution. Hardware description languages (HDL) used in the FPGA development tool-chain imposes an inherent tradeoff between size and performance (bandwidth, latency) in addition to the power consumption required by hardware modules. FPGA IP core interfaces are explicitly defined as hardware wires and IP functionality is requested via an application/user-defined protocol. Moreover, hardware processing can be achieved on-the-fly using pipelining. Due to memory limitations in FPGAs, the data granularity is less course grained as in software - a bit vector is used instead of an array of words, requiring control flow to occur during hardware/software communications. In contrast with developments in the software domain, no component model actually exists for direct application to FPGA. The main reason for this is that hardware modules are very often seen as slave processing accelerators which are static in nature, controlled by high level services managed in software. Consequently, the architectural items presented here in the main should be considered as building blocks that can be used to realize FPGA component model-like functionality. A common and unified component model that encompasses FPGA should certainly be based on the common elements existing between available software component PIMs and provide a common programming model and design rules applying to every FPGA component describing how the definition of abstract functional interfaces can be mapped onto component concrete interfaces. The WINTSEC Architecture Items characterize the FPGA domain as very unique with regards to the SDR as a whole; the integration of its systems is a confluence of a number of typically challenging aspects of software and hardware development, and as such it appears on the periphery of component model technology which exists exclusively in the software domain. However, these items describe the necessary building blocks that are essential in aligning the FPGA with the consistent set of integration capabilities to support key SDR principles. This concerns design methodology, with FPGA Design Flow and Programming Paradigm, distribution, with Commercial CORBA-based

FP7-Security EULER


Middleware in FPGA, connectivity, with Distributed Object Model Hardware Implementations, HAL-based Approaches and SCA Communication API for FPGA, abstraction, with Technical Services Hardware Implementations, standards, with Non-proprietary Hardware Interface and dynamism, with Partial Reconfiguration.

4.5.7.4.1 Dynamic Partial Reconfiguration Partial Reconfiguration capability is generally attributed to Xilinx devices. These provide the ability to reconfigure a portion of an FPGA while the remainder of the design is still operational. Certain areas of a device can be reconfigured while other areas remain operational and unaffected by reprogramming when the device is active. Partial reconfiguration is an essential step in providing dynamic resource allocation on FPGA devices. However, the additional requirements of establishing connectivity synchronization between newly loaded resources and the messaging infrastructure need still to be addressed. The reconfigurability of radio systems has received significant attention in recent times. The general hypothesis is that a radio system can reconfigure itself automatically in response to some external stimulus as for example that would be required given a required change in transmission protocol. The challenge in the case of FPGA is to provide similar component lifecycle support using a device that is static in nature and where a restart involving a power down/up cycle procedure is not possible.. Using a static approach, all components that may to be required can all be hosted by the device when it is programmed and these can be utilized at any time using a multiplexer to switch between them. Clearly this approach has many disadvantages in respect of the expense associated with providing a high level of redundancy. In the dynamic case, the premise is that the system can continue to operate while changes affecting only some components deployed to the FPGA can be made. The underlying mechanism required to support this is referred to as dynamic reconfiguration and is currently only achievable using a specific family of FPGA, but worthy of special note here due to the potential significance and benefits of such a capability. The concept of dynamic partial reconfiguration (DPR) consists in having several independent parts of the design which are not required to be used at the same time during the run time operation of the application (in other words, they are not used in parallel) and having them time share the same physical resources. In Figure 47, module A and B are not used in parallel:

Module AModule B

Module C

Run time operation

Figure 47: parallel execution of modules

When two or more parts of the design are not used in parallel, we consider that they do not need to be physically present in the system at the same time. They are the reconfigurable parts of the design. Modules that need to be physically present in the system all along the application run time are the fixed parts of the design. Requirements for reconfiguration are discussed in paragraph 4.5.7.7. This will result in the following requirements for ESRA:

EULER_REQ 11: ESRA will support the use of FPGA to meet stringent processing

requirements

FP7-Security EULER


4.5.7.4.2 High bandwidth waveforms requiring FPGA usage High bandwidth waveforms may require usage of FPGA processing units. The physical layer needed for high bandwidth waveforms is subdivided in between platform support (typically a Transceiver Sub-system plus a Power Amplifier) and waveform functional application. A Time Machine sub-system is as well present. The high datarate waveform might be composed of waveform function blocks which may be implemented in DSP or FPGA. A given functional module can be entirely implemented either as a single FPGA component or as a single DSP component. Figure 48 is depicting a typical Functional Decomposition for a high bandwidth Physical Layer.

PA

PHY

Modem

ChannelCoding

Modulation Tx SSP

ChannelDecoding

Demodulation Rx SSP

Synchro

PHY M&C

Ti me Machine

X

Transceiver

X

X

Data path

MAC

(Not exhaustive representation)

Control path

Figure 48: Functional waveform decomposition

In the case of lower bandwidth waveforms, the entire modem can enter into a single processing unit which does not impose to perform any sub-decomposition of the Modem functionality.

4.5.7.5 Multi-cores processors Multi-core processors can contribute to the implication of radio functionality in the digital domain. They should not be a major issue to deal with since from the inception the ESRA approach is considering the Waveform Applications as software applications distributed over an heterogeneous set of processing units. Taking into account the high level of constraints imposed to such processors, definition of solutions without a mandate to use CORBA will be a prerequisite for such achievements. The work currently conducted within ETSI RRS Working Group 2 (Reconfigurable Radio Equipment Architecture) is seen as a key source of information on these matters. This will result in the following requirements for ESRA:

EULER_REQ 12: ESRA will support the use of multi-core processing

4.5.7.6 Real-Time Engineering Time management at implementation level is of high importance in SDR. Possibility for the transceiver facility to be implemented as a general purpose radio subsystem is still not covered and within EULER dedicated solutions are used. However platform openness and waveform application portability would be greatly enhanced by proper time management.

FP7-Security EULER


The transceiver facility interacts with other components of Waveform Functional Application using a set of pre-defined Reference Functional interaction patterns. Examples are:

• Procedural, • Asynchronous, • Synchronous, • Balking, • Time Out.

The Functional dimension of such patterns requires accurate real-time behavior. This capability to enter accurate real-time design capabilities will increase the value of future waveform engineering activities. Real-time Engineering Constraints are imposed to the connection mechanisms established between the Waveform Functional Modules and the radio domain device. Examples are:

• Max Transmission Latency, • Max Activation Time, • Minimum Inter-Activation Time, • Minimum Inter-Invocation Time.

Modeling of real-time aspects is difficult to perform. Significant efforts in this area are performed, taking into account the specific aspects of the SDR domain. One essential identified aspect of SDR which limits complexity is the relatively simple real-time engineering of waveform capabilities. By real-time engineering is meant the analysis to be conducted in order to check that a given waveform operates in correct mode. This often means that the derived real-time requirements are stringent to meet. Time management at implementation level is a topic of high importance. Unfortunately, until now, a possibility for this capability to be implemented as a general purpose radio subsystem is not achieved. Its advantage would be significant in terms of platform openness and waveform application portability. It is recognized that time management require its own interfaces. Time management is essential for control in receive and transmit channels. The SDR forum transceiver facility describes two time domain types, absolute time and event-based time. To enable use of stringent timing, the use of the SDR Forum transceiver facility time machine is proposed. To date however, the time machine is still in its infancy. The need for timing, the phenomenology attached to it and the universal approach of the time machine still justifies its recommendation. This will result in the following requirements for ESRA:

EULER_REQ 13: ESRA will conform to the SDR forum time machine

4.5.7.7 Reconfiguration The WINTSEC Architecture Area “Decision Making” corresponds to the entire functionalities managing the SDR Configuration States applied on the SDR Equipment as time elapses. This implies defining the corresponding states, then triggering the reconfiguration process between two successive Configuration States. It is assumed that the Decision Making part of a SDR Set is triggering Reconfiguration Infrastructure so as to implement a certain Configuration State. Depending on the Radio Sets, the strategies governing Decision Making can vary to an extreme extent, from direct user commands to complex collaborative decisions between the Set and remote agents of the Radio System it belongs to. An important research area that is directly related to Decision Making is Cognitive Radio research. It is assumed that the Decision Making part of a SDR Set is triggering Reconfiguration Infrastructure so as to implement a certain Configuration State. Decision Making is introduced to stress the boundaries of

FP7-Security EULER


Reconfiguration Infrastructure. It is for the time being an Architecture Area which study has not been developed.

Reconfiguration Infrastructures

The Architecture Area “Reconfiguration Infrastructures” is dealing with solutions and approaches to determine the Reconfiguration Infrastructure of a given SDR Set Architecture. The Reconfiguration Infrastructure par of a SDR Set Architecture, as previously introduced, can be summarized as the part of the SDR Set platform that undertakes the management of the reconfiguration process which is turning the Radio Set from one Configuration State to another. A Reconfiguration Infrastructure is implementing the reconfiguration through a mix of Re-programming and Parameters Setting operations. The Reconfiguration Infrastructure depicts a run-time management software which illustrates how the Waveform Reconfigurability in SDR Set should be realized. It enables to modify the SDR Configuration State i.e. how to modify the Waveform Capability (or capabilities) executing on a given SDR Set. The SDR Set runs Waveform Application that can be thought of as a collection of software distributed over different processing devices. This waveform application is driven on different Execution Environments which are connected to Radio Platform Sub-systems to achieve some signal processing, see Figure 49. Role of the Reconfiguration Infrastructure is to define and realize the deployment and configuration of the Waveform Application and Platform Support consisting in a deployment and configuration Meta-Data.

Functional Application

Execution Environments

Dep

loym

ent

FunctionalComponent 1


FunctionalComponent n

Reconfiguration Infrastructure

Meta-Data

Meta Descriptor

Meta Descriptor

Configuration

Parsering

Platform Subsystems

Meta Descriptor


Connections


Platform Support

Figure 49: Overview of Reconfiguration Infrastructure role

This includes ensuring that Functional Components of waveform Functional Application are driven on proper Execution Units; the Radio Platform Sub-systems are properly connected and all implementation artifacts of the Platform Support are well configured with appropriate configuration values. It specifies the functionality related to SDR Waveform Reconfigurability i.e. like how to load and activate Functional Application and how the Waveform Application and Platform Support should operate together within a Software Defined Radio. The Reconfiguration Infrastructures defines the essential, core set of software Interfaces to provide an abstraction of the underlying software and hardware layers. Typically it involves Meta Descriptors of Waveform Implementation and the computational effort needed for their execution as well as (Radio) Platform Meta-Descriptors including deployment and configuration of Execution Units offered by SDR Platform. Also a mechanism using these descriptors to deploy waveform Functional

FP7-Security EULER


Components on proper Execution Units is defined. These descriptors compose so called Meta-Data profiles for Waveform Application and Platform Support, which describe the identity, capabilities, properties, inter-dependencies and location of the hardware devices, and software components that determine the system deployment and configuration. Meta-Data profiles can also specify the connections to other software components ((Radio) Platform Services and (Radio) Logical Devices). In practice the Meta-Data profiles are a set of files that describe:

• Hardware devices and software components of the system, • Component properties, • How the components are interconnected.

These Meta-Data profiles are used to build its internal information base of HW devices, SW components and application assemblies. The Meta-Data profile can also contain descriptions of applications, interfaces, the start-up requirements of devices, functional capabilities and other pertinent parameters. Reconfiguration Infrastructures is addressing the following subjects:

• Mechanisms to deploy and tear down Waveform Implementations, • Mechanisms to handle reconfiguration of the elementary execution modules participating to

the Waveform Implementation, in particular the installation of the software components participating to the Waveform Applications,

• Meta-data describing the various configurations, including waveform application description and platform configuration information.

For radio interfaces the last two bullets are relevant. From transceiver perspective, this will lead to the following requirement:

EULER_REQ 14: ESRA will support the use of FPGA hot reconfiguration.

4.5.8 Radio Domain Devices & Services Radio Domain Devices & Services is an Intermediate Architecture Area, that is grouping together two following Leaf Architecture Areas:

• Radio Domain Devices, • Radio Domain Services, • Radio Security.

These Architecture Areas are constitutive of the Functional Support provided by a SDR Platform. Renaming the Intermediate Architecture Area towards Functional Support is under consideration. The Architecture Area “Radio Domain Devices” is addressing the Radio Platform Sub-systems. To support reconfigurability in the core of RTE constrained software implementations such as the physical layers, the specification and standardization of relevant radio platform sub-systems is acknowledged to be a necessity, although it remains a largely uncovered subject, even if studies results have paved the way with interesting results. The architecture area Radio Domain Services is covering the Radio Domain Services. The architecture area Radio Security is specifically addressing the Radio Platform Sub-system or Radio Platform Service providing security-related capabilities (e.g. a flexible INFOSEC module or a biometric authentication device).

4.5.9 Architecture Evaluation and Certification Evaluation and certification of Software Defined Radios recently has been treated by the Wireless Innovation Forum (WInnF) [32] and by a study contracted by the European Defence Agency [33].

FP7-Security EULER


4.5.9.1 Why certification? One might wish to certify properties of a technical product to give evidence to a customer or user, that a certain specification is met. There can be just a matter to show the quality of the product or the user needs the specified properties for an operation or system interfacing aspects. The producer on the other hand might want an independent party to confirm, that a specification is understood in the right way and correctly implemented. In any case a precondition for certification is to have a specification or standard to certify against. The certificate, which is issued after successful evaluation by a conformity assessment body, is an official document showing compliance with the specification or standard.

4.5.9.2 Important terms Within this chapter terms are used, which often are not well specified and might be used in different meanings by different people.

Table 10: Certification terms and definitions

Term Definition Accreditation Third-party attestation related to a conformity assessment body

conveying formal demonstration of its competence to carry out specific conformity assessment tasks (ISO/IEC 17000: 2005)

Accreditation Body Authoritative body that performs accreditation (ISO/IEC 17000: 2005)

Certificate Document stating the successful performance of the Conformity Assessment

Certification Third-party attestation related to products, processes, systems or persons (ISO/IEC 17000: 2005)

Certification Body National body or body related to international organizations, formally issues the Certification after receiving the evaluation results (Test Report)

Certification Criteria Certification Criteria are derived from the standard and represent the specified requirements, which shall be verified during the tests

Conformity Assessment Demonstration that specified requirements relating to a product, process, system, person or body are fulfilled. Conformity assessment is a series of three functions that satisfy a need or demand for demonstration that specified requirements are fulfilled: selection; determination; and review and attestation Conformity assessment activities can be characterized as “firstparty”,“second-party” or “third-party”. (ISO/IEC 17000: 2005)

Conformity Assessment Body

Body that performs conformity assessment services (ISO/IEC 17000: 2005)

Contributor Entity designing specifications in response to operational requirements. A Contributor can be an individual private company or a public administration, or a closed group of companies or administrations.

Definition Body Body to define the Certification Criteria Data Base and to perform the validation of tools and procedures

Device under Test Device that is undergoing the evaluation by the Test Lab (e.g. radio platform, waveform, complete radio or software component

First Party Conformity Assessment Activity

Conformity assessment activity that is performed by the person or organization that provides the object (ISO/IEC 17000: 2005)

FP7-Security EULER


Inspection

Examination of a product design, product, process or installation and determination of its conformity with specific requirements or, on the basis of professional judgment, with general requirements (ISO/IEC 17000: 2005)

Mandating Body (MB) Organisation mandating a Specification Body to deliver Technical Specifications fulfilling provided Operational Requirements

Procedure Specified way to carry out an activity or a process (ISO/IEC 17000: 2005)

Product Manufacturer Legal entity taking responsibility for a product applying to certification. It may be the industrial manufacturer itself or its authorised representative.

Self Assessment Term used as a synonym for First Party Conformity Assessment Activity as defined by ISO/IEC 17000: 2005

Specification Body

Open, usually non-for-profit organisation of Industry Experts and Market Stakeholders, called “Contributors”, which is generating Technical Specifications by hosting the technical convergence between the contributions using open and transparent processes

Specified Requirement Need or expectation that is stated NOTE: Specified requirements may be stated in normative documents such as regulations, standards and technical specifications. (ISO/IEC 17000: 2005)

Standard Specification, which is under the configuration control of an recognized Standards Developing Organization

Standards Body Body to define and maintain a standard Test Case The specific implementation of a Method of Test on a Means of Test. Test Definition Body Body defining the Profiles and Certification Criteria associated to a

given specification. Test Developer Entity to develop test procedures and test tools, used by the test labs

to perform, assessment of Certification Criteria Test Lab Term used as a synonym for Conformity Assessment Body as defined

by ISO/IEC 17000: 2005 Test Report Report of the results of a test according to the test procedure Test Report Form Form of the test report Test Tool Tool, used to perform certification assessment of some or all the

certification criteria Testing Determination of one or more characteristics of an object of

conformity assessment, according to a procedure (ISO/IEC 17000: 2005)

Third-party conformity assessment activity

Conformity assessment activity that is performed by a person or body that is independent of the person or organization that provides the object and of user interests in that object (ISO/IEC 17000: 2005)

Validation To declare that a document or tool is according the requirements

4.5.9.3 What to certify The final decision what to certify has to be carefully elaborated considering

• the purpose of the certificate • additional cost • additional time-to-market • intellectual property rights

In other words: Certification costs money, time to market and may have issues with proprietary information within the radio. Certification of parts of an SDR architecture makes sense, if an interface

FP7-Security EULER


or property is concerned shared by different development parties. The most prominent example for this is porting of a waveform from one platform to another. Also when separating a transceiver unit from the platform (digital baseband unit) a standardized interface (e.g. digital IF) comes into play. Possible “Objects to be Standardised or Certified” within a SDR are depicted in Erreur ! Source du renvoi introuvable. from 0. The topics and nomenclature are related to the SCA because of the high international relevance of this specification. It can be easily transformed to ESRA or other architectures.

Table 11: Objects to be standardized/certified

WF PTF WF PTF

POSIX AEPs n/a x x x

Connectivity (ORB,

MHAL) n/a x x x

Basic PTF Services n/a x x x

Core Framework n/a x x x

x

Radio Services n/a x x x

Radio Devices n/a x x x

Radio Security

Services n/a x x x

Execution capabilities n/a n/a Evaluation Evaluation

Over-the-air

interoperability x n/a x n/a

Red/Black separation n/a x n/a x

Tempest n/a x n/a x

Multichannel operation n/a x n/a x

Distribution of Crypto

Material n/a x n/a x

Operating Environment

Standardisation CertificationObjects to be Standardised/Certified

APIs

PTF Performance

WF interoperability

PTF Physical Security

The selection what to certify has to be done carefully. In practice a likely choice for certification is the area of the operating environment and the APIs. Over-the-air interoperability and security topics are very important but are probably treated separately.

4.5.9.4 The standardization/certification process and the players 0 The process of standardization and certification can be broken down into

• standardization phase • certification preparation phase • certification execution phase

Standardization Phase

FP7-Security EULER


Opt

Opt

Mandating Body (MB) Specification Body (SpB)

Test Defin ition Body (TDB)

Requ irementsSpecification

Convergence

Validation

mandates

OperationalRequirements

notifies

Profiling

Test Case Specification+Test Suites

Test Procedure

Product Manufactu rer (PM)

ProductDevelopment

submits for CertificationExecutiondelivers TP

delivers TC, TS

InternalVerification

Standardisation Body (StdB)

delivers Tech Spec

Adoption

SpB delivers Tech Spec or StdB delivers Standard

notifies, tracing to Standard / Tech Spec

Contributors

Designs

contributes

Figure 50: Standardization phase

Target of the Standardization phase is to create a standard, the product under evaluation can be evaluated against. Certification Preparation Phase

FP7-Security EULER


Test Definition Body (TDB)

Test Equipment Manufacturer (TEM)

loop

Conformity Assessment Body (CAB)

Develops

delivers TC, TS

Accreditation Body (AB)

delivers Test Tools

AcceptanceTest Tools

Verifies

see Certification Execution activity diagram

accredits

accepts

see ESSaC Task 2 Report

feedbacks

see Standardisation activity diagram delivers Test Procedures

Developsinternal procedures

Figure 51: Certification preparation phase

During the certification preparation phase all the non-recurring work is done like development of test procedures, development of test tools, accreditation of test labs (0 Conformity Assessment Body). Certification Execution Phase

FP7-Security EULER


alt

loop

Product Manufacturer (PM)

Conformity Assessment Body (CAB)

submits Product+Doc

CertificationBody (CB)

see Standardisation activity diagram

[self-assessment]

[else: assessment by CAB]

self-assessment

submits CA report

grants Certificate

submits CA report

grants Certificate

conformityassessment

reports failure

Figure 52: Certification execution phase

During the certification execution phase the evaluation and subsequent issuing of the certificate is happening. Evaluation could be done by the Conformity Assessment Body, but also in terms of a self-assessment at industry. The self-assessment can be supported by means of audits and witness by persons, authorized by the Certification Body. The Certification Body will issue the certificate after successful evaluation.

4.5.9.5 A Concrete Example In the following an example for certification is given, based on a selected scenario. It is a proposal, how the steps towards a certification could look like. This proposal could be the basis for application on various certifications including possible future ESRA certifications. Scenario:

A radio manufacturer residing in a certain country does have a development contract for a radio platform from this country, including among others the requirement for certification of waveform/platform APIs including the relevant published JTRS APIs. A certificate has to be presented to the customer.

FP7-Security EULER


Since the API specifications are not complete the standardization phase has to be executed. Contributions to the forthcoming standard are provided. JPEO is one contributor, another contributor could be the mentioned radio manufacturer. The contributions will be completed and harmonized by the specification body, e.g. the Wireless Innovation Forum (WINNF). As soon as the API specification is complete and approved by the specification body, a formal standardization process will follow e.g. at the WINNF, at ETSI or IEEE. The WINNF then could act also as the Test Definition Body in order to do profiling, test case specification and development of test procedures. In case of the APIs these tests could include verification of the API signature and functional behaviors described for each API (e.g. state transitions, sequence diagrams, return values). After the creation of the standard or specification the Certification Preparation Phase can be entered. The Test Definition Body (e.g. WINNF) has the important task to decide, which parts of the standard shall be tested and what the certification criteria are. The Test Equipment Manufacturer can develop the test tools based on previously defined certification criteria, test cases and test specifications. The Test Equipment Manufacturer can be a specialized company for test tool development or alternatively, a government organization with sufficient knowledge and experience. In parallel to this the Conformity Assessment Body is being accredited by the Accreditation Body. In case of a self assessment of the equipment manufacturer the respective test lab within the company is accredited by the procurement organization of the contracting government. Now everything is prepared for the execution of the certification. The manufacturer is the Conformity Assessment Body and is producing a test report. In case of a successful test (tests during self assessment can be witnessed) the Certification Body (in our example a governmental organisation) is issuing the certificate as a proof, that the radio platform under consideration is satisfying the API standard.

FP7-Security EULER


5 Conclusion As introduced above, the initial ambition of this deliverable was to evolve ESRA set of recommendations and guidelines in the light of EULER EWF design and implementation choices. If we look at Operating Environment and Waveform design, EULER has been focused on technical issues that appear to be slightly far away from ESRA high level considerations. As a consequence of being a first step of formalism, ESRA recommendations are sometimes too high-level concepts, and the link between a recommendation and a physical implementation is difficult to establish. That means that direct evolution of ESRA set of recommendations one by one into requirements is not feasible. This fact, together with previous statement that ESRA is not longer applicable, has shifted the scope of this deliverable to more practical issues. However, ESRA recommendations still represent a good analysis standpoint, and the objective the present document tried to address is the change from ESRA recommendations into ESRA requirements whenever it was feasible and made sense. Requirements are more specific and match better with an implementation level (by definition a requirement has to feature three main attributes: standalone specification which is easily understandable, easily verifiable and easily testable). Two kinds of requirements will have been considered within this document:

• Interface requirements, • Functional requirements.

Important remarks:

• As SDR concepts and implementations are subject to evolutions and in order to take full benefit of other on-going initiatives results, an objective was to conserve as a basis the SCA-compatibility.

• At least, and as requirements represent precise specifications, certification aspects have been also (to a limited extent) taken into account.

FP7-Security EULER


6 References 1 WINTSEC, D7.3 European Software Radio Architecture (ESRA): ESRA Framework Overview and Recommendations. Master Document. March 2009 2 WINTSEC, D7.3 European Software Radio Architecture (ESRA): ESRA Framework Overview and Recommendations. Attachment 1: ESRA Vision and Terms of Reference. March 2009 3 WINTSEC, D7.3 European Software Radio Architecture (ESRA): ESRA Framework Overview and Recommendations. Attachment 2: ESRA State-Of-The-Art analysis. March 2009 4 Joint Tactical Radio Systems (JTRS) Operational Requirements Document, Version 3.2.1, 28 August 2006 5 Joint Tactical Radio Systems (JTRS) Standards, Joint Program Executive Office (JPEO) JTRS Software Communications Architecture Specification, Version 2.2.2, 15 May 2006 6 Joint Tactical Radio Systems (JTRS) Standard JTRS Modem Hardware Abstraction Layer (MHAL) Application Program Interface (API), Version 7 Joint Tactical Radio Systems (JTRS) Standard MHAL on Chip Bus Application Program Interface (API), Version 8 JPEO JTRS Standards Standardization Plan, Version 1.9.1, 3 June 2009 9 JTRS JPEO Software Standards, Version 1.2, 23 May 2007 10 JTRS Network Enterprise Domain Test & Evaluation, Waveform Portability Guidelines, Version 1.2.1, 28 December 2009 11 Multicore Resource API (MRAPI) Specification, defined by The Multicore Association. Version 1.0 November 23, 2010 12 Multicore Communications API (MCAPI) Specification V2.015, defined by The Multicore Association. March 25, 2011 13 EULER D3.2 System Architecture 14 J Mitola, “The Software Radio”, IEEE National Telesystems Conference , 1992 - Digital Object Identifier 10.1109/NTC.1992.267870 15 J.H. Reed, B. D. Woerner, “Software Radio: A Modern Approach to Radio Engineering”, Prentice Hall, 2002 16 A. Kountouris, C. Moy, L. Rambaud, "Reconfigurability: A Key Property in Software Radio Systems", First Karlshruhe Workshop on Software Radios, Karlshruhe, Germany, 29-30 March 2000 17 C. Moy, M. Raulet, "High-Level Design for Ultra-Fast Software Defined Radio Prototyping on Multi-Processors Heterogeneous Platforms", Journal on Advances in Electronics and Telecommunications – Radio Communication Series: special issue on Recent Advances and Future Trends in Wireless Communications, Vol. 1, n° 1, pp. 67-85, April 2010 18 Delahaye J.P., Leray P., Moy C. and Palicot J., "Managing Dynamic Partial Reconfiguration on Heterogeneous SDR Platforms", SDR Forum Technical Conference’05, Anaheim (USA), November 2005 19 Xilinx tutorial presentation – “Introduction to Partial Reconfiguration Methodology”, 2010 20 Delorme J., Martin J., Nafkha A., Moy C., Clermidy F., Leray P., Palicot J., “A FPGA partial reconfiguration design approach for cognitive radio based on NoC architecture”, IEEE New Circuits and Systems Conference, NEWCAS, 22-25 June 2008, Montréal, Canada 21 Delorme J., Nafkha A., Leray P., Moy C., “New OPBHWICAP interface for real-time Partial reconfiguration of FPGA”, International Conference on ReConFigurable Computing and FPGAs, ReConFig'09, Cancun, Mexico, 9-11 Dec 2009 22 http:/Iwww.omg.org1docs/formal03-06-03.pdf 23 http://www.omg.org/docs/fomial99-0'7-35.pdf 24 orbos/07-01-99: Chapter 10 25 OMG Document orbos 98-05-13, May 19, 1998 26 OMG Document formal/00-11/01: Interoperable Naming Service Specification 27 Event OMG Document formal/01-03-01:Event Service 28 C. Lanzani, ‘Open Base Station Architecture:Can Standardization enable true innovation ?’, Radiocomp, http://www.radiocomp.com/Files/Billeder/OBSAI_CPRI_Tutorial_and_Primer_ver02.pdf 29 www.etsi.org/WebSite/document/Technologies/LEAFLETS/OpenRadioEquipmentInterface.pdf

FP7-Security EULER


30 CPRI Specification V4.2 (2010-09-29 ) http://www.cpri.info/downloads/CPRI_v_4_2_2010-09-29.pdf 31 WINNF, Specification of the IQ Baseband Interface’, Wireless Innovation Forum, Doc.-Nr.: SDRF-08-I-0014-V0.0.0, version 0.0.0, 29th Jan., 2009’ 32 SDR Forum, “Test and Certification Guide for SDRs based on SCA, Part 1: SCA“ – April 2009 - SDRF-08-P-0007-V1_0_0_SCA_Certification_Guide.pdf 33 ESSaC - European SDR Standardization and Certification feasibility study 09-ARM-002; 2010; European Defence Agency EDA

EULER 4 1 ESRA recommendations - v1Deliverable 4.1 – ESRA recommendations extensions and maturity...

Documents

Transcript of EULER 4 1 ESRA recommendations - v1Deliverable 4.1 – ESRA recommendations extensions and maturity...