TCP/IP über IEEE 802.15.4 Prof. Alexander Klapproth, Thomas Bürkli CEESAR, the Center of Excellence for Embedded Systems Applied Research Hochschule für Technik und Architektur Luzern CH-6048 Horw 1. Einführung TCP/IP basierte Netzwerke sind heute fester Bestandteil von IT-Infrastrukturen und nicht mehr aus unserem Leben wegzudenken. Neben den etablierten Bereichen wie Firmen- und Heimvernetzung, hat die IP-basierte Kommunikation auch in Gebieten Einzug gehalten, wo früher proprietäre Transportprotokolle zum Einsatz kamen, wie z.b. in der Gebäuteautomation. Der aktuelle Trend in der Vernetzung geht weg von Verkabelungen hin zu Wireless-Lösungen. Täglich kommen wir mit solchen Geräten und Anwendungen in Kontakt. Begriffe wie GSM, GPRS, Bluetooth, WLAN, sind allgegenwärtig. Batteriebetriebene Funkknoten erlauben einen kabellosen und mobilen Einsatz, was Installationskosten vermindert. Zurzeit existiert eine Vielzahl von Funkstandards und Funkprotokollen, welche die unterschiedlichsten Anwendungsgebiete abdecken. Auch dank dieser Vielfalt konnte die Funktechnik während den letzten Jahren stetig neue Gebiete erschliessen und sich bei einem breiten Publikum etablieren. Die fortschreitende Standardisierung erreichte mit IEEE 802.15.4 den Low-Rate und Low-Cost Bereich. Die Vernetzung von kleinsten Geräten wie z.b. Haushaltsgeräten, Sensoren, Schalter, Lampen oder Spielzeugen kann mittels dieser Technologie kostengünstig realisiert werden. Der IEEE 802.15.4 Standard ist u.a. die Basis für den ZigBee-Protokollstack. Dieses Paper befasst sich mit dem 802.15.4 Standard und zeigt auf, dass alternativ zum ZigBee-Stack auch der TCP/IP- Protokollstack eingesetzt werden kann. Dies erlaubt die einfache Integration von IEEE 802.15.4 basierten Geräten in eine bestehende IT-Infrastruktur über ein kostengünstiges Ethernet-Funk Gateway.
Abbildung 1: Direkte TCP/IP Kommunikation mit Wireless-Sensoren über ein Ethernet-Funk Gateway 2. IEEE 802.15.4 Der IEEE 802.15.4 Standard [1] ist für Low-Rate Wireless Personal Area Netzwerke (WPAN) konzipiert worden und definiert lediglich die Layer 1 (Physical Layer, PHY) und Layer 2 (Media Access Control Layer, MAC) des OSI Referenzmodells. Die Definition der höheren Schichten bleibt damit offen. Eigenschaften von 802.15.4 Netzwerken sind: maximale Paketgrösse von 127 Bytes Unterstützung von kurzen 16-bit oder IEEE 64-bit Extended MAC Adressen Frequenzen: 2.4 GHz, 915 und 868 MHz Bandbreiten: 250 kb/s, 40 kb/s und 20 kb/s Stern, Baum oder Mesh-Topologie Low-Power, gute Eignung für batteriebetriebene Endknoten Low-Cost, (Low processing, Low Memory, geeignet für 8-Bit Controller, etc.) Sehr grosse Anzahl von Geräten in einem Funknetz Schneller Verbindungsauf- und Abbau Geeignet für Ad hoc Vernetzungen Erhöhte Störanfälligkeit wegen Frequenzüberlappung mit andern Wireless Standards im ISM- Band
Physical Layer (PHY) Die physikalische Schnittstelle von IEEE 802.15.4 bietet in drei verschiedenen Frequenzbändern insgesamt 27 Kanäle. Frequenz (Mhz) Frequenzband (Mhz) Kanäle Datenrate Verfügbarkeit 868 868-868.6 1 20 kb/s Europa/Asien 915 902-928 10 40 kb/s Amerika 2400 2400-2483.5 16 250 kb/s weltweit Tabelle 1: IEEE 802.15.4 Frequenzbänder Wie aus der obigen Tabelle zu entnehmen ist, liegen die verwendeten Frequenzen alle im lizenzfreien ISM (Industrial, Scientific and Medical) Band. Da eine Vielzahl anderer Wireless Anwendungen (Wi- Fi / IEEE 802.11b/g/a, WirelessUSB, Bluetooth, Funk-Kopfhörer, Funk-Garagenöffner, etc.) diese Frequenzbänder ebenfalls benutzt, existiert ein erhöhtes Stürpotenzial. In [2] wird diese Problematik näher erläutert. Aus diesem Bericht ist auch zu entnehmen, dass mittels Feldtest aufgezeigt werden konnte, dass in 802.15.4 Netzwerken bei Überlappung mit einem stark genutzten Wi-Fi Channel bis zu 20% der Pakete aufgrund von Kollisionen neu übermittelt werden mussten. Bei der Auslegung von Wireless Anwendungen kann man dieser Problematik Rechnung tragen, z.b. durch dynamische Auswertung der Kanalqualität, situative Kanalwahl und adaptives Tuning der optimalen Sendefeldstärke. Der Physical Layer ist für folgende Aufgaben verantwortlich: Activation and deactivation of the radio transceiver Energy Detection within the current channel Link Quality Indication for received packets Clear channel assessment for CSMA-CA (carrier sense multiple access with collision avoidance) Channel frequency selection Data transmission and reception Medium Access Control (MAC) Die Hauptaufgabe des MAC-Layers ist es, eine zuverlässige Verbindung zwischen MAC Entitäten verschiedener Geräte aufzubauen und aufrecht zu erhalten. Für die Datenübertragung gibt es vier verschiedene Frametypen: Beacon Data Acknowledgment MAC command Der MAC-Layer handelt die Zugriffe auf den physical Layer und ist für folgende Aufgaben verantwortlich: Generating network beacons if the device is a coordinator Synchronizing to the beacons Supporting PAN association and disassociation Supporting device security Employing the CSMA-CA mechanism for channel access Handling and maintaining the GTS mechanism Providing a reliable link between two peer MAC entities
3. IP über IEEE 802.15.4 Nebst der Möglichkeit, proprietäre Protokolle auf den höheren Schichten einzusetzen, bieten sich im Wesentlichen zwei Optionen: ZigBee und TCP/IP. Diese zwei Protokollstacks unterscheiden sich aber wesentlich, sowohl in der Anwendung als auch in Funktionalität und Integrationsfähigkeit. ZigBee ist auf effizienten und energiesparenden Betrieb ausgelegt und berücksichtigt die Schlankheit von IEEE 802.15.4 optimal. TCP/IP wird weltweit in IT-Systemen eingesetzt und gilt als Standard-Kommunikationsprotokoll in Firmen- und Heimnetzwerken. Die Kommunikation über TCP/IP findet auch immer mehr Einzug in die Embedded Welt, beispielsweise in der Gebäudeautomatisierung. Jedoch hat man bei der Entwicklung von IPv4 für Forschungs- und Militär-Netze nicht daran gedacht, dass das Internet die heutige Grösse annehmen würde. Heute treten durch die Struktur von IPv4 einige Probleme auf wie z.b. ungenutzte Adressen wegen fixen Netzklassen oder der hohe Konfigurationsaufwand (IP-Adresse, Subnetmaske, Default Gateway). Zudem macht der Protokolloverhead von IPv4 bei geringer Nutzdatenmenge einen erheblichen Anteil des gesamten Datenverkehrs aus. Zukunftsweisend könnte sich hier der Einsatz von IPv6 erweisen. IPv6 verwendet 128-bit Adressen und ist für grosse Netzwerke konzipiert worden. Zudem beinhaltet es z.b. Headerkompression, was den Einsatz auf ressourcenarmen Systemen erleichtert und die Übertragungspaketlänge verringert. Es gibt einige Aspekte, welche für den Einsatz von IP als Kommunikationsprotokoll in 802.15.4 Netzwerken sprechen: Bestehende IT-Infrastrukturen mit IP-Netzen können genutzt werden IP basierte Technologie ist sehr verbreitet, ausgereift und erprobt IP Technologie ist besser bekannt als neuere oder proprietäre Lösungen Tools für Diagnose, Management und Inbetriebnahme von IP-Netzwerken existieren bereits Keine Protokollumwandlung erforderlich (z.b. ZigBee TCP/IP) Die nachfolgenden Kapitel erläutern die Realisierung der IPv4 Kommunikation in 802.15.4 Netzwerken. 3.1. Grundlagen IETF Working Group: IPv6 over Low power WPAN (6lowpan) [7] Seit einiger Zeit befasst sich eine Working Group der Internet Engineering Task Force (IETF) mit der Spezifikation von IPv6 über IEEE 802.15.4 Netzwerken. Die Arbeitsgruppe trägt den Namen IPv6 over Low power WPAN (6lowpan) und hat bereits zwei Internet Drafts herausgegeben: 6LoWPAN: Overview, Assumptions, Problem Statement and Goals [3] Transmission of IPv6 Packets over IEEE 802.15.4 Networks [4] Unsere Realisierung der IPv4 Kommunikation über den IEEE 802.15.4 Standard basiert auf diesen Draft-Dokumenten.
3.2. Realisierung Die nachfolgenden Kapitel beschreiben die Realisierung von IPv4 über IEEE 802.15.4. Als Grundlage wurden die oben genannten Internet Drafts verwendet und auf IPv4 adaptiert. Die nachfolgende Beschreibung der Realisierung nimmt aber auch immer wieder Bezug auf die Möglichkeiten beim Einsatz von IPv6. 3.2.1. Übertragungsmode Der IEEE 802.15.4 Standard definiert vier verschiedene Frametypen auf der MAC-Ebene: Beacon Data Acknowledgment MAC Command Die IP-Pakete müssen zwingend in Datenframes übermittelt werden. Bei diesem Typ von Frames besteht die Möglichkeit, für jedes versendete Paket eine Bestätigung (Acknowledge) anzufordern. Dadurch kann eine zuverlässige Übertragung von Datenpaketen bereits auf MAC-Ebene garantiert werden. Von dieser Funktionalität wird deshalb auch bei der IPv4-Kommunikation über IEEE 802.15.4 Gebrauch gemacht. 3.2.2. Fragmentierung Die Paketgrösse ist in 802.15.4 Netzwerken auf 127 Bytes beschränkt. Aufgrund der maximalen Grösse des MAC-Headers von 25 Bytes, bleiben noch 102 Bytes für weitere Daten zur Verfügung. Durch die Verwendung von IPv4 und TCP bleiben schliesslich noch 62 Byte für höhere Protokolle und Applikationsdaten. Grösse [bytes] Maximum physical layer packet size 127 Maximum IEEE 802.15.4 Frame overhead - 25 IPv4 Header - 20 TCP Header - 20 Höhere Protokolle, Applikationsdaten 62 Die restlichen 62 Bytes reichen nur für Anwendungen mit geringen Datenvolumen aus. Grössere Datenpakete müssen fragmentiert werden können. Im Zusammenhang mit Fragmentierung bieten sich auf den ersten Blick folgende Möglichkeiten an: Verwendung der IPv4 Fragmentierung Definition eines neuen Layers für die Fragmentierung
Das IPv4 Protokoll bietet seine eigene Fragmentierungsfunktionalität an. Jedoch unterstützen nicht alle IPv4-Implementationen diese Möglichkeit. Dies trifft häufig auf Embedded Systemen zu: Das Weglassen dieser Funktionalität erlaubt eine einfachere und ressourcensparende IPv4-Implementation. Aus diesem Grund scheint es uns nicht sinnvoll, die IPv4-Fragmentierung zu verwenden. Die Fragmentierung auf IP-Ebene käme auch bei IPv6 nicht in Frage. In der IPv6 Spezifikation [5] ist im Kapitel 5 definiert: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Dies triftt in unserem Fall zu, da die maximale Paketgrösse in 802.15.4 Netzen 127 Byte beträgt. Daraus folgt, dass nur eine Fragmentierung über einen zusätzlichen Layer realisiert werden kann. In [4] ist ein solcher Layer definiert. Dieser wird nachfolgend beschrieben. 3.2.3. Adaption Layer und Frame Format Der Adaption Layer definiert drei unterschiedliche Encapsulation Headers (Abbildung 2): 1. Header für unfragmentierte Pakete 2. Header für den ersten Teil eines fragmentierten Paketes 3. Header für die nachfolgenden Teile eines fragmentieten Paketes Abbildung 2: LoWPAN Encapsulation header formats
Beschreibung der einzelnen Headerfelder: LF Das Linkfragment Bitmuster spezifiziert den Typ des Fragmentes. LF Position 00 Unfragmented 01 First Fragment 10 Last Fragment 11 Interior Fragment proto_type M datagram_size datagram_tag datagram_offset Payload Das Internet Draft [4] kreierte eine neue IANA Registry für dieses proto_type (Protocol Type) Feld. Zwei Werte sind bereits definiert: 0x01: IPv6 0x02: IPv6 mit LOWPAN_HC1 Headerkompression Für IPv4 haben wir einen neuen Wert definiert: 0x03: IPv4 M=1 signalisiert, dass dem Encapsulation Header ein Mesh Delivery Header folgt. Ein solcher ist für IPv6 in Internet Draft [4] beschreiben, wird aber in unserem Fall nicht verwendet (M=0). Grösse des unfragmentierten Datenpaketes Der Wert dieses Feldes ist für alle Fragmente eines Datenpaketes (z.b. IPv4-Paket) gleich. Der Sender soll diesen Wert für jedes neue Datenpaket inkrementieren (0-1023). Offset des aktuellen Fragments im unfragmentierten Datenpaket, inkrementiert in 8 Byte Blöcken. Wert Offset 1 8 Bytes 2 16 Bytes 255 2040 Bytes Fragment eines Datenpakets
3.2.4. Address Mapping MAC-IP Um IP Pakete in einem Netzwerk verschicken zu können, muss die IP Adresse auf eine MAC Adresse abgebildet werden. Dies geschieht in einem Ethernet mittels des Adress Resolution-Protokolls (ARP). Für das Mapping von IPv6 Unicast Adressen in IEEE 802.15.4 Link Layer Adressen gibt es bereits ein definiertes Vorgehen [6]. Für IPv4 gibt es kein spezifiziertes Vorgehen. Nachfolgend werden zwei mögliche Mapping- Verfahren beschrieben. Beide Arten verwenden die kurzen 16-bit Link Layer Adressen. Statisches Mapping Die IP-Adressen werden gemäss Abbildung 3 auf die 802.15.4 MAC-Adressen abgebildet: Abbildung 3: Statisches Mapping von IP auf MAC Adressen
Mapping mit dem Address Resolution Protocol Address Resolution Protocol (ARP) ist ein spezifiziertes Verfahren um in Netzwerken Protokoll Adressen (z.b. IP) auf Hardware Interface Adressen (z.b. Ethernet) abzubilden. Der ARP-Header ist in Abbildung 4 dargestellt: Abbildung 4: ARP Header Die Länge einiger Felder des ARP-Headers sind variabel und werden durch zwei weitere Protokollfelder definiert: Hardware address length und Protocol address length. Die nachfolgende Tabelle zeigt die Werte für Hardware address length für ein Ethernet und ein 802.15.4 Netzwerk mit kurzen oder erweiterten MAC-Adressen. ARP Header Field Ethernet-MAC 802.15.4 short addresses 802.15.4 extended addresses Hardware address length 6 2 8 Die Protocol address length ist für IPv4 unabhängig vom verwendeten Netzwerk 4 Bytes. Mit diesen Anpassungen kann das ARP-Protokoll innerhalb eines 802.15.4 Netzwerkes verwendet werden, um die IP-Adressen auf die entsprechenden MAC-Adressen aufzulösen.
4. Geräte Funktionalität Dieses Kapitel beschreibt den Funktionsumfang der bereits realisierten Geräte. Gateway von Ethernet auf IEEE 802.15.4 Das Gateway ist für die Umwandlung von Ethernet auf IEEE 802.15.4 und umgekehrt verantwortlich. Abbildung 5: Ethernet - 802.15.4 Gateway Wie im obigen Blockdiagramm zu sehen ist, besitzt das Gateway zwei verschiedene ARP-Tables. Die eine für die Umwandlung von IP auf Ethernet MAC-Adressen, die andere für die Umwandlung von IP auf 802.15.4 MAC-Adressen. Hardware: Ethernet Controller: Crystal CS8900A RF Transeiver: Chipcon CC2420 [8] Wireless Sensor Module Das Wireless Sensor Module basiert auf dem Zebra2411 Modul von sentec Elektronik GmbH [9]. Abbildung 6: IP fähiges Wireless Sensor Module Das Einsatzgebiet eines solchen Knotens ist sehr universell und reicht vom einfachen Temperatursensor bis hin zu einem Webserver. Am CEESAR der HTA Luzern wurden u.a. eine Java Virtual Machine, eine Webservice Plattform und ein UPnP-Stack für dieses Modul entwickelt.
5. Fazit Es hat sich gezeigt, dass IPv4 als Kommunikationsprotokoll in 802.15.4 Netzen eingesetzt werden kann. Die Integration von Funkknoten in bestehende IT-Infrastrukturen lässt sich mit einem kostengünstigen und einfachen Ethernet-Funk Gateway realisieren. Dabei müssen keine aufwändigen Protokollumwandlungen durchgeführt werden. Beim Einsatz von IPv4 ist jedoch einiges an Konfigurationsarbeit erforderlich, damit die Netze funktionieren, was für. Ad-hoc Vernetzung ungünstig ist. Eine IETF Working Group [10] befasst sich mit dieser Problematik mit dem Ziel, neue Mechanismen innerhalt von IP-Netzwerken zu definieren, um eine automatische Konfiguration zu ermöglichen. Unsere aktuelle Implementation von IPv4 über IEEE 802.15.4 erlaubt nur eine Peer-To-Peer Kommunikation. Die Mesh-Routing Fähigkeit ist aber denkbar und kann auf speziellen Routingknoten realisiert werden. Im Bezug auf Energieeffizienz ist die Verwendung des TCP/IP-Protokolles sicherlich nicht optimal. Das Protokoll ist für festverkabelte Netzwerke ausgelegt, d.h. es sind a priori keine Energiesparmechanismen definiert. Eine solche Funktionalität muss selber auf Applikationsebene realisiert werden, beispielsweise durch Definition von Duty-Cycles für die Aktivierung des Transceivers. Der Header Overhead ist bei IPv4 für kleine Pakete gross. Dies erfordert längere Sendezeiten, was die Anfälligkeit für Übertragungsfehler erhöht. Welcher Protokollstack sich für IEEE 802.15.4 Netzwerke durchsetzen wird, ist zurzeit offen. Es macht aber Sinn, nebst ZigBee auch alternative Standards in Betracht zu ziehen.
Autoren Prof. Alexander Klapproth Leiter CEESAR Hochschule für Technik+Architektur Luzern, Schweiz Mail: ceesar@hta.fhz.ch Web: www.ceesar.ch Thomas Bürkli Wissenschaftlicher Mitarbeiter CEESAR Hochschule für Technik und Architektur Luzern, Schweiz Mail: tbuerkli@hta.fhz.ch Web: www.ceesar.ch Referenzen [1] IEEE Standard 802.15.4. October 2003 [2] R. Winfield and M. Gerrior. Avoiding Interference in the 2.4 GHz ISM Band. www.wirelessnetdesignline.com/howto/60401206 [3] N. Kushalnagar and G. Montenegro. 6LoWPAN: Overview, Assumptions, Problem Statement and Goals. Internet-Draft: draft-ietf-6lowpan-problem-02.txt. February 2006. [4] G. Montenegro and N. Kushalnagar. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. Internet-Draft: draft-ietf-6lowpan-format-01.txt. October 2005. [5] Internet Protocol, Version 6 (IPv6) Specification, RFC 2460 December 1998 [6] T. Nartan et al. Neighbor Discovery for IP version 6 (IPv6) Internet Draft: draft-ietf-ipv6-2461bis-05.txt October 2005 [7] IETF Working Group, IPv6 over Low power WPAN (6lowpan) http://www.ietf.org/html.charters/6lowpan-charter.html [8] Chipcon CC2420 RF Transeiver, Chipcon AS, www.chipcon.com [9] ZEBRA2411, sentec Elektronik GmbH, www.sentec-elektronik.de [10] IETF Workging Group, Zero Configuration Netzworking (Zeroconf), www.zeroconf.org