MTU en BLE: qué es, tamaño de paquete y negociación

¿Qué es MTU en BLE?

Maximum Transmission Unit (MTU) en el contexto de BLE es el tamaño máximo de una Unidad de Datos del Protocolo de Aplicación (APDU) que un dispositivo puede aceptar en una sola solicitud GATT. El MTU se define a nivel de ATT (Attribute Protocol) e incluye la cabecera ATT (1 byte) + datos útiles. Por defecto, todos los dispositivos BLE admiten un MTU de 23 bytes (23 = 1 byte de cabecera ATT + 22 bytes de datos).

El MTU no es un límite físico del canal de radio, sino un acuerdo entre dispositivos a nivel GATT. El tamaño físico del paquete BLE en la capa de enlace (Link Layer) puede ser mayor (hasta 27 bytes en BLE 4.0, hasta 257 bytes en BLE 5.0 con Data Length Extension), pero la capa GATT limita cuántos datos se transmiten por transacción. Data Length Extension (DLE) es un mecanismo separado de la capa de enlace que aumenta el paquete físico a 251 bytes y debe negociarse de forma independiente.

La diferencia entre MTU y DLE: ATT MTU — cuántos datos se transmiten por solicitud GATT, DLE — cuántos datos caben en un paquete de la capa de enlace. Para obtener la máxima velocidad, es necesario negociar ambos parámetros. Sin DLE, incluso con un MTU de 247 bytes, los datos se fragmentarán en varios paquetes de la capa de enlace de 27 bytes, reduciendo el rendimiento.

Negociación de MTU: procedimiento y protocolo

MTU Size Request — un procedimiento iniciado por el Central después de establecer una conexión GATT. El Central envía una solicitud MTU Request indicando su capacidad MTU (el tamaño máximo que puede aceptar). El Peripheral responde con una MTU Response con su propio valor. El MTU resultante es el mínimo de los dos valores. Si el Central ofrece un MTU de 512 y el Peripheral solo admite 128, la conexión utilizará un MTU de 128.

import CoreBluetooth

// Solicitar MTU máximo en iOS
func requestMTU(central: CBCentralManager,
                    peripheral: CBPeripheral) {
    peripheral.maximumWriteValueLength(
        for: .withoutResponse
    )

// iOS negocia el MTU automáticamente al conectar
            // MTU = 512 para dispositivos BLE 5.0
    let mtu = peripheral.maximumWriteValueLength(
        for: .withResponse
    )

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

Momento de la negociación: la solicitud MTU Request debe enviarse después del descubrimiento de servicios (discoverServices), pero antes de que comience la transmisión activa de datos. En iOS Core Bluetooth, el MTU se negocia automáticamente al conectar — el desarrollador no necesita enviar una MTU Request manualmente. En Android, es necesario llamar explícitamente a requestMTU. Una vez negociado, el MTU permanece fijo para esa conexión — no es posible renegociarlo sin desconectar y volver a conectar.

Limitaciones de ATT: por qué el MTU no puede superar los 251 bytes

ATT (Attribute Protocol) — el protocolo sobre el que se construye GATT. Un paquete ATT tiene un tamaño máximo de 257 bytes (ATT_MTU-1). De ellos, 1 byte es Opcode (tipo de operación), 1 byte es Handle, y hasta 255 bytes son Value. Por lo tanto, el MTU máximo permitido por la especificación ATT es de 257 bytes (pero en la práctica se usan hasta 251 bytes, ya que algunos campos de overhead siguen siendo necesarios).

Para enviar datos mayores que el MTU, se utiliza la fragmentación a nivel de aplicación. El desarrollador divide manualmente los datos en fragmentos de tamaño ≤ MTU y los envía secuencialmente. Cada fragmento se envía como una solicitud GATT Write Request independiente. El lado receptor ensambla los fragmentos en un único búfer. GATT no tiene soporte incorporado para la fragmentación — es responsabilidad del desarrollador.

Dato interesante: iOS y Android solicitan MTU de 512 y 517 bytes respectivamente, pero este valor supera el límite de ATT. En la práctica, la pila BLE fragmenta estos datos automáticamente, enviándolos como múltiples solicitudes GATT secuenciales de hasta 251 bytes cada una. Para el desarrollador, la diferencia es transparente — writeValue funciona con cualquier tamaño de hasta 512 bytes en iOS.

Impacto del MTU en el rendimiento

El tamaño del MTU afecta directamente al rendimiento de la conexión BLE. Con un MTU de 23 bytes, la tasa de transferencia útil máxima es de aproximadamente 7–10 KB/s en condiciones ideales. Aumentar el MTU a 247 bytes eleva la velocidad a 60–90 KB/s (con DLE e intervalo de conexión óptimo). Esto es especialmente importante para aplicaciones que transmiten imágenes, fragmentos de audio o registros.

El rendimiento de la transmisión BLE depende de tres factores: MTU (cuántos datos por solicitud ATT), intervalo de conexión (con qué frecuencia ocurren los eventos de intercambio) y DLE (cuántos datos por paquete de la capa de enlace). La configuración óptima para máxima velocidad: MTU = 247, DLE = 251, intervalo de conexión = 7.5 ms (valor mínimo).

Según el Bluetooth SIG White Paper (2023), aumentar el MTU de 23 a 247 bytes con un intervalo de conexión de 30 ms incrementa el rendimiento de 8 KB/s a 42 KB/s — un aumento de 5 veces. Con un intervalo de conexión de 7.5 ms, el rendimiento alcanza los 88 KB/s. Para aplicaciones que no requieren alta velocidad (sensores de temperatura, balizas BLE), el MTU estándar de 23 bytes sigue siendo suficiente.

Configuración del MTU en iOS y Android

iOS Core Bluetooth negocia automáticamente el MTU al conectar con un Peripheral. El desarrollador puede consultar el MTU actual mediante maximumWriteValueLength, pero no puede configurarlo manualmente. iOS utiliza un MTU de hasta 512 bytes para dispositivos BLE 5.0 y hasta 247 para BLE 4.2. Para escribir grandes volúmenes de datos, use writeType: .withResponse para entrega garantizada.

// Solicitar MTU en Android (Kotlin)
val bluetoothGatt: BluetoothGatt = ...

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

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

Android proporciona BluetoothGatt.requestMtu(int), que permite solicitar cualquier MTU de hasta 517 bytes. El MTU real lo determina el dispositivo periférico — si solo admite 23 bytes, Android devolverá un MTU de 23. Para determinar el MTU actual, use gatt.requestMtu(0) — esto devuelve el valor actual sin intentar cambiarlo. Android 12+ admite la negociación automática de MTU al conectar mediante TRANSPORT_LE.

Los frameworks multiplataforma (Flutter, React Native) suelen proporcionar una API para requestMTU. En la biblioteca FlutterBlue Plus, el MTU se establece como un parámetro de conexión. En RxAndroidBle — mediante el método requestMtu. Se recomienda negociar siempre el MTU máximo inmediatamente después del descubrimiento de servicios, antes de que comience la transmisión de datos, para evitar la fragmentación a nivel de aplicación.

MTU y actualizaciones OTA

Actualizaciones de firmware OTA (Over-The-Air) — el escenario que más exige el MTU en BLE. El tamaño típico del firmware de un dispositivo IoT es de 100–500 KB. Con un MTU de 23 bytes y un intervalo de conexión de 30 ms, transferir 100 KB lleva entre 2 y 3 minutos. Con un MTU de 247 bytes y DLE de 251 bytes — de 20 a 40 segundos. Y con un MTU de 512 bytes (iOS) — de 10 a 15 segundos.

El proceso de actualización OTA generalmente incluye: fragmentación del firmware en paquetes de tamaño ≤ MTU, envío secuencial mediante Notify/Write, verificación de suma de comprobación en cada paquete y confirmación de recepción. Si se pierde un paquete, el dispositivo solicita la retransmisión. La fiabilidad de OTA depende críticamente de la correcta selección del MTU y del intervalo de conexión.

Recomendaciones para OTA: negocie el MTU máximo (247–512 bytes), establezca el intervalo de conexión en 7.5–15 ms (si el dispositivo lo admite), use DLE (Data Length Extension) para aumentar el paquete físico a 251 bytes. Para dispositivos con memoria de búfer limitada (por ejemplo, módulos BLE basados en nRF52), verifique el MTU máximo en la especificación del chip.