Communication for IoT or Embedded applications

There is really a lot of talk about IoT and how many billion dollars it will be worth in the future. However, unless we solve actual problems that we face, that might be a dream that will only connect a bunch of toys to the internet without much information for our use. One of those problems is connectivity.

Communication Options

Most examples available online from hardware manufacturers, for development kits, and from cloud service providers will only describe the connection to the internet via ethernet. If they do not show ethernet, the application is most likely a Bluetooth Smart client app that does not connect directly to the internet but via a host like a mobile phone. Using a mobile phone is not always the best option unless it is a wearable device. There are many of those nowadays. You also cannot use ethernet everywhere you want. Your piece of hardware is grounded.

Mobile communication towers, on the other hand, can be used within certain radii. This makes them the most ideal for IoT applications that are mobile or need not be noticed (ethernet cables expose your spying camera). We have been using them all too much on our mobile phones for over the past 10 years. Can you imagine, if your phone needed an ethernet cable?

Most people have already solved this and have added the communication modules for GSM or CDMA. Most applications have used SMS features and not data features. In those that use the data features (mostly GPRS and EDGE), they leverage the already built-in TCP/IP stacks which normally have support even for SMTP, FTP, UDP, HTTP, etc. Others can check mail auto-magically.

You could use the modules support for HTTP but I found that quite unreliable. Why so? I have to implement error checking, fallbacks, and some resilience when using UART/Serial communication with a module. Some things will work if you call them twice, others once and others just fail. This happens in initialization and worsens when you get to using the inbuilt stacks.

What do I recommend?

There are a number of TCP/IP communication stacks available. Some free, others with a huge (or manageable) price tag. I recommend leveraging these stacks to connect to the internet using PPP (Point to Point Protocol) or SLIP (Serial Line Interface Protocol). For PPP see here and here. For SLIP see here and here. Once how you connect to the internet is out of the way, you can then concentrate on the communication protocols details and security.

Security

The reality with IoT as it stands is that security will be paramount. If there is no security then your systems will be hacked on day 1 of getting popular. You need to communicate securely. Of course, there is a module that supports SSL allowing you to make HTTPS requests. However, I have found it very important to have the cryptography abilities strongly baked into your application. It would allow you to add extra encryption to the parts of the data that are being transmitted. Sometimes, this is very necessary.

Sample Scenario

Just when do you need extra encryption? Consider this scenario. Your company maintains a wind power station. As part of your policy, you only give access to certain persons to access the control of the turbines. The turbines are located in the hills and your IT office is in the city. It has been decided, fingerprint identification should be used to restrict the persons who access the controls. Let us presume the persons who have been granted access are changing but you cannot go up the hills to update the fingerprint data. You need the means to update the fingerprint database. Unlike passwords, someone’s fingerprint information cannot be changed. Securing them is very important.

First, you employ SSL for communication. Secondly, you encrypt the fingerprint data with a totally different set of keys or passwords. It may increase the amount of data being sent but it will increase your security. If the SSL communication is compromised, the fingerprint data should remain secure. Remember, there is no such thing as too much security in IT.

Let’s get back to security, shall we?

If you are lucky to get a GPRS module with SSL communication, then you are lucky. Until the day you want to update to the latest version of the stack. Like I alluded to earlier, security is something that needs to be constantly improved. The open-source security libraries are constantly updated as bugs and exploits are discovered. Wikipedia shows here the latest version of the common libraries. Notice the date of the last update. As of this writing, the oldest was 4 months ago.

So what do I recommend?

Try your best to incorporate the encryption libraries/source together with SSL/TLS support into your application code. It may increase compile time, code size and RAM used and it is not for the faint of heart but the results will be worthwhile. Please do not attempt to write your own encryption stack especially, if you are starting out. You will need years of work to get to the level of reliability required. It is better to concentrate on your application functionality.

Conclusion

I am not the best writer, tutor, security expert, etc. but I have a number of posts that explain my approach to solving communication and security. I concentrate on applications that use ARM Cortex M3 microcontrollers which are low on RAM and internal storage. Mainly I use STM32F407 or LPC4337. Occasionally, I use LPC1343 or LPC1347.

The series of blog posts are:

1. SIM900 Dialup Connection Setup
2. SIM900 PPP Driver for KEIL Network-DS
3. Communication protocols for embedded application
4. MQTT with LPC4337 and Keil MDK
5. Add encryption and SSL/TLS into your IoT project
6. Getting mbedTLS to work with your Keil project
7. Proper configuration of mbedTLS for IoT project
8. Use MQTT with mbedTLS in Keil uVision 5 (MDK)
9. Use Azure IoT Hub without client libraries (MQTT)
10. Does the mobile carrier matter in your IoT project?

The Github repository iot-tutorial-communication will contain all the code in the repository.