Throughput
Milky Ways of sensors hanging above our heads are rising above our heads in offices and public spaces. They control the environment by sending signals to neighboring lights and HVAC systems that adjust their output based on local conditions and presence of people. Sensor packed smart buildings become natural elements of our everyday life. To the point we simply do not see them nor we see the light or cooling air that help counterbalance sunshine (or lack of it). The evident trend is to have even more sensors per square foot and have each of them reporting more frequently. They usually report to middleware gateways that create a local processing Fog and then send aggregated data to the Cloud.
The challenge is to collect information from all the nodes, via wireless links. The messages sent by the sensors are small, just a few bytes, including the security overhead (yes, these days every bit of information has to be authenticated and encrypted). So why is it a challenge, when the payload is so small? After all anybody's home WiFi can stream megabytes per second worth of high definition video.
The challenge is the high number of transmitters each randomly accessing the shared radio spectrum. It is like hundreds of cars entering randomly a crossing. All within the same time window. The effect? Collisions. And nothing goes through.
There can be some arbitrage techniques implemented, such as traffic lights. But imagine the waiting line at a crossing of 100 streets, when only one is green at a time and 99 red. A standstill. Streets of Hanoi or Ho Chi Minh show us the only way to increase throughput is to swap cars for bikes or scooters. Translating that to radio means very small packets, moving at a fast rate over a many channels. The effect is a very high throughput and surprisingly no collisions!
Comparing existing radio technologies, there is one clear leader in this field: Bluetooth Mesh. It meshes messages like Hanoi meshes scooters. WiFi in comparison is like a veeery long train (lots of payload, but only few simultaneous connections) and anything 802.15.4 - based is Shenzhen: narrow streets full of big cars, all in one gigantic traffic jam.
Bluetooth's message occupies a sub - millisecond time slot - roughly 10 times smaller than ZigBee. Theoretically we can squeeze more than 2500 of them per second. IRL it means we can easily have 100+ nodes sending data every second. Or 1000+ nodes sending randomly data every 10 seconds each, with very low collision rate. Again, nothing comes close, while the next release of Bluetooth will double that number. Looks like we have an unexpected winner in an unexpected race!
The challenge is to collect information from all the nodes, via wireless links. The messages sent by the sensors are small, just a few bytes, including the security overhead (yes, these days every bit of information has to be authenticated and encrypted). So why is it a challenge, when the payload is so small? After all anybody's home WiFi can stream megabytes per second worth of high definition video.
The challenge is the high number of transmitters each randomly accessing the shared radio spectrum. It is like hundreds of cars entering randomly a crossing. All within the same time window. The effect? Collisions. And nothing goes through.
There can be some arbitrage techniques implemented, such as traffic lights. But imagine the waiting line at a crossing of 100 streets, when only one is green at a time and 99 red. A standstill. Streets of Hanoi or Ho Chi Minh show us the only way to increase throughput is to swap cars for bikes or scooters. Translating that to radio means very small packets, moving at a fast rate over a many channels. The effect is a very high throughput and surprisingly no collisions!
Comparing existing radio technologies, there is one clear leader in this field: Bluetooth Mesh. It meshes messages like Hanoi meshes scooters. WiFi in comparison is like a veeery long train (lots of payload, but only few simultaneous connections) and anything 802.15.4 - based is Shenzhen: narrow streets full of big cars, all in one gigantic traffic jam.
Bluetooth's message occupies a sub - millisecond time slot - roughly 10 times smaller than ZigBee. Theoretically we can squeeze more than 2500 of them per second. IRL it means we can easily have 100+ nodes sending data every second. Or 1000+ nodes sending randomly data every 10 seconds each, with very low collision rate. Again, nothing comes close, while the next release of Bluetooth will double that number. Looks like we have an unexpected winner in an unexpected race!
Comments
Post a Comment