of SWoT is to provide semantic interoperability that allows not only sharing and reusing the IoT Things but also making IoT data to be universally understandable [35]. The sum-mary of the evolution from Internet of Things to Semantic Web of Things is illustrated in Figure 2.1 [36].
2.1.3 Massive Internet of Things
With the explosion of Internet of Things, the number of Things and its connectivity have been growing exponentially. In addition, the Things is not only deployed in the dense environments (e.g., building, city.), but also in the hostile environments (e.g., in the for-est or mountain). As a result, Massive IoT (MIoT) is emerging as a new focal point for IoT connectivity technologies referring to the huge volume of constrained IoT devices, which stringently require excellent coverage, cost-effective and low-energy consumption [37].
Among several new connectivity technologies for MIoT, proprietary LPWAN technologies like Sigfox and LoRa have been considering the potential candidates while cellular-based connectives, such as 5G or Narrowband IoT (NB-IoT), are under developing and testing process [38].
In practice, the IoT devices in Massive Internet of Things context are distributed in spacious areas from large manufacturing plants to inside sewer systems where the radio signal is physically challenging. To adapt to such environments, the connectivity technology of Massive IoT must be wide coverage and robust. In addition, replacing device battery in enormous areas is extremely expensive. They have to consume low energy to extend the device battery life. High throughput and latency are not unessential in massive IoT applications, since they more focus on collecting data than controlling the IoT Things.
2.2 Fundamentals of IoT
2.2.1 IoT Things
Similar to Internet of Things definition, deriving a unified definition for the “Things” in IoT is still challenging although it has received the most attention from academic organizations, such as National Institute of Standards and Technology (NIST), Committed to Connect-ing the World (ITU),World Wide Web Consortium (W3C),International Energy Research Centre (IERC), and Internet Engineering Task Force (IETF) [39]. Institute of Electrical and Electronics Engineers (IEEE) simply defined the Things as a physical or a relevant object from a user or application perspective [33]. However, IERC believes that a Thing can be a physical or virtual object and identified by an unique identity [40]. NIST proposes the Things can be software, hardware, or the combination of software and hardware. [41].
Due to the heterogeneity in Things definition, we simplify the Thing could be a physical or virtual object integrated into a network. This object can be interacted via a unique identity and interfaces. For example, a smartphone can be a Thing which is a physical object, able to connect networks (WiFi, Cellular Network), has a unique identity (phone number, IP address) and interfaces (Web services, applications).
2.2.2 IoT Connectivity
In this section, rather than mentioning all the IoT protocol following an existing architecture model likeOpen Systems Interconnection model (OSI model) , we only briefly present some
dedicated protocols in IoT and categorize them based on their functionalities.
Infrastructure:
• 6LoWPAN: This is an acronym of IPv6 over Low Power Wireless Personal Area Networks defined by IETF in the document RFC 6282 [42], deriving from the idea that “the Internet Protocol could and should be applied even to the smallest devices” [43]. This protocol uses 2.4 GHz frequency with 250 kbps rate.
• uIP: The uIP is an open source project licensed under a BDS style license [44].
The goal of this project is to create a dedicated TCP/IP stack for 8 or 16 bits micro-controllers. Currently, it is further developed by a wide community.
• NanoIP: The concept NanoIP is to optimize all features of Internet to adapt to embedded and small devices, without the overhead of TCP/IP [45]. NanoIP uses two dedicated transport techniques are nanoUPD and nanoTCP. A socket-compatible API is also provided to ensure the compatibility to the original IP protocol.
• Time Synchronized Mesh Protocol (TSMP): TSMP is a communication protocol designed for a self-organizing network of wireless devices enabling reliable, low power, and secure communication [46].
Discovery:
• mDNS: The mDNS is used to resolve hostnames to IP addresses within small networks. Except missing a local name server, this technology is essentially the same with the unicast Domain Name System (DNS) in term of programming interfaces, packet formats, and operations [47].
• Physical Web: The Physical Web aims to discover and interact with nearby devices through a list of URLs being broadcast. That means every smart object in the network needs to broadcast its access URL to nearby devices.
• HyperCat: HyperCat is an open, lightweight JSON-based hypermedia cata-logue format to exploit Thing resources [48]. It allows adding a set of semantic annotations to Things resources and makes them discoverable over the web.
• Universal Plug and Play (UPnP): The UPnP uses Internet and Web protocols to automatically discover new devices to be plugged into a network. These devices announce their presence to other devices by using a discovery protocol based on Hypertext Transfer Protocol (HTTP) [49].
Data Protocol:
• Message Queuing Telemetry Transport (MQTT): MQTT is a publish-subscribe based messaging protocol working on the top of TCP/IP protocol. It is effective for connections limited bandwidth [50]. An MQTT system consists of a central messaging server named “message broker” and clients. There are two client types are (1) Publisher: Clients publish data to broker. (2) Subscriber: Clients receive data from the broker. The responsibility of brokers forward data from publishers to subscribers.
• Constrained Application Protocol (CoAP): CoAP is an application layer pro-tocol designed for constrained internet devices limited in storage, computation power. It is based on RESTful protocol to directly translate to HTTP for simpli-fied integration, and while also fulfill specialized requirements, such as multicast
2.2. Fundamentals of IoT 13
support, very low overhead, and simplicity [51]. Currently, the major standard-ization for CoAP is done by IETF, and various new functionalities have been added [52].
• Extensible Messaging and Presence Protocol (XMPP): XMPP is a real-time communication protocol based on Extensible Markup Language (XML). It is defined in an open standard managed by IETF. Designed to be extensible, this protocol is also used for the publish-subscribe model in Voice over Internet Pro-tocol (VoIP), video, and IoT applications.
• Advanced Message Queuing Protocol (AMQP): Similar to XMPP, AMQP is an open standard application layer, but it is designed for message-oriented middle-ware. Thereby, its functionalities ensure reliability and security, such as message orientation, queuing, routing [53]. The authentication and encryption are based on Simple Authentication and Security Layer(SASL) or Transport Layer Security (TLS).
• Lightweight Local Automation Protocol (LLAP): LLAP is a simple short message designed for the device-to-device communication. The key strengths of LLAP are widely compatible and easily understandable by humans [54].
Communication/Transport layer:
• Sigfox: Sigfox is a radio technology using Ultra Narrow Band (UNB). It targets to provide a long range and low energy consumption connectivity for IoT devices.
By using UNB, sigfox achieves bandwidth efficiently, low noise levels. However, it is limited in throughput (100bps) and packet size (12 bytes payload).
• Narrow band IoT(NB-IoT): NB-IOT is a Low Power Wide Area Network (LP-WAN) radio technology developed by 3rd Generation Partnership Project (3GPP) [55].
It adopts narrowband technology with single frequency 200kHz. Thereby, NB-IoT has the limited bandwidth. In contrast with Sigfox, NB-NB-IoT aims to provide the lost-cost connection in indoor scenarios or dense urban areas in which the connection density is high.
• LoRa: LoRa is a patented digital wireless data communication IoT technology developed by Semtech [56]. It operates over the open license radio frequency bands (169 MHz, 433 MHz, or 868 MHz) enabling long-range transmissions with low power consumption [57]. The technology of LoRa includes two parts: (1) LoRaPhy: is a communication technology working on the physical layer to enable long-range communication link; (2) LoraWan: is an open-source communication protocol built upon the LoRaPhy.
2.2.3 IoT Platform
The IoT platform (also known as IoT middleware) is an intermediate software layer in-terposed between the technique and application layer. Its goal is to abstract the IoT sys-tem complexities related to hardware, connectivity, configurations under simple interfaces or services. In this way, the application developer more focusing on their tasks without concerning the technology behind. In the IoT, such complexities mostly relate to commu-nication because of the considerable heterogeneity in devices, protocols, and applications.
In such context, the middleware provides standard services or interfaces, which wrap the heterogeneous computing and communication technologies of IoT devices. To achieve its goals, the middleware needs fulfilling requirements [58]:
• Programming abstraction: The middleware should provide a simple and unified API interface for application developers. This interface is used to separate the IoT applications and services with the underlying heterogeneous IoT infrastructures. The style of the programming interface depends on the interface type. For instance, SQL-like languages for data query will be used in descriptive interfaces. [59].
• Interoperable layers: One of the main goals of middleware is to deal with the hetero-geneity in IoT. Hence, the middlewares should equip an interoperable layer interacted with heterogeneous components in IoT systems.
• Service-based: A middleware should equip elements to produce high flexibility and reliability services which easily adapt to the frequent changes in middleware functions and application contexts.
• Adaptive: A middleware must be able to dynamically adapt and adjust itself with the changes of its context or environments.
• Context-aware: Context-aware represents the ability to aware the context of users, devices, and environment. This is a key feature to build an adaptive middleware.
• Autonomous: The middleware may integrate, communicate and exchange the data with IoT devices without human interactions. To achieve this requirement, there are many technologies includingautonomous agents,embedded intelligence, andproactive approaches [60, 61].
2.2.4 IoT Service
As IoT service is an ambiguous term which highly depends on the context, it is hard to provide a concise definition. The most common understanding is that “An IoT-Service is a transaction between service providers and consumers. It triggers a prescribed function to interact (e.g., observe, initiate actions) with the physical world via IoT Things” [62]. Based on this definition, we could classify the IoT services into two types:
• Thing-based services: This kind of services provided by the IoT Things allows to connect, obtain and control the Things resources. It is popular in powerful IoT things, such as smartphones, Raspberry devices.
• Cloud-based services: These services are provided by the cloud-based IoT platforms.
They may include Things-based services and non-IoT services.
2.2.5 IoT Applications
The IoT is expected to offer a huge number of applications, which significantly increase our life quality in every aspect (e.g., working, living, traveling) . In this section, we briefly present the common IoT applications in: (1) Transportation domain, (2) Health care do-main, (3) Smart environment domain.
• Transportation domain: Vehicles will be more intelligent based on collected informa-tion from surrounding context, such as traffic status, road quality, and nearby objects.
Two typical features in vehicle based on IoT technologies areCollision avoidance sys-tem and Automotive navigation system. In detail, collected information is used by a collision avoidance system to assist drivers in preventing unexpected objects (e.g.,