What should be considered when building a wireless sensor network?

Question

This question originates from a question asking about a specific detail about building wireless sensor networks. While answering the question, I wanted to share some general guidelines for the planning process of a wireless sensor network.

So let's consider we want to build a new wireless sensor network deployment. What is the best approach to avoid common pitfalls and mistakes others made before?

Answer 1

Please do not waste your time and make the same mistake as hundreds of research groups (including ours) made before for decades and just throw some unspecific sensors into the wild without knowing what you really want to get in the end!

There is a nice paper from 2006 (!) that shares experiences from a real-world deployment.

Langendoen, Koen, Aline Baggio, and Otto Visser. "Murphy loves potatoes: Experiences from a pilot sensor network deployment in precision agriculture." 20th International Parallel and Distributed Processing Symposium (IPDPS) 2006.

Be prepared for those and many other problems that could arise and plan ahead and focus on your target!

You should ask yourself the following question: Why do I want to build the deployment? Is it really the data itself that I want to collect, do I want to evaluate and develop network protocols or do I want to develop and test new hardware? The answer results in very distinct paths:

I want to get the data!

In that case, try to rely on proven practices as much as you can. Buy standard hardware, use industrial grade housings, provide much more batteries than you think your hardware requires and monitor them! Use already existing and well-tested software and do not build everything from scratch! Even think about the following: Do I really need wireless connections?

Of course, there are many applications where you really need hundreds of energy harvesting, wireless, self-organizing and tiny devices. But just using these techniques because they are cool is a waste of money and time.

If you really want to get the data, nothing is more frustrating than to notice that just for the most interesting day, no data is available because water has accumulated in your devices (been there...).

I want to improve protocols for wireless sensor networks!

In that case, really focus on the core. I talk about network protocols here, but it equally holds for all other procedures and algorithms in the IoT context.

For most protocols, it does not care if they transport real-world data or just some pseudo-random noise. So why not take the easy road, throw away your sensors and just generate some random data? I recommend the following procedure:

1. Think about which problem you want to solve. What is your research question?
2. Read! Many things have been done already. Many concepts have been shown to be good, many others not. Starting with network protocols from scratch is just a waste of time.
3. Do some theoretical evaluations. Is it really possible to improve a given protocol or is it already at a principle boundary? Shannon can not be fooled!
4. Do simulations. I suggest the OMNeT++/INET framework, but there are many frameworks out there. But please do not start from scratch. Most components are already there for your convenience. Test if your ideas work in the controlled environment of a simulator.
5. Work on the hardware implementation. Does your implementation work at least on your desk?
6. Test it in an already existing testbed. One example is the FIT IoT-LAB. This allows you to test your implementation with real-world hardware without the burden of all the problems arising from self-made testbeds.
7. Now you can finally plan your real-world deployment and tailor it to the specific problem that you want to address. Until now you should have a good idea how dense your network has to be, how many devices are meaningful, how they should be distributed, which kind of data has to be provided and so on. Then go to "I want to get the data!", but this time your data is the performance measure that you want to test.

Yes, this is a long way to go, but there are students doing this during a six-month master's thesis, so it is feasible and definitely worth the effort! There is already so much existing research in this area that skipping a step does not pay off in the end.

I want to build cool hardware!

If you are mostly interested in building cool hardware, start with playing around with existing hardware. Then think about what this hardware lacks and what could be improved. Maybe you just want to create a nice and waterproof housing and see how it works in practice.

You will need several iterations anyway, so start with something oversized (e.g. in terms of RAM or persistent memory) and then strip away unnecessary parts in future iterations. This is much more satisfactory than recognizing that the software you want to use is just 1 KB too large after production. Also, provide good possibilities to debug and evaluate your hardware.

Even if you do not need a serial or USB interface for the final application, it speeds up the development a lot. If you are actually building a housing, attach a humidity sensor and monitor it constantly instead of just waiting and checking manually. If you integrate an energy harvester, monitor the energy flows, even if a precise power measurement IC might be oversized for a final application.

For the software part, rely on existing components! If you are building a testbed because you like to build hardware and you do not really know what to do with it, publish it! There are many people (see above) that dream to have access to a real-world deployment, so they will happily provide software.