There is already a fair amount of easy reachable information regarding Thread, ranging from the basics to in-depth technical dive. This blog is not intended to be a typical one with this kind of information.
Instead, consider the situation when there is already decided to use Thread, either by requirements gathered by itself or passed down by others; so, what happens next? How is a specific vendor selected?
There are various questions that can help make a better decision, but scalability is one of the main topics to have in mind; and just to mention a few questions in terms of vendors: how robust is the Thread implementation? How committed is with further development and support? How robust is its ecosystem? Are there any known products already using its solutions? Is there relevant publicly available collateral material? and the most obvious ones are those regarding price and pricing structure.
There is a “Thread Large Network” Application Note (AN) that is available in the NXP webpage, there are some tacit implications about this AN that give insights to some of the questions mentioned above and maybe can also give it to other important considerations to a specific Thread application.
First and foremost, the implementation of the Thread protocol depends on each vendor, this Application Note tests the NXP implementation together with its available platforms. In other words, both hardware and software are being put to test as a system and with one of the core features of Thread: the potential to scale a network to include over 250 devices under real world conditions.
Also important, consider the invested resources to test the platforms and the confidence to publish the obtained results; which is not very common, at the time of this publication there is only other vendor that has published something similar.
In the below table there is a condensation of the information mentioned in the AN, compared side to side to the only other vendor with similar test published. One suggestion is to make this kind of comparison before deciding which vendor to use, customizing the table and add items that are particularly important.
In conclusion, after the determination to use Thread, there still are important factors and work to be done before deciding to use a specific vendor; not all Thread implementations are the same, and it should be considered as a part of the development itself to gather the relevant information and deciding in favor of a vendor, future headaches can be prevented by doing so.
Thread Large Network | NXP | Vendor 1 |
Test Network setup and conditions Description | Yes | Yes |
Network topology | Fixed, distributed in clusters | Fixed, distributed in clusters |
Office Layout | Yes | Yes |
Implementation Pictures | Clusters and mounted | Clusters and mounted |
Central test server controls scripts and tests | Yes | Yes |
Number of devices | 1 topology: 250 nodes | 3 topologies: 47, 103, 137 nodes |
WiFi captures showing 2.4GHz usage on building | Yes | Yes |
Data transmission concepts and basic background information | Mesh, IEEE802.15.4 Data frame, IPv6, 6LoWPAN, ICMP, CoAP, Latency, RTT, Multicast, 2.4GHz channel usage concept | Multicast, Thread, Wireless interference basic behavior |
Theoretical expected latency and RTT data for multiple payload sizes with multiple hops | Yes | NA |
Results |
|
|
Network attaching time | NA | NA |
Multicast latency Average | 250 nodes: ~40-80ms | 47 nodes: ~40ms |
Unicast latency while multicasting with other nodes | NA | 47 nodes: ~40ms |
Unicast latency with no added interference | 250 nodes: ~20-40ms | NA |
Test data | Packet interval, payload size, RTT average data results | Packet interval, latency, total packets, worst/average data results |
Conclusion | Yes | Yes |
Used Platforms | NA |