Lorawan-stack: Enlaces descendentes rechazados por pasarelas para ciertos poderes de transmisión

Parece que se produce un error con Lora-net/packet_forwarder . Código relevante: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L2517 -L2527

Con las configuraciones de puerta de enlace que se han distribuido a través de TTN (https://github.com/TheThingsNetwork/gateway-conf/), las puertas de enlace aceptan los siguientes poderes de TX:

-6 , -3 , 0 , 3 , 6 , 10 , 11 , 12 , 13 , 14 , 16 , 20 , 23 , 25 , 26 , 27

En The Things Stack usamos la misma lista cuando creamos la configuración dinámica para puertas de enlace: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/pfconfig/shared/shared.go#L259 -L276

Esto significa que _ERROR: paquete RECHAZADO, potencia de RF no admitida para TX - 11_ es solo una configuración incorrecta de la puerta de enlace, pero los otros informes son válidos.

Sospecho que estos son causados ​​por un servidor de puerta de enlace v3 que envía un valor de potencia TX no admitido. Necesitamos asegurarnos de que el GS solo envíe valores de potencia TX a las puertas de enlace UDP si están en la lista de potencias TX admitidas.

¿Alguna actualización o información reciente sobre esto?

¿Puede agregar un informe a https://status.thethings.network/ ? ¡Gracias!

https://status.thethings.network/ está destinado a incidentes de red. Ese no es el lugar para esto. Lanzaremos una nueva actualización en la que el servidor comprobará si TX Power es compatible antes de enviarlo.

Hola Kirshna,

¿Puede ser un poco más preciso cuándo se lanzará esta actualización? Hay mucha gente esperando esta solución.

Por cierto, ¿qué quieres decir con "comprobará la potencia TX compatible antes de enviar"? ¿Se asegurará el servidor de que la potencia de transmisión sea "estándar" o dejará caer el paquete?

Gracias por tu ayuda

https://status.thethings.network/ está destinado a incidentes de red.

Solo para expresar que siento que eso es muy rígido. Esto _es_ un problema operativo para algunos, ¿verdad? Al menos para algunos usuarios, los dispositivos caen a SF12 debido a que no reciben enlaces descendentes ADR, y otros de repente ven fallar OTAA. Sin acceso a un registro de puerta de enlace, no saben la causa, más aún porque las cosas estaban funcionando bien hasta hace poco, se cambió algo para el enrutamiento del tráfico V2. (O algo así; tampoco hay una comunicación clara sobre esos cambios).

@avbentem : Esto no se clasificaría como un problema operativo ya que está relacionado con el comportamiento del software y no con la conectividad / rendimiento / disponibilidad, etc. Sin embargo, entiendo que es importante solucionarlo. Puede esperar una solución en los próximos días.
PD: Tienes toda la razón. Este cambio no se comunicó correctamente.

Este cambio no se comunicó correctamente.

Aparte: ¿nunca es demasiado tarde para al menos arreglar eso? No me queda claro qué cambió, cuándo y si la gente debería mirar V2 o V3 al depurar problemas,

Agradezco mucho, digamos, una publicación en el foro o algo en https://www.thethingsnetwork.org/updates sobre este cambio y los cambios futuros. ¡Gracias!

Acabamos de implementar un parche que debería revertir el comportamiento. Esperaré algunos comentarios antes de cerrar esto.

¡Gracias Krishna!
¿Puede darnos algunos detalles de lo que se solucionó? No culpar a nadie, solo porque eso nos ayudaría a comprender mejor los problemas que teníamos con nuestras puertas de enlace y reenviadores de paquetes y a asegurarnos de que el comportamiento que observamos fue causado por este cambio.

El cambio básicamente fue este:

asegúrese de que el GS solo envíe valores de potencia TX a las puertas de enlace UDP si están en la lista de potencias TX admitidas

https://github.com/TheThingsNetwork/lorawan-stack/issues/2106#issuecomment -596502171

Además de este cambio, descubrimos que la conversión de la potencia TX en los enlaces descendentes recibidos de los sistemas v2 no se realizó correctamente, lo que resultó en una diferencia de 3 dBm (11 deberían haber sido 14; 17 deberían haber sido 20 y 24 deberían haber sido 27). Esto también se solucionó.

Gracias por los detalles, "_24 debería haber sido 27_" es exactamente lo que causó nuestros problemas. Al conocer este detalle, ya no necesitamos depurar el GW en el sitio.

Ya no pude reproducir el problema de mi lado. ¡Gracias por la actualización!

Gracias, @htdvisser y @KrishnaIyer. Dado que esto está relacionado de alguna manera con la conexión de V2 y V3: ¿puede documentar en algún lugar cómo están conectadas las cosas hoy en día, para la red comunitaria?

Aparentemente, como se anunció brevemente durante la Conferencia de fines de enero de 2020, el tráfico de las puertas de enlace que se configuraron en V2 se enruta a través de V3. Tal vez me perdí algo, pero no tengo muy claro qué componentes de V2 todavía se usan y qué se está delegando ahora a V3. Además, no está claro cuándo se realizaron los cambios.

(Me gusta: la red de la comunidad todavía usa V2 TTN Console, y eso funciona bien. También asumo que ADR todavía está siendo manejado por V2, ya que https://github.com/TheThingsNetwork/ttn/issues/767 todavía se está informando para Dispositivos OTAA que se unieron antes de octubre de 2019. Pero dado que el problema anterior se solucionó en V3, ¿la V3 también hace algo? Saber cuándo cambiaron las cosas podría ayudar a la depuración futura).

@dermatias

ya no necesitamos depurar el GW en el sitio

Tenga en cuenta que también podría ser una buena idea arreglar el lado de la puerta de enlace, para implementar un mecanismo de reserva para cambios futuros o para el uso futuro de V3. No estoy seguro vea algunos comentarios de Slack en https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14

No veo cómo esto ha solucionado el problema cuando alguien tiene (por ejemplo) una antena de 5dBi en su puerta de enlace. Si dejan la ganancia de antena en el archivo de configuración como 0dBi, excederán la potencia de transmisión máxima legal y si cambian el archivo de configuración a 5dBi, habrá casos en los que la puerta de enlace rechazará el paquete.

responder a @avbentem :

Dado que todos nuestros grupos de redes comunitarias se ven diferentes y las cosas están cambiando todo el tiempo, nos costaría demasiado tiempo mantener una descripción general actualizada de cómo están conectadas las cosas en cada región.

En la imagen a continuación, verá cómo las puertas de enlace se pueden conectar a una red v2. La situación anterior (amarillo) se migrará lentamente a la nueva situación (verde). Hacemos esto enrutando primero un pequeño porcentaje de tráfico para un protocolo de puerta de enlace dado a través de los nuevos componentes y aumentando lentamente ese porcentaje. Lo mismo para los otros protocolos de puerta de enlace.

Como mencionó @johanstokking durante su presentación en la conferencia, muchas puertas de enlace de redes comunitarias ya se conectan a través de un servidor de puerta de enlace v3, y con el tiempo estamos conectando más puertas de enlace a través de servidores de puerta de enlace v3.

Aparte de estos servidores de puerta de enlace, toda la red comunitaria pública todavía ejecuta componentes v2.

responder a @ tonysmith55 :

Esto no lo ha hecho. Simplemente cambia el comportamiento de nuevo a lo que era antes. Sí, es (y siempre será) posible que las puertas de enlace excedan la potencia máxima de transmisión legal si sus propietarios no han configurado correctamente estas puertas de enlace.

Espero que esto responda a sus preguntas. Dado que nos vamos un poco fuera del tema aquí, y dado que ahora se confirma que este problema está resuelto, ahora lo cerraré.