MTU in BLE: wat is het, pakketgrootte en onderhandeling

Wat is MTU in BLE?

Maximum Transmission Unit (MTU) in de context van BLE — is de maximale grootte van de Application Protocol Data Unit (APDU) die een apparaat kan ontvangen in één GATT-verzoek. MTU wordt gedefinieerd op ATT-niveau (Attribute Protocol) en omvat de ATT-header (1 byte) + nuttige gegevens. Standaard ondersteunen alle BLE-apparaten een MTU van 23 bytes (23 = 1 byte ATT-header + 22 bytes gegevens).

MTU is geen fysieke limiet van het radiokanaal, maar een overeenkomst tussen apparaten op GATT-niveau. De fysieke grootte van een BLE-pakket op Link Layer-niveau kan groter zijn (tot 27 bytes in BLE 4.0, tot 257 bytes in BLE 5.0 met Data Length Extension), maar de GATT-laag beperkt hoeveel gegevens er in één transactie worden verzonden. Data Length Extension (DLE) — is een apart mechanisme op Link Layer-niveau dat het fysieke pakket vergroot tot 251 bytes en moet afzonderlijk worden overeengekomen.

Verschil tussen MTU en DLE: ATT MTU — hoeveel gegevens worden verzonden in één GATT-verzoek, DLE — hoeveel gegevens passen in één Link Layer-pakket. Voor maximale snelheid moeten beide parameters worden overeengekomen. Zonder DLE worden gegevens zelfs bij een MTU van 247 bytes gefragmenteerd in meerdere Link Layer-pakketten van 27 bytes, wat de bandbreedte vermindert.

MTU-onderhandeling: procedure en protocol

MTU Size Request — procedure geïnitieerd door Central na het tot stand brengen van een GATT-verbinding. Central stuurt een MTU Request met opgave van zijn MTU-capaciteit (de maximale grootte die het kan ontvangen). Peripheral antwoordt met een MTU Response met zijn waarde. De gebruikte MTU is het minimum van de twee waarden. Als Central een MTU van 512 voorstelt en Peripheral ondersteunt slechts 128, zal de verbinding MTU 128 gebruiken.

import CoreBluetooth

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

// iOS onderhandelt automatisch MTU bij verbinding
            // MTU = 512 voor BLE 5.0 apparaten
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

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

Tijdstip van onderhandeling: MTU Request moet worden verzonden na het ontdekken van services (discoverServices), maar voordat de actieve gegevensoverdracht begint. In iOS onderhandelt Core Bluetooth automatisch over MTU bij verbinding — de ontwikkelaar hoeft niet handmatig een MTU Request te sturen. In Android moet requestMTU expliciet worden aangeroepen. Na onderhandeling blijft MTU vast voor deze verbinding — heronderhandeling is onmogelijk zonder verbreking en hernieuwde verbinding.

ATT-beperkingen: waarom MTU niet groter kan zijn dan 251 bytes

ATT (Attribute Protocol) — het protocol waarop GATT is gebouwd. Een ATT-pakket heeft een maximale grootte van 257 bytes (ATT_MTU-1). Hiervan is 1 byte Opcode (type bewerking), 1 byte Handle, en tot 255 bytes Value. De maximale MTU toegestaan door de ATT-specificatie is dus 257 bytes (in de praktijk wordt tot 251 bytes gebruikt omdat sommige servicevelden toch nodig zijn).

Voor het verzenden van gegevens groter dan de MTU wordt fragmentatie op applicatieniveau gebruikt. De ontwikkelaar verdeelt de gegevens zelf in stukken van ≤ MTU en verzendt ze sequentieel. Elk stuk is formeel een afzonderlijk GATT Write Request. De ontvangende partij assembleert de stukken in één buffer. Ingebouwde ondersteuning voor fragmentatie in GATT bestaat niet — dit is de taak van de ontwikkelaar.

Interessant feit: iOS en Android vragen respectievelijk MTU 512 en 517 bytes, maar deze waarde overschrijdt de ATT-limiet. In de praktijk fragmenteert de BLE-stack dergelijke gegevens automatisch en verzendt ze als meerdere sequentiële GATT-verzoeken van maximaal 251 bytes. Voor de ontwikkelaar is het verschil onmerkbaar — writeValue werkt met elke grootte tot 512 bytes in iOS.

Invloed van MTU op prestaties

MTU-grootte heeft directe invloed op de bandbreedte van een BLE-verbinding. Bij een MTU van 23 bytes is de maximale nuttige overdrachtsnelheid ongeveer 7–10 KB/s onder ideale omstandigheden. Het verhogen van de MTU naar 247 bytes verhoogt de snelheid naar 60–90 KB/s (met DLE en optimaal connection interval). Dit is vooral belangrijk voor toepassingen die afbeeldingen, audiofragmenten of logboeken verzenden.

De prestaties van BLE-overdracht zijn afhankelijk van drie factoren: MTU (hoeveel gegevens in één ATT-verzoek), connection interval (hoe vaak wisselgebeurtenissen plaatsvinden) en DLE (hoeveel gegevens in één Link Layer-pakket). Optimale configuratie voor maximale snelheid: MTU = 247, DLE = 251, connection interval = 7.5 ms (minimale waarde).

Volgens gegevens van Bluetooth SIG White Paper (2023) verhoogt het verhogen van MTU van 23 naar 247 bytes bij een connection interval van 30 ms de bandbreedte van 8 KB/s naar 42 KB/s — een toename van 5 keer. Bij een connection interval van 7.5 ms bereikt de bandbreedte 88 KB/s. Voor toepassingen die geen hoge snelheid vereisen (temperatuursensoren, BLE-bakens) blijft de standaard MTU van 23 bytes voldoende.

MTU configureren in iOS en Android

iOS Core Bluetooth onderhandelt automatisch over MTU bij verbinding met een Peripheral. De ontwikkelaar kan de huidige MTU controleren via maximumWriteValueLength, maar kan deze niet handmatig instellen. iOS gebruikt een MTU tot 512 bytes voor BLE 5.0-apparaten en tot 247 voor BLE 4.2. Gebruik voor het schrijven van grote hoeveelheden gegevens writeType: .withResponse voor gegarandeerde levering.

// MTU aanvragen in Android (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

// MTU 517 bytes aanvragen
bluetoothGatt.requestMtu(517)

// Resultaat afhandelen in callback
override fun onMtuChanged(
    gatt: BluetoothGatt,
    mtu: Int,
    status: Int
) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        println("MTU negotiated: $mtu")
    }
}

Android biedt BluetoothGatt.requestMtu(int), waarmee elke MTU tot 517 bytes kan worden aangevraagd. De werkelijke MTU wordt bepaald door het randapparaat — als het slechts 23 bytes ondersteunt, retourneert Android MTU 23. Gebruik gatt.requestMtu(0) om de huidige MTU te bepalen — dit retourneert de huidige waarde zonder te proberen deze te wijzigen. Android 12+ ondersteunt automatische MTU-onderhandeling bij verbinding via TRANSPORT_LE.

Cross-platform frameworks (Flutter, React Native) bieden meestal een API voor requestMTU. In de bibliotheek FlutterBlue Plus wordt MTU ingesteld als verbindingsparameter. In RxAndroidBle — via de requestMtu-methode. Het wordt aanbevolen om altijd de maximale MTU onmiddellijk na het ontdekken van services te onderhandelen, voordat de gegevensoverdracht begint, om fragmentatie op applicatieniveau te voorkomen.

MTU en OTA-updates

OTA (Over-The-Air) firmware-updates — het meest veeleisende scenario wat betreft MTU in BLE. De typische firmwaregrootte van een IoT-apparaat is 100–500 KB. Bij een MTU van 23 bytes en een connection interval van 30 ms duurt het verzenden van 100 KB ongeveer 2–3 minuten. Bij een MTU van 247 bytes en DLE van 251 bytes — 20–40 seconden. En bij een MTU van 512 bytes (iOS) — 10–15 seconden.

Het OTA-updateproces omvat meestal: fragmentatie van de firmware in pakketten van ≤ MTU, sequentiële verzending via Notify/Write, verificatie van de controlesom op elk pakket en bevestiging van ontvangst. Als een pakket verloren gaat, vraagt het apparaat om herverzending. De betrouwbaarheid van OTA hangt kritisch af van de juiste keuze van MTU en connection interval.

Aanbevelingen voor OTA: onderhandel maximale MTU (247–512 bytes), stel connection interval in op 7.5–15 ms (als het apparaat dit ondersteunt), gebruik DLE (Data Length Extension) om het fysieke pakket te vergroten tot 251 bytes. Controleer voor apparaten met beperkt buffergeheugen (bijv. BLE-modules op basis van nRF52) de maximale MTU in de chipspecificatie.