The WiFi and RF debate for IoT and Sensors

The IoT concept has been around for a while and soon applications and platforms will start hitting the market (whether the market is mature enough for the IoT, could be another debate…). It has never been that easy to build a prototype, make a nice 3D-printed case, deploy a backend application on a Cloud platform (or use one of the numerous existing IoT Web applications) and use crowd funding for getting started.

So, I am quite sure there is a number of people out there investigating potential solutions for M2M communication. In addition, a number of vendors are offering respective solutions trying to address the major IoT communication challenges: cost, power consumption, range.

Lately there have been many debates over low-power WiFi and RF (including ZigBee, 6LoWPAN, etc.) networks in the context of IoT application and sensor devices. In the lack of a succesfull radio communication technology for IoT devices, people (developers, researchers, etc.) seem to have been divided into two groups: Group A that supports that new WiFi implementations (featuring low energy consumption) can be used for IoT internetworking. Group B that opposes and suggests that WiFi is too complicated for sensor and M2M communication.

Was WiFi ever ment to be used for M2M and IoT? Definitely not, so why bother with the comparison and why do vendors care about providing enhanced WiFi modules that can be integrated into devices? There are some benefits for sure:

WiFi pros:

  • Internet gateways (i.e. WiFi access points) are already used so IoT devices could have direct connectivity to the Internet without the need for additional infrastructure (setup cost, maintenance cost, etc.).
  • Almost every smartphone is WiFi enabled, so communication with WiFi devices is quite easy and direct without the need for additional hardware.
  • It is an established standard, supporting a full TCP/IP stack, meaning that when developing applications you need to focus only on the application level programming for message and information exchange.
  • Integrates security

 

WiFi cons:

  • Cost (even the Electric Imp at 25$ is much more expensive than a pair of RF transceivers)
  • Even low power WiFi has more power consumption than RF (and also the communication protocol introduces much unnecessary overhead)
  • Low power has poor indoor performance

RF on the other hand has also great benefits over WiFi in the context of M2M:

  • Higher transmission range and better indoor performance
  • Better price

 

Standards like ZigBee and 6LoWPAN include security implementations and mechanisms for error corrections/retransmission, etc. so that developers can focus just on the application level as well.

Who is the winner?

I think there can be two answers here: a) depends on the application/use case, b) the hybrid solution.

For instance, if an IoT system relies on a limited number of devices and direct mobile communication, then WiFi currently looks the best solution.

For case a) there are several options. An Arduino with a WiFi shield, or a Flyport WiFi module can be used for quick prototyping (and also used integrated in systems, especially the Flyport). The soon available electric imp is another example of a WiFi integrated device with low power consumption that can interact with the physical world and enable IoT applications.

For the hybrid solution, the idea is that devices are interconnected through RF and then a gateway is used to provide connectivity with the rest infrastructure and/or the Internet.

What’s missing here? Standards for gateway-to-devices communication, address translation (like NAT) for physical devices so that they can be accessed remotely, etc.

A very interesting RF-based approach is the Enocean alliance and the soon-to-come Flyport Enocean gateway.

 

Which RF technology is going to win?

Well, ZigBee for a number of reasons has failed to penetrate home market (even Bluetooth 4 seems to compete better)  and I am not quite sure it will be given a second chance in the IoT era. 6LoWPAN looks more promising, incorporates IPv6 support (thought I am not sure why every device shall have an IP address) and might have a better chance.

Would like your opinion on the entire debate issue, so please go ahead and answer the following poll:

WiFi vs RF for IoT: I would currently develop a product using:

View Results

Loading ... Loading ...

WiFi vs RF for IoT: Which one will eventually win?

View Results

Loading ... Loading ...

About ZigBee:

View Results

Loading ... Loading ...

3 Comments

  1. Christophe August 31, 2012 1:03 pm Reply

    Just one thing : you say “WiFi [was] never ment to be used for M2M and IoT”. Actually, it’s irrelevant : the telephone network was never meant for sending documents, yet we have (had) faxes ! That’s the typical example of my “Ladder theorem” : infrastructure and applications are the two legs climbing the ladder of innovation. You never change both at the same time.

    • Charalampos August 31, 2012 6:34 pm Reply

      I see your point Christophe, in your example though I consider telephone network as the medium that enables everything from fax and voice to streaming media data at high speeds. Similarly, the RF technology (in the broader sense) enables WiFi, 3G, ZigBee, BT, DVBT, etc.
      So, to my point (WiFi was never ment for IoT), WiFi is not low power (some people try to build low power modules but still not enough info and use cases on that), in many cases TCP/IP is not ideal (especially for M2M) and there are also cases where WiFi range is not enough.
      IoT is about bringing Internet resources to devices and sharing sensor information through the Internet. WiFi can be used in some cases, but was never designed for devices like sensors (need for low power, high range, low bandwidth)

      Ch.

      • Arnie April 14, 2014 4:35 pm Reply

        This might seem a bit late, but what are your views on this subject now? Have you done a bit of research into DASH7?

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>