Architectures in the IoT Civilization

IoT Architecture Basics

So what are we looking for in an “end-to-end” or complete IoT architecture anyway? Here are some important requirements [1] [2] :

• Concurrent Data Collection – support for collection, analysis and control from a large number of sensors or actuators
• Efficient Data Handling – minimize raw data and maximize actionable information
• Connectivity and Communications – provide network connectivity and flexible, robust protocols support between sensors/actuators and the cloud
• Scalable – scale individual elements in the system using the same architecture
• Security – end to end encryption and monitoring
• Availability and Quality of Service – minimal latencies and fault tolerant
• Modular, Flexible and Platform-independent – each layer should allow for features, hardware or cloud infrastructure to be sourced from different suppliers
• Open Standards and Interoperable – communication between the layers should be based on open standards to ensure interoperability
• Device Management – enable automated/remote device management and updates
• Defined APIs – each layer should have defined APIs that allow for easy integration with existing applications and integration with other IoT solutions

Common Architectures:

While we can’t cover all of the possibilities and permutations, the following group of architectures should give you a greater understanding of the core design considerations and typical primary functional layers in an end-to-end IoT stack.

Three Layer (Tier) IoT Architecture

While there are myriad bits that build a complete end-to-end IoT architecture, this architecture simplifies it down to three fundamental building blocks [3] :

1. Perception layer – Sensors, actuators and edge devices that interact with the environment
2. Network Layer – Discovers, connects and translates devices over a network and in coordination with the application layer
3. Application Layer – Data processing and storage with specialized services and functionality for users

Devices make up a physical or perceptual IoT layer and typically include sensors, actuators and other smart devices. One might call these the “Things” in the Internet of Things. Devices, in turn, interface and communicate to the cloud via wire or localized Radio Frequency (RF) networks. This is typically done through gateways. Oftentimes IoT devices are said to be at the “edge” of the IoT network and are referred to as “edge nodes”. When selecting a device, it is important to consider requirements for specific I/O protocols and potential latency, wired or RF interfaces, power, ruggedness and the device’s overall sensitivity. It is critical to determine how much device flexibility your architecture should have.

Many newer devices are IoT ready right out of the box (e.g. are sold with low power bluetooth or are Ethernet enabled). However, most sensors, actuators and legacy devices still interface via conventional “pre-IoT” methods such as analog or serial connections. It is common practice to connect one or more of these conventional devices to microcontrollers, systems on modules (SOMs) or single-board computers (SBCs) with the necessary peripherals (e.g. Arduino, NetBurner, or Raspberry Pi). At a minimum, such collectors provide network connectivity between the edge nodes and a master gateway. In some instances they may be capable of being configured as a gateway as well.

IoT Gateways are an important middleman element that serves as the messenger and translator between the cloud and clusters of smart devices. They are physical devices or software programs that typically run from the field in close proximity to the edge sensors and other devices. Large IoT systems might use a multitude of gateways to serve high volumes of edge nodes. They can provide a range of functionality, but most importantly they normalize, connect and transfer data between the physical device layer and the cloud. In fact, all data moving between the cloud and the physical device layer goes through a gateway. IoT gateways are sometimes called “intelligent gateways” or “control tiers”. [4]

Today, gateways also support additional computing and peripheral functionality such as telemetry, multiple protocol translation, artificial intelligence, pre-processing and filtering massive raw sensor data sets, provisioning and device management. It is becoming common practice to implement data encryption and security monitoring on the intelligent gateway so as to prevent malicious man-in-the-middle attacks against otherwise vulnerable IoT systems. NetBurner devices can be used as robust IoT Gateways, as well as IoT Device Collectors, as mentioned above.

Certain gateways offer an operating system that is specialized for use in embedded and IoT systems along with optimized low-level support for different hardware interfaces, such as NetBurner’s SOMs with our custom Real Time Operating System (RTOS) and interface libraries. Managing memory, I/O, timing and interface is not a trivial task. According to Google Cloud, “Generally these abstractions are not easy to use directly, and frequently the OS does not provide abstractions for the wide range of sensor and actuator modules you might encounter in building IoT solutions.”[5] Libraries are typically available based on standard protocols. Oftentimes, the most optimized libraries will be part of commercially available development kits and SDKs (as is the case with NetBurner for a multitude of protocols and hardware types).

The Cloud is the application layer. It communicates with the gateway, typically over wired or cellular internet. The “Cloud” might be anything from services like AWS or Google Cloud, server farms, or even a company’s on-premises remote server. It provides powerful servers and databases that enable robust IoT applications and integrate services such as data storage, big data processing, filtering, analytics, 3rd party APIs, business logic, alerts, monitoring and user interfaces. In a Three Layer IoT Architecture, the “Cloud” is also used to control, configure, and trigger events at the gateway, and ultimately the edge devices.

Five Layer (Tier) IoT Architecture

The Five Layer IoT Architecture essentially builds upon the three layer approach (see figure above). This is still primarily a cloud-centric IoT architecture, where almost all of the IoT data processing is done on the cloud or a remote server. The difference between the Five Layer IoT Architecture and the Three Layer IoT Architecture are the addition of the following:

• A Business Layer
• A Processing Layer

The top-level Business Layer highlights the various management, business logic, and top-level requirements that need to be coordinated for a sustainable and successful architecture that is able to provide consistent value to the business and end users. It also reinforces the idea that IoT applications may be just a part of an organization’s portfolio of interconnected technology and business areas.

The use of a Processing Layer unveils an important element of many IoT systems which need to incorporate numerous layers of processing in their architecture; oftentimes to filter down massive data sets and thus conserve resources. Using the processing layer at more than one point within in a specific architecture may be required for particular systems.

Fog Computing IoT Architecture

Fog computing is a newer convention that moves certain IoT services, like monitoring and pre-processing, closer to the edge to enable faster local decision making and automation. The Fog Layer resides between the Physical Layer (sensors and devices) and Transportation Layer (gateway) in what might be called the local network for that IoT cluster. In Fog architectures, computational and storage resources are typically provided by what is called a “Smart IoT Gateway” or “Fog Node”, which can also be laterally networked to other fog nodes.

According to NIST’s 2018 Fog Computing Definition Draft, “Fog nodes may be either physical or virtual elements and are tightly coupled with the smart end-devices or access networks. Fog nodes typically provide some form of data management and communication service between the peripheral layer where smart end-devices reside and the Cloud. Fog nodes, especially virtual ones, also referred as cloudlets, can be federated to provide horizontal expansion of the functionality over disperse geolocations.” [6]

Fog architectures can have many benefits. By pre-processing sensor data, they can reduce bandwidth requirements between the gateway and the cloud while reducing the resource consumption on the cloud. They also can lead to significantly improved real-time performance. Using the Fog Architecture makes a lot of sense for use cases where the above reasons hold value. It is sort of like refining a raw material closer to the source and only transporting the refined product to market. Fog nodes may even be configured to communicate directly with other fog nodes to create a mesh that can bypass the cloud completely.

Fog computing architectures attempt to address requirements surrounding real-time performance, security and efficiency. The figure below illustrates the added layers entailed with the Fog Architecture. [7] You can see how four new layers sit on the margin between the Physical and Transport Layers and the value that these new layers can provide. That said, this also increases the complexity of the architecture, and the new layers introduce additional steps and data conversions which can lead to more points of failure.

Table: A Fog Computing Architecture

Edge Computing Architecture

Edge computing is closely related to fog computing, where the goal is to keep certain processing capabilities and functionality closer to the edge nodes. It can be particularly useful in reducing sense and respond latencies for applications that require real-time performance. In edge computing, processing takes place at the physical perception layer directly on a smart device or on an IoT device collector as discussed earlier in this article. It can work independently or in any combination with fog and cloud computing. [8]

If the edge node’s processing unit were powerful enough, we could even extend layers for transport, security, storage, pre-processing, and monitoring, thereby reducing the work and functionality required between it and the cloud. According to info.opto22.com, “Edge computing saves time and money by streamlining IoT communication, reducing system and network architecture complexity, and decreasing the number of potential failure points in an IoT application. “[9] Conversely, there are many reasons why having too much computing at the edge can be inefficient and overkill.

In this modality, edge computing provides similar benefits as fog computing but with an even greater capability to reduce localized latencies. Edge computing potentially allows for decentralization of computing, even greater data privacy, and allows for mesh networking off of the cloud. We go into more detail on edge computing in our piece called, “Computing from the Edge.”  Whether or not the benefits of this architecture outweigh its potential cons will depend on the specific requirements of the system and applications in question.

Hybrid Cloud-Fog-Edge Architecture

As hinted to earlier, fog and edge architectures can be hybridized with cloud-centric IoT architectures if deemed to be a good fit for a project’s requirements and business objectives. The below diagram portrays one combination which uses a nested configuration.

Mist Computing Architecture

Mist! Really?! Without being too judgmental about the naming trend going on here, let’s just touch on this fairly young IoT topology. Mist is an optional layer and a subclass of fog computing. Inspired by the proliferation of IoT and introduction of IoT social applications (e.g. crowd sensing) the Mist Computing Architecture attempts to optimize for scalable, cost-efficient platforms, distributed data analytics, allocation and provisioning of limited resources, and reduced response times.[10]

A Mist Layer sits on the verge between the edge domain and the fog domain, and it supports the sharing of real-time situational awareness of the environment across nodes within the same local network via mesh connectivity. Mist also supports lightweight computing residing on the edge network fabric itself. Through decentralization of computing power, mist can also help reduce the load on fog node gateways, offer a low cost processing solution, enable localized, autonomous decision making and AI, and provide real-time responses and fault tolerance. [11]

According to a 2017 paper by M.K. Yogi et al:

There are notable differences between edge computing a{n}d mist computing. In edge computing, functionality is fixed, data processing occurs at the edge of the network, application configuration is fixed, whereas in mist computing, there are functionalities, timings which are dynamic and adjustable, there are high level application specific rules, new applications can e assembled from existing devices at runtime. For example, when we install a movement sensor the that movement it provides a service of movement detection, so this service can be used by any device which is then connected to that network. It can be used by a light sensor to turn the light on when there is movement or it can be used by an alarm system to provide an alarm if there should not e anyone in that area at that time. Performing all these operations using a 8-bit microcontroller and communication channel with provision for a packet of 100 bytes is much more difficult. [12]

SSRG International Journal of Computer Science and Engineering (SSRG-IJCSE) – volume 4 Issue 7 – July 2017 , page 19-20

Mist’s dynamic device-to-device routing technology lays on top of other complimentary IoT architectures. Furthermore, in mist any node should be able to connect to any gateway, thus eliminating a potential set of dependencies. For example, in a large-scale network, gateway failures can force the addition of a new gateway. Nodes near that gateway should have the ability to dynamically connect  and establish a new route between themselves and the alternate gateway. In this way mist supports IoT system maintainability and scalability.

There’s more food for thought in this still expanding IoT universe. Currently, the company Thinnect is a leader in this exciting field.

Some others IoT architectures if we only had time!

• SDN-Based Architecture
• Quality of Service (QoS) Based Architecture
• Service Oriented Architecture
• Mobility First Architecture
• CloudThings Architecture
• IoT-A Architecture
• S-IoT (Social IoT) Architecture

And end without an end

You can see that there are many models and options when it comes to IoT architectures. There clearly is no one convention to follow, but we hope that you are now able to better identify the areas for serious consideration as you plan your IoT projects. In our next post on the topic, we’ll go deeper into the IoT stack and IoT protocols, and discuss how they can compliment certain architectures and applications. Until then we look forward to your comments!