Resumen us915

US915

Frequency band: 902 Mhz to 928 Mhz

Upstream

Channels 0-63

  • 125kHz
  • 902.3 to 914.9 in steps of 200khz

Channels 64-71

  • 500kHz
  • 903.0 to 914.2 in steps of 1.6Mhz

Downstream

Channels 0-7

  • 500kHz
  • 923.3 to 927.5 insteps of 600kHz

We will use Hybrid mode, with 8+1 channels per gateway. Because of this we need to limit the tx power.

Power:

  • Upstream: max 21dBm (Hybrid mode, 125kHz)
  • Downstream: max 26dBm (500kHz)

Duty Cyle:

Not applicable. However, it’s still good to keep track of it, and limit it to say 10%, to prevent RX starvation on that gateway.
There is a dwell time limit of 400ms. This is taken care of by a maximum packet length for each SF abd BW setting (table 7.2.6 of R1 standard)

Sub-bands:

8+1 frequencies per SX1301. Band 1: channel 0-7 and 64, band 2: 8-15 and 65, Etc.
Pre-defined on the nodes because they need to transmit a join in the band the gateway is configured (there are no join frequencies).
We could use the ChMaskCntl field of the LinkADRReq to mask the channels we don’t need (later, when we implement MAC commands)

Which sub-band to use? We seem to be using 7 a lot, but there’s no science behind that. Sub-band 2 would be another good choice. Certainly not sub-bands 1 and 8.

RX1

Only initiate downstream if uplink frequency is > 902 and < 915 Mhz, and if the down_chan is an integer (do not round).

Downstream channel for upstream freq1 @ 125kHz:

down_chan = ((freq1-(902.3))/0.2) %% 8

Downstream channel for upstream freq1 @ 500kHz:

down_chan = ((freq1-(903.0))/1.6)

Convert to downstream frequency:

down_freq = 923.3 + (down_chan * 0.6)

DR Upstream -> DR Downstream

0 SF10BW125 – 10 SF10BW500
1 SF9BW125 – 11 SF9BW500
2 SF8BW125 – 12 SF8BW500
3 SF7BW125 – 13 SF7BW500
4 SF8BW500 – 13 SF7BW500

Upstream can only be DR 0 to 4, the reset below if just for reference.

8 SF12BW500 – 8 SF12BW500
9 SF11BW500 – 9 SF11BW500
10 SF10BW500 – 10 SF10BW500
11 SF9BW500 – 11 SF9BW500
12 SF8BW500 – 12 SF8BW500
13 SF7BW500 -13 SF7BW500

(yes, DR4 = DR12)

(reminder: investigate if we need to increase RX1DROffset due to hybrid mode power limitations 21/26).

RX2

freq = 923.3Mhz
datarate: DR8 SF12BW500

Join-accept message:

RX1DROffset: 0 (R1 default)
RX2 Data rate: 8 (R1 default)

Join Response CFList is not used. If present, it is ignored by the node. Better to not include it decrease message length!

LoRaWAN ™ para Norteamérica

RESUMEN REGIONAL DE LoRaWAN ™

La especificación de LoRaWAN ™ varía ligeramente de una región a otra en función de las diferentes asignaciones de espectro regionales y los requisitos . La especificación LoRaWAN ™ para Europa y América del Norte está definida, pero el comité técnico aún está definiendo otras regiones. Unirse a la Alianza LoRa® como miembro colaborador y participar en el comité técnico puede tener importantes ventajas para las empresas que buscan soluciones para el mercado asiático.

La banda ISM para Norteamérica es de 902-928MHz. LoRaWAN ™ define 64 canales de enlace ascendente de 125kHz de 902.3 a 914.9MHz en incrementos de 200kHz. Hay ocho canales adicionales de 500KHz de enlace ascendente en incrementos de 1.6MHz de 903MHz a 914.9MHz. Los ocho canales de enlace descendente tienen un ancho de 500 kHz desde 923.3MHz hasta 927.5MHz. La potencia de salida máxima en la banda de 902-928MHz de Norteamérica es de + 30dBm, pero para la mayoría de los dispositivos es suficiente + 20dBm. Bajo FCC no hay limitaciones del ciclo de trabajo, pero hay un tiempo de permanencia máximo de 400 ms por canal.

Modo híbrido LoRaWAN ™ para América del Norte

La mayoría de las personas están familiarizadas con los requisitos de salto de frecuencia para FCC, que requieren que más de 50 canales se utilicen por igual en la banda ISM. LoRaWAN ™ se define con más de 50 canales para aprovechar el espectro disponible y permitir la máxima potencia de salida. La modulación LoRa® califica como una técnica de modulación digital por lo que está exenta de tener que cumplir con todos los requisitos de salto de frecuencia especificados por FCC en un modo de operación híbrido. En el modo Híbrido, la potencia de salida máxima está limitada a + 21dBm y solo un subconjunto de ocho canales de los 64 canales de enlace ascendente se utiliza en el modo Híbrido.

De parte de la FCC:

“Un sistema híbrido utiliza tanto la modulación digital como las técnicas de salto de frecuencia al mismo tiempo en el mismo operador. Como se muestra en la Sección 15.247 (f), un sistema híbrido debe cumplir con el estándar de densidad de potencia de 8 dBm en cualquier banda de 3 kHz cuando la función de salto de frecuencia está desactivada. La transmisión también debe cumplir con un tiempo máximo de permanencia de 0,4 segundos / canal cuando la función de salto está activada. No hay ningún requisito para que este tipo de sistema híbrido cumpla con el ancho de banda mínimo de 500 kHz normalmente asociado con una transmisión DTS; y, no hay un número mínimo de canales de salto asociados con este tipo de sistema híbrido.

Traducido con: Google Translate

Fuente: https://lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf

Clases de Dispositivos LORAWAN

No todos los nodos son iaguales. Los dispositivos de extremo igual sirven para diferentes aplicaciones y tienen diferentes requisitos. Para optimizar una variedad de perfiles de aplicaciones finales, LoRaWAN ™ utiliza diferentes clases de dispositivos. Las clases de dispositivos intercambian la latencia de comunicación del enlace descendente de la red frente a la duración de la batería. En una aplicación de tipo control o actuador, la latencia de comunicación del enlace descendente es un factor importante.

Clase A

Dispositivos finales bidireccionales (Clase A): Los dispositivos finales de Clase A permiten comunicaciones bidireccionales, por lo que la transmisión de enlace ascendente de cada dispositivo final es seguida por dos ventanas de recepción de enlace descendente cortas. La ranura de transmisión programada por el dispositivo final se basa en sus propias necesidades de comunicación con una pequeña variación basada en un tiempo aleatorio (ALOHA-type of protocol). Esta operación Clase A es el sistema de dispositivo final de menor potencia para aplicaciones que solo requieren comunicación de enlace descendente desde el servidor poco después de que el dispositivo final haya enviado una transmisión de enlace ascendente. Las comunicaciones de enlace descendente desde el servidor en cualquier otro momento deberán esperar hasta el próximo enlace ascendente programado.

Clase B

Dispositivos finales bidireccionales con ranuras de recepción programadas (Clase B): Además de las ventanas de recepción aleatoria de Clase A, los dispositivos de Clase B abren ventanas de recepción adicionales en los horarios programados. Para que el dispositivo final abra su ventana de recepción a la hora programada, recibe una baliza sincronizada en el tiempo desde la puerta de enlace. Esto permite al servidor saber cuándo está escuchando el dispositivo final.

Clase C

Dispositivos finales bidireccionales con ranuras de recepción máximas (Clase C): los dispositivos finales de Clase C tienen ventanas de recepción casi continuamente abiertas, solo cerradas cuando se transmiten.

 

LoRaWAN: ¿OTAA o ABP?

Cada recién llegado a LoRaWAN eventualmente necesita saber cómo obtener datos de un dispositivo LoRaWAN. Si aún estás aceptando LoRaWAN, echa un vistazo a esta suave introducción al panorama general de cómo y por qué de LoRaWAN. Si está listo para ensuciarse las manos, tarde o temprano se enfrentará a términos como OTAA , ABP , DevEUI y AppNonce . Probablemente irás en busca de respuestas y serás bastante decepcionado.

Aquí, he intentado poner todos los conceptos que necesitarás para envolver tu cabeza alrededor de este lío aparentemente confuso en un solo lugar. Espero que esta ventanilla única, bastante sucinta, te ahorre meses de trabajo frustrante en la búsqueda de datos que se encuentran dispersos en otros lugares. No vale la pena que los conceptos descritos aquí solo se apliquen a LoRaWAN 1.0.x, no al próximo LoRaWAN 1.1. Y antes de recibir cualquier nitpickers: este artículo está deliberadamente incompleto: quería centrarme en los conceptos importantes que necesitarás para comenzar.

Los datos de LoRaWAN comienzan su vida como una transmisión inalámbrica de radio LoRa desde el dispositivo a la puerta de enlace. Allí se envía a través de un backhaul de comunicaciones (como celular o Ethernet) a un servidor de red en la nube.

El Servidor de red realiza las funciones necesarias para que LoRaWAN funcione antes de reenviar los datos al Servidor de aplicaciones apropiado para su procesamiento *. Los datos se cifran a lo largo de todo el viaje, primero mediante una clave de sesión de red ( NwkSKey ) y luego a través de una clave de sesión de aplicación ( AppSKey ).

* Tenga en cuenta que en realidad hay otro servidor llamado Join Server que asiste a los servidores de red y de aplicaciones durante el proceso de unión. Proporciona una funcionalidad de seguridad importante para los fabricantes y fabricantes de dispositivos, pero complica innecesariamente la imagen aquí.

P. ¿Pero de dónde vienen NetSKey y AppSKey?
A. Depende del método de «activación»: OTAA o ABP

OTAA: Activación por el aire
En OTAA, un dispositivo recibe una DevEUI , una AppEUI y una AppKey . Lo suficientemente confuso , el AppKey se utiliza para generar las claves de sesión, NwkSKey y AppSKey . Así que ten cuidado con los astutos o te confundirás de verdad. Para activarlo, el dispositivo envía una solicitud de combinación y utiliza la respuesta de combinación para derivar las claves de sesión NwkSKey y AppSKey . El dispositivo puede almacenar esas claves y continuar usándolas para comunicarse. Si se pierden o la red decide caducar, el dispositivo debe volver a unirse para generar nuevas claves.

Pros:
Las claves de sesión solo se generan cuando son necesarias, por lo que no se pueden comprometer antes de la activación.
Si el dispositivo cambia a una nueva red, puede volver a unirse para generar las nuevas claves, en lugar de tener que volver a programarlas.
Las configuraciones de red como RxDelay y CFList pueden especificarse en el momento de la unión.
Contras:
Se requiere un esquema para preprogramar cada dispositivo con un DevEUI y AppKey únicos , y el AppEUI correcto .
El dispositivo debe admitir la función de unión y poder almacenar claves generadas dinámicamente.

ABP: Activación Por Personalización
En ABP (Activación por personalización), un dispositivo no necesita un DevEUI , un AppEUI o un AppKey . En su lugar, las claves de sesión NwkSKey y AppSKey están preprogramadas en el dispositivo y el dispositivo está registrado previamente en la red. Cuando el dispositivo desea comunicarse, lo hace utilizando las claves de sesión sin tener que usar primero un procedimiento de unión.

Pros:
El dispositivo no necesita la capacidad o los recursos para realizar un procedimiento de unión.
El dispositivo no necesita decidir si una unión es necesaria en algún momento, ya que nunca es necesaria.
No es necesario ningún esquema para especificar un DevEUI o AppKey único .
Contras:
El esquema para generar NwkSKey y AppSKey debe garantizar que sean únicos, para evitar una violación generalizada si un solo dispositivo se ve comprometido. Y el esquema debe ser seguro para evitar que las claves sean obtenidas o derivadas por partes deshonestas.
Si el dispositivo se ve comprometido en cualquier momento, incluso antes de la activación, es posible que se descubran las claves.
La configuración de red no se puede especificar en el momento de la unión.
Los eventos que justifican un cambio de claves (por ejemplo, el traslado a una nueva red, el dispositivo comprometido o la caducidad de las claves) requieren una reprogramación del dispositivo.

P. Entonces, ¿uso OTAA o ABP?
Con cuidado, cualquiera de los métodos puede ser tan seguro y efectivo como el otro. Pero a menos que tenga requisitos particulares, OTAA es la forma más fácil de lograr cierta seguridad y flexibilidad básicas cuando llega el momento de la implementación. Es más probable que ABP sea útil en la etapa de creación de prototipos cuando necesita un control completo sobre los dispositivos activados. De cualquier manera, recuerde que, a menos que esté realizando una unión OTAA antes de cada mensaje, debe mantener actualizado su contador de fotogramas para que los mensajes subsiguientes lleguen.

Traducido con Google Translator

Fuente: https://www.newieventures.com.au/blogtext/2018/2/26/lorawan-otaa-or-abp

Compartido por Alex Corvis via Twitter