Dedicated Testing Environment for TSN Deterministic Networking

Testing environment dedicated for TSN deterministic networking based on COTS devices Henryk Gierszal, Krzysztof Romanowski, Mateusz Rajewski, Jaros aw Kwiatkowski, David Jameux, Tomasz Szewczyk, Barth l my Attanasio www.itti.com.pl

Plan of presentation Introduction Emulation environment Results Conclusions www.itti.com.pl 2

Introduction The deterministic networking paradigm is being more and more addressed for future space missions (e.g. ESA SAVOIR OSRA-NET study) There is a need to implement on-board communication networks with high Quality of Service (QoS) The project aimed at: evaluating the performance of the Time-Sensitive Networking (TSN) protocols for scenarios involving Attitude and Orbit Control System (AOCS) and payload testing specific hardware network devices of TSN protocols building demo bench (testing) systems as reusable software and installable on commodity hardware like Personal Computers (PCs) providing a proposed Extensible Markup Language (XML) representation schema for TSN networks performing interoperability testing for evaluation of the TSN protocols in a multi-vendor environment with different switches www.itti.com.pl 3

Emulation environment Emulated sensors and activators used in the satellite Different emulation scenarios with: network topologies that can be: simple (a limited number of on-board devices) comprehensive (a full set of on-board devices) various number of hardware switch and emulated end-devices XML representations to represent: on-board devices (transmitter, receiver and switch) on-board network topology link phenomena (that could disturb the transmission) www.itti.com.pl 4

Emulation environment (2) Applications to: set up and manage an emulator of the on-board device in order to set: the frequency of the transmission generated by the on-board device the typical volume of the cargo to be encapsulated in the Ethernet frame payload execute a run-time of the emulator in the computer configure TSN switches with a Graphical User Interface (GUI) adequate to a given type of the switch For development of the environment the following platforms were used: C++ for the emulator of source flows transmitted by a device; shell scripts for: configuring switches using their API; running tests with on-board devices emulated; C++ with Qt widgets for: the tool used for management of test campaigns; the tool used for configuration of protocols in the switches. www.itti.com.pl 5

Use cases Payload in the Loop Applications - in two versions: Active Line of Sight Fine Guidance Sensor Robotic Application Mission Data Routing www.itti.com.pl 6

Use cases (2) www.itti.com.pl 7

Emulated on-board device A single on-board device emulated can handle many traffic flows controlled for Tx and Rx directions Each on-board device is described by: max cargo size (bits) frequency (Hz) of data sending typical bit rate (Mbps) accepted jitter (ms) accepted latency (ms) a flag if the time stamp (8 octets) is needed www.itti.com.pl 8

Tests TSN protocols: IEEE 802.1p traffic prioritizing IEEE 802.1Qav traffic shaping IEEE 802.1Qbv traffic scheduling IEEE 802.1Qci filtering and policing Switches: NXP LS1021ATSN NXP LS1028ARDB Kontron PCIE-0400-TSN www.itti.com.pl 9

Test scenarios Scenarios are based on two use cases: Mission Data Routing: Scenario 1: 6 devices and one switch Scenario 2: 10 devices and two switches Robotic Application: Scenario 3: 47 devices and one switch Scenario 4: 47 devices and two switches (figure) www.itti.com.pl 10

Results for IEEE 802.1Qbv Using frame scheduling based on IEEE 802.1Qbv protocol, the results for most critical traffic generated by Gyros and Force Sensors were better as compared to using only IEEE 802.1p With NXP LS1028ARDB switch, the best-effort bandwidth is also maintained The Round Trip Time (RTT) latency increased when more bandwidth was allocated for best effort traffic (figure: different relations in time slot parameters) www.itti.com.pl 11

Results for IEEE 802.1Qbv - scheduling NXP LS1021ATSN switch Configurations no. 3 and no. 4 allowed obtaining a stable transmission with low delay for switches by NXP and Kontron Configuration Time for the lower priorities [ms] No scheduling 0.5 0.05 0.02 Time for the highest priority [ms] 1 2 3 4 0.5 0.05 0.03 Kontron PCIE-0400-TSN switch www.itti.com.pl 12

Tests with 48 devices in the network If a number of on-board devices was increased to all 48 nodes, the best results were achieved for Kontron PCIE-0400-TSN switches (using only IEEE 802.1p standard). Version Allowed priority 0, 1, 2, 3, 6 4 5 7 0, 1, 2, 3, 6 4 5 7 0, 1, 2, 3, 6 4 5 7 Time [ s] 25 25 25 25 50 16.67 16.67 16.67 35 21.67 21.67 21.67 Initial In the case of NXP LS1028ARDB switches, with scheduling configured (initial configuration), there were very large losses for Best Effort traffic, and also the latency values for Gyros and Force Sensors were quite far from expected. Modification A Modification B After modification of the scheduling scheme (configuration B) it was possible to reduce the latency for Gyros and Force Sensors. www.itti.com.pl 13

Results for modified configuration (B) of the scheduler red - the expected values are exceeded, yellow - measured value differs from the expected value, green - measured value is close to the expected value Results NXP LS1028ARDB Expected values Configuration of scheduler A Configuration of scheduler B Jitter of delay [ s] Band- width [Mbps] Jitter of delay [ s] Band width [Mbps] Jitter of delay [ s] Band width [Mbps] Device Delay [ s] Delay [ s] Delay [ s] Priority FLR [%] FLR [%] GYRO 1 GYRO 2 GYRO 3 Observation Payload FORCE SENSOR 1 FORCE SENSOR 2 FORCE SENSOR 3 FORCE SENSOR 4 0.58 0.58 0.58 100 100 100 100 100 100 7 7 7 0.58 0.58 0.58 169.38 70.42 164.27 70.05 165.28 70.81 2278.9 9 5.54e-05 0.e+00 0.e+00 0.58 0.58 0.58 185.48 181.47 185.06 61.92 62.76 61.87 2.74e-05 5.48e-05 5.48e-05 800 100 100 1 400.01 848.78 1.23e+01 600.01 1622.49 611.79 4.79e+00 0.58 100 100 7 0.58 171.93 70.13 0.e+00 0.58 195.59 56.84 0.e+00 0.58 100 100 7 0.58 168.54 69.63 0.e+00 0.58 193.45 59.45 0.e+00 0.58 100 100 7 0.58 164.69 68.74 0.e+00 0.58 189.86 61.95 2.74e-05 0.58 100 100 7 0.58 166.17 72.28 2.77e-05 0.58 187.72 61.77 2.74e-05 www.itti.com.pl 14

Conclusions TSN switches have different functionality depending on manufactures Due to the limited demand the COTS TSN switches used in the project can be seen rather as a proof-of-concept solutions than carrier-/enterprise-grade devices Resulting from firmware some technical problems remained unsolved, e.g. with implementation of link reliability features based on IEEE 802.1CB Support duration from the manufactures is relatively short Products of different generations built by the same manufacturer have different configuration requirements and APIs because they use different hardware (e.g. FPGA of a different generation) Such COTS products are not mature enough to be fully reliable for implementation in on-board networks even for laboratory evaluations TSN-based solutions seem to be still a niche because the number of applications and the volume of the demand are rather limited www.itti.com.pl 15