Configuring High Density Sensor Networks
Optimizations for dense sensor networks
- Sensor Communication Density:
As a rule of thumb we like to allow enough bandwidth for one sensor communication with the gateway per second, (or 60 per minute) as a maximum throughput. In theory the gateway can process more than that, but we seldom see perfectly randomized sensors. If there are 60 sensors that are going to talk in a 60 second period it is just as likely that all of them communicate in the first half of the minute as it is that they are equally spaced out. The other tricky part with triggered sensors such as the PIR is that depending on how they are deployed there can be events that trigger many at the same time. Consider a room with one sensor in every corner to make sure they see around cabinets and such, but when someone moves in the middle of the room all 4 are triggered simultaneously. 4 isn’t too big of an issue, but 40 would certainly be an problem.
In a perfectly randomized network where no two sensors are triggered at the same time 60 sensors with a 1 minute rearm time would work flawlessly. But in the real world I believe that will be pushing some limits and you’ll likely run into issues where sensors somewhat randomly fall offline because they are not able to communicate effectively.
- Sensor to Gateway Distribution:
When the sensors scan to find an available gateway they start their search on channel 1 and continue up from there. Therefore if there are two gateways one running on channel 3 and the other on channel 10. As sensors start coming online if they are in range of both gateways they will almost always join the gateway on channel 3 before they find the gateway on channel 10. This will continue until the gateway on channel 3 is running at capacity and can’t accept more sensors. Then the sensors will start joining on channel 10.
Example: 10 sensors with 1 minute heartbeats (10 messages a minute) when idle but each communicating every 5 seconds (120 messages a minute) when active. They can all talk to one gateway just fine when idle, but when they go active there is too much traffic for a single gateway. Because of this the ones that fall off will re-scan and find the channel 10 gateway and start communicating through it. Over time they will balance themselves.
There are some ways to maximize the balance from the start, but some can be more difficult to implement.
In this small simple example if you know which gateway is on channel 3 and which is on channel 10. Simply unplug the gateway on channel 3 until the first 5 are joined to channel 10, then plug it in and the second 5 will stop at channel 3. But in a larger implementation this can be more difficult.
Segregating by network can be used, if 5 of the sensors were on one network and the other 5 on a second network, each network holding one gateway. Than the sensors would automatically join only their designated gateway.
You could set 10 gateways into 10 networks for perfect balance but then you have to keep track of which network every sensor is on. But there is another way to work it where you don’t have to keep track at that level.
A more complex example:
Area is too big for a single gateway to cover, but two gateways opposite can cover all.
Network 1: Red Gateway, Green Gateway, Black Sensors
Network 2: Blue Gateway, Yellow Gateway, Gray Sensors
By splitting into two networks the sensors are automatically split in half as to which gateways they can join. But in this example there is also range definition that will cause some sensors to only see one gateway. Top left sensor can only join red or green, but is too far from green so that one will always join red. Bottom left sensor will join either red or green as it can see both of them but won’t join yellow because it’s not in the same network. The distribution won’t be perfectly balanced because the bunch in the middle will still have to select one of the gateways, but it is much better than it could be with a single network. You only have to keep track of which gateways are in which network.
If the area were smaller and each gateway could see all sensors, this still works just not quite as distributed but you don’t have to track which gateway is in which network. So your environment can dictate a bit how you distribute the gateways.
Depending on how many gateways you deploy and how many networks you split them into you can come up with a worst case guess of how many sensors will be on one gateway. in the above scenario 72 sensors into 2 networks, assuming about 2/3 will go to the gateway with the lower channel. So about 20 sensors. The rearm time could be as short at 1 minute and they should still be within the maximum throughput, as long as they don’t have events that trigger them all simultaneously.
Ultimately you have some flexibility because if this proves too much for one gateway a few will fall off and join the other gateway in the network anyway.