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
103 nodes: ~80-120ms
137 nodes: ~80-120ms

Unicast latency while multicasting with other nodes

NA

47   nodes: ~40ms
103 nodes: ~80-120ms
137 nodes: ~80-120ms

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

Product LinkProduct Link

Product LinkProduct Link

NA