Forschungsprojekt. RAvE - Realtime Automation Networks in Moving Industrial Environments

Transkript

1 Forschungsprojekt RAvE - Realtime Automation Networks in Moving Industrial Environments Zuwendungsempfänger: Hochschule Ostwestfalen-Lippe Förderkennzeichen: 1787A07 Laufzeit: Schlussbericht (Sachbericht des Verwendungsnachweises nach Nr. 6 ANBest-P) M.Sc. Henning Trsek Prof. Dr.-Ing. Jürgen Jasperneite Prof. Dr. rer. nat. Stefan Heiss Lemgo, den 15. Februar 2011 Prof. Dr.-Ing. Jürgen Jasperneite Institut Industrial IT der Hochschule Ostwestfalen-Lippe Liebigstrasse 87 D Lemgo juergen.jasperneite@hs-owl.de

2

3 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung Organisatorische Rahmenbedingungen Ausführende Stelle Zusammenarbeit mit anderen Stellen Planung und Ablauf des Vorhabens Stand der Technik Ausgangssituation Allgemeine Anwendungsanforderungen der Automation Anforderungsanalyse anhand einer realen Fertigungsanlage Untersuchungsgegenstand Erfassung und Auswertung der Daten Ergebnisse und Kommunikationsanforderungen Zusammenfassung der Anforderungen Verwaltung drahtloser Netze IEEE WLAN Handover Phasen des WLAN Handover Optimierungen des Handover Technischer Fortschritt bei anderen Stellen Ergebnisse RAvE Architektur Zentralisierte Verwaltung CAPWAP Protokoll CAPWAP Implementierung Schnelles Handover in IEEE WLANs Mechanismus der Infrastruktur-Seite Mechanismus der Client-Seite Bewertung der Handover Mechanismen Demonstrator Verbreitung und Nutzung der Ergebnisse Veröffentlichungen Abschlussarbeiten iii

4 Inhaltsverzeichnis 5.3 Kooperative Promotionen Messeauftritte Standardisierung Zusammenfassung Schlussfolgerung Ausblick iv

5 Kurzfassung Drahtlose Technologien aus dem Büroumfeld werden aufgrund ihrer weiten Verbreitung immer häufiger in der industriellen Automatisierungstechnik eingesetzt, können aber die hohen Anforderungen in diesem Bereich nicht erfüllen. Insbesondere in Bezug auf ihre Echtzeitfähigkeit, das Netzwerkmanagement und die IT Sicherheit. Das init - Institut Industrial IT untersucht im Projekt RAvE diese Eigenschaften anhand von zellularen WLAN Infrastrukturen, die eine großflächige Netzabdeckung bieten. Folglich ergibt sich einerseits das Problem der Verwaltung von den vorhandenen Infrastrukturkomponenten und andererseits die Notwendigkeit einen schnellen und für die Anwendung nicht sichtbaren Zellwechsel durchführen zu können. Für beide Funktionalitäten müssen relevante Aspekte der IT Sicherheit berücksichtigt werden. Durch eine infrastrukturseitige Zentralisierung von verschiedenen Funktionen (Schlüsselverwaltung, etc.) wurde die Verwaltung von komplexen WLAN Systemen erheblich vereinfacht. Das WLAN Management System basiert auf dem Protokoll CAPWAP. Hauptbestandteil ist ein zentraler Controller, der u. a. mit den angeschlossenen Access Points kommuniziert, sie entsprechend verwaltet und so Informationen über die jeweilige Zelle erhalten kann. Der schnelle Zellwechsel innerhalb des Systems wurde auf der Infrastruktur-Seite durch die in der Standarderweiterung IEEE r spezifizierten Mechanismen realisiert, besonders im Hinblick auf die IT Sicherheit. Seitens der mobilen Clients wurde ein Background Scanning Mechanismus eingesetzt, der die Handover Zeiten weiter reduzieren konnte. Die Integration beider Ansätze resultierte in einem zellularen WLAN System, welches die Anforderungen der Anwendungen in Bezug auf die zulässigen Zeiten des Zellwechsel erfüllt. Die Ergebnisse des Projekts wurden anhand eines IEEE WLANs bewertet. Sie ermöglichen die Verwaltung eines komplexen WLAN Netzes und die Optimierung des Zellwechsels unter Verwendung von existierenden commercial-of-the-shelf Chipsätzen. Die Ergebnisse können daher einfach in bereits bestehende Produkte der Partner integriert werden, ohne die sonst erforderliche Anpassung der Hardware. Außerdem sind die eingesetzten Verfahren hinreichend generisch und lassen sich grundsätzlich auch auf andere Technologien abbilden. v

6

7 Abstract Due to the success of IEEE networks in home, office and other environments, deployment of IEEE networks in industrial environments has already begun. However, their application remains a challenge due to the high requirements in this area. Especially, regarding their real-time capabilities, network management and IT security. Within the research project RAvE these characteristics are investigated by the init - Institut Industrial IT in the context of cellular infrastructures which provide coverage of large spatial areas. As a consequence two main problems arise, the management of the infrastructure components in such huge systems and the necessity to have a fast handover between different cells which is seamless for the application. Both functionalities require to consider relevant IT security aspects. The management of complex WLAN infrastructures was considerably simplified by means of a centralization of different functions (key management, etc.) on the infrastructure side. The whole system is based on the protocol CAPWAP. A centralized controller is the main component of the system. It communicates periodically with all connected Access Points and manages them accordingly. Therefore, the controller has information about any cell in the system at any time. The fast handover within the system was realized based on mechanisms of the r Standard amendment which is particularly important in the context of IT security. On the client side a background scanning was used to further reduce the overall handover duration. The integration of both approaches led to a cellular WLAN system which is able to meet the defined application requirements regarding the allowed latencies during a handover. The project results have been implemented and evaluated based on an IEEE WLAN. Mainly, the results comprise a centralized management system of a complex WLAN infrastructure and a handover optimization for WLANs using a commercial of the shelf WLAN chipset. The project results can be easily integrated into existing products of the involved partners without any hardware modifications. Moreover, the results are sufficiently generic in order to be applied to different kinds of other wireless technologies. vii

8

9 Abkürzungsverzeichnis AC ANSI AP AT BSS BSSID CAPWAP CSMA/CA CSS ESS FT FTIE HF IE IEC IEEE IETF IP IuK LAN LLC MAC MDID MDIE MLME MTU NAS OSI PDU PMK PTK QoS RFC RSSI RSNA SME Access Controller American National Standards Institute Access Point Automatisierungstechnik Basic Service Set Basic Service Set Identifier Control and Provisioning of Wireless Access Points Carrier Sense Multiple Access with Collision Avoidance Chirp Spread Spectrum Extended Service Set Fast BSS Transition Fast BSS Transition Information Element High Frequency Information Elements International Electrotechnical Commission Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Protocol Informations- und Kommunikationstechnik Local Area Network Logical Link Control Medium Access Control Mobility Domain Identifier Mobility Domain Information Element MAC sublayer Management Entity Maximum Transfer Unit Network Access Server Open System Interconnection Protocol Data Unit Pairwise Master Key Pairwise Transient Key Quality of Service Request for Comments Received Signal Strength Indicator Robust Security Network Association Station Management Entity ix

10 Inhaltsverzeichnis STA SUT TCP TDMA VLAN WAN WLAN WTP WLAN Station/Client System Under Test Transmission Control Protocol Time Division Multiple Access Virtual Local Area Network Wide Area Network Wireless Local Area Network Wireless Termination Point x

11 1 Einleitung 1.1 Aufgabenstellung Der Einsatz mobiler Dienste in der industriellen Automatisierungstechnik (AT) besitzt das Potenzial zu signifikanten Kosten-und Zeiteinsparungen. Daraus resultieren Produktivitätssteigerungen in unterschiedlichen Anwendungsfeldern der AT, beispielsweise in der Fabrik- und Prozessautomatisierung oder in der Produktionslogistik. Neben der Möglichkeit zur Erschließung innovativer Anwendungsmöglichkeiten wird von Systemintegratoren durch die Einführung mobiler Dienste eine Reduzierung der Aufwände zum Betrieb einer Anlage der AT und eine Reduzierung der Engineering-Aufwände prognostiziert. Verglichen mit den technischen Möglichkeiten und dem damit einhergehenden Potenzial ist die Durchdringung mobiler Technologien in der AT immer noch sehr gering. Das übergeordnete Ziel des Forschungsvorhabens bestand darin, die heute existierende technologisch bedingte Hemmschwelle fürden Einsatz von mobilen Diensten in der industriellen Automatisierungstechnik zu überwinden. Die hierfür notwendigen sicheren, mobilen Echtzeitdienste, insbesondere im Kontext ausgedehnter Anlagen der Produktionsautomatisierung, wurden realisiert und auf Basis einer reproduzierbaren Messumgebung evaluiert. Die Reproduzierbarkeit der Leistungsbewertung ist von besonderer Bedeutung, da sie, neben den eigentlich technologischen Fragestellungen, einen Beitrag zu einer erhöhten Anwenderakzeptanz leistet und so der traditionell eher konservativen Grundhaltung der Anwender entgegenwirkt. Gleichzeitig ergibt sich ein hohes Innovationspotenzial aufgrund neuer möglicher Anwendungen und eine erheblich gesteigerte Effizienz in Bezug auf den Anlagenbetrieb und das Engineering. Das wissenschaftliche Ziel bestand in der Entwicklung eines generischen Frameworks zur Nutzung, Konfiguration und Monitoring eines drahtlosen Netzes und der dafür notwendigen Mechanismen und Verfahren. Aus Sicht der Hochschule Ostwestfalen-Lippe wurde, aufgrund der spezifischen Randbedingungen und Anforderungen der Automatisierungstechnik, der Hauptfokus auf die Echtzeiteigenschaften und ein einfaches Securitymanagement gelegt. Da die Flexibilitätsanforderungen in der AT zukünftig weiter steigen werden, sind mobile Dienste zwingend erforderlich. Vor diesem Hintergrund ist es von großem wissenschaftlichen Interesse, neue Verfahren zu entwickeln, die drahtlose Technologien aus dem IuK Bereich für die Echtzeitkommunikation in der Automatisierungstechnik nutzbar machen. 1

12

13 2 Organisatorische Rahmenbedingungen 2.1 Ausführende Stelle Hinsichtlich der Fragestellungen in den Bereichen WLAN und IT Security wurde das Projekt im init - Institut Industrial IT der Hochschule Ostwestfalen-Lippe am Standort Lemgo durchgeführt. Das init ( ist eine Einrichtung der angewandten Forschung und fasst die Forschungsaktivitäten von 6 Professoren unterschiedlicher Fachgebiete zusammen. In dem Institut, dass von Prof. Dr. Jürgen Jasperneite geleitet wird, sind derzeit mehr als 40 Mitarbeiter in den Bereichen industrielle Kommunikation, industrielle Bildverarbeitung und verteilte Echtzeit-Software in öffentlich geförderten Verbundvorhaben oder in Projekten der bi-/multilateralen Auftragsforschung tätig. Beteiligte Personen an dem Projekt RAvE waren aus Sicht der ausführenden Stelle (init - Institut Industrial IT, Hochschule Ostwestfalen-Lippe): Prof. Dr.-Ing. Jürgen Jasperneite, Projektleiter Prof. Dr. rer. nat. Stefan Heiss, Projektleiter M.Sc. Henning Trsek, wiss. Mitarbeiter M.Sc. Ahmad Ali Tabassam, wiss. Mitarbeiter M.Sc. Jamal Raiyn, wiss. Mitarbeiter 2 Studierende als studentische Hilfskräfte 6 Studierende im Rahmen von Abschlussarbeiten Zusammenarbeit mit anderen Stellen Als Kooperationspartner haben die folgenden Unternehmen und Forschungseinrichtungen das Projekt unterstützt und begleitet: Forschungsstellen Hochschule Bochum, Labor für Softwaretechnik und Rechnernetze, Lennershofstr. 140, Bochum 3

14 2 Organisatorische Rahmenbedingungen Gewerbliche Partner Phoenix Contact Electronics GmbH, Dringenauer Str. 30, Bad Pyrmont rt-solutions.de GmbH, Oberländer Ufer 190a, Köln nanotron Technologies GmbH, Alt-Moabit 60, Berlin Wissenschaftliche Begleitung Otto-von-Guericke-Universität Magdeburg, Prof. Dr. E. Nett, Universitätsplatz 2, Magdeburg Ruhr-Universität Bochum, Prof. Dr. C. Paar, Universitätsstr. 150, Bochum ifak - Institut für Automation und Kommunikation e.v. Magdeburg, Werner- Heisenberg-Str. 1, Magdeburg Die Hochschule Bochum bearbeitete im Rahmen des Projekts den Bereich der Short Range Wireless Technologien. Hierdurch war sichergestellt, dass im Projekt die gesamte Bandbreite der für die Automatisierungstechnik relevanten Funktechnologien abgedeckt wurde. Die erzielten Projektergebnisse aus den verschiedenen Arbeitsbereichen wurden in regelmäßigen Besprechungen mit dem Projektpartner Hochschule Bochum diskutiert. Von dem regen Erfahrungsaustausch und dem damit einhergehenden Austausch von vorhandenem Know-how konnten beide Forschungspartner und das gesamte Projekt erheblich profitieren. Phoenix Contact Electronics hat seinen Sitz in Bad Pyrmont und ist ein Unternehmen der industriellen Automatisierungstechnik. Neben der Ausfinanzierung einer TV-L 13 Stelle durch eine Bareinlage unterstützte Phoenix Contact Electronics das Projekt durch die Bereitstellung und Überlassung von Evaluationsboards und weiterer WLAN- bzw. Automatisierungskomponenten. Darüber hinaus fand ein regelmäßiger Informationsaustausch bezüglich aktueller Trends in der Automation und innovativer Anwendungen mit drahtlosen Systemen und der sich daraus ergebenen Anforderungen statt. Des Weiteren wurde das Projekt auf inhaltlicher Ebene intensiv unterstützt. Das Unternehmen rt-solutions.de GmbH ist ein international agierendes Hightech Unternehmen, das 2000 von erfolgreichen Wissenschaftlern und Unternehmern mit dem Ziel gegründet wurde, leistungsfähige Netzwerke und sichere IT- Infrastrukturen als Grundlage für Unternehmensprozesse zu realisieren, sowohl im Bereich Office als auch in der Automatisierung. Die rt-solutions.de GmbH unterstützte das Projekt im Wesentlichen durch Beratungsleistungen im Bereich der Konzeption, der drahtlosen Netze und der IT Sicherheit. Die nanotron Technologies GmbH mit Sitz in Berlin entwickelt Kommunikationslösungen auf der Basis von ChirpSpreadSpectrum(CSS) und kann somit die 4

15 2.1 Ausführende Stelle Technologie für eine IEEE a Anbindung zur Verfügung stellen. Durch das spezifische Know-how des Projektpartners konnten im Rahmen des Projekts Beiträge zur Anforderungsdefinition hinsichtlich der drahtlosen Technologien geleistet werden. Die wissenschaftliche Begleitung des Projekts erfolgte durch Prof. Dr. Nett (Ottovon-Guericke-Universität Magdeburg, Institut für verteilte Systeme), Prof. Dr. Paar (Ruhr-Universität Bochum, Lehrstuhl für Embedded Security) und das ifak - Institut für Automation und Kommunikation e.v. Magdeburg Planung und Ablauf des Vorhabens Das Projekt RAvE wurde im Wesentlichen durch das init - Institut Industrial IT der Hochschule Ostwestfalen-Lippe und durch das Labor für Softwaretechnik und Rechnernetze der Hochschule Bochum durchgeführt. Es kann grundsätzlich in zwei Teilbereiche gegliedert werden, Wireless Local Area Networks und IT Sicherheit und Short Range Wireless Technologien. Für den ersten Teilbereich wurde die Bearbeitung und Projektleitung vom init übernommen, die Projektleitung und die Bearbeitung des zweiten Bereichs übernahm die Hochschule Bochum. Die kooperierenden Unternehmen standen während der einzelnen Arbeitspakete für entsprechende Analysen, Definitionen und Realisierungen im Bereich der kommerziellen Ausgestaltung des Projekts zur Verfügung. Zur Erreichung des in Kapitel 1.1 formulierten übergeordneten Ziels wurden die Aufgaben im Projekt in einem Kick-off Meeting mit den Projektpartnern in Bezug auf die o. g. Teilbereiche weiter strukturiert. Das Gesamtprojekt gliedert sich in die acht Arbeitspakete Konzeption (AP1), Framework (AP2), Wireless Convergence (AP3), Security (AP4), Services (AP5), Hard- und Software (AP6), Feldtest (AP7) und das Projektmanagement (AP8). In dem Arbeitspakete 1 wurde zunächst eine systematische Analyse der Anforderungen heutiger Automatisierungssysteme durchgeführt. Basierend darauf wurde in den Arbeitspaketen 2, 3 und 4 ein Gesamtsystem spezifiziert, das Die entstandenen Definitionen wurden im Anschluss in den Arbeitspaketen 5 und 6 implementiert und zu einem Gesamtsystem integriert. Abschließend erfolgte gemäß des Arbeitspaketes 7 die Validierung der entstandenen Implementierung durch entsprechende Testsszenarien. Die Aufgaben des AP 8 hinsichtlich der Durchführung und Dokumentation des Projektes und der Koordination relevanten Messeauftritte und notwendiger Projektabstimmungen erstreckten sich über die gesamte Laufzeit des Projekts. 5

16

17 3 Stand der Technik 3.1 Ausgangssituation Die drahtlose funkbasierte Datenübertragung ermöglicht in vielen Bereichen der Automatisierungstechnik (AT) die Realisierung neuer technischer Lösungen, daher ist ihre Einführung in zukünftigen Netzwerken, auch auf Feldbusebene, unumgänglich. Dafür verantwortlich sind zum einen Anwendungen, die ein großes Maß an Mobilität der beteiligten Geräte erfordern und zum anderen Faktoren wie eine höhere Flexibilität und eine merkliche Kostenersparnis durch den Einsatz einer drahtlosen Kommunikationsinfrastruktur [1]. 3.2 Allgemeine Anwendungsanforderungen der Automation Die allgemeinen Anwendungsszenarien für den Einsatz der in RAvE entwickelten Architektur werden in diesem Kapitel genauer beschrieben, um daraus im Anschluss in Kapitel 3.3 entsprechende Anforderungen anhand einer realen Fertigungsanlage ableiten zu können. Die Anwendungsfälle können in die beiden Bereiche der Fertigungsautomatisierung (FA) und der Prozessautomatisierung (PA) unterteilt werden, die sich im Wesentlichen durch unterschiedliche Anforderungen an die maximal tolerierbare Latenzzeit unterscheiden. Beide Bereiche haben jedoch die Gemeinsamkeit, dass hohe Anforderungen an die Zuverlässigkeit und die Echtzeiteigenschaften der jeweiligen drahtlosen Technologie gestellt werden. Die Anwendungsfälle der Prozessautomatisierung bestehen im Wesentlichen aus fünf Bereichen. Dies sind die Prozesssteuerung, die Prozessüberwachung, die Alarmbehandlung, das Asset Management und das Engineering. Im Allgemeinen müssen großflächige Installationen (1 km x 1 km) möglich sein, die eine große Anzahl drahtloser Knoten ( ) beinhalten. Die höchsten Anforderungen an die zulässigen Latenzzeiten stellt hierbei die Prozesssteuerung, wegen dem notwendigen zyklischen und deterministischen Datenaustausch und geforderten Zykluszeiten im Bereich von 100 ms. In der Fertigungsautomatisierung sind die Anwendungsfälle in die Bereiche Fertigungssteuerung, Bedienen und Beobachten, sowie die Überwachung und Dia- 7

18 3 Stand der Technik gnose gliedert. Die Ausdehnung des drahtlosen Netzwerkes beschränkt sich hier üblicherweise auf mehrere Fertigungszellen, d. h. bis zu mehreren 100 Metern. Die Knotenanzahl liegt ungefähr in dem Bereich der Prozessautomatisierung. Eine detaillierte Übersicht der geforderten Eigenschaften zeigt Tabelle 3.1. Tabelle 3.1: Anforderungen in verschiedenen Bereichen der Prozess- und Fertigungsautomatisierung [2] Bereich Anwendungsfall Entfernung Zykluszeit Betrieb Steuerung m 20 ms Zyklisch Fertigungsautomatisierung Bedienen+Beobachten m 50 ms Azyklisch/zyklisch Überwachung+Diagnose m 1 min Zyklisch Prozesssteuerung m 100 ms Zyklisch Prozessmonitoring m 100 ms Zyklisch Prozessautomatisierung Asset Management m 1 s - min. Azyklisch/zyklisch Alarmbehandlung m Azyklisch Mobile Dienste m Azyklisch Zusammenfassend kann man sagen, dass in der Prozessautomatisierung Zykluszeiten in der Größenordnung von 100ms garantiert werden müssen und demgegenüber Werte von 10 ms in der Fertigungsautomatisierung stehen. Beispielhafte Anwendungen sind Transportsysteme, die drahtlos mit einer übergeordneten Steuerung kommunizieren oder aber Scanner in der Materialflussüberwachung, um eingescannte Daten an eine Logistikzentrale zu senden. 3.3 Anforderungsanalyse anhand einer realen Fertigungsanlage Anwendungen der Fertigungsautomatisierung sind repräsentativ für die in RAvE relevanten Anwendungsgebiete. Sie stellen wegen ihrer hohen Dynamik häufig anspruchsvolle und hohe zeitliche Anforderungen [3] an das eingesetzte Kommunikationssystem. Um einen drahtgebundenen Feldbus oder ein Echtzeit-Ethernet System durch ein alternatives drahtloses System ersetzen zu können, ist es daher zunächst erforderlich, eine detaillierte Analyse der bestehenden Anforderungen durchzuführen. Die Analyse erfolgt durch die Aufzeichnung der Kommunikation an der laufenden Anlage und der anschließenden Auswertung des aufgezeichneten Datenverkehrs. Die Auswertung erfolgt im Hinblick auf verschiedene Kriterien. Dieses Vorgehen ist ein bekannter Ansatz im Umfeld von Local Area Networks (LAN) und Wide Area Networks (WAN). Es gibt bereits viele Arbeiten in diesem Gebiet (siehe [4]), es sind allerdings nur wenig Forschungsergebnisse im Bereich der industriellen Automatisierung verfügbar. Jasperneite et al. [5] haben ein Kommunikationssystem einer Anlage der Fertigungstechnik untersucht, um daraus ein repräsentatives Verkehrsmodell für eine simulative 8

19 3.3 Anforderungsanalyse anhand einer realen Fertigungsanlage und analytische Leistungsbewertung abzuleiten. Hierfür wurde der Datenverkehr der Anlage eine Woche aufgezeichnet. Die Ergebnisse basieren auf der Verteilung von Ankunftszeiten, der Verteilung von Paketgrößen und der zeitlichen Charakteristiken der versendeten Nachrichten. Das Kommunikationssystem bestand im Wesentlichen aus dem Feldbussystem Interbus [6]. In Rahmen dieses Projektes wird eine Anlage mit einem heterogenen Kommunikationssystem untersucht, welches die Feldbussysteme Interbus [6], Sercos II [7] und Modbus/TCP [8] basierend auf Ethernet [9] beinhaltet. Aus den Messungen werden Verkehrsmuster und die entsprechenden zeitlichen Anforderungen abgeleitet [10] Untersuchungsgegenstand Bei der zu untersuchenden Anlage handelt es sich um eine Maschine die zur Erprobung neuer Technologien und Konzepte betrieben wird. Die Bus- und Netzwerkkonfiguration der Maschine ist in Abbildung 3.1 dargestellt. Es handelt sich hier um einen komplexen Aufbau, mit mehreren Steuerungen, Antrieben, sowie Sensoren und Aktoren. Grundsätzlich lässt sich der Versuchsaufbau zunächst in die drei vorherig genannten Feldbussysteme gliedern. Abbildung 3.1: Industrielle Produktionsanlage mit heterogener Kommunikationsstruktur Sercos II übernimmt die Ansteuerung der Antriebe, die Sensor- und Aktorkom- 9

20 3 Stand der Technik munikation wird mit Interbus realisiert und Modbus/TCP ist für den Austausch von Parametern und Fehlermeldungen zuständig. Die Anlage ist mit einer zentralen Steuerung ausgestattet. Hierbei handelt es sich um eine PC-basierte All-in-One Steuerlösung, d. h. es werden die Funktionen einer SPS geboten und je nach Ausführung kann ein Touchscreen integriert sein (z. B. als Bedienschnittstelle). In der zu untersuchenden Anlage ist die Steuerung mit einem Interbus- und einem Sercos II-Master ausgestattet. Für Modbus/TCP wird das serienmäßig integrierte Ethernet Interface verwendet. Über den Sercos II-Master werden zwei Antriebe (Sercos II Slaves) angesteuert. Der Interbus Master ist über den Fernbus mit einer Kompaktsteuerung ILC 370, mehreren I/O-Knoten und dem Industrie-PC 5100 verbunden. Über Ethernet bzw. Modbus/TCP werden einerseits Signale, die für sicherheitsrelevante Aspekte der Anlage zuständig sind, und andererseits Displays für die Ausgabe von Parametern und Fehlermeldungen angebunden. Produktionsanlage Bei der Phoenix Contact Konzeptmaschine handelt es sich um eine reale Produktionsanlage aus dem Bereich der Fertigungsautomatisierung zur Herstellung von Steckverbindern. Sie dient dem Unternehmen zur Erprobung neuer Technologien und Maschinenkonzepte. Da die Anlage ausschließlich für Demonstrationszwecke eingesetzt wird, sind einige mechanische Komponenten sowie Stationen, ohne Funktion bzw. in ihrer Funktion eingeschränkt, welches jedoch keinen Einfluss auf die Kommunikationscharakteristiken hat. Der Ablauf der Produktionsanlage ist in einzelne Stationen unterteilt. Insgesamt werden neun Stationen durchlaufen, bis ein Steckverbinder vollständig zusammengesetzt und auf Fehler geprüft ist. Für einen vollständigen Durchgang (Station 1 - Station 9) benötigt ein Werkstück ca. 165s. Die Zuführung der Werkstücke zu den einzelnen Stationen ist durch die dafür konzipierten Werkstückträger, die häufig auch als Nest bezeichnet werden, realisiert. Die Feinpositionierung der Träger an den verschiedenen Stationen wird durch einen Servomotor (Hauptantrieb) in Verbindung mit einem Kugelgewindetrieb durchgeführt. Der Rücktransport wird durch ein Transportband bewerkstelligt. An Station 1 werden die Steckverbinder-Gehäuse den Werkstückträgern zugeführt. Hierzu entnimmt ein Teile-Greifer ein Leergehäuse aus der Zuführung (Förderrinne) und setzt es in den Werkstückträger. Anschließend wird auf Station 2 durch einen Lichtschranke geprüft, ob sich das Werkstück in der richtigen Position im Werkstückträger befindet. Die dritte Station ist für das Einsetzen der Kontaktstifte in die Werkstückgehäuse zuständig. Station 4 stellt sicher, dass der zuvor eingesetzte Kontaktstift vollständig eingerastet ist. Zu diesem Zweck werden die Stifte der Reihe nach mit einem Pneumatikzylinder eingedrückt. An den Stationen 5-7 wird die Ausdrückkraftprüfung vorgenommen. Hiermit wird sichergestellt, dass sich kein Stift löst, wenn ein Stecker aus der Grundleiste einer Leiterplatte gezogen wird. Station 8 10

21 3.3 Anforderungsanalyse anhand einer realen Fertigungsanlage prüft die qualitativen Merkmale der Werkstücke unter Zuhilfenahme einer Kamera und dem IPC 5100 (vgl. Abb. 3.1). Die letzte Station sortiert die fertigen Artikel nach Gutteil und Ausschuss. Dazu wird, ähnlich der ersten Station, ein Teile-Greifer für das Entnehmen und Ablegen verwendet. Interbus, Sercos II und Modbus/TCP Bei Interbus handelt es sich um einen international verbreiteten Feldbusstandard, optimiert für den Sensor-Aktor-Bereich [11]. Die Kommunikation des Interbus- Protokolls basiert auf dem Summenrahmenverfahren. Aus topologischer Sicht ist Interbus ein Ringssystem, d. h. alle Teilnehmer sind aktiv in einem geschlossenen Übertragungsweg eingebunden [11]. Bei Sercos II handelt es sich um eine speziell auf Antriebe ausgerichtete digitale Schnittstelle, die nach dem Master-Slave-Prinzip arbeitet [7]. Der Datenaustausch zwischen den Teilnehmern findet auf Grundlage einer monomasterfähigen Ringstruktur statt. Der Zugriff auf das Übertragungsmedium ist durch ein Zeitschlitzverfahren realisiert [12]. Im Gegensatz zu den anderen beschriebenen Standards, kommen bei Sercos II Lichtwellenleiter (LWL) als Übertragungsmedium zum Einsatz. Modbus/TCP ist eines der ersten Ethernet-basierten Feldbussysteme und wird hauptsächlich in der Fertigungsautomatisierung eingesetzt [8]. Das Modbus/TCP Protokoll ist eine Weiterentwicklung des bereits 1979 hervorgebrachten Modbus- Standards. Dabei wurden die Modbus-Dienste sowie das Kommunikationsmodell aus dem Standard übernommen und auf TCP/IP abgebildet [8] Erfassung und Auswertung der Daten Der erste Schritt zur Ermittlung der Kommunikationsanforderungen, der im vorherigen Kapitel beschriebenen Konzeptmaschine, ist die gleichzeitige Aufzeichnung der gesamten Kommunikation. Die zentrale speicherprogrammierbare Steuerung (SPS) hat drei verschiedene Kommunikationsschnittstellen, deren Verkehr gleichzeitig von einem PC mit spezieller Analyse-Hardware, die während der Messungen zeitlich synchron arbeitet, aufgezeichnet wird. Die aufgezeichneten Nutzdaten werden mit den in der Anlage projektierten Eingangs- und Ausgangssignalen verknüpft. Dadurch können die zeitlichen Verläufe der Zwischenankunftszeiten der einzelnen Sensorund Aktorsignale extrahiert, statistisch ausgewertet und hinsichtlich ihrer Verteilung bewertet werden. Neben der Bewertung der Zwischenankunftszeiten einzelner Prozesssignale werden die Einflüsse der heterogenen Kommunikationsstruktur untersucht. Die Datenerhebung erfolgte auf der Leit-, Prozess- und der Feldebene, aufgezeichnet wurde sämtlicher Datenverkehr, in zwei, im Vorfeld definierten Messszenarien. Da es sich hierbei um eine reale industrielle Produktionsanlage handelt, kann das 11

22 3 Stand der Technik Anwendungsverhalten während der Messung nicht beeinflusst werden. Die Aufzeichnung erfolgte daher nach der Methode der passiven Überwachung (Monitoring) [13], die mit Hilfe eines für das jeweilige Bussystem entsprechenden Protokollanalysators durchgeführt wird. Die Analyse des Sercos II Protokolls wurde mit dem Sercos Monitor durchgeführt, der sowohl aus Hardware- als auch aus Softwarekomponenten besteht und von der Hilscher GmbH bereitgestellt wurde. Des Weiteren wurde der Protokollanalysator netanalyzer (ebenfalls von der Hilscher GmbH) für Modbus/TCP verwendet. Die Auswertung der aufgezeichneten Daten erfolgte mit der frei erhältlichen Software Wireshark. Die Aufzeichnung des Interbus Protokolls erfolgte mit einem vorhandenen Interbus Analyzer, der ebenfalls aus einer Hard- und Software Kombination bestand. Das erste Messszenario beschränkte sich auf die Bussysteme Interbus und Modbus/TCP. Die Gesamtdauer der Messung betrug ca. 2 h und wurde im Vorfeld anhand beispielhafter Messungen bestimmt (siehe [13]). Ziel dieser Messung war die Untersuchung einzelner Sensor- und Aktorsignale und deren anschließende statistische Bewertung unter dem Kriterium der Zwischenankunftszeit. Außerdem wurden die Messergebnisse hinsichtlich der entstehenden Latenzzeiten ausgewertet. Für das zweite Messszenario wurden die Bussysteme Interbus, Sercos II und Modbus/TCP herangezogen. Die Messdauer wurde entsprechend vorhandener Einschränkungen bezüglich der Aufzeichnungsdauer des Sercos II Protokollanalysators ausgelegt und hatte daher eine Gesamtdauer von ca. 7 min. Ziel dieser Messung war der Nachweis von Signalabhängigkeiten innerhalb der heterogenen Kommunikationsstruktur und die Bestimmung vorhandenen Latenzzeiten Ergebnisse und Kommunikationsanforderungen Im ersten Schritt konnten aus der Datenerhebung für das erste Messszenario einzelne Sensor- und Aktorsignale extrahiert werden. Im Folgenden werden diese unter dem Kriterium der Zwischenankunftszeit (T E ) statistisch bewertet und grafisch veranschaulicht. Die zeitlichen Verläufe der Zwischenankunftszeiten werden hierbei als Histogramm H(T E ) und als empirische Verteilungsfunktion F (T E ) dargestellt. Grundsätzlich lassen sich die gewonnenen Ergebnisse zunächst in drei Leistungskategorien einteilen: 1. Hohe Anforderungen ( 100ms) 2. Mittlere Anforderungen ( 1s) 3. Geringe Anforderungen ( 1s) Das Signal ST1 OUT xoeffner 2 vor-y (Interbus) steuert die Bewegung eines Aktors auf Station 1 und kann der Leistungskategorie hohe Anforderungen zugeordnet werden. 12

23 3.3 Anforderungsanalyse anhand einer realen Fertigungsanlage (a) (b) Abbildung 3.2: Verteilung der Zwischenankunftszeiten des Signals ST1 OUT xoeffner 2 vor-y Die bimodale Verteilung in Abbildung 3.2(a) ist auf die sequentielle Arbeitsweise des fertigungstechnischen Prozesses zurückzuführen. Es kann zwischen aktiven Phasen und passiven Phasen unterschieden werden. In den aktiven Phasen wird das Werkstück bearbeitet und in den passiven Phasen findet keine Bearbeitung des Werkstücks statt. In Abbildung 3.2(b) wird das Intervall 50 ms fokussiert, es handelt sich hierbei um die aktive Phase. Das Histogramm zeigt eine deutliche Häufung der Messwerte bei ca. 23 ms und 27 ms. (a) (b) Abbildung 3.3: Verteilung der Zwischenankunftszeiten des Signals ST3 IN xstift vorhanden-b Das Signal mit den vergleichsweise höchsten Anforderungen konnte an Station 3 identifiziert werden. Bei dem Sensorsignal ST3 IN xstift vorhanden-b (Interbus) handelt es sich um eine Lichtschranke. Mit dieser wird geprüft, ob ein Kontaktstift folgerichtig in das Werkstückgehäuse eingesetzt wurde. 13

24 3 Stand der Technik Abbildung 3.3(b) stellt einen feiner skalierten Bereich der zeitlichen Verläufe der Zwischenankunftszeiten dar ( 10 ms). Es ist eine Häufung der Messwerte bei ca. 3,37ms und 6,5ms erkennbar. Auffällig ist hierbei die Häufung der Messwerte bei 3,37 ms, dieser Wert entspricht der Interbus-Buszykluszeit. Es kann somit festgehalten werden, dass das Signal an die Leistungsgrenze des Bussystems herankommt. Da der Betrieb der Anlage allerdings während der gesamten Messdauer fehlerfrei war, wird davon ausgegangen, dass die gebotene Leistung in diesem Fall ausreichte. Abbildung 3.4: Verteilung der Zwischenankunftszeiten des Signals ST3 IN xstift Greifer zu-b Als Beispiel für ein Signal im mittleren Anforderungsbereich wurde das Sensorsignal ST3 IN xstift Greifer zu-b untersucht. Die entsprechenden Zwischenankunftszeiten des Signals sind in Abbildung 3.4 dargestellt. Die Messwerte häufen sich bei ca. 400ms und 500ms. Auffällig ist, dass der Abstand zwischen den deutlich ausgeprägten Gipfeln deutlich kleiner ist, im Vergleich zu den bisher untersuchten Signalen. Dies ist dadurch begründet, dass die aktiven und passiven Phasen des fertigungstechnischen Prozesses eine ähnliche zeitliche Dauer haben. Tabelle 3.2: Latenzzeiten verschiedener, betrachteter Signale i Quelle Senke Latenzzeit (T L ) 1 ST1 IN xoeffner 2 (Sensor) ST1 OUT xoeffner 2(Aktor) 16 ms 2 ST1 IN xgeh greifen zu (Sensor) ST1 OUT xgeh greifen zu (Aktor) 42 ms 2 ST1 IN Zylinderschalter vorne (Sensor) ST1 OUT Hauptantrieb (Aktor) 45 ms 2 ST1 IN Zylinderschalter hinten (Sensor) ST1 OUT Hauptantrieb (Aktor) 48 ms 3 ST3 IN xstift Greifer zu (Sensor) ST3 OUT xstift Greifer zu (Aktor) 23 ms 6 ST9 IN xentnahme vorne (Sensor) ST9 OUT xentnahme vor (Aktor) 270 ms Für die Ableitung von Kommunikationsanforderung ist neben der Zwischenankunftszeit (T E ), auch die Latenzzeit (T L ) von entscheidender Bedeutung. Betrachtet wurde die Zeitspanne zwischen Sendebeginn von der Quelle bis zur Ankunft an der Senke bzw. in diesem Fall vom Sensor bis zum Aktor. In Tabelle 3.2 sind Latenzzeiten für einzelne ausgewählte Aktor- und Sensorsignale (Interbus) veranschaulicht. Besonders hohe Anforderungen sind in Station 3 und 4 vorzufinden und liegen bei 10 ms, 14

25 3.3 Anforderungsanalyse anhand einer realen Fertigungsanlage eher geringe Anforderungen liegen bei 270 ms in Station 9. Abbildung 3.5: Latenzzeiten Bus-übergreifend Um eine Bus-übergreifende Signalabhängigkeit nachzuweisen, wurden die zeitlichen Verläufe der Signale xduswivelunitinfront-b und xdu1swivelunitback-b (beide Interbus) in Abhängigkeit zu dem zeitlichen Verlauf des Hauptantriebs (Sercos II) betrachtet (Abbildung 3.5). Bei beiden Interbus-Signalen handelt es sich um Sensorsignale (Zylinderschalter) des Drehantriebs für die Schwenkleisten, welche gemäß der Bewegungsrichtung des Hauptantriebs abwechselnd true sind. Dem zeitlichen Verlauf des Hauptantriebs ist zu entnehmen, dass die längeren zeitlichen Abstände auf den Werkstückträgertransport zurückzuführen sind (Signal true). Die kurzen zeitlichen Abstände (Signal false) deuten auf den Werkstückträgerwechsel hin. Für den Hauptantrieb und das Sensorsignal xdu1swivelunitinfront-b wurde eine durchschnittliche Latenzzeit von 45 ms ermittelt. Des Weiteren konnte für das Sensorsignal xdu1swivelunitback-b und den Hauptantrieb eine Latenzzeit von 48 ms bestimmt werden Zusammenfassung der Anforderungen In diesem Kapitel wird eine reale Maschine aus dem Bereich der Fertigungsautomatisierung, die zur Produktion von Steckverbindern dient, herangezogen, um die Verkehrsmuster der verschiedenen Sensor- und Aktorsignale zu untersuchen. Aus den extrahierten Ergebnissen werden aktuell gültige Anforderungen an ein drahtloses Kommunikationssystem abgeleitet. Der Hauptaugenmerk der Analyse liegt hierbei auf den Zwischenankunftszeiten und den Latenzzeiten einzelner Signale, da hieraus 15

26 3 Stand der Technik die zeitlichen Anforderungen und Charakteristiken der Anwendung direkt abgeleitet werden können. Die beiden Metriken haben eine unterschiedliche Bedeutung und Aussagekraft. Die Zwischenankunftszeit ist von Bedeutung, wenn es darum geht den gesamten Prozess zu verstehen. Die Latenzzeit ist hingegen entscheidend, wenn Anforderungen für Technologien abgeleitet werden sollen, insbesondere im Bezug auf die Echtzeitfähigkeit. Aus dieser Metrik ist direkt ersichtlich, welche Eigenschaften eine drahtlose Technologie bezüglich oberer Zeitschranken erfüllen muss. Die erzielten Ergebnisse zeigen, dass die höchsten Anforderungen im Bereich von ca ms (vgl. Tabelle 3.2) liegen. Wenn der vorhandene Feldbus durch eine drahtlose Technologie ersetzt werden soll, müssten diese garantiert werden. Betrachtet man beispielsweise IEEE WLAN [14], ist es möglich diese Anforderungen unter idealen Bedingungen zu erfüllen, d. h. geringe Auslastung des Übertragungskanals (wenige aktive Stationen), kein Zellwechsel und keine weiteren Interferenzen. Sobald diese Bedingungen jedoch nicht mehr zutreffen und beispielsweise ein Zellwechsel durchgeführt werden müsste, können diese hohen Anforderungen mit der derzeitigen WLAN Technologie nicht erfüllt werden. 3.4 Verwaltung drahtloser Netze Bei einer herkömmlichen zellbasierten WLAN Infrastruktur sind immer mehrere dezentrale Access points (APs) vorhanden, die über ein gemeinsames Netzwerk miteinander kommunizieren können. Jeder AP bildet mit den assoziierten Clients ein basic service set (BSS). Die einzelnen BSSs bilden wiederum ein extended service set (ESS), innerhalb dessen sich die gesamte Intelligenz in den einzelnen APs befindet. Alle weiteren verteilten APs innerhalb des ESS besitzen keine Informationen über benachbarte APs. Hieraus ergeben sich Probleme, wie z. B. eine sehr aufwendige Administration. Jeder AP muss individuell verwaltet und gewartet werden, welches in der Regel qualifiziertes Personal erfordert. Die prinzipielle Architektur eines zentralisierten WLANs wird in Abbildung 3.6 gezeigt. Bei diesem Ansatz wird ein Teil der Funktionalitäten des APs in einen zentralen Switch verlagert. In einer solchen Architektur wird der AP meist als Wireless Termination Point (WTP) und der zentrale Switch als Access Controller (AC) bezeichnet. Der AC ist die zentrale Instanz und kontrolliert bzw. kommuniziert mit den angeschlossen WTPs über ein spezielles Protokoll. Die möglichen Architekturen für ein Switched WLAN bestehen aus drei verschiedenen Ansätzen. Die Local MAC, die Split MAC und die Remote MAC. Die Local MAC belässt alle WLAN Funktionalitäten im WTP und verlagert nur die Konfiguration und das Management in den AC. Bei der Split MAC verbleiben nur die echtzeitkritischen Funktionen (z. B. Erzeugung der Beacons, Neuübertragungen, usw.) im WTP. Alle übrigen, die Konfiguration und das Management werden in den AC verlegt. Bei der Remote 16

27 3.5 IEEE WLAN Handover Abbildung 3.6: Verschiedene Architekturen eines zentralisierten WLANs MAC dient der WTP lediglich als Transceiver, der nur den PHY Layer beinhaltet, sämtliche MAC Funktionalitäten werden im AC realisiert. Alle drei Architekturen haben zwei Merkmale gemeinsam. Zum einen werden die assoziierten Clients immer zentral verwaltet, sodass die meisten der anfallenden Management- und Monitoring- Aufgaben ausschließlich dem zentralen AC zufallen und zum anderen befindet sich derphylayerimmerimwtp. Die Kontrolle und die Kommunikation des AC mit den angeschlossenen WTPs kann über das CAPWAP (Control and Provisioning of Wireless Access Points) Protokoll [15], [16] erfolgen, welches seit einiger Zeit von einer Arbeitsgruppe innerhalb der IETF (Internet Engineering Task Force) entwickelt wird. Das Protokoll wurde im Rahmen des Projekts prototypisch auf dem eingesetzten Evaluierungssystem implementiert und wird in Kapitel 4.2 genauer beschrieben. 3.5 IEEE WLAN Handover WLAN Infrastrukturen, die sehr großflächige Bereiche abdecken müssen, werden häufig in zellularen Strukturen realisiert. Für mobile Knoten ist es daher zwingend erforderlich, Zellwechsel durchzuführen, um eine weitere Datenübertragung gewährleisten zu können. Während des Zellwechsels kommt es jedoch zu einem Verbindungsabbruch, der so kurz wie möglich sein sollte, damit eine vorgegebene Dienstgüte garantiert werden kann. 17

28 3 Stand der Technik Phasen des WLAN Handover Der gesamte Vorgang eines Zellwechsels kann in vier verschiedene Phasen unterteilt werden, die Suchphase, die offene Authentifizierungsphase, die Assoziierungsphase und die abschließende sichere Authentifizierung. Die Berechnung der Zeitdauer des gesamten Handovers t HO erfolgt mit Gl In Abbildung 3.7 sind diese Phasen zusammen mit ihrer zeitlichen Größenordnung dargestellt. t HO = t Search + t Auth + t Asso + t SecAuth (3.1) Die Feststellung des Verbindungsabbruchs bzw. einer sehr schlechten Qualität der Verbindung wird durch den Client durch Verwendung verschiedener Indikatoren detektiert, am häufigsten auf Basis des Received Signal Strength Indicator (RSSI), der ein Maß für die Signalstärke ist. Im Anschluss wird der Zellwechsel gestartet und die Suchphase beginnt, in der alternative, verfügbare Access Points (APs) gesucht werden. Da die Entscheidung einen Zellwechsel durchzuführen durch verschiedene Mechanismen getroffen werden kann und außerdem während dieser ersten Phase bis zu 13 Kanäle nach APs durchsucht werden müssen, nimmt das Standardverfahren sehr viel Zeit in Anspruch und bietet entsprechendes Optimierungspotenzial. Abbildung 3.7: Verschiedene Phasen des WLAN Handover Wird ein neuer AP gefunden, startet die offene Authentifizierung, in der sich der Client gegenüber dem AP durch das Senden eines Authentication Requests und den Empfang einer Authentication Response authentifiziert. Die Anmeldung des Clients 18

29 3.5 IEEE WLAN Handover erfolgt im Anschluss während der Assoziierungsphase (Association Request / Association Response). Diese beiden Phasen können nicht verkürzt werden, beanspruchen aber nur einen sehr geringen Anteil der gesamten Handover-Zeit. Abschließend erfolgen die sichere Authentifizierung und die Aushandlung der Schlüssel nach der Erweiterung IEEE i [14]. Bei der sicheren Authentifizierung authentifiziert sich der Client gegenüber einem Authentifizierungsserver (z. B. Radius) gemäß IE- EE 802.1x [17]. Der komplette Ablauf besteht aus der eigentlichen Authentifizierung, durch die ein gemeinsamer Pairwise Master Key (PMK) für den Client und den AP erzeugt wird und einem anschließenden 4-Wege-Handshake. Während des 4-Wege- Handshakes werden aus dem PMK mehrere transiente Schlüssel erzeugt, die für die Verschlüsselung des Datenverkehrs verwendet werden. Auch hier können Optimierungen zu einer Verkürzung der Gesamtzeit führen. 3 t Search t Auth 2.5 t Asso t SecAuth Handover Zeit > t HO (s) Handovervorgang Abbildung 3.8: Ergebnisse des WLAN Standard Handover Exemplarisch werden in Abbildung 3.8 Ergebnisse des Standard Handover dargestellt. Das Testszenario bestand aus industriellen APs und Clients, die keine Optimierungen des Handovers verwenden. Es ergeben sich Gesamtzeiten von durchschnittlich 2,4 s. Es ist ersichtlich, dass die Suchphase zu Beginn und die abschließende sichere Authentifizierung den größten Anteil der Gesamtzeit in Anspruch nehmen. Weitere detaillierte Untersuchungen und Ergebnisse zum Stand der Technik in Bezug auf das Handover in industriellen WLAN Netzwerken werden in [18] und [19] beschrieben. 19

30 3 Stand der Technik Optimierungen des Handover Aus den Betrachtungen in Kapitel ist ersichtlich, dass das Handover in WLAN Netzwerken durch verschiedene Änderungen optimiert werden kann. Die Änderungen können entweder auf der Infrastruktur-Seite oder auf der Client-Seite vorgenommen werden. Infrastruktur Infrastrukturseitig ist dies im Wesentlichen die Verkürzung der sicheren Authentifizierung, welche z. B. durch eine Zwischenspeicherung der Pairwise Master Keys (PMKs) erreicht werden kann, sodass eine erneute 802.1x-Authentifizierung entfällt. Die in diesem Kapitel kurz beschriebenen Mechanismen werden ausführlich in [20] erläutert. PMK Caching Beim PMK Caching werden die während einer 802.1x Authentifizierung ausgehandelten PMKs im AP und im Client zwischengespeichert [14], [21]. Wenn der Client nun erneut zu einem AP wechselt, zu dem er bereits verbunden war, kann der zwischengespeicherte PMK direkt zur Ableitung der transienten Schlüssel während des 4-Wege-Handshakes verwendet werden und die zeitaufwendige 802.1x Authentifizierung entfällt. Pre-Authentication Das Pre-Authentication Verfahren wird genutzt, um einen mobilen Client vorab am neuen AP zu authentifizieren, während er noch mit dem alten AP assoziiert ist [22]. Hierzu sendet der Client über die bestehende Verbindung und die Infrastruktur die notwendigen Authentifizierungsnachrichten. Nach erfolgreicher Authentifizierung werden die PMKs auf beiden Seiten zwischengespeichert. Sobald das Handover zu dem neuen AP erfolgt, ist lediglich eine Re-Assoziierung und ein erneuter 4-Wege-Handshake erforderlich. Client Clientseitig bietet die Suchphase das größte Optimierungspotenzial. Die Dauer der Suchphase ist im Wesentlichen abhängig davon, ob eine passive oder eine aktive Suche verwendet wird. Das passive scanning ist langsamer, weil die einzelnen Kanäle lediglich passiv abgehört werden. Die Handover Zeit ist somit eine Funktion des Beacon Intervalls und der verfügbaren Kanäle [23]. Beim active scanning werden auf jedem der n verfügbaren Kanäle aktiv Probe Request Frames gesendet und auf ein Probe Response Frame gewartet. Die Wartedauer auf jedem Kanal ist durch die beiden Konstanten MinChannelTime und MaxChannelTime begrenzt, sodass die entstehende Verzögerungszeit T Search gemäß Gl. 3.2 ausgedrückt werden kann. 20

31 3.5 IEEE WLAN Handover n MinChannelT ime T Search n MaxChannelT ime (3.2) Im Folgenden wird näher auf mögliche Änderungen und Mechanismen eingegangen, die zu einer signifikanten Verkürzung dieser ersten Phase des Handovers führen. Die clientseitigen Mechanismen zur Optimierung werden außerdem in [24], [25] beschrieben. Selektives Scannning Das selektive Scanning wird in [26] beschrieben. Es verwendet Nachbarschaftsinformationen zur Reduzierung der Suchphase. Das Verfahren basiert auf einem Nachbarschaftgraph, dessen Knoten die APs und deren Kanal repräsentieren. Die Kanten des Graphen sind die vorhandenen Nachbarschaften, die zur Auswahl der relevanten Kanäle dienen. Dieser Ansatz kann die Suchphase erheblich reduzieren, wenn sich nur wenige APs in der direkten Nachbarschaft befinden. Es bietet jedoch nur eine geringe Verbesserung, wenn eine hohe Dichte von potenziellen APs besteht, da in diesem Fall die Anzahl der zu untersuchenden Kanäle immer noch relativ hoch ist. SyncScan Der SyncScan Ansatz wird in [27] vorgestellt. Es handelt sich dabei um einen Mechanismus der eine kontinuierliche Überwachung der umliegenden, erreichbaren APs vornimmt. Hierzu ist, im Gegensatz zu ähnlichen Mechanismen, nur eine sehr kurze Zeitdauer erforderlich. Es ist jedoch notwendig, dass alle APs zeitsynchron arbeiten und ihre Beacon Frames zu entsprechend geplanten Zeitpunkten versenden. Auf diese Weise wird sichergestellt, dass der Client in einem sehr kurzen Zeitintervall alle relevanten Informationen über benachbarte APs empfangen kann. Die Synchronisation zwischen den APs muss hierfür allerdings sehr genau sein. Außerdem können unerwünschte Kollisionen auftreten, wenn Beacon Frames auf einem identischen Kanal versendet werden. Make before break In [28] wirddermake-before-break Algorithmus vorgestellt. Die Autoren stellen zwei verschiedene Methoden zur Verkürzung des Handovers vor. Die erste Methode verwendet ein regelmäßiges Scanning der übrigen Kanäle im Hintergrund, was allerdings eine erhöhte Framefehlerrate und einen erhöhten Jitter zur Folge hat. Bei der zweiten Variante ist eine weitere WLAN Karte notwendig. Diese wird ausschließlich verwendet, um im Hintergrund nach weiteren APs zu suchen, während die erste WLAN Karte weiterhin zur Kommunikation eingesetzt wird. Bei dieser Methodik ist allerdings nachteilig, dass eine Anpassung der Hardware erforderlich ist, weil mindestens eine weitere WLAN Karte benötigt wird. DeuceScan Der DeuceScan Algorithmus [29] reduziert den Suchvorgang durch Verwendung eines räumlich-zeitlichen Graphen. Er basiert, ähnlich wie der SyncScan 21

32 3 Stand der Technik Mechanismus, auf einem Vorabscan, der aber nur partiell durchgeführt wird. Daher ist er im Vergleich zu SyncScan effektiver und erzielt bessere Ergebnisse bei hohen Geschwindigkeiten des mobilen Clients. Auch bei DeuceScan ist es erforderlich, dass alle APs zeitsynchronisiert sind und ihre Beacon Frames zu entsprechend geplanten Zeitpunkten versenden. Viele der hier genannten Verfahren haben jedoch den wesentlichen Nachteil, dass sie entweder zeitsynchronisierte Geräte oder eine spezielle Hardware (z. B. zwei WLAN Interfaces) erfordern. Eine Integration in ein bestehendes System, z. B. durch eine einfache Firmware Aktualisierung, ist daher nicht ohne zusätzlichen weiteren Aufwand möglich. 3.6 Technischer Fortschritt bei anderen Stellen Während der Projektlaufzeit sind keine weiteren Arbeiten bekannt geworden, die den gleichen Fokus wie das Projekt RAvE hatten. 22