IoT Architecture,Protocols,Applications

Architecture of IoT

There is no single consensus on architecture for IoT, which is agreed universally. Different architectures have been proposed by different researchers.

Three- and Five-Layer Architectures

Figure 1: Architecture of IoT (A: three layers) (B: five layers).

The most basic architecture is a three-layer architecture [3–5] as shown in Figure 1. It was introduced in the early stages of research in this area. It has three layers, namely, the perception, network, and application layers.(i)The perception layer is the physical layer, which has sensors for sensing and gathering information about the environment. It senses some physical parameters or identifies other smart objects in the environment.(ii)The network layer is responsible for connecting to other smart things, network devices, and servers. Its features are also used for transmitting and processing sensor data.(iii)The application layer is responsible for delivering application specific services to the user. It defines various applications in which the Internet of Things can be deployed, for example, smart homes, smart cities, and smart health.

The three-layer architecture defines the main idea of the Internet of Things, but it is not sufficient for research on IoT because research often focuses on finer aspects of the Internet of Things. That is why, we have many more layered architectures proposed in the literature. One is the five-layer architecture, which additionally includes the processing and business layers [3–6]. The five layers are perception, transport, processing, application, and business layers (see Figure 1). The role of the perception and application layers is the same as the architecture with three layers. We outline the function of the remaining three layers.(i)The transport layer transfers the sensor data from the perception layer to the processing layer and vice versa through networks such as wireless, 3G, LAN, Bluetooth, RFID, and NFC.(ii)The processing layer is also known as the middleware layer. It stores, analyzes, and processes huge amounts of data that comes from the transport layer. It can manage and provide a diverse set of services to the lower layers. It employs many technologies such as databases, cloud computing, and big data processing modules.(iii)The business layer manages the whole IoT system, including applications, business and profit models, and users’ privacy. The business layer is out of the scope of this paper. Hence, we do not discuss it further.

Another architecture proposed by Ning and Wang [7] is inspired by the layers of processing in the human brain. It is inspired by the intelligence and ability of human beings to think, feel, remember, make decisions, and react to the physical environment. It is constituted of three parts. First is the human brain, which is analogous to the processing and data management unit or the data center. Second is the spinal cord, which is analogous to the distributed network of data processing nodes and smart gateways. Third is the network of nerves, which corresponds to the networking components and sensors.

 Cloud and Fog Based Architectures

Let us now discuss two kinds of systems architectures: cloud and fog computing (see the reference architectures in [8]). Note that this classification is different from the classification in Section 2.1, which was done on the basis of protocols.

In particular, we have been slightly vague about the nature of data generated by IoT devices, and the nature of data processing. In some system architectures the data processing is done in a large centralized fashion by cloud computers. Such a cloud centric architecture keeps the cloud at the center, applications above it, and the network of smart things below it [9]. Cloud computing is given primacy because it provides great flexibility and scalability. It offers services such as the core infrastructure, platform, software, and storage. Developers can provide their storage tools, software tools, data mining, and machine learning tools, and visualization tools through the cloud.

Lately, there is a move towards another system architecture, namely, fog computing [10–12], where the sensors and network gateways do a part of the data processing and analytics. A fog architecture [13] presents a layered approach as shown in Figure 2, which inserts monitoring, preprocessing, storage, and security layers between the physical and transport layers. The monitoring layer monitors power, resources, responses, and services. The preprocessing layer performs filtering, processing, and analytics of sensor data. The temporary storage layer provides storage functionalities such as data replication, distribution, and storage. Finally, the security layer performs encryption/decryption and ensures data integrity and privacy. Monitoring and preprocessing are done on the edge of the network before sending data to the cloud.

Often the terms “fog computing” and “edge computing” are used interchangeably. The latter term predates the former and is construed to be more generic. Fog computing originally termed by Cisco refers to smart gateways and smart sensors, whereas edge computing is slightly more penetrative in nature. This paradigm envisions adding smart data preprocessing capabilities to physical devices such as motors, pumps, or lights. The aim is to do as much of preprocessing of data as possible in these devices, which are termed to be at the edge of the network. In terms of the system architecture, the architectural diagram is not appreciably different from Figure 2. As a result, we do not describe edge computing separately.

Finally, the distinction between protocol architectures and system architectures is not very crisp. Often the protocols and the system are codesigned. We shall use the generic 5-layer IoT protocol stack (architectural diagram presented in Figure 2) for both the fog and cloud architectures.

IoT Network Protocol Stack

The Internet Engineering Task Force (IETF) has developed alternative protocols for communication between IoT devices using IP because IP is a flexible and reliable standard . The Internet Protocol for Smart Objects (IPSO) Alliance has published various white papers describing alternative protocols and standards for the layers of the IP stack and an additional adaptation layer, which is used for communication [51–54] between smart objects.

(1) Physical and MAC Layer (IEEE 802.15.4). The IEEE 802.15.4 protocol is designed for enabling communication between compact and inexpensive low power embedded devices that need a long battery life. It defines standards and protocols for the physical and link (MAC) layer of the IP stack. It supports low power communication along with low cost and short range communication. In the case of such resource constrained environments, we need a small frame size, low bandwidth, and low transmit power.

(2) Adaptation Layer. IPv6 is considered the best protocol for communication in the IoT domain because of its scalability and stability. Such bulky IP protocols were initially not thought to be suitable for communication in scenarios with low power wireless links such as IEEE 802.15.4.

6LoWPAN, an acronym for IPv6 over low power wireless personal area networks, is a very popular standard for wireless communication. It enables communication using IPv6 over the IEEE 802.15.4 [52] protocol. This standard defines an adaptation layer between the 802.15.4 link layer and the transport layer. 6LoWPAN devices can communicate with all other IP based devices on the Internet.

(3) Network Layer. The network layer is responsible for routing the packets received from the transport layer. The IETF Routing over Low Power and Lossy Networks (ROLL) working group has developed a routing protocol (RPL) for Low Power and Lossy Networks (LLNs) 

(4) Transport Layer. TCP is not a good option for communication in low power environments as it has a large overhead owing to the fact that it is a connection oriented protocol. Therefore, UDP is preferred because it is a connectionless protocol and has low overhead.

(5) Application Layer. The application layer is responsible for data formatting and presentation. The application layer in the Internet is typically based on HTTP. However, HTTP is not suitable in resource constrained environments because it is fairly verbose in nature and thus incurs a large parsing overhead. Many alternate protocols have been developed for IoT environments such as CoAP (Constrained Application Protocol) and MQTT (Message Queue Telemetry Transport).

 Bluetooth Low Energy (BLE)

Bluetooth Low Energy, also known as “Bluetooth Smart,” was developed by the Bluetooth Special Interest Group. It has a relatively shorter range and consumes lower energy as compared to competing protocols. The BLE protocol stack is similar to the stack used in classic Bluetooth technology. It has two parts: controller and host. The physical and link layer are implemented in the controller. The controller is typically a SOC (System on Chip) with a radio. The functionalities of upper layers are included in the host [62]. BLE is not compatible with classic Bluetooth. Let us look at the differences between classic Bluetooth and BLE [63, 64].

The main difference is that BLE does not support data streaming. Instead, it supports quick transfer of small packets of data (packet size is small) with a data rate of 1 Mbps.

There are two types of devices in BLE: master and slave. The master acts as a central device that can connect to various slaves. Let us consider an IoT scenario where a phone or PC serve as the master and mobile devices such as a thermostat, fitness tracker, smart watch, or any monitoring device act as slaves. In such cases, slaves must be very power efficient. Therefore, to save energy, slaves are by default in sleep mode and wake up periodically to receive packets from the master.

In classic Bluetooth, the connection is on all the time even if no data transfer is going on. Additionally, it supports 79 data channels (1 MHz channel bandwidth) and a data rate of 1 million symbols/s, whereas, BLE supports 40 channels with 2 MHz channel bandwidth (double of classic Bluetooth) and 1 million symbols/s data rate. BLE supports low duty cycle requirements as its packet size is small and the time taken to transmit the smallest packet is as small as 80 s. The BLE protocol stack supports IP based communication also. An experiment conducted by Siekkinen et al. [65] recorded the number of bytes transferred per Joule to show that BLE consumes far less energy as compared to competing protocols such as Zigbee. The energy efficiency of BLE is 2.5 times better than Zigbee.

 Low Power WiFi

The WiFi alliance has recently developed “WiFi HaLow,” which is based on the IEEE 802.11ah standard. It consumes lower power than a traditional WiFi device and also has a longer range. This is why this protocol is suitable for Internet of Things applications. The range of WiFi HaLow is nearly twice that of traditional WiFi.

Like other WiFi devices, devices supporting WiFi HaLow also support IP connectivity, which is important for IoT applications. Let us look at the specifications of the IEEE 802.11ah standard [66, 67]. This standard was developed to deal with wireless sensor network scenarios, where devices are energy constrained and require relatively long range communication. IEEE 802.11ah operates in the sub-gigahertz band (900 MHz). Because of the relatively lower frequency, the range is longer since higher frequency waves suffer from higher attenuation. We can extend the range (currently 1 km) by lowering the frequency further; however, the data rate will also be lower and thus the tradeoff is not justified. IEEE 802.11ah is also designed to support large star shaped networks, where a lot of stations are connected to a single access point.

 Zigbee

It is based on the IEEE 802.15.4 communication protocol standard and is used for personal area networks or PANs [68]. The IEEE 802.15.4 standard has low power MAC and physical layers and has already been explained in Section 7.3. Zigbee was developed by the Zigbee alliance, which works for reliable, low energy, and cheap communication solutions. The range of Zigbee device communication is very small (10–100 meters). The details of the network and application layers are also specified by the Zigbee standard. Unlike BLE, the network layer here provides for multihop routing.

There are three types of devices in a Zigbee network: FFD (Fully Functional Device), RFD (Reduced Functional Device), and one Zigbee coordinator. A FFD node can additionally act as a router. Zigbee supports star, tree, and mesh topologies. The routing scheme depends on the topology. Other features of Zigbee are discovery and maintenance of routes, support for nodes joining/leaving the network, short 16-bit addresses, and multihop routing.

The framework for communication and distributed application development is provided by the application layer. The application layer consists of Application Objects (APO), Application Sublayer (APS), and a Zigbee Device Object (ZDO). APOs are spread over the network nodes. These are pieces of software, which control some underlying device hardware (examples: switch and transducer). The device and network management services are provided by the ZDO, which are then used by the APOs. Data transfer services are provided by the Application Sublayer to the APOs and ZDO. It is responsible for secure communication between the Application Objects. These features can be used to create a large distributed application.