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.

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.

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.

LMP wird für die Steuerung der Funkverbindung zwischen zwei Geräten verwendet und ist im Controller implementiert. Es dient zusammen mit L2CAP aus dem Host Stack als Sicherungsschicht im Bluetooth-Protokoll-Stack.

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.

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.

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 oder zur ACL-Verbindung weiter.

Funktionen von L2CAP sind unter anderem:

• Multiplexen von Daten zwischen unterschiedlichen Protokollen höherer Ebenen
• Segmentierung und Wiederzusammenfügung von Paketen
• Bereitstellung der Verwaltung unidirektionaler Übertragungen von Multicast-Daten zu einer Gruppe von anderen Bluetooth-Geräten
• Verwaltung der 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 kann L2CAP für zuverlässige oder asynchrone Daten pro Kanal konfiguriert werden, indem erneute Übertragungen und CRC-Prüfungen durchgeführt werden.

Die Zuverlässigkeit in jedem dieser Modi wird optional oder zusätzlich durch die Bluetooth-BDR- oder EDR-Luftschnittstelle der unteren Schicht garantiert, indem die Anzahl der Neuübertragungen und das Löschzeitlimit (Zeit, nach der das Funkgerät Pakete löscht) konfiguriert werden. Die Zusammensetzung in der richtigen Reihenfolge wird durch die untere Schicht garantiert.

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

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 Subnetwork Access Protocol (SNAP) in WLAN.

Im Protokoll-Stack ist BNEP an L2CAP gebunden.

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.

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.

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 Telephony Control Protocol wird nicht TCP genannt, damit Verwechslung mit Transmission Control Protocol (TCP), welches für Internetkommunikation verwendet wird, zu vermeiden.

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.

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; 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, einfaches Drucken, Telefonbuchzugriff etc.).

Vergleichbar mit 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.

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

Im Protokoll-Stack ist SMP an L2CAP gebunden.

• Bluetooth.com | Architecture - Data Transport
• Using the Java APIs for Bluetooth Wireless Technology
• Specifications – Bluetooth® Technology Website