Architectural Features of IoT Cloud Platforms

IoT platforms are an essential part of IoT solutions today. They help accelerate the development of IoT applications and also ensure the requisite level of security, remote management, and integration capabilities in your solution.

There are several established platform providers in the market today such as – AWS IoT, ThingWorx, Azure IoT, Xively et. al. Many of these platforms share common features and architectural patterns.

In this post, we explore the architectural components and essential patterns to be considered in your IoT solutions.

We also share our wishlist of desired features for IoT Cloud Platforms. Such a wishlist is quite useful when trying to evaluate and choose a platform for a specific IoT solution.

Device Connectivity and Protocol Support

IoT devices support a variety of protocols, so any mature IoT platform should include support for multiple protocols such as: MQTT, AMQP, CoAP, STOMP, WebSockets, XMPP etc.

A component within an IoT platform which handles (terminates) these protocols is often called as the Cloud Gateway. Such gateways need to be highly scalability with an ability to process millions of messages each day.

Most IoT protocols use a message-centric, asynchronous communication model instead of the traditional Request-Response model of Web Applications. Hence, IoT platforms often include a scalable message bus infrastructure that is responsible for routing messages between devices and application services. Messages are delivered to one or more recipients using a pub-sub delivery model.

Device connectivity is often divided into two logical channels – control and data. The QoS levels and the exact protocols used for each logical channel may vary depending on specific application needs.

  • A Control Channel: To deliver device commands, health status, updates etc.
  • A Data Channel: To carry actual telemetry data, sampling values, from devices to the platform.

Unified Device Management Capabilities

Device management is a must-have feature for any IoT platform today. This includes capabilities enumerated below. Such capabilities are typically exposed as an admin dashboard with can be used by IoT Ops personnel.

  • Device Inventory: Tracking inventory of devices (things).
  • Device Health: Capturing heartbeat and health status of devices.
  • Remote Configuration Management: Remote management of device configuration using two-way sync capabilities.
  • Remote Device Management: Remote management of the device state – wipe, lock, activate.
  • Device Firmware Upgrades: Over-the-air firmware upgrades with canary releases.
  • Remote Logging: Remote access to device logs and capturing error reports from devices.

Security Features

Nearly all CIOs rate ‘security’ to be a paramount concern for IoT applications today. Any IoT Platform hence needs to offer robust security features out-of-the-box. These include:

  • Device Identity: Establish a secure device identity using client certificates or other cryptographic means.
  • Device Enrollment: Securely enroll and authorize IoT devices to the platform.
  • Device Policy: Fine-grained authorization control to restrict device traffic coming into the IoT platform. Restrict what devices can publish, and what they can subscribe to.
  • Secure Communication Channels: Provide secure tunnels for communication between devices and the platform (TLS / SSL / IPSec / Private Networks etc).
  • Secure Firmware Delivery: Deliver signed software updates and checksum verifications during firmware upgrades.

Telemetry Analytics

This includes the ability to capture data streams from devices in real-time and performing analytics to drive business decision making.

Analytics can be offered in four flavors:

  • Real-time analytics,
  • Batch analytics,
  • Predictive analytics using machine learning and,
  • Interactive Analytics.

The underlying analytics platform should be ready for scale, with an ability to handle millions (or even billions) of telemetry messages each day.

Support for Business Rules

This component provides ‘extensibility’ to an IoT Platform. This is where business logic (specific to your IoT application) gets codified.

It includes a business rules engine which can be customized to your business requirements, and it also includes a micro-services stack where custom code (business logic, lambda functions etc.) can be deployed by the application developer.

The rules engine often forms an important part of the ‘control loop’ for IoT applications. For example: If the temperature of a furnace exceed a certain threshold, a specific business rule triggers, and this may send a ‘cut-off’ command to the electric furnace.

Rules engines provide a DSL (Domain Specific Language) to express business rules. A common pattern to express rules is also the IFFT (If-This-Then-That). Alternately, you can codify your business logic in a programming language of your choice and deploy it as micro services.

Rules engines and micro services hook into the message bus so that they are able to receive real-time telemetry data and dispatch commands to devices.

Integration Capabilities

Most enterprise systems offer standard protocols such as REST, SOAP, and HTTPS to facilitate integration with other systems. Enterprise cloud platforms also offer capabilities such as Big Data Stores, Large File Stores, Notification Services etc.

To build a complete IoT solution, devices need to integrate with legacy enterprise solutions and enterprise cloud applications. IoT platforms hence need to provide connectors to such enterprise and cloud services. These connectors would be invoked by the business rules or by the micro services running on the IoT platform.

Wrapping Up…

The rapid growth of IoT paradigms today has made it necessary to accelerate ‘goto market’ timelines for IoT solution providers. Leveraging an IoT platform is a great way to achieve this goal.

IoT platforms provide cross-cutting concerns such as connectivity, security, management, and analytics so that solution developers do not reinvent the wheel. It is critical for you to evaluate your chosen IoT platform against these set of features before you embark on your journey. Now go build something awesome!


Protocol Design Challenges in M2M Communication

Connecting smart IoT appliances requires a robust and lightweight protocol that facilitates an efficient Machine-to-Machine (M2M) communication. In this post, we explore some of the interesting challenges in the design of protocols for M2M communication needs.

Low Bandwidth

IoT devices deployed in the field are often connected using networks that have low-bandwidth or offer inconsistent throughput. Hence, the protocol overheads need to be very low – such as having small protocol headers, using variable length headers etc.

For example: Field devices are often connected using 2G / 3G carrier networks that offer low bandwidth.

Two-way Communication:

IoT devices often require a two-way communication channel, whereby communication can be initiated by either parties.

For example: Say, a device needs to send telemetry data to a Backend Application, or the Application wants to dispatch commands to this device. Unlike a traditional HTTP Request-Response model, the communication could be initiated by either of the parties. Polling is an inefficient way of doing this over HTTP.

Intermittent Connectivity

Wide area wireless networks (carrier networks) often experience flaky connectivity. So the underlying protocol needs resilience against connectivity problems. After an abrupt disconnection, when a device comes back online later, any pending messages for this device should be automatically delivered to it.

For example: IoT devices can fade in-and-out of network connectivity as their geo-location changes, or they switch to a ‘hibernation mode’ to conserve power.

Low Compute Footprint

Embedded devices often have low compute capabilities – CPUs with lower energy consumption, lower clock rates, and low memory availability. So the protocol implementation should require a minimal compute and memory overhead on those devices.

One-to-Many Communication Model

Unlike conventional protocols such as HTTP which only allow a 1-to-1 communication, an IoT protocol should allow a one-to-N communication model.

For example: Messages from a temperature sensor could be routed to a telemetry logging service, a temperature control logic, and a monitoring dashboard – all at the same time!

Asynchronous Model

Any party can dispatch messages at will, sometimes even without knowing if the recipient is online at that point in time. As devices fade in-and-out of network connectivity, or hibernate from time to time, it would be inefficient for the senders to keep polling recipients over a HTTP request-response model. Hence, the underlying messaging protocol is expected to be asynchronous in nature

For example: Most IoT devices sense real world events and trigger messages based on the occurrence of those events. Sensors can dispatch this information without really knowing if the intended recipients are online / offline at that point in time.

For example: Applications need to instruct devices by dispatch commands to them. Applications could dispatch commands without knowing if the recipient device is online / offline at that point.

Decoupling of Participants

The protocol needs an appropriate ‘routing mechanism’ whereby a message can be routed to a set of interested recipients, without the sender necessarily knowing who the exact recipients are. The set of recipients for a certain type of message could change as the ecosystem evolves.

For example: A logger device may be interested in temperature information today. Tomorrow, a new dashboard may also be interested to receive this information. The temperature emitter (sensor) may be oblivious to who the recipients actually are.

Routing Complexity

The routing complexity and responsibility should be encapsulated within the IoT Cloud (and not within the devices themselves). The device should be offered a simpler model to connect, dispatch, and to receive messages asynchronously.


This is a paramount concern in IoT today. The protocol should support a strong security model to protect data-in-motion using a robust PKI infrastructure. It needs to offer capabilities such as: Secure endpoint identity (Client certificates), real-time authorization controls, and real-time policy enforcements.

Adoption of Standards

Most embedded OSes and all cloud OSes today support the TCP/IP stack. So a suitable IoT protocol is expected to run on top of the standard TCP/IP stack to ensure highest compatibility across multiple hardware and OS platforms.

Wrapping Up…

M2M communication brings its unique set of challenges – Intermittent connectivity, asynchronous communication needs, and a need to decouple participants. Having an intermediate messaging queue (broker) is a great way to address many of these requirements. Hence IoT protocols such as MQTT adopt a pub-sub, queue-based architecture and are thus better suited for IoT applications today.