Bluetooth y BLE: qué es, diferencia entre Classic y Low Energy y cómo funciona

¿Qué son Bluetooth y BLE?

Bluetooth es un estándar de red de área personal inalámbrica (WPAN) que opera en la banda ISM de 2,4 GHz, diseñado para la comunicación de dispositivos a distancias de hasta 100 metros. La especificación IEEE 802.15.1 define las capas física y MAC, mientras que la pila Bluetooth SIG define perfiles de alto nivel para escenarios específicos: auriculares de audio (HSP), transferencia de archivos (OPP), entrada de teclado (HID).

El estándar se dividió en dos ramas desde la versión 4.0 (2010): Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) y Bluetooth Low Energy (BLE, anteriormente Bluetooth Smart). Classic está diseñado para flujos continuos — llamadas de audio, música, archivos. BLE fue creado para aplicaciones donde los datos se transmiten en paquetes cortos con pausas de decenas de segundos o minutos — pulsómetros, etiquetas, sensores de temperatura.

Según Bluetooth SIG (2025), el 99% de los nuevos smartphones soportan ambas versiones, y el ecosistema BLE cuenta con más de 15 tipos de perfiles desde Blood Pressure hasta Environmental Sensing.

Bluetooth Classic vs BLE: Comparativa

La elección entre Classic y BLE depende del escenario: para transmisión de audio en flujo solo Classic es adecuado, para consultar un sensor una vez por hora — solo BLE. BR/EDR utiliza 79 canales con espaciado de 1 MHz y salto de frecuencia adaptativo (AFH), proporcionando resistencia a interferencias Wi-Fi.

BLE 5.x añadió LE Coded PHY para aumentar el alcance hasta 1 km (en espacios abiertos) y LE Audio con códec LC3 — la nueva versión está difuminando gradualmente el límite entre Classic y BLE para escenarios de audio.

Arquitectura BLE: Controller, Host y Application

La pila BLE se divide en tres capas: Controller (capas física y de enlace), Host (L2CAP, ATT, GATT, Security Manager) y Application (implementación del perfil en la aplicación). Esta separación permite que el fabricante del chip implemente el Controller en firmware, mientras que el desarrollador de la aplicación móvil trabaja solo con abstracciones GATT.

La capa de enlace (LL) gestiona el tiempo en el aire: el dispositivo alterna entre los estados Standby, Advertising, Scanning, Initiating y Connection. En el estado Connected, Central y Peripheral acuerdan un intervalo de conexión — la frecuencia con la que intercambian paquetes de datos. Un intervalo típico es de 7.5 a 1000 ms; cuanto más frecuente es el intercambio, mayor es el rendimiento y el consumo de energía.

El Security Manager (SM) implementa cifrado AES-128 con intercambio de claves mediante el protocolo de emparejamiento. Existen tres modos: Just Works (sin introducir PIN), Passkey Entry (código de 6 dígitos en pantalla) y OOB (NFC o QR). Para dispositivos portátiles se usa generalmente Just Works, para dispositivos médicos — OOB con verificación adicional.

Según la Bluetooth Core Specification 5.4 (2023), el tiempo de establecimiento de conexión segura en modo LE Secure Connections no supera los 300 ms con un intervalo de conexión de 30 ms.

Perfil GATT: Servicios, Características y Descriptores

El ATT (Attribute Protocol) es el modelo de transporte básico donde el servidor (dispositivo periférico) almacena atributos y el cliente (smartphone) los lee o escribe. GATT (Generic Attribute Profile) construye una jerarquía sobre ATT: Service → Characteristic → Descriptor.

Cada servicio es un grupo lógico de características que describen una función del dispositivo: Heart Rate Service (UUID 0x180D) contiene la característica Heart Rate Measurement (UUID 0x2A37) con un Descriptor Client Characteristic Configuration (0x2902) que controla las notificaciones. El desarrollador de la aplicación móvil obtiene la lista de servicios mediante discoverServices(), luego encuentra la característica requerida por UUID y se suscribe a las notificaciones.

BLE utiliza UUID de 16 bits para servicios estandarizados de Bluetooth SIG y UUID de 128 bits para servicios personalizados del fabricante. Por ejemplo, una funda con rastreador puede definir un servicio A000-… con una característica para transmitir el nivel de carga de su batería.

Ejemplo de trabajo con GATT en Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Pulso: $heartRate ppm")
    }
}

En el ejemplo, la aplicación encuentra el servicio Heart Rate mediante el UUID estándar de Bluetooth SIG, obtiene la característica de medición de pulso y se suscribe a sus notificaciones — cada vez que cambia el pulso, el dispositivo periférico envía datos sin una solicitud explícita del Central.

Advertising, escaneo y establecimiento de conexión

Advertising es un mecanismo clave de BLE mediante el cual un dispositivo Peripheral envía periódicamente paquetes de difusión (PDUs de advertising) en tres canales primarios (37, 38, 39). El dispositivo central escanea estos canales, recibe los datos de advertising y puede iniciar una conexión.

Un paquete de advertising contiene hasta 31 bytes de carga útil: flags, nivel de potencia TX, nombre local, UUID de servicios, datos específicos del fabricante. Esto es suficiente para transmitir lecturas de sensores sin establecer una conexión — modo Connectionless (tipo Broadcaster). Para transmisión continua de datos (por ejemplo, temperatura una vez por minuto), se utiliza una conexión con un intervalo de hasta 1000 ms.

En las plataformas móviles, el escaneo se inicia mediante startScan() (Android) o scanForPeripherals() (iOS). El filtrado por UUID de servicio ahorra energía al no procesar todos los dispositivos visibles — la aplicación recibe un callback solo para las etiquetas o sensores relevantes.

Ejemplo de escaneo de dispositivos BLE en Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Dispositivo encontrado: \(name)")
        }
    }
}

Tras descubrir un dispositivo, el Central llama a connect(), pasando el objeto CBPeripheral. Los parámetros de conexión (intervalo, latencia, tiempo de supervisión) se negocian a nivel de Link Layer — el desarrollador no los gestiona directamente, pero puede influir mediante requestConnectionPriority en Android.

Bluetooth LE en el desarrollo móvil: Core Bluetooth y android.bluetooth

Ambas plataformas móviles proporcionan API nativas para trabajar con BLE. Core Bluetooth (iOS) utiliza un enfoque de delegados: el administrador central inicia operaciones y el objeto periférico informa de los resultados mediante métodos delegados. android.bluetooth (Android) está construido sobre interfaces de callback y soporta operaciones GATT paralelas con múltiples dispositivos.

Diferencias clave entre las plataformas:

• iOS — soporta hasta 7 conexiones simultáneas; el modo BLE en segundo plano requiere UIBackgroundModes = bluetooth-central; al salir del primer plano, el sistema puede retrasar los callbacks varios minutos
• Android — no tiene límite fijo de conexiones (limitado por memoria); requiere permisos BLUETOOTH_SCAN y BLUETOOTH_CONNECT (Android 12+); se necesita un servicio en primer plano para un escaneo fiable en segundo plano
• Flutter — el paquete flutter_blue_plus abstrae las API de las plataformas con una interfaz Dart unificada: el código para escaneo y operaciones GATT es idéntico en ambas plataformas

Según pruebas de Bluetooth SIG (2024), el tiempo de conexión BLE entre un smartphone y una pulsera de actividad promedia 150–300 ms en Android y 100–250 ms en iOS — la diferencia se debe a las políticas de gestión del módulo de radiofrecuencia.

Ejemplo de conexión BLE en Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

El desarrollador de Flutter obtiene una interfaz API unificada; bajo el capó, flutter_blue_plus traduce las llamadas a android.bluetooth nativo o Core Bluetooth. Este enfoque reduce el tiempo de desarrollo de aplicaciones para trabajar con periféricos BLE en ambas plataformas.