ioe.tex

\chapter{Internet of Everything}

Zusammenfassung der Vorlesung "`Internet of Everything"' aus dem Wintersemester 2016.\footnote{\url{http://telematics.tm.kit.edu/ws201617_IoE.php}}

\section{Einführung}
\begin{itemize}
	\item Zielvorstellung: Erhöhung der Lebensqualität in einer zunehmend Technik-geprägten und vernetzten Umgebung
	\item Allerdings verbunden mit ubiquitären Sammeln und Auswerten von Daten, meist beim Hersteller, ohne Kontrolle des Eigentümers
	\item Alltagsbeispiele: Die intelligente Toilette; Lifelogging-Armband; internetfähige Wetterstation, deren Daten auf einer öffentliche Wetterkarte bereitstellt werden, es werden Sprachdaten erfasst, Kommunikation Wetterstation \(\leftrightarrow\) Smartphone-App ausschließlich per Server des Anbieters
	\item Sensor/Aktor, Anwendungsbeispiel Gewächshaus: Sensoren erfassen Umweltdaten, Aktoren setzen Regeln zur Kontrolle um (Wasserzufuhr, Schatten, etc.)
	\item \textbf{Historische Beispiele}
	\begin{itemize}
		\item Great Duck Island (2002): Erforschung des Mikroklimas der unterirdischen Nestern von Sturmschwalben ohne die Tiere zu stören ("`non-intrusive"' und "`non-disruptive"'). Seonsorknoten in den Höhlen der Nestern sowie Basisstation mit direktem Satellitenuplink
		\item ZebraNet (2003): Langfristige Erforschung des Migrationsverhaltens von Zebras durch kontinuierliche Lokalisation sowie Erfassung der biometrischen Daten. Selbstorganisation der Knoten durch großes zu überwachendes Gebiet notwendig (Verbindung Zebra \(\rightarrow\) Zebra günstig, zu einer Basisstation allerdings teuer)
	\end{itemize}
	\item Besonderheiten: Dezentral, selbstorganisierend, limitierte Ressourcen, unzuverlässiger Kommunikationskanal, unsicher (bzgl. IT-Sicherheit)
\end{itemize}



\section{Geräteklassen und Anwendungen}

\subsection{Einführung}
\begin{itemize}
	\item Klassifizierung von Geräten. Beispielsweise nach Anwendungsbreich, Leistungsfähigkeit, Energiebedarf, Lebensdauer, Kosten, Größe/Gewicht, etc.
	\item Auswahl von Geräteklasse und Hardwarekomponenten von konkreter Anwendungsanforderung abhängig
\end{itemize}


\subsection{Klassifikationskriterien}
\begin{itemize}
	\item Energiebedarf: Grundlegende Problematiken bei Energiebschränkung: Bereitstellung durch Batterien oder Kondensatoren oder Umwandlung alternativer Enegieformen aus der Umgebung (\textit{Energy Harvesting})
	\item Deployment-Model: Klassifikation anhand Aufteilung und Ausbringungsort der Komponenten. Logisch-funktionale Aufteilung mittels Systemmodell/Schnittstellen/HW-Ressourcen/Dienste
	\item Sonsoren: Kontext/Technik/Funktionsweise/Messgröße
	\item \textbf{Klassifikation der Leistungsfähigkeit von Objekten im IoE (\texttt{IETF RFC 7228}\footnote{\url{https://tools.ietf.org/html/rfc7228}})}\\\\
	\begin{tabularx}{\linewidth}{l|l|l|X}
		\textbf{Klasse} & \textbf{Data Size (RAM)} & \textbf{Code Size (Flash)} & \textbf{Typische Eigenschaften} \\
		\hline
		\texttt{C0} & \(< 10 KB\) & \(< 100 KB\) & Sichere Internetkommunikation nur über Gateways/Proxies möglich \\
		\hline
		\texttt{C1} & \(\sim 10 KB\) & \(\sim 100 KB\) & Optimiertes IP und UDP, kein HTTP oder TLS \\
		\hline
		\texttt{C2} & \(\sim 50 KB\) & \(\sim 250 KB\) & Energieoptimierte Netzwerkstacks für traditionelle Internet-Protokolle \\
	\end{tabularx}
	\item \textbf{Klassifikation nach Energiebschränkung (\texttt{IETF RFC 7228})}\\\\
	\begin{tabularx}{\linewidth}{l|l|X}
		\textbf{Klasse} & \textbf{Typ der Energiebeschränkung} & \textbf{Beispiel}\\
		\hline
		\texttt{E0} & Beschränkung auf Ereignis & Event-basiertes Harvesting \\
		\hline
		\texttt{E1} & Beschränkung auf Zeitperiode & Batterie, die periodisch aufgeladen wird \\
		\hline
		\texttt{E2} & Lebenszeitbeschränkung & Nicht austauschbare Batterie \\
		\hline
		\texttt{E9} & Keine Beschränkung & Kontinuierliche Stromversorgung \\
	\end{tabularx}
\end{itemize}


\subsection{Hardware und Anwendungen}
\begin{itemize}
	\item Nanonetze: Vernetzte Nanomaschinen, die jeweils nur eine Aufgabe erledigen (Berechnen/Speichern/Messen/Manipulieren). Anwendung beispielsweise in Biomedizin, Militär oder (Chemie-)Industrie. Kommunikation über E. coli Bakterien oder Pheromone (in Wasser)
	\item Smart Dust: Sehr viele kleine (dumme) Knoten, die unaufdringlich in die Umwelt integriert werden. Sehr beschränkte Hardware und viele Probleme und offene Fragen (Skalierbarkeit/Netzdichte/Energieversorgung/Entsorgung)
	\item Klassische Sensornetze: Sehr kleine, maßgeschneiderte Systeme für Einzelanwendungen. Selbstorganisierend, geringe Leistungsaufnahme, Batteriebetrieb (beispielsweise \texttt{Zebranet})
	\item Physical und Embedded Computing: Flexible Systeme aus eingebetteter, miniaturisierter Standardhardware. Kostengünstig und energieeffizient. Einsatzbereiche u.a. Steuerungselektronik, Home Automation, Bastlerprojekte (beispielsweise \texttt{ESP8266})
	\item Smart- und Submetering: Zeitnahe Erfassung und Steuerung von Energieverbräuchen. Große Ansammlung von Geräten und Kommunikationsstandards
	\item Smart Home: Hausautomation und -monitoring durch (drahtlose) Sensornetze mit Steuerung wahlweise vor Ort oder über das Internet. Herausforderungen beispielsweise Nutzbarkeit vs. Sicherheit, Zugriffsschutz, Robustheit, Skalierbarkeit. Privacy bisher kaum umgesetzt; Abhängigkeit von externen Anbietern bei privaten, sicherheitsrelevanten Systemen (Heizung, Rauchmelder, Alarmanlage, etc)
	\item Drohnen und Roboter: Mobile Plattform mit Sensoren und Aktoren zur Messung vor Ort. Einsatzbereiche sind kritische/lebensfeindliche/unzugängliche Gebiete sowie Hilfestellung im menschlichen Umfeld
	\item Wearables: Datenverarbeitung unauffällig in Kleidung oder Körpernähe zur Unterstützung in Alltagssituationen. Verwendung neuartiger Benutzerschnittstellen wie Gestenerkennung, Anwendung beispielsweise Life-Logging
	\item Smartphones: Heutige Schnittstelle des Menschen zum IoE. Leistungsfähige Hardware, die leistungsfähige Kommunikationsinfrastruktur voraussetzt
	\item Single-Board Computer: Eingesetzt in Entwicklungs- und Prototypingumgebungen. Anpassbare bzw. vielfältige Betriebssysteme und kostengünstige Herstellung (beispielsweise Raspberry Pi oder BeagleBone)
	\item Industrie 4.0 / Industrial Internet: Breites Spektrum an unterschiedlicher Hardware. Hohe Anforderungen an Zuverlässigkeit, Robustheit, Langlebigkeit
\end{itemize}


\subsection{Geräteanbindung und Datenmodell}
\begin{itemize}
	\item Betriebssysteme und Programmierung: Große Unterschiede zwischen den Geräteklassen. Hardwarenähe/Abstraktionsebenen/Anzahl Anwendungen pro Gerät/Power- und Speichermanagement. Spezielle (angepasste) Betriebssysteme für die Geräteklassen
	\item Cloudanbindung: Trend zur Interation von IoE-Kleinstgeräten in Cloud für Datenhaltung
\end{itemize}



\section{Privatsphäre}

\subsection{Allgemein}
\begin{itemize}
	\item Problem: Sensoren können über das Internet angegriffen werden
	\item Beispiel RFID als Herausforderung für den Datenschutz: Eindeutige Identifikation jedes Objekts ohne Sichtkontakt möglich. Historie verschiedenster Objekte kann im Vorbeigehen überwacht werden (Kleidungsstücke, Fahrkarten, Inhalt einer Einkaufstasche)
	\item Lösungsansätze: Kill-Befehl, Blocker-Tags, Authentifizierung für Zugriff (z.B. Reisepass), Abreißen der Antenne
	\item Neben den personenbezogenen Daten auch Metadaten schützenswert, da mit ihnen ein Benutzerprofil erstellt werden kann
	\item Säulen der Privatsphäre: Regulierung durch Gesetze; Selbstregulierung durch die Anbieter (Tüv, Trusted Shop, etc.); Selbstschutz durch PETs
	\item Allgemeine IT-Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit (CIA: Confidentiality, Integrity, Availability)
	\item Schutzziele für Privatsphäre: Unverkettbarkeit, Transparenz, Intervenierbarkeit, Nicht-Identifizierbarkeit, Unentdeckbarkeit, (Nicht-) Abstreitbarkeit
	\item Privacy Enhancing Technologies, Technologie zur Verbesserung des Datenschutzes, beispielsweise in RFID-Systemen. Beispielse für Technologien: \texttt{Anonymizer}\footnote{\url{https://de.wikipedia.org/wiki/Anonymizer}}, Shared Online Accounts
	\item \textbf{Prozess zum Entwurf und zur Bewertung}
	\begin{enumerate}
		\item Analyse des Systems: Welche Entitäten sind beteiligt und welcher Dienst wird erbracht?
		\item Erstellen von Vertrauensmodell (Wie viel Vertrauen wird dem Anbieter entgegengebracht?) und Angreifermodell (Kategorisierung des Angreifers nach Motivation/Ressourcen/Ziel/etc.)
		\item Entwurf geeigneter PETs (auf Basis des Angreifermodells)
		\item Bewertung der PETs (auf Basis des Angreifermodells)
	\end{enumerate}
	\item Angreifermodell: Klassifizierung von Angreifern nach Motivation/Ressourcen/Fähigkeiten
	\item \textbf{Klassisches Angreifermodell: "`Dolev-Yao"'-Angreifer}
	\begin{itemize}
		\item Omnipräsent im Netz, kann sämtliche Kommunikation abhören
		\item Kann eigene Dateneinheiten verzeugen und versenden sowie fremden Datenverkehr abhören und modifizieren
		\item Kann nicht Ent-/Verschlüsseln ohne den Schlüssel zu kennen
	\end{itemize}
\end{itemize}


\subsection{Was ist anders im Internet of Everything?}
\begin{itemize}
	\item Technologie greift viel stärker in das private Leben ein \(\rightarrow\) Privatsphäre stärker gefährdet als im klassischen Internet
	\item Technische Herausforderungen: Mehr Daten; kontinuierliche Datenerfassung; sensiblere Daten; Vielfalt von gemessenen Größen
	\item Angreifermodell im IoE: Geräte befinden sich häufig an zugänglichen Orten. Diebstahl/Auslesen/Korrumpieren/Zerstören einfacher \(\rightarrow\) Diensterbringung muss auch dann zuverlässig funktionieren, wenn ein Teil der Geräte korrumpiert worden ist
	\item Dienst muss auch dann zuverlässig funktionieren, wenn ein Angreifer einen Teil der Geräte korrumpiert hat ("`byzantinische"' Fehler) \(\rightarrow\) Herausforderung für Kommunikationsprotokoll (Angreifer wird zum Insider)
	\item Beispiel Smart-Metering: Informationsbedarf für Stromnetz der Zukunft ist enorm. Schutzbedarf nicht nur vor Outsider sondern auch vor Datensenke \(\rightarrow\) klassische Verschlüsselung bietet keine Lösung
	\item Beispiel Smart-Traffic: Dienstanbieter benötigt Positionsdaten für Liveupdates. Selbst ohne Klarnamen können anonyme IDs - die selten wechseln - typischen Routen (beispielsweise die Fahrt zum Arbeitsplatz) zugeordnet werden
	\item IBM-Studie "`Device democracy"': Betreiben einer zentralisierten Cloud verursacht hohe Kosten sowie schwer umzusetzende Privatsphäre \(\rightarrow\) in Zukunft dezentrale Umsetzung
	\item Anforderungen an die verteilte IoE-Cloud: Sicherer Nachrichtenaustausch zwischen Geräten ohne zentrale Vertrauensanker (beispielsweise via "`P2P-Kommunikation"'); Verteilen der Daten; robuste und skalierbare Koordination von Geräten mit Halten eines konsistenten Zustands
\end{itemize}


\subsection{Ansätze zum Schutz der Privatsphäre}
\begin{itemize}
	\item Anwendungsabhängige Anforderungen. Diensterbringung mit dem Prinzip der Datensparsamkeit
	\item Es sollen lediglich Daten erfasst werden, die möglichst wenig Privates preisgeben und die nicht mit Nutzern oder untereinander in Verbindung gebracht werden können (Unverkettbarkeit)
	\item Ansätze: Verschleierung von Sampling-Werten (Präzision herabsetzen oder Störwerte einfügen); Vermeidung von zentralen Datensenken (P2P oder lokale Diensterbringung); Verschleierung der Identität der Quelle; Unverkettbarkeit von Samples gewährleisten (Anpassen der Samplerate)
	\item \textbf{Entwurfsstrategien: Schutz der Privatsphäre}
	\begin{itemize}
		\item Datenorientiert
		\begin{itemize}
			\item MINIMISE: Verarbeitung und Erfassung von Daten auf ein Minimum reduzieren
			\item HIDE: Beziehungen zwischen Datensätzen sollen verborgen werden
			\item SEPARATE: Dezentrale Speicherung und Verarbeitung
			\item AGGREGATE: Aggregierte Verarbeitung personenbezogener Daten
		\end{itemize}
		\item Prozessorientiert
		\begin{itemize}
			\item INFORM: Benutzer sollen über die Verarbeitung ihrer Daten informiert werden (Schutzziel: Transparenz)
			\item CONTROL: Benutzer sollen die Kontrolle über die Verarbeitung ihrer personenbezogenen Daten behalten (Schutzziel: Intervenierbarkeit)
			\item ENFORCE: Erstellen und Durchsetzen einer rechtskonformen Datenschutzrichtlinie
			\item DEMONSTRATE: Bei der Verarbeitung personenbezogener Daten muss die Einhaltung der Datenschutzrichtlinie demonstriert werden können
		\end{itemize}
	\end{itemize}
\end{itemize}

\subsubsection{Blockchain-Grundkurs}
\begin{itemize}
	\item High-Level Vorstellung: Blockchain ist wie ein schwarzes Brett; man kann nur schreiben (mit Zeitstempel) aber nichts löschen
	\item Über P2P-Netz realisiert. Alle Peers kennen die komplette Blockchain, kein Vertrauen untereinenader notwendig
	\item Neue Einträge (\textit{Transaktionen}): Werden an alle Peers geflutet. \textit{Blöcke} bestehen aus mehreren Transaktionen und halten eine Referenz auf den vorherigen Block. Das Finden von gültigen Blöcken (\textit{Mining}) benötigt viele Ressourcen (beispielsweise Rechenzeit durch Lösen von Krypto-Puzzles)
	\item Widersprüchliche Transaktionen werden beim Erstellen von Blöcken ausgeschlossen
	\item Bei parallel erstellten Blöcken entstehen Forks \(\rightarrow\) "`die"' Blockchain ist die längste bekannte Kette gültiger Blöcke
	\item Flexiel einsetzbarer Baustein. Beispielsweise zum Realisieren von Namensdiensten; robusten Zeitstempeln bei Messwerten oder als finanzielle Gegenleistung bei Micropayments
	\item \textbf{Eigene Arbeit: \texttt{BitNym}}
	\begin{itemize}
		\item Problem bei vielen IoE-Anwendungen: Nutzer brauchen fair verteilte, eindeutige Identifier. Privatsphäre: Echte Identitäten sollen verschleiert werden
		\item Ansatz: Ersetze Vertrauensanker (der die Pseudonyme verteilt) durch Blockchain \(\rightarrow\) Pseudonyme werden auf Blockchain abgespeichert. Die Blockchain sichert die Nachvollziehbarkeit der Pseudonymwechsel
	\end{itemize}
\end{itemize}


\subsection{Konkrete Beispiele und Szenarien}
\begin{itemize}
	\item \textbf{Privatheit beim Smart-Metering}
	\begin{itemize}
		\item Ziel: Verbrauch von Energie in Energienetzen oder kundenspezifisch in Echtzeit nachvollziehbar machen. Stromzähler senden hierfür regelmäßig Messdaten über den Internetanschluss des Kunden an den Messdienstleister (MDL)
		\item Gefahr für die Privatsphäre: Periodisches Senden der Messwerte (beispielsweise alle 15 Minuten) liefert ein detailliertes Verbraucherprofil (beispielsweise über Arbeitszeiten, Urlaube, Art der Geräte, Personenzahl). Heutiges einjähriges Ableseintervall stellt impliziten Privatsphäreschutz dar
		\item Generische Lösungsansätze
		\begin{itemize}
			\item Pseudonymisierung: Aufwendige Pseudonymverwaltung sowie Verknüpfbarkeit mit Nutzer (durch IP-Adresse oder mittels externen Daten wie Urlaube oder Arbeitszeit)
			\item Modifikation des Energiebedarfs durch lokalen Akkumulator. Dazu allerdings teurer, sich abnutzender Akku sowie Lade- und Entladestrategie erforderlich
		\end{itemize}
		\item Generische Ansätze unzureichend \(\rightarrow\) anwendungsspezifischer Ansatz nötig: Aggregation der Daten. Dadurch lediglich der summierte Verbrauch einer Region sichtbar
		\item Möglichkeiten zur Aggregation
		\begin{itemize}
			\item Über die Zeit mittels verschiedener Tarifregister: Einfach realisierbar
			\item Über Haushalte, ohne Kooperation der Stromzähler: Hinzufügen von Rauschwerten, die sich bei der Summenbildung gegenseitig eliminieren. Allerdings unrealistisch viele Teilnehmer zur Verschleierung feingranularer Messungen notwendig
			\item Über Haushalte, mit kooperierenden Stromzählern: Einzelne Messwerte vor MDL geschützt; Ausfallschutz durch Redundanz; auf ressourcenbeschränkter Hardware realisierbar. Zusätzlich homomorphe Verschlüsselung baumartig mit Keypair verwendbar, wodurch kein Stromzähler den Wert eines anderen erfährt. Kryptografie allerdings ungeeignet für ressourcenbeschränkte Hardware; einzelne korrumpierte Zähler lassen Rückschlüsse zu
		\end{itemize}
		\item Eigene Arbeit \textit{SMART-ER}: Auf SMART basierendes, privatsphäregerechtes Smart Metering Protocol, das die Benutzer in untereinander kooperierende Gruppen einteilt, die ein gemeinsames Aggregat zur Verfügung stellen
		\begin{itemize}
			\item MDL teilt Stromzähler in Gruppen ein (Gruppengröße konfigurierbar)
			\item Gruppenteilnehmer kooperieren und stellen maskierte, ungefährliche Messwerte mit korrektem Aggregat zur Verfügung
			\item Vorgehen pro Zeitintervall und Zähler. Jeweils lokale Speicherung von \(L\) (Abhängigkeiten) und \(M\) (Messwert)
			\begin{enumerate}
				\item Austausch von Zufallswerten innerhalb der Gruppe
				\item Berechnung von \(M = \sum Zufallswerte_{eingehend} - Zufallswert_{ausgehend}\)
				\item Menge \(L\) beinhaltet alle Abhängigkeiten (alle Knoten außer dem speichernden)
				\item Ermitteln den Messwert und Aktualisieren von \(M := M + Messwert\) (Messwerte ist jetzt maskiert)
				\item Übermittlung von \(L\) und \(M\) an MDL
			\end{enumerate}
			\item MDL erhält Summe aller verschleierten Messwerte (das gemeinsame Aggregat)
			\item Verbleibendes Problem: Gruppenerstellung durch MDL \(\rightarrow\) MDL kann korrumpierte Zähler einschleußen. Lösungsansatz: Denzentrale Gruppenbildung. "`Stromzählerspeeddating"' oder \textit{Elderberry} (baumbasierte, dezentrale Aggregation mit P2P-Overlay)
		\end{itemize}
	\end{itemize}
	\item \textbf{Privatheit im Smart Traffic}
	\begin{itemize}
		\item Anwendungen: Verkehrssicherheit, Verkehrsoptimierung, Erfassen von Wetter/Luftqualität/etc. mittels Sensordaten
		\item Nutzung von Positionsdaten von Android-Smartphones
		\item Trennung von Positionssamples und Identitäten notwendig. Pseudonymwechsel nötig, um Positionssamples desselben Nutzers nicht leicht zusammengruppieren zu können. Problem: Beobachtbarkeit. Lösung: Zufällige "`Funkstille"' beim Wechsel oder gleichzeitiger Wechsel verschiedener Nutzer in der selben Umgebung (innerhalb "`Mix-Zones"')
		\item Eigene Arbeit \textit{Geocast mit OverDrive}: P2P-Netz zwischen den Fahrzeugen. Keine zentrale Senke, niemand hat die komplette Sicht. Nur direkte Nachbarn erhalten die genaue Position, weit entfernte bekommen verfälschte Daten (bei jedem Hopp werden die Daten leicht verändert)
	\end{itemize}
\end{itemize}



\section{Kommunikation}

\subsection{Medienzugriff}

\subsubsection{Grundlegendes}
\begin{itemize}
	\item Sensorknoten sind häufig batteriebetrieben \(\rightarrow\) Energie ist wichtige aber sehr beschränkte Ressource \(\rightarrow\) Funktransceiver möglichst häufig deaktvieren (Problem: Wann empfangsbereit?)
	\item Betrachtetes Medium: Geteiltes Medium mit relativ hoher Unzuverlässigkeit ohne Duplexbetrieb (i.d.R.)
	\item \textbf{Funkmedium}
	\begin{itemize}
		\item Klassische Probleme gegenüber drahtgebundenen Netzen: Höhere Fehlerraten, niedrigere Datenrate, hohe Verzögerung, geringere Sicherheit
		\item Quadratische Abnahme der Signalausbreitung
		\item Signalausbreitungsbereiche: Übertragungsbereich, Erkennungsbereich, Interferenzbereich. Grenzbereiche unscharf, natürliche Gegenheiten ausschlaggebend
		\item Sicherheitsbetrachtung: Abhören/Manipulieren ohne großen Aufwand möglich
		\item \texttt{CSMA/CD}-basierte Verfahren für Medienzuteilung nicht nutzbar, da nur der Empfänger Kollisionen erkennen kann (\textit{Semi-Broadcast-Medium})
		\item \textbf{Problem}
		\begin{itemize}
			\item Genereller Aufbau: \texttt{A} \(\Leftrightarrow\) \texttt{B} \(\Leftrightarrow\) \texttt{C} \(\Leftrightarrow\) \texttt{D}
			\item Versteckte Endsysteme: \texttt{A} sendet zu \texttt{B}, \texttt{C} kann dies nicht feststellen und versucht ebenfalls zu \texttt{B} zu senden \(\rightarrow\) Carrier Sense versagt
			\item Ausgelieferte Endsysteme: \texttt{B} sendet zu \texttt{A}, \texttt{C} möchte zu \texttt{D} senden, muss aber warten bis \texttt{B} fertig gesent hat
			\item Nahe und ferne Endsysteme: \texttt{A} und \texttt{C} möchten senden, die Signalstärke nimmt allerdings quadratisch ab. Daher "`übertönt"' \texttt{C} \texttt{A} im rechten Teil des Aufbaus
		\end{itemize}
	\end{itemize}
	\item \textbf{Medienzuteilung}
	\begin{itemize}
		\item Verwendung von Zeitmultiplex, beispielsweise mit (festen) Zeitschlitzen
		\item Unnötiger Energieverbrauch bei Kollisionen, unnötigem Lauschen und Mithören \(\rightarrow\) vermeiden. Transceiver soll möglichst oft ausgeschaltet werden
		\item RTS-CTS-Handshake zur Kollisionsvermeidung (Auftritt während des Handshake unwahrscheinlich, da Pakete sehr klein): Empfänger wird zunächst mit \texttt{RTS} angefragt ob es empfangsbereit ist. Bei naherzu zeitgleichen Anfragen zweier Sender gewinnt der schnellere. Die sendewilligen Systeme warten, bis der Empfänger mittels \texttt{CTS} Empfangsbereitschaft signalisiert. Vermeidet versteckte/ausgelieferte Endsysteme
		\item Duty-Cycling zur Reduzierung des Energieverbrauchs: Funktransceiver wird bei Bedarf synchron (erfordert Zeitsynchronisation zwischen den Knoten) oder asynchron (ohne Koordination zwischen den Knoten) aktiviert, was zusätzliche Latenz verursacht, da bei Sendewunsch zunächst auf das entsprechende Zeitfenster gewartet werden muss (\textit{Duty Cycle: Zeitanteil, den ein System im Wachzustsnd vrbringen soll})
		\item WLAN im IoE: Verursacht hohen Energiebedarf durch Kollisionen, Idle Listening, Overhearing
		\item Bluetooth im IoE: Langsamer, aufwendiger Verbindungsaufbau; Synchronisation mehrerer Piconetze problematisch
		\item Bluetooth Smart (beeinhaltet "`classic"', "`high speed"' und "`low energy"'): Hohe Reichweite (150 m) mit geringer Bandbreite (1 Mbit/s). Nur der Master versucht dauerhaft neue Geräte zu finden sowie eingebaute Sicherheitsfunktionalität (AES-128-CCM). Lizenzfreier Betrieb (konventionelles Bluetooth erfordert Zertifizerung im kommerziellen Umfeld) \(\rightarrow\) insgesamt energieeffizienter Betrieb möglich
	\end{itemize}
\end{itemize}

\subsubsection{Medienzugriffsprotokolle}
\begin{itemize}
	\item \textbf{S-MAC (Sensor Media Access Control)}
	\begin{itemize}
		\item Rein akademisch, keine Verbreitung in der Praxis
		\item Zielsetzung: Ernergieeffizienz (durch periodisches Schlafen des Transceivers), Skalierbarkeit, Autokonfiguration
		\item Weniger berücksichtigt: Fairness zwischen den Systemen, Latenz
		\item Idee: Koordiniertes Schlafen zur Vermeidung von \textit{idle listening} mit zeitlicher Synchronisation der Systeme. Einführung eines \textit{S-MAC-Rahmen} mit fester Länge. Während \textit{Listen-Phase} erfolgt die Synchronisation sowie ggf. der Anstoß zum Datenaustauschen. Anschließend \textit{Sleep-Phase} zum Energie sparen oder Daten austauschen
		\item Aufbau eines S-MAC Frames
		\begin{description}
			\item{\texttt{Listen Phase:}} In Zeitschlitze gegliedert
			\begin{enumerate}
				\item \texttt{Sync Phase}: In einem zufälligen Zeitschlitz wird die Zeitspanne bis zum Beginn der nächsten Sleep Phase gesendet
				\item \texttt{RTS/CTS Phase}: In einem zufälligen Zeitschlitz wird der Datenaustausch durch Senden eines \texttt{RTS} angestoßen. Pro Frame kann maximal eine Dateneinheit übertragen werden
			\end{enumerate}
			\item{\texttt{Sleep Phase:}} Datenaustausch oder temporäres Schlafen des Transceivers. Empfangene Daten werden mit \texttt{ACK} quittiert
		\end{description}
		\item Ablauf aus Sendersicht: Während des ersten Teil der Listen-Phase durch ein SYNC-Paket die Zeitspanne bis zum Beginn der nächsten Sleep-Phase gesendet. im zweiten Teil der Listen-Phase wird in einem zufälligen Zeitschlitz ein RTS-Signal gesendet. Antwortet der Empfänger mit CTS, so hat der Sender wärend der folgenden Sleep-Phase Zeit, die gewünschten Daten zu senden
		\item Synchronisation: System muss den Anfang der nächsten Sleep Phase kennen lernen. Dazu lernt es die Zeitpläne seiner Nachbarn durch regelmäßiges Hören der \texttt{SYNC}-Dateneinheiten \(\rightarrow\) es entstehen "`SYNC-Inseln"'. Grenzknoten lernen und befolgen verschiedene Zeitpläne. Initiierung einer "`eigenen"' "`SYNC-Insel"' falls nach einem Timeout kein \texttt{SYNC} eines anderen Knotens empfangen wird
		\item Verbesserungen
		\begin{itemize}
			\item \textit{Message Passing} zur fragmentierten Übertragung einer größeren Datenmenge. Die Bitfehlerwahrscheinlichkeit steigt mit der Länge der Nachricht. Jede Dateneinheit wird einzeln bestätigt. Bei einem Bitfehler muss nur die fehlerhafte Einheit neu gesendet werden und nicht die komplette Nachricht (alles während einer einzigen Sleep-Phase). Wird eine Dateneinheit nicht sofort quittiert, so wird von einem Übertragungsfehler ausgegangen und sie wird erneut gesendet
			\item Erweiterung \textit{Adaptive Listening}: Bisheriges System spart Energie aber vergrößert die Verzögerungen bei Multihop (pro Rahmen kann maximal eine Dateneinheit weitergereicht werden). Einführung einer zusätzlichen Phase um einen neuen Datenaustausch anzustoßen (Adaptive Listening Phase; startet nach Versenden der Quittung). So kann innerhalb eines einzelnen S-MAC-Frames mehr als ein Hop überbrückt werden. Problem: Woher weis ein schlafendes System, dass die Datenübertragung abgeschlossen ist?
		\end{itemize}
		\item Leistungsbewertung über Energiebedarf pro Byte; durschnittliche Ende-zu-Ende-Verzögerung sowie Ende-zu-Ende-Goodput (Gesamtmenge durch Gesamtzeit). S-MAC reduziert den Energiebedarf deutlich. Bei hoher Last kann Adaptive Listening den Energiebedarf nochmals halbieren
	\end{itemize}
	\item \textbf{B-MAC}
	\begin{itemize}
		\item Ebenfalls rein akademisch, hat sich in der Forschung durchgesetzt
		\item Zielsetzung: Energieeffizient durch Kollisionsvermeidung und effiziente Kanalnutzung; Skalierbarkeit; Toleranz bzgl. Funkbedingungen; einfache Implementierbarkeit
		\item Besonderheiten: Periodisches Prüfen des Kanals statt zeitlicher Synchronisation; keine Fragmentierung großer Nachrichten
		\item \textit{Low Power Listening} (LPL): System schläft meist und erwacht gelegentlich kurzzeitig um Kanal auf Daten zu prüfen. Sendewunsch durch Senden einer Präambel. Bleibt nur wach, falls Präambel empfangen wird und daher Daten zum Empfang bereitstehen
		\item \textit{Clear Channel Assessment} (CCA): Prüfe ob Kanal frei ist und übertrage ggf. Präambel und Daten. Präambel muss daher mindestens dem Intervall zwischen zwei Kanalüberprüfungen entsprechen (damit der Empfänger nichts verpasst)
		\item Erweiterung X-MAC: Statt einer großen Präambel werden viele kleine Präambelpakete gesendet mit Quittung für erhaltene Präambel um die Kosten beim Sender weiter zu reduzieren. Bei \texttt{Unicast} wird die Zieladresse in der Präambel übertragen
		\item Kenngrößen zur Leistungsbewertung
		\begin{itemize}
			\item Durschnittlicher Energiebedarf pro Byte: Gesamtenergiebedarf aller Systeme geteilt durch die Anzahl von der Senke empfangenen Bytes
			\item Durschnittliche Ende-zu-Ende Verzögerung: Summe aller Ende-zu-Ende Verzögerungen geteilt durch die Anzahl der Dateneinheiten
			\item Ende-zu-Ende Goodput: Gesamtzahl von der Senke empfangener Bytes geteilt durch die Zeitspanne zwischen Versenden der ersten Datenheit bis zum Empfang der letzten Dateneinheit an der Senke
		\end{itemize}
		\item Leistungsvergleich: S-MAC vs. B-MAC
		\begin{itemize}
			\item Durchsatz: Je weniger Systeme um den Kanal konkurrieren, desto höher ist der Durchsatz. Bei nur einem System hat B-MAX den höheren Durchsatz. Durch CCA erreicht B-MAC das 4,5-fache des S-MAC-Durchsatzes
			\item Energiebedarf und Durchsatz: Mit steigendem Durchsatz wächst der Energieverbauch von S-MAC schneller und ist insgesamt höher
			\item Ende-zu-Ende Verzögerung steigt mit der Anzahl der Hops linear
		\end{itemize}
		\item IEEE 802.15.4 mit B-MAC/X-MAC
		\begin{itemize}
			\item B/X-MAC nicht auf vorhandenen Funkchips implementierbar, da 802.15.4 paketbasiert ist und kein dauerhaftes Präambelsenden erlaubt \(\rightarrow\) wiederholtes Senden einer kurzen Präambel. Beispielsweise in TinyOS-LPL entsprechend umgesetzt. Bei Unicast wird die Zieladresse in die Präambel eingefügt
		\end{itemize}
	\end{itemize}
	\item \textbf{IEEE 802.15.4}
	\begin{itemize}
		\item IEEE Standard für Low-Rate WPAN-Anwendungen, der oft von ZigBee und 6LoWPAN genutzt wird
		\item Ziele: Kleine bis mittlere Datenraten, moderate Verzögerung, geringer Energiebedarf sowie geringe Komplexität
		\item Eigenschaften: Frequenzbänder 868/914/2450 MHz; Datenrate von maximal 250 kbit/s; Reichweite 10 m
		\item MAC-Protokoll
		\begin{itemize}
			\item Größe der Datenheit maximal 127 Byte
			\item Kombiniert Zeitplan-basiertes und Konkurrenz-basiertes Verfahren. Realtimefähigkeit durch garantierte Zeitschlitze
			\item Asymmetrisch: Systeme können unterschiedliche Rollen einnehmen
			\item Basiert auf CSMA/CA, das auch bei WLAN verwendet wird
		\end{itemize}
		\item Typen von Netzen: P2P-Netz ("`Mesh-Netzwerk"') oder Stern-Netz. Verbindungen zwischen Netzen über FFD (s.u.) möglich
		\item Klassen von Systemen
		\begin{itemize}
			\item \textit{Full Function Device} (FFD)
			\item \textit{Reduced Function Device} (RDF), nur in Stern-Netzen
			\item Jedes Netz besitzt einen Koordinator (FFD), der das Netz organisiert (koordiniert Zeitschlitze, verwaltet Systeme und Adressen)
		\end{itemize}
		\item Betriebsmodi
		\begin{itemize}
			\item Beacon Modus
			\begin{itemize}
				\item Stern-Netz: Systeme sind einem Koordinator zugeordnet und formieren ein \textit{Personal Area Network} (PAN)
				\item Koordinator verwaltet das Netz, bearbeitet Anforderungen für garantierte Zeitschlitze und vermittelt zwischen Systemen und Peer-Koordinatoren. Annahme: Für Koordinator steht unbegrenzte Energie zur Verfügung
				\item Rahmenstruktur
				\begin{itemize}
					\item {Aktive Phase:} Während der gesamten Phase muss der Koordinator aktiv sein
					\begin{enumerate}
						\item \textit{Contention Access Period} (\texttt{CAP}) mit konkurrierendem Zugriff auf die Zeitschlitze durch \texttt{Slotted CSMA/CA} (Kanal abhören bevor gesendet wird mit exponentiellem Backoff zur Kollisionsvermeidung. Kein Schutz versteckter Endsysteme)
						\item \textit{Guaranteed Time Slots} (\texttt{GTS}). Zeitschlitze müssen während der \texttt{CAP}-Phase beim Koordinator angefragt werden und gelten so lange, bis sie wieder freigegeben werden
					\end{enumerate}
					\item {Inaktive Phase:} Alle Systeme können Transceiver ausschalten
				\end{itemize}
				\item GTS-Anfrage an den Koordinator: System fragt während der \texttt{CAP}-Phase an und bekommt den Empfang der Anfrage unmittelbar quittiert. Der zugeordnete \texttt{GTS}-Zeitschlitz wird einem der folgenden \texttt{Beacons} mitgeteilt, sobald einer verfügbar (frei) ist. Koordinator kann \texttt{GTS}-Zeitschlitze freigeben, falls diese für eine bestimmte Dauer nicht genutzt worden sind
				\item Übertragung
				\begin{itemize}
					\item System \(\rightarrow\) Koordinator: Während \texttt{CAP} oder \texttt{GTS} (falls ein Zeitschlitz reserviert wurde)
					\item Koordinator \(\rightarrow\) System: Während \texttt{GTS}, falls ein Zeitschlitz reserviert wurde oder während \texttt{CAP} (Koordinator teilt dies im \texttt{Beacon} mit). Während \texttt{CAP} schickt das System zunächst eine Daten-Anfrage und erhält anschließend die Daten. Alle Transaktionen während \texttt{CAP} werden quittiert
				\end{itemize}
			\end{itemize}
			\item Non-Beacon Modus: Keine feste Rahmenstruktur, Zugriff auf das Medium durch unslotted CSMA/CA (wegen fehlender Zeitsynchronisation keine Zeitschlitze möglich). Bei P2P-Netzen können die Systeme direkt untereinander kommunizieren. PAN-Koordinator wird frei gewählt, beispielsweise das erste, kommunizierende System
		\end{itemize}
	\end{itemize}
\end{itemize}


\subsection{Routing}

\subsubsection{Motivation Routing im drahtlosen Sensornetz. Was sit anders?}
\begin{itemize}
	\item Adressierung anders: Globales Adressierungsschema unpraktisch
	\item Datenfluss: Meist von vielen Quellen zu einer Senke (Concast) oder von einer Quelle an viele andere Knoten. Meist wenig Knoten-zu-Knoten Kommunikation
	\item Ressourcen stark limitiert
\end{itemize}

\subsubsection{Probabilistische Verfahren}
\begin{itemize}
	\item \textbf{Fluten}
	\begin{itemize}
		\item Knoten sendet jede Dateneinheit per Broadcast an alle Nachbarn. Diese leiten die Dateneinheit wieder per Broadcast an alle Nachbarn weiter
		\item Durchaus häufig im Einsatz, da dezentral/selbstorganisierend und keine Routingtabellen erforderlich
		\item Vorteile: Keine Routenfindung/Topologiewartung/Routentabelle erforderlich
		\item Nachteile: Implosion (Versenden duplizierter Dateneinheiten); limitierte Ressourcen nicht beachtet; terminiert nicht; unzuverlässig
		\item Verbesserungen
		\begin{itemize}
			\item Duplikatvermeidung: Sensorknoten leiten neue Dateneinheit nur einmal weiter. Knoten müssen dazu allerdings Zustandshaltung über weitergeleitete Nachrichten betreiben und Nachrichten müssen eindeutig identifizierbar sein, was nicht immer zu erfüllen ist \(\rightarrow\) Einsatz probabilistischer Verfahren zur Duplikatserkennung
			\item Reichweitenbegrenzung mit maximaler Time-To-Live (TTL): Sorgt für weniger Netzbelastung; allerdings nicht zuverlässig
		\end{itemize}
	\end{itemize}
	\item \textbf{Gossiping}
	\begin{itemize}
		\item Idee: Simulation der Verbreitung von Gerüchten. 
		\item Zufallsbasierte Weiterleitung von Dateneinheiten an Nachbarknoten, die sie wieder zufallsbasiert an Nachbarknoten weiterleiten. Weiterleitungswahrscheinlichkeit typischerweise bei \(65\%-75\%\)
		\item Vorteile: Keine Nachrichtenimplosion, geringerer Overhead als Fluten
		\item Nachteile: Unzuverlässig, eventuell lange Übertragungszeit durch ungünstige Pfadwahl
	\end{itemize}
	\item \textbf{Kombination aus Fluten und Gossiping}
	\begin{itemize}
		\item Idee: Auf den ersten \(k\) Hops fluten, danach Gossiping mit Wahrscheinlichkeit \(p\)
		\item Erfahrungswerte: Ideale Parametrisierung möglich, so dass nahezu alle Knoten erreicht werden
		\item Verbesserung: \(p\) steigt, je näher eine Dateneinheit ihrem Ziel kommt. Voraussetzung ist, dass jeder Knoten die Distanz zum Ziel kennt
	\end{itemize}
\end{itemize}

\subsubsection{Inhaltsbasierte Verfahren}
\begin{itemize}
	\item \textbf{Direct Diffusion}
	\begin{itemize}
		\item Basiert auf Fluten, ist selbstorganisierend. Unterstützt die Aggregation von Daten
		\item Besonders geeignet bei regelmäßiger Anfrage von Daten (beispielsweise regelmäßige Temperaturmessungen). Alle Knoten, welche die Bedingungen der Anfrage erfüllen (beispielsweise Datentyp oder Lokation), antworten
		\item Verfahren
		\begin{enumerate}
			\item Senke äußert Interesse an Daten (Query), diese wird im Netz geflutet
			\item Aufbau eines Pfads zur Datenquelle: Speicherung der Richtung (Gradient), aus der die Query kam. Zu einem Query können mehrere Gradienten existieren
			\item Daten werden auf dem Rückwärtspfad gesendet
			\item Anfragen generell teuer (Fluten), Antworten günstig (Gradienten) \(\rightarrow\) gut geeignet für wiederkehrende Daten zur Senke
		\end{enumerate}
		\item Verbesserung: Gradientenverstärkung zur Etablierung eines oder mehrerer "`guten"' Wege. Gradienten werden verstärkt, wenn eine Senke gefunden wird. Weiterleitung von Datenpaketen erfolgt dann entsprechend des stärksten Gradienten \(\rightarrow\) zunächst redundantes Senden von Daten, danach Reduktion der Pfade durch Gradientenverstärkung
		\item Evaluierung Direct Diffusion vs. Fluten: Direct Diffusion verbraucht deutlich weniger Energie pro Knoten
	\end{itemize}
	\item \textbf{Rumor Routing}
	\begin{itemize}
		\item Datenzentrischer Ansatz: Initiative geht von Ereignisquelle und -senke aus. Kompromis zwischen Fluten von Anfragen und Fluten von Ereignissen
		\item Ereignis-Agenten
		\begin{itemize}
			\item Etablieren Pfade zu Ereignissen. Anfragen suchen im Netz nach Ereignis-Pfaden
			\item Ereignis-Agenten wandern als langlebige Dateneinheiten (mit maximaler Lebensdauer) durch das Netz, lernen unterwegs selbstständig Information und hinterlassen Pfadinformationen in den Knoten (vgl. Ameisen in biologischen Systemen)
			\item Pfadwahl durch Random-Walk
		\end{itemize}
		\item Die beteiligten Sensorknoten sammeln Informationen über Nachbarn (beispielsweise durch periodische Hello-Dateneinheiten) und Ereignisse (Ereignistabelle mit zeitlich limitierten Informationen zu Weiterleitungen bei bekannten Ereignissen)
		\item Funktioniert, da die Wahrscheinlichkeit sehr hoch ist, dass sich zwei Pfade im zweidimensionalen Raum treffen
		\item Beispiel
		\begin{itemize}
			\item Knoten A beobachtet Ereignis und sendet zwei Ereignis-Agenten aus, die Routinginformationen zum Ereignis installieren (geben je einen Pfad vor)
			\item Knoten B fragt nach einem Ergebnis und sendet Such-Agenten aus, die mit hoher Wahrscheinlichkeit einen bestehenden Ereignispfad kreuzen \(\rightarrow\) Pfad zum Ereignis ab jetzt bekannt
		\end{itemize}
		\item Leistungsfähigkeit: Fluten vs. Rumor Routing
		\begin{itemize}
			\item Anfragen fluten: Lohnt sich bei vielen Events und wenigen Anfragen
			\item Events fluten: Gradienten zur Eventquelle aufbauen, dann sind Anfragen mit geringen Kosten möglich
			\item Rumor Routing lohnt sich bei allen Fällen dazwischen 
		\end{itemize}
	\end{itemize}
\end{itemize}

\subsubsection{Lokationsbasierte Verfahren}
\begin{itemize}
	\item Motivation lokationsbasierter Verfahren: In vielen Anwendungen sollen Orte/Regionen adressiert werden. Informationen über Position der beteiligten Systeme kann Routing unterstützen (beispielsweise Koordinaten).
	\item \textbf{Distanzbasiertes Greedy-Verfahren}
	\begin{itemize}
		\item Ziel: Übertragung einer Dateneinheit zu einer bekannten Position
		\item Basiert auf der Annahme dass jedes System die eigene Position kennt
		\item Strategie: Weiterleiten der Nachricht an das System in Reichweite, das dem Ziel am nächsten ist
		\item Vorteil: Strategie garantiert schleifenfrei
		\item Nachteile: Topologie bleibt unbeachten (eventuell schlechte Routen); Systeme am Rand der Übertragungsreichweite bevorzugt (eventuell schlechte Verbindungen \(\rightarrow\) höhere Wahrscheinlichkeit für Paketverluste und Notwendigkeit zum wiederholten Senden)
	\end{itemize}
	\item \textbf{Richtungsbasiertes Greedy-Verfahren}
	\begin{itemize}
		\item Idee: Wähle das nächste Zwischenziel möglichst nahe an der idealen Richtung
		\item Metriken: Minimalistischer Abstand zur Verbindungsgerade oder minimaler Winkel zur Verbindungsgerade
		\item Problem: Nicht garantiert schleifenfrei
	\end{itemize}
	\item Generelles Problem bei Greedy-Strategien: Algorithmus kann in Sackgassen stecken bleiben
	\item \textbf{Greedy Perimeter Stateless Routing (GPSR)}
	\begin{itemize}
		\item Idee: Verwendung der Rechte-Hand-Regel um aus Sackgassen zu entkommen
		\item Benötigt einen planaren Graphen. Da drahtlose Netze i.d.R. nicht planar sind müssen sie erst "`planiert"' werden
		\item Weiterleitungs-Modi: Distanzbasiertes Greedy-Routing (kommt dem Ziel schneller näher); Perimetermodus um Sackgassen durch Rechte-Hand-Regel zu entkommen. GPSR startet im Greedy-Modus und wechselt in einer Sackgasse selbstständig in den Perimetermodus. Diese Position wird als Eintrittspunkt in den Permietermodus gespeichert. Sobald das Ziel näher ist als der Eintrittpunkt wird wieder in den Greedy-Modus gewechselt
	\end{itemize}
\end{itemize}

\subsubsection{Distanzvektorbasierte Verfahren: RPL (IETF-Standard)}
\begin{itemize}
	\item \textbf{Anforderungen (aus RFC 6550)}
	\begin{itemize}
		\item Adaptivität: Dynamisches Anpassen der Pfade bei geänderten Umgebungsbedingungen
		\item Constraint-based Routing: Miteinbeziehen von Randbedingungen wie niedrigem Batteriestand oder schlechter Verbindungsqualität
		\item Unterstützung verschiedener Verkehrsmuster
		\item So wenig wie möglich Konfigurations- und Managementaufwand
	\end{itemize}
	\item \textbf{Grundlegendes Prinzip}
	\begin{itemize}
		\item Eine/Mehrere Wurzeln halten die Verbindung zum Internet
		\item Verwendung von Gerichteten Azyklischen Graphen (DAG, DODAG): Wurzel ist höchster Knoten in "`up"'-Richtung (Concast) und hält Verbindung zum Internet, "`down"' in entgegengesetzter Richtung (Multicast)
	\end{itemize}
	\item Destination-oriented Distributed Acyclic Graphs (DODAGs)
	\begin{itemize}
		\item Nutzung von Metriken ("`Finde Pfade mit der geringsten Latenz"') und Constraints/Randbedingungen ("`Vermeide batteriebetriebene Knoten"')
		\item Konstruktion des Graphen: Start bei der Wurzel. Knoten in der Nachbarschaft empfangen DIO-Nachricht und entscheiden, ob Beitritt zum Graphen oder nicht (vgl. Breitensuche). Durch individuelle IDs können alle Knoten innerhalb des Graphen eindeutig identifiziert werden. Knoten können immer nur genau einem Netzwerk beitreten
		\item DODAG sind versionierbar um auf dynamische Anpassungen im Netz reagieren zu können. Für die Anpassungen ist die Wurzel verantwortlich
		\item \textit{Node Ranks} geben die relative Position eines Knoten im DODAG durch einen skalaren Wert an. Monoton wachsend nach unten (zur Schleifenvermeidung), gültig innerhalb einer DODAG-Version
		\item \textit{Objective Function}: Gibt die Pfadkosten an. Nutzt Metriken und Constraints zur Berechnung (s.o.)
		\item Kontrollnachrichten
		\begin{itemize}
			\item \textbf{DAG Information Object (DIO)}: Strukturinformation, die es Knoten ermöglichen neue RPL-Instanzen zu entdecken; Konfigurationsparameter; DODAG-Eltern
			\item \textbf{DAG Information Solicitation (DIS)}: Gezielte Anforderung eines DIOs von einem Knoten
			\item \textbf{Destination Advertisement Object (DAO)}: Routingziele (Erreichbarkeit) entlang eines DODAGs
		\end{itemize}
		\item Knoten können Informationen für Down-Routing speichern (storing nodes). Im alternativen non-storing Betrieb fügt die Wurzel die Routinginformationen bei. Mischbetrieb ist unzulässig
		\item Sicherheit: Wahlweise \textit{unsecured}, \textit{pre-installed} (vorinstallierte gemeinsame Geheimnisse auf den Knoten zum Versenden gesicherter Nachrichten), \textit{authentifiziert} (Beitritt mit Schlüssel einer Authentication Authority)
		\item \textbf{DODAG-Konstruktion im Detail}
		\begin{enumerate}
			\item Knoten schicken periodisch \texttt{DIO}-Informationen
			\item Initialisierung durch Wurzel sowie verknüpfen der Knoten untereinander. Wurzel gibt den \texttt{ROOT\_RANK} bekannt (weitere Wurzeln würden den selben Wert benutzen)
			\item Berechnung der Link-Kosten und Node-Ranks
			\item Hierarchische Wahl der/des Elternknoten (Link-Kosten entscheidend)
			\item Schleifenerkennung durch \texttt{max\_depth rule}
		\end{enumerate}
	\end{itemize}
\end{itemize}


\subsection{Datentransport}
\begin{itemize}
	\item Besonderheiten: Zuverlässigkeit; beschränkte Ressourcen; oft Echtzeit-Anforderung; keine klassischen Topologien mit Client-Server-Architekturen
\end{itemize}

\subsubsection{Unicast}
\begin{itemize}
	\item Kommunikationsform: Sensoren \(\rightarrow\) Aktoren (Ende-zu-Ende)
	\item Herausforderungen: Zuverlässigkeit, geringe Verzögerung
	\item Anwendungsbeispiele: Hausautomation (Schalter steuert Lichtquelle), Industrie (Überwachungssensor stoppt Produktionsanlage), Autowäsche (Abstandssensor verhindert Beschädigungen am Auto)
	\item \textbf{Zuverlässigkeit}
	\begin{itemize}
		\item Traditioneller Weise TCP als zuverlässiger Transportdienst. Probleme: TCP erkennt die Ursachen für Paketverlust nicht; erfordert ggf. viele Sendewiederholungen (hoher Energiebedarf) sowie sehr teuren 3-Wege-Handshake
		\item Nicht alle Messwerte sind relevant, Ungenauigkeiten können (anwendungsabhängig) toleriert werden (beispielsweise minimale Temperaturschwankungen in einem Raum)
		\item Probabilistische Zuverlässigkeit: Nur ein Teil aller Dateneinheiten erreicht die Senke. Ggf. leidet die Genauigkeit/Aktualität
		\item Pro-Hop Quittungen: Quittungen/Sendewiederholungen pro Hop. Energieverbrauch wird gleichmäßig im Netz verteilt
		\item Ende-zu-Ende Quittungen: Nur ursprünglicher Sender wiederholt die Dateneinheit. Bei geringen Bitfehlern besser geeignet
	\end{itemize}
	\item \textbf{Hop-by-Hop Reliabilty (HHR)}
	\begin{itemize}
		\item Zielsetzung: Erhöhe Zuverlässigkeit ohne Quittungen durch \(k\)-maliges Senden (\texttt{k} errechnet sich aus der Paketfehlerrate zum Nachbarsystem)
		\item HHR mit Acknowledgements (HHRA): Wiederholtes Senden bis \(k\) erreicht ist oder die erste Quittung den Sender erreicht
		\item Evaluierung: Pro-Hop Quittungen lohnen sich erst bei hohen Paketfehlerraten
		\item HHR vs. HHRA
		\begin{itemize}
			\item HHR
			\begin{itemize}
				\item Vorteile: Einsparen von Übertragungen durch Verzicht auf Quittungen bei niedrigen Paketfehlerraten
				\item Paketwiederholung stoppt nicht, wenn Dateneinheit erfolgreich übertragen worden ist
			\end{itemize}
			\item HHRA
			\begin{itemize}
				\item Vorteil: Bei hohen Paketfehlerraten wird auf weiteres Senden nach erfolgreichem Erhalt einer Quittung verzichtet
				\item Nachteil: Großer Overhead bei geringer Paketfehlerquote \(\rightarrow\) lohnt dann nicht
			\end{itemize}
		\end{itemize}
	\end{itemize}
\end{itemize}

\subsubsection{Multicast}
\begin{itemize}
	\item Kommunikationsform: Senke \(\rightarrow\) Sensoren/Aktoren
	\item Herausforderungen: Zuverlässigkeit
	\item Typische Daten: Kontroll-/Steuerungsaufgaben, Code-Updates, Anfrageverteilung, Befehlsverteilung
	\item \textbf{Pump Slowly Fetch Quickly (PSFQ)}
	\begin{itemize}
		\item Ziel: Transportieren von Daten von einer Basisstation zu mehreren Sensoren/Aktoren
		\item Vorgehen: Basisstation pumpt Dateneinheiten ins Sensornetz (mit je einer Pause zwischen dem Versand zweier Dateneinheiten). Systeme leiten nur weiter ("`pumpen"'), falls es eine neue Dateneinheit ist (Identifikation mittels fortlaufender Sequenznummer) und keine Einheit dazwischen fehlt. Fehlende Dateneinheiten können per \texttt{Fetch}-Operation (\texttt{NACK} mit fehlenden Sequenznummern als Boradcast, die mehrere Nachbarn erreichen) explizit angefordert werden
		\item Evaluierung/Beobachtungen
		\begin{itemize}
			\item Je größer die Distanz zur Quelle desto niedriger die Zustellrate (Prozentsatz der angekommenen Dateneinheiten an den Gesamteinheiten)
			\item Je höher die Paketfehlerrate desto niedriger die Zustellrate
			\item Keine Zustellgarantie
			\item Im Test allerdings selbst bei einer Paketfehlerrate von \(70\%\) noch eine Zuverlässigkeit von \(>70\%\)
		\end{itemize}
	\end{itemize}
\end{itemize}

\subsubsection{Concast}
\begin{itemize}
	\item Kommunikationsform: Sensoren \(\rightarrow\) Senke
	\item Herausforderungen: Zuverlässigkeit, Stauvermeidung und Energieeffizienz
	\item Anwendungsbeispiel: Sensor beantwortet Anfrage mit Messdaten
	\item Stau: Datenströme können zu Stau/Überlastung führen. Dabei kann es zu Datenverlust (Gegenmaßnahme: erneutes Senden) kommen oder Daten kommen verzögert an (Gegenmaßnahme: weniger Daten senden) \(\rightarrow\) Energiebedarf steigt
	\item \textbf{Event-to-Sink Reliable Transport (ESRT)}
	\begin{itemize}
		\item Szenario: Viele Sensoren senden periodisch Dateneinheiten zur Senke, welche eine ausreichende Anzahl Dateneinheiten (egal von welchem Sensor) benötigt
		\item Ziel: Bestimmen der benötigten Senderate im nächsten Zeitschritt auf Basis der aktuellen Senderate und der aktuellen Zustellrate durch die Senke. Senderate wird anschließend per Broadcast an alle Systeme geschickt (Annahme: Alle Knoten können die Senke hören)
		\item Ein Stau wird erkannt, wenn weniger Daten als gewünscht die Senke erreichen (Schwelle festgelegt vom Benutzer)
	\end{itemize}
	\item \textbf{Aggregation}
	\begin{itemize}
		\item Ziel: Zusammenfassen von Daten um weniger Dateneinheiten zu verschicken
		\item Aggregationsformen
		\begin{itemize}
			\item Keine Aggregation: Eingehende Daten werden direkt weitergeleitet
			\item Paketaggregation: Eingehende Daten werden zwischengespeichert und zusammen in einem großen Paket weitergeleitet
			\item Datenaggregation: Eingehende Daten werden zwischengespeichert und mit Aggregatsfunktion zusammengefasst und weitergeleitet
		\end{itemize}
		\item Evaluations-Metrik: Anzahl Messwerte, welche die Datensenke erreichen (MRS)
		\begin{itemize}
			\item Ergebnisse mit TinyOS LPL: Unterschiede durch Aggregation minimal da LPL die Knoten lokal synchronisiert. Kein unmittelbarer Zusammenhang zwischen Energiebedarf und Anzhl Datenpakete/-volumen
			\item Ergebnisse mit S-MAC: Aggregation erhöht MRS, da der Durchsatz mit S-MAC bei kleinem Duty-Cycle gering ist. Aggregation reduziert die Anzahl der Übertragungen
		\end{itemize}
		\item Fazit
		\begin{itemize}
			\item Ergebnis stark abhängig vom MAC-Protokoll
			\item Kein signifikanter Unterschied zwischen Daten- und Paketaggregation. Paketaggregation ist daher vorzuziehen, da so alle Messwerte bei der Senke ankommen und nicht nur das Aggregat
			\item Datenvolumen hat hier keinen großen Einfluss auf Energiebedarf
		\end{itemize}
	\end{itemize}
\end{itemize}


\subsection{Topologiekontrolle}
\begin{itemize}
	\item \textit{Topologie} beschreibt den Aufbau von Verbindungen zwischen Systemen. Ein dichtes Netz führt zu komplexer Topologie (Anzahl der Nachbarn als Dichtemaß)
	\item \textbf{Flache Netze mit gleichberechtigten Systemen}
	\begin{itemize}
		\item Ziel: Nicht immer die volle Sendeleistung nutzen \(\rightarrow\) Energie sparen
		\item Sendeleistung regulieren: Sendeleistung und Zahl der direkten Nachbarn hängen unmittelbar zusammen (Übertragungen zu lokal näher gelegene Nachbarn benötigen weniger Energie). Ideale Sendeleistung als Tradeoff zwischen Energiesparen und Qualität der Konnektivität. Ziel: Bestimmen der \textit{Minimalen maximalen Sendeleistung} (MMS)
		\item Zahl der der Nachbarn regulieren
	\end{itemize}
	\item \textbf{Hierarchische Netze (Systeme haben unterschiedliche Fähigkeiten/Aufgaben)}
	\begin{itemize}
		\item Backbone-Netz: Aufteilen der Systeme in Backbones und einfachen Knoten. Die einfachen Knoten sind jeweils dem lokal nächsten Backbone zugeordnet. Einfache Knoten dürfen lediglich innerhalb des selben Backbone-Netzes kommunizieren. Außerhalb dürfen nur Backbones direkt kommunizeren (diese bilden ein \textit{dominating set})
		\item Cluster-Netze
		\begin{itemize}
			\item Aufteilung der Sensoren in Gruppen (Cluster), so dass jedes Sytem in genau einer Gruppe ist. \textit{Cluster-Heads} bilden Vertreter ihrer Gruppe, wobei keine zwei Cluster-Heads direkte Nachbarn sein dürfen. Gesucht ist die maximale unabhängige Menge
			\item Bestimmung der Gateways: Nach der Bestimmung der Cluster-Heads werden diese untereinander verbunden. Jeder Cluster-Head benötigt eine Verbindung zu allen anderen Cluster-Heads, die maximal drei Schritte entfernt sind
			\item Low-Energy Cluster Hierarchy (LEACH)
			\begin{itemize}
				\item Idee: Regelmäßiges Rotieren der höher belasteten Cluster-Heads zur Umverteilung der Last \(\rightarrow\) gleichmäßige Verteilung des Energieverbrauchs
				\item Vorgehen: Knoten bestimmen sich selbstständig mit bestimmter Wahrscheinlichkeit zu einem Cluster-Head und teilen dies den benachbarten Knoten mit (rundenbasiert). Alle anderen Knoten ordnen sich dem nächsten, neuen Cluster-Head in Reichweite zu
				\item Mögliche Verbesserung: Clusterwahl nicht rein probabilistisch sondern basierend auf Restenergie der Knoten
			\end{itemize}
		\end{itemize}
	\end{itemize}
\end{itemize}


\subsection{Systeme und Standards}

\subsubsection{IETF}
\begin{itemize}
	\item Die wesentlichen Standards: \texttt{RPL} (Routing), \texttt{6LoWPAN} (Verbindung zum Internet, Kombrimierung/Fragmentierung) und \texttt{CoAP} (für Client-Server-basierte Systeme)
	\item \textbf{Einführung}
	\begin{itemize}
		\item Verwendung von IPv6 (da IPv4-Adressraum nicht ausreicht): Knoten haben eine global eindeutige Adresse und nutzen den IPv6-Autokonfigurationsmechanismus
		\item Nutzung etablierter Managementprotokollen (UPD als Transport) \(\rightarrow\) kein Anpassen von Anwendungen notwendig
		\item 6LoWPAN Architektur
		\begin{itemize}
			\item Konzept: Verbindungen zwischen "`Inseln"' mit drahtlosen eingebetteten Systemen herstellen. Inseln mit Geräten haben einen gemeinsamen IP-Adresspräfix
			\item Router: Führen Routingaufgaben aus
			\item Host: Quellen und/oder Senken von Daten. Nicht in das Routing involviert
		\end{itemize}
		\item Typen von 6LoWPANs
		\begin{itemize}
			\item Simple LoWPAN: Ein Edge-Router mit einem Link zu anderen IP-Netzen
			\item Ad-hoc LoWPAN: Kein Edge-Router, keine Infrastruktur
			\item Extended LoWPAN: Mehrere Edge-Router, gemeinsamer Backbone-Link zum Internet
		\end{itemize}
		\item Schichtenmodell
		\begin{itemize}
			\item \texttt{Constraint Application Protocol (CoAP)}: Transferprotokol für Umgebungen mit stark limitierten Ressourcen. RESTful, Interworking mit HTTP (einfache Proxy- und Caching-Umsetzung), Unterstützung für DTLS
			\item \texttt{UDP}
			\item \texttt{RPL}: Distanzvektor-basiertes Routing. Fokus auf Concast und Multicast
			\item \texttt{IPv6 mit 6LoWPAN-Adaption}: Adressierung mit Autokonfiguration für IPv6, Fragmentierung, Header-Kompression
			\item \texttt{802.15.4}: Medienzugriffsprotokoll mit verschiedenen Betriebsmodi. Alternativen sind beispielsweise Bluetooth-Low-Energy oder NFC
		\end{itemize}
	\end{itemize}
	\item \textbf{IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)}
	\begin{itemize}
		\item Annahmen und Anforderungen
		\begin{itemize}
			\item Anwendungen senden kleine Datenmengen, typischerweise \texttt{<100 Byte}
			\item Basiert auf 802.15.4, wobei Alternativen existieren (IPv6 über Bluetooth Low Energy oder NFC)
			\item Batteriebetriebene, günstige Geräte mit geringer Leistungsfähigkeit
			\item Minimaler Konfigurations- und Managementaufwand (u.U. schwere Erreichbarkeit der Geräte)
		\end{itemize}
		\item IPv6-Adressen
		\begin{itemize}
			\item Adressierung: Abbildung von \texttt{IPv6-Adressen} \(\rightarrow\) \texttt{IEEE 802.15.4-Adresse} (im Edge-Router). Alle Knoten eines LoWPANs haben einen gemeinsamen \texttt{IPv6-Präfix}
			\item Adresstypen
			\begin{itemize}
				\item Adresstyp wird durch führende Bits einer Adresse festgelegt
				\item Unicast \texttt{fe80::/10}: Identifikator für ein einzelnes Interface
				\item Anycast: Identifikator für eine Menge von Interfaces. Dateneinheit mit einer solchen Adresse wird an ein Interface aus dieser Menge ausgeliefert (üblicherweise an das "`nächstgelegene"')
				\item Multicast \texttt{ff00::/8}: Identifikator für eine Menge von Interfaces. Dateneinheit mit solcher Adresse wird an alle Interfaces aus dieser Menge ausgeliefert
				\item Global Unicast \texttt{0:0:0:0:0:ffff::/96}: IPv4-Adressen abgebildet auf IPv6-Adressen
			\end{itemize}
			\item Addressen bei Nutzung von \texttt{IEEE 802.15.4}: \texttt{MAC-Adresse} der Geräte (\texttt{IEEE-64-bit Adressen}) oder \texttt{16-bit} Kurzadressen, die der PAN-Koordinator verteilt (vgl. \texttt{802.15.4} im Non-Beacon-Modus). \texttt{IPv6-Adresse} setzt sich aus Präfix und Interface-Identifier zusammen
		\end{itemize}
		\item Beispiel für Simple LoWPAN Netzkonfiguration mit einem Edge-Router und mehreren Routern/Hosts
		\begin{enumerate}
			\item Router gibt IPv6-Präfix \texttt{2001:300a::/32} bekannt
			\item Edge-Router konfiguriert IPv6-Präfix \texttt{2001:300a::/48} für 802.15.4-Interface
			\item Edge-Router gibt Präfix im LoWPAN bekannt und Router konfigurieren Adressen
		\end{enumerate}
		\item 6LoWPAN Frame-Format und Paketköpfe
		\begin{itemize}
			\item 6LoWPAN spezifiziert eigene Paketköpfe für LoWPAN-spezifische Metadaten: Standard/Dispatch/Mesh/Fragmentierung. 6LoWPAN-Paketköpfe können verkettet werden
			\item Fragmentierung
			\begin{itemize}
				\item Randbedingung Paketgröße: Minimale MTU bei IPv6 beträgt 1280 Byte, 802.15.4 unterstützt allerdings nur die maximale Größe von 127 Byte \(\rightarrow\) Fragementierung in der Adaptionsschicht notwendig
				\item \texttt{Datagram\_tag} zur Unterscheidung der Dateneinheiten bei Reassemblierung sowie \texttt{Datagram\_size} zur Positionsangabe in der reassemblierten Dateneinheit
			\end{itemize}
			\item Header Compression
			\begin{itemize}
				\item Motivation: Verringerung des statischen Übertragungsaufwands durch Weglassen von redundanten/allgemeinen Informationen in höheren Schichten. Dabei kann der IPv6-Kopf oder der UDP-Kopf komprimiert werden
				\item Größe eines IPv6+UDP-Headers: 48 Byte
				\item \texttt{Dispatch-Byte} im Header gibt den nachfolgenden Paketkopftyp an
				\item Komprimierung im IPv6-Kopf: \texttt{LOWPAN\_HC1}
				\begin{itemize}
					\item Parameter, die komprimiert werden können: Versionsnummer (immer \(6\), ändert sich nicht); u.U. Adressen (lokale Adressen können aus Schicht 2 abgeleitet werden, bei externen Zielen muss komplette IPv6-Ziel-Adresse angegeben werden); Payload length (kann aus Schicht 2 Payload length berechnet werden); Traffic Class und Flow Label sind häufig \(0\); Next Header ist UDP, TCP oder ICMP (kurze Bitkodierungen. Bsp.: \texttt{01} \(\rightarrow\) \texttt{UDP})
					\item Kann auf 2 Byte + 1 Byte für das Hop-Limit-Feld komprimiert werden
				\end{itemize}
				\item Komprimierung im UDP-Kopf: \texttt{LOWPAN\_HC2}
				\begin{itemize}
					\item Was kann komprimiert werden: Port-Nummer (weniger als \(2^{16}\) Ports im IoE ausrechend); UDP-Payload-Length kann aus Schicht 3 berechnet werden; Komprimierung der Prüfsumme allerdings schwierig
				\end{itemize}
				\item IPv6-Kopf und UDP-Kopf können auf 6 Byte komprimiert werden
				\item Bisher nur Komprimierung von lokalen Adressen. Unter Ausnutzung von Kontextinformationen können auch globale Unicast-Adressen oder Multicast-Adressen komprimiert werden
				\item Weitere Möglichkeiten
				\begin{description}
					\item{\texttt{LOWPAN\_IPHC}:} Komprimierung globaler Unicast sowie Mulicast Adressen
					\item{\texttt{LOWPAN\_NHC}:} Komprimierung von \texttt{next header}. Sowohl \texttt{UDP} als auch \texttt{TCP} nutzbar
				\end{description}
			\end{itemize}
		\end{itemize}
	\end{itemize}
	\item \textbf{Constrained Application Protocol (CoAP)}
	\begin{itemize}
		\item Transferprotokoll für eingebettete bzw. ressourcenbeschränkte Maschinen-zu-Maschinen Kommunikation als leichtgewichtige Alternative zu HTTP; kann von Proxy unkompliziert in HTTP umgewandelt werden; nutzt \texttt{UDP}; kompakt; mit \texttt{DTLS} verwendbar
		\item Requests/Responses enthalten jeweils einen Methodenaufruf (\texttt{GET} (Abruf), \texttt{PUT} (Speicherung), \texttt{POST} (Update), \texttt{DELETE} (Löschen)) auf ein Objekt (eindeutig per URI identifiziert)
		\item Identifizierung eines Objekts per \texttt{URI}
		\item Messaging-Modell
		\begin{itemize}
			\item Eindeutige ID zur Duplikatserkennung sowie dem Zuordnen von Quittungen
			\item Wahlweise unzuverlässige Übertragung durch Non-Confirmable Nachrichtentyp (\texttt{NON}) oder zuverlässige Übertragung (Quittungen und exponentieller Backoff) durch Confirmable Nachrichtentyp (\texttt{CON})
			\item Empfangsbestätigung durch \texttt{ACK}-Nachricht (Quittung)
			\item Signalisierung von Fehlern durch Reset Nachrichtentyp (\texttt{RST})
		\end{itemize}
		\item Response-Klassen: 2 (Success), 4 (Client-Error), 5 (Server-Error). Responses können Piggy-Backed im \texttt{ACK} oder als separate Nachricht übertragen werden (muss im zweiten Fall ggf. mit einem \texttt{ACK} vom Client bestätigt werden)
		\item Sicherheitsmodi bei Verwendung von DTLS: Sichert Integrität, Vertraulichkeit und Authentizität
		\begin{itemize}
			\item NoSec
			\item PreSharedKey: Vorverteilte Schlüssel
			\item RawPublicKey: Nutzung von DTLS mit asymmetrischem Schlüsselpaar
			\item Certificate: Nutzung von DTLS mit X.509-Zertifikat
		\end{itemize}
	\end{itemize}
\end{itemize}

\subsubsection{Anwendungsgetrieben}
\begin{itemize}
	\item \textbf{Message Queue Telemetry Transport (MQTT)}
	\begin{itemize}
		\item Transfer-Protokoll für eingebettete/resourcenbeschränkte Maschinen-zu-Maschinen Kommunikation (vgl. CoAP). Fokus auf Many-to-Many-Kommunikation
		\item TCP-basiertes, einfaches Protokoll für leichtgewichtige Implementierung
		\item Publish-Subscribe-Paradigma mit \texttt{Topics}; Sicherheit mittels \texttt{TLS/DTLS}; ereignisorientiert
		\item Nachrichtenweiterleitung und Speicherung über zentralen Broker
		\item Clients abonnieren Topics bei Broker
		\item Quality of Service: Von Client während \texttt{SUBSCRIBE} festgelegt, kann allerdings von Broker (globale QoS-Levelgrenze) und Absender (in \texttt{PUBLISH}) beschränkt werden
		\begin{description}
			\item{Level 0}: Keine Garantien
			\item{Level 1}: Clients empfangen Nachrichten mindestens einmal
			\item{Level 2}: Clients emfangen Nachtichten genau einmal
		\end{description}
		\item Gegenüberstellung mit CoAP
		\begin{itemize}
			\item Publish-Subscribe-Schema mit zentralem Broker vs. Ende-zu-Ende-Verbindungen zwischen Datenquelle und -senke
			\item \texttt{MQTT} kann Datenquellen entlasten (durch puffernden Broker vs. Request-Response-Schema bei CoAP) oder belasten (Aktualisierungsrate > Bedarf)
		\end{itemize}
	\end{itemize}
	\item \textbf{ZigBee}
	\begin{itemize}
		\item Ziel: Überwachungs- und Steueraufgaben mit herstellerübergreifenden Schnittstellen (Haus-/Gebäudeautomation, Einzelhandel/Logistik, Smart Energy, etc.)
		\item Von der \textit{ZigBee Allicance} entwickelter Standard für das Internet der Dinge ohne Interoperabilität mit etablierter Infrastruktur
		\item Randbedingungen: Geringes Datenvolumen sowie geringer Energieverbauch
		\item \textbf{Schichtenmodell}
		\begin{itemize}
			\item Anwendungsschicht
			\begin{itemize}
				\item Anwendungsunterstützung: Zuverlässiger Transportdienst, Kopplung von Geräten, Gruppenverwaltung
				\item Anwendungs-Framework: Anwendungsfunktionalität
				\begin{itemize}
					\item Einbettung von bis zu 240 Anwendungsobjekten (entsprecht jeweils einem Endpunkt, was einem Port im ISO/OSI-Modell entspricht)
					\item Definition von Anwendungsprofilen (Kommunikationsstandards)
				\end{itemize}
				\item ZigBee-Device-Object: Besteht aus Netzwerk, Anwendungsunterstützung und Anwendungs-Framework
			\end{itemize}
			\item Netzwerkschicht für Routing und Adressierung
			\item \texttt{IEEE 802.15.4} als Medienzugriffsprotokoll
			\item Quittungen pro erfolgreich übertragenen Dateneinheit in spezieller Dateneinheit (kein \textit{piggy-back})
		\end{itemize}
		\item \textbf{Anwendungsprofile}
		\begin{itemize}
			\item Soll Interoperabilität zwischen Geräteherstellern sicherstellen
			\item In ZigBee Profilen werden für einen bestimmten Anwendungsfall Systemvoraussetzungen und Geräte definiert. Jedes Gerät implementiert hierbei eine Menge von Clustern. Beispielprofile sind z. B. Home Automation, Building Automation und Health Care\footnote{\url{https://de.wikipedia.org/wiki/ZigBee\#ZigBee_Profile}}
			\item Beispiel \textit{ZigBee Home Automation Profile}: Beschreibt welche Geräte (Türschloss, Lichtschalter, Dimmer, Thermostat) und welche Cluster (Türschloss, Fensterabdeckung) benötigt werden
		\end{itemize}
		\item Client/Server-Modell: Attribute sind typischerweise Geräten zugeordnet (beispielsweise der Status einer Lampe)
		\item Cluster: Um insbesondere Interoperabiltät von Produkten verschiedener Hersteller zu gewährleisten, hat die ZigBee Allianz Cluster und Profile definiert. Ein Cluster funktioniert nach dem Client/Serverprinzip. Der Server eines Cluster besitzt verschiedene Attribute, die im Allgemeinen der Client durch bestimmte Kommandos verändern kann. Eine Lampe ist z. B. ein Server des Clusters OnOff (ClusterID: 0x0006). Der Client kann durch Senden wohldefinierter Kommandos (On, Off, Toggle) den Zustand des Attributes verändern. Der Datenaustausch erfolgt über ZCL-Frames. Sämtliche Cluster sind in der ZigBee Cluster Library zusammengefasst\footnote{\url{https://de.wikipedia.org/wiki/ZigBee\#ZigBee_Cluster_Library}} (Cluster \(\Rightarrow\) Satz standardisierter Commandos)
		\item Datentransport: Keine eigene Schicht, verbindungslos, Fragmentierung für große Dateneinheiten
		\item Nutzung von Quittungen pro übertragene Dateneinheiten, die als separate Dateneinheiten übertragen werden (keine Piggy-Back-Quittungen). Nach Ablauf eines Timers erfolgen maximal drei Sendewiederholungen
		\item Fragmentierung: Quittungen verpflichtend
		\item Adressierung erfolgt über 16 Bit Kurzadressen. Keine Verwendung von IP-Adressen
		\item Binding: Cache-Server, der die Verknüpfungen zwischen den Endpunkten verwaltet. Dadurch bei der Kommunikation keine Adressen erforderlich \(\rightarrow\) Quelle muss Zielgerät nicht kennen
		\item Gruppenverwaltung: Endpunkte können mehreren Gruppen zugeordnet werden. In der \textit{Gruppentabelle} werden Gruppen IDs lokalen Endpunkten zugeordnet
		\item \textbf{Geräteklassen bzw. Rollen}
		\begin{itemize}
			\item Koordinator (FFD): Verwaltung des ZigBee-Netzwerks, beeinflusst Netztopologie, Funkkanal, etc.
			\item Router (FFD): Kann Dateneinheiten im Netzwerk weiterleiten
			\item Endgerät (FFD, RFD): Geräte ohne Weiterleitungsfunktion
		\end{itemize}
		\item \textbf{Routing}
		\begin{itemize}
			\item Baumtopologie
			\begin{itemize}
				\item Topologie: Ein Koordinator als Wurzel, Router als weitere Elternknoten, Endgeräte als Blätter
				\item Statisches Adressierungsschema, das für jeden Router einen eigenen Adressraum vorsieht \(\rightarrow\) implizite Baumstruktur im Adressraum
				\item Adressen können direkt zum Routing genutzt werden
				\item Vorteile: Weder Pfadsuche noch Zustandshaltung
				\item Nachteile: Ausfallanfällig (keine redundanten Pfade); suboptimale Pfade; falls kein Router mit freier Adresse in Reichweite: kein Netzzutritt möglich
				\item Beacon-Modus möglich: Duty-cycling für alle Knoten
			\end{itemize}
			\item Meshtopologie
			\begin{itemize}
				\item Topologie: Ein Koordinator im Netzwerk, Router verbinden untereinander und Endgeräte verbinden sich zum nächsten Router
				\item Adressen werden zufällig gewählt. Koordinator stellt sicher, dass keine Kollisionen entstehen
				\item Ad-hoc on Demand Distance Vector Routing (AODV): Fluten von Routinganfragen worauf hin das Zielsystem die Anfrage beantwortet und so ein bidirektionaler Pfad zwischen den Routern aufgebaut wird. Das Endsystem eteiligt sich nicht an der Pfadsuche
				\item Vorteile: Robust, selbstheilend; eventuell bessere Pfade
				\item Nachteile: Kein Beacon-Modus, höherer Ressourcenbedarf
			\end{itemize}
		\end{itemize}
		\item Varianten von ZigBee, die im Rahmen der Standardisierung entstanden sind
		\begin{itemize}
			\item ZigBee 2007 - Stack-Profile
			\begin{itemize}
				\item ZigBee: Baumtopologie mit statischem Routing und "`normaler Sicherheit"'. Reduzierte Funktionalität und einfache Verfahren \(\rightarrow\) insgesamt geringer Ressourcenbedarf
				\item ZigBee Pro: Meshtopologie mit freier Adressvergabe, die Concast, Multicast und Source-Routing beherrscht. Sicherheitsstandard mit hohem Anspruch
			\end{itemize}
			\item ZigBee IP
			\begin{itemize}
				\item Basiert auf 6LoWPAN und definiert einen Protokollstapel auf Basis etablierter Standards: RPL, TCP, HTTP+TLS, ZigBee SE 2.0
				\item Spezifiziert im Wesentlichen Datenformate, Schnittstellen und Anwendungsverhalten
			\end{itemize}
		\end{itemize}
		\item Sicherheit
		\begin{itemize}
			\item Netzwerkschicht: Single-Mission-Key für das gesamte Netzwerk
			\item Anwendungsunterstützungsschicht: Separate Schlüssel für jede (Unicast) E2E-Verbindung
			\item Schlüsselverwaltung durch Trustcenter
		\end{itemize}
	\end{itemize}
	\item \textbf{EnOcean}
	\begin{itemize}
		\item Energie bei Energy Harvesting nur eingeschränkt (zeitweise) verfügbar \(\rightarrow\) keine Kontrolle und Planbarkeit; diskontinuierlicher Betrieb
		\item Kooperativer Medienzugriff impliziert Verzögerung und Kosten
		\item Beispiele für Energiegewinnung mit Energy Harvesting: Kinetische (Lichtschalter)/thermische Energie, Solarenergie
		\item EnOcean extrem angepasst an eingeschränkte Energieversorgung (minimale, hochoptimierte Nutzdaten von \(\sim 1 Byte\) oft ausreichend)
		\item Mailbox-Konzept für bidirektionale Kommunikation: Zentrales Gateway (kontinuierliche Stromversorgung) speichert Antwortpakete zwischen und leitet lediglich in einem definierten Zeitfenster weiter
	\end{itemize}
\end{itemize}

\subsubsection{Industrial Internet}
\begin{itemize}
	\item Bisher Fokus auf Energiebedarf und Leistungsfähigkeit. Jetzt harte Echtzeit- und Verfügbarkeitsanforderungen: Deterministisches Verhalten, geringe Latenz sowie Isolierung des Verkehrs von verschiedenen Kunden
	\item Anwendungsgebiete: AV-Streaming (im Studio-Einsatz), Industie 4.0 (Prozessleitsysteme, Maschinensteuerung)
	\item \textbf{WPAN}
	\begin{itemize}
		\item Drahtlose Ansätze aus dem Internet der Dinge auf Grund hoher Fehlerraten und geringer Robustheit keine gangbare Möglichkeit
		\item Verwendung von 6LoWPAN (nahtlose Integration in IP-basierte Lösungen) mit \textit{Time-Slotted Channel Hopping} (TiSCH), einem Medienzugriffsverfahren, das eine hohe Robustheit und weniger Fehleranfälligkeit verspricht
		\item Time Slotted Channel Hopping (TiSCH)
		\begin{itemize}
			\item Entwicklung neuer Medienzugriffsverfahren basierend auf synchronem Zeitmultiplex (feste Zeitschlitze) und Channel Hopping (Wechsel der Frequenz für jede zu übertragende Dateneinheit \(\rightarrow\) Sendewiederholungen erfolgt auf einer anderen Frequenz)
			\item Vorteile: Planebare Belegung; Bandbreitenzuteilung möglich; Frequenzwechsel verbessert Robustheit (Störungen durch Signalüberlagerung betreffen normalerweise nie alle Funkkanäle)
			\item Umsetzung als neuer Betriebsmodus in \texttt{IEEE 802.15.4e}
			\item Netzwerkstack
			\begin{itemize}
				\item \texttt{CoAP}
				\item \texttt{UDP}
				\item \texttt{RPL}
				\item \texttt{IPv6 mit 6LoWPAN-Adaption}
				\item \texttt{(6)TiSCH}: Umsetzung von Scheduling
				\item \texttt{802.15.4e}
			\end{itemize}
			\item Synchronisation
			\begin{itemize}
				\item Problem: Knoten müssen sehr genau synchronisiert werden (auf etwa 1 ms genau) \(\rightarrow\) wiederkehrende Synhronisation notwendig
				\item Lösung: Einführung von \textit{Time-Mastern}, wozu verschiedene Verfahren möglich sind
				\item Umsetzung entweder über paketbasierte Synchronisierung (messen der Ankunftszeit der der Pakete und verlängern/verkürzen der eigenen Aktivitätsphase); ACK-basierte Synchronisierung oder regelmäßige Keep-Alive Nachrichten (alle 30 s), falls keine Kommunikation stattgefunden hat
			\end{itemize}
		\end{itemize}
	\end{itemize}
	\item \textbf{LAN}
	\begin{itemize}
		\item Keine Änderung des Medienzugriffsverfahren. Einhalten von Garantien durch geeignetes Scheduling (übergeordnete Planung/Koordination der Mediennutzung)
		\item Grundlegendes Konzept
		\begin{itemize}
			\item Geringe Latenzen und hohe zuverlässigkeit: Keine Paketverluste/große Puffer in Zwischensystemen möglich
			\item Explizite Reservierung von Bandbreite. Dadurch entstehen keine Überlastsituation \(\rightarrow\) keine Pufferung nötig \(\rightarrow\) deterministische Latenzen
		\end{itemize}
	\end{itemize}
\end{itemize}


\section{Sicherheit}
\begin{itemize}
	\item Kryptografische Operationen sind teuer und benötigen viel Speicher. Speziell asymmetrische Schlüssel benötigen noch mehr Speicherplatz als symmetrische \(\rightarrow\) vermeide asymmetrische Kryptografie so weit wie möglich
\end{itemize}

\subsection{Schlüsselaustausch in Sensornetzen}
\begin{itemize}
	\item Klassische Schlüsselaustauschprotokolle benutzen häufig zentrale Komponenten (beispielsweise PKIs), Einsatz von Diffie-Hellman aufgrund von Ressourcenbeschränkungen schwierig
	\item \textbf{Verfahren zum Schlüsselaustausch}
	\begin{itemize}
		\item Single-Mission-Key
		\begin{itemize}
			\item Alle Systeme erhalten vor ihrer Ausbringung den selben Schlüssel, der zur Kommunikationsicherung (Verschlüsselung, Integrität, etc.) verwendet wird
			\item Problem: Sobald ein System korrumpiert wird, ist die gesamte Kommunikation im Netz unsicher
			\item Paarweise Schlüssel mit allen Systmen: Extrem hoher Speicherbedarf; was passiert, wenn neue Systeme dem Netz beitreten?
		\end{itemize}
		\item Zufallsverteilte Schlüssellisten: Ansatz von Eschenauer und Gligor
		\begin{itemize}
			\item Benutzer erstellt vorab offline eine große Liste mit verschiedenen, nummerierten Schlüsseln. Jedes System, das dem Netz beitreten soll, bekommt vorab eine zufällige Teilmenge dieser Schlüssel
			\item Zwei Systeme, die kommunizieren wollen besitzen mit einer bestimmten Wahrscheinlichkeit einen gemeinsamen Schlüssel; falls nicht lässt sich ein Schlüsselpfad konstruieren
			\item Alle Systeme bilden mit einer Wahrscheinlichkeit \(>99\%\) einen zusammenhängenden Schlüsselgrafen
			\item Finden von gemeinsamen Schlüsseln: \texttt{System 1} sendet eine Liste seiner Schlüsselnummern im Klartext an \texttt{System 2}. \texttt{System 2} antwortet mit einer gemeinsamen Schlüsselnummer, ebenfalls im Klartext \(\rightarrow\) unsicher
			\item Erweiterung um Challenge: \texttt{System 1} sendet Zufallszahl \(Z\) sowie jeweils verschlüsseltes \(Z\) (also (\(Z, ENC_{1..n}(Z)\)) an \texttt{System 2}. \texttt{System 2} antwortet beispielsweise mit \(ENC_2(Z+1)\) \(\rightarrow\) teuer
			\item Simulierte Sicherheitsbetrachtung mit \(n\) Systemen: Logarithmisches Wachstum der prozentualen Anzahl an gebrochener Verbindung, abhängig vom Prozentsatz der kurrumpierten Systeme. Spätestens bei 10 \% Korruption sind nahezu alle Verbindungen unsicher
			\item Fazit: Insgesamt unsicher, kommt allerdings ohne zusätzliche Infrastruktur aus \(\rightarrow\) Tradeoff zwischen Speicherverbrauch und Sicherheit der Schlüssel
		\end{itemize}
		\item Key Infection: Smart Trust for Smart Dust
		\begin{itemize}
			\item Einsatzszenario: Viele, sehr günstige und zufällige ausgebrachte Sensorknoten mit eingeschränktem Angreifermodell (kann nicht das komplette Netz abhören und kann keine Angriffe während der Schlüsselaustauschphase starten)
			\item \textit{Key Infection}: Inital gegenseitiger Schlüsselaustausch jeweils zwischen allen Systemen in Reichweite. Dazu sendet \texttt{Knoten 1} einen zufälligen Schlüssel und versendet ihn per Broadcast. \texttt{Knoten 2} wählt einen gemeinsamen Sitzungsschlüssel und sendet diesen zusammen mit seiner ID verschlüsselt an \texttt{Knoten 1}
			\item Protokoll (2 und 3 optional)
			\begin{enumerate}
				\item Key Infection: Initialer Schlüsselaustausch zwischen Nachbarknoten
				\item Multihop Key Exchange: Schlüsselaustausch zwischen nicht benachbarten Knoten
				\item Secrecy Amplification: Verstärkung der Schlüsselsicherheit durch Nutzung von Mehrweg Austausch
			\end{enumerate}
			\item Zusammenfassung
			\begin{itemize}
				\item Einfaches Schlüsselaustauschprotokoll mit geringem Speicheraufwand für Schlüsselmaterial
				\item Hoher Kommunikationsaufwand da in der Praxis alle Knoten nahezu gleichzeitig anfangen Schlüssel auszutauschen \(\rightarrow\) viele Sendewiederholungen durch Kollisionen
				\item Tatsächlicher Angreifer eventuell mit mehr Möglichkeiten
			\end{itemize}
		\end{itemize}
		\item Stand der Forschung: Einige neue Ansätze mit asymmetrischen Verfahren auf dem Weg zur Standardisierung
	\end{itemize}
\end{itemize}


\subsection{Standardisierung - Sicherheit im IoT}
\begin{itemize}
	\item \textbf{Sicherheit in \texttt{IEEE 802.15.4}}
	\begin{itemize}
		\item Link-Layer-Schutzmechanismus durch symmetrisches \texttt{AES-CCM}: Zunächst \texttt{AES-CBC-MAC} zur Integritätssicherung, anschließend Verschlüsselung durch \texttt{AES-CTR}
		\item Generelles Problem: Jede Kombinationen aus Schlüssel und Initialisierungsvektor (Nonce) darf nur einmal verwendet werden \(\rightarrow\) Nonce beinhaltet einen Frame-Zähler
	\end{itemize}
	\item \textbf{DTLS In Constrained Environments (DICE): Draft bei der IETF}
	\begin{itemize}
		\item Ziel: Effiziente Nutzung von DTLS in IoT/IoE-Anwendungen
		\item Problem: (D)TLS zu komplex/speicherintensiv für IoE-Anwendungen \(\rightarrow\) Spezifizierung eines TLS/DTLS-Profils mit angepasstem Umfang (DICE)
		\item Soll Vertraulichkeit sicherstellen und auf ressourcenbeschränkten Systemen implementierbar sein
		\item Definition von DTLS-Konfigurationen, die effizient und sicher sind
		\item DICE DTLS-Profil
		\begin{itemize}
			\item Einschränkung der unterstützten, kryptografischen Algorithmen auf eine wenige sichere, aber auch effiziente
			\item Einschränkung der Authentifizierungsmechanismen: Preshared Keys, Raw Public Keys, Zertifikate
			\item Einschränkung der Protokollerweiterungen und Funktionen
		\end{itemize}
		\item Einschränkung der Cipher-Suites auf AES, SHA-1 und Elliptische Kurven (effizienter als RSA, geringere Schlüssellänge als RSA)
	\end{itemize}
	\item \textbf{Delegated CoAP Authentication und Autorization (DCAF): Draft bei der IETF}
	\begin{itemize}
		\item Problem bisher: Existierende Sicherheitslösungen sind zu komplex für IoE, auch mit DICE ist asymetrische Kryptografie zu teuer
		\item Idee \textit{Delegated Security}: Authentifizierung und Autorisierung durch vertrauenswürdigen Stellvertreter zur Entlastung der ressourcenbeschränkten Systeme. Allerdings entsteht so ein höher Kommunikationsaufwand (Tradeoff zwischen Kommunikations- und Berechnungsaufwand)
		\item Spezifiziert einen Delegationsmechanismus in CoAP und ist darin eingebettet. Keine zusätzliche Protokollschicht
		\item Nur symmetrische Verschlüsselung auf ressourcenbeschränkten Systeme mit individueller Autorisierung für jede CoAP-Ressource
		\item Rollen
		\begin{itemize}
			\item Besitzer sowie eingeschränkte System (Clients oder Servers)
			\item Vertrauensbeziehung zwischen Besitzern durch Zugriffsberechtigungen
			\item \textit{Client Authentication Manager} (CAM) übernimmt die Rolle des Clients im Autorisierungsprozess
			\item \textit{Server Authentication Manager} (SAM) vertritt den Server im Autorisierungsprozess
		\end{itemize}
		\item Delegation - Architektur
		\begin{itemize}
			\item Jeweils symmetrische Schlüssel zwischen Client und CAM, Server und SAM
			\item Wechselseitige Authentifizierung von CAM und SAM (beispielsweise mit Zertifikaten)
		\end{itemize}
		\item Ablauf
		\begin{enumerate}
			\item Unautorisierte Anfragen Client \(\rightarrow\) Server: Server verweist Client an SAM. Bei Autorisierungsanfragen an CAM enthält die Anfrage die URI des SAM. CAM kann die Anfragen ablehnen oder einschränken
			\item SAM stellt jeweils für Client und Server ein Ticket mit gemeinsamem Geheimnis aus. Das Client-Ticket wird zunächst CAM geschickt
			\item CAM leitet Client-Ticket an Client weiter
		\end{enumerate}
	\end{itemize}
\end{itemize}


\subsection{Reality Check}

\subsection{Fallbeispiel: BMW ConnectedDrive}
\begin{itemize}
	\item Cloud-basierter Dienst zur Steuerung des Autos aus der Ferne. Kommunikation via SMS und HTTP
	\item \textbf{Schutzmechanismen}
	\begin{itemize}
		\item Sicherheitsmechanismen sind im Modem (im Auto) implementiert. Mikrokontroller realisiert Basisfunktionalität und überwacht das Modem
		\item Verschlüsselung wahlweise AES oder DES, Signaturverfahren mit DES-CBC-MAC, HMAC-SHA1 oder HMAC-SHA256
		\item Schlüsselmaterial ist fest im Modem implementiert und bei allen Fahrzeugen gleich \(\rightarrow\) relativ einfach zu extrahieren
	\end{itemize}
	\item \textbf{Angriff}
	\begin{itemize}
		\item Ausgangspunkt: Falsche Mobilfunk-Basisstation \(\rightarrow\) Auto bucht sich ins gefälschte Netz ein
		\item Angreifer weckt das Steuergerät mit einer SMS
		\item Auto fordert Befehler per HTTP(!) aus der Cloud an
		\item Angreifer antwortet mit gewünschtem Steuerbefehl. Die Nutzdaten sind mit bekannten Schlüsseln verschlüsselt und signiert
		\item Auto akzeptiert Befehle nur, wenn die Fahrgestellnummer übereinstimmt...schickt diese allerdings per SMS an den Angreifer, wenn sie nicht übereinstimmt
		\item Letzte Hoffnung: ConnectedDrive kann deaktiviert werden, ist aber über den gleichen Angriff wieder aktivierbar
	\end{itemize}
	\item \textbf{Was ist schief gelaufen?}
	\begin{itemize}
		\item Ein gemeinsamer Schlüsselsatz für alle Fahrzeuge des Herstellers
		\item Keine Authentifizierung der ConnectedDrive Cloud
		\item Unnötige Preisgabe von zur Validierung nutzbaren Informationen
	\end{itemize}
\end{itemize}

\subsubsection{Fallbeispiel: Philips Hue}
\begin{itemize}
	\item Plattform für "`intelligente"' Beleuchtungssysteme, basiered auf ZigBee Light Link; direkt per ZigBee steuerbar; Verfügbar auch über das Internet
	\item Absicherung durch Single Mission Key: Ein Netzwerkschlüssel für alle Geräte im PAN \(\rightarrow\) sicher solange der Angreifer nicht an den Schlüssel kommt
	\item Problem: Reichweitenbegrenzung zum Gerätemanagement kann durch Programmierfehler umgangen werden. Nach Rücksetzen des Gerätes bucht es sich (als normales ZLL-Gerät) auch in fremde Netze ein
\end{itemize}


\subsection{Projekte}
\begin{itemize}
	\item \textbf{Kompetenzzentrum für angewandte Sicherheitstechnologien (KASTEL)}
	\begin{itemize}
		\item Herausforderungen
		\begin{itemize}
			\item ZeroConf vs. LittleConf vs. Expert
			\item Nutzung von IPv6
			\item Stark heterogene Netze mit unterschiedlichen Sicherheitsanforderungen in Teilen des Netzes
			\item Sicherheit verursacht Kosten: Energieeffizienz
		\end{itemize}
		\item Funktionale Domäne: Komponenten im Smart-Home, die gemeinsam eine bestimmte Funktion erfüllen
		\item Sicherheitszone: Setzt Komponenten des Smart-Home mit gleichem Schutzbedarf in Vertrauensbeziehungen (beispielsweise "`intern"' und "`extern"'). Funktionale Domänen können sich über mehrere Sicherheitszonen erstrecken
		\item Zonenübergänge müssen kontrolliert werden (Firewall, VLANs, etc.)
	\end{itemize}
	\item \textbf{FleGSens}
	\begin{itemize}
		\item Untersucht die Möglichkeit einer sicheren und flexiblen Überwachung von Grenz- und Liegenschaften mit Hilfe von drahtlosen Sensornetzen. Prototyp überwacht eine 350 m lange Grenze mit 200 Sensorknoten
		\item Herausforderungen: Unsichere/raue Umgebung, Protokolle zum Betrieb und zur Ortung von Eindringlingen, Absicherung gegen Angriffe mit IT-Mitteln, sicherer Betrieb auch bei Ausfall von 10\% der Knoten
		\item Protokolle
		\begin{itemize}
			\item Trackingprotokoll mit Lokalisierung
			\item Zeitsynchronisation
			\item Knotenausfallerkennung, Partitionserkennung, DoS-Erkennung
		\end{itemize}
	\end{itemize}
\end{itemize}