MTU dans le BLE : définition, taille de paquet et négociation

Qu'est-ce que le MTU dans le BLE ?

Maximum Transmission Unit (MTU) dans le contexte du BLE est la taille maximale d'une unité de données du protocole d'application (APDU) qu'un appareil peut accepter dans une seule requête GATT. Le MTU est défini au niveau ATT (Attribute Protocol) et comprend l'en-tête ATT (1 octet) + les données utiles. Par défaut, tous les appareils BLE prennent en charge un MTU de 23 octets (23 = 1 octet d'en-tête ATT + 22 octets de données).

Le MTU n'est pas une limite physique du canal radio, mais un accord entre appareils au niveau GATT. La taille physique du paquet BLE au niveau de la couche liaison (Link Layer) peut être plus grande (jusqu'à 27 octets en BLE 4.0, jusqu'à 257 octets en BLE 5.0 avec Data Length Extension), mais la couche GATT limite la quantité de données transmises par transaction. Data Length Extension (DLE) est un mécanisme distinct de la couche liaison qui augmente le paquet physique à 251 octets et doit être négocié séparément.

La différence entre MTU et DLE : ATT MTU — quantité de données transmises par requête GATT, DLE — quantité de données pouvant tenir dans un paquet de la couche liaison. Pour une vitesse maximale, il est nécessaire de négocier les deux paramètres. Sans DLE, même avec un MTU de 247 octets, les données seront fragmentées en plusieurs paquets de 27 octets de la couche liaison, réduisant le débit.

Négociation du MTU : procédure et protocole

MTU Size Request — une procédure initiée par le Central après l'établissement d'une connexion GATT. Le Central envoie une requête MTU Request spécifiant sa capacité MTU (la taille maximale qu'il peut accepter). Le Peripheral répond par une MTU Response avec sa propre valeur. Le MTU résultant est le minimum des deux valeurs. Si le Central propose un MTU de 512 et que le Peripheral ne supporte que 128, la connexion utilisera un MTU de 128.

import CoreBluetooth

// Demander le MTU maximum sur iOS
func requestMTU(central: CBCentralManager,
                    peripheral: CBPeripheral) {
    peripheral.maximumWriteValueLength(
        for: .withoutResponse
    )

// iOS négocie le MTU automatiquement à la connexion
            // MTU = 512 pour les appareils BLE 5.0
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

    print("MTU négocié : " +
          String(mtu))
}

Moment de la négociation : la requête MTU Request doit être envoyée après la découverte des services (discoverServices), mais avant le début de la transmission active des données. Dans iOS Core Bluetooth, le MTU est négocié automatiquement à la connexion — le développeur n'a pas besoin d'envoyer manuellement une MTU Request. Sur Android, il est nécessaire d'appeler requestMTU explicitement. Une fois négocié, le MTU reste fixe pour cette connexion — il est impossible de le renégocier sans se déconnecter et se reconnecter.

Limitations de l'ATT : pourquoi le MTU ne peut pas dépasser 251 octets

ATT (Attribute Protocol) — le protocole sur lequel GATT est construit. Un paquet ATT a une taille maximale de 257 octets (ATT_MTU-1). Parmi ceux-ci, 1 octet est Opcode (type d'opération), 1 octet est Handle, et jusqu'à 255 octets sont Value. Par conséquent, le MTU maximum autorisé par la spécification ATT est de 257 octets (mais en pratique, jusqu'à 251 octets sont utilisés, car certains champs de surcharge sont encore nécessaires).

Pour envoyer des données plus grandes que le MTU, on utilise la fragmentation au niveau de l'application. Le développeur divise manuellement les données en morceaux de taille ≤ MTU et les envoie séquentiellement. Chaque morceau est envoyé comme une requête GATT Write Request distincte. Le côté récepteur assemble les morceaux dans un seul tampon. Il n'y a pas de support intégré pour la fragmentation dans GATT — c'est la responsabilité du développeur.

Fait intéressant : iOS et Android demandent un MTU de 512 et 517 octets respectivement, mais cette valeur dépasse la limite ATT. En pratique, la pile BLE fragmente ces données automatiquement, les envoyant comme plusieurs requêtes GATT séquentielles d'un maximum de 251 octets chacune. Pour le développeur, la différence est transparente — writeValue fonctionne avec n'importe quelle taille jusqu'à 512 octets sur iOS.

Impact du MTU sur les performances

La taille du MTU affecte directement le débit de la connexion BLE. Avec un MTU de 23 octets, le taux de transfert utile maximal est d'environ 7–10 Ko/s dans des conditions idéales. L'augmentation du MTU à 247 octets élève la vitesse à 60–90 Ko/s (avec DLE et intervalle de connexion optimal). Ceci est particulièrement important pour les applications qui transmettent des images, des fragments audio ou des journaux.

Les performances de transmission BLE dépendent de trois facteurs : MTU (quantité de données par requête ATT), intervalle de connexion (fréquence des événements d'échange) et DLE (quantité de données par paquet de la couche liaison). La configuration optimale pour une vitesse maximale : MTU = 247, DLE = 251, intervalle de connexion = 7,5 ms (valeur minimale).

Selon le Bluetooth SIG White Paper (2023), l'augmentation du MTU de 23 à 247 octets avec un intervalle de connexion de 30 ms accroît le débit de 8 Ko/s à 42 Ko/s — une multiplication par 5. Avec un intervalle de connexion de 7,5 ms, le débit atteint 88 Ko/s. Pour les applications qui ne nécessitent pas une vitesse élevée (capteurs de température, balises BLE), le MTU standard de 23 octets reste suffisant.

Configuration du MTU sur iOS et Android

iOS Core Bluetooth négocie automatiquement le MTU lors de la connexion à un Peripheral. Le développeur peut consulter le MTU actuel via maximumWriteValueLength, mais ne peut pas le définir manuellement. iOS utilise un MTU allant jusqu'à 512 octets pour les appareils BLE 5.0 et jusqu'à 247 pour BLE 4.2. Pour écrire de grands volumes de données, utilisez writeType: .withResponse pour une livraison garantie.

// Demander le MTU sur Android (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

// Demander un MTU de 517 octets
bluetoothGatt.requestMtu(517)

// Traiter le résultat dans le callback
override fun onMtuChanged(
    gatt: BluetoothGatt,
    mtu: Int,
    status: Int
) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        println("MTU negotiated: $mtu")
    }
}

Android fournit BluetoothGatt.requestMtu(int), qui permet de demander n'importe quel MTU jusqu'à 517 octets. Le MTU réel est déterminé par le périphérique — s'il ne supporte que 23 octets, Android retournera un MTU de 23. Pour déterminer le MTU actuel, utilisez gatt.requestMtu(0) — cela retourne la valeur actuelle sans tenter de la modifier. Android 12+ prend en charge la négociation automatique du MTU lors de la connexion via TRANSPORT_LE.

Les frameworks multiplateformes (Flutter, React Native) fournissent généralement une API pour requestMTU. Dans la bibliothèque FlutterBlue Plus, le MTU est défini comme un paramètre de connexion. Dans RxAndroidBle — via la méthode requestMtu. Il est recommandé de toujours négocier le MTU maximum immédiatement après la découverte des services, avant le début de la transmission des données, pour éviter la fragmentation au niveau de l'application.

MTU et mises à jour OTA

Mises à jour du firmware OTA (Over-The-Air) — le scénario le plus exigeant en MTU dans le BLE. La taille typique du firmware d'un appareil IoT est de 100–500 Ko. Avec un MTU de 23 octets et un intervalle de connexion de 30 ms, le transfert de 100 Ko prend environ 2–3 minutes. Avec un MTU de 247 octets et un DLE de 251 octets — 20–40 secondes. Et avec un MTU de 512 octets (iOS) — 10–15 secondes.

Le processus de mise à jour OTA comprend généralement : la fragmentation du firmware en paquets de taille ≤ MTU, l'envoi séquentiel via Notify/Write, la vérification de la somme de contrôle sur chaque paquet et la confirmation de réception. Si un paquet est perdu, l'appareil demande une retransmission. La fiabilité de l'OTA dépend de manière critique du choix correct du MTU et de l'intervalle de connexion.

Recommandations pour l'OTA : négociez le MTU maximum (247–512 octets), définissez l'intervalle de connexion sur 7,5–15 ms (si l'appareil le prend en charge), utilisez DLE (Data Length Extension) pour augmenter le paquet physique à 251 octets. Pour les appareils avec une mémoire tampon limitée (par exemple, les modules BLE basés sur nRF52), vérifiez le MTU maximum dans la spécification de la puce.