Bachelorarbeit
Torben Wille
Simulationsbasierte Analyse von Frame-Preemption für Time
Sensitive Network Ethernet
Fakultät Technik und Informatik
Studiendepartment Informatik
Faculty of Engineering and Computer Science
Department of Computer Science
Torben Wille
Simulationsbasierte Analyse von Frame-Preemption für Time
Sensitive Network Ethernet
Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung
im Studiengang Bachelor of Science Technische Informatik
am Department Informatik
der Fakultät Technik und Informatik
der Hochschule für Angewandte Wissenschaften Hamburg
Betreuender Prüfer: Prof. Dr. Korf
Zweitgutachter: Prof. Dr. Fohl
Eingereicht am: 22. Juli 2015
Torben Wille
Thema der Arbeit
Simulationsbasierte Analyse von Frame-Preemption für Time Sensitive Network Ethernet
Stichworte
Frame-Preemption, TSN, Time-Triggered Ethernet, OMNeT++, CoRE4INET, INET
Kurzzusammenfassung
Diese Dokument zeigt einen Ansatz wie Frame-Preemption in Time Sensetive Network Ethernet
umgesetzt werden kann. Mit Hilfe der Simulationsumgebung OMNeT++ und dem CoRE4INET
Framework, welches Time-Triggered Ethernet implementiert, wird die Implementierung des
Ansatzes mit einer abstrahierten Kommunikations-Matrix analysiert, evaluiert und bewertet.
Torben Wille
Title of the paper
Simulation based analysis of frame preemption for Time Sensitive Network Ethernet
Keywords
Frame-Preemption, TSN, Time-Triggered Ethernet, OMNeT++, CoRE4INET, INET
Abstract
This document presents an approach how frame preemption can be implemented in Time
Sensetive Network Ethernet. Using the simulation environment OMNeT ++ and the CoRE4INET
Framwork that implements Time-Triggered Ethernet, the implementation of the approach is
analyzed and evaluated based on an abstract communication matrix.
Inhaltsverzeichnis
1 Einleitung
1
2 Grundlagen
2.1 Time-Triggered Ethernet . . . . . . . . . .
2.1.1 Kommunikationsklassen . . . . . .
2.1.2 Synchronisation der lokalen Uhren
2.2 Die Simulationsumgebung OMNeT++ . . .
2.2.1 Die Beschreibungssprache NED . .
2.2.2 Konfiguration einer Simulation . .
.
.
.
.
.
.
4
4
4
6
7
7
8
.
.
.
.
.
.
.
.
.
.
10
10
10
11
13
14
4 Konzept
4.1 Zwei mögliche Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Frame-Preemption in der LLC Schicht . . . . . . . . . . . . . . . . .
4.1.2 Frame-Preemption nach der Time-Sensetive-Networking Task Group
4.2 Das Konzept für die Implementierung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
16
16
16
17
17
3 Analyse und Anforderungen
3.1 Frame-Preemption . . . . .
3.1.1 Problemstellung . .
3.1.2 Lösungsansätze . .
3.2 Verwandte Arbeiten . . . .
3.3 Anforderungen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Implementierung
18
6 Qualitätssicherung und Evaluation
19
7 Fazit und Ausblick
20
iv
Abbildungsverzeichnis
1.1
Bordnetz im Auto (Quelle: IAV GmbH (2014)) . . . . . . . . . . . . . . . . . . .
1
2.1
2.2
Kompatibilität der Standards (Steiner u. a. (2009)) . . . . . . . . . . . . . . . .
Zweiphasen-Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
3.1
3.2
Standard Ethernet und TTEthernet Scheduling . . . . . . . . . . . . . . . . . .
Frame-Preemption Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
12
4.1
Ausschnitt Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
v
Listings
2.1
2.2
NED Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
omnetpp.ini Konfigurationsdatei . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
8
8
1 Einleitung
Die folgende Arbeit entstand in der Communication over Real-time Ethernet Forschungsgruppe
(CoRE RG (2015)) an der HAW Hamburg. In dieser Forschungsgruppe wird an neuen Echtzeit
Ethernet Kommunikationslösungen für den Automotive und Flugzeug Bereich geforscht.
Abbildung 1.1: Bordnetz im Auto (Quelle: IAV GmbH (2014))
Durch die Entwicklung von neuen Fahrerassistenz-, Sicherheits-, Infotainment- und Komfortsystemen, die den Fahrer unterstützen, steigt die Anzahl der Steuergeräte und verschiedenen
Nachrichtentypen, in Bordnetzen moderner Kraftfahrzeuge stetig an (s. Abb. 1.1). Das sind
zum Beispiel Nachrichten von einer Rückfahrkamera die eine hohe Bandbreite benötigen oder
Nachrichten mit einer niedrigen Latenzanforderung zur Steuerung des Antiblockiersystems.
Die heute eingesetzten Bussysteme wie FlexRay, CAN oder MOST stoßen durch den erhöhten
Kommunikationsaufwand an ihre Grenzen und können die Anforderungen an die Bandbreite
1
1 Einleitung
in naher Zukunft nicht mehr erfüllen.
Daher werden neue Lösungen gesucht, wobei das weit verbreitete Ethernet eine vergleichsweise kostengünstige Alternative zu den jetzigen Bussystemen darstellt. Das Standard Ethernet
IEEE 802.3 Protokoll ist allerdings nicht ohne weiteres im Automotive Bereich einsetzbar, es
erfüllt zwar die Bandbreitenanforderung, ist aber nicht für Systeme mit harten Echtzeitanforderungen geeignet. Dadurch dass Ethernet nicht deterministisch ist, kann nicht sichergestellt
werden, dass zeitkritische Nachrichten innerhalb vorgegebener Zeitfenster beim Empfänger
eintreffen.
Deshalb hat das Institute of Electrical and Electronics Engineers (IEEE (2015)) die Time Sensetive Networking Task Group (IEEE TSN Task Group (2015)) gegründet, die sich damit beschäftigt die Funktionalität von Ethernet um echtzeitfähige Protokolle zu erweitern. Dafür
eignet sich das TDMA-Verfahren. Beim TDMA-Verfahren wird jedem Sender im Netzwerk
ein festes Übertragungsfenster für den Versand von Echtzeit-Paketen, das sind Pakete mit
harten Echtzeitanforderungen, zugewiesen. Niedrig priorisierte Pakete, die vor dem nächsten
zu übertragenen Echtzeit-Paket nicht komplett übertragen werden können, müssen verzögert
werden. Durch diese Verzögerungen entstehen Lücken in denen keine Daten versendet werden.
Dies wirkt sich negativ auf die ausgenutzte Bandbreite aus.
Um solche unerwünschten Lücken und Verzögerungen zu unterbinden, diskutiert die TSN
Task Group derzeit über die Erweiterung von Ethernet um Frame-Preemption. Unter FramePreemption versteht man das unterbrechen eines Ethernet Frames. Die TSN Task Group nutzt
Frame-Preemption, um niedrig priorisierte Nachrichten zugunsten von Echtzeit-Paketen zu
unterbrechen (vgl. IEEE 802.1Qbu (2015)).
Das Ziel dieser Arbeit besteht aus der Erweiterung des CoRE4INET Simulationsframework
um Frame-Preemption. Das CoRE4INET Framework basiert auf dem Time-Triggered Ethernet Protokoll, welches das TDMA Verfahren nutzt, und wurde für die Simulationsumgebung
OMNeT++ entwickelt. Mit Frame-Preemption lässt sich die verfügbare Bandbreite durch niedrig priorisierte Pakete besser ausnutzen. Dies wird an charakteristischen Netzwerken in der
Simulationsumgebung OMNeT++ analysiert. Die Analyse findet auf Basis einer abstrahierten
Kommunikations-Matrix statt.
Die Gliederung der Arbeit sieht wie folgt aus: In Kapitel 2 werden die Grundlagen, die zum
besseren Verständnis der Arbeit dienen, erläutert. In Kapitel 3 folgt eine Analyse von Frame-
2
1 Einleitung
Preemption, verwandten Arbeiten und den Anforderungen an Frame-Preemption. Das Kapitel
4 beschreibt verschiedene Konzepte wie Frame-Premption umgesetzt werden kann und das umzusetzende Konzept. Kapitel 5 beinhaltet die Umsetzung anhand dem in Kapitel 4 erarbeitetem
Konzept. In Kapitel 6 folgt die Qualitätssicherung, Evaluation und Bewertung der Implementierung anhand von Tests und Fallbeispielen. Im letzten Kapitel gibt es eine Zusammenfassung
der Arbeit und einen Ausblick auf zukünftige Projekte.
3
2 Grundlagen
Im folgenden Kapitel werden die Grundlagen erläutert, die zum weiteren Verständnis dieser Arbeit wichtig sind. Zuerst wird das Time-Triggered Ethernet Protokoll und danach die
Simulationsumgebung OMNeT++ betrachtet.
2.1 Time-Triggered Ethernet
Time-Triggered Ethernet (TTEthernet) ist eine Erweiterung von Standard Ethernet, die es erlaubt asynchrone und synchrone Nachrichten im selben physikalischen Netzwerk zu versenden.
Damit unterstützt TTEthernet Anwendungsbereiche mit unterschiedlichen Anforderungen
an zeitliche Vorgaben. TTEthernet bietet deterministisches Verhalten, mit niedriger Latenz
und niedrigem Jitter, für zeitkritische Anwendungen. Außerdem ist TTEthernert vollständig
kompatibel mit Standard Ethernet, somit können Geräte beider Typen in ein bestehendes
Netzwerk integriert oder aus diesem entfernt werden. Entwickelt wurde TTEthernet von der
Firma TTTech Computertechnik AG (TTTech (2015)) und standardisiert durch die Society of
Automotive Engineers (SAE (2011)).
2.1.1 Kommunikationsklassen
TTEthernet unterscheidet zwischen drei verschiedenen Kommunikationsklassen: Time-Triggered
(TT), Rate-Constrained (RC) und Best-Effort (BE) Kommunikation. Die drei Klassen unterscheiden sich hinsichtlich ihrer Qualität und Versandstrategie.
Time-Triggered
TT Kommunikation basiert auf dem TDMA-Verfahren, in einem Konfliktfreien Offline-Scheduling
wird festgelegt in welchen Zeitfenstern jeder TTEthernet Knoten im Netzwerk TT Nachrichten versendet und empfängt. Dies setzt eine gemeinsame Zeitbasis aller TTEthernet Knoten
voraus, die durch eine Synchronisation, der lokalen Uhren, der Knoten erreicht wird. Des
weiteren haben TT Nachrichten die höchste Priorität und werden bevorzugt behandelt. Sollte
es zwischen einer TT Nachricht und einer RC oder BE Nachricht einen Konflikt geben, so wird
4
2 Grundlagen
die RC oder BE Nachricht verzögert. TT Nachrichten werden für Anwendungen mit harten
Echtzeitanforderungen genutzt.
Rate-Constrained
Bei der RC Kommunikation stellt jeder Sender eine gewisse Bandbreite für RC Nachrichten zur
Verfügung. Die Beschränkung der Bandbreite wird wie folgt realisiert: Im Sender werden zwei
aufeinanderfolgende RC Nachrichten durch eine konfigurierbare minimale Laufzeit versetzt
von einander übertragen. Dies ermöglicht es maximale Werte für die Nachrichtenverzögerung
und den Jitter zu ermitteln (vgl. Obermaisser (2012)). Verwendung findet RC Kommunikation
wenn deterministische und zeitliche Anforderungen nicht so strikt sind wie bei der TT Kommunikation. RC Kommunikation basiert auf dem ARINC 664 part 7 Standard (ARINC (2002)),
auch Avionics Full-Duplex Switched Ethernet (AFDX) genannt.
Best-Effort
Die Übertragung von BE Nachrichten erfolgt nach dem Standard Ethernet Ansatz. Es kann
keine Voraussage getroffen werden, ob oder wann eine BE Nachricht gesendet wird und ob
die BE Nachricht beim Empfänger eintrifft. BE Nachrichten haben die niedrigste Priorität und
nutzen die verbliebene Bandbreite, die nicht durch TT oder RC Nachrichten belegt wurde. BE
Kommunikation ist für Anwendungen ohne zeitliche Garantien geeignet.
Abbildung 2.1: Kompatibilität der Standards (Steiner u. a. (2009))
5
2 Grundlagen
Wie in Abbildung 2.1 dargestellt ist das TTEthernet Frame Format kompatibel mit dem Standard
Ethernet (IEEE 802.3) Frame Format. Bei einer TT Nachricht werden die ersten Bytes der Payload
für einen zusätzlichen TT Header verwendet.
2.1.2 Synchronisation der lokalen Uhren
Die Uhren-Synchronisation aller Netzwerkteilnehmer ist unabdingbar für die Übertragung von
TT Nachrichten. Die Uhren werden mit einem Fehlertoleranten Zweiphasen-Synchronisationsprotokoll
synchronisiert. Für die Kommunikation während der Synchronisation wird eine extra Nachrichtenklasse eingeführt, die sogenannten Protocol Control Frames (PCF), welche ebenfalls auf dem
Standard Ethernet Frame Format basieren. Jedem TTEthernet Knoten wird für die Synchronisa-
Abbildung 2.2: Zweiphasen-Synchronisation
tion eine der drei folgenden Rollen zugewiesen: Synchronisation-Master, Compression-Master
und Synchronisation-Client. Die Synchronisation-Master beginnen die Synchronisation, die
Compression-Master berechnen die neue globale Zeit und die Synchronisation-Clients empfangen die globale Zeit (vgl. Steinbach u. a. (2011)). In der ersten Phase, senden alle Synchronisation-
6
2 Grundlagen
Master ein PCF an die Compression-Master. In der zweiten Phase, berechnen die CompressionMaster anhand der Empfangszeitpunkte aller PCF’s die neue globale Zeit und verteilen diese
in einem neuen PCF an alle Synchronisation-Master und -Clients (siehe Abb. 2.2).
2.2 Die Simulationsumgebung OMNeT++
„OMNeT++ is an extensible, modular, component-based C++ simulation library and framework,
primarily for building network simulators.“ (OpenSim Ltd. (2015))
Hierbei bedeutet Network nicht nur Ethernet Netzwerke, sondern verschiedenste Arten von
kabelloser und kabelgebundener Kommunikation.
OMNeT++ ist eine diskrete eventbasierte Simulation, dass heißt die Simulation schreitet nur
beim eintreten zeitlich diskreter Events weiter voran und es wird angenommen, dass zwischen
zwei aufeinanderfolgenden Events nichts passiert. In einem Ethernet Netzwerk zum Beispiel,
sind der Start einer Nachrichtenübertragung und das Ende einer Nachrichtenübertragung
Events.
Eine der wichtigsten Eigenschaften von OMNeT++ sind die Simulationsmodelle, die auf einer
Komponentenarchitektur aufbauen. Ein Modell besteht aus einer Vielzahl von wiederverwendbaren Komponenten, auch Module genannt. Ein Modul kann über ein Gate mit einem anderen
Modul verbunden werden, mehrere Module miteinander kombiniert ergeben ein zusammengesetztes Modul und kommunizieren tun Module durch den Austausch von Nachrichten. Die
Tiefe eines zusammengesetzten Moduls ist nicht begrenzt. Die Module auf der untersten Ebene
der Hierarchie enthalten die Logik und werden in C++ programmiert (vgl. OMNeT++ Manual
(2015)).
Zur Ausführung einer Simulation stellt OMNeT++ zwei verschiedene Benutzerschnittstellen
zur Verfügung. Zum einen gibt es die Möglichkeit eine Simulation über eine animierte grafische
Oberfläche zu starten oder über die textbasierte Kommandozeile.
2.2.1 Die Beschreibungssprache NED
NED steht für Network Description was ins deutsche übersetzt Netzwerkbeschreibung heißt.
Mit NED kann der Anwender sein eigenes Netzwerk beschreiben, aus welchen Modulen und
zusammengesetzten Modulen es besteht und wie diese untereinander verbunden sind.
Das folgende Listing 2.1 zeigt die Beschreibung eines einfachen Moduls Node und eines Netzwerks Test. Test ist ein Netzwerk, welches aus den beiden Submodulen node1 und node2 zusammengesetzt ist. Die beiden Submodule sind Instanzen vom Modul-Typ Node und sind über ihre
Input und Output Gates miteinander verbunden. In beide Richtungen ist eine Übertragungsver-
7
2 Grundlagen
zögerung von 100ms definiert. Node ist ein einfaches Modul und hat ein Input und ein Output
Gate. Da Node ein Modul auf der untersten Ebene der Hierarchie ist wird die zugehörige Logik
in C++ implementiert.
1
2
3
4
5
6
simple Node
{
gates:
input in;
output out;
}
7
8
9
10
11
12
13
14
15
16
network Test
{
submodules:
node1: Node;
node2: Node;
connections:
node1.out --> { delay = 100ms; } --> node2.in;
node1.in <-- { delay = 100ms; } <-- node2.out;
}
Listing 2.1: NED Beispiel
2.2.2 Konfiguration einer Simulation
Damit eine Simulation gestartet werden kann, muss eine omnetpp.ini Konfigurationsdatei
vorhanden sein.
1
2
3
4
5
6
[General]
network = Test
sim-time-limit = 100s
debug-on-errors = true
#record-eventlog = true
**.vector-recording = false
7
8
include anotherConfig.ini
9
10
11
12
[Config Recording]
*.node1.vector-recording = true
*.node2.vector-recording = true
Listing 2.2: omnetpp.ini Konfigurationsdatei
8
2 Grundlagen
In Listing 2.2 ist eine omnetpp.ini Konfigurationsdatei beispielhaft dargestellt. Die Konfigurationsdatei ist in zwei Abschnitte mit den Namen [General] und [Config Recording] eingeteilt,
jeder Abschnitt kann mehrere Einträge enthalten. Eine Konfigurationsdatei kann einen [General] Abschnitt und mehrere [Config <Name>] Abschnitte enthalten. Einträge in einem
Abschnitt werden als Schlüssel-Wert Zeilen (Zeile 2-4, 6 und 10-11) oder Direktive Zeilen (Zeile
8) angegeben (vgl. OMNeT++ Manual (2015)). In Zeile 5 ist ein Kommentar zu sehen, welcher
mit einem # eingeleitet wird. Es lassen sich auch andere Konfigurationsdateien inkludieren,
zu sehen in Zeile 8, somit kann man die Konfiguration übersichtlicher gestalten. Die wohl
wichtigste Konfigurationsoption ist network in Zeile 2, denn dort wird das Netzwerk (Modell)
angegeben welches simuliert wird, ohne diese Angabe kann die Simulation nicht starten.
9
3 Analyse und Anforderungen
Dieses Kapitel geht auf Frame-Preemption, dessen Anforderungen und mögliche Lösungen
ein. Zudem gebe ich einen Einblick in verwandte Arbeiten, die sich ebenfalls mit dem Thema
Frame-Preemption beschäftigen. Am Ende des Kapitels werden die Anforderungen an FramePreemption beschrieben.
3.1 Frame-Preemption
Der Begriff Frame-Preemption beschreibt ein Verfahren, mit dem ein in der Übertragung
befindliches niedrig priorisiertes Frame unterbrochen wird, um ein höher priorisiertes Frame bevorzugt zu übertragen. Nach der Übertragung des höher priorisierten Frame wird die
Übertragung des unterbrochenen Frame wiederaufgenommen.
In der Automobilbranche liegen die Anforderungen an die maximale Latenz von kritischen
Daten bei 100 µs über drei Switches, bei einer Übertragungsrate von 100 Mbit/s oder höher.
Anders sieht es bei den Anforderungen in der Industrie aus, dort wird bei einer Übertragungsrate von 1 Gbit/s oder höher eine maximale Verzögerung von weniger als 5 µs pro Switch
gefordert. Diese Anforderungen können von Standard Ethernet nicht erfüllt werden (siehe
Unterkapitel 3.1.1). Aus diesem Grund wird ein Mechanismus wie Frame-Preemption benötigt.
(vgl. Kim (2011))
3.1.1 Problemstellung
Wie im Ethernet Schedule in Abbildung 3.1 zu sehen ist, kann das hoch priorisierte Frame
A aufgrund des Best-Effort Prinzips erst nach dem kompletten Frame C übertragen werden.
Dadurch kann es im schlimmsten Fall, wenn ein maximales Ethernet Frame mit einer Bandbreite
von 100 Mbit/s übertragen wird, zu einer Verzögerung von ungefähr 122 µs kommen (siehe
Gleichung 3.1).
1526 B
≈ 122 µs
12 500 000 B/s
10
(3.1)
3 Analyse und Anforderungen
Bei einer Bandbreite von 1 Gbit/s kommt es im schlimmsten Fall zu einer Verzögerung von
circa 12 µs (siehe Gleichung 3.2).
1526 B
≈ 12 µs
125 000 000 B/s
(3.2)
Die Anforderungen aus der Automobilbranche und Industrie können mit solchen Verzögerungen nicht erfüllt werden.
Abbildung 3.1: Standard Ethernet und TTEthernet Scheduling
In Abbildung 3.1 ist außerdem ein TTEthernet Schedule dargestellt. Wie in Kapitel 2.1 beschrieben, werden BE und RC Frames solange verzögert, bis das TT Frame ohne Verzögerung
übertragen werden kann. Im Vergleich zum Ethernet Schedule, wird das hoch priorisierte Frame
ohne Verzögerung übertragen, aber die Bandbreite vor diesem bleibt ungenutzt. Daher ist
es für TTEthernet wünschenswert diese Bandbreite für niedrig priorisierte Frames durch
Frame-Preemption auszunutzen. Im folgenden Unterkapitel 3.1.2, zeige ich zwei allgemeine
Lösungsansätze für Frame-Preemption.
3.1.2 Lösungsansätze
Hier folgen zwei Lösungsansätze für Frame-Preemption, die mit Hilfe von Abbildung 3.2 erklärt
werden.
1. Lösung Schedule Ein niedrig priorisiertes Frame C wird zum Zeitpunkt T1 durch das
hoch priorisierte Frame A unterbrochen. Damit wurde der erste Teil von Frame C (C-1)
11
3 Analyse und Anforderungen
übertragen. Zum Zeitpunkt T2 beginnt dann die Übertragung von Frame A. Nachdem
auch Frame B übertragen wurde, welches eine höhere Priorität als Frame C hat, wird
der Rest von Frame C (C-2) zum Zeitpunkt T3 übertragen.
2. Lösung Schedule Der zweite Ansatz ist ähnlich dem ersten, auch hier wird Frame C durch
Frame A zum Zeitpunkt T1 unterbrochen, ebenfalls wird Frame A zum Zeitpunkt T2
übertragen und genauso beginnt die Übertragung von Frame B nach der Übertragung
von Frame A. Die beiden Ansätze unterscheiden sich ab Zeitpunkt T3 , denn im Gegensatz
zum vorherigen Ansatz, wird in diesem Ansatz Frame C komplett neu übertragen und
nicht der Rest, der nach der Unterbrechung übrig bleibt.
Abbildung 3.2: Frame-Preemption Scheduling
Im weiteren Verlauf dieser Arbeit orientiere ich mich am ersten Ansatz. Vergleicht man denn
TTEthernet Schedule aus Abbildung 3.1 mit dem 2. Lösung Schedule aus Abbildung 3.2, so
ähneln sich diese im Schedule zu sehr und man würde keinen Gewinn aus Frame-Preemption
für TTEthernet erzielen. Aber mit dem ersten Ansatz lässt sich die Bandbreite, die vor dem
TT Frame ungenutzt bleibt, durch niedriger priorisierte Frames besser ausnutzen und die
Übertragungsverzögerung dieser Frames sinkt.
12
3 Analyse und Anforderungen
3.2 Verwandte Arbeiten
Dieses Kapitel gibt einen Einblick über verwandte Arbeiten, die sich ebenfalls mit FramePreemption beschäftigen. Im weiteren Verlauf werden die Arbeiten zusammengefasst, dessen
Ergebnisse dargestellt und eine Abgrenzung zu den Zielen dieser Arbeit vorgenommen.
Time-Sensetive Networking Task Group
Die IEEE IEEE TSN Task Group (2015) gehört zur IEEE 802.1 (2015) Working Group und
wie am Namen zu erkennen, arbeiten Sie an der Verbesserung des zeitlichen Verhaltens von
Ethernet. Besonders erwähnenswert hierbei sind die beiden Projekte IEEE 802.1Qbu - FramePreemption und IEEE 802.3br - Interspersing Express Traffic Task Force, welche in Kooperation
an der Erweiterung von Ethernet um einen Frame-Preemption Mechanismus arbeiten. Beide
Projekte befinden sich zurzeit noch in der Entwurfsphase (Draft).
Die 802.1Qbu Projektgruppe erarbeitet die Spezifikationen für die LLC Subschicht der Sicherungsschicht des OSI-Modells und die 802.3br Projektgruppe erarbeitet die Spezifikationen
für die MAC Subschicht. Dies bedeutet, auf der LLC Schicht wird spezifiziert welcher Traffic
anderen Traffic unterbrechen darf und welcher Traffic unterbrechbar ist, und in der MAC
Schicht wird das Unterbrechen von Frames spezifiziert.
Ihr Ziel ist es, dass ein zeitkritisches Paket ein in der Übertragung befindliches normales
Best-Effort Paket unterbrechen kann, um ein oder mehrere zeitkritische Pakete zu übertragen.
Sobald die zeitkritischen Pakete übertragen wurden, wird die Übertragung des unterbrochenen
Pakets wieder fortgesetzt. Außerdem soll ein nicht-zeitkritisches Paket mehrmals unterbrochen
werden können.
Performance Evaluation of IEEE 802.1Qbu: Experimental and Simulation Results
Jia u. a. (2013) stellen in ihrem Bericht ein Konzept und eine mögliche Umsetzung von IEEE
802.1Qbu - Preemptive Priority Frame Forwarding vor, und realisieren diese in der MAC Schicht
von Gigabit Ethernet. Ihre Umsetzung evaluieren Sie ebenfalls mit Hilfe einer Simulation,
hier aber mit der Simulation eines Gigabit Ethernet Netzwerk. Dabei vergleichen Sie die Performanz ihres Frame-Preemption Mechanismus mit anderen Non-Frame-Preemption Queuing
Mechanismen.
In ihrem Ansatz werden die Traffic Klassen in zwei verschiedene Kategorien (Prioritäten)
eingeteilt: Time-Critical Frames (TCF) und Non-Time-Critical Frames (NTCF). Im Gegensatz zu
IEEE 802.1Qbu werden TCFs in diesem Ansatz nicht beim senden, sondern beim empfangen
verarbeitet (vor dem Queuing/Scheduling). Dafür führen Sie zwei spezielle Steuersymbole ein:
13
3 Analyse und Anforderungen
HOLD und RETRIEVAL. Empfängt der Empfänger während der Übertragung eines NTCF ein
HOLD Symbol, pausiert der Empfang des NTCF und eine höher priorisierte Empfangsprozedur
für das TCF startet. Sobald der Empfänger ein RETRIEVAL Symbol erkennt, wird der Empfang
des unterbrochenen NTCF fortgesetzt. In ihrem Ansatz es ist möglich das ein NTCF während
der Übertragung mehrmals unterbrochen wird.
Sie kommen am Ende zu dem Ergebnis dass, mit ihrem Frame-Preemption Ansatz die Performanz deutlich besser ist, die durchschnittliche Verzögerung von TCFs auch bei hoher
Hintergrundlast kleiner als 700 ns bleibt und der Jitter mit der Hintergrundlast ansteigt, dabei
aber nicht 460 ns überschreitet.
Im Gegensatz zu diesem Bericht, wird in dieser Arbeit ein anderer Ansatz verfolgt (siehe Kapitel
4) und die Realisierung findet in Time-Sensetive Ethernet Network (Time-Triggered Ethernet)
statt.
3.3 Anforderungen
In dieser Arbeit wird das CoRE4INET Framework um Frame-Preemption erweitert. Die dadurch
nötigen Änderungen am bestehenden Code dürfen keine negativen folgen haben. Auch nach
den Änderungen muss sichergestellt sein, dass der Ablauf des Frameworks ohne aktivierten
Frame-Preemption Mechanismus der selbe ist wie vor den Anpassungen.
Nach der Erweiterung des CoRE4INET Framework soll es möglich sein, dieses mit FramePreemption oder auch ohne Frame-Preemption zu nutzen. Daher muss Frame-Preemption für
einen Netzwerkteilnehmer aktivierbar bzw. deaktivierbar sein.
Bei der Unterbrechung von Frames entstehen sogenannte Fragmente, welche wieder valide Ethernet Frames bilden müssen, daher gibt es einige Anforderungen an die minimale Größe
von Frames und Fragmenten:
• Die Mindestgröße eines unterbrechbaren Frame beträgt 124 Byte, denn daraus entstehen
dann wieder zwei valide Ethernet Frames:
1. ein minimales erstes Fragment mit der Größe von 64 Byte und
2. ein minimales letztes Fragment von 64 Byte
• Für ein unterbrechbares Fragment gilt die selbe Mindestgröße, von 124 Byte, wie für ein
unterbrechbares Frame. Daraus entstehen ebenfalls zwei valide Ethernet Frames:
1. ein minimales Zwischenfragment von 64 Byte und
14
3 Analyse und Anforderungen
2. ein minimales letztes Fragment mit 64 Byte
Die hier aufgeführten Größen sind dem IEEE 802.1Qbu Draft 2.2 (vgl. IEEE P802.1Qbu/D2.2
(2015)) entnommen.
Für Fragmente, die bei einer Unterbrechung eines Frames entstehen, wird ein neues, zum
Standard Ethernet Frame Format kompatibles, Frame Format benötigt.
Damit Frames überhaupt fähig sind andere Frames zu unterbrechen, müssen die Traffic-Klassen
des CoRE4INET Framework gewichtet werden. Daraus ergibt sich die Anforderung, dass den
Traffic-Klassen des CoRE4INET Framework eine Priorität vergeben wird, wodurch höher
priorisierte Frames niedriger priorisierte Frames unterbrechen können.
15
4 Konzept
4.1 Zwei mögliche Konzepte
Dieses Unterkapitel zeigt zwei verschiedene Konzepte, wie Frame-Preemption in Time-Triggered
Ethernet Netzwerken umgesetzt werden kann. Das wäre zum einen, ein Konzept welches FramePreemption in der LLC Schicht beschreibt und zweitens, ein Konzept das Frame-Preemption
nach dem vorhaben der Time-Sensetive Ethernet Networking Task Group beschreibt.
4.1.1 Frame-Preemption in der LLC Schicht
Dieses Konzept zeigt wie Frame-Preemption durchführbar ist, ohne das sich ein unterbrechbares
Frame in der Übertragung befinden muss. Anders ausgedrückt heißt das, dass ein unterbrechbares Frame schon vor Beginn der Übertragung im Sender unterbrochen wird. Dadurch können
aber nur Time-Triggered Frames andere Frames unterbrechen, da nur bei TT Frames durch
das Offline Scheduling im voraus bekannt ist zu welchen Zeitpunkten diese versendet werden. Somit gibt es in diesem Konzept keine Einteilung der Traffic- Klassen in verschiedene
Prioritäten. In Abbildung 4.1 ist zu sehen, dass die LLC Schicht ganze Ethernet Frames an die
MAC Schicht weiterleitet und das die MAC Schicht diese Frames zur Übertragung bitweise
an die Bitübertragungsschicht weitergibt. Daher ist es nicht möglich ein in der Übertragung
befindliches unterbrechbares Frame in der LLC Schicht zu unterbrechen, da es sich in der MAC
Schicht befindet.
Abbildung 4.1: Ausschnitt Schichtenmodell
16
4 Konzept
Ablauf der Unterbrechung von Frames:
Folgend wird Frame als Synonym für Frame und Fragment verwendet, da beide den gleichen
Ablauf haben.
Sobald in der LLC Schicht ein nicht TT Frame aus der Sende-Queue zum Versand an die MAC
Schicht weitergeleitet werden soll, wird überprüft ob dieses komplett vor dem nächsten zu
versendenden TT Frame übertragen werden kann. Für die Überprüfung wird die Zeit bis zum
Beginn der Übertragung des TT Frame in Bytes umgerechnet und mit der Länge des nicht TT
Frame verglichen. Ist die Länge des nicht TT Frame kleiner, dann wird dieses wie gewohnt im
ganzen an die MAC Schicht weitergeleitet.
Wenn die Länge des nicht TT Frame größer ist als die berechnete Länge bis zum Beginn der
Übertragung des TT Frame, dann wird überprüft ob nach der Unterbrechung die Mindestgrößen
der entstehenden Fragmente, in den Anforderungen in Kapitel 3.3 beschrieben, eingehalten
werden können. Bei nicht Einhaltung wird das Frame nicht unterbrochen und wieder an den
Anfang der Sende-Queue befördert. Bei Einhaltung der Mindestgrößen, wird das Frame in zwei
Fragmente unterbrochen. Ein erstes Fragment welches an die MAC Schicht weitergeleitet wird
und ein zweites Fragment, das an den Anfang der Sende-Queue kommt.
4.1.2 Frame-Preemption nach der Time-Sensetive-Networking Task Group
In diesem Konzept wird ein niedrig Priorisiertes Frame während der Übertragung durch ein
höher priorisiertes Frame unterbrochen. Die Traffic-Klassen des Time-Triggered Ethernet
werden in zwei Prioritäten eingeteilt:
1. Express - nicht unterbrechbare Frames
2. Preamptable - unterbrechbare Frames
Express Frames können nur Preamptable Frames unterbrechen, aber keine anderen Express
Frames.
4.2 Das Konzept für die Implementierung
Dieses Konzept orientiert sich am Konzept der TSN Task Group.
17
5 Implementierung
Das Konzept ist in dem OMNeT++ Framework CoRE4INET implementiert.
18
6 Qualitätssicherung und Evaluation
Die Qualitätssicherung und Evaluation sollte mit einer abstrahierten Kommunikationsmatrix
anhand verschiedener Simulationskonfigurationen, vor allem in Bezug auf die Prioritäten,
durchgeführt werden.
19
7 Fazit und Ausblick
Für die Zukunft interessante Projekte wären:
• Frame-Preemption in realer Hardware zu implementieren und zu analysieren wie sich
Frame-Preemption dort verhält
• Nach der Standardisierung der beiden Drafts IEEE 802.1Qbu und IEEE 802.3br zu überprüfen wie Frame-Preemption dort umgesetzt wurde und was dementsprechend angepasst
werden müsste
20
Literaturverzeichnis
Aeronautical Radio Incorporated: Standard 664 part 7. 2002
[ARINC 2002]
CoRE RG: Communication over Real-Time Ethernet. 2015. – URL http:
[CoRE RG 2015]
//core.informatik.haw-hamburg.de
IAV GmbH Ingenieurgesellschaft Auto und Verkehr: Bordnetz. 2014.
[IAV GmbH 2014]
– URL https://www.iav.com/sites/default/files/styles/lightbox-fullsize/public/images/2014/
page/bordnetz.jpg
IEEE: Institute of Electrical and Electronics Engineers. 2015. – URL https:
[IEEE 2015]
//www.ieee.org/index.html
[IEEE 802.1 2015]
Institute of Electrical and Electronics Engineers: IEEE 802.1. 2015.
– URL http://www.ieee802.org/1/
[IEEE 802.1Qbu 2015]
Institute of Electrical and Electronics Engineers: 802.1Qbu -
Frame Preemption. 2015. – URL http://www.ieee802.org/1/pages/802.1bu.html
[IEEE P802.1Qbu/D2.2 2015]
Institute of Electrical and Electronics Engineers: IEEE
P802.1Qbu/D2.2. Mai 2015. – URL http://www.ieee802.org/1/files/private/bu-drafts/d2/
802-1Qbu-d2-2.pdf
[IEEE TSN Task Group 2015]
Institute of Electrical and Electronics Engineers: Time-
Sensitive Networking Task Group. 2015. – URL http://www.ieee802.org/1/pages/tsn.html
[Jia u. a. 2013]
Jia, Wen-Kang ; Liu, Gen-Hen ; Chen, Yaw-Chung: Performance evaluation
of IEEE 802.1Qbu: Experimental and Simulation results. In: Local Computer Networks (LCN),
2013 IEEE 38th Conference on, 2013, S. 659–662. – ISBN 978-1-4799-0536-2
[Kim 2011]
Kim, Yong: IEEE 802.1 & 802.3 Packet Transmission Pre-emption Solution and Pro-
blem Statement. IEEE 802.1 Plenary. Juli 2011. – URL http://www.ieee802.org/1/files/public/
docs2011/new-avb-kim-8021-8023-Preemption-Solution-Problem-Statements-0711-v02.
pdf
21
Literaturverzeichnis
[Obermaisser 2012]
Obermaisser, Roman: Time-Triggered Communication. 3rd. Boca Raton,
FL, USA : CRC Press, Inc., 2012. – ISBN 978-1-4398-4661-2
[OMNeT++ Manual 2015]
OpenSim Ltd.: OMNeT++ - User Manual. 2015. – URL https:
//omnetpp.org/doc/omnetpp/manual/usman.html. – Zugriffsdatum: 21. Juli 2015
OpenSim Ltd.: OMNeT++ - Discrete Event Simulator. 2015. – URL
[OpenSim Ltd. 2015]
https://omnetpp.org/
[SAE 2011]
Society of Automotive Engineers - AS-2D Time Triggered Systems and
Architecture Committee: Time-Triggered Ethernet AS6802. SAE Aerospace. November
2011. – URL http://standards.sae.org/as6802/
[Steinbach u. a. 2011]
Steinbach, Till ; Dieumo Kenfack, Hermand ; Korf, Franz ; Schmidt,
Thomas C.: An Extension of the OMNeT++ INET Framework for Simulating Real-time
Ethernet with High Accuracy. In: Proceedings of the 4th International ICST Conference on
Simulation Tools and Techniques. New York : ACM-DL, März 2011, S. 375–382. – ISBN
978-1-936968-00-8
[Steiner u. a. 2009]
Steiner, W. ; Bauer, G. ; Hall, B. ; Paulitsch, M. ; Varadarajan, S.:
TTEthernet Dataflow Concept. In: 8th IEEE International Symposium on Network Computing
and Applications, 2009. NCA 2009., Juli 2009, S. 319–322
[TTTech 2015]
TTTech Computertechnik AG: Ensuring Reliable Networks TTTech. TT-
Tech Computertechnik AG. 2015. – URL https://www.tttech.com/
22
Hiermit versichere ich, dass ich die vorliegende Arbeit ohne fremde Hilfe selbständig verfasst und
nur die angegebenen Hilfsmittel benutzt habe.
Hamburg, 22. Juli 2015 Torben Wille
© Copyright 2024 ExpyDoc
