作者：Preston Tesvich
假设你在一个物联网项目的计划阶段。你有很多的抉择要做，也许你不知道从哪开始：
在这篇文章中，我们关注于如何思考这个问题的标准、协议和无线通信的框架。
当然，这个框架取决于你的部署将是对内的（如工厂内）还是对外的（如消费产品）。在这段对话中，我们将着重讨论面向更广泛的客户推出的产品，为此，我们有很多需要考虑的。
让我们看看物联网的现状— 底线，没有一个标准如此完美或重要以至于不使用它就会犯错。那么，我们要做的是尽可能的寻找解决问题的方法（该方法要有可接受的实现成本和规模），而不是过于担心未来流行的标准。
因此，首先归根结底是技术的限制：
- 覆盖范围和带宽需求?
- 网络中要支持多少个节点？
- 无线通信的成本？
无线通信的选择有很大的影响—它不仅是你物料清单上一行巨额的项目，它也将决定设备所需的资源。例如，你最终选择WiFi无线通信，那就需要不菲的CPU和内存资源，而如果选择蓝牙或者其他网格网络，就少了很多。 还要考虑到基础设施的扩展成本。如果通过WiFi：正在部署的位置是否已经有WiFi基础设施? 如果我们从头开始，覆盖大面积的计划是什么？ 这可能需要巨大的代价，尤其是如果你使用工业级的接入点，所以考虑到这些影响是非常重要的。
聚焦具体标准
我们认为我们发现的最大误区: “难道没有一个标准来规整他们吗？“ 那是不可能的，这不仅是因为作为一个行业我们从不会在所有的事情上达成一致，也因为在许多情况下，不同的标准解决不同的问题。所以，理解了这个，我们现在可以看看每个协议要解决的东西以及它们在OSI模型或 "栈"上所处的位置。
MQTT
有些人认为这是一个从设备到服务器通信的完整协议，但并不全是。 MQTT作为一种数据格式用于通信，并且该负载可以通过任意方式传输，可以是Wi-Fi,、网格网络或其它套接字协议。它定义一种方法来处理事物的属性。围绕着属性的读写很好的解决了物联网的问题。在某些方面，它确实节省了开发时间，但这取决于你在多大程度上实现它，它可能会花费你更多的开发时间。一旦你在过它的每个部分，你要认真的做好记录，有时当逼近一个时间和成本因素时，实现自己的负载方案可能是一个更好的选择。
它足够丰富到你绝对要使用它吗? 不，它还没有达到那个层度，也不可能达到那个层度。目前它是一个设备直连到云的实用标准， 我们不对两端进行控制，因为它提供了一些我们达成一致的通用语言的处理措施；但要记住的是，大多数时候，它实际上需要附加的文档说明 — 要读/写什么属性以及确切的实现机制 — 这样，到最后你就不会在使用MQTT上花费太多的工夫。
Zigbee和Z-wave
同样从网络层开始，Zigbee和Z-wave在网状网络中占有重要的位置。它们试图解决两个问题：提供一个合理的规范，将数据包从网状网络上的一个位置移到另一个位置，并指示应该如何构造这些包；因此，他们在栈中的位置更高。这也是限制他们的地方。 例如，Zigbee使用一个称为profiles的系统，它是一些功能的集合，比如 smart energy profile 或home automation profile。当一个协议要如此具体的指明说‘这是灯泡所做的事情’时，就很难去实现那些未包含在profile中的设备。虽然有自定义数据，但这一点上，你并不真正使用交叉兼容规范 — 只要你使用了未在profile中定义的设备，你就基本上违反了标准。
关于这两个的另一个考量是他们都是路由的网状网络。我们使用一个节点与另一个节点进行通信时需要借助中间节点。也就是说，我们可以发送一条消息从A到B到C到D，但实际上，我们是从A发送一条消息到D。作为路由网格，每个节点都知道消息发送所需的路径，但这也带来了相应的内存开销。Z-wave和Zigbee网络理论上支持65,535个节点(地址空间是一个16位的整数)。 实际限制将近数百个节点，因为这些设备通常是低功率、低内存设备。路由也有一定的时间开销，所以大型网状网络可能会对你的用例产生不可接受的延迟。另一个考虑因素，尤其是如果你要推出一个云控制的消费产品，这些网状网络不能直接连接到互联网—他们需要一个中间桥梁(也就是 网关, hub, edge server) 来与云通信。
最后需要注意的是，Z-wave只有一个供应商—无线通信由Zensys制造并销售，所以你必须从他们那进行购买。Zigbee有一个认证过程，并且有Atmel、TI等多个无线电供应商。
蓝牙
蓝牙的芯片出货量确实无可匹敌。 2014年超过10,000种不同型号的蓝牙被推出。.在采用方面，除了WiFi，没有能和与之对比的。蓝牙最初是专为‘personal area networks,’设计的，原始标准支持7个并发设备。现在我们有低功耗蓝牙 (BLE)，理论上可以有无限多个并发设备。BLE围绕着物联网的挑战做了大量优化。他们重点着眼于通信所需的功耗，考虑了"低功耗"的方方面面，而不只是在无线电方面-- 他们着眼于数据格式，数据包大小，无线传输时间，内存消耗，内存功耗，以及占用的CPU时间，同时考虑整体的BOM成本。例如，他们指出每次无线传输的时间只能到1.5ms。这个一个最佳的时间 — 如果你传输更长的时间，元件升温，从而需要更多的功耗。他们还指出纽扣电池的功率传输更适合用短脉冲而不是连续脉冲。此外，他们对抗WiFi干扰也做了优化，因为这些协议共享相同的无线频段(2.4GHz)。
然后企业社会责任来了，实现了蓝牙网格标准。 利用BLE携带的所有优点，获得了网状网络的所有好处。 蓝牙网格是洪泛网格，意味着替代了到节点的特定路由，消息在所有节点间不加区分地发送。 这比传播的网格更好，因为没有内存限制。 对于物联网中的许多问题来说，这是一个很好的解决方案，而且在规模上可能是实现最低的成本。
Thread
一个即将到来的标准，建立在与Zigbee广播相同电源的硅片之上。它解决了网状节点无法通过添加IPv6支持直接与云通信的问题，这意味着网络上的节点可以完成合格的互联网请求。这个标准背后有很多的重要性。 Google似乎认为制作自己的协议（称为“Weave”）是非常有趣的。然后是Nest Weave，这是Google Weave的其他版本。就像现在这样，标准需要很长时间才能真正掌握 - 你可以立即看到Thread的故事有点混乱，这不利于它的采用。但它也解决了设备数量少的问题。以传感器为例。做这些低功耗，轻便，低成本，低内存，低处理，相当笨重的设备需要直接互联网请求？使用Thread，每个节点现在都对这个世界知道的更多 - 例如服务器的位置，也许他们不应该关心这些事情，因为不仅要增加设备的要求，而且现在必须在现场更新他们的概率和频率上升了。在实际传感器和其他端点方面，哲学上您希望最小化这些责任，除非需要离线的耐久性，本地处理和决策（特别是雾计算）的特殊情况。
当Thread去年宣布其产品认证时，仅提交了30个产品。关于Thread的另一个要注意的事情是，网格IPv6问题已经解决了 - 蓝牙4.2中实际上有一个规范，它将IPv6路由添加到蓝牙，但很少有人在使用它。尽管北欧半导体厂商认为这将是一个重大的事情，并且首先实施了，但它并没有在行业中出现 ——在2014年第四季度，没有人在谈论它。
Thread还做了一件事是它不再定义设备之间如何对话，以及设备如何格式化数据，这样做会使其更具前瞻性。这是Weave技术进来的地方，因为它假设数据应该结构化。所以基本上只有一种方式看待它，就是Weave+Thread = Zigbee / Z波的直接竞争对手。我们还没有看到谷歌以外的任何人主动采取Weave，除了Nest，他们做了一个很好的营销工作，看起来像是在他们被Weave吸引。
AllJoyn
其他协议呆在堆栈中更高的位置，并且在网络层保持不可知。其中最着名的可能是高通的Alljoyn的努力。他们有Allseen联盟，虽然他们的品牌有点暗淡 - Allplay，AllShare等。我们看到了一些牵引力，但不是一吨 - 它最大的担忧是它是一个真正开放的协议，宽松的定义，你真的不会建立一个完全可以互操作的东西。这对产品团队来说是一个很大的风险。如果世界上没有足够的设备使用这种语言，那我为什么要使用呢？也就是说，LIFX实现了这一点，它对他们来说非常有用，特别是Windows实现它以后。现在它是Windows 10的一部分 - 有一个专门为AllJoyn的东西，它似乎做得很好。 AllJoyn有证据表明，您可以将设备带到不知道任何事物的表格，并获得某种持久的互操作性。但是，一目了然，看起来很复杂 - 授权处理方式和设备需要相互协商的方式。真的没有失败的采纳。
IEEE的Wi-Fi
IEEE的802.11系列已经称雄于世了。从B到G再到A，如今是AC。802.11真的很擅长更简单的设置和更高的带宽。它并不关注电源消耗，它更关注性能，因为它就是要成为有线的替代品。大约2年前，它们发布了802.11 AH，命名为 HaLow，试图解决电源问题、频率问题和经典的WiFi配对问题。大多数Wi-Fi设备都不是无头的（headless：没有显示和其它的输入），它们拥有丰富的用户界面-这样我们就可以登录并配置WiFi的连接。配对无头设备是一个非常繁琐的过程。对于HaLow，它们解决了两个问题-如何让事情变得更简单，如何降低运行在无线信道上的设备的预期（尤其是电源）。尚不知它能够带来哪种吸引力，但IEEE对于标准的采用有着优秀的跟踪记录。
LoRa 和 SIGFOX
更像是： LoRa vs. SIGFOX。我们正在研究的是如何通过这些协议将很远距离的物体连接起来，例如在智慧城市的应用中。LoRaWAN是一个开放协议，它遵循的是自下而上的策略。而SIGFOX是自上而下构建基础架构的，并且将API交付给其客户。这样说来，SIGFOX更像是一个服务。随着有更多公共类型的应用开始使用IoT，我们能够看到这两个协议之间的舞蹈还是蛮有趣的。
以上就是需要提及的一些标准协议。还有很多很多，但是对于今天的IoT来说，我们并没有看到它们怎么令人激动人心。
原文：Hitchhiker's Guide to IoT Standards and Protocols / 物联网标准和协议漫游指南
文章来源：可译网