Esta página explica qué ocurre entre el envío de una trama LoRaWAN por parte de un sensor y la aparición de una lectura en su dispositivo en Hermetry. Léala una vez antes de añadir pasarelas y dispositivos; la mayoría de la resolución de problemas parte de este esquema.
Los componentes
| Componente | Qué hace |
|---|---|
| Dispositivo final (sensor) | Envía tramas de radio cortas (uplinks) y escucha brevemente las respuestas (downlinks). |
| Pasarela | Recibe todas las tramas LoRaWAN dentro de su alcance y las reenvía al servidor de red a través de Internet. También transmite los downlinks. Una pasarela no sabe qué dispositivos son suyos. |
| Servidor de red | El servidor integrado de Hermetry. Comprueba cada trama, fusiona las copias recibidas por varias pasarelas, mantiene la sesión y los contadores del dispositivo, ejecuta la capa MAC (ADR y otros ajustes de radio) y planifica los downlinks. |
| Servidor de unión | Parte del servidor de red. Responde a las solicitudes de unión de los dispositivos OTAA y crea sus claves de sesión. |
| Codec | Convierte los bytes de una trama en valores con nombre, por ejemplo temperature y humidity. |
| Flujos | Los mensajes de sus dispositivos pasan por el flujo raíz, que almacena los valores y ejecuta las reglas de alarma. |
Las pasarelas y los dispositivos finales son dispositivos en Hermetry. Una pasarela usa el perfil integrado LoRaWAN gateway; un dispositivo final que añade manualmente usa el perfil integrado LoRaWAN EU868 Class A OTAA (1.0.3). Ambos se crean la primera vez que los necesita.
De un sensor a una lectura
- El sensor envía un uplink. Todas las pasarelas dentro de su alcance lo reciben.
- Cada pasarela reenvía su copia, con la potencia de señal (RSSI) y la calidad (SNR) que ha medido, a la dirección del servidor de red de su organización.
- El servidor de red reúne las copias de la misma trama durante un breve intervalo (200 ms por defecto) y las fusiona en un único uplink. Las copias solo se fusionan dentro de una misma organización: una trama recibida por la pasarela de otro cliente nunca se mezcla con las suyas.
- Comprueba la trama: la dirección del dispositivo (DevAddr) debe pertenecer a la sesión de uno de sus dispositivos, la comprobación de integridad (MIC) debe ser correcta con la clave de esa sesión y el contador de tramas debe avanzar. Una trama que falla se descarta y se muestra en el registro de tramas con su motivo.
- Procesa los comandos MAC que envió el dispositivo y decide si es necesaria una respuesta (un acuse de recibo, una solicitud MAC o un downlink en cola).
- Decodifica la carga útil de aplicación con el codec del dispositivo. Sin codec, o si la decodificación falla, la carga útil original se pasa en hexadecimal bajo la clave
raw. - Escribe un mensaje de dispositivo para el uplink. Cuando el ajuste del perfil Añadir los valores de radio (lora.rssi, lora.snr, …) a cada mensaje está activado, el mensaje también incluye
lora.rssi,lora.snr,lora.gw_count,lora.dr,lora.freqylora.fcnt_up. - El mensaje pasa por su flujo raíz como cualquier mensaje de dispositivo. El flujo raíz almacena los valores.
Un uplink es un mensaje de dispositivo, sin importar cuántas pasarelas lo hayan recibido. Las tramas en FPort 0 (solo comandos MAC) no escriben ningún mensaje de dispositivo.
Eliminación de duplicados
Varias pasarelas suelen recibir el mismo uplink. El servidor de red identifica cada copia por su organización y por los bytes exactos de la trama. La primera copia abre un grupo; las copias que llegan dentro del intervalo se unen a él; al cerrarse el intervalo, el uplink se procesa una sola vez, con la lista de todas las pasarelas que lo recibieron. Una copia que llega después de cerrarse el intervalo se cuenta como tardía y se ignora.
La mejor pasarela (SNR más alto y, después, RSSI) se usa para los valores de radio del mensaje y es la primera opción para una respuesta.
Uniones
Un dispositivo OTAA debe unirse antes de poder enviar datos. Su solicitud de unión pasa por las mismas pasarelas y por la misma eliminación de duplicados. El servidor de unión comprueba el DevEUI, el JoinEUI, el AppKey y el DevNonce del dispositivo, crea una sesión y envía una respuesta de unión a través de la mejor pasarela que todavía pueda llegar al dispositivo a tiempo. Consulte Cómo se une un dispositivo.
Un dispositivo ABP no se une. Su sesión (dirección y claves) se introduce al añadirlo.
Respuestas y downlinks
Un dispositivo Clase A escucha solo en dos ventanas breves después de cada uplink (RX1 y RX2). El servidor de red elige la pasarela y la ventana que todavía pueden llegar a tiempo, teniendo en cuenta el tiempo de ida y vuelta de la pasarela y su presupuesto de ciclo de trabajo. Un dispositivo Clase C escucha todo el tiempo, por lo que sus downlinks en cola se envían de inmediato. Consulte Clases de dispositivos y Envío de downlinks.
Aislamiento entre organizaciones
Cada DevEUI y cada EUI de pasarela solo puede registrarse una vez en toda la plataforma. Cuando intenta registrar uno que otra organización ya tiene, Hermetry indica que está ocupado y nunca dice quién lo tiene. Las tramas de los dispositivos de otra organización que reciben sus pasarelas se descartan con el mensaje «A device of another network» y no se le muestra nada de ese dispositivo.
Qué no se almacena
El servidor de red guarda solo un registro breve de tramas (el último día, como máximo 1.000 tramas por organización) y la última recepción de cada dispositivo. El historial de recepciones se almacena solo cuando su flujo guarda las claves lora.* junto con los demás valores, algo que hace el flujo raíz por defecto cuando el perfil las añade al mensaje.