Direct Device Connections in IoT

Overview

Strictly defined, the Internet of Things (IoT) refers to embedded devices that communicate over a network using the Internet Protocol. In this article, IoT solutions and architectures refer to the network infrastructure, topology, or technologies that enable embedded devices to connect to the IoT.

As with all embedded design, adding IoT connectivity should be chosen to meet specific application requirements. Different applications face different challenges, so multiple architectures have been proposed, created, and deployed. Below I briefly describe and compare three IoT architectures used by developers working with FreeRTOS: traditional "web server devices," "virtual cloud devices," and "peer-to-peer" direct-to-device configurations. These are three among many possible architectures, including hybrids of these approaches.

For readers familiar with the common web-and-cloud IoT approach, the term peer-to-peer (P2P) here describes an architecture that establishes two-way command and data connections directly to deployed IoT devices, hence "direct-to-device." Nabto is an example of a P2P architecture. Nabto uses FreeRTOS to provide a common runtime across embedded platforms to take advantage of low-power, tickless operation.

Use Cases

Broadly speaking, there are three main categories of IoT use cases:

• Data monitoring and collection. Examples include a transport company tracking truck locations nationwide, a manufacturer monitoring the number of parts produced, an insurer recording driving behavior, or a maintenance team monitoring deployed equipment performance to predict failures.
• Providing control interfaces. Examples include remotely opening or closing a farm feed dispenser, changing pump speed in a drainage system, switching parts on a production line, or opening or closing a window. Control can be driven programmatically by a central supervisory system or manually by a user.
• Providing graphical user interfaces (GUIs). For the use cases above, a GUI gives users an interface to IoT devices. GUIs often present different screens to different user categories; for example, remote maintenance technicians may access screens and data that local operators cannot.

Challenges

Different use cases bring different challenges, so different IoT architectures serve different needs. Use cases may require that IoT nodes can:

• be identified and located, optionally named, and assigned an IP address
• be accessible when deployed behind a customer's network firewall
• operate without Internet access, especially during device debugging
• be used from different geographic regions, which may require internationalization (language, currency, units)
• be accessed only by authenticated users, or only send their data to authenticated servers
• ensure data transmitted over the Internet is encrypted
• ensure stored data and databases are secure and private (who owns the data?)
• ensure integrity of all exchanged data and commands
• dynamically change what data is collected, the rate of collection, or the destination for collected data
• dynamically change the number of connections or data flows
• be easy to integrate and use
• be cost-effective

Architecture 1: Web Devices

Here, "web devices" refers to traditional embedded TCP/IP web servers. This approach has been used for many years and has valid use cases. It was popular when IoT was envisioned as a home automation gateway coordinating many smaller devices. Key advantages include:

• It uses familiar technologies.
• It can be fully standalone and not dependent on cloud services.
• Server-side scripts such as CGI can provide powerful control interfaces.
• Including a simple FTP or TFTP server allows updating web pages and scripts after deployment, though each deployed device must be connected and updated individually.

However, revisiting the IoT challenges shows web devices only suit a subset of use cases. Important drawbacks include:

• Embedded firmware requires many interface layers, increasing complexity. Examples include TCP/IP, an HTTP parser, CGI script execution, template generation, and a filesystem.
• Even a simple web interface requires significant HTML logic, consuming CPU time, memory, and bandwidth.
• Deploying web devices on typical networks with DHCP and firewalls may require router configuration to make devices accessible.
• Accessing web devices from outside a firewall often requires VPN, port forwarding, dynamic DNS, or a combination of those techniques, which can be complicated for everyday users.

Architecture 2: Virtual Cloud Devices

Virtual cloud devices typically include minimal firmware: an IP stack and rules to push data to a predetermined cloud server. Users interact with the cloud server rather than the device itself, hence "virtual."

Virtual cloud devices overcome some challenges that standard web devices cannot. Notable advantages include:

• Reduced resource requirements, lowering cost and power consumption.
• Interfaces live in the cloud and can be updated centrally to respond to new UI needs.
• Internationalization can be handled on the server side.
• They are effective for continuous data recording for later offline analysis.

They still only address a subset of challenges. Important limitations include:

• They are suited to applications that only need devices to push data, not receive commands.
• They are inherently inflexible: what data to push, the frequency, and the destinations are typically fixed at firmware compile time. This can lead to bandwidth waste, since data volume and frequency must account for worst-case needs.
• They depend on Internet connectivity.
• Average data age is roughly half the push interval.
• Privacy concerns arise when data is stored on third-party servers.

Architecture 3: Direct Peer-to-Peer Devices

Unlike virtual cloud devices that communicate only with cloud servers, Nabto-enabled devices use cloud servers for only two purposes; all other communication is direct between the deployed IoT device and clients.

Nabto devices use cloud servers to:

• mediate and establish connections so each IoT device has a resolvable URL, for example serialnumber.myDomain.net, rather than a predetermined IP address
• establish connections using UDP hole punching, a technique used by VoIP services. The connection setup is hidden from users, presenting a simple click-to-call style interface while handling firewall traversal transparently.

With FreeRTOS plus Nabto, you can connect to a remote IoT device regardless of its network location, even if it is behind a firewall, by knowing the device URL and authenticating as a valid user. The connection setup is hidden from software integrators, who typically need only call a C function, and end users need only know the device URL. Nabto uses standard Internet naming and DNS.

P2P devices also allow rich web-based user interfaces without requiring the IoT device to host a filesystem or a full TCP/IP stack. The device can implement a small runtime of around 10 KB of code and a few kilobytes of RAM. This is achieved by shifting storage and web content handling to powerful cloud servers while the device uses a low-bandwidth protocol for real-time data and commands. Network content is cached in the web browser, tablet, or smartphone application, allowing access to the device user interface even when the Internet connection is unavailable.

Reviewing the IoT challenge list shows this P2P architecture provides solutions for the listed challenges. From a device designer's perspective, it is one of the easier-to-integrate approaches, and from an end user's perspective, the ability to change data collection decisions after deployment makes it flexible. Built-in encryption and authentication allow users to control data storage and privacy.