Novedad: el cortafuegos de IA supervisa cada módulo y explica cada incidente con palabras sencillas. Vea cómo funciona

Cómo se une un dispositivo, paso a paso

Lo que el servidor de unión comprueba en una solicitud de unión OTAA, cómo la respuesta llega al dispositivo, las reglas de DevNonce y Restablecer sesión.

Un dispositivo OTAA debe unirse antes de que el servidor de red acepte sus datos. Esta página sigue una solicitud de unión a través de cada comprobación, para que puedas saber por el estado de la unión o por el registro de tramas dónde se detiene una unión fallida.

Los pasos

  1. El dispositivo envía una solicitud de unión. Incluye el JoinEUI, el DevEUI, un DevNonce (un número que elige el dispositivo) y un código de integridad (MIC) calculado con el AppKey.
  2. Las pasarelas la reenvían. Las copias de varias pasarelas se fusionan, como cualquier uplink.
  3. Se busca el DevEUI. El servidor de red busca el DevEUI en el directorio de la plataforma.
    • No registrado en ningún lugar: si uno de tus perfiles está en modo de emparejamiento y la solicitud coincide con su AppKey compartido, el emparejamiento toma el control (véase Modo de emparejamiento). De lo contrario, la solicitud se descarta como DevEUI desconocido.
    • Registrado en otra organización: se descarta como Dispositivo de otra red. No se obtiene más información sobre él.
  4. Se comprueba el registro del dispositivo.
    • Un dispositivo ABP que envía una solicitud de unión es rechazado (El dispositivo ABP envió una solicitud de unión).
    • Un dispositivo retenido por el modo de emparejamiento es rechazado (Esperando aprobación).
    • Un dispositivo sin clave es rechazado (No hay AppKey almacenado).
  5. Se compara el JoinEUI con el almacenado, salvo que el dispositivo acepte cualquier JoinEUI. Uno distinto es rechazado (Unión rechazada: otro JoinEUI).
  6. Se comprueba el código de integridad con el AppKey (el propio del dispositivo, o la clave compartida del perfil para los dispositivos añadidos por emparejamiento). Si no coincide, se rechaza (Unión rechazada: ¿AppKey incorrecto?).
  7. Se comprueba el DevNonce (véase más abajo). Si se reutiliza, se rechaza (Unión rechazada: DevNonce usado antes).
  8. Se crea una sesión. El servidor de red elige una dirección de dispositivo (DevAddr) libre en su red, deriva las dos claves de sesión y las almacena cifradas. La nueva sesión queda pendiente hasta el primer uplink del dispositivo.
  9. Se envía la respuesta de unión. Pasa por la mejor pasarela que aún puede llegar al dispositivo: 5 segundos después de la solicitud (RX1, mismo canal) o 6 segundos después (RX2, 869,525 MHz, DR0). La respuesta indica al dispositivo su dirección, el retardo RX1 de su perfil (5 s por defecto), el desplazamiento de velocidad de datos RX1, la velocidad de datos RX2 y cinco canales EU868 adicionales.
  10. El dispositivo envía su primer uplink con la nueva sesión. A partir de ese momento, sus tramas son aceptadas.

Cuando todas las comprobaciones se superan, la insignia de unión del dispositivo muestra Unido, y el dispositivo recibe los atributos lora.devAddr y lora.joinedAt.

Si ninguna pasarela puede usar ninguna de las dos ventanas (todas desconectadas, deshabilitadas o sin presupuesto de ciclo de trabajo), la sesión se crea pero la respuesta no se envía. La insignia de unión muestra entonces Respuesta de unión no enviada (ninguna pasarela a tiempo) y el dispositivo volverá a intentarlo.

Un dispositivo que fue rechazado nunca recibe una respuesta. LoRaWAN no tiene un mensaje de «unión rechazada», así que el dispositivo simplemente reintenta más tarde.

Reglas de DevNonce

El DevNonce impide que alguien reproduzca una solicitud de unión antigua.

Versión de LoRaWANRegla
1.0.4Cada DevNonce debe ser mayor que el último aceptado.
1.0.2 y 1.0.3Un DevNonce no debe haberse usado antes. Se recuerdan los últimos 256 valores.

Un dispositivo que se reinicia y vuelve a contar su DevNonce desde 0 (1.0.4), o que elige un valor usado antes (1.0.2, 1.0.3), es rechazado hasta que use uno nuevo. Establecer un nuevo AppKey para el dispositivo borra su historial de DevNonce.

Estados de unión

La pestaña LoRaWAN del dispositivo muestra una insignia de unión:

InsigniaSignificado
Aún no unidoNo hay unión registrada ni sesión.
UnidoLa última unión fue aceptada, o el dispositivo tiene una sesión activa.
Unión rechazada: ¿AppKey incorrecto?La comprobación de integridad falló.
Unión rechazada: DevNonce usado antesLa protección contra repetición rechazó el DevNonce.
Unión rechazada: otro JoinEUIEl JoinEUI difiere del almacenado.
Respuesta de unión no enviada (ninguna pasarela a tiempo)Todas las comprobaciones se superaron, pero ninguna pasarela pudo enviar la respuesta.
No hay AppKey almacenadoEl dispositivo no tiene clave con la que comprobar.
Esperando aprobaciónAñadido por el modo de emparejamiento, aún no aprobado.
Dispositivo ABP: no se uneUn dispositivo ABP envió una solicitud de unión.
Unión rechazada (motivo)Cualquier otro rechazo, con su código.

Mediante la API, la lista de dispositivos acepta el filtro joinState con joined, refused o never.

Restablecer sesión

Restablecer sesión en la pestaña LoRaWAN del dispositivo finaliza la sesión actual del dispositivo. Sus uplinks son rechazados hasta que vuelva a unirse.

Úsalo después de que el dispositivo se haya restablecido a la configuración de fábrica, o después de cambiar sus claves, para que no quede ninguna sesión antigua. Confirma Restablecer la sesión: «El dispositivo debe volver a unirse antes de que se acepten sus uplinks. Úsalo después de restablecer un dispositivo o cambiar sus claves.»

Restablecer sesión no hace que el dispositivo se una: el dispositivo debe iniciar una unión por sí mismo (reinícialo o usa su botón de unión). No está disponible para dispositivos ABP. Cada restablecimiento se audita como iot_lorawan.device.session_reset.

Relacionado