OpenUNB-Entwurf eines nationalen IoT-Standards: kritische Überprüfung

Hallo Habr!

Vor einiger Zeit veröffentlichte die Skoltech Internet of Things-Arbeitsgruppe einen Entwurf eines nationalen Schmalband-IoT-Standards namens „OpenUNB“, dessen vollständiger Text hier zu finden ist . Einerseits ist das Phänomen zweifellos positiv - wenn es im Bereich der Breitbandstandards ein De-facto-Open für alle gibt, die LoRaWAN nutzen möchten, dann waren Schmalbandstandards bis heute äußerst proprietär (Sigfox, XNB von Strizh, NB-Fi von Vaviot - obwohl Letzteres wird auch in Form eines Entwurfs einer nationalen Norm veröffentlicht. Es enthält keine Teile, die für die Umsetzung durch Dritte wesentlich sind.

Gleichzeitig haben Schmalband- und Breitbandsysteme ihre eigenen Vor- und Nachteile. Die Aussage "Warum brauchen Sie etwas anderes, wenn es LoRaWAN gibt?" Ist also nicht ganz richtig. Das heißt, ein offener Standard für die UNB-Kommunikation wird benötigt.

Die Notwendigkeit ist jedoch nur eine von zwei Bedingungen. Der zweite ist ausreichend. Ok, was Skoltech veröffentlicht hat, ist notwendig, aber reicht es für den praktischen Gebrauch?



Wir werden dies in einem Format beantworten, das einem Interview ähnelt - unter den abgeschnittenen Zitaten aus dem Entwurf des OpenUNB-Standards und den dazugehörigen Kommentaren von Alexander Sheptovetsky (AS), technischer Direktor von GoodWAN, und Oleg Artamonov (OA), technischer Direktor von Unwired Devices.

Also lass uns gehen. Die Stilistik, Rechtschreibung und Zeichensetzung der Autoren bleiben erhalten.

Ein Protokollmerkmal ist die Verwendung einer Ultra-Schmalband-Modulation (die Breite des Emissionsspektrums beträgt weniger als 1 kHz), die es ermöglicht, ein hohes Signal-Rausch-Verhältnis (mit Einschränkungen der Strahlungsleistung im nicht lizenzierten Bereich) zu erzielen, dh Daten über große Entfernungen oder durch mehrere Hindernisse (Betonwände, Trennwände) zu übertragen Metallschränke).

OA: Der erste Fehler der Autoren des Standards besteht darin, dass sie zunächst ein hohes SNR (Signal-Rausch-Verhältnis) als Hauptanforderung für Signale in LPWAN-Systemen annehmen - und aus diesem Grund werden die Fehler beim Entwurf und der Implementierung des Protokolls selbst weiter zunehmen, beispielsweise bei der Auswahl Präambeln zum Beispiel.

In der Realität ist die Hauptfähigkeit der LPWAN-Funkprotokolle, die ihre "Reichweite" bereitstellen, die Fähigkeit, ein Signal mit einem niedrigen SNR bis zu einem negativen zu empfangen, d. H. Fälle, in denen der Signalpegel niedriger als der Rauschpegel ist.

Darüber hinaus sind die Autoren des Standards mit den Grundprinzipien der Theorie der Signalübertragung und insbesondere mit der Shannon-Grenze für die Datenübertragungsrate im Kanal bei Vorhandensein von Rauschen nicht gut vertraut. Diese Geschwindigkeit wird durch den Wert des SNR und die Breite des Signalspektrums bestimmt - tatsächlich wird eine durch die andere kompensiert. Für die Übertragung von Daten in LPWAN-Systemen über große Entfernungen werden daher sowohl Schmalband- als auch Breitbandsignale (z. B. im LoRaWAN-Band - 125 kHz) sehr erfolgreich verwendet. Jedes der Verfahren hat seine eigenen Vor- und Nachteile.

Dies ist möglich, weil Teilnehmergeräte Daten senden, ohne eine Verbindung mit der Basisstation herzustellen (Simplex-Modus), wie dies beispielsweise in Mobilfunknetzen der Fall ist.

OA: Zusätzlich zu Stil- und Interpunktionsfehlern stelle ich die inakzeptable unachtsame Verwendung der Terminologie fest. Der Simplex-Modus, dh die Übertragung von Nachrichten über den Kommunikationskanal nur in eine Richtung, steht nicht in direktem Zusammenhang mit der Notwendigkeit, eine Verbindung herzustellen - und dies sind sicherlich keine Synonyme. Das gleiche LoRaWAN bietet eine bidirektionale Kommunikation im Halbduplexmodus, erfordert jedoch auch keine vorherige Verbindung mit der BS.

Wahrscheinlich hatten die Autoren das Fehlen eines Sitzungsbetriebs in OpenUNB im Auge - aber dies ist ein charakteristisches Merkmal aller LPWAN-Protokolle.

Um die Kosten für den Entwurf des Transceivers zu vereinfachen und zu reduzieren, werden Senden und Empfangen zeitlich getrennt, dh Daten werden von der Basisstation entweder im Simplex-Modus (Übertragung von der Teilnehmereinheit zur Basisstation) oder im Halbduplex-Modus (Übertragung von der Teilnehmereinheit zur Basisstation und anschließend) ausgetauscht Empfang auf dem Teilnehmergerät von der Basisstation).

OA: und buchstäblich eine halbe Seite später stellt sich heraus, dass es in OpenUNB auch einen Halbduplex-Modus gibt! Generell möchte ich darauf hinweisen, dass der Standardentwurf viele solcher internen Widersprüche enthält.

Die Bytereihenfolge im Paket ist vom ältesten zum jüngsten (Big-Endian).

OA: Big-Endian ist eine Art Computerarchitektur mit einer bestimmten Bytereihenfolge in einer Multibyte-Zahl. In einem Paket ist die Bytereihenfolge immer dieselbe - vom ersten bis zum letzten. Ich wiederhole: Für einen Entwurf einer nationalen Norm ist eine solche nachlässige Verwendung etablierter Terminologie nicht akzeptabel.

Pakete können je nach Größe der Nutzlast unterschiedlich lang sein. Optionen für die Nutzlastlänge: 0, 64 oder 128 Bit. Eine Nachricht ohne Nutzlast kann als reguläres Signal verwendet werden, dass das Gerät funktioniert (Herzschlag). Die Paketlängen von 64 und 128 Bit werden durch die Größe der Verschlüsselungsblöcke der Verschlüsselungsalgorithmen bestimmt.

AS: Die Entwickler haben die Nutzlastlänge auf 0, 64 oder 128 Bit begrenzt, um dies mit der Bequemlichkeit der Verschlüsselung zu rechtfertigen. Dies ist eine völlig erfundene Einschränkung. Manchmal müssen Sie sehr kurze Nachrichten senden, aber Sie müssen 64 Bit verwenden. Über welche Energieeffizienz können wir danach sprechen! Das Verschlüsseln von Kurznachrichten mit langen Schlüsseln kann beispielsweise im LoRaWAN-Protokoll gelesen werden.

OA: Ja, im selben LoRaWAN wird regelmäßig das AES-CTR-Verschlüsselungsschema verwendet, mit dem Pakete beliebiger Länge verschlüsselt werden können, einschließlich weniger Schlüssellänge.

Um einen hohen Übertragungsbereich im nicht lizenzierten Bereich zu erreichen, ist ein hohes Signal-Rausch-Verhältnis erforderlich. Dies wird aufgrund der ultrakleinen Übertragungsbandbreite (in der Größenordnung von 100 Hz) erreicht.

AS: Im Standardentwurf gibt es nicht einmal eine einzige Meinung zur Bandbreite - es ist "weniger als 1 kHz", dann "ungefähr 100 Hz". War es nicht möglich, zu einer einzigen Aussage im Standard zu kommen?

OA: und noch einmal über die Notwendigkeit eines hohen SNR. Nein, nein! LPWAN ist auch LPWAN, um auch mit einem negativen SNR zu arbeiten.

Einige Transceiver können ihre Eigenschaften zu Beginn einer Übertragung sehr stark ändern. Dies kann die Frequenz und Länge des modulierten Signals der ersten Bits im Paket beeinflussen. Um diesen Faktor zu kompensieren, wird empfohlen, vor Beginn der Übertragung der Präambel ein Signal mit einer Paketfrequenz von einer Dauer zu senden, die einer Übertragungsdauer von 1-2 Bit entspricht (Abbildung 2). [...] Am Ende der Übertragung sollten Sie nach der Prüfsumme auch 1 Bit mehr studieren und die Signalamplitude schrittweise verringern, was die Wahrscheinlichkeit des korrekten Empfangs des letzten Bits erhöht

AS: Informationen und Zeichnungen stammen aus der technischen Beschreibung von SigFox und sind mit einigen Merkmalen der Beschreibung von SigFox verbunden. Der Empfänger fixiert die Bits nicht zum Zeitpunkt des Phasenwechsels, sondern vorher und nachher. Sie sollten die Funktionen und Beschreibungsfehler anderer Personen nicht gedankenlos kopieren.

Empfohlener Präambelwert für das Uplink-Paket: 101010101010101010 ₂ . Nach Ermessen der Entwickler können die Präambelwerte für das gesamte Netzwerk geändert werden. Dies kann beispielsweise verwendet werden, um mehrere Netzwerke in einem Gebiet zu erstellen, deren Empfang von der einen oder anderen Basisstation auf der Grundlage verschiedener Präambeln aufgeteilt wird.

AS: Kurze Erklärung. UNB-Signalempfänger arbeiten mit Luftgeräuschen. In der Regel werden Direktumwandlungsempfänger verwendet, nach denen FFTs erstellt werden. Wenn das Signal eine Phasenmodulation aufweist, sehen Sie sich die Phasenänderung für jeden Frequenzkanal genauer an. Wenn in einem Kanal eine der Präambel entsprechende digitale Sequenz gefunden wird, wird über das Vorhandensein eines Nutzsignals entschieden. Gleichzeitig geht auf jedem Korrelator nach der FFT ständig eine zufällige Folge von Nullen und Einsen aus dem Rauschen des Äthers hervor - dies bedeutet, dass es immer die Möglichkeit gibt, eine Präambel aus dem Rauschen des Äthers zu erhalten. Lassen Sie uns nun sehen, wie oft falsche Präambeln mit 16 Bit beispielsweise auf dem Empfänger erscheinen, dessen Verwendung von Vaviot, den Autoren eines ähnlichen „Entwurfs eines nationalen Standards“, deklariert wird. Das von ihnen deklarierte Empfangsband beträgt 200 kHz mit einem FFT-Schritt von 7 Hz, was bedeutet, dass mehr als 28.000 Korrelatoren benötigt werden. Für einen exakten Treffer in einer Bitlänge von 10 ms (Übertragungsgeschwindigkeit 100 bps) starten die Korrelatoren alle 2,5 ms. Insgesamt müssen pro Sekunde 11 Millionen Korrelate auf das mögliche Vorhandensein einer Präambel überprüft werden, und pro Sekunde werden durchschnittlich 178 falsche Präambeln aus dem Rauschen des Äthers gegossen . Jede falsche Präambel muss verarbeitet werden - und gleichzeitig den Empfang der wahren Präambeln nicht verlieren. Dies ist eine unangemessen redundante Aufgabe für einen BS-Prozessor, der bereits bis an die Grenzen arbeitet.

Für alle mir bekannten Hersteller von UNB-Systemen ist die Präambel 32 Bit lang und wurde nicht zufällig ausgewählt, sondern aufgrund von Berechnungen und Experimenten.

Darüber hinaus besteht der Zweck der Präambel nicht nur darin, ein nützliches Signal aus dem Rauschstrom zu extrahieren, sondern auch eine Synchronisation bereitzustellen. In UNB-Systemen werden spezielle M-Sequenzen von Bits mit einer ausgeprägten Autokorrelationsfunktion als Präambel verwendet . Wenn beispielsweise vor der von den Autoren vorgeschlagenen Sequenz (10101010101010101 ₂ ) versehentlich ein anderes Paar 10 ₂ vom Rauschen empfangen wird, bestimmt der Empfänger den Beginn der nützlichen Informationen zwei Bits früher und kann das Paket nicht empfangen.

Einige Systeme verwenden reguläre Präambeln, aber danach folgt immer die Wortsynchronisation, die in diesem Protokoll nicht vorgesehen ist. Aus den gleichen Gründen ist es falsch, die Gerätekennung als Präambel für den Downlink zu verwenden, wie von diesem Protokoll bereitgestellt.

OA: Die Autoren des Standardentwurfs lassen sich klar mit der Idee eines „hohen Signal-Rausch-Verhältnisses“ zusammenfassen, das tief in ihren Köpfen verwurzelt ist und das sie bereits mehrfach betont haben. Ja, während Experimenten im Labor ist das SNR hoch und der Empfänger kann im Modus „Ich sehe das Signal - ich empfange das Signal“ arbeiten (und viele billige Produkte, die auf Aliexpress verkauft werden, arbeiten erfolgreich in diesem Modus und bieten eine Kommunikationsreichweite von mehreren hundert Metern).

Unter allen realen Bedingungen und noch mehr bei angegebenen Entfernungen von 50 km stirbt die vorgeschlagene Präambel einfach im Rauschen: Ein schlechtes Bit oder zufälliges Rauschen davor reicht aus, um den Empfänger daran zu hindern, das Paket zu erkennen.

AS: Ohne Elemente der geräuschdichten Codierung ist es unmöglich, unter den Bedingungen des alltäglichen Luftgeräuschs eine qualitativ hochwertige Kommunikation zu erhalten, insbesondere im nicht lizenzierten Frequenzbereich. Dies ist ein „Klassiker des Genres“. Jegliche kurze Impulsstörung im Kanal, die nur ein Bit in der gesamten Sequenz ausschaltet, und der Empfänger akzeptiert nichts.

Die Absender-ID ist eine eindeutige 32-Bit-Sequenz, die einem Gerät während seiner Produktion zugewiesen wird. Weitere Informationen zu Kennungen finden Sie in Anhang E: Format zum Schreiben von Kennungen, Teilnehmereinheiten, Berechnung von Steuerinformationen und reservierten Bereichen von Kennungen.

OA: Der Standard, der behauptet, die Grundlage eines einheitlichen Datenübertragungssystems in Ressourcenabrechnungssystemen zu sein, beschreibt nicht die Regeln, nach denen Hersteller Kennungen für sich selbst auswählen - es wird nicht einmal angegeben, dass solche Regeln jemals existieren werden. Was wird es führen? Das ist richtig, für eine Reihe von Geräten verschiedener Hersteller, aber mit denselben Kennungen, da jeder zweite Hersteller die Geräte einfach von Grund auf neu nummeriert.

Serviceinformationen bestehen aus 8 Bits, wobei die 6 Bits ganz links für die zukünftige Verwendung reserviert sind. 2 Bits sind für die Paketnummer in der Nachricht reserviert.

OA: eine sehr seltsame und sehr bescheidene Menge an Overhead-Informationen. Man könnte die End-to-End-Paketnummer, den Verschlüsselungstyp, die Paketgröße und vieles mehr angeben. Es ist nicht klar, warum wir in der Nachricht überhaupt eine "lokale" Paketnummer benötigen - sagen wir, wir haben die Paketnummer 0 und dann die Nummer 1 erhalten. Sollten wir die zweite verwerfen? Und wenn dies bereits Paket Nummer 1 aus der nächsten Nachricht ist, von der wir die Nummer 0 in der Luft verloren haben? Und wenn wir Pakete auf dieser Basis nicht verwerfen können, wie lösen wir das Problem mit der Tatsache, dass das Gerät 4 identische Pakete hintereinander übertragen kann - akzeptieren und berücksichtigen wir sie alle und empfangen mehrere doppelte Nutzdaten am Ausgang?

AS: Normalerweise folgt eine Präambel einer Überschrift, die die Länge des Pakets angibt, dieses Protokoll jedoch nicht. Wie versteht der Empfänger, wie viele Bits zu wählen sind? Sie können natürlich alle möglichen Längen mit CRC überprüfen, aber niemand tut dies, es ist aus Hardware-Sicht des Empfängers zu teuer.

Die Paketprüfsumme wird basierend auf dem Algorithmus in Anhang B: Berechnung der Paketprüfsumme berechnet.

OA: Um ehrlich zu sein, ich stehe nur mit offenem Mund. Nein, im Allgemeinen wird einfach kein Schutz gegen typische Angriffe im Protokoll bereitgestellt! Mit der deklarierten Sicherheit des Protokolls, der Verwendung starker Chiffren und anderer und anderer kann jeder das Paket eines anderen abfangen, die Felder darin ändern, die Nutzdaten durch ein anderes Paket ersetzen, die Prüfsumme neu berechnen - und es senden, und die Basisstation akzeptiert es und kann in keiner Weise in der Lage sein, eine Fälschung von einem "nativen" Paket zu unterscheiden.

AS: Entwickler schützen nützliche Informationen durch Verschlüsselung, aber das reicht eindeutig nicht aus! Die Entwickler behaupten, dass sie mit den LoRaWAN- und NB-FI-Protokollen vertraut sind. Wenn dies der Fall wäre, würden sie verstehen, warum ein Schutz vor Wiederholungen erforderlich ist und warum ein zusätzlicher Imitationseinsatz im Paket erforderlich ist. Zum Beispiel ist ein Paket mit einer 0-Bit-Nutzlast absolut unsicher, es ist kein Problem, es aus der Luft zu schreiben und zu wiederholen, und das System wird es als sein eigenes verstehen. Es ist für einen Angreifer auch nicht schwierig, Müll an das System zu senden oder im Auftrag eines Sensors in Paketen mit einer Länge ungleich Null zu wiederholen.

Der A-priori-Standard ist bereits zu Informationssicherheitsprotokollen in LoRaWAN geworden, die die Verwendung von zwei Sicherheitsschlüsseln für das Netzwerk und den Benutzer sowie die Möglichkeit zur Generierung von Sitzungsschlüsseln über die Luft rechtfertigten. Die Protokollentwickler haben anscheinend nicht einmal darüber nachgedacht.

Verschlüsselungsschlüssel müssen auf dem Teilnehmergerät und auf den Netzwerkservern in einem sicheren Speicher gespeichert werden. Um Uplink- und Downlink-Pakete zu verschlüsseln, müssen unterschiedliche Verschlüsselungsschlüssel verwendet werden. Für jedes Gerät muss der Satz von Verschlüsselungsschlüsseln eindeutig sein.

OA: Einerseits schreiben sich OpenUNB-Entwickler "Feldgrößen, die in Vielfachen von 8 Bit für eine effizientere Verarbeitung auf Mikroprozessoren ausgewählt wurden" (Schreibweise des Autors) zu verdanken, andererseits scheinen sie einfach nichts über eine so effektive symmetrische Optimierungstechnik zu wissen Verschlüsselung, da die Möglichkeit besteht, anstelle von zwei Verfahren - Verschlüsselung und Entschlüsselung - nur eines auf dem Endgerät zu belassen, wodurch die Größe der Firmware auf Mikrocontrollern erheblich reduziert wird. Zumindest im Standardentwurf wird es nicht erwähnt.

AS: Aber es ist ihnen wirklich gelungen, die Größe der Felder in Vielfachen von 8 Bit zu erfassen!

Das Senden einer Nachricht von einem Downstream-Kanal ist nur als Antwort auf eine Nachricht von einem Upstream-Kanal möglich. Dafür gibt es mehrere Gründe. Erstens ist das Protokoll auf Teilnehmergeräte spezialisiert, die keine externe Stromversorgung haben und für eine besonders lange Akkulaufzeit ausgelegt sind, was bedeutet, dass der Stromverbrauch eine Schlüsselrolle spielt. Da der Verbrauch des Senders im Empfangsmodus sehr hoch ist, sollten Sie nur für kurze Zeit in diesen Modus wechseln

OA: Ich verstehe nicht ganz, warum der Geltungsbereich des Standards bewusst eingeschränkt wird. Tun Sie dies außerdem bereits, als in der Einleitung desselben Standards angegeben. Hat ein normaler Haushaltsstromzähler eine externe Stromversorgung? Hat. Was hindert Sie daran, den „Sender im Empfangsmodus“ ständig eingeschaltet zu lassen? Nichts.

Zweitens ist es nicht möglich, einen bestimmten Zeitschlitz auf einem Teilnehmergerät auszuwählen, da diese zur Reduzierung der Kosten von Teilnehmergeräten häufig mit instabilen Quarzoszillatoren ausgestattet sind und keine Echtzeituhr haben.

OA: Das ist natürlich nicht so. Erstens halten die Autoren mit Blick auf zwei Absätze bereits ein riesiges Empfangsfenster - 8 Sekunden (im selben LoRaWAN sind die Empfangsfenster 1-2 Sekunden groß). Zweitens reicht es aus, zu berechnen, wie oft das Gerät die Uhr mit der Basisstation synchronisieren soll (und eine Methode für eine solche Synchronisation bereitzustellen), damit das Problem der Quarzinstabilität kein Problem darstellt. In LoraWAN erfolgt dies in Geräten der Klasse B.

Drittens erfordert die geringe Stabilität von Quarzoszillatoren auf Teilnehmergeräten die Verwendung des in Anhang D: Einstellung der Downlink-Übertragungsfrequenz beschriebenen Frequenzanpassungsalgorithmus. Da jedoch die letzte Nachricht vom Upstream-Kanal zur Berechnung der Frequenzdrift verwendet wird und sich die Frequenz des Quarzoszillators zeitlich ändern kann (z. B. wenn sich die Temperatur ändert), sollte die Zeit zwischen der letzten Upstream-Nachricht und der Downstream-Nachricht klein genug sein, um die Frequenzabweichung des Teilnehmers zu ändern Gerät während dieser Zeit war vernachlässigbar.

AS: Nach den Details der Beschreibung zu urteilen, betrachten die Entwickler des OpenUNB-Protokolls ihre Lösung für das Problem der Frequenzabwärtssynchronisation als ihre wichtigste Errungenschaft.

Die Berechnungsmethode selbst ist durchaus akzeptabel, es gibt jedoch mehrere Probleme:

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

Wir haben die entsprechenden Studien durchgeführt und konnten unter realen Bedingungen keine Treffergenauigkeit im Bereich von 868 MHz über ± 150 Hz erzielen. Um ein 100-Hz-BPSK-Signal zu empfangen, ist eine Genauigkeit von mindestens 30 Hz erforderlich.

SigFox arbeitet im Rückkanal mit einer Frequenzmodulation von 600 Hz. Ich denke, dass die maximal mögliche Organisation des Rückkanals 2GFSK mit einer Abweichung von 300 Hz und einer Erhöhung der Leistung des nachgeschalteten Signals auf 100 mW ist.

Darüber hinaus funktionieren UNB-Systeme mit Phasenumtastung des Signals bei sich bewegenden Objekten ohnehin nicht sehr gut, da das Phasenrauschen während der Mehrwegesignalausbreitung zunimmt. Das vorgeschlagene Verfahren zum Bestimmen der Frequenz des Abwärtssignals bei Vorhandensein einer Doppler-Vorspannung ergibt einen zusätzlichen Fehler beim Bestimmen der Trägerfrequenz des Aufwärtsverbindungskanals, was zu einem zusätzlichen Fehler beim Bestimmen der Abwärtsfrequenz führt.

Vielleicht haben die Autoren des Protokolls andere Daten, die nicht "auf dem Tisch" bestätigt wurden, aber unter realen Bedingungen möchte ich die Testberichte sehen.

OA: , 30 100 – , 10 % ( LPWAN- , ). OpenUNB , BER 10 % – , OpenUNB , - - , 5 % . , .

, , .

Die Dauer des Zeitintervalls T _dl wird so gewählt, dass sie das Mehrfache der Dauer der Übertragung einer Paket-Downlink-Verbindung beträgt. Eine solche Vergrößerung des Zeitfensters ist notwendig, da normalerweise viele Geräte pro Station vorhanden sind, was dazu führen kann, dass ein Downlink-Paket gleichzeitig an mehrere Geräte gesendet werden muss.

OA: Jede Magie hat einen Preis, wie der Held einer Serie sagte. Bei der Funknetzplanung muss dieser Preis berechnet werden - entweder haben die Autoren des Standardentwurfs keine Zeit für solche Berechnungen gefunden (aber vielleicht hat es sich dann nicht gelohnt, das Projekt zu veröffentlichen?), Oder sie haben überhaupt nicht geraten, sie zu erstellen.

In diesem Fall ist, wie die gleichen Autoren oben richtig bemerkt haben, der Betrieb des Empfängers ein ziemlich energieaufwendiger Vorgang. In einem Fall erhalten wir 8 Sekunden Leerlaufbetrieb, in dem anderen Fall (wenn der Empfangsschlitz auf 1-2 Sekunden reduziert wird) - die Möglichkeit, dass die Basisstation nicht reagiert (sie hatte keine Zeit für den eingestellten Zeitschlitz) und die Notwendigkeit, die Nachrichten vom Empfänger erneut zu initiieren. In beiden Fällen war es notwendig, in Abhängigkeit von der Intensität des Funkaustauschs im Netzwerk mindestens ungefähr die Ätherlast und den Energieverbrauch abzuschätzen und eine explizit beschriebene Methode bereitzustellen, um zu bestätigen, dass der Empfänger Nachrichten von der Basisstation empfangen hat.

Schließlich ist aus dem Text der Norm nicht klar, ob die gesamte nachgelagerte Prämisse in T _dl fallen sollte- oder der Empfänger, der die Präambel und seine Adresse abgefangen hat, verlängert das Empfangsfenster, bis genügend Zeit vorhanden ist, um das gesamte Paket zu erhalten. In LPWAN-Systemen folgen sie in der Regel dem zweiten Pfad, wodurch wiederum die erforderliche Dauer des Empfangsfensters verkürzt werden kann.

Im Falle eines erfolgreichen Empfangs der Nachricht vom nachgeschalteten Kanal durch das Teilnehmergerät sendet es als Antwort eine Nachricht über den erfolgreichen Empfang auf der Aufwärtsverbindung. Die Benutzerdaten sollten einen Hinweis auf die bestätigte Nachricht enthalten.

[...] Eine Nachricht ohne Nutzlast kann als Bestätigung verwendet werden, dass die Basisstation Daten von einer Teilnehmereinheit empfangen hat (Bestätigung).

OA: Hallo nochmal, Sicherheit! Als Bestätigung der Zustellung wird vorgeschlagen, ein kryptografisch ungeschütztes Paket von der Basisstation zu senden, das jeder in einer halben Minute fälschen kann. Ganz zu schweigen davon, was Sie aus diesen beiden Absätzen zu verstehen versuchen - sollte das Gerät eine Nachricht über den erfolgreichen Empfang an das ACK senden? Aus dem wörtlichen Text des Standardentwurfs geht hervor, dass dies der Fall sein sollte. ACK zu ACK. Zumindest wird jedoch nirgendwo gesagt, dass die Basisstation ACK für ACK auf ACK beantworten soll - oder vielmehr, der Standardentwurf sagt nirgendwo aus, wie die BS verstehen soll, ob das Paket bestätigt werden soll oder nicht. Dies ist keine Eigenschaft des Pakets (obwohl mit 6 leeren Bits im Header eines dem Zustellbestätigungsflag zugewiesen werden könnte).

Und was bedeutet es, dass „ein Hinweis auf eine bestätigte Nachricht“ enthalten sein muss? Wie kann man auf eine bestimmte Nachricht in einem System verweisen, in dem keine individuelle Kennzeichnung von Nachrichten durch ein Protokoll vorgesehen ist?

Der OpenUNB-Standard erfordert eine minimale Energiemenge, um ein Informationsbit zu senden. Nach den Ergebnissen von Vorversuchen ist es jetzt eines der energiesparendsten Protokolle.

AS: Eine kontroverse, unbestätigte Aussage. Das Protokoll enthält mindestens einige Elemente, die auf seine geringe Energieeffizienz hinweisen:

• Eine zu lange Prüfsumme von 32 Bit, obwohl alle Hersteller solcher Systeme CRC 16 Bit kosten.
• Die Beschränkung der Informationslänge beträgt nur 64 oder 128 Bit. Wenn Sie eine Kurznachricht mit mehreren Bits senden müssen (z. B. von einem binären Sensor - 1 Bit), müssen Sie jedes Mal ein paar zusätzliche Bytes senden. Wie hoch ist hier die Effizienz?
• Die erklärte Notwendigkeit, die Übertragung einer Nachricht bis zu viermal zu duplizieren, wodurch die Energieparameter sofort um das Vierfache geändert werden.
• Ein langes 8-Sekunden-Fenster zum Empfangen von Downstream-Paketen.

Ich würde die Testberichte sehr gerne sehen, es gibt gewisse Zweifel, dass sie überhaupt existieren.

OA: Ja, es ist schwer zu verstehen, wo Skoltech es so eilig hatte, dass er nicht einmal Testberichte und andere begleitende Informationen teilen konnte, um zu bewerten, auf welche echte OpenUNB-Leistung man zählen kann.

OpenUNB ist ein universeller offener Standard, der absolut einsatzbereit ist.

AS: Der Text der Norm ist grob, er enthält fragmentarische, unvollständige und ungenaue Beschreibungen einzelner punktierter Elemente, seine Verwendung in der Praxis ist unmöglich. Es gibt nichts über die Besonderheiten des Schlüsselelements von UNB-Systemen - des Basisstationsempfängers.

OA: Insgesamt habe ich das Gefühl, dass in ein oder zwei Wochen eine gute Arbeit im dritten Studienjahr geschrieben wurde. Gut gemacht, ich habe alle Vorlesungen besucht, ich habe sogar 70-80 Prozent verstanden, die reale Erfahrung ist immer noch Null, aber zumindest gibt es ein Thema für eine fruchtbare Diskussion mit dem Lehrer, wenn der Test bestanden wird. Vor der praktischen Anwendung ist es nicht nur wie vor dem Mond - für die praktische Anwendung in LPWAN muss das gesamte Projekt verworfen und neu geschrieben werden.