MTU in BLE: Was es ist, Paketgröße und Aushandlung

Autor: IT Sectr Veröffentlicht: 2026-07-15 Lesezeit: 10 Min.

MTU (Maximum Transmission Unit) ist die maximale Größe der Nutzdaten in einem BLE-Paket, die in einer einzigen GATT-Transaktion zwischen Geräten übertragen werden kann. In BLE Classic (4.x) ist die MTU auf 23 Byte festgelegt, was für kleine Sensorwerte ausreicht, aber für Dateiübertragungen oder OTA-Updates unzureichend ist. Die Bluetooth Core Specification 4.2 (2014) führte das MTU Size Request-Verfahren ein, das die Aushandlung einer größeren MTU — bis zu 247 Byte (BLE 5.0 — bis zu 251 Byte) — ermöglicht. Die korrekte MTU-Konfiguration ist einer der wichtigsten Leistungsfaktoren für BLE-Anwendungen, die große Datenmengen übertragen.

Wichtige Punkte

  • MTU — die maximale Datengröße in einem BLE-Paket, von 23 Byte (BLE 4.x) bis 251 Byte (BLE 5.0).
  • Die MTU-Aushandlung erfolgt nach dem Aufbau einer GATT-Verbindung über MTU Size Request/Response.
  • Eine große MTU (247 Byte) erhöht die Datenübertragungsgeschwindigkeit um das 5–10-Fache im Vergleich zu den standardmäßigen 23 Byte.
  • Android fordert automatisch eine 517 Byte MTU mit BLE 5.0 an, iOS fordert 512 Byte über requestMTU an.
  • Bei OTA-Firmware-Updates verkürzt eine große MTU die Übertragungszeit von Minuten auf Sekunden.

Was ist MTU in BLE?

Maximum Transmission Unit (MTU) ist im Kontext von BLE die maximale Größe einer Application Protocol Data Unit (APDU), die ein Gerät in einer einzigen GATT-Anfrage akzeptieren kann. Die MTU wird auf ATT-Ebene (Attribute Protocol) definiert und umfasst den ATT-Header (1 Byte) + Nutzdaten. Standardmäßig unterstützen alle BLE-Geräte eine MTU von 23 Byte (23 = 1 Byte ATT-Header + 22 Byte Daten).

Die MTU ist keine physikalische Begrenzung des Funkkanals, sondern eine Vereinbarung zwischen Geräten auf GATT-Ebene. Die physikalische Größe des BLE-Pakets auf der Link Layer kann größer sein (bis zu 27 Byte in BLE 4.0, bis zu 257 Byte in BLE 5.0 mit Data Length Extension), aber die GATT-Schicht begrenzt, wie viele Daten pro Transaktion übertragen werden. Data Length Extension (DLE) ist ein separater Link-Layer-Mechanismus, der das physikalische Paket auf 251 Byte erhöht und separat ausgehandelt werden muss.

Der Unterschied zwischen MTU und DLE: ATT MTU — wie viele Daten pro GATT-Anfrage übertragen werden, DLE — wie viele Daten in ein Link-Layer-Paket passen. Für maximale Geschwindigkeit müssen beide Parameter ausgehandelt werden. Ohne DLE werden Daten selbst bei einer MTU von 247 Byte in mehrere 27-Byte-Link-Layer-Pakete fragmentiert, was den Durchsatz verringert.

MTU-Aushandlung: Verfahren und Protokoll

MTU Size Request — ein Verfahren, das vom Central nach dem Aufbau einer GATT-Verbindung initiiert wird. Der Central sendet eine MTU Request mit Angabe seiner MTU-Kapazität (der maximalen Größe, die er akzeptieren kann). Der Peripheral antwortet mit einer MTU Response mit seinem eigenen Wert. Die resultierende MTU ist der kleinere der beiden Werte. Bietet der Central MTU 512 an und unterstützt der Peripheral nur 128, verwendet die Verbindung MTU 128.

swift
import CoreBluetooth

// Maximale MTU auf iOS anfordern
func requestMTU(central: CBCentralManager,
                    peripheral: CBPeripheral) {
    peripheral.maximumWriteValueLength(
        for: .withoutResponse
    )

// iOS handelt MTU automatisch bei Verbindung aus
            // MTU = 512 für BLE 5.0-Geräte
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

    print("Ausgehandelte MTU: " +
          String(mtu))
}

Zeitpunkt der Aushandlung: Die MTU Request sollte nach der Service-Erkennung (discoverServices), aber vor Beginn der aktiven Datenübertragung gesendet werden. In iOS Core Bluetooth wird die MTU beim Verbinden automatisch ausgehandelt — der Entwickler muss keine MTU Request manuell senden. In Android muss requestMTU explizit aufgerufen werden. Einmal ausgehandelt, bleibt die MTU für diese Verbindung fest — eine erneute Aushandlung ist ohne Trennen und erneutes Verbinden nicht möglich.

ATT-Einschränkungen: Warum MTU 251 Byte nicht überschreiten kann

ATT (Attribute Protocol) — das Protokoll, auf dem GATT aufbaut. Ein ATT-Paket hat eine maximale Größe von 257 Byte (ATT_MTU-1). Davon sind 1 Byte Opcode (Operationstyp), 1 Byte Handle und bis zu 255 Byte Value. Daher beträgt die maximal von der ATT-Spezifikation erlaubte MTU 257 Byte (in der Praxis werden jedoch bis zu 251 Byte verwendet, da immer noch einige Overhead-Felder benötigt werden).

Zum Senden von Daten, die größer als die MTU sind, wird auf Anwendungsebene die Fragmentierung verwendet. Der Entwickler teilt die Daten manuell in Blöcke der Größe ≤ MTU auf und sendet sie sequenziell. Jeder Block wird als separate GATT Write Request gesendet. Die empfangende Seite setzt die Blöcke zu einem einzigen Puffer zusammen. GATT bietet keine integrierte Fragmentierungsunterstützung — dies liegt in der Verantwortung des Entwicklers.

BLE-VersionMax. MTUMax. DLEATT MTU-Grenze
BLE 4.0 / 4.123 Byte27 ByteATT fest
BLE 4.2247 Byte251 Byte257 Byte
BLE 5.0251 Byte251 Byte257 Byte
Android + iOS512 / 517251 ByteÜberschreitet ATT

Interessante Tatsache: iOS und Android fordern MTU 512 bzw. 517 Byte an, aber dieser Wert überschreitet die ATT-Grenze. In der Praxis fragmentiert der BLE-Stack solche Daten automatisch und sendet sie als mehrere sequenzielle GATT-Anfragen von jeweils maximal 251 Byte. Für den Entwickler ist der Unterschied transparent — writeValue funktioniert unter iOS mit jeder Größe bis zu 512 Byte.

Auswirkungen der MTU auf die Leistung

Die MTU-Größe wirkt sich direkt auf den BLE-Verbindungsdurchsatz aus. Bei einer MTU von 23 Byte beträgt die maximale Nutzübertragungsrate unter idealen Bedingungen etwa 7–10 KB/s. Eine Erhöhung der MTU auf 247 Byte steigert die Geschwindigkeit auf 60–90 KB/s (mit DLE und optimalem Verbindungsintervall). Dies ist besonders wichtig für Anwendungen, die Bilder, Audiofragmente oder Logs übertragen.

Die BLE-Übertragungsleistung hängt von drei Faktoren ab: MTU (wie viele Daten pro ATT-Anfrage), Verbindungsintervall (wie oft Austauschereignisse stattfinden) und DLE (wie viele Daten pro Link-Layer-Paket). Die optimale Konfiguration für maximale Geschwindigkeit: MTU = 247, DLE = 251, Verbindungsintervall = 7,5 ms (Mindestwert).

Laut dem Bluetooth SIG White Paper (2023) erhöht sich bei einer Erhöhung der MTU von 23 auf 247 Byte mit einem Verbindungsintervall von 30 ms der Durchsatz von 8 KB/s auf 42 KB/s — eine Steigerung um das 5-Fache. Bei einem Verbindungsintervall von 7,5 ms erreicht der Durchsatz 88 KB/s. Für Anwendungen, die keine hohe Geschwindigkeit erfordern (Temperatursensoren, BLE-Beacons), reicht die standardmäßige MTU von 23 Byte weiterhin aus.

MTU-Konfiguration in iOS und Android

iOS Core Bluetooth handelt die MTU beim Verbinden mit einem Peripheral automatisch aus. Der Entwickler kann die aktuelle MTU über maximumWriteValueLength abfragen, aber nicht manuell einstellen. iOS verwendet eine MTU von bis zu 512 Byte für BLE 5.0-Geräte und bis zu 247 für BLE 4.2. Verwenden Sie zum Schreiben großer Datenmengen writeType: .withResponse für garantierte Zustellung.

kotlin
// MTU auf Android anfordern (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

// MTU 517 Byte anfordern
bluetoothGatt.requestMtu(517)

// Ergebnis im Callback behandeln
override fun onMtuChanged(
    gatt: BluetoothGatt,
    mtu: Int,
    status: Int
) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        println("MTU negotiated: $mtu")
    }
}

Android bietet BluetoothGatt.requestMtu(int), mit dem jede MTU bis zu 517 Byte angefordert werden kann. Die tatsächliche MTU wird vom Peripheriegerät bestimmt — wenn es nur 23 Byte unterstützt, gibt Android MTU 23 zurück. Verwenden Sie gatt.requestMtu(0), um die aktuelle MTU zu ermitteln — dies gibt den aktuellen Wert zurück, ohne zu versuchen, ihn zu ändern. Android 12+ unterstützt die automatische MTU-Aushandlung bei Verbindung über TRANSPORT_LE.

Plattformübergreifende Frameworks (Flutter, React Native) bieten in der Regel eine API für requestMTU. In der Bibliothek FlutterBlue Plus wird die MTU als Verbindungsparameter festgelegt. In RxAndroidBle — über die Methode requestMtu. Es wird empfohlen, die maximale MTU immer unmittelbar nach der Service-Erkennung vor Beginn der Datenübertragung auszuhandeln, um eine Fragmentierung auf Anwendungsebene zu vermeiden.

MTU und OTA-Updates

OTA (Over-The-Air) Firmware-Updates — das MTU-intensivste Szenario in BLE. Die typische Firmware-Größe eines IoT-Geräts beträgt 100–500 KB. Bei einer MTU von 23 Byte und einem Verbindungsintervall von 30 ms dauert die Übertragung von 100 KB etwa 2–3 Minuten. Bei einer MTU von 247 Byte und DLE von 251 Byte — 20–40 Sekunden. Und bei einer MTU von 512 Byte (iOS) — 10–15 Sekunden.

Der OTA-Update-Prozess umfasst in der Regel: Fragmentierung der Firmware in Pakete der Größe ≤ MTU, sequenzielle Übertragung über Notify/Write, Prüfsummenverifikation auf jedem Paket und Bestätigung des Empfangs. Wenn ein Paket verloren geht, fordert das Gerät eine erneute Übertragung an. Die OTA-Zuverlässigkeit hängt entscheidend von der richtigen Wahl der MTU und des Verbindungsintervalls ab.

Empfehlungen für OTA: Handeln Sie die maximale MTU (247–512 Byte) aus, stellen Sie das Verbindungsintervall auf 7,5–15 ms ein (falls das Gerät dies unterstützt), verwenden Sie DLE (Data Length Extension), um das physikalische Paket auf 251 Byte zu erhöhen. Überprüfen Sie bei Geräten mit begrenztem Pufferspeicher (z. B. BLE-Module auf Basis von nRF52) die maximale MTU im Chip-Datenblatt.

Häufig gestellte Fragen

Was passiert, wenn die MTU nicht ausgehandelt wird?

Die Verbindung verwendet die standardmäßige MTU — 23 Byte. Für die meisten IoT-Szenarien (Übertragung von Sensorwerten) ist dies ausreichend. Bei der Übertragung großer Datenmengen ist die Geschwindigkeit 5–10 Mal niedriger als mit einer ausgehandelten MTU von 247 Byte.

Kann die MTU nach Beginn der Datenübertragung geändert werden?

Nein, die MTU wird nach der Verbindung einmal ausgehandelt und kann ohne Trennen und erneutes Verbinden nicht geändert werden. Daher wird empfohlen, die MTU unmittelbar nach der Service-Erkennung vor Beginn der aktiven Datenübertragung auszuhandeln.

Warum fordert Android eine MTU von 517 Byte an, während iOS nur 512 anfordert?

Dies sind historisch gewachsene empirische Maximalwerte für jeden Stack. Die tatsächliche ATT MTU ist immer noch durch die Spezifikation auf 257 Byte begrenzt. Die Stacks fragmentieren Daten über 251 Byte automatisch in mehrere Pakete, sodass der Unterschied zwischen 512 und 517 unbedeutend ist.

Wie hängt MTU mit Data Length Extension (DLE) zusammen?

MTU — die Größe einer GATT-Anfrage auf ATT-Ebene. DLE — die Größe eines physikalischen Pakets auf der Link Layer. Ohne DLE wird jede GATT-Anfrage (bis zu 247 Byte) in 27-Byte-Pakete fragmentiert. Mit DLE wird sie als einzelnes Paket übertragen. Für maximale Geschwindigkeit müssen beide Parameter ausgehandelt werden.

Welche MTU sollte ich für einen Fitness-Tracker wählen?

Für einen Fitness-Tracker, der Herzfrequenz- und Schrittdaten überträgt, reicht die standardmäßige MTU von 23 Byte aus. Wenn Sie Trainingsverläufe (10–50 KB Größe) übertragen müssen, handeln Sie eine MTU von 247 Byte aus, um die Datensynchronisation beim Verbinden mit dem Smartphone zu beschleunigen.

Zusammenfassung

  • MTU — die maximale Datengröße in einer GATT-Anfrage: von 23 Byte (Standard) bis 251 Byte (BLE 5.0).
  • Die MTU-Aushandlung erfolgt über MTU Size Request/Response, initiiert durch den Central nach der Verbindung.
  • Das ATT-Protokoll begrenzt die MTU auf 257 Byte, aber iOS und Android fordern bis zu 512–517 Byte mit automatischer Fragmentierung an.
  • Eine Erhöhung der MTU von 23 auf 247 Byte verbessert den Durchsatz um das 5–10-Fache bei optimalem Verbindungsintervall.
  • Für maximale Geschwindigkeit handeln Sie MTU + DLE + Verbindungsintervall von 7,5 ms aus.
  • Unter iOS wird die MTU automatisch ausgehandelt, unter Android verwenden Sie requestMtu — es wird empfohlen, 247–517 Byte anzufordern.
  • OTA-Updates — das anspruchsvollste Szenario: Die richtige MTU reduziert die Übertragungszeit von Minuten auf Sekunden.

Wir entwickeln eine mobile Applikation schlüsselfertig

IT Sectr entwickelt seit 2017 iOS- und Android-Apps für Startups und Unternehmen. Wir beraten Sie und schlagen die beste Lösung vor.

Projekt besprechen

Lesen Sie auch