MTU in BLE: cos'è, dimensione del pacchetto e negoziazione

Cos'è il MTU in BLE?

Maximum Transmission Unit (MTU) nel contesto del BLE è la dimensione massima di un'Unità di Dati del Protocollo Applicativo (APDU) che un dispositivo può accettare in una singola richiesta GATT. Il MTU è definito a livello ATT (Attribute Protocol) e include l'intestazione ATT (1 byte) + dati utili. Per impostazione predefinita, tutti i dispositivi BLE supportano un MTU di 23 byte (23 = 1 byte di intestazione ATT + 22 byte di dati).

Il MTU non è un limite fisico del canale radio, ma un accordo tra dispositivi a livello GATT. La dimensione fisica del pacchetto BLE a livello di collegamento (Link Layer) può essere maggiore (fino a 27 byte in BLE 4.0, fino a 257 byte in BLE 5.0 con Data Length Extension), ma il livello GATT limita la quantità di dati trasmessi per transazione. Data Length Extension (DLE) è un meccanismo separato del livello di collegamento che aumenta il pacchetto fisico a 251 byte e deve essere negoziato separatamente.

La differenza tra MTU e DLE: ATT MTU — quanti dati vengono trasmessi per richiesta GATT, DLE — quanti dati possono essere contenuti in un pacchetto del livello di collegamento. Per la massima velocità, è necessario negoziare entrambi i parametri. Senza DLE, anche con un MTU di 247 byte, i dati verranno frammentati in più pacchetti di 27 byte del livello di collegamento, riducendo il throughput.

Negoziazione del MTU: procedura e protocollo

MTU Size Request — una procedura avviata dal Central dopo aver stabilito una connessione GATT. Il Central invia una richiesta MTU Request specificando la sua capacità MTU (la dimensione massima che può accettare). Il Peripheral risponde con una MTU Response con il proprio valore. Il MTU risultante è il minimo dei due valori. Se il Central offre un MTU di 512 e il Peripheral supporta solo 128, la connessione utilizzerà un MTU di 128.

import CoreBluetooth

// Richiedere MTU massimo su iOS
func requestMTU(central: CBCentralManager,
                    peripheral: CBPeripheral) {
    peripheral.maximumWriteValueLength(
        for: .withoutResponse
    )

// iOS negozia il MTU automaticamente alla connessione
            // MTU = 512 per dispositivi BLE 5.0
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

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

Momento della negoziazione: la richiesta MTU Request deve essere inviata dopo la scoperta dei servizi (discoverServices), ma prima dell'inizio della trasmissione attiva dei dati. In iOS Core Bluetooth, il MTU viene negoziato automaticamente alla connessione — lo sviluppatore non deve inviare manualmente una MTU Request. Su Android, è necessario chiamare requestMTU esplicitamente. Una volta negoziato, il MTU rimane fisso per quella connessione — non è possibile rinegoziarlo senza disconnettersi e riconnettersi.

Limitazioni dell'ATT: perché il MTU non può superare i 251 byte

ATT (Attribute Protocol) — il protocollo su cui è costruito GATT. Un pacchetto ATT ha una dimensione massima di 257 byte (ATT_MTU-1). Di questi, 1 byte è Opcode (tipo di operazione), 1 byte è Handle e fino a 255 byte sono Value. Pertanto, il MTU massimo consentito dalla specifica ATT è di 257 byte (ma in pratica vengono utilizzati fino a 251 byte, poiché alcuni campi di overhead sono ancora necessari).

Per inviare dati più grandi del MTU, viene utilizzata la frammentazione a livello di applicazione. Lo sviluppatore divide manualmente i dati in blocchi di dimensione ≤ MTU e li invia in sequenza. Ogni blocco viene inviato come una richiesta GATT Write Request separata. Il lato ricevente assembla i blocchi in un unico buffer. Non esiste supporto integrato per la frammentazione in GATT — è responsabilità dello sviluppatore.

Fatto interessante: iOS e Android richiedono rispettivamente un MTU di 512 e 517 byte, ma questo valore supera il limite ATT. In pratica, lo stack BLE frammenta automaticamente questi dati, inviandoli come più richieste GATT sequenziali di massimo 251 byte ciascuna. Per lo sviluppatore, la differenza è trasparente — writeValue funziona con qualsiasi dimensione fino a 512 byte su iOS.

Impatto del MTU sulle prestazioni

La dimensione del MTU influisce direttamente sul throughput della connessione BLE. Con un MTU di 23 byte, il tasso di trasferimento utile massimo è di circa 7–10 KB/s in condizioni ideali. L'aumento del MTU a 247 byte porta la velocità a 60–90 KB/s (con DLE e intervallo di connessione ottimale). Questo è particolarmente importante per le applicazioni che trasmettono immagini, frammenti audio o log.

Le prestazioni della trasmissione BLE dipendono da tre fattori: MTU (quanti dati per richiesta ATT), intervallo di connessione (con che frequenza si verificano gli eventi di scambio) e DLE (quanti dati per pacchetto del livello di collegamento). La configurazione ottimale per la massima velocità: MTU = 247, DLE = 251, intervallo di connessione = 7,5 ms (valore minimo).

Secondo il Bluetooth SIG White Paper (2023), l'aumento del MTU da 23 a 247 byte con un intervallo di connessione di 30 ms aumenta il throughput da 8 KB/s a 42 KB/s — un aumento di 5 volte. Con un intervallo di connessione di 7,5 ms, il throughput raggiunge 88 KB/s. Per le applicazioni che non richiedono alta velocità (sensori di temperatura, beacon BLE), il MTU standard di 23 byte rimane sufficiente.

Configurazione del MTU in iOS e Android

iOS Core Bluetooth negozia automaticamente il MTU quando si connette a un Peripheral. Lo sviluppatore può interrogare il MTU corrente tramite maximumWriteValueLength, ma non può impostarlo manualmente. iOS utilizza un MTU fino a 512 byte per i dispositivi BLE 5.0 e fino a 247 per BLE 4.2. Per scrivere grandi volumi di dati, utilizzare writeType: .withResponse per una consegna garantita.

// Richiedere MTU su Android (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

// Richiedere MTU 517 byte
bluetoothGatt.requestMtu(517)

// Gestire il risultato nel callback
override fun onMtuChanged(
    gatt: BluetoothGatt,
    mtu: Int,
    status: Int
) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        println("MTU negotiated: $mtu")
    }
}

Android fornisce BluetoothGatt.requestMtu(int), che consente di richiedere qualsiasi MTU fino a 517 byte. Il MTU effettivo è determinato dal dispositivo periferico — se supporta solo 23 byte, Android restituirà un MTU di 23. Per determinare il MTU corrente, utilizzare gatt.requestMtu(0) — restituisce il valore corrente senza tentare di modificarlo. Android 12+ supporta la negoziazione automatica del MTU alla connessione tramite TRANSPORT_LE.

I framework multipiattaforma (Flutter, React Native) solitamente forniscono un'API per requestMTU. Nella libreria FlutterBlue Plus, il MTU viene impostato come parametro di connessione. In RxAndroidBle — tramite il metodo requestMtu. Si consiglia di negoziare sempre il MTU massimo immediatamente dopo la scoperta dei servizi, prima dell'inizio della trasmissione dei dati, per evitare la frammentazione a livello di applicazione.

MTU e aggiornamenti OTA

Aggiornamenti del firmware OTA (Over-The-Air) — lo scenario che richiede più MTU in BLE. La dimensione tipica del firmware di un dispositivo IoT è di 100–500 KB. Con un MTU di 23 byte e un intervallo di connessione di 30 ms, il trasferimento di 100 KB richiede circa 2–3 minuti. Con un MTU di 247 byte e DLE di 251 byte — 20–40 secondi. E con un MTU di 512 byte (iOS) — 10–15 secondi.

Il processo di aggiornamento OTA di solito include: frammentazione del firmware in pacchetti di dimensione ≤ MTU, invio sequenziale tramite Notify/Write, verifica del checksum su ogni pacchetto e conferma di ricezione. Se un pacchetto viene perso, il dispositivo richiede una ritrasmissione. L'affidabilità dell'OTA dipende criticamente dalla corretta selezione del MTU e dell'intervallo di connessione.

Raccomandazioni per l'OTA: negoziare il MTU massimo (247–512 byte), impostare l'intervallo di connessione su 7,5–15 ms (se il dispositivo lo supporta), utilizzare DLE (Data Length Extension) per aumentare il pacchetto fisico a 251 byte. Per i dispositivi con memoria buffer limitata (ad esempio, moduli BLE basati su nRF52), verificare il MTU massimo nelle specifiche del chip.