Bluetooth und BLE: Was es ist, Unterschied zwischen Classic und Low Energy und wie es funktioniert

Was sind Bluetooth und BLE?

Bluetooth ist ein drahtloser Personal Area Network (WPAN)-Standard, der im 2,4-GHz-ISM-Band arbeitet und für die Kommunikation von Geräten über Entfernungen von bis zu 100 Metern ausgelegt ist. Die IEEE-802.15.1-Spezifikation definiert die physikalische und die MAC-Schicht, während der Bluetooth-SIG-Stack Profile auf hoher Ebene für bestimmte Szenarien definiert: Audio-Headset (HSP), Dateiübertragung (OPP), Tastatureingabe (HID).

Der Standard hat sich seit Version 4.0 (2010) in zwei Zweige aufgeteilt: Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) und Bluetooth Low Energy (BLE, früher Bluetooth Smart). Classic ist für kontinuierliche Ströme ausgelegt — Audioanrufe, Musik, Dateien. BLE wurde für Anwendungen entwickelt, bei denen Daten in kurzen Paketen mit Pausen von mehreren zehn Sekunden oder Minuten übertragen werden — Herzfrequenzmesser, Tags, Temperatursensoren.

Laut Bluetooth SIG (2025) unterstützen 99 % der neuen Smartphones beide Versionen, und das BLE-Ökosystem umfasst mehr als 15 Profiltypen von Blood Pressure bis Environmental Sensing.

Bluetooth Classic vs BLE: Vergleich

Die Wahl zwischen Classic und BLE hängt vom Szenario ab: Für Audio-Streaming ist nur Classic geeignet, für das Abfragen eines Sensors einmal pro Stunde — nur BLE. BR/EDR verwendet 79 Kanäle mit 1 MHz Abstand und adaptives Frequenzsprungverfahren (AFH), das Widerstandsfähigkeit gegen Wi-Fi-Störungen bietet.

BLE 5.x hat LE Coded PHY für eine größere Reichweite von bis zu 1 km (im Freien) und LE Audio mit LC3-Codec hinzugefügt — die neue Version verwischt allmählich die Grenze zwischen Classic und BLE für Audio-Szenarien.

BLE-Architektur: Controller, Host und Application

Der BLE-Stack ist in drei Schichten unterteilt: Controller (physikalische und Verbindungsschicht), Host (L2CAP, ATT, GATT, Security Manager) und Application (Profilimplementierung in der App). Diese Trennung ermöglicht es dem Chip-Hersteller, den Controller in der Firmware zu implementieren, während der Mobile-App-Entwickler nur mit GATT-Abstraktionen arbeitet.

Die Verbindungsschicht (LL) verwaltet die Sendezeit: Das Gerät wechselt zwischen den Zuständen Standby, Advertising, Scanning, Initiating und Connection. Im verbundenen Zustand einigen sich Central und Peripheral auf ein Verbindungsintervall — die Häufigkeit, mit der sie Datenpakete austauschen. Ein typisches Intervall beträgt 7,5–1000 ms; je häufiger der Austausch, desto höher der Durchsatz und desto größer der Stromverbrauch.

Der Security Manager (SM) implementiert AES-128-Verschlüsselung mit Schlüsselaustausch über das Pairing-Protokoll. Es gibt drei Modi: Just Works (ohne PIN-Eingabe), Passkey Entry (6-stelliger Code auf dem Bildschirm) und OOB (NFC oder QR). Für Wearables wird normalerweise Just Works verwendet, für medizinische Geräte OOB mit zusätzlicher Verifizierung.

Laut Bluetooth Core Specification 5.4 (2023) überschreitet die Einrichtungszeit einer sicheren Verbindung im LE Secure Connections-Modus bei einem Verbindungsintervall von 30 ms nicht 300 ms.

GATT-Profil: Dienste, Eigenschaften und Deskriptoren

Das ATT (Attributprotokoll) ist das grundlegende Transportmodell, bei dem der Server (Peripheriegerät) Attribute speichert und der Client (Smartphone) sie liest oder schreibt. GATT (Generic Attribute Profile) baut eine Hierarchie über ATT auf: Service → Characteristic → Descriptor.

Jeder Dienst ist eine logische Gruppe von Eigenschaften, die eine Gerätefunktion beschreiben: Heart Rate Service (UUID 0x180D) enthält die Heart Rate Measurement-Eigenschaft (UUID 0x2A37) mit einem Client Characteristic Configuration-Deskriptor (0x2902), der Benachrichtigungen steuert. Der Mobile-App-Entwickler erhält die Liste der Dienste über discoverServices(), findet dann die gewünschte Eigenschaft per UUID und abonniert Benachrichtigungen.

BLE verwendet 16-Bit-UUIDs für standardisierte Bluetooth-SIG-Dienste und 128-Bit-UUIDs für kundenspezifische Herstellerdienste. Beispielsweise kann ein Tracker-Etui einen Dienst A000-… mit einer Eigenschaft zur Übertragung des Akkuladestands definieren.

Beispiel für die Arbeit mit GATT in Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Puls: $heartRate Schläge/min")
    }
}

Im Beispiel findet die App den Heart Rate-Dienst anhand der standardmäßigen Bluetooth-SIG-UUID, ruft die Herzfrequenzmessungs-Eigenschaft ab und abonniert deren Benachrichtigungen — bei jeder Änderung der Herzfrequenz sendet das Peripheriegerät Daten ohne explizite Anfrage vom Central.

Advertising, Scannen und Verbindungsaufbau

Advertising ist ein zentraler BLE-Mechanismus, bei dem ein Peripheral-Gerät periodisch Broadcast-Pakete (Advertising-PDUs) auf drei primären Kanälen (37, 38, 39) sendet. Das zentrale Gerät scannt diese Kanäle, empfängt Advertising-Daten und kann eine Verbindung initiieren.

Ein Advertising-Paket enthält bis zu 31 Byte Nutzdaten: Flags, TX-Leistungspegel, lokaler Name, Dienst-UUIDs, herstellerspezifische Daten. Dies reicht aus, um Sensorwerte ohne Verbindungsaufbau zu übertragen — Verbindungsloser Modus (Broadcaster-Typ). Für die kontinuierliche Datenübertragung (z. B. Temperatur einmal pro Minute) wird eine Verbindung mit einem Verbindungsintervall von bis zu 1000 ms verwendet.

Auf mobilen Plattformen wird das Scannen über startScan() (Android) oder scanForPeripherals() (iOS) gestartet. Die Filterung nach Dienst-UUID spart Energie, da nicht alle sichtbaren Geräte verarbeitet werden müssen — die App erhält nur für relevante Tags oder Sensoren einen Callback.

Beispiel für das Scannen von BLE-Geräten in Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Gerät gefunden: \(name)")
        }
    }
}

Nach dem Erkennen eines Geräts ruft der Central connect() auf und übergibt das CBPeripheral-Objekt. Die Verbindungsparameter (Intervall, Latenz, Überwachungs-Timeout) werden auf der Verbindungsschicht ausgehandelt — der Entwickler verwaltet sie nicht direkt, kann sie aber über requestConnectionPriority auf Android beeinflussen.

Bluetooth LE in der mobilen Entwicklung: Core Bluetooth und android.bluetooth

Beide mobilen Plattstellen bieten native APIs für die Arbeit mit BLE. Core Bluetooth (iOS) verwendet einen Delegatenansatz: Der zentrale Manager initiiert Operationen, und das Peripherieobjekt meldet Ergebnisse über Delegatenmethoden. android.bluetooth (Android) ist auf Callback-Schnittstellen aufgebaut und unterstützt parallele GATT-Operationen mit mehreren Geräten.

Hauptunterschiede zwischen den Plattformen:

• iOS — unterstützt bis zu 7 gleichzeitige Verbindungen; der Hintergrund-BLE-Modus erfordert UIBackgroundModes = bluetooth-central; nach Verlassen des Vordergrunds kann das System Callbacks um mehrere Minuten verzögern
• Android — keine feste Verbindungsgrenze (durch Speicher begrenzt); erfordert BLUETOOTH_SCAN- und BLUETOOTH_CONNECT-Berechtigungen (Android 12+); ein Vordergrunddienst ist für zuverlässiges Scannen im Hintergrund erforderlich
• Flutter — das Paket flutter_blue_plus abstrahiert Plattform-APIs mit einer einheitlichen Dart-Schnittstelle: Der Code für Scannen und GATT-Operationen ist auf beiden Plattformen identisch

Laut Bluetooth-SIG-Tests (2024) beträgt die BLE-Verbindungszeit zwischen einem Smartphone und einem Fitness-Tracker im Durchschnitt 150–300 ms auf Android und 100–250 ms auf iOS — der Unterschied ist auf die Richtlinien zur Verwaltung des Funkmoduls zurückzuführen.

Beispiel für eine BLE-Verbindung in Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

Ein Flutter-Entwickler erhält eine einheitliche API-Schnittstelle; unter der Haube übersetzt flutter_blue_plus Aufrufe in natives android.bluetooth oder Core Bluetooth. Dieser Ansatz verkürzt die App-Entwicklungszeit für die Arbeit mit BLE-Peripherie auf beiden Plattformen.