Projet de norme nationale IoT OpenUNB: examen critique

Bonjour, Habr!

Il y a quelque temps, le groupe de travail Skoltech sur l'Internet des objets a publié un projet de norme nationale sur l'Internet des objets à bande étroite appelé «OpenUNB», dont le texte intégral se trouve ici . D'une part, le phénomène est sans aucun doute positif - si, dans le domaine des normes de large bande, il existe de facto un accès ouvert à tous ceux qui le souhaitent, LoRaWAN, alors les normes à bande étroite ont été extrêmement propriétaires à ce jour (Sigfox, XNB de la société Strizh, NB-Fi de la société Vaviot - bien que cette dernière est également publiée sous forme de projet de norme nationale, elle ne révèle pas les parties indispensables à la mise en œuvre par des tiers).

En même temps, les systèmes à bande étroite et à large bande ont leurs propres avantages et inconvénients, donc dire "pourquoi avez-vous besoin d'autre chose quand il y a LoRaWAN" n'est pas tout à fait vrai. Autrement dit, une norme ouverte pour les communications UNB est nécessaire.

Cependant, la nécessité n'est qu'une des deux conditions. La seconde est la suffisance. Ok, ce que Skoltech a publié est nécessaire, mais est-ce suffisant pour une utilisation pratique?



Nous y répondrons dans un format similaire à une interview - sous les citations réduites du projet de norme OpenUNB et des commentaires y relatifs, donnés par Alexander Sheptovetsky (AS), directeur technique de GoodWAN, et Oleg Artamonov (OA), directeur technique de Unwired Devices.

Alors allons-y. La stylistique, l'orthographe et la ponctuation des auteurs sont préservées.

Une caractéristique du protocole est l'utilisation de la modulation à bande ultra-étroite (la largeur du spectre d'émission est inférieure à 1 kHz), ce qui permet d'atteindre un rapport signal / bruit élevé (avec des restrictions sur la puissance rayonnée dans la plage sans licence), ce qui signifie de transmettre des données sur de longues distances ou à travers de multiples obstacles (murs en béton, cloisons armoires métalliques).

OA: la première erreur des auteurs de la norme est qu'ils supposent initialement un SNR élevé (rapport signal / bruit) comme principale exigence pour les signaux dans les systèmes LPWAN - et à partir de cela, les erreurs continueront de croître dans la conception et la mise en œuvre du protocole lui-même, comme le choix préambules, par exemple.

En réalité, la principale capacité des protocoles sans fil LPWAN, en fournissant leur «portée», est la capacité de recevoir un signal avec un faible SNR, jusqu'à un négatif, c'est-à-dire cas où le niveau du signal est inférieur au niveau de bruit.

De plus, les auteurs de la norme ne connaissent pas bien les principes de base de la théorie de la transmission du signal, et en particulier la limite de Shannon sur le taux de transfert de données dans le canal en présence de bruit. Cette vitesse est déterminée par la valeur du SNR et la largeur du spectre du signal - en fait, l'un est compensé par l'autre. Par conséquent, pour transmettre des données dans des systèmes LPWAN sur de longues distances, les signaux à bande étroite et à large bande (par exemple, dans la bande LoRaWAN - 125 kHz) sont utilisés avec succès, chacune des méthodes a ses propres avantages et inconvénients.

Cela est possible du fait que les appareils d'abonnés diffusent des données sans établir de connexion avec la station de base (mode simplex), comme par exemple, cela se fait dans les réseaux cellulaires mobiles.

OA: en plus des erreurs stylistiques et de ponctuation, je note l'usage imprudent et inacceptable de la terminologie. Le mode simplex, c'est-à-dire la transmission de messages sur le canal de communication dans une seule direction, n'est pas directement lié à la nécessité d'établir une connexion - et ce ne sont certainement pas des synonymes. Le même LoRaWAN fournit une communication bidirectionnelle en mode semi-duplex, mais ne nécessite pas non plus de connexion préalable avec la BS.

Probablement, les auteurs avaient à l'esprit l'absence d'un mode de fonctionnement de session dans OpenUNB - mais c'est une caractéristique de tous les protocoles LPWAN.

Pour simplifier et réduire le coût de la conception de l'émetteur-récepteur, la transmission et la réception sont séparées dans le temps, c'est-à-dire que les données sont échangées de la station de base soit en mode simplex (transmission de l'unité d'abonné à la station de base) soit en mode semi-duplex (transmission de l'unité d'abonné à la station de base et les suivantes réception sur l'appareil d'abonné de la station de base).

OA: et littéralement une demi-page plus tard, il s'avère qu'il existe également un mode semi-duplex dans OpenUNB! D'une manière générale, je tiens à noter qu'il existe de nombreuses contradictions internes de ce type dans le projet de norme.

L'ordre des octets dans le paquet est du plus ancien au plus jeune (big-endian)

OA: big-endian est un type d'architecture informatique avec un ordre d'octets spécifique dans un nombre multi-octets. Dans un paquet, l'ordre des octets est toujours le même - du premier au dernier. Je le répète: pour un projet de norme nationale, une telle utilisation imprudente de la terminologie établie est inacceptable.

Les colis peuvent être de différentes longueurs en fonction de la taille de la charge utile. Options de longueur de charge utile: 0, 64 ou 128 bits. Un message avec une charge utile nulle peut être utilisé comme un signal régulier que l'appareil fonctionne (rythme cardiaque). Les longueurs de paquets de 64 et 128 bits sont déterminées par la taille des blocs de chiffrement des algorithmes de chiffrement.

AS: Les développeurs ont limité la longueur de la charge utile à 0, 64 ou 128 bits, justifiant cela par la commodité du chiffrement. Il s'agit d'une limitation complètement artificielle. Parfois, vous devez envoyer des messages très courts, mais vous devez utiliser 64 bits. De quelle efficacité énergétique peut-on parler après ça! Comment chiffrer des messages courts avec des clés longues peut être lu, par exemple, dans le protocole LoRaWAN.

OA: oui, dans le même LoRaWAN, le schéma de chiffrement AES-CTR est régulièrement utilisé, ce qui permet de chiffrer des colis de toute longueur, y compris moins de longueur de clé.

Pour obtenir une plage de transmission élevée dans la plage sans licence, un rapport signal / bruit élevé est requis. Il est obtenu grâce à la bande passante de transmission ultra-petite (de l'ordre de 100 Hz).

AS: dans le projet de norme, il n'y a même pas une seule opinion sur la bande passante - elle est "inférieure à 1 kHz", puis "de l'ordre de 100 Hz". N’a-t-il pas été possible de faire une seule déclaration dans la norme? ..

OA: et encore sur la nécessité d'un SNR élevé. Non, non! LPWAN est également LPWAN pour fonctionner même avec un SNR négatif.

Certains émetteurs-récepteurs peuvent modifier leurs propriétés assez fortement au tout début d'une transmission. Cela peut affecter la fréquence et la longueur du signal modulé des premiers bits du paquet. Pour compenser ce facteur, il est recommandé d'émettre un signal à une fréquence de paquet d'une durée égale à une durée de transmission de 1 à 2 bits avant de commencer la transmission du préambule (figure 2). [...] À la fin de la transmission, après la somme de contrôle, vous devez également étudier 1 bit de plus et réduire progressivement l'amplitude du signal, ce qui augmentera la probabilité de bonne réception du dernier bit

AS: Les informations et les dessins sont tirés de la description technique de SigFox et sont liés à certaines fonctionnalités de la description de SigFox. Le récepteur fixe les bits non pas au moment du changement de phase, mais avant et après. Vous ne devez pas copier sans réfléchir les fonctionnalités et les erreurs de description d'autres personnes.

Valeur de préambule recommandée pour le paquet de liaison montante: 101010101010101010 ₂ . À la discrétion des développeurs, les valeurs de préambule pour l'ensemble du réseau peuvent être modifiées. Par exemple, cela peut être utilisé pour créer plusieurs réseaux sur un même territoire, dont la réception de l'une ou l'autre station de base sera répartie sur la base de différents préambules.

AS: Brève explication. Les récepteurs de signaux UNB fonctionnent au niveau du bruit de l'air. En règle générale, des récepteurs à conversion directe sont utilisés, après quoi des FFT sont effectuées. Si le signal a une modulation de phase, regardez plus loin le changement de phase pour chaque canal de fréquence. Si une séquence numérique correspondant au préambule est trouvée dans n'importe quel canal, alors une décision est prise sur la présence d'un signal utile. En même temps, sur chaque corrélateur après la FFT, une séquence aléatoire de zéros et de uns s'écarte constamment du bruit de l'éther - cela signifie qu'il y a toujours la possibilité d'obtenir un préambule du bruit de l'éther. Voyons maintenant à quelle fréquence de faux préambules de 16 bits apparaîtront, par exemple, sur le récepteur, dont l'utilisation est déclarée par Vaviot, les auteurs d'un "projet de norme nationale" similaire. La bande de réception déclarée par eux est de 200 kHz avec un pas FFT de 7 Hz, ce qui signifie que plus de 28 000 corrélateurs sont nécessaires. Pour un coup exact dans une longueur de bit de 10 ms (vitesse de transmission 100 bps), les corrélateurs démarrent toutes les 2,5 ms. Au total, 11 millions de corrélats doivent être vérifiés chaque seconde pour la présence éventuelle d'un préambule, et une moyenne de 178 faux préambules seront déversés du bruit de l'éther chaque seconde . Chaque faux préambule doit être traité - et en même temps ne pas perdre la réception des vrais préambules. Il s'agit d'une tâche excessivement redondante pour un processeur BS, qui fonctionne déjà à la limite.

Pour tous les fabricants de systèmes UNB que je connais, le préambule mesure 32 bits et n'a pas été choisi par hasard, mais à la suite de calculs et d'expériences.

De plus, le préambule n'a pas seulement pour objet d'extraire un signal utile du flux de bruit, mais également d'assurer la synchronisation. Dans les systèmes UNB, des séquences M spéciales de bits avec une fonction d'autocorrélation prononcée sont utilisées comme préambule . Par exemple, si avant la séquence proposée par les auteurs (1010101010101010 ₂ ), une paire 10 _{2 de plus est} accidentellement reçue du bruit, le récepteur déterminera le début des informations utiles deux bits plus tôt et ne pourra pas recevoir le paquet.

Certains systèmes utilisent des préambules réguliers, mais après eux, il y a toujours le mot synchronisation, qui n'est pas prévu dans ce protocole. Pour les mêmes raisons, il est incorrect d'utiliser l'identifiant de périphérique comme préambule pour la liaison descendante, comme le prévoit ce protocole.

OA: les auteurs du projet de norme se résument clairement à l'idée d'un «rapport signal / bruit élevé» profondément ancré dans leur tête, qu'ils ont déjà souligné à plusieurs reprises. Oui, lors d'expériences en laboratoire, le SNR est élevé et le récepteur peut fonctionner en mode `` Je vois le signal - je reçois le signal '' (et beaucoup de produits bon marché vendus sur Aliexpress fonctionnent avec succès dans ce mode, offrant une portée de communication de plusieurs centaines de mètres).

Dans toutes les conditions réelles, et plus encore à des distances déclarées de 50 km, le préambule proposé mourra simplement dans le bruit: un mauvais bit ou un bruit aléatoire devant lui suffira pour empêcher le récepteur de reconnaître le paquet.

AS: Sans éléments de codage anti-bruit, il est impossible d'obtenir des communications de haute qualité dans les conditions de bruit aérien quotidien, en particulier dans la gamme de fréquences sans licence, c'est un «classique du genre». Toute interférence d'impulsion courte dans le canal, coupant un seul bit dans toute la séquence, et le récepteur n'acceptera rien.

L'ID de l'expéditeur est une séquence unique de 32 bits attribuée à un périphérique lors de sa production. Des informations supplémentaires sur les identifiants sont données dans l'Annexe E: Format d'écriture des identifiants, unités d'abonné, calcul des informations de commande et plages réservées d'identifiants.

OA: la norme, qui prétend être la base d'un système de transfert de données unifié dans les systèmes de comptabilité des ressources, ne décrit pas les règles selon lesquelles les fabricants choisissent eux-mêmes les identifiants - il n'est même pas indiqué que de telles règles existeront un jour. À quoi cela mènera-t-il? C'est vrai, pour un tas d'appareils de différents fabricants, mais avec les mêmes identifiants, car chaque deuxième fabricant numérotera simplement les appareils à partir de zéro.

Les informations de service se composent de 8 bits, les 6 bits les plus à gauche étant réservés pour une utilisation future. 2 bits sont réservés au numéro de paquet dans le message.

OA: une quantité très étrange et très modeste d'informations de frais généraux. On pourrait spécifier le numéro de paquet de bout en bout, le type de cryptage, la taille du paquet et bien plus encore. On ne sait pas pourquoi nous avons même besoin d'un numéro de paquet "local" dans le message - disons que nous avons reçu le numéro de paquet 0, puis le numéro 1. Faut-il éliminer le deuxième? Et si c'est déjà le paquet numéro 1 du message suivant, duquel nous avons perdu le numéro 0 à l'antenne? Et si nous ne pouvons pas éliminer les paquets sur cette base, comment résoudre le problème avec le fait que l'appareil peut transmettre 4 paquets identiques d'affilée - les acceptons-nous et les considérons-nous tous, recevant plusieurs charges utiles en double à la sortie? ..

AS: Habituellement, un préambule suit un en-tête qui indique la longueur du paquet, ce qui n'est pas le cas dans ce protocole. Comment le récepteur comprend-il le nombre de bits à composer? Vous pouvez, bien sûr, vérifier toutes les longueurs possibles en utilisant CRC, mais personne ne le fait, c'est trop cher du point de vue matériel du récepteur.

La somme de contrôle des paquets est calculée sur la base de l'algorithme de l'annexe B: Calcul de la somme de contrôle des paquets.

OA: pour être honnête, je me tiens juste la bouche ouverte. Non, généralement aucune protection contre les attaques typiques dans le protocole n'est simplement fournie! Avec la sûreté et la sécurité déclarées du protocole, l'utilisation de chiffres forts, et d'autres, et d'autres, n'importe qui peut attraper le paquet de quelqu'un d'autre, changer les champs qu'il contient, substituer la charge utile d'un autre paquet, recalculer la somme de contrôle - et la diffuser, et la station de base l'acceptera et ne peut en aucune façon être en mesure de distinguer un faux d'un package "natif".

AS: les développeurs protègent les informations utiles avec le cryptage, mais ce n'est clairement pas suffisant! Les développeurs affirment qu'ils connaissent les protocoles LoRaWAN et NB-FI, si tel était le cas, ils comprendraient pourquoi une protection contre les répétitions est requise et pourquoi une insertion d'imitation supplémentaire est nécessaire dans le package. Par exemple, un colis avec une charge utile de 0 bit est absolument dangereux, il n'y a aucun problème à l'écrire depuis l'air et à le répéter, et le système le comprendra comme le sien. Il n'est pas non plus difficile pour un attaquant d'envoyer des ordures au système ou de répéter pour le compte de n'importe quel capteur dans des packages d'une longueur non nulle.

La norme a priori est déjà devenue des protocoles de sécurité de l'information dans LoRaWAN, ce qui justifiait l'utilisation de deux clés de sécurité, pour le réseau et pour l'utilisateur, ainsi que la possibilité de générer des clés de session par voie aérienne, les développeurs de protocoles n'ont apparemment même pas pensé à cela.

Les clés de chiffrement doivent être stockées sur l'appareil d'abonné et sur les serveurs réseau dans un stockage sécurisé. Pour chiffrer les paquets de liaison montante et de liaison descendante, différentes clés de chiffrement doivent être utilisées. Pour chaque appareil, l'ensemble de clés de chiffrement doit être unique.

OA: d'une part, les développeurs d'OpenUNB se créditent de "tailles de champs sélectionnées en multiples de 8 bits, pour un traitement plus efficace sur microprocesseurs" (orthographe de l'auteur), d'autre part, il semble qu'ils ne connaissent tout simplement pas une technique d'optimisation symétrique aussi efficace le cryptage, comme la possibilité de conserver l'appareil final au lieu de deux procédures - cryptage et décryptage - une seule, ce qui réduit sensiblement la taille du micrologiciel sur les microcontrôleurs. Au moins dans le projet de norme, il n'est pas mentionné.

AS: mais ils ont vraiment réussi à capter les tailles des champs en multiples de 8 bits!

L'envoi d'un message depuis un canal aval n'est possible qu'en réponse à un message provenant d'un canal amont. Il y a plusieurs raisons à cela. Premièrement, le protocole est spécialisé pour les appareils d'abonnés qui n'ont pas d'alimentation externe et sont conçus pour une durée de vie de la batterie extra longue, ce qui signifie que la consommation d'énergie joue un rôle clé. Étant donné que la consommation de l'émetteur en mode réception est assez élevée, vous ne devez passer à ce mode que pendant une courte période

OA: Je ne comprends pas très bien pourquoi limiter consciemment le champ d'application de la norme, d'ailleurs, faites-le déjà que ce qui est indiqué dans l'introduction de la même norme. Un compteur électrique domestique ordinaire a-t-il une alimentation externe? A. Qu'est-ce qui vous empêche de garder «l'émetteur en mode réception» allumé en permanence? Rien.

Deuxièmement, il n'est pas possible de sélectionner un intervalle de temps spécifique sur un appareil d'abonné, car afin de réduire le coût des appareils d'abonné, ils sont souvent équipés d'oscillateurs à cristal instables et n'ont pas d'horloge en temps réel.

OA: Ce n'est bien sûr pas le cas. Premièrement, en regardant deux paragraphes en avant, les auteurs tiennent déjà une immense fenêtre de réception - 8 secondes (dans le même LoRaWAN, les fenêtres de réception sont de 1 à 2 secondes). Deuxièmement, il suffit de calculer la fréquence à laquelle l'appareil doit synchroniser l'horloge avec la station de base (et fournir une méthode pour une telle synchronisation) afin que le problème de l'instabilité du quartz ne soit pas un problème. Dans LoraWAN, cela se fait dans les appareils de classe B.

Troisièmement, la faible stabilité des oscillateurs à cristal sur les dispositifs d'abonné nécessite l'utilisation de l'algorithme de réglage de fréquence décrit dans l'annexe D: Réglage de la fréquence de transmission en liaison descendante. Mais, puisque le dernier message du canal amont est utilisé pour calculer la dérive de fréquence, et que la fréquence de l'oscillateur à cristal peut changer dans le temps (par exemple, lorsque la température change), le temps entre le dernier message amont et l'aval doit être suffisamment petit pour modifier l'écart de fréquence sur l'abonné. pendant cette période était négligeable.

AS: À en juger par les détails de la description, les développeurs du protocole OpenUNB considèrent que leur solution au problème de la synchronisation en fréquence en aval est leur réalisation la plus importante.

La méthode de calcul elle-même est tout à fait acceptable, mais il y a plusieurs problèmes:

• , , .
• .
• , 7 50 , 7 .
• , .
• .
• , , .

Nous avons mené les études appropriées et n'avons pas pu obtenir, dans des conditions réelles, une précision de frappe dans la plage de 868 MHz au-dessus de ± 150 Hz. Pour recevoir un signal BPSK de 100 Hz, une précision d'au moins 30 Hz est requise.

SigFox fonctionne dans le canal de retour avec une modulation de fréquence de 600 Hz. Je pense que l'organisation maximale possible du canal de retour est de 2GFSK avec un écart de 300 Hz et une augmentation de la puissance du signal aval à 100 mW.

De plus, les systèmes UNB avec codage à décalage de phase du signal ne fonctionnent pas très bien sur les objets en mouvement de toute façon en raison d'une augmentation du bruit de phase pendant la propagation du signal par trajets multiples. La méthode proposée pour déterminer la fréquence du signal descendant en présence d'une polarisation Doppler donnera une erreur supplémentaire dans la détermination de la fréquence porteuse du canal de liaison montante, ce qui conduira à une erreur supplémentaire dans la détermination de la fréquence descendante.

Peut-être que les auteurs du protocole ont d'autres données, confirmées non pas "sur la table", mais en conditions réelles, j'aimerais voir les rapports d'essais.

OA:J'ajoute que même un écart de 30 Hz avec une bande de 100 Hz n'est pas une réception idéale, mais environ 10% des erreurs de bits (dans les systèmes LPWAN, cela est traditionnellement pris à l'étranger, où la qualité de réception peut toujours être considérée comme acceptable). Étant donné le manque de codage du bruit dans OpenUNB, la probabilité qu'un message de l'ordre de quelques centaines de bits capture au moins une erreur avec un BER de 10% est très élevée - c'est-à-dire que dans OpenUNB j'évaluerais l'écart de fréquence admissible auquel quelque chose d'autre en quelque sorte seront parfois prises, à 5% maximum. En trente fois mieux qu'il est possible d'obtenir en réalité.

En bref, il existe de sérieux doutes que la méthode d'organisation d'un canal de communication inverse décrite dans le projet de norme soit généralement opérationnelle en principe.

La durée de l'intervalle de temps T _dl est choisie pour être plusieurs fois la durée de la transmission d'une liaison descendante de paquet. Une telle augmentation de la taille de la fenêtre temporelle est nécessaire, car il y a généralement de nombreux périphériques par station, ce qui peut entraîner la nécessité d'envoyer un paquet de liaison descendante à plusieurs périphériques en même temps.

OA: Chaque magie a un prix, comme l'a dit le héros d'une série. Dans le cas de la planification d'un réseau radio, ce prix doit être calculé - et soit les auteurs du projet de norme n'ont pas trouvé le temps de faire de tels calculs (mais peut-être alors ne valait-il pas la peine de se précipiter pour publier le projet?), Ou bien ils n'ont pas du tout deviné de les faire.

Dans ce cas, comme les mêmes auteurs l'ont correctement noté ci-dessus, le fonctionnement du récepteur est une procédure plutôt énergivore. Dans un cas, nous obtenons 8 secondes de fonctionnement inactif, dans l'autre (lorsque le créneau de réception est réduit à 1-2 secondes) - la possibilité que la station de base ne réponde pas (elle n'a pas eu le temps pour le créneau horaire défini) et la nécessité de relancer la messagerie du récepteur. Il était nécessaire d'estimer au moins approximativement la charge de l'éther et la consommation d'énergie dans les deux cas, en fonction de l'intensité de l'échange radio dans le réseau, et également de prévoir un moyen explicitement décrit pour confirmer que le récepteur a reçu des messages de la station de base.

Enfin, il ne ressort pas clairement du texte de la norme si l'ensemble du local en aval doit tomber dans T _dl- ou le destinataire, après avoir pris le préambule et son adresse, étendra la fenêtre de réception jusqu'à ce qu'il ait le temps de recevoir le colis dans son intégralité. En règle générale, dans les systèmes LPWAN, ils suivent le deuxième chemin, cela permet à nouveau de réduire la durée requise de la fenêtre de réception.

En cas de réception réussie par le dispositif abonné du message du canal aval, il envoie en réponse un message de réception réussie sur la liaison montante. Les données utilisateur doivent contenir une indication du message confirmé.

[...] Un message avec une charge utile nulle peut être utilisé comme confirmation que la station de base a reçu des données d'une unité d'abonné (accusé de réception).

OA: Bonjour encore une fois, la sécurité! Comme confirmation de livraison, il est proposé d'envoyer un paquet cryptographiquement non protégé à partir de la station de base, que n'importe qui peut truquer en une demi-minute. Sans parler de ce que vous essayez de comprendre à partir de ces deux paragraphes - l'appareil doit-il envoyer un message sur sa réception réussie à l'ACK? Il ressort du texte littéral du projet de norme qu'il le devrait. ACK à ACK. Mais, au moins, il n'est dit nulle part que la station de base devrait répondre ACK pour ACK sur ACK - ou plutôt, le projet de norme ne dit nulle part comment la BS doit comprendre si elle doit accuser réception du paquet ou non. Ce n'est pas une propriété du paquet (bien qu'avec 6 bits vides dans son en-tête, un puisse être attribué à l'indicateur de confirmation de livraison).

Et qu'est-ce que cela signifie, "une indication d'un message qui est confirmé" doit être contenue? Comment désigner un message spécifique dans un système dans lequel un étiquetage individuel des messages par un protocole n'est pas fourni?

La norme OpenUNB nécessite un minimum d'énergie pour envoyer un bit d'information. Selon les résultats des tests préliminaires, il s'agit désormais de l'un des protocoles les plus économes en énergie.

AS: Une déclaration controversée et non confirmée. Le protocole contient au moins quelques éléments qui indiquent sa faible efficacité énergétique:

• Une somme de contrôle excessivement longue de 32 bits, bien que tous les fabricants de tels systèmes coûtent CRC 16 bits.
• La restriction sur la longueur des informations n'est que strictement de 64 ou 128 bits. Si vous devez envoyer un court message de plusieurs bits (par exemple, à partir de n'importe quel capteur binaire - 1 bit), vous devrez alors transmettre quelques octets supplémentaires à chaque fois, quelle est l'efficacité ici.
• Le besoin déclaré de dupliquer la transmission d'un message jusqu'à quatre fois, ce qui modifie immédiatement les paramètres énergétiques de 4 fois.
• Une longue fenêtre de 8 secondes pour recevoir les paquets en aval.

J'aimerais beaucoup voir les rapports d'essais, il y a certains doutes qu'ils existent même.

OA: oui, il est difficile de comprendre où Skoltech était si pressé qu'il ne pouvait même pas partager des rapports de test et d'autres informations de support pour évaluer les performances réelles d'OpenUNB.

OpenUNB est un standard ouvert universel, absolument prêt pour une utilisation pratique.

AS: Le texte de la norme est grossier, il contient des descriptions fragmentaires, incomplètes et inexactes des éléments perforés individuels; son utilisation dans la pratique est impossible. Il n'y a rien sur les spécificités de l'élément clé des systèmes UNB - le récepteur de la station de base.

OA: Dans l'ensemble, j'ai le sentiment d'un bon travail de cours de troisième année écrit en une semaine ou deux. Bien joué, j'ai assisté à toutes les conférences, j'ai même compris 70-80 pour cent, il n'y a pas encore d'expérience réelle, mais au moins il y a un sujet de discussion fructueuse avec l'enseignant lors du passage du test. Avant l'application pratique, ce n'est pas comme avant la lune - pour une application pratique dans LPWAN, tout ce projet devra être rejeté et réécrit.