G A 826152 P a g e 1 | 40

Deliverable D 3.1: High-level design of Radio access emulation tool

(stream b)

Reviewed

Project acronym: EMULRADIO4RAIL Starting date: 01/12/2018 Duration (in months): 18 Call (part) identifier: H2020-S2R-OC-IP2-2018-03 Grant agreement no: 826152 Due date of deliverable: Month 05 Actual submission date: 8/10/2019 Responsible/Author: Raul Torrego - IKERLAN (IKL) Dissemination level: PU Status: Reviewed

Ref. Ares(2019)6273432 - 10/10/2019

G A 826152 P a g e 2 | 40

Document history Revision Date Description 0 17/05/2019 First issue – Table of Contents and initial structure 1 30/08/2019 Integration of contributions from IFSTTAR, DTU and IKL 2 24/09/2019 Integration of contributions from ULILLE and RADIOLABS. 3 03/10/2019 First review process 4 08/10/2019 Final review process

Report contributors Name Beneficiary Short

Name Details of contribution

Raul Torrego IKERLAN Deliverable leader Pedro Aljama IKERLAN Section 7.1, 7.2.2, 7.6 and 7.8 Marion Berbineau IFSTTAR Chapter 7.4 and 7.5 Jose Soler DTU Chapter 7.4 and 7.5 Ying Yan DTU Chapter 7.4 and 7.5 Laurent Clavier ULILLE Chapter 7.2.1 and 7.3 Sofiane Kharbech ULILLE Chapter 7.2.1 and 7.3 Alessandro Vizzarri RADIOLABS Chapter 7.7 Christophe Gransart IFSTTAR Review

G A 826152 P a g e 3 | 40

Table of Contents 1. Executive Summary ......................................................................................................... 5

2. Abbreviations and acronyms ........................................................................................... 6

3. Background ...................................................................................................................... 8

4. Objectives ........................................................................................................................ 9

5. Introduction ................................................................................................................... 10

6. High-Level Design proposed in D2.1 ............................................................................. 11

6.1. Full architecture ......................................................................................................... 11

6.2. IP impairment model emulator ................................................................................. 13

6.3. RF emulation architecture ......................................................................................... 15

6.4. Backhaul/PLMN network emulation architecture .................................................... 16

6.5. Miscellaneous architectures ...................................................................................... 17

7. Low level design ............................................................................................................ 17

7.1. Overall Low-Level-Design .......................................................................................... 17

7.2. RF Channel emulators ................................................................................................ 20

7.2.1. RF Channel emulator 1 ....................................................................................... 20

7.2.2. RF Channel emulator 2 ....................................................................................... 21

7.3. Interference generator .............................................................................................. 24

7.4. LTE emulation platform ............................................................................................. 27

7.5. Backhaul/PLMN emulation platform ......................................................................... 29

7.6. Wi-Fi emulation platform .......................................................................................... 31

7.7. Satellite emulator ...................................................................................................... 32

7.8. Control infrastructure ................................................................................................ 38

8. Conclusions .................................................................................................................... 39

9. References ..................................................................................................................... 40

G A 826152 P a g e 4 | 40

Table of Figures Figure 1: Full architecture (high-level) ..................................................................................... 12 Figure 2: IP impairment model emulator (high-level) .............................................................. 13 Figure 3: RF infrastructure used to obtain IP impairment models (high-level) ....................... 14 Figure 4: RF emulation architecture (high-level) ..................................................................... 15 Figure 5: Backhaul/PLMN network emulation architecture (high-level) ................................. 16 Figure 6: Overall view of the Low-Level Design ....................................................................... 18 Figure 7: Channel emulator in baseband (BB) mode. .............................................................. 20 Figure 8: Channel emulator in RF mode. .................................................................................. 20 Figure 9: Channel emulator 2 (low-level) ................................................................................. 21 Figure 10: RF-IF Conversion Stage (Internal block diagram) .................................................... 22 Figure 11: FMC150 board ......................................................................................................... 22 Figure 12: MPSoC (Zynq Ultrascale+ - ZCU102) ....................................................................... 23 Figure 13: RF interference – Scenario 1. .................................................................................. 24 Figure 14: RF interference – Scenario 2. .................................................................................. 25 Figure 15: RF interference – Scenario 3. .................................................................................. 25 Figure 16: Baseband interference – Options 1 and 2. ............................................................. 26 Figure 17: LTE platform (layout) ............................................................................................... 27 Figure 18: LTE platform (setup) ................................................................................................ 27 Figure 19: LTE setup equipment .............................................................................................. 28 Figure 20: Overall test scenario with simulated backbone network ....................................... 29 Figure 21: Simulated Backhaul Network – with failure at link sw_2-sw_4 .............................. 30 Figure 22: Wi-Fi emulation platform ........................................................................................ 31 Figure 23: Considered satellite link transmission .................................................................... 33 Figure 24: IP emulated Satellite link transmission ................................................................... 33 Figure 25: IP emulated Satellite link transmission ................................................................... 33 Figure 26: Terminals and Server sub-networks Emulation ...................................................... 34 Figure 27: Terminals and Server sub-networks Emulation ...................................................... 35 Figure 28: Satellite bearers ...................................................................................................... 36

G A 826152 P a g e 5 | 40

1. Executive Summary The European EMULRADIO4RAIL Project aims to develop an innovative emulation platform for tests and validation of various radio access technologies (RAT) like Wi-Fi, LTE, LTE-A and Sat-Coms. The project considers the integration of both channel emulators and network emulators into a single emulation platform so that the proposed testbed can offer a complete (from physical layer to IP level) test environment. This deliverable provides both the high-level and low-level design description of the complete emulation platform to be developed and tested. As starting point, and as a summary of the conclusions adopted and presented in Deliverable 2.1 [1], the high-level design of the architecture is presented. This high-level design presents the modular architecture that has been defined and the different configuration options. Later, the deliverable continues with a detailed snapshot of each block in which the full emulation platform is divided. Namely: RF channel emulator(s), Interference generator(s), LTE emulation platform, Wi-Fi emulation platform, Backhaul/PLMN emulation platform, Satellite emulation platform and Control infrastructure.

G A 826152 P a g e 6 | 40

2. Abbreviations and acronyms

Abbreviation / Acronyms Description ACS Adaptable Communication System ADC Analog-to-Digital Converter AP Access Point AWGN Additive White Gaussian Noise BB Base Band CPU Central Processing Unit DAC Digital to Analog Converter DUT Device Under Test EPC Evolved Packet Core ESG Signal Generator FPGA Field-Programmable Gate Array GSM Global System for Mobile communications GSM-R GSM - railway GUI Graphical User Interface I/O Input / Output port IF Intermediate Frequency IP Internet Protocol KPI Key Performance Indicator KVM Kernel-based Virtual Machine LTE Long Term Evolution LTE-A Long Term Evolution Advanced LXC Linux Containers MIMO Multiple Input Multiple Output MPLS Multiprotocol Label Switching MXG Mid-range, Xtra good signal generator NICS Network Interface Cards OAI Open Air Interface OPNET OPtimized Network Engineering Tool PC Personal Computer PL Programmable Logic PLMN Public Line Mobile Network PS Processing System PSG Performance Signal Generator PXA Extra performance Signal analyser PXB Base Band Generator QoS Quality of Service RF Radio Frequency Sat-Coms Satellite Communications SDR Software-Defined Radio SIM Subscriber Identity Module

G A 826152 P a g e 7 | 40

SITL System In The Loop SMA SubMiniature version A SW Software TBF Token Bucket Flow TDL Tap Delay Line TM Transmission Mode USB Universal Serial Bus USRP Universal Software Radio Peripheral VM Virtual Machine Wi-Fi Wireless Fidelity WLAN Wireless Local Area Network WP Work Package

G A 826152 P a g e 8 | 40

3. Background The present document constitutes the Deliverable D3.1 “High-level design of Radio access emulation tool (stream b)” according to Shift2Rail Joint Undertaking programme of the project titled “EMULATION OF RADIO ACCESS TECHNOLOGIES FOR RAILWAY COMMUNICATIONS” (Project Acronym: EMULRADIO4RAIL, under Grant Agreement No 826152). In December 2018, the European Commission awarded a grant to the EMULRADIO4RAIL consortium of the Shift2Rail / Horizon 2020 call (H2020-S2RJU-OC-2018 S2R-CFM-IP2-01-2015). EMULRADIO4RAIL is a project connected to the development of a new Communication System planned within the Technical Demonstrator TD2.1 of the 2nd Innovation Programme (IP2) of Shift2Rail JU: Advanced Traffic Management & Control Systems. The IP2 “Advanced Traffic Management & Control Systems” is one of the five asset-specific Innovation Programmes (IPs), covering all the different structural (technical) and functional (process) sub-systems related to control, command and communication of railway systems.

G A 826152 P a g e 9 | 40

4. Objectives This document has been prepared to provide the description of the different building blocks of the radio access emulation tool taking as input the results of WP2 D2.1 [1]. The emulation tool will consist of different flexible and reconfigurable elements; therefore, the main objective of this deliverable is to provide the description of the following solutions to be developed in Task T3.1:

• Solution for LTE emulation using the RF channel emulator from the University of Lille and the implementation of the LTE eNodeB and EPC with Open Air Interface emulator from DTU and IFSTTAR

• Solution for Wi-Fi emulation using the IKERLAN RF channel emulator and commercial Wi-Fi APs and nodes

• Solution for SatCom emulation at IP level using the emulation architecture provided by RADIOLABS

• Solution for the Backhaul/PLMN emulation platform using the SITL interface in Riverbed Modeler from DTU and IFSTTAR

• Solution for RF interference generation and injection using the architecture proposed by the University of Lille

• Solution for a control infrastructure in charge of controlling (locally or in a remote way) the above presented blocks

G A 826152 P a g e 10 | 40

5. Introduction EMULRADIO4RAIL will provide an innovative platform for test and validation of various radio access technologies (Wi-Fi, LTE, LTE-A and Sat-Coms) that combines very new approaches for testing so called System In-The-Loop (SITL) and Hardware-In-The-Loop (HITL). The prototypes of the Adaptable Communication System (ACS) from X2RAIL-3 WP3, which constitute the devices under test (DUT), will be coupled to emulators of both the communication core network and various radio access technologies thanks to the coupling among discrete event simulator such as RIVERBED modeler (former OPNET modeler), Open Air Interface (OAI), various radio Channel emulators, Network emulators, models of IP parameters and real physical systems. It is important to note that it has been stated in D1.1[2] and after discussion with X2RAIL-3 WP3 partners, that GSM-R is out of the scope of the ACS, so this technology will not be addressed in the emulation platform. Besides, 5G is still in development and particularly, the solution chosen (Open Air Interface) to emulate 5G does not guaranty today the availability of all the 5G NR (New Radio) features. Several are not yet implemented, although the Open Air Wiki information mentions a roadmap for implementing them, without detailed time-plans (https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/5g-nr-development-and-releases). Once OAI 5G development will be matured, no major changes, regarding the radio access, are expected for the emulator as 5G NR is built over LTE concepts (eNB vs gNB – gNB replaces eNB on the 5G NR architecture). Due to this, only a software update for the eNB element is expected to be necessary. It may be also necessary to upgrade the SDR boards (buying new equipment in relation to the new operating frequency bands and encoding). Another very important issue concerns the 5G Core, which most likely will be affected by the new Release 16 coming December 2019. This will impact OAI developments as well as the current LTE-EPC part of the Emulator, which makes really unlikely that the Emulradio4Rail project can test any 5G e2e case (5G radio access + 5G core) during project duration. Nevertheless, it can be stated that the methodology developed for LTE using OAI will be transposable to OAI 5G NR as well as OAI 5G Core, with basic software updates, when available. Considering the above-mentioned diverse technologies that will take part in the project, the aim of this deliverable is providing a low-level design description of the complete emulation architecture platform so that it can be implemented in task T3.1. As starting point, and as a summary of the conclusions adopted and presented in Deliverable 2.1 [1], the high-level design of the architecture is presented. This high-level design presents the modular architecture that has been defined and the different configuration options. Later, the deliverable continues with a detailed snapshot of each block in which the full emulation platform is divided. Namely: RF channel emulator(s), Interference generator(s), LTE emulation platform, Wi-Fi emulation platform, Backhaul/PLMN emulation platform, Satellite emulation platform and Control infrastructure.

G A 826152 P a g e 11 | 40

6. High-Level Design proposed in D2.1 According to the conclusions adopted in Deliverable 2.1 [1], the emulation platform to be developed aims to cover different possible users, hence a modular architecture for the emulation platform is proposed so that it can be configured as needed. Several configurations depending on the functionalities demanded are foreseen:

• Full architecture (section 6.1) • IP impairment model emulator (section 6.2) • RF emulation architecture (section 6.3) • Backhaul/PLMN network emulation architecture (section 6.4)

This section sums up the proposed high-level design and its different configurations (NOTE: See chapter 10 from “D2.1 Solutions to emulate the Radio Bearer” to obtain detailed information about these configurations.)

6.1. Full architecture This architecture is intended for partners which aim to test their IP level communication devices against a very realistic emulation platform in which radio bearers, RF channels and backhaul/PLMN networks will be emulated in real time (see Figure 1).

G A 826152 P a g e 12 | 40

Figure 1: Full architecture (high-level)

G A 826152 P a g e 13 | 40

6.2. IP impairment model emulator This configuration represents a simplified version from the Full architecture platform (6.1). In this scenery only SW emulation of the IP impairments that derive from RF impairments is carried out (see Figure 2). This is done obtaining previously the IP impairment models making use of the RF infrastructure supplied by the full architecture configuration (see Figure 3)

Figure 2: IP impairment model emulator (high-level)

G A 826152 P a g e 14 | 40

Figure 3: RF infrastructure used to obtain IP impairment models (high-level)

G A 826152 P a g e 15 | 40

6.3. RF emulation architecture In this version, the input and output are at RF level. It makes use of channel emulators and interference generators. IP level is out of the scope of this configuration model. (see Figure 4). This configuration is intended for those partners who aim to test their radio bearers at RF level.

Figure 4: RF emulation architecture (high-level)

G A 826152 P a g e 16 | 40

6.4. Backhaul/PLMN network emulation architecture This configuration will be adopted for the users who are not interested in the RF emulation capabilities presented in others architectures, but only in the backhaul/PLMN network emulation (see Figure 5).

Figure 5: Backhaul/PLMN network emulation architecture (high-level)

G A 826152 P a g e 17 | 40

6.5. Miscellaneous architectures The above presented architectures/configurations that derive from the full emulation architecture depicted in section 6.1 only constitute some examples of the different possibilities in which the proposed emulation platform can be used. However, the configuration possibilities are not limited to them. Taking into account the modular design that has been foreseen, any interconnection between the different blocks can be carried out. As an example of this, after discussion with X2RAIL-3 WP3 partners, which are the target test users of the emulation platform, it has been confirmed that different configurations are required by each of the use cases. Furthermore, not all the configurations exactly fix into the ones presented above. Hence, even if this document describes the complete emulation architecture and all the blocks/capabilities that will be developed, during the tests the end users will be able to use only the ones they need and in the way they require.

7. Low level design The above section presents a High-Level Design of the emulation architecture (and its different possible configurations). This High-Level Design mainly links black boxes (e.g.: channel emulator, interference generator…) in order to offer a conceptual/functional view of the architecture but it is not enough in order to carry out an implementation. This section aims to present the Low-Level Design of the complete architecture. The different building blocks of the emulation platform and the concrete way of interconnecting them will be detailed in the following sub- sections.

7.1. Overall Low-Level-Design

G A 826152 P a g e 18 | 40

Figure 6: Overall view of the Low-Level Design

G A 826152 P a g e 19 | 40

Figure 6 shows the overall view of the emulation platform to be implemented. It considers: • A LTE emulation platform made of:

o An instrumentation-based RF Channel emulator o A RF interference generator o A PC + LTE Dongle o A RF-Board (USRP SDR board) + 2 PC running Open Air Interface (used for eNodeB

and EPC respectively)

• A Wi-Fi emulation platform made of: o A FPGA-based RF Channel emulator o A RF interference generator o A commercial Wi-Fi node o A commercial Wi-Fi AP

- A Satellite emulation platform made of:

o A PC where a virtualization system is running.

• A Backhaul/PLMN emulation platform made of: o A PC running Riverbed Modeller with SITL interfaces (IN/OUT).

• A control infrastructure made of:

o A control PC running the User Interface o Several network switches that interconnect the different devices o An external ethernet access to one of these switches in order to enable the

remote control and use of the emulation platform

The way the different devices are interconnected can be observed looking at the different coloured arrows. Mainly:

• The Ethernet connections that are part of the configuration/control functions are drawn with blue arrows. Besides, the NICs that are part of this control architecture are coloured in orange

• The Ethernet connections that are part of the main datapaths (IP level) are drawn with green arrows. Besides, the NICs that are part of the main datapaths (IP level) are coloured in green.

• The RF connections (likely SMA to SMA cables) are drawn with red arrows

The following sub-sections will now describe each of the sub-systems in deep.

G A 826152 P a g e 20 | 40

7.2. RF Channel emulators

7.2.1. RF Channel emulator 1 The platform used in the testbed is the baseband generator and channel emulator PXB N5106A from Keysight Technologies. The main features of the PXB are the followings.

• Input and output bandwidth up to 160 MHz (80 MHz I + 80 MHz Q). • Many predefined channel models (GSM, 802.16, WLAN, etc.), including LTE communications

for high-speed trains (vehicle speed up to 864 kph). • Supports MIMO systems (up to 4x4) and considers antenna correlation. • Adds additive white Gaussian noise. • Many fading types (Rician, Rayleigh, etc.) and Doppler spectra (flat, Jakes, etc.). • Up to 24 taps per fader.

Figure 7: Channel emulator in baseband (BB) mode.

Since it is a baseband emulator, and to be able to work with RF signals, the PXB requires RF modulator (e.g. PXA) at its input and RF demodulator (e.g., PSG, ESG, MXG) at its output.

Figure 8: Channel emulator in RF mode.

G A 826152 P a g e 21 | 40

7.2.2. RF Channel emulator 2 The wireless channel emulator labelled as 2 and designed by IKERLAN presents the following key features:

• Chanel emulator based on FPGA. • Four bidirectional RF ports. • A wide band emulation: from 400 MHz up to 6 GHz. • 100 MHz signal bandwidth.

Figure 9: Channel emulator 2 (low-level)

Regarding its internal design, its block diagram is shown in Figure 9. In that sense, it can be distinguished three levels of analysis:

• RF-IF conversion stage (Green Region).

o At the input and output of the channel emulator, RF frontend and backend stages are presented. In Figure 10, an internal block diagram of RF-IF conversion stage is shown for a RF bidirectional RF port (out of 4 existing). Hence, input IF signal is obtained after mixing RF signal and a Local Oscillator signal (transmission, RF to IF path). Similarly, output signal is obtained after the IF-RF conversion with the fading applied (reception, IF to RF path).

RF Trx

RF-IF Conversion

Stage

ADC/ DACFMC150

RF-IF Conversion

Stage

RF Trx

ADC/ DACFMC150

FPGA

Mult ipath +

Mult ipath+

+

WGNG

+

Complex-Baseband Equivalent Channel Model

CHANNEL EMULATOR

G A 826152 P a g e 22 | 40

Figure 10: RF-IF Conversion Stage (Internal block diagram)

• Digital Conversion Stage (Blue Region).

o An analogic-digital conversion of the IF signal is sampled to be modified in the following stage (FPGA) according to the emulation model. This stage is carried out through two FMC150 boards (in order to cover the 4 RF bidirectional ports). From 4DSP manufacturer, it is composed by 4 ADC/DAC channels (2 ADC of 14 bits and 2 DAC of 16 bits, see Figure 11 ).

Figure 11: FMC150 board

• FPGA Stage (Gray Region).

G A 826152 P a g e 23 | 40

o Amplitude, phase and delay are modified according to a tapped delay line

model emulated making use of a MPSoC platform. Concretely, the ZCU102: it combines a powerful system processing system (PS) and user-programmable logic (PL) into the same device. As key components it must be remarked the following (see Figure 12): Quad-core Arm Cortex-A53 processor: running a Linux operating system and

acting as manager implementing the user system interface. Dual-core Arm Cortex R5 real time processors: responsible for controlling the

digital signal processing and also carrying out specific digital signal processing operations.

A programmable logic region where the digital signal processing algorithms are implemented.

Figure 12: MPSoC (Zynq Ultrascale+ - ZCU102)

G A 826152 P a g e 24 | 40

7.3. Interference generator Many interference scenarios can be considered for baseband or RF signals. The proposed schemes regard only one-way transmission, i.e., uplink or downlink.

• RF interference scenarios:

Possible scenarios are described in the figures below. Scenario 1 is close to real-world communications since the interfering signal is issued from real communication.

Figure 13: RF interference – Scenario 1.

In Scenario 2, the interfering signal is generated using a baseband arbitrary waveform generator (AWG). That instrument can be manipulated using a computing environment like Matlab and then allows signals generation for a wide range of standards. The PSG is needed for RF modulation. We also note that instead of AWG and PSG, we can use a USRP platform. Scenario 3 gets the benefit of the arbitrary signal generation inside the PXB and emulating different channel for the interfering signal. Then, for ensuring RF interference, RF modulation is needed for both PXB outputs. Scenarios 2 and 3 are applicable regardless of the nature of the interfering signal, i.e., interfering communication signal or noise.

circulator

G A 826152 P a g e 25 | 40

Figure 14: RF interference – Scenario 2.

Figure 15: RF interference – Scenario 3.

• Baseband interference scenarios:

As described in the figure below, for baseband interference, two options are proposed; generating the interfering signal through a USRP platform (option 1) or AWG (option 2). For both options, the channel for the interfering signal is emulated separately in the PXB, then the baseband signals (signal of interest and the interfering) are superposed after RF modulation.

G A 826152 P a g e 26 | 40

Figure 16: Baseband interference – Options 1 and 2.

G A 826152 P a g e 27 | 40

7.4. LTE emulation platform LTE emulation platform is setup to validate the communication with an LTE terminal, through an end to end communication path formed by an OAI emulation (LTE eNodeB + LTE EPC) and a Riverbed Modeller simulation of the backhaul network. The proposed LTE Emulation platform in D3.1 is shown in Figure 17 whose real setup is developed in Figure 18.

Figure 17: LTE platform (layout)

Ethernet

UE (PC with LTE dongle) GCG host (PC)

Real Simulated EnvironmentEmulated Environment

EthernetSITLSITL

eNodeB (fat PC with SDR card)

Ethernet

EPC (PC) OPNET (PC)

Figure 18: LTE platform (setup)

The equipment description and functionality used to carry out the setup described in Figure 18 is summarized in Figure 19 and detailed in the following bullets:

eNodeB • Dell Precision Tower 7810 CTO Base • Ubuntu 16.04 kernel 4.8 low latency

SDR board • USRP B210 from Ettus research • VERT900 Vertical Antenna (824-960MHz, 1710-1990MHz, Dualband)

EPC • Common laptop,

G A 826152 P a g e 28 | 40

• Ubuntu 16.04 kernel 4.2 generic

UE with LTE dongle

• Common laptop • Ubuntu 16.04 kernel 4.2 generic • Huawei E3372 LTE USB dongle • Sysmocom SJS1 SIM card

Figure 19: LTE setup equipment

• Equipment Description o LTE UE:

A laptop with LTE USB dongle. o LTE eNodeB:

A PC that runs an OpenAirInterface program with SDR which acts as eNodeB. The SDR is used for emulating signal loss and consequently a communication failure. Two Ethernet cards are required (USB-Ethernet converter can work).

o LTE EPC: A laptop that runs an OpenAirInterface program which acts as LTE EPC.

o Riverbed Modeler PC: A laptop as Riverbed Modeler simulator. A laptop that runs an Riverbed

Modeler program which acts as backbone network. Two licenses for SITL interfaces are required.

• Functionality description of LTE platform equipment

o eNodeB configurations The testbed is configured to operate as a Release 8 LTE eNodeB in Band

7 and using Transmission Mode (TM) 1. All the parameter settings are defined in the configuration file enb.band7.tm1.usrpb210.conf. Based on the default settings provided by OAI, some identification parameters and network interfaces are modified to match the settings in this project implementation.

o EPC configurations All the settings for EPC can be found in configuration files

hss.conf,mme.conf and spgw.conf respectively. The configuration of EPC includes the specification of network interfaces, free diameter settings and adding UE information in the HSS database.

o UE configurations

G A 826152 P a g e 29 | 40

A blank SIM card with available administrative keys is used, which can be scanned and re-programmed to match the settings in their prospective entry in the EPC database.

7.5. Backhaul/PLMN emulation platform As part of the LTE emulation platform, but with enough entity so to as to have an individual section, here the description of the Backhaul/PLMN emulation platform is carried out. This module, implemented in the “Riverbed Modeler PC” described above, and running Riverbed modeler, has the following characteristics/configurations:

• Current backhaul network configuration

o The backhaul network in the Riverbed modeler simulation environment contains two SITL interfaces for converting between the real traffic packet format and simulated packet format and two Ethernet switches for routing the traffic to the destination.

o A network consisting of 8 switches is simulated in the Riverbed Modeler. Two SITL gateways are connected as the real-sim/real-sim interfaces to the LTE OAI EPC and the application service host. The overall test scenario is show in Figure 20.

Eth

UE

eNodeB

Application servers

RealSimulated Environment

Emulated Environment

Ethernet Eth

SITLSITL

Discrete-event networkSimulator

Real

OAI based LTE network

Figure 20: Overall test scenario with simulated backbone network

• General operations o The overall backhaul network infrastructure is shown in Figure 21.

The traffic is routed between the switch_1 and switch 8 via the link switch_1 <-> switch_2 <-> switch_4 <-> switch_8. The redundancy property is tested by setting the link switch_2 <-> switch_4. In case of failure occurred (shown with the red cross), traffic is routed via a new path as switch_1 <-> switch_2 <-> switch_3 <-> switch_5 <-> switch_4 <-> switch_8.

G A 826152 P a g e 30 | 40

Figure 21: Simulated Backhaul Network – with failure at link sw_2-sw_4

• Further proposal: o Extend the current backhaul scenario with 1) different network topologies (e.g.

ring, star etc) 2) different number of switch nodes. o In the simulation environment, the link performance parameters (e.g. link

delay, loss etc) can be injected and tested. o Different traffic types can be introduced into the scenario. The QoS function

will be implemented in the multi-layer topology by using for example MPLS technology or others.

NOTE: while the previous design matches the original idea and objectives described in the DoA, industrial partners of X2Rail-3 explicitly declared on a common meeting (San Sebastian, September 2019) that they are not interested on emulating the Backhaul network for any scenario. Nevertheless, they are still interested on injecting different traffic mixes to the emulator, in order to trigger a switch to alternative bearer/networks (alternative LTE or Wi-Fi). As a result, Emulradio4Rail consortium is currently investigating the possibility of injecting a (IP) traffic mix at the input or output of the EPC element, as an alternative to the original design

G A 826152 P a g e 31 | 40

7.6. Wi-Fi emulation platform The Wi-Fi emulation platform is made of a commercial Wi-Fi node/STA and AP, and the above described RF Channel emulator 2. Frames at IP level enter the platform through the Wi-Fi node, which converts them into RF Wi-Fi frames. These frames are introduced into the channel emulator which modifies them according to the TDL channel model programmed. The outcoming Wi-Fi frames are introduced into the Wi-Fi AP that converts them back to IP frames. Besides, the platform completes with a RF interference generator at RF level as depicted in Scenario2 of section 7.3.

Figure 22: Wi-Fi emulation platform

G A 826152 P a g e 32 | 40

7.7. Satellite emulator The considered satellite emulator operates at IP level. This means the Device Under Test (DUT) acting as a client, injects IP packets at its input. The emulator applies to the input IP flow the envisaged impairments. In particular the emulator can account for the typical impairments of satellite links as seen at IP level. The most important KPI end-to-end delay and its variability, the Packet Loss, Jitter and Physical Link Bitrate (bandwidth). The impaired IP flow at the output of the satellite emulator is then delivered to the server running the railway application(s). The main features of the satellite emulator are related to the possibility to add delay, packet loss, duplication and more other characteristics to packets outgoing from a selected network interface. This can be achieved through existing Quality of Service (QoS) and Differentiated Services (diffserv) facilities in the Linux kernel.

• Delay [ms]: can be added to the packets outgoing to a specific network interface. The delay variation and correlation can be also set. Delay and jitter values are expressed in ms while correlation is percentage

• Distribution: allow the user to choose a specific delay distribution based on models known in literature (normal, Poisson, etc...)

• Packet Loss: adds an independent loss probability to the packets outgoing from the specific network interface

• Loss State: adds packet losses according to the 4-state Markov using the transition probabilities as input parameters

• Loss gemodel: adds packet losses according to the Gilbert-Elliot loss model or its special cases (Gilbert, Simple Gilbert and Bernoulli)

• Packet tagging • Packet Corruption: random noise can be emulated introducing an error in a random position

for a chosen percent of packets • Packet Duplication before queuing • Packet reordering

Some of these parameters should be set and varied in time in accordance with the specific needs dictated by the scenario conditions considered by the tester.

• Proposed Satellite emulator architecture

The considered satellite link transmission is shown in Figure 23. From a client point of view, the user terminal is connected to the satellite earth station through a satellite modem. The same scheme is adopted on the server side. The IP packets are sent from the client to server (and vice versa) in end-to-end way.

G A 826152 P a g e 33 | 40

Figure 23: Considered satellite link transmission

The IP emulated Satellite link transmission through the EMULRADIO4RAIL Platform is shown in Figure 24. The EMULRADIO4RAIL platform implements the interfaces on which IP packets are sent in end-to-end way.

Figure 24: IP emulated Satellite link transmission

• Emulator subsystems and their roles

The main subsystems of satellite emulator platform for EMULRADIO4RAIL are (see Figure 25):

Figure 25: IP emulated Satellite link transmission

train

G A 826152 P a g e 34 | 40

• Terminal interface • Satellite modem • Satellite bearer • Server interface

a) Terminals and Server sub-networks subsystem

• Allows to interconnect satellite emulator with external devices (see Figure 26). DUT: running the client-side applications (e.g. the railway terminal to

be tested) Server: running the railway application

• Interconnection of external devices (DUT and Server) is achieved by Ethernet connection

• Provides the tester the capability of defining virtual terminals and servers to: Run application creating additional (disturbing) traffic to the DUT Run other server applications directly inside the emulator

• Virtual terminals and servers also allow to autonomously calibrate and/or to test emulator capabilities independently of the presence of external DUT(s) or Server(s)

Figure 26: Terminals and Server sub-networks Emulation

b) Ingress and Egress routers: operations

• Ingress router

o Routes ingress packets from the DUT router or packets from the virtual terminals (vTi) to the corresponding satellite modem/bearer emulator (e.g. one of the modem 1..K) in accordance with the source IP address For packets from DUT: the source IP address in the packet is the IP address

of the DUT interface generating the packet flow • On the basis of the destination IP address, routes egress packets to:

G A 826152 P a g e 35 | 40

o The DUT router o The virtual terminals vTi, i=1…n

• Egress router o On the basis of the destination IP address routes ingress/egress packets to:

the Server Router The virtual servers vSi, i=1…q

c) Satellite modems (see Figure 27)

• Requirement: should allow to regulate the transmission bit rate even at run

time. • Solution at IP level: adoption of Token Bucket Flow (TBF) queue discipline at

the output of the i-th link of the ingress router to limit transmission bit rate.

Figure 27: Terminals and Server sub-networks Emulation

d) Satellite bearers (see Figure 28)

For the single i-th satellite bearer (i=1,2…,P) the emulation is shown in Figure 28.

G A 826152 P a g e 36 | 40

Figure 28: Satellite bearers

• Considered technologies for satellite emulator implementation

a) Lightweight virtualization (namespaces)

LXC (Linux Containers) is a lightweight virtualization system. It allows to create (within a Linux machine) multiple environments (or containers), each of them being invisible and impervious to the others. LXC is similar to OpenVZ, VServer, FreeBSD jails, or even Solaris Zones: they can all be seen as improvements over a basic “chroot”, isolating processes within a common host kernel, with very low overhead. This contrasts with KVM, Xen, or VirtualBox, which all emulate a complete machine, with its own kernel, and a higher overhead. Of course, virtual machines have their advantages as well: for instance, they make it possible to run a Windows VM inside a Linux machine (or vice versa), while LXC only deals with Linux processes. LXC relies on two significant feature sets of the kernel: kernel namespaces, and control groups. Kernel namespaces provide basic isolation, making sure that each container cannot “see” or affect other containers.

b) Netem

To limit the outgoing traffic on an interface, the Token Bucket Filter or “tbf qdisc” is used. In the tbf queuing discipline each outgoing traffic byte is serviced by a single token. These tokens are refreshed at the desired output rate. Tokens are saved up in a bucket of limited size, so smaller bursts of traffic can still be handled at a higher rate.

c) Queue disciplines

To limit the outgoing traffic on an interface, the Token Bucket Filter or “tbf qdisc” is used. In the tbf queuing discipline each outgoing traffic byte is serviced by a single token. These tokens are refreshed at the desired output rate. Tokens are saved up in a bucket of limited size, so smaller bursts of traffic can still be handled at a higher rate.

G A 826152 P a g e 37 | 40

• Considered IP Impairment distribution

The delay impairment distribution models can be implemented by EMULRADIO4RAIL platform are:

• Normal • Pareto • Paretonormal • Custom (personalized)

G A 826152 P a g e 38 | 40

7.8. Control infrastructure The control infrastructure is in charge of configuring the complete emulation architecture. It is made of: - A control PC running a User Interface in which all the parameter of the emulation platform

can be configured. Once the configuration is ready, it sends it to the different devices using Ethernet based communication. Each device is in charge of receiving this information and applying it.

- Several network switches in charge of interconnecting the several devices. Considering that control/configuration information will be distributed via Ethernet connections.

- An external Ethernet port connected to the control infrastructure is foreseen so that the emulation platform can be operated and controlled remotely.

The control infrastructure description will be updated when the platforms will be operational.

G A 826152 P a g e 39 | 40

8. Conclusions The EMULRADIO4RAIL project intends to develop an innovative platform for tests and validation of various radio access technologies (Wi-Fi, LTE, LTE-A and Satellite). The proposed platform aims to couple Channel emulators and Network emulators into a single emulation platform so that a very realistic, testing platform from physical layer to IP level can be offered. As explained previously, GSM-R was excluded from the emulation platform after preliminary discussions with X2RAIL-3 WP3 partners because GSM-R is not included in the ACS in development. Besides, due to non-maturity of 5G features today, 5G has also been excluded, although the methodology developed for LTE using OAI will be transposable to OAI 5G NR as well as OAI 5G Core, with basic software updates, when available. During the execution of the initial steps of Task T3.1 and during the development of this deliverable D3.1, both a high-level and low-level design description of the complete emulation platform to be developed and tested has been carried out. The high-level design aims to present the modular architecture that has been defined and the different configuration options. The low-level design details each of the blocks in which the full emulation platform is divided. Namely: RF channel emulator(s), Interference generator(s), LTE emulation platform, Wi-Fi emulation platform, Backhaul/PLMN emulation platform, Satellite emulation platform and Control infrastructure. These high-level and low-level design descriptions aim to be the starting point and design guide for the implementation of the emulation platform to be carried out in Task T3.1. As has been stated during the document, the presented architecture represents the complete emulation architecture and all the blocks/capabilities that will be developed. However, the final user of the platform (e.g. X2RAIL-3 WP3 partners) will be able to use only the ones they need and in the way they require. Finally, it has to be stated that due to the IP level nature of the emulation platform (at least in its full-architecture configuration) the possibility of remotely using and controlling the platform is foreseen. This would also enable the possibility of having a geographically distributed platform in which each of the sub-platforms (LTE emulation platform, Wi-Fi emulation platform… etc.) could be placed in a different country.

G A 826152 P a g e 40 | 40

9. References [1] R. Torrego, "D2.1 - Solutions to emulate the Radio Bearer (stream b),"

EMULRADIO4RAIL project deliverable 2019. [2] J. Moreno, "D1.1 - Application layer requirements for communications systems in

railway environments (stream a)," EMULRADIO4RAIL project deliverable 2019.