Cloud Computing zur Optimierung einer Netzwerkpartitionierung. Bachelorarbeit

Transkript

1 Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Informatik Lehrstuhl für Informations- und Kommunikationsdienste Cloud Computing zur Optimierung einer Netzwerkpartitionierung Bachelorarbeit Erstgutachter und Betreuer: Dr. Thomas Mundt Zweitgutachter: Dipl.-Inf. Till Wollenberg vorgelegt von: Georgi Straube Abgabedatum: 15. August 2011

2 Inhaltsverzeichnis 1 Einleitung Motivation Zielstellung Gliederung der Arbeit Stand der Technik Drahtlose Mesh-Netzwerke Prinzip Charakteristik von Mesh-Netzwerken Einsatzgebiete Interferenzen und Multichanneling in Mesh-Netzwerken Routing Netzwerkalgorithmen Kürzeste Wege in Graphen Cloud Computing Prinzip Ausprägungen Anbieter von Cloud-Diensten Konzept Brute-Force-Berechnungen Datengrundlage Beschränkung der zu betrachtenden Knoten Vereinfachungen Überprüfung der Gültigkeit einer Kanalzuordnung Zielfunktion Kontroll- und Datenfluss Annahmen Implementierung Auswahl eines Cloud-Anbieters Parallelisierung mittels Mapreduce Model-View-Controller-Architektur Zusammenfassung Auswertung Erfahrungen mit der Cloud Ausblick A Anhang 53 A.1 Anleitung zur Nutzung der Anwendung A.1.1 Netzwerkübersicht A.1.2 Starten von Mapreduce-Jobs

3 A.1.3 Bewertung A.1.4 Hochladen von Dateien A.1.5 Leeren des Datastore A.2 Funktion zur Berechnung des kartesischen Produkts

4 1 Einleitung 1.1 Motivation Drahtlose Kommunikationstechnologien sind auf dem Vormarsch. Die Verwendung dieser erstreckt sich von der Gerätekommunikation über kleine Entfernungen hinweg (z.b. via Bluetooth oder einer Infrarot-Schnittstelle) über das Mobilfunknetz und WLAN bis hin zur Positionsbestimmung mittels GPS. Die zugrundeliegenden Technologien sind dabei auf einen spezifischen Einsatzzweck hin ausgerichtet. So steht beispielsweise bei Mobilfunknetzen die Abdeckung eines größtmöglichen Gebiets mittels einer Basisstation im Vordergrund, wohingegen im Falle von WLAN-Netzen eine hohe Datenübertragungsrate wichtig ist. Möchte man diese beiden Eigenschaften kombinieren, stößt man auf Probleme: Mobilfunknetze der neuesten Generation (3G) bieten eine niedrige Übertragungsrate, die bestenfalls ungefähr 2 Mbps beträgt, während die Abdeckung durch einen Access Point bei WLAN gering ist und die Mobilität des Nutzers dadurch eingeschränkt wird. [Sic05, S. 1]. Um dennoch eine mobile, schnelle und kostengünstige Datenkommunikation zu ermöglichen, hat das Institute of Electrical and Electronics Engineers 1 (IEEE) den Standard entworfen, der auch unter der offiziellen Bezeichnung WirelessMAN bzw. als WiMAX 2 (nach dem Industriekonsortium WiMax Forum benannt) bekannt ist. Dieser Standard spezifiziert ein Funknetz, das einen Breitbandzugang ermöglicht. Es werden Frequenzen unterhalb von 10 GHz sowie im Bereich GHz verwendet. Im letzten Fall muss eine Sichtverbindung (Line Of Sight) zwischen Sender und Empfänger gegeben sein [Sch10, S. 37]. Dies wertet Mihail L. Sichitiu als Nachteil von WirelessMAN und hebt ferner die (noch) fehlende Unterstützung von mobilen Nutzern als negativen Aspekt hervor [Sic05, S. 1]. Als Alternative, die diese Mängel nicht aufweist, führt er drahtlose Mesh-Netzwerke (englisch: Wireless Mesh Networks, im Folgenden als WMNs abgekürzt) an. WMNs können aufgrund ihrer Architektur und der sich daraus ergebenden Eigenschaften (siehe 2.1.2) eine Vielzahl von unterschiedlichen Anforderungen erfüllen, womit sie eine große Bandbreite an möglichen Einsatzszenarien abdecken. Einige davon werden in Abschnitt geschildert. Ein Einsatzgebiet stellen freie Funknetze dar. Freie Funknetze werden von Privatpersonen, die in einem Verein organisiert sein können, aufgebaut und haben keinen kommerziellen Hintergrund. Im Vordergrund steht der Austausch von Informationen sowie die Kommunikation untereinander. Der Zugang ins Internet wird dadurch ermöglicht, dass einige Nutzer ihren Internetanschluss zur Verfügung stellen. Das Konzept von freien Funknetzen wird in [FREa] näher erläutert. Weltweit wurden in vielen Städten freie Funknetze aufgebaut. Eine Übersicht über die Worldwide Interoperability for Microwave Access 4

5 in Deutschland, Österreich, der Schweiz und einigen anderen Ländern vorhandenen Funknetze ist in [FREb] zu finden. In Rostock und Umgebung betreibt der Verein Opennet Initiative mit ungefähr 160 Mitgliedern seit 2005 ein Funknetz [OPE]. Hierbei wird zum einen handelsübliche Hardware eingesetzt, d.h. WLAN-Access-Points, die auch für den Aufbau eines Heimfunknetzes eingesetzt werden (nach dem IEEE-Standard b/g). Zusätzlich wird im Backbone- Bereich von leistungsfähigeren Routern Gebrauch gemacht, die nach dem IEEE-Standard a arbeiten. Der Netzwerkverkehr verläuft hauptsächlich zwischen den Knoten, die als Gateways ins Internet fungieren, und den Knoten, die von den Endnutzern betrieben werden. Zum gegenwärtigen Zeitpunkt verwenden alle Knoten dieselbe Frequenz. Dies führt zu Interferenzen, die negative Auswirkungen auf die Qualität der Verbindungen zwischen den Knoten und damit auf die Dienstgüte insgesamt haben. Dies wird näher in Abschnitt ausgeführt. Um das Auftreten von Interferenzen zu reduzieren, können den Knoten verschiedene Kanäle im Sinne der Standards zugewiesen werden. 1.2 Zielstellung Eine Untersuchung der Auswirkungen von Interferenzen im Opennet sowie der Möglichkeiten zur Vorhersagbarkeit dieser wurde von Till Wollenberg in [Wol10] vorgenommen. Der Gegenstand dieser Arbeit ist die Untersuchung von Eigenschaften des Opennet- Netzwerkes, die sich bei der Verwendung von mehr als einer Frequenz ergeben. Im Vordergrund stehen dabei die Veränderungen der Netztopologie. Die Auswirkungen, die ein Wegfall der Interferenzen mit sich bringt, sollen hingegen nicht gesondert betrachtet werden. Es soll ein Großteil aller möglichen Kanalzuordnungen berechnet und betrachtet werden. Dadurch ergibt sich ein hoher Rechenaufwand. Aus diesem Grund sollen die Berechnungen in der Cloud ausgeführt werden. Hierfür werden verschiedene Cloud-Computing-Angebote betrachtet und ein Cloud-Anbieter ausgewählt. Es wird eine Anwendung konzipiert und implementiert. Die in der Cloud-Infrastruktur ausgeführten Berechnungen werden vorgestellt und erörtert. 1.3 Gliederung der Arbeit In Abschnitt 2 wird ein Überblick über Sachgebiete gegeben, die für diese Arbeit relevant sind. Zunächst werden in 2.1 technologische Aspekte und Einsatzgebiete von drahtlosen Mesh-Netzwerken sowie die Problematik von Interferenzen vorgestellt. Anschließend werden Graphenalgorithmen erläutert, die im Bereich der Netzwerke Anwendung finden (Abschnitt 2.2). Schließlich werden in 2.3 die Grundlagen des Cloud Computing dargelegt und einige Cloud-Anbieter präsentiert. Das Anwendungskonzept wird in 3 vorgestellt. Hierbei wird auf die Datengrundlage 5

6 eingegangen (3.2), Vorüberlegungen werden geschildert (3.3, 3.4, 3.5 und 3.6) und schließlich der Kontroll- und Datenfluss entworfen (3.7). Ebenso werden getroffene Annahmen genannt (3.8). Die Implementierung wird in 4 beschrieben. Die Auswahl eines Cloud-Angebots wird begründet (4.1) sowie die Parallelisierung der Anwendung mittels der Mapreduce-Bibliothek vorgestellt (4.2). Ferner wird die Verwendung des Model-View-Controller-Entwurfsmusters erläutert (4.3). Abschließend werden in Abschnitt 5 die im Rahmen dieser Arbeit durchgeführten Berechnungen ausgewertet (5.1) und die mit der Cloud gesammelten Erfahrungen dargelegt (5.2). Des Weiteren werden die erzielten Resultate betrachtet sowie ein Ausblick über mögliche Verbesserungen gegeben (5.3). 2 Stand der Technik 2.1 Drahtlose Mesh-Netzwerke Prinzip Der Begriff Mesh bezeichnet eine Netzwerk-Topologie, die sich dadurch auszeichnet, dass jeder Teilnehmer im Netzwerk Verkehr weiterleitet, der für andere Teilnehmer bestimmt ist. Die Knoten im Netzwerk sind somit gleichgestellt, was eine übergeordnete Kontrollinstanz überflüssig macht. Wenn alle Knoten miteinander verbunden sind, spricht man von einem voll vermaschten, andernfalls von einem teilvermaschten Netzwerk. Voll vermaschte Netzwerke sind jedoch selten, da sie zu komplex sind und einen hohen Konfigurationsaufwand erfordern. Da die Verbindungen zwischen den Knoten von diesen selbst hergestellt werden, ohne dass ein Konfigurieren von außen notwendig wäre, ergibt sich eine hohe Ausfallsicherheit. Der Verlust einer Verbindung wird dadurch kompensiert, dass die Daten über eine andere Route umgeleitet werden. Zu diesem Zweck können im Netzwerk redundante Verbindungen vorhanden sein. In einem WMN können nach [NNS + 07, S. 79] drei Arten von Knoten unterschieden werden: Mesh-Punkte, Mesh-Router und Mesh-Clients. Mesh-Router zeichnen sich dadurch aus, dass sie als Gateway ins Internet oder zu anderen Netzen fungieren sowie Routing im Mesh-Netzwerk betreiben [AWW05, S. 447], während Mesh-Punkte nur den Verkehr weiterleiten. Mesh-Clients sind die Endgeräte, die sich mit den stationären Mesh-Punkten oder -routern verbinden. Akyildiz et al. unterscheiden drei Arten von Mesh-Netzwerken [AWW05, S. 447ff.], die im Folgenden vorgestellt werden sollen. Im Gegensatz zu Nandiraju et al. wird hier nur zwischen Mesh-Routern und -Clients unterschieden. Infrastructure/Backbone WMNs: Die Router bilden das Backbone des Netzwerks. Sie vernetzen sich untereinander, wobei die Verbindungen dynamisch aufge- 6

7 Abbildung 1: Hybrid WMN (Quelle: [AWW05, S. 448]) baut werden. Die Kommunikation der Router untereinander kann dabei entweder kompatibel zum IEEE-Standard sein, sodass sich die Clients direkt mit dem Router verbinden können, oder auf einer anderen Funktechnologie basieren, wobei in diesem Fall zusätzlich WLAN-Basisstationen eingesetzt werden, die per Kabel an den Router angeschlossen werden. Die Router werden typischerweise auf Häuserdächern platziert und versorgen Clients in Gebäuden und auf der Straße, während für die Kommunikation untereinander gerichtete Antennen eingesetzt werden. Client WMNs: Diese Form der Mesh-Netzwerke zeichnet sich durch die Abwesenheit einer Backbone-Infrastruktur aus, d.h. auf Router wird verzichtet, sodass die Clients Pakete im Netzwerk selbst routen. Hierbei wird meist nur eine Funktechnik eingesetzt. Client WMNs erfordern einen erhöhten Konfigurationsaufwand. Hybrid WMNs: Hybrid WMNs stellen eine Kombination aus Infrastructure/- Backbone WMNs und Client WMNs dar. Der Netzwerkverkehr wird sowohl von den Routern als auch von den Clients geroutet, womit letztere nicht auf die Verbindung zu einem Router angewiesen sind, um Zugang zum Mesh-Netzwerk zu erhalten. Dies gewährleistet eine bessere Abdeckung und Fehlertoleranz. Die Router können weiterhin als Gateways operieren. In Abbildung 1 ist ein Beispiel für ein Hybrid WMN abgebildet. Drahtlose und drahtgebundene Verbindungen sind durch gestrichelte bzw. durchgezogene Linien gekennzeichnet. 7

8 2.1.2 Charakteristik von Mesh-Netzwerken WMNs besitzen eine Reihe einzigartiger Eigenschaften, die sich aus ihrer Architektur ergeben und ihre Eignung für die in beschriebenen Einsatzgebiete herstellen. Akyildiz et al. stellen folgende Charakteristika heraus [AWW05, S. 449f.]: Multi-Hop-Verbindungen: Pakete in WMNs werden über mehrere Zwischenknoten hinweg vom Sender zum Empfänger transportiert. Dies ermöglicht Verbindungen ohne Sichtkontakt (none light of sight, NLOS) und hat eine hohe Abdeckung zur Folge, ohne dass die Kanalkapazität verringert wird. Auch treten weniger Interferenzen auf und Frequenzen können häufiger wiederverwendet werden. Selbstverwaltung: Die flexible Architektur der WMNs gewährleistet unter anderem die dynamische Erweiterung des Netzwerks, eine einfache Konfiguration, erhöhte Fehlertoleranz sowie niedrige Vorlaufkosten. Ebenso gestaltet sich das Deployment als unaufwendig. Mobilität abhängig vom Typ des Knotens: Mesh-Router sind unbeweglich, während Mesh-Clients stationär oder mobil sein können. Nandiraju et al. heben in diesem Zusammenhang hervor, dass aufgrund der fixen Positionierung der Router die Routing-Algorithmen auf die Auswahl von optimalen Verbindungen mit hoher Bandbreite, geringer Verzögerung und Interferenz ausgelegt sein können, wohingegen die Mobilität der Clients zusätzliche Anforderungen an den Algorithmus stellt [NNS + 07, S. 80]. Einbindung externer Netzwerke: Neben der Peer-to-Peer-Kommunikation zwischen den Clients ist eine Anbindung an das Internet sowie andere Netzwerke möglich. Restriktionen bezüglich Energieverbrauch abhängig vom Typ des Knotens: Da die Router stationär sind, existieren keine Anforderungen bezüglich des Energieverbrauchs. Bei den mobilen Clients ist der Fall anders gelagert. Hieraus ergibt sich - ähnlich wie beim Punkt Mobilität abhängig vom Typ des Knotens - ein Unterschied in der Gestaltung der Routing-Algorithmen für diese zwei Knotentypen: Während im Falle der Clients der Fokus auf Energieeffizienz liegt, steht bei den Routern die Auswahl qualitativ hochwertiger Verbindungen im Vordergrund. Kompatibilität und Interoperabilität mit existierenden Netzwerken: WMNs, die auf Technologien des IEEE-Standards setzen, müssen sowohl solche Clients unterstützen, die Routing im Mesh-Netzwerk betreiben können, als auch herkömmliche Endgeräte. Ferner ist eine Unterstützung anderer Drahtlosnetzwerke, wie beispielsweise WiMAX oder ZigBee, wünschenswert. 8

9 2.1.3 Einsatzgebiete Da WMNs aufgrund der Multi-Hop-Verbindungen keine Kabelverbindung zwischen den einzelnen Routern benötigen, können sie in einer Vielzahl von Fällen eingesetzt werden, wo bisher ein kabelbasiertes oder WLAN-Netzwerk verwendet wurde. Bruno et al. nennen beispielsweise folgende Szenarien [BCG05, S. 124f]: Intelligente Transport-Systeme: Das Ziel besteht darin, Transportsysteme zu bauen, die zuverlässig, günstig, effizient und sicher sind. Hierbei können nach Meinung von Bruno et al. WMNs eingesetzt werden, um Probleme wie Stauvermeidung und Umweltverschmutzung zu adressieren. Als Beispiel für ein in der Praxis eingesetztes System führen die Autoren das Portsmouth Real-Time Travel Information System (PORTAL) an. Dieses bietet an über 40 Standorten in Portsmouth (Großbritannien) den Passagieren in Echtzeit Informationen über das öffentliche Verkehrsnetz an. Das System wird durch ein WMN realisiert, dessen Knoten auf über 300 Busse verteilt sind. Öffentliche Sicherheit: In diesem Bereich wurden bisher funkzellenbasierte Kommunikationssysteme eingesetzt. Diese haben jedoch den Nachteil, eine sehr geringe Bandbreite aufzuweisen und hohe Infrastrukturkosten zu verursachen. Aus diesem Grund empfiehlt sich auch hier der Einsatz von WMNs. Als Beispiel nennen die Autoren das San Matteo Police Department (in den USA), das seine Streifenwagen mit Laptops und Motorräder mit PDAs ausrüstet. Eingesetzt werden WLAN-Karten, die den Standard b/g unterstützen. Ferner wurden 30 WLAN-Access-Points innerhalb der Stadt fest installiert, wobei auf eine proprietäre Mesh-Technologie der Firma Tropos Networks 3 gesetzt wird. Öffentlicher Internet-Zugang: Kleine und große Internet-Provider können von WMNs profitieren, da diese einen flächendeckenden Breitband-Internetzugang ermöglichen, ohne dass Kosten für Aufbau und Pflege einer teuren kabelbasierten Netzwerkinfrastruktur anfallen. Besonders vorteilhaft erweist sich dies in ländlich oder schwach besiedelten Gegenden, wo es nur wenige potentielle Abonnenten gibt. In Cerritos (USA) existiert ein derartiges Netzwerk, das ebenfalls auf Technologie der Firma Tropos aufbaut. Dieses besteht aus mehr als 130 Access Points, die ein Gebiet von über 20 Quadratkilometern abdecken. Dabei sind weniger als 20 Prozent der Access Points an das kabelbasierte Backbone-Netzwerk angebunden. Weitere Einsatzmöglichkeiten werden von Akyildiz et al. erläutert [AWW05, S. 451ff.]: Heimnetzwerke: Üblicherweise werden Heimnetzwerke nach dem WLAN- Standard aufgebaut. Die Positionierung der Access Points erweist sich hierbei als Problem, da sich ohne vorherige Ausmessung viele Funklöcher ergeben. Eine solche Ausmessung ist jedoch teuer. Die Installation vieler Access Points ist ebenso unwirtschaftlich sowie umständlich, da die Access Points über eine Backhaul-Verbindung an ein kabelgebundenes Netzwerk oder das Internet verfügen müssen. Durch die 3 9

10 Multi-Hop-Verbindungen können WMNs helfen, Funklöcher zu überbrücken. Ferner kann die Kommunikation zwischen zwei Endknoten direkt erfolgen, sodass der Umweg über die Backhaul-Verbindungen vermieden und der Netzwerkverkehr über diese reduziert wird. Community- und Nachbarschafts-Netzwerke: Diese Art von Netzwerk wird häufig durch eine Kombination von Kabel- oder DSL-Modem und WLAN-Router realisiert. Hiermit sind folgende Nachteile verbunden: Wenn Daten zwischen den Teilnehmern des Netzwerks ausgetauscht werden, geschieht dies über das Internet, was einen vermeidbaren Mehraufwand darstellt. Große Flächen zwischen Gebäuden sind nicht abgedeckt. Ein in einem Gebäude vorhandener Breitband-Internetzugang kann nicht unter allen Teilnehmern geteilt werden. Access Points müssen für jedes Gebäude separat installiert werden. Hohe Kosten sind die Folge. Es kann vorkommen, dass für ein Gebäude nur eine einzige Verbindung ins Internet bzw. zu einem benachbarten Gebäude verfügbar ist. Durch ihre flexiblen Multi-Hop-Verbindungen können WMNs diese Nachteile aufwiegen. Des Weiteren bieten sie die Grundlage für Anwendungen wie beispielsweise verteilte Datenspeicherung und -zugriff oder Video-Streaming. Unternehmensnetzwerke: Ein Unternehmensnetzwerk kann ein einzelnes Büro, ein ganzes Gebäude oder mehrere Gebäude umfassen. Wie auch bei Heimnetzwerken wird hier häufig auf WLAN gesetzt. Als Problem erweist sich hierbei, dass die einzelnen drahtlosen Netzwerke über Ethernet miteinander verbunden werden müssen. Besonders bei einem großen Netzwerk erweist sich dies als sehr teuer. Der Einsatz von Mesh-Routern anstelle von Access Points macht die Kabelverbindungen überflüssig. Ferner kann ein Internetzugang geteilt werden, d.h. diese Ressource wird besser ausgenutzt. Ebenso ergibt sich eine höhere Fehlertoleranz, ein geringeres Risiko der Netzwerküberlastung sowie eine einfache Erweiterbarkeit des Netzwerks um neue Knoten. Metropolitan Area Networks (MANs): Wie bereits in 1.1 erwähnt, eignen sich WMNs gut zur Realisierung eines MAN, da sie eine hohe Bandbreite bieten und kein kabelbasiertes Backbone-Netzwerk benötigen, sodass der Aufbau kostengünstig erfolgen kann - dies macht drahtlose Mesh-MANs vor allem in unterentwickelten Gegenden zu einer attraktiven Option. Gebäudeautomatisierung: Im Bereich der Gebäudeautomatisierung (Überwachung und Steuerung von elektrischen Geräten wie Klimaanlagen, Aufzügen, Lichtinstallation etc.) wurden bisher kabelbasierte Netzwerke eingesetzt. In letzter Zeit werden auch hier drahtlose Netzwerke nach verwendet. Diese haben jedoch 10

11 den Nachteil, dass ihre Installation aufgrund der benötigten Ethernet-Verkabelung aufwendig ist. In diesem Punkt sind WMNs überlegen. Medizinische Systeme: Krankenhäuser oder andere medizinische Einrichtungen benötigen eine Kommunikationsinfrastruktur, um Daten zwischen Räumen austauschen zu können. Da es sich hierbei um hochauflösende Bilder oder periodisch übermittelte Informationen über den Gesundheitszustand eines Patienten handeln kann, muss die Infrastruktur in der Lage sein, einen konstanten Strom an großen Datenmengen zu bewältigen. Ein kabelbasiertes Netzwerk ist aufwendig und auch WLAN benötigt Ethernet-Verbindungen, wohingegen ein WMN diesen Nachteil nicht aufweist. Sicherheitsüberwachungssysteme: In diesem Fall existiert wie bei medizinischen Systemen die Anforderung an ein Netzwerk, das hohe Datenmengen (Bilder und Video) bewältigen kann, und auch hier erweist sich der Einsatz eines WMNs aufgrund der nicht benötigten Verkabelung als vorteilhaft Interferenzen und Multichanneling in Mesh-Netzwerken Die Knoten in einem Mesh-Netzwerk verwenden für gewöhnlich einen Frequenzkanal. Dies führt jedoch zu Interferenzstörungen innerhalb des eigenen Funksystems (auf Störungen, die durch andere Systeme verursacht werden, wird hier nicht näher eingegangen). Diese Störungen wirken sich negativ auf die Qualität der Verbindungen zwischen den Knoten aus. Der IEEE-Standard sieht sowohl im 2,4- als auch im 5-GHz-Frequenzband mehrere Kanäle vor, von denen höchstens 3 respektive 12 überlappungsfrei zur gleichen Zeit eingesetzt werden können (siehe [IEE07]). Der Einsatz mehrerer Kanäle zur Vermeidung von Interferenzen ist daher naheliegend. Im Folgenden sollen zwei Lösungen zur Realisierung von Multichanneling in Mesh- Netzwerken betrachtet werden sowie ein Überblick über Entstehung und Folgen von Interferenzen gegeben werden. Interferenzen Die Nutzung nur einer Frequenz in einem Funknetzwerk hat verschiedene Auswirkungen. Zum einen erfordert sie einen Mechanismus, mit dem die Netzknoten erkennen können, wann ein Kanal belegt ist und sie somit zur Vermeidung von Kollisionen keine eigenen Signale aussenden dürfen. Der Standard sieht in diesem Zusammenhang den Einsatz von Ready-to-Send- und Clear-to-Send-Nachrichten (RTS bzw CTS) vor. Ein sendewilliger Knoten verschickt hierbei eine RTS-Nachricht an den Empfänger. Dieser antwortet mit einer CTS-Nachricht. Jeder andere Knoten, der im Empfangsbereich der beiden kommunizierenden Stationen liegt, empfängt ebenfalls diese Nachrichten und ist somit darüber informiert, dass der Kanal belegt ist. 11

12 Des Weiteren führt die Verwendung der gleichen oder von sich überlappenden Frequenzen dazu, dass das Signal verrauscht wird. Hierauf soll im Folgenden näher eingegangen werden. Funksignale sind elektromagnetische Wellen, deren Ausbreitung und Intensität durch verschiedene Faktoren beeinflusst wird. Dazu zählen u.a. Reflexion und Streuung, Dämpfung und Beugung (siehe [Lü07, S. 38ff.]). Ferner beeinflussen sich die Funksignale gegenseitig, wobei verschiedene Störungen auftreten können [Lü07, S. 113ff]: Empfängerrauschen: Dieser Störfaktor wird durch zufällige thermische Bewegungen der Elektronen in den elektronischen Bauelementen des Empfängers verursacht [Lü07, S. 113]. Hierdurch wird der Empfang des Nutzsignals beeinträchtigt. Dieses Phänomen ist für alle Funksysteme charakteristisch. Intersymbolinterferenz: Aufgrund der Mehrwegeausbreitung eines Signals kann dieses mehrfach vom Empfänger zu unterschiedlichen Zeitpunkten empfangen werden, wobei sich die Echosignale gegenseitig stören. Störung durch andere Systeme: Ein Funknetz teilt sich das von ihm verwendete Frequenzband typischerweise mit anderen Systemen. Das in WLANs nach dem Standard b/g genutzte 2,4-GHz-Frequenzband ist auch als ISM-Band 4 bekannt, da es in Anwendungen im industriellen, wissenschaftlichen und medizinischen Bereich eingesetzt wird. WLANs nach a teilen sich das 5-GHz-Band u.a. mit Radarsystemen und dem Satelliten- sowie Ortungsfunk. Störungen durch gleichartige Systeme: Beim Einsatz der gleichen oder von benachbarten Frequenzen durch gleichartige Funksysteme kommt es zu Interferenzstörungen. Diese sollen im Folgenden näher betrachtet werden. Der Begriff Interferenz kennzeichnet die Überlagerung von zeitlich versetzten Funkwellen. Abhängig davon wie Wellenberge und -täler aufeinander treffen, kann es hierbei zu einer Verstärkung (bei einer Phasenverschiebung von 0 ) oder einer Auslöschung (180 Phasenverschiebung) des Signals kommen [Rec08]. Die Signal-to-Interference-Ratio (SIR) kennzeichnet das Verhältnis von der Nutzleistung S zur Störleistung I. Die Reference Interference Performance stellt ein Maß dar, das angibt bis zu welcher Störleistung ein hinreichender Empfang im Sinne einer niedrigen BER 5 bzw. FER 6 möglich ist [Lü07, S. 114]. Störungen, die auftreten, wenn zwei Verbindungen den gleichen bzw. benachbarte Frequenzträger benutzen, werden als Co-Channel Interference respektive Adjacent Channel Interference bezeichnet. Der Abstand zwischen zwei Frequenzträgern wird durch die Größe n charakterisiert [Lü07, S. 114f.]: 4 Industrial, scientific, and medical radio band 5 Bit Error Rate. Das Verhältnis von fehlerhaften empfangenen zu insgesamt empfangenen Bits in einem Zeitintervall. 6 Frame Error Rate. Das Verhältnis von fehlerhaften empfangenen zu insgesamt empfangenen Rahmen (Frames) in einem Zeitintervall. 12

13 Abbildung 2: Überlappung der Kanäle bei b (Quelle: wlan_diary, abgerufen am ) System n = 0 n = 0 n = 0 n > 2 IEEE a 5 db -11 db -27 db - Bluetooth 11 db 0 db -30 db -40 db Tabelle 1: Exemplarische Werte für die Reference Interference Performance in Abhängigkeit vom Frequenzträgerabstand (Quelle: [Lü07, S. 155] Wenn die Frequenzträger gleich sind, so gilt n = 0. Bei Frequenzträgern in unmittelbarer Nachbarschaft: n = 1. Wenn zwischen den Frequenzträgern ein dritter Frequenzträger liegt: n = 2. In Abhängigkeit von n legt die Reference Interference Performance einen SIR-Wert fest, bei dem ein hinreichender Empfang (siehe oben) möglich ist. Da sich die Kanäle bei b/g stark überlappen (siehe Abbildung 2), ist die Reference Interference Performance nur dann definiert, wenn n 5 gilt [Lü07, S. 115]. Für a und Bluetooth sind in Tabelle 1 Beispielwerte für die Reference Interference Performance angegeben. Multichanneling Mesh-Netzwerke lassen sich als Single- und Multi-Radio-Netze charakterisieren. In Single- Radio-Netzen verfügen die Knoten jeweils nur über ein Netzwerkinterface, während es bei Multi-Radio-Netzen mindestens zwei sind. In beiden Arten von Netzwerken lassen sich mehrere Kanäle nutzen. Abbildung 3 stellt ein Single-Radio-Netz dar, bei dem nur ein Kanal verwendet wird. Hierbei treten bei allen Verbindungen Interferenzstörungen auf. Wenn wie in Abbildung 4 zwei Frequenzen verwendet werden, sind diese Störungen beseitigt. Das Netzwerk zerfällt jedoch in zwei Partitionen, die keine Verbindung zueinander haben. Abbildung 5 zeigt ein Multi-Radio-Netz, bei dem jeder Knoten über zwei Netzwerkinterfaces verfügt und vier Kanäle verwendet werden - somit sind sowohl Interferenzen ausgeschlossen als auch die Konnektivität zwischen allen Knoten sichergestellt. Im Folgenden wird je ein Beispiel für die Realisierung von Multichanneling in Single-Radiound Multi-Radio-Netzen vorgestellt. 13

14 Abbildung 3: Single-Radio (ein Kanal) Abbildung 4: Single-Radio (zwei Kanäle) Abbildung 5: Multi-Radio (vier Kanäle) 14

15 So (Name des Autors) et al. stellen in [SV04] einen Ansatz für die Nutzung von mehreren Kanälen bei Single-Radio-Netzen vor, bei dem das Netzwerk nicht in voneinander getrennte Partitionen zerfällt. Dieser beruht auf einer Modifikation der im WLAN üblichen MAC-Methode 7 Distributed Coordinated Function (kurz: DCF). Die Autoren erläutern zunächst ein Problem (als multi-channel hidden terminal problem bezeichnet), das bei der Nutzung von mehreren Kanälen im Zusammenhang mit der Nutzung von DCF auftritt [SV04, S. 224f.]. Hierbei wird davon ausgegangen, dass insgesamt n Kanäle genutzt werden, wobei ein Kanal für den Austausch von Steuerdaten reserviert ist, während alle anderen Kanäle für Nutzdaten verwendet werden können. Wenn Knoten A mit Knoten B kommunizieren möchte, verschickt A eine RTS-Nachricht (siehe oben) an B, die eine Liste aller von A akzeptierten Kanäle enthält. B wählt einen Kanal aus und teilt dies A in einer CTS-Nachricht mit. Anschließend können beide Nutzdaten austauschen. Wenn eine dritte Station C jedoch zum Zeitpunkt der Aussendung der RTS-Nachricht auf einem anderen Kanal Daten empfängt oder sendet, wird sie keine Kenntnis davon haben, dass A und B auf einem bestimmten Kanal kommunizieren. Sie könnte dann ihrerseits eine Kommunikation auf diesem Kanal initiieren. Dies würde zu einem Konflikt führen. Die Autoren machen für ihre Lösung folgende Annahmen: Alle Kanäle verfügen über dieselbe Bandbreite und überlappen nicht, d.h. es treten keine Interferenzen auf. Die Knoten wissen im Vorhinein, welche Kanäle zur Auswahl stehen. Jeder Knoten verfügt über einen Transceiver, der im Halbduplex-Modus arbeitet, d.h. er kann auf genau einem Kanal entweder senden oder empfangen. Der Transceiver kann seinen Kanal ändern. Die Uhren aller Knoten sind miteinander synchronisiert. Das vorgestellte Multi-Channel-MAC-Protokoll lässt die Kommunikation zwischen den Knoten in Intervallen verlaufen [SV04, S. 225ff.]. Jedem Intervall ist eine Phase vorangestellt, in der der zu benutzende Kanal zwischen zwei Stationen, die Daten austauschen möchten, ausgehandelt wird. Die dazu verwendeten Steuernachrichten werden auf einem vordefinierten Kanal verschickt, auf dem innerhalb dieser Phase alle Knoten lauschen. Befindet sich ein dritter Knoten im Empfangsbereich von zwei verhandelnden Knoten, so kann er den von ihnen ausgewählten Kanal in einer internen Datenstruktur mit einer niedrigen Priorität versehen, sodass die Wahrscheinlichkeit sinkt, dass er selbst diesen Kanal verwendet. Si (Name des Autors) et al. heben hervor, dass das Multichanneling in Single-Radio-Netzen aufgrund der Verzögerung beim Kanalwechsel und Konnektivitätsproblemen keine große Performance-Verbesserung mit sich bringt [SSZ10, S. 506]. Multi-Radio-Netze weisen diesen Nachteil nicht auf. Ferner ist hier keine Veränderung des MAC-Protokolls nötig. 7 Media Access Control. Vom IEEE eingeführte Teilschicht des Data Link Layers im OSI-Modell, welche u.a. den Zugriff auf das Kommunikationsmedium regelt. 15

16 Jedoch ergeben sich andere Herausforderungen. Zu den wichtigsten gehören dabei die Zuordnung von Kanälen zu den Netzwerkinterfaces sowie das Routing im Netzwerk. Laut Raniwala et al. besteht das Ziel bei der Kanalzuordnung darin, die Bandbreite jeder virtuellen Verbindung so zu gestalten, dass sie in einem proportionalen Verhältnis zu der erwarteten Last steht [RGC04, S. 54]. Aufgabe des Routings ist es, möglichst kurze und qualitativ hochwertige Wege für die Kommunikation zwischen zwei Endknoten zu finden. Dabei sollten Engpässe vermieden werden und die Netzwerklast insgesamt niedrig gehalten und gleichmäßig verteilt sein (Load Balancing). Das von Raniwala et al. entwickelte Verfahren bezieht bei der Kanalzuordnung und dem Aufbau der Routing-Tabellen die zu erwartende Last auf den Verbindungen mit ein. Anfänglich werden dabei Schätzungswerte angenommen. Auf diesen Werten beruhend wird der Routing-Algorithmus und darauffolgend die Zuordnung von Kanälen vorgenommen (wobei darauf geachtet wird, dass die verfügbare Bandbreite die zu erwartende Last übersteigt). Anschließend werden die Routing-Tabellen neu aufgebaut. Dieses Mal stehen dem Routing-Algorithmus Informationen über die zu erwartende Last zur Verfügung, die auf der Kanalzuordnung basieren. Anschließend wird geprüft, ob es Verbindungen gibt, bei denen die Bandbreite niedriger ist als die zu erwartende Last. Wenn dies der Fall ist, wird eine neue Kanalzuordnung vorgenommen. Danach wird eine neue Routing-Tabelle erstellt. Dieser iterative Prozess wird solange wiederholt, bis keine Verbesserung mehr auftritt. Die Autoren stellen für die Kanalzuordnung einen Greedy-Algorithmus vor. Die Verbindungen werden in abnehmender Reihenfolge der zu erwartenden Last betrachtet. Davon ausgehend, dass jeder Knoten über n Netzwerkinterfaces verfügt, wird einer Verbindung zwischen zwei Knoten A und B nach folgendem Prinzip ein Kanal zugeordnet (es sind drei Fälle möglich) [RGC04, S. 54]: 1. Sowohl A als auch B haben weniger als n Kanäle in ihrer Kanalliste. In diesem Fall wird der Kanal mit dem geringsten Interferenzgrad 8 in Bezug auf die Verbindung zwischen A und B ausgewählt. Da die Verbindungen mit der höchsten Last zuerst ausgewählt werden, ist die Wahrscheinlichkeit groß, dass ihnen ein Kanal zugewiesen wird, der wenig durch Interferenzen beträchtigt wird, was sich positiv auf die Kanalkapazität auswirkt. 2. Einer der beiden Knoten (z.b. Knoten A) hat n, der andere weniger als n Kanäle in seiner Liste. In diesem Fall wird derjenige Kanal aus der Liste von A ausgewählt, dessen Interferenzgrad in Bezug auf die Verbindung minimal ist, und zur Kanalliste von B hinzugefügt, sofern er dort noch nicht vorhanden ist. 3. Beide Knoten haben n Einträge in ihrer Liste. Wenn es Überschneidungen in den Listen gibt, wird der Kanal mit dem geringstem Interferenzgrad ausgewählt. Andernfalls wird dieser aus einer der beiden Listen (z.b. der von A) ermittelt. Dem 8 Die Summe der zu erwartenden Lasten auf den virtuellen Verbindungen, denen der gleiche Kanal zugewiesen wurden und die sich in einem Interferenzgebiet befinden. 16

17 Netzwerkinterface, das B für die Verbindung zu A verwendet, wird dieser Kanal zugewiesen, was Auswirkungen auf alle anderen Verbindungen hat, die mittels dieses Interfaces betrieben werden. Der Routing-Algorithmus ist austauschbar. Ihre Untersuchungen haben Raniwala et al. mit zwei unterschiedlichen Algorithmen durchgeführt. Zum einen wurde der Bellman- Ford-Algorithmus verwendet (siehe Abschnitt 2.2.1), wobei als Metrik der minimale Hop-Count dient und der kürzeste Pfad mit ausreichender Bandbreite berechnet wird. Des Weiteren wurde ein Routing-Algorithmus eingesetzt, der zur Laufzeit den Verkehr zwischen zwei Endknoten auf verschiedene Pfade verteilt [RGC04, S. 63]. Die Autoren haben ihr Szenario im Netzwerksimulator ns-2 9 als auch in einer realen Testumgebung erprobt. Hierbei verfügte jeder Knoten über zwei Netzwerkinterfaces. Im Vergleich zu Single-Radio-Netzen mit nur einem Kanal konnte der Datendurchsatz um das 8-fache erhöht wurde [RGC04, S. 63]. Weitere Forschungsfragen betreffen beispielsweise die Entwicklung eines verteilten Kanalzuordnungsalgorithmus, der lokale Entscheidungen treffen kann, sowie die Berücksichtigung von mobilen Nutzern im Netz Routing Das Routing in Mesh-Netzwerken muss Anforderungen gerecht werden, die in kabelbasierten Netzen keine oder nur eine geringe Rolle spielen. Mobile Knoten machen die Netztopologie veränderlich und haben Beschränkungen, was den Energieverbrauch betrifft. Verbindungen sind von unterschiedlicher und veränderlicher Qualität [Fee99, S. 1]. Im Folgenden soll nach [BATT09] eine Einordnung von Routing-Protokollen vorgenommen werden (siehe Abbildung 6). Des Weiteren werden Metriken beschrieben, die in den Routing-Protokollen eingesetzt werden. Proaktive Routing-Protokolle Proaktive Routing-Protokolle zeichnen sich dadurch aus, dass jeder Knoten in Form von Tabellen Informationen darüber enthält, auf welchen Wegen jeder andere Knoten im Netzwerk erreichbar ist. Die Tabellen müssen aktualisiert werden, sobald sich die Netztopologie verändert. Der Vorteil besteht darin, dass eine Route nicht erst berechnet wird, wenn sie gebraucht wird, sodass das Routing keine großen Verzögerungen verursacht. Des Weiteren kann schnell festgestellt werden, ob ein Ziel erreichbar ist. Nachteilig ist, dass der Aufbau und die Aktualisierung der Tabellen die Netzwerkressourcen stark in Anspruch nimmt [Fee99, S. 5]. Der Unterschied zwischen den Protokollen besteht darin, in welcher Form die Routing-Tabellen verwaltet werden [BATT09, S. 142]. Das Optimized-Link-State-Routing-Protokoll (OLSR) gehört zur Klasse der Link-State- Protokolle. Das zentrale Merkmal dieser besteht darin, dass jedem Knoten die gesamte

18 Abbildung 6: Übersicht über Routing-Protokolle (Quelle: [BATT09, S. 133]) Netzwerktopologie als Graph verfügbar ist. Im Unterschied zu Protokollen, die auf Distanzvektoralgorithmen basieren, werden Veränderungen im gesamten Netz propagiert und nicht nur den unmittelbar benachbarten Knoten mitgeteilt. Dieser als Flooding bezeichnete Prozess ist jedoch mit einem signifikanten Overhead verbunden. Eine Verbesserung wird durch OLSR realisiert - die Größe jeder Nachricht und die Anzahl der Aussendungen werden minimiert [BATT09, S. 143]. Die Optimierung wird dadurch erzielt, dass nicht jeder Knoten, sondern nur eine ausgewählte Teilmenge Informationen weiterleiten. Diese Knoten werden als Multipoint Relays (MPR) bezeichnet. Jeder Knoten wählt seine MPRs aus der Menge seiner Nachbarn, die einen Abstand von einem Hop aufweisen. Um Letztere zu ermitteln, verschickt jeder Knoten in periodischen Abständen HELLO-Nachrichten. Aus der Menge der so ermittelten unmittelbaren Nachbarn wird eine (minimale) Teilmenge als MPRs ausgewählt, sodass über die MPRs alle Knoten in einem Abstand von zwei Hops erreichbar sind [AWD04, S. 7f.]. Ein Beispiel für die Auswahl von MPRs ist in Abbildung 7 ersichtlich. Knoten A wählt hierbei seine Nachbarknoten B, C, K und N (blau markiert) als MPRs, da er über diese sämtliche Knoten im Abstand von zwei Hops erreichen kann. Ein weiteres Beispiel für ein proaktives Routing-Protokoll ist das Cluster-head gateway switching routing-protokoll (CGSR). Hierbei wird das Netz in Cluster aufgeteilt, wobei die Informationen über Veränderungen der Topologie nur innerhalb des eigenen Clusters propagiert werden müssen. Pro Cluster existiert jeweils ein Knoten, der dafür zuständig ist, dass die Informationen auch zwischen den Clustern ausgetauscht werden [AWD04, S. 18

19 Abbildung 7: Auswahl von MPRs in OLSR (Quelle: [AWD04, S. 8]) 6f.]. Reaktive Routing-Protokolle Im Gegensatz zu proaktiven Routing-Protokollen werden in reaktiven Routing-Protokollen Routen erst dann berechnet, wenn sie gebraucht werden. Von einem Quellknoten ausgehend wird die Anfrage nach einer Route durch das ganze Netz weitergeleitet (Flooding). Wenn die Anfrage das Ziel selbst erreicht oder einen Knoten, der über eine Route zum Zielknoten verfügt, wird eine Antwort entweder über den gleichen Weg zurückgeleitet (falls die Verbindungen bidirektional sind) oder per Flooding dem Quellknoten zugestellt [AWD04, S. 9f.]. Dieses Prinzip wird beispielse im Dynamic-Source-Routing-Protokoll (DSR) umgesetzt. Jede Anfrage enthält in sich den Weg, den sie bisher zurückgelegt hat. Das erste Paket, das das Ziel erreicht, enthält somit die gewünschte Route (von der angenommen wird, dass sie die Kürzeste ist). Ferner verfügt jeder Knoten über einen Cache, in dem ermittelte Routen abgelegt werden, und der zu Rate gezogen wird, wenn eine Route gefunden werden soll. Des Weiteren werden Pakete verschickt, um im Fall nicht mehr vorhandener Routen die Caches zu aktualisieren [BATT09, S. 133f.]. DSR ist ein Beispiel für Source Routing, wo jedes Datenpaket den gesamten Weg zwischen Quelle und Ziel in seinem Header enthält. Dies hat den Vorteil, dass Knoten zwischen Quelle und Ziel die Pakete weiterleiten können, ohne Informationen über jede aktive Route verwalten zu müssen. Allerdings werden mit einer wachsenden Anzahl von Zwischenknoten die Pakete immer größer, was bei großen Netzwerken problematisch ist. Daher wurden andere Verfahren, wie z.b. das Ad Hoc On-Demand Distance Vector-Protokoll (AODV), entwickelt, die Hop-by-Hop-Routing betreiben. Hierbei wird im Paket nur die Zieladresse vermerkt, sodass dieses von Knoten zu Knoten anhand der Routingtabellen weiterbefördert wird [AWD04, S. 9]. 19

20 Hybride Protokolle Proaktive und reaktive Protokolle lassen sich kombinieren, wie es z.b. beim Zone-Routing- Protokoll (ZRP) der Fall ist. Das ZRP macht sich die Beobachtung zunutze, dass die Kommunikation in Ad-hoc-Netzen meist lokal begrenzt ist und daher die Änderungen in der Nachbarschaft eines Knotens die größte Bedeutung haben. Es werden daher Zonen eingerichtet, innerhalb derer das Routing proaktiv verläuft, während zwischen den Zonen reaktiv geroutet wird [BATT09, S. 145]. Location-Aware Protocols Wenn die Knoten die Positionen aller anderen Knoten im Netzwerk kennen, so kann diese Information für das Routing verwendet werden. Das Location-Aided-Routing-Protokoll beispielsweise setzt GPS ein. Ist die Position eines Knotens sowie seine Bewegungsrichtung und Geschwindigkeit (im Falle mobiler Knoten) bekannt, so werden Routenanfragen nur in das Gebiet des Netzes verschickt, in dem der Knoten vermutet wird. Der durch Flooding verursachte Overhead kann somit drastisch verringert werden [BATT09, S. 149f.]. Multipath-Protokolle Um die Zuverlässigkeit und Bandbreite von Verbindungen zu erhöhen sowie eine Netzwerküberlastung zu vermeiden, bietet es sich an, mehrere Routen für den Weg von der Quelle zum Ziel zu berechnen. Das Caching and Multipath Routing-Protokoll (CHAMP) kann dies leisten. Es sieht zudem bei jedem Knoten einen Cache vor, in dem Pakete zwischengespeichert werden. Bei einem Paketverlust ist ein erneutes Versenden über eine alternative Route somit schnell möglich [BATT09, S. 154f.]. Metriken Campista et al. führen aus, dass in Ad-hoc-Netzen meist die Anzahl an Hops als Metrik verwendet wird. Da die Knoten in einem solchen Netz mobil sind, kommt es vor allem darauf an, Routen schnell berechnen zu können. Hierfür eignet sich die Hop-Count-Metrik gut. In WMNs hingegen sind die Mesh-Router stationär, sodass auch die Güte der Verbindung berücksichtigt werden kann [CEM + 08, S. 6]. Die Expected-Transmission-Count-Metrik bezieht sich auf die erwartete Anzahl von Aussendungen, die nötig sind, um ein Paket erfolgreich von Knoten A zu Knoten B zu übermitteln. Zur Berechnung der ETX-Metrik werden von jedem Knoten in regelmäßigen Abständen Testpakete im Broadcast-Verfahren ausgesendet. Diese enthalten die 20

21 Anzahl der von jedem Nachbarn in einem bestimmten Zeitintervall erhaltenen Testpakete. Der ETX-Wert einer Verbindung vom Knoten A zum Knoten B ergibt sich dann folgendermaßen [CEM + 08, S. 7]: ET X(A, B) = 1 L AB L BA Hierbei bezeichnet L AB das Verhältnis von Paketen, die B von A erfolgreich erhalten hat, zu der Gesamtanzahl an Paketen, die A an B verschickt hat. L BA ist dazu analog definiert, nur dass hier die Rollen von A und B vertauscht sind. Die ETX-Werte für jede Verbindung entlang einer Route werden addiert. Schließlich wird die Route mit der minimalen Summe ausgewählt. Um die Route mit der geringsten Wahrscheinlichkeit eines Paketverlustes zu ermitteln, müssen die einzelnen ETX-Werte multipliziert statt addiert werden. Man spricht dann von der Minimal-Loss-Metrik (ML). Eine weitere auf ETX basierende Metrik stellt die Expected-Transmission-Time-Metrik (ETT) dar. Diese bezieht sich auf die Dauer der erfolgreichen Übertragung eines Datenpakets. Dabei werden u.a. verschiedene Paketgrößen verwendet [CEM + 08, S. 7]. 2.2 Netzwerkalgorithmen Kürzeste Wege in Graphen Die Algorithmen zur Ermittlung kürzester Wege in Graphen zählen zu den grundlegenden Algorithmen der Graphentheorie, die in vielen Gebieten Anwendung finden. Im Bereich der Netzwerke sind es die Routing-Verfahren, die für die Berechnung der kürzesten Route auf diese Algorithmen zurückgreifen. Im Folgenden soll das Problem der Bestimmung der kürzesten Wege formal beschrieben sowie zwei bekannte Verfahren vorgestellt werden. Kürzeste Wege Sei G = (V, E) ein ungerichteter oder gerichteter Graph, wobei V die Menge der Knoten und E die Menge der Kanten bezeichne. Es existiere eine Abbildung w : E R. Das Tupel (G, w) wird dann als Netzwerk und der Wert w(e) als Länge der Kante e bezeichnet [Jun07, S. 59]. Die Länge eines Pfades W = (e 1,..., e n ) ist als w(w ) w(e 1 ) + + w(e 2 ) definiert. Die Distanz d(a, b) zwischen zwei Knoten ergibt sich dann wie folgt [Jun07, S. 60]: 21

22 d(a, b) = {, wenn b nicht von a aus erreichbar ist min{w(w ) : W ist ein Weg von a nach b}, sonst Wichtig ist hierbei, dass nur Wege zwischen a und b betrachtet werden, d.h. alle Pfade zwischen a und b, die Zyklen enthalten, werden ausgeschlossen. Der Grund hierfür ist, dass das Minimum nicht bestimmt werden kann, wenn es einen Pfad gibt, der einen Zyklus negativer Länge enthält. Jeder Weg zwischen a und b, der minimal im Sinne der Gleichung 1 ist, wird als kürzester Weg oder Abstand zwischen a und b bezeichnet [Jun07, S. 60]. (1) Dijkstra-Algorithmus Der Dijkstra-Algorithmus kann in gerichteten oder ungerichteten Graphen eingesetzt werden, in denen alle Kantenlängen nicht negativ sind. Sei (G, w) ein Netzwerk (mit G = (V, E)), in dem die Nichtnegativitätsbedingung bezüglich der Kantenlängen erfüllt ist. Ferner sei s ein Knoten in G. Die Länge einer Kante (siehe oben) zwischen zwei Knoten a und b wird als w(a, b) notiert. Die Abstände von s zu allen anderen Knoten lassen sich dann folgendermaßen berechnen [KP95, S. 147]: 1. Setze d(s) 0 und T V. 2. Für alle v V \ {s} setze d(v). 3. Solange T gilt, führe folgende Schritte aus: a) Bestimme ein f T, sodass d(f) minimal ist. b) Setze T T \ {f}. c) Für alle v T setze d(v) min{d(v), d(f) + w(v, f)}. Für jeden Knoten v V gibt d(v) den Abstand von s zu v an. Der Dijkstra-Algorithmus soll im Folgenden an einem Beispiel verdeutlich werden. Als Grundlage dient der in Abbildung 8 dargestellte Graph. Anfangs gilt T = {a, b, c, d, e, f}, d(a) = 0 sowie d(b) = d(c) = d(d) = d(e) = d(f) =. Es sollen die Abstände aller Knoten zum Knoten a bestimmt werden. Dabei werden die in Tabelle 2 notierten Schritte ausgeführt. In der letzten Zeile der Tabelle kann man die ermittelten Abstände ablesen. Der Algorithmus von Dijkstra hat eine Komplexität von O( E 2 ) [KP95, S. 148]. 22

23 Schritt Ausgewählter Knoten T d 1 a T = {b, c, d, e, f} d(a) = 0, d(b) = 3, d(c) = 8, d(d) = d(e) = d(f) = 2 b T = {c, d, e, f} d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 8, d(f) = 3 d T = {c, e, f} d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 4 e T = {c, f} d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 8 5 c T = {f} d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 8 6 f T = d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 8 Tabelle 2: Beispieldurchlauf für den Dijkstra-Algorithmus da Abbildung 8: Beispielgraph 23

24 Schritt d/d 1 d (a) = 0, d (b) = d (c) = d (d) = d (e) = d (f) = d(a) = 0, d(b) = 3, d(c) = 8, d(d) = d(e) = d(f) = 2 d (a) = 0, d (b) = 3, d (c) = 8, d (d) = d (e) = d (f) = d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 8, d(f) = 15 3 d (a) = 0, d (b) = 3, d (c) = 8, d (d) = 4, d (e) = 8, d (f) = 15 d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 11 4 d (a) = 0, d (b) = 3, d (c) = 8, d (d) = 4, d (e) = 5, d (f) = 11 d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 8 5 d (a) = 0, d (b) = 3, d (c) = 8, d (d) = 4, d (e) = 5, d (f) = 8 d(a) = 0, d(b) = 3, d(c) = 8, d(d) = 4, d(e) = 5, d(f) = 8 Tabelle 3: Beispieldurchlauf für den Bellman-Ford-Algorithmus Bellman-Ford-Algorithmus Der Algorithmus von Bellman-Ford ermöglicht es, kürzeste Wege in Graphen mit negativen Kantenlängen zu bestimmen. Jedoch dürfen auch hier keine Zyklen negativer Länge vorkommen. Sei (G, w) ein Netzwerk. Die Länge einer Kante (a, b) sei wieder mit w(a, b) bezeichnet. Für einen gegebenen Knoten s werden die Abstände zu allen anderen Knoten in G wie folgt berechnet [KP95, S. 243]: 1. Setze d(s) Für alle v V \ {s} setze d(v). 3. Wiederhole folgende Schritte a) Für alle v V setze d (v) d(v). b) Für alle v V setze d(v) min(d (v), min{d (u) + w(u, v) : (u, v) E}). bis d(v) = d (v) für alle v V. Anhand des Beispielgraphen aus Abbildung 8 soll der Bellman-Ford-Algorithmus veranschaulicht werden. Zu Beginn gilt d(a) = 0, d(b) = d(c) = d(d) = d(e) = d(f) = (Punkt 1 und 2 des Algorithmus ). Der Algorithmus durchläuft dann die in Tabelle 3 dargestellten Schritte (Punkt 3 des Algorithmus ). 24

25 2.3 Cloud Computing Prinzip Baun et al. beschreiben das mit dem Begriff Cloud Computing verbundene Konzept wie folgt [BKNT09, S. 4]: Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud Computing skalierbare, netzwerkzentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfügung. Die Abrechnung dieser Dienste erfolgt nutzungsabhängig. In dieser Definition sind die wesentlichen Merkmale, die das Cloud Computing ausmachen, enthalten. Diese sollen im Folgenden näher betrachtet werden. Dynamische Skalierbarkeit Ressourcen für Anwendungen, die in der Cloud laufen, können diesen je nach Bedarf automatisiert zugewiesen und entzogen werden. Dies geschieht ohne interaktiven Eingriff seitens des Kunden. Es kann zwischen proaktiver und reaktiver Skalierung unterschieden werden [Ree09, S. 145]. Bei proaktiver Skalierung wird ein Plan erstellt, dem die Zuteilung von Ressourcen folgt. So können einer Anwendung z.b. zu einer bestimmten Tageszeit zusätzliche Kapazitäten zugewiesen werden, um den Anforderungen von Lastspitzen gewachsen zu sein. Im Falle der reaktiven Skalierung werden Lastspitzen erkannt und zusätzliche Ressourcen bei Bedarf hinzugefügt. Des Weiteren kann man zwischen horizontaler und vertikaler Skalierung unterscheiden. Bei der horizontalen Skalierung werden neue Server hinzugefügt, während bei der vertikalen Skalierung bestehende Systeme aufgerüstet werden [Ree09, S. 176]. Virtualisierte Ressourcen Von zentraler Bedeutung für das Cloud Computing ist die Virtualisierung von Ressourcen, da sie die Grundlage für die Eigenschaften darstellt, welche das Cloud Computing interessant machen. Es gibt unterschiedliche Ausprägungen der Virtualisierung, die im Folgenden vorgestellt werden (siehe [BKNT09, S. 13 ff.]. Zum einen kann eine Virtualisierung auf Ebene des Betriebssystems erfolgen. Hierbei verwaltet das Betriebssystem mehrere voneinander getrennte Container, die dieselben physischen Ressourcen sowie denselben Betriebssystemkern verwenden. Im Gegensatz zur Betriebssystemvirtualisierung können bei der Plattformvirtualisierung für die virtuellen Umgebungen unterschiedliche Betriebssysteme und Anwendungen verwendet werden. Es wird zwischen vollständiger und Para-Virtualisierung unterschieden. 25

26 Im Falle der vollständigen Virtualisierung werden die physischen Ressourcen simuliert, wobei der Zugriff auf CPU und Hauptspeicher direkt erfolgen kann, während beispielsweise Netzwerkkarten emuliert werden. Bei der Para-Virtualisierung erfolgt der Zugriff auf die Hardware indirekt über spezielle Funktionen, die vom Gastbetriebssystem angeboten werden (Hypercalls). Beide Formen der Virtualisierung haben gemein, dass ein Hypervisor eingesetzt wird, der die Zuteilung der Ressourcen koordiniert. Eine abstrahierte Sicht auf Daten bietet die Speichervirtualisierung. Der verfügbare Speicher wird dabei in Pools gebündelt, aus denen Anwendungen je nach Bedarf Speicherplatz anfordern können. Hierbei kann beispielsweise ein Storage Area Network (SAN) eingesetzt werden. Ein anderer Aspekt der Speichervirtualisierung betrifft die Daten, mit denen der Nutzer der Anwendung Umgang hat. Diese werden als gekapseltes Objekt repräsentiert, wobei der Zugriff auf dieses über eine Web-Schnittstelle erfolgt. Die Speicherabstrahierung hat u.a. den Vorteil, dass dem Kunden verschiedene Angebote offeriert werden können, die unterschiedliche Anforderungen hinsichtlich Reservekapazität, Zuverlässigkeit und Backup-Sicherung erfüllen können. Im Bereich der Netzwerkvirtualisierung können mit Hilfe von virtuellen lokalen Netzwerken (VLANs) externe Ressourcen transparent in das Kundennetzwerk eingebunden werden. Dies erleichtert den Aufbau verteilter Anwendungen und schafft Vorteile bezüglich der Sicherheit, da kritische Komponenten in einem eigenen virtuellen Netz gekapselt werden können. Nutzung von Web-Technologien Um Anwendungen über das Internet nutzbar zu machen und das Zusammenwirken verschiedener Komponenten zu koordinieren, werden Service-orientierte Architekturen (SOA) und damit verbunden Web Services und Representational-State-Transfer-APIs (REST) eingesetzt. SOA zeichnet sich durch lose gekoppelte, modulare Dienste aus, die mittels Nachrichten miteinander kommunizieren. Die Dienste können auf der Grundlage unterschiedlicher Technologien und Programmiersprachen implementiert werden. Dienstnutzer suchen in einem Dienstverzeichnis nach einem bestimmten Dienst. Wird ein Diensteanbieter gefunden, wird der Dienst zur Laufzeit gebunden und kann anschließend genutzt werden. Web-Services stellen Anwendungen dar, die über einen Uniform Resource Identifier adressiert werden. Die Beschreibung der Schnittstelle eines Web Services sowie die zur Kommunikation verwendeten Nachrichten basieren auf XML. SOAP und die Web Services Description Language stellen Protokolle dar, die den Nachrichtenaustausch bzw. die Schnittstellenbeschreibung spezifizieren. Ebenso ist es möglich, eine REST-API für den Nachrichtenaustausch zu verwenden. Diese setzt auf HTTP auf und ist flexibler als SOAP. 26

27 Abbildung 9: Schichtenmodell (Quelle: [BKNT09, S. 30] Ausprägungen Public, Private und Hybrid Clouds Public Clouds zeichnen sich dadurch aus, dass Anbieter und die potenziellen Benutzer nicht derselben organisatorischen Einheit angehören [BKNT09, S. 57]. Das Cloud- Angebot ist öffentlich zugänglich und über eine Web-Schnittstelle hinsichtlich verschiedener Leistungsparameter konfigurierbar. Die Abrechnung der Dienste erfolgt nutzungsabhängig. Private Clouds hingegen sind im lokalen Netzwerk eines Unternehmens oder einer Organisation angesiedelt. Dies gewährleistet dem Betreiber volle Kontrolle über Sicherheitsaspekte und Leistungsmerkmale der Cloud [Fur10, S. 7]. Eine Kombination von Public und Private Clouds stellen Hybrid Clouds dar. Hierbei können bestimmte Teile der Anwendung in eine Public Cloud ausgelagert werden, wenn z.b. Lastspitzen auftreten. Daten und Funktionen, die einen hohen Sicherheitsstellenwert aufweisen, sollten dabei die private Cloud nicht verlassen [BKNT09, S. 29]. Everything as a Service Das Everything as a Service-Prinzip definiert ein Schichtenmodell aufeinander aufbauender Dienste (siehe Abbildung 9), die im Folgenden vorgestellt werden. Konkrete Angebote werden in Abschnitt betrachtet. 27

28 Infrastructur as a Service (IaaS) bietet dem Kunden eine abstrahierte Sicht auf Hardware [BKNT09, S. 31]. Der Kunde kann darüber entscheiden, welches Betriebssystem zum Einsatz kommt und wie die Ressourcen genutzt werden. IaaS bietet den größten Freiheitsgrad, erfordert jedoch auch den höchsten Konfigurationsaufwand. Wird ein Platform-as-a-Service-Dienst (PaaS) genutzt, stehen dem Kunden eine Entwicklungs- (Programming Environment, PE) und Laufzeitumgebung (Execution Environment, EE) bereit, sodass er sich nicht um das Aufsetzen und Konfiguration des Betriebssystems kümmern muss. Anwendungen können in einer vom Cloud-Anbieter unterstützten Programmiersprache entwickelt und in die Cloud ausgeliefert werden [BKNT09, S. 35ff.]. Im Fokus von Software as a Service (SaaS) stehen Anwendungen, die vom Endnutzer direkt genutzt werden. Diese können unterschiedlich komplex sein und entweder selbständig lauffähig sein oder in andere Dienste integriert werden. Der Vorteil von SaaS liegt darin begründet, dass eine Installation und das Einspielen von Updates, um die Anwendung auf dem neuesten Stand zu halten, entfallen. Im Falle von Human as a Service (HaaS) wird von Auftraggebern auf die Dienste von Menschen zurückgegriffen. Diese erledigen Aufgaben, die schlecht automatisiert werden können, wie beispielsweise Recherche- oder Übersetzungstätigkeiten. Sie erhalten dafür einen geringen Geldbetrag als Entlohnung [BKNT09, S. 39f.] Anbieter von Cloud-Diensten In diesem Abschnitt werden drei der zum Zeitpunkt dieser Arbeit bekanntesten Cloud- Anbebote vorgestellt (siehe [BKNT09, S. 44ff.]). Amazon Web Services Die Firma Amazon bietet in ihrem Cloud-Angebot namens Amazon Web Services 10 (AWS) die Nutzung von Kapazitäten an, die in Zeiten erhöhter Kaufaktivität (z.b. während des Weihnachtsgeschäfts) benötigt werden, die restliche Zeit über jedoch ungenutzt bleiben. AWS ist ein Beispiel für ein IaaS-Angebot. Amazon bietet eine Vielzahl an unterschiedlichen Diensten, die in Kategorien wie Compute, Speicherung, Datenbank u.a. eingeordnet werden. Eine Übersicht ist unter [AMA] zu finden. In der Kategorie Compute ist Amazon Elastic Compute Cloud (EC2) der zentrale Dienst. Kunden können einen virtuellen Server betreiben. Dieser basiert auf einem Amazon Machine Image (AMI). Es werden eine Reihe von vorgefertigten AMIs angeboten (sowohl von Amazon selbst als auch von Drittanbietern wie IBM oder Oracle). Des Weiteren

29 besteht die Möglichkeit, ein eigenes Image zu erstellen, das auch vermarktet werden darf. Neben der Konfiguration von Hardware-Ressourcen besteht die Auswahl zwischen verschiedenen geografischen Standorten. Diese sind wiederum in Verfügbarkeitszonen unterteilt, die unabhängig voneinander sind. Dies gewährleistet eine höhere Ausfallsicherheit [BKNT09, S. 47]. Hat der Kunde das AMI konfiguriert und eine Entscheidung über Leistungsparameter sowie Standort getroffen, kann eine Instanz des AMI gestartet werden. Diese verfügt über eine öffentliche und private IP-Adresse, jeweils für den Zugriff von außen über das Internet und innerhalb der Cloud-Infrastruktur. Es besteht die Möglichkeit, den Zustand einer Instanz dauerhaft zu speichern, auch wenn diese beendet wurde. Amazon Simple Storage Service (S3) ist ein Dienst im Bereich Speicherung. Die Daten werden in Buckets abgelegt und können über SOAP oder eine REST-API adressiert werden. Es ist nicht möglich, Buckets in andere Buckets zu schachteln - S3 ist somit kein Dateisystem im herkömmlichen Sinn [BKNT09, S. 54]. Amazon Simple DB ist ein Dienst, der die Funktionalität einer einfachen Datenbank zur Verfügung stellt. Hierbei stehen Zuverlässigkeit und ein geringer Administrationsaufwand im Vordergrund. So wird das relationale Datenbankschema verwendet, jedoch sind keine Join-Operationen über mehrere Tabellen (im Kontext von Amazon Simple DB Domänen genannt) möglich. Ebenso gibt es kein Transaktionsmanagement [BKNT09, S. 56]. Benötigt man diese Eigenschaften, muss auf den Amazon Relational Database Service (RDS) zurückgegriffen werden. Die von Amazon offerierten Dienste werden für gewöhnlich nicht getrennt genutzt, sondern miteinander kombiniert. Google App Engine Die Google App Engine 11 ist ein vom Unternehmen Google bereitgestellter PaaS-Dienst. Webbasierte Anwendungen können in den Programmiersprachen Java und Python in einer speziellen Umgebung lokal entwickelt werden und in der Cloud zur Ausführung gebracht werden. Hierbei muss kein (virtueller) Server konfiguriert werden. Die Anwendung profitiert von den Zuverlässigkeits- und Skalierungstechnologien, die Google auch für seine eigenen Endprodukte wie die bekannte Suchmaschine oder die Online Office Suite Google Docs einsetzt [BKNT09, S. 62]. Wird die Programmiersprache Java verwendet, so hat der Entwickler Zugriff auf Dienste, die die Funktionalitäten der Java-Standardbibliotheken erweitern. Hierzu gehört beispielsweise die Möglichkeit, Objekte mit Hilfe des Datastore zu persistieren. Des Weiteren existiert ein auf Google Mail aufbauender Dienst zum Empfang und Versand von s sowie Funktionalitäten zur Benutzerverwaltung (in Verbindung mit Google- Benutzerkonten). Die Verwendung proprietärer Schnittstellen und Dienste erweist sich

30 jedoch nachteilig für die Portabilität der Anwendung, da diese stark an die Technologien des Cloud-Anbieters gebunden wird. Diese Abhängigkeit kann durch quelloffene Lösungen gelöst werden. Eucalyptus 12 ist ein Projekt, das auf der Basis von Open-Source-Software den Aufbau einer privaten IaaS-Cloud ermöglicht, deren Schnittstelle kompatibel zu Amazon EC2 und Amazon S3 ist [EUC]. In Verbindung mit der Open-Source-Plattform AppScale 13 können Anwendungen, die für die Google App Engine entwickelt wurden, in einer privaten Cloud verwendet werden, ohne dass auf die Dienste eines kommerziellen Anbieters zurückgegriffen werden muss. Microsoft Windows Azure Mit Windows Azure 14 stellt Microsoft ähnlich wie bei AWS verschiedene Dienste zu Verfügung. Neben den Angeboten zur Speicherung von Daten (SQL Azure und Windows Azure Storage) und dem Streaming von multimedialen Inhalten (Windows Azure Content Delivery Network, CDN), stellt Windows Azure Compute einen der bekanntesten Dienste dar. Windows Azure Compute ist ein PaaS-Dienst. Anwendungen werden hierbei in drei Rollen unterschieden. Die Web role bezeichnet Web-Anwendungen, die unter Einsatz des Web-Servers Internet Information Services (IIS) sowie der Programmiersprache ASP.NET entwickelt werden. Die Verwendung von Java und PHP ist ebenfalls möglich [MIC]. Programme, die im Hintergrund laufen und Aufgaben von Web-role-Anwendungen delegiert bekommen, werden der Worker role zugeordnet. Der Hauptunterschied zwischen den beiden Rollen besteht darin, dass Worker-role-Anwendungen nicht innerhalb einer IIS-Instanz ausgeführt werden

31 3 Konzept 3.1 Brute-Force-Berechnungen Brute-Force-Berechnungen stellen eine einfache und vielseitig anwendbare Methode der Ergebnissuche dar, die jedoch eine hohe Komplexität aufweist. Die folgenden Ausführungen orientieren sich an [WIK]. Ein generalisierter Brute-Force-Algorithmus könnte wie folgt aussehen: candidate = generate_candidate() while candidate do if is_valid(candidate) then evaluate(candidate) end if candidate = generate_candidate() end while Die Funktion generate_candidate erzeugt auf der Basis der Eingabedaten einen Lösungskandidaten und gibt den speziellen Wert zurück, wenn keine weiteren Kandidaten mehr erzeugt werden können. Die Funktion is_valid prüft, ob ein Kandidat in Hinblick auf bestimmte Randbedingungen eine gültige Lösung darstellt, während evaluate eine gültige Lösung anhand einer Zielfunktion bewertet. Der in 3.7 vorgestellte Kontroll- und Datenfluss spiegelt die hier vorgestellten Funktionen und den Programmablauf wider. Der Brute-Force-Ansatz im Rahmen dieser Arbeit besteht darin, alle oder einen Großteil aller möglichen Zuordnungen von verfügbaren Kanälen zu Netzwerkknoten zu berechnen und betrachten. Insgesamt ergeben sich n m mögliche Zuordnungen, wobei n der Anzahl der Kanäle und m der Anzahl der Knoten entspricht. Wenn 2 Kanäle zur Auswahl stehen und insgesamt 180 Knoten vorhanden sind (entspricht ungefähr der Knotenanzahl im Opennet-Netzwerk), so ergeben sich also = 1, mögliche Zuordnungen. Unter der Annahme, eine Kombination in einer Millisekunde berechnen und beurteilen zu können, ergibt sich insgesamt eine Laufzeit von 4, Jahren. Dies ist ein Beispiel für das Phänomen der kombinatorischen Explosion, das häufig mit Brute-Force-Ansätzen einhergeht, wenn die Eingabedaten hinreichend groß sind. In bestimmten Anwendungszenarien können Heuristiken helfen, bestimmte Teile des Kandidatensuchraums auszuschließen. Diese Heuristiken stützen sich meist auf Vorwissen. Im Rahmen dieser Arbeit soll jedoch möglichst wenig Wissen verwendet oder Annahmen getroffen werden, die über die Netzwerktopologie hinausgehen. Um die kombinatorische 31

32 Explosion dennoch eindämmen zu können, sollen daher die Eingabedaten beschränkt werden. Dies wird in 3.3 für den konkreten Anwendungsfall näher ausgeführt. 3.2 Datengrundlage Die primäre Datengrundlage besteht in einer Abbildung des Netzwerkgraphen, die jedem Knoten vorliegt und die die Grundlage für das Routing mittels OLSR bildet. Die Beschreibung eines Links im Netzwerk beinhaltet Datum und Uhrzeit, Quell-IP und Ziel-IP sowie Link Quality (LQ) und Neighbor Link Quality (NLQ). Ein Link wird jeweils aus der Sicht der beiden Endknoten beschrieben, sodass er zweimal aufgeführt wird. Hierbei kann es Unterschiede in den Werten für die Link Quality und Neighbor Link Quality geben. Diese Messunterschiede lassen sich unter anderem auf unterschiedliche Hardware zurückführen. Die Topologie des Netzwerkes wird minütlich festgehalten, womit sich eine Reihe von Timestamp-Dateien ergibt. Ein beispielhafter Auszug aus einer Timestamp-Datei sieht wie folgt aus: Datum Uhrzeit Quell-IP Ziel-IP LQ NLQ :45: :45: :45: :45: :45: :45: :45: Des Weiteren liegt eine Liste aller Backbone-Knoten 15 vor. Diese Knoten verfügen über mehr als ein Netzwerkinterface und können somit mit anderen Knoten gleichzeitig auf mehr als einem Kanal kommunizieren. Diese Daten sind somit von grundlegender Bedeutung für die Ausführung der Berechnung. Ferner ist eine Liste aller kabelbasierten Verbindungen enthalten. Das Wissen, ob ein Link kabelbasiert ist oder zwischen zwei Backbone-Knoten besteht, vereinfacht die Berechnung (siehe 3.4). 15 Knoten im Netzwerk, die nicht im Ad-hoc-Modus operieren und nicht für Endnutzer zur Verfügung stehen. Im Opennet-Netzwerk werden diese Knoten durch leistungsfähige Router realisiert, die den IEEE-Standard a unterstützen. 32

33 3.3 Beschränkung der zu betrachtenden Knoten Interferenzen treten verstärkt in Gebieten mit einer hohen Knotendichte auf. Aus diesem Grund ist es sinnvoll, den Fokus auf diese Gebiete zu legen. Die Knotendichte kann anhand realer geografischer Informationen bestimmt oder approximiert werden. Hierbei können verschiedene Kriterien zu Rate gezogen werden: Eine hohe Anzahl von (ein- oder ausgehenden) Links für einen Knoten. Je höher der Schwellenwert (minimale Anzahl an Links) angesetzt wird, desto stärker wird die zu betrachtende Knotenmenge eingeschränkt. Es ist von Interesse, eine größtmögliche Anzahl von Knoten zu betrachten, wobei die Komplexität und Laufzeit der Berechnung im Auge behalten werden muss. Die Anzahl der 2-Hop-Nachbarn für einen Knoten erlaubt einen Rückschluss auf die Knotendichte. Es ist sinnvoll, nicht nur die direkten Nachbarn (im Abstand von einem Hop) zu betrachten, da auch weiter entfernte Knoten zur Entstehung von Interferenzen beitragen können. In Abbildung 10 und 11 sind diejenigen Knoten grün markiert, die jeweils über eine Mindestanzahl von 3 ausgehenden Links bzw. 6 2-Hop-Nachbarn verfügen. Diese würden für die Berechnung der Kanalzuordnungen in Betracht gezogen. Geografische Daten über das Netzwerk liegen in Form von Koordinaten für alle Knoten vor. Um aus diesen Daten Gebiete mit hoher Knotendichte zu ermitteln, wäre es beispielsweise denkbar, den Bereich des gesamten Netzwerks in Sektoren zu unterteilen und die Anzahl der Knoten in jedem Sektor zu bestimmen. Selektiert werden dann die Knoten aus Gebieten, deren Knotenanzahl einen bestimmten Minimalwert überschreitet. Dieser Ansatz wäre aufwendiger als die Schätzung mittels Hop-Count und Linkanzahl. Im Folgenden wird angenommen, dass die Approximation anhand der Topografie des Netzes den realen geografischen Begebenheiten gerecht wird. Aus diesem Grund soll die einfacher zu bestimmende Näherung als Grundlage für die Anwendung dienen. Die Koordinaten der Knoten können für die Darstellung des Netzwerkes (mit der dazugehörigen Kanalzuordnung) auf einer Karte verwendet werden. Der Durchschnitt der Link-Quality-Werte für jeden ausgehenden Link eines Knotens kann ebenfalls als Indikator für Interferenz dienen: Je schlechter die Link Quality, umso wahrscheinlicher der störende Einfluss von Interferenzen. Dies ist jedoch nur ein schwaches Kriterium, da die Link Quality auch von vielen anderen Faktoren beeinflusst wird, z.b. von Interferenzstörungen durch fremde Funksysteme oder den Wetterbedingungen. Aus diesem Grund wird dieses Kriterium nicht berücksichtigt. Wahl der Parameter für die Knotenauswahl Wie bereits erwähnt, hängt es von der Parameterwahl ab, wie viele Knoten für die Kanalzuordnung in Betracht gezogen werden. Im Folgenden soll daher für einige Parame- 33

34 Abbildung 10: Selektion anhand minimaler Anzahl von 2-Hop-Nachbarn Abbildung 11: Selektion anhand minimaler Anzahl an Links 34

35 Minimale Linkanzahl Minimale Anzahl an 2-Hop-Nachbarn Tabelle 4: Parameterkombinationen, für die die Anzahl selektierter Knoten zwischen 10 und 20 liegt terkombinationen die Anzahl ausgewählter Knoten bestimmt werden. Um die Anzahl aller möglichen Parameterkombinationen zu begrenzen, sollen im Rahmen der in dieser Arbeit durchgeführten Berechnungen minimal 10 und maximal 20 Knoten ausgewählt werden. Die Entscheidung, wie viele Knoten ausgewählt werden, ist ein Kompromiss zwischen Aussagekraft und Rechenzeit. In Tabelle 4 wird dargestellt, für welche Kombination von Werten der beiden Parameter die resultierende Knotenanzahl zwischen 10 und 20 liegt. 3.4 Vereinfachungen Um die Knotenmenge weiter einzuschränken, können Vereinfachungen des Graphen vorgenommen werden. Es ist möglich Knoten zusammenzufassen, deren Links als einzige zu einem bestimmten Gateway hinführen. Dies wird in Abbildung 12 veranschaulicht. Die zusammengefassten Knoten müssen einen Kanal verwenden, da ansonsten das Gateway unerreichbar wird (vorausgesetzt, das Gateway ist nur über diese Knotenmenge erreichbar). Eine weitere Vereinfachung der Berechung ergibt sich daraus, dass Links zwischen Backbone-Knoten sowie kabelbasierte Links bei der Betrachtung einer Kanalzuordnung außer Acht gelassen werden können. Konkret bedeutet dies, dass bei der Überprüfung des Zusammenhangs diese Kanten nicht berücksichtigt werden müssen. Ebenso können Backbone-Knoten bei der Kanalzuordnung unberücksichtigt bleiben, da sie mehrere Kanäle unterstützen. 35

36 Abbildung 12: Zusammenfassen von Knoten 3.5 Überprüfung der Gültigkeit einer Kanalzuordnung Eine wichtige Bedingung, die eine gültige Kanalzuordnung erfüllen musst, besteht bezüglich der Konnektivität des Netzwerkgraphen. Der Graph muss weiterhin stark zusammenhängend bleiben, d.h. es muss einen gerichteten Weg von jedem Knoten zu jedem anderen Knoten existieren (siehe [Jun07, S. 26]. Kanalzuweisungen, die eine Partitionierung des Graphen bewirken, werden daher verworfen. Dies soll an einem Beispielgraphen veranschaulicht werden (siehe Abbildung 13). Der Knoten b verfügt hierbei über zwei Netzwerkinterfaces, alle anderen Knoten über ein Netzwerkinterface (gekennzeichnet durch Kreise an den Knoten). In Abbildung 14 wird eine Kanalzuordnung abgebildet, die den Zusammenhang im Graphen zerstört, während dieser im Falle der Kanalzuweisung aus Abbildung 15 bewahrt wird. In beiden Zuordnungen fällt die Verbindung zwischen den Knoten a und c weg. Um die Gültigkeit einer erzeugten Kanalzuordnung zu überprüfen, werden folgende Schritte ausgeführt: 1. Für alle Kanten e im Graphen: Wenn die Endknoten von e Backbone-Knoten darstellen oder e einen kabelbasierten Link repräsentiert, so wird e nicht weiter berücksichtigt. Falls den Endknoten von e nicht der gleiche Kanal zugewiesen wurde, so wird e aus dem Graphen entfernt. 2. Prüfe, ob der Zusammenhang des Graphen zerstört wurde. Die Überprüfung wird durch eine einfache Tiefensuche realisiert: Lassen sich ausgehend von einem beliebigen Startknoten alle anderen Knoten erreichen, so ist der Graph zusammenhängend. 36

37 a b a b f f c d e c d e Abbildung 13: Ausgangsgraph Abbildung 14: kein Zusammenhang a b f c d e Abbildung 15: Zusammenhang bewahrt 37

38 3.6 Zielfunktion Der Entwurf einer geeigneten Zielfunktion steht nicht im Vordergrund dieser Arbeit. Vielmehr soll die Anwendung so entworfen werden, dass die Zielfunktion austauschbar ist. Im Folgenden sollen Gütekriterien vorgestellt werden, die für die Bewertung einer Kanalzuweisung herangezogen werden können: Arithmetischer Mittelwert oder Median der ETX-Pfadwerte: In diesem Fall wird die Güte einer Kanalzuordnung durch einen einzelnen skalaren Wert beschrieben. Sei k i eine Kanalzuordnung und bezeichne d(k i ) den arithmetischen Mittelwert bzw. Median der ETX-Werte. Im Sinne der ETX-Metrik (siehe die Ausführungen zum Thema Metriken in 2.1.5) sei festgelegt, dass eine Kanalzuordnung k 1 genau dann eine höhere Güte gegenüber eine Kanalzuordnung k 2 aufweist, wenn d(k 1 ) < d(k 2 ) gilt. Der Median ist zu bevorzugen, da er im Gegensatz zum Mittelwert verzerrungsfrei gegenüber Extremwerten ist. Güteklassen für Knoten: Anstatt den Mittelwert/Median über alle Kanten zu berechnen, kann dieser für jeden Knoten für dessen ein- und ausgehenden Kanten berechnet werden. Anschließend wird der Knoten einer Klasse zugeordnet. Jede Klasse hat jeweils einen ETX-Wert als Ober- und Untergrenze, wobei die Obergrenze einer Klasse die Untergrenze der nächsten Klasse bildet, sodass sich eine Klassenrangfolge ergibt. Seien k 1, k 2 zwei Kanalzuordnungen und u(k i ) sowie v(k i ) die Anzahl derjenigen Knoten, die einer besseren bzw. schlechteren Klasse zugeordnet wurden als im Ursprungsgraphen. Dann sei k 1 von höherer Güte als k 2 genau dann, wenn gilt, dass u(k 1 ) v(k 1 ) > u(k 2 ) v(k 2 ). Eine Zielfunktion kann auch aus einer Kombination dieser Gütekriterien bestehen, die gegebenenfalls gewichtet werden können. 3.7 Kontroll- und Datenfluss Im Folgenden soll der Kontroll- und Datenfluss der Anwendung schematisch skizziert werden. Das Flussdiagramm in Abbildung 16 fasst das hier Beschriebene zusammen. Die Aktionen, die sich innerhalb des gestrichelten Bereichs befinden, werden parallel für jede Kanalzuordnung ausgeführt. 1. Erzeugen einer internen Repräsentation des Graphen: Aus einer Timestamp-Datei (siehe 3.2) wird ein gewichteter Graph in einer geeigneten Datenstruktur erzeugt. Netzwerkknoten und die Links zwischen ihnen werden direkt auf Knoten und Kanten des Graphen abgebildet. Die Kanten werden mit dem ETX-Wert des Links gewichtet, der aus den Link-Quality- und Neighbor-Link-Quality-Werten berechnet wird (siehe Metriken in 2.1.5). Die so erzeugte interne Repräsentation des Graphen wird in einem Datenspeicher abgelegt. 2. Bestimmung einer Knotenteilmenge: Wie in 3.3 ausgeführt, muss eine geeig- 38

39 nete Auswahl an Knoten vorgenommen werden, um die Komplexität der Brute- Force-Berechnungen zu begrenzen. Die Anzahl der ausgewählten Knoten soll anhand von zwei Parametern variiert werden: Minimale Anzahl an ein- und ausgehenden Links Minimale Anzahl an 2-Hop-Nachbarn 3. Vereinfachung und Bereinigung des Graphen: In 3.4 wurden die Vereinfachungen erläutert, die an der internen Repräsentation des Graphen vorgenommen werden können. Hierzu werden die Liste von Backbone-Knoten sowie die Liste kabelbasierter Links als Eingabe benötigt. 4. Berechnen aller möglichen Kanalzuordnungen: Allen Knoten (mit Ausnahme der Backbone-Knoten) wird ein Kanal aus der Menge aller verfügbaren Kanäle zugeordnet. Es werden alle möglichen Kombinationen für eine gegebene Menge an ausgewählten Knoten und Kanälen berechnet. 5. Überprüfung der Gültigkeit und Bewertung der Kanalzuordnungen: Die folgenden Schritte werden für alle im Schritt 4 erzeugten Kanalzuordnungen ausgeführt. a) Überprüfung der Gültigkeit der Kanalzuordnung: Anhand verschiedener Kriterien (die als Randbedingungen zusammengefasst werden) wird überprüft, ob die berechnete Kanalzuweisung gültig ist. Eine grundlegende Bedingung ist, dass der Zusammenhang des Graphen bewahrt werden muss (siehe 3.5). Ist die Zuordnung ungültig, wird sie verworfen. b) Bewertung der Kanalzuordnung: Wurde in Schritt 5a eine gültige Zuweisung erzeugt, so erfolgt in diesem Schritt eine Bewertung dieser. Eine Zielfunktion dient als Bewertungsgrundlage (siehe 3.6). Die bewertete Kanalzuordnung wird in einem Datenspeicher abgelegt. 3.8 Annahmen Anzahl der verfügbaren Kanäle Die Anwendung soll so gestaltet werden, dass die Anzahl der verfügbaren Kanäle parametrisierbar ist. Für die im Rahmen dieser Arbeit ausgeführten Berechnungen soll diese Zahl auf 2 begrenzt werden, um die Laufzeit zu beschränken. Verbesserung der Link-Quality-Werte Da nicht auf empirische Daten über die im Netzwerk auftretenden Interferenzen zurückgegriffen wird, kann keine realitätsnahe Aussage darüber getroffen, inwiefern sich der Link-Quality-Wert durch den Wegfall von Interferenzen verändert. 39

40 Abbild des Netzwerkgraphen Erzeugen einer internen Repräsentation des Graphen Timestamp Bestimmung einer Knotenteilmenge Parameter Liste von Backbone-Knoten Abbild des Netzwerkgraphen Vereinfachung und Bereinigung des Graphen Liste von kabelbasierten Links Berechnen aller Kanalzuordnungen Nein Randbedingungen Kanalzuordnung gültig? Ja Bewertete Kanalzuordnung Bewertung der Kanalzuordnung Zielfunktion Abbildung 16: Flussdiagramm 40

41 Aus diesem Grund muss die Verbesserung geschätzt werden. Für die in dieser Arbeit durchgeführten Berechnungen wird angenommen, dass sich der Link-Quality-Wert einer Verbindung zwischen zwei Knoten um 0% 20% verbessert. Die Anwendung erlaubt es, diese Grenzen frei festzulegen (siehe 4.2). 4 Implementierung 4.1 Auswahl eines Cloud-Anbieters Für die vorliegende Aufgabenstellung kann entweder ein Infrastructur-as-a-Service- (IaaS) oder Platform-as-a-Service-Dienst (PaaS) (siehe 2.3.2) gewählt werden. Bei der Benutzung eines IaaS-Angebots muss die Umgebung, in der die Anwendung läuft, konfiguriert werden. Der dadurch bedingte Mehraufwand bringt im vorliegenden Fall jedoch keinen direkten Nutzen, sodass die Entscheidung zugunsten eines PaaS-Dienstes ausfällt. Als Cloud-Angebot wird die von Google betriebene App Engine (siehe 2.3.3) ausgewählt, da es sich um ein etabliertes Angebot handelt. Des Weiteren profitieren Anwendungen, die im Kontext der App Engine laufen, von derselben Infrastruktur, die auch den Google-Anwendungen zur Verfügung steht. Ein weiterer Vorteil besteht darin, dass die Nutzung von Kapazitäten wie CPU-Zeit oder Speicherzugriff innerhalb festgelegter Quoten kostenfrei ist. Werden diese Quoten überschritten, fallen Kosten für die darüber hinaus in Anspruch genommenen Ressourcen an. [GOOf] bietet eine Übersicht über das Preismodell. Anwendungen für die App Engine können in den Programmiersprachen Python und Java implementiert werden. Python wurde von Anfang an unterstützt, während Java erst zu einem späteren Zeitpunkt hinzugekommen ist. Da es sich bei Python um eine dynamisch typisierte Sprache handelt, die eine große Anzahl von Standardbibliotheken mitbringt, zeichnen sich in Python entwickelte Anwendungen im Vergleich zu statisch typisierten Sprachen wie Java durch eine kürzere Entwicklungszeit aus. Aus diesen beiden Gründen soll Python als Entwicklungssprache Verwendung finden. 4.2 Parallelisierung mittels Mapreduce Mapreduce ist ein von Google entwickeltes Framework für verteilte Berechnungen auf Grundlage einer großen Datenbasis. Das Prinzip ist der funktionalen Programmierung entlehnt. Die Daten liegen als eine Menge von Schlüssel-Wert-Paaren (k, v) vor. Der Vorgang teilt sich in den Map- und den Reduce-Schritt auf [DG08, S. 2]: 1. Map: Für jedes Paar (k, v) wird die Map-Funktion m auf v angewendet. Als Ergebnis erhält man einen Wert v = m(v). Dieser Wert wird mit einem Zwischenschlüssel k versehen. 41

42 Abbildung 17: Mapreduce (Quelle: [DG08, S. 3]) 2. Reduce: Alle Paare (k, v 1 ),..., (k, v n), die denselben Schlüssel k aufweisen, werden durch die Reduce-Operation r zusammengefasst. Abbildung 17 fasst das hier Beschriebene grafisch zusammen. Der Benutzer braucht lediglich die Map- und Reduce-Operationen zu spezifizieren. Die Partitionierung der Eingabedaten und die Verteilung der Berechnung auf mehrere Maschinen werden von der Laufzeitumgebung übernommen [DG08, S. 1]. Im Kontext der App Engine wurde die Open-Source-Bibliothek AppEngine-MapReduce entwickelt, um Map-Reduce-Berechnungen auf der App Engine durchführen zu können (siehe [GOOd]). Die Bibliothek weist u.a. folgende Eigenschaften auf: Vordefinierte Eingabeschnittstellen, um über Datastore 16 - oder Blobstore 17 -Objekte zu iterieren Die Anzahl der Worker und die Ausführungsrate (Anzahl bearbeiter Entities pro Worker und Sekunde) sind anpassbar. Somit kann man die Berechnung über mehrere Tage strecken, um die Quotengrenzen nicht zu überschreiten. Ein Webinterface, um die Ausführung der Berechnung verfolgen zu können 16 Nicht-relationale, objektorientierte Datenbank der App Engine (siehe [GOOc]) 17 Datenspeicher für (große) Objekte, die vom Nutzer hochgeladen werden können (siehe google.com/intl/de-de/appengine/docs/python/blobstore/) 42

43 Abbildung 18: Webinterface der Mapreduce-Bibliothek Abbildung 18 zeigt das Webinterface der Mapreduce-Bibliothek. Zum Zeitpunkt des Verfassens dieser Arbeit unterstützt die Bibliothek die Ausführung von Map-Operationen, jedoch fehlt die Unterstützung von Reduce-Operationen. Für die zu entwickelnde Anwendung ist dies jedoch unerheblich, da nur der Map-Schritt benötigt wird. Dieser soll im Folgenden näher dargestellt werden. Die Datengrundlage stellen Kanalzuordnungen dar, die im Voraus in einem Schritt berechnet und als Entities im Datastore abgelegt werden. Eine Kanalzuordnung ist ein Tupel der Form (k 1,..., k n ), wobei n der Anzahl der ausgewählten Knoten (siehe 3.3) entspricht und k i den Kanal bezeichnet, der dem ausgewählten Knoten u i zugewiesen wird. Im Datastore angelegte Entities sind Instanzen einer Model-Klasse, welche die Attribute der Entity spezifiziert. Die vom Entwickler geschriebene Model-Klasse muss dabei die von Google im Software Development Kit (SDK) für die App Engine bereitgestellte Klasse Model erweitern. Für Details zur Nutzung des Datastores sei auf [GOOc] verwiesen. Die folgende Model-Klasse beschreibt die Struktur der Entities, die eine Kanalzuordnung repräsentieren: class ChannelAssignmentModel(db.Model): channel_assignment = db.textproperty(required=true) 43

44 Die Entities verfügen über ein einziges Attribut, dessen Wert der String-Repräsentation eines Tupels der oben beschriebenen Form entspricht. Python erlaubt es, aus der String- Repräsentation durch Aufruf nur einer Funktion das entsprechende Tupelobjekt zu rekonstruieren. Nachdem für eine Menge an ausgewählten Knoten und eine gegebene Anzahl von Kanälen alle möglichen Kombinationen berechnet wurden, werden diese im Datastore gespeichert. Anschließend wird mit Unterstützung der Mapreduce-Bibliothek ein Map-Job gestartet. Die auszuführenden Aktionen werden durch eine Handler-Funktion festgelegt. Sie entsprechen den Aktionen, die in Schritt 5 der Beschreibung des Kontroll- und Datenflusses aufgeführt wurden. Für diejenigen Kanalzuordnungen, die sich als gültig erwiesen haben, wird eine Entity in den Datastore hinzugefügt. Die entsprechende Model-Klasse sieht wie folgt aus: class EvaluationModel(db.Expando): network_graph = db.referenceproperty(networkgraphmodel, required=true) channel_assignment = db.referenceproperty(channelassignmentmodel, required=true) Anstelle der Klasse Model wird die Klasse Expando erweitert. Diese erlaubt es, einer bereits erzeugten Instanz zusätzliche Attribute mit entsprechenden Attributwerten hinzuzufügen. Wird die Klasse Model abgeleitet, müssen alle Attribute bei der Deklaration der Unterklasse angegeben werden und die Werte als Konstrukturparameter bei der Instanziierung übergeben werden. Der Vorteil der Nutzung der Expando-Klasse im konkreten Fall liegt darin, dass man die für jede Evaluator-Klasse spezifischen Attribute nach Erzeugung der Instanz hinzufügen kann. Die Evaluator-Klassen implementieren die in 3.6 aufgeführten Strategien zur Bewertung von Kanalzuordnungen. Für die Klasse channel_assignment.averagevaluesevaluator 18, welche die Kanalzuordnungen nach ETX-Durchschnittswerten bewertet, sind dies beispielsweise die Attribute etx_median und etx_arithmetic_mean, die sich jeweils auf den Median bzw. das arithmetische Mittel aller ETX-Pfadwerte beziehen. Zur Laufzeit kann somit entschieden werden, welche Evaluator-Klasse genutzt werden soll und die entsprechenden Eigenschaften dynamisch hinzugefügt werden. Im Rahmen dieser Arbeit wurden drei Mapreduce-Jobs definiert, die im Folgenden beschrieben werden. Die Nutzung der Anwendung wird in A.1 vorgestellt. Anlegen aller Kanalzuordnungen Dieser Job bestimmt für eine gegebene minimale Anzahl von Links und 2-Hop-Nachbarn die Menge der ausgewählten Knoten. Anschließend generiert er alle möglichen Kanalzuwei- 18 Im Folgenden wird auf Klassennamen in der Form modulname.klassenname Bezug genommen. 44

45 sungen für die ausgewählten Knoten und die zur Verfügung stehende Anzahl an Kanälen, und legt diese als Entities des Models channel_assignment.channelassignmentmodel (siehe oben) im Datastore an. Da über nur eine Entity als Eingabe iteriert wird, wird dieser Job nicht parallel ausgeführt. Dies hat den Hintergrund, dass sich die Berechnung aller möglichen Kombinationen in der derzeitigen Implementierung nicht parallelisieren lässt, was in A.2 näher erläutert wird. Jobname: CreateChannelAssignments Parameter: entity_kind: Legt den Typ der Entities fest, über die iteriert wird. Im vorliegenden Fall ist dies eine Entity der Model-Klasse network_graph.networkgraphmodel, die den Netzwerkgraphen repräsentiert. min_links: minimale Anzahl an Links min_neighbors: minimale Anzahl an 2-Hop-Nachbarn num_channels: Anzahl verfügbarer Kanäle Ergebnis: Alle möglichen Kanalzuordnungen (in Form von Entities des Typs channel_assignment.channelassignmentmodel) für die berechnete Menge an selektierten Knoten und gegebene Anzahl an Kanälen Validieren und Bewerten der Kanalzuordnungen Dieser Job dient dazu, die erzeugten Kanalzuordnungen auf ihre Gültigkeit zu überprüfen (siehe 3.5) und anschließend zu bewerten (siehe 3.6), falls sie sich als gültig erwiesen haben. 45

46 Jobname: ValidateAndEvaluate Parameter: entity_kind: Legt den Typ der Entities fest, über die iteriert wird. Im vorliegenden Fall sind dies Entities der Model-Klasse channel_assignment.channelassignmentmodel. evaluator: Der Name einer Klasse, die eine Funktionalität zur Bewertung der Kanalzuordnungen (siehe 3.6) implementiert. Die Klasse channel_assignment.averagevaluesevaluator Durchschnittswerte als Bewertungsgrundlage. verwendet die ETX- Die Klasse channel_assignment.etxclassesevaluator setzt das in 3.6 beschriebene Konzept der Einordnung von Knoten in ETX-Klassen um. improvement_rate_lower: Legt die prozentuale Untergrenze fest, ab der die Link- Quality-Werte des modifizierten Netzwergraphen verbessert werden. improvement_rate_upper: Legt die prozentuale Obergrenze fest, bis zu der die Link- Quality-Werte des modifizierten Netzwergraphen verbessert werden. num_classes: Anzahl der ETX-Klassen (für die Evaluator-Klasse channel_- assignment.etxclassesevaluator). Die Klassen ergeben sich aus dem Wert dieses Parameters und der Obergrenze, die durch den Parameter upper_bound festgelegt wird. Die Klassenbreite entspricht dabei der Obergrenze geteilt durch die Klassenanzahl. Die Untergrenze der ersten Klasse ist 1.0. upper_bound: Obergrenze für die ETX-Klassen (für die Evaluator-Klasse channel_- assignment.etxclassesevaluator). Die letzte Klasse hat diesen Wert als Untergrenze und beinhaltet alle Knoten, deren ETX-Durchschnittswert größer oder gleich diesem Wert ist. Ergebnis: Die Bewertungen der Kanalzuweisungen in Form von Entities der Model-Klasse channel_assignment.evaluationmodel. Diese enthalten einen Verweis auf den modifizierten Netzwergraphen und die entsprechende Kanalzuordnung. Darüber hinaus besitzen sie Attribute, die für die jeweilige Evaluator-Klasse spezifisch sind. Löschen von Datastore-Entities Um alle Entities eines bestimmten Typs aus dem Datastore zu löschen, wurde der folgende Job spezifiziert. Jobname: ClearDatastore Parameter: entity_kind: Legt den Typ der Entities fest, die gelöscht werden sollen. Ergebnis: Alle Entities des angegebenen Typs werden aus dem Datastore gelöscht. 46

47 Zeitliche Verteilung der Berechnung Wie bei der Aufzählung der Eigenschaften der Mapreduce-Bibliothek bereits erwähnt, kann man Einfluss auf die Berechnungsdauer des Mapreduce-Jobs nehmen. Dies geschieht über den Parameter processing_rate, dessen Wert festlegt, wie viele Entities pro Sekunde von allen Mapper-Instanzen bearbeitet werden (100 per Default). Der Parameter kann in der Datei /Quellcode/mapreduce.yaml für jeden Mapper angegeben werden. Ist dies nicht der Fall, wird der Default-Wert von 100 angenommen. 4.3 Model-View-Controller-Architektur Model-View-Controller stellt ein Entwurfsmuster dar, das ursprünglich für die Entwicklung von User-Interfaces in der Programmiersprache Smalltalk-80 verwendet wurde (siehe [GHJV02, S. 4]) und bei Webframeworks wie Django 19 oder Ruby on Rails 20 eingesetzt wird. Das MVC-Muster beschreibt, wie die Darstellung der Daten vom Datenmodell getrennt wird. Es kommt eine nur lose Kopplung zum Einsatz, was den Vorteil hat, dass die Erstellung und Aktualisierung mehrerer Ansichten für ein Datenmodell mit geringem Aufwand möglich ist. Eine MVC-Architektur setzt sich aus drei Komponenten zusammen [GHJV02, S. 4]: Model: Das Model enthält die Daten der Anwendung. Wenn sich diese ändern, werden alle registrierten Observer gemäß des Observer-Patterns (siehe [GHJV02, S. 293ff.]) benachrichtigt. View: Die View beschreibt die Darstellung der Daten auf dem Bildschirm. Eine View hat dabei die Rolle eines Observers in Bezug auf ein Model. Bei Datenänderungen wird sie somit benachrichtigt und kann sich aktualisieren. Controller: Der Controller definiert, welche Änderungen der im Model enthaltenen Daten vorgenommen werden, wenn eine bestimmte Benutzeraktion auf der View erfolgt. Die Google App Engine verfügt über ein eigenes Webframework namens webapp (siehe [GOOg]). Darüber hinaus ist es möglich, andere Frameworks wie Django in Kombination mit der App Engine zu benutzen. Für die zu entwickelnde Anwendung wurde das webapp- Framework verwendet, da es sich für die Anforderungen der Anwendung als ausreichend erwies. Im Folgenden soll das Zusammenwirken der Komponenten durch einen Ausschnitt aus der Anwendung verdeutlicht werden. Als Beispiel dient die Darstellung der Bewertungen nach Ausführung des Mapreduce-Jobs ValidateAndEvaluate (siehe 4.2)

48 Der Controller gestaltet sich folgendermaßen: class EvaluationOverview(webapp.RequestHandler): def get(self): self.response.headers[ Content-Type ] = text/html inputreader = InputReader() evaluation_entities = inputreader.read_all_entities( EvaluationModel, order= etx_median ) template_values = { evaluations : evaluation_entities} path = os.path.join(os.path.dirname( file ), html, evaluation_overview.html ) self.response.out.write(template.render(path, template_values)) Die Klasse main.evaluationoverview erweitet die im webapp-framework vordefinierte Klasse webapp.requesthandler. Eine Instanz der Klasse webapp.wsgiapplication wird benötigt, um eine Abbildung von URLs auf RequestHandler-Klassen vorzunehmen. In diesem Beispiel sähe das wie folgt aus: application = webapp.wsgiapplication([( /evaluation, EvaluationOverview)]) Dem Konstruktor wird eine Liste von Tupeln der Form (URL, Name der RequestHandler- Klasse) übergeben. Der Aufruf der Methode webapp.util.run_wsgi_app führt dazu, dass die die Anwendung gestartet wird. Wenn ein Request für eine URL empfangen wird, wird eine Instanz der mit dieser URL assoziierten RequestHandler-Klasse erzeugt. Anschließend wird die Methode aufgerufen, die der HTTP-Methode des Requests entspricht (sofern diese in der RequestHandler- Klasse definiert wurde). Im obigen Beispiel würde bei einem GET-Request die Methode get aufgerufen. Innerhalb dieser Methode wird die HTTP-Response vorbereit und durch den Aufruf von self.response.out.write übermittelt. Beim Erzeugen der Response wird ein HTML-Template 21 verwendet, das der View im Sinne der MVC-Architektur entspricht. Hierbei handelt es sich um ein HTML-Dokument, in dem Attributwerte vorkommen können, deren Werte beim Rendern des HTML-Dokuments durch das webapp-framework eingefügt werden. Ein Ausschnitt aus dem Template für die Klasse main.evaluationoverview soll dies verdeutlichen: 21 Das webapp-framework verwendet die Template-Engine von Django (siehe com/intl/de-de/appengine/docs/python/gettingstarted/templates.html). 48

49 <tbody> {% for evaluation in evaluations %} <tr> <td><a href="./evaluation_details?key={{ evaluation.key }}"> {{ forloop.counter }} </a> </td> <td>{{ evaluation.etx_median }}</td> <td>{{ evaluation.etx_arithmetic_mean }}</td> <td>{{ evaluation.num_removed_edges }}</td> </tr> {% endfor %} </tbody> In der Methode get der Klasse main.evaluationoverview werden zunächst alle Entities aus dem Datastore geholt, die dem Typ EvaluationModel entsprechen. Diese werden zusammen mit dem Pfad des Template-Dokuments der Methode webapp.template_- render übergeben. Auf die Objekte und ihre Attribute und Methoden kann in der HTML-Datei in der Form objekt_name.attribut bzw. objekt_name.methode zugegriffen werden. Dabei wird im gerenderten Dokument der entsprechende Attributwert bzw. Rückgabewert eingefügt. Darüber hinaus können Kontrollanweisungen verwendet werden, wie beispielsweise die for-schleife im obigen Beispiel ({% for evaluation in evaluations %}). Die Methode webapp.template_render rendert das HTML-Template und gibt die HTML-Seite in Textform zurück. Diese Ausgabe wird wiederum der Methode self.response.out.write übergeben, welche die HTML-Seite in der Response ausliefert. Die Anwendung des MVC-Musters im konkreten Beispiel lässt sich wie folgt zusammenfassen: Die Rolle des Controllers übernimmt eine RequestHandler-Klasse, die der View das HTML-Template. Die Klasse channel_assignment.evaluationmodel, die bereits weiter oben vorgestellt wurde (siehe 4.2), repräsentiert das Model. 5 Zusammenfassung 5.1 Auswertung In Tabelle 5 sind die Ergebnisse dargestellt, die sich für eine unterschiedliche Anzahl von ausgewählten Knoten und eine Timestamp-Datei 22 ergeben. Angegeben ist die durchschnittliche Dauer (über fünf Durchläufe) der Berechnung aller Zuordnungen von Knoten zu Kanälen sowie der Auswertung der erzeugten Kanalzuweisungen - jeweils unter Verwendung der Klassen channel_assignment.averagevaluesevaluator und channel_- assignment.etxclassesevaluator (siehe 4.2). Die angegebenen Werte ergeben sich aus der Ausführungsdauer des jeweiligen Mapreduce-Jobs. Diese Werte unterliegen Schwan- 22 Die verwendete Timestamp-Datei entspricht der Datei /Quellcode/data/timestamp.txt. Des Weiteren werden alle Dateien verwendet, die sich im Ordner /Quellcode/data/ befinden. In A.1.4 wird erläutert, welche Dateien benötigt werden und wie sie hochgeladen werden können. 49

50 Knotenanzahl Zeit für Berechnung (hh:mm:ss) alle Kombinationen Durchschnittswerte ETX-Klassen 5 00:00:03 00:00:03 00:00: :00:05 00:00:06 00:00: :00:07 00:00:09 00:00: :00:24 00:00:55 00:01: :01:39 00:02:50 00:02: :04:57 00:04:30 00:04: :05:09 00:05:49 00:06:45 Tabelle 5: Zeitmessungen kungen, je nachdem wie die Berechnung im Hintergrund durch die Mapreduce-Bibliothek und die App Engine ausgeführt wird. Abhängig von der Knotenanzahl und davon, wie viele Berechnungen bereits durchgeführt wurden, kommt es dazu, dass die Quote an freier CPU-Zeit überschritten wird und die Berechnung durch einen DeadlineExceededError unterbrochen wird (siehe dazu 5.2). Wird beispielsweise ein Mapreduce-Job zum Erzeugen aller Kanalzuordnungen (siehe 4.2) angestoßen, bei dem 15 Knoten ausgewählt werden und 100 Entities pro Mapper und Sekunde bearbeitet werden, so kann dieser Job nicht innerhalb der freien Quotengrenze ausgeführt werden. Es gibt zwei Möglichkeiten, diese Problem zu umgehen. Zum einen können zusätzliche CPU-Stunden gekauft werden. Diese Option wird näher in 5.2 betrachtet. Zum anderen kann über den Parameter processing_rate Einfluss auf die Anzahl der Entities genommen werden, die pro Sekunde und Mapper bearbeitet werden (siehe dazu 4.2). Hierdurch wird die Berechnung des Mapreduce-Jobs über mehr als einen Tag verteilt. Der Versuch, einen Job über mehrere Tage auszuführen, scheitert jedoch an einem MemoryError. Dieser betrifft eine Datenstruktur, die bei der Berechnung aller möglichen Kanalzuordnungen erzeugt wird (siehe A.2). Der Fehler ist jedoch nicht dokumentiert (siehe [GOOe]), sodass unklar bleibt, unter welchen Bedingungen er auftritt. Auf eine weitere Auswertung soll nicht näher eingegangen werden. Die durchgeführten Berechnungen zeigen, dass die Anwendung die Zielstellung erfüllt. Stattdessen sollen im Folgenden die gesammelten Erfahrungen mit der Google App Engine dargestellt und Verbesserungsmöglichkeiten aufgezeigt werden. 5.2 Erfahrungen mit der Cloud Die Google App Engine stellt verschiedene Restriktionen an die Anwendungen. Eine HTTP-Response muss innerhalb von 30 Sekunden erfolgen, nachdem der entsprechende Request empfangen wurde. Dies bedeutet, dass es nicht möglich ist, einen rechenintensiven 50

51 Prozess durch einen Request anzustoßen. Hierfür hat Google die Task Queue API entwickelt, mit der sich Hintergrundprozesse (Tasks) starten lassen. Auch ein Task muss innerhalb von 10 Minuten nach Eingang des Requests einen Response-Statuswert zwischen 200 und 299 zurückgeben. Dieses Zeitlimit lässt sich jedoch umgehen, indem Tasks derart miteinander verzahnt werden, dass ein Task bei seiner Beendigung den nächsten anlegt. Die im Rahmen dieser Arbeit verwendete Mapreduce-Bibliothek macht Gebrauch von der Task Queue API. Bei der Berechnung der CPU-Zeit wird ein Intel-x86-Prozessor mit 1,2 GHz als Referenz verwendet (siehe [GOOb]). Es steht ein freies Kontingent von 6 Stunden zur Verfügung, das alle 24 Stunden erneuert wird. Dieses Kontingent wird durch eine rechenlastige Anwendung jedoch (wie in 5.1 geschildert) schnell verbraucht. Die CPU-Quote kann auf bis zu maximal Stunden ausgedehnt werden. Eine Stunde kostet dabei gegenwärtig 0,10 US-Dollar (siehe [GOOa]). Die hier angeführten und weitere Restriktionen verdeutlichen, dass die Entwicklung rechen- oder datenlastiger Anwendungen nicht im Vordergrund der Google App Engine steht. Gemäß der zentralen Idee des Cloud Computing (siehe 2.3), ist die App Engine an erster Stelle für Web-Anwendungen entwickelt worden, die sich durch eine schwankende Anzahl von Requests charakterisieren lassen und denen dementsprechend Ressourcen dynamisch und automatisch zugeteilt und entzogen werden können. Insbesondere durch die Verwendung der Mapreduce-Bibliothek lassen sich sich jedoch auch solche Anwendungen realisieren. Die App Engine unterstützt zum gegenwärtigen Zeitpunkt die Python-Version 2.5 (als aktuell stabile Versionen gelten die Versionen 2.7 und ). Dadurch sind viele neu hinzugekommene Erweiterungen nicht verfügbar. Aufgrund der verteilten Speicherung der Daten sind Schreib- und Lesezugriffe auf den Datastore zeitaufwendig. Das nichtrelationale Datenbanksystem bringt eine Reihe von Einschränkungen mit sich, so sind z.b. keine Join-Anfragen möglich und die Prüfung auf Ungleichheit kann jeweils nur für eine Eigenschaft pro Entity und Abfrage erfolgen. Die Nutzung eines relationalen Datenbanksystems wird gegenwärtig nicht unterstützt. Es zeigte sich, dass die Anwendung unterschiedliches Verhalten aufweist, je nachdem ob sie in der lokalen Entwicklungsumgebung ausgeführt wird oder innerhalb der App Engine. Dies betrifft insbesondere die Limitierungen der App Engine, die in der lokalen Entwicklungsumgebung nicht geprüft werden. Ein weiterer kritischer Punkt betrifft die Abhängigkeit der Anwendung von der Infrastruktur der App Engine, die eine Portierung erschweren kann. Dieses Problem und Ansätze zu seiner Lösung wurden in Abschnitt bei der Vorstellung der Google App Engine näher erläutert. Auch liegt zum gegenwärtigen Zeitpunkt kein verbindliches Service-Level-Agreement (SLA) vor, sondern nur ein Entwurf 24. Somit gibt es keine rechtlich bindenden Garantien über die Sicherstellung der Verfügbarkeit der Anwendung 23 Stand:

52 und andere Kriterien. Für die entwickelte Anwendung ist dies unerheblich, da sie keine für das Funktionieren des Opennet-Netzwerks kritische Funktion erfüllt. Dieser Punkt sollte für wissenschaftliche Berechnungen im Allgemeinen nicht von großer Bedeutung sein, da im Gegensatz zu kommerziellen Anwendungen finanzielle Verluste, die durch die Nichtverfügbarkeit entstehen, keine Rolle spielen. 5.3 Ausblick In 5.1 wurde dargestellt, dass die entwickelte Anwendung die im Rahmen dieser Arbeit definierten Ziele erfüllt, wobei in 5.2 auf die während der Entwicklung entstandenen Erfahrungen mit der Google App Engine eingegangen wird. Im Folgenden sollen die Resultate der Arbeit beurteilt werden und Möglichkeiten zur Verbesserung der Anwendung aufgezeigt werden, die nicht realisiert wurden, da sonst der zeitliche und/oder inhaltliche Rahmen dieser Arbeit überschritten würde. Eine Prämisse dieser Arbeit bestand darin, dass die Berechnungen ohne Bezug zu realen Interferenzwerten im Netzwerk durchgeführt werden. Es sollte stattdessen ein Brute-Force- Ansatz mit Bezug auf die Ausführung in einer Cloud-Umgebung implementiert werden. Zusammenfassend lässt sich sagen, dass wissenschaftliche, rechenintensive Anwendungen von der Infrastruktur eines Cloud-Computing-Anbieters profitieren können, auch wenn die Angebote primär für Webanwendungen ausgelegt sind und Ressourcen wie CPU- Zeit restriktiv gehandhabt werden. Bezöge man die Interferenzen bei der Zuweisung von Kanälen zu Links mit ein, ergäbe sich eine andere Aufgabenstellung, die wenig Gemeinsamkeiten mit der Aufgabenstellung dieser Arbeit hätte. Jedoch könnte man die Interferenzwerte heranziehen, um eine realitätsnahe Verbesserung der Link-Quality-Werte zu errechnen, anstatt hierfür Zufallswerte zu verwenden. Es stellte sich heraus, dass die Brute-Force-Berechnung für eine geringe Knotenanzahl in vertretbarer Zeit durchführbar ist, die Komplexität jedoch exponentiell anwächst und Berechnungen für mehr als 15 Knoten durch die Restriktionen der App Engine nicht durchführbar sind. Dieser Umstand ist der Implementierung der Funktionalität zur Berechnung aller Kanalzuordnungen geschuldet (siehe A.2). Wie an anderer Stelle bereits erwähnt, ist die derzeitige Implementierung nicht parallelisierbar. Durch eine alternative Implementierung, die sich parallelisieren ließe, böte sich eine Möglichkeit, die Berechnungen für mehr Knoten durchführen zu können, als es gegenwärtig der Fall ist. Es wäre beispielsweise denkbar, eine Funktion zur verteilten Berechnung des kartesischen Produkts zu entwerfen. Dadurch könnte die maximale Anzahl der Knoten, für die eine Brute-Force-Berechnung durchgeführt werden kann, vermutlich erweitert werden. Es ist jedoch anzunehmen, dass aufgrund der exponentiellen Komplexität schnell ein Punkt erreicht wird, bei dem die Begrenzungen der App Engine die Ausführung der Berechnung verhindern. Ein anderer Ansatz besteht darin, weitere Kriterien für die Auswahl von Knoten zu definieren oder eine Priorisierung von Knoten vorzunehmen. Hierfür wäre es nützlich, empirische Daten, die im Netzwerk erhoben wurden, zu verwenden. 52

53 A Anhang Anmerkung: Zu Testzwecken wurden bereits 2048 Kombinationen für zwei Kanäle berechnet und ausgewertet. Die Ergebnisse können auf com/evaluation eingesehen werden (siehe A.1.3). A.1 Anleitung zur Nutzung der Anwendung A.1.1 Netzwerkübersicht URL: Wichtig: Diese Seite muss aufgerufen werden, bevor die Mapreduce-Jobs ausgeführt werden können, damit der Netzwerkgraph als Datastore-Entity angelegt wird. Die Seite bietet eine tabellarische Übersicht über alle Links im Netzwerk (Abbildung 19). Der Netzwerkgraph wird anhand der Timestamp-Datei konstruiert. Wenn keine Timestamp-Datei hochgeladen wurde (siehe Abschnitt A.1.4), wird die Timestamp- Datei /Quellcode/data/timestamp.txt verwendet. Im Kopf der Tabelle sind Datum und Uhrzeit der Timestamp-Datei sowie die ETX-Durchschnittswerte (Median und arithmetisches Mittel) aller Links im Netzwerk verzeichnet. Die Spalten From und To geben jeweils den Start- und Endknoten (in Form der zugehörigen IP-Adresse) einer jeden Verbindung im Netzwerk an. Die IP-Adressen der Knoten verlinken zu einer Seite, auf der die kürzesten Wege von dem ausgewählten Knoten zu allen anderen Knoten angegeben werden (Abbildung 24). Hierbei wird die Distanz im Sinne der ETX-Pfadmetrik angegeben sowie der Pfad zwischen den Knoten angezeigt. Die Spalte ETX Value enthält den ETX-Wert der jeweiligen Verbindung, der aus den Link-Quality- und Neighbor-Link-Quality-Werten berechnet wird. Die Spalte Link type enthält nur dann einen Eintrag, wenn es sich um Backbone- oder eine kabelbasierte Verbindung handelt. A.1.2 Starten von Mapreduce-Jobs URL: Wichtig: Bevor die Mapreduce-Jobs ausgeführt werden können, muss die Übersichtsseite aufgerufen werden (siehe den obigen Abschnitt Netzwerkübersicht). Des Weiteren müssen alle eventuell noch im Datastore vorhandenen Entities gelöscht werden - siehe dazu A.1.5. Die Mapreduce-Jobs wurden in 4.2 beschrieben. Die Weboberfläche, über die die Mapreduce- Jobs gestartet werden, ist in Abbildung 18 zu sehen. 53

54 Abbildung 19: Netzwerkübersicht A.1.3 Bewertung URL: Wurden die Mapreduce-Jobs CreateChannelAssignments und ValidateAndEvaluate erfolgreich ausgeführt, so können die Bewertungsergebnisse abgerufen werden. Abbildung 20 zeigt die Bewertungsübersicht für den Fall, dass die Kanalzuordnungen durch eine Instanz der Klasse channel_assignment.averagevaluesevaluator bewertet wurden (siehe 4.2). Hierbei sind die Kanalzuordnungen aufsteigend nach dem ETX-Median aufgeführt. Wurde stattdessen die Klasse channel_assignment.etxclassesevaluator verwendet, ergibt sich die in Abbildung 21 dargestellte Übersicht. Die Spalte Ascended nodes enthält die Anzahl der Knoten, die einer Klasse mit niedrigeren ETX-Intervallwerten als denen der Ursprungsklasse zugeordnet wurden. Die Spalte Relegated nodes enthält die Anzahl der Knoten, die in eine Klasse mit höheren ETX-Intervallwerten fallen. Die Spalte Difference beinhaltet die Differenz zwischen diesen beiden Werten (Ascended nodes - Relegated nodes), wonach die Kanalzuordnungen absteigend geordnet sind. In der derzeitigen Implementierungen werden die Link-Quality-Werte um einen zufälligen Wert verbessert, jedoch nie verschlechtert. Dies hat zur Folge, dass es keine Knoten gibt, die einer schlechteren Klasse zugeordnet werden. Daher haben alle Einträge in der Spalte Relegated nodes den Wert 0. Der Link, der mit View channel assignment betitelt ist, führt zu einer Übersicht aller Knoten im Netzwerk mit dem ihnen zugeordneten Kanal. Backbone-Knoten werden dabei explizit gekennzeichnet. Es existiert ein Default-Kanal, dem alle Knoten zugeordnet werden, die nicht zu den ausgewählten Knoten gehören. Der Link View map führt zu einer Karte, auf der die Netzwerkknoten verzeichnet sind. Die 54

55 Abbildung 20: Bewertungsübersicht (ETX-Durchschnittswerte) Abbildung 21: Bewertungsübersicht (ETX-Klassen) Verbindungen zwischen ihnen sind farbig gekennzeichnet: Kabelbasierte Verbindungen oder solche zwischen Backbone-Knoten sind schwarz dargestellt. Verbindungen auf dem Default-Kanal sind blau eingezeichnet. Allen anderen Kanälen wird eine zufällige Farbe zugeordnet. Eine Übersicht über den modifizierten Netzwerkgraphen erhält man, wenn man dem Link View network graph folgt. Die Übersicht entspricht der Darstellung in Abbildung 19 (siehe A.1.1). 55

56 Abbildung 22: Kanalzuordnung Abbildung 23: Karte Abbildung 24: Kürzeste Wege 56

57 Abbildung 25: Hochladen von Dateien A.1.4 Hochladen von Dateien URL: Die Anwendung benötigt folgende Dateien (der Aufbau der Dateien wird in der Datei /Quellcode/README.txt beschrieben): timestamp.txt: Enthält den Netzwerk-Timestamp (siehe 3.2). backbone_nodes.txt: Liste aller Backbone-Knoten cable_links.txt: Liste aller Kabellinks ip_to_coordinates.txt: Zuordnung von IP-Adressen der Netzwerkknoten zu geografischen Koordinaten Die Dateien können mit der Anwendung deployt werden, indem sie im Ordner /Quellcode/data/ platziert werden. Des Weiteren besteht die Option, diese Dateien über ein HTML-Formular hochzuladen (siehe Abbildung 25). Es erfolgt keine Überprüfung, ob die Dateien wohlgeformt sind, sodass ein Fehler an anderer Stelle auftritt, wenn dies nicht der Fall ist. A.1.5 Leeren des Datastore Um neue Mapreduce-Jobs ausführen zu können, müssen die Entities, die durch frühere Jobs im Datastore angelegt wurden, gelöscht werden. Hierzu muss der Job ClearDatastore für jeden Entity-Typ ausgeführt werden (siehe 4.2), indem der Entity-Typ als Wert des Parameters entity_kind übergeben wird. Der Job muss nacheinander für folgende Entity-Typen ausgeführt werden: NetworkGraphModel ModifiedNetworkGraphModel ChannelAssignmentModel NamesToNumbersModel EvaluationModel 57