Lorawan-stack: Configuración de la capa MAC del dispositivo en la consola

Creado en 25 feb. 2020  ·  9Comentarios  ·  Fuente: TheThingsNetwork/lorawan-stack

Resumen

La capa MAC del dispositivo debe ser configurable desde la consola.
Reemplaza https://github.com/TheThingsNetwork/lorawan-stack/issues/1378

¿Porqué necesitamos esto?

  • Creación/actualización de dispositivos Clase B desde la consola
  • Creación/actualización de dispositivos finales utilizando configuraciones de capa MAC no predeterminadas (por ejemplo, The Things Uno)

¿Qué ya hay? ¿Qué ves ahora?

CLI como el único medio para configurar la capa MAC del dispositivo

¿Lo que falta? ¿Qué quieres ver?

Soporte para configurar todos los campos MACSettings .

Lista de prioridad de campo
Alto

  • Todos los dispositivos

    • [x] rx2_data_rate_index
    • [x] rx2_frequency
    • [x] factory_preset_frequencies

  • Específico de clase A (también conocido como todos los dispositivos que no son de multidifusión)

    • [x] rx1_delay
    • [x] rx1_data_rate_offset
    • [x] resets_f_cnt

  • Específico de clase B

    • [x] ping_slot_periodicity
Medio

  • Específico de clase A (también conocido como todos los dispositivos que no son de multidifusión)

    • [ ] max_duty_cycle
    • [x] supports_32_bit_f_cnt
    • [ ] use_adr
    • [ ] status_time_periodicity
    • [ ] status_count_periodicity

  • Específico de clase B

    • [ ] ping_slot_data_rate_index
    • [x] ping_slot_frequency
    • [ ] beacon_frequency
Bajo

  • Específico de clase A (también conocido como todos los dispositivos que no son de multidifusión)

    • [ ] adr_margin
    • [ ] desired_rx1_delay
    • [ ] desired_rx1_data_rate_offset
    • [ ] desired_rx2_data_rate_index
    • [ ] desired_rx2_frequency
    • [ ] desired_max_duty_cycle
    • [ ] desired_adr_ack_limit_exponent
    • [ ] desired_adr_ack_delay_exponent

  • Específico de clase B

    • No multidifusión

      • [ ] class_b_timeout

      • [ ] desired_ping_slot_data_rate_index

      • [ ] desired_ping_slot_frequency

      • [ ] desired_beacon_frequency

  • Específico de clase C

    • No multidifusión

      • [ ] class_c_timeout

NOTA: Es posible que algunos de estos ya sean configurables (por ejemplo, cosas de FCnt), actualice las casillas de verificación en consecuencia y verifique que estas configuraciones estén en los lugares correctos (es decir, no está disponible para dispositivos de multidifusión)

Creo que la configuración específica de clase B y C debería estar disponible para todos los dispositivos, incluso para los dispositivos para los cuales SupportsClass{B,C} respectivos son false . De esta manera, los usuarios pueden (temporalmente) deshabilitar/habilitar la operación de clase B/C cuando sea necesario y mantener la configuración específica.

La configuración específica de Clase A solo debe estar disponible para dispositivos que no sean de multidifusión.

¿Cómo propone implementar esto?

Agregue todos los campos desde MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190 -L284 como campos para la configuración de la capa de red. Estos campos deben ser configurables en todo momento, es decir, tanto en la creación como en la actualización.

Use comentarios del prototipo para la descripción.

¿Puedes hacerlo tú mismo y enviar una solicitud de extracción?

@bafonins se encargará

console compaapi documentation uweb
Fuente
picture rvolosatovs

Todos 9 comentarios

Casi he terminado con los campos de alta prioridad para la configuración de configuración de MAC:


capturas de pantalla
PAA:

Screenshot 2020-03-29 at 17 41 50

clase B:

Screenshot 2020-03-29 at 17 44 00

OTAA:
Screenshot 2020-03-29 at 18 11 58

Sin embargo, para agregarlos a todos y permitir que los usuarios registren, por ejemplo, The Things Uno a través de la Consola, falta el campo mac_state.factory_preset_frequencies . No estoy seguro de cómo se debe representar exactamente esto en la interfaz de usuario, actualmente tengo estas ideas:

  1. Como selección múltiple:
    Screenshot 2020-03-30 at 09 47 01

En mi opinión, dicho campo hace que la selección de frecuencias sea muy fácil. Además, podemos presentarle al usuario frecuencias basadas en frequency_plan_id para el dispositivo final. Sin embargo, como mencionó @rvolosatovs, las entradas pueden tener valores arbitrarios y no necesariamente dependen del plan de frecuencia del dispositivo final.

Además, para este enfoque, sería genial tener un RPC para buscar preajustes de frecuencias por banda.

  1. Como matriz de entradas de números (similar a cómo permitimos agregar encabezados a las integraciones de webhook):
    Screenshot 2020-03-30 at 11 06 13

Este enfoque es más flexible, sin embargo, el usuario necesita más tiempo para configurar el campo y requiere frecuencias de escritura.

  1. Como selección múltiple con opciones para crear nuevas etiquetas:

freqqs

Básicamente, una combinación de 1 y 2.

@rvolosatovs @johanstokking

bafonins picture bafonins en 30 mar. 2020

Creo que tener la lista (2) es más claro, ya que muestra el orden. Y el orden es importante.

De hecho, las frecuencias pueden ser cualquier cosa, pero sería muy útil obtenerlas a través de un plan de frecuencias existente.

johanstokking picture johanstokking en 30 mar. 2020
👍1

Agregar compat/api porque es posible que necesitemos un NS rpc para obtener el plan de frecuencia.

johanstokking picture johanstokking en 30 mar. 2020

Creo que tener la lista (2) es más claro, ya que muestra el orden. Y el orden es importante.

Ambos componentes selectos (1) y (2) también conservan el orden.

De hecho, las frecuencias pueden ser cualquier cosa,

Con (3) también se pueden agregar valores de frecuencia arbitrarios

bafonins picture bafonins en 30 mar. 2020

Creo que la solución (2) también es la más limpia, mientras que (3) se ve mejor para una pequeña cantidad de frecuencias, tener múltiples (por ejemplo, 4 o más) se verá desordenado y difícil de seguir.
Sería genial si pudiéramos tener sugerencias de frecuencia para (2) en cada cuadro de texto (del plan de frecuencia propuesto RPC), algo así como lo que ve en (3), pero por cuadro de texto

rvolosatovs picture rvolosatovs en 30 mar. 2020
👍1

Más o menos hecho con la implementación, pero quiero esperar a que https://github.com/TheThingsNetwork/lorawan-stack/issues/2605 se fusione antes de hacer un PR para agregar pruebas para el asistente del dispositivo (incluido el manejo de la configuración de mac)

bafonins picture bafonins en 12 jul. 2020

¿Cuál es el estado aquí?

johanstokking picture johanstokking en 3 nov. 2020

@johanstokking https://github.com/TheThingsNetwork/lorawan-stack/pull/3065 está listo para su revisión. Agregué todos los campos de prioridad alta y algunos de prioridad media.

bafonins picture bafonins en 3 nov. 2020
👍1

Cambiando el hito de este problema no hay siguiente. Todos los campos de prioridad alta junto con algunos campos de prioridad media se agregaron en https://github.com/TheThingsNetwork/lorawan-stack/pull/3065. Volveremos a esto más adelante si se deben agregar otros campos a la consola.

bafonins picture bafonins en 21 dic. 2020
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

johanstokking picture johanstokking  ·  8Comentarios
johanstokking picture johanstokking  ·  3Comentarios
ZeroSum24 picture ZeroSum24  ·  3Comentarios
adriansmares picture adriansmares  ·  8Comentarios
adriansmares picture adriansmares  ·  9Comentarios