iBeacon: qué es, principio de funcionamiento de balizas y configuración BLE

¿Qué es iBeacon?

iBeacon es una tecnología de posicionamiento en interiores desarrollada por Apple y presentada en la WWDC 2013. A diferencia del GPS, que no funciona dentro de edificios, iBeacon utiliza balizas Bluetooth Low Energy — pequeños dispositivos alimentados por batería que transmiten paquetes de identificación fijos. Los dispositivos iOS y Android reciben estos paquetes y calculan la distancia aproximada a la baliza basándose en la intensidad de la señal (RSSI).

Historia y desarrollo

El protocolo iBeacon fue el primer estándar masivo de balizas BLE, lanzado por Apple en 2013 con iOS 7. Inicialmente, la tecnología se utilizó en el comercio minorista: las Apple Store implementaron iBeacon para informar a los clientes sobre descuentos al entrar en zonas específicas. Para 2025, la infraestructura iBeacon cuenta con millones de balizas instaladas en todo el mundo, aunque han surgido protocolos alternativos — Eddystone de Google y AltBeacon de código abierto.

Áreas de aplicación

iBeacon se utiliza en cinco escenarios principales: navegación en interiores (centros comerciales, aeropuertos, museos), notificaciones contextuales (descuentos al entrar en una tienda), automatización de flujos de trabajo (control de asistencia), logística y gestión de almacenes, y guías turísticos con reproducción automática de contenido al acercarse a un objeto. Según ABI Research (2025), el mercado de balizas BLE se estima en 3200 millones de dispositivos en funcionamiento.

Estructura del protocolo iBeacon y formato del paquete

Un paquete iBeacon es una PDU de publicidad (Protocol Data Unit) transmitida en los canales de publicidad BLE a frecuencias de 2402, 2426 y 2480 MHz. El formato del paquete está estrictamente fijado y consta de cuatro campos: el prefijo Apple iBeacon (0x4C000215), un UUID de 16 bytes, un valor Major de 2 bytes y un valor Minor de 2 bytes, y un TX Power de 1 byte para calibración de distancia. El tamaño total de datos es de 30 bytes, cabiendo en una única PDU de publicidad BLE.

Jerarquía UUID, Major y Minor

Los identificadores iBeacon forman una jerarquía de tres niveles. El UUID se asigna a una organización (por ejemplo, una cadena de tiendas), Major a una tienda o piso específico, y Minor a un punto concreto dentro de la zona (área de caja, departamento de producto). Esta jerarquía permite a la aplicación responder de forma flexible a diferentes niveles de contexto: al entrar en una tienda (UUID + Major), la aplicación puede cargar un mapa del piso, y al acercarse a un departamento específico (Minor), mostrar información del producto.

TX Power y calibración

El campo TX Power es un valor de referencia de intensidad de señal (RSSI) a 1 metro de distancia de la baliza. Al recibir el paquete, el dispositivo registra el RSSI real y calcula la distancia mediante la fórmula: distance = 10^((TX_Power - RSSI) / (10 * n)), donde n es el coeficiente de atenuación del entorno (normalmente 2-4). Una calibración correcta de TX Power es crítica para la precisión del posicionamiento: un error de 1 dBm produce una inexactitud de hasta el 30% a 5 metros de distancia.

Zonas de proximidad: Immediate, Near, Far

iOS define tres zonas de proximidad basadas en la distancia calculada a la baliza: Immediate (menos de 0,5 metros), Near (de 0,5 a 3 metros) y Far (de 3 a 30-50 metros según las condiciones). La distancia exacta no se revela — solo la categoría. Esto es intencional: el RSSI está sujeto a interferencias, reflejos de señal y la influencia del cuerpo humano, por lo que las categorías proporcionan una determinación de ubicación más estable.

Immediate — proximidad directa

Immediate es la zona de contacto directo, cuando el dispositivo se encuentra a centímetros de la baliza. Se utiliza para escenarios que requieren máxima precisión: pago a través de terminal, apertura de cerradura digital, verificación en un punto de control. En la zona Immediate, el RSSI suele estar entre -30 y -60 dBm.

Near — distancia media

La zona Near es el rango de trabajo principal de iBeacon, que cubre distancias de 0,5 a 3 metros. Se utiliza para navegación en interiores — por ejemplo, al acercarse a un expositor de productos, la aplicación muestra información detallada. En la zona Near, el RSSI oscila entre -60 y -80 dBm con una calibración TX Power de -59 dBm.

Far — larga distancia

Far es la zona máxima de detección de señal de la baliza. Se utiliza para monitorizar la entrada a una región (por ejemplo, entrar en un centro comercial). A distancia Far, el RSSI suele ser inferior a -80 dBm, y la precisión de la distancia disminuye significativamente. Para la monitorización de entrada se utilizan las API del sistema de monitorización de regiones, no la determinación precisa de la zona.

Monitorización de regiones en iOS

Una región iBeacon es un área virtual definida por UUID (y opcionalmente Major + Minor). iOS permite monitorizar hasta 20 regiones simultáneamente usando CLLocationManager. Al entrar en una región, el sistema activa la aplicación incluso en segundo plano o estado finalizado y envía una notificación a través del delegado locationManager:didEnterRegion. Al salir de una región, se llama a locationManager:didExitRegion.

import CoreLocation

let locationManager = CLLocationManager()
let region = CLBeaconRegion(
    uuid: UUID(uuidString: "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0")!,
    identifier: "myBeaconRegion"
)
locationManager.delegate = self
locationManager.requestAlwaysAuthorization()
locationManager.startMonitoring(for: region)

Ranging — determinación de la zona exacta

Para determinar la zona (Immediate, Near, Far) se utiliza el ranging — escaneo de balizas en tiempo real. A diferencia de la monitorización, el ranging solo funciona en modo activo de la aplicación y requiere permiso de ubicación. El método locationManager:didRangeBeacons:inRegion devuelve un array de CLBeacon con campos proximity (CLProximity.immediate, .near, .far, .unknown), accuracy (distancia calibrada en metros) y rssi.

func locationManager(
    _ manager: CLLocationManager,
    didRangeBeacons beacons: [CLBeacon],
    in region: CLBeaconRegion
) {
    for beacon in beacons {
        switch beacon.proximity {
        case .immediate:
            print("Immediate proximity")
        case .near:
            print("Near proximity")
        case .far:
            print("Far proximity")
        default:
            print("Unknown proximity")
        }
    }
}

iBeacon en Android: AltBeacon e integración multiplataforma

Android no tiene soporte nativo para iBeacon, ya que el protocolo es una solución propietaria de Apple. Sin embargo, usando bibliotecas de terceros como AltBeacon de Radius Networks (ahora parte de la organización Open Beacon), los desarrolladores pueden integrar iBeacon en aplicaciones Android. La biblioteca AltBeacon implementa escaneo de paquetes BLE, análisis del formato iBeacon y emulación de ranging y monitorización de regiones similar a la API de iOS.

val beaconManager = BeaconManager.getInstanceForApplication(context)
beaconManager.beaconParsers.add(
    BeaconParser().setBeaconLayout(
        "m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
    )
)
beaconManager.backgroundBetweenScanPeriod = 5000
beaconManager.foregroundScanPeriod = 1100
beaconManager.bind(this)

Análisis de paquetes iBeacon en Android

El formato de análisis de iBeacon en la biblioteca AltBeacon se define mediante la cadena layout: “m:2-3=0215” — verificación de dos bytes del marcador iBeacon, “i:4-19” — UUID de 16 bytes, “i:20-21” — Major, “i:22-23” — Minor, “p:24-24” — TX Power. El mismo formato es compatible con Eddystone y otros protocolos, lo que convierte a AltBeacon en una biblioteca universal para trabajar con balizas BLE en Android.

Limitaciones en Android

En Android, trabajar con iBeacon tiene tres limitaciones clave: el escaneo en segundo plano está restringido por los fabricantes (Xiaomi, Huawei, Samsung a menudo eliminan procesos en segundo plano), la precisión del RSSI es menor que en iOS debido a diferencias en las pilas BLE, y el escaneo requiere permiso ACCESS_FINE_LOCATION desde Android 6.0 y BLUETOOTH_SCAN desde Android 12.

iBeacon vs Eddystone: comparación de protocolos de balizas

Eddystone es un protocolo abierto de balizas BLE de Google, presentado en 2015. A diferencia de iBeacon, Eddystone admite cuatro tipos de paquetes: Eddystone-UID (identificador fijo), Eddystone-URL (transmisión de URL para Physical Web), Eddystone-TLM (telemetría de baliza — nivel de batería, temperatura) y Eddystone-EID (identificador cifrado para protección contra clonación). Aunque Google discontinuó el desarrollo de Physical Web en 2022, el protocolo Eddystone continúa utilizándose en soluciones empresariales.

Elección del protocolo para el proyecto

La elección entre iBeacon y Eddystone depende de la plataforma objetivo y el caso de uso. iBeacon es preferible para aplicaciones iOS gracias a la integración nativa con CoreLocation y la monitorización de regiones en segundo plano. Eddystone es más adecuado para proyectos orientados a Android y escenarios de Physical Web, donde la baliza transmite una URL sin necesidad de instalar una aplicación. Para proyectos multiplataforma, se utiliza a menudo AltBeacon, que admite ambos protocolos.

Problemas comunes y limitaciones de iBeacon

Al implementar iBeacon, los desarrolladores se enfrentan a una serie de limitaciones que deben considerarse en la fase de diseño de la arquitectura. La consideración incorrecta de estos factores provoca navegación inestable, falsas activaciones y un agotamiento más rápido de la batería de las balizas de lo estimado.

Impacto ambiental en el RSSI

El nivel de señal RSSI está sujeto a fluctuaciones significativas debido a reflejos en paredes, estructuras metálicas, presencia de personas y otros dispositivos inalámbricos en el rango de 2,4 GHz. En interiores, la variación del RSSI para una sola baliza puede alcanzar 10-15 dBm por minuto, lo que hace que el cálculo de distancia sea inexacto sin usar filtros (suavizado por media móvil, filtrado de Kalman).

Límite de monitorización de regiones

iOS admite la monitorización de no más de 20 regiones simultáneamente por aplicación. Para proyectos que requieren cobertura de áreas extensas (aeropuerto, estadio), esto es insuficiente. La solución es usar conmutación dinámica de regiones: al entrar en una región, se activan las adyacentes y se desactivan las distantes.

Tiempo de respuesta de monitorización

El retardo entre la entrada en una región y la recepción de la notificación puede oscilar entre 1 y 30 segundos según las condiciones. iOS escanea balizas periódicamente para ahorrar batería, por lo que no se debe esperar una reacción instantánea. Para escenarios críticos en tiempo (apertura de puerta al acercarse), se recomienda el ranging Immediate, pero solo funciona en modo activo de la aplicación.