reading

Cover
Dedication
Preface
Chapter 1: Preliminaries, Motivation, and Related Work
1. 1.1 What is the Internet of Things?
2. 1.2 Wireless Ad‐hoc and Sensor Networks: The Ancestors without IP
3. 1.3 IoT‐enabled Applications
Chapter 2: Standards
1. 2.1 “Traditional” Internet Review
2. 2.2 The Internet of Things
3. 2.3 The Industrial IoT
Chapter 3: Interoperability
1. 3.1 Applications in the IoT
2. 3.2 The Verticals: Cloud‐based Solutions
3. 3.3 REST Architectures: The Web of Things
4. 3.4 The Web of Things
5. 3.5 Messaging Queues and Publish/Subscribe Communications
6. 3.6 Session Initiation for the IoT
7. 3.7 Performance Evaluation
8. 3.8 Optimized Communications: the Dual‐network Management Protocol
9. 3.9 Discoverability in Constrained Environments
10. 3.10 Data Formats: Media Types for Sensor Markup Language
Chapter 4: Discoverability
1. 4.1 Service and Resource Discovery
2. 4.2 Local and Large‐scale Service Discovery
3. 4.3 Scalable and Self‐configuring Architecture for Service Discovery in the IoT
4. 4.4 Lightweight Service Discovery in Low‐power IoT Networks
5. 4.5 Implementation Results
Chapter 5: Security and Privacy in the IoT
1. 5.1 Security Issues in the IoT
2. 5.2 Security Mechanisms Overview
3. 5.3 Privacy Issues in the IoT
Chapter 6: Cloud and Fog Computing for the IoT
1. 6.1 Cloud Computing
2. 6.2 Big Data Processing Pattern
3. 6.3 Big Stream
4. 6.4 Big Stream and Security
5. 6.5 Fog Computing and the IoT
6. 6.6 The Role of the IoT Hub
Chapter 7: The IoT in Practice
1. 7.1 Hardware for the IoT
2. 7.2 Software for the IoT
3. 7.3 Vision and Architecture of a Testbed for the Web of Things
4. 7.4 Wearable Computing for the IoT: Interaction Patterns with Smart Objects in RESTful Environments
5. 7.5 Effective Authorization for the Web of Things
References
Index
End User License Agreement

List of Tables

Chapter 02
1. Table 2.1 CoAP options.
2. Table 2.2 CoAP content formats.
3. Table 2.3 HTTP/CoAP response code mappings.
4. Table 2.4 Comparison between CoSIP and SIP signaling (bytes per message) for session instantiation and establishment.
Chapter 03
1. Table 3.1 Semantics and effects of HTTP methods for manipulating resources.
2. Table 3.2 Semantics of 2xx HTTP status codes when manipulating resources.
3. Table 3.3 Semantics HTTP error status codes when manipulating resources.
4. Table 3.4 Comparison of different session initiation protocols.
5. Table 3.5 Comparison of Java bytecode footprints.
6. Table 3.6 DNMP message fields.
7. Table 3.7 Packet‐loss rate at different hops for a 5 s audio stream at 1008 B/s (i.e., 5 kB).
8. Table 3.8 Interface description summary.
9. Table 3.9 JSON SenML labels.
Chapter 04
1. Table 4.1 Local service discovery metrics.
2. Table 4.2 ROM usage for the proposed multicast protocol and an MPL implementation: total ROM occupation and as a percentage of available memory on 128‐kB WiSMote.
Chapter 05
1. Table 5.1 Comparison of different symmetric‐key cryptographic algorithms.
2. Table 5.2 Comparison of security levels for symmetric ciphers, ECC, and RSA (recommended NIST key sizes).
3. Table 5.3 Public‐key encryption library ROM occupancy.
4. Table 5.4 RSA private key operation performance.
5. Table 5.5 ECDSA signature performance: TinyECC versus Wiselib implementations.
6. Table 5.6 Acronyms used.
Chapter 06
1. Table 6.1 Comparison between graph framework actors and OAuth roles.
2. Table 6.2 Average stream delay related to the adoption of asymmetric encryption solution (RSA) into the graph framework processing block.
3. Table 6.3 Average CPU and memory utilization related to specific IoT Hub procedures on both local and remote instances.
Chapter 07
1. Table 7.1 Power sources for smart objects, maximum current draws, and charge they can store.
2. Table 7.2 RFC7228 classes of constrained devices.
3. Table 7.3 Hardware specification of the MemSic TelosB mote.
4. Table 7.4 Hardware specification of the Zolertia Z1 platform.
5. Table 7.5 Hardware specification of the OpenMote platform.
6. Table 7.6 Hardware specification of the Arduino Yun AVR Arduino microcontroller.
7. Table 7.7 Hardware specification of the Arduino Yun Arduino microprocessor.
8. Table 7.8 Hardware specification of the Intel Galileo board.
9. Table 7.9 Constrained IoT nodes in the WoTT.
10. Table 7.10 Single board computer nodes in the WoTT.
11. Table 7.11 Authorization framework message specification.

List of Illustrations

Chapter 02
1. Figure 2.1 Communication protocol stacks: traditional seven‐layer ISO‐OSI stack (left) versus four‐layer TCP/IP stack (right).
2. Figure 2.2 Header structure for IPv4 (left) and IPv6 (right) packets.
3. Figure 2.3 Header structure for TCP (top) and UDP (bottom) datagrams.
4. Figure 2.4 UA registration and session setup with two intermediate proxy servers.
5. Figure 2.5 CoAP protocol stack vs. HTTP protocol stack.
6. Figure 2.6 CoAP URI.
7. Figure 2.7 CoAP messaging model.
8. Figure 2.8 CoAP reliability.
9. Figure 2.9 Piggyback response and separate responses.
10. Figure 2.10 CoAP general message format.
11. Figure 2.11 CoAP message header detail.
12. Figure 2.12 CoAP extended option delta with (a) 1 byte and (b) 2 bytes added after the option length.
13. Figure 2.13 CoAP extended option length with (a) 1 byte and (b) 2 bytes added after the option length or extended delta.
14. Figure 2.14 Procedure to construct CoAP message options to target URI coap://example.com/people/123.
15. Figure 2.15 Observer pattern.
16. Figure 2.16 CoAP resource observation.
17. Figure 2.17 Anatomy of a Block option value.
18. Figure 2.18 Block2 option (response payload) transfer example.
19. Figure 2.19 Block1 option (request payload) transfer example.
20. Figure 2.20 CoAP group communication.
21. Figure 2.21 Resource discovery in CoAP.
22. Figure 2.22 HTTP‐to‐CoAP proxying.
23. Figure 2.23 (a) Direct endpoint communication to origin server; (b) communication through intermediary node; (c) proxy‐based communication. (d) HTTP‐to‐CoAP proxy.
24. Figure 2.24 HTTP‐to‐CoAP URI mapping.
25. Figure 2.25 CoSIP message format.
26. Figure 2.26 Comparison of the layered architectures of: (a) SIP and (b) CoSIP.
27. Figure 2.27 CoAP service discovery. The numbers indicate the order of exchanged messages.
28. Figure 2.28 CoSIP session establishment.
29. Figure 2.29 Subscribe/notify applications with CoSIP.
30. Figure 2.30 Transmitted bytes for CoSIP and SIP session (signaling only).
31. Figure 2.31 Transmitted bytes in a CoSIP session vs. CoAP confirmed POST requests and responses.
Chapter 03
1. Figure 3.1 Cloud IoT platform architecture.
2. Figure 3.2 Representations of resources are exchanged between endpoints.
3. Figure 3.3 Generic URL structure.
4. Figure 3.4 Applications as finite‐state machines.
5. Figure 3.5 The Richardson maturity model.
6. Figure 3.6 XML‐based RPC.
7. Figure 3.7 URI‐to‐action mapping.
8. Figure 3.8 Resource creation.
9. Figure 3.9 Resource retrieval.
10. Figure 3.10 Resource update.
11. Figure 3.11 Resource deletion.
12. Figure 3.12 Publish/subscribe communication model.
13. Figure 3.13 Example of an XML‐based representation of a session resource carrying SDP session information.
14. Figure 3.14 Session initiation procedure.
15. Figure 3.15 Session terminated by (a) UAC and (b) UAS.
16. Figure 3.16 Session updated by (a) UAC and (b) UAS.
17. Figure 3.17 Network traffic comparison between three session initiation mechanisms: RESTful (CoAP‐based), compressed SIP (re‐using CoAP‐syntax), standard SIP.
18. Figure 3.18 Network traffic comparison between i) CoAP observing and ii) session‐based data flow as a function of the number of exchanged packets (adimensional).
19. Figure 3.19 DNMP message flow for the RP route establishment: locking.
20. Figure 3.20 DNMP message flow for the RP route establishment: route identification.
21. Figure 3.21 DNMP message flow for the RP route establishment: unlocking.
22. Figure 3.22 Picture of the integrated node. A Raspberry Pi hosts a TelosB mote as IEEE 802.15.4 interface and a TP‐LINK as IEEE 802.11s interface.
23. Figure 3.23 IEEE 802.15.4 vs. IEEE 802.11s transmission ranges.
24. Figure 3.24 Experimental results: transmission time as a function of the payload size.
25. Figure 3.25 Experimental results: average transmission time with 95% Confidence Interval (CI), as a function of the number of hops from source to destination.
26. Figure 3.26 Experimental results: packet‐loss rate as a function of the number of hops from source to destination.
27. Figure 3.27 Experimental results: transmission time as a function of the payload size using IEEE 802.15.4 and IEEE 802.11s.
Chapter 04
1. Figure 4.1 Physical Web discovery mechanism.
2. Figure 4.2 Architecture of IoT gateway with internal layers and caching/resource directory capabilities.
3. Figure 4.3 HTTP‐to‐CoAP proxy acting as: (a) reverse proxy and (b) origin server.
4. Figure 4.4 Large‐scale service‐discovery architecture. IoT gateway nodes act as peers of two different P2P overlays. The DLS overlay is used for discovering resources and services: a “white‐pages” service that provides a name resolution service to be used to retrieve the information needed to access a resource. The DGT is used as a “yellow‐pages” service, for learning about the existence of IoT gateway nodes in a certain geographical neighborhood.
5. Figure 4.5 Messages exchanged when a new node joins the network. First, the IoT gateway discovers the resources of a new CoAP server or stores them on behalf of a CoAP client. Finally, DGT and DLS are updated with information about the new node.
6. Figure 4.6 Data retrieval operations: 1) the client C contacts a known IoT gateway GW1; 2) GW1 accesses the DGT to retrieve the list of IoT gateways available in a given area; 3a) GW1 selects one of these IoT gateways, namely GW2; 3b) GW1 discovers the nodes managed by the GW2 through the DLS or directly by contacting GW2; 4) finally, GW1 queries the node, associated with the resource of interest, managed by GW2.
7. Figure 4.7 Service advertisement by CoAP server detected by HTTP‐to‐CoAP proxy.
8. Figure 4.8 Service advertisement by HTTP‐to‐CoAP proxy detected by CoAP client.
9. Figure 4.9 (a) Linear topology considered for multi‐hop Zeroconf‐based service discovery; (b) average time of Zeroconf‐based service discovery on Contiki nodes with linear topology.
10. Figure 4.10 Grid topologies considered for bi‐dimensional deployments of smart objects: (a) Grid‐A (3 hops); (b) Grid‐B (4 hops); (c) Grid‐C (6 hops); (d) Grid‐D (5 hops).
11. Figure 4.11 Average QC/QS times of the Zeroconf‐based service discovery in the grid topologies shown in Figure 4.10.
12. Figure 4.12 Experimental results collected to evaluate the performance of the DLS overlay: (a) average elapsed time for JOIN operations, (b) the average number of rounds (adimensional) for PUT operations, and (c) the average number of rounds (adimensional) for GET operations on the DLS towards the number of active IoT gateways in the P2P network. Plotted data have also been used to construct fitted curves (in red); the formulae of which are reported in the top‐right hand corners.
13. Figure 4.13 Flooding of a DNS‐SD query in generic topology with cycles.
14. Figure 4.14 DNS‐SD query propagation DNS‐SD query propagation with ContikiMAC broadcast. Time is on the ‐axis while node identifiers are on the ‐axis.
15. Figure 4.15 DNS‐SD query propagation with multi‐unicast. Time is on the ‐axis while node identifiers are on the ‐axis.
16. Figure 4.16 Topologies considered for Zeroconf service discovery experimentation with the proposed multicast protocol: (a) linear and (b) grid.
17. Figure 4.17 Time required to perform a DNS‐SD query by a client in linear and grid topologies with broadcast and multiple unicast.
18. Figure 4.18 Overall network energy consumption when a client performs a DNS‐SD query in linear and grid topologies with broadcast and multiple unicast.
Chapter 05
1. Figure 5.1 Comparison between the IoT and the Internet protocol stack for OSI layers.
2. Figure 5.2 Comparison of Internet and IoT security protocols.
3. Figure 5.3 Secure communication with symmetric‐key cryptographic algorithms.
4. Figure 5.4 In‐network data aggregation.
5. Figure 5.5 Interaction between the four roles of the OAuth protocol flow.
6. Figure 5.6 Standard OAuth roles and operation flow. The numbers indicate the sequence.
7. Figure 5.7 IoT‐OAS main procedures: (a) AT grant procedure; (b) SP integration with IoT‐OAS for request authorization. The numbers indicate the sequence.
8. Figure 5.8 Application scenarios: (a) client‐to‐network broker communication; (b) gateway‐enabled communication; (c) end‐to‐end CoAP communication between the external client and the smart object; (d) hybrid gateway‐based communication.
Chapter 06
1. Figure 6.1 The hierarchy of layers involved in IoT scenarios: the fog works as an extension of the cloud to the network edge, where it can support data collection, processing, and distribution.
2. Figure 6.2 (a) Data sources in big data systems. (b) The multiple data sources and listener management in big stream systems.
3. Figure 6.3 Traditional big data architecture for IoT and delay contributions from data generation to applications information delivery. Refer to text for details.
4. Figure 6.4 The proposed listener‐based architecture for the IoT: delay contributions from data generation to consumer information delivery are explicitly indicated.
5. Figure 6.5 The proposed listener‐based graph architecture: the nodes of the graph are listeners and the edges are the dynamic flow of information data streams.
6. Figure 6.6 (a) The concentric linked core and application graphs. (b) Basic processing nodes build the core graph: the outer nodes have increasing complexity.
7. Figure 6.7 Allowed input and output flows for core‐graph and application‐graph nodes.
8. Figure 6.8 Components of the proposed graph‐based cloud architecture and relations between each element.
9. Figure 6.9 Detailed representation of acquisition and normalization blocks.
10. Figure 6.10 Interaction between core and application layers with binding rule.
11. Figure 6.11 Detailed representation of the application register module, with possible actions that may be performed by graph nodes, highlighting ATTACH request steps needed to include an external node in the graph.
12. Figure 6.12 The complete graph cloud architecture, with reference to the data stream flows between all building blocks, from IoT data sources to final consumers.
13. Figure 6.13 Average time related to the acquisition block.
14. Figure 6.14 Average times related to graph framework processing block, showing per‐node time, varying data generation rate, for each subset of nodes deployed into the graph topology.
15. Figure 6.15 Average times related to graph framework processing block, showing per‐node time, varying the subset of nodes deployed into the graph topology, for each evaluated data generation frequency.
16. Figure 6.16 Main building blocks of the proposed listener‐based graph architecture. Nodes in the graph are listeners, edges between nodes represent dynamic flows followed by information streams. Edges can be “open” or “secured”.
17. Figure 6.17 The OFS module manages security in the acquisition and normalization blocks, interacting with an authentication storage entity containing data source identities.
18. Figure 6.18 The application register module structure with security elements. PMSV and GRAN modules interact with a storage entity to manage authorization in the graph.
19. Figure 6.19 Detail of the structure of a single graph node: the decryption module is activated when the node is a listener of a secured stream, while the encryption module is activated if the node generates a secured stream.
20. Figure 6.20 Complete IoT cloud architecture, including proposed security modules and showing different interactions, from incoming stage to final consumer notification.
21. Figure 6.21 Average stream delay (ms) related to graph framework processing block, showing per‐node time, in the case of unsecured communication as well as the case of adoption of symmetric encryption.
22. Figure 6.22 Logarithmic representation of the stream delay as a function of the number of nodes of the graph, evaluated both with and without security mechanisms.
23. Figure 6.23 The IoT nub can manage multiple networks of heterogeneous smart objects and enables access to resources by external consumers that should not be aware of the ow‐level details of communications.
24. Figure 6.24 Protocol stack and functional modules implemented by an IoT Hub.
25. Figure 6.25 Message flow for the polling scenario: a HTTP/CoAP client requests a resource to the cloud platform, which internally selects a suitable IoT Hub replica and forwards the request. The request reaches the smart object only if neither the replica nor the IoT Hub have stored a fresh cached representation of the resource. Other replicas (which are not in the path of the request) are kept in sync using the synchronization protocol.
26. Figure 6.26 Message flow for the observing scenario: a CoAP client requests a resource to the cloud platform using the CoAP Observe option. The cloud platform internally selects a suitable IoT Hub replica and forwards the request. The observe request is then forwarded to the IoT Hub and to the smart object thus creating an “observe chain”. Resource updates are then sent from the smart object back to the IoT Hub, then to the replica, and finally to the CoAP client. Other replicas (which are not in the path of the request) are kept in sync using the synchronization protocol.
27. Figure 6.27 Message flow for the pushing scenario: a smart object acting as a CoAP client posts and updates resources on the IoT Hub, which acts as origin server. All replicas are kept in sync using the synchronization protocol. External client can request resources, which will served by a replica.
28. Figure 6.28 (a) broker‐based message flow between the IoT Hub and its replicas. (b) internal structure of the replica registry module of the IoT Hub.
29. Figure 6.29 (a) Average synchronization time with respect to the number of synchronized resources; (b) average remote resource access time in different application scenarios.
30. Figure 6.30 Average IoT Hub creation time on different cloud platforms.
31. Figure 6.31 Synchronization procedure performed at startup of the replica of an IoT Hub.
32. Figure 6.32 IoT Hub process CPU percentage usage for local (Raspberry Pi node) and remote (Microsoft Azure VM) instances.
33. Figure 6.33 Effect of replica management with respect to the increasing number of requests per second (Microsoft Azure infrastructure).
34. Figure 6.34 Average IoT Hub startup time on a Docker container.
Chapter 07
1. Figure 7.1 Smart object hardware, with (a) radio network interface and (b) wired communication interface.
2. Figure 7.2 The hardware schema and the board image of the TelosB mote platform.
3. Figure 7.3 The Zolertia Z1 platform with board images and main component schema.
4. Figure 7.4 The OpenMote platform with main hardware schema and core board with battery and OpenBase additional modules.
5. Figure 7.5 Classical and Yun versions of the Arduino platform with a detailed representation of the Yun hardware architecture and main components.
6. Figure 7.6 First and second generations of the Intel Galileo platform with board schemas and hardware architecture of main components.
7. Figure 7.7 Main Raspberry Pi boards and revisions.
8. Figure 7.8 OpenWSN protocol stack, highlighting hardware‐independent modules and supported hardware platforms.
9. Figure 7.9 Schematic overview of the TI‐RTOS operating system with main modules and software components.
10. Figure 7.10 Overview of networking architecture for the RIOT operating system.
11. Figure 7.11 Screenshot of Cooja Contiki network simulation for an Ubuntu system with Contiki 2.6 running on 41 nodes forming an IPv6/RPL/6lowpan network.
12. Figure 7.12 The WoTT architecture and protocol stack with emphasis on the role of the IoT Hub in the management of the testbed's heterogeneous network.
13. Figure 7.13 Web, mobile, and wearable REST‐based testbed applications.
14. Figure 7.14 Interaction patterns between wearable devices and smart objects.
15. Figure 7.15 Mobile/wearable application for interaction with smart objects: operational flow with indication of communications and screenshots of the implemented Android application.
16. Figure 7.16 Verification of access grant with IoT‐OAS.
17. Figure 7.17 Specification of message flows for authorization use cases: (a) access to resources for smart object owner; (b) reactive sharing of smart objects; (c) proactive sharing of smart objects.
18. Figure 7.18 Main sections of the Android application: (a) platform authentication with Facebook and Google+; (b) list of owned and shared devices; (c) detail view of a specific device with related permissions.