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
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 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.
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 (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-Version | Max. MTU | Max. DLE | ATT MTU-Grenze |
|---|---|---|---|
| BLE 4.0 / 4.1 | 23 Byte | 27 Byte | ATT fest |
| BLE 4.2 | 247 Byte | 251 Byte | 257 Byte |
| BLE 5.0 | 251 Byte | 251 Byte | 257 Byte |
| Android + iOS | 512 / 517 | 251 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.
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.
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.
// 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.
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
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.
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.
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.
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.
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
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.
Lesen Sie auch