We continue our series on wireless communication in commercial lighting environment, and this is the third – and last – blogpost covering the issue of network robustness. This time we’ll discuss multicasting, data packet size, payload, overhead and frequency hopping, explaining what this all means in the context of commercial smart lighting systems.
When outlining some of the advantages of mesh networks using the flooding technique, we mentioned multicasting as one of the features that are critical for a robust performance of a commercial smart lighting network. Let’s see what multicasting is and why it’s so important in smart lighting applications. The thing is that in a commercial environment, messages usually must be distributed to a number of recipients at the same time. Think about office spaces – it almost doesn’t happen that a single lamp operates independently. Instead, commands need to be transmitted to entire groups of lamps. With unicast, this communication is slow and sluggish, which causes latency issues and prevents synchronous operation of the lighting infrastructure. This is because unicast is like communicating with a group of persons via SMSes – each message has to be sent separately, each of them needs to have a sender and recipient specified, and preparing each of them takes certain amount of time. Now multicasting is more like communicating via Twitter. A single tweet can reach thousands of recipients even though you don’t have to address each of them separately. This is the essence of the publish/subscribe model that we use in our Bluetooth mesh implementation. A message is broadcast to multiple nodes simultaneously, and thus can be delivered to thousands of fixtures with minimal energy and processing power consumption.
In the previous blogpost we also mentioned that achieving a satisfactory network performance within a commercial lighting network with hundreds or thousands of nodes requires minimizing the occurrence of radio packet collisions. This is one of the major challenges for high-density smart lighting networks, since they involve multiple transmitters each randomly accessing the shared radio spectrum over and over again. To minimize collisions, data packets must be small enough and need to be transmitted as quickly as possible. We’ve already covered the issue of transmission data rate, now let’s focus of the size of data packets.
Each data packet includes payload and overhead. The former is the essential data carried within a packet – the core message that is conveyed so that other network nodes can act upon it. The overhead is all the additional information that is required to make the message reach its destination. This includes security mechanisms, certain networking procedures, potentially also some sort of routing data (if a routing technique is applied). Radio communication requires overhead for effective, secure communications and interoperability. It ensures that appropriate encryption and authentication measures are applied, and that the integrity of transmitted data is maintained. So on the one hand, overhead must be capacious enough to ensure reliable and safe communication, but on the other hand we want to keep it as small as possible – since the size of overhead obviously affects the size of the entire data packet. Just one of many contradictions typical for the resource-scarce IoT environment. Unfortunately, numerous protocols are loaded with overhead. If you look at Wi-Fi, both payload and overhead are extremely heavy. As a result, messages occupy massive time slots on a given frequency, which is the easiest way to saturate such dense networks as commercial smart lighting systems. Bluetooth is just the opposite, proving that proper network design can minimize overhead and improve the overall network performance, while not compromising on security or manageability.
With both payload and overhead kept under very strict limits, Bluetooth’s message occupies less than 400µs in the shared radio spectrum. This means that more than 2,500 such messages can theoretically be sent over a period of 1 second. Bluetooth has been optimized for transporting very large amounts of very small data packets, so it doesn’t make much sense to compare these numbers to Wi-Fi which has been designed with completely different assumptions in mind. But even other low-power protocols pale in comparison. It takes less than 4 ms to transmit a message within a ZigBee network, which is approximately 10 times more than in the case of Bluetooth. Where does this enormous difference come from? First, the data packet of ZigBee is roughly 2 times larger than Bluetooth’s. Second, the maximum data rate of all 802.15.4 radios is 250 kbit/s, compared to Bluetooth’s current rate of 1 Mbit/s (and 2 Mbit/s within a couple of months). All these numbers add up, having significant impact on real throughput, and determining whether a high-density smart lighting network deployed in a commercial environment can provide a satisfactory performance. Our CTO has recently published a great post on throughput related challenges in the commercial environment – so check it out if you wish to get a better understanding of what it’s all about.
The requirement for keeping the packet size as small as possible is yet another reason why the flooding technique suits smart lighting applications so well. Regardless of wireless communication technology applied, payload accounts for only about one-third of the entire data packet, which shows that keeping overhead at a reasonable size is quite a challenge. Obviously, this cannot be done at the expense of e.g. security, but eliminating the routing information from this mix is a clear improvement contributing to robust performance of Bluetooth mesh implementations.
One more way to increase robustness of a high-density smart lighting network is to utilize additional packet collision prevention mechanisms. Bluetooth Smart mastered this by using the adaptive frequency hopping scheme. It allows the signal to hop dynamically between the 40 available channels, avoiding the noisy ones and selecting those that ensure a quick and successful delivery. This is particularly important considering the fact that Bluetooth utilizes the same 2.4GHz spectrum as numerous other radio technologies, including Wi-Fi, ZigBee or Thread, but also such appliances as microwave ovens, baby monitors or cordless phones.
However, this concept cannot be directly applied in the case of mesh networks. In Bluetooth Smart, once two devices establish a connection between each other, they can easily agree the channel hopping scheme, i.e. the sequence of channels over which they will hop while transferring data between each other. But a Bluetooth Mesh network is non-connection-oriented, which is part of the reason why it scales so well to thousands of nodes. The downside is that the adaptive frequency hopping scheme doesn’t work in such a dynamic publish-subscribe model. Fortunately, Bluetooth has another weapon. Its core functionality allows the broadcaster to send commands simultaneously over 3 different channels. The recipient chooses the least noisy one and uses it to read the incoming message. The single-channel 802.15.4 radio, used by both ZigBee and Thread, does not have such tricks up its sleeve that would allow it to effectively combat interference common in the crowded 2.4GHz band. This, in addition to the lower data rate and larger packet size, is yet another reason why high-density networks based on the 802.15.4 radio saturate much quicker than mesh networks based on Bluetooth.
Coming up next: what matters when it comes to maintenance of commercial smart lighting networks.