Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

A closer look at IoT comms software

Posted: 25 Apr 2014     Print Version  Bookmark and Share

Keywords:Internet of Things  encryption  IoT  HTTP  software 

Designing a communications software stack aimed at the needs of your Internet of Things platform is crucial, not to mention difficult, considering the continually evolving range of options available. Some network topologies are commonly used to link IoT products to the Internet. They all carry protocol requirements in four core areas: security, authentication, message routing and payload.

Broadcasting data in the open is a recipe for disaster. Encrypting traffic and validating at least your server endpoint is a given to protect against this type of situation.

Matt Osminer

Despite recent publicity around the Heartbleed defect in TLS/SSL, SSL still remains the preferred encryption solution because it is an established, supported and highly scrutinized Internet standard. Only extreme circumstances should steer you to a different protocol.

Encryption generally forms the basis for the next requirement, authentication, the act of validating that a device or user is who they say they are. Among the many authentication choices, the simplest approach is to ask a user to enter a printed serial number from his or her device.

Unique SSL certificates programmed at manufacture are a "freebie" with TLS/SSL for at least device authentication. The oAuth standard is a robust choice many websites use. SASL provides a framework for options ranging from basic passwords to more complicated SHA hash methods.

Given the diversity options, you should think through this particular requirement carefully. Most of these methods require some form of user interaction, and that can have an impact on the overall customer experience.

Once an IoT device is authenticated and signed on it will typically begin exchanging messages with a server. Some form of addressing and/or filtering is typically needed.

Your product requirements will largely guide your choice of routing protocols. You might even be able to dispense with this requirement entirely. Two popular standards in this space are MQTT and XMPP.

The last requirement for the communication stack is a protocol for product-specific messages to support your feature set. This is the real Wild West of IoT at present, because few established standards have emerged for controlling specific classes of devices.

Lack of standardisation has opened the door to aggregation solutions such as Revolv that attempt to simplify cross product management. There also are convenient standard message description formats such as XML, JSON and GPB that can ease message exchange with the back office.

Choices here depend on factors such as the CPU and memory limits of your product. Operating and development costs may also be a concern.

If you choose to host your back office on Amazon Web Services or GAE you are paying proportional to resource use. Optimising resources is of great interest if your product is connected 24/7 and frequently communicating.

Hosting service providers strongly encourage the use of established frameworks such as HTTP, REST and HTML. If you choose a standard or protocol that isn't in the mainstream, development effort may be substantially increased.

Finally, you need to consider the presence of firewalls and route-ability. If your IoT device resides behind a firewall it is best to have it establish communication with the Internet back office to circumvent the firewall. Asking consumers to configure their firewalls isn't viable if you want to reach a non-technical consumer base.

Furthermore, not all protocols are routed through the entire Internet. HTTP is the lingua franca of the Internet and is almost universally routed, making it a natural choice. If you choose a different protocol I advise careful consideration of your network topology before proceeding.

Ultimately you will need to evaluate your specific product needs and decide on a communication stack that makes sense for your product. As time progresses I expect more cohesive standards and frameworks will emerge to simplify development.

The following outlines some well-known and supported protocols I recommend from countless options available.

Communication protocols

- Matt Osminer
  EE Times

Comment on "A closer look at IoT comms software"
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top