Antes de que un dispositivo LoRaWAN pueda enviar o recibir datos, debe completar un proceso llamado activación — el paso en el que el dispositivo obtiene su dirección de red y sus claves de sesión. El método de activación que elija afecta a la seguridad, la complejidad del despliegue y las operaciones diarias.
La especificación LoRaWAN define dos métodos de activación: OTAA (Over-The-Air Activation) y ABP (Activation By Personalization). Este artículo desglosa cómo funciona cada uno, los compara en paralelo y ofrece orientación práctica para la selección.
OTAA: Over-The-Air Activation
OTAA es el método de activación recomendado. Los dispositivos se envían sin claves de sesión y completan la autenticación por el aire tras el primer encendido.
Cómo funciona
La activación OTAA ocurre en tres pasos:
1. El dispositivo envía una Join Request
El dispositivo transmite una Join Request que contiene:
| Campo | Descripción |
|---|---|
| JoinEUI / AppEUI | Identificador de aplicación (64 bits) que selecciona la aplicación o el servidor de red al que unirse |
| DevEUI | Identificador de dispositivo único a nivel global (64 bits), normalmente derivado de la MAC del hardware o programado en la fabricación |
| DevNonce | Un número aleatorio (16 bits) que se incrementa en cada Join Request, lo que evita ataques de repetición |
La Join Request se autentica con un MIC (Message Integrity Code) calculado usando la AppKey, lo que garantiza que el mensaje no ha sido manipulado.
2. El servidor de red valida y envía una Join Accept
Al recibir la Join Request, el servidor de red:
- Busca la AppKey del dispositivo (y la NwkKey en LoRaWAN 1.1) por JoinEUI/AppEUI
- Verifica el MIC para confirmar la integridad del mensaje
- Comprueba el DevNonce para evitar la repetición (cada DevNonce solo puede usarse una vez)
- Si tiene éxito, asigna una DevAddr (dirección de red del dispositivo de 32 bits)
- Genera un Join Nonce (valor aleatorio del lado del servidor de red)
- Construye y cifra un mensaje Join Accept con la AppKey
La Join Accept contiene:
| Campo | Descripción |
|---|---|
| JoinNonce | Valor aleatorio (24 bits) generado por el servidor de red, usado para la derivación de claves |
| NetID | Identificador de red (24 bits) |
| DevAddr | La dirección de red asignada (32 bits) |
| DLSettings | Ajustes de enlace descendente (RX2 data rate, desplazamiento RX1, etc.) |
| RxDelay | Retardo de la ventana de recepción |
| CFList | Lista opcional de frecuencias de canal |
3. El dispositivo deriva sus claves de sesión
El dispositivo descifra la Join Accept con su AppKey y luego deriva las claves de sesión a partir de la AppKey, el JoinNonce, el DevNonce y el NetID.
LoRaWAN 1.0.x (1.0.2 / 1.0.3 / 1.0.4) deriva dos claves:
- NwkSKey (Network Session Key): cálculo del MIC para mensajes de la capa MAC y cifrado de comandos MAC
- AppSKey (Application Session Key): cifrado de la carga útil de la aplicación
Derivación simplificada:
NwkSKey = aes_encrypt(AppKey, 0x01 | AppNonce | NwkID | DevNonce)
AppSKey = aes_encrypt(AppKey, 0x02 | AppNonce | NwkID | DevNonce)
LoRaWAN 1.1 introduce la separación de claves, derivando cuatro claves:
- FNwkSIntKey: Forward Network Session Integrity Key
- SNwkSIntKey: Serving Network Session Integrity Key
- NwkSEncKey: Network Session Encryption Key
- AppSKey: Application Session Key
LoRaWAN 1.1 cambia el nombre de AppEUI a JoinEUI y separa la NwkKey de la AppKey, lo que permite la separación de claves a nivel de red y a nivel de aplicación — la base para el roaming seguro.
Propiedades de seguridad de OTAA
- Las claves nunca viajan por el aire: la AppKey/NwkKey se aprovisionan en el dispositivo y en el servidor de red; las claves de sesión se derivan de forma independiente en ambos lados. Solo la Join Accept cifrada cruza la interfaz aérea.
- Protección contra repetición de DevNonce: cada DevNonce puede usarse exactamente una vez; los servidores registran los valores usados.
- Rotación de claves: un dispositivo puede volver a unirse en cualquier momento para obtener claves de sesión nuevas.
- Compatibilidad con roaming: el diseño de separación de claves de LoRaWAN 1.1 permite el roaming entre redes.
ABP: Activación por personalización
ABP omite por completo el procedimiento de unión. Los dispositivos se aprovisionan previamente con todos los parámetros de comunicación en el momento de fabricación y comienzan a enviar inmediatamente después del encendido.
Qué se aprovisiona previamente
Lo siguiente debe escribirse en el dispositivo antes del envío y registrarse en el servidor de red con antelación:
| Parámetro | Descripción |
|---|---|
| DevAddr | Dirección de red del dispositivo (32 bits), debe ser única dentro de la asignación del servidor |
| NwkSKey | Clave de sesión de red (AES de 128 bits) |
| AppSKey | Clave de sesión de aplicación (AES de 128 bits) |
Los dispositivos ABP no necesitan un DevEUI, JoinEUI ni AppKey (a menos que se planee migrar a OTAA más adelante).
Cómo funciona
Un dispositivo ABP pasa directamente a funcionar tras el encendido:
- Usa el DevAddr preconfigurado como su dirección de origen
- Calcula los MIC con NwkSKey y cifra los comandos MAC con NwkSKey
- Cifra/descifra los datos de aplicación con AppSKey
- Comienza a transmitir en los canales predeterminados
No hay intercambio de Join Request / Join Accept.
El problema del contador de tramas
Los dispositivos ABP deben gestionar sus contadores de tramas de enlace ascendente (FCntUp) y de enlace descendente (FCntDown). Los servidores de red rastrean estos contadores para prevenir ataques de repetición: si un dispositivo se reinicia y su contador se restablece por debajo del valor que el servidor registró por última vez, sus tramas serán rechazadas.
Dos enfoques comunes:
- Restablecimiento del lado del servidor: restablecer manualmente los contadores de tramas del dispositivo en la plataforma (adecuado para depuración)
- Persistencia del lado del dispositivo: almacenar los contadores en almacenamiento no volátil y reanudar desde el último valor tras el reinicio (obligatorio para producción)
Lleva esta guía a tu proyecto
ManThink ofrece productos IoT para conectar dispositivos, desplegar redes y trabajar con datos. Consulta estos recursos de producto junto con las recomendaciones técnicas del artículo:
OTAA vs ABP: comparación lado a lado
| Dimensión | OTAA | ABP |
|---|---|---|
| Seguridad | Alta — las claves se derivan durante el procedimiento de unión y nunca se transmiten | Baja — las claves deben escribirse en la fabricación y registrarse en el servidor; riesgo de exposición |
| Rotación de claves | Sí — volver a unirse para obtener claves nuevas | No — las claves son fijas; cambiarlas requiere reflashear los dispositivos |
| Asignación de DevAddr | Asignada dinámicamente por el servidor de red | Fija en la fabricación; la unicidad debe gestionarse manualmente |
| Complejidad de despliegue | El dispositivo solo necesita las claves raíz; el servidor gestiona el resto | Tanto el dispositivo como el servidor necesitan una preconfiguración completa |
| Tiempo hasta el primer paquete | Primero el procedimiento de unión (normalmente 5–15 segundos) | Instantáneo — funciona justo después del encendido |
| Gestión del contador de tramas | Comienza desde cero tras la unión; sin problemas de conflicto | Debe gestionarse con cuidado; un reinicio puede provocar el rechazo de tramas |
| Roaming | Compatible (separación de claves de LoRaWAN 1.1) | No compatible |
| LoRaWAN 1.1 | Totalmente compatible — 1.1 depende de OTAA | No recomendado en 1.1 |
| Escala de despliegue | Adecuado para flotas de producción | Adecuado para pruebas pequeñas |
| Cambio de red | Cambiar el JoinEUI para unirse a otra red | Requiere reflashear todos los parámetros |
¿Cuál debería usar?
Use OTAA cuando
- Despliegues de producción — cualquier flota más allá de un puñado de dispositivos debería usar OTAA
- La seguridad importa — datos sensibles o requisitos de cumplimiento
- Gran escala — el DevAddr se asigna dinámicamente, evitando conflictos
- Se necesita roaming — despliegues entre redes o multirregión
- Redes LoRaWAN 1.1 — las funciones de seguridad de 1.1 dependen de OTAA
ABP es aceptable cuando
- Desarrollo y depuración — validar rápidamente la comunicación del dispositivo sin el handshake de unión
- Enseñanza y demostraciones — simplificar el flujo para que los estudiantes se centren en el intercambio de datos
- Despliegues muy pequeños y fijos — uno o dos dispositivos en un entorno controlado con bajos requisitos de seguridad
- Escenarios solo de enlace ascendente — dispositivos que solo transmiten, con necesidades mínimas de gestión de claves (aun así, sopesar el compromiso de seguridad)
Un error común
"ABP ahorra energía porque no hay procedimiento de unión."
No realmente. El procedimiento de unión cuesta muy poco — una Join Request y una Join Accept, normalmente completadas en unos segundos. En comparación con la vida útil de la batería de varios años de un dispositivo, la energía de la fase de unión es insignificante. Lo que ABP realmente ahorra es esfuerzo de configuración durante el desarrollo — y en producción esa comodidad tiene como costo una menor seguridad y una mayor sobrecarga operativa.
Notas prácticas
OTAA en la práctica
- DevEUI debe ser globalmente único: use un EUI-64 de IEEE derivado de la MAC del dispositivo; nunca codifique un valor predeterminado de forma fija
- Almacene AppKey de forma segura: es la clave raíz — su compromiso significa que toda la comunicación del dispositivo puede ser descifrada. Prefiera un elemento seguro, o al menos el cifrado de flash del MCU
- Persista DevNonce: debe residir en almacenamiento no volátil e incrementarse continuamente entre reinicios. Una reversión provoca que el servidor de red rechace las Join Requests
- Implemente reintento de join con backoff: evite saturar el canal si la red no está disponible temporalmente
- Escuche en las ventanas de join: Join Accept llega en RX1 (predeterminado 5 s) y RX2 después de la Join Request; el dispositivo debe estar escuchando
ABP en la práctica
- Persista los contadores de tramas: almacene FCntUp y FCntDown en almacenamiento no volátil (registros de respaldo RTC, flash o EEPROM)
- Planifique DevAddr con cuidado: el NwkID de 7 bits debe coincidir con el NetID del servidor de red; la dirección de 25 bits debe ser única dentro de la red
- Proteja las claves en la fabricación: las claves ABP se escriben en la fabricación — manténgalas fuera de los registros de producción y de los registros de prueba
- Nunca confirme claves en repositorios públicos: si comparte código en GitHub o similar, no codifique NwkSKey y AppSKey de forma fija
Trabajar con la plataforma ThinkLink
En ThinkLink:
- Dispositivos OTAA: registre DevEUI y AppKey en la plataforma; el dispositivo se une automáticamente tras el encendido
- Dispositivos ABP: registre DevAddr, NwkSKey y AppSKey; el dispositivo se comunica de inmediato
- La plataforma muestra el estado de join y los contadores de tramas de cada dispositivo
- Si se produce un conflicto de contador de tramas, restablézcalo desde la página de gestión del dispositivo
Resumen
| OTAA | ABP | |
|---|---|---|
| En una frase | Como conectarse a Wi-Fi — autenticación automática, dirección automática | Como una línea fija — número y línea preconfigurados en fábrica |
| Seguridad | Alta | Baja |
| Recomendado para producción | Sí | No (solo depuración/enseñanza) |
| LoRaWAN 1.1 | Requerido | No recomendado |
En conclusión: use OTAA en producción, ABP solo para depuración y enseñanza. Si tiene más de diez dispositivos, o si los dispositivos están en entornos que no puede controlar físicamente, OTAA es la única opción sensata.
Escrito conforme a las especificaciones LoRaWAN 1.0.4 y 1.1. Los detalles del protocolo siguen los documentos de especificación de LoRa Alliance; los consejos operativos se basan en la experiencia de la plataforma ThinkLink.
ThinkLink es el producto de plataforma IoT de ManThink, que ofrece gestión de red LoRaWAN, operaciones de dispositivos y servicios de datos.