Bluetoothbasiertes Informationssystem - Konzeption und Realisation eines Prototypen für einen Stadtinformationsdienst

Inhaltsverzeichnis

1 Einleitung
1.1 Mobile Endgeräte
1.2 Übertragungstechnologien
1.3 Abgrenzung des Themas

2 Bluetooth
2.1 Technik
2.2 Bluetooth-Protokoll-Stack
2.2.1 Bluetooth Radio
2.2.2 Baseband
2.2.3 Der Link Manager
2.2.4 Host Controller Interface (HCI)
2.2.5 Logical Link Control and Adaption Protocol (L2CAP)
2.2.6 Service Discovery Protocol (SDP)
2.2.7 RFCOMM (Radio Frequency Oriented Emulation of the Serial COM Ports)
2.3 Bluetooth-Profile

3 Symbian OS
3.1 Einführung
3.2 System-Architektur
3.2.1 Hardware
3.2.2 Software-Architektur
3.3 System-Grundlagen
3.3.1 Komponenten und Grenzen
3.3.2 Der Kernel
3.3.3 Prozesse und Threads in Symbian OS
3.3.4 Server und Clients
3.3.5 Speicher
3.4 Programmierung unter Symbian OS
3.4.1 Event Handling und Active Objects
3.4.2 Error Handling und Cleanup
3.4.3 Strings und Deskriptoren
3.4.4 Ausführbare Programme in Symbian OS
3.4.5 Das Application Framework
3.4.6 Ressourcen-Dateien
3.4.7 Namenskonventionen
3.5 Symbian OS und Bluetooth
3.6 Programmierumgebung

- 4 HyNetOS
4.1 Einführung
4.2 System-Architektur
4.2.1 Hardware
4.2.2 Software-Architektur
4.3 System-Grundlagen
4.3.1 Der Kernel
4.3.2 Tasks und Task-Synchronisation
4.3.3 Intertask-Kommunikation mit Messages
4.3.4 Speicher und Dateisystem
4.4 Programmierung unter HyNetOS
4.5 HyNetOS und Bluetooth
4.6 Programmierumgebung

5 Stadtinfo-Projekt: Analyse und Konzeption
5.1 Idee und Anforderungen
5.2 Konzeption
5.2.1 Gesamtarchitektur
5.2.2 Installation der Anwendung und Verbindungsaufbau
5.2.3 Prototyp und Finalversion
5.2.4 Ablauf des Informationsabrufs
5.2.5 Use Cases P800 / MBT
5.3 Projektablauf

6 Stadtinfo-Projekt: Umsetzung
6.1 Die Stadtinfo-Anwendung auf dem MBT
6.2 Die Stadtinfo-Anwendung auf dem P800
6.2.1 Bluetooth Engine
6.2.2 Protokollklasse
6.2.3 Main Controller
6.2.4 Audio Engine
6.2.5 Model Controller
6.2.6 XML-Parser
6.2.7 View Controller
6.2.8 Die einzelnen Views
6.3 Gesamtablauf eines Szenarios
6.4 Kommunikation der Komponenten
6.4.1 Das Stadtinfo-Protokoll
6.4.2 Die XML-Datei
6.5 Benutzerführung
6.6 Implementierung

7 Schlussbetrachtungen
7.1 Fazit
7.2 Erweiterungsmöglichkeiten des Prototypen
7.3 Visionen
7.4 Persönliches Fazit

8 Anhang
8.1 Klassendiagramm der Stadtinfo-Anwendung auf dem P800
8.2 Abkürzungsverzeichnis
8.3 Tabellenverzeichnis
8.4 Abbildungsverzeichnis
8.5 Bibliographie
8.6 CD

1 Einleitung

Sie sind überall - mobile Endgeräte, die uns den Alltag erleichtern. Fast ständig führen wir Laptops, PDAs und Mobiltelefone bei uns und nutzen sie zur Kommunikation und Datenverarbeitung.

Vor allem durch den Austausch von Informationen gewinnen diese mobilen Geräte an Bedeutung. Unterschiedliche Technologien zur Datenübertragung finden Verwendung und auch Sprache wird mittlerweile in Form von digitalen Datenpaketen übermittelt. Bald wird die Größe eines Gerätes nur noch durch die gewünschte Größe der Anzeige bestimmt sein, später werden die Informationen vielleicht sogar in den Raum projiziert oder auf andere Art dem Benutzer vermittelt.

Doch keines der Geräte wird in der Lage sein, alle gewünschten Informationen zu speichern, diese müssen auch von außen übermittelt werden können. Und um möglichst unabhängig zu sein geschieht dies drahtlos, ohne physikalische Verbindung zum bereitstellenden System.

Was versteht man unter mobilen Endgeräten und welche Übertragungsmöglichkeiten für den Informationsaustausch gibt es?

1.1 Mobile Endgeräte

„Mobil“ heißt „beweglich“. Mobilität ist daher vor allem eine Frage von Größe, Gewicht und Unabhängigkeit bezüglich Stromversorgung und Verbindungen.

Unter mobilen Endgeräten werden in dieser Diplomarbeit Geräte verstanden, die diesen Anforderungen gerecht werden: Sie sind portabel, besitzen eine eigene Hardware mit entsprechen-der Stromversorgung und geeignetem Betriebssystem und verfügen über die notwendigen Schnittstellen, um drahtlos kommunizieren zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Überblick Mobile Endgeräte

Um mobile Endgeräte für den Markt interessant zu machen, sollten diese programmierbar sein. So können auch komplexe Anwendungen von Drittanbietern entwickelt werden. Solche Anwendungen für mobile Geräte werden als „Mobile Applikationen“ bezeichnet. Soll die Anwendung auf mehreren Gerätearten eingesetzt werden, so muss sie auf das entsprechende Betriebssystem, sowie die Darstellungs- und Eingabemöglichkeiten des Zielgerätes angepasst werden. Immer wichtiger wird dabei die plattformunabhängige Programmiersprache Java. Unterschiedliche Java-Versionen wurden für die unterschiedlichen Einsatzgebiete entwickelt, für programmierbare Mobiltelefone z. B. J2ME (Java 2 Micro Edition). Auf Java-Programmierung soll in dieser Diplomarbeit jedoch nicht weiter eingegangen werden, da der Prototyp aufgrund der derzeitigen technischen Voraussetzungen nicht in Java realisiert wurde.

Programmierbare mobile Endgeräte

Die drei wichtigsten programmierbaren mobilen Endgeräte sind Laptops, PDAs/MDAs und Smartphones (s. Abbildung 1-1). Eher exotische Vertreter wie Tablet-PCs oder SimPads spielen für den Massenmarkt keine große Rolle und sollen daher hier nicht weiter betrachtet werden.

Laptops sind sehr leistungsfähig und haben ein großes Display, sind aber auch recht teuer. Für einen bluetoothbasierten Informationsdienst erscheinen sie gut geeignet, haben jedoch den großen Nachteil, dass sie aufgrund ihrer Größe und des Strombedarfs nur bedingt portabel sind.

PDAs/MDAs sind wesentlich kleiner und dank eines ansprechend großen Displays auch gut in einem Informationssystem einsetzbar. Gegen sie spricht die eher geringe Verbreitung im Consumer-Bereich.

Smartphones sind klein und portabel. Sie verfügen über ein leistungsfähiges Betriebssystem und ein ansprechend großes Display. Smartphones sind momentan noch nicht allzu sehr verbreitet. Aufgrund der Nähe zum Standard-Mobiltelefon ist jedoch zu erwarten, dass sie sich in den nächsten Jahren als Massenmarktprodukt durchsetzen werden.

1.2 Übertragungstechnologien

Informationsaustausch wird immer wichtiger und gerade für mobile Endgeräte ist es entscheidend, dass dieser drahtlos geschehen kann. In diesem Abschnitt soll daher auf die wichtigsten drahtlosen Übertragungstechnologien eingegangen werden, die bei der Programmierung von mobilen Applikationen eingesetzt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-2: Überblick drahtlose Übertragungstechnologien

Grundsätzlich bieten sich zur drahtlosen Kommunikation zwei Möglichkeiten an:

Die Kommunikation per Infrarot oder per Funk.

IR (Infrarot)

Bei Infrarot werden Daten optisch übertragen. Die Wellenlängen sind hierbei länger als die für das menschliche Auge sichtbare und kürzer als Funkwellenlängen.^[1] Sender und Empfänger müssen bei Infrarot-Übertragungen Sichtkontakt haben, was den großen Nachteil dieser Technologie darstellt und den Einsatz in vielen Bereichen uninteressant macht.

Infrarot ist dennoch sehr verbreitet und findet vor allem bei Fernbedienungen Anwendung. Aber auch Laptops und Mobiltelefone sind oft mit Infrarot ausgerüstet und können so beispielsweise ihre Daten synchronisieren. Infrarot ist günstig in Herstellung und Stromverbrauch, hat aber auch nur eine recht geringe Reichweite von etwa 5 Metern.

Funk

DECT (Digital European Cordless Telecommunication)

DECT ist ein etablierter Standard für digitale Funkübertragung und wird hauptsächlich bei Schnurlostelefonen eingesetzt. DECT arbeitet in einem reservierten Frequenzband und ermöglicht Reichweiten zwischen 50 Metern in Gebäuden und 300 Metern im Freien. Ein großer Vorteil von DECT besteht in seiner geringen Störanfälligkeit. Ein Nachteil ist jedoch, dass weltweit unterschiedliche Frequenzen verwendet werden.^[2]

GSM (Global System for Mobile Communication)

Das GSM-Netz unterstützt Sprach- und Datentransport. Hauptsächlich Mobiltelefone nutzen dieses weit verbreitete Netz der so genannten „Second Generation“ (2 G).^[3] Die so genannte CSD-Verbin-dung (Circuit Switched Data) ist leitungsorientiert und überträgt bis zu 9,6 kBit/s. Beim GSM-Netz können zur Erhöhung der Transferrate auch mehrere Kanäle gebündelt werden. Diese Technik nennt sich dann HSCSD oder „High Speed Circuit Switched Data“.^[4]

GPRS (General Packet Radio Service)

GPRS ist eine Verbesserung des GSM-Standards für Datenübertragungen und stellt eine Brückentechnologie dar für so genannte 2.5 G-Netzwerke. GPRS ist paketorientiert und unterstützt Konzepte wie virtuelle Verbindungen.^[5] Da GPRS vor allem nach Volumen und nicht nach Zeit berechnet wird, ist für den Nutzer auch eine ständige Verbindung zum Provider möglich, ohne die Kosten entscheidend zu erhöhen. GPRS kann bis zu 115 kBit Daten pro Sekunde übertragen und ist damit deutlich schneller als GSM.

UMTS (Universal Mobile Telecommunication System)

UMTS ist ein Mobilfunkstandard der dritten Generation (3 G) und bietet vor allem höhere Transferraten von bis zu 2 MBit/s. Derzeit wird UMTS aufgrund der hohen Kosten noch selten eingesetzt. Außerdem gibt es nur sehr wenige Endgeräte, die UMTS unterstützen und der Dienst ist bei weitem nicht flächendeckend verfügbar.

WLAN (Wireless Local Area Network)

WLAN definiert mehrere Versionen des bekannten Funkstandards IEEE 802.11. Fast alle WLAN-Produkte arbeiten im Bereich von 2,4 GHz. Die Technologie wird hauptsächlich zur drahtlosen Vernetzung von Computern eingesetzt, wobei die Transferrate bei der schnellsten Version bis zu 54 MBit/s beträgt. Die Reichweite liegt zwischen 30 Metern in Gebäuden und etwa 300 Metern im Freien. In einer Richtfunkvariante können sogar bis zu 20 Kilometer im Freien erreicht werden.^[6]

Bluetooth

Bluetooth ist ein offener Funkstandard für Kurzstrecken, der wie auch WLAN im freien Frequenzband von 2,4 GHz arbeitet. Bluetooth unterstützt Sprach- und Datenübertragungen und kann sehr vielfältig eingesetzt werden. So kann beispielsweise ein Computer mit seinen Peripherie-Geräten oder ein Mobiltelefon mit seinem Headset drahtlos über Bluetooth verbunden werden. Die Transferrate bei asymmetrischen Verbindungen liegt bei bis zu 721 kBit/s und die Reichweite eines Gerätes kann bis zu 100 Meter erreichen.^[7] Auf Bluetooth wird in Kapitel 2 ausführlich eingegangen.

1.3 Abgrenzung des Themas

Diese Diplomarbeit beschreibt ein bluetoothbasiertes Informationssystem anhand eines Prototypen für einen Stadtinformationsdienst. Folgende Bereiche sind daher zu betrachten:

- Ein stationäres Gerät, das die Informationen bereitstellt.
- Ein mobiles Endgerät, das die Informationen abruft und darstellt.
- Die Verbindung der beiden Geräte über Bluetooth.

Stationäres Gerät

Als stationäres Gerät könnte im Grunde jeder PC dienen. Anforderungen an das stationäre Gerät beim Stadtinformationsdienst waren neben Unterstützung von Bluetooth jedoch vor allem eine einfache Programmierbarkeit und die einfache Installationsmöglichkeit am jeweiligen Standort. In dieser Diplomarbeit wird daher ein kleines, programmierbares Embedded Device beschrieben, das beim Prototypen eingesetzt wurde. Es unterstützt Bluetooth und hat ein eigenes Betriebssystem namens HyNetOS. Das eingesetzte Gerät ist weitaus kleiner als ein PC, was der Installation am Standort sehr entgegenkommt.

Mobiles Endgerät

Welche mobilen Endgeräte sich in der Zukunft durchsetzen werden, ist nicht mit Sicherheit vorherzusagen. Doch die Größe und damit die Portabilität wird ein entscheidender Faktor sein. Und unter den mobilen Endgeräten haben Mobiltelefone momentan die größte Verbreitung.^[8] Der zu entwickelnde Stadtinformationsdienst stellte einige Anforderungen an das eingesetzte Mobiltelefon. Wichtige Auswahlkriterien waren die Unterstützung von Bluetooth, umfangreiche Programmier-barkeit und Benutzerfreundlichkeit. Daher wurde ein Bluetooth-Smartphone mit dem leistungsfähigen Symbian-Betriebssystem verwendet. Das eingesetzte Gerät ist mit einem ansprechend großen Display ausgestattet und bietet umfangreiche Bedienmöglichkeiten.

Verbindung über Bluetooth

Als Technologie für die Verbindung der Geräte wird Bluetooth näher erläutert. Für die Entwicklung des Stadtinformationsdienstes war es wichtig, dass die Informationen problemlos an den jeweiligen Standorten lokal bereitgestellt werden können. Bluetooth kann im Kurzstreckenbereich unlizenziert eingesetzt werden und ist hinsichtlich der Reichweite von bis zu 100 m ebenfalls für einen solchen Dienst geeignet. Gegen den Einsatz von Infrarot sprach neben dessen ungenügender Reichweite auch die recht hohe Störanfälligkeit.

Ein weiteres Auswahlkriterium war die Kostenkontrolle für den Benutzer, wie sie beim Einsatz der Technologien aus dem Mobiltelefonbereich wie etwa GSM oder GPRS nicht gegeben gewesen wäre. Bluetooth ist weiterhin aufgrund seiner stromsparenden Eigenschaften im Gegensatz zu WLAN schon in vielen mobilen Endgeräten integriert.

Aufbau der Diplomarbeit

Bluetooth ist eine relativ neue Funktechnologie. Im folgenden Kapitel werden daher deren Grundlagen erläutert. Auch Symbian OS und HyNetOS sind recht neue und vor allem spezielle Betriebssysteme mit eigenen Konzepten. Um ein grundlegendes Verständnis zu ermöglichen, wird in den Kapiteln drei und vier auf diese beiden Betriebssysteme eingegangen.

Den Hauptteil der Diplomarbeit stellt der praktische Teil dar, in dem ein Prototyp für einen bluetoothbasierten Stadtinformationsdienst entwickelt und realisiert wurde. Dieses Projekt, das für die Firma Alcatel SEL AG in Stuttgart durchgeführt wurde, wird im Folgenden auch kurz als „Stadtinfo-Projekt“ bezeichnet. Nach eingehender Beschreibung von Analyse, Konzeption und Umsetzung des Projektes folgen einige Schlussbetrachtungen.

2 Bluetooth

Die Geschichte von Bluetooth beginnt mit einer Studie der Firma Ericsson im Jahre 1994.^[9] Es sollten mittels eines kostengünstigen und energiesparenden Systems über Funk Daten zwischen Mobiltelefonen und deren Zubehör ausgetauscht werden. Nachdem Ericsson das Potential des Konzeptes bewusst wurde, gründeten sie 1998 die „Bluetooth Special Interest Group“ (Bluetooth SIG).^[10] Diese sollte die Entwicklung einer Technologie für drahtlose Übermittlung von Sprache und Daten per Funk übernehmen. Weitere Gründungsmitglieder waren IBM, Intel, Nokia und Toshiba. Heute sind über 2500 Firmen, hauptsächlich als Lizenznehmer, vertreten. Im Juli 1999 wurde die Version 1.0 der Bluetooth-Spezifikation veröffentlicht.

Wofür steht Bluetooth?

- Bluetooth steht für Netzwerke für Sprach- und Datenübertragung:

Da Bluetooth sowohl Sprache als auch Daten übertragen kann, ist es eine ideale Technologie für Geräte wie Mobiltelefone, die genau dies benötigen. Außerdem kann Bluetooth spontan Netzwerke aufbauen, um zwei oder mehrere Geräte miteinander zu verbinden.

- Bluetooth kann weltweit im Kurzstreckenbereich eingesetzt werden:

Bluetooth arbeitet im Frequenzbereich des 2,4 GHz ISM-Bandes (Industrial Scientific Medical Band). Dieser wurde weltweit für Industrie, Wissenschaft und Medizin vorgesehen und ist daher nahezu überall gebührenfrei und ohne Lizenz verfügbar. Bluetooth-Geräte haben, je nach Klasse, eine Reichweite zwischen 3 und 100 Metern.

- Bluetooth ist ein offener Industriestandard:
Die Standards sind kostenlos verfügbar.^[11]

Was aber ist das Besondere an Bluetooth? Bisherige Techniken sind recht spezialisiert: z. B. GSM für das Mobiltelefonnetz, WLAN für Computernetzwerke, DECT für schnurlose Telefone oder Infrarot für Fernbedienungen. Bluetooth dagegen versucht, ein wesentlich größeres Spektrum abzudecken. Das zeigt sich schon in der Anzahl an unterschiedlichen Klassen und Unterklassen der Bluetooth-Spezifikation. Die unterschiedlichsten Geräte sollen sich gegenseitig spontan erkennen können, so dass keine Konfiguration von Seiten des Benutzers notwendig ist – quasi ein Plug and Play, nur über Funk.

Bereits heute gibt es eine Vielzahl an Geräten auf Bluetooth-Basis und der Standard bleibt offen für Erweiterungen: Headsets, Mobiltelefone, Computerdongles, Computermaus/-tastatur, Bluetooth Access Points und vieles mehr.

Bluetooth kann beispielsweise eingesetzt werden, um Zeichnungen, die mit einem mit Bluetooth ausgerüsteten Filzstift an eine herkömmliche Tafel gemalt werden, direkt auf die bluetoothfähigen Geräte beispielsweise von Schulungsteilnehmern zu übertragen.^[12]

Toshiba rüstet Waschmaschinen mit Bluetooth aus^[13], SonyEricsson stellt ein per Mobiltelefon fernsteuerbares Spielzeugauto her^[14] und auch Pulsdaten können mittlerweile per Bluetooth übertragen werden^[15]. Auch die Automobilindustrie hat die neue Funktechnologie für sich entdeckt: Im Toyota Prius ist z. B. eine auf Bluetooth basierende Freisprecheinrichtung integriert.^[16]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Nokia N-Gage

Vor allem wird die Technologie jedoch bei mobilen Geräten eingesetzt, da Bluetooth kostengünstig ist und sich durch einen geringen Stromverbrauch auszeichnet. Auch die Fähigkeit, spontan Netzwerke aufbauen zu können, scheint für Mobiltelefonhersteller zunehmend interessant zu werden. So hat Nokia das „N-Gage“ entwickelt (s. Abbildung 2-1): Ein Mobiltelefon basierend auf dem Symbian- Betriebssystem, das als Spielekonsole genutzt werden kann. N-Gage-Besitzer können so über Funk im Netzwerk miteinander spielen. Angesichts des Booms in der LAN-Party-Szene ein durchaus erfolg-versprechendes Konzept.

2.1 Technik

Bluetooth-Geräte werden hinsichtlich ihrer Sendeleistung in drei Klassen unterteilt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Bluetooth-Klassen^[17]

Wie bereits erwähnt arbeitet Bluetooth in dem Frequenzbereich des 2,4 GHz ISM-Bandes, da dieses für Geräte mit geringer Sendeleistung weltweit lizenzfrei zur Verfügung steht.

Dieser Frequenzbereich wird daher aber auch von vielen anderen Geräten genutzt. Diese sind oft lokal installiert und auf eine feste Frequenz eingestellt.

Um Störern entgegenzuwirken, entschied man sich zu einem so genannten „Frequenzsprung-verfahren“. Die Frequenz, auf der gesendet und empfangen wird, springt bei Bluetooth in einer pseudozufälligen Sequenz 1.600 mal in der Sekunde zwischen insgesamt 79 Kanälen. So erreicht man eine sehr gute Störunanfälligkeit.^[18] Gehen trotzdem Daten verloren, regeln bestimmte Ebenen im Protokoll, dass diese erneut gesendet werden.

Auch das verbreitete WLAN nutzt das 2,4 GHz-Frequenzband. Wie sich in Untersuchungen mit Bluetooth und WLAN-IEEE 802.11b herausgestellt hat, sind Interferenzen zwischen den beiden Systemen und damit eine Verringerung der Datenrate jedoch akzeptabel, solange diese in einem angemessenen Abstand zueinander betrieben werden.^[19]

Netze

Eine Besonderheit von Bluetooth ist die Art und Weise, wie Netzwerke spontan und selbstständig gebildet werden können. Man spricht hier von so genannten „Ad-hoc-Netzen“. Für diese ist keine fest installierte Infrastruktur notwendig. Die einzelnen Geräte sind anhand ihrer weltweit eindeutigen Bluetooth-ID identifizierbar.^[20]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Bluetooth-Netze

Verbinden sich zwei oder mehr Bluetooth-Geräte miteinander, so spricht man von einem „Piconetz“ (s. Abbildung 2-2). Aufgrund des Frequenzsprungverfahrens müssen die beiden Geräte synchroni-siert werden, um eine Kommunikation zu ermöglichen. Diese Aufgabe übernimmt die Einheit, die den Verbindungsaufbau eingeleitet hat: die so genannte „Master“-Einheit. Der Master kann sich gleichzeitig mit bis zu sieben aktiven und 255 geparkten „Slaves“ verbinden. Ein PC, der beispielsweise Maus, Tastatur, Drucker und Scanner per Bluetooth anspricht, ist ein solcher Master in einem Piconetz. Piconetze können aber auch untereinander kommunizieren, indem ein Master oder ein Slave des einen Piconetzes gleichzeitig Slave eines zweiten Piconetzes wird. Dann spricht man von einem „Scatternetz“. Der jeweilige Master legt die individuelle Frequenzsprungfolge fest. Die Wahrscheinlichkeit einer Kollision der Piconetze ist daher relativ gering.

Stromverbrauch

Bluetooth-Geräte in einem Piconetz können vom Master in verschiedene Zustände versetzt werden, die in einem unterschiedlich hohen Stromverbrauch resultieren:

- Active: Im aktiven Zustand erwartet der Slave Übertragungen vom Master. Alle Pakete werden ausgewertet, und bei einer Sendeerlaubnis wird mit der Übertragung begonnen. Die Stromaufnahme im aktiven Zustand ist hoch, die Reaktionszeit dafür aber kurz. Anwendung: Aktive Kommunikation.

- Sniff: Der Slave wird nur periodisch aktiv, sonst ist er abgeschaltet. Das Intervall der aktiven Phase kann flexibel eingestellt werden. Je nach Einstellung sind Reaktionszeit und Strombedarf entsprechend kurz bzw. hoch.

Anwendung: Der Slave soll relativ schnell angesprochen werden können, es ist aber noch nicht bekannt, wann wieder kommuniziert werden muss.

- Hold: Der Slave wird für eine festgelegte Zeit abgeschaltet. Diese Zeit ist dem Master und dem Slave bekannt und kann flexibel eingestellt werden. Danach ist der Slave wieder aktiv. Je nach Einstellung kann die Reaktionszeit im Vergleich zum Sniff-Zustand schlechter sein, die durchschnittliche Stromaufnahme ist jedoch geringer.

Anwendung: Es ist bekannt, dass für eine bestimmte Zeit keine Kommunikation notwendig sein wird. So lange kann der Slave abgeschaltet werden.

- Park: Der Slave ist nicht aktiv, lediglich die Synchronisation mit dem Master wird aufrecht erhalten. Dies erfolgt mit dem so genannten „Beacon-Schlitz-Verfahren“: In einem dem Master und Slave bekannten Zeitraum schaltet der Slave kurz auf empfangsbereit. Danach schläft er wieder, sollte er kein Aktivierungssignal vom Master erhalten haben. Bis zu 255 Slaves eines Piconetzes können sich neben den sieben aktiven Geräten im geparkten Zustand befinden. Park bedeutet eine sehr geringe Stromaufnahme, aber auch eine relativ hohe Reaktionszeit.

Anwendung: Der Slave soll im Piconetz eingebunden sein, um aktiviert werden zu können, derzeit ist aber keine aktive Kommunikation notwendig.

Bluetooth-Geräte, die nicht in ein Piconetz eingebunden sind, befinden sich in einem Standby-Zustand. Darin suchen sie im Abstand von 1,28 s nach möglichen Übertragungen in ihrer Umgebung. Dies ist der Zustand mit der geringsten Stromaufnahme.

Um weiterhin Strom zu sparen, können Geräte ihre Sendeleistung gegenseitig beeinflussen. Befinden sich zwei Geräte beispielsweise direkt nebeneinander, so ist die Empfangsqualität, gemessen mit dem so genannten „RSSI“-Wert (Received Signal Strength Indicator), sehr gut. Der Empfänger kann den Sender in einem solchen Fall auffordern, seine Sendeleistung zu reduzieren, um die Stromaufnahme nicht unnötig zu erhöhen. Der Master führt diese individuelle Leistungsanpassung für jeden Slave gesondert durch. Diese werden also unter Umständen alle mit einer anderen Sendeleistung angesprochen.^[21]

Eine Systemübersicht über Bluetooth wurde nun gegeben. Dabei wurde auf die verwendete Übertragungstechnik sowie auf die möglichen Verbindungsnetze der Geräte untereinander eingegangen. Im Folgenden sollen der Bluetooth-Protokoll-Stack und seine verschiedenen Protokolle eingehender beschrieben werden.

2.2 Bluetooth-Protokoll-Stack

Bluetooth soll die Kommunikation unterschiedlichster Geräte von verschiedenen Herstellern ermöglichen. Um dies zu erreichen, sind einheitliche Regeln notwendig, an die sich alle halten. Diese werden von der Bluetooth SIG formuliert und ständig erweitert. Die so genannte Bluetooth-Spezifikation kann in der jeweils aktuellen Version von deren Internetseite kostenlos heruntergeladen werden.^[22]

In der Bluetooth-Spezifikation wird ein Protokoll-Stack festgelegt, der von den Herstellern je nach Bedarf auf seinen Geräten implementiert wird. Dieser Protokoll-Stack verwendet weitest möglich schon bestehende Protokolle. So kann die Einarbeitungszeit für Entwickler gering gehalten werden und es ist einfacher, bestehende Anwendungen auf Bluetooth zu adaptieren.

Bluetooth-Protokoll-Stack

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: Der Bluetooth-Protokoll-Stack

Die Protokolle des Bluetooth-Protokoll-Stacks können in vier Gruppen unterteilt werden (s. Abbildung 2-3):

- Bluetooth-Kern-Protolle (Bluetooth Core Protocols): Bluetooth Radio, Baseband, LMP, L2CAP und SDP. Dies sind die für Bluetooth exklusiven und wichtigsten Protokolle.
- Kabelersatz-Protokoll (Cable Replacement Protocol): RFCOMM.
Mit RFCOMM (Radio Frequency Oriented Emulation of the Serial COM Ports) werden serielle Schnittstellen emuliert.
- Telefonie-Kontroll-Protokolle (Telephony Control Protocols): TCS-Binary, AT-Commands. Sie basieren auf Protokollen aus der Telefon-Industrie.
- Angepasste Protokolle (Adopted Protocols): PPP, UDP, TCP, IP, WAP, OBEX.
Diese Protokolle wurden lediglich für Bluetooth angepasst.

Das Host Controller Interface (HCI) ist die Schnittstelle zwischen den Protokollen, die auf dem Bluetooth Controller integriert sind wie Baseband und LMP und Protokollen, die softwareseitig auf dem Host implementiert sind, wie beispielsweise L2CAP oder SDP.

Vergleich von Bluetooth mit dem ISO/OSI-Modell^[23]

Der Bluetooth-Protokoll-Stack referenziert das ISO/OSI-Modell, stimmt jedoch nicht exakt damit überein. In Abbildung 2-4 kann die Verbindung der beiden erkannt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: Vergleich ISO/OSI-Modell mit dem Bluetooth-Protokoll-Stack

In den folgenden Abschnitten soll nur auf die Bluetooth-Kern-Protokolle und das RFCOMM-Protokoll näher eingegangen werden. Zum einen sind dies die wichtigsten und für Bluetooth spezifischen Protokolle, zum anderen wurden sie direkt oder indirekt im Stadtinfo-Projekt verwendet.

2.2.1 Bluetooth Radio

Bluetooth-Geräte sind naturgemäß nicht per Kabel miteinander verbunden. Bluetooth Radio ist die unterste Ebene des Protokoll-Stacks und repräsentiert die physikalische Ebene des OSI-Referenzmodells.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Bluetooth-Frequenzband und Kanaleinteilung

Das freie ISM-Band im Bereich von 2,4 GHz hat eine Bandbreite von insgesamt 83,5 MHz. Diese wurde bei Bluetooth in 79 Kanäle mit je 1 MHz Bandbreite eingeteilt. Außerdem wurden zwei Schutzbänder vorgesehen, um Interferenzen mit benachbarten Funksystemen zu vermeiden (s. Abbildung 2-5).^[24] Zwischen diesen 79 Kanalfrequenzen springen alle Teilnehmer eines

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6: Frequenzsprünge mit Störfrequenz

Piconetzes gleichzeitig 1.600 mal in der Sekunde. Die Frequenzsprungfolge wird von der weltweit eindeutigen Bluetooth-Geräteadresse des Masters abgeleitet und ist somit ebenfalls einzigartig.^[25] Gegenüber schmalbandigen, festfrequenten Störsignalen ist Bluetooth daher recht robust, da durch die vielen Sprünge insgesamt gesehen nur recht wenig Daten im gestörten Frequenzbereich übertragen werden (vgl. Abbildung 2-6).

Die Daten werden auf die jeweilige Träger-frequenz mit dem so genannten Frequency Shift Keying-Verfahren aufmoduliert. Das bedeutet, dass eine binäre Eins durch eine

positive Frequenzabweichung von der Trägerfrequenz übertragen wird, eine binäre Null durch eine negative Abweichung. Genauer gesagt wird das GFSK (Gaussian Frequency Shift Keying) eingesetzt: Um die Bandbreite des Signals noch weiter zu reduzieren, wird das Datensignal vor der Modulation noch durch einen Gaußfilter gefiltert. Das Frequenzspektrum wird so noch effektiver ausgenutzt und die Beeinflussung von benachbarten Kanälen weiter reduziert.^[26]

Bluetooth soll sowohl Daten, als auch Sprache übertragen. Diese verschiedenen Anwendungs-zwecke stellen unterschiedliche Anforderungen. Es wurden daher zwei Arten von physikalischen Verbindungen definiert, die auch kombiniert werden können:^[27]

- SCO-Link (synchronous connection-oriented link):

Ein SCO-Link ist eine synchrone, verbindungsorientierte Verbindung. Ein Master kommuni-ziert mit einem bestimmten Slave in einer symmetrischen Punkt-zu-Punkt-Verbindung. Verloren gegangene SCO-Pakete werden nicht erneut übertragen. Ein Master kann bis zu drei SCO-Links verwalten. Anwendung: Zeitkritische Übertragungen wie z. B. Sprache.

- ACL-Link (asynchronous connection-less link):

Eine asynchrone, verbindungslose Verbindung. Ein Master kommuniziert mit seinen Slaves in einer Punkt-zu-Multipunkt-Verbindung. Verlorene Pakete werden wiederholt versendet.
Anwendung: Zeitunkritische, paketorientierte Übertragungen wie z. B. beim Laden einer Internetseite.

2.2.2 Baseband

Die Baseband-Ebene ist die wohl wichtigste Komponente des Bluetooth-Protokoll-Stacks.

Sie hat eine Reihe von Aufgaben:

- Steuerung der physikalischen Funkverbindung
- Verpacken/Entpacken der Datenpakete
- Festlegung der Frequenzsprung-Sequenz
- Fehlerkorrektur
- Datentransfer
- Verwaltung der Verbindungen
- Adressierung
- Authentisierung, Autorisation und Verschlüsselung

Um diese Aufgaben zu erfüllen, kommunizieren Bluetooth-Geräte auf Baseband-Ebene in Form von Datenpaketen. Auf dessen Aufbau und unterschiedliche Arten soll daher zunächst kurz eingegangen werden.

Aufbau des Baseband-Standardpaketes

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7: Baseband-Standardpaket

Ein Standardpaket besteht aus drei Teilen (s. Abbildung 2-7):

- Access Code (68 oder 72 Bit):

Der Access Code dient der Synchronisation und Identifikation. Ein Bluetooth-Gerät überprüft diesen Teil des empfangenen Paketes und verwendet es nur, wenn es für das Gerät bestimmt ist. Alle Pakete eines Piconetzes haben den gleichen Access Code.

- Header (54 Bit):

Der Header enthält in den ersten 10 Bit wichtige Steuerinformationen. Hier wird z. B. die Adresse der aktiven Slaves und die Art der Übertragung (SCO oder ACL) festgelegt. Danach werden 8 Bit von einem CRC-Code belegt, der den fehlerfreien Empfang des Headers feststellt. Diese 10+8 Bit werden drei mal übertragen, wodurch die Länge des Headers auf 54 Bit anwächst. Die korrekte Übertragung des Headers ist also mehrfach abgesichert.

- Payload (0-2745Bit):

Im Payload sind die eigentlichen Daten des Paketes enthalten, wie beispielsweise Sprachdaten bei einer SCO-Verbindung oder Daten einer zu übertragenden Datei bei einer ACL-Verbindung.

Arten des Baseband-Standardpaketes

Die Baseband-Standardpakete werden in drei unterschiedliche Arten eingeteilt:

- Steuerpakete:

Sie dienen der Steuerung und Fehlerkorrektur der Übertragung und enthalten keine Informationsdaten des Nutzers.

- ACL-Pakete:

ACL-Pakete enthalten die Nutzerdaten bei einer ACL-Verbindung und sind je nach notwendiger Fehlerkorrektur und Übertragungsgeschwindigkeit unterschiedlich aufgebaut.

- SCO-Pakete:

SCO-Pakete haben eine feste Länge und enthalten, je nach erforderter Qualität der zu übertragenden Daten, die Möglichkeit zur Fehlerkorrektur. Verlorene SCO-Pakete werden nicht erneut gesendet.

Fehlerkorrektur

Ein Funkkanal ist, verglichen mit einer Kabelverbindung, grundsätzlich sehr störanfällig. Im Baseband werden daher unterschiedliche Fehlerkorrekturverfahren eingesetzt, auf die im Rahmen dieser Diplomarbeit jedoch nicht weiter eingegangen werden kann.^[28]

Scrambling

Wie eben beschrieben gibt es eine Vielzahl unterschiedlicher Pakete. Bevor diese Pakete übermittelt werden, werden sie umgeordnet, was man auch als „Scrambling“ bezeichnet. Bei Bluetooth dient dies weniger dem Schutz vor unerlaubtem Abhören der Verbindung als vielmehr einer Verbesserung der Übertragungseigenschaften. Eine Übertragung digitaler Daten in Form einer Schwingung ist immer dann für Fehler anfällig, wenn viele Nullen oder Einsen aufeinander folgen. Durch das Scrambling-Verfahren wird dieser Gleichspannungsanteil minimiert. Auf Empfängerseite werden die Pakete dann wieder zurückgeordnet.

Synchronisation

Um eine problemlose Kommunikation zwischen Bluetooth-Geräten zu gewährleisten, müssen diese exakt synchronisiert werden. Jede Bluetooth-Einheit hat hierfür einen internen Zeitgeber. In Piconetzen passen die Slaves ihre interne Systemzeit an die des Masters an. Regelmäßig wird ein Offset bestimmt, damit alle Geräte gleichzeitig die Frequenz wechseln und zur richtigen Zeit empfangsbereit werden. Dieser Zeitgeber sollte laut Spezifikation mit 3,2 kHz getaktet sein. Bei einer Untersuchung mit einem Bluetooth-Analyzer wurde hingegen festgestellt, dass Geräte teilweise erheblich von dieser Vorgabe abweichen können. So beispielsweise bei einem getesteten SonyEricsson P800-Mobiltelefon, dessen interner Takt mit 3,4 kHz gemessen wurde.^[29] Eine Datenübertragung mit dem Gerät war trotzdem problemlos möglich.

Bluetooth-Adresse

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: Bluetooth-Adresse

Eine weitere wichtige Aufgabe des Baseband ist die Adressierung. Ein Bluetooth-Gerät hat eine weltweit eindeutige Adresse (s. Abbildung 2-8). Diese besteht aus insgesamt 48 Bit und enthält unter anderem eine herstellerspezifische ID sowie eine firmeninterne Nummer. Bei 48 Bit sind so 248 verschiedene Adressen möglich. Bei einer Weltbevölkerung von angenommenen 6,5 Milliarden Menschen entspricht dies über 40.000 möglichen Bluetooth-Adressen pro Mensch. Einem Problem vergleichbar mit dem der IP-Adressen wurde so aller Voraussicht nach ausreichend vorgebeugt.

Die Bluetooth-ID wurde beim Stadtinfo-Projekt unter anderem eingesetzt, um die Geräte eindeutig identifizieren zu können, für die bereits für den Informationsdienst bezahlt wurde.

Sicherheit

Sicherheit ist bei einer Funkverbindung ungleich wichtiger als bei Kabelverbindungen. Schon das Frequenzsprungverfahren gewährleistet eine gewisse Sicherheit vor ungewolltem Abhören einer Verbindung. Das genügt jedoch nicht, wenn sensible Daten übermittelt werden sollen. Werden in einer Firma beispielsweise Daten per Bluetooth an einen Drucker gesendet, so soll es nicht möglich sein, diese von außen abzuhören. Bluetooth trägt diesen Anforderungen Rechnung, indem drei Sicherheitsstufen definiert wurden:^[30]

- Security Mode 1 (non-secure):

Keinerlei Sicherheitsmaßnahmen auf Baseband-Ebene.

- Security Mode 2 (service level enforced):
Erst nach erfolgreichem Verbindungsaufbau werden erste Sicherheitsmaßnahmen ergriffen. Je nach angefordertem Service kann dann beispielsweise eine Verschlüsselung erfolgen.

- Security Mode 3 (link level enforced):
Je nach Einstellung können Geräte schon vor Verbindungsaufbau abgelehnt werden.

2.2.3 Der Link Manager

In den vorangegangenen Kapiteln wurden die beiden untersten Schichten des Protokoll-Stacks beschrieben. Bluetooth Radio ermöglicht die physikalische Übertragung der einzelnen Bits und Baseband regelt das gesicherte Senden und Empfangen von Datenpaketen. Ein Verbindungsaufbau beispielsweise kann aber mit diesen Funktionen noch nicht erreicht werden.

Der Link Manager übernimmt nun diese und andere wichtige Aufgaben, die hauptsächlich die Verbindung selbst betreffen:

- Verbindungsaufbau und –abbau
- Generierung, Austausch und Überprüfung der Sicherheitsschlüssel
- Powermodes und Leistungsregelung
- Aushandeln der Paketgrößen des Baseband
- Quality of Service (QoS)
- Link-Überwachung

Link Manager Protocol

Der Link Manager ist, wie auch Bluetooth Radio und Baseband, auf dem Bluetooth Controller implementiert und kommuniziert in erster Linie mit dem Link Manager des jeweils anderen Gerätes. Das dabei verwendete Protokoll wird als Link Manager Protocol (LMP) bezeichnet. Das LMP überträgt keine Anwenderdaten. Die zwischen zwei Link Managern ausgetauschten Nachrichten werden im Payload von ACL-Paketen übertragen.^[31]

Verbindungsaufbau und -abbau

Als Voraussetzung für einen Verbindungsaufbau durch den Link Manager muss bereits ein ACL-Link auf Baseband-Ebene vorhanden sein. Durch den Link Manager erfolgt dann eine Vielzahl aufeinander folgender Schritte, von denen die wesentlichen hier beschrieben werden sollen:^[32]

1. Als erstes wird der Offset zur Systemzeit des Masters bestimmt. Dieser wird nach jedem empfangenen Paket aktualisiert, um eine optimale Synchronität zu gewährleisten.

2. Dann wird die Version des LMP-Protokolls ermittelt. Dies ist notwendig, da Unterschiede in den LMP-Versionen bestehen.

3. Als nächstes wird ausgetauscht, welche Eigenschaften das jeweilige Gerät tatsächlich unterstützt, da nicht alle Eigenschaften von Baseband und Bluetooth Radio obligatorisch sind. Ein Bluetooth-USB-Dongle, der an einen PC angeschlossen ist, benötigt beispielsweise nicht die optionalen Stromsparzustände Hold, Park oder Sniff.

4. Nun wird der benutzerfreundliche Name ausgetauscht, den jede Bluetooth-Einheit haben kann. Dieser darf laut Spezifikation bis zu 248 Byte lang sein.

Offset, LMP-Version, unterstützte Eigenschaften und Name der Gegenstelle sind nun bekannt. Sollte nach Auswertung dieser Daten keine Verbindung mehr erwünscht werden, wird der Verbindungsaufbau hier beendet.

5. Soll eine Verbindung hergestellt werden, fordert der Master nun den eigentlichen Verbindungsaufbau an. Wird diese Anforderung erfolgreich bestätigt, werden die Verbindungseigenschaften bezüglich Pairing, Authentifikation, Verschlüsselung und Quality of Service (QoS) ausgehandelt.

Der Aufbau einer ACL-Verbindung ist nun abgeschlossen.

Wird eine SCO-Verbindung gewünscht, folgen noch weitere Schritte, bei denen die Parameter für eine SCO-Verbindung festgelegt werden. Dies kann z. B. der Audio-Codec sein, der für die Übermittlung von Sprachdaten eingesetzt wird.

Weitere LMP-Prozeduren dienen dem Einstellen der Stromsparzustände, einem Master/Slave-Rollentausch etc.

Auch der Verbindungsabbau erfolgt in einer strengen Abfolge von ausgetauschten Nachrichten. Hierbei wird unter anderem der Grund für die Einleitung des Verbindungsabbaus angegeben.

2.2.4 Host Controller Interface (HCI)

In diesem Kapitel soll auf die Schnittstelle zwischen der Hardware des Bluetooth Controllers und der Software des Host eingegangen werden. Die Bluetooth Hardware wird über diese Schnittstelle mit so genannten HCI-Kommandos angesprochen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: Überblick Bluetooth-Kommunikation mit Focus HCI^[33]

Damit ein Gerät den Bluetooth-Chip nutzen kann, muss es physikalisch mit diesem verbunden sein. Dies geschieht über ein so genanntes Bussystem. Derzeit werden bei Bluetooth drei Bussysteme unterstützt: Universal Serial Bus (USB) wie bei USB-Dongles, PC-Card (PCMCIA) und serielle Schnittstellen.^[34]

Ist diese physikalische Schnittstelle vorhanden, kommuniziert der Host über seinen HCI-Gerätetreiber mit der auf dem Controller des Bluetooth-Chips integrierten HCI Firmware.

Diese Kommunikation ermöglicht auch eine Flusskontrolle für ACL-Daten: Der Host kann den zur Verfügung stehenden Puffer der Bluetooth Hardware ermitteln und den Datenfluss zum Bluetooth-Chip dementsprechend regulieren. Das ist beispielsweise notwendig, wenn das Gegengerät nicht mehr antwortet.

Im Embedded-Bereich werden vornehmlich serielle Schnittstellen eingesetzt, sei es RS232, UART oder das proprietäre Transportprotokoll BCSP. BCSP wurde von der Firma Cambridge Silicon Radio (CSR) entwickelt und steht für BlueCore Serial Protocol.

Beim Einsatz von BCSP ist es möglich, auch die Schichten L2CAP, RFCOMM und SDP im Controller des Bluetooth-Chips zu integrieren und damit in der Hardware. So muss weit weniger Aufwand für die softwareseitige Implementierung dieser Protokolle auf dem entsprechenden System betrieben werden. BCSP setzt auf UART auf, ermöglicht jedoch zusätzlich noch eine Fehlerkorrektur und hat eine höhere Transferrate als UART.^[35]

Das beim Stadtinfo-Projekt eingesetzte Bluetooth-Modul ist mit dem Bluetooth-Chip „BlueCore01b“ der Firma CSR bestückt.^[36] Das BCSP-Protokoll wird hier allerdings nicht eingesetzt, da die zusätzliche Fehlerkorrektur bauartbedingt nicht notwendig ist und eine Einschränkung der Leistungsfähigkeit zur Folge gehabt hätte.^[37] Das Modul nutzt daher das UART-Protokoll.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-10: Bluetooth-Protokoll-Stack mit Focus L2CAP/RFCOMM/SDP

Die Protokolle des Controllers und die Schnittstelle zum Host wurden nun erläutert. In den folgenden Kapiteln wird auf die wichtigsten Protokolle des Host eingegangen (s. Abbildung 2-10):

L2CAP, RFCOMM und SDP. RFCOMM kommt in dieser Diplomarbeit besondere Bedeutung zu, da das Mobiltelefon und das Bluetooth-Modul im Stadtinfo-Projekt auf dieser Ebene kommunizieren. SDP stellt ein interessantes Protokoll dar, das es Bluetooth-Geräten ermöglicht, die gegenseitig angebotenen Dienste zu erkennen. SDP könnte daher auch in der Finalversion des Stadtinfo-Projektes eingesetzt werden.

2.2.5 Logical Link Control and Adaption Protocol (L2CAP)

Das L2CAP-Protokoll empfängt Daten von den höheren Protokollschichten und sendet diese weiter an die unter ihr liegenden Schichten (s. Abbildung 2-10). L2CAP unterstützt ausschließlich ACL-Verbindungen, überträgt also in der Regel kein Audio.

Die Aufgaben der L2CAP-Ebene kann man folgendermaßen zusammenfassen:

- Multiplexen von höheren Protokollen
- Segmentierung/Desegmentierung von großen Datenpaketen
- Gruppenmanagement
- Verwaltung des Quality of Service für die höheren Protokollschichten

Kommunikation über Kanäle

Die L2CAP-Schichten der verschiedenen Bluetooth-Geräte kommunizieren über so genannte Kanäle. Jeder Kanal hat zwei Endpunkte. Diesen Endpunkten wird je nach Kanalart eine so genann-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-11: L2CAP-Entities und Kanäle^[38]

te Channel ID (CID) zugeordnet (s. Abbildung 2-11). Es gibt verbin-dungsorientierte und verbindungs-lose Kanäle. Letztere werden beispielsweise für unidirektionale Kommunikation wie das Senden einer Broadcast-Nachricht verwen-det und haben die CID 2.

Neben den Kanälen für den Daten-austausch gibt es in diesem Kanal-prinzip auch noch die so genannten Signalisierungskanäle mit der CID 1. Pro Verbindung kann es immer nur einen Signalisierungs-kanal geben.

Wie bereits erwähnt, empfängt die L2CAP-Ebene Daten von höheren Ebenen. Dies sind die Ebenen RFCOMM, SDP und TCS. In den Paketen der Signalisierungskanäle wird angegeben, welche darüber liegende Ebene das Protokoll nutzt und auf welchen Kanal die Rückantwort geleitet werden soll. Wird eine Verbindung vom anderen Bluetooth-Gerät abgelehnt, wird in den Signalisierungskanälen dafür ein Grund angegeben, wie z. B. Sicherheitsgründe oder mangelnde Kapazitäten.

Nach erfolgreichem L2CAP-Verbindungsaufbau muss der Übertragungskanal noch konfiguriert werden. Dabei wird angegeben

- wie lange ein L2CAP-Paket maximal sein darf. Dies wird auch Maximum Transmission Unit (MTU) genannt. Die MTU kann für die beiden Bluetooth-Geräte unterschiedlich sein.
- wie oft versucht werden soll, ein Paket zu versenden, wenn es nicht erfolgreich übertragen wurde. Standardmäßig geschieht dies so oft, bis die Verbindung abbricht.
- ob das Best-Effort-Prinzip oder das Quality of Service-Prinzip verwendet werden soll.

Nachdem diese Konfiguration erfolgt ist, kann mit der eigentlichen Datenübertragung begonnen werden. Dabei kann es vorkommen, dass die höheren Protokollschichten größere Pakete an die L2CAP-Ebene schicken als Bluetooth an einem Stück verarbeiten kann. Solche Pakete werden in der L2CAP-Ebene zerlegt und paketweise an die unteren Schichten weitergeleitet. Im Baseband kann dann unter Umständen eine weitere Segmentierung der Pakete erfolgen.

2.2.6 Service Discovery Protocol (SDP)

Begibt man sich mit einem Bluetooth-Gerät in eine Umgebung, in der noch andere bluetoothfähige Geräte vorhanden sind, so möchte man unter Umständen deren Dienste nutzen. Die Dienste eines jeden Bluetooth-Gerätes sind in der so genannten Service Discovery-Datenbank eingetragen. Jedes Bluetooth-Gerät hat genau einen so genannten SDP-Server, der auf die Einträge seines Gerätes zugreifen kann. Möchte man also wissen, welche Dienste von einem Gerät angeboten werden, so startet der SDP-Client des eigenen Gerätes eine Anfrage an den SDP-Server des externen Gerätes, der dann die angebotenen Dienste übermittelt. Dadurch kann man noch nicht auf die Dienste zugreifen, man weiß aber, welche Dienste angeboten werden.

Informationen über den jeweiligen Dienst sind in Service-Einträgen gespeichert. Jeder Eintrag ist eine Instanz einer so genannten Service-Klasse, wobei ein Dienst auch zu mehreren dieser Klassen gehören kann. Ein Farbdrucker kann beispielsweise den Service-Klassen Drucker, Postscript-Drucker und Farb-Postscript-Drucker angehören.

Jeder Service-Klasse ist gemäß Vorgaben der Bluetooth SIG eine eindeutige Nummer zugeordnet. So haben Service-Klassen wie „Cordless Telephony“ oder „Fax“ ihren eigenen so genannten Universally Unique Identifier (UUID).^[39]

Es gibt zwei Arten, wie man nach Diensten auf anderen Bluetooth-Geräten suchen kann:

- Suchen nach einer speziellen UUID. So kann man beispielsweise herausfinden, ob das andere Gerät den Drucker-Dienst anbietet und dann versuchen, diesen Dienst zu nutzen.
- Abfragen des SDP-Servers nach allen von dem Bluetooth-Gerät angebotenen Diensten. Dies wird als „browsen“ bezeichnet.

2.2.7 RFCOMM (Radio Frequency Oriented Emulation of the Serial COM Ports)

Wie bereits erwähnt, wurde bei der Entwicklung von Bluetooth aus verschiedenen Gründen versucht, vorhandene, ausgereifte Protokolle zu nutzen.

Bluetooth soll bei vielen Geräten der Computer- und Telekommunikationswelt Kabelverbindungen ersetzen. Bei PDAs, Notebooks, Mobiltelefone und Druckern werden oft standardisierte serielle Schnittstellen eingesetzt. RFCOMM emuliert daher genau diese seriellen Schnittstellen und wird deswegen auch „Cable Replacement Protocol“ genannt. Es unterstützt theoretisch bis zu
60 gleichzeitige Verbindungen zwischen zwei Bluetooth-Geräten, in der Realität hängt die Anzahl von der Implementierung des jeweiligen Gerätes ab.

Emulation serieller Ports auf RFCOMM-Ebene

Jedem der 60 möglichen Verbindungen wird ein so genannter Data Link Connection Identifier (DLCI) zugewiesen (s. Abbildung 2-12). Der ersten Schnittstelle wird die Nummer 2, der letzten die Nummer 61 zugewiesen. Die Nummer 0 ist für den Signalisierungskanal reserviert, die Nummer 1 ist ebenfalls anderweitig reserviert.

Die im Stadtinfo-Projekt eingesetzten Geräte kommunizieren auf der RFCOMM-Ebene, wobei der DLCI hier willkürlich auf fünf festgelegt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-12: Emulation serieller Ports auf RFCOMM-Ebene^[40]

Damit ein Dienst, der auf RFCOMM aufsetzt, genutzt werden kann, muss dieser auch in der Service Discovery Datenbank eingetragen werden.^[41] Hierbei wird mindestens ein Dienstname und eine Kanalnummer für die Übertragung angegeben.

2.3 Bluetooth-Profile

Im vorangegangen Kapitel wurden die wichtigsten Bluetooth-Protokolle beschrieben. Nicht jedes Gerät muss jedoch alle Protokolle beherrschen. Ein Drucker beispielsweise benötigt kaum das für Telefonie notwendige TCS-Protokoll. Bestimmte Geräteklassen sollten also bestimmte Protokoll-Pakete implementieren. Die Bluetooth SIG definiert daher so genannte Bluetooth-Profile. Jedes Profil definiert die notwendigen Bluetooth-Protokolle und legt die darauf aufbauenden Regeln für die Kommunikation fest. Durch die Festlegung von Bluetooth-Geräten auf bestimmte Profile wird auch die Entwicklung von Anwendungen wesentlich vereinfacht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-13: Bluetooth-Profile

Abbildung 2-13 gibt einen Überblick über die wichtigsten Bluetooth-Profile:^[42]

- Generic Access Profile (GAP):

Dieses Profil ist grundlegend für alle anderen Profile, hier wird die Erkennung von Bluetooth-Geräten durch den Link Manager beschrieben.

- Service Discovery Profile (SDP):

Um die Dienste eines anderen Gerätes herauszufinden, müssen verschiedene Abläufe definiert werden. Diese sind im SDP festgelegt.

- Cordless Telephony Profile (CTP):

Soll ein Mobiltelefon mit einer Basisstation kommunizieren, die beispielsweise dann einen Festnetz-Telefonanschluß anspricht, wird dieses Profil implementiert.

- Intercom Profile (INTP):

Ähnlich wie CTP, jedoch besteht hier eine direkte Verbindung von z. B. zwei Mobiltelefonen. Dieser Modus wird auch „Walkie-Talkie-Modus“ genannt.

- Serial Port Profile (SPP):

Für die Emulation einer seriellen Kabelverbindung wird das SPP verwendet. Das Kabel wird durch eine virtuelle serielle Schnittstelle ersetzt. Dieses Profil wurde beim Stadtinfo-Projekt verwendet.

- Headset Profile (HSP):

Das HSP definiert die notwendigen Abläufe zwischen einem Audio-Headset und beispiels-weise einem Mobiltelefon.

- Dial-Up Networking Profile (DUNP):

Dieses Profil stellt dar, welche Protokolle für einen Netzzugang eines Computers per Mobiltelefon implementiert werden müssen. Dazu gehört auch die Möglichkeit, als Server zu fungieren und angewählt werden zu können.

- Fax Profile (FAXP):

Das Fax Profile definiert die notwendigen Abläufe und Protokolle für die Nutzung drahtloser Faxgeräte.

- LAN Access Profile (LAP): Dieses Profil dient dem Zugang zu einem LAN über das PPP-Protokoll.

- General Object Exchange Profile (GOEP):

Das GOEP enthält die wesentlichen Protokolle für den generellen Austausch von Objekten.

- Object Push Profile (OPP):

Für die Übertragung von Objekten von einem Client an einen Server wurde das OPP definiert. Ein Objekt könnte hierbei z. B. eine elektronische Visitenkarte sein (vCard). Diese wird in die Inbox des Servers gelegt.

- File Transfer Profile (FTP):

Dieses Profil wird zur Übertragung von Dateien genutzt oder um die Verzeichnisstruktur eines anderen Bluetooth-Gerätes zu durchsuchen.

- Synchronisation Profile (SP):

Sollen beispielsweise Daten wie Adressbuch oder Kalender auf verschiedenen Geräten synchronisiert werden, kommt dieses Profil zum Einsatz.

Die Definition von Profilen wird stetig erweitert. So wird es auch möglich sein, für zukünftig entwickelte Geräte passende Profile zu definieren.^[43] Auf der Internetseite der Bluetooth SIG finden sich beispielsweise auch die Definition für ein Profil für ISDN-Dienste über Bluetooth (Common ISDN Access Profile) oder das Human Interface Device Profile für z. B. Joysticks, Thermometer oder Fernbedienungen.

3 Symbian OS

„OS“ steht für „Operating System“, also „Betriebssystem“. Ein Betriebssystem dient der Steuerung und Verwaltung der Komponenten eines Computersystems.^[44]

Im Hinblick auf die Entwicklung des Stadtinformationsdienstes sollen in dieser Diplomarbeit die beiden Betriebssysteme Symbian OS und HyNetOS in ihren Grundlagen sowie wesentlichen Konzepten beschrieben werden. Dieses Kapitel gibt einen Einblick in das in erster Linie für Mobiltelefone entwickelte Betriebssystem Symbian OS.

3.1 Einführung

Die Ursprünge des Betriebssystem Symbian OS sind auf das von der Firma Psion Computers entwickelte Betriebssystem SIBO zurückzuführen („Sixteen Bit Organizer“ oder „Single-Board“ – je nach hardware- oder softwarenaher Betrachtung).

Psion hatte sich zum Ziel gesetzt, die Leistungsfähigkeit eines Desktop PCs mit der Mobilität eines Organizers zu verbinden und brachte im Jahre 1990 erstmals ein auf SIBO basierendes Gerät auf den Markt. In den nächsten Jahren folgten weitere Geräte, 1991 beispielsweise die „Series 3“, dessen Display bereits die halbe VGA-Auflösung erreichte. Alle Geräte waren sehr erfolgreich, unter anderem da sie sehr stromsparend waren, leistungsfähige Anwendungen beinhalteten und einfach mit anderen Geräten wie z. B. PCs kommunizieren konnten.

Das Betriebssystem SIBO hatte jedoch einige Einschränkungen:

- Es war ein 16-Bit-Betriebssystem, konnte also nur Zahlen bis 65.536 verwalten.
- Es unterstützte weder Maus noch Stift als Eingabemedium.
- SIBO war in C geschrieben. Grafische Benutzeroberflächen und komplexe Anwendungen lassen sich jedoch wesentlich besser mit moderneren, objektorientierten Sprachen programmieren.

1994 entschied sich Psion daher, ein neues Betriebssystem zu entwickeln, welches 1997 unter dem Namen „EPOC“ (für „Epoche“) erstmals auf Psions „5mx“ eingesetzt wurde.

Während der Weiterentwicklung von EPOC suchte Psion nach Wegen, das Betriebssystem auf möglichst vielen interessanten Plattformen einzusetzen und entdeckte den Markt der Mobiltelefone. Die Hersteller waren hier schon seit längerem auf der Suche nach einem leistungsfähigen Betriebssystem für die nächste Generation ihrer Geräte.

[...]

---

^[1] Vgl. Jipping (2002), S. 52.

^[2] Vgl. Frech (2003), S. 16.

^[3] Vgl. Jipping (2002), S. 380.

^[4] Vgl. Frech (2003), S. 17.

^[5] Vgl. Jipping (2002), S. 380.

^[6] Vgl. PDF-Quelle IZT, S. 49.

^[7] Vgl. Merkle (2002), S. 68-69.

^[8] Vgl. Internetquelle Statistisches Bundesamt.

^[9] Vgl. Merkle (2002), S. 5-23.

^[10] Der Name „Bluetooth“ geht zurück auf Harald Blatand, einen dänischen König des 10. Jhdts. Ihm gelang die Vereinigung sich bekämpfender Parteien des heutigen Norwegens, Schwedens und Dänemarks. Vgl. Internetquelle Bluetooth-Geschichte.

^[11] Kostenloser Download der Bluetooth-Spezifikation unter Internetquelle Bluetooth-Spezifikation.

^[12] Vgl. Internetquelle Bluetooth-E-Beam.

^[13] Vgl. Internetquelle Bluetooth-Waschmaschine.

^[14] Vgl. Internetquelle Bluetooth-Spielzeugauto.

^[15] Vgl. Internetquelle Bluetooth-Pulsmessgerät.

^[16] Vgl. Internetquelle Bluetooth-Toyota.

^[17] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 21.

^[18] Vgl. Kapitel 2.2.1.

^[19] Vgl. Merkle (2002), S. 271-284.

^[20] Vgl. Kapitel 2.1.2.

^[21] Vgl. Merkle (2002), S. 68-75.

^[22] Vgl. Internetquelle Bluetooth-Spezifikation.

^[23] Vgl. Merkle (2002), S. 79.

^[24] Da in Frankreich nicht das komplette 2,4 GHz ISM-Band freigegeben wurde, wird hier mit nur 23 Kanälen gearbeitet. Vgl. Merkle (2002), S. 85.

^[25] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 126-137.

^[26] Vgl. Merkle (2002), S. 86-88.

^[27] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 45.

^[28] Weitergehende Informationen vgl. PDF-Quelle Bluetooth-Spezifikation, S. 66-74.

^[29] Dies ergab eine Untersuchung mit einem Bluetooth-Analyzer an der Hochschule der Medien, Stuttgart, im Juli 2003.

^[30] Vgl. Merkle (2002), S. 134-147.

^[31] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 191-192.

^[32] Weiterführende Informationen vgl. Merkle (2002), S. 152-162.

^[33] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 544.

^[34] Auf den Datenaustausch über das USB- und PCMCIA-Bussystem soll hier nicht näher eingegangen werden.

^[35] Vgl. Merkle (2002), S. 163-182.

^[36] Vgl. PDF-Quelle MBT-Info.

^[37] Auskunft per Mail vom 04.03.2004 von Offner, Georg, SND.

^[38] Vgl. PDF-Quelle Bluetooth-Spezifikation, S. 262.

^[39] Diese Liste der UUIDs wird ständig erweitert. Sie kann kostenlos heruntergeladen werden von Internetquelle UUIDs.

^[40] Vgl. PDF-Quelle Bluetooth-Spezifikation, S.401.

^[41] Vgl. Kapitel 2.2.5.

^[42] Vgl. Merkle (2002), S. 80-82.

^[43] Vgl. Internetquelle Bluetooth-Spezifikation.

^[44] Vgl. Balzert (1999), S. 17.