Architecture

In a very complex environment such as IoT, a particular outcome can be achieved in many ways.

Different specific devices and technologies can be chosen which perform equivalent functions, and there are essentially no rules on how to write the software that connects them together. Because of this, there is a significant risk that every specific IoT implementation may be slightly different due to the preferences of the designer. The result would be a high degree of incompatibility and a great deal of wasted effort as the same problems are solved over and over again in different ways.

A reference architecture helps to avoid this chaos by providing a broad-brush framework that the designer can follow. The high-level perspective afforded by the reference architecture maps out a set of main system components and their interactions. The designer's job then becomes how to implement the inner workings of each main component while satisfying the communication requirements between them. A reference architecture is very generic, and can be refined further to define a specific architecture for a particular application domain.

The divisions between components in an architectural diagram may be real, conventional or a little of both. For example, it is common practice to divide an architecturalmodel into layers where the lower levels are closer to physicalreality, and the higher levels are more related to the conceptual or logical purpose of the system. This is similar to the well-known 7-layer OSI network model shown in Figure 1.

Figure 1: The OSI 7-layer network model

In the OSI model, the divisions between the layers are essentially conceptual; however, they are made concrete by the use of specific network protocols which implement a certain set of features at each level. Thus a higher-level protocol may encapsulate the structures created by a lower-level protocol. This hierarchical approach means that the divisions between the layers have a physical reality defined by the constraint on a particular protocol.

Architectural diagrams are very commonly used to represent complex enterprise systems. They allow system designers to make certain decisions independently of any particular technology choice. In architectural diagrams, some elements may appear at the same level. This usually indicates that they have a similar level of abstraction, and usually that they have similar communications with lower and higher levels. The purpose of an architectural design is to facilitate interoperability, simplify development and to ease implementation (Weyrich & Ebert, 2016)

Because the IoT is a relatively new and very dynamic concept, many generic architectures have been proposed. They typically include three to five layers and recent articles provide a comparison (Vallois et al., 2019; Weyrich & Ebert, 2016). The model proposed by the International Telecommunications Union (ITU) offers a good compromise between clarity and detail:

Figure 2: The ITU IoT reference architecture (ITU, 2012; Kafle et al., 2016)

The ITU describes these architectural layers and cross-cutting vertical elements as follows:

• Application layer

  The application layer contains IoT applications.

• Service support and application support layer

  • Generic support capabilities: The generic support capabilities are common capabilities which can be used by different IoT applications, such as data processing or data storage. These capabilities may be also invoked by specific support capabilities, e.g., to build other specific support capabilities.

  • Specific support capabilities: The specific support capabilities are particular capabilities which cater for the requirements of diversified applications. In fact, they may consist of various detailed capability groupings, in order to provide different support functions to different IoT applications.

• Network layer

  • Networking capabilities:

    provide relevant control functions of network connectivity, such as access and transport resource control functions, mobility management or authentication, authorization and accounting (AAA).

  • Transport capabilities:

    focus on providing connectivity for the transport of IoT service and application specific data information, as well as the transport of IoT-related control and management information.

• Device layer

  Device layer capabilities can be logically categorized into two kinds of capabilities:

  • Device capabilities:

    Direct interaction with the communication network: Devices are able to gather and upload information directly (i.e., without using gateway capabilities) to the communication network and can directly receive information (e.g., commands) from the communication network.

    Indirect interaction with the communication network: Devices are able to gather and upload information to the communication network indirectly, i.e., through gateway capabilities. On the other side, devices can indirectly receive information (e.g., commands) from the communication network.

    Ad-hoc networking: Devices may be able to construct networks in an ad-hoc manner in some scenarios which need increased scalability and quick deployment.

    Sleeping and waking-up: Device capabilities may support "sleeping" and "waking-up" mechanisms to save energy.

  • Gateway capabilities:

    Multiple interfaces support: At the device layer, the gateway capabilities support devices connected through different kinds of wired or wireless technologies, such as a controller area network (CAN) bus, ZigBee, Bluetooth or Wi-Fi. At the network layer, the gateway capabilities may communicate through various technologies, such as the public switched telephone network (PSTN), second generation or third generation (2G or 3G) networks, long-term evolution networks (LTE), Ethernet or digital subscriber lines (DSL).

    Protocol conversion: There are two situations where gateway capabilities are needed. One situation is when communications at the device layer use different device layer protocols, e.g., ZigBee technology protocols and Bluetooth technology protocols, the other one is when communications involving both the device layer and network layer use different protocols e.g., a ZigBee technology protocol at the device layer and a 3G technology protocol at the network layer.

• Management capabilities

  In a similar way to traditional communication networks, IoT management capabilities cover the traditional fault, configuration, accounting, performance and security (FCAPS) classes, i.e., fault management, configuration management, accounting management, performance management and security management.

  The IoT management capabilities can be categorized into generic management capabilities and specific management capabilities. Essential generic management capabilities in the IoT include:

  • device management, such as remote device activation and de-activation, diagnostics, firmware and/or software updating, device working status management;

  • local network topology management;

  • traffic and congestion management, such as the detection of network overflow conditions and the implementation of resource reservation for time-critical and/or life-critical data flows.

  Specific management capabilities are closely coupled with application-specific requirements, e.g., smart grid power transmission line monitoring requirements.

• Security capabilities

  There are two kinds of security capabilities: generic security capabilities and specific security capabilities. Generic security capabilities are independent of applications. They include:

  • at the application layer: authorization, authentication, application data confidentiality and integrity protection, privacy protection, security audit and anti-virus;

  • at the network layer: authorization, authentication, use data and signalling data confidentiality, and signalling integrity protection;

  • at the device layer: authentication, authorization, device integrity validation, access control, data confidentiality and integrity protection.

  Specific security capabilities are closely coupled with application-specific requirements, e.g., mobile payment, security requirements.

Another more recent model has been proposed by Cisco and contains seven layers as shown in Fig. 3. The Cisco model is popular because its structure is more linear than that of the ITU model. It also explicitly acknowledges the concept of edge or fog computing in which cloud services are extended closer to the edge. This is typically achieved by providing limited processing and storage facilities on a gateway device. While intuitively simple, the representation of fog computing in the Cisco model glosses over the actual location where the processing takes place. For example, a gateway device has connectivity to the edge devices in one direction and also to the cloud services in the other. This suggests that the model should contain two separate connectivity layers. The second layer of the model may be taken to represent connectivity from the physical devices to the gateway (if present) while the onward connection to the cloud is assumed.

Figure 3: The Cisco IoT reference architecture (Cisco, 2014)