Introduction and Background#
Silicon Labs has provided performance testing results from embedded mesh networks as part of developer conferences and industry white papers. The basic performance data of throughput, latency, and impact of security can be used by system designers to define expected behavior. This testing has previously been presented for Zigbee and Thread networks as basic 15.4 mesh networking technologies. These were presented because performance varies even though both systems use the same underlying physical layer defined by IEEE 802.15.4. With the advent of Bluetooth mesh networks, it is common for questions to arise concerning the expected performance differences between a Bluetooth mesh and these 15.4 mesh networks. Prior to discussing the testing and performance differences, we need to review the underlying technologies of these networks as it helps to understand their performance differences.
Underlying Physical Layer and Packet Structure#
Network performance is based on payload sizing since the application usage does not account for the packet overhead.
Bluetooth low energy is based on the BT 4.x specification and has a 33-byte packet with an underlying data rate of 1 Mbps. The Bluetooth mesh packet size is shown in the figure below and results in a 12 or 16-byte payload. For payloads above 12 bytes, there is a process of segmentation and reassembly.
Bluetooth mesh has a higher data rate but the packet payload is smaller; therefore, it takes more packets to send the same amount of data. Our data on performance is based on payload size as this is the design parameter of concern when building an application. The Bluetooth mesh has designed mesh profiles (application layer) to specifically minimize the packet payload and fit in a single packet where possible.
1 | 1 | 3 | 2 | 2 | 12 or 16 | 4 or 8 | ||
|---|---|---|---|---|---|---|---|---|
IVI | Network ID | CTL | TTL | Sequence Number | Source Address | Dest Address | Packet Payload | NWK MIC |
Bluetooth Mesh Packet Format
Network Routing Differences#
Bluetooth mesh uses a managed flooding technique to relay messages instead of routing. This means that instead of building, maintaining, and using defined routes to send messages, Bluetooth mesh relays relay the messages they hear using the following two simple rules:
Every message has a unique sequence number.
Relays keep track of the recently seen sequence numbers and do not relay the messages they have already seen or relayed before.
The messages also have a time-to-live counter (TTL) and every time a message is relayed, the counter is reduced by one until it reaches a value indicating that it should no longer be relayed.
As there are no acknowledgements used at the network level, Bluetooth mesh relays can be configured to repeat the same message multiple times so that more reliability is achieved due to the air interface packet loss. Typically, this value is set to 3, so each relay repeats the same message three times. Also, a configurable delay between the repetitions is used to optimize between latency and network performance. The minimum delay between repetitions, called the retransmission interval = (Relay Retransmit Interval Steps + 1) * 10ms + 0-10ms random delay, is typically 15 ms per hop.
Note: This performance data is for the Silicon Labs implementation of these mesh networking stacks. As is shown in the test network and infrastructure provided for this testing, no tests were performed with other stacks or systems.
This application note also focuses on the performance of new features introduced in the Bluetooth Mesh 1.1 specification, such as Remote Provisioning and OTA DFU.