Проект национального IoT-стандарта OpenUNB: критический разбор

[Lerk]

Интересно написано, спасибо.
А можно для тех, кто этим не занимается, пояснить, что за GoodWAN и где он применяется(сайт то красивый, спору нет)? Про лору тут же на хабре уже куча статей была.
PS. И если GoodWAN так хорош, то почему он не сидит в Сколково и не участвует в написании нац. стандарта?

[amartology]

И если GoodWAN так хорош, то почему он не сидит в Сколково и не участвует в написании нац. стандарта?

Тебе ли не знать, что на Варшавском шоссе, 125Ж сидеть гораздо приятнее, чем в Сколково? )

[Lerk]

Мне интересен взгляд с другой стороны двери ;)

[0serg]

В реальности основная возможности протоколов беспроводной связи LPWAN, обеспечивающая их «дальнобойность» – это способность принимать сигнал с низким SNR, вплоть до отрицательного, т.е. случая, когда уровень сигнала ниже уровня шума.

Там есть много разных SNR. Можно смотреть SNR в канале а можно — на выходе согласованного фильтра приемника (где и стоит собственно детектор принимающий решение «нолик или единичка»). Системы работающие «под шумом» — это в основном ШПС где сигнал размазан по широкой полосе. В канале у них SNR низкий, но на выходе детектора уже нормальный. Только вот энергетического выигрыша над узкополосным каналом это не дает, т.к. там из-за размазывания сигнала по большему спектру при равной мощности передатчика его спектральная плотность (а в SNR фигурирует именно она) получается меньше. ШПС-система способна работать при более низком уровне SNR в канале, да, но у нее и SNR при равной мощности передатчика будет ниже и в конечном результате одно полностью компенсирует другое. Использование узкополосного передатчика «с большим SNR» системе не поможет, это верно, но и «способность работать с отрицательным SNR» — это тоже ни о чем. Чисто технически, в пределе Шеннона, фигурирует величина "энергии бита деленной на спектральную плотность шума". Это соотношение однозначно определяет SNR на выходе согласованного фильтра и вероятность ошибки для 1 бита. А уж как на широкую спектральную полосу эта энергия одного бита размазывается или на узкую — неважно.

[Gryphon88]

Извините, а в рабочую группу Вы написали?

[olartamonov]

Нет, и не буду. Я не работаю с форматом «на деревню дедушке», в котором от меня требуется проделать работу, бросить результат в почтовый ящик и забыть о нём.

[AC130]

любой желающий может поймать чужой пакет, поменять в нём поля, подставить полезную нагрузку от другого пакета, пересчитать контрольную сумму – и передать в эфир, а базовая станция это примет и не никак не сможет отличить подделку от «родного» пакета.

Кхм. А базовой станции и не надо ничего отличать :-). Пункт 6.4:

Стоит отметить, что на базовая станция не должна производить процедуры расшифрования полезной нагрузки, она должна передавать прозрачным образом зашифрованные данные, полученные от пользовательских устройств, на сервера для дальнейшей обработки.

[hobogene]

А базовой станции и не надо ничего отличать

И что радикально меняется-то? Будет та же проблема у сервера(ов). И придется на уровне приложения изобретать велосипед, который должен бы быть в протоколе пониже.

[EGregor_IV]

Эээ… Взяли даташит на nrf24L01, прочитали, добавили умные и не очень слова, поменяли частоты, и вот вам, стандарт.

[hobogene]

(в том же LoRaWAN окна приёма имеют размер 1-2 секунды)

Вообще, гораздо меньше. Если мы не говорим про class C с «бесконечным» вторым окном.

[hobogene]

Текст стандарта сырой, содержит отрывочные, неполные и неточные описания отдельных выколотых элементов, его применение на практике невозможно.

«Нацстандарта» LoRaWAN это тоже касается, что уж совсем удивительно. Странный выборочный перевод, местами через Google translate, плюс за уши притянутые отечественные криптоалгоритмы, которыми все равно шифруется app. payload, которому не место в спеке.

Хотя, может, поправили слегка уже, надо посмотреть…