哈Ha！
不久前，Skoltech物联网工作组发布了名为“ OpenUNB”的国家窄带物联网标准草案，其全文可在
此处找到。 一方面，这一现象无疑是积极的-如果在宽带标准领域中，事实上想要供所有人使用的LoRaWAN开放使用，那么迄今为止，窄带标准一直是非常专有的（Sigfox，Strizh的XNB，Vaviot的NB-Fi）。后者也以国家标准草案的形式发布，没有透露对于第三方实施至关重要的部分。
同时，窄带和宽带系统各有优缺点，因此说“有LoRaWAN时为什么还需要其他东西”并不是完全正确的。 也就是说，需要一个用于UNB通信的开放标准。
但是，必要性只是两个条件之一。 第二是足够。 好的，Skoltech发表的内容是必要的，但足以用于实际用途吗？
我们将以类似于采访的格式来回答此问题-在GoodUN技术总监Alexander Sheptovetsky（AS）和Unwired Devices技术总监Oleg Artamonov（OA）给出的OpenUNB标准草案的删节报价及其评论中，以此类推。
所以走吧 保留了作者的风格，拼写和标点符号。
协议功能是使用超窄带调制（发射频谱的宽度小于1 kHz），这可以实现高信噪比（在未许可范围内限制了辐射功率），这意味着可以长距离或通过多个障碍物（混凝土墙，分隔墙）传输数据金属柜）。
OA：标准制定者
的第一个错误是，他们最初假设LPWAN系统中信号的SNR（信噪比）高，并且由于这种错误，在协议本身的设计和实现中，这种错误将继续增长，例如选择例如，序言。
实际上，提供其“范围”的LPWAN无线协议的主要功能是能够接收
低 SNR信号的能力，该信号的信噪比最高为负。 信号电平低于噪声电平的情况。
此外，该标准的作者对信号传输理论的基本原理还不太了解，尤其是在存在噪声的情况下，香农对信道中数据传输速率的限制也很有限。 该速度由SNR的值
和信号频谱
的宽度确定-实际上，一个被另一个补偿。 因此，为了在LPWAN系统中长距离传输数据，窄带和宽带（例如，在LoRaWAN频段-125 kHz）信号都被成功使用，每种方法都有其优点和缺点。
由于以下事实，这是可能的，因为订户设备在不建立与基站的连接的情况下广播数据（简单模式），例如，这是在移动蜂窝网络中完成的。
OA：除了在样式和标点符号方面的错误外，我注意到对术语的粗心使用也是无法接受的。 单工模式（即仅在一个方向上通过通信通道传输消息）与建立连接的需求没有直接关系-当然，这些不是同义词。 相同的LoRaWAN以半双工模式提供双向通信，但也不需要事先与BS连接。
作者可能会想到OpenUNB中没有会话操作模式-但这是所有LPWAN协议的特征。
为了简化并降低收发器的设计成本，在时间上分离了发送和接收，即，以单工模式（从用户单元到基站的传输）或半双工模式（从用户单元到基站及其后的传输）从基站交换数据。在用户设备上从基站进行接收）。
OA：实际上在半页之后，事实证明OpenUNB中还存在半双工模式！ 总的来说，我想指出的是，标准草案中存在许多这样的内部矛盾。
数据包中的字节顺序从最早到最小（大端）
OA： big-endian是一种计算机体系结构，在多字节数字中具有特定的字节顺序。 在数据包中，字节顺序始终相同-从第一个到最后一个。 我再说一遍：对于国家标准草案，如此粗心地使用既定术语是不可接受的。
包的长度可以不同，具体取决于有效负载的大小。 有效载荷长度选项：0，64或128位。 负载为零的消息可以用作设备正常运行的常规信号（心跳）。 64位和128位的数据包长度由加密算法的密码块大小确定。
AS：开发人员已将有效载荷长度限制为0、64或128位，并通过加密的便利性证明了这一点。 这是一个完全人为的限制。 有时您需要发送非常短的消息，但必须使用64位。 之后我们能谈谈什么能源效率！ 例如，可以在LoRaWAN协议中阅读如何使用长密钥加密短消息。
OA：是的，在同一个LoRaWAN中，通常使用AES-CTR加密方案，该方案允许对任意长度的包裹进行加密，包括 密钥长度少。
为了在非许可范围内实现高传输范围，需要高信噪比。 这是由于超小的传输带宽（大约100 Hz）而实现的。
AS：在标准草案中，甚至没有关于带宽的单一意见-它是“小于1 kHz”，然后是“约100 Hz”。 在标准中不可能只发表一个声明吗？
OA：关于高SNR的需求。 不，不！ LPWAN也是LPWAN，即使SNR为负也可以使用。
一些收发器可以在传输的一开始就非常强烈地更改其属性。 这可能影响分组中第一比特的调制信号的频率和长度。 为了补偿这个因素，建议在开始传输前同步码之前以与1-2位传输持续时间相等的持续时间的数据包频率发射信号（图2）。 [...]在传输结束时，在校验和之后，您还应该进一步研究1位，并逐渐减小信号幅度，这将增加正确接收最后一位的可能性
AS：信息和图纸均来自SigFox的技术说明，并与SigFox的说明的某些功能相关。 接收器不是在相位变化时而是在前后固定位。 您不应该无所顾忌地复制他人的功能和描述错误。
上行链路数据包的建议前导值：101010101010101010 2 。 由开发人员决定，可以更改整个网络的前导值。 例如，这可以用于在一个地区中创建多个网络，一个或另一个基站中哪个基站的接收将根据各种前导码进行划分。
AS：简要说明。 UNB信号接收器在空气噪声水平下运行。 通常，使用直接转换接收器，然后进行FFT。 如果信号具有相位调制，则进一步查看每个频道的相位变化。 如果在任何信道中找到与前同步码相对应的数字序列，则决定是否存在有用信号。 同时，在FFT之后的每个相关器上，零和一的随机序列不断地从以太噪声中消失-这意味着总有可能从以太噪声中获取前导。 现在，让我们看看16位错误的前同步码在接收器上出现的频率，例如，接收者使用了类似的“草案国家标准”的作者Vaviot声明的用法。 它们声明的接收频段为200 kHz，FFT步长为7 Hz，这意味着需要超过28 000个相关器。 对于10 ms的位长（传输速度100 bps）中的精确命中，相关器每2.5 ms启动一次。 总计，每秒必须检查1100万个关联，以检查是否存在前导，并且每秒
平均会从以太噪声中
倒出178个错误的前导 。 每个错误的前同步码都需要进行处理-同时不要丢失对真实前同步码的接收。 对于已经处理到极限的BS处理器来说，这是不合理的冗余任务。
对于我所知道的所有UNB系统制造商来说，
前言都是32位长 ，并不是偶然地选择它，而是出于计算和实验的结果。
另外，前同步码的目的不仅是从噪声流中提取有用的信号，而且还提供同步。
在UNB系统中，具有明显自相关函数的特殊M比特位用作前导 。 例如，如果在作者建议的顺序（1010101010101010
2 ）之前，偶然从噪声中又接收到一对10
2 ，则接收器将更早地确定有用信息的开始两位，并且将无法接收该数据包。
一些系统使用常规的前同步码，但是在它们之后，总会出现“同步”一词，该协议中未提供。 由于相同的原因，如该协议所提供的那样，将设备标识符用作下行链路的前导是不正确的。
OA：标准草案
的作者清楚地总结了“高信噪比”的思想，这种思想已经根深蒂固，他们已经强调了好几次。 是的，在实验室内进行实验时，SNR很高，并且接收器可以在“我看到信号-我接收到信号”模式下工作（并且在Aliexpress上出售的许多廉价产品都可以在此模式下成功工作，提供了几百米的通信范围）。
在任何实际条件下，甚至在声明的50 km距离下，甚至更是如此，建议的序言将简单地在噪声中死亡：其中的一个不良位或其前面的随机噪声将足以阻止接收器识别数据包。
AS：如果没有抗噪编码元素，则在日常空气噪声的情况下，尤其是在无执照的频率范围内，不可能获得高质量的通信，这是“流派的经典”。 通道中的任何短脉冲干扰，在整个序列中仅剔除一位，接收器将不接受任何东西。
发件人ID是设备生产期间分配给其的唯一32位序列。 有关标识符的其他信息，请参见附录E：编写标识符的格式，用户单位，控制信息的计算以及标识符的保留范围。
OA：该标准声称是资源会计系统中统一数据传输系统的基础，但并未描述制造商自行选择标识符的规则-甚至没有表明此类规则将永远存在。 它会导致什么？ 对来自不同制造商但具有相同标识符的一堆设备来说是正确的，因为每一秒钟的制造商都会简单地从头开始对设备进行编号。
服务信息由8位组成，最左边的6位保留供将来使用。 消息中的数据包编号保留2位。
OA：非常奇怪且很少的开销信息。 可以指定端到端的数据包编号，加密类型，数据包大小等。 目前尚不清楚为什么我们甚至在消息中需要一个“本地”数据包编号-假设我们收到的数据包编号为0，然后是编号1。我们应该丢弃第二个吗？ 如果这是下一条消息中已经发送的1号数据包，那么我们从中丢失了0号数字吗？ 而且，如果我们不能在此基础上丢弃数据包，该如何解决该设备可以连续发送4个相同数据包的问题-我们接受并考虑所有这些数据包，在输出端接收多个重复的有效载荷吗？
AS：通常，在标头之后的前导码指示数据包的长度；在此协议中情况并非如此。 接收器如何理解要拨多少位？ 当然，您可以使用CRC检查所有可能的长度，但是没有人这样做，从接收器的硬件角度来看，这太昂贵了。
数据包校验和基于附录B：数据包校验和的计算中的算法计算。
OA：说实话，我只是张着嘴站着。 不，
通常没有提供针对协议中典型攻击的保护措施！ 使用已宣布的协议安全性，使用强密码等技术，任何人都可以捕获别人的数据包，更改其中的字段，替换另一个数据包中的有效负载，重新计算校验和-并进行广播，基站将接受它并且无法以任何方式将假冒产品与“本地”产品包区分开。
AS：开发人员通过加密保护有用的信息，但这显然还不够！ 开发人员声称他们熟悉LoRaWAN和NB-FI协议，如果确实如此，他们将理解为什么需要防止重复的保护以及为什么在包装中需要附加的仿制插入物。 例如，一个零位有效载荷的包裹绝对是不安全的，从空中写并重复它是没有问题的，系统会将其理解为自己的包裹。 对于攻击者而言，将任何垃圾发送到系统或代表具有非零长度的软件包中的任何传感器重复也是不难的。
先验标准已经成为LoRaWAN中的信息安全协议，该协议证明了为网络和用户使用两个安全密钥的合理性以及通过空中生成会话密钥的能力，协议开发人员显然甚至没有考虑过。
加密密钥必须存储在用户设备和网络服务器上的安全存储器中。 要加密上行链路和下行链路数据包，必须使用不同的加密密钥。 对于每个设备，加密密钥集必须唯一。
OA：一方面，OpenUNB开发人员相信自己“以8位的倍数选择字段大小，以便在微处理器上进行更有效的处理”（作者的拼写）；另一方面，他们似乎根本不了解这种有效的对称优化技术加密，因为它可以保留在终端设备上，而无需执行两个过程-加密和解密-仅保留一个过程，这极大地减少了微控制器上固件的大小。 至少在标准草案中未提及。
AS：但是他们确实成功地以8位的倍数获取了字段的大小！
仅响应于来自上游信道的消息，才有可能从下游信道发送消息。 这有几个原因。 首先，该协议专门针对没有外部电源的用户设备而设计，以延长电池寿命，这意味着功耗起着关键作用。 由于发射器在接收模式下的功耗很高，因此您应该仅在短时间内切换到该模式
OA：我不太理解为什么有意识地限制了标准的范围，而且比同一个标准的引言中已经说明的那样。 普通家用电表是否具有外部电源？ 有。 是什么使您无法始终打开“发射器处于接收模式”？ 没事
其次，不可能在用户设备上选择特定的时隙，因为为了降低用户设备的成本，它们通常配备有不稳定的晶体振荡器并且没有实时时钟。
OA：当然不是。 首先，向前看两段，作者已经拥有一个巨大的接收窗口-8秒（在同一个LoRaWAN中，接收窗口的大小为1-2秒）。 其次，计算设备与基站同步时钟的频率（并提供用于这种同步的方法）就足够了，这样石英不稳定的问题就不成问题了。 在LoraWAN中，这是在B类设备中完成的。
第三，用户设备上晶体振荡器的低稳定性要求使用附录D：下行链路传输频率的调整中描述的频率调整算法。 但是，由于来自上游信道的最后一条消息用于计算频率漂移，并且晶体振荡器的频率会随时间变化（例如，当温度变化时），因此，最后一条上游消息与下游消息之间的时间应足够短，以改变订户的频率偏差在此期间的设备可以忽略不计。
AS：从描述的细节来看，OpenUNB协议的开发人员认为他们对频率下信道同步问题的解决方案是他们最重要的成就。计算方法本身是可以接受的，但是存在几个问题：- 从传感器发射的信号的频谱包含发生器的相位噪声，该信号与以太噪声混合，并且接收频带模糊。
- 多普勒频移和多径传播尚未消除。
- , 7 50 , 7 .
- , .
- .
- , , .
我们进行了适当的研究，但在实际条件下无法获得高于±150 Hz的868 MHz范围内的命中精度。要接收100 Hz BPSK信号，至少需要30 Hz的精度。SigFox在返回通道中以600 Hz的频率调制运行。我认为，返回通道的最大可能组织是2GFSK，偏差为300 Hz，下游信号的功率增加到100 mW。此外，由于在多径信号传播期间相位噪声的增加，带有信号的相移键控的UNB系统无论如何在移动物体上也无法很好地工作。所提出的在存在多普勒偏置的情况下确定下行信号的频率的方法将在确定上行链路信道的载波频率时产生附加误差，这将在确定下行频率时导致附加误差。协议的作者也许还有其他数据，但不是“确定”，而是在实际条件下，我想查看测试报告。OA：我补充说，即使100 Hz频段的30 Hz偏差也不是理想的接收，但是大约10％的误码率（在LPWAN系统中，这通常是在国外采用的，在这种情况下，接收质量仍然可以接受）。鉴于OpenUNB中缺少噪声编码，因此几百位数量级的消息捕获至少一个误码率（BER）为10％的错误的可能性非常高-也就是说，特别是在OpenUNB中，我将评估允许的频率偏差，以其他方式确定有时会以5％的最高剂量服用。在三十次比它有可能获得在现实中。简而言之，严重怀疑标准草案中描述的组织反向通信信道的方法在原则上通常是可操作的。时间间隔T dl的持续时间被选择为一个分组下行链路的传输持续时间的倍数。时间窗口大小的这种增加是必要的，因为每个站点通常有许多设备，这可能导致需要同时向多个设备发送下行链路数据包。
OA：每一个魔术都有代价，就像一个系列的英雄所说。在无线电网络规划的情况下，必须计算出这个价格-标准草案的作者没有找到时间进行这样的计算（但也许那不值得急于发布该项目？），或者根本没有猜测要这样做。在这种情况下，正如以上作者正确指出的那样，接收器的操作是相当耗能的过程。在一种情况下，我们获得8秒的空闲操作，而在另一种情况下（当接收时隙减少到1-2秒时）-基站不响应的可能性（它没有设置时隙的时间），并且需要重新启动接收器的消息传递。在两种情况下，都必须至少估计大约以太的负载和能量消耗，这取决于网络中无线电交换的强度，并且还必须提供一种明确描述的方式来确认接收器已从基站接收消息。最后，从标准文本中尚不清楚整个下游前提是否应归入T dl-或者接收者已经抓住了序言及其地址，将拉长接收窗口，直到有足够的时间接收整个包裹为止。通常，在LPWAN系统中，它们遵循第二条路径，这又可以减少所需的接收窗口持续时间。在订户设备成功接收到来自下游信道的消息的情况下，它作为响应在上行链路上发送关于成功接收的消息。其用户数据应包含已确认消息的指示。
净荷为零的消息可以用作确认基站已从用户单元接收到数据（确认）。
OA：再次您好，安全性！为了确认发送，建议从基站发送一个不受密码保护的数据包，任何人都可以在半分钟内伪造该数据包。更不用说您试图从这两段中了解的内容-设备是否应该向ACK发送有关其成功接收的消息？从标准草案的文字文本可以看出，应该这样做。 ACK到ACK。但是，至少在任何地方都没有说基站应该在ACK上对ACK进行应答ACK-确切地说，标准草案在任何地方都没有说BS应该如何理解是否确认分组。这不是数据包的属性（尽管报头中有6位为空，但可以将其分配给传递确认标志）。而且，必须包含“已确认消息的指示”的含义是什么？在没有提供通过协议对消息进行单独标记的系统中，如何指向特定消息？OpenUNB标准需要最少的能量来发送一位信息。根据初步测试的结果，现在它是最节能的协议之一。
AS：有争议的未经证实的陈述。该协议至少包含一些表明其能源效率低的元素：- 尽管此类系统的所有制造商都花费16位CRC校验码，但校验和过长（32位）。
- 信息长度的限制只有严格的64位或128位。如果您需要发送几位的短消息（例如，从任何二进制传感器发送-1位），那么每次将不得不发送额外的几个字节，这有什么效率。
- 声明需要将一条消息的传输重复最多四次，这会立即将能量参数更改四次。
- 8秒长的窗口，用于接收下游数据包。
我非常希望看到测试报告，有些怀疑甚至存在。OA：是的，很难理解Skoltech急于去哪儿，他甚至无法共享测试报告和其他附带信息来评估可以指望OpenUNB真正的性能。OpenUNB是一个通用的开放标准，绝对可以实际使用。
AS：该标准的文本是粗略的，其中包含对单个被穿孔元素的零碎，不完整和不准确的描述；在实践中不可能使用它。关于UNB系统的关键要素-基站接收器，没有任何细节。OA：总的来说，我感觉在一到两周内就可以完成出色的三年级学生课程。干得好，我参加了所有的讲座，我什至理解了70-80％，真实经验为零，但至少在通过考试时与老师进行了富有成果的讨论。在实际应用之前，不仅要像登月前那样，对于LPWAN中的实际应用，整个项目都必须扔掉并重写。