3.3.1.1 Passive

Passive devices have the lowest radio coverage because they do not have onboard power supplies and rely on readers in close proximity for their energy supply. The limitation of passive enabling technologies is that communication with them is unidirectional. Data can be read from nodes but cannot be written back to the nodes. However, for many applications, unidirectional communication is sufficient. Examples of passive perception layer technologies are as follows:

• Quick Response (QR) Codes. These codes function as a method of storing information on an IoT node and can be used to recognize nodes. QR codes are probably the easiest and cheapest technology in this category. They can potentially be applied to almost anything. By printing a 1 sq. in. code on nodes, they become readily recognizable using various readers, such as cameras or light sensors, although they must appear within the line of sight of the reader. QR codes can be employed in many scenarios, such as shipments or manufacturing tracking.
• Passive Radio Frequency Identification (RFID) Tags. These tags are small electronic chips that—similar to QR codes—can be attached to any node enabling the nodes to be recognized for tracking or automatic identification purposes, which enable applications such as inventory management. Readers recognize these chips when they are within a short range by sending a signal that provides sufficient power for the tag to respond; the response contains the identification data.

3.3.1.2 Semipassive

Semipassive devices have batteries that power tags while receiving signals from a reader. Unlike passive technologies, the extra available power enables them to read and write data. Examples of semipassive technologies are as follows:

• Semipassive RFID Tags. These tags are similar to passive tags, but their batteries enable them to have a longer range, which supports a variety of additional uses. One example is smart transportation, for example, blocking railway crossings when a train is approaching.
• Infrared (IR) Readers. These readers are devices that sense electromagnetic radiation that is invisible to humans. Modern uses of this technology include automatic and remote body temperature sensing and remote controls. In the context of IoT, connected IR readers can trigger some actions (e.g., alarm) when detecting abnormalities (e.g., high body temperature). Since the IR is cheap, simple, and consumes low energy, it might be preferable in some IoT scenarios where IR readers might be stolen (e.g., monitoring body temperature at airports). However, it is limited to the line of sight and is subject to interference or failure due to objects blocking the light signals.

3.3.1.3 Active

Active devices often have the longest range because they have larger batteries or are attached to power supplies that enable them to receive and transmit data. Examples of these devices are as follows:

• Active RFID Tags. Similar to semipassive RFID tags but have a longer range due to their larger onboard battery. These tags are mostly used in real-time locating systems (RTLS)⁷, for example, to monitor valuable assets (e.g., to track lost or stolen expensive medical devices). In such IoT scenarios, connected nodes equipped with active RFID can trigger an alarm when they leave a particular area.
• Smart Actuators. Mechanical devices that can be automatically controlled, without human intervention, to apply a specific motion to a product or process based on sensed data or based on the defined workflow. Connected actuators can help industries or smart cities to be more efficient and save money because actuators can react automatically based on sensed data, which requires less staff.
• Wearable, Embedded, or Stand-Alone Smart Sensors. Devices that include embedded sensors, such as gyroscopes, Global Positioning System (GPS) radios, and heart rate monitors used in modern smartphones or smart watches to monitor users' activities and health. Smart thermostats also use connected sensors to efficiently manage energy. In modern IoT applications, such connected devices (e.g., smartwatch, smartphone, etc.) often collaborate to achieve a common goal (e.g., pervasive health monitoring, alert care givers, etc.).

3.3.2.1 Identification

When a node connects to the network, it is assigned an identifier that enables it to communicate with other nodes. Identification is important to control the excessive use of bandwidth in large networks (e.g., flooding) by ensuring that only identified nodes communicate. To easily locate devices in the massive network, names and addresses are assigned to the devices. The naming conventions assign structured names to nodes; these names allow the nodes to be readily identified and may even specifically describe the functions. Naming solutions are as follows:

• Uniform Resource Identifier (URI)⁸. A unique sequence of characters in the form of a web link that refer to an abstract or physical resource (Masinter et al., 2016). These identifiers are used to locate and interact with resources (including IoT nodes) on networks using human-friendly structured names that describe their purpose (e.g., http://www.example.com/temperature/actual).
• Electronic Product Code (EPC)⁹. An EPC global tag standard that assigns a unique identity to each physical object anytime worldwide (e.g., EPC = urn:epc:id:sgtin:0614141.012345.62852). EPCs are encoded on passive RFID tags, which can be used to track all types of objects, such as vehicles on toll roads.
• Ubiquitous Code (uCode)¹⁰. A numeric identification system that uniquely identifies physical objects and places in the real world. Using uCode, information can be associated with objects and locations and can be retrieved from www.uidcenter.org. An example uCode is 00001C00000000000001000285E7A6E3. Unlike EPC, uCode offers more flexibility because the tags can take many forms, such as print (i.e., QR and barcodes), passive RFID, active RFID, infrared, and acoustic tags.

Addressing techniques enable the assignment of unique network addresses to nodes for better network management. Addressing protocols are as follows:

• IPv4. A popular networking protocol that uses 32-bit addresses to assign nodes to unique addresses and aggregate them into smaller networks. Although IPv4 is extensively applied, it is not recommended for IoT due to the small number of addresses (i.e., 2³² addresses) that can be employed.
• IPv6. A networking protocol that aims to overcome the limitations of IPv4 by supporting 2¹²⁸ addresses, which allows every device to have a unique address. Unlike IPv4, IPv6 provides autoconfiguration, which enables devices to be assigned IPs without the need for a Dynamic Host Configuration Protocol (DHCP) server. Autoconfiguration is an important feature for IoT because it simplifies the large-scale deployment of WSNs. Due to the large header size (i.e., 320 bits) in IPv6, IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN) is used to compress the address to make it compatible with traditional WSN protocols (i.e., IEEE 802.15.4), as will be subsequently described.

3.3.2.2 Communication

After a node has been identified (i.e., addressed and named), it can start communicating with other nodes or with backend servers. However, this communication requires the selection of a suitable communication medium, which depends on the capabilities of the node (e.g., power and coverage). Nodes can communicate horizontally (i.e., ad hoc with another node) or vertically (i.e., with servers in the middleware layer). Communication technologies are discussed in this section with emphasis on their use in the IoT. These commonly employed technologies are listed in ascending order based on their wireless range (i.e., wired and short, medium, and long range):

• Power-Line Communication (PLC). This comprises a set of communication protocols that use power-line wiring to simultaneously transmit both data and alternating current. Using this approach, a person can power devices and control/retrieve data using only the standard power cables that run to the device. PLC can be used to connect the nodes in an IoT environment to share data with the backend that then performs some actions. It is mainly preferable in stationary nodes because they rely on power lines anyway as well as in IoT environments that have high wireless interference in smart vehicles, smart grids, and smart homes.
• X10. Similar to PLC, X10 is an industry standard that uses electrical cabling for signaling and controlling devices, in which the signals contain short Radio Frequency (RF) bursts that can include data. Despite its lower data rate and range compared with PLC, it remains a popular choice due to its low cost. X10 is primarily employed to connect nodes in smart homes where outlet modules (e.g., light switches, AC switches, etc.) can be controlled from a mobile application or a web portal.
• Near-Field Communication (NFC)¹¹. A set of protocols that enable communication between two devices over very short distances. NFC is unlike RFID, which is used primarily for identification, it offers a simple way to authenticate, access, and share data between devices and users in IoT systems. NFC is employed in many IoT applications such as smart payments and access control systems.
• Ultra-Wide Bandwidth (UWB). An older wireless technology that uses low-energy transmissions to provide high-bandwidth communications over a wide radio spectrum (Fontana, 2004). This technology is suitable for IoT due to its resistance to interference, which makes it highly scalable since adding more nodes will not cause interference. This technology can help wireless networks to be more adaptive and efficient because each node can be tracked using the UWB. UWB is usually employed in location-based services (e.g., asset tracking) (Anonymous, 2017).
• Wi-Fi. Wi-Fi is particularly useful for ad hoc configurations, such as Wi-Fi Direct, which does not require a wireless access point. The main limitation of Wi-Fi is its power consumption. However, in some IoT applications (e.g., smart homes), power is not an important issue. The Wi-Fi Alliance is launching a new energy-efficient Wi-Fi technology named Wi-Fi HaLow¹² that is specifically designed for IoT nodes.
• IEEE 802.15.4¹³. A standard for low-rate wireless personal area networks (LR-WPANs) that specifies the physical layer and media access control. Because IEEE 802.15.4 was designed for IPv4, the larger sized datagrams of IPv6 are not a natural fit for IEEE 802.15.4 networks. The solution to this problem is to use an adaptation layer (i.e., 6LoWPAN), which encapsulates and compresses headers to allow IPv6 packets to be carried over IEEE 802.15.4 networks. ZigBee¹⁴, ISA100.11a¹⁵, WirelessHART¹⁶, MiWi¹⁷, and Thread¹⁸ are based on IEEE 802.15.4 and only differ in their upper layers. ZigBee and Thread are commonly employed in smart homes and smart meters, whereas ISA100.11a, MiWi, and WirelessHART are commonly used in industrial applications.
• Bluetooth Low Energy (BLE)¹⁹. A wireless standard is intended to exchange data over short distances and build personal area networks (PANs). For Bluetooth v4.0 and later versions, the energy consumption is improved, which renders Bluetooth well suited for sensors and other small devices that require low power. Internet-enabled nodes often use BLE to act with local nodes and send collected data to the backend for more actions. BLE can be used in an extensive range of applications, such as smart buildings, smart transportation, and wearables.
• ANT+²⁰. A proprietary (but open access) wireless communications protocol stack enables nodes to communicate by creating rules for coexistence, signaling, data representation, authentication, and error detection. It is primarily employed in sports, wellness management, and home health monitoring IoT applications where each IoT node use or send sensed data to the cloud, for more actions.
• Z-Wave²¹. A technology extensively applied in smart homes. Z-Wave devices can be attached to home appliances, which enable them to be controlled over the Internet.
• Weightless²². A set of Low-Power Wide-Area Network (LPWAN)²³ open wireless technology standards for exchanging data between a base station and thousands of surrounding nodes. There are three different standards for Weightless, namely, Weightless-W, Weightless-P, and Weightless-N; each of which has different use cases due to its features. Weightless-W offers two-way communication that is ideal for use in the smart oil and gas sector, where TV white space (TVWS) is likely to be available. Although weightless-P also provides two-way communication, it is perfect for private networks and situations that require both uplink and downlink capabilities. Weightless-N offers an uplink that makes it ideal for sensor-based networks, such as temperature readings, tank level monitoring, and metering.
• Cellular Networks. These networks exist in various generations (e.g., 3G and 4G) of cellular network standards that are often employed in smartphones but are also suitable for IoT due to their high mobility and higher speed. Substantial progress has been made in recent generations in terms of power consumption and speed. For example, a recent specification of 4G (called LTE-Advanced) offers a power saving mode that extends the device battery life to a decade with a maximum speed of 10 Mbps. For comparison, other versions of 4G (less energy efficient) can have a speed of up to 1 Gbps (Nokia, 2017).
• SigFox²⁴. A subscription-based service that offers connectivity solutions (in some countries) over dedicated LPWAN networks. SigFox is ideal for IoT applications that need to send infrequent and small bursts of data, such as alarm systems or smart meters.
• DASH7 Alliance Protocol (D7A)²⁵. An open-source wireless sensor and actuator network protocol that provides multiyear battery life and low latency to connect moving nodes. Its IoT applications include smart buildings, location-based services, logistics, and smart vehicles.
• Long-Range Wide-Area Network (LoRaWAN)²⁶. A technology from LoRa Alliance that offers low-cost, mobile, and secure bidirectional communication. It is optimized for low power consumption and is designed to support large networks with millions of nodes, which renders it ideal for IoT applications such as smart cities and industrial applications.

  Some additional technologies that are expected to be adopted in IoT applications are currently under development and will likely be used in the next few years because they will address some of the communication limitations in current technologies. This includes, for example, the following:

• 5G. A medium-range communication candidate that should be available by 2020 (Prasad, 2014). It offers many improvements over 4G, such as increased speed (almost equivalent to Ethernet) and better coverage, and supports a large number of users. Thus, it will enable a larger number of nodes to be connected with extra mobility.
• Light Fidelity (Li-Fi). A new wireless technology that offers high-speed data transmission using visible light communication (VLC) (Ackerman, 2015). Li-Fi can also utilize energy-efficient light-emitting diode (LED) lights to reduce energy costs. However, the Li-Fi scheme is limited to the line of sight and is subject to interference or failure due to objects blocking the light signals. Although Li-Fi has not been extensively adopted in IoT, its high speed indicates that it has substantial potential for use in many applications, such as smart theaters and smart classrooms.
• Software Defined Network (SDN). A networking architecture that is dynamic, manageable, adaptable, and cost effective. These characteristics make SDNs very effective, given the high-bandwidth and dynamic nature of the IoT (Jacquenet and Boucadair, 2016). Underutilized network resources and intelligent route trafficking will facilitate planning for the data flood that is expected as IoT usage increases. SDNs minimize bottlenecks and introduce network efficiencies (Duffy, 2014).

Each of these current communication technologies has special features that enable different scenarios to be implemented efficiently. Table 3.1 compares the important characteristics of most IoT communication technologies and lists them in ascending wireless range order. The data rate aids in the selection of the best technology based on the data flow requirements of applications. Similarly, range is an important consideration for IoT nodes in terms of mobility. Security is also a vital feature because large-scale sensors can cause catastrophic damage when compromised. Therefore, technologies that do not offer any built-in security should only be employed with additional security protocols provided by other layers, as discussed in the next section. Ad hoc communications are critical in applications where nodes communicate with each other without a controller. Technologies that are considered native TCP/IP protocols can be easily integrated into current systems. Header size may affect the choice of technologies with low data rates. Latency can be important in some IoT applications (e.g., remote surgery (West, 2016)). The total latency often increases when a large number of sensors are deployed. Frequency is important to avoid signal interference or restrictions in some places. Scalability is also an important feature of the IoT. Technologies that are scalable often allow for addition of new large number of nodes without affecting the performance, whereas nonscalable technologies are generally limited to fewer than 100 nodes per network.

3.3.2.3 Security

Due to a large number of nodes with limited capabilities, security is an important and challenging task because a successful attack is likely to cause excessive damage (e.g., Distributed Denial-of-Service (DDoS) attacks) (Stephen, 2016). As discussed in the communication technologies section, security may not be built in to the various communication technologies (e.g., Z-wave and Sigfox). Therefore, additional security mechanisms must be provided by different layers to reduce the likelihood of attacks. Attacks can occur in this layer due to insecure communication among nodes. Therefore, lightweight security mechanisms are required for secure communication. Some suggested security techniques are as follows:

• Internet Protocol Security (IPsec)²⁷. A well-known network layer protocol that is employed with IPv6 for authentication and end-to-end encryption among nodes. Because IPsec is implemented in the network layer (in TCP/IP), it also serves the upper layers. A lightweight implementation of IPsec is possible, which renders it ideal for IoT nodes (Raza et al., 2011).
• Transport Layer Security (TLS)²⁸ and Datagram TLS (DTLS)²⁹. These are well-known cryptographic protocols that are also employed with TCP protocols and user datagram protocols (UDPs), respectively, to provide secure communications.
• IEEE 1888³⁰. This protocol is part of a family of standards for the Ubiquitous Green Community Control Network. IEEE 1888.3 prevents unauthorized access to resources and accidental data leaks while enhancing the confidentiality and integrity of transferred data.

3.3.2.4 Routing

Once a node knows a destination address, it must have an efficient method for routing data to that destination node. Efficient routing is critical in IoT environments because of the massive number of nodes that can be connected in an ad hoc manner. Due to the limited capabilities of IoT nodes, each node must efficiently learn about the optimal route. Therefore, a special routing protocol was introduced for these environments. Routing Protocol for Low Power and Lossy Networks (RPL)³¹ is an IPv6 routing standard protocol for resource-limited devices. This protocol was proposed to support different types of links, such as IEEE 802.15.4, and common traffic types, including one-to-one, many-to-one, and one-to-many. The protocol can be compactly represented as a set of graphs in which each graph is a Destination-Oriented Directed Acyclic Graph (DODAG). In this type of graph, each node knows at least one path to its root node (i.e., border router), and each node is aware of its parent. Nodes exchange RPL special messages to maintain the graph and ensure that a valid route(s) to the root is always available. As shown in Figure 3.2, routers can work in two operational modes: nonstoring mode (as in DODAG 1) and storing mode (as in DODAG 2). In nonstoring mode, nodes forward each message to the root, which could be useful in scenarios where nodes are programmed to send sensed data (e.g., temperature readings) periodically. In contrast, in storing mode, communications are bidirectional, and each node stores the routes to all nodes under it. This can be helpful in scenarios where nodes only send sensed data when they are requested; hence, downward routes are needed to deliver the request messages.

3.3.3.1 Service Discovery

IoT applications and users need to be able to use names or addresses to request services without knowing the underlying infrastructure details. Therefore, services need to be discoverable and registered. Scalable and heterogeneous environments, service registration, and discovery should be autonomous, dynamic, and efficient. The protocols that are most commonly employed to provide service discovery are as follows:

• Multicast DNS (mDNS)³². A zero-configuration and infrastructure-independent protocol that can continue to function even during an infrastructure failure because they can use their local caches. It binds host names to IP addresses inside small networks by multicasting an IP request message asking a device with a particular host name to send its IP address. This host replies with a multicast message that contains its IP address. All other devices in the subnet use this response to update their mDNS local caches. This protocol, when combined with IPv6 (with autoconfiguration), can entirely eliminate the need for a local server to manage local WSNs.
• DNS Service Discovery (DNS-SD)³³. Another zero-configuration protocol that complements mDNS because it pairs services to hosts within a domain. IoT clients can find a service by sending a multicast request for a service type (e.g., temperature readings), and all machines that provide this service will respond with their host names. Names are important because the nodes names, unlike IP addresses, rarely change. Then, mDNS is used to pair the names of the nodes with their IP addresses. Avahi³⁴ and Bonjour³⁵ are two popular implementations of both mDNS and DNS-SD.

  Another approach to service discovery is to publish the uniform resource identifiers (URIs) of nodes that provide services over the Web. This approach is known as the Web of Things (WoT). Technologies that adopt this approach are as follows:

• HyperCat³⁶. An open, lightweight JavaScript Object Notation (JSON)-based hypermedia catalog format is intended to be used for publishing collections of URIs. Each HyperCat catalog can include any number of URIs, each with any number of Resource Description Format (RDF)³⁷-like triple statements that provide information about this URI. HyperCat enables developers to publish linked data descriptions of IoT nodes that can be fetched by HTTP GET requests, which requires IoT clients to know the URI address.
• Physical Web³⁸. A technology that enables nodes to broadcast their Uniform Resource Locators (URLs) or some local data inside web pages. Unlike HyperCat, IoT clients do not need to know the URLs because they can fetch them via Bluetooth beacons (e.g., Eddystone³⁹), mDNS, or Wi-Fi Direct (Anonymous, 2016a). The published URLs enable users to interact with the nodes (e.g., sensors) from their smartphones or laptops. A proxy service is used to prevent malicious URLs and sort lists of URLs based on users' preferences.
• Universal Plug and Play (UPnP)⁴⁰. A group of networking protocols that enable networked IoT nodes to seamlessly discover each other's presence in the network and supply functional network services (i.e., data sharing, communications, and entertainment). However, UPnP is known to be vulnerable to security problems (Anonymous, 2016b). UPnP+ is an emerging initiative that aims to address the issues associated with UPnP (Anonymous, 2016c).

3.3.3.2 Data Exchange

To manage the vast amount of data created by the large number of nodes, a manager must transmit data to receivers in a secure and efficient manner. This management occurs on the TCP/IP application layer. Thus, the technologies that reside here are known as application protocols. In IoT environments, each node can capture data, analyze data, and control other nodes. However, before a node can begin communicating and exchanging data in the IoT network, it must be identified and registered as a part of the service network. This operation is referred to as node subscription. A subscribing node must make a request to join a service network (i.e., subscribe) before it can obtain or publish service-related data (e.g., temperature) from or to the network. Once the node is subscribed to publishers, it will receive service-related data when they are published. This model is known as the publish/subscribe model. An alternative approach is called request/response in which a joined node always requests a service-related data explicitly and receives a response that contains the requested data. Once the node joins the network, it is assigned network resources and can start exchanging data and operating as a component of the IoT environment. The publish/subscribe model is generally preferable for IoT scenarios that require the large deployment of nodes that frequently exchange data. Indeed, in such scenarios, using the request/response model leads to high network overhead, which can cause increased power consumption. In contrast, the request/response model can be easily integrated into client/server applications, as will be discussed for the Constrained Application Protocol (CoAP). Some of the commonly used protocols are as follows:

• CoAP⁴¹. A request/response protocol was created by the Constrained RESTful Environments (CoRE) group for constrained devices. To provide resource-oriented interactions in a request/response architecture, it uses the HTTP commands (i.e., GET, POST, PUT, and DELETE) over UDP. Unlike TCP, UDP is suitable for lightweight IoT implementations. HTTP-CoAP proxies can be used to effortlessly convert interactions between HTTP and CoAP. To provide the reliability that UDP lacks, the header of CoAP messages has two bits that determine the required Quality of Service (QoS) level. CoAP includes four types of messages: confirmable (i.e., must be acknowledged by the receiver with an acknowledgment [ACK] packet), nonconfirmable (i.e., “fire and forget” messages that do not require acknowledgment), acknowledgment (i.e., an acknowledgment of a confirmable message), and reset (i.e., rejecting a message or removing an observer). CoAP has a simple back-off retransmission mechanism to detect and prevent duplicates for confirmable messages via a unique message ID, which is a 16-bit header field. DTLS can be used to provide security to CoAP applications; however, DTLS has problems because (1) its handshakes cause resource-limited nodes to consume additional resources, leading to reduced battery life; (2) it increases the conversion complexity between HTTP and CoAP; and (3) it prevents CoAP's multicast support.
• Extensible Messaging and Presence Protocol (XMPP)⁴². An IETF protocol for communicating over the Internet. It is appropriate for IoT because it provides near real-time, low-latency, and platform-independent communications in a decentralized manner. It runs over TCP and works in both publish/subscribe and request/response models. In XMPP, a client connects to a server using eXtensible Markup Language (XML) messages. The XML parsing creates high network overhead; however, methods are available to reduce this overhead (Waher and DOI, 2015). XMPP has built-in core TLS/Secure Sockets Layer (SSL) security features. QoS is not provided in XMPP; it inherits the TCP mechanisms for reliability, which are not suitable for the IoT (Karagiannis et al., 2015). To overcome this issue, a draft standard (i.e., XEP-0184: Message Delivery Receipts) has been proposed (Saint-Andre and Hildebrand, 2011).
• Message Queue Telemetry Transport (MQTT)⁴³. A lightweight M2M communication protocol that utilizes the publish/subscribe model. It is suitable for slow, unreliable connections and computation-limited devices. MQTT includes three types of modules: broker, publishers, and subscribers. A subscriber can register for a specific service; then, the broker notifies interested subscribers when publishers start a service that interests them. MQTT runs on top of TCP and provides three levels of QoS: at most once (i.e., a message will be delivered once with no confirmation), at least once (i.e., a message will be delivered at least once, with confirmation required), and exactly once (i.e., a message will be delivered exactly once using a four-step handshake) (Karagiannis et al., 2015). A slightly different version of MQTT for sensor networks (i.e., MQTT-SN) is aimed at embedded devices on non-TCP/IP networks, such as ZigBee. Security is implemented by the MQTT broker using TLS/SSL, which requires subscriber authentication.
• Advanced Message Queuing Protocol (AMQP)⁴⁴. An open standard for the IoT that provides message-oriented publish/subscribe communications capabilities. Similar to MQTT, message reliability is maintained using message delivery guarantees, such as at most once, at least once, and exactly once. TLS/SSL and/or Simple Authentication and Security Layer (SASL)⁴⁵ are used for security over TCP. Communications in AMQP are managed by two components: exchanges and message queues. Exchanges route messages to or among appropriate queues based on predefined rules. Message queues store messages in queues before they are sent to receivers. Although it lacks protocol support for Last-Value Queues (LVQs)⁴⁶, AMQP provides a richer group of messaging scenarios (e.g., one-to-one, broadcast, topic filtered, and request-reply) (StormMQ, 2017).
• Data Distribution Service (DDS)⁴⁷. A M2M standard that was created by the Object Management Group (OMG). It is a data-centric publish/subscribe protocol that does not rely on a broker. Due to its multicast support, it is a very reliable protocol because it offers 23 different QoS policies. The DDS architecture consists of two interface levels. The first level—Data-Centric Publish-Subscribe (DCPS)—is responsible for information delivery to subscribers. The second level—the Data-Local Reconstruction Layer (DLRL)—is an optional layer that breaks data objects into separate elements to enable the simple integration of DDS into the application layer (Anonymous, 2016d). In addition to publishers and subscribers, a typical DDS application has the following elements: (1) a domain (e.g., medical devices), (2) a topic (i.e., a group of data from similar devices, such as electrocardiogram (ECG) readings from many devices), (3) an instance, (i.e., a target where data is changing, such as “patient #13 ECG readings”), (4) a sample (i.e., a snapshot of an instance at a point in time), (5) a Data-Writer (i.e., a source of information about the topic), and (6) a DataReader (i.e., an observer of the topic).

Table 3.2 compares the most important features of data exchange protocols. The first two columns list the messaging model type (i.e., request/response or publish/subscribe). The Brokerless column indicates whether a broker between subscribers and publishers is required. Brokerless protocols do not rely on a broker to deliver messages, thereby eliminating the possibility of a single point of failure. The RESTful column indicates whether services are accessible via stateless operations, which is relevant in situations where communication is required upon request (as in HTTP). The Transport column shows the type of transport protocol that is employed in the technology. TCP is connection oriented, which offers high QoS but can be slow for large applications. The Multicast column specifies whether the technology enables multicast, which is preferable to reduce unwanted communications and add extra QoS. The Security column lists the security features supported by each technology. The QoS policies column specifies the number of QoS policies: Typically, a high number of policies is better. The Header Size column indicates the minimum size of a packet, which can be a consideration when the data rate is low, and communications are unreliable. The Discovery column specifies whether the protocol has discovery abilities in terms of services and node properties.

3.3.3.3 Computation

Computation is required to process the collected data and manage sensors. Computations in IoT environments can range from lightweight to complex operations. Lightweight computations are related to managing the platform, such as service access lists that involve encryption/decryption. Complex computations address the actual data (e.g., logic). Computations can be performed based on IoT application requirements in the following locations:

• Local. Local computations are performed using a processing unit or system on a chip (SoC). Applications may include networking and one-board sensing technologies, such as Arduino⁴⁸, UDOO⁴⁹, Intel's IoT products⁵⁰, and Raspberry PI⁵¹. This hardware is typically operated by real-time operating systems (RTOSs), such as Contiki OS⁵² and RIOT OS⁵³. This type can be used in small IoT project (e.g., do-it-yourself (DIY) security systems (Anonymous, 2016e)) or in border routers for lightweight operations, such as filtering and compressing data, to reduce network overhead and load on servers in the cloud or fog.
• Cloud. Cloud computing is preferable for applications in which sensors that reside in different places send generated data to the cloud for centralized processing. This approach is flexible because cloud services can scale-up or scale-down on demand (Hassan et al., 2012). Cloud-based IoT platforms are the most common architecture in current real IoT deployments. Kaa⁵⁴ and DeviceHive⁵⁵ are examples of cloud-based IoT Platform as a Service (PaaS) implementations. Cloud Infrastructure as a Service (IaaS) is used by IoT service providers to allow their customers to use IoT services (i.e., Software as a Service (SaaS)).
• Fog. A fog computing layer is ideally employed with the cloud to improve performance because it can be deployed near end users or nodes. This is important because cloud servers might be far away from the nodes; thus, fog computing servers can perform some operations to reduce the latency of transferring data all the way to the cloud. Also, fog is preferred over cloud because only a small amount of the data transferred is relevant for actionable insights. Hence, cloud is not always efficient. Thousands of fog computing units are provided by mobile network operators but do not have the same computing capabilities as the cloud. Similar to cloud computing, fog computing improves scalability. Low latency and location awareness, widespread graphical distribution, device density, mobility, and real-time capabilities are advantages of fog computing (Saint-Andre and Hildebrand, 2011). For more details about fog computing in the IoT, refer to Chapter 4.

3.3.4.1 Identity-Related Services

Identity-related services require an identifier that is embedded in a node and a reader device, such as an RFID device. Identity-related services can be active or passive (as discussed in the RFID subsections). These services are extremely important in IoT applications because they keep track of devices in large deployments (e.g., recording device maintenance and maintaining inventories of used parts and stock levels.) A package-tracking application is an example of this type of service.

3.3.4.2 Information Aggregation Services

Aggregation services summarize the collected raw sensory measurements from various types of sensors and networks that must be processed and reported to the IoT application. Load distribution among smart grids is an example of this type of service.

3.3.4.3 Collaborative Aware Services

Collaborative aware services are built on top of information aggregation services and are used to make decisions about the acquired data. This type of service can be found in smart homes, smart agriculture, and smart manufacturing, among other applications. For example, in a smart home, a security system and smart thermostats are employed together to improve security and energy efficiency based on sharing data between them (Anonymous, 2016f).

3.3.4.4 Ubiquitous Services

These are the most advantageous services of the IoT because they advance collaborative aware services to the next level by offering complete access to everything at (almost) any time and from anywhere. Access and control can be achieved using a computer, smartphone, or any smart device. Smart cities are examples of these services.

3.3.5.1 Semantics

After data are captured by sensors, they can be analyzed to extract knowledge. Knowledge is crucial for enhancing services and obtaining useful results that cannot be discovered without examining all IoT environment data. In order to analyze data efficiently, it has to be well-formed using some semantics technologies. Many semantic XML-based technologies can be used for knowledge extraction, resource discovery and usage, and modeling. An Efficient XML Interchange (EXI) is often used to resolve the performance issue that arises from the use of XML (e.g., XML parsing) to make it suitable for IoT applications (Al-Fuqaha et al., 2015). Many nodes from different brands are likely to generate data that has different form in each type of nodes. Such problem requires more work to unify the data so that it can be processed efficiently. Therefore, dynamic semantics is an important factor in improving the interoperability of the IoT. IoT technologies for semantics include the following:

• Sensor Model Language (SensorML)⁵⁶. A standard model based on an XML schema to describe sensors and measurement procedures. SensorML is useful in IoT systems for creating electronic description sheets for sensor modules and collecting metadata to be used to discover sensor systems and observe processes. It also enables sensor networks to be autonomous because of the self-describing features of SensorML-supported sensors.
• Media Types for Sensor Markup Language (SenML)⁵⁷. It is a new, simple model for acquiring sensed data and to control actuators. It provides semantics for the data and allows for additional metadata with links and extensions. This simple model can be used in many IoT applications (Keränen and Jennings, 2017). For example, a sensor, such as a humidity sensor, could use this media type in CoAP to transport the sensors' measurements.
• IoT Database (IOTDB)⁵⁸. A new technology with unlimited expandability that supports semantics for providing formal definitions of all necessary items. Unlike the aforementioned technologies, IOTDB uses JSON dictionaries to manipulate and monitor nodes, which makes it relatively fast since JSON parsing is always more efficient than XML parsing. IOTDB is compatible with protocols, such as CoAP, and MQTT.
• RESTful API Modeling Language (RAML)⁵⁹. This language is used to define HTTP-based APIs that represent most of the principles of Representational State Transfer (REST)⁶⁰. Since it is RESTful, it is more likely to be used in IoT scenarios that are suitable for CoAP (as discussed in Section 3.3.3.2), where the network overhead is negligible.
• Wolfram Data Drop⁶¹. An open service that allows accumulating data of any type from anywhere (including IoT nodes) to prepare it semantically for instant computation, querying, analysis, visualization, or other operations. Computable data (i.e., collections and time series) are saved in named data bins in the Wolfram Cloud and are immediately accessible from all other systems/applications.

3.3.5.2 Big Data Analytics

IoT environments involve an immense number of sensors that collect vast amounts of data, resulting in extremely large datasets (i.e., Big Data) that may be computationally analyzed to extract knowledge, such as patterns, trends, and associations. The generated Big Data continues to increase as the IoT collects additional data. Therefore, special technologies that can address the ever-increasing amount of data are required. The most efficient strategy for addressing continuously increasing data is to process them in real time (streaming). Real-time processing enables up-to-date analytics that reflect recent changes in data and conserves storage. Machine learning can also utilize Big Data to make accurate predictions. Additionally, parallel computing can be employed using some IoT nodes (or fog computing units) to process data in parallel with back-end servers for better performance and load balancing. The following technologies aid in the generation of real-time (streaming) analytics from Big Data:

• Apache Spark⁶². A well-known open-source distributed processing technology that utilizes in-memory caching and features enhanced execution for better performance. Apache Spark supports streaming analytics, batch processing, graph databases, ad hoc queries, and machine learning. Although Spark has been employed in numerous IoT systems, it requires some extra effort to overcome some limitations, such as time delays in real-time processing (Freedman, 2016). Spark is a very flexible technology since it supports static and streaming data and many programming languages (as presented in Table 3.3).
• Apache Apex⁶³. An open-source platform, similar to Spark, unifies stream and batch processing in a distributed, scalable, fault-tolerant, performant, stateful, and secure manner. Unlike Spark, it has a very low latency and processes big-data-in-motion (i.e., processes streaming data, including in-flight modification). Its ability for processing big-data-in-motion, enables it to be integrated easily with fog computing units. However, it lacks out-of-order processing and only supports Java as a programming language. Although it is a relatively new platform, it is widely adopted in many large-scale IoT projects, such as smart grids (Anonymous, 2016g; DataTorrent, 2016) and industrial applications (Apache Apex, 2016).
• Apache Flink⁶⁴. An open-source platform that is conceptually very similar to Apex. However, it is older than Apex, it has not been used frequently in real-life IoT projects due to its lack of autoscaling and limited message delivery guarantees (QoS).
• Apache Kafka⁶⁵. A client library used to process and analyze the data stored in Kafka and either forward the output to an external system or write it back to Kafka. The first scenario allows Kafka to serve as a middle layer in which it collects the data generated by IoT sensors, then applies some operations to it (e.g., filtering and sorting), and finally streams it to other components in other frameworks (e.g., Flink and Spark).

Table 3.3 highlights the main differences between these technologies. The first column describes the languages that these Big Data frameworks support. This helps IoT adopters to choose Big Data frameworks based on their employee's expertise. The next column describes the delivery policies, which might be an important element in critical IoT scenarios in which “at least once” policy is appropriate. In contrast, in less critical scenarios (or for more efficiency), at most once would be sufficient. In this feature, Apex has an advantage over the others because it has the highest number of policies. Autoscaling is a very important feature for IoT because it ensures the efficiency of computation as extra resources are used only when needed. Latency can be relevant in some IoT scenarios (e.g., traffic control) to ensure the accuracy of real-time analytics. Finally, the last column indicates the ability of the framework to perform some computations on data before they reach the back-end servers, as in fog computing.