Direct-to-device connectivity in the Internet of Things -

Direct-to-device connectivity in the Internet of Things


Although the term is often applied loosely, “Internet of Things” (IoT), strictly defined, refers to embedded devices that communicate over or are accessible over a network via the Internet.Protocol. In this article IoT ‘solutions’ and IoT ‘architectures’ refer to networking infrastructure, topologies, or technologies that enable embedded devices to connect to the Internet of Things.

As with all embedded designs, adding IoT connectivity should be chosen to meet specific application requirements. Not all applications pose the same challenges, so different architectures have been proposed, created, and deployed. In this article I will briefly describe then discuss three contrasting IoT architectures in which FreeRTOS has been used by developers. The three architectures are a traditional ‘web server device’, a ‘virtual cloud device’, and a “peer to peer” direct-to-device configuration. These are just three architectures of many that could have been chosen (including some that are hybrids of these three).

For those more familiar with the traditional approaches to IoT connectivity using web and cloud devices, the term peer to peer (P2P) is used here to describe an architecture that creates a two way command and data connection directly with the deployed IoT device, hence the term ‘Direct to Device’. Nabto is an example of a peer to peer architecture. Nabto uses FreeRTOS to provide a common run time environment across all embedded platforms to take advantage of its low power, tickless operation.)

Use Cases
Very broadly speaking, there are three base IoT use case categories:

Data monitoring and acquisition. Examples of this type of use would include a haulage firm monitoring the positions of its trucks as the trucks move around the country, a production company monitoring the number of parts made, a vehicle insurance company logging the driving habits of its customers, or a maintenance company monitoring performance attributes of deployed equipment in order to predict potential failures before they occur.

The provision of a control interface. Examples of this type of use would include the ability to remotely open or close animal feed troughs on a farm, remotely vary the speed of a pump in a drainage system, remotely switch the part being produced by a production line, or simply to open or close a window. Control interfaces can be driven programmatically by a centralized supervisory and control computer system, or manually by users.

The provision of a graphical user interface (GUI). A GUI provides an interface for users using an IoT device for use case 1 or 2 above. Often a GUI is required to display different screens to different categories of user. For example, remote maintenance technicians (or even accountants) might have access to screens and data that are inaccessible to local operators.

Different use cases bring with them different challenges, and are therefore best serviced by differing IoT architectures. A use case may need to ensure that nodes on the IoT can:

  • Be uniquely identified and located, potentially named, and allocated an IP address
  • Be accessed when deployed behind a customer’s network firewall
  • Operate in the absence of the Internet, particularly during equipment commissioning
  • Be used from different geographic regions, which may require language, currency, or measurement unit conversions (internationalization)
  • Only be accessed by authenticated users, or only send their data to authenticated servers
  • Ensure data passing across the Internet is securely encrypted
  • Ensure data stores and databases are secure and private (who owns the data?)
  • Ensure the integrity of all exchanged data and commands
  • Dynamically change the data that is being acquired, the rate at which the data is being acquired, or where acquired data is being sent
  • Dynamically change the number of connections or data flows
  • Be integrated easily, and used easily
  • Be cost effective

Architecture 1: Web devices
In this article the term web device refers to a traditional embedded TCP/IP web server, as shown in Figure 1 .

Figure 1: Architecture of a web device

This approach has been used for years, and for good reasons. The Web Device approach was especially in focus at the time when IoT was envisioned to be a home-automation-gateway that coordinated a lot of smaller devices inside the home. Its major advantages include:

  • It uses familiar technologies
  • It is completely self-contained, with no reliance on a cloud service
  • CGI (and other server side) scripts can provide a very powerful control interface

The inclusion of a simple FTP or TFTP server will allow the web pages and scripts to be updated after deployment (but note that each deployed device must be connected to then updated individually). However, despite these points in its favor, a quick re-read of the IoT challenges stated above shows the traditional web device is only suited to a small subset of potential use cases. It would take too long to go through each point in turn, but the following points are worth highlighting:

  • The embedded firmware has a lot of interface layers and is therefore complex. Examples of the layers that must be provided include TCP/IP, HTTP parser, CGI script execution, template generation, and file systems.
  • Even quite simple web interfaces require a lot of HTML logic, and hence computing time, memory resources, and high bandwidth.
  • Deploying a web device on a standard network that includes a DHCP server (dynamic assignment of IP addresses) and a firewall can require specific rules to be set up in the end user’s router in order to make the web device accessible.
  • Reaching the web device from outside of a firewall requires a VPN, port-forwarding, dynamic DNS, or a combination of such technologies. These are complex technologies for everyday users.

Architecture 2: Virtual cloud devices
Virtual cloud devicesnormally have a small amount of firmware that includes an IP stack andrules for pushing data to a pre-determined cloud server. Userscommunicate with the cloud server rather than the IoT devicesthemselves, hence the ‘virtual’ terminology.

Figure 2: Architecture of a virtual cloud device

Reviewingthe list of IoT challenges once again shows virtual cloud devices areable to overcome challenges that standard web devices cannot. Here aresome noteworthy advantages of virtual cloud devices:

  • Their sparse resource requirements help reduce both cost and power consumption.
  • The presented interface resides in the easily accessible cloud, making it easy to respond to new interface demands by adjusting only the single centralized server.
  • Internationalization can be implemented in the server.
  • It is an efficient solution for applications that require the continuous logging of data for future offline analysis (so called ‘big data’ collection).

Once again, however, only a subset ofchallenges are overcome, although conveniently a different subset tothose overcome by the standard web device. The following points are alsoworth highlighting:

  • Virtual cloud devices are best suited to applications that only require data to be pushed from, rather than to, the IoT device.
  • It is inherently inflexible. Decisions on which data to push, how often to push the data, and where to push the data are made when the firmware is compiled. This inflexibility can also result in bandwidth wastage as the quantity and frequency of data is fixed and must account for the worst case.
  • There is an inherent reliance on an internet connection.
  • The data is out of date by an average of half the push-interval.
  • Privacy may be a concern if the data is stored on somebody else’s server.

Architecture 3: Direct peer-to-peer devices
Unlikevirtual cloud devices that communicate only with the cloud server,Nabto-enabled devices only use the cloud server for the two reasonsstated below – all other communication is performed directly with thedeployed IoT device itself.

Figure 3: Peer to peer connection options

Nabto devices use a cloud server to:

  • Mediate and establish a connection directly with IoT devices, each of which has a resolvable unique URL, such as, rather than a pre-determined IP address.
  • Connections are established using ‘UDP hole punching’, which is a technique used by Voice over IP (VoIP) services such as Skype. If you are familiar with using Skype you will know you can connect a call to a person wherever that person is at the time of the call (even when they are behind a firewall), simply by knowing the Skype ID of that person, and having the agreement of the person that the connection can be made. The technology used to establish the call is hidden from the user, leaving the user with a simple click-and-talk user interface.
  • Using FreeRTOS+Nabto you can connect to a remote IoT device wherever that device is at the time of the connection (even when it is behind a firewall), simply by knowing the device's unique URL, and being securely authenticated as a legitimate user. Again, the technology used to establish the connection is hidden from both the software integration engineer, who must provide only a single C function, and the end user, who need only know the IoT device’s URL. Unlike Skype, Nabto uses the normal internet naming scheme and DNS system.
  • Allow tiny IoT devices to be accessed through a rich web-based user interface without the IoT device requiring either a file system or a full TCP/IP stack. The IoT device need only provide approximately 10K bytes of code space and a few K bytes of RAM. This is achieved by seamlessly (to the user) moving the burden of storing and processing web content to the large and powerful cloud server, leaving the IoT device to provide live data and receive commands using a low bandwidth protocol. Further, the Web content is cached in the web browser, tablet or smartphone app used to view the user interface, allowing devices to be accessed even in the absence of an Internet connection.
Figure 4: Using Nabto to create a rich user interface to a small IoT device

Reviewingthe list of IoT challenges for one last time shows that this type ofpeer-to-peer architecture provides a solution for each listedchallenge. Conveniently, from the IoT device designers’ perspective, itis also one of the simplest to integrate, and from the end users’perspective, the ability to change data acquisition decisions afterdeployment makes it one of the most flexible. Encryption andauthentication are built in, and users have complete control over datastorage and privacy.

At we were so impressed by the peer-to-peer approach to implementing IoTconnectivity in embedded designs that we now use Nabto’s versatile yetlight-weight and simple implementation in our fully managed cloudhosting offering called FreeRTOS+Nabto, which is part of the FreeRTOS+ecosystem.

Richard Barry graduated with 1st Class Honorsin Computing for Real Time Systems from the University of the West ofEngland. He's been directly involved in the startup of severalcompanies, primarily working in the industrial automation and aerospaceand simulation markets. Barry is currently a director of Real TimeEngineers Ltd., owners, developers and maintainers of the FreeRTOS real time kernel   and Head of Innovation at WITTENSTEIN High Integrity Systems.

1 thought on “Direct-to-device connectivity in the Internet of Things

  1. “For a bootstrapping hardware startup with a small customer base, Nabto seems cost-prohibitive. Is there an open-source, device-to-device option? Once which does not require a cloud server? Thx!”

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.