Configuring High Density Sensor Networks

Summary

Optimizations for dense sensor networks

  1. 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. Theoretically, the gateway can process more than that, but we seldom see perfectly randomized sensors. If 60 sensors will talk in a 60-second period, it is just as likely that they will communicate in the first half of the minute as 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 simultaneously. Consider a room with one sensor in every corner to ensure they see around cabinets and such, but when someone moves in the middle of the room, all four are triggered simultaneously. Four isn’t too big of an issue, but 40 would be a problem.

In a perfectly randomized network where no two sensors are triggered at the same time, 60 sensors with a one-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.

  1. Sensor to Gateway Distribution:

When the sensors scan for an available gateway, they start their search on channel one and continue. Therefore, if there are two gateways, one running on channel three and the other on channel 10, as sensors start coming online if they are in the range of both gateways, they will almost always join the gateway on channel three before they find the gateway on channel 10. This will continue until the gateway on channel three runs 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 five sensors were on one network and the other five were on a second network, each network holding one gateway, then the sensors would automatically join only their designated gateway.

You could set 10 gateways into ten 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

Sensor Network Density

Dense Network

By splitting into two networks, the sensors are automatically split in half to which gateways they can join. However, in this example, there is also a range definition that will cause some sensors to only see one gateway. The top left sensor can only join red or green but is too far from green, so one will always join red. The bottom left sensor will join red or green as it can see both, but it 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.

Conclusion

Depending on how many gateways you deploy and how many networks you split them into, you can devise a worst-case guess of how many sensors will be on one gateway. In the above scenario, 72 sensors are placed into two 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 as 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.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.