Die Daten�bertragungsraten sind abh�ngig von der Spezifikation bzw. der Bluetooth-Version des jeweiligen Produkts. Die �bertragungsrate hat sich w�hrend der ersten drei Versionen nicht gesteigert, sie wurde erst mit der Bluetooth-Spezifikation Version 2.0 erh�ht. Ein �berblick �ber die �bertragungsraten, sowie die grossen �nderungen/Probleme, der jeweilgen Bluetooth-Versionen ist in [Tab.: 2.2] dargestellt.
Klassifikation Reichweite Sendeleistung Klasse 1 100 m 100 mW Klasse 2 40 m 2.5 mW Klasse 3 10 m 1 mW Tabelle 2.1: Reichweiten der einzelnen Bluetooth Klassen (Vgl. : [Wik06b])
Der Datentransport innerhalb der Bluetooth-Architektur sowie s�mtliche Betriebsmodi folgen dem selben generischen Ansatz. Dieser generische Ansatz ist mit Hilfe einer Schichtenarchitektur realisiert, die in [Abb.: 2.1] dargestellt, und mit dem OSI-Schichtenmodell vergleichbar ist.
Bluetooth-Version Maximale Daten�bertragungsrate �nderung/Problem 1.0 und 1.0B 723.2 Kbit/s Enth�lt Sicherheitsprobleme 1.1 723.2 Kbit/s Indikator f�r die Signalst�rke hinzugef�gt Received Signal Strength Indicator (RSSI) 1.2 723.2 Kbit/s Adaptive Frequency-Hopping spread spectrum (AFH) eingef�hrt; reduziert Interferenzen mit anderen Funktechnologien (z. B. WLAN) 2.0 2.1 Mbit/s Etwa dreifache Daten�bertragungsgeschwindigkeit durch Enhanced Data Rate (EDR) Tabelle 2.2: Daten�bertragungsraten von Bluetooth (Vgl. : [Wik06b, Versionen])
Abbildung 2.1: Allgemeine Datentransport Architektur von Bluetooth (Vgl. : [Blu03, Architecture, S.25; PDF, S. 101])
Die Authentifizierung beider Ger�te erfolgt in zwei Schritten, das heisst es wird eine gegenseitige Authentifizierung beider Ger�te vorgenommen. In direktem Anschluss der Authentifizierung des Ger�ts A bei Ger�t B wird die Authentifizierung in entgegengesetzter Richtung vorgenommen10 (Vgl. : [Blu03, Security Specification, S. 758; PDF, S. 914]).
Entit�t Gr�sse Bluetooth Device Address (BD_ADDR) 48 Bit Privater Schl�ssel des Benutzers (Authentifizierung) 128 Bit Privater Schl�ssel des Benutzers (Verschl�sselung) 8-128 Bit Pseudozufallszahl (RAND) 128 Bit Tabelle 2.3: In Authentifizierung und Verschl�sselung involvierte Entit�ten (Vgl. : [Blu03, Security Specification, S. 749; PDF, S. 907 Tabelle 1.1])
Die Spezifikation des GAP besch�ftigt sich haupts�chlich damit, zu beschreiben, welchem Zweck die unteren Schichten des Bluetooth Protokollstapels dienen (LC und LMP). Um Sicherheitsbezogene Alternativen zu diskutieren, wurden ebenfalls h�here Ebenen mit einbezogen (L2CAP, RFCOMM und OBEX) [Blu03, Generic Access Profile, S. 181; PDF: S. 1129].Abbildung 2.2: GAP Schichtenmodell (Vgl.: Abbildung 2.1: Profile stack covered by this profile, S. 181 [Blu03])
Die spezifizierten Werte der Zugriffskennzeichner LIAC und GIAC sind auf der Bluetooth Homepage12 zu finden [Blu06].
Auffindbarkeitszustand Beschreibung Non-discoverable mode Ist das Ger�t in diesem Zustand, so kann es von einer Suchanfrage nicht gefunden werden. Ein Bluetooth-Ger�t in diesem Zustand wird als “Stilles Ger�t” (silent device) bezeichnet. Limited discoverable mode (LIAC) Das Ger�t ist f�r einen beschr�nkten Zeitraum oder bis zum Eintritt eines bestimmten Ereignisses auffindbar. Es sollte allerdings nicht l�nger als eine vordefinierte Zeit in diesem Zustand bleiben (timeout). Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den Limited Dedicated Inquiry Access Code (LIAC) verwenden. General discoverable mode (GIAC) Das Ger�t befindet sich in einem dauerhaft auffindbaren Zustand. Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den General/Unlimited Inquiry Access Code (GIAC) verwenden. Tabelle 2.4: Auffindbarkeitszust�nde eines Bluetooth-Ger�ts [M+05, Generic Access Profile, S. 189ff; PDF, S.1137ff]
Die J2ME Architektur folgt also prinzipiell dem in [Abb.: 2.4] dargestellten Aufbau. Die einzelnen Schichten der Architektur (CLDC [Kapitel 2.3] und MIDP [Kapitel 2.4]) werden im Folgenden genauer beschrieben.
User Permission G�ltigkeitszeitraum blanket G�ltig f�r jede Ausf�hrung der MIDlet-Applikation bis sie deinstalliert oder die Rechte vom Benutzer ge�ndert werden. session G�ltig vom Start eines MIDlets, bis zu dessen Termination. Der “session” Modus ist verpflichtet, den Benutzer beim oder vor dem ersten Aufruf einer gesch�tzten Funktion einen Dialog anzuzeigen, in dem der Benutzer entweder den Zugriff gestattet oder ablehnt. Bei einem erneuten Start des MIDlets muss diese Abfrage erneut erfolgen. oneshot Eine Interaktion mit dem Benutzer ist bei jedem Zugriff auf ein gesch�tztes API notwendig. Tabelle 2.5: G�ltigkeitszeitraum der Rechte eines MIDlets (Vgl. : [VW02, S. 26])
Eigenschaft Beschreibung bluetooth.api.version obex.api.version Version des Java APIs for Bluetooth wireless technology die unterst�tzt wird. F�r die Version 1.1 wird entsprechend “1.1” zur�ckgeliefert. bluetooth.l2cap.receiveMTU.max Maximum Transfer Unit (MTU) in Empfangsrichtung, die von L2CAP unterst�tzt wird. Der zur�ckgelieferte Wert ist dezimal in einem java.lang.String kodiert. bluetooth.connected.devices.max Maximale Anzahl verbundener Ger�te. bluetooth.connected.inquiry Kann eine Ger�tesuche durchgef�hrt werden, w�hrend das Ger�t bereits verbunden ist? bluetooth.connected.page Kann das lokale Ger�t eine Verbindung zu einem entfernten Ger�t herstellen, wenn das lokale Ger�t bereits verbunden ist? bluetooth.connected.inquiry.scan Kann das lokale Ger�t auf eine Suchanfrage antworten, w�hrend es mit einem anderen Ger�t verbunden ist? bluetooth.connected.page.scan Kann das lokale Ger�t eine Verbindung von einem anderen Ger�t annehmen, w�hrend es bereits mit einem anderen Ger�t verbunden ist? bluetooth.master.switch Ist der master/slave Wechsel erlaubt? bluetooth.sd.trans.max Maximale Anzahl zeitgleicher Dienstsuchen (Service Discovery) bluetooth.sd.attr.retrievable.max Maximale Anzahl der Service-Attribute die mit einem Service Record empfangen werden k�nnen. Tabelle 2.6: �bersicht der Eigenschaften des Ger�ts (Vgl. [M+05, S. 24, Tabelle 3-2 Device Properties])
Name Beschreibung Zul�ssige Werte Client oder Server master Gibt an, ob das Ger�t master der Verbindung sein muss. true, false Beide authenticate Gibt an, ob das entfernte Ger�t authentifiziert werden muss bevor eine Verbindung hergestellt werden kann. true, false Beide encrypt Gibt an, ob die Verbindung verschl�sselt werden muss. true, false Beide authorize Gibt an, ob alle Verbindungen zu diesem Ger�t authorisiert werden m�ssen um den Dienst zu nutzen. true, false Server name Der Name des angebotenen Dienstes, der in der SDDB gespeichert wird. Jeder g�ltige String Server Tabelle 2.7: G�ltige Parameter f�r RFCOMM Verbindungskennzeichner (Vgl. : [BJJ04, S. 59, Tabelle 4.1 Valid Parameters for RFCOMM Connection Strings])
Da das OBEX Protokoll �ber verschiedene Transportprotokolle verwendet werden kann, muss der String, der die Verbindung spezifiziert, das Transportprotokoll beinhalten. Die URL, um eine Verbindung zu einem entfernten Ger�t herzustellen, hat folgenden Aufbau:
Operation Beschreibung CONNECT Stellt die Verbindung zum Server her. PUT �bertr�gt Daten vom Client an den Server. GET �bertr�gt Daten vom Server an den Client. SETPATH �ndert das Arbeitsverzeichnis auf dem Server. ABORT Bricht eine PUT oder GET Operation ab. CREATE-EMPTY Erzeugt ein leeres Objekt mit dem im Header angegebenen Namen auf dem Server. PUT-DELETE L�scht das im Header angegebene Objekt auf dem Server. DISCONNECT Beendet die Verbindung zum Server. Tabelle 2.8: OBEX Operationen