2019 Conference Presentation Abstracts (where available):
Wednesday, 15 May  |   Thursday, 16 May

Wednesday, 15 May 2019

Wednesday, May 15 9:00 - 10:00
Welcome and Keynote

Wednesday, May 15 10:00 - 10:30
SDS Projects Overview

Wednesday, May 15 10:30 - 11:00
Networking and Refreshments

Wednesday, May 15 11:00 - 12:15
SDS Projects Deep Dive

Wednesday, May 15 12:15 - 13:30
Lunch and Product Exhibition

Wednesday, May 15 13:30 - 15:25
SDS and the SCA

Management of SCA-based Radio Systems with the PlatformManager Component

Shan Wang (National University of Defense Technology & University of Montreal, P.R. China); Fanglin Gu (National University of Defense Technology, P.R. China); Jian Wang(University of Calgary, P.R. China)

With the widespread application of software radio equipment, how to manage and operate such equipment flexibly and conveniently has become an interesting topic. In typical software radio devices based on SCA architecture, there are two types of components: waveform application components and device service components. The former requires high portability, while the latter allows it to be dependent on specific hardware platforms. We can use this feature to design the management implementation, and provide an agile and open external control channel as an agent through the PlatformManager service component. The approach is not defined explicitly in the SCA specification, but it has been proven to be effective in practice and can be implemented in various ways. Because of this, it provides a solution for all kinds of management requirements of host machines with different communication interfaces.

CERTIF: Conformance tests on software defined radio platforms

Olivier Kirsch (KEREVAL, France)

In order to facilitate interoperability and portability of software defined radio components, the conformance to SDR standards (including APIs and behavior specifications) is mandatory. Due to the huge number of requirements and to ensure reproducibility of the compliance assessment, a testing methodology has been developed and implemented into the bench CERTIF. Firstly this presentation will summarize briefly the test methodology applied to verify the conformance of a software radio platform to the SDR standards. In a second time we will show all kind of non conformance issues detected by the bench CERTIF on the basis of concrete examples and we will show the reproducibility of the test results. All these cases come from experience feedbacks on the bench. The presentation will be made by Olivier Kirsch, Test project Manager of KEREVAL. KEREVAL is a French testing Lab.

An Approach for solving Real-time and Synchronization Issues in heterogeneous Multi-Processor Software Defined Systems

Peter Troll (Rohde-Schwarz, Germany)

Real-time and synchronisation issues have been subject to deliberation - and a source of potential confusion - since the invention of computers and their application in technical systems. They also are core issues of Software Defined Systems (SDS) and Software Defined Radio (SDR). Distributed real-time systems require a precise measurement of time and time-exact execution of commands. Taking into consideration that waveform portability is one of the primary objectives of SDR, the use of universal, simple and easy to use concepts is paramount that allow the provision of waveform agnostic Application Programming Interfaces (API) by the host environment. These APIs allow designing waveform specific solutions employing the universal concepts they encapsulate. Due to further objectives like scalability and broad applicability in various fields, numerous standards have evolved over the years, that address real-time and synchronisation issues in the SDR-ecosystem, e.g. IEEE/OMG POSIX, SCA, the JTRS/JTNC standards and the WINNF specifications. They allow for diverse approaches to synchronisation and in some cases orthogonal solutions, e.g. "Absolute Time" vs. "Relative Time" within the WINNF Transceiver Facility PIM specification. In this contribution, we will sketch how through the systematic combination of well-established concepts from these standards a comprehensive - but nevertheless simple - strategy to support real-time and synchronisation issues in SDS is possible that is applicable both to SCA as well as to non-SCA host environments. To give an example that relates to practice, we will exemplify the application of the strategy to a common hardware architecture that includes a GPP, a DSP and an FPGA as processing elements and look into the specific real-time aspects of the different types of processing elements. The focus will lie on core challenge of how the radio system can enable an application to synchronise on the air interface. The central ideas the strategy is based on are: a) Consequent application of the "system-wide monotonic clock" concepts b) Utilisation of the real-time capabilities of FPGAs in combination with APIs that allow real-time capable implementations, like the JTRS MOCB API c) Provision of a "lean platform" that features a clear separation of functionality between the host environment and applications

 

A Comparative Study of Eight Transfer Mechanisms with FM3TR

Jin Lian (Hunan University, P.R. China); Qi Tang (NUDT, P.R. China); Li Zhou (National University of Defense Technology, P.R. China); Shan Wang (National University of Defense Technology & University of Montreal, P.R. China); Jun Xiong (National University of Defense Technology, P.R. China); Lin Wang (Hunan University, P.R. China); Jibo Wei (National University of Defense Technology, P.R. China)

Transfer mechanism is an indispensable constituent part of the operation environment in the SCA-based SDR system. It leverages standardized client-server innovations to the system that is composed of a set of different kinds of components. Client-server communications may be located in the same or different address spaces, making the client the server apparent to each other. Many different transfer mechanisms can be used in implementing the SCA system, including CORBA, RPC, RPC over DDS, IPC mechanisms, etc. However, different techniques render various overhead to the system constructed using the transfer mechanism. Thought some literature studies the performance of various techniques, these works either focus on one or two transfer mechanisms or has not consider the realistic waveform. For this reason, this paper conducts an in-depth analysis of the performance of eight different transfer mechanisms, i.e., ACE TAO, omniORB, RPCexpress, e*ORB, Orbit2, ICE, eProsima RPC over DDS and TCP/IP, by integrating them with the Future Multiband Multi waveform Modular Tactical Radio (FM3TR) waveform. Various performance metrics, including latency, predictability, static and dynamic memory consumption, and CPU load, are taken into account, thus providing a full profile for each transfer mechanism.

Wednesday, May 15 15:25 - 15:50
Networking and Refreshments

Wednesday, May 15 15:50 - 17:20
Networking Aspects of SDS

From laboratory to the field: An open source Software Defined Radio project coupled with native Linux driver framework

Xianjun Jiao (Ghent University - imec, IDLab, Belgium); Wei Liu (University Ghent - imec, Belgium); Muhammad Aslam (Ghent University - imec, IDLab, Belgium); Felipe Augusto Pereira de Figueiredo (Ghent University, Belgium); Ingrid Moerman (Ghent University - imec, Belgium); Filip Louagie (Ghent University - imec, IDLab, Belgium)

Software Defined Radio (SDR) concept has been applied to a wide range of activities including research and production. Recently, in the emerging area between research and large volume production, SDR gains importance. srsLTE (https://github.com/srsLTE) and Open Air Interface (http://www.openairinterface.org/) are two successful open source SDR projects, which offer open source software, ranging from physical layer (PHY) to core network in x86 Linux computers. Different from LTE SDR projects, WiFi SDR projects always need Field-Programmable Gate Array (FPGA) to implement PHY and low level Media Access Control (lower MAC) due to the Short Inter-Frame Space (SIFS) requirement. This renders pure software implementation impossible because of the large latency between the host computer and the Radio Frequency (RF) front-end. While in LTE systems the feedback is scheduled to happen 4 ms after a transmission, which can be handled by software implementations. National Instruments sells WiFi and LTE SDR application frameworks which require x86 computer together with USRP with a big volume FPGA containing PHY and lower MAC . Upper MAC and network layers run by the Network Simulator 3 (ns-3) in a Linux computer. Another Windows computer is needed to modify and run FPGA in USRP. Wireless Open Access Research Platform (WARP: https://www.warpproject.org) sells full stack WiFi SDR design based on FPGA. It doesn't need any x86 computer. However the soft processor core deployed in the FPGA runs in bare metal mode to execute the WiFi protocol, which means that rich Linux resources, such as libraries, network stacks and applications, are not part of this WiFi SDR design. On the other hand, WiFi network researchers, Linuxers, hackers and DIYers have created many active open ecosystems. Raspberry PI is the most popular single board ARM Linux computer with rich wireless peripherals. OpenWRT (https://openwrt.org/) is an open source WiFi router firmware ecosystem that enables researchers to test experimental software, such as Click Modular Router (https://github.com/kohler/click) software. Nexmon project (https://github.com/seemoo-lab/nexmon) offers a way to modify WiFi chip firmware on Raspberry PI and many Android phones through reverse engineering. In this paper, we propose an open source SDR project which is coupled with the native Linux driver framework, the same way commercial chips work with their Linux drivers. The project is expected to connect traditional SDR community and Linux community. Users will have full freedom to customize/configure all layers of the network stack, ranging from RF, PHY, and MAC to the Application layers. In the first phase, the focus is on WiFi standard. The project will offer full stack source code to the community. FPGA source code will include WiFi baseband TX and RX module, RF front-end control logic, lower MAC control logic and CPU interface logic (data and register ports). On the CPU side, Linux mac80211 framework compatible SDR driver source code will be delivered. An out-of-the-box ready image will also be offered for quick demonstrations on supported hardware platforms. After Linux boots up, the FPGA based SDR module will be recognized as a network interface, behaving like commercial WiFi cards. As the first step, off-the-shelf Xilinx Zynq board and FMCOMMS RF front-end will be used as proof of concept. In this Zynq System-on-Chip (SoC) platform, Linux and driver will run in ARM processor, so called Processing System (PS). Baseband logic will be in Programmable Logic (PL) part of the same chip. Main features delivered with the reference design will include: 802.11a/g (all MCS); 802.11n (20MHz bandwidth, MCS 0~7); Frequency range 70MHz~6GHz, which means it can operate in non standard WiFi frequencies; Supported modes: station mode (kernel space), AP mode (hostapd in user space), monitor mode, Ad-Hoc (IBSS) mode, Wireless Distribution System (WDS), Mesh. An initial internal proof of concept work has been finished recently in Horizon 2020 Orchestration and Reconfiguration Control Architecture (ORCA) project. Communication between SDR WiFi and commercial WiFi terminal in ad-hoc mode has been achieved on the platform composed by Xilinx zc706 and Analog Devices FMCOMMS2 board. RF measurement shows that the design meets the SIFS timing requirement. Ping, iperf and video streaming were run successfully via the SDR-commercial WiFi link. This progress gives us confidence to make future releases successful. By the end of 2019, corresponding open source project will be setup under an open source license. More advanced features will be released based on our past innovation achievements. This will help the community to do more innovative work, starting from a consolidated platform. More modes (802.11p, 802.11ah, Bluetooth, 802.15.4) will be added to the FPGA design, and Linux drivers will be offered accordingly. Non-standard mode by exposing real-time reconfigurable parameters such as the bandwidth/sampling-rate. Simultaneous and independent operation of multiple virtual radio instance with the hardware footprint of a single radio by radio hardware virtualization. Time-Annotated Instruction Set Computer (TAISC) based MAC engine will offer easy and platform-agnostic MAC programing of lower MAC, which is always a black box implementations in commercial chips. A developer community is expected to emerge around this project. Since the project has full flexibility/access to full radio stack, we believe that more interesting features will pop up in the future with the help of SDR/Linux community. To maintain a sustainable community, dedicated internal human resources will be allocated to do daily support and development. In summary, an open source SDR project will be set up in a more "commercial chip" like approach, which will bring traditional SDR community and Linux community together. Thanks to the embedded Linux hardware/software ecosystem, this approach will help developers to apply SDR in many embedded scenarios, such as drone, vehicle and handheld devices. With the inherent flexibility on both PHY and MAC offered in our project, more SDR applications can be explored in the area where commercial chip is not the ideal choice. As the project initiator, we are also open to work on domain specific feature/customization requests from community in the future.

Hierarchical Orchestration of End-to-End Networks

Joao F. Santos (Trinity College Dublin & CONNECT/CTVR, Ireland); Jonathan van de Belt (Trinity College Dublin, Ireland); Luiz DaSilva (Trinity College & Trinity College Dublin, Ireland)

In contrast to previous mobile network standards, 5G is being envisioned from the very beginning to support a variety of different services, e.g., ultra-reliable low latency communication, high-speed vehicular communication, and low-power massive IoT communication. To cope with such diverse network requirements, the 3GPP introduced the concept of end-to-end (E2E) network slicing for 5G, which proposes the partitioning of the physical network infrastructure into independent virtual networks, known as Network Slices (NSs). Each NS operates as a separate and isolated E2E network, which can be individually tailored and configured for serving different applications. Hence, services with diverging network requirements can be supported through distinct NSs, capable of ensuring the particular network requirements. However, E2E networks can comprise multiple network segments, e.g., radio access networks, transport networks, core networks, and data centre networks. Each network segment behaves as an individual network, with its own resource management, QoS configuration, and policy enforcement. Hence, the slicing of E2E networks requires the slicing of each individual network segment and the subsequent combination between the slices of network segments for creating E2E NSs. The management of the network resources for the creation of NSs is carried out by an entity known as the orchestrator, which has a view and control over the network's resources and capabilities. This entity is responsible for the translation of high-level service requirements into the necessary configuration of the different NSs. Then, it orchestrates the allocation of network resources and the placement of network functionality to form the NSs. However, there are fundamental differences between different types of network segments, both regarding their purpose and the physical network resources. These differences lead to different sets of requirements for the NSs and the need for difference hypervisors and network virtualisation mechanisms. Hence, each network segment should have their own orchestrator, tailored to the network segment's particularities. This separation of control and management between different network segments allows each segment orchestrator to focus on a limited number of well-defined tasks, reducing the software complexity, both in terms of design and implementation. Furthermore, it also allows the owners of each network segment to apply their own policies and have different business models. In this scenario, there must be an entity with a global view of the available network resources and the capabilities of each orchestrator for establishing and managing E2E networks, leveraging the slicing of each network segment. This entity, called a hyperstrator, acts as would be an orchestrator of orchestrators, responsible for coordinating the interaction between the underlying virtualised infrastructure and NSs. The hyperstrator sits on top of the different orchestrators for controlling the E2E allocation of resources and the management of the entire network. In this presentation, we will introduce a hierarchical orchestration scheme for E2E networks. Our proposed hierarchical orchestration scheme enables each network segment to be independently managed, and yet allows cross-network segment resource management through the hyperstrator, a higher-level cross-segment orchestrator. We developed a prototype implementation of a hyperstrator, as well as the orchestrators for managing wired and wireless network segments. Our prototype implementation can deploy E2E NSs on top of a wired network segment, using the wired orchestrator to manage an SDN network, and a wireless network segment, using the wireless orchestrator to manage an SDR network. The coordination between the orchestrators is performed by the hyperstrator, which receives high-level E2E service requests, decides the network requirements for the different network segments, and delegates the appropriate network requirements to the respective orchestrators. Then, the different orchestrators use the respective resources of their network segments to provision NSs. Finally, the hyperstrator ensures the combination of the different NSs to form E2E NSs. Our current implementation can successfully deploy E2E NSs and establish E2E communication services to support distinct traffic classes.

Experimental Evaluation of LSPR Routing Protocol

Khalid Hussain Mohammadani and Kamran Ali Memon (Beijing University of Posts and Telecommunications, P.R. China); Safiullah Faizullah (Hewlett-Packard, USA); Arshad M. Shaikh (Isra University, Pakistan); Saleemullah Memon (Beijing University of Posts and Telecommunications, P.R. China); Asiya Siddiqui and Noor Ul Ain (Beijing University of Posts & Telecomunications, Beijing, P.R. China)

Mobile adhoc network (MANET) routing protocols can be classified as either topology based (which uses the inter-node connectivity information to create routes) or position based (that uses geographical positions of the nodes for routing and forwarding decisions). Topology based routing often runs into problems due to its inability of identifying week links (links that are about to break due to mobility), resulting in broken routes and hence cost performance penalty. Position based routing often uses a greedy approach that stucks in local-maxima situation resulting in a stalled communication. In our previous work [1] we had introduced LSPR (Location Server based Proactive Routing) protocol that offers a unique hybrid of both topology-based and position-based routing strategies. LSPR constructs routes from topology information extracted from geographical position data of the nodes. It ignores any weak links by confirming that each pair of communicating nodes are located at least two-third transmission-range apart. In this study we attempt to provide more support and evidence that our LSPR protocol is indeed a better choice for routing in MANETs. We hereby compared the performance of LSPR protocol with AODV, DSDV, LAR, and LSAR protocols under varying mobility and network conditions.

Simulation, test and reference facility for IP based heterogeneous communication networks

Gerald Ulbricht, Christopher Laske (Fraunhofer Institute for Integrated Circuits IIS), Carsten Hatzig (Bundeswehr Technical Center for Information Technology and Electronics - WTD 81)

Today's communications networks are commonly based on the internet protocol suite.  Different voice and data services require distinct quality of service for a satisfactory user experience. This can be a challenging issue for heterogeneous networks including mobile communications that have to bear with low bitrates and occasional high latencies. In consequence, a test environment is required providing component, routing and system analytical capabilities to validate and verify quality of service of such networks during design and operation.

 The presentation will introduce a test environment that specifically provides:

• support during analysis, design and configuration of the network of technically heterogeneous networks

• acceptance tests of components and applications

• integration and interoperability tests e.g. after updates, upgrades, and provisioning to support configuration management

• non-proprietary component and system tests for benchmarking within the specifications or requirements

• objectively comparable and reproducible test results

• validation of new configurations within the system-of-systems

• fault analysis under realistic environmental emulations/ simulations and reproducible conditions

• test for certification as part of a release management

• script-based test automation and evaluation

The purpose is a permanently available and flexible test environment for a wide range of validation and verification activities. Key properties are easy and intuitive usability as well as repeatability and transparency for high quality and nonrepudiability of test results.

Wednesday, May 15 17:20 - 17:30
Day 1 Closing Remarks

Thursday, May 16

Thursday, May 16 9:00 - 10:00
Thurs Welcome and Keynotes

Thursday, May 16 10:00 - 10:30
Multinational Programs and Initiatives Session 1

Thursday, May 16 10:30 - 11:00
Networking and Refreshments

Thursday, May 16 11:00 - 12:40
Multinational Programs and Initiatives Session 2

Thursday, May 16 12:40 - 14:00
Lunch and Product Exhibition

Thursday, May 16 14:00 - 15:20
NATO Nations' Perspective

Thursday, May 16 15:20 - 15:50
Networking and Refreshments

Thursday, May 16 15:50 - 16:50
NATO Nations' and Partners for Peace Nations' Perspectives

Thursday, May 16 16:50 - 17:25
Panel: NATO Panel Discussion

Thursday, May 16 17:25 - 17:30
Summit Closing Remarks