Liste der Bluetooth-Protokolle

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von RFCOMM)
Zur Navigation springen Zur Suche springen

Der kabellose Datenaustauschstandard Bluetooth verwendet eine Vielzahl an Protokollen. Kern-Protokolle werden von der Bluetooth SIG definiert. Zusätzliche Protokolle wurden von anderen Standardisierungsorganisationen verabschiedet. Dieser Artikel gibt eine Übersicht über die Kern-Protokolle und die weit verbreiteten übernommenen Protokolle.

Der Bluetooth Protocol Stack kann in zwei Teile geteilt werden: Der "Controller Stack" enthält die zeitkritische Funkschnittstelle und der "Host Stack" behandelt höherliegende Daten. Der Controller Stack ist üblicherweise in günstigen Hardwareeinheiten implementiert, welche das Funkequipment und einen Mikroprozessor enthalten. Der Host Stack ist üblicherweise als Teil des Betriebssystems oder als Programm für das Betriebssystem implementiert. Für integrierte Geräte wie Bluetooth Headsets kann der Host Stack und der Controller Stack auf demselben Mikroprozessor laufen, um Massenproduktionskosten zu reduzieren. Das wird Hostless System genannt.

Controller Stack[Bearbeiten | Quelltext bearbeiten]

Asynchronous Connection-Less [Logischer Transport] (ACL)[Bearbeiten | Quelltext bearbeiten]

Der normale Typ der Funkverbindung für gewöhnliche Datenpakete verwendet ein Polling TDMA Schema für einen beliebigen Zugriff. Er kann Pakete verschiedener Typen übertragen, welche durch folgende Kriterien unterschieden werden:

  • Länge (1, 3, oder 5 Zeitschlitze abhängig von der benötigten Payloadgröße)
  • Forward Error Correction (optional wird die Datenrate zu Gunsten der Zuverlässigkeit reduziert)
  • Modulation (Enhanced Data Rate Pakete erlauben eine bis zu drei fach höhere Datenrate indem eine andere HF Modulation für die Payload verwendet wird)

Eine Verbindung zwischen den zwei Geräten muss explizit eingerichtet und akzeptiert werden, bevor Pakete übertragen werden können.

ACL Pakete werden automatisch erneut übertragen, wenn sie unbestätigt bleiben. Das ermöglicht die Korrektur von gestörten Funkverbindungen. Für isochrone Daten kann die Anzahl an erneuten Übertragungen durch ein flush timeout limitiert werden. Wenn allerdings der Retransmission und Flow Control Modus von L2PLAY nicht verwendet wird, muss sich eine höhere Schicht um den Paketverlust kümmern.

ACL Verbindungen werden getrennt, wenn in einem bestimmten Zeitraum nichts empfangen wurde. Das sind standardmäßig 20 Sekunden. Dies kann aber durch den Master geändert werden.

Synchronous Connection-Oriented (SCO) link[Bearbeiten | Quelltext bearbeiten]

Diese Funkverbindung wird für Sprachdaten verwendet. Eine SCO Verbindung ist eine Reihe von reservierten Zeitschlitzen einer bestehenden ACL Verbindung. Jedes Gerät sendet enkodierte Sprachdaten im reservierten Zeitschlitz. Es gibt keine wiederholten Übertragungen, aber optional kann Vorwärtsfehlerkorrektur angewendet werden.

Enhanced SCO (eSCO) Verbindungen ermöglichen größere Flexibilität in der Einrichtung von Verbindungen: Um Zuverlässigkeit zu erreichen können Pakete im Fehlerfall erneut übertragen werden. Sie erlauben eine weitere Anzahl an Pakettypen und größere Intervalle zwischen Paketen als SCO. Dadurch wird die Verfügbarkeit des Funkkanals für andere Verbindungen erhöht.

Link Management Protokoll (LMP)[Bearbeiten | Quelltext bearbeiten]

Wird für die Steuerung der Funkverbindung zwischen zwei Geräten verwendet. Ist im Controller implementiert. Dient zusammen mit L2CAP aus dem Host Stack als Sicherungsschicht im Bluetooth Protokoll Stack.

Host Controller Interface (HCI)[Bearbeiten | Quelltext bearbeiten]

Standardisierte Kommunikation zwischen dem Host Stack (z. B. ein PC oder Smartphone OS) und dem Controller (Der Bluetooth Integrated Circuit (IC)). Dieser Standard macht den Host Stack oder den Controller IC mit wenig Aufwand austauschbar.

Es gibt einige HCI Transportschicht Standards, von denen alle eine andere Hardwareschnittstelle für die Übertragung der gleichen Kommandos, Events und Datenpakete verwenden. Die am meisten verwendete Schnittstelle ist USB (in PCs) und UART (in Smartphones).

Bei Geräten mit einfacher Funktionalität (z. B. Headsets) kann der Host Stack und der Controller in denselben Mikroprozessor integriert werden. Dann ist HCI optional, wird aber trotzdem oft als interne Software Schnittstelle implementiert.

Low Energy Link Layer (LE LL)[Bearbeiten | Quelltext bearbeiten]

LE LL ist das LMP Äquivalent für Bluetooth Low Energy (LE). Es ist allerdings deutlich einfacher. Es ist auf dem Controller implementiert und verwaltet Advertisements, Scanning, Connection und Security aus einer low-level, hardwarenahen Sicht aus Bluetooth Perspektive.

Host Stack[Bearbeiten | Quelltext bearbeiten]

Logical Link Control and Adaptation Protokoll (L2CAP)[Bearbeiten | Quelltext bearbeiten]

L2CAP wird innerhalb des Bluetooth Protokoll Stacks verwendet. Es reicht Pakete entweder zum Host Controller Interface (HCI) oder, bei einem hostlosen System, direkt zum Link Manager/ zur ACL Verbindung weiter.

Funktionen von L2CAP sind unter anderem:

  • Multiplexen von Daten zwischen unterschiedlichen Protokollen höherer Ebenenen.
  • Segmentierung und Wiederzusammenfügung von Paketen.
  • Bereitstellen von Verwaltung unidirektionaler Übertragungen von Multicast Daten zu einer Gruppe von anderen Bluetooth Geräten.
  • Verwaltung von Quality of service (QoS) für Protokolle höherer Ebenen.

L2CAP wird verwendet, um über ACL Verbindungen zu kommunizieren. Seine Verbindung wird aufgebaut, nachdem die ACL Verbindung eingerichtet wurde.

Im Basismodus stellt L2CAP Pakete mit einer konfigurierbaren Payloadgröße bis zu 64 kB, mit 672 Byte als standard MTU und 48 Byte als minimale verpflichtende unterstützte MTU bereit. Im Retransmission und Flow Control Modus kan L2CAP für zuverlässige oder asynchrone Daten pro Kanal konfiguriert werden, indem erneute Übertragungen und CRC-Prüfungen durchgeführt werden.

Reliability in either of these modes is optionally and/or additionally guaranteed by the lower layer Bluetooth BDR/EDR air interface by configuring the number of retransmissions and flush timeout (time after which the radio will flush packets). In-order sequencing is guaranteed by the lower layer.

Die EL2CAP Spezifizierung fügt einen zusätzlichen Enhanced Retransmission Modus (ERTM) zur Kernspezifikation hinzu, der eine verbesserte Version des Retransmission und Flow Control Moduses ist. ERTM ist für die Verwendung von AMP (Alternate MAC/PHY), wie IEEE 802.11abgn notwendig.

Bluetooth Network Encapsulation Protokoll (BNEP)[Bearbeiten | Quelltext bearbeiten]

BNEP wird verwendet, um Netzwerkpakete über L2CAP zu versenden. Dieses Protokoll wird vom Personal Area Networking (PAN) Profil verwendet. BNEP nimmt die gleiche Funktion ein, wie das Subnetwrok Access Protocol (SNAP) in WLAN.

Im Protokoll Stack ist BNEP an L2CAP gebunden.

Radio Frequency Communication (RFCOMM)[Bearbeiten | Quelltext bearbeiten]

Das Protokoll RFCOMM ist eine Reihe einfacher Transport Protokolle, die auf dem L2CAP Protokoll agieren und emulierte RS-232 Serial Ports zur Verfügung stellen (bis zu 60 simultane Verbindungen zu einem Bluetooth Gerät gleichzeitig). Das Protokoll basiert auf dem ETSI Standard TS 07.10.

RFCOMM wird auch Serial Port Emulation genannt. Das Bluetooth Serial Port Profil (SPP) basiert auf diesem Protokoll.

RFCOMM stellt, wie TCP, einen einfachen und zuverlässigen Datenstrom zum User dar. Es wird direkt von vielen Telefon Profilen zur Übertragung von AT Kommandos verwendet und dient als Transportschicht für OBEX über Bluetooth.

Viele Bluetooth Anwendungen verwenden RFCOMM wegen der verbreiteten Unterstützung und wegen der unter den meisten Betriebssystemen öffentlich zugänglichen Programmierschnittstelle. Zusätzlich können Anwendungen, die eine Serielle Schnittstelle für die Kommunikation verwenden, einfach auf RFCOMM portiert werden.

Im Protokoll Stack ist RFCOMM an L2CAP gebunden.

Service Discovery Protokoll (SDP)[Bearbeiten | Quelltext bearbeiten]

Wird verwendet, damit Geräte herausfinden können, welche Dienste das andere anbietet und welche Parameter verwendet werden müssen, um sich zu ihnen zu verbinden. Wenn sich z. B. ein Smartphone mit einem Bluetooth Headset verbindet, wird SDP verwendet, um herauszufinden, welche Bluetooth-Profile vom Headset unterstützt werden (Headset Profil, Hands Free Profil, Advanced Audio Distribution Profil, etc.) und welche Protokoll-Multiplexer-Einstellungen benötigt werden, um sich mit ihnen zu verbinden. Jeder Dienst wird durch einen Universally Unique Identifier (UUID) identifiziert. Offizielle Dienste (Bluetooth-Profile) haben eine kurze UUID-Form (16 statt den vollen 128 Bit).

Im Protokoll-Stack ist SDP an L2CAP gebunden.

Telephony Control Protokoll (TCS)[Bearbeiten | Quelltext bearbeiten]

Auch telephony control protocol specification binary (TCS binary) genannt.

Wird verwendet, um Sprach und Daten Anrufe zwischen Bluetooth Geräte aufzubauen und zu verwalten. Das Protokoll basiert auf dem ITU-T Standard Q.931. Es wurden die Bestimmungen von Annex D angewandt und minimale Änderungen vorgenommen.

TCS wird von Intercom (ICP) und Cordless Telephony (CTP) Profilen verwendet. Das Telephone Control Protokolllwird nicht TCP genannt, damit Verwechslung mit Transmission Control Protocol (TCP), welches für Internetkommunikation verwendet wird, zu vermeiden.

Audio/Video Control Transport Protokoll (AVCTP)[Bearbeiten | Quelltext bearbeiten]

Wird vom Remote Control Profil zur Übertragung von AV/C Kommandos über einen L2CAP Kanal verwendet. Die Musiksteuerungsknöpfe an einem Stereo Headsets verwenden dieses Protokoll um den Musik Player zu kontrollieren.

Im Protokoll Stack ist AVCTP an L2CAP gebunden.

Audio/Video Data Transport Protokoll (AVDTP)[Bearbeiten | Quelltext bearbeiten]

Wird vom Advanced Audio Distribution Profil zum Streamen von Musik zu Stereo Headsets über L2CAP Kanäle verwendet. Zur Verwendung von Videoverteilungsprofilen vorgesehen.

Im Protokoll Stack ist AVDTP an L2CAP gebunden.

Object Exchange (OBEX)[Bearbeiten | Quelltext bearbeiten]

Object Exchange (OBEX; auch IrOBEX genannt) ist ein Kommunikationsprotokoll, das den Austausch von binären Objekten zwischen Geräten ermöglicht. Es wird von der Infrared Data Association verwaltet, aber wurde außerdem von der Bluetooth Special Interest Group und der SyncML Flügel der Open Mobile Alliance (OMA) übernommen.

OBEX wird in Bluetooth für viele Profile verwendet, die einfachen Datenaustausch benötigen (z. B. Object Push, Datenübertragung, einfachen Drucken, Telefonbuch Zugriff, etc.).

Low Energy Attribute Protokoll (ATT)[Bearbeiten | Quelltext bearbeiten]

Vergleichbar zu SDP aber speziell für Low Energy Bluetooth angepasst und vereinfacht. Es ermöglicht dem Client bestimmte vom Server veröffentlichte Attribute in einer einfachen und low-power freundlichen Art und Weise zu lesen und zu schreiben.

Im Protokoll Stack ist ATT an L2CAP gebunden.

Low Energy Security Manager Protokoll (SMP)[Bearbeiten | Quelltext bearbeiten]

SMP wird von Bluetooth Low Energy Implementierungen zur Verteilung von Pairing und Transport spezifischen Schlüsseln verwendet.

Im Protokoll Stack ist SMP an L2CAP gebunden.

Weblinks[Bearbeiten | Quelltext bearbeiten]