Wifi vs Bluetooth vs BLE, choosing the right IoT tech

Internet-of-Things (IoT) devices are increasing in popularity and availability - think Amazon Alexa, smart thermostats & light bulbs, Internet-connected garage door openers, GoPro cameras, and so on. One thing these products have in common is that they communicate wirelessly with either a mobile device, the Internet, or both. As these devices become smarter and generate an ever increasing amount of data, the need to be controlled by or communicate with a mobile device presents some difficulties to developers.

What are the best existing technologies for enabling this wireless communication? How can developers of IoT devices and apps design products to be user-friendly? As wireless communication technologies have not quite caught up to the needs in IoT, the answer, unfortunately, is that it's complicated.

The Options

Let's ignore three wireless communication technologies that are unsuitable to the majority of IoT applications: Infrared (IR), cellular connectivity, and Near Field Communications (NFC).

IR was popular in flip phone days, but almost none of today's smartphones come with this option, mainly due to low bandwidth, short range, and a requirement that devices be positioned within line of sight of each other. Cellular is not feasible due to the need to provision a SIM card and pay a subscription fee. NFC is short range (<20 cm), not many smartphones support it, and also has low bandwidth.

The technologies most ideal for IoT products must be usable by consumers out of the box and ideally with minimal setup. This leaves us with three options: Bluetooth Classic, Wi-Fi, and Bluetooth Low Energy (BLE).

Bluetooth Classic and Wi-Fi are the historic choices and supported by most smartphones, but were developed with rather specific use cases in mind. Wi-Fi was conceived to eliminate wires on LAN networks. Bluetooth was designed for creating personal area networks (PAN) between computing devices (laptops, smartphones) and various peripherals such as keyboards and headsets, typically over shorter distances than Wi-Fi.

Neither of these connection types are ideal for IoT applications. Wi-Fi networks rely on the TCP-IP protocol, which requires that each device obtains its own IP address and authenticate itself on the network. This is not suitable for IoT devices, some of which don't have a physical UI for entering a Wi-Fi passcode. Wi-Fi networks have a very high data throughput, but that is not always needed by IoT devices. Meanwhile, Bluetooth Classic requires pairing of each individual device, which can be confusing for users. Bluetooth Classic supports fairly high data transfer rates, but also uses a fair bit of energy, which is not suitable for small battery powered devices that need to run for long periods of time.

In recent years, a third connectivity option has become available with modern devices - Bluetooth Low Energy (BLE). BLE is perfect for devices that must operate for long periods of time on small energy sources, such as coin cell batteries. Devices that utilize BLE today range in intelligence from heart rate monitors to smart watches. BLE is particularly well suited for receiving small data updates, such as the current heart rate, every few seconds. The "pairing" process is also greatly simplified since BLE devices can advertise themselves at will and multiple BLE devices can be connected to a central device, such as a smartphone. BLE support goes back as far as the iPhone 4S.

The Challenge of Large Files

But BLE is not the answer for every ioT device or scenario. Smart watches, for example, exchange a lot of data with their paired device. Anyone who has owned an Apple Watch will know that sometimes you are wirelessly pushing updates that are over 200MB to the watch. It's a common misconception that the watch primarily relies on BLE to accomplish this. For high-bandwidth transfers like these, the watch uses both Wi-Fi and Bluetooth Classic.

So what if your goal is to transmit moderately sized files, say 500KB images?

You could use Wi-Fi, and a lot of products do. GoPro creates its own Wi-Fi hotspot and Amazon Alexa has you go through a Wi-Fi setup process. But your smartphone can't be connected to more than one Wi-Fi network at once, so it will pick either the home network or your IoT device's hotspot. Even if your ioT device can act as a Wi-Fi access point, unless that device is already connected to your home Wi-Fi network, your users will have to exit your app, go into device settings, find the Wi-Fi section, and select your device's network from the list to temporarily connect to it. Then they would have to go back to the app. You have probably experienced this at least a few times when using "connected" mobile devices like cameras and home automation tools - it is a sub-optimal user experience.

What about Bluetooth Classic? With Bluetooth 3.0 High Speed, throughput is as high as 24 Mbps, so once paired, sending 500KB would take no time at all. This sounds like the way to go, especially if battery consumption is not much of an issue. But at least with Apple devices, one must enroll into Apple's MFi program in order to enable serial communication over Bluetooth Classic. This can be cost-prohibitive, as Apple collects licensing and other fees in exchange for this functionality, and is rather complicated from a technical standpoint. This is not an issue on Android, but most developers want their devices to be compatible with both major platforms.

So once again, BLE is your best bet. Apple iOS devices support BLE out of the box, without the need to enroll into the MFI program, and many Android devices are being shipped with BLE as well. To send large data files, one needs to break apart the payload into 20-byte chunks. On the receiving end, these chunks are recombined. You can send around four such chunks per connection interval, which can vary from one device to the next. Android devices support intervals as low as 7.5 ms. The iPhone 6 supports connection intervals in the 30 ms range. So from here we can calculate the actual bandwidth: 

At this rate, a 500KB image file would take a little over three minutes to transfer. There is not really a good way around this as BLE was simply not designed for high transfer speed, hence the LE (Low Energy) in the name. Where BLE is all you can use, this transfer rate is just something you will have to live with. Clever use of data partitioning, serialization, and compression can help reduce payload sizes. One can imagine a scenario where a JPEG compressed image is wrapped with a Protocol Buffer message before being broken up into 20 byte chunks and sent over via BLE.

But what can you do if your BLE transfer rates are simply way too slow for your application and you still don't wish to join Apple's MFi program? If your device has Wi-Fi capabilities, BLE can act as a control interface to the Wi-Fi chipset. Your users may be able to launch the app, which will use BLE to direct your device to create a Wi-Fi access point, or connect to the user's home network based on the information received from the app over the BLE connection. Once both devices are on the same network, Wi-Fi can be used to transfer large chunks of data.

So in summary, it's complicated

As you can see, the answer to seamless wireless communication between IoT devices and smartphones relies on using several different wireless communication technologies in concert.

BLE is the common lowest denominator, so add BLE capabilities early on. Nordic nRF BLE chips cost only pennies and are well documented and supported. BLE is perfectly suited for applications with a need to exchange simple bits of data between devices without pairing or any manual connection steps. If you don't need to send large files, live video, or have other bandwidth intensive data requirements, you can stop here - BLE is all you need.

If you do need to send moderately large files, and if your device can connect to a home Wi-Fi network, then BLE can be used to command your device's Wi-Fi chipset to scan and connect to the desired network without the user ever leaving your mobile app. This achieves a streamlined user experience - one that, ideally, makes your users not have to worry about how the wireless magic actually happens.

---

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

---