und Bluetooth

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol und Bluetooth Seminar: Internetprotokolle für die Multimediakommunikation WS 2002/2003 Christian Beecks Matrikelnummer: Betreuung: Jan Kritzner Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhalt 1. Überblick 3 2. Bluetooth Protokollstack Radio Interface Baseband / Link Controller Physikalische Verbindungen und Paketaufbau Verbindungsaufbau Piconetze und Scatternetze Link Manager Host Controller Interface Logical Link Control and Adaption Protocol Aufbau, Konfiguration, Abbau einer Verbindung Service Discovery Protocol RFCOMM Wireless Access Protocol Object Exchange Telephony Control Protocol Bluetooth Anwendungsprofile Zusammenfassung Literaturverzeichnis 16 2

3 1. Überblick Bluetooth ist ein lizenzfreies Funkverfahren das verschiedenen Geräten überall auf der Welt ermöglicht, über eine international standardisierte Datenschnittstelle zu kommunizieren. Bluetooth entstand 1994 aus einer von der schwedischen Mobilfunkfirma Ericsson in Auftrag gegebenen Studie mit dem Ziel, günstige, stromsparende Funkverbindungen innerhalb einer Umgebung von bis zu 100 Metern zu realisieren, in der Kabel und Inkompatibilitäten vermieden werden sollten. Im Jahre 1998 bildete sich aufgrund positiver Ergebnisse die Bluetooth Special Interest Group (SIG), zu der damaligen Zeit waren Ericsson, Nokia, IBM, Toshiba und Intel an der Gründung beteiligt. Heutzutage sind über 2000 Firmen Mitglieder dieser Gruppe. Ein Ziel der Bluetooth Spezifikation ist es, Geräten verschiedener Hersteller die gemeinsame Kommunikation zu ermöglichen, deshalb definiert der Standard nicht nur die Sende- /Empfangseinheit sondern auch den Software Stack, um Programme auf Dienste anderer Bluetooth Geräte zugreifen zu lassen und deren Benutzung zu gestatten. Abbildung 1.1 zeigt den Bluetooth Protokollstack. Applications Bluetooth Host SDP WAP OBEX TCS RFCOMM Logical Link Control and Adaption Host Controller Interface Link Manager Bluetooth Modul Baseband/Link Controller Radio Abbildung 1.1: Bluetooth Protokollstack Die Anwendungen können zum Beispiel mittels Wireless Access Protocol (WAP) oder Object Exchange (OBEX) auf serielle Schnittstellen zugreifen, die durch das Modul RFCOMM simuliert werden. Des weiteren steht eine Telephony Control Protocol Specification (TCS) zur Verfügung, welche ein Interface zum Umgang mit Telefonanrufen bereitstellt. Das Service Discovery Protocol (SDP) ermöglicht es Bluetooth Geräten, die angebotenen Dienste anderer in ihrer Umgebung befindlichen Bluetooth Geräten ausfindig zu machen. 3

4 Logical Link Control and Adaption (kurz L2CAP) stellt ein Protokoll zur Verfügung, welches Daten von höheren Schichten zwischen den unterschiedlichen Paketgrößen konvertiert. Unterhalb des L2CAP ist das Host Controller Interface für die Verbindung zwischen den getrennten Host und Bluetooth Modulen zuständig. Darunter kontrolliert und konfiguriert der Link Manager Verbindungen zu anderen Geräten. Die Baseband/Link Controller Schicht steuert die physikalischen drahtlosen Verbindungen, setzt Pakete zusammen und reguliert das Frequenz Hopping. Als unterste Schicht ist schließlich die Radio Einheit zu nennen, die Daten moduliert und demoduliert bzw. sendet und empfängt. Im 2. Kapitel werden die grundsätzlichen Aufgaben der einzelnen Schichten beschrieben, die Anwendungsprofile werden im 3. Kapitel erläutert. Im 4. Kapitel folgt eine Zusammenfassung. 2. Bluetooth Protokollstack Die Elemente des Bluetooth Protokollstack lassen sich in zwei Teile unterteilen, in eine Gruppe unterhalb des Host Controller Interface (HCI), die die Schichten auf dem Bluetooth Modul darstellt, und in eine zweite Gruppe, die den Teil auf dem Host Gerät darstellt. Der Sinn dieser Trennung wird in den Erläuterungen zum HCI in Kapitel 2.4 ersichtlich. 2.1 Radio Interface Bluetooth Geräte arbeiten in dem weltweit verfügbaren ISM Band. Es stehen 79 Kanäle im Abstand von 1 MHz im 2,4 GHz Bereich zur Verfügung, die mittels Frequenz Hopping optimal genutzt werden. Bei diesem Verfahren ändern sich die Frequenzen 1600 mal pro Sekunde. Die benutze Modulation ist Gaussian Frequency Shift Keying (GFSK), eine einfache Technik, bei der die Datenbits durch Änderung der Frequenz repräsentiert werden. Die Geräte sind in drei verschiedene Leistungsklassen unterteilt, die zwischen 1 und 100mW Ausgangsleistung liefern, die Reichweite liegt dementsprechend zwischen 10 und 100 Meter. 2.2 Baseband / Link Controller Die Baseband-Schicht ist verantwortlich für die Kanalkodierung/-dekodierung, das Timing und das Frequenz Hopping innerhalb eines Datenpakets. Zu den rohen Datenpaketen werden Adress- und Kontrollfelder hinzugefügt, die Fehlerkorrektur ermöglichen. Der Link Controller führt Instruktionen höherer Schichten aus, erstellt und organisiert die Verbindungen mit mehreren Geräten, und steuert die verschiedenen Zustände. Ein Bluetooth Gerät kann in sechs verschiedenen Zuständen betrieben werden: Im Standby Mode ist das Gerät inaktiv, es findet kein Datentransfer statt. Im Inquiry Mode sucht das Gerät andere Geräte, die sich im Inquiry Scan Mode befinden, um Informationen über angebotene Dienste zu sammeln. Der Page Mode dient zur Herstellung der Verbindung mit einem Gerät, das sich im Page Scan Mode befindet, und über das zuvor durch den Inquiry Mode Informationen gesammelt wurde. Bei einer bestehenden Verbindung wechselt das Gerät in den Connection Mode, der nochmals unterteilt ist in Hold, Sniff und Park Mode. 4

5 2.2.1 Physikalische Verbindungen und Paketaufbau Verbindungen zwischen zwei oder mehreren Bluetooth Geräten werden in asynchrone (ACL) und synchrone (SCO) Verbindungen aufgeteilt. Eine ACL (Asynchronous Connection-Less) Verbindung existiert direkt nach dem Verbindungsaufbau zwischen zwei Geräten. Diese paketorientierte Verbindung wird zur Datenübertragung eingesetzt, ein Master kann mehrere Verbindungen zu verschiedenen Slaves haben. Der ACL Modus bietet Fehlerkorrektur durch Redundanz und erneute Sendung, um Datenvollständigkeit zu gewährleisten. Die Bandbreite liegt bei der symmetrischen Variante bei 432,6 kbit/s, bei der asymmetrischen Ausführung bei 721 kbit/s bzw. 57,6 kbit/s. SCO (Synchronous Connection Oriented) Verbindungen sind leitungsorientiert, Daten werden in regelmäßigen Abständen und ohne Fehlerkorrektur übertragen. SCO Verbindungen sind für Audio geeignet, die Bandbreite liegt konstant bei 64 kbit/s. Ein Master kann bis zu drei SCO Verbindungen zu Slaves aufsetzen. Access Code Header Payload 68 or 72 bits 54 bits bits Abbildung 2.1: Struktur eines Bluetooth Pakets Die Abbildung 2.1 zeigt den grundsätzlichen Paketaufbau eines Bluetooth Paketes. Der Access Code dient zur Synchronisation und zur Identifizierung. Er enthält unter anderem die Adresse des Bluetooth Master. Der Header enthält Informationen über das Paket, wie Fehlerkorrektur, Flusskontrolle, Slave Adresse und Art des Pakets. Der Payload enthält die Nutzdaten des Pakets. Der ACL Payload bietet im Gegensatz zum SCO Payload die Möglichkeit einer Fehlerkorrektur. Es gibt auch noch eine Reihe weiterer Spezialpakete, wie ID, NULL, POLL und FHS Verbindungsaufbau Um eine Verbindung zwischen zwei Bluetooth Geräten aufzubauen, durchläuft der Link Controller verschiedene der o.a. Zustände. Abbildung 2.2 zeigt den generellen Ablauf eines Verbindungsaufbaus. Zu Beginn befinden sich sowohl der Master als auch der Slave im Standby Mode. Der spätere Master wechselt dann durch Befehl der Anwendung in den Inquiry Mode, um nach allen anderen in Reichweite befindlichen Geräten, die durch die Anwendung in den Inquiry Scan Mode versetzt wurden, zu suchen. Er sendet ID Pakete aus, welche nur den Access Code enthalten. Die Antwort auf dieses ID Paket ist ein FHS Paket, welches dem Master erlaubt, alle notwendigen Informationen wie die Adresse und über das Frequenz Hopping Muster eines jeden Gerätes zu sammeln. Optional können die Geräte wieder in den Standby Mode wechseln, dies kann sinnvoll sein, wenn sie nicht direkt eine Verbindung eingehen wollen, sondern erst zu einem späteren Zeitpunkt benötigt werden. Um eine Verbindung herzustellen, muss die Anwendung den Slave in den Page Scan Mode versetzen. Der Master sendet im Page Mode erneut ein ID Paket an jeweils einen Slave, jetzt jedoch mit dessen Informationen, die er vorher durch das FHS Paket im Inquiry Mode erhalten hat. Der Slave wechselt in den Slave Response Mode, sendet ein ID Paket zurück, und wartet danach auf das FHS Paket des im Master Response Mode befindlichen Masters. Dieses FHS Paket ermöglicht dem Slave sein eigenes Timing und Access Code des Master 5

6 zu aktualisieren. Der Master sendet nun ein POLL Paket an den Slave, welches wie das NULL Paket nur aus dem Access Code und Header besteht, das jedoch durch den Slave durch das NULL Paket bestätigt werden muss. Dies bestätigt den erfolgreichen Verbindungsaufbau, beide Geräte befinden sich jetzt im Connection Mode. Master Standby Slave Standby Inquiry ID Inquiry Scan FHS Inquiry Response Standby Standby Page ID Page Scan Master Response ID FHS Slave Response Connection (Master) POLL NULL Connection (Slave) Abbildung 2.2: Aufbau einer Verbindung Piconetze und Scatternetze Ein Bluetooth Gerät, das eine Verbindung initiiert heißt Master, das Gerät das auf die Verbindung wartet und sie gegebenenfalls annimmt heißt Slave. Wenn sich zwei oder mehrere Geräte in Reichweite befinden, entsteht ein Piconetz. In einem Piconetz können sich bis zu sieben Slaves mit einem Master aktiv verbinden. Der ganze Datenfluss läuft zentral über den Master, er kontrolliert und steuert das gesamte Piconetz. Alle Slaves eines Piconetzes haben das selbe Frequenz Hopping Muster, das der Master vorgibt. Bei spontan entstehenden Piconetzen kann es durchaus vorkommen, das sich mehr als acht Geräte in Reichweite befinden, und mehrere Piconetze entstehen. Diese werden zu einem Scatternetz zusammengeschlossen. Dabei hat jedes Piconetz weiterhin einen Master, der durchaus ein Slave in einem anderen Piconetz sein kann. Es besteht die Möglichkeit, die Rollen von Master und Slave nach Bedarf zu wechseln. 6

7 2.3 Link Manager Zu den Aufgaben des Link Manager gehört das Hinzufügen und Entfernen von Slaves zu einem Piconetz, Konfiguration der Verbindung sowie Master/Slave Rollentausch. Er stellt ACL und SCO Verbindungen her und steuert die verschiedenen Connection Modes Hold, Sniff und Park, um den Stromverbrauch zu senken. Über das Link Manager Protocol (LMP) kommuniziert er mit Link Managern in anderen Bluetooth Geräten. 2.4 Host Controller Interface Das Host Controller Interface (HCI) bildet die Verbindung zwischen dem Bluetooth Modul, bestehend aus Radio, Baseband / Link Controller sowie Link Manager und dem Bluetooth Host, der alle höheren Schichten enthält. Das Bluetooth Modul könnte so beispielsweise eine Karte für den PC sein, sodass die höheren Schichten auf dem Prozessor des PC ausgeführt werden. Der PC hat genug Ressourcen, um sich mit den Schichten oberhalb des HCI zu beschäftigen, was dazu führt, dass das Bluetooth Modul weniger Speicher braucht und ein schwächerer Prozessor ausreicht, wodurch die Kosten für das Modul gesenkt werden können. Auch ist durch solch eine Implementierung die Möglichkeit gegeben, den PC durch das Bluetooth Modul einzuschalten. Möglich ist auch eine Implementierung des kompletten Protokollstacks auf einem Prozessor, einem Headset zum Beispiel, jedoch muss auch eine solche Lösung ein Host Controller Interface zu Testzwecken unterstützen. Die Bluetooth Spezifikation sieht drei verschieden HCI Pakete vor: ein Command Paket welches der Host nutzt, um das Modul zu kontrollieren; ein Event Paket das dem Modul erlaubt, Änderungen der unteren Schichten an den Host zu senden und ein Data Paket in dem Nutzdaten zwischen Host und Modul hin und her transportiert werden. Ebenso ist die physikalische HCI Transport Ebene definiert, um HCI Pakete zwischen Host und Bluetooth Modul zu verschicken. USB, sowie eine Serielle Schnittstelle mit und ohne Fehlerkorrektur stehen zur Verfügung. Zu den Aufgaben des HCI gehört die Herstellung, Kontrolle, Konfiguration und der Abbau von Verbindungen, sowie die Kontrolle der Baseband Einheit, um diese in die verschiedenen Zustände zu setzen. Eine Flusskontrolle der Transport Ebene ist auch vorgesehen, um den Datentransfer sicherzustellen. Das Host Controller Interface ermöglicht direkten Zugriff auf das lokale sowie mittels LMP auf das entfernte Bluetooth Modul, um dessen Status zu ändern und Informationen zu empfangen. 2.5 Logical Link Control and Adaption Protocol Das Logical Link Control and Adaption Protocol (L2CAP) ist der wichtigste Teil eines Bluetooth Systems. Alle Anwendungen und somit höhere Schichten des Bluetooth Protokollstacks müssen dieses Protokoll benutzen um Daten über die tieferliegenderen Schichten zu übertragen. L2CAP unterstützt Paketgrößen, die nicht unbedingt von den darunter liegenden Schichten unterstützt werden, teilt diese zur Übertragung auf und setzt sie wieder richtig zusammen. L2CAP erlaubt verschiedenen höheren Schichten, gemeinsam Daten über eine ACL Verbindungen zu übertragen. Damit verschiedene Benutzeranwendungen erfolgreich über eine ACL Verbindung Daten austauschen können, werden die Pakete mit Kanalnummern versehen, um die korrekte Zuordnung zu gewährleisten. Diese Kanalnummern werden zugewiesen, sobald eine 7

8 Verbindung erstellt wird. Die Kanalnummern stehen im Channel Identifier Feld des Headers, direkt hinter dem Length Feld. Abbildung 2.3 zeigt die Struktur eines L2CAP Pakets. Length Channel Identifier Data 2 Byte 2 Byte Bytes Abbildung 2.3: Struktur eines L2CAP Pakets Es können bis zu Byte Nutzdaten in einem Paket transportiert werden, wie man aus der Abbildung 2.3 erkennt. L2CAP Verbindungen werden über einen reservierten Signalisierungskanal (0x0001) mittels Kontrollpaketen gesteuert. Dies ermöglicht die Eröffnung, Konfiguration und Abschaltung von Verbindungen. Die Kontrollpakete werden im Datenfeld des L2CAP Pakets transportiert Aufbau, Konfiguration, Abbau einer Verbindung Um eine Verbindung herzustellen, sendet die Anwendung eine Anfrage an die Logical Link Control and Adaption (L2CA) Ebene, welche wiederum eine ACL Verbindung mithilfe der unteren Schichten herstellt, falls noch keine besteht. Eine schematische Darstellung des Verbindungsaufbaus zeigt Abbildung 2.4. Nachdem die L2CA Ebene durch ein ConnectReq(1) der Anwendung informiert wurde, sendet sie ein ConnectReq(2) an das Host Controller Interface, welches in Abbildung 2.4 mit den tieferliegenden Schichten zusammengefasst wurde. Das Host Controller Interface steuert den in Kapitel beschriebenen Verbindungsaufbau einer ACL Verbindung durch den Lower Protocol Stack (3), dabei wird die L2CA Schicht auf der Gegenseite durch ein ConnectInd(4) Signal ihres Host Controller von dem Einrichten der Verbindung informiert, und bestätigt diesen mittels ConnectRsp(5). Es besteht nun eine Verbindung zwischen den unteren Schichten der Module (6). Der initialisierenden L2CA Einheit wird danach durch das Signal ConnectCnf(7) bestätigt, das eine ACL Verbindung existiert. Erst zu diesem Zeitpunkt können die beiden L2CA Einheiten miteinander Kontrollnachrichten über die vorher eingerichtete ACL Verbindung austauschen. Die annehmende L2CA Einheit bestätigt die ConnectReq(8) Nachricht durch eine ConnectRspPnd(9) Mitteilung und informiert die auf Verbindung eingehende Anwendung mit Hilfe eines ConnectInd(10) Signals. Das ConnectReq Paket enthält unter anderem den Protocol and Service Multiplexer (PSM) und die source Channel ID (CID), die Kanalnummer welche der Verbindung auf der Host Seite zugeordnet wird. Der PSM wird vom L2CAP benutzt um die Art der durch die höheren Schichten benutzen Verbindung zu identifizieren. So hat beispielsweise RFCOMM immer den PSM = 0x0003. Willigt die Anwendung die Verbindung ein, so teilt sie dies mit einem ConnectRsp(11) Signal mit. Die entfernte L2CA Einheit sendet nun ein ConnectRsp(12) Paket an die Host L2CA Ebene, die dann per ConnectCnf(13) die Anwendung informiert. Das ConnectRsp Paket enthält neben der destination Channel ID (CID), welche von dem antwortendem Gerät für die Verbindung benutzt wird, auch die vorher empfangene source Channel ID. Des weiteren enthält das Paket noch ein Feld, das den Status der Verbindung zurückgibt. Mögliche Zustände sind Verbindungsaufbau erfolgreich, unvollendeter Verbindungsaufbau, aus Sicherheitsgründen verweigert oder abgelehnt aus Mangel an Ressourcen. 8

9 Application Initiating Connection Application Accepting Connection 11: ConnectRsp 10: ConnectInd 13: ConnectCnf 1: ConnectReq Logical Link Control and Adaption 8: ConnectReq 9: ConnectRspPnd Logical Link Control and Adaption 12: ConnectRsp 5: ConnectRsp 4: ConnectInd 7: ConnectCnf 2: ConnectReq Lower Protocol 3: Lower Protocol Connection Procedures Lower Protocol 6: Lower Protocol setup complete Abbildung 2.4: Herstellung einer L2CAP Verbindung Nachdem eine Verbindung hergestellt wurde, muss diese konfiguriert werden. Dies geschieht, indem die initiierende L2CA Konfigurationsanfragen sendet. Die empfangende L2CA kann diese verwerfen oder eine Konfigurationsantwort senden. Dieser Vorgang dauert maximal zwei Minuten. Folgende drei Parameter können konfiguriert werden: Die Maximum Transmission Unit (MTU) gibt die maximale Größe in Bytes an, die ein Datenpaket im Payload enthalten darf. Flush Timeout legt die maximale Zeit fest, in der ein Gerät versucht, zu senden. Die Quality of Service Option kann zwischen beste Übertragungsleistung und garantierte Übertragungsqualität variieren. Werden sich beide Geräte nicht einig über die Parameter, so arbeiten sie entweder mit den Parametern weiter, die sie haben, oder schließen die Verbindung. Ist die Verbindung konfiguriert, so kann ab diesem Zeitpunkt die Datenübertragung beginnen. Ein Kanal kann auf zwei Arten geschlossen werden, zum einen, wenn eine höhere Schicht eine Trennung fordert, oder durch einen Timeout. 2.6 Service Discovery Protocol Ein Bluetooth Piconetz ist ziemlich unterschiedlich im Vergleich zu einem drahtgebundenen Local Area Network (LAN). In dieser dynamischen Umgebung wechseln Verbindungen schnell und gefundene Geräte, wie etwa ein Drucker, können benutzt werden, ohne dafür 9

10 Einstellungen vorzunehmen. Das Service Discovery Protocol (SDP) ermöglicht dieses. Es bietet die Mittel, um Dienste der in Reichweite befindlichen Geräte zu ermitteln. SDP Client/Server Verbindungen setzten auf L2CAP Verbindungen auf. Ein SDP Server stellt dabei Informationen bereit, die ein Client über den Dienst benötigt, um sich mit ihm zu verbinden. Bluetoothfähige Geräte können sowohl Client als auch Server sein. Damit sich ein Client mit einem Server verbinden kann, muss der Client eine L2CAP Verbindung zu dem Server aufbauen und den Kanal mit dem PSM = 0x0001 benutzen. Anschließend kann der Client nach einer bestimmten Klasse von Diensten oder direkt nach Diensten suchen, die notwendigen Attribute empfangen und sich auf einem separaten Kanal mit dem Dienst verbinden und diesen nutzen. Die SDP Datenbank, die ein Server anbietet, ist eine Menge von Datensätzen, die einen Dienst, welcher ein Bluetooth Gerät anderen Geräten zur Verfügung stellt, beschreibt. Ein SDP Dienst wird durch Attribute beschrieben. Es gibt 28 Sorten von Attributen, die alle einen anderen Aspekt eines Dienstes beschreiben. Anhand des Datensatzes eines Bluetooth Headset lassen sich die wichtigsten Attribute beispielhaft mittels Tabelle 2.1 erklären. Der ServiceRecordHandle ist eine 32 Bit Nummer die einen Dienst innerhalb eines Server eindeutig identifiziert. Es folgt eine Liste von Diensten, die das Gerät anbietet; einen Headset Dienst und einen Generic Audio Dienst, auf welchem der Headset Dienst aufbaut. Anschließend werden die Protokolle aufgelistet die benötigt werden. Das Headset benötigt L2CAP und RFCOMM. Damit der Client sich mittels RFCOMM verbinden kann, muss er eine Kanal Nummer kennen, die der Server dem Client unter dem ProtocolSpecificParameter() mitteilt. Als nächstes kommt eine Liste der unterstützten Profile, nebst eines Parameter(); hier wird das Headset Profil in Version 1.0 unterstützt. Es folgt noch ein ServiceName, der Name des Dienstes, der dem Benutzer bei Bedarf angezeigt wird. Schließlich bietet RemoteAudioVolumeControl noch die Möglichkeit, Informationen darüber einzuholen, ob ferngesteuerte Lautstärkeregelung möglich ist. Hier ist das nicht der Fall. Item Type Value Attribute ServiceRecordHandle Uint32 Assigned by Server 0x0000 ServiceClassIDList 0x0001 ServiceClass0 UUID Headset 0x1108 ServiceClass1 UUID Generic Audio 0x1203 ProtocolDescriptorList 0x0004 Protocol0 UUID L2CAP 0x0100 Protocol1 UUID RFCOMM 0x0003 Uint8 Server Channel # BluetoothProfileDescriptorList 0x0009 Profile0 UUID Headset 0x1108 Parameter() Uint16 Version 1.0 0x0100 ServiceName String Headset 0x0000 RemoteAudioVolumeControl Boolean False 0x0302 Tabelle 2.1: SDP Datensatz eines Headset 10

11 SDP Clients und Server ermöglichen den Informationsaustausch durch spezielle Suchanfragen und Suchantworten. Auf eine Suchanfrage des Clients antwortet der Server immer mit einer Suchantwort. So kann der Client mittels ServiceSearchRequest nach einem bestimmten Dienst suchen, worauf der Server mit ServiceSearchResponse antwortet. Der Server schickt eine Liste mit Diensten und dessen ServiceRecordHandle zurück, auf die das Suchmuster passt. Die ServiceAttributeRequest Nachricht ermöglicht dem Client die Attribute eines bestimmten Dienstes zu empfangen. Der Server antwortet durch ServiceAttributeResponse mit einer Liste von Attributen der zutreffenden Dienste. Oft möchte der Client sich zu einem Dienst verbinden, ohne dabei alle Attribute zu kennen. Um diesen Vorgang zu beschleunigen, bietet das SDP den ServiceSearchAttributeRequest, welche die Suche nach Diensten und dessen Attributen vereinigt. Die ServiceSearchAttributeResponse welche der Server zurücksendet enthält eine Liste mit Diensten und dessen benötigten Attributen. Falls ein Server auf eine Suchanfrage nicht einwandfrei antworten kann, so schickt er eine ErrorResponse, die Informationen darüber enthält warum die Suchanfrage nicht beantwortet werden kann. 2.7 RFCOMM RFCOMM bietet die Möglichkeit, serielle Schnittstellen zu simulieren, um gewöhnlichen Anwendungen die Möglichkeit zu verschaffen, Daten zu übertragen. RFCOMM lässt den Zugriff mehrerer Anwendungen gleichzeitig zu, es ist ein einfaches und zuverlässiges Transportprotokoll. Es werden zwei verschiedene Arten von seriellen Schnittstellen unterstützt, zum Einen ein interner simulierter Anschluss, zum Anderen ein physikalischer serieller Anschluss zum Anstecken eines seriellen Kabels. RFCOMM basiert auf dem GSM Standard, welcher ein asymmetrisches Protokoll beschreibt, das von GSM Mobilfunktelefonen genutzt wird, um verschiedene Datenströme über ein serielles Kabel zu übertragen. RFCOMM selbst ist ein symmetrisches Protokoll und übermittelt Daten mittels Frames, welche als Daten im L2CAP Payload transportiert werden. Die Abbildung 2.5 zeigt den generellen Verbindungsaufbau einer RFCOMM Verbindung. Um eine Verbindung zu eröffnen, muss zuerst ein L2CAP Kanal mit dem PSM = 0x0003 eingerichtet werden, dadurch werden alle L2CAP Frames mit diesem PSM an RFCOMM weitergeleitet. Nachdem die L2CAP Verbindung besteht, wird das SABM (Start Asynchronous Balanced Mode) Frame mit dem DLCI = 0 (Data Link Connection Identifier) gesendet. RFCOMM unterscheidet mittels DLCI zwischen den einzelnen Kanälen, wobei Frames mit DLCI = 0 Kontrollnachrichten sind und Frames mit DLCI > 0 benutzt werden, um Daten zu senden. Das entfernte Gerät bestätigt das SABM Frame bei erfolgreicher Verbindung mit dem UA (Unnumbered Acknowledgement) Frame auf dem selben Kanal (DLCI = 0). Es folgen PN- Command und PN-Response, um gegebenenfalls Verbindungsparameter auszuhandeln. PN steht für Parameter Negotiation. Um nun Daten zu übertragen, muss ein weiterer RFCOMM Kanal hergestellt werden, da der bestehende Kanal mit dem DLCI = 0 nur für Kontrollnachrichten vorgesehen ist. Es folgt die erneute Sendung eines SABM Frames, und die Gegenstelle bestätigt dieses erneut mit Hilfe des UA Frame. Anschließend werden Modem Status Commands (MSC) ausgetauscht, um den Status zu überprüfen. Sobald dies geschehen ist, können Benutzerdaten über diesen Kanal übertragen werden. 11

12 Set up L2CAP connection SABM Frame (DLCI = 0) UA Frame (DLCI = 0) Initiating RFCOMM PN Command SABM Frame PN Response Responding RFCOMM UA Frame MSC User Data on UIH Frames Abbildung 2.5: Herstellung einer RFCOMM Verbindung Eine RFCOMM Verbindung wird mittels des DISC (Disconnection) Befehls geschlossen. Dieses Kommando kann zum Schließen eines Kanals gesendet werden; wird es auf Kanal 0 (DLCI = 0) gesendet, so wird die RFCOMM Verbindung getrennt. 2.8 Wireless Access Protocol Das Wireless Access Protocol (WAP) ist ein Protokoll, das mobilen Geräten die drahtlose Benutzung von Datendiensten und den Zugang zum Internet ermöglicht. Der WAP Protokollstack benutzt Bluetooth als Übertragungsmedium. WAP unterstützt eine Client/Server Architektur. Clients sind typischerweise mobile Geräte, ausgestattet mit einem Mikrobrowser, die von einem Server Daten herunterladen möchten. Der WAP Server stellt diese Internetseiten in einem HTML ähnlichen Format bereit. Das WML (Wireless Markup Language) Format bietet ein komprimiertes Format, was aufgrund der geringeren Bandbreitenanforderung vorteilhaft ist. Abbildung 2.6 zeigt die Übertragung von Daten. Zuerst wird, wie bei den oberen Schichten des Bluetooth Protokollstacks üblich, eine L2CAP Verbindung hergestellt. Auf diese wird dann eine RFCOMM Verbindung aufgesetzt, auf die der WAP Protokollstack direkt per PPP (Point to Point Protocol) zugreifen kann. Um Datenpakete von höheren WAP Schichten zu übertragen, muss eine PPP Verbindung aufgebaut und konfiguriert werden. Mithilfe des WSP (Wireless Session Protocol) wird eine Sitzung zwischen dem Client und dem Server eingerichtet. Nun kann der Benutzer durch das angebotene Benutzerinterface, typischerweise ein Mikrobrowser, eine bestimmte Seite anfragen, die der Server dann mittels des WSP übermittelt. Das Wireless Access Protocol bietet eine Reihe weiterer interessante Funktionen, zu der auch die Server Push Unterstützung gehört. Beim Server Push versucht der Server aktiv Verbindungen zu den Clients in seinem Bereich zu starten, um so an alle Clients Daten zu 12

13 Set up L2CAP link for RFCOMM Set up RFCOMM link for WAP WAP Client Open & configure PPP link WSP establishes a session WAP Server URL request WAP content Abbildung 2.6: WAP Datenübertragung versenden. Es gibt viele nützliche Anwendungen, jedoch muss man auch die Sicherheitsrisiken beachten. Der Server wäre in der Lage, ausführbaren Programmcode auf ein Gerät zu laden, und dieses Gerät dazu veranlassen, dieses Programm auszuführen. 2.9 Object Exchange Object Exchange (OBEX) ist ein binäres Protokoll, das einer Vielzahl von Geräten ermöglicht einfach und spontan Daten auszutauschen. OBEX besitzt eine Client/Server Architektur, der Client kann Daten zum Server senden oder von ihm empfangen. Jedes Gerät das OBEX unterstützt, muss sowohl im Client als auch im Server Betrieb laufen. Die OBEX Definition umfasst ein Objekt-Modell, um Datenobjekte zu repräsentieren, und ein Sitzungsprotokoll, um Anfragen und Antworten zwischen den Geräten zu übertragen. Die Spezifikation sieht folgende Regeln vor, um OBEX über RFCOMM zu benutzen: Bluetooth Geräte mit mehreren OBEX Servern müssen jedem einen eigenen RFCOMM Kanal zuordnen. OBEX Server-Anwendungen müssen sich zugleich mit dem zugeordneten RFCOMM Kanal in der SDP Datenbank eintragen. OBEX Pakete werden in RFCOMM Frames transportiert. Der OBEX Betrieb über TCP/IP mittels einer Bluetooth Verbindung ist von der Spezifikation noch nicht festgelegt. Folgende Anforderungen müssen die Geräte jedoch erfüllen: Der Server muss die Port Nummer 650 oder eine über 1023 benutzen, der Client eine über OBEX Server Anwendungen müssen sich in der SDP Datenbank eintragen. Das Objekt-Modell definiert eine Reihe von Headern, um den Datenaustausch zwischen Anwendungen zu standardisieren. Es gibt eine Vielzahl an Headern, die ein Teil des Objekts oder Informationen über dieses enthalten. Die Benutzung von Headern ist nicht zwingend, wenn die Anwendungen genau wissen, in welchem Format sie die Daten übertragen. Das OBEX Sitzungsprotokoll beschreibt die Client/Server Kommunikation. Der Client sendet Anfragen, auf welche der Server Antworten erwidert. Die dazu benutzen Pakete bestehen aus einem OpCode, der die Art des Pakets identifiziert. Es folgt ein Feld mit der Länge des Pakets, und danach die zu transportierenden Header. Es existieren sechs OpCodes, die zugleich die OBEX Operationen anzeigen. Der Connect und Disconnect OpCode wird benutzt, um eine OBEX Verbindung herzustellen oder zu trennen. Put dient zum Senden von Objekten, Get wird benutzt, um ein Objekt anzufordern. Der OpCode SetPath ermöglicht die Einstellung des Verzeichnisses, in der die Objekte 13

14 gespeichert werden. Schließlich besteht noch die Abort Operation, die eine Prozedur beendet bevor sie normal ausgeführt wird. Nachdem eine L2CAP und eine RFCOMM Verbindung für OBEX eingerichtet wurde, kann man mit den vorher aufgeführten Befehlen eine OBEX Sitzung einleiten und Objekte ähnlich wie in einem Dateisystem austauschen. Eine Anfrage wird dabei immer mit einem Success Paket beantwortet, oder, falls ein Objekt wegen der Größe über mehrere Pakete transportiert wird, mit einem Continue Paket. Die Verbindung wird, falls sie nicht mehr benötigt wird, mit Disconnect getrennt, worauf der Server ebenfalls mit einem Success Paket antwortet Telephony Control Protocol Die Bluetooth Telephony Control protocol Specification (TCS) beschreibt, wie Telefongespräche über eine Bluetooth Verbindung übertragen werden. Ein Beispiel für den Gebrauch von TCS wäre ein Mobilfunktelefon, das ein Gespräch per Bluetooth durch Benutzung von TCS an einen Laptop weiterleitet, um diesen dann als Freisprechanlage zu benutzen. Die mit TCS zu übertragende Sprache oder Daten liefert eine Benutzeranwendung. Die Spezifikation sieht ebenfalls eine Mehrfachnutzung von TCS vor, jede Instanz erhält eine eigene L2CAP Kanal Nummer. L2CAP channel setup Outgoing TCS SETUP Call accepted Incoming TCS Speech/Data channel setup Abbildung 2.7: Aufbau einer TCS Verbindung Abbildung 2.7 zeigt den Aufbau einer Punkt zu Punkt Verbindung. Da die Sprache in L2CAP Paketen transportiert wird, muss zuerst ein L2CAP Kanal mit dem PSM = 0x0005 eingerichtet werden. Im Anschluss daran wird eine Setup Nachricht, die alle notwendigen Informationen über den Anruf enthält, gesendet. Üblicherweise sollte die Anwendung zu diesem Zeitpunkt den Benutzer über den Anruf informieren, dieser kann dann den Anruf annehmen oder ablehnen. Im Falle das er den Anruf annimmt, wird ein Call accepted Signal zurückgesendet. Nun kann ein weiterer L2CAP Kanal erstellt werden. Dies kann eine ACL Verbindung oder die für Sprache besser geeignete SCO Verbindung sein, über dem dann die Sprache oder Daten übertragen werden. 3. Bluetooth Anwendungsprofile Bluetooth Profile beschreiben wie die Bluetooth Spezifikation in Anwendungen benutzt wird. Das Ziel ist die Realisierung einer Endbenutzeranwendung, die zuverlässig mit anderen Geräten verschiedener Hersteller zusammenarbeiten kann. Sie definieren eine einheitliche Benutzung der unteren Bluetooth Schichten. Die verschiedene Profile lassen sich in Gruppen unterteilen, wie die Abbildung 3.1 zeigt. 14

15 Generic Access Profile Telephony Control Protocol Specifikation Service Discovery Applikation Profile Cordless Telephony Profile Intercom Profile Serial Port Profile Dial-Up Networking Profile FAX Profile Generic Object Exchange Profile File Transfer Profile Object Push Profile Headset Profile LAN Access Profile Synchronisation Profile Abbildung 3.1: Einteilung der Profile Jedes Profil erbt die Funktionen und Eigenschaften der Gruppen darunter. Das Generic Access Profile ist das fundamentale Profil, auf dem alle anderen Profile aufbauen. Das Ziel des Generic Access Profile ist es, den unterschiedlichen Geräten einen erfolgreichen Aufbau einer Baseband Verbindung zu ermöglichen. Um dies zu garantieren, definiert das Generic Access Profil Merkmale, die in allen Geräten implementiert werden müssen; allgemeine Prozeduren, um andere Bluetooth Geräte zu finden; Link-Manager Möglichkeiten, um sich mit anderen Geräten zu verbinden und Prozeduren, um die verschiedenen Sicherheitslevel zu benutzen. Des weiteren wird das Parameterformat, welches von der Benutzerschnittstelle zugänglich ist, festgelegt. Auf dem Generic Access Profile aufbauend sitzt das Serial Port Profile. Dieses Profil beschreibt wie die durch RFCOMM unterstütze Simulation von seriellen Schnittstellen benutzt wird, um gewöhnliche Anwendungen auch auf Bluetoothfähigen Geräten zu betreiben. Aufbauend auf dem Generic Access Profile befindet sich das Dial-Up Networking Profile, das eine Bluetooth Verbindung zu einem Modem, und von da aus in ein Telefonnetzwerk beschreibt. Das FAX Profile stellt Prozeduren für die drahtlose FAX Übertragung da, das Headset Profile bietet die Möglichkeiten, eine bidirektionale Verbindung zu einem Headset zu implementieren. Ein Bluetooth Gerät kann sich zu einem LAN Access Point verbinden, was durch das LAN Access Profile beschrieben wird. Eine weitere Gruppe, die auf der Seriellen Schnittstelle basiert, ist die des Generic Object Exchange Profile. Diese Gruppe benutzt OBEX zur Datenübertragung und hat drei weitere Profile. Das File Transfer Profile ermöglicht Geräten, per Bluetooth Dateien auszutauschen. Um Visitenkarten auszutauschen, bietet das Object Push Profile die benötigten Richtlinien. Das Synchronisation Profile dient zur Datensynchronisation zweier Bluetooth Geräte. Zwei weitere Profile basieren auf der Telephony Control Protocol Specification. Zum Einen das Cordless Telephony Profile, welches bei Verbindungen zwischen Bluetooth Geräten und Telefonanlagen zum Einsatz kommt, zum Anderen das Intercom Profile, das Sprachverbindungen zwischen Bluetooth Geräten beschreibt. 15

16 4. Zusammenfassung Bluetooth ist eine moderne Funktechnologie, die drahtlose Übertragung und Kompatibilität vereinigt. Unter der Leitung der IEEE Arbeitsgruppe entstand ein Protokollstack, der diesen Anforderungen gerecht werden soll. Durch die Trennung des Protokollstacks in Bluetooth Modul und Host, mittels des Host Controller Interface, ist eine Entwicklung von Bluetooth Modulen mit einem Stückpreis von unter 5 US $ beabsichtigt. Die komplexe Sammlung von Protokollen erlaubt vielen verschiedenen Anwendungen eine effiziente Benutzung dieser Funktechnologie. Dadurch, das eine Simulation von seriellen Schnittstellen vorgesehen ist, ist Bluetooth auch für herkömmliche Anwendungen interessant, so könnten in naher Zukunft beispielsweise Autos mit einem Modul ausgestattet werden, um so in der Werkstatt oder an der Tankstelle kabellos Informationen über den Zustand des Autos zu übertragen. Durch die Anwendungsprofile, die den Entwicklern Richtlinien beschreiben, wie sie eine gewünschte Anwendung zu implementieren haben, ist sichergestellt, dass die Anwendung mit verschiedenen Bluetooth Modulen zusammenarbeitet. Bluetooth entwickelt sich zu einem ernstzunehmenden Standard für die mobile Kommunikation. Ein neuer Bluetooth-Standard ist derzeit in der Entwicklung, darin ist eine Datenübertragungsgeschwindigkeit von bis zu 10 MBit/s vorgesehen. 5. Literaturverzeichnis 1. Jennifer Bray und Charles F Sturman, Bluetooth Connect Without Cables, Prentice Hall, Bluetooth Specification Book, zum Beispiel online unter: 16