Hola Habr!
Hace algún tiempo, el Grupo de Trabajo de Internet de las Cosas de Skoltech publicó un borrador del estándar nacional de IoT de banda estrecha llamado "OpenUNB", cuyo texto completo se puede encontrar
aquí . Por un lado, el fenómeno es indudablemente positivo: si en el campo de los estándares de banda ancha hay un hecho abierto para uso de todos los que quieran, LoRaWAN, los estándares de banda estrecha hasta el día de hoy han sido extremadamente propietarios (Sigfox, XNB de Strizh, NB-Fi de Vaviot), aunque este último también se publica en forma de un proyecto de norma nacional, no revela partes que son esenciales para la implementación de terceros).
Al mismo tiempo, los sistemas de banda estrecha y banda ancha tienen sus propios pros y contras, por lo que decir "por qué necesitas algo más cuando hay LoRaWAN" no es del todo cierto. Es decir, se necesita un estándar abierto para las comunicaciones de UNB.
Sin embargo, la necesidad es solo una de dos condiciones. El segundo es la suficiencia. Ok, lo que Skoltech publicó es necesario, pero ¿es suficiente para un uso práctico?
Responderemos esto en un formato similar a una entrevista: bajo las citas cortadas del borrador del estándar OpenUNB y los comentarios al respecto, dados por Alexander Sheptovetsky (AS), director técnico de GoodWAN, y Oleg Artamonov (OA), director técnico de Unwired Devices.
Entonces vamos. Se conservan la estilística, la ortografía y la puntuación de los autores.
Una característica del protocolo es el uso de modulación de banda ultra estrecha (el ancho del espectro de emisión es inferior a 1 kHz), que permite lograr una alta relación señal / ruido (con restricciones en la potencia radiada en el rango sin licencia), lo que significa transmitir datos a largas distancias o a través de múltiples obstáculos (paredes de concreto, particiones gabinetes de metal).
OA: el primer error de los autores del estándar es que inicialmente asumen una alta SNR (relación señal / ruido) como el requisito principal para las señales en los sistemas LPWAN, y a partir de estos errores continuará creciendo en el diseño e implementación del protocolo en sí, como elegir preámbulos, por ejemplo.
En realidad, la capacidad principal de los protocolos inalámbricos LPWAN, que proporciona su "rango", es la capacidad de recibir una señal con una SNR
baja , hasta una negativa, es decir casos en los que el nivel de señal es inferior al nivel de ruido.
Además, los autores del estándar no están bien familiarizados con los principios básicos de la teoría de la transmisión de señales, y específicamente con el límite de Shannon en la velocidad de transferencia de datos en el canal en presencia de ruido. Esta velocidad está determinada por el valor de SNR
y el ancho del espectro de la señal; de hecho, uno es compensado por el otro. Por lo tanto, para transmitir datos en sistemas LPWAN a largas distancias, se utilizan con bastante éxito señales de banda estrecha y de banda ancha (por ejemplo, en la banda LoRaWAN - 125 kHz), cada uno de los métodos tiene sus propias ventajas y desventajas.
Esto es posible debido al hecho de que los dispositivos de abonado transmiten datos sin establecer una conexión con la estación base (modo simplex), como por ejemplo, esto se hace en redes celulares móviles.
OA: además de los errores estilísticos y de puntuación, observo el uso inaceptable y descuidado de la terminología. El modo simplex, es decir, la transmisión de mensajes a través del canal de comunicación solo en una dirección, no está directamente relacionado con la necesidad de establecer una conexión, y ciertamente no son sinónimos. El mismo LoRaWAN proporciona comunicación bidireccional en modo semidúplex, pero tampoco requiere conexión previa con el BS.
Probablemente, los autores tenían en mente la ausencia de un modo de operación de sesión en OpenUNB, pero esta es una característica de todos los protocolos LPWAN.
Para simplificar y reducir el costo del diseño del transceptor, la transmisión y la recepción se separan en el tiempo, es decir, los datos se intercambian desde la estación base ya sea en modo simplex (transmisión desde la unidad de abonado a la estación base) o en modo semidúplex (transmisión desde la unidad de abonado a la estación base y la posterior recepción en el dispositivo suscriptor desde la estación base).
OA: y, literalmente, media página más tarde, ¡resulta que también hay modo semidúplex en OpenUNB! En general, quiero señalar que existen muchas contradicciones internas en el proyecto de norma.
El orden de bytes en el paquete es del más antiguo al más joven (big-endian)
OA: big-endian es un tipo de arquitectura de computadora con un orden de bytes específico en un número multibyte. En un paquete, el orden de los bytes es siempre el mismo, desde el primero hasta el último. Repito: para un proyecto de norma nacional, un uso tan descuidado de la terminología establecida es inaceptable.
Los paquetes pueden ser de diferentes longitudes dependiendo del tamaño de la carga útil. Opciones de longitud de carga útil: 0, 64 o 128 bits. Un mensaje con carga útil cero puede usarse como una señal regular de que el dispositivo está funcionando (latido). Las longitudes de paquetes de 64 y 128 bits están determinadas por el tamaño de los bloques de cifrado de los algoritmos de cifrado.
AS: Los desarrolladores han limitado la longitud de la carga útil a 0, 64 o 128 bits, lo que justifica esto con la conveniencia del cifrado. Esta es una limitación completamente artificial. A veces necesita enviar mensajes muy cortos, pero debe usar 64 bits. ¡De qué eficiencia energética podemos hablar después de eso! Cómo encriptar mensajes cortos con claves largas se puede leer, por ejemplo, en el protocolo LoRaWAN.
OA: sí, en el mismo LoRaWAN se usa regularmente el esquema de encriptación AES-CTR, que permite encriptar parcelas de cualquier longitud, incluyendo Menos longitud de la clave.
Para lograr un alto rango de transmisión en el rango sin licencia, se requiere una alta relación señal / ruido. Se logra debido al ancho de banda de transmisión ultra pequeño (del orden de 100 Hz).
AS: en el borrador del estándar no hay ni una sola opinión sobre el ancho de banda: es "menos de 1 kHz", luego "del orden de 100 Hz". ¿No fue posible llegar a una sola declaración en el estándar? ..
OA: y nuevamente sobre la necesidad de una alta SNR. No no LPWAN también es LPWAN para funcionar incluso con una SNR negativa.
Algunos transceptores pueden cambiar sus propiedades con bastante fuerza al comienzo de una transmisión. Esto puede afectar la frecuencia y la longitud de la señal modulada de los primeros bits del paquete. Para compensar este factor, se recomienda emitir una señal a una frecuencia de paquete de una duración igual a una duración de transmisión de 1-2 bits antes de comenzar la transmisión del preámbulo (Figura 2). [...] Al final de la transmisión, después de la suma de comprobación, también debe estudiar 1 bit más y reducir gradualmente la amplitud de la señal, lo que aumentará la probabilidad de la recepción correcta del último bit.
AS: La información y el dibujo se toman de la descripción técnica de SigFox y están relacionados con algunas características de la descripción de SigFox. El receptor arregla los bits no en el momento del cambio de fase, sino antes y después. No debe copiar sin pensar las características y errores de descripción de otras personas.
Valor de preámbulo recomendado para el paquete de enlace ascendente: 101010101010101010 2 . A discreción de los desarrolladores, los valores de preámbulo para toda la red pueden cambiarse. Por ejemplo, esto se puede usar para crear varias redes en un territorio, cuya recepción de una u otra estación base se dividirá en función de varios preámbulos.
AS: Breve explicación. Los receptores de señal UNB funcionan al nivel del ruido del aire. Como regla general, se utilizan receptores de conversión directa, después de lo cual se realizan FFT. Si la señal tiene modulación de fase, observe el cambio de fase para cada canal de frecuencia. Si se encuentra una secuencia digital correspondiente al preámbulo en cualquier canal, entonces se toma una decisión sobre la presencia de una señal útil. Al mismo tiempo, en cada correlacionador después de la FFT, una secuencia aleatoria de ceros y unos va constantemente del ruido del éter; esto significa que siempre existe la posibilidad de obtener un preámbulo del ruido del éter. Ahora veamos con qué frecuencia aparecerán preámbulos falsos de 16 bits, por ejemplo, en el receptor, cuyo uso es declarado por Vaviot, los autores de un "proyecto de norma nacional" similar. La banda de recepción declarada por ellos es de 200 kHz con un paso FFT de 7 Hz, lo que significa que se necesitan más de 28 mil correlacionadores. Para un impacto exacto en una longitud de 10 ms (velocidad de transmisión de 100 bps), los correlacionadores comienzan cada 2,5 ms. En total, se deben verificar 11 millones de correlatos cada segundo para detectar la posible presencia de un preámbulo, y se
emitirá un promedio de 178 preámbulos falsos del ruido del éter
cada segundo . Cada preámbulo falso debe ser procesado y, al mismo tiempo, no perder la recepción de los preámbulos verdaderos. Esta es una tarea excesivamente redundante para un procesador BS, que ya funciona hasta el límite.
Para todos los fabricantes de sistemas UNB que conozco,
el preámbulo tiene una longitud de 32 bits y fue elegido no por casualidad, sino como resultado de cálculos y experimentos.
Además, el propósito del preámbulo no es solo extraer una señal útil del flujo de ruido, sino también proporcionar sincronización.
En los sistemas UNB, se utilizan secuencias M especiales de bits con una función de autocorrelación pronunciada como preámbulo . Por ejemplo, si antes de la secuencia que proponen los autores (10101010101010101
2 ),
se recibe accidentalmente otro par 10
2 del ruido, entonces el receptor determinará el comienzo de la información útil dos bits antes y no podrá recibir el paquete.
Algunos sistemas usan preámbulos regulares, pero después de ellos siempre viene la sincronización de palabras, que no está prevista en este protocolo. Por las mismas razones, es incorrecto utilizar el identificador del dispositivo como preámbulo para el enlace descendente, según lo dispuesto por este protocolo.
OA: los autores del proyecto de norma se resumen claramente en la idea de una "alta relación señal / ruido" que está profundamente arraigada en sus cabezas, que ya han enfatizado varias veces. Sí, durante los experimentos en el laboratorio, la SNR es alta, y el receptor puede funcionar en el modo "Veo la señal: recibo la señal" (y muchos productos baratos vendidos en Aliexpress funcionan con éxito en este modo, proporcionando un rango de comunicación de varios cientos de metros).
En cualquier condición real, y aún más a distancias declaradas de 50 km, el preámbulo propuesto simplemente morirá en ruido: un bit malo o ruido aleatorio frente a él será suficiente para evitar que el receptor reconozca el paquete.
AS: Sin elementos de codificación a prueba de ruido, es imposible obtener comunicaciones de alta calidad en las condiciones de ruido diario del aire, especialmente en el rango de frecuencia sin licencia, este es un "clásico del género". Cualquier interferencia de pulso corto en el canal, noqueando solo un bit en toda la secuencia, y el receptor no aceptará nada.
La identificación del remitente es una secuencia única de 32 bits asignada a un dispositivo durante su producción. En el Apéndice E se proporciona información adicional sobre los identificadores: Formato para escribir identificadores, unidades de abonado, cálculo de información de control y rangos reservados de identificadores.
OA: el estándar, que afirma ser la base de un sistema unificado de transferencia de datos en los sistemas de contabilidad de recursos, no describe las reglas por las cuales los fabricantes eligen identificadores por sí mismos; ni siquiera se indica que tales reglas existan alguna vez. ¿A qué conducirá? Así es, para un montón de dispositivos de diferentes fabricantes, pero con los mismos identificadores, porque cada segundo fabricante simplemente numerará los dispositivos desde cero.
La información de servicio consta de 8 bits, con los 6 bits más a la izquierda reservados para uso futuro. Se reservan 2 bits para el número de paquete en el mensaje.
OA: una cantidad muy extraña y muy modesta de información general. Se podría especificar el número de paquete de extremo a extremo, el tipo de cifrado, el tamaño del paquete y mucho más. No está claro por qué incluso necesitamos un número de paquete "local" en el mensaje. Digamos que recibimos el paquete número 0 y luego el número 1. ¿Deberíamos descartar el segundo? Y si este es el paquete número 1 del siguiente mensaje, ¿desde el cual perdimos el número 0 en el aire? Y si no podemos descartar paquetes sobre esta base, ¿cómo resolvemos el problema con el hecho de que el dispositivo puede transmitir 4 paquetes idénticos seguidos? ¿Aceptamos y tomamos en cuenta todos, recibiendo múltiples cargas útiles duplicadas en la salida?
AS: Por lo general, un preámbulo sigue un encabezado que indica la longitud del paquete; este no es el caso en este protocolo. ¿Cómo entiende el receptor cuántos bits marcar? Puede, por supuesto, verificar todas las longitudes posibles utilizando CRC, pero nadie lo hace, es demasiado costoso desde el punto de vista del hardware del receptor.
La suma de verificación del paquete se calcula con base en el algoritmo del Apéndice B: Cálculo de la suma de verificación del paquete.
OA: para ser honesto, solo estoy parado con la boca abierta. No,
generalmente no se proporciona protección contra ataques típicos en el protocolo. Con la seguridad declarada del protocolo, el uso de cifrados fuertes, y otros, y otros, cualquiera puede atrapar el paquete de otra persona, cambiar los campos en él, sustituir la carga de otro paquete, recalcular la suma de verificación y transmitirla, y la estación base lo aceptará. y de ninguna manera puede distinguir un paquete falso de un paquete "nativo".
AS: los desarrolladores protegen la información útil con cifrado, ¡pero esto claramente no es suficiente! Los desarrolladores afirman que están familiarizados con los protocolos LoRaWAN y NB-FI, si ese fuera el caso, entenderían por qué se requiere protección contra repeticiones y por qué se necesita un inserto de imitación adicional en el paquete. Por ejemplo, un paquete con una carga útil de 0 bits es absolutamente inseguro, no hay problema para escribirlo desde el aire y repetirlo, y el sistema lo entenderá como propio. Tampoco es difícil para un atacante enviar basura al sistema o repetir en nombre de cualquier sensor en paquetes con una longitud distinta de cero.
El estándar a priori ya se ha convertido en protocolos de seguridad de la información en LoRaWAN, que justifica el uso de dos claves de seguridad, para la red y para el usuario, así como la capacidad de generar claves de sesión a través del aire, los desarrolladores de protocolos aparentemente ni siquiera pensaron en ello.
Las claves de cifrado deben almacenarse en el dispositivo del suscriptor y en los servidores de red en un almacenamiento seguro. Para cifrar los paquetes de enlace ascendente y enlace descendente, se deben utilizar diferentes claves de cifrado. Para cada dispositivo, el conjunto de claves de cifrado debe ser único.
OA: por un lado, los desarrolladores de OpenUNB se atribuyen a sí mismos "tamaños de campo seleccionados en múltiplos de 8 bits, para un procesamiento más eficiente en microprocesadores" (ortografía del autor), por otro lado, parece que simplemente no conocen una técnica de optimización simétrica tan efectiva cifrado, como la capacidad de mantener el dispositivo final en lugar de dos procedimientos, cifrado y descifrado, solo uno, lo que reduce el tamaño del firmware en los microcontroladores. Al menos en el proyecto de norma no se menciona.
AS: ¡ pero realmente lograron recoger los tamaños de los campos en múltiplos de 8 bits!
Enviar un mensaje desde un canal descendente solo es posible en respuesta a un mensaje de un canal ascendente. Hay varias razones para esto. En primer lugar, el protocolo está especializado para dispositivos de suscriptor que no tienen alimentación externa y están diseñados para una vida útil de la batería extra larga, lo que significa que el consumo de energía juega un papel clave. Dado que el consumo del transmisor en el modo de recepción es bastante alto, debe cambiar a este modo solo por un corto período de tiempo
OA: No entiendo muy bien por qué limitar conscientemente el alcance del estándar, además, hazlo más de lo que se indica en la introducción del mismo estándar. ¿Un medidor eléctrico doméstico normal tiene energía externa? Tiene. ¿Qué le impide mantener el "transmisor en modo de recepción" encendido todo el tiempo? Nada
En segundo lugar, no es posible seleccionar un intervalo de tiempo específico en un dispositivo suscriptor, ya que para reducir el costo de los dispositivos suscriptores, a menudo están equipados con osciladores de cristal inestables y no tienen un reloj en tiempo real.
OA: Esto, por supuesto, no es así. En primer lugar, mirando hacia adelante dos párrafos, los autores ya tienen una gran ventana de recepción: 8 segundos (en el mismo LoRaWAN, las ventanas de recepción tienen un tamaño de 1-2 segundos). En segundo lugar, es suficiente calcular con qué frecuencia el dispositivo debe sincronizar el reloj con la estación base (y proporcionar un método para dicha sincronización) para que el problema de la inestabilidad del cuarzo no sea un problema. En LoraWAN, esto se hace en dispositivos de Clase B.
En tercer lugar, la baja estabilidad de los osciladores de cristal en los dispositivos de abonado requiere el uso del algoritmo de ajuste de frecuencia descrito en el Apéndice D: Ajuste de la frecuencia de transmisión del enlace descendente. Pero, dado que el último mensaje del canal ascendente se usa para calcular la deriva de frecuencia, y la frecuencia del oscilador de cristal puede cambiar en el tiempo (por ejemplo, cuando cambia la temperatura), el tiempo entre el último mensaje ascendente y el descendente debe ser lo suficientemente pequeño como para cambiar la desviación de frecuencia en el abonado dispositivo durante este período fue insignificante.
AS: A juzgar por los detalles de la descripción, los desarrolladores del protocolo OpenUNB consideran que su solución al problema de la sincronización del canal descendente en frecuencia es su logro más importante.
El método de cálculo en sí es bastante aceptable, pero hay varios problemas:
- , , .
- .
- , 7 50 , 7 .
- , .
- .
- , , .
Realizamos los estudios apropiados y no pudimos obtener, en condiciones reales, una precisión de impacto en el rango de 868 MHz por encima de ± 150 Hz. Para recibir una señal BPSK de 100 Hz, se requiere una precisión de al menos 30 Hz.SigFox opera en el canal de retorno con una modulación de frecuencia de 600 Hz. Creo que la organización máxima posible del canal de retorno es 2GFSK con una desviación de 300 Hz y un aumento de la potencia de la señal aguas abajo a 100 mW.Además, los sistemas UNB con modulación de fase de la señal no funcionan muy bien en los objetos en movimiento de todos modos debido a un aumento en el ruido de fase durante la propagación de la señal multitrayecto. El método propuesto para determinar la frecuencia de la señal descendente en presencia de polarización Doppler dará un error adicional al determinar la frecuencia portadora del canal de enlace ascendente, lo que conducirá a un error adicional al determinar la frecuencia descendente.Quizás los autores del protocolo tienen otros datos, confirmados no "sobre la mesa", pero en condiciones reales, me gustaría ver los informes de las pruebas.OA:Agrego que incluso una desviación de 30 Hz con una banda de 100 Hz no es la recepción ideal, sino alrededor del 10% de los errores de bits (en los sistemas LPWAN esto se lleva tradicionalmente al extranjero, en el que la calidad de recepción aún puede considerarse aceptable). Dada la falta de codificación de ruido en OpenUNB, la probabilidad de que un mensaje del orden de un par de cientos de bits capte al menos un error con una BER del 10% es muy alta, es decir, específicamente en OpenUNB, estimaría la desviación de frecuencia permitida, en lo que de alguna otra manera a veces se tomará, al 5% como máximo. En treinta veces mejor de lo que es posible obtener en la realidad.En resumen, existen serias dudas de que el método de organización de un canal de comunicación inversa descrito en el borrador del estándar sea generalmente operativo en principio.La duración del intervalo de tiempo T dl se selecciona para que sea varias veces la duración de la transmisión de un enlace descendente de paquete. Tal aumento en el tamaño de la ventana de tiempo es necesario, ya que generalmente hay muchos dispositivos por estación, lo que puede llevar a la necesidad de enviar un paquete de enlace descendente a varios dispositivos al mismo tiempo.
OA: Cada magia tiene un precio, como dijo el héroe de una serie. En el caso de la planificación de la red de radio, este precio debe calcularse, o bien los autores del borrador del estándar no encontraron tiempo para tales cálculos (¿pero tal vez no valió la pena apresurarse a publicar el proyecto?), O no adivinaron en absoluto para hacerlos.En este caso, como los mismos autores señalaron correctamente anteriormente, el funcionamiento del receptor es un procedimiento que consume bastante energía. En un caso, obtenemos 8 segundos de operación inactiva, en el otro (cuando la ranura de recepción se reduce a 1-2 segundos): la posibilidad de que la estación base no responda (no tenía tiempo para la ranura de tiempo establecida) y la necesidad de reiniciar los mensajes desde el receptor. Era necesario estimar al menos aproximadamente la carga del éter y el consumo de energía en ambos casos, dependiendo de la intensidad del intercambio de radio en la red, y también proporcionar una forma explícitamente descrita para confirmar que el receptor recibió mensajes de la estación base.Finalmente, del texto del estándar no queda claro si toda la premisa aguas abajo debe caer en T dl- o el destinatario, habiendo captado el preámbulo y su dirección, extenderá la ventana de recepción hasta el tiempo suficiente para recibir el paquete completo. Como regla, en los sistemas LPWAN siguen la segunda ruta, esto nuevamente permite reducir la duración requerida de la ventana de recepción.En caso de que el dispositivo suscriptor reciba con éxito el mensaje del canal descendente, en respuesta envía un mensaje sobre la recepción exitosa en el enlace ascendente. Los datos del usuario de los cuales deben contener una indicación del mensaje confirmado.
[...] Un mensaje con carga útil cero puede usarse como confirmación de que la estación base ha recibido datos de una unidad de abonado (acuse de recibo).
OA: Hola de nuevo, seguridad! Como confirmación de entrega, se propone enviar un paquete criptográficamente desprotegido desde la estación base, que cualquiera puede falsificar en medio minuto. Sin mencionar lo que intenta comprender de estos dos párrafos: ¿el dispositivo debe enviar un mensaje sobre su recepción exitosa al ACK? Del texto literal del borrador del estándar resulta que debería. ACK a ACK. Pero, al menos, no se dice en ninguna parte que la estación base debería responder ACK por ACK en ACK, o más bien, el borrador del estándar no dice en ninguna parte cómo la BS debe entender si debe reconocer el paquete o no. Esta no es una propiedad del paquete (aunque con 6 bits vacíos en su encabezado, uno podría asignarse al indicador de confirmación de entrega).¿Y qué significa "debe contener una indicación de un mensaje confirmado"? ¿Cómo se puede señalar un mensaje específico en un sistema en el que no se proporciona un etiquetado individual de mensajes por un protocolo?El estándar OpenUNB requiere una cantidad mínima de energía para enviar un bit de información. Según los resultados de las pruebas preliminares, ahora es uno de los protocolos más ahorradores de energía.
AS: Una declaración controvertida y sin confirmar. El protocolo contiene al menos algunos elementos que indican su baja eficiencia energética:- Una suma de verificación excesivamente larga de 32 bits, aunque todos los fabricantes de dichos sistemas cuestan CRC 16 bits.
- La restricción en la longitud de la información es estrictamente de 64 o 128 bits. Si necesita enviar un mensaje corto de varios bits (por ejemplo, desde cualquier sensor binario - 1 bit), deberá transmitir unos pocos bytes adicionales cada vez, ¿cuál es la eficiencia aquí?
- La necesidad declarada de duplicar la transmisión de un mensaje hasta cuatro veces, lo que cambia de inmediato los parámetros de energía en 4 veces.
- Una larga ventana de 8 segundos para recibir paquetes descendentes.
Me gustaría mucho ver los informes de prueba, hay ciertas dudas de que incluso existan.OA: sí, es difícil entender dónde estaba Skoltech con tanta prisa que ni siquiera podía compartir informes de prueba y otra información que lo acompañara para evaluar con qué se puede contar con el rendimiento real de OpenUNB.OpenUNB es un estándar abierto universal, absolutamente listo para su uso práctico.
AS: El texto del estándar es crudo, contiene descripciones fragmentarias, incompletas e inexactas de elementos perforados individuales; su uso en la práctica es imposible. No hay nada acerca de los detalles del elemento clave de los sistemas UNB: el receptor de la estación base.OA: En general, tengo la sensación de un buen curso de tercer año escrito en una o dos semanas. Bien hecho, asistí a todas las conferencias, incluso entendí 70-80 por ciento, hay cero experiencia real, pero al menos hay un tema para una discusión fructífera con el maestro al aprobar el examen. Antes de la aplicación práctica, no es como antes de la luna: para la aplicación práctica en LPWAN, todo este proyecto tendrá que desecharse y reescribirse.