Let’s say you’re in the planning phase of an IoT project. You have a lot of decisions to make, and maybe you’re not sure where to start. In this article, we focus on a framework for how you can think about this problem of standards, protocols, and radios.


The framework, of course, depends on if your deployment is going to be internal, such as in a factory, or external, such as a consumer product. In this conversation, we’ll focus on products that are launching externally to a wider audience of customers, and for that, we have a lot to consider.


Let’s look at the state of the IoT right now — bottom line, there’s not a standard that’s so prolific or significant that you’re making a mistake by not using it. What we want to do, then, is pick the thing that solves the problem that we have as closely as possible and has acceptable costs to implement and scale, and not worry too much about fortune telling the future popularity of that standard.


So, it first comes down to technical constraints:

  • How many nodes are going to be supported in the network?
  • What are the range and bandwidth requirements?
  • What is the cost for the radio?


  • 带宽范围要求是什么?
  • 网络中将支持多少个节点?
  • 每个节点网络的覆盖范围多大?

That radio choice has big impacts — not only is it a hefty line item on your BOM on its own, it’s also going to determine the resources that the device needs as well. For example, if you have a Wi-Fi radio in the end, there are considerable CPU and memory expectations, whereas if we have BLE or some mesh network, it’ll need a lot less. There are infrastructure scaling costs to consider as well. If we go Wi-Fi: Is there Wi-Fi infrastructure already in place where this is being deployed? How reliable is it? If we’re starting from scratch, what’s the plan for covering a large area? That can become very costly, especially if you’re using industrial-grade access points, so it’s important to consider these effects that are downstream of your decision.

无线网络的选择是一个很重要的环节,它还直接影响到了你对通信设备和资源的选择。例如,如果你有一个无线 Wi-Fi,你就需要相当大的 CUP 和内存,而如果我们选择 BLE 或者一些其他的双通道网络则需要很少的资源。另外我们还要考虑通信基础架构的扩展成本,如果我们使用 Wi-Fi 就要考虑在部署项目的地方是否有 Wi-Fi 的覆盖,这些 Wi-Fi 是否可靠,如果没有如何去大面积的覆盖,这些可能会使成本变的很高,尤其当你选择工业级的接入点的时候成本更高,所以我们要综合考虑这些因素的影响。

物联网标准协议 物联网标准协议


In our opinion, the biggest misconception we find: “Isn’t there going to be one standard to rule them all?” There’s no future of that, and it’s not just because we’re never going to all agree on stuff as an industry, it’s because in many cases different standards aren’t solving the same problems differently, they are solving different problems. So by understanding that, we can now look at what each protocol attempts to solve and where they live on the OSI model, or “the stack.”

在我们看来,我们发现的最大误解是:“难道不会有一个通信标准来统治它们吗?”,如果有这样的标准,那么物联网的发展是没有未来的,因为在物联网的领域永远不会存在一个相同的问题,我们解决的都是特定领域的特殊问题,所以接下来我们来看看不同的通信协议的特点,它们擅长解决那类通信问题,以及它们在 OSI 模型中的位置。


Some would suggest that it is a full protocol to do communication from a device to a server, but it’s not quite that. MQTT is used as a data format to communicate to something, and that payload can be sent over any transport, be it Wi-Fi, mesh, or some socket protocol. What it tries to solve is to define a way to manipulate attributes of some thing. It centers around reading and writing properties, which lends itself very well to an IoT problem. It certainly saves development time in some regards, but depending on how strictly you’re trying to implement it, it may cost you more development time. As soon as you one-off any part of it, you have to document it really well, and at some point, you approach a time and cost factor where implementing your own payload scheme may be a better option.

有些人认为从设备到服务器进行通信是一个完整的通信协议,但事实并非如此。MQTT 协议只被用来定义通信中的一种数据格式,和具体的传输方式无关,可以通过任何方式传输,无论是 Wi-Fi 还是一些双工通信网络或者是 socket. MQTT 视图解决的是如何i当以一种操纵某些事物属性的方法,它以读写属性位核心,这样就很好的解决了物联网中的数据格式问题。从某些方面来说,MQTT 节省了很大的开发时间,可能在刚开始使用的时候你需要花费更多的时间去研究和更严谨的使用它,等你完成一次协议对接后,把这种方案保存下来,后面就可以极大的节约你的时间。

Is it prolific enough to where you should absolutely use it?

MQTT 是否已经好到你必须使用它的程度了?

No, it hasn’t reached that level, and it won’t likely reach that level. What it is right now is a convenient standard for device-direct-to-cloud where we don’t control both ends because it gives some measure of a common language that we can agree on; however, the thing to keep in mind is that most of the time it does, in fact, need additional documentation — what properties are being read/written and what the exact implementation looks like — ultimately, you’re not getting out of a lot of work using MQTT.

不,它还没有达到那个水平,也不可能达到那个水平。现在而言 MQTT 只是一个方便设备和云端通信的一种标准,它提供了一种我们设备和云端的一致的通用语言,然而,MQTT 还需要我们去定义一些额外的文档,定义具体的读和写的属性,所以使用 MQTT 并没有让你从大量的工作中解脱。

Zigbee 和 Z-wave

Also starting at the network layer, Zigbee and Z-wave are the big incumbents everyone likes for mesh networking. They attempt to solve two problems: provide a reasonable specification to move packets from one place to another on a mesh network, and actually suggest how those packets should be structured; so, they both reach up higher in the stack. And that’s the part that hinders their futures. For example, Zigbee uses a system called profiles, which are collections of capabilities, such as the smart energy profile or the home automation profile. When a protocol gets so specific as to say ‘this is what a light bulb does,’ it’s pretty difficult to implement devices that aren’t included in the profile. While there are provisions for custom data, you’re not really using a cross-compatible spec at that point — you’re basically off the standard as soon as you’re working with a device not defined in the profile.

同样从网络层开始,Zigbee 和 Z-wave 是大家都喜欢的网状网络的主要运营商。它们试图解决两个问题:提供一个合理的规范,将数据包从网格网络上的一个位置移动到另一个位置并建议如何组织这些包。所以,它们都在堆栈中向上延伸。例如,Zigbee 使用一种称为简档的系统,简档是功能的集合,例如智能能源简档或家庭自动化简档。当协议变得如此具体以至于说“这就是灯泡的功能”时,很难实现概要文件中没有的设备。虽然有自定义数据的规定,但在这一点上,您并没有真正使用交叉兼容的规范——只要您使用概要文件中未定义的设备,您就基本上脱离了标准。

The other consideration with these two is that they are both routed mesh networks. We use one node to communicate with another node using intervening nodes. In other words, we can send a message from A to B to C to D, but in practice, we’ve sent a message from A to D. As routed meshes, each node understands the path the message needs to take, and that has an in-memory cost associated with it. While Z-wave and Zigbee have a theoretical limit of 65,535 nodes on a network (the address space is a 16-bit integer), the practical limit is closer to few hundred nodes, because these devices are usually low power, low memory devices. The routing also has a time cost, so a large mesh network may manifest unacceptable latency for your use case. Another consideration, especially if you’re launching a cloud-controlled consumer product, is that these mesh networks can’t directly connect to the Internet — they require an intervening bridge (a.k.a gateway, hub, edge server) to communicate to the cloud.

这两种网络的另一个考虑因素是它们都是路由网状网络。我们使用一个节点通过中间节点与另一个节点通信。换句话说,我们可以将消息从 A 发送到 B、C 和 D,但实际上,我们已经将消息从 A 发送到 D。在路由网格中,每个节点都理解消息需要走的路径,并且与此相关的内存开销。而 Z-wave 和 Zigbee 在网络上的理论极限为 65,535 个节点(地址空间为16位整数),实际极限接近几百个节点,因为这些设备通常是低功耗,低内存设备。路由也有时间成本,所以大型网状网络可能会对您的用例显示不可接受的延迟。另一个需要考虑的问题是,这些网状网络无法直接连接到互联网,这一点在推出云控制消费产品时尤为明显。网关、集线器、边缘服务器)与云通信。

A final caveat is that Z-wave is a single source supplier — the radios are made and sold by Zensys, so you have to buy it from them. Zigbee has a certification process, and there are multiple suppliers of the radio, from Atmel to TI.

最后一点需要说明的是,Z-wave 是一个单一来源的供应商——无线网络是由 Zensys 制造和销售的,所以你必须从他们那里购买。Zigbee 有一个认证程序,从 Atmel 到 TI,有多个无线电供应商。


You really just can’t compete with the amount of silicon being shipped based on Bluetooth. 10,000 unique SKUs were launched in Bluetooth in 2014. Other than Wi-Fi, there’s nothing that compares in terms of adoption. Bluetooth was originally designed for ‘personal area networks,’ with the original standard supporting 7 concurrent devices. And now we have Bluetooth low energy (BLE), which has a theoretically infinite limit. BLE did a ton to optimize around IoT challenges. They looked heavily at the amount of energy required to support communication. They considered every facet of “low energy,” not just the radio — they looked at data format, packet size, how long the radio needed to be on to transmit those packets, how much memory was required to support it, what the power cost was for that memory, and what the protocol expects of the CPU, all while keeping overall BOM costs in mind. For example, they figured out that the radio should only be on for 1.5ms at a time. That’s a sweet spot — if you transmit for longer, the components heat up and thus require more power. They also figured out that button cell batteries are better at delivering power in short bursts as opposed to continuously. Further, they optimized it to be really durable against Wi-Fi interference because the protocols share the same radio space (2.4GHz).

你没法和蓝牙相关的电子产品进行数量比较,因为在仅在 2014 年就推出了 10,000 个基于蓝牙的 SKUs. 除了Wi-Fi,没有什么能与之相比。蓝牙最初是为个人区域网络设计的,最初的标准支持 7 个并发设备。现在我们有蓝牙低功耗(BLE),理论上有一个无限的连接限制。BLE 在物联网挑战方面做了大量的优化工作。他们仔细观察了支持通信所需的能量。他们考虑了“低能量”的各个方面,不仅仅是无线电——他们考虑了数据格式、数据包大小、无线电需要打开多长时间来传输这些数据包、需要多少内存来支持它、内存的功耗是多少以及协议对中央处理器的期望,同时考虑了总的BOM成本。例如,他们发现无线网络每次智能在线1.5毫秒。这是很好的发现——如果你传输的时间更长,组件就会发热,因此需要更多的能量。他们还发现纽扣电池比连续电池更擅长在短时间内供电。此外,他们对其进行了优化,使其真正耐用,不受无线干扰,因为协议共享相同的无线电空间(2.4千兆赫)。

And then CSR came along and implemented a mesh standard over Bluetooth. Take all the advantages afforded with BLE, and then get all the benefits of a mesh network. The Bluetooth Mesh is flood mesh, meaning instead of specific routing to nodes, a message is sent indiscriminately across all nodes. This scales better than routed mesh because there are no memory constraints. It’s a good solution for many problems in the IoT and at scale is probably going to be the lowest cost to implement.

然后 CSR 出现了并通过蓝牙实现了网格标准。利用 BLE 提供的所有优势,然后获得网状网络的所有优势。蓝牙网格是泛洪网格,这意味着不是特定的节点路由,而是在所有节点之间不加区分地发送消息。因为没有内存限制,所以这比路由网格缩放得更好。对于物联网中的许多问题来说,这是一个很好的解决方案,大规模实施可能是最低的成本。


Thread is an up-and-coming standard built on top of the same silicon that powers the Zigbee radio. It solves the problem of mesh nodes not being able to communicate directly to the cloud by adding IPv6 support, meaning that nodes on the network can make fully qualified internet requests. There’s a lot of weight behind this standard. Google seems to think it’s interesting enough to make their own protocol (known as “Weave”) on top of it. And then there’s Nest Weave, which is some other version of Google Weave. As it stands, it takes a long time for a standard to really take hold — you can immediately see how the story with Thread is a little muddier, which will not help its adoption. It’s also solving a problem that it just doesn’t seem that many devices have. Let’s take sensors as an example. Do these low power, lightweight, low cost, low memory, low processing, fairly dumb devices NEED to make internet requests directly? With Thread, each node now knows a lot more about the world — where your servers are for example, and maybe they shouldn’t be concerned with those things, because not only do the requirements of the device increase, but now the probability and frequency of having to update them in the field goes way up. When it comes to the actual sensors and other endpoints, philosophically you want minimize those responsibilities, except in special cases where offline durability, local processing, and decision making is required (this is called fog computing).

Thread 是一种正在兴起的标准,它建立在为 Zigbee 无线电提供动力的硅的基础上。它通过添加 IPv6 支持解决了网格节点无法直接与云通信的问题,这意味着网络上的节点可以发出完全合格的 internet 请求。这一标准背后有很大的分量。谷歌似乎认为在其上创建自己的协议(称为 Weave)已经足够有趣了。然后是 Nest Weave,这是谷歌编织的另一种版本。按照目前的情况,要让一个标准真正站稳脚跟需要很长时间,您可以立即看到使用 Thread 的情况有多么混乱,这不利于采用它。这也解决了一个问题,所以使用的设备很少。让我们以传感器为例。这些低功耗、轻量级、低成本、低内存、低处理、相当哑的设备需要直接发出互联网请求吗?有了线程,每个节点现在对世界有了更多的了解——例如,您的服务器在哪里,也许它们不应该关心这些事情,因为不仅设备的需求增加了,而且现在必须在现场更新它们的概率和频率也大大提高了。当涉及到实际的传感器和其他端点时,从哲学上讲,您希望将这些责任最小化,除非在需要离线耐久性、本地处理和决策制定的特殊情况下(这称为雾计算)。

When Thread announced their product certification last year, only 30 products submitted. Another thing to note about Thread’s adoption is that the mesh-IPv6 problem has been solved before — there’s actually a spec in Bluetooth 4.2 that adds IPv6 routing to Bluetooth, but very few people are using it. Although Nordic Semiconductor thought it was going to be a big deal and went ahead and implemented it first, it just hasn’t come up much in the industry.t.

当 Thread 去年宣布他们的产品认证时,只有 30 个产品提交。关于线程的采用,需要注意的另一点是网格 IPv6 问题以前已经解决了——实际上蓝牙4.2 中有一个规范将IPv6路由添加到蓝牙中,但是很少有人使用它。尽管北欧半导体公司认为这将是一件大事,并首先着手实施,但它在行业中并没有出现太多

One thing Thread does have going for it is that it steps out of defining how devices talk to each other, and how devices format their data—doing this makes it more future proof. This is where Weave comes in, because it does suppose how the data should be structured. So basically, a way to look at it is that Weave + Thread = direct Zigbee/Z-wave competitor. We haven’t seen anyone outside of Google really take an initiative on Weave, other than Nest who have put a good marketing effort into making it look like they are getting traction with it.

Thread 确实有一个优势,那就是它不再定义设备如何相互通信,以及设备如何格式化它们的数据——这样做可以让它成为未来的证据。这就是Weave的作用,因为它确实假设了数据应该如何构造。所以基本上,一种看待它的方法是 Weave + Thread = Zigbee/Z-wave 竞争对手。除了 Nest 之外,我们还没有看到谷歌以外的任何人真正在 Weave 上采取主动,他们已经做出了很好的营销努力,让它看起来像是在吸引他们。


Other protocols live higher in the stack and remain agnostic at the network layer. The most well-known of these is probably Qualcomm’s Alljoyn effort. They have the Allseen Alliance, although their branding is a bit murky — Allplay, AllShare, etc. We’ve seen some traction with it, but not a ton — the biggest concern that it’s fighting is that it’s a really open-ended protocol, loosely defined enough that you’re really not going to build something totally interoperable with everything else. That’s a big risk for product teams. If there aren’t enough devices in the world that speak that language, then why do I need to speak it? That said, LIFX implemented it, and it worked really well for them, especially since Windows implemented it as well. Now, it’s part of Windows 10 — there’s a layer specifically for AllJoyn stuff and it seems to do well. There’s evidence with AllJoyn that you can bring devices to the table that don’t know anything about each other and get some kind of durable interoperability. However, at a glance, it seems complicated — the way authorization is dealt with and the way devices need to negotiate with each other. There really isn’t runaway adoption.

其他协议位于堆栈的较高位置,对网络层不可见。其中最著名的可能是高通公司的 Alljoyn 了。他们有 Allseen 联盟,尽管他们的品牌有点模糊——Allplay, AllShare 等等。我们已经看到了它的一些吸引力,但还不多——它所面临的最大问题是,它是一个真正开放的协议,定义得足够宽松,以至于你真的不会构建一些与其他所有东西完全互操作的东西。这对产品团队来说是一个巨大的风险。如果世界上没有足够的设备说那种语言,那我为什么要说呢?也就是说,LIFX 实现了它,而且对他们来说非常有效,尤其是因为视窗系统也实现了它。现在,它是视窗 10 的一部分——有一个专门针对所有游戏的层,它看起来做得很好。AllJoyn 有证据表明,您可以将互不了解的设备带到桌面上,并获得某种持久的互操作性。然而,乍看之下,这似乎很复杂——处理授权的方式和设备之间需要协商的方式。真的没有失控的收养。

IEEE’s Wi-Fi

IEEE’s Wi-Fi — they’ve ruled the roost with their 802.11 series. B then G then A, and now we have AC. 802.11 has been really good at being simple to set up and being high bandwidth. It doesn’t care about power consumption, it’s more concerned with performance because it’s meant to be a replacement for wires. Almost 2 years ago, they announced 802.11 AH which they’ve branded as HaLow, which attempts to address power, range, and pairing concerns of classic WiFi. Most Wi-Fi devices are not headless (“headless” — no display or other input), they have a rich user interface — meaning we can log in and configure them to connect to WiFi. Pairing headless devices has been a very tedious process. With HaLow, they’re solving two problems — how do we get things on easier, and how do we decrease the expectations (particularly power) of the device running the radio. It’s too early to know what type of traction this will get, but IEEE has a great track record at standards adoption.

IEEE’s Wi-Fi 网络——他们的 802.11 系列已经称雄天下。然后是 G 和 A 系列,现在我们有 AC 系列了。802.11非常擅长于简单设置和高带宽。它不关心功耗,它更关心性能,因为它是电线的替代品。大约两年前,他们宣布了 802.11 AH,并将其命名为 HaLow,试图解决传统无线网络的功率、范围和配对问题。大多数无线设备不是无头的(“无头的”——没有显示器或其他输入),它们有丰富的用户界面——这意味着我们可以登录并配置它们连接到无线网络。配对无头设备是一个非常乏味的过程。有了 HaLow,他们解决了两个问题——如何让事情变得更容易,以及如何降低运行收音机的设备的期望值(尤其是功率)。现在知道这将会带来什么样的牵引力还为时过早,但是 IEEE 在标准采用方面有着良好的记录。


More like: LoRa vs. SIGFOX. With these protocols, we’re looking at how to connect things over fairly long distances, such as in smart city applications. LoRaWAN is an open protocol that’s following a bottoms-up adoption strategy. SIGFOX is building out the infrastructure from the top down, and handing APIs to their customers. In that way, SIGFOX is more like a service. It’ll be interesting to see the dance-off between these two as the IoT is adopted in these more public-type applications.

更像是: LoRa 和 SIGFOX 比较。通过这些协议,我们正在研究如何在相当长的距离上连接事物,例如在智能城市应用中。LoRaWAN 是一个遵循自下而上采用策略的开放协议。SIGFOX 正在自上而下构建基础设施,并将 APIs 交付给他们的客户。这样,SIGFOX 更像是一种服务。随着物联网在这些更加公共的应用中被采用,看到这两者之间的分离将会很有趣。

That’s the body of standards that need to be addressed. There’s a ton more, but we don’t see them as exciting for the IoT today.