OpenUNB draft national IoT standard: critical review
Hello, Habr!
Some time ago, the Skoltech Internet of Things Working Group published a draft national narrowband IoT standard called “OpenUNB,” the full text of which can be found here . On the one hand, the phenomenon is undoubtedly positive - if in the field of broadband standards there is a de facto open for use by all comers, LoRaWAN, then narrow-band standards have been extremely proprietary to this day (Sigfox, XNB from Strizh, NB-Fi from Vaviot - although the latter is also published in the form of a draft national standard, it does not reveal parts that are essential for third-party implementation).
At the same time, narrow-band and wide-band systems have their own pros and cons, so saying “why do you need something else when there is LoRaWAN” is not entirely true. That is, an open standard for UNB communications is needed.
However, necessity is only one of two conditions. The second is sufficiency. Ok, what Skoltech published is necessary, but is it enough for practical use?
We will answer this in a format similar to an interview - under the cut quotes from the draft OpenUNB standard and comments thereto, given by Alexander Sheptovetsky (AS), technical director of GoodWAN, and Oleg Artamonov (OA), technical director of Unwired Devices.
So let's go. The stylistics, spelling and punctuation of the authors are preserved.
In reality, the main capability of the LPWAN wireless protocols, providing their “range”, is the ability to receive a signal with a low SNR, up to a negative one, i.e. cases when the signal level is lower than the noise level.
In addition, the authors of the standard are not well acquainted with the basic principles of the theory of signal transmission, and specifically with the Shannon limit on the data transfer rate in the channel in the presence of noise. This speed is determined by the value of SNR and the width of the signal spectrum - in fact, one is compensated by the other. Therefore, for transmitting data in LPWAN systems over long distances, both narrowband and wideband (for example, in the LoRaWAN band - 125 kHz) signals are quite successfully used, each of the methods has its own advantages and disadvantages.
Probably, the authors had in mind the absence of a session mode of operation in OpenUNB - but this is a characteristic feature of all LPWAN protocols.
OA: yes, in the same LoRaWAN the AES-CTR encryption scheme is regularly used, which allows encrypting parcels of any length, including less key length.
OA: and again about the need for high SNR. No! LPWAN is also LPWAN to work even with a negative SNR.
AS: Information and drawing are taken from the technical description of SigFox and are connected with some features of the description of SigFox. The receiver fixes the bits not at the moment of phase change, but before and after. You should not thoughtlessly copy other people's features and description errors.
For all manufacturers of UNB systems I know of, the preamble is 32 bits long and it was chosen not by chance, but as a result of calculations and experiments.
In addition, the purpose of the preamble is not only to isolate the useful signal from the noise stream, but also to provide synchronization. In UNB systems, special M-sequences of bits with a pronounced autocorrelation function are used as a preamble . For example, if before the sequence that the authors propose (1010101010101010 2 ), another pair 10 2 is accidentally received from the noise, then the receiver will determine the beginning of the useful information two bits earlier and will not be able to receive the packet.
Some systems use regular preambles, but after them then always comes the word synchronization, which is not provided for in this protocol. For the same reasons, it is incorrect to use the device identifier as the preamble for the downlink, as provided for by this protocol.
OA: the authors of the draft standard are clearly summed up by the idea of a “high signal-to-noise ratio” that is deeply rooted in their heads, which they have already emphasized several times. Yes, during experiments within the laboratory, the SNR is high, and the receiver can work in the “I see a signal - I receive a signal” mode (and a lot of cheap products sold on Aliexpress successfully work in this mode, providing a communication range of several hundred meters).
In any real conditions, and even more so at declared ranges of 50 km, the proposed preamble will simply die in noise: one bad bit in it or random noise in front of it will be enough to prevent the receiver from recognizing the packet.
AS: Without elements of noise-proof coding, it is impossible to get high-quality communication in the conditions of everyday air noise, especially in the unlicensed frequency range, this is a "classic of the genre." Any short pulse interference in the channel, knocking out only one bit in the entire sequence, and the receiver will not accept anything.
AS: Usually a preamble follows a heading that indicates the length of the packet; this is not the case in this protocol. How does the receiver understand how many bits to dial? You can, of course, check all possible lengths using CRC, but no one does it, it is too expensive from the hardware point of view of the receiver.
AS: developers protect useful information with encryption, but this is clearly not enough! The developers claim that they are familiar with the LoRaWAN and NB-FI protocols, if this were so, they would understand why protection against repetitions is required and why an additional imitation insert is needed in the package. For example, sending a 0-bit payload is completely unsafe, there is no problem writing it from the air and repeating it, and the system will understand it as its own. It is also not difficult for an attacker to send any garbage to the system or repeat on behalf of any sensor in packages with a non-zero length.
The a priori standard already became information security protocols in LoRaWAN, which justified the use of two security keys, for the network and for the user, as well as the ability to generate session keys over the air, the protocol developers apparently did not even think about.
AS: but they really succeeded in picking up the sizes of the fields in multiples of 8 bits!
The calculation method itself is quite acceptable, but there are several problems:
We conducted the appropriate studies and were not able to obtain, under real conditions, a hit accuracy in the range of 868 MHz above ± 150 Hz. To receive a 100 Hz BPSK signal, accuracy of at least 30 Hz is required.
SigFox operates in the return channel with a frequency modulation of 600 Hz. I think that the maximum possible organization of the return channel is 2GFSK with a deviation of 300 Hz and an increase in the power of the downstream signal to 100 mW.
In addition, UNB systems with phase-shift keying of the signal do not work very well on moving objects anyway due to an increase in phase noise during multipath signal propagation. The proposed method for determining the frequency of the downward signal in the presence of Doppler bias will give an additional error in determining the carrier frequency of the upward channel, which will lead to an additional error in determining the downward frequency.
Perhaps the authors of the protocol have other data, confirmed not "on the table", but in real conditions, I would like to see test reports.
OA: I ’ll add that even a deviation of 30 Hz with a band of 100 Hz is not an ideal reception, but about 10% bit errors (in LPWAN systems, this is traditionally taken abroad, at which the reception quality can still be considered acceptable). Given the lack of noise-encoding in OpenUNB, the probability of a message of the order of a couple of hundred bits to catch at least one error with a BER of 10% is very high - that is, specifically in OpenUNB I would evaluate the permissible frequency deviation, at which something else somehow will sometimes be taken, at 5% maximum. Thirty times better than being able to get in reality.
In short, there are serious doubts that the method of organizing a reverse communication channel described in the draft standard is generally operational in principle.
In this case, as the same authors correctly noted above, the operation of the receiver is a rather energy-consuming procedure. In one case, we get 8 seconds of idle operation, in the other (when the reception slot is reduced to 1-2 seconds) - the possibility of the base station not responding (it did not have time for the set time slot) and the need to re-initiate the exchange of messages from the receiver. It was necessary to estimate at least approximately the load of the ether and the energy consumption in both cases, depending on the intensity of the radio exchange in the network, and also to provide for the explicitly described way to confirm that the receiver received messages from the base station.
Finally, it is not clear from the text of the standard whether the entire downstream parcel should be in T dl - or the recipient, having caught the preamble and his address, will stretch the receive window until enough time to receive the whole parcel. As a rule, in LPWAN-systems they follow the second path, this again allows to reduce the required duration of the receive window.
And what does it mean "should contain an indication of the message that is confirmed"? How can one point to a specific message in a system in which an individual labeling of messages by a protocol is not provided for?
I would very much like to see the test reports, there are certain doubts that they even exist.
OA: yes, it’s hard to understand where Skoltech was in such a hurry that he couldn’t even share test reports and other supporting information to assess what real OpenUNB performance can be counted on.
OA: , -, -. , , 70-80 , , . – LPWAN .
Some time ago, the Skoltech Internet of Things Working Group published a draft national narrowband IoT standard called “OpenUNB,” the full text of which can be found here . On the one hand, the phenomenon is undoubtedly positive - if in the field of broadband standards there is a de facto open for use by all comers, LoRaWAN, then narrow-band standards have been extremely proprietary to this day (Sigfox, XNB from Strizh, NB-Fi from Vaviot - although the latter is also published in the form of a draft national standard, it does not reveal parts that are essential for third-party implementation).
At the same time, narrow-band and wide-band systems have their own pros and cons, so saying “why do you need something else when there is LoRaWAN” is not entirely true. That is, an open standard for UNB communications is needed.
However, necessity is only one of two conditions. The second is sufficiency. Ok, what Skoltech published is necessary, but is it enough for practical use?
We will answer this in a format similar to an interview - under the cut quotes from the draft OpenUNB standard and comments thereto, given by Alexander Sheptovetsky (AS), technical director of GoodWAN, and Oleg Artamonov (OA), technical director of Unwired Devices.
So let's go. The stylistics, spelling and punctuation of the authors are preserved.
A feature of the protocol is the use of ultra-narrowband modulation (the width of the emission spectrum is less than 1 kHz), which allows to achieve a high signal-to-noise ratio (with restrictions on the radiated power in the unlicensed range), which means to transmit data over long distances or through multiple obstacles (concrete walls, partitions metal cabinets).OA: the first mistake of the authors of the standard is that they initially assume high SNR (signal-to-noise ratio) for signals in LPWAN systems, and from this errors will continue to grow in the design and implementation of the protocol itself, such as choosing preambles, for example.
In reality, the main capability of the LPWAN wireless protocols, providing their “range”, is the ability to receive a signal with a low SNR, up to a negative one, i.e. cases when the signal level is lower than the noise level.
In addition, the authors of the standard are not well acquainted with the basic principles of the theory of signal transmission, and specifically with the Shannon limit on the data transfer rate in the channel in the presence of noise. This speed is determined by the value of SNR and the width of the signal spectrum - in fact, one is compensated by the other. Therefore, for transmitting data in LPWAN systems over long distances, both narrowband and wideband (for example, in the LoRaWAN band - 125 kHz) signals are quite successfully used, each of the methods has its own advantages and disadvantages.
This is possible due to the fact that subscriber devices broadcast data without establishing a connection with the base station (simplex mode), as for example, this is done in mobile cellular networks.OA: in addition to stylistic and punctuation errors, I note the unacceptable careless use of terminology. The simplex mode, that is, the transmission of messages over the communication channel only in one direction, is not directly related to the need to establish a connection - and certainly these are not synonyms. The same LoRaWAN provides two-way communication in half-duplex mode, but it also does not require prior connection with the BS.
Probably, the authors had in mind the absence of a session mode of operation in OpenUNB - but this is a characteristic feature of all LPWAN protocols.
To simplify and reduce the cost of the design of the transceiver, the transmission and reception are separated in time, that is, data is exchanged from the base station either in simplex mode (transmission from the subscriber unit to the base station) or in half-duplex mode (transmission from the subscriber unit to the base station and the subsequent reception on the subscriber device from the base station).OA: and literally half a page later it turns out that there is also half-duplex mode in OpenUNB! In general, I want to note that there are a lot of such internal contradictions in the draft standard.
The byte order in the packet is from oldest to youngest (big-endian)OA: big-endian is a type of computer architecture with a specific byte order in a multibyte number. In a packet, the byte order is always the same - from the first to the last. I repeat: for a draft national standard, such a careless use of established terminology is unacceptable.
Packages can be of different lengths depending on the size of the payload. Payload length options: 0, 64, or 128 bits. A message with zero payload can be used as a regular signal that the device is functioning (heartbeat). The packet lengths of 64 and 128 bits are determined by the size of the cipher blocks of the encryption algorithms.AS: The developers have limited the payload length to 0, 64 or 128 bits, justifying this with the convenience of encryption. This is a completely contrived limitation. Sometimes you need to send very short messages, but you have to use 64 bits. What energy efficiency can we talk about after that! How to encrypt short messages with long keys can be read, for example, in the LoRaWAN protocol.
OA: yes, in the same LoRaWAN the AES-CTR encryption scheme is regularly used, which allows encrypting parcels of any length, including less key length.
To achieve a high transmission range in the unlicensed range, a high signal to noise ratio is required. It is achieved due to the ultra-small transmission bandwidth (of the order of 100 Hz).AS: in the draft standard there is not even a single opinion on the bandwidth - it is “less than 1 kHz”, then “of the order of 100 Hz”. Wasn’t it possible to come to a single statement in the standard? ..
OA: and again about the need for high SNR. No! LPWAN is also LPWAN to work even with a negative SNR.
Some transceivers can change their properties quite strongly at the very beginning of a transmission. This may affect the frequency and length of the modulated signal of the first bits in the packet. To compensate for this factor, it is recommended to emit a signal at a packet frequency of a duration equal to a transmission duration of 1-2 bits before starting the transmission of the preamble (Figure 2). [...] At the end of the transmission, after the checksum, you should also study 1 bit more and gradually reduce the signal amplitude, which will increase the probability of the correct reception of the last bit
AS: Information and drawing are taken from the technical description of SigFox and are connected with some features of the description of SigFox. The receiver fixes the bits not at the moment of phase change, but before and after. You should not thoughtlessly copy other people's features and description errors.
Recommended preamble value for uplink burst: 101010101010101010 2 . At the discretion of the developers, the preamble values for the entire network may be changed. For example, this can be used to create several networks in one territory, the reception of which of one or another base station will be divided on the basis of various preambles.AS: Brief explanation. UNB signal receivers operate at the level of air noise. As a rule, direct conversion receivers are used, after which FFTs are made. If the signal has phase modulation, then look further at the phase change for each frequency channel. If a digital sequence corresponding to the preamble is found in any channel, then a decision is made on the presence of a useful signal. At the same time, on each correlator after the FFT, a random sequence of zeros and ones is constantly going from the ether noises - this means that there is always the possibility of getting a preamble from the ether noises. Now let's see how often false preambles of 16 bits will appear, for example, on the receiver, the use of which is declared by Vaviot, the authors of a similar “draft national standard”. The reception band declared by them is 200 kHz with an FFT step of 7 Hz, which means that more than 28 thousand correlators are needed. For an exact hit in a bit length of 10 ms (transmission speed 100 bps), the correlators start every 2.5 ms. In total, every second, 11 million correlates must be checked for the possible presence of a preamble, and an average of 178 false preambles will be poured from the noise of the ether every second . Each false preamble must be processed - and at the same time, the reception of the true preambles must not be lost. This is an unreasonably redundant task for a BS processor, which already works to the limit.
For all manufacturers of UNB systems I know of, the preamble is 32 bits long and it was chosen not by chance, but as a result of calculations and experiments.
In addition, the purpose of the preamble is not only to isolate the useful signal from the noise stream, but also to provide synchronization. In UNB systems, special M-sequences of bits with a pronounced autocorrelation function are used as a preamble . For example, if before the sequence that the authors propose (1010101010101010 2 ), another pair 10 2 is accidentally received from the noise, then the receiver will determine the beginning of the useful information two bits earlier and will not be able to receive the packet.
Some systems use regular preambles, but after them then always comes the word synchronization, which is not provided for in this protocol. For the same reasons, it is incorrect to use the device identifier as the preamble for the downlink, as provided for by this protocol.
OA: the authors of the draft standard are clearly summed up by the idea of a “high signal-to-noise ratio” that is deeply rooted in their heads, which they have already emphasized several times. Yes, during experiments within the laboratory, the SNR is high, and the receiver can work in the “I see a signal - I receive a signal” mode (and a lot of cheap products sold on Aliexpress successfully work in this mode, providing a communication range of several hundred meters).
In any real conditions, and even more so at declared ranges of 50 km, the proposed preamble will simply die in noise: one bad bit in it or random noise in front of it will be enough to prevent the receiver from recognizing the packet.
AS: Without elements of noise-proof coding, it is impossible to get high-quality communication in the conditions of everyday air noise, especially in the unlicensed frequency range, this is a "classic of the genre." Any short pulse interference in the channel, knocking out only one bit in the entire sequence, and the receiver will not accept anything.
Sender ID is a unique 32-bit sequence assigned to a device during its production. Additional information about identifiers is given in Appendix E: Format for writing identifiers, subscriber units, calculation of control information and reserved ranges of identifiers.OA: the standard, which claims to be the basis of a unified data transfer system in resource accounting systems, does not describe the rules by which manufacturers choose identifiers for themselves - it is not even indicated that such rules will ever exist. Where it leads? That's right, to a bunch of devices from different manufacturers, but with the same identifiers, because every second manufacturer will simply number the devices from scratch.
Service information consists of 8 bits, with the leftmost 6 bits reserved for future use. 2 bits are reserved for the packet number in the message.OA: a very strange and very modest amount of overhead information. One could specify the end-to-end packet number, encryption type, packet size, and much more. At the same time, it is not clear why we even need a “local” packet number in the message — let's say we received packet number 0, and then number 1. Should we discard the second one? And if this is packet number 1 already from the next message, from which we lost number 0 on the air? And if we cannot discard packets on this basis, how do we solve the problem with the fact that the device can transmit 4 identical packets in a row - do we accept and consider them all, receiving multiple duplicate payloads at the output? ..
AS: Usually a preamble follows a heading that indicates the length of the packet; this is not the case in this protocol. How does the receiver understand how many bits to dial? You can, of course, check all possible lengths using CRC, but no one does it, it is too expensive from the hardware point of view of the receiver.
The checksum of the packet is calculated based on the algorithm given in Appendix B: Calculation of the checksum of the packets.OA: to be honest, I just stand with my mouth open. No, generally no protection against typical attacks in the protocol is simply provided! With the declared safety and security of the protocol, the use of strong ciphers, and others, and others, anyone can catch someone else’s packet, change the fields in it, substitute the payload from another packet, recalculate the checksum - and broadcast it, and the base station will accept it and will not be able to distinguish a fake from a "native" package.
AS: developers protect useful information with encryption, but this is clearly not enough! The developers claim that they are familiar with the LoRaWAN and NB-FI protocols, if this were so, they would understand why protection against repetitions is required and why an additional imitation insert is needed in the package. For example, sending a 0-bit payload is completely unsafe, there is no problem writing it from the air and repeating it, and the system will understand it as its own. It is also not difficult for an attacker to send any garbage to the system or repeat on behalf of any sensor in packages with a non-zero length.
The a priori standard already became information security protocols in LoRaWAN, which justified the use of two security keys, for the network and for the user, as well as the ability to generate session keys over the air, the protocol developers apparently did not even think about.
Encryption keys must be stored on the subscriber device and on the network servers in a secure storage. To encrypt uplink and downlink packets, different encryption keys must be used. For each device, the set of encryption keys must be unique.OA: on the one hand, OpenUNB developers credit themselves with “field sizes selected in multiples of 8 bits, for more efficient processing on microprocessors” (author’s spelling), on the other hand, it seems that they simply don’t know about such an effective symmetrical optimization technique encryption, as an opportunity to keep on the end device instead of two procedures - encryption and decryption - only one, which pretty much reduces the size of the firmware on microcontrollers. At least in the draft standard it is not mentioned.
AS: but they really succeeded in picking up the sizes of the fields in multiples of 8 bits!
Sending a message from a downstream channel is only possible in response to a message from an upstream channel. There are several reasons for this. Firstly, the protocol is specialized for subscriber devices that do not have external power and are designed for extra long battery life, which means that power consumption plays a key role. Since the consumption of the transmitter in the reception mode is quite high, you should switch to this mode only for a short period of timeOA: I do not quite understand why consciously limit the scope of the standard, moreover, do it already than stated in the introduction to the same standard. Does a regular household electric meter have external power? It has. What prevents you from keeping the “transmitter in receive mode” turned on all the time? Nothing.
Secondly, it is not possible to select a specific time slot on a subscriber device, since in order to reduce the cost of subscriber devices, they are often equipped with unstable crystal oscillators and do not have a real-time clock.OA: This, of course, is not so. Firstly, looking ahead two paragraphs, the authors are already holding a huge reception window - 8 seconds (in the same LoRaWAN, reception windows are 1-2 seconds in size). Secondly, it is enough to calculate how often the device should synchronize the clock with the base station (and provide a method for such synchronization) so that the problem of quartz instability is not a problem. In LoraWAN, this is done in Class B devices.
Thirdly, the low stability of crystal oscillators on subscriber devices requires the use of the frequency adjustment algorithm described in Appendix D: Correction of the downlink transmission frequency. But, since the last message from the upstream channel is used to calculate the frequency drift, and the frequency of the crystal oscillator can change in time (for example, when the temperature changes), the time between the last upstream message and the downstream should be small enough to change the frequency deviation on the subscriber’s device during this period was negligible.AS: Judging by the details of the description, the developers of the OpenUNB protocol consider the solution to the problem of synchronizing the down-channel in frequency as their most important achievement.
The calculation method itself is quite acceptable, but there are several problems:
- The spectrum of the emitted signal from the sensor contains phase noise of the generator, the signal is mixed with the noise of the ether, and the reception band is blurred.
- Doppler shift and multipath propagation has not been canceled.
- There is a discreteness in determining the frequency of the base station, determined by the Fourier step from 7 to 50 Hz, and at 7 Hz it is possible to determine in several bands.
- The base station receiver correlators are not synchronized with the received signal, and the FFT captures the tails of the upside-down bits.
- The resolution increment of the correlators at the base station receiver does not allow to get exactly to the beginning of the bit.
- These problems are especially pronounced on weak signals in a noisy broadcast, but will also be present when calibrating the frequency with a real test signal from the broadcast, as this protocol suggests.
We conducted the appropriate studies and were not able to obtain, under real conditions, a hit accuracy in the range of 868 MHz above ± 150 Hz. To receive a 100 Hz BPSK signal, accuracy of at least 30 Hz is required.
SigFox operates in the return channel with a frequency modulation of 600 Hz. I think that the maximum possible organization of the return channel is 2GFSK with a deviation of 300 Hz and an increase in the power of the downstream signal to 100 mW.
In addition, UNB systems with phase-shift keying of the signal do not work very well on moving objects anyway due to an increase in phase noise during multipath signal propagation. The proposed method for determining the frequency of the downward signal in the presence of Doppler bias will give an additional error in determining the carrier frequency of the upward channel, which will lead to an additional error in determining the downward frequency.
Perhaps the authors of the protocol have other data, confirmed not "on the table", but in real conditions, I would like to see test reports.
OA: I ’ll add that even a deviation of 30 Hz with a band of 100 Hz is not an ideal reception, but about 10% bit errors (in LPWAN systems, this is traditionally taken abroad, at which the reception quality can still be considered acceptable). Given the lack of noise-encoding in OpenUNB, the probability of a message of the order of a couple of hundred bits to catch at least one error with a BER of 10% is very high - that is, specifically in OpenUNB I would evaluate the permissible frequency deviation, at which something else somehow will sometimes be taken, at 5% maximum. Thirty times better than being able to get in reality.
In short, there are serious doubts that the method of organizing a reverse communication channel described in the draft standard is generally operational in principle.
The duration of the time interval T dl is selected to be multiple times the duration of the transmission of one packet downlink. Such an increase in the size of the time window is necessary, since there are usually many devices per station, which can lead to the need to send a downlink packet to several devices at the same time.OA: Every magic comes with a price, as the hero of one series said. In the case of radio network planning, this price must be calculated - and either the authors of the draft standard did not find time for such calculations (but maybe then it was not worth rushing to publish the project?), Or did not even guess to make them.
In this case, as the same authors correctly noted above, the operation of the receiver is a rather energy-consuming procedure. In one case, we get 8 seconds of idle operation, in the other (when the reception slot is reduced to 1-2 seconds) - the possibility of the base station not responding (it did not have time for the set time slot) and the need to re-initiate the exchange of messages from the receiver. It was necessary to estimate at least approximately the load of the ether and the energy consumption in both cases, depending on the intensity of the radio exchange in the network, and also to provide for the explicitly described way to confirm that the receiver received messages from the base station.
Finally, it is not clear from the text of the standard whether the entire downstream parcel should be in T dl - or the recipient, having caught the preamble and his address, will stretch the receive window until enough time to receive the whole parcel. As a rule, in LPWAN-systems they follow the second path, this again allows to reduce the required duration of the receive window.
In case of successful reception by the subscriber device of the message from the downstream channel, it in response sends a message about successful reception on the uplink. The user data of which should contain an indication of the message which is confirmed.OA: Hello again, security! As a confirmation of delivery, it is proposed to send a cryptographically unprotected packet from the base station, which anyone can fake in half a minute. Not to mention what you try to understand from these two paragraphs - should the device send a message about its successful reception to the ACK? From the literal text of the draft standard it turns out that it should. ACK to ACK. But, at least, it’s not said anywhere that the base station should answer ACK for ACK on ACK - or rather, the draft standard doesn’t say anywhere how the BS should understand whether or not it should acknowledge packet reception. This is not a property of the packet (although with 6 bits empty in its header, one could be allocated to the delivery confirmation flag).
[...] A message with zero payload can be used as confirmation that the base station has received data from a subscriber unit (acknowledgment).
And what does it mean "should contain an indication of the message that is confirmed"? How can one point to a specific message in a system in which an individual labeling of messages by a protocol is not provided for?
The OpenUNB standard requires a minimum amount of energy to send one bit of information. According to the results of preliminary tests, now it is one of the most energy-saving protocols.AS: A controversial, unconfirmed statement. The protocol contains at least a few elements that indicate its low energy efficiency:
- An excessively long checksum of 32 bits, although all manufacturers of such systems cost CRC 16 bits.
- The restriction on the length of information is only strictly 64 or 128 bits. If you need to send a short message of several bits (for example, from any binary sensor - 1 bit), then you will have to transmit an extra few bytes each time, what’s the efficiency.
- The declared need to duplicate the transmission of one message up to four times, which immediately changes the energy parameters by 4 times.
- A long 8 second window for receiving downstream packets.
I would very much like to see the test reports, there are certain doubts that they even exist.
OA: yes, it’s hard to understand where Skoltech was in such a hurry that he couldn’t even share test reports and other supporting information to assess what real OpenUNB performance can be counted on.
OpenUNB is a universal open standard, absolutely ready for practical use.AS: The text of the standard is crude, it contains fragmentary, incomplete and inaccurate descriptions of individual punctured elements; its use in practice is impossible. UNB- – .
OA: , -, -. , , 70-80 , , . – LPWAN .
All Articles