Textbooks in Telecommunication Engineering

Rolando Herrero

Fundamentals
of IoT
Communication
Technologies
Textbooks in Telecommunication Engineering

Series Editor
Tarek S. El-Bawab,
Professor and Dean,
School of Engineering,
American University of Nigeria
Telecommunications have evolved to embrace almost all aspects of our everyday life, including
education, research, health care, business, banking, entertainment, space, remote sensing,
meteorology, defense, homeland security, and social media, among others. With such progress
in Telecom, it became evident that specialized telecommunication engineering education
programs are necessary to accelerate the pace of advancement in this field. These programs
will focus on network science and engineering; have curricula, labs, and textbooks of their own;
and should prepare future engineers and researchers for several emerging challenges. The IEEE
Communications Society’s Telecommunication Engineering Education (TEE) movement, led
by Tarek S. El-Bawab, resulted in recognition of this field by the Accreditation Board for
Engineering and Technology (ABET), November 1, 2014. The Springer’s Series Textbooks
in Telecommunication Engineering capitalizes on this milestone, and aims at designing,
developing, and promoting high-quality textbooks to fulfill the teaching and research needs
of this discipline, and those of related university curricula. The goal is to do so at both
the undergraduate and graduate levels, and globally. The new series will supplement today’s
literature with modern and innovative telecommunication engineering textbooks and will make
inroads in areas of network science and engineering where textbooks have been largely missing.
The series aims at producing high-quality volumes featuring interactive content; innovative pre-
sentation media; classroom materials for students and professors; and dedicated websites. Book
proposals are solicited in all topics of telecommunication engineering including, but not limited
to: network architecture and protocols; traffic engineering; telecommunication signaling and
control; network availability, reliability, protection, and restoration; network management; net-
work security; network design, measurements, and modeling; broadband access; MSO/cable
networks; VoIP and IPTV; transmission media and systems; switching and routing (from
legacy to next-generation paradigms); telecommunication software; wireless communication
systems; wireless, cellular and personal networks; satellite and space communications and
networks; optical communications and networks; free-space optical communications; cognitive
communications and networks; green communications and networks; heterogeneous networks;
dynamic networks; storage networks; ad hoc and sensor networks; social networks; software
defined networks; interactive and multimedia communications and networks; network appli-
cations and services; e-health; e-business; big data; Internet of things; telecom economics and
business; telecom regulation and standardization; and telecommunication labs of all kinds.
Proposals of interest should suggest textbooks that can be used to design university courses,
either in full or in part. They should focus on recent advances in the field while capturing
legacy principles that are necessary for students to understand the bases of the discipline and
appreciate its evolution trends. Books in this series will provide high-quality illustrations,
examples, problems and case studies. For further information, please contact: Dr. Tarek S.
El-Bawab, Series Editor, Professor and Dean, School of Engineering, American University of
Nigeria, [email protected]; or Mary James, Senior Editor, Springer, mary.james@springer.
com.

More information about this series at http://www.springer.com/series/13835

Rolando Herrero

Fundamentals of IoT
Communication Technologies
Rolando Herrero
Northeastern University
Boston, MA, USA

The solutions and slides for this book can be found at https://www.springer.com/us/book/9783030700805
ISSN 2524-4345 ISSN 2524-4353 (electronic)
Textbooks in Telecommunication Engineering
ISBN 978-3-030-70079-9 ISBN 978-3-030-70080-5 (eBook)
https://doi.org/10.1007/978-3-030-70080-5

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole
or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and
retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter
developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not
imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and
regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed
to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty,
expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been
made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface

What Is This Book About?

The Internet of Things (IoT) is often described as a group of standardized technologies,

systems, protocols, and design principles associated with Internet-connected entities and things
that interact with the physical environment. Although IoT relies on many moving parts, a
basic classification can serve to identify three main components: (1) devices that interact with
the physical environment, (2) applications that perform analytics and extract knowledge from
devices in order to make decisions, and (3) Internet-based communication that provides the
“glue” that ties these two other components together. This book is about this complex latter
component.
Topologies of most IoT architectures are affected by power and computational complexity
constraints that render most traditional communication mechanisms ineffective. IoT commu-
nication technologies attempt to overcome these problems by relying on several overlapping
standard and non-standard protocols designed and developed by multiple organizations ranging
from industry consortia to standardization bodies. This book explores many of these state-of-
the-art protocols and maps them to functionality associated with the different layers of the
well-known layered architectures with special focus on their interaction. Moreover, the book
introduces these mechanisms from a perspective of protocol stacks that support diverse IoT
solutions and use cases like home automation or Industrial IoT (IIoT). Additionally, other
aspects of IoT communication technologies like routing, security, and resource management
are also explored.
To summarize, understanding IoT communication technologies is key to understanding how
IoT works. There is no IoT without dedicated protocols that overcome the limitations of IoT
access networks. This book presents, describes, and investigates the relationship between the
many communication technologies that are essential to the successful deployment of most IoT
solutions.

Why Did I Write This Book?

The motivation for this book is the need of finding a single book that addresses state-of-the-art
IoT networking and communication technologies. Specifically, while teaching “Fundamentals
of IoT” at Northeastern University in Boston, I noticed the lack of “student-ready” material that
can be used to present the most relevant IoT communication technologies. Moreover, because
of the dynamic nature of these protocols, most of the material I use in the class comes from
industry standards. Unfortunately, these standards are not “student-friendly” as they are usually
intended for developers and architects. It is impossible to find a single book, or many for that
matter, that address all the topics relevant to the class. Yes, there are many IoT books out there;
however, there are very few books that focus on IoT communication and networking. Those
that do focus on these topics, however, typically miss the big picture, and their content is fairly
compartmentalized.

v
vi Preface

The main motivation is to introduce a book that:

• provides exclusive focus on IoT communication and networking technologies from a layered
architecture perspective. IoT protocols are presented and classified based on physical, link,
network, transport, and application layer functionality.
• presents and discusses the main families of networking architectures that rely on the IoT
protocols (i.e. LWPAN vs. WPAN).
• introduces use cases and examples that focus on protocol interaction to build network stacks.
• analyzes the impact of the IoT mechanisms on network and device performance with special
emphasis on power consumption and computational complexity.

Of course, these goals comply with the information presented in the previous section.

Intended Audience

The book is intended for advanced undergraduate-level or introductory graduate-level students

as well as for practicing engineers, technologists, and system architects who wish to learn and
understand the principles of IoT communication and networking technologies. The assumption
is that the reader is familiar with mainstream communication and networking fundamentals
including some basic knowledge of signals and systems.

Book Organization

This book follows a progression that starts with a description of IoT and how IoT fits in
the context of conventional communication systems; it continues by presenting IoT protocols
from a perspective of the layered architecture and concludes by focusing on advanced topics
associated with IoT. This content is delivered in three parts:

• Part I—Understanding IoT Communications: It deals with the bases of IoT communications
that are the building blocks needed to understand architectures and topologies. It includes
two chapters. Chapter 1 provides an introduction that details the evolution of IoT, discussing
components and the main differences when compared to traditional networking. Chapter 2
focuses on the topologies and the interaction between the different players involved in IoT
networking.
• Part II—IoT Network Layers: It explores the different communication layers of standard
IoT solutions. It includes three chapters. Chapter 3 introduces the physical and link layers
of wireless and wireline IoT technologies. Chapter 4 explores the network and transport
layers including adaptation mechanisms to enable IoT physical and link layer protocols to
support IPv6. Chapter 5 deals with the application layers that support the establishment and
maintenance of IoT sessions.
• Part III—Advanced IoT Networking Topics: It reviews the advanced IoT networking topics
that complement the protocols presented in Part II. It includes four chapters. Chapter 6
explores the different mechanisms used for resource identification and management. Chap-
ter 7 focuses on the technologies that provide traffic routing and message forwarding.
Chapter 8 presents a wide range of full and hybrid IoT LPWAN industry standards. Chapter 9
introduces Thread, a popular home automation WPAN architecture.

It is recommended that these parts and chapters are read in sequential order as there are
many dependencies among them.

Boston, MA, USA Rolando Herrero

October 2020
Contents

Part I Understanding IoT Communications

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 M2M and IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Layered Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Use Case: IoT Applied to UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Why Now? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Concepts of IoT Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 IoT Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Types of Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 Actuators and Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Part II IoT Protocol Layers

3 Physical and Link Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 About Physical and Link Layers… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Wireline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2 ITU-T G.9903 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3 IEEE 1901.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4 MS/TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.2 IEEE 802.15.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.3 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.4 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3.5 ITU-T G.9959 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.6 DECT ULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.7 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vii
viii Contents

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4 Network and Transport Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 Why IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.3.1 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.2 Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3.3 Routing and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.4 Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.5 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3.6 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.7 TCP and 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.4 6Lo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.1 Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2 Request/Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.1 REST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.2 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.2.3 XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.2.4 CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.2.5 SIP and RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.2.6 OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.3 Publish/Subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.3.2 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Part III Advanced IoT Networking Topics

6 Resource Identification and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.1 IoT Services and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.2 mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.2.1 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.2.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.2.3 mDNS Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.3 SD-DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.4 CoAP Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.4.1 Distributed CoAP Resource Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.4.2 Centralized CoAP Resource Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.5 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.5.1 Addressing and Discovery Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.5.2 Description Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.5.3 Control, Eventing, and Presentation Steps . . . . . . . . . . . . . . . . . . . . . . . 166
Contents ix

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7 Routing on Constrained Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.1 Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.2 WSN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.2.1 Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.2.2 Gossiping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.2.3 SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.2.4 Directed Diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
7.2.5 LEACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.2.6 PEGASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.3 RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.3.1 DODAG Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.3.2 Storing and Non-storing Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
7.3.3 Loop Detection and Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
7.3.4 RPL, 6LoWPAN, and ND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.4 LOADng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
7.4.1 Minimal Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7.4.2 Smart Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
8 LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.1 LPWAN in IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.2 LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.2.2 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.3 SigFox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
8.3.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
8.3.2 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
8.4 D7AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
8.4.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
8.4.2 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
8.4.3 Other Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
8.5 Weightless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
8.5.1 Physical and Link Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.6 NB-IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
8.6.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
8.6.2 Link and Upper Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
8.7 More LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
8.7.1 NB-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
8.7.2 IQRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8.7.3 RPMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8.7.4 Telensa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
8.7.5 SNOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.7.6 Nwave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.7.7 Qowisio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.7.8 IEEE 802.15.4k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.7.9 IEEE 802.15.4g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.7.10 LTE-M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
8.7.11 EC-GSM-IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
x Contents

8.7.12 5G and B5G Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

8.7.13 IPv6 Support Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9 Thread Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.1 Thread and IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.2 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
9.3 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.4 Why Not RPL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
9.5 Thread Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
9.6 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.7 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9.8 Thread Network Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9.9 OpenThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Homework Problems and Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Acronyms

3GPP 3rd Generation Partnership Project

5G NSA 5G Non-Standalone
5G SA 5G Standalone
6LoBAC IPv6 over BACnet
6LoBTLE IPv6 over Low power Bluetooth Low Energy
6LoPLC IPv6 over Power Line Communication
6LoWPAN IPv6 over Low power Wireless Personal Area Networks
6P 6top Protocol
6TiSCH IPv6 over TSCH
6top 6TiSCH Operational Sublayer
AA Authoritative Answer
AC Alternating Current
ACE Authentication and Authorization for Constrained Environments
ACL Access Control List
ADC Analog to Digital Converter
AES Advanced Encryption Standard
AGC Automatic Gain Control
AH Authentication Header
AI Artificial Intelligence
AIFS Arbitrary Interframe Spacing
AMI Alternate Mark Inversion
AMQP Advanced Message Queuing Protocol
ANCOUNT Answer Count
AoA Angle of Arrival
AoD Angle of Departure
API Application Program Interfaces
APS Application Support Layer
ARCOUNT Additional Count
ARM Advanced RISC Machine
ARP Address Resolution Protocol
ARQ Automatic Repeat reQuest
AS Access Stratum
ASCII American Standard Code for Information Interchange
ASK Amplitude Shift Keying
ASN Absolute Slot Number
ATM Adaptive Tone Mapping
ATP Association Timeout Period
AWGN Additive White Gaussian Noise
B5G Beyond 5G
BAN Body Area Network
BER Bit Error Rate
BFD Bidirectional Forwarding Detection

xi
xii Acronyms

BLE Bluetooth Low Energy

bppb bits per pixel per band
bps bits per second
BPSK Binary PSK
BSS Basic Service Set
BSSID BSS Identifier
CA Certificate Authority
CAP Contention Access Period
CBC Cipher Block Chaining
CBOR Concise Binary Object Representation
CDMA Code Division Multiple Access
CFS Contention Free Slot
CIoT Celullar IoT
CISF Contention Interface Spacing
CNAME Canonical Name
CoAP Constrained Application Protocol
COBS Consistent Overhead Byte Stuffing
codec Coder/Decoder
CONNACK Connection Acknowledgment
CoSIP Constrained SIP
CPI Cyclic Prefix Insertion
CPS Cyber Physical System
CPU Central Processing Unit
CRC Cyclical Redundancy Checking
CS Circuit Switching
CSM Central Management System
CSMA/CA Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD Carrier Sense Multiple Access with Collision Detection
CSRC Contributing Source
CSS Chirp Spread Spectrum
ct content type
CTA Channel Time Allocation
CTAP Channel Time Allocation Period
CTS Clear to Send
D7AAvP D7A Advertising Protocol
D7ANP D7A Network Protocol
D7AP DASH7 Alliance Protocol
D7ASP D7A Session Protocol
D7ATP D7A Transport Protocol
DA Destination Address
DAC Digital to Analog Converter
DAD Duplicate Address Detection
DAE Destination Address Encoding
DAM Destination Address Mode
DAO DODAG Advertisement Object
DBPSK Differential BPSK
DC Direct Current
DCF Distributed Coordination Function
DCI Downlink Control Information
DECT ULE DECT Ultra Low Energy
DECT Digital Enhanced Cordless Telecommunications
DIFS Distributed Inter Frame Spacing
DIO DODAG Information Object
Acronyms xiii

DIS DODAG Information Solicitation

DLC Data Link Control
DMRS Demodulation Reference Signal
DNS Domain Name System
DODAG Destination Oriented Directed Acyclic Graph
DOFDM Distributed OFDM
DoS Denial of Service
DPA Direct Peripheral Access
DPSK Differential PSK
DRS Dynamic Rate Shifting
DSAP Destination Service Access Point
DSCP Differentiated Services Code Point
DSP Digital Signal Processing
DSSS Direct Sequence SS
DS-UWB Direct Sequence Ultra Wideband
DTLS Datagram Transport Layer Security
DTX Discontinuous Transmissions
DV Distance Vector
ECC Elliptic-Curve Cryptography
EC-GSM-IoT Extended Coverage GSM IoT
ECN Explicit Congestion Notification
EDCF Enhanced DCF
EDR Enhanced Data Rate
eDRX Extended Discontinuous Reception
EID Extension Identifier
EMI Electromagnetic Interference
eMTC Enhanced Machine Type Communication
eNB eNode Base Station
EoF End of Frame
EPC Evolved Packet Core
EPS Evolved Packet System
ESP Encapsulating Security Payload
ESS Extended Service Set
ETag Entity Tag
ETSI European Telecommunications Standards Institute
ETX Expected Transmission
EUI Extended Unique Identifier
E-UTRAN Evolved UMTS Terrestrial Radio Access Network
FCS Frame Checksum
FDD Frequency Division Duplex
FDMA Frequency Division Multiple Access
FEC Forward Error Correction
FED Full End Device
FFD Full Function Devices
FHC Frame Control Header
FHSS Frequency Hopping SS
FIB Forwarding Information Base
FOV Field of View
FQDN Fully Qualified Domain Name
FSF Frame Control Field
FSK Frequency Shift Keying
Gbps Gigabits per second
GFSK Gaussian FSK
xiv Acronyms

GMSK Gaussian Minimum Shift Keying

GPIO General Purpose Input and Output
GPS Global Positioning System
GPU Graphical Processing Unit
GSM Global System for Mobile Communications
GUA Global Unicast Addresses
H2M Human-to-Machine
HAL Hardware Abstraction Layer
HAN Home Area Network
HARQ Hybrid Automatic Repeat reQuest
HC1 Header Compression 1
HC2 Header Compression 2
HEC Hybrid Error Correction
HIP BEX HIP Base Exchange
HIP DEX HIP Diet Exchange
HIP Host Identity Protocol
HPCW High Priority Contention Window
HS High Speed
HSS Home Subscriber Server
HTML Hypertext Markup Language
HTTP HyperText Transfer Protocol
HTTPU HTTP over UDP
HVAC Heating, Ventilation and Air conditioning
I2 C Inter Integrated Circuit
I/O Input/Output
IANA Internet Assigned Numbers Authority
IBSS Independent BSS
ICMP Internet Control Message Protocol
IE Information Element
IETF Internet Engineering Task Force
if interface description
IID Interface Identifier
IIoT Industrial Internet of Things
IKE Internet Key Exchange
IoT Internet of Things
IP TTL IP Time to Live
IP Internet Protocol
IPHC IP Header Compression
IPSec IP Security
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
ISI Inter Symbol Interference
ISM Instrument, Scientific and Medical
ISO International Organization for Standardization
IV Initialization Vector
JID Jabber Identifier
JTAG Joint Test Action Group
Kbps Kilobits per second
KC Key Control
KEK Key Encryption Key
KI Key Index
KIM Key Identifier Mode
Acronyms xv

KS Key Source
L2CAP Logical Link Control and Adaptation Protocol
LAN Local Area Network
LBR Low Power PAN Border Router
LDPC Low Density Parity Check
LEACH Low Energy Adaptive Clustering Hierarchy
LECIM Low Energy, Critical Infrastructure Monitoring
LFU Least Frequently Used
LHIP Lightweight HIP
LIDR Light Detection And Ranging
LKM Link Margin
LLC Link Layer Control
LLCP Logical Link Control Protocol
LLLN Low Power, Low Rate and Lossy Network
LLN Low Power and Lossy Network
LOAD Lightweight On-demand Ad-hoc Distance Vector
LOADng LOAD Next Generation
LoRa Long Range
LPWAN Low Power Wide Area Network
LS Link State
LSB Least Significant Bit
LTE Long Term Evolution
LTN Low Throughput Networks
M2M Machine to Machine
M2P Multipoint to Point
MAC Media Access Control
Mbps Megabits per second
MCTA Management Channel Time Allocation
mDNS Multicast DNS
MED Minimal End Device
MEIP Media over IP
MEMS Micro Electro Mechanical Systems
MeshCoP Mesh Commissioning Protocol
MFR MAC Footer
MHR MAC Header
MIB Master Information Block
MIC Message Integrity Code
MIMO Multiple Input Multiple Output
MLE Mesh Link Establishment
MMC Modified Miller Code
MME Mobility Management Entity
MPDU MAC Protocol Data Unit
MPL Multicast Protocol for Low Power and Lossy Networks
MQTT Message Queue Telemetry Transport
MQTT-SN MQTT for Sensor Networks
MS/TP Master Slave/Token Passing
MSB Most Significant Bit
MSDU MAC Service Data Unit
MSF Minimal Scheduling Function
MSSIM Mean Structural Similarity
MTC Machine Type Communication
MTR Multi-Topology Routing
MTU Master Slave/Token Passing
xvi Acronyms

NA Neighbor Advertisement
NACK Negative Acknowledgment
NAS Non-Access Stratum
NAT Network Address Translation
NB Narrow Band
NB-Fi Narrowband Fidelity
NB-IoT Narrow Band IoT
ND Neighbor Discovery
NFC Near Field Communication
NHC Next Header Compression
NPBCH Narrowband Physical Broadcast Channel
NPCW Normal Priority Contention Window
NPDCCH Narrowband Physical Downlink Control Channel
NPDSCH Narrowband Physical Downlink Shared Channel
NPRACH Narrowband Physical Random Access Channel
NPSS Narrowband Primary Synchronization Signal
NPSSS Narrowband Secondary Synchronization Signal
NPUSCH Narrowband Physical Uplink Shared Channel
NR New Radio
NRS Narrowband Reference Signal
NS Neighbor Solicitation
NSEC Next Secure
NUD Neighbor Unreachability Detection
NZR Unipolar Nonreturn to Zero
OFDM Orthogonal Frequency Division Multiplexing
OOK On-Off Keying
OPC UA Open Platform Communications United Architecture
OPCODE Operation Code
OQPSK Offset QPSK
OS Operative System
OSI Open Systems Interconnection
P2P Point to Point
PAM Pulse Amplitude Modulation
PAN ID PAN Identifier
PAN Personal Area Network
PCA Priority Channel Access
PCF Point Coordination Function
PDR Packet Delivery Ratio
PDU Packet Data Unit
PEGASIS Power-Efficient Gathering in Sensor Information Systems
P-GW Packet Data Node Gateway
PID Proportional Integral Derivative
PINGREQ Ping Request
PINGRESP Ping Response
PKI Public Key Infrastructure
PLC Power Line Communication
PNC Piconet Coordinator
PRB Physical Resource Block
PS Packet Switching
PSK Phase Shift Keying
PSKc Pre-Shared Key for the Commissioner
PSM Power Saving Mode
PSNR Peak Signal to Noise Ratio
Acronyms xvii

PTYPE PDU Type

PUBACK Publish Acknowledgment
PUBCOMP Publish Complete
PUBREC Publish Received
PUBREL Publish Release
QAM Quaddrature Amplitude Modulation
QDCOUNT Question Count
QoS Quality of Service
QPSK Quaddrature PSK
QR Query/Response
RA Recursion Available
RA Router Advertisement
RADAR Radio Detection And Ranging
RAP Random Access Procedure
RCODE Response Code
RD Recursion Desired
REED Router Eligible End Device
RERR Route Error
REST Representational State Transfer
RF Radio Frequency
RFD Reduced Function Devices
RFID Radio Frequency Identification
RFTDMA Random Frequency and Time Division Multiple Access
RIP Routing Information Protocol
RIPng RIP Next Generation
RISF Response Interface Spacing
ROLL Routing over Low Power and Lossy Networks
RPL Routing for Low Power
RPMA Random Phase Multiple Access
RR Receiver Report
RR Resource Record
RRC Radio Resource Control
RREP Route Reply
RREP-ACK RREP Acknowledgment
RREQ Route Request
RS 232 Recommended Standard 232
RS 485 Recommended Standard 485
RS Router Solicitation
RSSI Received Signal Strength Indicator
rt resource type
RTC Real Time Communication
RTCP Real Time Control Protocol
RTOS Real Time Operating System
RTP Real Time Transport Protocol
RTS Request to Send
RU Resource Unit
RZ Unipolar Return to Zero
SA Source Address
SAA Stateless Address Autoconfiguration
SAE Source Address Encoding
SAM Source Address Mode
SAP Service Access Point
SCADA Supervisory Control And Data Acquisition
xviii Acronyms

SCEF Service Capability Exposure Function

SC-FDMA Single Carrier FDMA
SCHC Static Context Header Compression
SCTP Stream Control Transmission Protocol
SD-DNS Service Discovery DNS
SDES Source Description
SDN Software Defined Network
SDP Session Description Protocol
SDR Software Defined Radio
SDW Software Defined WAN
SF Scheduling Function
SFD Start Frame Delimiter
S-GW Serving Gateway
SIB System Information Block
SIFS Short Inter Frame Spacing
SigComp Signal Compression
SIP Session Initialization Protocol
SNAP Subnetwork Access Protocol
SNOW Sensor Network Over White Spaces
SNR Signal to Noise Ratio
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SoC System on Chip
SoF Start of Frame
SoM System on Module
SONAR Sound Navigation And Ranging
SPI Serial Peripheral Interface
SPIN Sensor Protocols for Information via Negotiation
SPIN-BC SPIN Broadcast
SPIN-EC SPIN Energy Conservation
SR Sender Report
SS Spread Spectrum
SSAP Source Service Access Point
SSDP Simple Service Discovery Protocol
SSIM Structural Similarity
SSRC Synchronization Source
SUBACK Subscribe Acknowledgment
SWD Serial Wire Debug
SWoT Social Web of Things
sz maximum size
TC Truncation
TCP Transport Control Protocol
TDD Time Division Duplex
TDMA Time Division Multiple Access
TG4g IEEE 802.15.4g Task Group
TG4k IEEE 802.15.4k Task Group
TLS Transport Layer Security
TLV Type-Length-Value
TMF Thread Management Framework
TMSP Time Synchronized Mesh Protocol
TPC Transmit Power Control
TSCH Time Slotted Channel Hopping
TTL Time to Live
Acronyms xix

TTN The Things Network

UAC User Agent Client
UART Universal Asynchronous Receiver Transmitter
UAS User Agent Server
UAV Unmanned Aerial Vehicle
UDP User Datagram Protocol
UE User Equipment
ULA Unique Local Unicast Addresses
UNB Ultra Narrow Band
UNSUBACK Unsubscribe Acknowledgment
UPnP Universal Plug and Play
URI Uniform Resource Identifier
URL Uniform Resource Locator
V2I Vehicle to Infrastructure
V2V Vehicle to Vehicle
V2X Vehicle to Everything
VAD Voice Activity Detection
VoIP Voice over IP
VoLTE Voice over LTE
VPN Virtual Private Network
WAN Wide Area Network
WAVE Wireless Access in Vehicular Environment
Weightless SIG Weightless Special Interest Group
WEP Wired Equivalent Privacy
Wi-Fi Wireless Fidelity
Wi-SUN Wireless Smart Utility Networks
WLAN Wireless Local Area Network
WPA Wi-Fi Protected Access
WPA2 Wi-Fi Protected Access II
WPAN Wireless Personal Area Network
WSN Wireless Sensor Network
WUR Wake Up Radio
XEP XMPP Extension Protocol
XLEACH eXtended LEACH
XMPP eXtensible Messaging and Presence Protocol
ZCL ZigBee Cluster Library
ZDP ZigBee Device Profile
 Part I
Understanding IoT Communications

This part of this book, that includes two chapters, deals with the bases of IoT communications
that are the building blocks needed to understand architectures and topologies. Chapter 1
provides an introduction that addresses the evolution of IoT, discussing components and the
main differences with traditional networking schemes. The chapter also introduces a use case
that explores some of the technologies and mechanisms that are presented later in this book.
Chapter 2 focuses on the topologies and the interaction between the different players involved
in IoT networking. It describes wireless sensor networks (WSNs) and their importance in the
context of modern IoT networks.
 Introduction
1

only exist in the context of a processor or computer memory.

1.1 M2M and IoT However, for them to be transmitted to the application, they
must be first sent over the analog channel. This implies the
Understanding IoT communication requires understanding presence of an additional stage where these digital values are
its origins and progression throughout the years. IoT results converted, through a modulator (M), back into an analog
from the evolution of several other technologies like wireless signal. This signal, known as a modulated wave, traverses
sensor networks (WSNs) and machine-to-machine (M2M) the analog channel, and when it arrives at the far end, it is
communication. M2M is heavily linked to IoT due to their demodulated by means of a demodulator (DM). The DM
many similarities. Although the distinction between M2M converts the analog signal into digital temperature readouts
and IoT has been an area of great debate, there is a consensus and associated controlled redundancy. The controlled redun-
on what their main differences are [14]. dancy is removed by the channel decoder (CD) that restores
M2M communication systems rely on devices and ap- the digital temperature readouts. Since the application is an
plications interacting, without any human intervention, over algorithm that is run by a piece of software, there is no
wireless and wireline channels. Each of these entities trans- need to convert the information any further. At this point,
mits and receives data and supports basic functionality that the application uses the temperature readouts as samples that
includes source encoding, channel encoding, and modula- can be processed by a generic Proportional Integral Deriva-
tion. In general, each full duplex bidirectional link between tive (PID) controller algorithm. The application decides and
two devices is composed of two independent half duplex increases or decreases the flow of coolant by transmitting
unidirectional links. In a typical M2M scenario, where a an actuation flow rate. Since this value is already digital, it
device and an application communicate with each other, the is processed by a CE that introduces controlled redundancy
latter sends requests to the former to sense some meaningful to improve reliability. The digital rate and its associated
environment parameter or asset that can be used, in turn, by redundancy are modulated and converted into a modulated
the application to make an automated decision. For example, wave that is transmitted over the channel. When the signal
the device could be an engine, while the application could arrives at the engine, it is demodulated and processed by the
be a piece of software that based on the device internal CD. Because the engine is an analog device, the digital flow
temperature would decide on the flow rate of coolant injected rate is converted by a source decoder (SD) into an analog
in the engine. This scheme represents a traditional communi- value that is applied to the coolant flow regulator of the
cation system that is integrated by the series of components engine. The same way that source encoding is performed by
that are shown in Fig. 1.1. An analog signal generated by an ADC, source decoding is carried out by a digital-to-analog
the temperature sensor is converted to the digital domain, converter (DAC).
compressed by means of a source encoder (SE) and then For most communication systems [8], not just M2M
processed through a channel encoder (CE). Essentially, the scenarios, the functionality provided by SE, SD, CE, CD, M,
SE converts the analog temperature signal into digital read- and DM is typically mapped in layers that ease software and
outs by relying on an analog-to-digital converter (ADC) that firmware implementation and deployment. More details of
performs sampling and quantization. The CE, in turn, adds these layered architectures in the context of not only M2M
controlled redundancy to the readouts in order to improve re- but also IoT are discussed in Sect. 1.2 and further presented
liability when they are transmitted over the noisy channel. By in Chap. 2.
virtue of being digital, readouts and controlled redundancy

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 3

R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_1
4 1 Introduction

Fig. 1.1 M2M communication

digital analog digital analog
system

CD DM M CE SE

PID CHANNEL

CE M DM CD SD

PID PID controller

CD channel decoder
DM demodulator
M modulator
CE channel encoder
SE source encoder
SD source decoder
CD channel decoder

As it can be inferred from the example above, M2M usu- a communication channel to an application. The application,
ally involves proprietary mechanisms where source, chan- in turn, processes the readout and makes a decision that may
nel encoding, as well as modulation are not standardized. or may not involve actuation. If it does involve actuation, the
Moreover, many legacy M2M scenarios are not even nec- application transmits over the channel a command or some
essarily digital, and, in many cases, just plain modulation other relevant piece of information that is used by the actuator
and demodulation are good enough to provide some basic to perform a specific action against the environment.
functionality. Telemetry, which represents the quintessential Typical M2M applications just deal with one type of
M2M application, relies on the remote measurement of a pa- parameter (i.e. temperature, humidity, speed, inventory level)
rameter that is processed at some monitoring station. An early where a simple decision is made (i.e. open or close a valve).
example of analog telemetry includes the synchro which is Lack of standardization, which manifests by the lack of
a variable coupling transformer where the magnitude of the communication protocols, many times plays against M2M
magnetic coupling between the primary and secondary varies applications and devices attempting to interact with each
in accordance with the position of a rotable element. The other.
Panama Canal, completed in 1914, relied on the extensive Because single-device scenarios limit the level of automa-
use of synchros to monitor locks and water levels. This tion that a particular system can have, it is just natural to
and other telemetry mechanisms evolved for decades until try to expand them by incorporating multiple devices. A
1968 when the digital Supervisory Control And Data Ac- more complex solution with multiple heterogeneous devices
quisition (SCADA) system became that standard technology associated with multiple heterogeneous parameters implies a
for distributed measurement and control. Although initially horizontal approach to the machine communication problem.
SCADA systems were built from mainframe computers and A horizontal approach, in turn, requires a standard mecha-
required intensive human supervision to operate, they eventu- nism to enable communication between dissimilar devices.
ally became more automated and therefore more compatible Traditional M2M frameworks, unfortunately, do not usually
with the M2M paradigm [18]. provide such a mechanism [14]. Luckily, the Internet Pro-
Another example of well-known M2M systems are the tocol (IP) can be used as the fundamental building block to
programmable logic controllers that consist of an industrial enable this integration. Specifically, IP serves as the glue
computer with several digital input and output ports that can that connects different devices with different applications
be used for sensing and actuation [6]. These devices usually and leads to what it has been called the Internet of Things
include built-in wireline communication ports that rely on (IoT). IoT is consequently a superset of traditional M2M
physical and data link mechanisms ranging from low-rate schemes that is only possible due to standardization by means
RS-232 to high-rate Ethernet. of IP. Figure 1.2 illustrates the difference between M2M and
Because most M2M applications involve devices that are IoT deployments. Each scenario shows three cyber-physical
remotely monitored and controlled by other devices that systems (CPSs) where in every CPS a device (D1 , D2 , or
make decisions, these architectures tend to be vertical in D3 ) interacts with a single asset (i.e. temperature, humidity,
nature. Specifically, a sensor interacts with the environment speed, inventory level). The sensor data generated by each
by sampling and generating a readout that is transmitted over CPS reaches three separate applications (A1 , A2 , and A3 ).
1.2 Layered Architectures 5

Fig. 1.2 M2M vs IoT CPS CPS CPS CPS CPS CPS

asset asset asset asset asset asset

device device device device device device

D1 D2 D3 D1 D2 D3

VERTICAL
VERTICAL
IP

A1 A2 A1 A2 A3
A3
application application application application application application

M2M IoT
HORIZONTAL

Under traditional vertical M2M communication, applications power wireless personal area networks (6LoWPAN), that,
neither share data nor make global decisions that affect more among many things, compress fields and lift some of the
than one CPS. On the other hand, under horizontal IoT, a restrictions on the size of packets [20].
single super application that encompasses A1 , A2 , and A3
makes decisions that affect all three CPSs. Moreover, sensor
traffic from the different CPSs reaches the super application 1.2 Layered Architectures
by means of IP communication.
In the long run, IoT is intended to rely on the automated M2M and IoT communication systems represented by the
IP interaction of billions of devices all over the globe. How- functional blocks described in Sect. 1.1 are difficult to im-
ever, IoT relies on IP version 6 (IPv6) addresses that over- plement, take too long to develop, and are very expensive
come the well-known IP version 4 (IPv4) address shortage. to maintain. A more efficient approach consists in mapping
Specifically, IPv4 relies on 32-bit addresses that can only these functions into multiple layers that can be indepen-
support up to 232 ≈ 4300 × 106 addresses. On the other dently updated. For example, while modulation and source
hand, IPv6 relies on 128-bit addresses that account for up encoding are, respectively, mapped into physical and ap-
to 2128 ≈ 3000 × 1035 addresses. IPv4 network address plication layers, channel encoding is distributed over mul-
translation (NAT) mechanisms that have a goal to overcome tiple layers that provide great functional granularity and
the address shortage require network infrastructure changes enable additional mechanisms like security and networking
that make them impractical. Moreover, since NATting relies support.
on using transport layer ports to provide additional network Under a layered architecture, each layer is a black box
layer, addressing it constitutes a violation of the traditional with an input that processes the output of the layer under-
IP layered architecture described in Sect. 1.2. neath, and an output becomes the input of the layer above.
Using IPv6 “as is” on IoT applications is not usually pos- The exchange of data between layers is performed by means
sible because IPv6 exhibits some characteristics that make of standardized interfaces supported by the input and output
it incompatible with most IoT scenarios. Specifically, IoT is facilities [15]. Granularity and standardization ease imple-
typically associated with devices that produce and consume mentation and make system maintenance a lot simpler and
small chunks of data, so it is advantageous to keep the cheaper. Essentially, network software updates apply only to
network overhead as negligible as possible. Long 128-bit ad- those layers that oversee the specific functionality that needs
dresses and IPv6 limitations on the minimum size of packets to be upgraded.
put heavy restrictions on certain IoT wireless and wireline In a layered architecture, layers can be made “shorter” or
technologies. These problems are minimized by introducing “taller” by, respectively, removing and adding more func-
IoT-specific adaptation mechanisms, like IPv6 over low- tions. To an extreme, a flat architecture is one where all
6 1 Introduction

Fig. 1.3 Flat vs layered

architectures

MODULATOR DEMODULATOR

FLAT ARCHITECTURE
one sensor – one application

MODULATOR DEMODULATOR

MODULATOR
DEMODULATOR

two colocated sensors – two applications

LAYERED ARCHITECTURE

DEMODULATOR

MODULATOR
SWITCH

DEMODULATOR

one sensor – two applications

functions are performed by a single layer. Too many layers OSI IETF
can also be a problem due to the extra overhead associated layer 7 application application layer 5
with handling them. To understand the advantages of a lay- layer 6 presentation
layer 5 session transport layer 4
ered architecture when compared to a flat one, consider the
layer 4 transport network layer 3
example in Fig. 1.3. The system consists of a temperature network
layer 3
sensor transmitting readouts to multiple applications. In a flat link control layer 2
layer 2 link control
architecture, the support of two applications requires two co- layer 1 physical physical layer 1

located sensors transmitting readouts since every device and

application relies on a single layer providing all functionality. Fig. 1.4 IETF vs OSI stacks
In general, each additional application requires changes of
the sensing infrastructure. Flat architectures are inflexible Although there are several models that can be used to
with simple topology changes requiring complex scenario represent layered architectures, the two most important ones
modifications. This results in higher costs and longer de- are the Open Systems Interconnection (OSI) and the Internet
ployment times that can affect the overall feasibility of the Engineering Task Force (IETF) models. The stacks of layers
solution. On the other hand, a layered architecture supports of these two models are comparatively shown in Fig. 1.4.
packet switching that enables a single application to simul- The OSI model introduces seven layers. First, the physical
taneously communicate with multiple endpoints. Essentially, layer is dedicated to the transmission and reception of data
each layer processes information that has been segmented in over the channel including the conversion of information be-
units of packets that can be queued and transmitted through- tween the digital and the analog domains. This layer involves
out the network. In a layered IoT architecture, the support of physical phenomena including traditional signal modulation
additional endpoints does not require dramatic changes of the and demodulation. Second, the link layer provides error
network infrastructure. control mechanisms for reliable transmission of information
1.3 System Components 7

over the channel. Third, the network layer ensures that in- vices interact with assets, while applications interact with
formation packets are delivered to the destination. Fourth, enterprise processes. Devices are sensor, controllers, and
the transport layer provides support of multiplexing of traffic actuators typically running on small constrained embedded
from different applications. Fifth, the session layer oversees computers based on system-on-chip (SoC) and system-on-
managing multiple sessions between applications. Sixth, the module (SoM) hardware. A SoC is a chip that provides a
presentation layer provides formatting of information for central processing unit (CPU), memory, storage, input/output
further processing including security extensions for encryp- digital and analog interfaces, and radio-frequency (RF) signal
tion and decryption. Seventh, the application layer involves processing. A SoC may also include a graphical processing
application-specific services as well as the conversion of unit (GPU) and support for several peripherals. On the other
information between the digital and analog domain. Packets hand, a SoM is a circuit board that includes a SoC in addition
at each layer receive different names; they are called mes- to some other discrete chips that provide additional function-
sages at the application layer, they are called segments at ality.
the transport layer, they are called datagrams at the network The communication channel is the medium that enables
layer, and they are called frames at the link layer. The five- the propagation of signals between devices and applications.
layer IEFT model is similar to the OSI model with the main Because, in a traditional sensor-application scenario, signal
difference being that OSI layers 5 through 7 are mapped propagation is usually from multiple devices to a single ap-
into a single application layer. Since IoT is based on Internet plication, it is called multipoint-to-point (M2P). In a layered
technologies originally specified by IETF, this book follows architecture, simultaneous communication between multiple
the IETF layered architecture model as the main mechanism devices and an application is efficiently carried out by means
to build IoT protocols, frameworks, and solutions [17]. of network packet switching. Moreover, being an IoT sys-
tem a superset of several interacting M2M subsystems, the
channel is a critical component that integrates devices and
1.3 System Components application and where the standardization of communication
protocols is key.
Two additional and very important components are needed Embedded devices are resource constrained; they have
for IoT communication to work, a device and an applica- very little memory and exhibit very low computational capac-
tion. Summarizing, in its simplest format and as illustrated ity in order to minimize power consumption to extend battery
in Fig. 1.5, an IoT scenario typically involves three main life. Low power consumption also limits transmission rates
fundamental components: (1) devices, (2) a communica- and signal coverage. The communication between a device
tion channel, and (3) an application performing analytics. and an application may involve signals traversing different
These components interact with the “outside world”; de- channels that affect the very nature of the communication
protocol stacks and the network itself. Specifically, the con-
version between different protocols at each layer, as signals
assets traverse channels, is performed by IoT gateways. Gateways,
depending on the protocol complexity, range from simple
embedded devices to more complex specialized equipment
devices [19].
Although IoT is associated with several types of networks,
there are two main types: (1) wireless personal area networks
IoT/M2M Components

(WPANs) and low-power wide-area networks (LPWANs).

The difference between them is the trade-off between cov-
channel
erage and transmission rate. LPWAN is associated with very
low transmission rates (up to 50 Kbps) over long distances
(in the order of kilometers). On the other hand, WPAN com-
paratively provides higher transmission rates (in the order
of Mbps) but supports shorter distances (in the order of
hundreds of meters). Both technologies rely on devices com-
application (analytics)
municating with gateways that provide access to applications
through the Internet core. Under LPWAN, this connectivity is
one-hop with direct communication between a device and the
enterprise processes gateway. Under WPAN, the connectivity is multi-hop with a
single device communicating with the gateway by relying on
Fig. 1.5 M2M/IoT components intermediate devices to propagate its data. This latter scenario
8 1 Introduction

Fig. 1.6 WPAN vs LPWAN ACCESS CORE

device
device GW IP application
WPAN gateway
device

LPWAN device
GW
IP application

device
ACCESS CORE

range

is called mesh connectivity and enables WPAN to operate domain by means of the modulator. This signal, which
over long distances at a cost of the additional latency intro- is transmitted over the channel, is characterized by
duced by the packet forwarding of the intermediate devices. its bandwidth. The bandwidth is measured in units of
WPANs support end-to-end IP connectivity by relying on Hertz (Hz). Through the modulation technique, a larger
gateways. These gateways are fairly simple components that analog bandwidth is usually associated with a higher
just convert lower layer traffic (physical and link layers). digital transmission rate. The demodulated analog
LPWANs do not typically support end-to-end IP connectivity, wave is converted back into digital information that
and their gateways are more complex as they convert full arrives at the receiver at a rate known as throughput.
stacks of protocols. Throughput, as the transmission rate, is measured in
Figure 1.6 shows the difference between a WPAN and units of bps. Because of network impairments like
an LPWAN. As it can be seen, the portion of the network network packet loss, throughput is usually lower than
between the devices and the gateway is called the access side, the transmission rate. The relationship between these
while everything else is called the core side or backbone. three parameters is shown below:
Note that the WPAN supports multiple devices connected
in mesh to increase access side coverage. Additionally, the
trans mission band width throughput
WPAN gateway is fully IP compliant, while the LPWAN ... CE
rate
M ... DM
gateway, on the other hand, only supports IP on one inter- transmitter
[bps] [Hz] [bps]
receiver

face [1].
In the context of IoT, applications typically perform
operational analytics to extract knowledge from the data Applications deal with knowledge, while devices deal
generated by devices. This knowledge is used, in turn, with data. An IoT communication system is partially respon-
to make automated actuation decisions and to provide sible for facilitating the conversion from data to knowledge.
visualization for human interaction. Knowledge extraction is Essentially devices collect data that is highly redundant.
a complex subject that is outside the scope of this book. Given that devices are constrained, and transmission rates
It relies on several techniques ranging from traditional are low, data is compressed by the devices before transmis-
statistical and predictive analysis to machine learning and sion. This compression is known as the data-information
data mining. conversion that attempts to lower throughput in order to
optimize channel utilization and lower power consumption to
 Transmission Rate vs Bandwidth vs Throughput One extend battery life. Depending on topologies and scenarios,
important distinction in communication systems is more data-information conversions may be performed in
the difference among transmission rate, bandwidth, other network entities like gateways. When the information
and throughput. The transmission rate represents how arrives at the application, it is processed in what it is called
much digital information is being transmitted over the information-knowledge conversion [22, 16]. This is a sce-
communication path. It is measured in units of bits nario compatible with cloud computing, but this processing
per second (bps). It typically includes the redundancy can be partially performed in entities that are closer to the
added by the CE. Note that the transmission rate is device. Depending on how close they are, the situation can
sometimes referred to as network bandwidth. The be representative of mist computing and fog computing sce-
digital bits are converted into a signal in the analog narios.
1.4 Use Case: IoT Applied to UAVs 9

Fig. 1.7 Data transformation device channel application

example

10°C 10°C 10°C

10°C alarm
10°C
13°C 13°C 13°C
>< 80°C
13°C ok
13°C
13°C
82°C 82°C 82°C alarm
time

82°C
82°C

data information knowledge

Figure 1.7 illustrates an example of data to knowledge

transformation in an IoT scheme. A temperature sensor pe- (continued)
riodically transmits readouts to an application. Since these the transmission rate. The information then arrives at
readouts are highly redundant, the device just sends tem- the application that runs an algorithm to convert it into
perature values whenever a change is detected. This data- knowledge in order to make a decision that results in
information conversion reduces the amount of network traf- actuation.
fic, decreases the transmission rate, and lowers power con-
sumption in order to prolong battery life. The information is
used by the application to determine whether the temperature
1.4 Use Case: IoT Applied to UAVs
at the sensor location is too high. Its goal is to convert infor-
mation into knowledge by means of a threshold comparison
Let’s focus now on an introductory IoT use case that involves
that triggers an alarm that can be used, in turn, to perform
several different protocols and mechanisms that fall under
actuation. Of course, this is a very simple example of ana-
the umbrella of the topologies and architectures discussed
lytics being performed by the application. Moreover, due to
in the previous sections. Unmanned aerial vehicles (UAVs)
its simplicity, the procedure could be easily performed on the
are excellent candidates of IoT automation since they can
device. In more generic scenarios, however, the information-
be used for remote sensing and more specifically to capture
knowledge conversion is complex enough that can only be
hyperspectral images [12]. Hyperspectral images are made of
performed by an application.
data cubes, which, including a few dozens of spectral bands,
support different applications ranging from the detection of
Example 1.1 Consider the communication system land vegetation to the monitoring of atmospheric products
shown in Fig. 1.1. What components are responsible derived from the processing of lower-level radiance informa-
for the data-information and the information- tion.
knowledge conversions? Essentially UAVs can capture these images and perform
on-board compression as part of the data-information con-
version. Information is then transmitted to an application that
Solution The data-information conversion is per- by means of real-time image processing makes flight path
formed at the SE since it converts an analog tempera- decisions in order to zoom in and obtain other images of
ture signal into digital readouts that result from ADC interest. The processing performed by the application is part
sampling and quantization. The SE also includes an of the information-knowledge conversion. To summarize,
embedded processor that performs data compression raw images are converted at each UAV into information by
and removes redundancy in a controlled way in order means of compression techniques and then transmitted to
to generate information. The overall goal is to lower the application that transforms the information into knowl-
edge through image processing mechanisms. Knowledge is
(continued)
used, in turn, to change the flight path in order to support
10 1 Introduction

zooming and resolution changes that enable additional fine- only possible by means of multi-hop communications where
tuning required for analysis. Compression at the UAV is a UAV communicates with the planner through intermediate
performed by means of a hyperspectral image coder/decoder UAVs that forward packets. The drawback of this scheme is
(codec) that takes a raw image as input and produces a overhead and latency. Similarly, power limitations condition
lossy compressed image as output. Lossy compression is long-range LPWAN links to be low rate.
a term used to describe the compression mechanism that The idea behind a hybrid network architecture is to rely on
removes non-essential information in order to lower its size. the high-latency WPAN for the transmission of hyperspectral
Lossy compression leads to noise due to the distortion intro- images and rely on the low-latency LPWAN for transmission
duced by the removal of such information. In general, codec- of sensor and flight control information. In general, due to the
based compression is a lot less computationally complex than nature of each network, different technologies are typically
the image classification performed by the application and used. Traditionally, WPAN technologies range from IEEE
therefore a lot more suitable for an embedded device like a 802.11 (Wi-Fi) to IEEE 802.15.4. Similarly, LPWAN tech-
UAV. nologies include a myriad of mechanisms like narrowband
The autonomy of the UAVs is such that it covers an area IoT (NB-IoT) and LoRa. Note that within the family of
divided into multiple subareas known as cells of size Acell . WPAN protocols, some technologies like IEEE 802.15.4,
Cells are scanned by UAVs by taking hyperspectral pictures when compared to others like IEEE 802.11, exhibit certain
of the different parts of the cell. The size of the area covered LPWAN features like lower rate and larger coverage. This is
by a single image is given by Aimage . The application, in particularly important in the context of this use case where
the context of this scenario, is called mission planner. The IEEE 802.15.4 and IEEE 802.11n, respectively, provide low-
planner resides at a ground station and calculates flight paths rate LPWAN and high-rate WPAN communications.
of UAVs to efficiently coordinate the mission by considering The planner extracts knowledge by means of image
environmental parameters like wind and weather conditions processing- and machine learning-based classification. Note
as well as terrain information and other inputs from the that these tasks cannot be performed at a UAV since the
UAVs. Moreover, the mission planner controls the movement required computational complexity is too high. Moreover,
of the UAVs and receives in return location information, because computational complexity is related to power
such as Global Positioning System (GPS) positions, and other consumption, even if computation were possible, the extra
sensory information from the UAVs. processing could lead to battery drain that would render the
Communication between the planner and the UAVs is solution impractical. Therefore, UAVs are only in charge of
through a hybrid network, shown in Fig. 1.8, that com- less intensive hyperspectral image compression.
bines a high-rate WPAN and a low-rate LPWAN. UAVs Each cell is scanned by one UAV using a mounted camera
are powered by batteries such that energy consumption is with resolution of Rpx × Rpy (pixel). The resolution results
a limiting factor that conditions high-rate WPAN links to from a trade-off between processing capabilities associated
exhibit short-distance coverage. Long-distance coverage is with lossy compression and transmission rates. In fact, de-
pending on the codec and the compression algorithm under
consideration, the compressed image results in a stream of
Mimage bits. Each image covers an area Aimage that includes
distance

multiple spectral bands. Additionally, each band is rectan-

LPWAN
gular with a k aspect ratio given by the ratio of the width
cell to the height of the image and a field of view (FOV) given
image WPAN
by the length of the diagonal of the rectangle. By changing
altitude, UAVs can zoom in and zoom out by, respectively,
decreasing and increasing the FOV. Note that the covered area
is calculated as
   
FOV FOV
Aimage = k × √ × √
k2 + 1 k2 + 1

where the relationship between k and FOV is shown in

planner Fig. 1.9. The total amount of data transmitted on a given
UAV-to-UAV link, defined as Mcell , is given by
`
distance
Mcell = n × Mimage
Fig. 1.8 Hybrid network
1.4 Use Case: IoT Applied to UAVs 11

peak transmission of 600 Mbps and a coverage of 100 m.

height
FOV k=
width Because an IEEE 802.11n radio supports multiple spectral
height bands in addition to those supported by the IEEE 802.15.4
radio, interference can be greatly minimized. More details of
width
these and other technologies are presented in Chap. 3.
Fig. 1.9 Aspect ratio k vs FOV The brain of the UAV is a SoM that interacts with the
autopilot and enables both IEEE 802.11n and IEEE 802.15.4
connectivity. This SoM runs Ubuntu Core, a well-known
Linux distribution intended for IoT systems, that supports the
upper layer protocol stacks, including drivers and applica-
tions, for interaction with the planner. By keeping the weight
of the UAVs low, many advantages can be accomplished: (1)
battery consumption is reduced, (2) UAVs can fly higher,
(3) UAVs can fly longer, (4) UAVs can fly faster, and (5) in
case of malfunctioning, liability due to physical and personal
damage can be greatly minimized. Unfortunately, low-weight
systems are also computationally less complex and support
slower communications because of smaller batteries. Addi-
tionally, low-weight systems support fewer add-on modules
and are more likely to have UAV flight instability issues
due to the presence of the hyperspectral camera and the
external antennas. The hyperspectral camera is a fast 60 g
80 mm×97 mm×159 mm camera that captures 25,650×990
spectral bands that can be used, among other things, for land
vegetation detection.
Leaving IP connectivity and routing issues aside, dis-
cussed in detail in Chap. 4, we can focus on the mechanisms
Fig. 1.10 UAV winglet to transmit low-rate sensor and flight control information as
well as high-rate hyperspectral images [9]. Low-rate traffic
transmitted over IEEE 802.15.4 relies on the Constrained
where n = AAimage
cell
is the number of images scanned in each Application Protocol (CoAP) [21]. CoAP is a lightweight
cell. and highly efficient protocol that enables the management
The UAV is a winglet, illustrated in Fig. 1.10, that has a of IoT sessions. More importantly, CoAP supports Repre-
wingspan of 0.8 m and a weight of 1/2 kg including a hyper- sentational State Transfer (REST) transactions that optimize
spectral camera. A single electrical motor drives a propeller the interaction of the entities involved in the communication.
that enables the UAV to fly. A lithium polymer battery gives Figure 1.11 illustrates the flow of the CoAP transactions
the UAV an autonomy of half an hour. The average linear used for the transmission of sensor and flight control in-
speed is about 10 m/s, and the maximum altitude is around formation [10]. First, the planner transmits a CoAP GET
400 m high. Each UAV has an autopilot that provides, among request to observe the sensor readouts originated at the UAV.
other things, a GPS unit and pressure as well as inertial Observation is a feature associated with REST and adopted
sensors. The autopilot also gives UAVs automated takeoff by certain protocols like CoAP that enables an observed
and landing capabilities as well as mechanisms to navigate device to transmit readouts whenever parameter changes are
through a set of waypoints dynamically programmed by detected. Observation removes the need of an application
the planner. In this solution, the low-rate communication to be constantly polling a device. In that figure, dash lines
between UAVs and planner is by means of a IEEE 802.15.4 identify both the original GET request and the UAV CoAP
radio that enables a 250 Kbps peak transmission and a 1 km 2.05 Content updates that carry readouts from sensors. These
coverage. Although this low rate is good enough for transmis- updates are real-time processed and used, in turn, by the
sion of actuation and sensor traffic that includes control mes- application to send CoAP POST requests with lists of way-
sages and status information, it is not high enough to support points that define the flightpath. Solid lines identify each
compressed hyperspectral images. To that end, the UAV also POST request and its corresponding acknowledgment carried
has a multi-antenna Multiple Input-Multiple Output (MIMO) in an empty 2.05 Content message. More details of CoAP are
IEEE 802.11n radio that provides high throughput with a presented in Chap. 5.
12 1 Introduction

NON-FEC 4⁄ FEC 4⁄ FEC

3 TX 3 RX
TX RX TX RX
planner UAV
processing

x
x x

lost #2 lost #3 lost none

Fig. 1.12 FEC

processing

media quality issues. Specifically, the communication links

between UAVs and the planer rely on radio propagation
that is mainly by the way of scattering over surfaces and
diffraction over and around them in a situation typical of a
multipath scenario that usually results in signal fading that
causes network packet loss. Note that SIP, RTP, and SDP are
discussed in detail in Chap. 5.
Network packet loss can be prevented and minimized by
processing

the intensive use of forward error correction (FEC), negative

acknowledgment (NACK), as well as a combination of both
approaches known as hybrid error correction (HEC) [11].
All these mechanisms have been widely used in the context
of conventional media. In this solution, however, FEC is
applied due to two main reasons: (1) it is computationally
simple and (2) it exhibits very low latency. Moreover, FEC
Fig. 1.11 CoAP traffic is independently applied to both uplink and downlink media
streams. The IETF RFC 5109 standardizes a mechanism
to encode generic FEC information via separate RTP FEC
On critical issue with this solution is how to efficiently
streams negotiated by means of SIP. Since the standard
transmit hyperspectral images from the UAVs to the planner.
does not recommend any concrete FEC mechanism and just
Since hyperspectral images are responsible for high-
provides the general guidelines for correct signaling of FEC
throughput traffic, well-known real-time communication
information, a generic bidimensional parity code is used.
(RTC) mechanisms similar to those used in Voice over
Specifically, the payloads of two consecutive hyperspectral
IP (VoIP) solutions can be applied to IoT. The goal
data cube RTP packets are XORed together into a single FEC
is to rely and extend traditional RTC protocols for
RTP payload.
transmission of compressed hyperspectral images. In this
To understand the implications of FEC, we can look at
context, RTC consists of two different components: (1)
Fig. 1.12 that shows an example of traffic being transmitted
signaling that refers to the exchange of information between
with and without FEC. If FEC is disabled, lost network
entities in order to establish a session and (2) media that
packets result in lost packets at the application level. This
is about the transmission of the hyperspectral images
is shown in the left flow in the figure. If the packet #2 is
themselves. Signaling provides extensions for negotiation
lost, the application is not able to process it. On the other
of hyperspectral image codecs by means of the Session
hand, if FEC is enabled, redundant packets are transmitted to
Description Protocol (SDP) that runs in the context of the
compensate for those packets dropped by the network layer.
more generic Session Initialization Protocol (SIP). Media, on
The relationship between redundant and original packets is
the other hand, is transmitted over the Real-Time Transport
given by the code rate defined as the ratio k/n where n is the
Protocol (RTP) that runs on top of User Datagram Protocol
total number of transmitted packets (redundant and original)
(UDP). UDP provides some minimal sequence and timing
and k is the number of original packets. A 3/4 code rate in-
control but lacks any data integrity protection. This causes
dicates that every four transmitted packets, three are original
RTP traffic to be affected by network loss that leads to
and one is redundant. There are many ways to specify how
1.4 Use Case: IoT Applied to UAVs 13

Fig. 1.13 SIP and RTP traffic

Hyerspectral
planner UAV camera

capture delay

coding delay

the redundant packet should be generated. One possibility

v=0
is randomly selecting one out of the three original packets
o=hyperspectral 53123232 2323154545 IN IP4 example.com
and retransmitting it. This leads to application layer packet s=SDP image example
loss if the network drops any of the other two packets that c=IN IP4 192.168.1.8
do not have redundant copies. This is shown in the middle t=0 0
m=image 5000 RTP/AVP 96
flow in Fig. 1.12. If packet #3 is lost, the application is not a=rtpmap:96 mblpc
able to process it since it has no redundant packet associated a=sendrecv
with it. Alternatively, by XORing all three data packets into
a single redundant FEC packet, it is possible to recover up to
Fig. 1.14 SDP offering
one of the lost original packets. Specifically, and as shown
in the figure, if the packet #3 is lost, this packet can be
recovered from the redundant packet by XORing all other Figure 1.13 shows a media session between the planner
received packets; that is, #1 ⊕ #2 ⊕ (#1 ⊕ #2 ⊕ #3) = #3. and a UAV to request a single hyperspectral image. Note
Therefore, the XOR operation (⊕) provides a simple mech- that although communication is from a UAV to a planner,
anism to encode information about all three original packets traffic may flow through multiple intermediate UAVs. A
in a single redundant packet. Because image compression hyperspectral image is transmitted through the interaction of
payloads are typically of variable length, XORing requires SIP, RTP, and SDP. First, the planner requests a new session
padding packets with zeros to make them all the same size. by transmitting a SIP INVITE message that includes an SDP
Each hyperspectral image is well over 80 MBytes of section, shown in Fig. 1.14, that identifies the offered hy-
raw data that can be compressed by means of the mblpc perspectral codec as well as transport parameters associated
hyperspectral codec [12]. In order to minimize throughput with the RTP traffic. The UAV then accepts the request and
and network load, the codec is configured to provide lossy issues a 200 OK response that also includes an SDP section
compression as a trade-off between rate and distortion. The that specifies the negotiated codec and transport parameters.
rate is inversely related to the distortion, such that higher The planner then sends a SIP ACK message to terminate the
transmission rates are associated with lower image quality. three-way handshake. At this point, the planner transmits a
Because different applications require different quality lev- sequence of RTP packets (in accordance with the negotiated
els, they also provide different average transmission rates. session) to request a partial or full hyperspectral image.
14 1 Introduction

When the UAV receives this request, its camera captures

an image (taking around 25 ms per spectral band) that is (continued)
compressed, packetized (chunked into several packets), and rate. Note that because dtrans  dprop , the propagation
transmitted back to the planner. Reliability against network delay can be typically ignored and the delay can be
impairments is introduced by means of FEC RTP packets that considered as d ≈ dtrans = 1.53 ms. This is even
are transmitted alongside the original RTP traffic. more noticeable when considering IoT-friendly IEEE
802.15.4 where a R  = 0.25 × 106 bps transmission
Example 1.2 Consider the SIP flow in Fig. 1.13, and rate leads to a d ≈ 3 × RL = 30.72 ms delay.
assume that the distance between the UAV and the
planner is 200 m. How long does it take for the session The payload of each RTP packet includes specific infor-
to be established when assuming a realistic Wi-Fi mation that applies to both uplink and downlink. For those
5 Mbps rate in this scenario? What happens if 250 originated at the planner and sent to a UAV, each packet
Kbps IEEE 802.15.4 networking were used instead? includes control information that specifies the list of spectral
Assume average packet sizes of 320 bytes. Consider bands that are requested. Figure 1.15 shows the specific fields
only propagation and transmission delays. included in each packet. Specifically, an 8-bit sequence num-
ber that specifies the hyperspectral image being requested is
followed by a variable number of groups of spectral bands.
Solution Since there is no packet loss, the transmission These groups are indicated by an 8-bit start and end band
rate and throughput are identical. The delay specifies fields that specify the band numbers associated with each
how fast the first RTP packet can be sent. This can group. Downlink packets originated at a UAV and sent to
be done as soon as the SIP ACK is transmitted. The the planner include the compressed data cubes encoded as
propagation delay is given by how long it takes for the illustrated in Fig. 1.16. Each response includes an 8-bit se-
SIP INVITE and SIP 200 OK to be propagated. This is quence number that specifies the data cube being transmitted.
given by dprop = 2 × dc = 1.34 µs where c is the speed This sequence number matches that of the incoming request.
of light given by c = 300 × 106 m/s and d = 200 m The response includes an 8-bit band number that specifies the
is the distance between UAV and planner. Note that spectral band number being encoded as well as a 16-bit index
using the speed of light in this calculation is a best- that represents the incremental index number of the portion
case scenario assumption as an electromagnetic wave of spectral band included in the payload. Additionally, the
propagates slightly slower in regular (non-vacuum) payload includes a 16-bit size field that indicates the length
channels. of the portion of hyperspectral band data along with the
The transmission delay is given by how long it takes compressed portion of the band itself.
for the SIP INVITE, SIP 200 OK, and SIP ACK to be One issue with wireless IoT communications is the prob-
transmitted. This is given by dtrans = 3 × RL = 1.53 ms lem caused by the characteristics of the fading channel. This
where L = 8 × 320 bytes = 2560 bits is the packet is a well-known phenomenon that can be modeled by the two-
size and R = 5 × 106 bps is the Wi-Fi transmission state Markov process shown in Fig. 1.17 [13]. The model
(continued)
Fig. 1.16 Packetization of
hyperspectral images sequence number 0-7
Fig. 1.15 Packetization of
sequence number 0-7
control information band 8-15
start band 8-15
index 16-31
end band 16-23
start band 24-31
size 32-47
end band 32-39

data
start band

end band
1.4 Use Case: IoT Applied to UAVs 15

Fig. 1.17 Fading channel p

high low
α loss rate loss rate
1-p

1-α

relies on two states such that the channel is either in a low-loss Table 1.1 Effects of FEC in transmission of hyperspectral images
state or in a high-loss state. While in low-loss state packets PSNR (dB) MSSIM
may be dropped, the loss probability is lower than when the α p No FEC FEC No FEC FEC
channel is in the high-loss state. Transitions are given by two 0.01 0.01 42.91 45.28 0.90 0.94
main parameters: (1) p, the transition probability from low- 0.01 0.05 39.11 43.83 0.86 0.92
to high-loss states, and (2) α, the probability that the channel 0.01 0.10 35.74 41.71 0.79 0.89
stays in a high-loss state. The assumption is that all packets 0.05 0.01 40.39 44.16 0.86 0.92
are dropped when the channel is in a high packet loss state, 0.05 0.05 36.09 41.49 0.81 0.89
while no packets are lost if the channel is in a low packet loss 0.05 0.10 32.75 40.10 0.77 0.86
state. From this model, it is clear that the nature of the channel 0.10 0.01 37.17 41.07 0.83 0.88
is such that bursty packet loss is likely to occur because when 0.10 0.05 31.66 39.49 0.74 0.86
the channel is in a high-loss state, several packets may be 0.10 0.10 27.48 37.63 0.68 0.83
dropped before the channel transitions back to the low-loss 0.15 0.01 32.71 39.85 0.76 0.86
state. 0.15 0.05 25.11 37.12 0.69 0.82
One way to assess the efficiency of the solution, evaluating 0.15 0.10 21.05 33.52 0.64 0.79
its resilience against fading and other performance problems,
is to check the quality of the transmitted hyperspectral im-
ages. Although there are many algorithms that can be used Table 1.1 shows PSNR values as well as MSSIM scores for
to assess image quality, there are only a few that are effective transmission of hyperspectral images with and without FEC-
when considering the effects of network impairments. To this assisted RTP transport. These values incorporate the effects
end, the evaluation of data cube quality can be performed of lossy compression due to the mblpc codec configured to
by means of different technologies including peak signal-to- provide a compression rate of around 1 bits per pixel band
noise ratio (PSNR) and structural similarity (SSIM). These (bppb). The measured transmission rates are 1.608 Mbps and
mechanisms provide quality scores that can be used to un- 2.575 Mbps for RTP and FEC-assisted RTP, respectively.
derstand the degradation introduced by the encoding and Note that, as expected, there is high correlation between
packetization in a lossy environment. PSNR provides the PSNR values and MSSIM scores and that the best results
ratio between the energy of the hyperspectral and the energy are obtained when FEC is enabled. In this latter case, the
of the error between the image and its reference. SSIM is maximum PSNR and MSSIM improvements are 12 dB and
used to measure the similarity between images by means of 20%, respectively. As the bursty packet loss intensifies, when
comparing local patterns of pixels and considering the strong both α and p go up, the overall improvement becomes
interdependency of sections that are spatially close [23]. more significant. This can be better seen with a graphical
SSIM scores range from −1 to 1 where 1 is only achievable example; Fig. 1.18 shows PSNR as a function of the network
when a received image is identical to its reference. The SSIM loss for both low and high loss burstiness. It is important
scores that result from all spectral bands in an image are to mention that although this scheme relies on basic XOR
averaged to obtain a mean structural similarity (MSSIM) FEC, other more efficient alternatives like Reed-Solomon
score that represents the quality of a data cube. (RS) codes, turbo codes (TC), and low-density parity-check
(LDPC) codes can be used instead.
16 1 Introduction

Fig. 1.18 PSNR vs loss

45

40

PSNR(dB)
35

30

25 No FEC (low loss burstiness)

FEC (low loss burstiness)
No FEC (high loss burstiness)
FEC (high loss burstiness)
20
0.02 0.04 0.06 0.08 0.1 0.12 0.14
p

through big data distributed data mining mechanisms. Virtu-

1.5 Why Now? alization that provides multiple independent execution envi-
ronments to run different applications on the same hardware
One of the main questions is why now?, that is, why has IoT and enable the conversion from hardware-specific systems to
become so popular in the last few years? Although remote inexpensive software-based solutions [3].
sensing and actuation have been around for well over a From the perspective of this book, however, the most
century at this point, there are specific technological and sci- relevant breakthroughs are on the communication and net-
entific developments, shown in Fig. 1.19, that have led to the working sides. This includes ubiquitous Internet access that
IoT explosion. On the device side: material science improve- is instantaneously available everywhere and provides cheap
ments including microelectromechanical systems (MEMS) end-to-end connectivity. Networking technologies that are
used to build micro-sized sensors and actuators, printable standardized through different mechanisms ranging from
electronics that enable fast and cost-effective development physical layer wireless IEEE 802.15.4 and wireline Power
of embedded devices, and smart textiles for the creation Line Communication (PLC) to application layer Message
of next-generation wearables [5]. Energy production and Queue Telemetry Transport (MQTT) and the aforementioned
storage advancements that include smart grids to generate CoAP. This book focuses on these and many other protocols
electricity through affordable photovoltaic panels and energy and technologies, detailing their interaction as well as their
harvesting that relies on miniaturized ultracapacitors and most important features and characteristics including secu-
batteries [4]. Embedded processing developments that result rity, resilience in a constrained environment to support power,
from cheaper and computationally more complex SoM and and transmission efficiency.
SoC platforms that are essential to sensors and actuators that
include lightweight, low-power 32-bit and 64-bit Advanced
RISC Machine (ARM) processors and the support of several
Input/Output (I/O) and networking interfaces and ports in a 1.6 Applications
very small footprint [7].
On the application and analytics side: software archi- IoT applications span over several industries relying on mul-
tecture evolution toward Open Application Program Inter- tiple overlapping technologies. Of all industries, however,
faces (APIs) and REST interfaces that based on the web consumer electronics is probably the one that has evolved the
paradigm extend the Service-Oriented Architecture (SOA) to most with the introduction of IoT. Some common consumer
IoT. Specifically, SOA is a system design approach where electronics applications are connected gadgets, wearables,
applications use the services that are available in the network. robotics, and participatory sensing that tied to the Social
Decision-making support by means of knowledge frame- Web of Things (SWoT) enables users to use their sensors’
works supported by artificial intelligence (AI) technologies readouts in order to share relevant information like traffic
like machine learning that rely on huge data sets accessible and pollution conditions. IoT applications in the retail bank-
Homework Problems and Questions 17

Fig. 1.19 Developments that MEMS

lead to IoT printable electronics
Material Science smart textiles
smart grids
DEVICES Energy Production and Storage energy harvesting
SoM and SoC
Embedded Processing ARM processors
I/O
Soware Architectures APIs
REST
ANALYTICS
APPLICATION
Decision Making knowledge framework
big data
Virtualizaon execution enviroments
software based solutions
Ubiquitous Internet Access instatanous everywhere access
NETWORKING end-to-end connectivity
Technologies standardization
IEEE 802.15.4, PLC, MQTT, CoAP …

ing industry involve micro payments, logistics, product life- that natively support IPv6 with Protocol Stack Virtualization
cycle information, and shopping assistance. The automobile (PSV) techniques that enable the deployment of massive IoT
industry is also being affected by IoT through autonomous solutions.
cars and multi-modal transport that enables the coordination
for end-to-end delivery of goods. Another sector to consider
is agriculture where IoT applications include forestry, farm-
ing, livestock monitoring, and urban agriculture that enables Summary
small-scale farming in cities and other highly populated
zones [14]. IoT is driven by several scientific and technological break-
The environmental industry initially by means of WSNs throughs and developments that provide an evolution that
and now with IoT has improved applications intended to starts with traditional M2M and WSN schemes. This chapter
sense pollution and monitor air, water, soil, and weather. explored this evolution by introducing an overview of the
The infrastructure industry, on the other hand, relies on main concepts needed to understand IoT. It detailed the
IoT advancements to provide home and building automation convenience of the layered architecture as a model for de-
including access control as well as monitoring of roads and sign, development, and deployment of IoT communication
railroads. Similarly, public utility companies are also starting technologies. The chapter presented a quick overview of
to take advantage of IoT and enhancing their services by the main IoT components and how they lead to the two
means of smart grids; water, gas, as well as oil management; most popular IoT network topology families: WPANs and
and heating and cooling control and monitoring. The health LPWANs. These topologies are put in the context of a use
industry is another sector that has been heavily disrupted case that supports IoT communication with UAVs. Other
by IoT; this includes remote monitoring of health, assisted relevant IoT applications ranging from home automation to
living, behavioral change, treatment compliance, and fitness IIoT are also discussed.
applications. A whole new industry that is based on the
smart city concept has resulted from IoT; some areas of
interest are integrated environments, sustainability, and in-
clusive living. IoT has also resulted in improved industrial Homework Problems and Questions
processes with applications ranging from simple automation
and remote operations to resource management and robotics 1.1 In an M2M scenario, an application performs image
including manufacturing and control of heavy machinery. processing of a video stream captured by a camera and
This has led to IIoT that is a key factor in the context of the unlocks a door when the right person is identified:
Fourth Industrial Revolution also known as Industry 4.0 [2].
Other critical elements of the IoT evolution include the (a) Describe the different elements of the communication
integration of newer and more efficient LPWAN technologies system
18 1 Introduction

camera

application

door lock

(b) Indicate what components transform data into informa- 3. Geng, H.: Internet of Things and Data Analytics in the Cloud with
tion Innovation and Sustainability, pp. 1–28 (2017)
4. Geng, H.: Internet of Things and Smart Grid Standardization, pp.
(c) Indicate what components transform information into 495–512 (2017)
knowledge 5. Geng, H.: MEMS, pp. 147–166 (2017)
6. Geng, H.: Scada Fundamentals and Applications in the IoT, pp.
1.2 Based on addressing capabilities alone and ignoring 283–293 (2017)
7. Hassan, Q.F.: A Tutorial Introduction to IoT Design and Prototyp-
other NAT limitations, when comparing IPv6 to IPv4 with
ing with Examples, pp. 153–190 (2018)
NAT support, which one provides the largest address space? 8. Haykin, S.: Communication Systems, 5th edn. Wiley, New York
How much larger is it? (2009)
9. Herrero, R.: Real time transmission of hyperspectral images on-
board UAVs. In: 4th AETOS International Workshop on “Research
1.3 In the transformation example of Fig. 1.7, each tempera-
Challenges for Future RPAS/UAV Systems”
ture readout is a 1-byte number, and the extracted knowledge 10. Herrero, R.: MQTT-SN, CoAP, and RTP in wireless IoT real-time
can be encoded as a 1-bit number. What are the compression communications. Multimed. Sys. (2020). https://doi.org/10.1007/
rates for each transformation? The compression rate is given s00530-020-00674-5
11. Herrero, R., Cadirola, M.: Effect of FEC mechanisms in the per-
by the ratio between the uncompressed and compressed
formance of low bit rate codecs in lossy mobile environments. In:
values. Proceedings of the Conference on Principles, Systems and Appli-
cations of IP Telecommunications, IPTComm ’14. Association for
1.4 In Fig. 1.6, why is the WPAN gateway inside the IP Computing Machinery, New York (2014). https://doi.org/10.1145/
2670386.2670387
cloud, while the LPWAN one is not?
12. Herrero, R., Cadirola, M., Ingle, V.K.: Preprocessing and com-
pression of Hyperspectral images captured onboard UAVs. In:
1.5 What are the implications of combining OSI session, Carapezza, E.M., Datskos, P.G., Tsamis, C., Laycock, L., White,
presentation, and application layers into a single IETF ap- H.J. (eds.) Unmanned/Unattended Sensors and Sensor Networks
XI; and Advanced Free-Space Optical Communication Techniques
plication layer?
and Applications, vol. 9647, pp. 8–16. International Society for
Optics and Photonics, SPIE (2015). https://doi.org/10.1117/12.
1.6 What components are responsible for the data- 2186169
information and information-knowledge conversion stages 13. Hohlfeld, O., Geib, R., Hasslinger, G.: Packet loss in real-time
services: Markovian models generating QoE impairments. In: 2008
in the use case in Sect. 1.4? What type of conversion does
16th International Workshop on Quality of Service, pp. 239–248
each stage involve? (2008). https://doi.org/10.1109/IWQOS.2008.33
14. Holler, J., Tsiatsis, V., Mulligan, C., Avesand, S., Karnouskos, S.,
1.7 In Figs. 1.13 and 1.11, respectively, consider an average Boyle, D.: From Machine-to-Machine to the Internet of Things:
Introduction to a New Age of Intelligence, 1st edn. Academic, New
RTP image packet size of 1000 bytes transmitted every
York (2014)
12 ms and an average 2.05 Content packet size of 10 bytes 15. Kurose, J.F., Ross, K.W.: Computer Networking: A Top-Down
transmitted every 1 ms. Ignoring any additional overhead due Approach, 6th edn. Pearson, London (2012)
to lower layers, what channel capacity is minimally expected 16. Lucero, S., et al.: IoT platforms: enabling the internet of things.
White paper (2016)
for WPAN and LPWAN networks?
17. Palattella, M.R., Accettura, N., Vilajosana, X., Watteyne, T.,
Grieco, L.A., Boggia, G., Dohler, M.: Standardized protocol stack
for the internet of (important) things. IEEE Commun. Surv.
Tutorials 15(3), 1389–1406 (2013)
18. Ravi Kumar, K.S., Gottapu, J., Mandarapu, C., Rohit, M.S.,
References Murthy, T.V.N., Mavuri, M.: Introduction to M2M communication
in smart grid. In: 2015 International Conference on Control,
1. Al-Sarawi, S., Anbar, M., Alieyan, K., Alzubaidi, M.: Internet Instrumentation, Communication and Computational Technologies
of things (IoT) communication protocols: review. In: 2017 8th (ICCICCT), pp. 250–254 (2015)
International Conference on Information Technology (ICIT), pp. 19. Sethi, P., Sarangi, S.R.: Internet of things: architectures, protocols,
685–690 (2017) and applications. J. Electr. Comput. Eng. 2017, 9324035 (2017).
2. Conway, J.: The industrial internet of things: an evolution to a smart https://doi.org/10.1155/2017/9324035
manufacturing enterprise. White paper (2015)
References 19

20. Shelby, Z., Bormann, C.: 6LoWPAN: The Wireless Embedded 22. Siow, E., Tiropanis, T., Hall, W.: Analytics for the internet of things:
Internet. Wiley, Chichester (2010) a survey. ACM Comput. Surv. 51(4) (2018). https://doi.org/10.
21. Shelby, Z., Hartke, K., Bormann, C.: The Constrained Application 1145/3204947
Protocol (CoAP). RFC 7252 (2014). https://doi.org/10.17487/ 23. Wang, Z., Bovik, A.C., Sheikh, H.R., Simoncelli, E.P.: Image
RFC7252. https://rfc-editor.org/rfc/rfc7252.txt quality assessment: from error visibility to structural similarity.
Trans. Img. Proc. 13(4), 600–612 (2004). https://doi.org/10.1109/
TIP.2003.819861
 Concepts of IoT Networking
2

Examples of free propagation include wireless broadcast and

2.1 IoT Networking satellite channels. In the context of IoT, the decision between
relying on a wireless and relying on a wireline solution is
From a functional perspective, an IoT network, like most related to device deployment costs and times. Specifically,
packet switched networks, is made of two types of devices: in order to support a massive number of devices, wireline
endpoints that are known as hosts and are source or desti- solutions usually require huge infrastructure changes that
nation of messages and routers that assist in the propagation are too expensive and take too long to implement. Wire-
of messages throughout the network. Both, hosts and routers, less architectures with battery-powered devices are the most
form communication systems with transmitters and receivers common type of IoT deployment. Alternatively, wireline
connected to channels by means of links. Each router sup- scenarios that take advantage of preexistent power wiring for
ports multiple hosts that, in turn, are connected to sources communications are also popular.
and sinks as illustrated in Fig. 2.1 [13]. By means of packet Depending on the needs and requirements of a given sce-
switching, the network provides an alternative to dedicated nario, limiting factors, including transmission power, channel
links between endpoints as routers allow for resource sharing bandwidth, and deployment costs, favor one solution over
in a highly efficient manner. In the context of IoT, hosts the others. One important consideration is that a transmitted
are typically sensors, actuators, controllers, and devices in signal is affected by the channel noise. By the time the
general as well as applications like those performing com- signal arrives at the receiver, it has been attenuated and
plex decision-making. Routers, on the other hand, can be affected by channel noise leading a specific signal-to-noise
dedicated equipment or as in the case of capillary networks, (SNR). Because the channel capacity theorem states that the
described in the next section, other devices. By giving plain maximum achievable transmission rate is a direct function
devices, like sensors and actuators, routing capabilities, it is of SNR, higher SNR typically means higher transmission
possible to lower deployment times and costs by maximizing rates [4,15]. Note that the transmission rate is error-free if the
hardware reutilization. right channel encoding mechanism is used. In IoT networks,
Links, depending on the nature of the channel, can be this can be challenging as preserving battery life usually
wireless associated with free propagation or wireline asso- implies low signal power and low SNR that translates into
ciated with guided propagation. Guided propagation typi- low transmission rates. More details of this interaction are
cally involves (1) copper conductors that are twisted at a described in Chap. 3.
rate of several twists per centimeter in order to mitigate Because IoT devices, like sensors, interact with the physi-
electromagnetic interference (EMI); (2) coax cables that are cal environment, they monitor infinite precision analog assets
made of inner and outer conductors, separated by a dielectric like temperature, humidity, or light intensity that cannot be
insulating material with stronger immunity to EMI and com- packetized and transmitted without certain transformations.
paratively higher bandwidth that enables higher transmission This was previously described as part of the example of
rates; and (3) optical fibers that exhibit no EMI and support Fig. 1.1 that shows the communication path between a tem-
much higher transmission rates [16]. On the other hand, perature sensor and an application. To put it in the context of a
free propagation occurs between corresponding antennas in layered architecture, first, the analog variable is converted to
the Earth’s atmosphere, underwater, as well as in free space. a digital number represented by a sequence of bits generated

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 21

R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_2
22 2 Concepts of IoT Networking

Fig. 2.1 Communication host

network
source sink
host router
source sink
router
router

router
host

source sink
host
host
source sink
source sink

by source encoding at an ADC. Note that source encoding

can be thought of as being performed at the application layer. 2.2 Types of Networks
The converted digital value representing the asset can then
be prepared for transmission by adding reliability, addressing As indicated in Fig. 2.2, IoT networks sit in between appli-
and additional routing information as part of channel encod- cations and devices that, in turn, interact with assets. The
ing [9]. This is typically done by appending headers and other IoT system is the set made of devices, applications, and
fields to the converted digital value in order to build a packet networks, while the asset is external to the IoT system. In
in a way that is consistent with transport, network, and link all cases, IoT networks usually involve wireless and wireline
layers. For example, a checksum field that provides FEC is an links that use different physical and link layers but that
example of channel encoding. The resulting packet can then they all rely on IPv6 connectivity. In the IoT domain, there
be transmitted over the channel as a modulated wave. are two common scenarios for communication between two
Note that modulation is performed by the physical layer. endpoints: (1) one-hop communication (i.e. sensor directly
Since the channel is analog because it exists in the physical talking to an application) and (2) multi-hop communication
world, modulation performs one more conversion. Essen- (i.e. sensor indirectly talking to an application by relying on
tially, the modulator converts the packet into electrical signals intermediate devices to forward packets). This latter scenario
that can be transmitted through wires or propagated through is representative of capillary networks initially introduced as
antennas. As the analog signal traverses the channel, it is part of WSNs and now widely extended to many IoT tech-
attenuated and becomes affected by noise that lowers the nologies [10]. Figure 2.3 illustrates a capillary network where
SNR and limits performance. When the signal arrives at sensor 1 communicates with the application through sensor 2
the receiver, the demodulator, at the physical layer, restores and sensor 3. Alternatively, and due to routing, sensor 1 can
the digital packet by converting the signal into a stream of talk to the application through sensor 4. Similarly, Fig. 2.4
bits. Subsequently, the channel decoder removes any ad- shows the same devices and application but under a one-hop
dress fields and additional reliability information performed topology.
at link, network, and transport layers, and it forwards the
payload to the application layer. In sensing scenarios, the Example 2.1 Consider the following scenario where a
consumer of the payload is an application that makes au- sensor transmits a 200-byte packet over three different
tomated decisions. In actuation scenarios, however, digital paths based on specific routing objectives. Each path
data is generated by an application and transmitted through is associated with a number of hops needed to reach
the channel to a device that performs actuation. In this case, the destination. More hops imply shorter links that
since the consumer of the digital payload is analog, source support higher transmission rates as signal degradation
decoding converts it into an analog signal by means of a DAC. is lower. In this particular scenario, links A, B, and
This is consistent with the communication path between the C support nominal transmission rates of 240 Kbps,
application and the engine in the example of Fig. 1.1. 64 Kbps, and 152 Kbps, respectively. How long does it

(continued)
2.2 Types of Networks 23

Fig. 2.2 IoT networks IoT system

network

.....
....
application

devices
assets

sensor 1 sensor 1

sensor 2 sensor 2

sensor 3 sensor 3

sensor 4 sensor 4

application application

Fig. 2.3 Multi-hop capillary network Fig. 2.4 Single-hop network

(continued) (continued)
take for a packet to reach the gateway over the three = 20 ms, dB = 200×8 bits/64000 bps =
200×8 bits/240000 bps

different paths (dA , dB , and dC )? 25 ms, and dC = 2 × 200×8 bits/152000 bps = 21.05 ms.
Note that although path A traffic is retransmitted by
two intermediate nodes, it exhibits lower delay when
compared to paths B and C because of its higher
transmission rate.

gateway
Networks have been traditionally classified based on the
area they cover; as shown in Fig. 2.5, the three main types
sensor are local area networks (LANs), metropolitan area networks
(MANs), and wide-area networks (WANs). A LAN involves
an office, a lab, and a building, and it does not rely on
third-party communication infrastructure to provide high-
Solution The delay is given by the number of hops speed service. A WAN, on the other hand, involves a very
per path multiplied by the delay over a single link. large geographical region and therefore relies on third-party
Specifically the corresponding delays are dA = 3 × infrastructure to function. The throughput of a WAN is typ-
(continued) ically much lower than that of a LAN. The size of a MAN
falls somewhere in between that of a LAN and WAN. As a
24 2 Concepts of IoT Networking

Fig. 2.5 Network classification MAN

MAN

LAN
LAN
`
LAN

WAN

Most IoT access side networks, where constrained devices

are usually deployed, classify as low-rate short-range LAN
subtypes. A home area network (HAN) is one such subtype
that supports IoT communication at home and building lev-
els. Another very popular subtype that is of particular impor-
tance in the IoT domain is that of personal area networks
(PANs). PANs provide a small coverage at relatively low
core

gateway
border router transmission rates in order to extend battery life. As indicated
clusterhead in Sect. 1.3, a very big family of IoT solutions are based on
wireless PANs and therefore called WPANs. WPANs are one
of the most common network types in the context of IoT. With
a smaller coverage than PANs, body area networks (BANs)
are made of wearables and implants as well as other small
access devices that support fitness and health-care applications. As
LLN it is also indicated in Sect. 1.3, the other big family of
IoT networks falls under the WAN umbrella due to their
large coverage. Because these technologies are low power in
Fig. 2.6 IoT access network
order to extend battery life, they are called low-power WANs
or LPWANs. Note that although LPWANs are inherently
WAN, a MAN also relies on third-party communications but wireless, they are called LPWAN and not LPWWAN [3].
operates at higher speeds typically linking LANs and WANs. Both WPANs and LPWANs, by virtue of being wireless,
Larger than WANs, an Internet area network (IAN) connects rely on batteries. Moreover, in order to extend battery life,
endpoints within a cloud environment. power consumption must be minimized. Low power, unfor-
Under IoT, networking typically refers to the access net- tunately, implies weak signals and therefore low SNR that is
work where the devices are located. Figure 2.6 illustrates a responsible for high packet loss and low transmission rates.
generic IoT access network. In general, the overall topology Most IoT technologies, as shown in Fig. 2.6, fall under what it
is such that devices interact with an IoT gateway, border is called low-power and lossy networks (LLNs) or sometimes
router, or clusterhead that acts as the boundary between ac- called low-power, low-rate, and lossy networks (LLLNs) [2].
cess and core sides. The core network is usually a mainstream There are several PAN physical and link layer mechanisms
IP network that provides global connectivity to applications. that can co-exist in an IoT environment. They range from
These applications, in turn, many times reside in the cloud wireless technologies like IEEE 802.15.4 and Bluetooth Low
infrastructure. Energy (BLE) to wireline schemes like PLC and Master-
Recent developments of virtualization have led to the Slave/Token-Passing (MS/TP). More complete description
integration of WANs and software-defined networks (SDNs) of these and other technologies are presented in Chap. 3.
into software-defined WAN (SD-WANs) that provide reliable Since IoT PANs and WPANs involve devices communicating
long-distance WAN access at a reduced cost by relying on IP with each other or against gateways, they can be laid out
tunnels transmitted over the public Internet. in different topologies including buses, rings, and master-
All these network types can be deployed as wireless or slave schemes. In most cases, these technologies are part of
wireline topologies. For example, WWAN and WLAN, re- proprietary network stacks that do not rely on the Internet
spectively, indicate the wireless versions of WAN and LAN. for communications. The IoT revolution has brought into
Essentially, a “W” prefix indicates that the network type is existence several network layer protocols that can be used
wireless. Similarly, if no prefix “W” is included, it is assumed with these heterogeneous mechanisms to provide broad IPv6
to be a plain wireline-based network type. communication. Specifically, 6LoWPAN and other similar
2.3 Devices 25

mechanisms provide IPv6 connectivity on top of physical regardless of their complexity, include several I/O interfaces
and layer protocols like IEEE 802.15.4 to uniformly support that are accessible to system designers by means of pins on
IoT applications. Details of the IoT network layers including SoCs and SoMs. These interfaces provide basic communica-
6LoWPAN support are presented in Chap. 4. There are also tion between peripherals within a device by supporting point-
several LPWAN stacks that co-exist in several full and hybrid to-point and bus infrastructures [8]. The Serial Peripheral
IoT environments. They are mostly wireless technologies that Interface (SPI) enables very simple, fast serial communi-
include LoRa, SigFox, NB-IoT, and many more presented in cation between a master embedded processor and multiple
Chap. 8. slaves. Similarly, the Inter-Integrated Circuit (I2 C) interface
provides a more complex, but a bit slower, bus architec-
ture that supports multiple co-existent bidirectional master
2.3 Devices and slave peripheral. A universal asynchronous receiver-
transmitter (UART) interface supports a generic and reliable
IoT involves, by definition, interaction with the physical mechanism for the transmission of data over serial link. Both,
environment that is performed by means of logical devices RS-232 and RS-485, are well-known examples of UART
that can be controllers, actuators, sensors, and gateways [17]. serial interfaces that despite being old and slow are widely
These logical devices are supported by hardware provided used in the industry. As opposed to SPI and I2 C, UART-
by physical devices running on constrained embedded com- based serial interfaces are sometimes used by some IoT
puters and systems, first introduced in Sect. 1.3. They are technologies. For example, wireline MS/TP relies on RS-485
embedded because they are typically part of a bigger CPS. for its physical layer.
They are constrained because they have limited memory and Another serial interface that is widely supported by most
computational complexity. In general, these computers are embedded processors is known as Joint Test Action Group
characterized by a power source, a networking stack, and a (JTAG). JTAG, standardized as IEEE 1149.1, is used to per-
processor. form a boundary scan of an integrated circuit to enable circuit
The power sources can be traditional alternating current testing in situations where using electrical probes is virtually
(AC) and direct current (DC) electric power lines, batteries, impossible. It also enables the examination and control of the
or hybrid schemes that support energy harvesting by means state of an embedded processor. A newer mechanism is Serial
of, for example, solar panels [6]. In regard to the networking Wire Debug (SWD) that provides similar functionality with
stacks, and depending on the hardware and software capa- fewer pins.
bilities, there are different protocols associated with layers In the context of IoT devices, some embedded processors
and technologies as diverse as IEEE 802.15.4 and CoAP. As also include ADC and DAC interfaces for conversion of
stated before, the main goal of this book is to explore these signals from the analog to the digital and from the digi-
IoT communication technologies. tal to the analog domains, respectively. Last but not least,
The processors are in most cases low-power constrained most embedded processors include general-purpose input
embedded computers with limited computational complexity and output (GPIO) ports that can be used to read and write
and small instruction set architectures (ISAs). Because of the two-level digital signals for interaction with sensors and
IoT interaction with the physical environment, these devices actuators [14].
are particularly reliable when it comes to control over timing. In order to run complex software, complex hardware
Therefore, in many cases, embedded processing is a syn- is needed. Constrained 8-bit embedded processors are a
onym of real-time processing. The simplest devices rely on lot weaker candidates than 64-bit ARM processors to run
microprocessors with basic central processing units (CPUs) complex operating systems (OSs). Based on levels of com-
that combine several peripheral devices like memories, I/O plexity, OSs can be classified as main-loop, event-based,
interfaces, and timers. They are usually 8-bit processors that embedded, or full-featured. A main-loop OS consists of a
consume extremely small amounts of energy and rely on simple bootloader that executes a single threaded process
power cycles as well as sleep modes to minimize energy that continuously polls sensors and performs actuation in
consumption and extend battery life. These small embedded response. An event-based OS is a bit more sophisticated
devices are well known to operate on small batteries for and relies on hardware interrupts to report events to an
several years. application. An embedded OS, usually called real-time OS
More advanced devices rely on 32-bit and 64-bit ARM (RTOS), is lightweight but includes all basic building blocks
processors that comparatively consume more power but pro- of traditional OSs including threading, sockets, and con-
vide a lot higher computational complexity including, some- tention mechanisms that provide concurrency and real-time
times, support of digital signal processing (DSP) capabil- functionality [5]. Full-feature OSs, on the other hand, include
ities. Many not-too-complex embedded processors rely on all the components and modules that belong to commercial-
co-processors that offload complex functionality like signal grade OSs distributed into kernel and user space elements.
and network processing. In general, embedded processors, In many scenarios, highly constrained devices run as bare-
26 2 Concepts of IoT Networking

metal devices that do not rely on any OS support, and their IoT devices, and more specifically sensors, controllers,
firmware provides all functionality. and actuators, can be self-configured and self-organized. The
Based on hardware and software capabilities, devices can idea is that they can be deployed in a network such that once
be simple or complex. A simple device relies on a main-loop they are powered up, they can be automatically provisioned
or event-based OS running on a battery-powered constrained and configured to become functional right away. Devices,
embedded processor. Examples of simple devices are basic at this point, have all the information that enables them
sensors or actuators. Simple device communication is low to communicate with gateways and applications. Moreover,
rate and may or may not rely on IP networking. When a sim- certain devices can also self-propel and support mobility that
ple device does not natively include an IP interface, Internet allows them to deploy themselves in unaccessible remote
connectivity is provided by means of an IoT gateway. Specif- areas while preserving connectivity. In general, a highly
ically, many simple devices talk to a gateway that converts desired property of IoT devices is reliability such that they
non-IP into IP traffic. LPWANs are quintessential examples can operate for years without any human interaction.
of this scenario. A complex device, on the other hand, relies
on an RTOS or on a full-featured OS with fully compliant
IP stacks. These stacks provide PAN, LAN, and WAN access 2.3.1 Sensors
that provide direct communication to the Internet. Complex
devices, such as gateways and stand-alone sensors, rely on Sensors are logical devices that sense or measure an asset
external power lines that enable higher transmission rates. of the physical environment. Examples of assets include
Keep in mind that the topic of software/hardware interac- not only physical parameters like temperature, humidity,
tion and capabilities of embedded devices in the context of and light intensity but also other measurable quantities like
IoT is quite complex and it falls outside the scope of this inventory and population sizes. The sensors in each case
book. retrieve temperature, relative humidity, and light intensity as
values measured in Centigrade degrees, percentage, and Lux,
 RTOSs RTOSs give devices capabilities that are not respectively [24]. Sensors can be classified in accordance to
typically available in bare-metal environments. Specif- their size; they can be nanoscopic in the order of 1–100 nm,
ically, they provide very efficient task concurrency, mesoscopic between 100 and 10,000 nm, microscopic in
communication, and scheduling. RTOSs are typically the range between 10 and 1000 µm, and macroscopic when
as limited as the devices they run on. A list of some of above 1 mm. Moreover, depending on size and logistics, sen-
the most popular ones is shown below. sors are sometimes deployed as an array of devices specially
in the context of WSNs.
Depending on the complexity of the embedded proces-
Contiki BSD-licensed open-source, lightweight OS.
sor, a sensor may perform some local processing in order
Implemented in C and ported to Atmel AVR, MSP430,
and ARM M processors. to remove redundancy in a controlled way. An example
Very low memory requirements (order of kilobytes). of this removal is source encoding where sensor readouts
Open Open-source OS created by UC Berkeley. are digitized and compressed. Compression can be lossless
WSN Implemented in C. or lossy depending upon whether the original samples can
TinyOS BSD-licensed open-source OS. be recovered or not. Specifically, through source encoding,
It runs on devices with 16 KB of memory. data is converted into information that can be transmitted at
Applications are written in nesC a version of C that lower rates reducing the channel bandwidth requirements and
optimizes resources. improving power consumption. This data-information con-
RIOT LGPLv2-licensed open-source OS. version is part of the transformation shown in Fig. 1.7 [21].
Implemented in C and C++. If more complex computational capabilities are available,
Minimum memory requirement of 1.5 KB. more efficient processing can be done at the sensor. In spe-
Zephyr Apache 2.0-licensed open-source OS. cial cases, this additional processing is performed under the
Implemented in C and ported to ARM M, x86, and umbrella of an information-knowledge conversion executed
RISC-V 32 processors.
at the sensor. Examples of these more complex technologies
High-end support includes POSIX APIs.
include machine learning classification as well as numerical
FreeRTOS MIT-licensed open-source OS.
predictions by means of linear regression and other statistical
Implemented in C and ported to 35 microcontrollers and
processors. mechanisms.
Full kernel support. In general, a sensor is active if it is required to emit sounds
MBed Apache 2.0-licensed open-source OS. or generate electromagnetic waves that can be detected by
Implemented in C and C++. Ported to ARM M proces- means of external observation. A sensor that is not active is
sors. passive. For example, temperature and humidity sensors as
2.3 Devices 27

well as cameras are examples of passive sensors since it is 2.3.2 Actuators and Controllers
impossible to tell whether they are sensing by just looking
at them. On the other hand, radio detection and ranging Actuators are logical devices that perform some external
(radar), sound navigation and ranging (sonar), and light change of an asset of the physical environment. An example
detection and ranging (lidar) are examples of active sensors of actuation is the activation of a fan to lower the temperature
as they emit electromagnetic waves or they generate sounds of a room. In this case, the actuator is the fan, and the asset is
that can be easily detected by observing them. Because they the temperature. Another example of actuation is the servos
generate energy, active sensors consume a lot more power, that can be used to change the flight path of a UAV. Similarly,
and, therefore, they cannot rely on batteries to function. In the servos are the actuators, and the flight path is the asset.
opposition, passive sensors are more likely to rely on batteries Actuation is typically tied to sensing through feedback mech-
and perform external energy harvesting by means of, for anisms where decision-making takes sensor and actuation
example, solar panels. data as input and output parameters, respectively. Because
Battery life can be extended by means of power duty of this, if a given physical device has a logical actuator, it
cycles where devices sleep by dramatically reducing power is quite likely that a logical sensor is also present [21]. The
consumption at preprogrammed intervals. Specifically, while opposite, that is, the presence of an actuator given a sensor is
a device sleeps, it minimizes power consumption by only present, is a lot less common.
enabling basic functionality including a wake-up interrupt or Same way sensors are associated with source encoding
notification. In order to minimize network throughput and and DACs, actuators are associated with source decoding
preserve the power consumption of all devices to extend and ADCs. Actuators, however, are a lot simpler as they
the network lifetime, it is preferable that duty cycles are do not rely on data-information and information-knowledge
coordinated throughout the network [6]. This is particularly conversions. Usually the knowledge from the application
important when considering capillary networks that rely on results in a command being sent down to the actuator. As with
multi-hop communication where intermediate sensors act sensors, actuators are affected by loss and latency that results
as routers. If a sensor does not know whether transitional in different QoS levels.
devices are sleeping at any given time, it may waste energy to Controllers are logical devices that perform some internal
transmit data to an inactive router that is not able to propagate change in the physical device to assist sensing or actuation
packets to destination. [22]. This involves, for example, having a camera zoom in
From a networking perspective, depending on the use of and out, replacing optical filters, or having a transmitter turn
the sensor readouts, transmission reliability is important. If antennas around. For most cases, controllers are deployed
sensor readouts are to be used to make real-time decisions along with sensors and actuators as logical devices on the
like to change the flight path of a UAV, latency and packet same physical device. When assisting sensing, control is
loss must be as low as possible. On the other hand, if those affected by the same application QoS requirements that are
readouts are to be used to perform offline data visualization, needed by the sensor.
latency and packet loss requirements are a lot less restrictive.
In general, application-specific quality of service QoS goals
lead to different application latency and packet loss levels that 2.3.3 Gateways
tell how reliable sensor data transmission must be. The trade-
off, shown in Fig. 2.7, between QoS and reliability has power Gateways are logical devices that serve as an interface be-
consumption and, therefore, battery life implications. tween access side IoT devices and core side applications.
Access side IoT devices are the sensors, actuator, and con-
trollers, while the core side applications rely on analytics to
make real-time decisions. When compared to other devices,
QoS

gateway is a bit more advanced, demanding higher computa-

tional complexity that requires more resourceful and power-
ful embedded processors fed by power lines. This complexity
is also needed for the gateway to have enough “horsepower”
to simultaneously interact with multiple sensors, actuators,
and controllers. This does not prevent, in certain scenarios
typically associated with multi-hop communications, simpler
devices like sensors and actuators from providing basic gate-
baery life
latency way functionality. Specifically, sometimes networks can rely
packet loss on sensors and actuators taking turns in becoming temporary
gateways that aggregate and forward packets to uplink appli-
Fig. 2.7 QoS vs battery life, loss, and latency
28 2 Concepts of IoT Networking

Table 2.1 Device comparison

Device Complexity Networking Form factor (continued)
Sensor Low WPAN/LPWAN Small gateway 1 gateway 2
Actuator Low WPAN/LPWAN Medium A1 A2 A1 A2
Controller Low WPAN/LPWAN Medium
Gateway High WPAN/LPWAN + Large T1 T2 T1 T2
WAN
N N1 N2

L L1 L2
cations. Of course, this is contingent on device computational
complexity and battery life. Many times, gateways are critical P P1 P2
in providing communication between devices, as they route
all traffic up and down the network. This is especially true
when the gateway acts as clusterheads that forward back and
forth all packets in the access side. Solution The delay associated with gateway 1 is given
In most IoT scenarios, gateways are known to provide by dgw1 = 3 × 5 ms + 2 × 30 ms = 75 ms.
interfaces between WPANs and LPWANs on the access side Similarly, the delay associated with gateway 2 is given
and mainstream WANs on the core side. In a more generic by dgw1 = 5 × 30 ms = 150 ms. Clearly a hybrid IoT
definition, gateways translate messages at different levels of scenario where IP is only supported on the core side of
the layered architecture [18]. They can (1) convert physical the network requires gateways converting full stacks.
and link layer frames, for example, when forwarding them Of course, this introduces processing delays that are a
between wireline Ethernet and wireless IEEE 802.15.4; they lot larger than those of IoT scenarios that support end-
can (2) convert network layer datagrams, for example, when to-end IP connectivity.
forwarding them between IPv4 and 6LoWPAN/IPv6 layers;
they can (3) convert transport layer segments, for example,
when forwarding them between Transport Control Protocol
(TCP) and UDP layers; and they can (4) convert application 2.4 Security
layer messages, for example, when forwarding them between
Hypertext Transfer Protocol (HTTP) [1] and CoAP layers. The security challenges in IoT networks are multiple [12,19];
Table 2.1 compares gateways against the other devices re- (1) it is very important to minimize resource consumption,
garding computational complexity, networking capabilities, (2) it is critical to prevent link attacks ranging from passive
and hardware form factors. eavesdropping to active interfering, and (3) wireless com-
munication mechanisms associated with IoT networks render
Example 2.2 Consider the two gateways below: traditional security mechanisms many times unsuitable.
gateway 1 (associated with a IoT scenario) only Security requirements are also important; (1) confiden-
converts transport protocol 1 (T1) to transport tiality implies that information must be encrypted to make
protocol 2 (T2) and application protocol 1 (A1) sure that it is inaccessible to unauthorized users, (2) au-
to application protocol 2 (A2), while gateway 2 thentication dictates that only trusted sources can transmit
(associated with a hybrid IoT scenario), respectively, data, (3) integrity means that the received messages are not
converts physical protocol 1 (P1), link layer protocol 1 altered in transit, (4) freshness guarantees that traffic does not
(L1), network protocol 1 (N1), transport protocol (T1), include replayed datagrams, (5) availability ensures connec-
and application protocol 1 (A1) to physical protocol tivity even when subjected to hostile attacks, (6) resilience
2 (P2), link layer protocol 2 (L2), network protocol provides consistent security levels even when devices are
2 (N2), transport protocol 2 (T2), and application compromised, (7) resistance prevents intruders from getting
protocol 2 (A2). Assuming that basic processing delay full control of the network, and (8) energy efficiency implies
(i.e. address lookup) takes around 5 ms and more that the network security must minimize power consumption.
complex protocol conversion processing delay takes Attacks and threats against both user and data in IoT net-
around 30 ms, how long does it take for a protocol 1 works are typically very destructive as IoT access networks
packet to be processed by both gateways? are usually wireless and easily accessible. In this context,
there are several threats that can be analyzed from the layered
architecture perspective. The assumption is that an intruder is
(continued) fully capable of carrying out an attack at any time but during
2.5 Wireless Sensor Networks 29

deployment. IoT is special because it is highly susceptible datagram loss, (2) selective forwarding where an affected
to physical attacks where devices are destroyed or relocated. device only forwards certain datagrams in order to cause
Because of these attacks, one or multiple devices can be connectivity problems, (3) sinkhole attack where an affected
put out of commission causing irreversible losses. During a device attempts to become the destination of all traffic in a
physical attack, it is possible to extract keys and modify the certain location (this requires the device to broadcast low-
behavior of the device by uploading a new firmware. cost routes to neighbors beforehand), (4) Sybil attack where a
In IoT networks, denial-of-service (DoS) attacks are per- single device assumes multiple identities in order to become a
formed at different layers. Physical layer DoS attacks consist destination of many other nodes in the network, (5) wormhole
of an intruder generating interference that lowers the over- attack where the attacker captures datagrams in one location
all SNR of the modulated waves. Link layer DoS attacks and retransmits them in another leading to routing and con-
are associated with forcing devices to deplete their energy. nectivity problems, and (6) neighbor discovery attack where
Specifically, attackers induce device media collisions that neighbor discovery messages typically used in the context of
cause devices to retransmit frames that, in turn, reduce their WPANs are either dropped or corrupted in order to induce
battery life. In addition, frames with fake addresses in dif- reachability issues.
ferent WPANs can cause a device to transmit bogus replies
that also drain its battery. This is further aggravated when a
device relies on power duty cycles. In this case, the attacker 2.5 Wireless Sensor Networks
attempts to keep the device busy in a scenario known as sleep
deprivation torture. When the device that is being attacked WSNs have been briefly mentioned in previous sections, but
is an IoT gateway, the results can be devastating as routing because of their historical importance, it is very important to
throughout the network is usually affected. Network layer talk about them in the context of IoT [20]. WSN is an old
DoS attacks are associated with an intruder flooding the net- legacy term that designates a system of a very large number
work with many datagrams that fill queues and cause network of wireless sensors that interact with an application that mon-
performance degradation as well as throughput reduction. itors events and other phenomena occurring in the physical
Replay protection is a mechanism that many networks put in environment. Specifically, as indicated in Sect. 2.3.1, sensors
place to make sure that attackers do not resend old datagrams measure assets like temperature and humidity and transmit
in order to cause intentional congestion. To support this, these values to applications that perform data visualization
datagrams include incrementing sequence numbers that are and, in more advanced cases, knowledge extraction. Like IoT
used by devices to keep track of the age of the datagrams. networks, WSNs rely on control for sensors to work effi-
Devices drop stale datagrams that have sequence numbers ciently. For example, if a sensor is a camera taking pictures,
that are lower than those of previously received datagrams. control by means of the camera zooming in and out leads to
Unfortunately, this protection can be used to cause a type better sensing.
of DoS attack called replay protection attack. Essentially, an When, in addition to sensing and control, actuation is also
attacker sends bogus datagrams with high sequence numbers performed by the devices, the network becomes a wireless
in order to prevent valid datagrams from being processed by sensor and actuation network (WSAN). In many cases, the
a destination device [7]. term WS(A)N is used to designate a generic form of a
In certain IoT protocols, for the sake of simplicity, ac- WSN where actuation may or may not be also present. In
knowledgment messages associated with reliable transmis- general, WSANs are associated with decision-making, either
sions are not protected by security. Attackers can take advan- automated or manual by means of human intervention, that
tage of this situation by falsely acknowledging a transmitted rely on actuators to complete the feedback path. Note that, in
message while producing enough interference for the original most cases, sensing is always present regardless of whether
message to be dropped. The idea is to make the source believe actuation is in place or not. In general, if a network supports
that a message has been received even if it has not. In many actuation, it is almost certain that it also supports sensing; the
IoT scenarios, cryptographic keys are periodically negotiated opposite is not always true.
in order to make sure that confidentiality is preserved as time WS(A)Ns are predecessors of modern IoT networks
progresses. This is typically triggered by the IoT gateway in and, as such, incorporate all their basic components
response to an unencrypted device request. An attacker can shown in Fig. 2.8. Clearly there are (1) assets, (2)
take advantage of this situation by pretending to be a valid sensors/actuators/controllers, (3) a communication network,
device and forcing key renegotiation that leaves the device (4) gateway(s), and (5) a central processor that serves as
in-communicated. application [23]. There are differences in some of these
Other network layer attacks include (1) routing informa- components though. WS(A)Ns do not typically follow
tion spoofing where the intruder spoofs, alters, or replays standards, like IP-based protocols, so communications are
routing information in order to create loops that lead to based on proprietary legacy mechanisms that prevent data
30 2 Concepts of IoT Networking

Fig. 2.8 WSAN

sensor
sensor

sensor
gateway
sensor
clusterhead

sensor
assets sensor sensor
actuator actuator

gateway
gateway
actuator clusterhead
actuator clusterhead
controller

channel

central processor / application

sharing and use of information in a wide sense. Sensors and between transmitters and receivers, it is possible to improve
actuators are wireless and only interact with gateways that the overall network energy efficiency.
collect packets and aggregate, transform, and forward them In the context of WS(A)Ns, the central processor does
to the central processor. not necessarily make real-time decisions, and in many cases,
Moreover, WS(A)N architectures, as illustrated in especially in WSN scenarios, information is stored for offline
Fig. 2.8, are pyramidal with multiple devices communicating processing and visualization. This is particularly true for
to multiple gateways that talk to a single application. traditional WSNs that were built when analytics mechanisms
Communication is therefore M2P and relies on clusters like machine learning and data mining were not as developed
of devices that connect to other clusters by means of as they are today.
gateways that in turn communicate with other gateways Limited battery life at devices leads to a trade-off between
in order to access the central processor. In many cases, computational complexity and transmission power. If more
the gateway functionality is carried out by sensors and processing is performed at a sensor or actuator, more energy
actuators that behave as clusterheads. In fact, and in order to is needed to execute more complex algorithms. Similarly, if
preserve battery life, devices typically take turns in becoming more traffic is to be generated by a device, more energy is
clusterheads as gateway communication requirements needed for a higher transmission rate [11]. Fortunately, more
typically impose power consumption conditions that can lead processing results in fewer packets being transmitted and
to energy depletion. WS(A)Ns can also define mechanisms therefore lower transmission rate requirements. Figure 2.9
that reduce the overall battery consumption by allowing shows this trade-off; essentially, battery life is presented as
sensors to forward packets to other intermediate sensors a function of both processing and transmission rate. Specif-
that, in turn, retransmit these packets to reach the central ically, battery life decreases as both processing and trans-
processor. Since power consumption is exponentially mission rate increase, but more processing implies a lower
affected by signal coverage, by minimizing the distance transmission rate, and a higher transmission rate implies less
2.5 Wireless Sensor Networks 31

Fig. 2.9 Operational point

BATTERY LIFE
OPTIMAL OPERATIONAL POINT

HIGH
MEDIUM
LOW PROCESSING
LOW MEDIUM HIGH
TRANSMISSION RATE
HIGH MEDIUM LOW

processing. When considering their accumulated effect, the “sleep” in order to guarantee that sensor readouts are always
optimum operational point that maximizes battery life results transmitted uplink. Again, this depends on overall network
from a trade-off between transmission rate and processing. coordination including traffic routing protocols. Summariz-
In general, maximizing the battery life of a device leads to ing, in the context of WSNs, battery life preservation is usu-
finding an operational point that determines computational ally the result of several interrelated trade-off mechanisms:
requirements and protocol stacks. (1) low transmission rates at a cost of higher processing,
Most WSN applications produce traffic that is lightweight (2) power duty cycles to minimize device processing, (3)
in nature since it involves the transmission of packets con- multi-hop routing to lower transmission power, and (4) low
taining simple commands and events. This relates to both computational complexity at a cost of higher transmission
communication and processing requirements. On the other rates [20].
hand, some WSN applications rely on sensors that capture WSNs are classified depending on their size and more im-
video by means of cameras. Video, as opposed to traditional portantly on whether they support multi-hop communication.
sensor readouts, is highly demanding from transmission rate Specifically, category 1 WSNs are those that include a very
and computational complexity perspectives. Video codec se- large and highly dense deployment of devices. Transmission
lection at the device enables a WSN application to decide the is multi-hop with communication from devices to gateways
operational point that represents the best trade-off between relying on intermediate sensors and actuators forwarding and
those two parameters. For example, transmitting raw uncom- aggregating packets. Under category 1 structures, multiple
pressed video minimizes processing but maximizes through- devices talk to other devices that forward traffic to gateways
put, while video compression by means of the state-of-the-art that, in turn, talk to other gateways that end up communi-
International Telecommunication Union Telecommunication cating with a single gateway that provides communication to
Standardization Sector (ITU-T) H.265 codec maximizes pro- the central processor. On the other hand, category 2 WSNs
cessing but minimizes throughput. Other less efficient codecs are simpler, with fewer devices directly connected to a sin-
can be selected to find the best trade-off for a given WSN gle gateway that communicates with the central processor.
scenario. The penalty to pay for the extended coverage provided by
When comparing IoT networks to traditional WS(A)Ns, category 1 WSNs is lower transmission rates and higher
one major difference is that the latter consist of networks latency when compared to category 2 WSNs. Figure 2.10
with many sensors (and actuators) highly densely deployed. shows examples of both category 1 and 2 WSNs. In many
Specifically, because these devices are wireless and battery- solutions, category 1 and 2 WSNs overlap in order to provide
powered, duty cycles are used to preserve battery life. In fact, different functionalities. As such, each network type relies on
most sensors affected by power duty cycles are installed in different physical and link layer technologies. Leaving other
clusters where highly redundant sensors take turns to go to differences aside, the low- and high-throughput networks
32 2 Concepts of IoT Networking

Fig. 2.10 WSN classification

sensor

sensor (clusterhead)

gateway

application

category 1 category 2

presented in the IoT UAV example in Sect. 1.4 can be thought of authentication, association, registration, and session
of as category 1 and 2 WSNs, respectively. establishment. Additionally, and depending on the WSN,
Because of the limitations associated with WSNs, devices asset tracking enables asset detection and classification.
may not have global identification and be only accessible Also, part of group management, dynamic device allocation
through gateways that act as proxies between sensors and presents procedures to provision, unprovision, and query
processors. Moreover, by virtue of being wireless, devices sensors.
can also move leading to dynamic topology changes trig- Some factors that are relevant to WSNs are (1) network
gered by internal and external position changes. Internal coverage that indicates the topological coverage of a given
mobility is caused by self-powered changes of the device WSN, (2) detectability that provides the probability that a
position by means of control. External mobility results from given WSN is able to detect a specific asset or physical
an application or an operator changing the position of the phenomenon, (3) node coverage that presents the level of
device. device redundancy available to capture data if a sensor failure
Mobile ad hoc networks (MANETs) are a well-known occurs, (4) node assessment that introduces provisioning
type of wireless networks that, from a traffic perspective, capabilities to add additional sensors and actuators to accom-
are similar in nature to WSNs. MANETs are representative plish redundancy goals whenever needed, and (5) control ca-
of Wi-Fi (standardized by IEEE 802.11 and described in pability that enables orientation and mobility sensor changes
Sect. 3.3.1) networks configured in ad hoc mode as presented that maximize coverage.
in Sect. 3.3.1. In MANETs, however, packets flow between Most WSN devices perform in-network processing that
a few endpoints point-to-point (P2P) as opposed to WSNs relies on several techniques: (1) data aggregation where
where transmission is mostly M2P from a large number of readouts from different sensors are collected by a sensor
devices to a central processor [25]. WSNs are wireless but closer to the gateway or clusterhead, (2) data fusion where
not always mobile, while MANETs are mobile. Moreover, redundancy from readouts of different sensors is removed
traffic of WSNs can be highly redundant as it originates from by another sensor, (3) data analysis where a single sensor
close-by sensors that describe the same physical phenomena. converts data into information though signal processing and
This redundancy, when coordinated, can be exploited to lightweight machine learning techniques, and (4) grid and
increase the device battery life through the introduction of hierarchical computing where data analysis is performed
power cycles. In addition, as opposed to WSNs, MANETS by those sensors that have the best context information to
are not deployed for long periods of time without human do it. Central processors complement in-network process-
intervention and almost always do not run on batteries. The ing by taking the pre-preprocessed information and con-
many differences between MANETs and WSNs make that verting it to useful knowledge as mentioned in previous
routing protocols that would normally work in one case do paragraphs.
not work in the other. Like IoT, under WSN, controller side data management
Due to the sheer size of WSNs, both network organization is critical. The main aspects of data management include
and device tracking are very important. Because traditional database management that can be used to set, query, and
WSNs do not rely on standardized mechanisms, technologies store device configuration and provisioning parameters
to accomplish these goals include proprietary group as well as sensor readouts and actuation information. In
management that provides device self-organization by means some scenarios, high availability is provided by distributing
References 33

databases over multiple entities including several controllers 2.2 For the use case in Sect. 1.4:
and devices supporting in-network processing. Data in
WSN is multidimensional for both storage and retrieval, (a) what mechanism plays the role of controller (if any)?
and therefore efficient spatial and temporal searching is (b) what mechanism plays the role of IoT gateway (if any)?
mandatory. (c) what element is the asset?
When designing WSNs, it is important to consider hard-
ware and power constraints that limit physical layer param- 2.3 In Fig. 2.9, the trade-off between embedded processing
eters like transmission rate. Moreover, deploying a WSN and transmission rate is shown. How can the figure be modi-
requires understanding of network topologies and how to deal fied to consider throughput instead of transmission rate?
with fault tolerance, mobility, and scalability. As previously
mentioned, WSNs are typically self-configuring systems that 2.4 From a power consumption perspective, what are the
must be able to deal with unpredictable states and situations. differences between passive and active sensors?
Other less flexible scenarios that rely on static or semi-
static topologies are pre-configured and do not support self- 2.5 The end-to-end delay of a communication system is
configuration. defined as (N − 1 + P ) RL where N and P are the number of
Desired characteristics of WSNs are low network and links and transmitted packets, respectively, L is the average
computational latency, power efficiency, and low transmis- packet size, and R is the transmission rate. What is the extra
sion rates that enable efficient use of the wireless channel. latency due to transforming a high-power single-hop access
The idea is to minimize the amount of traffic generated by IoT network into a low-power four-hop one? Assume that in
each device in order to create enough room for all sensors both scenarios the packet size and the transmission rate is the
to share the medium. In-network processing is a good mech- same.
anism to accomplish this goal at a cost of increased energy
consumption that results from the trade-off between compu- 2.6 What are some of the drawbacks of replay protection?
tational complexity and transmission power [20]. Traditional How do they relate to power consumption?
WSNs due to their proprietary nature have not been very
efficient at addressing these issues. Standardization by means 2.7 The efficiency of a communication system η is given by
of IoT protocols and technologies give WSNs a new way to η = CR where R is the transmission rate and C is the channel
overcome these limitations. capacity. In an IoT M2P scenario, the access interface of
a gateway has an 85% efficiency. What is the efficiency
of the core interface if the access and core side channel
Summary capacities are 250 Kbps and 1 Gbps, respectively? What are
the implications of these results?
Most IoT communication solutions are deployed as a combi-
nation of access and core networks where devices interact 2.8 In a WSN scenario, several sensors are to be used to
with applications that extract knowledge in order to make transmit readouts of an asset that is 20 km away. If the
smart decisions. This chapter started by delving into concepts coverage of each sensor is 500 m, what category of WSN is
associated with different IoT networking topologies to then the best deployment option? Why?
focus on the multiple elements of connectivity including
security aspects. This led to presenting the roles supported by
actuators, sensors, controllers, and gateways in the context References
of IoT networks. The chapter also investigated the main
1. Belshe, M., Peon, R., Thomson, M.: Hypertext Transfer Protocol
differences between modern IoT scenarios and traditional Version 2 (HTTP/2). RFC 7540 (2015). https://doi.org/10.17487/
WSNs. RFC7540. https://rfc-editor.org/rfc/rfc7540.txt
2. Bormann, C., Ersue, M., Keranen, A.: Terminology for
Constrained-Node Networks. RFC 7228 (2014). https://rfc-
editor.org/rfc/rfc7228.txt
Homework Problems and Questions 3. Chew, D.: Protocols of the Wireless Internet of Things, pp. 21–45
(2019)
4. Cover, T.M., Thomas, J.A.: Elements of Information Theory (Wiley
2.1 Draw the topology of a capillary network with four Series in Telecommunications and Signal Processing). Wiley-
sensors, three actuators, and a simple gateway that provides Interscience, New York (2006)
connectivity to the Internet. Assume that only one of the 5. Elk, K.: Embedded Software for the IoT: The Basics, Best Practices
sensors and two of the actuators support routing capabilities. and Technologies, 2nd edn. CreateSpace Independent Publishing
Platform, North Charleston, SC (2017)
34 2 Concepts of IoT Networking

6. Geng, H.: Internet of Things and Smart Grid Standardization, pp. 16. Robertazzi, T., Shi, L.: Networking and Computation: Technology,
495–512 (2017) Modeling and Performance (2020)
7. Geng, H.: Security of IoT Data, pp. 399–406 (2017) 17. Sehrawat, D., Gill, N.S.: Smart sensors: analysis of different types
8. Hassan, Q.F.: A Tutorial Introduction to IoT Design and Prototyp- of IoT sensors. In: 2019 3rd International Conference on Trends in
ing with Examples, pp. 153–190 (2018) Electronics and Informatics (ICOEI), pp. 523–528 (2019)
9. Haykin, S.: Communication Systems, 5th edn. Wiley, New York 18. Sethi, P., Sarangi, S.R.: Internet of things: architectures, protocols,
(2009) and applications. J. Electr. Comput. Eng. 2017, 9324035 (2017).
10. Holler, J., Tsiatsis, V., Mulligan, C., Avesand, S., Karnouskos, S., https://doi.org/10.1155/2017/9324035
Boyle, D.: From Machine-to-Machine to the Internet of Things: 19. Shrobe, H., Shrier, D.L., Pentland, A.: Data Security and Privacy
Introduction to a New Age of Intelligence, 1st edn. Academic, New in the Age of IoT, Chap 13, pp. 379–401 (2018)
York (2014) 20. Sohraby, K., Minoli, D., Znati, T.: Wireless Sensor Networks:
11. Huang, Y.M., Hsieh, M.Y., Sandnes, F.E.: Wireless Sensor Net- Technology, Protocols, and Applications. Wiley, New York (2007)
works and Applications, pp. 199–219. Springer, Berlin (2008) 21. Stanley, M., Lee, J., Spanias, A.: Sensor Analysis for the Internet
12. Jurcut, A.D., Ranaweera, P., Xu, L.: Introduction to IoT Security, of Things (2018)
pp. 27–64 (2020) 22. Xia, F., Kong, X., Xu, Z.: Cyber-physical control over wireless
13. Kurose, J.F., Ross, K.W.: Computer Networking: A Top-Down sensor and actuator networks with packet loss (2010)
Approach, 6th edn. Pearson, London (2012) 23. Yang, S.H.: Wireless Sensor Networks: Principles, Design and
14. Lee, E.A., Seshia, S.A.: Introduction to Embedded Systems: A Applications. Springer Publishing Company, Incorporated (2013)
Cyber-Physical Systems Approach, 2nd edn. The MIT Press, 24. Yasuura, H.: Introduction, pp. 1–6. Springer International Publish-
Cambridge (2016) ing, Cham (2017)
15. Popovski, P.: Information-Theoretic View on Wireless Channel 25. Zheng, J., Jamalipour, A.: Wireless Sensor Networks: A Net-
Capacity, pp. 201–234 (2020) working Perspective. Wiley/IEEE Press, Hoboken/Piscataway
(2009)
 Part II
IoT Protocol Layers

This part of this book, that includes three chapters, explores the different communication
layers of standard IoT solutions. Chapter 3 introduces the physical and link layers of wireless
and wireline IoT technologies. The chapter analyzes them from a perspective of their most
important characteristics like transmission rate and power efficiency. Chapter 4 explores
the network and transport layers including adaptation mechanisms that enable IoT physical
and link layer protocols to support IPv6. Chapter 5 deals with the application layers by
describing the most relevant methods for session management and the transmission of device
and application-generated media and data.
 Physical and Link Layers
3

the overall system latency to increase. MAC is, therefore,

3.1 About Physical and Link Layers… responsible for balancing access latency to benefit all users
in accordance with network requirements. Link access does
This section provides a brief introduction to some of the not guarantee that frames are not corrupted by the channel
fundamentals of physical and link layers. As such, a reader when they are transmitted. If channel coding is in place,
familiar with these mechanisms can skip this section. The receivers can detect corrupted frames and avoid their pro-
link layer provides basic connectivity for adjacent endpoints cessing. Since the corrupted frames are dropped from the
to interact with each other over a single link. In order to transmission path, transmitters can resend them to guarantee
accomplish this goal, the link layer relies on several mech- reliability. Specifically, reliable delivery is an optional mech-
anisms: framing, channel coding, link access, and reliable anism that provides the infrastructure to signal and support
delivery. Framing is a generic technique that consists of these retransmissions. It typically involves some feedback
adding fields and special synchronization markers to data technique by which receivers indicate whether a given frame
propagated down from upper layers. Framing in the context has been received (i.e. by means of an acknowledgment) or
of the link layer implies adding headers and delimiters to net- not (i.e. by means of a negative acknowledgment). Moreover,
work layer datagrams in order to make frames. On the other it sometimes includes timers that are reset on successful
hand, channel coding is an optional mechanism that embeds reception of acknowledgments. When these timers expire,
FEC information in one of these headers. This information, in retransmissions and connectivity loss events are triggered. In
turn, can be used by the receiver to determine whether a given a similar way to framing and channel coding that are grouped
frame has been corrupted by channel noise, attenuation, and together in the LLC sublayer, link access and reliable delivery
other interference. Traditional methods of FEC rely on block are part of the greater MAC sublayer. All these four sublayers
and convolutional codes that map frame fields into code- are shown in Fig. 3.1.
words that enable error detection and, sometimes, correction. The channel capacity theorem provides the maximum
These two functionalities, framing and channel coding, are transmission rate as a function of the two main characteristics
part of the Link Layer Control (LLC) sublayer [22]. of a communication system, namely, channel bandwidth and
Link access is provided by a set of rules, known as SNR at the receiver for a channel subjected to additive white
media access control (MAC), that determine how frames Gaussian noise (AWGN) [19]. Note that this is a simple
are received and transmitted over the physical channel. If model that does not consider, among many things, the fading
multiple endpoints share the same channel, their transmission characteristics of wireless channels. However, the model is
is restricted to the contention that exists when trying to good enough to understand some of the effects of system
send frames simultaneously. MAC, in this case, provides parameters in its performance. In general, the larger the band-
the mechanisms that describe how the channel is shared width and SNR are, the higher the allowable transmission rate
and how it becomes accessible in an efficient way. As part is. Similarly, the larger the SNR is, the lower the bit error rate
of this sublayer, MAC addresses are needed to indicate (BER) is. BER is defined as the probability that a received
source and destination endpoints and sometimes intermediate frame bit has been corrupted by channel noise, attenuation,
waypoints. Generally, MAC must guarantee endpoints fair and interference. Note that SNR at the receiver is given by the
access to the channel based on priorities and QoS goals. ratio between the transmitted signal power and the channel
For example, if a single device transmits a very long frame, noise power. Because both channel noise and bandwidth are
it prevents other devices from also sending traffic causing typically fixed, the only element that can be adjusted is the

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 37

R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_3
38 3 Physical and Link Layers

LINK LAYER FEC is the generic mechanism under which, through

channel encoding, error control codes are propagated from
CHANNEL CODING
the transmitter to the receiver. Since the channel encoder

LLC
FRAMING
adds controlled redundancy in the form of additional bits
in the frames sent from the transmitter to the receiver, the
RELIABLE DELIVERY transmission rate is slightly increased. On the receiver, the

MAC
channel decoder removes the controlled redundancy and
LINK ACCESS restores the error controlled source frame. To accommodate
the transmission rate increase, the modulation scheme is
Fig. 3.1 Link layer typically modified to increase either the bandwidth or the
number of bits per symbol. Because channel bandwidth is a
limiting factor and a modulated wave with higher bandwidth
transmission power at the transmitter. If transmission power cannot be always used, changing the modulation scheme is
increases, then transmission rate also increases, while BER usually the most common option. When block codes are
lowers as SNR gets larger. used for error control, a payload is partitioned into chunks
Unfortunately, in the context of a wireless scheme, in- of data called messages, and each message, when controlled
creasing transmission power leads to depleting batteries a redundancy is added, becomes a codeword. A block code is
lot faster. Essentially, in order to extend battery life, power identified by the tuple (n, k) that, as indicated in Fig. 3.3,
consumption must be minimized. This idea is illustrated in implies that out of n bits, k bits are message bits and n−k are
Fig. 3.2. For fixed channel bandwidth and noise, long battery controlled redundancy bits. Note that n is the block length,
life leads to low power consumption that translates into low while k is the message length [17]. For every k message
SNR at the receiver. Low SNR, in turn, implies both low bits entering the block channel encoder, n code bits are
channel capacity and high BER. Low channel capacity limits generated leading to a code rate r = nk with 0 ≤ r ≤ 1.
the transmission rate, and high BER causes high packet loss. An alternative to block codes are convolutional codes that
High packet loss and low transmission rates are represen- operate on continuous streams of bits instead of on blocks of
tative of LLNs discussed in Sect. 2.2. Note that packet loss bits.
can be minimized by means of reliable delivery and channel Transmission in wireline scenarios is performed by means
coding techniques that enable the retransmission of missing of line codes [16]. Line coding is used to modulate digital
and corrupted packets at a cost of a larger transmission bits of a link layer frame into an electrical signal that can
rate. Again, this is not always possible as channel capacity be transmitted over the channel. Different mechanisms exist
typically limits transmission rates. to fulfill this objective, but they all attempt to accomplish
Low transmission rates associated with LLNs greatly af- two goals that affect the transmitted signal; (1) minimize its
fect how MAC works. Since the MAC sublayer must guaran- DC component, and (2) maximize its transitions. Minimizing
tee fair access to the channel, a single user cannot transmit the DC component increases the propagation range of a
for too long as it prevents the other users from accessing signal and the distance between repeaters. On the other hand,
the media. In this case, transmitting traffic as short bursts maximizing signal transitions enables the receiver to better
at low transmission rates translates into limiting the frame synchronize with the transmitter.
size to a maximum allowable size known as the maximum Figure 3.4 shows the modulation of the codeword 101010
transmission unit (MTU) size. by means of Unipolar Nonreturn-to-Zero (NZR) where bit
The physical layer is responsible for processing the link 1 is modulated by transmitting a square pulse of positive
layer frame by subjecting it to both transmission and propa- amplitude for the duration of the bit Tb , while bit 0 is
gation. It is propagation that defines the characteristic of the modulated by not transmitting any signal during that period.
transmission, and it is the channel that defines the character- Because the DC component of any waveform modulated
istics of the propagation. As indicated in Chap. 1, depending by this mechanism is always positive, NZR is not a good
on the channel characteristics, the physical layer can support option for modulation over wireline channels. Also, if an all
guided propagation or free propagation. Guided propaga- ones or an all zeros sequence is transmitted, the resulting
tion occurs in man-made guiding channels like waveguides, modulated wave exhibits no transitions, and therefore no
coaxial cables, twisted pair cables, and optical fibers that synchronization information can be extracted.
are examples of traditional wireline communications. On the Figure 3.5 shows the modulation of the codeword 101010
other hand, free propagation occurs between corresponding by means of Polar NZR where bits 1’ and 0 are respectively
antennas in the Earth’s atmosphere and underwater. Free represented by transmitting a positive or negative square
propagation is, of course, the basis of wireless broadcasting. pulse for the duration of the bit Tb . Unless the incoming
sequence has an even distribution of zeros and ones, the
3.1 About Physical and Link Layers… 39

Fig. 3.2 Battery life and LLNs

LONG BATTERY LIFE

LOW POWER CONSUMPTION

LOW SNR

LOW CHANNEL CAPACITY HIGH BIT ERROR RATE

LOW TRANSMISSION RATE HIGH PACKET LOSS

LOW POWER LOSSY NETWORK (LLN)

... ...

k-BIT MESSAGE n-BIT CODEWORD 1 0 1 0 1 0

BLOCK CODES

Fig. 3.3 Block codes

Tb t

1 0 1 0 1 0 Fig. 3.6 Unipolar RZ

1 0 1 0 1 0
Tb t

Fig. 3.4 Unipolar NRZ

Tb t

1 0 1 0 1 0

Fig. 3.7 Bipolar RZ (AMI)

Tb

t for half the duration of the bit Tb , and bit “0” is modulated
by not transmitting any signal during that period. Because
the DC component of any waveform modulated by this
mechanism is always positive, it is not a good alternative for
modulation over wireline channels. However, as opposed to
Fig. 3.5 Polar NRZ
unipolar NRZ, clock information can be extracted if an all-
one sequence is received.
Figure 3.7 shows the modulation of the codeword 101010
modulated wave exhibits a positive DC component, and no by means of Bipolar RZ, also known as Alternate Mark
synchronization information can be extracted deeming this Inversion (AMI). Under this scheme bit 1 is modulated by
modulation impractical in most wireline channels. transmitting a square pulse of alternate positive and negative
Figure 3.6 shows the modulation of the codeword 101010 amplitudes for half the duration of the bit Tb , while bit 0 is
by means of Unipolar Return-to-Zero (RZ). Bit “1” is mod- modulated by not transmitting any signal during that period.
ulated by transmitting a square pulse of positive amplitude The DC component of a bipolar RZ modulated wave is al-
40 3 Physical and Link Layers

data

1 0 1 0 1 0 1 0 1 0 1 0

1 1 0 0 1 1 0

Tb Tb t

reference differentially encoded data

Fig. 3.10 Differential encoding

Fig. 3.8 Manchester code

10 01 11 01 11 00
1 0 0 0 1 0
0 after 0

Ts
0 after 1
t
t 1

Tb

Fig. 3.11 Multilevel pulse-amplitude modulation

Fig. 3.9 Modified Miller code

ways zero, and synchronization information can be extracted

1 0 1 1 1
if the input sequence includes ones. This line code is the base
of many wireline modulation schemes.
Figure 3.8 shows the modulation of the codeword 101010 t
by means of Manchester Code, also known as Split Phase.
Bit 1 is modulated by transmitting a symbol that has positive
amplitude for half the duration of the symbol Tb , and it has
negative amplitude for the other half. Similarly, bit 0 is mod-
Fig. 3.12 FSK
ulated by transmitting a symbol that has negative amplitude
for half the duration of the symbol Tb , and it has positive
amplitude for the other half. The modulated wave does not reference if the input bit is zero. The output bitstream is then
have a DC component because the symbols themselves do not modulated with a line code like unipolar NRZ.
have DC components. Moreover, because each symbol tran- Figure 3.11 shows the modulation of the codeword
sitions between negative and positive levels, synchronization 100111011100 by means of multilevel pulse-amplitude
information can be extracted from the modulated wave. modulation (PAM). Under this scheme, groups of two bits
Figure 3.9 shows the modulation of the codeword 100010 are mapped into different levels of the square signal with
by means of modified Miller code (MMC) where bit 1 is pulses transmitted every Ts seconds. In general, if n bits are
modulated by transmitting pulses and bit 0 is modulated by mapped into M = log2 (n) levels, the scheme is known as
transmitting a pulse (or not) depending on the previous sym- PAM-M. The scheme shown in Fig. 3.11 is, therefore, known
bol. This mechanism attempts to introduce signal transitions as PAM-4.
even when multiple zeros are transmitted sequentially. Line codes are typically suitable for wireline communica-
Figure 3.10 shows the modulation of the codeword tions, but they get filtered out when transmitted over wireless
101010 by means of differential encoding where given a channels like radio and satellite links that are passband.
reference bit, the output bit is identical to this reference if Because continuous wave sinusoidal carriers are compatible
the input bit is one and the output bit is the opposite of the with passband channels, they are the preferred mechanism
3.1 About Physical and Link Layers… 41

digits QPSK

1 0 1 1 1
00

01

Fig. 3.13 PSK

10
digit FSK PSK

0 11

Fig. 3.16 QPSK digital-to-analog mapping

1

respectively, depending on whether a digital one or zero is

Fig. 3.14 FSK and PSK digital-to-analog mapping transmitted.
In the case of PSK, the phase separation between each
sinusoidal is 180◦ . This PSK scheme with 2 signals is also
1 0 1 1 1 called binary PSK (BPSK) or 2-PSK. This idea can be
further extended by grouping multiple digits into sinusoidal
waves with different phase values. When mapping 2-bit
t digits into these signals, the phase separation is 90◦ instead.
This scheme, shown in Fig. 3.16, is called Quadrature PSK
(QPSK) or 4-PSK. One issue with QPSK is when transition-
ing from 00 to 11. This situation introduces a phase shift
Fig. 3.15 ASK of 180◦ that, as it can be seen, is responsible for bandwidth
widening and additional noise. To prevent this, QPSK is mod-
ified as Offset QPSK (OQPSK) where 180◦ phase transitions
for digital transmission in wireless environments [12]. The are done in two 90◦ -transition stages. In addition, PSK can
characteristics of the passband channel, that is, the lowest be further modified to rely on relative phase differences as
and highest frequencies, determine the sinusoidal carrier opposed to absolute phase values. The idea is to improve
frequency to use in a digital passband modulation scheme. the symbol detection capabilities at the receiver. This leads
Depending on what carrier parameter is used to carry digital to a modulation scheme called Differential PSK (DPSK).
information, modulation can be frequency-shift keying (FSK) Examples of DPSK are DBPSK when the PSK signal is
or phase-shift keying (PSK). FSK, shown in Fig. 3.12 and binary.
PSK, shown in Fig. 3.13, rely on changing the carrier fre- If, besides the phase, the carrier amplitude is also modi-
quency and phase, respectively. Both FSK and PSK are the fied, the modulation scheme is called quadrature amplitude
digital equivalents of analog frequency modulation (FM) and modulation (QAM). When eight signals are used to map 3-
phase modulation (PM) modulations and therefore exhibit bit digits, illustrated in Fig. 3.17, the modulation is called
constant envelopes that increase reliability against impair- 8-QAM. In general, if M is the number of symbols, then
ments in wireless channels. n = log2 (M) is the number of bits per symbol. Note that this
Essentially FSK and PSK provide a one-to-one mapping scenario leads to M-QAM, M-PSK, and M-FSK modulation
between binary digits zero and one and the sinusoidal wave- schemes. Because the receiver must detect the different sym-
forms illustrated in Fig. 3.14. Another scheme, not as popular bols to perform inverse mapping, for fixed symbol energy, a
as FSK and PSK, that is analogous to analog amplitude larger number of symbols implies a higher likelihood that the
modulation (AM) is amplitude-shift keying (ASK). ASK, receiver will fail to correctly demodulate them due to channel
shown in Fig. 3.15, relies on changing the amplitude of a noise. Similarly, a larger number of symbols translates into a
sinusoidal carrier based on the input bitstream. Specifically, higher transmission rate as each symbol is transmitted on a
the amplitude of the signal is either maximum or zero, fixed time interval. In general, as part of a trade-off known
42 3 Physical and Link Layers

Fig. 3.17 8-QAM digits 8-QAM digits 8-QAM

digital-to-analog mapping

000 100

001 101

010 110

011 111

as rate-distortion, higher transmission rates correspond to to each of them. For example, in a simplified scenario with
higher distortion. two carriers (K = 2), one carrier can modulate QPSK and
another 64-QAM such that the overall transmission rate is
Example 3.1 If a wireless sensor relies on a 8-PSK given by the aggregate of the rates over each subchannel,
modulation scheme and the symbol duration is namely, R = 2+6 T
= T8 bps.
T = 25 µs, what are the symbol (Rs ) and transmission Another popular mechanism that enables the modulation
(Rb ) rates? of binary streams in wireless scenarios is spread spectrum
(SS) [26]. Let’s assume a 101 bit sequence is to be transmit-
ted, that sequence can be represented as a signal b(t) with
Solution Symbol rate is Rs = T1 = 40,000 symbols amplitudes 1 and −1 representing binary ones and zeros,
per second. Transmission rate is Rb = log2 (8) × Rs = respectively. If each bit is transmitted every Tb seconds, it
120 Kbps. is possible to find another signal c(t) with period Tb that
represents a pseudo-random sequence, known as code, that
includes a number of binary digits, known as chips, transmit-
All passband modulations presented so far rely on a single ted every Tc seconds.
carrier acting at any time. It is natural to think that this
scheme can be expanded to simultaneously rely on multiple
Example 3.2 An OFDM scheme consists of 16 QPSK
carriers each one using a particular modulation. The idea is to
subchannels with symbol duration T = 3.2 µs, what
divide the available channel bandwidth W into a number of
is the transmission rate (Rb ) ?
subchannels of equal bandwidth f such that, as illustrated
in Fig. 3.18, around K = W/f subchannels are avail-
able for modulation. When the carrier waves are orthogonal,
Solution Symbol rate is Rs = T1 = 312,500 symbols
that is  T per second. Transmission rate is Rb = 16 × log2 (4) ×
Si (t)Sj (t)dt = 0 (1) Rs = 10 Mbps.
0
where Sn is one M of the symbols associated with the
modulation, T is the symbol length and i = j , and the Figure 3.19 shows both b(t) and c(t), where c(t) is rep-
scheme is called Orthogonal Frequency Division Multi- resented by the pseudo-random 15-chip 100011110101100
plexing (OFDM). Orthogonality improves resilience against code. Of course, in this case, the code length is therefore 15
packet loss caused by channel noise and multipath phe- chips.
nomenon. If T = 1/f , where f is the frequency differ- Under direct-sequence SS (DSSS), the sequence to be
ence between symbol sinusoidal waves, the carrier waves transmitted b(t) is multiplied by the code c(t) to produce
are orthogonal for any possible value of the carrier phase. the spread spectrum signal m(t) shown in Fig. 3.20. When
Because orthogonality restricts the period of each symbol, the destination endpoint receives m(t), it can recover b(t) by
it also imposes a new limitation of the transmission rate in multiplying it by code c(t) because m(t) × c(t) = b(t) ×
each subchannel. In general, depending on SNR subchannel c(t) × c(t) = b(t) since c(t)2 = 1. The requirement is for
characteristics, different modulation schemes can be applied both, transmitter and receiver, to use the same code signal
3.1 About Physical and Link Layers… 43

Fig. 3.18 Discrete multicarrier Sx(f)

modulation

Δf

b(t)

+1
...
-1 TIME

Tb
c(t)

+1
...
-1 TIME

Tc N TC

Fig. 3.19 Modulating wave b(t) and code signal c(t)

b(t)

+1
...
-1 TIME

Tb
m(t)

+1
...
-1 TIME

Tc N TC

Fig. 3.20 b(t) vs. m(t)

c(t). In general, the longer the code, the more the resilience tation of m(t) exhibits a bandwidth that is much larger than
against channel noise and interference. Because each code that of b(t), thus the name spread spectrum. Under DSSS the
identifies each communication path, multiple streams can ratio between the symbol width and the chip width is known
share the same wireless channel. By relying on pulses, m(t) as the spreading factor (or processing gain) SF = TTbc . In
is a line code that cannot be wirelessly transmitted. To general, the higher the spreading factor, the more resilience
provide wireless support, a DSSS signal is modulated by, for against channel noise and interference.
example, BPSK. Another type of spread spectrum is called Frequency
Figure 3.21 shows the m(t) and the corresponding Hopping SS (FHSS) that relies on sequentially spreading the
DSSS/BPSK modulated signal x(t). The spectrum represen- message signal spectrum. Based on the code generated from a
44 3 Physical and Link Layers

Tb = N T c
m(t)

+1
...
-1 TIME

x(t)

...
TIME

Fig. 3.21 b(t) vs. x(t)

Fig. 3.22 Slow FHSS

modulation example FREQUENCY

TS

BAND 111

BAND 110

BAND 101

BAND 100
WC

BAND 011

BAND 010

BAND 001

BAND 000

TIME
INPUT BINARY 01 10 00 11 01 10 10 00 11 00 10 01

PN SEQUENCE 000 011 110 010 001 100

TH

pseudo-random or pseudo-noise (PN) sequence, FHSS relies indicates how fast a different subband is used. Depending
on translating the narrowband modulating wave across differ- on how fast frequency hopping is carried out, there are two
ent predefined subbands associated with carrier locations in possibilities; if in a specific subband multiple symbols are
the frequency domain. The binary stream is first modulated transmitted, that is, R > Rh , the modulation is called slow
by means of M-FSK and then transmitted through carrier FHSS, and, otherwise, if a single symbol is transmitted over
modulation in a specific frequency subband determined by multiple subbands, that is, R ≤ Rh , the modulation is called
the pseudo-random code. Because M-FSK is involved, this fast FHSS.
type of modulation is also known as FHSS/MFSK. Note Figure 3.22 shows tones generated when the binary se-
that under FHSS, the spreading factor is given by the ratio quence 0110001101101000 11001001 is modulated with
between spread signal and the narrowband transmitted wave slow FHSS. Specifically, k = 3 bits from a pseudo-random
(i.e. SF = W Ws
c
). code 000011110010001100 are taken to generate up to 2k =
It is possible to define to two rates, the symbol rate R = 8 possible carrier frequencies associated with eight subbands.
Rb
n
= nT1 b where n = log2 M and the hopping rate Rh that Within each subband, n = 2 bits of the input binary sequence
3.2 Wireline 45

are modulated with M-FSK where M = 2n = 4. The 3.2.1 Ethernet

total number of possible modulated FHSS tones is, therefore,
2k M = 8×4 = 32. Since it is a slow FHSS example, multiple Ethernet was originally designed to provide link-layer con-
symbols or tones are transmitted in any single subband. For nectivity through packet switching. It converts upper network
example, the first two binary symbols 01 and 10 are modu- layer datagrams into frames that are transmitted over wireline
lated over the same subband associated with the PN sequence links. Ethernet is ruled by the IEEE 802.3 standard that
000. When dehopped, the modulated wave exhibits just four supports nominal transmission rates as fast as 400 Gbps
tones that can be demodulated by means of conventional M- [10]. It comprises several signaling and wiring variants of
FSK mechanisms. the IETF/OSI physical and data link layer layers. Although
Figure 3.23 shows tones generated when the binary se- Ethernet has been traditionally used with higher layer net-
quence 01100011 is modulated with fast FHSS. As in the working protocols like IP, UDP, and TCP, it provides a natural
slow FHSS case, k = 3 bits from the same pseudo-random solution to high-end IoT communication.
sequence 000011110010001100 are taken to generate up to
2k = 8 possible carrier frequencies associated with eight 3.2.1.1 Physical Layer
subbands. Within each subband, n = 2 bits of the input Ethernet relies on different media for transmission and prop-
binary sequence are modulated with M-FSK where M = agation. Initially, Ethernet was designed to work with coax
2n = 4. The total number of possible modulated FHSS tones cables with twisted pair and fiber optics support added later.
is, therefore, 2k M = 8 × 4 = 32. Since it is a fast FHSS As these technologies evolved, transmission rates also im-
example, a single symbol is transmitted over two subbands. proved. Initially, nominal maximum transmission rates were
For example, the first binary symbol 01 is modulated over 10 and 100 Mbps, and they were later extended, with the
two subbands associated with the PN sequences 000 and 011. support of fiber options, to 1 Gbps, 10 Gbps, 40 Gbps and
When dehopped and, as for the slow FHSS case, the modu- 100 Gbps. In 2017 200 and 400 Gbps Ethernet transmission
lated wave exhibits just four tones that can be demodulated by rates were standardized as IEEE 802.3bs-2017. As with most
means of conventional M-FSK mechanisms. Note that spread wireline technologies, the Ethernet physical layer relies on
spectrum techniques are typically associated with Code line codes that range from Manchester to multilevel PAM.
Division Multiple Access (CDMA) where communication is Ethernet modulation and demodulation consist of the gen-
only possible if devices and applications know the associated eration and detection of these line codes. Synchronization
code. between endpoints results from a well-known pattern of bit
transitions that are described in the following section.
3.2.1.2 Link Layer
3.2 Wireline Figure 3.24 shows an Ethernet frame that encapsulates a
network layer datagram. The preamble is a 7-byte pattern of
In the context of IoT, wireline communications are provided,
alternating zeros and ones used by endpoints to determine bit
among others, by three main technologies: Ethernet, PLC,
synchronization including synchronization information ex-
and MS/TP. Well-known Ethernet provides high transmis-
traction as described in Sect. 3.1. The Start Frame Delimiter
sion rates and low latency but requires dedicated infrastruc-
(SFD) is a 10101011 sequence that indicates the actual start
ture either through an electrical twisted pair or through fiber
of the frame and enables the receiver to locate the subsequent
optics. Ethernet is a general-purpose networking physical
fields of the frame. The destination address (DA) field iden-
and link layer protocol that can be used in IoT networks.
tifies the station or stations for which this frame is intended.
On the other hand, because the main goal is to support
It may be a unicast (one endpoint), a multicast (a group of
communication technologies that lower deployment costs
endpoints), or a broadcast address (all endpoints). The source
and times, PLC overlaps modulating waves over pre-existent
address (SA) identifies the station that is transmitting the
electrical wiring infrastructure. The price to pay for minimal
frame. If the Ethernet frame is fully compliant with IEEE
deployment and operation costs is low transmission rates as
802.3, the length field specifies the size of the data payload
well as high latency and packet loss. There are two main
field in units of bytes. If the Ethernet frame, on the other hand,
PLC technologies: (1) ITU-T G.9903 standardized from a
complies with the older Ethernet II specification, the length
well-known industrial technology known as G3-PLC and (2)
encodes an ethertype field that indicates the type of datagram
IEEE 1901.2. MS/TP is a wireline medium access control
transported as payload. Since the MTU size of Ethernet is
method for the RS-485 physical layer that is primarily used
1526 bytes, a payload length equal or larger than 1536 (hex-
in building automation networks like BACnet. RS-485, also
adecimal 0x800) signals an ethertype instead. For example,
known as TIA/EIA-485, defines the electrical characteristics
a 1536 ethertype value indicates that the payload is an upper
of drivers and devices for use in certain architectures that
layer IPv4 datagram; on the other hand, a 34,525 ethertype
provide serial communication.
value (hexadecimal 0x86DD) indicates that the payload is
46 3 Physical and Link Layers

Fig. 3.23 Fast FHSS

FREQUENCY
modulation example

TH TS

BAND 111

BAND 110

BAND 101

BAND 100

WC
BAND 011

BAND 010

BAND 001

BAND 000

TIME
INPUT BINARY DATA 01 10 00 11

PN SEQUENCE 000 011 110 010 001 100

7 1 6 6 2 N1 N2 4

PREAMBLE S DA SA LEN LLC DATA P FCS

N1,2 variable length field

DA destination address
SA source address
S start of frame delimiter
FCS frame check sequence
P padding

Fig. 3.24 Ethernet frame

an upper layer IPv6 datagram. For IEEE 802.3 compatible by means of the Subnetwork Access Protocol (SNAP), also
frames that do not include an ethertype, upper layer generated shown in Fig. 3.25, that supports the identification of upper
payloads are signaled through an additional LLC layer that is layer datagrams by means of an organization identifier and
placed as Ethernet data. For all cases, the frames must be long an ethertype field.
enough to comply with collision detection requirements. If Ethernet as other wireline physical layer technologies
frames are not long enough, padding bits are typically added. relies on full duplex communications where devices and ap-
The very last field of an Ethernet frame is the frame checksum plications can simultaneously transmit and listen for frames.
(FCS) that through a 32-bit cyclical redundancy checking This fact leads to Carrier Sense Multiple Access with Colli-
(CRC) block code provides basic channel encoding. sion Detection (CSMA/CD) that is a generic mechanism for
IEEE 802.2, the LLC protocol that is transported on MAC under Ethernet.
top of standard IEEE 802.3, provides both unreliable The medium is shared so a device transmits frames if the
connectionless and reliable connection-oriented delivery channel is idle. If it is busy, a device continues to listen until
of frames. Connectionless delivery, in addition, supports the channel is idle, at this point it transmits immediately. If a
optional acknowledgments. Figure 3.25 shows the Service collision is detected during transmission, the device transmits
Access Point (SAP) header that includes a Destination a brief jamming signal to assure that all stations know that
Service Access Point (DSAP), a Source Service Access there has been a collision, so they can cease transmitting. The
Point (SSAP), and a control field. Both DSAP and jamming signal is a 32-bit to a 48-bit pattern of alternating
SSAP identify the source and destination addresses of ones and zeros. After transmitting the jamming signal, the
the upper layer protocols multiplexed under IEEE 802.2. device waits for a random amount of time, known as expo-
The control field signals mode selection as well as the nential backoff, and then it attempts to transmit the frame
messaging mechanism to provide connection-oriented and again. Essentially retransmissions are delayed by an amount
connectionless communications. IEEE 802.2 can be extended of time derived from a fixed interval of time that depends
3.2 Wireline 47

Fig. 3.25 IEEE 802.2 1 1 1/2 variable

DSAP SSAP CTRL DATA

IEEE 802.2 (SAP)

1 1 1/2 3 2 variable
DSAP SSAP CTRL OID ETHERTYPE DATA

IEEE 802.2 (SNAP)

DSAP destination service access point

SSAP source service access point
CTRL control field
OID organization id

3.2.2.1 Physical Layer

START

Example 3.3 Consider a sensor that transmits 5-

c=0 byte readouts every 20 ms and assume that the
overhead due to network, transport, and session
WAIT BACKOFF layer headers is 48 bytes. What is the efficiency of
SEND FRAME the communication system if the physical and link
layers are 10 Gbps Ethernet? The efficiency η is,
c = c + 1; backoff = rand(0,2c) as described in Problem 2.7, given by η = CR where
YES R is the transmission rate and C is the channel capacity.
COLLISION ?

SEND JAMING SIGNAL Solution The transmission rate R is given by R = TL =

NO 29,200 bps where L = 8 × (5 + 48 + H ), H = 20 is
the Ethernet header size as per information shown in
SUCCESS Fig. 3.24 and T = 20 ms. The efficiency is given by
η = CR = 2.92 × 10−6 where C = 10 × 109 bps. The
Fig. 3.26 CSMA/CD efficiency is therefore around 0.0003%.

Electrical power lines are not good at transmitting pulses

on the transmission rate known as slot time and the number and line codes as they are intended for the transmission
of retransmission attempts. After a c number of collisions, of AC signals over very long distances. Electrical power
a random number of slot times between 0 and 2c − 1 is is usually propagated over wires as a high-voltage sinu-
selected as exponential backoff. Figure 3.26 illustrates the soidal of fixed frequency (50 or 60 Hz depending on the
flow diagram of the CSMA/CD algorithm. country). This power sinusoidal is combined with device
data streams modulated through low-voltage carriers. ITU-T
G.9903, which standardizes 3G-PLC, establishes OFDM as
3.2.2 ITU-T G.9903 the modulation mechanism that divides a 500 KHz channel
into 128 subschannels. At any given time, only 36 subchan-
ITU-T G.9903 provides physical and link layer mechanisms nels are active for communications. Within each subchannel,
for low-rate data transmission over electrical wiring that are the carrier is modulated by means of DPSK, DQPSK, D8-
based on the protocols introduced by mainstream industrial PSK, and 16-QAM that carry 1, 2, 3, and 4 bits per symbol,
G3-PLC [21]. The advantage of this technology is that respectively. FEC is provided by means of a cascade between
deployment and maintenance costs are minimized since it a convolutional encoder, a Reed-Salomon block encoder, and
relies on pre-existent wiring infrastructure. 3G-PLC has been a scrambler that swaps bits of the output stream. Figure 3.27
mainly used for remote metering in smart grid scenarios, shows the building blocks of the ITU-T G.9903 physical
but its use has been extended to other applications ranging layer. Effective transmission rates of G.9903 range from
from home automation to plain Internet access. From an IoT 2.4 to 34 Kbps. This is fast enough to support many IoT
perspective, 3G-PLC has been standardized as ITU-T G.9903 applications.
by the G3-PLC Alliance in order to provide large-scale
connectivity over the electrical grid. IPv6 support, when ITU- 3.2.2.2 Link Layer
T G.9903 is in place, results from the 6LoWPAN mechanism Because a power line relies on a single wire, 3G-PLC devices
introduced in Sect. 4.3. can either transmit or receive packets but cannot do both tasks
48 3 Physical and Link Layers

Fig. 3.27 ITU-T G.9903

physical layer OFDM CONV ENCODER BLOCK ENCODER SCRAMBLER

end of last
CFS HPCW NPCW
transmission NO RESPONSE
CIFS CIFS contention state

CIFS contention interframe spacing

CFS contention free slot
end of last ACK HPCW high priority contention window
transmission NPCW normal priority contention window
RESPONSE
RIFS CIFS Fig. 3.29 Priority resolution

Fig. 3.28 End of transmission

priority devices compete during the High Priority Contention
Window (HPCW) and Normal Priority Contention Window
at the same time. This limitation leads to a MAC mechanism
(NPCW), respectively. Because HPCW is located before
that is performed by means of carrier sense multiple access
NPCW, high-priority devices access the channel before nor-
with collision avoidance (CSMA/CA). This mechanism pro-
mal priority devices.
vides transmitters with access to the channel after a random
Figure 3.30 shows a G3-PLC frame that includes several
backoff time that minimizes the collisions between contend-
fields; (1) a 9.5-byte preamble that is used for endpoint syn-
ing devices. When a device wants to transmit frames, it waits
chronization, (2) a 5-byte Frame Control Header (FCH) that
for a random time period, after which if the channel is found
carries control information needed to correctly demodulate
idle, transmission starts. If, on the other hand, the channel is
the received signal, (3) a payload that carries the network
busy, the device waits for another random time period before
layer datagram with its length determined from the trans-
attempting to retransmit.
mission mode (normal or robust), (4) FEC that relies on
As in the Ethernet case described in Sect. 3.2.1, the ran-
Reed-Salomon block and convolutional codes and enables
dom exponential backoff mechanism tends to progressively
error correction, and (5) 2-byte FCS field that, in any mode,
reduce the probability of collisions with the number of re-
enables error detection. In robust mode, to support additional
transmission attempts. The contention period starts after the
reliability, a repetition code is used after the convolutional
last transmission is detected, but there are two possibilities
encoder to repeat the bits at the output of the convolutional
depending on whether this transmission requires a response
encoder four times.
from its intended receiver. When a response is needed, it can
be in the form of an acknowledgment (ACK) or a negative
3.2.3 IEEE 1901.2
acknowledgment (NACK). In this case, after the transmission
is finished, there is a fixed time period known as the response
IEEE 1901.2 is another PLC mechanism similar to 3G-PLC
interface spacing (RISF) before the receiver transmits an
that supports physical and link layer mechanisms for low-
ACK or a NACK. If the transmitter does not receive an ACK
rate data transmission over electrical wiring [5]. It supports
after a waiting time period, it assumes that the transmission
slightly higher transmission rates than 3G-PLC, but as the
was unsuccessful and retries the frame transmission. If an
latter, it relies on 6LoWPAN adaptation to support IPv6.
ACK is still not received after several retries, the transmitter
Standardization started in 2009 triggered by interest of the
can choose either to terminate the transaction or to start again.
automotive industry in providing electric vehicles to charging
If no response is needed or if response is needed and it has
station communication. Additional applications include grid
been received, the contention period starts after a fixed time
to utility metering and HANs.
period known as contention interframe spacing (CIFS). This
mechanism is illustrated in Fig. 3.28. 3.2.3.1 Physical Layer
Under ITU-T G.9903 transmission supports two levels of As G3-PLC, IEEE 1901.2 relies on OFDM for low-frequency
priority; high and normal levels that map into two contention modulation, under 500 KHz, in narrowband power line de-
time windows shown in Fig. 3.29. The first contention slow vices via AC and DC power lines. The standard supports
is called Contention Free Slot (CFS) that is used for trans- indoor and outdoor transmissions over several types of lines:
mission of subsequent segments of a MAC frame without (1) low-voltage lines, less than 1000 V, like the lines between
the backoff mechanism in order to prevent interruption from transformers and meters; (2) low-voltage to medium lines,
other devices. This happens when the first segment is sent between 1000 V and 72 KV, like the lines between trans-
either as a high or normal priority segment and all subse- formers; and (3) long distance for multirange rural commu-
quent segments are sent in the CFS. The high and normal nications. Based on the geographical region, three frequency
3.2 Wireline 49

bands are available. As for any PLC technology, and because in Sect. 3.3.3, they rely on 6LoWPAN adaptation to support
of the inherently low EMI, devices can transmit in frequency IPv6.
bands that relying on relatively small guardbands exhibit
little disturbance. Depending on the transmission rate and
3.2.4 MS/TP
reliability, the number of subchannels varies.
In a typical example, the 500 KHz band provides
The Master-Slave/Token-Passing (MS/TP) protocol relies on
an OFDM scheme over 72 subchannels. Supported per
a RS-485 physical layer that enables devices to relay and
subchannel modulations are DPSK, DQPSK, D8-PSK,
exchange information. In addition, MS/TP and RS-485 are,
BPSK, QPSK, 8-PSK, and 16-QAM. Typical transmission
respectively, the link and physical layers of the BACNet
rates are around 500 Kbps. IEEE 1901.2 relies on adaptive
protocol stack [23]. MS/TP is a peer-to-peer, master/slave
tone mapping (ATM) that dynamically selects the usable
protocol that supports multiple masters. The mechanism is
tones and the optimum modulation and coding schemes that
based on a token passing scheme.
ensure reliable communication over the wireline channel.
3.2.4.1 Physical Layer
3.2.3.2 Link Layer
RS-485 enables communications in inexpensive LANs with
Two types of frames are supported: (1) data frames and (2)
multidrop links relying on differential signaling over twisted
ACK/NACK frames. Figure 3.31 shows the frame structure
pairs. Differential signaling consists of transmitting data by
where each frame starts with a (1) preamble used for syn-
means of two complementary electrical signals that, when
chronization and detection as well as to signal automatic
subtracted at the receiver, minimize noise. Figure 3.32 illus-
gain control (AGC). The preamble is followed by a FCH that
trates an example of differential signaling when one bit is
specifies the number of symbols depending on the number of
transmitted over two separate lines. The transmitter generates
carriers used by the OFDM scheme. This header also contains
two pulses of different polarity that are affected by the
information regarding modulation and the length of the cur-
same channel noise. On the receiver, the noisy pulses are
rent frame in symbols. The FCH also includes a FCS field that
subtracted, and the noise is canceled out resulting in a single
is used for error detection. The size of the FCS depends on the
large output pulse.
frequency band being utilized. From a topology perspective,
As shown in Fig. 3.33, MS/TP follows a bus topology
IEEE 1901.2 networks are typically deployed following a
with devices deployed in a daisy chain configuration where
full mesh structure. Because IEEE 1901.2 frames follow a
each device is connected point-to-point to one or two peers
similar structure to that of IEEE 802.15.4 frames presented
depending on its location in the network. Connectivity is

Fig. 3.30 G3-PLC frame 9.5 5 n1 n2 2

PREAMBLE FCH DATA PAYLOAD FEC FCS

FCH frame control header

FEC forward error correction
FCS frame checksum

Fig. 3.31 IEEE 1901.2 frame 9.5 5 n

PREAMBLE FCH DATA PAYLOAD

FCH frame control header

Fig. 3.32 Differential signaling RX

1 TX - detector 1
50 3 Physical and Link Layers

3.3 Wireless

As with any other IoT communication technology, and as

indicated in Sect. 3.2, the main goal is to lower deployment
costs and times. Because when comparing wireless and wire-
line technologies the former have considerable lower infras-
tructure cost, they are the preferred mechanisms for IoT sce-
Fig. 3.33 Daisy chain configuration narios. Under wireless communication, signal propagation
is by means of antennas. Antennas provide the mechanisms
for the conversion of electrical signals into electromagnetic
provided by means of low capacitance shielded twisted pair waves and vice versa. There are two types of antennas; a
cables. MS/TP networks support up to 64 devices, and the transmitting antenna converts a wireline modulated signal
number of devices also determines the transmission range into an electromagnetic wave that is radiated in a specific di-
and data rate. The maximum bus length and the maximum rection. Similarly, a receiving antenna converts the irradiated
transmission data rate are 1.2 km and 115.2 Kbps, respec- electromagnetic wave back into a wireline modulated signal.
tively. In general, 115.2 Kbps is not achievable in a 1.2 km The electromagnetic wave power is measured in terms of
long network, and much lower transmission rates are typ- effective irradiated power (EIRP) that assumes transmission
ical. Addresses 0 through 127 are used to identify mas- as being originated by an isotropic point source. An isotropic
ter devices, while the 255 destination address is used for point source is an ideal antenna that transmits power uni-
broadcasting. formly in all directions.
The wireless radio-frequency section of the electromag-
3.2.4.2 Link Layer netic spectrum lies between the frequencies of 9 kHz and
As its name indicates it, MS/TP relies on a master-slave 300 GHz such that different bands of the spectrum are used
scheme where transmissions are enabled by means of a token to deliver different services. The wavelength and frequency
passing mechanism. In other words, the token is used to of electromagnetic radiation are related via the speed of light
control device access on the bus. An MS/TP master endpoint through the λ = fc expression where λ is the wavelength,
can transmit a frame when it holds the token. When it is done c is the speed of light, and f is the frequency. Table 3.1
transmitting, it passes the token to the next master device shows the subdivisions of the radio-frequency spectrum. IoT
which is determined by its MAC address. wireless solutions heavily rely on unlicensed Instrument,
Figure 3.34 shows an MS/TP frame; it includes a header Scientific, and Medical (ISM) bands [25]. There are many
that starts with a 2-byte preamble encoded as a hexadecimal frequencies that fall under the umbrella of ISM bands, but the
value 0x55ff, it follows a 1-byte frame type field, a 1-byte three most important lie at 915 MHz (868 MHz in Europe),
destination address, a 1-byte source address, a 2-byte data 2.4, and 5.8 GHz. Additional unlicensed ISM bands are also
length, and a 1-byte header checksum which is computed by available for other applications like the 13.56 MHz ISM
means of a CRC code. The header is followed by a variable band that is intended for near-field communication (NFC)
length data payload and a 5-byte data payload checksum that or the 433 MHz ISM band that is used for radiolocation.
is also CRC based. The frame finishes with an optional 1- In the case of ISM bands, higher frequencies translate into
byte padding. Note that data payload and data payload check- smaller antennas that enable smaller hardware form factors.
sum are encoded using Consistent Overhead Byte Stuffing Higher frequencies, however, are typically associated with
(COBS). COBS provides a technique that enables the re- worse signal penetration and propagation. Therefore Sub-
moval of preamble sequences from these data fields. MS/TP GHz bands exhibit better propagation properties than super-
IPv6 support is provided by means of partial support of IP GHz bands. Super-GHz bands, however, are less restrictive
header compression supported by 6LoWPAN and described and leverage from more relaxed regulations that, for example,
in Sect. 4.

Fig. 3.34 MS/TP frame 2 1 1 1 2 1 n 5 1

PREAMBLE FT DA SA LENGTH HCS DATA PAYLOAD DCS P

FT frame type
DA destination address
SA source address
HCS header checksum
DCS data checksum
P padding
3.3 Wireless 51

Table 3.1 Radio-frequency spectrum the power limitations that result from the need of extended
Transmission type Frequency Wavelenth battery life. Similarly, media access contention is aggravated
Very low frequency (VLF) 9–30 kHz 33–10 km by the fact that collisions can be avoided but not detected
Low frequency (LF) 30–300 kHz 10–1 km because devices either transmit or receive frames at any given
Medium frequency (MF) 300–3000 kHz 1000–100 m time but cannot do both things at the same time.
High frequency (HF) 3–30 MHz 100–10 m Media access is also affected by two situations indicated
Very high frequency (VHF) 30–300 MHz 10–1 m in Fig. 3.35: (1) the hidden station problem that results from
Ultra high frequency (UHF) 300–3000 MHz 1000–100 mm stations A and C transmitting simultaneously to station B
Super high frequency (SHF) 3–30 GHz 100–10 mm and not detecting each other since they are out of range and
Extremely high frequency (EHF) 30–300 GHz 10–1 mm (2) the exposed station problem that results from station C
transmitting to station D and preventing station B to transmit
Table 3.2 Radio-frequency spectrum to station A. In general terms, the hidden station problem
RF band Wireless network specifica-
leads to excessive bit errors and therefore packet loss. The
tion exposed station problem leads to excessive latency that, in
915/868 MHz ISM IEEE 802.15.11ah, IEEE turn, becomes packet loss from an application perspective.
802.15.4, ITU-T G.9959, Essentially, packets that arrive too late are not useful and can,
BLE, LoRa, SigFox therefore, be considered lost by the application. Again, this
2.4 GHz ISM IEEE 802.11ax, IEEE depends on the nature of the application and QoS goals.
802.15.4, BLE, LoRa
This section introduces several wireless physical and link
5.8 GHz IEEE 802.11ac, IEEE
802.11ax layer technologies that are selected based on their native
support of IPv6. This support is either direct or by means of
an adaptation mechanism. This means that some well-known
do not impose power duty cycle limits that lower transmis- stacks like ANT+ are not included in this section because they
sion rates. do not have standard support of IPv6 adaptation.
Table 3.2 shows the some wireless IoT technologies as-
sociated with the ISM bands. The table shows both WPAN
and LPWAN technologies discussed in this chapter and in 3.3.1 IEEE 802.11
Chap. 8. In general, regulatory authorities in countries and
regions control the use of the spectrum by means of frequency Wireless Fidelity (Wi-Fi), also known as IEEE 802.11, is
band allocation for both licensed and unlicensed services an umbrella term for a number of technologies that are the
including the maximum allowable transmission power levels. wireless equivalent of Ethernet in the IoT world [8]. It
These legislation differences make very difficult the full includes many standard protocols that support a wide range
standardization of frequency band allocation and maximum of transmission rates and exhibit different levels of power
power levels by ITU and other standardization bodies. More- consumption. A few of these protocols are optimized for
over, they introduce hardware and software design interoper- IoT scenarios and have power efficiency as main goal. The
ability issues that affect deployment and maintenance costs. IEEE 802.11 standard provides a physical and link layer
The use of unlicensed bands under ISM implies that anyone mechanism for transmission in WLANs and, especially when
can freely use them if transmission power is low enough to considering IoT, WPANs.
minimize interference. However, if too many devices use the IEEE 802.11 networks rely on three main elements: (1)
same unlicensed band, it can eventually become unusable. stations that play the role of IoT access devices, (2) access
This is the case of the 2.4 GHz ISM band that is overcrowded points (APs) that play the role of IoT gateways interfacing
with device communications ranging from cordless phones between access and core networks, and the (3) distribution
to IoT sensors. system that provides the backbone for connectivity to appli-
Wireless, when compared to wireline communication, is cations performing analytics. Stations are grouped in what is
affected by three well-known problems: (1) data link reliabil- known as the Basic Service Set (BSS). APs, as most IoT gate-
ity issues due to the fading caused by multipath phenomena ways, include multiple communication stacks; IEEE 802.11
that results on bit errors that lead, in turn, to packet loss, to interact with the access side and some other technology,
(2) media access issues due to the contention of multiple like Ethernet, to interact with the core side. When considering
devices attempting to simultaneously transmit data over the both access and core networks, the whole infrastructure is
same wireless channel, and (3) security due to the fact that known as the Extended Service Set (ESS).
wireless transmissions by virtue of being open are more With IEEE 802.11, a BSS responds to a WLANs or
likely to be intercepted than those in a wireline scenario. WPANs that is under the control of a single AP. The AP, in
In the case of IoT, reliability is further degraded because of turn, enables communications by devices that use a common
52 3 Physical and Link Layers

Fig. 3.35 Contention problems

HIDDEN STATION

STATION BRANGE

STATION C RANGE

STATION D RANGE
STATION A RANGE

STATION B RANGE

STATION CRANGE
STATION A STATION B STATION C STATION D

X EXPOSED STATION

respectively. In an ad hoc IEEE 802.11 network, a BSS is

em known as Independent BSS (IBSS) since devices communi-
tion syst
distribu cate directly with each other without the intervention of an
AP. Moreover, the lack of an AP also implies that there is
no core network and therefore no ESS. Note that in an IBSS,
a randomly generated SSID and the other physically layer
parameters are broadcasted by beacon frames transmitted by
devices. Under infrastructure mode, on the other hand, all
communication between devices on the same BSS is through
an AP that acts as a gateway and provides connectivity to
the core side. This superset of access devices, AP, and core
network makes the ESS. Note that a single ESS can be
composed of multiple BSS with several APs providing inter-
Fig. 3.36 Basic service set (BSS)
BSS device connectivity.
The presence of an AP determines how communication
between devices in the same BSS is. In infrastructure mode,
Fig. 3.37 Independent basic
service set (IBSS)
packets sent from one device to another are transmitted
through an AP, while in ad hoc mode packets go directly
from source to destination. Infrastructure mode, therefore,
exhibits higher latency, but it also improves reliability as the
AP can buffer packets if the destination device is out of reach,
sleeping, or disabled. This is particularly important in the
context of IoT where connectivity is M2P between sensing
and actuation devices and applications performing analyt-
ics. In this context, communication between devices is not
common, and the use of IEEE 802.11 is almost exclusively
restricted to infrastructure mode.
BSS Identifier (BSSID) in order to share the wireless chan-
 Infrastructure BSS and IoT IoT architectures, that are
nel. The BSSID as well as other physical layer parameters
based on devices communicating with applications by
like transmission rates and other modulation attributes are
means of gateways, fit very well the infrastructure
transmitted in beacon frames that are broadcasted at regular
operation model of IEEE 802.11. In this context, IoT
intervals by APs and devices.
devices are IEEE 802.11 stations and IoT gateways are
Traditionally IEEE 802.11 defines two modes of operation
IEEE 802.11 APs. The distribution system is the IP
of a single BSS; ad hoc and infrastructure modes that are
core that carries IP traffic to and from the application
representative of the topologies shown in Figs. 3.36 and 3.37,
as shown below.
3.3 Wireless 53

access core

IP

station (device) AP (gateway) distribution system application

BSS
ESS

3.3.1.1 Physical Layer that results from aggregating all the code bits from the
The initial standardization of IEEE 802.11 presented two al- individual subchannels. The table also presents the FEC
ternative physical layer mechanisms: FHSS and DSSS oper- code rate that leads to the number of data bits per symbol.
ating in the ISM 2.4 GHz band. The standard also introduced The number of data bits per symbol, in turn, is used to obtain
an infrared (IR) communication mechanism that was never the actual transmission rate. For example, the fifth row in
fully implemented. Depending on negotiated parameters the the table is 16-QAM which includes 4 bits per subchannel
nominal transmission rate for this basic IEEE 802.11 support and, at 48 subchannels per symbol, leads to 192 code bits per
is either 1 or 2 Mbps. Later amendments to the standard led by symbol. With a 1/2 code rate, this translates to 192×1
2
= 96
power and modulation scheme changes improve transmission data bits per symbol that sent every 4 µs corresponds to a
rates, energy consumption, and signal range. Chronologically 96
4×10−6
= 24 Mbps transmission rate.
speaking, these amendments are IEEE 802.11a and IEEE IEEE 802.11b was released around the same time as IEEE
802.11b in 1999, IEEE 802.11g in 2003, IEEE 802.11n in 802.11a, but it was designed to operate on the mainstream
2009, IEEE 802.11ac in 2013, and IEEE 802.11ax in 2016. and more crowded ISM 2.4 GHz band. This improves signal
IEEE 802.11ad released in 2012 and IEEE 802.11aj released penetration at a cost of increased interference. For the same
in 2018 introduce support of unlicensed bands in the 45– power consumption and due to its lower penetration, IEEE
70 GHz spectral range available in certain countries. These 802.11a typically requires a larger number of APs to support
two standards enable very high transmission rates in the the same area coverage. IEEE 802.11b divides the ISM
Gbps range. From the IoT perspective (1) IEEE 802.11p was 2.4 GHz band into several overlapping 22 MHz channels.
introduced in 2010 to support Wireless Access in Vehicular Depending on the world region, the total number of channels
Environment (WAVE), (2) IEEE 802.11af in 2014 to provide is anywhere between 11 and 14. IEEE 802.11b supports up
low transmission rates by sending data over digital television to 31 20-µs timeslots.
guardbands, (3) IEEE 802.11ah for generic IoT support in IEEE 802.11b extends traditional IEEE 802.11 by intro-
2016, and (4) IEEE 802.11ba for power efficient, by means ducing additional DSSS based transmission rates. Table 3.4
of an aggressive Wake-up Radio (WUR) duty cycle, narrow illustrates the different modulation schemes that are used
band (NB) IoT access in 2020. under IEEE 802.11b. Note that the first two rows of the table
Many of the amendments to IEEE 802.11 evolve from present the two original IEEE 802.11 modulation schemes.
the original IEEE 802.11a standard. IEEE 802.11a relies on Through 11-chip codes that are used to generate symbols
OFDM operating in the ISM 5 GHz band and providing non- at a rate of 106 symbols per second and relying on BPSK
overlapping 20 MHz channels for modulation. Depending on and QPSK modulations, the maximum nominal transmission
different country regulations the number of channels and rates are 1 and 2 Mbps, respectively. Higher transmission
the maximum EIRP requirements may change. In many rates are obtained by changing the modulation method to a
scenarios upper channels are reserved for outdoor use and differential scheme that relies on D-QPSK and D8-PSK to
therefore increase the EIRP limit. Each of these 20 MHz accomplish 5.5 and 11 Mbps rates, respectively. Note that
channels support 52 OFDM subchannels with carriers sep- in this case, the code length is shorter at 8 chips, while the
arated every 312.5 KHz. Out of the 52 OFDM subchannels, symbol rate is slightly higher at 1.375 × 106 symbols per
48 are used for data transmission, while the remaining four second.
provide frequency and phase signal reference. IEEE 802.11a IEEE 802.11a and IEEE 802.11b rates are dynamically
allows a maximum of 15 9-µs backoff timeslots. selected by means of dynamic rate shifting (DRS). This
Table 3.3 shows the OFDM subchannel modulation mechanism allows the transmission rate to be selected in
schemes used under IEEE 802.11a to support maximum order to compensate for multipath fading and other types of
nominal transmission rates between 6 and 54 Mbps. The interference. If a link is not reliable, devices select lower
table includes the total number of code bits per symbol transmission rates until the communication path is stable.
54 3 Physical and Link Layers

Table 3.3 IEEE 802.11a

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 48 1/2 24 6
BPSK 1 48 3/4 36 9
QPSK 2 96 1/2 48 12
QPSK 2 96 3/4 72 18
16-QAM 4 192 1/2 96 24
16-QAM 4 192 3/4 144 48
64-QAM 6 288 2/3 192 48
64-QAM 6 288 3/4 216 54

Table 3.4 IEEE 802.11 DSSS

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 11 1 1 1
QPSK 11 1 2 2
DQPSK 8 1.375 4 5.5
D8-PSK 8 1.375 8 11

Whenever possible if interference reduction is detected, a physical device over multiple non-overlapping subchannels.
higher transmission rate is selected. This reduction is done Packet bursting improves throughput but introduces addi-
automatically at the physical layer and is transparent to tional network latency as frames are buffered before being
higher layers. transmitted. It also prevents other devices from transmitting
IEEE 802.11g uses the same OFDM modulation scheme as a source station accesses the channel for a compara-
as IEEE 802.11a but operates on the ISM 2.4 GHz band and tively longer amount of time. Similarly, channel bonding
supports transmissions rates between 6 and 54 Mbps. In addi- also improves throughput by increasing the transmission rate
tion, and to provide backward compatibility since they both without affecting latency. The drawback of channel bond-
operate on this band, IEEE 802.11g radios also support IEEE ing, however, is more expensive and complex hardware. In
802.11b transmission modes at a cost of lower throughput. opposition, packet bursting can be purely implemented in
Specifically, IEEE 802.11b devices can associate with IEEE software.
802.11g APs through a number of protection mechanisms MIMO is a technique that consists of using multiple
that enable interoperation; a device sends a Request to Send outgoing and incoming antennas that, exploiting spatial di-
(RTS) control frame to the AP and, in turn, the AP issues versity, lead to extra gain that can be used to defeat chan-
a Clear to Send (CTS) response to grant transmission. This nel noise. MIMO mechanisms increase transmission rates.
interaction minimizes the collisions between IEEE 802.11b With spatial diversity the same signal travels over different
and IEEE 802.11g transmission attempts but increases la- paths and thus is more likely to overcome wireless channel
tency thus lowering throughput. IEEE 802.11b devices can fading. MIMO is not the same as channel bonding, since
also transmit without the RTS/CTS frame exchange and just unlike channel bonding, MIMO achieves higher data rates
relying on the channel state to guarantee that it is clear before without increasing the number of subchannels used. IEEE
transmission. This is particularly useful in BSSs with very 802.11n introduces maximum nominal transmission rates
few devices since it can lead to lower latency and higher of 600 Mbps by combining OFDM with MIMO. Moreover,
throughput. IEEE 802.11g backoff slot parameters follow IEEE 802.11n extends channel bandwidths by combining
those of IEEE 802.11a unless when it is operating under up to two 20 MHz channels in the ISM 2.4 GHz and ISM
mixed mode where an IEEE 802.11g AP interacts with IEEE 5 GHz bands. IEEE 802.11n uses complex synchronization
802.11b devices. In this latter case, IEEE 802.11g backoff mechanisms that attempt to guarantee the highest throughput
slot parameters are those of IEEE 802.11b, and the overall by dynamically adapting channel selection, antenna configu-
network throughput is lowered. ration, modulation schemes, and code rates.
IEEE 802.11g introduces two mechanisms to improve Table 3.5 indicates the modulation schemes used by IEEE
throughput: (1) packet bursting that consists in buffering a 802.11n to accomplish the highest transmission rates. For
number frames before transmitting them all together in order example, the last row in the table is 64-QAM which includes
to lower average channel contention delay and (2) channel 6 bits per subchannel and, at 432 subchannels per symbol,
bonding that consists of transmitting frames of the same leads to 2592 code bits per symbol. With a 5/6 code rate,
this translates to 2592×5
6
= 2160 data bits per symbol that
3.3 Wireless 55

Table 3.5 IEEE 802.11n

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 432 1/2 216 54
QPSK 2 864 1/2 432 108
QPSK 2 864 3/4 648 162
16-QAM 4 1728 1/2 864 216
16-QAM 4 1728 3/4 1296 324
64-QAM 4 2592 2/3 1728 432
64-QAM 6 2592 3/4 1944 486
64-QAM 6 2592 5/6 2160 540

Table 3.6 IEEE 802.11ac

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 1872 1/2 936 260
QPSK 2 3744 1/2 1872 520
QPSK 2 3744 3/4 2808 780
16-QAM 4 7488 1/2 3922 1040
16-QAM 4 7488 3/4 5883 1560
64-QAM 6 11,232 2/3 7488 2080
64-QAM 6 11,232 3/4 8424 2340
64-QAM 6 11,232 5/6 9360 2600
256-QAM 8 14,976 3/4 11,232 3120
256-QAM 8 14,976 5/6 12,480 3467

sent every 4 µs that corresponds to a 4×10 −6 = 540 Mbps

2160 allocation of spectrum for uplink transmissions or dynamic
transmission rate. By reducing by half the symbol guard fragmentation that is used to chunked frames into variable
period, a symbol period of 3.6 µs leads to transmission rate size fragments such that overall overhead is reduced. Both
−6 = 600 Mbps.
2160 nominal transmission rates and latency are greatly improved.
of 3.6×10
IEEE 802.11ac, also known as Wi-Fi 5, extends some Table 3.7 shows the modulation schemes used by IEEE
of the features of IEEE 802.11n to reach a transmissions 802.11ax to reach its highest transmission rates. For example,
rate of 3.4 Gbps. IEEE 802.11ac relies on 80 and 160 MHz the second to last row in the table is 1024-QAM which
channels operating only over the ISM 5 GHz band. Besides includes 10 bits per subchannel and, at 4608 subchannels per
downlink MIMO transmissions, IEEE 802.11ac introduces symbol, leads to 46,080 code bits per symbol. With a 3/4 code
the utilization of beamforming that is signal processing tech- rate, this becomes 46,080×5
6
= 34,560 data bits per symbol
nique to support directional signal manipulation with the goal that sent every 4 µs corresponds to a 4×10 −6 = 9600 Mbps or
34,560

of minimizing interference. 9.6 Gbps transmission rate.

Table 3.6 illustrates the modulation schemes used by IEEE IEEE 802.11p is based on IEEE 802.11a also operating
802.11ac to accomplish its highest transmission rates [24]. in the ISM 5 GHz band and providing support for vehicle-
For example, the second to last row in the table is 256-QAM to-everything (V2X) communication where transmissions are
which includes 8 bits per subchannel and, at 1872 subchan- between vehicles (V2V) or between vehicles and roadside in-
nels per symbol, leads to 14,976 code bits per symbol. With frastructure (V2I). IEEE 802.11p relies on 10 MHz channels
a 3/4 code rate, this translates to 14,976×5
6
= 11,232 data that double the transmission times and therefore reduce the
bits per symbol that sent every 3.6 µs that corresponds to a data rates by half. Transmissions rates of 6, 9, 12, 18, 24,
11,232
3.6×10−6
= 3120 Mbps transmission rate. 36, 48, and 54 Mbps shown in Table 3.3 for IEEE 802.11a
Wi-Fi 5 has led to the development of the next-generation become 3, 4.5, 6, 9, 12, 18, 24, and 27 Mbps under IEEE
Wi-Fi 6 that has been standardized as IEEE 802.11ax. 802.11p.
One important difference with IEEE 802.11ac is that IEEE 802.11af, also known as Super Wi-Fi, relies on
IEEE 802.11ax operates in the 2.4 GHz and the 5 GHz transmitting over unused frequency bands of the licensed TV
ISM bands. Additionally, IEEE 802.11ax improves MIMO spectrum between 54 and 790 MHz. The technology uses
by supporting both downlink and uplink transmissions. cognitive radio to dynamically select the portions of the
Efficiency and performance are also improved by means spectrum that minimize interference. IEEE 802.11af uses the
of other mechanisms introduced by IEEE 802.11ax like same OFDM modulation scheme as IEEE 802.11ac with 6,
trigger-based random access that provides flexibility in the 7, and 8 MHz channels.
56 3 Physical and Link Layers

Table 3.7 IEEE 802.11ax

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 4608 1/2 2304 576
QPSK 2 9216 1/2 4608 1152
QPSK 2 9216 3/4 6912 1728
16-QAM 4 18,432 1/2 9216 2304
16-QAM 4 18,432 3/4 13,824 3456
64-QAM 6 27,648 2/3 18,432 4608
64-QAM 6 27,648 3/4 20,736 5184
64-QAM 6 27,648 5/6 23,040 5760
256-QAM 8 36,864 3/4 27,648 6912
256-QAM 8 36,864 5/6 30,720 7680
1024-QAM 10 46,080 3/4 34,560 8640
1024-QAM 10 46,080 5/6 38,400 9600

Table 3.8 IEEE 802.11af

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 2128 1/2 1064 43.2
QPSK 2 4256 1/2 2128 84.8
QPSK 2 4256 3/4 3192 128
16-QAM 4 8512 1/2 4256 171.2
16-QAM 4 8512 3/4 6384 256
64-QAM 6 12,768 2/3 8512 340.8
64-QAM 6 12,768 3/4 9576 384
64-QAM 6 12,768 5/6 10,640 427.2
256-QAM 8 17,024 3/4 12,768 512
256-QAM 8 17,024 5/6 14,168 569.6

Table 3.8 shows the modulation schemes used by IEEE Table 3.9 shows the modulation schemes used by IEEE
802.11af to accomplish the highest transmission rates. For 802.11ah to accomplish the lowest transmission rates. For
example, the last row in the table is 256-QAM which includes example, the last row in the table is 256-QAM which includes
8 bits per subchannel and, at 2128 subchannels per symbol, 8 bits per subchannel and, at 24 subchannels per symbol,
leads to 17,024 code bits per symbol. With a 5/6 code rate, this leads to 192 code bits per symbol. With a 5/6 code rate, this
translates to 17,024×5
6
= 14,168 data bits per symbol that sent translates to 192×5
6
= 160 data bits per symbol that sent every
every 24.75 µs corresponds to a 24.75×1014,168
−6 = 569.6 Mbps
40 µs corresponds to a 40×10
160
−6 = 4 Mbps transmission rate.

transmission rate.
IEEE 802.11ah, also known as Wi-Fi HaLow, is a Wi- 3.3.1.2 Link Layer
Fi standard intended exclusively for IoT use. As most other IEEE 802.11 devices cannot detect collisions between their
IEEE 802.11 deployments, IEEE 802.11ah networks are own transmissions and those of other devices because under
deployed as stars with the AP acting as IoT gateway. As wireless communications it is not possible to simultaneously
opposed to conventional IEEE 802.11 standards, however, transmit and receive frames. This results in a scenario where
IEEE 802.11ah operates on the ISM 915/868 MHz band collisions can only be avoided. Because avoiding collisions
with 1, 2, 4, 8, and 16 MHz channels. As IEEE 802.11af, takes longer than detecting them, latency is inherently higher
IEEE 802.11ah reuses the MIMO OFDM modulation scheme in wireless systems than in wireline ones.
introduced by IEEE 802.11ac by changing symbol interspace
and length to accomplish a wide range of transmission rates Example 3.4 Consider a sensor that transmits 200-
depending on power consumption. Also, as opposed to con- byte packets every 20 ms. What is the communication
ventional IEEE 802.11 standards, IEEE 802.11ah supports system efficiency for both non-IoT IEEE 802.11ax
a comparatively large number of devices in a single BSS in and IoT IEEE 802.11ah scenarios? Assume the lowest
order to enable LPWAN support. IEEE 802.11ah provides a possible transmission rates for both technologies.
typical range of 100 m–1 km for direct connectivity that is
supported by means of very low energy consumption that
relies on power saving strategies. (continued)
3.3 Wireless 57

Table 3.9 IEEE 802.11ah

Modulation Code bits/subchannel Code bits/symbol Code rate Data bits/symbol Data rate (Mbps)
BPSK 1 24 1/2 12 0.3
QPSK 2 48 1/2 24 0.6
QPSK 2 48 3/4 36 0.9
16-QAM 4 96 1/2 48 1.2
16-QAM 4 96 3/4 72 1.8
64-QAM 6 144 2/3 96 2.4
64-QAM 6 144 3/4 108 2.7
64-QAM 6 144 5/6 120 3.0
256-QAM 8 192 3/4 144 3.6
256-QAM 8 192 5/6 1608 4

Fig. 3.38 IEEE 802.11

device A data packet time
contention

device B busy DIFS backoff data packet time

device C busy DIFS backoff busy time

Figure 3.38 shows the time diagram of DCF mode where

(continued) two devices, B and C, are trying to transmit data when a third
Solution The transmission rate R is given by R = device A is transmitting. First, both B and C wait for A to
L
T
= 80,000 bps where L = 8 × 200 bits and stop transmitting, and then, once the channel is free, they
T = 20 ms. The efficiency under IEEE 802.11ax is wait for a fixed amount of time known as distributed inter-
given by ηIEEE 802.11ax = 576,000,000
R
bps
= 0.000138 frame spacing (DIFS). If at this point the channel is free,
while efficiency under IEEE 802.11ah is given by each device calculates a backoff time and starts transmitting
ηIEEE 802.11ah = 300,000
R
bps
= 0.2667. By virtue of being if the channel is still free after this interval has elapsed.
considerable slower, IoT technologies tend to occupy The backoff time Cw is randomly selected in the interval
a comparative larger section of the available channel (Cw min , Cw max ) in order to minimize the chances of repeated
network bandwidth. collision when devices are allowed to retransmit. Note that
the Cw is computed as a multiple of the standard IEEE 802.11
When many devices compete to simultaneously access slot time.
a channel, MAC is by means of a contention-based mech- Besides DIFS, some devices access the channel by means
anism known as distributed coordination function (DCF). of a shorter interframe spacing time known as short inter-
DCF relies on the same CSMA/CA algorithm, described in frame spacing (SIFS). SIFS is typically used for immediate
Sect. 3.2.2, that 3G-PLC supports. transmission of certain control frames and frame fragments.
On the other hand, when the AP allocates specific times- Figure 3.39 illustrates the time diagram when device A sends
lots for devices to individually access the channel, MAC is a frame to device B, while device C is also attempting to
by means of a contention-free mechanism known as point transmit a frame. Due to the shorter backoff time, device
coordination function (PCF). In the context of IoT where A transmits the frame first. This frame is marked to be
communications are M2P and traffic typically flows from acknowledged by the destination, so device B sends a spe-
devices to the AP but not between devices, PCF provides the cial control frame that serves as acknowledgment. Because
most efficient mechanism for sensor and actuator data trans- of the importance of this frame, the SIFS guarantees that
mission. PCF is a master-slave architecture usually found in the acknowledgment frame is transmitted right away, thus
many WPAN solutions; however, its support is not mandatory preventing other devices, including C, from sending any
under IEEE 802.11 so many implementations only rely on frames. Note that both SIFS and DIFS respectively provide
DCF for media access. high and low priorities for devices to access the channel. By
58 3 Physical and Link Layers

Fig. 3.39 SIFS time

device A busy DIFS backoff data

device B SIFS ACK time

device C busy DIFS backoff busy DIFS backoff data time

SIFS
mapped to three access priorities: high that supports a spacing
device A busy time
like that of DIFS, medium, and low. Figure 3.40 shows the
different AIFSs as well as SIFS and DIFS spacings.
Figure 3.41 shows a regular IEEE 802.11 frame that
device B busy PIFS time encapsulates a network layer datagram. Each frame consists
of a MAC header, payload data, and a frame checksum. The
backoff frame control is a 2-byte field that indicates whether it is a
DIFS
control, a data, or a management frame. Control frames, like
device C busy time
the CTS and RTS frames, are used to facilitate the exchange
high priority access of data frames between devices. Management frames are
backoff used for maintenance of the communication between devices
device D busy AIFS[2] time and APs. Data frames are used to carry real application and
medium priority access session traffic. The frame control field also indicates the
backoff encryption mechanism; Wired Equivalent Privacy (WEP),
busy AIFS[3] Wi-Fi Protected Access (WPA), or Wi-Fi Protected Access
device E time
II (WPA2). This field, in addition, provides fragmentation
high priority access as well as retransmission information. The duration id field
Fig. 3.40 SIFS
has multiple uses; when included in data frames, it indicates
the amount of air time the sending radio is reserving for
the pending acknowledgment frame, while when included in
default, there are no other MAC priorities and no way to management frames, it is used to indicate the AP association
guarantee a specific QoS level. In general, given the nominal id. The addresses 1 and 2 are the receiver and sender MAC
transmission rate of each of the standards that fall under addresses, respectively. The addresses 3 and 4 are used for
the IEEE 802.11 umbrella, the actual transmission rates are mesh routing and to provide connectivity between APs in an
much lower due to the latency introduced by CSMA/CA ESS. The sequence control field identifies the frame where
contention. The less severe the contention is, the closer to the first 4 bits specify the fragmentation number, while the
the nominal transmission rate the actual transmission rate last 12 bits indicate the sequence number itself. Data frames
becomes. are typically encapsulated following the IEEE 802.2 standard
Devices that need predictability and guaranteed QoS can described in Sect. 3.2.1.
rely on PCF. The device that serves as point coordinator Once a device activates its IEEE 802.11 interface, it scans
accesses the medium through an interframe spacing known for other devices that are within range and ready for associ-
as PCF IFS (PIFS) that lies somewhere in between the SIFS ation. Scanning can be either passive or active. Under pas-
and DIFS spacings. Once the coordinator has control, it tells sive scanning, devices sequentially listen for beacon frames
all other devices the duration of the contention free period. transmitted by other devices over IEEE 802.11 channels.
This enables these devices to access the medium, avoiding These beacon frames provide relevant information related
collisions, in a controlled fashion. Specifically, the point to synchronization and modulation as well as other physical
coordinator sequentially polls stations to check and verify layer parameters. Under active scanning, a device can send
whether they have frames to transmit. The PCF functionality, a probe frame indicating the SSID of the BSS it wants to be
although part of the original IEEE 802.11 specifications, is associated with. When the AP receives the probe, it replies
typically implemented as part of enhancements introduced with a probe response. Alternatively, active scanning can also
by IEEE 802.11e. IEEE 802.11e provides an extension to the involve a device sending a broadcast probe to all available
basic DCF called Enhanced DCF (EDCF) that relies on an devices. APs reply with response probes that are used by the
Arbitrary Interframe Spacing (AIFS). Essentially, AIFSs are devices to construct lists.
3.3 Wireless 59

Fig. 3.41 IEEE 802.11 frame 2 1 6 6 6 1 6 variable 4

FC DID ADDRESS 1 ADDRESS 2 ADDRESS 3 SC ADDRESS 4 DATA FCS

MAC header
FC frame control field
DID duraon id
SC sequence control field
FCS frame checksum

Devices that implement the IEEE 802.11 standard support

two types of services: station services and distribution ser- 2
vices. Station services deal with authentication and privacy 1 DEV
between devices. Authentication is performed by devices DEV
before association. APs can be configured with open or pre-
shared key authentication. Under open authentication, all 3
devices are successfully authenticated providing very little DEV
security and validation. Shared key authentication relies on 7
devices sharing a password that is pre-configured by means PNC
of an alternative channel like user configuration. Similarly,
6
to authentication that occurs before association, deauthen- 4
tication occurs before a device disassociates from a given DEV
DEV
device. Authentication and deauthentication are carried out
through special management frames. Privacy between de- 5
vices results from data frame encryption based on WEP,
DEV
WPA, and WPA2. Distribution services deal with station
services that span beyond communication between devices in DEV device
each BSS. Association enables devices to logically connect PNC piconet coordinator
with APs. APs cannot deliver any traffic from a device until
it is associated. Disassociation is performed when a device Fig. 3.42 IEEE 802.15.3 piconet
leaves a network if, for example, it disables its IEEE 802.11
network interface. Reassociation allows a device to dissociate
members for basic timing and synchronization. Moreover,
from an AP and associate to another one due to a stronger
the PNC also manages, among other things, power cycles,
beacon being detected. In general, the distribution service
access control, and QoS requirements. In general, all traffic
provides the mechanisms for devices to send frames within
in the piconet is P2P single hop with the PNC always being
BSSs and ESSs. Part of distribution services is integration
the source or destination of frames.
that gives APs the capability to interface with networks that
Figure 3.43 shows the superframe structure IEEE 802.15.3
are not IEEE 802.11 based.
relies upon to provide timing. A superframe starts with
a beacon; it continues with an optional contention access
3.3.2 IEEE 802.15.3 period (CAP) and ends with a channel time allocation period
(CTAP). Management information as well as timing alloca-
IEEE 802.15.3 provides a physical and link layer specifica- tions are transmitted by the beacon. The CAP is provided by
tion for high-rate WPANs [15]. These WPANs are deployed means of traditional CSMA/CA that supports the transmis-
as piconets with each piconet managed by a Piconet Coordi- sion of commands and asynchronous data between devices
nator (PNC) that supports a network of devices (DEVs) syn- and the PNC. On the other hand, the CTAP is based on
chronized by means of beacons as illustrated in Fig. 3.42. The time-division multiple access (TDMA) that provides regular
IEEE 802.15.3 nominal transmission rate is up to 55 Mbps Channel Time Allocations (CTAs) and Management Channel
with signals that are modulated as 64-QAM over the 2.4 GHz Time Allocations (MCTAs). CTAs enable devices, including
ISM band. the PNC, to transmit commands and periodic data at fixed
The isotropic coverage of a piconet is 10 m around the rates. This is useful in RTC scenarios where a device requests
PNC that, in turn, can be fixed or mobile. In total, up to 245 from the PNC a timeslot for transmission of real-time traffic.
devices can be part of a single piconet, with only one of them Transmission of asynchronous data is supported by means of
assuming the role of PNC. As mentioned above, the PNC the CAP, where devices attempt to transmit small chunks of
periodically transmits beacon frames that are used by device data after requesting channel time for the total amount of time
needed to transmit frames.
60 3 Physical and Link Layers

Fig. 3.43 IEEE 802.15.3

superframe n - 1 superframe n superframe n + 1
superframe

MCTA MCTA CTA CTA CTA CTA

beacon CAP
1 2 1 2 n-1 n

CTAP

CAP contention access period

CTA channel time allocation
CTAP CTA period
MCTA management CTA

Devices join an IEEE 802.15.3 piconet by sending an

association request to the PNC. The PNC processes the 10
2
request and transmits an association response that assigns DEV
1 DEV
the device a unique 8-bit Device Identifier (DEVID) that
DEV
identifies the device in the piconet. The device then sends
a new association request now using the newly assigned 3

DEVID. This handshake is used by the PNC to make sure child

7 PNC
that the device sends frames fast enough. In order to do 11
PNC
so, the PNC creates a timer that expires after Association DEV
6
Timeout Period (ATP) seconds triggering the disassociation 4
DEV
of the device. The device identifier plays the role of a short DEV
address by saving frame space when compared to the use
of 64-bit MAC source and destination addresses. The PNC 5
periodically checks for devices with expired ATPs to send a child
PNC
disassociation request to the devices. Similarly, if a device
wants to leave the network, it can transmit a disassociation
8 9
request to the PNC.
DEV DEV
Acknowledgments are requested upon transmission of
frames and four possible types may be requested: (1) no ac-
knowledgment, (2) immediate acknowledgment that is trans-
mitted upon the reception of a single frame, (3) delayed
Fig. 3.44 Child piconets
acknowledgment that is transmitted upon the reception of
multiple frames, and (4) implied acknowledgment that is
implied when the receiver transmits a frame back to the initiated when the device looks for beacon frames to identify
originator. This latter option was introduced in the IEEE clear channels. If a clear channel is found, after waiting for a
802.15.3b amendment of the original standard. specified time period, the device becomes a PNC and starts
IEEE 802.15.3 also introduces resource sharing by provid- sending beacons with specific PNID and BSID parameters.
ing mechanisms that enable devices to know what services Potentially, if no free channels are found and a piconet is
are available in the piconet. Moreover, devices can also already present, the device can associate with it in order to
advertise their own services. Service information is carried interact with other devices. Otherwise the device can start a
by means of Information Elements (IEs) that are optionally dependent piconet.
exchanged during the piconet association process. Several A piconet can be fully independent and have no child
commands provide the discovery of services by devices and piconets, or it can be dependent and be a child or a neighbor
the PNC including information request, probe request, and of a parent piconet. A parent piconet allocates private CTAs
announce commands. for its child piconets to create their own networks. The child
Piconets are identified through two parameters: the Pi- PNC coordinates its own devices while being a device of
conet Identifier (PNID) and the Beacon Source Identifier the parent piconet. Comparatively, a neighbor piconet is an
(BSID). In order to start a new piconet, a device can act autonomous network that is not a member of the parent pi-
as a PNC that scans for the available channels in order to conet but that it relies instead on CTAs assigned by the parent
find one that is not being used. An open scan is typically PNC.
3.3 Wireless 61

Figure 3.44 shows an IEEE 802.15.3 topology with a

parent PNC and two child PNCs. The idea behind the child pi- application layer
conet support is double: (1) to extend the coverage area of the transport layer
piconet and to (2) distribute computational and memory re-
sources from the parent PNC to child PNCs. A parent piconet network layer
can have multiple child and neighbor piconets. Dependent
IEEE 802.15.4 link layer
piconets share the frequency channels of different piconets
when no spectrum is available. The trade-off of physically IEEE 802.15.4 physical layer
extending a piconet is additional latency. Dependent piconets
are functionally autonomous from their parent piconet and Fig. 3.45 IEEE 802.15.4 and IETF protocols
have different PNIDs, but they rely on CTAs in the parent
superframe for transmission. A child PNC is a member of
the parent piconet, and it can interact with any device in the In all cases ultra low power consumption results from lim-
parent piconet. Moreover, a child PNC is also a member of the iting both signal coverage and the amount of data being
child piconet and can exchange frames with any device in the transmitted, thus decreasing transmission rates. This is ad-
child network. A neighboring PNC, however, is not a member ditionally improved by managing duty cycles where power
of the parent piconet, and therefore it cannot exchange frames down and sleep modes are controlled.
with devices in the parent piconet. The original IEEE 802.15.4 standard was released in
One issue with the IEEE 802.15.3 topology is that it does 2003 and amended in 2006 to increase transmission rates by
not allow, like many other WPAN technologies, support of incorporating additional modulation schemes. This release
a full mesh where network devices are directly connected led to IEEE 802.15.4a in 2007 that was consolidated as IEEE
to each other. Specifically, a child PNC can not only com- 802.15.4 in 2011 by further improving the offer of frequency
municate with the devices in its child piconet, but it can bands and modulation schemes. In 2012 IEEE 802.15.4e in-
also interact with its parent PNC and all devices in the troduced a channel hopping mechanism to improve resilience
parent piconet. Unfortunately, and regardless of the physical against channel interference by means of time synchronized
coverage, devices in the child piconet cannot communicate multi-hop communications. IEEE 802.15.4e is specially de-
with the parent PNC or the devices in the parent piconet. This signed to support industrial applications that are standardized
model of operation also introduces dependencies and single in the context of IIoT. Note that IEEE 802.15.4e has been
points of failure where if the parent PNC crashes all child adopted as a link layer mechanism for both WirelessHART
piconets also stop working until the ATP expires. Similarly, and ISA 100.11a. Other amendments to IEEE 802.15.4 in-
if a parent PNC shuts down, it must select one and only one clude IEEE 802.15.4c and IEEE 802.15.4d that add support
child PNC to take over the channel. for specific frequency bands in China and Japan, respectively.

3.3.3.1 Physical Layer

3.3.3 IEEE 802.15.4 The original IEEE 802.15.4 standard relies on DSSS modu-
lated by means of OQPSK with 16 non-overlapping channels
The IEEE 802.15.4 specification introduces a set of physical operating in the ISM 2.4 GHz band. The chip rate is 2 × 106
and link layer technologies intended for use in WPANs [11]. chips per second, and since each symbol is 32-chip long,
t
As such it is one of the preferred mechanisms to support it leads to a symbol rate of 2×10
32
= 62,500 symbols per
ultra low power consumption, and therefore long battery second. Because OQPSK implies 4-bit symbols, the overall
life, in the context of LLNs. IEEE 802.15.4 also serves as transmission rate is 62,500 × 4 = 250 Kbps. The legacy
physical and link layer mechanisms for stand-alone standards IEEE 802.15.4 standard, also relying on DSSS but by means
like ZigBee [6], ISA 100.11a [3], and WirelessHART [7]. of BPSK, supports in the United States a transmission rate
These technologies are well-known protocol stacks that are of 40 Kbps over ten ISM 915 MHz channels and in Europe a
an integral part of many M2M and CPS solutions. While rate of 20 Kbps over a single ISM 868 MHz channel. In the
ZigBee relies on profiles that target home automation and current IEEE 802.15.4 standard, this support is extended to
smart energy scenarios, WirelessHART and ISA 100.11a 100 and 250 Kbps in the ISM 868 MHz and 915 MHz bands,
target industrial automation and control. These standards use respectively.
IEEE 802.15.4 in combination with upper proprietary layers IEEE 802.15.4a introduced two additional modulation
that do not usually enable native IP connectivity. schemes later integrated into IEEE 802.15.4: (1) one based on
In most modern IoT scenarios however, as shown in direct-sequence ultra wideband (DS-UWB) and (2) another
Fig. 3.45, IEEE 802.15.4 is used in combination with IETF based on chirp spread spectrum (CSS). DS-UWB supports
protocols to provide efficient end-to-end IPv6 connectivity. precision ranging, and it is both efficient and robust for
62 3 Physical and Link Layers

Fig. 3.46 RFD topologies

2 3
1 2

4 5
3 4

P2P star
Fig. 3.47 Cluster networks CLUSTER 2

CLUSTER HEAD

CLUSTER 1
DEVICE

CLUSTER 3

low transmission power. CSS is a particular type of spread extended into a mesh topology that supports up to 64,000
spectrum that does not rely, as opposed to traditional DSSS devices. In this situation efficient routing is many times
and FHSS, on a pseudo-random sequence derived from a accomplished by means of reactive mechanisms that, relying
code to spread the spectrum. It spreads the spectrum, instead, on requests and responses, outperform proactive table-driven
by linearly varying the frequency of the sinusoidal carrier routing.
based on a spreading factor that results from the transmission
of chirps. In either case, these changes in modulation attempt Example 3.5 Consider a sensor that transmits 5-byte
to improve the trade-off between power density and signal readouts every 20 ms and assume that the overhead
bandwidth in order to improve the SNR at the receiver. due to network, transport, and session layer headers
Like the link layer of other technologies, the one of IEEE is 32 bytes. What is the efficiency of the communi-
802.15.4 provides many functions including the transmis- cation system if the physical and link layers are IEEE
sion of beacon frames, frame validation, node association, 802.15.4? Assume that the IEEE 802.15.4 header size
and security. IEEE 802.15.4 defines two device classes: (1) is minimum.
Full Function Devices (FFD) that can serve both as PAN
coordinators and as regular devices in any topology and (2) Solution The transmission rate R is given by R = TL =
Reduced Function Devices (RFD) that only provide node 18,800 bps where L = 8 × (5 + 32 + H ), T = 20 ms
functionality in simple topologies like star and P2P. Fig- and H = 10 is the minimum IEEE 802.15.4 header
ure 3.46 illustrates these two topologies supported by RFDs size as per information shown in Fig. 3.50. Note that the
communicating with one or more FFDs. Summarizing, an IEEE 802.15.4 header size in this case is 10 bytes long
FFD can coordinate a network of devices, while an RFD is because it includes a minimum size 4-byte address field
only able to communicate with other devices. FFDs, besides with no security. The efficiency is given by η = CR =
supporting all topologies associated with RFDs, also support 0.0752 where C = 250,000 bps, and it is therefore
the cluster network topology shown in Fig. 3.47. around 7.52%.
Figure 3.48 shows a scenario where multiple FFD and
RFD topologies are combined. In fact, basic P2P can be
3.3 Wireless 63

IEEE 802.15.4 END DEVICES

IEEE 802.15.4 END DEVICES

STAR LINKS
STAR LINKS
PAN COORDINATOR

MESH LINKS

MESH LINKS

ROUTER

Fig. 3.48 FFD and RFD topologies

3.3.3.2 Link Layer free timeslots provide devices with a way to predict
Under IEEE 802.15.4 media access is carried out by a com- channel access and estimate duty cycles that are essential
bination of contention and contention free periods accessible to minimize power consumption. During contention-based
via timeslots supported by both CSMA/CA and TDMA. access, the CSMS/CA mechanism is like that of IEEE 802.11
Figure 3.49 shows the structure of an IEEE 802.15.4 described in Sect. 3.3.1.1. Devices sense the channel before
superframe that consists of a beacon transmission followed transmission and backoff for a random time period before
by 16 timeslots. The PAN coordinator transmits beacons that transmitting. Backoff is exponential as it doubles whenever a
are used for device synchronization, to transmit configuration collision is detected. IEEE 802.15.4 supports basic reliability
information and for identification. Beacons are sent at a fixed allowing devices to request acknowledgments of transmitted
predefined interval between 15 ms and 252 s. Because beacon frames. If the far end device fails to send the acknowledgment
transmissions are quite infrequent and are not likely to suffer due to network loss, the transmitter resends the frame. Only
from collisions, they do not rely on CSMA/CA for media a fixed number of retransmissions are allowed before the
access. Contention-based access, that occurs right after bea- frame is declared lost. An IEEE 802.15.4 network can also be
con transmission, takes a section of the available 16 timeslots configured in non-beacon mode when device transmissions
for devices to transmit relying on CSMA/CA. The remaining are infrequent enough that contention-based access results
section of timeslots provides contention-free access where in a lack of collisions. This scenario comparatively lowers
the PAN coordinator assigns, by means of TDMA, guar- topology and device complexity requirements.
anteed access timeslots to certain devices. This is typically Support of single channel communication, as enabled by
associated with scenarios where the application has prede- the original IEEE 802.15.4 specification, results in unpre-
fined bandwidth requirements that require them to reserve dictable reliability especially in the context of multi-hop
exclusive timeslots for transmissions. The beacon carries a deployments where applications are time restricted. This is
permit joining flag that is used to indicate devices that they particularly true for certain IIoT applications that rely on
can join the network. Under standard IEEE 802.15.4, network media transmission. IEEE 802.15.4e addresses this prob-
joining is initiated at the device, for example, by pushing a lem by introducing the Time Synchronized Mesh Protocol
physical button. This contrasts with the Thread architecture (TMSP). TMSP provides a Time Slotted Channel Hopping
presented in Chap. 9 that also relies on IEEE 802.15.4 but (TSCH) MAC layer that relies on time synchronized channel
uses a different mechanism for devices to join a network. hopping in order to overcome multipath fading and inter-
The use of predefined intervals for the transmission ference. Essentially, devices link themselves to groups of
of beacons combined with the presence of contention- slots repeating over time where each slot is associated with
64 3 Physical and Link Layers

Fig. 3.49 IEEE 802.15.4

superframe SUPER FRAME n - 1 SUPER FRAME n SUPER FRAME n + 1

contention based contention free

B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 inactive B

beacon beacon

FCF Table 3.10 Frame type encoding

0 8 18 24 Frame type value Meaning
LENGTH R FT S P A C R N I DAM FV SAM SEQUENCE 000 Beacon
ADDRESSES … 001 Data
010 Acknowledgment
SECURITY …
011 MAC command
PAYLOAD … 100 Reserved
FCS 101 Multipurpose
110 Fragment
FCF frame control field
C PAN ID compression 111 Extended
N sequence number suppression
I informaon element present Table 3.11 SAM and DAM encoding
A ACK request
P frame pending SAM/DAM Meaning
S security enabled 00 Neither PAN ID nor the address field is given
FT frame type 01 Reserved
SAM source address mode
FV frame version 10 Address field contains a 16-bit short address
DAM destination address mode 11 Address field contains a 64-bit extended address
FCS frame checksum
R reserved
for future extensions that are followed by a 16-bit Frame
Fig. 3.50 IEEE 802.15.4 data packet
Control Field (FSF). The length value accounts for the entire
frame size including training checksum bytes. It thus limits
a schedule that specifies what devices communicate with the maximum frame size to 127 bytes. The FSF includes
each other. In this context, synchronization of devices is key, several fields (1) PAN ID compression that is used to indicate
two mechanisms exist: (1) acknowledgment based where the whether the 16-bit PAN Identifier (PAN ID) is included as
receiver computes the difference between the expected and part of the MAC addresses, (2) ACK request to ask for the
actual arrival times of a frame and provides this information transmission of an acknowledgment frame when this frame
as feedback to the sender so it can synchronize itself against is received, (3) frame pending that enables a sender to tell the
the receiver and (2) frame based where the receiver also receiver that it has more frames to send in order to maximize
computes the difference between the expected and actual channel utilization, (4) security enabled that indicates that
arrival times of a frame but instead it adjusts its own clock the frame includes security parameters, (5) frame type field
to be synchronized with the sender. to signal the nature of the frame as encoded in Table 3.10, (6)
IEEE 802.15.4 defines four frame types: (1) data frames frame version that specifies the IEEE 802.15.4 revision that
that are used for transmission of regular frames; (2) ac- applies to this particular frame, and (7) Source Address Mode
knowledgment frames that are transmitted by the receiver (SAM) and Destination Address Mode (DAM) fields that
to confirm reception whenever requested by the sender; (3) indicate how source and destination MAC addresses are en-
MAC command frames that are typically used in beacon coded. SAM and DAM encoding is shown in Table 3.11, (8)
mode to enable MAC services like network association, dis- sequence number suppression and (9) IE present bits. IEEE
association, and management of synchronized transmission 802.15.4 enables the use of the FSF to indicate additional
by the PAN coordinator; and (4) beacon frames that are used members that are used to send information between devices.
by the PAN coordinator to signal physical layer parameters Specifically, information between neighbors is carried by
and trigger communication with associated devices. means of IEs that are included in the frame when the IE
Figure 3.50 shows an IEEE 802.15.4 frame. The frame present bit in the FSF is set. IEs are not encrypted but they
starts with a 7-bit frame length field and a reserved bit used are authenticated.
3.3 Wireless 65

0 3 5 8 31 Table 3.12 IEEE 802.15.4 security modes

SL KIM R FC Security mode Security provided
No security Data is not encrypted
FC KS
Data authenticity is not validated
KS AES-CBC-MAC-32 Data is not encrypted
KS KI Data authenticity is 32-bit MIC
SL security level AES-CBC-MAC-64 Data is not encrypted
KIM key identifier mode Data authenticity is 64-bit MIC
R reserved AES-CBC-MAC-128 Data is not encrypted
FC frame counter (continuation) Data authenticity is 128-bit MIC
KS key source
AES-CTR Data is encrypted
KI key index
Data authenticity is not validated
Fig. 3.51 Security header AES-CCM-32 Data is encrypted
Data authenticity is 32-bit MIC
AES-CCM-64 Data is encrypted
Following the control field, the frame includes an 8-bit Data authenticity is 64-bit MIC
sequence number used for tracking of fragments and ac- AES-CCM-128 Data is encrypted
knowledgments. The variable length source and destination Data authenticity is 128-bit MIC
addresses, as encoded by the SAM and DAM fields, follow.
IEEE 802.15.4 relies on unique 64-bit long addresses that Table 3.13 KIM encoding
are hardcoded in all radio chips and 16-bit short addresses KIM Meaning
configured by the PAN coordinator. The 64-bit addresses are 00 Key identified by source and destination address
formed based on an IEEE 64-bit Extended Unique Identifier 01 Key identified by macDefaultKeySource + 1-byte key index
(EUI-64). Short addresses simplify addressing in restricted 10 Key identified by 4-byte key source + 1-byte key index
environments, while long addresses provide global reachabil- 11 Key identified by 8-byte key source + 1-byte key index
ity. If either 16-bit or 64-bit MAC addresses are transmitted,
then 16-bit PAN ID values must also be included unless the
PAN ID compression field is set. When set, this means that protected by encryption and/or message authentication. The
the PAN ID for both addresses is the same, and therefore it 32-bit frame counter is used to provide replay protection and
can be removed from the source address. This leads to an to keep track of the sequence of frames in order to apply chain
address field that can be anywhere between 4 and 20 bytes encryption mechanisms. Additionally, the security control
long. field also includes a Key Identifier Mode (KIM) shown in
Although IEEE 802.15.4 security, when enabled, is Table 3.13 that indicates how the keys required to process
present at the link layer, it also protects the upper layers. security are to be determined by the devices. IEEE 802.15.4
In fact, IEEE 802.15.4 security is typically provided through relies on 128-bit keys that may be implicitly known by trans-
hardware and firmware implementations that are highly mitter and receiver, or they may be derived from information
efficient. This contrasts with the security provided by upper transported in the 64-bit Key Source (KS) and 8-bit Key Index
layer protocols that is implemented as user space software (KI) fields. In general, the KS field indicates the group key
libraries. Of course, security services are terminated and originator, while the KI field is used to identify a key from
reestablished between devices and entities at the end of a specific source. KS and KI together form the Key Control
the link. This can be considered a violation of the well- (KC) field.
known end-to-end principle of network topologies. This The security modes shown in Table 3.12 carry information
principle states that, whenever possible, certain functions like related to security in the different configurations shown in
security must be deployed on an end-to-end basis typically Fig. 3.52. For scenarios where only confidentiality is needed,
at the application layer. This principle, when carried out, the payload is encrypted by means of AES-CTR that relies on
guarantees maximum efficiency improving overall latency, Advanced Encryption Standard (AES) encryption in counter
throughput, and security. (CTR) mode. For scenarios where message authentication
If security is enabled in the IEEE 802.15.4 FSF, the is needed, a Message Integrity Code (MIC) also known as
auxiliary security header, shown in Fig. 3.51, follows the Message Authentication Code are calculated over the IEEE
address field. The frame ends with a 16-bit CRC block code 802.15.4 header and payload by means of AES-CBC that
that is used as FCS. This header includes an 8-bit security relies on AES encryption in Cipher Block Chaining (CBC)
control field that specifies the 3-bit security level described mode. This leads to AES-CBC-MAC-32, AES-CBC-MAC-
in Table 3.12. This level indicates whether the payload is 64, and AES-CBC-MAC-128 based on whether the MIC is,
66 3 Physical and Link Layers

respectively, 32, 64, or 128 bits long. The MIC is then ap- of a frame to look for the security parameters needed to
pended to the unencrypted payload. For scenarios where both process encryption and message authentication. This infor-
confidentiality and message authentication are needed, CTR mation is stored as entries in an access control list (ACL). Up
and CBC modes are combined into a counter combined mode to 255 entries can be stored with a default entry that specifies
that leads to security modes AES-CCM-32, AES-CCM-64, security for those frames that are not associated with any
and AES-CCM-128 for MIC sizes of 32, 64, and 128 bits, entry. Figure 3.54 shows the format of a single ACL entry.
respectively. In this case, encryption is applied after message Each entry includes the addresses, a security suite identifier,
authentication is performed. Note that the frame counter and the cryptographic key, and, for scenarios with encryption, the
the KC fields are set by the sender whenever encryption is in last available IV. If replay protection is in place, then the
place. The frame counter is typically incremented each time latest frame counter is stored too.
a frame is hardware encrypted, while the KC is set by the
application and contains the KI that identifies the key in use. 3.3.3.3 TSCH
The original datagram is chunked into several 16-byte TSCH, introduced in IEEE 802.15.4e, is the MAC layer of the
blocks that are identified through a block counter. Each block TMSP. It provides a way to map timeslots to user channels
is encrypted using a different initialization vector (IV) that is based on a preassigned hopping sequence. The main goal
computed on-the-fly for each frame as illustrated in Fig. 3.53. is to make sure that no frames collide on the network and,
Essentially the IV consists of a 1-byte flag, the 64-bit long therefore, frames are scheduled and synchronized for energy
source address, the 32-bit frame counter, the 8-bit frame efficiency with no need for an extra preamble or guardbands.
control, and the 16-bit block counter. Note that the block Collision-free communication is accomplished by means of
counter is not sent so the receiver typically estimates its value the aforementioned schedule that allows multiple devices to
based on the order of block within the frame. communicate at the same time over different frequencies. As
IEEE 802.15.4 introduces support of access control by a collision-free mechanism, synchronization is critical under
allowing devices to use the source and destination addresses TSCH. Specifically, synchronization is carried out by means
of frames exchanged between neighbors. If devices do not
receive any traffic for a predefined time period, they can
AES-CTR FC KC ENCRYPTED PAYLOAD transmit dummy frames to trigger synchronization.
Under TSCH all devices are fully synchronized with
timeslots that are long enough to fit a full size frame and its
acknowledgment. Timeslot durations of 10 ms are typical,
AES-CBC-MAC-X PAYLOAD MIC
providing enough time for transmission, propagation, and
processing delays. Timeslots are grouped into slotframes that
are periodically transmitted. Depending on the application,
AES-CCM-X FC KC ENCRYPTED PAYLOAD EMIC a single slotframe can hold anywhere between tens and
thousands of timeslots. Shorter slotframes are associated
with higher transmission rates but also higher energy
FC frame counter consumption. TSCH allows a single schedule to rely on
KC key control
MIC message integrity code
multiple simultaneous slotframes. At some point in time, a
EMIC encrypted message integrity code device can perform two simultaneous tasks on two different
slotframes like receiving frames from device 2 in slotframe 1
Fig. 3.52 Payload data formats with IEEE 802.15.4 security and transmitting frames to device 3 in slotframe 2. Two rules
specify how devices behave in a multi-slotframe scenario: (1)
1 8 4 1 2
transmissions have higher priority than receptions, and (2)
FLAGS SOURCE ADDRESS FRAME COUNTER KC BC
lower slotframes have higher priority than higher slotframes.
The TSCH schedule specifies what a given device does
KC key control
BC block counter in a timeslot. Specifically, it indicates the channel offset
associated with hopping and the address of the neighbor
Fig. 3.53 Format of the IV with which to communicate. Possible actions in the schedule
include receiving or transmitting data as well as sleeping. For
ADDRESSES SECURITY SUITE KEY LIV RC each transmitting timeslot, the device checks whether there
are pending frames in the outgoing queue for the destination.
LIV last IV
RC replay counter If there are no frames, the device keeps its radio turned off in
order to save energy; otherwise it transmits the pending frame
Fig. 3.54 IEEE 802.15.4 ACL entry requesting an acknowledgment whenever needed. Similarly,
3.3 Wireless 67

for each receiving timeslot, the device listens for incoming of the frame counter field and to (2) indicate whether the
frames; if no frames are received for a certain amount time, frame counter field is 32 or 40 bits long. When ASN-based
the device shuts off its radio; otherwise if it receives a frame, encryption is in use, the 40-bit frame counter is followed by
the device can send an acknowledgment if needed. the key control field as indicated by Fig. 3.52.
The combination of the timeslot and channel is called a
cell. A cell represents an atomic unit of scheduling. A single 3.3.3.4 Limitations
device can communicate with another one through one or IEEE 802.15.4 exhibits some limitations that affect its reli-
more cells. If multiple cells carry traffic between two devices, ability in the context of LLNs. Specifically, one of the most
then the scheme is called a bundle. The larger the bundle important limitations affecting not only IEEE 802.15.4 but
is, the higher the transmission rate from one device to the also many other IoT technologies is due to the interference
other. TSCH also provides a mechanism that enables multiple associated with other transmissions over the ISM bands. This
devices to simultaneously transmit over the same cell. In this is particularly critical when considering the overcrowded
case of shared cells, contention is prevented by means of a 2.4 GHz band used by different versions of IEEE 802.11 and
backoff algorithm. BLE as well as other devices ranging from remote control
Each cell is determined by both parameters: the channel toys to cordless phones. Additionally, radio propagation is
offset and the timeslot offset that indicate the spectral and mainly by the way of scattering over surfaces and diffraction
temporal position of the cell. TSCH introduces a global over and around them in a situation typical of a multipath
timeslot counter called Absolute Slot Number (ASN) that environment. Essentially, in this scenario, multipath fading
specifies the number of timeslots that have been scheduled results from signals taking different paths and arriving at the
since the start of the network. In general, ASN = k × S + t receiver with different phases. If all signals interact positively
where k and S are the slotframe cycle and size, respectively, (i.e. they have same phase), then there is constructive interfer-
and t is the timeslot offset. The ASN value is broadcasted ence or upfading, while if, on the other hand, signals interact
throughout the network for devices to synchronize when they negatively (i.e. they have opposite phase), then there is de-
join the network. The ASN is 40 bits long in order to support structive interference or simply fading. As opposed to IEEE
hundreds of years without overflowing. 802.15.4 that is greatly affected by fading, IEEE 802.15.4e
Although the channel offset is constant for any given attempts to address some of these problems through TMSP.
transmission from one device to another, this does not mean IEEE 802.15.4 also limits the communication range.
the transmission frequency is constant. In fact, channel hop- Specifically, the coverage is around 200 m in outdoor
ping is supported by a transmission frequency calculated environments. Longer coverage is possible; however, it
as frequency = F ((ASN + c) mod N) where c is the requires the use of multi-hop transmissions in the context
channel offset, N is the maximum number of frequencies, of mesh forwarding. Devices that provide message relaying
and F (. . .) is a mapping to one of the possible N frequencies. introduce three problems: (1) additional deployment costs,
Because ASN is an incrementing counter, for any fixed cell, (2) increased latency, and (3) reduction of communication
the transmission frequency changes in each slotframe. This reliability. This latter point is associated with the fact that
enables channel hopping even when keeping the schedule multi-hop communication relies on systems that are “in
simple by relying on fixed cells associated with fixed channel series” and as such they have multiple points of failure when
and timeslot offset. Channel hopping is essential in order to compared to one-hop communication schemes. One way
prevent multipath fading and interference as these impair- to improve reliability is by increasing transmission power;
ments are frequency dependent. however, the nature of IoT solutions typically prevents this.
The TSCH network schedule is linked to the application
needs; a sparse schedule implies a solution where devices
consume very little energy, but throughput is very low too, 3.3.4 Bluetooth Low Energy
while a dense schedule implies a solution where devices
generate a lot of traffic and consume a lot of energy. TSCH Bluetooth is a full protocol stack that supports small coverage
introduces several IEs that can be used for communication in while providing low to medium transmission rates under
the context of this mechanism. wireless communications [13]. Initially released in 1998 as
IEEE 802.15.4e [4] adapts security to support TMSP; it Bluetooth 1.0 and 1.0B by the Bluetooth Special Interest
defines the possibility of using optional 40-bit frame counters Group, it has been updated several times since then. In 2002
that are set to the ASN of the network. The use of the ASN it was amended as Bluetooth 1.1, also released as IEEE
provides time-dependent security as well as replay protec- 802.15.1-2002, to address several deficiencies of the orig-
tion. In order to support the use of the 40-bit frame counter, inal specification and to support Received Signal Strength
IEEE 802.15.4e modifies the security control field to use Indicator (RSSI) as a mechanism for power control. This
two of the originally reserved bits to (1) enable suppression standard led to Bluetooth 1.2, also released as IEEE 802.15.1-
68 3 Physical and Link Layers

Fig. 3.55 BLE and Bluetooth PICONET 1 PICONET 2

topologies
master
slave
PICONET 3

master
slave
slave master

slave

SCATTERNET
slave slave

STAR-BUS
BLE ADVERTISING
PHY CHANNEL
slave
master

slave

BLE PICONET BLE PICONET

PHY CHANNEL PHY CHANNEL
slave

2005, to improve modulation and transmissions rates among Under classic Bluetooth, a master device controls up to
other things. Enhanced Data Rate (EDR), introduced in 2004 seven slaves on a single piconet. In the context of Bluetooth,
as Bluetooth 2.0, further improves transmission rates and a piconet is an ad hoc network that links a wireless user
energy consumption by incorporating power duty cycles. group of devices. Slaves communicate with the master, but
Bluetooth 2.1 was released in 2007 to simplify the device they do not communicate with each other. A slave can also
pairing process. In 2009, Bluetooth 3.0 introduced High belong to more than one piconet. An example of a classic
Speed (HS) support by means of co-located IEEE 802.11 Bluetooth topology is shown in Fig. 3.55 with multiple pi-
links. BLE, also known as Bluetooth Smart and standardized conets deployed in a scatternet configuration. Under BLE,
as Bluetooth 4.0, was released in 2010 as a brand new however, slaves talk to the master on a separate channel. As
mechanism to support low power consumption [18]. As such opposed to classic Bluetooth piconets, where slaves listen
it has been an excellent candidate for many M2M, CPS, for incoming connections from the master, a BLE slave
and hybrid IoT solutions. BLE is not backwards compatible, initiates connections, and it is therefore in control of power
so classic Bluetooth devices cannot directly interact with consumption. A BLE master, which is assumed not to be as
pure BLE-based topologies. Bluetooth 4.0 relies on devices power constrained as a slave, listens for advertisements and
supporting both mechanisms independently. Bluetooth 4.1 initiates connections as a result of received advertisement
and Bluetooth 4.2 were, respectively, released in 2013 and frames. An example BLE topology is also shown in Fig. 3.55
2014 to address certain requirements in order to enhance deployed in a star-bus configuration.
accessibility of connected devices. Bluetooth 5.0, released
in 2016, boosted BLE modulation and transmission rates. In
2019 Bluetooth 5.1 added angle of arrival (AoA) and Angle 3.3.4.1 Physical Layer
of Departure (AoD) to improve asset tracking complement- Classic Bluetooth relies on FHSS at a rate of 1600 hops
ing the use RSSI [14]. per second with each code spanning over 79 channels in
It is important to emphasize that IEEE 802.15.1 [1] is the 2.4 GHz ISM band. The code that controls the hopping
the standardization of Bluetooth 1.1 and Bluetooth 1.2 and pattern is derived from the 48-bit MAC address of the master
it does not refer to any other version of Bluetooth including device. BLE, on the other hand, uses a different FHSS scheme
BLE. The physical and link layers of BLE, in a similar way as it relies on 40 2 MHz channels that enable higher reliability
to ZigBee, are mechanisms that by means of adaptation can over long-range coverage. Classic Bluetooth nominal trans-
be used to transport IPv6 traffic that is essential to IoT. mission rates are 1, 2, and 3 Mbps, while the BLE nominal
3.3 Wireless 69

transmission rate is 1 Mbps with a typical throughput of 3.3.4.2 Link Layer

260 Kbps. The BLE link layer is based on the state machine shown in
The individual channel modulation schemes used by Fig. 3.57. The machine defines five states: (1) advertising, (2)
FHSS to accomplish those transmission rates are Gaussian init, (3) standby, (4) scan, and (5) connection. The link layer
FSK (GFSK) for 1 Mbps, DQPSK for 2 Mbps, and D8-PSK is in standby state when it first starts. In this state the link
for 3 Mbps. GFSK is a version of FSK where a type of digital layer is inactive, and it can transition to and from the scan,
filter known as Gaussian is used to smooth the transitions advertising or init states. In addition, in the connection state,
between symbols and therefore minimize the noise. One it can also transition back to standby. In advertising state, a
problem with FSK-based modulations is that transmitting device sends advertising frames and responds to incoming
an all-ones sequence like 1111111111…111 results in scan requests from other devices. A device in advertising
modulating the same symbol and therefore transmitting a state is discoverable and can transition, as a slave, to connec-
one-tone signal for a long period of time. This signal confuses tion state when it receives a connection request from a master
the detector that dynamically adjusts to small frequency device in init state.
changes and causes it to fail to demodulate the next zero. One In scan state, a device listens for advertising frames in
way to prevent this situation is by introducing a whitening the wireless channel. Two types of scanning are possible:
mechanism that randomizes in a controlled fashion by means passive where the device listens for frames and active where
of a scrambler the sequence of transmitted bits. Figure 3.56 the device sends scan requests to induce other devices to send
shows the scrambler; it relies on a feedback shift register that advertising frames. If a device stops scanning, it transitions
provides a pseudo-random bitstream that is bitwise added to back to the standby state. When a device receives an advertis-
the input sequence. The resulting sequence serves as input to ing frame, it can attempt to connect to the advertising device
the modulator. by sending a connect request that triggers a transition, as a
BLE power consumption is somewhere between 1 and master, to the connection state. When the advertising device
50% of that of classic Bluetooth. Power consumption also receives the connection request, it also transitions to the con-
dictates the transmission rate as shown in Table 3.14. Note nection state as a slave. In connection state, master and slave
that classic Bluetooth, as opposed to BLE, defines three devices send and receive data frames. A master sends peri-
classes that link power consumption to distance. Class 1 and odic data frames to a slave in order to give it an opportunity to
BLE radios implement transmit power control (TPC) that reply and send its own data frames. Specifically, when a slave
forces transmitting devices to adjust power in order to min- receives an individual data frame, it can send back another
imize interference and extend battery life. Under TPC, the data frame. If the slave wants to send more frames, it must
RSSI is used to determine whether signals are received within wait for the master to send more of these periodic frames.
an acceptable range in order to vary power accordingly. Note A slave can go to sleep, by ignoring data frames from the
that TPC is optional in class 2 and 3 radios.

input sequence
ADVERSING

SLAVE
feedback shift register +

to modulator
CONNECTION STANDBY SCAN
Fig. 3.56 Scrambler

Table 3.14 Power vs. range

Class EIRP Range (m) MASTER

BLE 10 µW < 10 mW <50

1 2.5 < 100 mW <100
INIT
2 1 mW < 2.5 mW <10
3 <1 mW 0.1 < 1

Fig. 3.57 Link layer state machine

70 3 Physical and Link Layers

master, and reduce power consumption. Advertising frames The data access address is a random 32-bit number that
are used to set up connections between devices, while data identifies a connection between two devices. The 8-bit
frames are used for communication traffic between devices. packet header field is encoded as indicated in Fig. 3.59
Advertising frames are sent over three advertising channels, depending on whether it applies to advertising or data frames.
while data frames are sent over 37 different data channels. For advertising frames, the header includes an advertising
The upper sublayer of the BLE link layer is called the Logical frame type and two bits to indicate whether transmission
Link Control and Adaptation Protocol (L2CAP) that enables and reception addresses are public or random. The possible
the multiplexing of data with higher layer protocols and advertising frame types are (1) advertising indication, (2)
supports segmentations among other things. connection indication, (3) non-connectable indication, (4)
Figure 3.58 shows a generic BLE frame. It starts with a scannable indication, (5) active scanning indication, (6)
preamble that is followed by an access address field that is active scanning response, and (7) connection request. For
used by the receiver to filter out this frame from channel data frames, the header includes a logical link identifier that
noise. This field is in turn followed by a packet header indicates whether the frame is a segment of higher layer
field that is used to indicate the nature of the frame. The datagram or whether it is used for connection management.
length field signals the size of the data payload. The last This header also includes a sequence number that identifies
field of the frame is a FCS that by means of a CRC block this data frame within the transmission stream and a next
code provides basic channel encoding. The preamble is sequence number that tells the peer device what the expected
an 8-bit sequence of alternating ones and zeros that are receiving sequence number is. Finally, the more data field in
used by the receiver to detect the modulation frequencies this header tells the receiver that there are more frames to
and perform gain control. The access address is a 32-bit be sent and therefore the connection should stay active and
field that can be an advertising access address or a data power management in effect.
access address. The advertising access address is always Figure 3.60 shows how first a device, an advertiser, sends
10001110100010011011111011010110 and is used for data an advertising frame that triggers another device, an initiator,
broadcasting as well as advertising and scanning frames. to transmit a connection request. Once the connection is
established, the initiator becomes master and the advertiser
becomes slave. From this point on, data frames are sent by
1 4 1 1 variable (0-37) 3
both devices. Whenever a data frame is sent, the sending de-
P ACCESS ADDRESS H L DATA PAYLOAD FCS
vice specifies the sequence number of the transmitted frame
P Preamble (S) and expected sequence number of next incoming frame
H Header (N) as well as whether more frames are to follow (M). If a
L Length
FCS Frame Checksum

Fig. 3.58 BLE frame INITIATOR ADVERTISER

Advertising Packet Header

4 2 1 1

APT RESERVED T R

APT advertising packet type MASTER SLAVE

T tx address type
R rx address type

Data Packet Header

2 1 1 1 3

LLI N S M RESERVED

LLI link layer identifier

N next sequence number
S sequence number
M more data

Fig. 3.59 Packet header Fig. 3.60 Connection creation and data transfer
3.3 Wireless 71

frame is lost and, therefore, it does not arrive at the endpoint, Figure 3.61 shows the building blocks of the physical
the transmitter knows it has to retransmit it when it analyzes layer. The data stream is first modulated by FSK or GFSK
the expected sequence number of the incoming frame. In followed by Manchester or Polar NRZ line coding depending
the exchange of frames, each frame is further identified by on the rate as shown in Table 3.15. Line coding is introduced
device addresses that follow the length field as part of the data to minimize the DC component of the transmitted signal and
payload. Specifically, 48-bit initiator and advertising MAC improve range as well as penetration.
addresses are used to identify the transmitting devices. Each
MAC address can be a public device address that is assigned 3.3.5.2 Link Layer
by the manufacturer or a random device address that can ITU-T G.9959 relies on a traditional CSMA/CA MAC as
be either static if it is reset on power cycle or private if it most wireless technologies discussed in this section. Col-
periodically changed to prevent device tracking. lision avoidance is active for all devices in the network if
their radios are active. It is completely independent of the
transmission rate mode R1, R2, or R3. ITU-T G.9959 also
3.3.5 ITU-T G.9959 introduces both power efficiency by means of predictable
duty cycles and reliability by means of retransmissions.
ITU-T G.9959 provides physical and link layer wireless ITU-T G.9959 supports three channel configurations.
mechanisms for low-rate data transmission that are derived Configuration one supports one channel named channel A.
from the well-known consumer-oriented Z-Wave technology Configuration two supports two channels named channel A
[20]. Z-Wave focuses mainly on sensing and actuation func- and channel B. Configuration three supports three channels
tions in home and small business facilities. Some common named channel A, channel B, and channel C. Figures 3.62
examples of Z-Wave use include physical security, lighting and 3.63, respectively, show IEEE G.9959 unicast and
and climate control, smoke detectors, appliances, remote multicast MAC frames for channel configuration one and
controls, as well as smart meters. In a similar way to ZigBee two. The frame format for channel configuration three is
and IEEE 802.15.4, Z-Wave and ITU-T G.9959 support identical, but it also includes a sequence number field.
wireless mesh topologies that enable devices to communicate Each frame starts with a preamble that is used for device
with other devices even if they are not within range. This synchronization, follows with a Start of Frame (SoF) field
is done by means of traffic transmission over intermediate and a MAC Protocol Data Unit (MPDU), and ends with
nodes. The architecture also supports master controllers that an End of Frame (EoF) field. From a topology perspective,
provide wider access to devices. An individual ITU-T G.9959 ITU-T G.9959 networks are typically deployed in mesh
WPAN can integrate up to 232 devices, and multiple master configurations.
controllers can be used to partition the network based on The MPDU includes a MAC Header (MHR), a MAC
different functions. Service Data Unit (MSDU), and a MAC Footer (MFR). The
MHR starts with a 4-byte HomeID field that indicates the
3.3.5.1 Physical Layer ITU-T G.9959 network the device is associated with. All
ITU-T G.9959 operates on the 915/868 MHz ISM band but devices in the network share the same HomeID. The MHR
relies on other bands in many other countries based on follows with a 1-byte source node ID that together with
licensing and regulations. Modulation is based on plain FSK
and GFSK in a similar way to BLE but without FHSS.
Three different transmission rates are supported by this tech- Table 3.15 Z-wave modulation
nology through physical layer configuration changes: R1 at Data rate Modulation Line coding Rate (Kbps)
9.6 Kbps, R2 at 40 Kbps, and R3 at 100 Kbps. The signal R1 FSK Manchester 9.6
coverage is up to 30 m depending on power and obstruction R2 FSK NRZ 40
conditions. The electrical transmission power is 1 mW. R3 GFSK NRZ 100

DATA RATE
(R1=9.6 Kbps, R2=40 Kbps, R3=100 Kbps)
PREAMBLE

MODULATOR CHANNEL CODING RF

DATA FRAME
(FSK/GFSK) MANCHESTER/NRZ ANTENNA

Fig. 3.61 Z-wave physical layer

72 3 Physical and Link Layers

4 1 2 1 1 m 1 or 2

Source Frame Dest

preamble SoF HomeID Node ID Control Length Node ID Data Payload FCS EoF

MHR MSDU MFR

MPDU
MHR MAC Header
MFR MAC Footer
MPDU MAC Packet Data Unit
MSDU MAC Service Data Unit
FCS Frame Checksum
SoF Start of Frame
EoF End of Frame

Fig. 3.62 ITU-T G.9959 unicast MAC frame

4 1 2 1 1 29 m 1 or 2

HomeID Source Frame Length Multicast Multicast FCS

preamble SoF Data Payload EoF
Node ID Control Control Bitmask
MHR MSDU MFR
MPDU

MHR MAC Header

MFR MAC Footer
MPDU MAC Packet Data Unit
MSDU MAC Service Data Unit
FCS Frame Checksum
SoF Start of Frame
EoF End of Frame

Fig. 3.63 ITU-T G.9959 multicast MAC frame

Table 3.16 Destination NodeID presented in Sect. 3.3.3, they can support IPv6 with the right
Value Meaning adaptation mechanism.
00000000 Uninitialized
00000001 − 11101000 NodeID
11101001 − 11111110 Reserved 3.3.6 DECT ULE
11111111 Broadcast NodeID
Digital enhanced cordless telecommunications (DECT) is
a cordless telephone technology that has been extended, as
the HomeID identify the device that generated the frame. DECT Ultra Low Energy (DECT ULE), for use in wireless
The MHR continues with a 2-byte frame control field that sensor and actuator networks in the context of smart home
defines the frame type as well as other control flags. Pos- applications [9]. The protocol is managed by the ULE Al-
sible frame types, among others, are unicast, multicast, and liance and intends to provide long-range and middle-rate
acknowledgment frames. The following fields are the 1-byte transmission rates with very little power consumption and
MPDU length and a 1-byte destination node ID that identifies low latency. Low power consumption combined with low
the device destination. Possible values of the destination duty cycles leads to batteries lasting over 5 years. Typical
NodeID are shown in Table 3.16. Multicast frames, shown in coverage is up to 60 and 500 m for indoor and outdoor
Fig. 3.63, include instead a 1-byte multicast control field and scenarios, respectively. The DECT ULE topology is a star
29-byte multicast bitmask that identify the destinations of with one-hop links between devices and the base station
the frame. For frames associated with channel configuration that plays the role of IoT gateway. Up to 400 devices are
three, the sequence number is a 1-byte value. The MSDU supported in a single DECT ULE network.
field includes the actual upper layer datagram. Acknowl-
edgment frames that are used when retransmissions are in 3.3.6.1 Physical Layer
place do not include the MSDU field. In general devices DECT ULE operates on the unlicensed cordless phone fre-
can only receive frames with MSDU fields that are short quency bands of 1.8 GHz in Europe and 1.9 GHz in US
enough to comply with configured transmission rates. The with channel spacing of 1.728 MHz supporting a maximum
MFR includes a 1-byte FCS. Because ITU-T G.9959 frames nominal transmission rate of 1 Mbps. The modulation relies
follow a similar structure to that of IEEE 802.15.4 frames on a GFSK scheme.
3.3 Wireless 73

3.3.6.2 Link Layer 3.3.7 NFC

DECT ULE uses frames of 24 timeslots transmitted every
10 ms divided in two groups of 12 timeslots configured for Near-field communications (NFC) is a technology that pro-
downlink and uplink communications, respectively. Frames vides ways for devices to communicate with each other by
are transmitted on channels at different frequencies, thus means of contactless transactions. NFC also enables efficient,
supporting frequency division multiple access (FDMA). Each convenient, and easy access to digital content. NFC relies on
frame, in turn, supports full duplex timeslot groups relying on several contactless card mechanisms, and therefore it is back-
time division duplex (TDD). TDD is a mechanism by which ward compatible with existing infrastructure. NFC devices
uplink and downlink communications share the same carrier supports three modes of operation: (1) NFC card emulation
frequency, but they have different allocated timeslots. Within that enables devices to act like smart cards so they can per-
each TDD group, multiple timeslots support TDMA. form transactions like payments, (2) NFC reader/writer that
Figure 3.64 shows a single timeslot that consists of a 4- enables devices to read information stored in NFC tags, and
byte preamble that is used for device synchronization, a 1- (3) NFC peer-to-peer that enables devices to communicate
byte network data header, a 5-byte network data payload, with each other. From an IoT perspective, NFC peer-to-peer
and a 2-byte network data checksum. The frame includes mode is the mechanism to provide IPv6 connectivity.
a variable length user data payload that, depending on the
configuration, includes an embedded user data checksum. 3.3.7.1 Physical Layer
The timeslot also includes a 4-bit quality field that provides NFC relies on the ISO/IEC 18000-3 standard that enables
QoS support and a 60-bit (71/2-byte) guard to prevent access passive radio-frequency identification (RFID) element iden-
collisions. This frame format leads to a packet size that is any- tification by means of electromagnetic induction between
where between 32 and 256 bytes. DECT ULE also supports two antennas located within their near fields [2]. This forms
security by means of pre-shared key-based encryption. an air-core transformer that operates within the 13.56 MHz
Figure 3.65 shows the DECT ULE protocol stacks; two
planes are supported: a control plane (C-Plane) and a user
C-PLANE U-PLANE
plane (U-Plane). C-Plane supports reliable transmission of
control traffic, while U-Plane supports speech and data trans-
mission in circuit switched (CS) and packet switched (PS)
modes, respectively. The link layer incorporates a Data Link
Control (DLC) layer that is responsible for routing of C-
Plane and U-Plane information. The network layer operates DECT DLC DECT ULE DLC
between peers with exchange of messages used for establish- L2 MAC
ment as well as maintenance and release of sessions. In order
to enable IPv6, 6LoWPAN datagrams are transmitted directly L1 PHY
over DECT ULE DLC in the U-Plane.
Fig. 3.65 DECT ULE protocol stack

DOWNSTREAM SLOTS UPSTREAM SLOTS

FRAME

PREAMBLE HDR NETWORK DATA CS USER DATA Q GUARD

4 1 5 2 n ½ 7½
HDR Network Data Header
CS Network Data Checksum
Q Quality

Fig. 3.64 DECT ULE frame

74 3 Physical and Link Layers

ISM band. In a passive configuration, NFC consists of an Summary

interrogator and a tag. The interrogator generates an RF
field that induces an electric field and powers the tag. In an There are several physical and link layer technologies that are
active configuration, which is associated with NFC peer-to- an integral part of many IoT solutions. Tables 3.17 and 3.18
peer mode, devices are always powered up and those wait- compare the technologies presented in this chapter including
ing for traffic disable their transmitters. Three transmission their most important characteristics. Note that CB and CF
rates are possible, 106 Kbps, 212 Kbps, and 424 Kbps that in the MAC column stand for contention-based (CB) and
depend on the modulation scheme and the configuration. contention-free (CF) MAC. While many of these mecha-
For 106 Kbps in passive configuration, 212 and 424 Kbps nisms are stand-alone protocols, a large proportion of them
bitstreams the scheme is a combination of Manchester line belong to proprietary stacks like ZigBee and BLE that do
coding with 10% ASK modulation. This implies that both not natively support IPv6. This chapter started by briefly re-
one and zero are encoded using a Manchester line code, but viewing basic physical layer modulation techniques like line
zero are attenuated by 10% of the peak signal amplitude. For codes, passband modulation, spread spectrum, and discrete
a 106 Kbps bitstream, in active configuration, bit encoding is multicarrier modulation that serve as building blocks of most
a combination of MMC with 100% ASK modulation. This
means that ones are encoding using an MMC line code, but
zeros are completely attenuated and not transmitted. Table 3.17 Wireline physical/link layers
Protocol Medium Modulation MAC Max
3.3.7.2 Link Layer nominal
rate
The NFC link layer is carried out by the Logical Link Control
Ethernet Twisted PAM CF 400 Gbps
Protocol (LLCP). LLCP provides three mechanisms: (1) pair, fiber
link management, (2) connection-oriented transmission, and optics
(3) connectionless transmission. Link management enables ITU-T G.9903 Existent DPSK, CF 34 Kbps
packet data unit (PDU) aggregation and disaggregation as electrical QAM
wiring
well as link status monitoring. Connection-oriented trans-
IEEE 1901.2 Existent DPSK, Both 500 Kbps
mission keeps track of maintaining all connection-related ex-
electrical QAM
changes including connection establishment and tear down. wiring
Connectionless transmission handles unacknowledged data MS/TP RS-485 Differential CB 115.2 Kbps
exchanges. Most NFC deployments are P2P with a single based signaling
device talking to a single M2M or IoT gateway.
Figure 3.66 shows the PDU format; it includes a 6-bit Table 3.18 Wireless physical/link layers
DSAP along with a 6-bit SSAP that are used to identify Protocol Bands Max Modulation MAC Max
the service access points with values between 0 and 15 to coverage nominal
rate
indicate well-known services, values between 16 and 31 to
IEEE 802.11 ISM/non- 1 km DSSS, Both 10 Gbps
indicate registered local services, and values between 32 and ISM OFDMA
47 to indicate services assigned by the upper layers. Note that IEEE 802.15.3ISM 10 m QAM CB 55 Mbps
the format of DSAPs and SSAPs is not the same as that of 2.4 GHz
DSAPs and SSAPs associated with IEEE 802.2. The PDU IEEE 802.15.4ISM 1 km DSSS, Both 250 Kbps
also includes a 4-bit PDU Type (PTYPE) that specifies the 1/2.4 GHz OQPSK
syntax and semantic of the remaining fields. Additionally, an BLE ISM 400 m FHSS, CB 3 Mbps
optional 8-bit sequence field identifies receiving and trans- 2.4 GHz GFSK
ITU G.9959 ISM 1 GHz 30 m GFSK CB 100 Kbps
mitting sequence numbers. The frame ends with a variable
DECT ULE ISM 500 m GFSK CB 1 Mbps
length payload. Note that address values between 32 and
1.8 GHz
47 can be used to generate IPv6 interface identifiers. IPv6 NFC ISM 10 cm ASK CF 424 Kbps
datagrams are transmitted under NFC by adopting some of 13.56 MHz
the 6LoWPAN techniques.

Fig. 3.66 PDU format 6 4 6 8 variable

DSAP PTYPE SSAP SEQUENCE PAYLOAD

DSAP Destination Service Access Point

PTYPE PDU Type
SSAP Source Service Access Point
Homework Problems and Questions 75

of these the technologies. The chapter first explored wireline

protocols like Ethernet, ITU-T G.9903, IEEE 1901.2, and
MS/TP and then proceeded to analyze wireless mechanisms
like IEEE 802.11, IEEE 802.15.3, IEEE 802.15.4, BLE, ITU-
T G.9959, DECT ULE, and NFC. In all cases, each of these A C
technologies was presented from the perspective of their
modulation and media access algorithms that are respectively B
associated with physical and link layers.

Homework Problems and Questions

3.1 In Fig. 3.2, how does signal coverage relate to LLNs? 3.8 A sensor generates a single readout once every second.
Each readout can take one out of 16384 possible values that
3.2 The readouts generated by an IoT sensor become the are subjected to a block code with rate r = 78 . Assuming the
following codewords when encoded by a block code: 0000, overhead due to network, transport, and session layer headers
0011, 0101, 0110, 1001, 1010, 1100 and 1111. What is the is 48 bytes, what is the protocol efficiency and the nominal
code rate? transmission rate of the following mechanism?

3.3 If a wireline connected sensor transmits the following (a) Ethernet

differentially encoded signal. What does the transmitted bit- (b) MS/TP
stream look like? (c) IEEE 802.15.4 (S = 0, C = 1, SAM = 10, DAM = 10)

The efficiency is given by the ratio between the size of the

actual sensor data and the total size of the frame. What
1 1 1 1 0 0 0 1 1 1 1 0 0 1 0 0 1 0 0 1 1 1 1 1 can be concluded from the efficiency and transmission rate
numbers? Ignore preamble and start frame delimeters in the
reference

frame length computation.

3.9 One of the rates supported by IEEE 802.11ah is

1.8 Mbps, how is this nominal rate obtained based on the
modulation scheme and code rate?

3.4 What do you think is the problem of a scheme where 3.10 How long does it take to transmit a full size IEEE
the sensor of Problem 3.2 generates a continuous sequence 802.15.4 frame? How does it compare to a full size Ethernet
of 0000 codewords encoded with AMI in a wireline environ- frame? What are the implications?
ment?
3.11 If an IEEE 802.15.4 layer receives a 130-byte datagram
3.5 If a wireless sensor uses a 64-QAM modulation scheme from its upper layer, what does the IEEE 802.15.4 layer do?
and the symbol duration is T = 100 µs, what are the symbol
Rs and transmission Rb rates? 3.12 Under IEEE 802.15.4, if the address field is 8 bytes
long. What are the values of the SAM, DAM, and C fields?
3.6 An OFDM scheme consists of 16 16-QAM subchannels
and 16 64-QAM subchannels with symbol duration T = 3.13 An IEEE 802.15.4 frame has the following fields S=0,
6.4 µs, what is the transmission Rb rate? C=0, SAM=11, DAM=10 and a 40-byte payload. How long
does it take to be transmitted?
3.7 Consider two IoT sensors A and B that transmit readouts
to sensor C that, in turn, forwards the aggregated traffic to 3.14 Consider the BLE communication flow below. What
the network core. The signal coverage of A and B is such are the missing transactions?
that they cannot directly communicate with each other. How
is this scenario affected by the hidden and exposed station
phenomena?
76 3 Physical and Link Layers

6. ZigBee Specification. Standard, The ZigBee Alliance, California

MASTER SLAVE (2015)
7. IEC 62591:2016 Industrial networks - Wireless communication
network and communication profiles - WirelessHART. Standard,
International Electrotechnical Commission, Geneva (2016)

? 8. IEEE standard for information technology—telecommunications

and information exchange between systems local and metropoli-
tan area networks specific requirements—part 11: Wireless lan
medium access control (MAC) and physical layer (PHY) specifica-
tions. IEEE Std 802.11-2016 (Revision of IEEE Std 802.11-2012)
pp. 1–3534 (2016)
9. ETSI TS 102 939. Standard, European Telecommunications Stan-
dards Institute, Sophia Antipolis (2017)
10. IEEE standard for ethernet. IEEE Std 802.3-2018 (Revision of
IEEE Std 802.3-2015) pp. 1–5600 (2018)
3.15 What are some advantages and disadvantages of the
11. IEEE Standards Association: IEEE standard for low-rate wire-
topologies shown in Fig. 3.46? less networks. IEEE Std 802.15.4-2020 (Revision of IEEE Std
802.15.4-2015), pp. 1–800 (2020)
3.16 Given the BLE state machine in Fig. 3.57, is it possible 12. Benedetto, S., Biglieri, E.: Principles of Digital Transmission: With
Wireless Applications. Kluwer Academic Publishers, Dordrecht
for a Master device to generate advertising messages?
(1999)
13. Bluetooth, S.: Bluetooth 5.2 Core Specification, p. 3256. Bluetooth
3.17 What technologies presented in this chapter do not rely SIG, Kirkland (2019)
on ISM bands? 14. Cominelli, M., Patras, P., Gringoli, F.: Dead on arrival: An empir-
ical study of the bluetooth 5.1 positioning system. In: Proceedings
of the 13th International Workshop on Wireless Network Testbeds,
3.18 To minimize interference in the overcrowded ISM Experimental Evaluation & Characterization, pp. 13–20 (2019)
bands, what other technologies can be used together with 15. Gilb, J.P.K.: Wireless Multimedia: A Guide to the IEEE 802.15.3
ITU-T G.9959? Standard, 250 p. IEEE Press (2003). ISBN 0-7381-3668-9
16. Glover, I., Grant, P.: Digital Communications. Prentice-Hall, Upper
Saddle River (2010)
17. Proakis, J.G.: Fundamentals of Communication Systems, 2nd edn.
Pearson, Boston (2014)
18. Gupta, N.: Inside Bluetooth Low Energy. Artech House Mobile
References Communications Series. Artech House, Norwood (2016). https://
books.google.com/books?id=hRoQkAEACAAJ
1. IEEE standard for information technology– local and metropoli- 19. Haykin, S.: Communication Systems, 5th edn. Wiley, Hoboken
tan area networks– specific requirements– part 15.1a: Wireless (2009)
medium access control (MAC) and physical layer (PHY) speci- 20. International Telecommunication Union: Short range narrow-band
fications for wireless personal area networks (WPAN). IEEE Std digital radio communication transceivers - PHY and MAC layer
802.15.1-2005 (Revision of IEEE Std 802.15.1-2002) pp. 1–700 specifications, ITU-T Recommendation G.9959, January 2015
(2005) 21. International Telecommunication Union: Narrowband orthogo-
2. ISO/IEC 18000-3: Parameters for air interface communications at nal frequency division multiplexing power line communica-
13,56 MHz. Standard, International Organization for Standardiza- tion transceivers for G3-PLC networks, ITU-T Recommendation
tion, Switzerland (2010) G.9903, May 2013
3. ANSI/ISA-100.11a-2011 Wireless systems for industrial 22. Kurose, J.F., Ross, K.W.: Computer Networking: A Top-Down
automation: Process control and related applications. Standard, Approach, 6th edn. Pearson, London (2012)
International Society of Automation, Research Triangle 23. Newman, H.M.: BACnet: The Global Standard for Building Au-
Park (2011) tomation and Control Networks. Momentum Press, New York
4. IEEE standard for local and metropolitan area networks–part 15.4: (2013)
Low-rate wireless personal area networks (LR-WPANs) amend- 24. Perahia, E., Stacey, R.: Next Generation Wireless LANs: 802.11n
ment 1: Mac sublayer. IEEE Std 802.15.4e-2012 (Amendment to and 802.11ac, 2nd edn. Cambridge University Press, Cambridge
IEEE Std 802.15.4-2011) pp. 1–225 (2012) (2013)
5. IEEE standard for low-frequency (less than 500 kHz) narrowband 25. Rackley, S.: Wireless Networking Technology: From Principles to
power line communications for smart grid applications - amend- Successful Implementation. Newnes, USA (2007)
ment 1. IEEE Std 1901.2a-2015 (Amendment to IEEE Std 1901.2- 26. Sklar, B.: Digital Communications: Fundamentals and Applica-
2013) pp. 1–28 (2015) tions. Pearson Prentice Hall, Upper Saddle River (2017)
 Network and Transport Layers
4

Since this adaptation is performed in the same device,

4.1 Why IP? there is no need for extra equipment or expensive network
topology changes. Moreover, introducing an adaptation layer
Many of the state-of-the-art technologies used in M2M, is typically performed by means of software updates that
CPS, and hybrid IoT scenarios like ZigBee [32], BLE [2], require no hardware changes. This comparatively lowers
ANT+ [14], Z-Wave [12], and NFC [11], among others, have deployment and management costs, reduces both latency as
no native IP support, and in many cases they are not even IP well as packet loss, and therefore improves connectivity and
compliant. They provide full stacks with their own physical, overall QoS.
link, network, transport, and application layers that do not Enabling devices to natively support IP-based protocols
usually interoperate outside their specific technology. This has several advantages; (1) devices can directly connect to
lack of compatibility is caused by the fact that they are stand- IP networks without the need of additional hardware and
alone stacks that have evolved into independent standards. software modules; (2) changes to IP network and routing
For broad interaction in the context of IoT, IP is typically infrastructure are minimized; (3) IP-based protocols, that
provided by means of border gateways that provide the have been around for decades, are proved to work and scale
translation between traffic generated by these technologies well; (4) standard socket APIs, that allow users to manage
and the datagrams that enable some basic IP connectivity. and control IP-based protocols, are an industry standard that
There are many problems associated with this approach: is available in almost every single software platform; (5) IP-
(1) increased deployment costs due to more complex network based protocols, standardized and documented by means of
topologies that result from the many different standards that IETF RFCs, are open, free, and available to everyone; and
must be translated, (2) increased transmission delays due (6) IP networks can be managed and monitored through a
to extra translations that negatively affect real-time perfor- number of widely available tools and mechanisms.
mance during sensing and actuation, (3) lack of real end- As already mentioned in Sect. 1.1, traditional IPv4 im-
to-end IP connectivity that enables applications to monitor poses address size restrictions that makes its use impractical
and access devices in an efficient way, (4) increased device for the volume of traffic and number of devices that IoT
deployment and management costs due to the need of inter- is intended to support. It is true that there are mechanisms
acting with different overlapping technologies, and (5) packet to overcome these restrictions, in particular NAT, but they
loss and other network impairments due to routing issues are quite cumbersome as they add unnecessary complexity
caused by the lack of a common network layer. and violate basic principles of the layered architectures.
The state-of-the-art standards rely on some of the physical Essentially, NATting uses transport layer ports to extend the
and link layer technologies introduced in Chap. 3. These range of the network layer addresses. In this context, the best
technologies, in turn, exhibit very good properties that, if alternative to IPv4 is IPv6. IPv6 relies on 128-bit addresses
adapted to provide end-to-end IP support, can enable IoT in order to supply an address space that is large enough to fit
solutions. Moreover, with a common network layer protocol billions of devices supporting end-to-end IP connectivity.
like IP, many of the issues indicated above can be greatly M2M, CPS, and hybrid IoT physical and link layers like
eliminated or at least mitigated. In recent years, and to this those of ZigBee, BLE, Z-Wave, and NFC provide compar-
end, there has been a massive effort by IETF to provide atively low transmission rates that, in order to minimize
adaptation layers that add IP support to these proprietary latency, limit their maximum frame sizes to values that are not
physical and link layers. compatible to mainstream IPv6 fragmentation. To address

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 77

R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_4
78 4 Network and Transport Layers

this issue, IPv6 adaptation is an intermediate mechanism address has a prefix that is used for network identification.
that sits between the link layer and the network layer to Specifically, the prefix indicates how many leading bits de-
address this fragmentation issue as well as other related termine the network identity. For example, if the address is
problems. The most popular IPv6 adaptation technology is 2001::10:21:10/64, it means the first 64 bits, that is 2001::,
6LoWPAN [26, 19, 15] that interfaces with IEEE 802.15.4 identify the network.
and has been widely extended to other link layer technologies The first few bits of an IPv6 address always indicate its
like BLE as 6LoBTLE [22]. format. Figure 4.1 shows the format of unicast addresses.
Regardless of limitations like frame size, using IPv6 and They start with the 001 binary sequence leading to prefixes
upper layer protocols directly without adaptation can be 2000::/3 and 3000::/3. It follows 45-bit and 16-bit fields
demanding for embedded IoT devices due to several reasons: known as global routing prefix and subnet identification,
(1) traditional security mechanisms that provide authentica- respectively. The global routing prefix is assigned to a site,
tion and encryption like IP Security (IPSec) [6] and Transport and the subnet identification is assigned to a subnet within
Layer Security (TLS) [24, 23] are too complex, (2) the a site. The 64-bit Interface Identification (IID) that follows
most popular session management application layer protocol identifies the specific device in the subnet. Because de-
transmitted over TCP, HTTP, is also too complex, (3) many vices supporting unicast IPv6 addresses can participate in
IPv6 session and application layer protocols require contin- the global IPv6 infrastructure, unicast addresses are known
uous connectivity (this is a limitation that is not compatible as global unicast addresses (GUAs). Some unicast addresses
with power duty cycles of many embedded IoT devices), (4) are known as Unique Local Unicast Addresses (ULAs) when
IPv6 multicast transmissions are not always supported by link they are routable inside a limited area like a site, but they are
layers of constrained technologies like IEEE 802.15.4, and not expected to be routable in the global Internet.
(5) IPv6 routing technologies are not prepared to deal with Figure 4.2 shows the format of multicast addresses. They
capillary networks that rely on mesh topologies to improve identify a group of devices such that a single device can
energy consumption. belong to multiple groups. The first 8 bits of a multicast
In order to understand IPv6 adaptation technologies like address are all ones that are followed by a flag and a scope
6LoWPAN, it is first necessary to understand IPv6 and its field. The address ends with a 112-bit group identification
benefits. field. Figure 4.3 shows the 4-bit flags field with three relevant
bits: (1) T that indicates that the address is temporary, (2)
P that indicates that the address is a unicast-prefix based
4.2 IPv6 IPv6 multicast address, and (3) R that indicates that the ren-
dezvous point address is embedded in the multicast address.
The most important and relevant change introduced by IPv6 Table 4.2 shows the 4-bit scope field that specifies the scope
[5, 8] is the support of 128-bit addresses that exponentially of the multicast group. As in the IPv4 case, some multicast
increase the potential number of accessible devices. IPv6 addresses are used to assign specific groups; FF02::1 and
address notation is based on eight 16-bit values separated FF02::2 identify all devices and all routers, respectively. As
by colons. Each 16-bit value is represented, in turn, by a the scope is link-local, datagrams are not forwarded by a
hexadecimal number with all its leading zeros removed. An border router.
IPv6 address can be represented in a short form by replacing Figure 4.4 shows the format of link-local addresses. They
any sequence of all-zero 16-bit values with a double colon. are used for bootstrapping and connectivity within a single
For example, the long form 2001:0:0:0:0:10:21:10 can be link. They start with the 10-bit binary sequence 1111111010
represented as the short form 2001::10:21:10. followed by 54 zeros and the 64-bit IID. The prefix of a link-
Table 4.1 shows this and other relevant IPv6 address local address is, therefore, always FE80::/10.
types including their IPv4 example counterparts. Each IPv6 Besides the address size change, IPv6 introduces a dif-
ferent header format that is shown in Fig. 4.5. It includes
several fields: (1) a 4-bit version field used to identify the
Table 4.1 IPv6 addresses
IP version number that always carries a value of 6; (2) an
IPv4
8-bit traffic class field that provides QoS information; (3) a
equivalent
Long form Short form Type example 20-bit flow label that identifies the datagram as part of a flow
2001:0:0:0:0:10:21:10 2001::10:21 Unicast 192.168.21.5 of datagrams; (4) a 16-bit payload length that indicates the
FF01:0:0:0:0:0:0:2105 FF01::2105 Multicast 224.0.0.24 number of payload bytes that follow this header; (5) an 8-
FE80:0:0:0:983D:3F44: same Link-local 169.254.1.10 bit next header field that specifies the protocol under which
2819:CFCC the payload is encoded; (6) an 8-bit hop limit field, also
0:0:0:0:0:0:0:1 ::1 Loopback 127.0.0.1 known as IP Time to Live (IP TTL), that provides a counter
0:0:0:0:0:0:0:0 :: Unspecified 0.0.0.0 that is decremented as the datagram is forwarded throughout
4.2 IPv6 79

Fig. 4.1 IPv6 unicast addresses

3 45 16 64 bits
001 global routing prefix subnet ID interface ID

Fig. 4.2 IPv6 multicast 8 4 4 112 bits

addresses
11111111 flags scope group ID

Fig. 4.3 IPv6 multicast flags 0 1 2 3

field
0 R P T

R rendezvous point
P unicast-prefix based IPv6 mulcast address
T temporary address

Table 4.2 IPv6 multicast scope Hex value Scope

field
1 Interface
2 Link
4 Admin
5 Site
8 Organization
E Global

Fig. 4.4 IPv6 link-local 10 54 64 bits

addresses
1111111010 0 interface ID

Fig. 4.5 IPv6 header 0 4 12 16 24

VERSION TRAFFIC CLASS FLOW LABEL

PAYLOAD LENGTH NEXT HEADER HOP LIMIT

SOURCE ADDRESS

DESTINATION ADDRESS

PAYLOAD
80 4 Network and Transport Layers

0 8 16 0 8 16
TYPE CODE CHECKSUM TYPE CODE CHECKSUM

MESSAGE BODY HOP LIMIT M O H PRF ROUTER LIFETIME

REACHABLE TIMER
Fig. 4.6 ICMPv6 RETRANSMISSION TIMER

0 8 16 OPTIONS…
TYPE LENGTH … M managed
… O other
H home agent
PRF preference
Fig. 4.7 ND message options
Fig. 4.8 Router advertisement ND message

the network; and (7) the aforementioned 128-bit source and 0 8 16 24 25 26

destination addresses. Note that when the IP TTL reaches TYPE = 3 LENGTH = 4 PREFIX LENGTH L A
zero, the datagram is dropped from the network. The payload VALID LIFETIME (seconds)
that follows the IPv6 header is processed by the destination
PREFERRED LIFETIME (seconds)
device.
An IPv6 header does not include many of the fields RESERVED
found in IPv4 headers. Fragmentation/reassembly fields are
not present since IPv6 does not support fragmentation and
reassembly at intermediate routers and can only be performed PREFIX
at source and/or destination by means of a special header. A
header checksum field is also absent since it is assumed that
link-layer and/or transport layers perform some type error
control. The IPv6 header does not include an options field L on-link determination
A SAA support
either since it is assumed that options can be signaled by
means of additional headers. Fig. 4.9 Prefix information
IPv6 borrows from IPv4 the Internet Control Message
Protocol (ICMP) that is used by devices and routers to com-
municate network layer information to each other. ICMPv6 Figure 4.8 shows an ICMPv6 RA ND message. It includes
[9], as it is called, follows the IPv6 header and has the general several fields; an 8-bit hop limit field for transmitters in the
format shown in Fig. 4.6. It includes a 1-byte type field that link, a managed bit that, when set, specifies that addresses
determines the format and meaning of the message, a 1-byte are obtained via DHCPv6 or through Stateless Address Au-
code field that can be used to support multiple subtypes and a toconfiguration (SAA, described later); otherwise, an other
2-byte checksum field that provides some basic error control. bit that indicates, when set, that additional configuration
ICMPv6 is essential in enabling IPv6 devices to interact information is obtained by means of DHCPv6, a home agent
with each other by means of the Network Discovery (ND) bit used to support mobility, a 2-bit preference field that
protocol [27]. ND messages are encoded as ICMPv6 with advertises the priority, between −1 and 1, of the router when
certain messages including a sequence of type-length-value compared to others, an 8-bit router lifetime that tells the
(TLV) options, shown in Fig. 4.7, transmitted inside the devices how long the router is available, a 16-bit reachable
payload. The type specifies the kind of option; the length timer field that indicates how long they should consider a
indicates the length of the option in multiples of 8-byte blocks neighbor to be reachable after they have received reachability
that are encoded, as values, on a 64-bit boundary. Certain confirmation, and a 16-bit retransmission timer field that
types of options can appear multiple times in ND messages. says how long a device should wait before retransmitting
One of the functions of ND is to provide communication neighbor solicitation messages. Options, included as TLVs,
with routers to enable connectivity beyond the local link. In encode information that can be used to specify the router
fact, on any given link, routers periodically send multicast (to link layer address and/or the network MTU size and/or prefix
address FF02::1) Router Advertisement (RA) ND messages information.
that are used to provision devices with network parameters Figure 4.9 shows the prefix TLV; it includes an 8-bit prefix
like prefix and hop limit information. Devices rely on this length, an on-link determination bit that indicates whether all
information to build a list of candidate routers that can be addresses covered by the prefix are considered link local, an
used to reach other networks.
4.3 6LoWPAN 81

0 8 16 state can be used for connectivity if they are used within

TYPE CODE CHECKSUM the preferred lifetime. The deprecated state is the state of
an address after its lifetime expires. Addresses in deprecated
state are no longer valid and can only be used for preexistent
OPTIONS… flows and connections. The deprecated state is active during
the predefined valid lifetime and enables devices to switch to
Fig. 4.10 Router solicitation ND message new addresses that must also be in the tentative state before
becoming preferred.
SAA support bit that specifies that the prefix is to be used The reason for relying on a state machine and not using
for SAA, a 32-bit valid lifetime field that indicates how long IPv6 addresses right away is because link layer addresses
the prefix is valid for existing connections, a 32-bit preferred are not always unique. In fact, although it is often true that
lifetime field that indicates how long the prefix is valid for most link layer technologies (like Ethernet) provide unique
new connections, and a 128-bit prefix field. The prefix is addresses, this is not always guaranteed. To this end, during
padded with zeros to comply with the specified length. the tentative state, a device performs DAD and validates its
If a newly deployed device has not received any RA ND own generated IPv6 address by transmitting multicast a NS
message, it can send out a Router Solicitation (RS) ND ND message requesting the link layer address of the address.
message to the multicast address (FF02::2) to induce routers If any other device on the link is already using that IPv6
to transmit RAs. As shown in Fig. 4.10, RS ND messages are address, it responds by transmitting an NA ND message that
just empty ICMPv6 messages. indirectly tells the querying device that the address is not
The ND protocol also addresses connectivity between available for use. In this case, the device needs to obtain a
devices by means of the Neighbor Solicitation (NS) ND mes- new address by some other means. If the request timeouts,
sage that is primary used as a substitute of the IPv4 Address the address transitions to the preferred state. The latency
Resolution Protocol (ARP). Specifically, ICMPv6 NS ND introduced while a device is in the tentative state can be
messages allow devices to find out the link layer address of avoided if instead of plain DAD, optimistic DAD is alterna-
other on-link devices. This, in turn, enables devices to find tively used. Under optimistic DAD, devices start using their
out if other on link devices are reachable by keeping track generated IPv6 addresses right away even while validation
of the Neighbor Unreachability Detection (NUD) cache. In is still in progress. Traffic flow, in this case, is minimized
response to NS ND messages, a device sends a Neighbor by only allowing the transmission of those datagrams that
Advertisement (NA) ND message that includes its own link do not affect the address translation caches of other on-link
layer address. Note that NA ND messages can also be sent devices. Note that SAA relies on dynamic lifetime values
unsolicited to signal link layer address changes. Another type provided by routers in RA ND messages. If a router changes
of ND message is the ICMPv6 Redirect ND message that is its lifetime estimations, devices relying on SAA must update
used by routers to inform other IPv6 devices on the link about their address configuration accordingly.
a better next hop device.
SAA [21], mentioned above, is a distributed mechanism Example 4.1 Consider an IEEE 802.15.4 device with
that allows devices to obtain a unique unicast IPv6 address a 11:22:33:44:55: 66:77:88 MAC (EUI-64 format)
that serves for proper routing of datagrams. A device relying address. If the network prefix is 2001:2105::/64, what
on SSA dynamically generates its IPv6 address by combining IPv6 address is derived from this MAC address by
its 64-bit Interface Identifier (IID) with the router supplied means of SAA?
prefix. The IID is derived from the device link layer address
and depends, therefore, on the link layer technology in use.
For Ethernet interfaces, this means converting the 48-bit Solution The IID is given by the MAC address; there-
MAC address into a modified IEEE 64-bit EUI-64-based fore the IPv6 address generated by means of SAA is
IID. This is done by inserting the 16-bit binary sequence 2001:2105::1122:3344:5566:7788.
1111111111111110 in between the third and fourth byte and
flipping a bit known as the universal/local bit in the resulting
EUI-64 address.
4.3 6LoWPAN
Each SAA generated address can be in one of three states.
The tentative state is the initial state of an address, when it
For the many reasons mentioned in previous Sections, IPv6
cannot be used since it is being validated by means of the
cannot be directly used with most of the physical and link
Duplicate Address Detection (DAD) mechanism (described
layer technologies that are part of IoT. Sitting in between
in the next paragraph). The preferred state is the state of an
network and link layers, 6LoWPAN and 6LoWPAN-like
address once it has been validated. Addresses in preferred
82 4 Network and Transport Layers

mechanisms can be used to adapt and translate IPv6 datagram More details of application and session layer mechanisms are
into a format that is suitable for transmission over LLNs. introduced in Chap. 5.
Essentially 6LoWPAN gives constrained and low-power de- Figure 4.12 shows both a plain IPv6 stack and 6LoWPAN-
vices native IPv6 support at a cost of minimal overhead. based stack. There are several differences; (1) each stack has,
This IPv6 support, of course, enables connectivity to other as expected, different physical and link layer protocols, (2)
Internet-based hosts and routers. Although 6LoWPAN was IPv6 cannot run directly over IEEE 802.15.4 as 6LoWPAN
originally designed to provide full IPv6 support under IEEE adaptation is needed, (3) TCP cannot be used over 6LoWPAN
802.15.4, many of its features have been adopted by other due to performance issues, and (4) CoAP over UDP, as
physical and link layer technologies like BLE and ITU-T opposed to HTTP over TCP, is used on the 6LoWPAN-
G.9959. In fact, the term 6LoWPAN network typically refers based stack. Note that the 6LoWPAN-based stack has the
to an LLN that relies on 6LoWPAN principles. 6LoWPAN adaptation layer placed in between the IPv6 and
The 6LoWPAN architecture, shown in Fig. 4.11, is in- the IEEE 802.15.4 link layers. Also note that in many im-
tegrated by several WPANs that are characterized by being plementations, UDP and IPv6 layers are integrated directly
access stub networks with traffic that is never transmitted to into 6LoWPAN with APIs that interface with network and
other networks. All devices in a WPAN have IPv6 addresses transport parameters. Because of this, 6LoWPAN adaptation
that share the same prefix usually retrieved through RA is typically shown as part of the IPv6 layer.
ND messages. There are three types of WPANs: (1) simple Figure 4.13 shows a basic translation between an Ethernet
WPANs that have connectivity to the IP core by means of wireline core and an IoT IEEE 802.15.4 wireless access
edge routers, (2) ad hoc WPANs that locally connect devices that usually occurs at an WPAN edge router. Incoming IPv6
and have no access to the IP core, and (3) extended WPANs traffic from the core, on the Ethernet interface, is encoded
that have connectivity to the IP code by means of several edge as 6LoWPAN datagrams before being transmitted over the
routers along a backbone link. IEEE 802.15.4 interface. Similarly, incoming 6LoWPAN
An edge router resides in between the access and core traffic on the IEEE 802.15.4 interface is decoded as IPv6
networks and plays the role of a traditional IoT gateway. datagrams before transmitted over the Ethernet interface.
It handles traffic in and out of the WPAN by performing Note that this bidirectional translation is quite efficient, and
6LoWPAN adaptation, ND for interaction with devices on depending on the 6LoWPAN compression scheme, it can be
the same link, and other types of operations like IPv4-to- either stateless or stateful. More details of the 6LoWPAN
IPv6 translations for communication with other entities in compression mechanisms are discussed later in this chapter.
the IP core. Devices in a WPAN can behave like either hosts Although 6LoWPAN is intended to work over IEEE
or routers depending on source and destination addresses of 802.15.4, it can work over other link layer technologies with
the datagrams. A sensor can act as a host when it generates some small modifications. Specifically, 6LoWPAN requires
readouts, and it can act as a router when it forwards traffic that link layer protocols support framing, presented in Sect. 3,
from other devices in a mesh scenario. Most devices only unicast transmission, and unique addresses that can be used,
have a single interface (i.e. wireless) that is used to receive in turn, to derive unique IPv6 addresses by means of SAA.
and transmit datagrams. This is even true when the devices In addition, because IPv6 fragments cannot be smaller than
play the role of routers and forward datagrams on the same 1280 bytes, 6LoWPAN performs its own fragmentation to
interface in which they were received as a mechanism to adapt datagram transmission to link layer mechanisms with
extend coverage. Note that this is quite different to what small MTUs.
traditional Internet routers do, where traffic received on one It is therefore desirable for link layer frames to be as large
interface is forwarded to a different one. as possible with payloads of at least 60 bytes to minimize
Access to core communication in the context of WPANs the number of fragments that 6LoWPAN needs to track.
follows the standard rules of any other IP communication. Moreover, for fixed network packet loss, it is always good
Each WPAN device is identified by its unique IPv6 address, to minimize the number of fragments per datagram since the
and it can send and receive datagrams. As processing capabil- more fragments the higher the probability that a datagram
ities are limited in constrained devices, the type of transport will get dropped by the network. Note that 6LoWPAN com-
and application traffic is also limited. While protocols like pression can be used to efficiently compress IPv6 and UDP
UDP are suitable in this situation, TCP and HTTP [1] fail headers in order to maximize link layer payload size and
due to computational complexity and excessive resource con- therefore minimize the number of fragments per datagram. In
sumption; TCP relies on sophisticated state machines, while the context of other link layers, it is also important, although
HTTP imposes high memory requirements due to the size not required, that the adaptation layer provides reliability by
of its messages. This means that although TCP and HTTP means of error detection and correction. Additionally, the
can be used in WPANs, this is not typically recommended. adaptation layer must support security through encryption
and authentication.
4.3 6LoWPAN 83

Fig. 4.11 6LoWPAN

architecture
remote application

internet core

router
local application
router
backhaul link backbone link

edge router edge router

edge router
R R
R R R R
R R

H H H
H H H
H
H

extended WPAN
simple WPAN
H
R router
R
R R H host

H H
H

ad-hoc WPAN

Fig. 4.12 6LoWPAN stack IPv6 Stack 6LoWPAN Stack

HTTP application CoAP
TCP UDP ICMP transport UDP ICMP
IPv6
IPv6 network 6LoWPAN
ETHERNET link IEEE 802.15.4
ETHERNET physical IEEE 802.15.4
84 4 Network and Transport Layers

Fig. 4.13 6LoWPAN translation

IPv6
6LoWPAN

Ethernet LINK IEEE 802.15.4 LINK

Ethernet PHY IEEE 802.15.4 PHY

CORE ACCESS

4.3.1 Addresses
remote server
2001:10::2105
6LoWPAN relies on IPv6 addresses that consist of a prefix
and an IID that are derived via SAA from link layer addresses
and edge router parameters received in 6LoWPAN ND RA
messages. 6LoWPAN ND messages are ICMPv6 ND mes- IPv6 CORE
sages that are exchanged in the context of 6LoWPAN and 2001:10::/64
have been optimized to work in WPANs as per IETF RFC
6775. As opposed to traditional ND, 6LoWPAN ND supports edge router
power duty cycles, and it can handle sleeping devices and
to minimize the use of multicast addressing. The mapping ::1
is essential in enabling 6LoWPAN IPv6 header compression
as most of the 128-bit source and destination addresses can
::2
be obtained from well-known information that does not need ::3
to be transmitted in every single datagram. Note that most
link layer IoT technologies like IEEE 802.15.4 support 64- ::6
::4 ::5
bit MAC addresses and configurable, 8-bit or 16-bit short
addresses typically assigned by the PAN coordinator. In the
context of 6LoWPAN, either one of these types of addresses 6LoWPAN ACCESS
can be used to form the 64-bit IIDs. 2001:11::/64
As mentioned in Sect. 2.3, IoT devices are intended to be
deployed, provisioned, and configured with minimal (and if Fig. 4.14 6LoWPAN example
possible, without) human intervention. This has to do with
the volume of sensors and actuators as well as the remote prefix 2001:11::/64. The access network is composed of five
nature of many of the locations where they are deployed. devices that interface with an edge router. These devices
Initial bootstrapping is performed by the link layer that can behave like routers or hosts depending on their location
besides assigning a link local address, attempts to obtain a and their traffic processing capabilities. This is because end
unicast globally routable address by means of SAA. In this devices do not have direct connectivity to the edge router and
scenario, the 6LoWPAN edge router exchanges 6LoWPAN rely on mesh routing to reach it. The edge router, in turn,
ND messages that not only support SAA but also enable connects to the core network and can access a server running
it to keep track of all devices in the link. Specifically, the on 2001:10::2105.
edge router creates a registry of devices and assigns simpler Bootstrapping starts when the edge router begins to ad-
IPv6 addresses that have the overall effect of simplifying the vertise the 2001:11::/64 prefix to the devices by means of
network operation. 6LoWPAN ND RA messages. The devices use this prefix and
Figure 4.14 shows an end-to-end IP network that com- their own IID derived from the 64-bit IEEE 802.15.4 MAC
bines a traditional IPv6 core with an 6LoWPAN access. The address to generate IPv6 addresses. This is further simplified
IPv6 core network is associated with the prefix 2001:10::/64, when devices, also relying on 6LoWPAN ND, register with
while the 6LoWPAN access network is associated with the
4.3 6LoWPAN 85

the edge router and receive a 16-bit IID that is combined As already stated, if a 128-bit destination address is from a
with the prefix to generate a less complex IPv6 address. device in the same WPAN, it can be compressed as a 16-bit
The edge router assigns its own access interface to ad- address. This would be a case of stateless compression since
dress 2001:11::1 and randomly assigns addresses 2001:11::2 each address is mapped based on the 128-bit address con-
through 2001:11::6 to the devices. This opens the door for tained in that datagram. If stateful compression were in place,
6LoWPAN compression since it is a lot more efficient to then the 128-bit address that is common to all datagrams
encode a 16-bit address than a 64-bit IID. Moreover, for would be associated with a context identifier, and it would not
traffic within the WPAN, datagrams only need to specify the need to be transmitted. This, of course, requires coordination
16-bit source and destination addresses since the network between transmitter and receiver. Usually, 6LoWPAN ND
prefix is well-known to all devices (i.e. traffic from ::4 to provides some mechanisms for context information dissemi-
::6). For datagrams going from one device to its closest nation.
neighbor, there is no need to include any IPv6 address since Both IPv4 and IPv6 work well with fast link layer pro-
their IEEE 802.15.4 MAC addresses provide all the routing tocols like Ethernet and IEEE 802.3 that natively support
information needed (i.e. traffic from ::5 to ::3). In other many of the regular IP requirements including the support of
words, if an 6LoWPAN stack finds a header that has neither large MTU sizes and multicast addresses. In those scenarios,
source nor destination address, it assumes that the traffic is there is no need for any adaptation mechanism. Other more
within neighbors. When datagrams flow from one device constrained link layer standards like IEEE 802.15.4 support
to the external server, the datagram includes a source 16- very small MTU sizes and do not allow multicast addressing
bit address (i.e. ::4) and the destination 128-bit address (i.e. due to restrictions linked to low transmission rates and low-
2001:10::2105). The edge router looks at its registry and power consumption. As many times mentioned, 6LoWPAN
converts the 16-bit address into the corresponding global provides an adaptation mechanism that overcomes these and
128-bit unicast address of the device before forwarding the other problems.
datagram to destination. In general, the edge router performs One of these problems is because link layer power limita-
any type of header compression and decompression in the tions also prevent devices from directly communicating with
process of translating network and transport layers back and other devices on the same link. In many cases, a device relies
forth. on intermediate devices to transmit frames to the destination.
This mesh topology requires additional information like orig-
inal and final MAC addresses that can be inserted by means of
4.3.2 Header Format 6LoWPAN adaptation. Another problem is that because link
layer protocols like IEEE 802.15.4 were designed to work
The 6LoWPAN layer maps fields of IPv6 and upper within proprietary stacks, they do not include a type field
layer headers into their compressed versions that become that can be used to identify the upper layer datagram. This
the 6LoWPAN header. This compression can be either is, again, a big difference when compared to fast link layer
stateless or stateful depending on whether the compressed protocols like Ethernet. Specifically, Ethernet includes the
information embedded in the datagram is enough to recover ethertype field to indicate if the upper layer is, for example,
the original IPv6 and transport layer headers. To be IPv4, IPv6, or ARP. 6LoWPAN introduces a special scheme
specific, Fig. 4.15 shows the difference between stateless to solve this issue. This scheme together with fragmentation
and stateful compressions. Under stateless compression, and header compression provides the most important features
6LoWPAN compresses each datagram header based on of 6LoWPAN.
intra-datagram redundancy alone. On the other hand, under To address the lack of a link layer type field, 6LoWPAN
stateful compression, 6LoWPAN compresses each datagram starts every datagram with an 8-bit field named dispatch value
header based on both intra- and inter-datagram redundancy. that serves as the datagram type indicator [18]. Although
Stateless compression is simple, and, as opposed to stateful the dispatch value is 8 bits long, most of the time only a
compression, it does not require a mechanism to keep track few of the most significant bits are used to indicate the type,
of the state of inter-datagram redundancy. Unfortunately, while the remaining bits are used to signal additional header
simplicity comes to a price of lower compression rates. information. Table 4.3 shows the dispatch values that are
Stateful compression relies on associating redundant used to assign the different types of 6LoWPAN headers;
information in uncompressed IPv6 headers with a context for example, a dispatch value starting with 10 indicates a
identifier that is transmitted in the datagrams instead. mesh header, while one starting with 01000001 specifies
Consequently, stateful compression requires coordination to an uncompressed IPv6 header. Note that a dispatch value
make sure that contexts are always correctly synchronized. 01000000 is used to indicate that the dispatch value extends
In most cases IPv6 addresses are not included in 6LoW- beyond one byte. All other dispatch values not shown in the
PAN headers because they can be derived one way or another. table are reserved values.
86 4 Network and Transport Layers

Fig. 4.15 Stateless vs stateful STATELESS COMPRESSION STATEFUL COMPRESSION

compression

6LoWPAN

6LoWPAN
OUTPUT OUTPUT

inter-datagram redundancy intra-datagram redundancy

Table 4.3 Dispatch values Pattern Header type Order

00 Not a LoWPAN frame (NALP)
01 000001 Uncompressed IPv6 4th
000010 HC1 stateless compression
010000 BC0 broadcast 2nd
1 IPHC stateful compression 4th
111111 Extension Escape (ESC)
10 MESH header 1st
11 000 FRAG1 initial fragment 3rd
100 FRAGN subsequent fragments
1010 RFRAG recovery fragments

Fig. 4.16 Uncompressed IPv6 0 8 12 20

header
01000001 VERSION TRAFFIC FLOW LABEL

FLOW LABEL PAYLOAD LENGTH NEXT HEADER

HOP LIMIT

SOURCE ADDRESS

DESTINATION ADDRESS
4.3 6LoWPAN 87

Figure 4.16 shows an IPv6 header that is transmitted a total of 48 bytes that can be found on every single datagram
uncompressed by means of 6LoWPAN by pre-appending regardless of the values of the fields. Figure 4.18, on the
a 01000001 dispatch value. Note that most IPv6 header other hand, shows the maximum compression that can be
fields are placed within a 32-bit boundary that makes them achieved when adapting the same headers with 6LoWPAN.
accessible by means of a single clock transition in 32-bit The 6-byte 6LoWPAN header starts with a 2-byte stateful IP
and 64-bit processors. The extra 8-bit dispatch value disrupts Header Compression (IPHC) dispatch value and associated
the 32-bit boundary of some fields like the flow label and compressed fields. It follows a 1-byte Next Header Compres-
forces an extra clock transition that lowers processing speed. sion (NHC) UDP compressed header that includes a 1-byte
Fortunately, many embedded IoT devices rely on 8-bit and field to identify both source and destination UDP ports. Note
16-bit processors that are less affected by this displacement. that uncompressed UDP ports are always 2 bytes long. The
Note that the 6LoWPAN uncompressed header can be also 6LoWPAN header ends with the 2-byte UDP checksum field
used to transmit IPv4 datagrams and other types of packets. that is transmitted in-line and therefore uncompressed. The
In this case, 6LoWPAN provides fragmentation that enables overall compression rate is 6–48 or 1–6.
the end-to-end transmission of full IPv4 stacks over IEEE
802.15.4. Essentially, the gateway only transforms physical
and link layers and preserves all the upper layers. Of course, 4.3.3 Routing and Forwarding
the drawback is the fact that because IPv4 datagrams are not
compressed, they are inefficiently transmitted. One of the roles of a network layer is to move datagrams
Note that multiple dispatch values and headers can be from a sending to a receiving device. Two main functions are
encoded in a single datagram based on the order given in identified: (1) forwarding that involves moving a datagram
Table 4.3. For example, if a datagram is compressed and then from an incoming to an outgoing link in a device or router
fragmented, the fragmentation dispatch value and header and (2) routing* that involves determining a route or path that
must go before the compression dispatch value and header datagrams must follow from source to destination. Routing is
since a given fragment cannot be decompressed until it is a network wide decision that results from executing a routing
properly reassembled. Essentially, the order of the different algorithm that defines a forwarding information base (FIB).
6LoWPAN headers enables synchronization between the en- Forwarding, in turn, is a device decision derived from the
coder and decoder when many of them are included in a FIB.
single datagram. The first header must be, if present, the mesh Figure 4.19 shows how encapsulation works under tra-
header that carries the original and final MAC addresses ditional IPv6 routing. A router device with a FIB has two
along with a hop count. It follows, if present, the broadcasting interfaces on two different links associated with two different
header that contains hop-by-hop link layer information. The subnets, 2001:10::/64 and 2001:11::/64. A frame received on
third header is, if present, the fragmentation header in order interface 0 is processed and, based on the destination IPv6
to support transmission of datagrams larger than the link address found in the FIB, is forwarded to the outgoing inter-
layer MTU size. The packet ends with the uncompressed or face 1. Figure 4.20 shows a datagram being sent from device
compressed network/transport layer header if present. Note 1 at address 2001:10::10 to device 2 at address 2001:11::10.
that this order is consistent with the order of plain headers in First, device 1 looks at its FIB table to determine that in
regular IPv6 datagrams. order to reach 2001:11::10, it must first send the datagram
6LoWPAN relies on the dispatch value to specify the to the router on interface 0 at address 2001:10::1. Then
different headers, while IPv6 relies on the next header field device 1 looks in its ND table to find out the MAC address
to do the same. Moreover, after the dispatch value, the corresponding to IPv6 address 2001:10::1. The resulting
6LoWPAN protocol adds the compressed fields associated 11:22:33:44:55:66 MAC address is used as a destination
with the header and then continues with the uncompressed link layer address for the datagram sent by device 1. The
fields that are directly copied from the IPv6 header. These router receives the datagram, and it looks at its FIB table
uncompressed fields are known as in-line because they are to determine that the datagram must be sent directly over
sent in-line after the compressed fields. Examples of in- interface 1 to reach destination IPv6 address 2001:11::10.
line fields include IPv6 addresses associated with external The router looks at its ND table to obtain the MAC address
hosts that cannot be easily compressed based on context and corresponding to IPv6 address 2001:11::10. The resulting
implied information. 11:12:13:14:15:16 MAC address is used as a destination link
To understand how compression works under 6LoWPAN, layer address for the datagram sent by the router.
it is interesting to look at a simple example. Figure 4.17 When 6LoWPAN is in place, communication between
shows the headers that are used when application traffic is devices is by means of capillary networking where devices
encapsulated by means of UDP over IPv6. The UDP and IPv6 acting as routers have only one interface. Datagrams enter
headers are 8 and 40 bytes long, respectively, accounting for the router and leave the router on the same interface. In this
88 4 Network and Transport Layers

Fig. 4.17 UDP over IPv6 0 4 12 16 24

VERSION TRAFFIC CLASS FLOW LABEL

PAYLOAD LENGTH NEXT HEADER HOP LIMIT

SOURCE ADDRESS

DESTINATION ADDRESS

IPv6

SOURCE PORT DESTINATION PORT UDP

LENGTH UDP CHECKSUM

Fig. 4.18 UDP over IPv6 over 0 16 24 28

6LoWPAN
IPHC DISPATCH + COMPRESSED FIELDS NHC COM’SSED FIELDS SRC PORT DST PORT

UDP CHECKSUM

Fig. 4.19 IPv6 encapsulation

FIB

application application

UDP UDP

IPv6 IPv6 IPv6

link link link link

physical physical physical physical

interface 0 interface 1
2001:10::/64 2001:11::/64
4.3 6LoWPAN 89

Fig. 4.20 IPv6 routing L3: ip address s: source address

L2: mac address d: destination address

router
dev 1 dev 2
L3: 2001:10::10 L3: 2001:10::1 L3: 2001:11::1 L3: 2001:11::10
L2: 01:02:03:04:05:06 L2: 11:22:33:44:55:66 L2: 11:21:31:41:51:61 L2: 11:12:13:14:15:16

Interface 0 Interface 0 interface 1

destination next hop if destination next hop if

2001:11::/64 2001:10::1 0 2001:11::/64 1
2001:10::/64 0 2001:10::/64 0
FIB FIB

L3 L2
2001:10::10 01:02:03:04:05:06
L3 L2 2001:10::1 11:22:33:44:55:66
2001:10::10 01:02:03:04:05:06 2001:11::1 11:21:31:41:51:61
2001:10::1 11:22:33:44:55:66 2001:11:10 11:12:13:14:15:16
ND ND

s: 2001:10::10 s: 2001:10::10
network
d: 2001:11::10 d: 2001:11::10
s: 01:02:03:04:05:06 s: 11:21:31:41:51:61
link
d: 11:22:33:44:55:66 d: 11:12:13:14:15:16

Fig. 4.21 6LoWPAN route-over

FIB

application application

UDP UDP

IPv6 IPv6 IPv6

6LoWPAN 6LoWPAN 6LoWPAN

link link link

physical physical physical

interface 0
2001:10::/64
90 4 Network and Transport Layers

Fig. 4.22 6LoWPAN route-over L3: ip address s: source address

encapsulation L2: mac address d: destination address

router
dev 1 dev 2
L3: 2001:10::10 L3: 2001:10::1 L3: 2001:10::20
L2: 01:02:03:04:05:06:07:08 L2: 11:22:33:44:55:66:77:88 L2: 11:12:13:14:15:16:17:18

Interface 0 Interface 0

destination next hop if destination next hop if

2001:10::20 2001:10::1 0 2001:10::20 0
2001:10::/64 0 2001:10::10 0
FIB FIB

L3 L2
L3 L2 2001:10::10 01:02:03:04:05:06:07:08
2001:10::10 01:02:03:04:05:06:07:08 2001:10::1 11:22:33:44:55:66:77:88
2001:10::1 11:22:33:44:55:66:77:88 2001:10::20 11:12:13:14:15:16:17:18

ND ND

ND
s: 2001:10::10 s: 2001:10::10
network
d: 2001:10::20 d: 2001:10::20
s: 01:02:03:04:05:06:07:08 s: 11:22:33:44:55:66:77:88
link
d: 11:22:33:44:55:66:77:88 d: 11:12:13:14:15:16:17:18

scenario, not all devices on a single link can talk to each end-to-end support. In the context of IEEE 802.15.4, mesh
due to the power limitations that prevent long-distance radio forwarding is introduced as part of IEEE 802.15.5. Link layer
transmissions. Figure 4.21 illustrates how IPv6 routing can be mesh forwarding is invisible to both 6LoWPAN and IPv6.
implemented in this case. Essentially, the 6LoWPAN layer Figure 4.24 shows how to bring mesh forwarding to the
just decompresses IPv6 addresses that are used for routing. 6LoWPAN adaptation layer. This approach is also called
Since routing occurs above 6LoWPAN, it is called route- mesh-under. In this case, 6LoWPAN must keep track of origi-
over. Figure 4.22 shows a datagram being sent from device 1 nal source and destination MAC addresses since the link layer
at address 2001:10::10 to device 2 at address 2001:10::20. keeps tracks of source and destination MAC addresses for
First, device 1 looks at its FIB table to determine that in immediate hop communication. Essentially at every single-
order to reach address 2001:10::20, it must first send the hop source and destination, MAC addresses are overwritten
datagram to the router on interface 0 at address 2001:10::1. at the link layer by means of the original source and des-
The resulting 11:22:33:44:55:66:77:88 MAC address is used tination addresses carried in the 6LoWPAN mesh header.
as destination link layer address for the datagram sent by Knowing source, destination, and original and final MAC
device 1. The router receives the datagram, and it looks at addresses is not only needed for mesh forwarding but also
its FIB table to determine that to reach destination IPv6 for other services provided by 6LoWPAN like fragmentation
address 2001:10::20, the datagram must be directly sent over and reassembly.
interface 0. The router looks at its NB table to obtain the Figure 4.25 shows an example of 6LoWPAN mesh for-
MAC address corresponding to IPv6 address 2001:10::20. warding; frames go from device 1 to device 4 through devices
The resulting 11:12:13:14:15:16:17:18 address is used as a 2 and 3. Each hop shows the frame source, destination, and
destination link layer address for the datagram sent by the original and final MAC addresses.
router. Figure 4.26 shows a 6LoWPAN mesh header. The header
The alternative to route-over routing is to rely on the defines two 1-bit fields, O and F that, respectively, indicate
link layer to perform multi-hop frame mesh forwarding and whether the original and final MAC address is 16-bit PAN co-
enable local link connectivity. This is shown in Fig. 4.23 ordinator assigned or 64-bit based. The header also includes
where the link layer not only keeps track of source and des- a hops left field that indicates how many times the packet
tination MAC addresses for immediate hop communication can be forwarded before it is dropped by the network. As the
but also original source and destination MAC addresses for datagram traverses a network, and it is forwarded by different
4.3 6LoWPAN 91

Fig. 4.23 Link layer mesh

forwarding
FIB

application application

UDP UDP

IPv6 IPv6 IPv6

6LoWPAN 6LoWPAN 6LoWPAN

link link link

physical physical physical

interface 0
2001:10::/64

Fig. 4.24 6LoWPAN mesh

forwarding
FIB

application application

UDP UDP

IPv6 IPv6 IPv6

6LoWPAN 6LoWPAN 6LoWPAN

link link link

physical physical physical

interface 0
2001:10::/64

1 2 3 4

00:01:02:03:04:05:06:07 00:10:20:30:40:50:60:70 00:12:23:45:56:67:78:89 00:11:22:33:44:55:66:77

S: 00:01:02:03:04:05:06:07 S: 00:10:20:30:40:50:60:70 S: 00:12:23:45:56:67:78:89

D: 00:10:20:30:40:50:60:70 D: 00:12:23:45:56:67:78:89 D: 00:11:22:33:44:55:66:77
O: 00:01:02:03:04:05:06:07 O: 00:01:02:03:04:05:06:07 O: 00:01:02:03:04:05:06:07
F: 00:11:22:33:44:55:66:77 F: 00:11:22:33:44:55:66:77 F: 00:11:22:33:44:55:66:77

S: SOURCE MAC ADDRESS

D: DESTINATION MAC ADDRESS
O: ORIGINAL MAC ADDRESS
F: FINAL MAC ADDRESS

Fig. 4.25 6LoWPAN mesh forwarding example

Fig. 4.26 Mesh header 0 23 4 8 16

1 0 O F HOPS LEFT ORIGINATOR ADDRESS, FINAL ADDRESS …

DISPATCH

10 O F 1111 HOPS LEFT ORIGINATOR ADDRESS, FINAL ADDRESS …

DISPATCH
92 4 Network and Transport Layers

devices acting as routers, this counter is decremented. In one fore forwarding datagrams. Consequently, 6LoWPAN header
version of the header, if the number of hops left is 14 or less, compression is usually performed on a hop-by-hop basis.
then it is encoded as a 4-bit field, while in another version, if Using traditional lossless data compression algorithms
the number of hops is larger than 15, then it is encoded as a like Lempel-Ziv for header compression is highly inefficient
4-bit 15 field followed by the actually 8-bit hop count. Note as those mechanisms rely on the formation and use of dic-
that these two different versions of the header can be used tionaries. Keeping track of dictionaries at both sender and
together in order to improve compression by maximizing the receiver is very complex and that does not scale well to
available header space. compress small amounts of data. Using traditional header
Since the mesh header carries all information needed for compression frameworks like Robust Header Compression
forwarding, it is the very first header included in a 6LoWPAN (ROHC), standardized by IETF through several RFCs, is
datagram. One of the requirements to support IPv6 is to not convenient either not only because of its computational
provide a single broadcast domain where all transmissions complexity that is not feasible in constrained devices but
are transitive throughout the network such that if device 1 also because of the additional traffic overhead that would
can send datagrams to 2 and device 2 can send datagrams overwhelm any LLN.
to 3, then device 1 can send datagrams to 3. Essentially any As already stated, 6LoWPAN introduces a simple stateless
interface can reach any other interface in the network by header compression scheme that relies on removing and
sending a single datagram. compressing all information that can be inferred from the
6LoWPAN enables the emulation of a single domain datagram. This implies the removal of irrelevant fields as well
within an 6LoWPAN network by relying on mesh-under. as the compression of addresses that can be derived from
Essentially the multi-hop topology is abstracted from IPv6 link layer MAC addresses. Alternatively, 6LoWPAN sup-
to make devices appear as fully connected and only one-hop ports context-based stateful header compression that relies
away. The mesh-under architecture defines the extent of an on information that can be inferred from a context related to
IPv6 link as all devices inside the same mesh, while the route- a flow of datagrams between two devices. This addresses the
over architecture puts routing and forwarding at the network compression of global unicast IPv6 addresses that by being
layer and defines the extent of an IPv6 link as immediate associated with a context, they do not need to be included in
devices that can be reached within a single hop. The mesh- every single IPv6 header.
under approach relies on routing functions at the link layer to
emulate a single broadcast domain where all devices appear 4.3.4.1 Stateless Compression
directly connected to each other at the network layer. In 6LoWPAN stateless compression is supported by means of
opposition, the route-over approach puts all routing functions the Header Compression 1 (HC1) header that is used to
at the network layer. compress IPv6 headers [18]. Together with the HC1 header
it is possible to include an additional Header Compression
2 (HC2) header that is used to compress some transport
4.3.4 Header Compression layer headers like UDP. The dispatch value LOWPAN_HC1
(01000010) is used to signal the presence of the HC1 header,
Constrained devices are subjected to channel access con- and within this header an additional flag is used to indicate
tention that limits for how long they can transmit. This to- that the HC2 header follows the HC1 header. Note that HC1
gether with power constraints that lower maximum transmis- and HC2 stateless compression headers have been super-
sion rates put restrictions on payload size of link layer frames. seded by the stateful compression mechanisms presented in
Because for efficiency the ratio between the sizes of headers Sect. 4.3.4.2 that support both stateful and stateless com-
and payloads must be kept low, header compression is critical pression. Having said this, however, it is still important to
in the context of 6LoWPAN. Although fragmentation can be understand how the original stateless compression scheme of
used to accommodate big payloads into multiple frames, it 6LoWPAN works.
is always preferable to minimize its use due to the negative Figures 4.27 and 4.28 show, respectively, the header for-
effect of network packet loss in fragmented datagrams. mat when HC1 is used alone and when HC1 is used in
6LoWPAN header compression can therefore take advan- combination with HC2. The difference resides in the use of
tage of the high degree of redundancy that exists in IPv6 the next header bit to indicate the presence of the HC2 header.
header fields including 128-bit addresses. Moreover, since After the dispatch value, the HC1 header includes two 2-bit
compression affects all layers above the link layer, each fields that specify the Source Address Encoding (SAE) and
device performing routing between original and final devices the Destination Address Encoding (DAE). Because encoding
must be able to do both (1) decompress IPv6 headers before is stateless, IPv6 addresses must be derived from information
making routing decisions and (2) compress IPv6 headers be- present in the frame. Moreover, whatever information cannot
4.3 6LoWPAN 93

Fig. 4.27 HC1 alone 0 8 10 12 13 15 16

01000010 SAE DAE C NH N in-line fields

dispatch HC1
SAE source address encoding
DAE destination address encoding
C traffic class and flow label encoding
NH next header type (if N= 1)
N=0 next header doesn’t follow

Fig. 4.28 HC1 with HC2 0 8 10 12 13 15 16 17 18 19 24

01000010 SAE DAE C NH N S D L PAD in-line fields

dispatch HC1 HC2 (N = 1)

SAE source address encoding

DAE destination address encoding
C traffic class and flow label encoding
NH next header type (if N = 1)
N=1 next header follows
S source port compression
D destination port compression
L datagram length compression
PAD padding

Table 4.4 HC1 address encoding transmitted in-line. Note that non-compressed in-line fields
SAE/DAE value 64-bit prefix 64-bit IID are transmitted in the order in which they appear in the
00 In-line In-line original IPv6 header.
01 In-line Derived HC2 that compresses the UDP header starts with two 1-bit
10 Link-local In-line fields that indicate, when set, that source and destination ports
11 Link-local Derived are compressed. If not set, the corresponding ports are sent in-
line. When compressed, ports are encoded by the four least
Table 4.5 HC1 next header significant bits of the port range between 61616 and 61631.
Value Meaning The following field specifies if the UDP payload length is
00 In-line removed from the header and inferred from the frame or
01 UDP transmitted in-line. The UDP checksum is transmitted in-
10 ICMP line. Figure 4.29 shows an example of a combination of HC1
11 TCP and HC2 headers when encoding UDP over IPv6 relying on
link-local addresses. Note that the resulting headers are about
56 bits long.
be derived from the frame, it must be sent in-line after the
compressed headers.  6LoWPAN Implementations There are many commer-
Table 4.4 illustrates the different possible values for DAE cial and open source 6LoWPAN implementations with
and SAE. The network prefix is either transmitted in-line support ranging from common constrained RTOS to
or assumed to be link-local as FE80::/64. Similarly, the IID general purpose Linux distributions. The list below
is either transmitted in-line or derived from the link layer shows the most popular open platforms that support
addresses. The 6LoWPAN header then includes a bit that is IEEE 802.15.4.
used to flag whether the traffic class and flow label fields are
transmitted or not. Specifically, the IPv6 8-byte traffic control
and 20-byte flow label are rarely used, so they can be re- Contiki Supported by means of the well-known open
moved from the header when this bit is set. If this bit is not set, source LwIP protocol stack.
TinyOS Supported by means of the Berkeley Low
then the traffic control and flow label are transmitted in-line.
Power IP (BLIP) protocol stack.
The IPv6 next header field is compressed right after as
OpenWSN Natively supported by the OS.
a 2-bit value in accordance with Table 4.5. As previously
Zephyr Natively supported by the OS.
stated, the last bit of the HC1 header specifies whether an Mbed Natively supported by the OS.
HC2 header follows. Note that IPv6 fields like version and Linux Kernel modules available for specific hard-
payload length are not transmitted since they can be inferred ware.
from the packet itself. The IPv6 8-bit hop limit is always
94 4 Network and Transport Layers

0 8 10 12 13 15 16 17 18 19 24 28 32 40

01000010 11 11 1 01 1 1 1 1 0 0 0 0 0 00000001 0000 0001 01011010

dispatch HC1 HC2 (N = 1)
48 56

01111101 PAYLOAD

SAE 11 (link local prefix / derived IID)

DAE 11 (link local prefix / derived IID)
C 1 (no traffic class and flow label)
NH 01 (next header UDP)
N 1 (HC2 header follows)
S 1 (source port compressed)
D 1 (destination port compressed)
L 1 (no datagram length)
PAD 0 0 0 0 0 (padding)
hop limit 0 0 0 0 0 0 0 1 (1)
source port 0 0 0 0 (61616)
destination port 0 0 0 1 (61617)
checksum 0101101001111101

Fig. 4.29 6LoWPAN Datagram HC1/HC2 (link-local addresses)

4.3.4.2 Stateful Compression In general, context-based synchronization problems can be

Stateless compression that is standardized as IETF RFC 4944 detected and prevented by higher-layer protocols like UDP
“Transmission of IPv6 Packets over IEEE 802.15.4 Net- or TCP that calculate checksums based on pseudo headers.
works” has been superseded by stateful compression stan- These headers include several fields including IPv6 source
dardized as IETF RFC 6282 “Compression Format for IPv6 and destination addresses. When the checksum is incorrect,
Datagrams over IEEE 802.15.4-Based Networks” [28]. The these datagrams are dropped and retransmitted when trans-
main difference between stateful and stateless compression is port is TCP based.
that the former addresses some of the limitations of the latter As in the case of stateless compression, stateful com-
by enabling the compression of parameters that are common pression includes the aforementioned IPHC as well as the
to datagrams associated with streams of data generated by optional next header NHC header compression schemes.
devices. Because these common parameters can be thought Figures 4.30 and 4.31, respectively, show the header format
of as part of a context, stateful compression is also known when IPHC is used alone and when IPHC is used in com-
as context-based compression. For example, for a session bination with NHC. Under stateful compression, only three
between a sensor and an external application, all datagrams bits of the 8-bit dispatch value are used to signal the presence
sent by the device carry the same unicast global IPv6 ad- of the IPHC header. The remaining five bits of the dispatch
dresses. If the sensor and the application agree to assign the value are used to encode actual header fields.
destination address to a given context, then compression can The IPHC header starts with a 2-bit TF field that encodes
be accomplished. Specifically, datagrams can carry a context traffic class and flow label as in-line fields as indicated in
identifier that is encoded with a lot fewer bits than those Fig. 4.32. If the field is encoded as 11 traffic class, flow
needed to encode unicast addresses. label are assumed to be all zero. All other values of TF are
The shared context negotiation is not specified by IETF used to encode combinations of the 2-bit Explicit Congestion
RFC 6282, and it is intended to be agreed by means of other Notification (ECN), the 6-bit Differentiated Services Code
mechanisms like ND. When the 6LoWPAN stack of a device Point (DSCP), and the 20-bit flow label. Note that variable
wants to compress traffic based on a context, it needs to make padding is used to make sure that encoding is within an 8-
sure that the destination 6LoWPAN stack context informa- bit boundary. The 1-bit flag N follows to indicate whether an
tion is fully synchronized with that of the sender. Usually, and NHC header is also included. If this bit is not set, it implies
to prevent context synchronization problems due to connec- that the 8-bit IPv6 next header field follows in-line the IPHC
tivity and power cycle limitations, context information is di- header.
vided into multiple slots that can be modified independently. The 2-bit hop limit field, shown in Table 4.6, is used to
specify, by means of variable length coding, the hop limit
of the original IPv6 header. Border routers and gateways
4.3 6LoWPAN 95

Fig. 4.30 IPHC alone 0 1 2 3 5 6 8 9 10 12 13 14 16 20 24

0 1 1 TF N HLM C S SAM M D DAM SCI DCI in-line fields

dispatch IPHC

TF traffic class and flow label encoding

N=0 NHC doesn’t follow
HLM hop limit encoding
C include context information fields
S context based source address encoding
SAM source address mode
M multicast destination address
D context based destination address encoding
DAM destination address mode
SCI source context identifier (if C = 1)
DCI destination context identifier (if C = 1)

0 1 2 3 5 6 8 9 10 12 13 14 16 20 24

0 1 1 TF N HLM C S SAM M D DAM SCI DCI 1 1 1 0 EID X 1 1 1 1 0K P in-line fields

element element
dispatch IPHC NHC

TF traffic class and flow label encoding

N= 1 NHC follows
HLM hop limit encoding
C include context information fields
S context based source address encoding
SAM source address mode
M multicast destination address
D context based destination address encoding
DAM destination address mode
SCI source context identifier (if C = 1)
DCI destination context identifier (if C = 1)
EID IPv6 extension header identifier
X more NHC elements
K UDP checksum removal
P UDP source and destination port encoding

Fig. 4.31 IPHC with NHC

Fig. 4.32 Traffic class encoding TF 0 2 4 8 12 16 24

00 ECN DSCP R FL

01 ECN R FL

10 ECN DSCP

11 NO BITS

TF traffic class and flow label encoding

ECN explicit congestion notification
DSCP differentiated services code point
FL flow label
R reserved field
96 4 Network and Transport Layers

Table 4.6 Hop limit encoding Table 4.9 EID

Value Meaning 000 IPv6 hop-by-hop options
00 1 hop 001 IPv6 routing
01 64 hops 010 IPv6 fragment
10 255 hops 011 IPv6 destination options
11 In-line 100 IPv6 mobility header
111 Nested IPv6 header, IPHC encoded

Table 4.7 Unicast S/SAM and D/DAM Values

Address and destination addresses, respectively. If a NHC header is
Context-based mode In-line bits Meaning present, several 8-bit elements follow. One type of element
0 00 128 Full unicast address
starts with a 1110 sequence and includes a 3-bit Extension
FE80:0:0:0:inline
Identifier (EID) that is mapped as illustrated in Table 4.9. The
(link-local + 64-bit
0 01 64 IID) EID is followed by another 1-bit flag that indicates whether
FE80:0:0:0:0:0:0:inline another element follows.
0 10 16 (link-local + 16-bit IID) Another type of element starts with a 11110 and identifies
FE80:0:0:0:link-layer a UDP header that includes a 1-bit flag that specifies whether
(link-local + link-layer the UDP checksum is to be transmitted or not. If it is not
0 11 0 address)
encoded in-line, it is recalculated on reception by the 6LoW-
Context[0…63]:inline
1 01 64 (context + 64-bit IID)
PAN layer when the IPv6 header is generated. The following
Context[0…111]:inline 2-bit field (P) is used to define how source and destination
1 10 16 (context + 16-bit IID) ports are encoded. This field is encoded in accordance to
Context[0…127] (con- Fig. 4.33. Essentially, the source and destination ports can be
1 11 0 text) sent in-line as 16-bit uncompressed fields or encoded as an 8-
bit field that indicates the offset between 61440 and 61695 or,
Table 4.8 Multicast D/DAM values
just as in the HC2 case, encoded as a 4-bit field that indicates
the offset between 61616 and 61631.
Address
Context-based mode In-line bits Meaning Figure 4.34 shows an example of a combination of IPHC
0 00 128 Full unicast address and NHC headers when encoding UDP over IPv6 relying on
link-local addresses. Note that the resulting headers are about
0 01 48 FFxx::xx..xx 48 bits long, this is one byte less than when HC1 and HC2 are
used instead as shown in Fig. 4.29. In addition, it is possible to
0 10 32 FExx::xx..xx
further reduce two bytes of the NHC header by removing the
0 11 8 FE02::00xx checksum and relying on lower layer protection. On the other
hand, Fig. 4.35 shows an example of a combination of IPHC
1 00 48 FFxx:context[0…31]:xx..xx
and NHC headers with global unicast addresses based on a
default context and 16-bit short addresses that are encoded
in-line instead.
can manipulate this field to improve the compression rate
by mapping certain ranges of hop limits to one of the fixed
values shown in the table.
The 1-bit source context-based encoding flag (S) indicates 4.3.5 Fragmentation
whether the following 2-bit Source Address Mode (SAM) is
context based or not. The following 1-bit flag (M) specifies Link layer MTU sizes are small enough that fragmentation
if the destination address is multicast. Next, a 1-bit destina- is usually required to support the transmission of very large
tion context based encoding flag (D) specifies whether the datagrams. One issue with fragmentation is that network
following 2-bit Destination Address Mode (DAM) is context packet loss gets amplified whenever a fragment gets lost.
based or not. Table 4.7 shows how SAM and DAM fields Specifically, for a datagram to be reassembled correctly, all
are encoded for unicast address support. If the destination fragments must arrive at their destination. The datagram loss
address is multicast, Table 4.8 shows how the combination probability, P , is given by
of the destination address bits encode the address.
When context encoding is set, the 4-bit source and desti- P = 1 − (1 − p)n
nation context identifiers indicate prefix used by the source
4.3 6LoWPAN 97

Fig. 4.33 NHC port encoding P in-line encoding

0 4 8 16 24 32

00 source destination

01 source destination

10 source destination

11 source destination

0 1 2 3 5 6 8 9 10 12 13 14 16 21 22 23 24 28 32 48

0 1 1 11 1 0 1 0 0 1 1 0 0 1 1 11110 0 11 0000 0000 1110110000111100 payload

dispatch IPHC NHC in-line

TF 11 neither traffic class not flow label encoding

N=1 1 NHC follows
HLM 01 hop limit is 64
C 0 no context information
S 0 no context based source address encoding
SAM 11 link layer source address
M 0 unicast destination address
D 0 no context based destination address encoding
DAM 11 link layer destination address
UDP 11110 UDP transport
K 0 transmit checksum in-line
P 11 4-bit source and destination port encoding
source 0000 UDP source port (61440)
destination 0000 UDP destination port (61440)
checksum 11 .. 00 checksum

Fig. 4.34 6LoWPAN datagram IPHC/NHC (link-local addresses)

0 1 2 3 5 6 8 9 10 12 13 14 16 24 40

0 1 1 11 1 0 0 0 1 1 0 0 1 1 0 10101010 0000000000000 010 00000000..

dispatch IPHC in-line

48 56 61 62 64 68 72

...00000100 11110 0 11 0000 0000 1110110011111100 payload

NHC in-line

TF 11 neither traffic class not flow label encoding

N=1 1 NHC follows
HLM 00 hop limit is 1
C 0 use default context
S 1 context based source address encoding
SAM 10 context + 16-bit in-line source address
M 0 unicast destination address
D 1 context based destination address encoding
DAM 10 context + 16-bit in-line destination address
HLM 00000010 hop limit (2)
source address 0000000000000010 16-bit short source address
destination address 0000000000000100 16-bit short destination address
UDP 11110 UDP header follows
source port 0000 source port (61440)
destination port 0000 destination port (61440)
checksum 11 .. 00 checksum

Fig. 4.35 6LoWPAN datagram (global addresses)

98 4 Network and Transport Layers

Fig. 4.36 Fragmentation

problem 1.4

1.2

1 0.15
0.1
P 0.8 0.05

0.03
0.6

p
0.4

0.2

0
20 40 60 80 100
n

where n and p are the total number of fragments and the Figure 4.39 shows an example of 6LoWPAN fragmen-
network packet loss, respectively. tation. A 310-byte chunk of application data is first en-
The datagram loss probability (P ) as a function of the capsulated via UDP and becomes a 318-byte message. The
number of fragments (n) for different levels of network message is then encapsulated via IPv6 and becomes a 358-
packet loss (p) is plotted in Fig. 4.36. Clearly, for a fixed byte datagram. 6LoWPAN compresses both IP and UDP
network packet loss (p), the overall datagram loss probability headers by means of stateful IPHC and NHC headers that
(P ) increases as the number of fragments per datagram end up reducing the overall datagram size to 337 bytes.
increase (n). This implies that the best decision is to avoid Since the maximum IEEE 802.15.4 payload size is 127 bytes
fragmentation whenever possible and, if this is unavoidable, and fragmentation headers are either 4 or 5 bytes long, the
to minimize the total number of fragments per datagram. datagram is fragmented into two 120-byte fragments and one
This is particularly important in the context of IoT where 77-byte fragment. Note that 120-byte fragments are that size
network packet loss is usually a lot higher than in mainstream to preserve the 8-byte offset boundary limitations. With the 4-
networks. byte initial fragment header, the first fragment becomes 124
6LoWPAN fragmentation is carried out by means of two bytes long. With the 5-byte non-initial fragment header, the
headers that identify whether a given fragment is the initial second and third fragments become 125 and 82 bytes long,
one in a datagram. Specifically, the first five bits of the respectively.
dispatch value are either 11100 or 11000 to identify initial
(Fig. 4.37) and non-initial (Fig. 4.38) fragments, respectively.
Both headers include a 11-bit datagram size field that sup- 4.3.6 Security Considerations
ports a length of up to 2048 bytes. The length is followed
by a 16-bit tag that is unique for all fragments of any given Security is paramount in IoT networks, and this is particularly
datagram. For the worst-case scenario, it takes around 4 min true for 6LoWPAN since 6LoWPAN is one of the main
for the tag counter to roll over when transmitting frames at technologies that enables IPv6 communications in LLNs.
IEEE 802.15.4 rates. For non-initial fragments, it follows an Moreover, since 6LoWPAN compresses information in net-
8-bit offset field that indicates the fragment offset in units of work and transmission layers, it is in a key position to provide
eight bytes. The restriction of making the offset a multiple of encryption and authentication. As stated in Sect. 3.3.3.2,
eight has the advantage of decreasing the field size by three the end-to-end principle states that providing security at
bits. Note that as opposed to IPv4, the datagram size is in- higher layers is always more efficient than doing so at lower
cluded in every single fragment so that embedded devices can layers. In the context of 6LoWPAN, this means that placing
allocate a buffer to store the datagram as soon as one fragment encryption and authentication at the UDP layer is probably
is received. The alternative of storing all fragments in maps the best option. In all, the security challenges, requirements,
and queues until the fragment that includes the datagram and threats over 6LoWPAN can be summarized as those
size is received is too resource intensive and computationally presented in Sect. 4.3.6.
complex for constrained devices.
4.3 6LoWPAN 99

Fig. 4.37 6LoWPAN 0 5 8 16 32

fragmentation (initial fragment) 11000 size tag initial fragment
dispatch

Fig. 4.38 6LoWPAN 0 5 8 16 32 40

fragmentation (non-initial 11100 size tag offset fragment
fragment)
dispatch

Fig. 4.39 6LoWPAN 0 310

fragmentation example
application data

0 318

U application data

0 358

I U application data

0 317

IPHC
NHC application data

0 124

FRAG IPHC
1 NHC data

0 125

FRAG
2
data

0 82
U UDP
FRAG
3
data
I IPv6
100 4 Network and Transport Layers

IPH data
Example 4.2 Given the following 53-byte IPv6
datagram: original IP datagram

IPH AH data
I U P
authentication
I IPv6 header (40 bytes)
U UDP header (8 bytes) IPH EH data ET EA
P Payload ( 5 bytes) encryption
Assuming best-case scenario stateful 6LoWPAN
IPH AH EH data ET EA
compression (i.e. smallest possible IPHC and NHC
header sizes), how long does it take to transmit encryption and authentication
the IEEE 802.15.4 frame? Also assume that IEEE IPH IP header
802.15.4 frame headers are a small as possible. How AH Authentication Header
EH Encapsulating Security Payload Header
does it compare to a scenario where uncompressed ET Encapsulating Security Payload Trailer
6LoWPAN is used instead? EA Encapsulating Security Payload Authentication

Fig. 4.40 IPSec/IKE

Solution The best-case scenario of stateful 6LoWPAN
compression consists of an IPHC header that is 3- IPSec includes two headers: (1) Authentication Header
byte long and a NHC header that is 1-byte long. (AH) that provides data integrity, data origin authentication,
The corresponding best-case scenario header size of and protection against replays and (2) Encapsulating Security
IEEE 802.15.4 is 10 bytes long because it included Payload (ESP) that provides confidentiality and ESP pay-
a minimum size 4-byte address field and no security. load authentication. IPSec supports two modes of operation,
Because the best-case scenario transmission rate of transport mode used in node-to-node operations where rout-
IEEE 802.15.4 is R = 250 Kbps, the frame trans- ing is not changed and tunnel mode used in encapsulation
mission takes T = RL = 608 µs where L = 8 × scenarios of Virtual Private Networks (VPNs).
(3 + 1 + 5 + 10) = 152 bits. Under uncompressed Figure 4.40 shows an example of transport mode including
6LoWPAN, the 1-byte dispatch is added to the data- an IP datagram, its authentication by means of AH, its
gram, therefore L = 8 × (53 + 1 + 10) = 512 bits encryption by means of ESP and authentication, as well
and T = RL = 2.048 ms. Essentially, by relying as encryption when combining both AH and ESP headers.
on stateful compression, the transmission time is more Note that ESP encrypts data and provides authentication over
than three times shorter. This also has an effect on the ESP header, trailer, and data. On the other hand, AH
power consumption and battery life preservation. authenticates the whole datagram including the IP header.
Several 6LoWPAN extensions have been proposed to support
the compression of IPSec AH and ESP headers in the context
4.3.6.1 IPSec/IKE of stateful compression as 6LoWPAN_NHC_AH and 6LoW-
One candidate to support security under 6LoWPAN is the PAN_NHC_ESP. There have also been some proposals to
IPSec/Internet Key Exchange (IKE) combo [6, 13]. They adapt IKE to the 6LoWPAN context. In all cases, especially
are well-known network security protocols that are used to when considering IKE, these protocols have a comparatively
establish a secure channel between two mutually authenti- higher overhead than other alternatives. Because of this,
cated nodes. IPSec provides encryption and authentication, IPSec/IKE is not the recommended option for 6LoWPAN
while IKE is used to set security associations (SAs) between security.
entities. Note that IPSec can be used with or without IKE
because the latter is typically used to exchange cryptographic
keys and other security parameters that can be set up relying 4.3.6.2 HIP
on other mechanisms otherwise. IKE is transmitted over UDP Another candidate to provide security in 6LoWPAN is the
as request/response transactions consisting of two stages: (1) Host Identity Protocol* (HIP) that separates the identity of
IKE_SA_INIT that is used to exchange security policies like a host from the location role of its IP address [20]. Based
algorithms and perform a Diffie-Hellman to exchange session on public key infrastructure (PKI) HIP assigns universal
keys for both endpoints to communicate with each other and host identities that exist beyond different addressing domains
(2) IKE_AUTH that is used for mutual node authentication. associated with NAT. Moreover, HIP support for end-to-end
Both endpoints are authenticated, and a simple IPsec child identities simplifies and makes more efficient mobility as
SA is established. well as it ensures that node locations are kept anonymous as
4.3 6LoWPAN 101

INITIATOR RESPONDER 4.3.6.3 DTLS

Datagram Transport Layer Security (DTLS) is a security
mechanism that is based on the well-known TLS protocol.
DTLS was designed to be as robust as TLS and provide
similar security levels [25,23]. As opposed to TLS, however,
Derive KDH, KM

DTLS does not require reliable transport to work. Specif-

ically, DTLS relies on UDP for transport, and it is, there-
fore, more suitable for use in 6LoWPAN and IoT scenarios.
Reliability which is critical in the context of security is
addressed by DTLS by adding (1) loss handling, (2) datagram
reordering, and (3) message size management. Note that

Derive KDH, KM
under TLS, these features are handled by stream-based TCP
transport.
DTLS is made of two layers; (1) the low layer called DTLS
Record Protocol that ensures that connections are private by
means of symmetric encryption and message authentication
codes and (2) the high layer that supports the DTLS Hand-
shake Protocol, the DTLS Change Cipher Spec Protocol,
Fig. 4.41 HIP handshake the DTLS Alert Protocol, and the DTLS Application Data
Protocol. The DTLS Handshake Protocol enables the ne-
gotiation of security parameters. The DTLS Change Cipher
identify is disassociated from IP addresses. HIP also provides
Spec Protocol is used to signal the transitions in ciphering
end-to-end encryption.
strategies and to indicate what records are protected by the
HIP starts with a secure handshake called HIP Base Ex-
negotiated parameters. The DTLS Alert Protocol is used to
change (HIP BEX) that is used to establish the security
terminate a session by indicating an error condition. Finally,
context between an initiator and a responder (Fig. 4.41). As
the DTLS Application Data Protocol ensures that messages
IPSec, HIP information is transmitted directly over the IP
are fragmented and transmitted by the DTLS Record Proto-
layer. As part of HIP-BEX, the initiator starts by transmit-
col.
ting a message I1 that contains the initiator identity HITI
Figure 4.42 shows a DTLS handshake. Each transmission
and the responder identity HITR. The responder replies by
from the client to the server or from the server to the client
transmitting a message R1 that includes a puzzle, its Diffie-
is called a flight. There are two entities: a client that initiates
Hellman public value (DHR ), its host identity (public key
the session and a server that accepts the session establishment
PKR ), and a signature. With the R1 information, the initiator
request. Note that these roles are inherited from TLS and
can derive the Diffie-Hellman public key (KDH ) and the
TCP where a client and servers are essential to establishing
master key (KM ). The initiator then transmits message I2
secure connections. The client starts by sending a Client
that has the puzzle solution, its Diffie-Hellman public value
Hello message that is replied by the server with a Client Hello
(DHI ), its host identity (public key PKI ), and a signature.
Verify that includes a random cookie. These two optional
With the I2 information, the responder can derive the Diffie-
messages are used to protect the server against DoS attacks.
Hellman public key (KDH ) and the master key (KM ). The
The client then resends the Client Hello message but includes
responder then replies by transmitting a message R2 that has
the cookie in order to indicate that it can process messages
a message authentication code computed using the Diffie-
from the server. The Client Hello message signals the pro-
Hellman public key and a signature.
tocol version and cipher suites supported by the client. The
There have been several proposals to reduce the complex-
server then replies by sending a Server Hello message that
ity of HIP in order to make it more suitable for 6LoWPAN
indicates the selected cipher suite from the client’s list and
scenarios. Some approaches like Lightweight HIP (LHIP)
its own ITU-T X.509 certificate. If the server is configured to
reduce complexity by compromising security. Another ap-
support mutual authentication the Server Hello message also
proach known as HIP Diet Exchange (HIP DEX) removes
includes a certificate request. The server ends the transaction
the need of signatures. In all cases, however, HIP overhead is
by transmitting a Server Hello Done message. The client then
too high to consider the protocol as a viable security solution
sends the certificate if requested by the client and the Client
in the context of 6LoWPAN.
Key Exchange message encrypting a master secret using the
102 4 Network and Transport Layers

Fig. 4.42 DTLS handshake client server

optional

encrypted

server’s public key obtained from its certificate. The master networks, with a 127-byte MTU, this is a limiting factor
secret is used by both endpoints to derive encryption and that leads to fragmentation, and, therefore, it increases the
authentication session keys. The client verifies the server’s chances of datagram loss. Essentially a 127-byte MTU yields
certificate against a known Certificate Authority (CA), and, about 70 bytes of payload after authentication and headers
under mutual authentication, the server verifies the client’s are put in place. Fortunately, DTLS addresses this issue by
certificate against a known CA. The client then transmits introducing a new mechanism by which instead of transmit-
a Change Cipher Spec message to indicate all subsequent ting the whole ITU-T X.509 certificate chain, public keys
messages are encrypted. The client transmits a Finished mes- are sent. Once received, the public keys are then validated
sage to indicate the client is done with the DTLS handshake. by endpoints by means of an out-of-band mechanism. DTLS
Similarly, the server transmits its own Change Cipher Spec also introduces handshake level fragmentation that can be
and Finished messages. used to prevent IP fragmentation of handshake messages.
DTLS breaks the data stream into DTLS records, appends Handshake level fragmentation, as opposed to the IP one, has
a MIC to each record for integrity checking, and then en- the advantage of being controlled by the DTLS Application
crypts both the record and the MIC. Figure 4.43 shows a Data Protocol and supports retransmissions at the fragment
DTLS record that consists of type, version, epoch, sequence level. Of course, there is a network overhead associated with
number, and data length fields as well as a data section and the this due to the extra datagrams being transmitted. Regardless,
MIC. Note that the first five fields are not encrypted. The type and as stated before, memory requirements in all scenarios
field indicates whether the record is a handshake message are large, as fragments associated with certificates need to be
or a message that contains application data. The epoch field stored for later reassembly at the receiver.
is a counter value that is incremented on every cipher state Although DTLS provides handshake level fragmentation,
change. The sequence number field is a counter value that is it does not support application data fragmentation. This
incremented with each record. means that for applications to prevent fragmentation, they
In the context of 6LoWPAN networking, DTLS is not must attempt to fit each message and all headers in a single
fully optimal as neither DTLS nor TLS were designed to datagram. There have been several proposals to minimize the
work with constrained networks and devices. One of these DTLS header length in order to increase the space available
issues is the fact that many of the messages exchanged during for message transmission including removing the version
handshaking are very large in nature as they carry certificates field in DTLS record carrying application data since it has
and other security parameters. This requires endpoints to already been negotiated during handshake and removing the
have large buffers to store messages in case they need to be re- length field of the last record in a given datagram since it can
transmitted. Moreover, certificates are typically represented be derived from its length.
by a chain of trust that includes intermediate certificates One way to prevent any type of fragmentation is by
that need to be transmitted along the way. In 6LoWPAN reducing the number of bytes to be transferred so that fewer
4.3 6LoWPAN 103

Fig. 4.43 DTLS record ENCRYPTED

T V E SN L DATA M

T type
V version
E epoch
SN sequence number
L length
M message integrity code

fragments can be potentially lost. One approach to accom- Although a DTLS handshake stage consumes a lot of
plish this is by exchanging, out of band, large chunks of memory due to the buffers required for retransmissions,
data. To this end, the TLS Cached Information Extension is a once a session is established, memory requirements are a
mechanism that enables an endpoint to omit the transmission lot less stringent. In general, a single session must have
of information, such as a certificate, that is already known enough memory to store session keys and sequence num-
to its peer. Another way to reduce the number of trans- bers. This is, in general, used to dimension the number of
mitted bytes is by introducing header compression. There supported DTLS sessions in 6LoWPAN scenarios. With most
have been multiples proposal for DTLS header compression embedded devices and real-time operating systems (RTOSs),
under 6LoWPAN including the use of IETF RFC 7400 that DTLS connections are allocated statically as part of pools
introduces 6LoWPAN-GHC a generic header compression of predefined size. Because of the memory implications of
mechanism under 6LoWPAN [3]. Other proposals include DTLS, determining when a DTLS connection terminates is
transmitting only the least significant bits of the sequence important. DTLS connection closure consists of a closure
number, using self-delimiting fields instead of fixed sized alert that is not retransmitted even if packet loss occurs.
fields as with Huffman coding and using single bit fields This, again, can lead to memory exhaustion due to stale
instead of multiple type fields to encode handshake mes- connections that result from lost alerts in the context of
sages. IETF RFC 7925 that addresses the security profiles lossy 6LoWPAN networks. One way to guarantee that DTLS
under TLS and DTLS for IoT states that compression at the connections are terminated is by keeping track of them such
TLS/DTLS layer is not needed since application-layer proto- that when a device starts running out of resources, the least
cols are highly optimized, and the compression algorithms at frequently used (LFU) connections are removed first. IETF
the DTLS layer increases code size and complexity [29]. RFC 7925 recommends using a mechanism introduced in
Another critical element are timers; DTLS recommends IETF RFC 6520 that introduces a heartbeat mechanism to
that protocol implementations include an initial timer of 1 s verify whether a given DTLS connection is still active [31].
and double the value each time a message is retransmitted Since a single flight is associated with one or more mes-
up to a maximum value of 60 s. In the context of DTLS, sages like Server Hello and Certificate Request in Fig. 4.42,
an initial timer of 1 s may lead to bogus retransmissions several fragments may end up being transmitted. This is
as it may not give enough time for embedded IoT devices aggravated by the fact that many messages are independent
to perform message transmissions. In 6LoWPAN networks, and can be transmitted in parallel. In this case, multiple
therefore, the initial retransmission timer value may need to fragments may simultaneously arrive at the receiver causing
be adjusted depending on hardware requirements. IETF RFC input buffer overflows that could lead to datagram loss. One
7925 recommends an initial timer value of 9 s. way to prevent this is by making sure that the DTLS protocol
The number of handshake messages and their complex- implementation transmits independent messages in a flight
ity have memory implications that can be challenging in sequentially. Another problem with fragmentation is the fact
6LoWPAN networks. When compared to TLS, DTLS is that message integrity check requires the whole record to be
even more complex because it incorporates the initial cookie processed even if it has been corrupted. Additionally, if a
exchange intended to prevent DoS attacks. There have been message is to be retransmitted, the cleartext or unencrypted
several proposals addressing this issue including introducing version of the message must be stored in order to be re-
client puzzles to prevent DoS attacks in a similar way to encrypted with every single retransmission. The idea behind
HIP DEX. Another possibility is for the client to create preserving a cleartext message is to make sure that every
DTLS connections before they are really needed in order to retransmission is different since sequence numbers are dif-
minimize the time it takes to send secure datagrams once they ferent, thus providing replay protection. This also increases
become available. This approach, however, requires servers memory requirements and prevents the implementation from
to be powerful enough to support and maintain multiple implementing in-place encryption. This mechanism consists
simultaneous DTLS sessions.
104 4 Network and Transport Layers

of encrypting data in the same memory space where the

cleartext message is. One way to overcome this issue is (continued)
to modify the implementation to support retransmissions Solution Clearly, around N = 60 bytes
3 bytes
= 20 mes-
with the same sequence number so in-place encryption is sages must be buffered before they can be transmitted.
feasible. Obviously, there are some security implications to The delay of each transmission is given by di =
this. Another way, that may result in slower performance, is to (N − 1 − i) × 20 ms where i = 0, . . . N − 1.
rely on cryptographic algorithms that use a lot less memory. The expected
 −1 di additional delay is, therefore, given by
E = N i=0 N = 1 ms (19 + 18 + 17 . . . + 1 + 0) =
190 ms. Because a sensor readout is transmitted every
4.3.7 TCP and 6LoWPAN 20 ms, it can be assumed that transmissions are uni-
formly distributed.
6LoWPAN HC2 and NHC headers provide ways to compress
an UDP header in a stateless and stateful way, respectively.
Although there have been several attempts to introduce a Another important issue with TCP is that in real-time
compression scheme for TCP under 6LoWPAN, no formal sensing applications, traffic needs to be sent as fast as it
specification exists to this day. TCP is a transport protocol is generated. Through the Nagle’s algorithm, TCP natively
that, as opposed to UDP, provides a connection-oriented buffers packet payloads until it has enough data to make it
service that characterizes for enabling reliable data transfer. efficient to send a datagram. This extra delay affects latency,
In order to accomplish this, TCP relies, when configured ac- and, as stated in the previous paragraph, it can also result in
cordingly, on a Automatic Repeat reQuest (ARQ) mechanism application packet loss. Fortunately, some applications can
with selective acknowledgments. A TCP stack not only re- disable Nagle’s algorithm in their TCP stacks to improve real-
quires computational complexity that is not always available time performance. In either case 6LoWPAN is not intended
in embedded devices, but it also introduces retransmissions to rely on TCP for session management, and therefore its use
that result in additional end-to-end delay. Because LLNs are is only supported as uncompressed traffic.
prone to packet loss, retransmissions are quite common in
the context of IoT. Moreover, retransmissions cause, in many
cases, more problems as they increase the volume of traffic 4.4 6Lo
that, with limited network capacity, results in collisions.
The support of IPv6 over IEEE 802.15.4, by means of
These collisions, in turn, cause more packet loss. By the time
6LoWPAN adaptation, has opened the door for other physical
datagrams arrive at their destination, the application has no
and link layer LLNs technologies like BLE (described
more use for them and ends up dropping them and causing
in Sect. 3.3.4), DECT ULE (described in Sect. 3.3.6),
additional application layer packet loss. Therefore, network
NFC (described in Sect. 3.3.7), IEEE 802.11ah (described
packet loss is amplified by retransmissions that cause an
in Sect. 3.3.1), IEEE 1901.2 (described in Sect. 3.2.3),
increased application layer packet loss.
MS/TP (described in Sect. 3.2.4), and ITU-T G.9959
Another issue of TCP transport is that it assumes that
(described in Sect. 3.3.5) to enable IPv6 connectivity
packet loss is caused by congestion due to intermediate
through their own adaptation schemes. These mechanisms
devices, like routers, dropping packets when their queues are
are comprehensively called 6Lo technologies as they are the
full. IoT packet loss, however, is mostly due to low SNR
focus of standardization of the IETF IPv6 over Networks of
situations where signals are heavily corrupted by noise. For
Resource Constrained Nodes (6Lo) working group [7].
scenarios of low-volume traffic, the TCP approach attempts
These stacks rely on IPv6 adaptation that is either partially
to further decrease the rate as it slows down the transmis-
or fully derived from 6LoWPAN functionality. Specifically,
sion of packets to cope with the congestion. In many of
these technologies modify some of the 6LoWPAN features to
these scenarios, however, it is convenient to rely on very
better fit their physical and link characteristics. Figure 4.44
fast retransmissions that provide a FEC-like mechanism to
illustrates the different LLN families with the proposed and
overcome the loss introduced by the channel.
standardized adaptation mechanisms. The figures indicates
the different topologies associated with each of the tech-
Example 4.3 Consider a sensor that transmits 3-byte
nologies and the corresponding standardized or proposed
readouts every 20 ms directly over a TCP stream
adaptation protocol: plain 6LoWPAN for IEEE 802.15.4,
(no session/application layer protocol). What is the
modified 6LoWPAN for ITU-T G.9959 [4], LoBAC for
expected additional delay due to the Nagle’s algorithm
MS/TP [16], 6LoPLC for IEEE 1901.2 [10], 6LoWPAN
(when it is enabled)? Assume that the algorithm will
for DECT ULE [17], 6LoBTLE 6LoWPAN for BLE [22],
buffer 60 bytes before transmitting.
6LoWPAN for NFC, and 6Lo IEEE 802.11ah [7]. These

(continued)
4.4 6Lo 105

Fig. 4.44 6Lo technologies MS/TP

ITU-T G.9959 DECT ULE
N IPv6
N IPv6
N IPv6 A LoBAC
A DECT ULE 6LoWPAN
A ITU-T G.9959 6LoWPAN L MS/TP
L DECT ULE
L ITU G.9959 P RS-485
P DECT ULE
P ITU G.9959

IEEE 1901.2
N IPv6
BLE A 6LoPLC
N IPv6
L IEEE 1901.2
A 6LoBTLE
P IEEE 1901.2
L BLE

P BLE
IPv6
gateway
device
P physical layer
L link layer
A adaptation layer
N IPv6 N IPv6
N network layer
A 6LoWPAN A NFC 6LoWPAN
L IEEE 802.15.4 L NFC
N IPv6
P IEEE 802.15.4 P NFC
A 6Lo IEEE 802.11ah

L IEEE 802.11ah NFC

IEEE 802.15.4 P IEEE 802.11ah

IEEE 802.11ah

Table 4.10 6Lo Technologies hops are IP hops. The only 6Lo technologies that support
Technology Adaptation layer Topology a mesh topology are IEEE 1901.2 and ITU-T G.9959 that
ITU-T G.9959 ITU-T G.9959 6LoWPAN M reuse 6LoWPAN functionality. ITU-T G.9959 supports both
MS/TP LoBAC M modes of operation, while IEEE 1901.2, under 6LoWPLC,
DECT ULE DECT ULE 6LoWPAN S only supports mesh-under forwarding.
IEEE 1901.2 6LoPLC M Address compression is also key to both 6LoWPAN and
NFC NFC 6LoWPAN S 6Lo. Specifically, the IID, obtained from link layer address-
IEEE 802.11ah 6Lo IEEE 802.11ah S ing, is not only used to derive IPv6 addresses by means of
IEEE 802.15.4 6LoWPAN M SAA but also to provide their compression. All adaptation
mechanisms standardized and proposed for the 6Lo technolo-
gies described in this section rely on address compression.
technologies are compared in Table 4.10 where the topology One drawback of this compression, however, is the fact that
column indicates whether they support multi-hop (M) or the universal and static nature of IIDs can lead to security
single-hop (S) communication. attacks. In this context, different proposals that target this
Many of these technologies are not just physical and link issue under 6Lo have been proposed.
layer technologies. Like ZigBee with IEEE 802.15.4, BLE, Header compression, as provided by 6LoWPAN, can be
NFC, and DECT ULE prescribe full stacks that include their stateless or stateful to take advantage of the inter- and intra-
own network, transport, and application layers. In these sce- flow information correlation. The difference between one
narios, 6Lo replaces these upper layers with IETF IP-based approach and the other is extra computational complexity in
protocols. In all cases, however, the different physical and favor of stateful compression. All 6Lo technologies, other
link layers face different challenges associated with issues than IEEE 1901.2 under 6LoWPLC which is based on IEEE
ranging from low transmission rates to small MTU sizes 802.15.4, modify 6LoWPAN header compression to adapt
including lack of link layer fragmentation and asymmetries to specific needs of the link layer. ITU-T G.9959, MS/TP
between uplink and downlink mechanisms. LoBAC, IEEE 802.11ah, and NFC introduce minor changes
As previously indicated in Sect. 4.3.3, 6LoWPAN pro- associated with the address length of the link layer addresses.
vides two main modes of operation to support a multi-hop Single-hop star topologies like BLE and DECT ULE are
topology: mesh-under where the multi-hop path appears as a slightly less complex from a header compression point of
single link to the network layer and route-over where physical view since the gateway, when receiving a datagram, can
106 4 Network and Transport Layers

safely assume that the source address is that of the originator. to understand what threats can affect 6Lo technologies and
Moreover, when a device receives a datagram from the gate- how they can be prevented. Neighbor discovery is usually
way, it can also safely assume that the destination address affected by DoS attacks where an intruder pretends to be a
is that of itself. In either case, this leads to IPv6 source or legitimate device by sending fake ND messages. One way to
destination address suppression. prevent this is by relying on router priorities while limiting
Fragmentation is another important issue associated with ND transmission rates. Fragmentation is another issue that
6LoWPAN. Specifically, 6LoWPAN introduces fragmenta- can lead to security attacks. Specifically, an attacker can send
tion because IEEE 802.15.4 does not include any mech- incomplete datagrams with pending fragments that cause
anism to truncate upper layer datagrams. Since the other devices to waste memory resources for long periods of time.
6Lo technologies do support link layer fragmentation, this The intruder can also send fake and duplicate fragments that
is not typically a requirement for their IPv6 adaptation lay- cause corruption of incoming datagrams.
ers. Moreover, under IPv6, MS/TP and IEEE 802.11ah do
not even need to support fragmentation because with 2032-
byte and 7951-byte MTU sizes, respectively, they can easily 4.5 6TiSCH
transport any minimum size 1280-byte IPv6 fragment. Also
related to fragmentation is the encapsulation overhead due to IPv6 over TSCH [30] is an umbrella term for a group of
the physical and link layers headers. In general, the larger the protocols intended to provide IPv6 support over the IEEE
headers, the smaller the payload available and the greater the 802.15.4e TSCH media access mechanism presented in
need for fragmentation. For example, BLE and DECT ULE Sect. 3.3.3.3. Because traditional 6LoWPAN and associated
that support very small payload size are heavily affected by routing mechanisms are not designed to handle the
fragmentation. The overhead of MS/TP and IEEE 802.11ah synchronous nature of the TSCH link layer, 6TiSCH provides
is comparatively low as they both can carry most IPv6 additional functionality that compensates for this missing
datagrams without fragmentation. The other technologies, functionality. 6TiSCH introduces a thin layer above the MAC
ITU-T G.9959, IEEE 1901.2, NFC, and IEEE 802.15.4 suffer functionality of TSCH called 6TiSCH Operational Sublayer
some fragmentation for large datagrams. In all scenarios, the (6top) that binds asynchronous 6LoWPAN to synchronous
fragmentation overhead at either layer, link, or adaptation is TSCH.
very low. Specifically, 6LoWPAN provides IPv6 adaptation for tra-
All 6Lo adaptation methods, other than that of IEEE ditional CSMA/CA-based IEEE 802.15.4, but it is not pre-
1901.2, rely on either 6LoWPAN ND or traditional IPv6 ND pared to deal with TSCH-based IEEE 802.15.4e. 6TiSCH sits
for neighbor discovery. Specifically, IEEE 1901.2 relies on in between 6LoWPAN and IEEE 802.15.4e. Figure 4.45 il-
DHCPv6 for address autoconfiguration. IPv6 multicasting lustrates the layer differences between traditional CSMA/CA
is particularly important in IoT as it enables applications to and TSCH stacks.
reach multiple devices through the transmission of a single 6TiSCH supports dynamic scheduling by means of two
datagram. Of all 6Lo technologies, only IEEE 802.11ah na- separate entities; (1) the 6top Protocol (6P) that can be used
tively supports multicast and broadcast transmissions. More- by neighbors to negotiate the addition and removal of cells
over, BLE and DECT ULE only support unicast transmis- from the schedule and (2) a Scheduling Function (SF) that
sions. Regardless, for IPv6 multicast to work properly, it is triggers 6P negotiations. The 6P, which is standardized under
critical that the adaptation layer is able to present to the upper IETF RFC 8480, provides several commands that neighbors
layer multicast support. This implies that 6Lo adaptation can execute to support schedule cell management including
follows 6LoWPAN in the fact that each multicast datagram adding, removing, and relocating cells from a schedule as
is transmitted by the adaptation layer to each device in the well as listing cells and signaling SFs.
multicast group as individual unicast datagrams. This has to 6P negotiation is carried out by means of 2-step or 3-step
be done very efficiently as it can lead to depleted batteries. transactions. 2-step transactions consist of one device trans-
Security is also a key factor with 6Lo but fortunately mitting a request to its neighbor that replies by transmitting
most adaptation mechanisms like 6LoWPAN rely heavily on a response. This is usually used when a device wants to add,
link layer security. Since all these technologies, including remove, or relocate a given cell. Three-step transactions add
IEEE 802.15.4, provide some sort of security at the link an extra confirmation that is transmitted by device that initi-
layer this is not usually a problem. Also, most applications ated the transaction. This is used when one device requests
support end-to-end security that, as explained in Sect. 4.3.6, adding one or more cells to the schedule and expects the
is always more efficient than security placed at lower layers. receiving neighbor to offer a list of available cells for the
Due to the limited resources, the biggest challenge is to originator to select from. This is illustrated in Fig. 4.46 where
make sure that upper and lower layer security mechanisms device 1 sends a request to add two cells and the receiving
do not inefficiently overlap. In this context, it is important neighbor device 2 offers four cells (2,3), (3,5), (1,2), (5,1)
Homework Problems and Questions 107

Fig. 4.45 6TiSCH stack CSMA/CA TSCH

IPv6 network layer IPv6
6LoWPAN 6LoWPAN
6TiSCH
IEEE 802.15.4 link layer
IEEE 802.15.4e
IEEE 802.15.4 physical layer IEEE 802.15.4

device 1 device 2 submitted. Negotiated cells are added or deleted based on

how fast neighbors exchange frames. MSF keeps track of
cell usage that is defined as the ratio between elapsed cells
and cells that are used to transmit frames to the neighbor. If
the cell usage ratio is high, MSF adds cells, and similarly,
if the ratio is low, MFS removes cells. All of this is done, of
course, by means of 6P commands. In this scenario MSF may
introduce collisions that are detected and resolved by means
of cell relocations. If an MSF negotiation transaction fails,
depending on the failure type, different recovery actions are
recommended; to do nothing or to clear the schedule or to
clear the schedule and put the device in quarantine dropping
Fig. 4.46 6P 3-step transaction all frames intended to it or to abort the transaction, wait for
a random amount of time and restart the transaction.
specified by the TSCH timeslot and channel offsets. Then
the originator device 1, confirms by selecting cells (1,2) and Summary
(5,1) for communication. All these commands are carried
by IEs in the IEEE 802.15.4 frame. Each IE includes not One critical requirement to enable IoT connectivity is to
only the command information but also an 8-bit sequence support end-to-end IPv6 networking. This chapter started by
number that is used to keep track of transactions while introducing the main features of IPv6 including procedures
detecting for inconsistencies like missing acknowledgments. like SAA that are key in allowing devices to self-initialize
When an inconsistency is detected, though, an SF may send and configure. IPv6 support in the context of IoT is provided
a command to clear all cells between the neighbors, or it may by adaptation mechanisms like 6LoWPAN that introduce
send a command to list all cells and attempt to delete and add network and transport layers over constrained physical and
individually. Because devices store the expected sequence link layer technologies. The chapter explored 6LoWPAN
numbers of their neighbors, they can detect problems when detailing its main characteristics and features including its
the sequence number received in a command does not match addressing model, header format, routing and forwarding
the expected one. Again, this situation is fixed by transmitting schemes, stateful and stateless compression support, as well
a clear command that resets the sequence number. as fragmentation. The chapter also delved into security con-
The default SF supported by 6TiSCH is called minimal siderations of IoT network layers by presenting the most rele-
SF (MSF). MSF defines two types of cells: autonomous cells vant security protocols: IPSec/IKE, HIP, and DTLS. Finally,
that provide proactive cell scheduling without any type of it presented several other IPv6 adaptation mechanisms that
negotiation and negotiated cells that rely on 6P to install fall under the umbrella of 6Lo and support other IoT physical
and remove cells from the schedule in a reactive way. Au- and link layer technologies like BLE and DECT ULE among
tonomous cells can be, in turn, autonomous RX cells that others.
are permanently installed in the schedule or autonomous
TX cells that are installed on demand. If a frame is to be
sent out and there is no cell installed, an autonomous TX Homework Problems and Questions
cell is briefly installed, the frame is sent out, and then the
cell is removed right away. The cell itself is derived from 4.1 Consider an Ethernet device with MAC (EUI-48 for-
hashing the destination address of the frame. Since hashing mat) address 11:22:33:44:55: 66 and an IEEE 802.15.4 de-
can lead to collisions where the same cell is allocated as vice with MAC (EUI-64 format) address 11:22:33:44:55:66:
an autonomous RX and an autonomous TX cell resolution 77:88. If the network prefix is 2001::/64, for the following
may be needed. In general, autonomous cells are kept in the IPv6 address types, what addresses are derived for both
schedule even after 6P commands to clear the schedule are Ethernet and IEEE 802.15.4?
108 4 Network and Transport Layers

(a) SAA based unicast Consider best and worst stateful compression scenarios. In-
(b) Link-local dicate all assumptions.

4.2 Why is DAD needed, if SAA relies on using MAC 4.11 What is the main difference between the 6LoWPAN
addresses that are typically unique? S/SAM and SAE fields?

4.3 What is the point of using fewer of the eight available 4.12 If an IEEE 802.15.4 IoT sensor generates N-byte read-
bits for dispatch encoding? outs at a rate of R readouts per second. Assuming each read-
out is transmitted over UDP/IPv6 and compressed by means
4.4 Why does not the initial 6LoWPAN fragment include the of 6LoWPAN. For the maximum nominal transmission rate
offset field? and best stateful compression, what is the relationship be-
tween R and N? Assume a minimum size IEEE 802.15.4
4.5 Given the following 88-byte IPv6 datagram… header.

4.13 Consider the IEEE 802.15.4/6LoWPAN route-over ag-

I U P
gregation scenario shown below. The sensors generate 40-
I IPv6 header (40 bytes) byte readouts transmitted every 100 ms. Assuming best-case
U UDP header (8 bytes) scenario stateful 6LoWPAN compression, what are the trans-
P Payload (40 bytes)
mission rates for each of the sensors?

What are the best compression rates for the scenarios listed
A B
below? Indicate all assumptions. Note that the compression
IPv6 address 2001::21:05 2001::21:10
rate is defined as the ratio between the size of the compressed MAC address 11:22:33:44:55:66:77:88 11:22:33:44:55:66:77:99
frame and that of the original datagram. Assume minimum
6LoWPAN compressed network and transport headers.
4.14 In an IoT scenario where real time readouts are trans-
(a) Stateless 6LoWPAN compression mitted over TCP by a sensor, what is a drawback of disabling
(b) Stateful 6LoWPAN compression Nagle’s algorithm?

4.6 Why is the 6LoWPAN fragment offset field a multiple 4.15 What does a 6LoWPAN stack that supports DTLS
of eight? security look like?

4.7 Repeat Problem 4.5 but considering the following 68- 4.16 Given the following scenario, if sensor A sends a data-
byte IPv4 datagram… gram to the application, what does the IEEE 802.15.4 frame
generated by the sensor look like? What does the Ethernet
frame generated by the edge router look like? Include all
I U P
headers and associated fields. Assume a 20-byte payload.
I IPv4 header (20 bytes) Indicate all assumptions including source and destination
U UDP header (8 bytes) UDP ports.
P Payload (40 bytes)

IEEE 802.15.4 /6LoWPAN/ IPv6 /UDP Ethernet/ IPv6 /UDP

4.8 Repeat Problem 4.5 but consider an 800-byte payload

instead. Assume that the lower layer is IEEE 802.15.4, sup-
porting payload sizes no larger than 118 bytes long. IP addr: 2001::21:11 IP addr: 2001::20:11
MAC addr: 11:22:33:44:55:66:77:88 MAC addr: 22:33:44:11:22:62

4.9 In what 6LoWPAN scenarios is stateless compression

more convenient than stateful compression?
A
4.10 If an IoT sensor generates 172-byte readouts every IP addr: 2001::21:10
IP addr: 2001::20:43
20 ms, what is its transmission rate? Each readout is transmit- MAC addr: 11:22:33:44:55:66:77:99
MAC addr: 22:33:44:11:22:30

ted over UDP/IPv6 and compressed by means of 6LoWPAN.

References 109

4.17 For the same conditions, what does typically result in 14. Khssibi, S., Idoudi, H., Van Den Bossche, A., Val, T., Saidane,
lower latency 6LoWPAN over IEEE 802.15.4 or over IEEE L.A.: Presentation and analysis of a new technology for low-power
wireless sensor network (2013)
802.15.4e? Why?
15. Kim, E., Kaspar, D., Gomez, C., Bormann, C.: Problem Statement
and Requirements for IPv6 over Low-Power Wireless Personal
4.18 How is a 20-byte payload transported over TCP state- Area Network (6LoWPAN) Routing. RFC 6606 (2012). https://
fully compressed by 6LoWPAN and transmitted over IEEE doi.org/10.17487/RFC6606. https://rfc-editor.org/rfc/rfc6606.txt
16. Lynn, K., Martocci, J., Neilson, C., Donaldson, S.: Transmission
802.15.4? What headers and fields do the IEEE 802.15.4
of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks. RFC
frame include? 8163 (2017). https://doi.org/10.17487/RFC8163. https://rfc-editor.
org/rfc/rfc8163.txt
4.19 A sensor generates 500-byte readouts, if the network 17. Mariager, P.B., Petersen, J.T., Shelby, Z., van de Logt, M., Barthel,
D.: Transmission of IPv6 Packets over Digital Enhanced Cordless
frame loss is 5%, what is the datagram loss for the following
Telecommunications (DECT) Ultra Low Energy (ULE). RFC 8105
two scenarios? (2017). https://doi.org/10.17487/RFC8105. https://rfc-editor.org/
rfc/rfc8105.txt
(a) IEEE 802.15.4 18. Montenegro, G., Hui, J., Culler, D., Kushalnagar, N.: Transmis-
sion of IPv6 Packets over IEEE 802.15.4 Networks. RFC 4944
(b) Ethernet
(2007). https://doi.org/10.17487/RFC4944. https://rfc-editor.org/
rfc/rfc4944.txt
19. Montenegro, G., Schumacher, C., Kushalnagar, N.: IPv6 over
References Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals. RFC 4919
1. Belshe, M., Peon, R., Thomson, M.: Hypertext Transfer Protocol (2007). https://doi.org/10.17487/RFC4919. https://rfc-editor.org/
Version 2 (HTTP/2). RFC 7540 (2015). https://doi.org/10.17487/ rfc/rfc4919.txt
RFC7540. https://rfc-editor.org/rfc/rfc7540.txt 20. Moskowitz, R., Heer, T., Jokela, P., Henderson, T.R.: Host Identity
2. Bluetooth, S.: Bluetooth 5.2 core specification, p. 3256 (2019) Protocol Version 2 (HIPv2). RFC 7401 (2015). https://doi.org/10.
3. Bormann, C.: 6LoWPAN-GHC: Generic Header Compression for 17487/RFC7401. https://rfc-editor.org/rfc/rfc7401.txt
IPv6 over Low-Power Wireless Personal Area Networks (6LoW- 21. Narten, D.T., Thomson, D.S.: IPv6 Stateless Address Autoconfig-
PANs). RFC 7400 (2014). https://doi.org/10.17487/RFC7400. uration. RFC 2462 (1998). https://doi.org/10.17487/RFC2462.
https://rfc-editor.org/rfc/rfc7400.txt https://rfc-editor.org/rfc/rfc2462.txt
4. Brandt, A., Buron, J.: Transmission of IPv6 Packets over ITU-T 22. Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z.,
G.9959 Networks. RFC 7428 (2015). https://doi.org/10.17487/ Gomez, C.: IPv6 over BLUETOOTH(R) Low Energy. RFC 7668
RFC7428. https://rfc-editor.org/rfc/rfc7428.txt (2015). https://doi.org/10.17487/RFC7668. https://rfc-editor.org/
5. Deering, D.S.E., Hinden, B.: Internet Protocol, Version 6 (IPv6) rfc/rfc7668.txt
Specification. RFC 8200 (2017). https://doi.org/10.17487/ 23. Oppliger, R.: SSL and Tls: Theory and Practice, 2nd edn. Artech
RFC8200. https://rfc-editor.org/rfc/rfc8200.txt House, Norwood (2016)
6. Frankel, S., Krishnan, S.: IP Security (IPsec) and Internet Key 24. Rescorla, E.: The Transport Layer Security (TLS) Protocol Version
Exchange (IKE) Document Roadmap. RFC 6071 (2011). https:// 1.3. RFC 8446 (2018). https://doi.org/10.17487/RFC8446. https://
doi.org/10.17487/RFC6071. https://rfc-editor.org/rfc/rfc6071.txt rfc-editor.org/rfc/rfc8446.txt
7. Gomez, C., Paradells, J., Bormann, C., Crowcroft, J.: From 6low- 25. Rescorla, E., Modadugu, N.: Datagram Transport Layer Security
pan to 6lo: Expanding the universe of ipv6-supported technologies Version 1.2. RFC 6347 (2012). https://doi.org/10.17487/RFC6347.
for the internet of things. IEEE Commun. Mag. 55 (2017). https:// https://rfc-editor.org/rfc/rfc6347.txt
doi.org/10.1109/MCOM.2017.1600534 26. Shelby, Z., Bormann, C.: 6LoWPAN: The Wireless Embedded
8. Graziani, R.: IPv6 fundamentals: a straightforward approach to Internet. Wiley, New York (2010)
understanding IPv6. Pearson Education (2012) 27. Simpson, W.A., Narten, D.T., Nordmark, E., Soliman, H.: Neighbor
9. Gupta, M., Conta, A.: Internet Control Message Protocol (ICMPv6) Discovery for IP version 6 (IPv6). RFC 4861 (2007). https://doi.
for the Internet Protocol Version 6 (IPv6) Specification. RFC 4443 org/10.17487/RFC4861. https://rfc-editor.org/rfc/rfc4861.txt
(2006). https://doi.org/10.17487/RFC4443. https://rfc-editor.org/ 28. Thubert, P., Hui, J.: Compression Format for IPv6 Datagrams over
rfc/rfc4443.txt IEEE 802.15.4-Based Networks. RFC 6282 (2011). https://doi.
10. Ikpehai, A., Adebisi, B.: 6loplc for smart grid applications. In: 2015 org/10.17487/RFC6282. https://rfc-editor.org/rfc/rfc6282.txt
IEEE International Symposium on Power Line Communications 29. Tschofenig, H., Fossati, T.: Transport Layer Security (TLS) / Data-
and Its Applications (ISPLC), pp. 211–215 (2015) gram Transport Layer Security (DTLS) Profiles for the Internet of
11. ISO/IEC 18000-3: Parameters for air interface communications at Things. RFC 7925 (2016). https://doi.org/10.17487/RFC7925.
13,56 MHz. Standard, International Organization for Standardiza- https://rfc-editor.org/rfc/rfc7925.txt
tion, Switzerland (2010) 30. Vilajosana, X., Watteyne, T., Chang, T., Vučinić, M., Duquennoy,
12. ITU, T.S.S.: Itu-t g.9959 : Short range narrow-band digital radio- S., Thubert, P.: Ietf 6tisch: a tutorial. IEEE Commun. Surv.
communication transceivers - phy, mac, sar and llc layer specifica- Tutorials 22(1), 595–615 (2020)
tions. Tech. rep., International Telecommunication Union (2015) 31. Williams, M., Tüxen, M., Seggelmann, R.: Transport Layer Se-
13. Kaufman, C., Hoffman, P.E., Nir, Y., Eronen, P., Kivinen, T.: curity (TLS) and Datagram Transport Layer Security (DTLS)
Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296 Heartbeat Extension. RFC 6520 (2012). https://doi.org/10.17487/
(2014). https://doi.org/10.17487/RFC7296. https://rfc-editor.org/ RFC6520. https://rfc-editor.org/rfc/rfc6520.txt
rfc/rfc7296.txt 32. ZigBee Specification. Standard, The ZigBee Alliance, USA (2015)
 Application Layer
5

5.1 Architectures 5.2 Request/Response

The IETF layered architecture indicates that the application 5.2.1 REST Architecture
layer also performs session and presentation functions that
enable the management of different sessions as well as en- IoT connectivity at the session level can take advantage of
cryption and authentication mechanisms. Most so-called IoT the existing request/response architecture that is an integral
application layer protocols provide session management such part of the web. Moreover, not only session layer mechanisms
that application layer-specific functionality is typically car- like HTTP but other technologies like HTML, JavaScript,
ried out by some other mechanism that encodes both sensor Node JS, Ajax, and PHP can be leveraged to provide con-
and actuation traffic. This is a similar situation to web traffic nectivity between devices and applications. This approach
transmission that relies on HTTP for session management has led to what it is called the Web of Things (WoT) that
and relies on Hypertext Markup Language (HTML) for ap- relies on embedding a simple web server on devices to take
plication data encoding. When considering session manage- advantage of the web infrastructure. There is no need for
ment, there are two well-known topologies request/response topology or client changes since all updates are pushed to the
and publish/subscribe that are shown in Figs. 5.1 and 5.2, devices. In general, request/response mechanisms associated
respectively [3, 15]. with web technologies like HTTP comply quite well with the
The request/response model, also known as client/server REST distributed architecture. REST architectures formalize
model, bases its interaction between application and device a series of requirements and interfaces that are necessary
by means of requests and responses. The device, sensor or for client/server interaction [8]. Not all REST schemes rely
actuator, acts as a server, while the application acts as a client. on the HTTP protocol, and not all HTTP scenarios support
The client typically requests sensor data or sends actuation REST architectures. Other protocols like CoAP, presented
commands, while the server responds by transmitting sensor later in this chapter, also support REST deployments.
readouts or actuation acknowledgments. The model is based For an architecture to be REST based, it must comply
on synchronous polling where for each request there is a with six requirements or principles. Freedom is given on
response. On the other hand, the publish/subscribe model the implementation of each component if it meets these
relies on a central broker that queues and delivers mes- requirements. The six requirements are the following:
sages between applications and devices. First, the application
subscribes to a specific topic supported by the device. The (1) The client/server requirement that states that a Uniform
device publishes device messages by sending them to the Interface separates clients and servers. This implies that
broker. The broker stores the messages and forwards them storage is associated with servers, while user interaction
via notifications to the application that is interested in them. is a function of the client. If the interface between a client
This model is based on asynchronous observation of devices and a server is preserved, they can evolve independently.
that do not rely on polling. The advantage of this mech- Moreover, clients and servers can be upgraded and down-
anism is that it improves latency and network utilization, graded without affecting each other.
but it requires the use of a broker that is a single point of (2) The stateless requirement that states that communication
failure. between client and servers is stateless and that each

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 111
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_5
112 5 Application Layer

Fig. 5.1 Request/response client server

request
response

application sensor, actuator

Fig. 5.2 Publish/subscribe

subscribe
publish
notify
application sensor, actuator

broker

request must contain all the information needed by the Table 5.1 shows an example of specific HTTP methods
server to process it and respond. No content stored on the and how they are used in the context of individual devices as
server can be used to process the request. Session state, well as collections of them. More details of the HTTP proto-
if any, is kept on the client side. col are presented in the following section. Note that REST
(3) The cacheable requirement that states that to minimize requests rely on resource identification by means of Uni-
overall network throughput and guarantee network versal Resource Identifiers (URIs) that follow the method.
efficiency, requests can be cached at the clients. Clients refer to resource identifiers but handle representations
Server responses indicate whether a given message of those resources and not the resources themselves. These
is cacheable or not depending on how likely it is to representations are data structures that can be formatted
change. via HTML, the more generic Extended Markup Language
(4) The Uniform Interface requirement that, besides separat- (XML), or JavaScript Object Notation (JSON). If a client
ing the client/server architectures, enables independent has enough permissions, it can use its own resource repre-
protocol evolution. sentation to update the resource on the server accordingly.
(5) The layered system requirement that states that the archi- Moreover, the client can also delete the resources from the
tecture must be composed of several hierarchical layers server.
with visible interfaces but without a formally specified One issue with traditional REST architectures is that the
implementation. CRUD mechanisms rely on the client always initializing the
(6) The code on demand requirement that allows client interaction with the server. In the context of IoT, this implies
code to be extended by dynamically downloading that the application must periodically send requests to obtain
and executing scripts from the server. This allows readouts from devices. For each readout, therefore, there is
the simplification of the client infrastructure by min- a full duplex transaction between client and server. There
imizing the preinstalled code and expediting software are two problems associated with this situation: (1) extra
updates. latency due to the time it takes for the client to poll the
sensor and (2) extra traffic due to the additional datagrams
REST APIs provide the basic functionality to access net- needed to poll the sensor. To address this issue, the reference
work resources by means of their representational states. architecture for IoT, introduced by the European Telecom-
REST APIs rely on the CRUD mechanism; C stands for munications Standards Institute (ETSI), extends REST by
create, R stands for read, U stands for update, and D stands means of two additional operations: (1) notify and (2) ex-
for delete. Essentially a client must be able to create, read, ecute. The notify operation, also known as observation, is
update, and delete an object representation. This is ideal triggered upon a change in the representation of a resource
for an IoT environment where objects are devices that are and results in a notification sent to the client in order to
(1) created as sensors or actuators, (2) read when they are monitor changes of the resource in question. The execute
sensors, (3) updated when they are actuators, or (4) deleted. operation enables a client to request the execution of a
In the context of the Internet, REST APIs rely on HTTP to specific task on the server. In the context of the CRUD set,
provide session management. As shown in Fig. 5.3, different notify is implemented by an UPDATE operation transmit-
HTTP methods are used; POST is used to create a new device ted from the server toward the requesting client. Similarly,
(sensor or actuator), GET is used to retrieve a sensor readout, execute is implemented by an EXECUTE operation from
PUT is used to update the state of an actuator, and DELETE the client to the server that includes task information and
is used to delete a device. parameters.
5.2 Request/Response 113

Fig. 5.3 REST APIs with HTTP

device AP
I

IP

AP
I

POST /tasks – create a new device

GET /tasks/[id] – read a sensor by id
PUT /tasks/[id] – update an actuator by id
DB
DELETE /tasks/[id] – delete device by id
application

Table 5.1 REST API Methods HTTP method Entire collection, e.g. /devices/ Specific item, e.g. /devices/id/
GET 200 (OK)—list of devices 200 (OK)—single device
404 (Not Found) if ID is not found or invalid
PUT 404 (Not Found) 200 (OK) or 204 (No Content)—update device information
404 (Not Found) if ID is not found or invalid
POST 201 (Created)—Location header with 404 (Not Found)—Generally not used
link to /devices/id/ containing the new ID.
DELETE 404 (Not Found) 200 (OK)
404 (Not Found)—Generally not used

5.2.2 HTTP

HTTP provides session layer management of web applica- device

HT
tions including client and server support. HTTP traffic relies ST TP
UE HT RE
on TCP transport that cannot be typically compressed by EQ SE TP QU
TPR ON RE ES
T
means of 6LoWPAN [9]. For reasons explained in Sect. 4.3.7, HT SP SP
RE ON
SE
since TCP transport is not usually recommended in the TP
HT
context of IoT, there is no standard way to compress TCP
headers. Moreover, HTTP messages are American Standard
Code for Information Interchange (ASCII) encoded, and
therefore they are typically too big to fit in a single frame
of most link layer IoT technologies like IEEE 802.15.4. In
consequence, the lack of TCP header compression added to client client
the large size of the messages results in network fragmen-
tation that leads to elevated network loss. HTTP is used to Fig. 5.4 HTTP request/response
access web documents that can be HTML content, scripts,
or media files that are accessed by means of a subset of
Uniform Resource Identifiers (URIs) known as Uniform Re- of a temperature readout object from a thermometer sensor
source Locators (URLs). An HTML document consists of an acting as a server. The sensor receives the requests and
XML structure used to reference several other web objects sends an HTTP response containing the representation of a
via their corresponding URLs. A URL consists of service temperature readout object. This interaction is done without
type, a hostname, and a path. For example, for the http:// the server keeping any state information and thus comply-
www.congress.gov/advanced-search/legislation URL, http:// ing with REST architecture principle of statelessness. Since
is the service type, www.congress.gov is the hostname, and HTTP relies on TCP for transport, before any traffic can
/advanced-search/legislation is the path. be transmitted, a connection must be established. Figure 5.5
Figure 5.4 shows a client/server interaction where an shows an example of a connection established between a
application sends an HTTP request to obtain a representation client/application and a server/sensor/device. Connection es-
114 5 Application Layer

that, in turn, is replied by the server. With a non-persistent

connection, as before, the client initiates a TCP connection
and transmits the first HTTP request as part of the last part of
the aforementioned three-way handshake. When the sensor
application device
responds, and after receiving the readout, the client tears
new down the connection. Later, when the client tries to obtain
TCP hand
shak a new readout from the server, it creates a new connection
connection e 1/
3 before it transmits the HTTP request. The sensor responds
by transmitting an HTTP response, which, when received
by the client, triggers the latter to tear down this second
RTT

connection.
3
e 2/ HTTP transported by means of persistent TCP connec-
ds hak
han tions has become more efficient with newer versions of
HTTP. This is shown in Fig. 5.7. The very first version 1.0
TIME

request
sensor
of HTTP, formally known as HTTP/1.0, only allowed clients
data hand to send requests in a stop-and-wait fashion. In other words,
shak
e 3/
3 if a client transmits a request, it must wait for the server
HT T
P re
ques response before it can transmit another request. The result of
t send this behavior is excessive latency. HTTP 1.1 (formally known
RTT

sensor as HTTP/1.1) introduces the concept of pipelining, where the

data
client can transmit many simultaneous requests that are pro-
o nse
resp cessed and answered by the server in the order in which they
H T TP
are received. HTTP 1.1 exhibits lower latency than HTTP
sensor 1.0. Although all the requests may arrive at the server at the
data same time, some of them may take longer to be processed
received
than the others. For example, a request that retrieves the
Fig. 5.5 HTTP setup temporal average of temperature readouts takes longer to
be processed than a request that retrieves a single readout.
Therefore, an earlier request may delay the transmission of
tablishment under TCP relies on a three-way handshake the response to a later request that may have been already
where the first two parts of the process consume one Round processed. This is known as head-of-line (HOL) blocking be-
Trip Time (RTT). An RTT is defined as the time it takes cause the processing of a request can prevent other responses
for a datagram to travel from the client to the server and from being transmitted. HTTP 2.0 [4] (formally known as
back to the client including transmission, propagation, and HTTP/2.0) addresses this issue by introducing multiplexing
queuing delays associated with all nodes. The last part of that enables the client to simultaneously transmit requests so
the handshake is combined with the HTTP request which that they can be answered by the server in the order in which
when received by the sensor causes it to send the HTTP they are processed. As a consequence, HTTP 2.0 exhibits
response including temperature readouts. It is clear from the lower latency than HTTP 1.1. HTTP 3.0 (formally known
figure that the approximate server response time is around as HTTP/3.0) [5] introduced as an IETF draft in September
two RTTs. 2020 attempts to improve latency by relying on Quick UDP
Depending on configuration, HTTP may rely on a single Internet Connection (QUIC) transport instead of TCP. QUIC
persistent TCP connection to transport all requests and re- is a transport layer protocol that lowers connection setup
sponses, or it may rely on multiple connections such that it as well as transmission latency and consequently improves
associates a single request/response transaction with a single congestion performance [12].
non-persistent TCP connection. Figure 5.6 shows a client Non-persistent connections are responsible for extra la-
requesting two consecutive sensor readouts on both scenar- tency introduced when each new connection is established.
ios. With a persistent connection, the client first initiates New connections also introduce additional computational
a TCP connection and transmits the first HTTP request as complexity and memory requirements because they rely on
part of the last part of the three-way handshake. When the allocated buffers and state variables. Persistent connections
sensor receives the request, it reads the temperature value do not have these restrictions; however, they are always active
and responds with an HTTP response. Neither the client even when they are not needed. So, if the client does not
nor the sensor tears down the connection. A bit later, the need to request sensor data, the connection remains causing
client issues a new HTTP request to get an additional readout a waste of computational and memory resources.
5.2 Request/Response 115

Fig. 5.6 Persistent vs persistent non-persistent

non-persistent connections

application device application device

readout request readout request

readout latency

readout latency
HTT
P re
que
st

nse nse
po

TIME
es es po
T Pr T Pr
HT HT

TIME
readout request readout request
HTT
P re
readout latency

que
st

nse
po

readout latency
es
T Pr
HT
HTT
P re
que
st

se
p on
res
TP
HT

5.2.2.1 HTTP Messages

(continued)
Example 5.1 Consider an end-to-end HTTP scenario LTCP = 20 bytes long, (e) the HTTP GET request
where an application requests a readout from a sensor: is LGET = 200 bytes long, (f) the HTTP 200 OK
response is L200 OK = 100 bytes long, (g) the IPv4
GW application
header is LIPv4 = 20 bytes long, (h) the 6LoWPAN
header is L6LoWPAN = 10 bytes long, (i) the Ethernet
GET header is Leth = 16 bytes long, and (f) the IEEE
GET
802.15.4 header is LIEEE 802.15.4 = 10 bytes long. How
sensor event
long does it take for the application to receive the
200 OK
200 OK readout?
IEEE 802.15.4 Ethernet

Assume the following: (a) the IEEE 802.15.4 Solution The overall delay is given by T = T1 +
transmission rate is 250 KBps, (b) the Ethernet T2 + T3 + T4 where T1 is the delay associated
transmission rate is 1 Gbps, (c) the only delay with the transmission of the TCP SYN frame to es-
is the transmission delay, (d) the TCP header is tablish the connection (as part of the initial RTT),
T2 is the delay associated with transmission of the
(continued)
(continued)
116 5 Application Layer

Fig. 5.7 HTTP 1.0 vs HTTP 1.1 HTTP/1.0 HTTP/1.1 HTTP/2.0

vs HTTP 2.0

application device application device application device

1 1 1
2 2
3 3

TIME

TIME
TIME

2
3
1 1
2 1
2
3

PIPELINING MULTIPLEXING

2
3

GET /sensor102/temperature HTTP/1.1

(continued) Host: www.l7tr.com
TCP SYN/ACK frame to acknowledge the connec- Connection: close
tion establishment (as part of the initial RTT), T3 User-Agent: PXO Sensor
is the delay associated with the transmission of the
HTTP GET request, and T4 is the delay to transmit The request consists of four lines with each line followed
the HTTP 200 OK. T1 and T2 are given by T1 = by ASCII carriage return and line feed characters. The very
T2 = 8×(Leth +L IPv4 +LTCP )
109
+ 8×(LIEEE 802.15.4 +L6LoWPAN +LTCP )
250000
= last line of the message is also followed by an additional
1.28 ms. T3 is given by T3 = 8×(Leth +LIPv4 +LTCP +LGET )
+ sequence of ASCII carriage return and line feed characters.
10 9
8×(LIEEE 802.15.4 +L6LoWPAN +LTCP +LGET ) Although this message is four lines long, HTTP messages
250000
= 7.68 ms. T4
8×(Leth +LIPv4 +LTCP +L200 OK ) can include any positive number of lines. The first line of
is given by T4 = 109
+
8×(LIEEE 802.15.4 +L6LoWPAN +LTCP +L200 OK )
the message is called the request line, and all other lines are
250000
= 4.48 ms. The total called header lines. The request line includes three elements:
delay is, therefore, T = 14.72 ms. the aforementioned method field that is followed by the
URL that is, in turn, followed by the version field. The
HTTP messages are ASCII encoded, and they can there- method, as previously explained, can take different values
fore be read by humans on the wire by means of network including GET, POST, HEAD, PUT, and DELETE that
sniffers and analyzers. There are basically two types of HTTP enable HTTP to perform the CRUD functionality associated
messages that comply with the client/server architecture in- with REST architectures. Most HTTP transactions involve
teraction: (1) request messages and (2) response messages. GET requests like the one in the example above. The /sen-
The message below is an example of an HTTP request sor102/temperature URL specifies the full path to the server
transmitted by a client attempting to retrieve a temperature resource being accessed. The first header in the example
readout from a sensor: is the Host header that points to the www.l7tr.com server.
Although this header may seem redundant, it is critical when
5.2 Request/Response 117

Fig. 5.8 HTTP request message

REQUEST LINE METHOD SP URL SP VERSION CR LF

HEADER FIELD NAME SP VALUE CR LF

HEADER LINES

HEADER FIELD NAME SP VALUE CR LF

BLANK LINE CR LF

ENTIRE BODY

SP ASCII space
CR ASCII carriage return
LF ASCII line feed

the client talks to the server through an intermediate proxy Table 5.2 HTTP response codecs
server. In this case, the header tells the proxy server who Range meaning
the final destination of the message is. The second header is 100–199 Informational
the Connection header that indicates whether the connection 200–299 Success
is persistent or not. The third and last header is the User- 300–399 Redirect
Agent header that identifies the application that is making 400–499 Client errors
the request to the sensor. This field lets the server make 500–599 Server errors
presentation decisions based on the type of application that
is originating the request. Other HTTP requests like POST
requests include a message body that follows the carriage line, in turns, includes a version field HTTP/1.1, a status
return and line feed after the last header in the message. The code 200, and a status message OK that maps the status
message body is used to include large amounts of information code. A response with a 200 OK status indicates that the
that can be transferred from the client to the server. This request was received and reply information is returned as
is particularly important in certain actuation scenarios. The part of the message. Other status codes are (1) 301 Moved
message body is also used in responses to HTTP GET re- Permanently to indicate that the object representation has
quests to carry object representations. The HEAD and GET been permanently moved and a new URL is specified in the
methods are similar with the difference that the former is used location, (2) 400 Bad Request that is a generic error code used
to signal that the client does not want to receive the message to indicate that the request was not understood by the server,
body if present. Essentially, the HEAD method enables the (3) 404 Not Found that indicates that the object does not
client to examine the object before requesting it in order to exist in the server, and (4) 505 HTTP Version Not Supported
minimize network utilization. On the other hand, the PUT that tells the client that the HTTP protocol version is not
method is usually used to create and upload objects, while supported by the server. Table 5.2 illustrates the numerical
the DELETE method enables a client to delete an object from range of possible response codes and their meaning. The first
the server. Figure 5.8 shows the format of a generic HTTP header is the Connection header that tells the client that the
request message. connection must be closed after the message is sent. The
The message below is an example of an HTTP response second header is the Date header that specifies when the
transmitted by a sensor including a temperature readout: HTTP response was created. The third header is the Server
HTTP/1.1 200 OK header that identifies the entity that created the response. The
Connection: close fourth header is the Last-Modified header that indicates when
Date: Tue, 23 July 2019 15:44:04 GMT the object representation was last changed. The fifth header
Server: www.l7tr.com is the Content-Length header that indicates the length of the
Last-Modified: Tue, 23 July 2019 15:44:04 GMT message body. Finally, the sixth header is the Content-Type
Content-Length: 5 header that identifies the encoding of the body. In this case,
Content-Type: text/plain the message body is a plain ASCII text that encodes in 5 bytes
the string 23.1C representing a temperature of 23.1◦ degrees.
23.1C Figure 5.9 shows the format of a generic HTTP response
In a similar way to a request, a response has three sections: message.
a status line, several headers, and a message body. The status
118 5 Application Layer

Fig. 5.9 HTTP response

STATUS LINE VERSION SP STATUS CODE SP PHRASE CR LF
message
HEADER FIELD NAME SP VALUE CR LF

HEADER LINES

HEADER FIELD NAME SP VALUE CR LF

BLANK LINE CR LF

ENTIRE BODY

SP ASCII space
CR ASCII carriage return
LF ASCII line feed

5.2.2.2 Cookies the client has been powered down, the requests from the client
As presented in Sect. 5.2.1, one of the main characteristics include the 2105 cookie identifier that is used, in turn, by the
of REST architectures is that they are stateless. HTTP, fitting sensor to identify the application and respond in accordance
the REST model, is stateless, but for many applications, it is with pre-specified preferences and states.
convenient to have a mechanism to treat certain transactions
as stateful. For example, if an application user is interested in 5.2.2.3 Proxy Servers
temperature readouts presented as Centigrade degrees, it may A proxy server, also known as a web cache, is a device
be interesting for the device to be able to implicitly identify that sits between client applications and sensors as well
these requests by keeping track of a user state. Cookies are as devices acting as HTTP servers in order to respond to
an add-on mechanism that can be used to introduce a state client requests on behalf of these servers. Proxy servers
in the interaction between clients and servers. Cookies are can reply on behalf of HTTP servers by keeping copies
associated with users, and although they violate the REST of the information stored in them. Since proxy servers are
principle, they are useful under certain circumstances. Es- close to client applications, they are useful in lowering core
sentially cookies are short strings that enable IoT devices traffic throughput and thus accomplishing better channel
to identify multiple applications. The cookie infrastructure utilization, reducing data access latency, and providing re-
relies on two databases: one at the client and another at dundancy. Proxy servers attempt to keep in their own stor-
the server. It also relies on two cookie headers, Cookie and age the most recent copies of any server object that may
Set-Cookie, that are added to HTTP requests and responses, be requested by applications. Proxy server interaction with
respectively. clients is shown in the example of Fig. 5.11. The following
Figure 5.10 shows the interaction between a client applica- steps describe the flow of messages shown in that figure:
tion and a sensor server. The client has previously interacted (1) the client connects to its pre-configured proxy server to
with another server that has populated a cookie identified by request, via HTTP, a specific temperature readout; (2) the
1912 in its own database. The figure describes the process in proxy server checks whether it has the most recent readout
several steps: (1) the application sends a request to retrieve a of the temperature (if so, jump to step (6)); (3) if the proxy
readout of temperature in Centigrade degrees from the sensor. server does not have a recent copy, it connects to the sensor
This information is specified as part of the URL, but since and requests, via HTTP, the temperature readout; (4) the
this is the first time that this interaction occurs, the client sensor sends an HTTP response including an object repre-
does not include a Cookie header in the request; (2) the sentation of the temperature readout; (5) the proxy server
server then responds to the incoming request by transmitting stores the copy of the temperature object; and (6) the proxy
the temperature readout and associating cookie 2105 to the server sends the object representation of the temperature
client. The cookie is transmitted as a Set-Cookie header to readout to the client. These steps are summarized as a flow in
the application; (3) the client stores the cookie and associates Fig. 5.12.
it with the sensor; then it requests a new readout, but this time The main question is how a proxy server remains syn-
it does not specify a full URL but the 2105 cookie instead; (4) chronized with a web server; HTTP provides a mechanism
the device associates the request with the user by means of the known as conditional GET that allows the proxy server to
received 2105 cookie and responds with a new temperature verify that a specific object is up to date. The message below
readout in Centigrade degrees; (5) any later time, even after is an example of a conditional GET request:
5.2 Request/Response 119

Fig. 5.10 HTTP cookies

application sensor C

sensor A: 1912
GET
tem
pe ratu
re in C°
unit
s
sensor creates
its entry 2105
° un
re in C 05
atu ie: 21
per k
tem et-Coo
S

sensor A: 1912
sensor B: 2105
GET
Coo sensor
kie:
2105

cookie-specific
its
° un acon
re in C 05
atu ie: 21
per k
tem et-Coo
S

LATER

sensor A: 1912
sensor B: 2105 GET
Coo sensor
kie:
2105

cookie-specific
nits acon
i n C° u
re 05
atu ie: 21
per k
tem et-Coo
S

GET /sensor102/temperature HTTP/1.1 On the other hand, if there have been more readouts since
Host: www.l7tr.com the last request, the sensor replies with a regular 200 OK
Connection: close response:
User-Agent: PXO Sensor HTTP/1.1 200 OK
If-modified-since: Tue, 23 July 2019 15:44:04 Connection: close
GMT Date: Tue, 23 July 2019 15:44:04 GMT
The request includes a If-Modified-Since header that is Server: www.l7tr.com
used by the proxy server to obtain a new object representation Last-Modified: Tue, 23 July 2019 16:04:04 GMT
only if it has changed since it was last requested on Tuesday, Content-Length: 5
July 23 2019 at 3:44:04 PM GMT. If there have been no Content-Type: text/plain
more new readouts since the last request, the sensor replies
by transmitting a 304 Not Modified response: 25.2C
HTTP/1.1 304 Not Modified In general, since the 304 Not Modified response is much
Date: Sat, 15 Oct 2011 15:39:29 smaller than the 200 OK response, this mechanism provides
Server: Apache/1.3.0 (Unix) a way to improve channel utilization efficiency.
120 5 Application Layer

by enabling sensors to push their readouts whenever they

become available.
XMPP provides several basic services: (1) channel en-

A
te
A

or
m
GE re cryption and authentication to support end-to-end security,

ns
pe
Tt tu

se
ra
em ra

tu
application pe (2) presence to enable entities to share information about

re
pe A
em

B
ra t e their availability within the network, (3) contact lists that
tu
re ET tur
G ra provide a mechanism for servers to store lists of devices and
B pe
e m
t applications, (4) one-to-one messaging to support the infras-
eA tructure of communication that enables users to send XML
tur
ra messages, (4) multi-party messaging and notifications that

te
A
pe re proxy server
GE

m
tu

pe
m

Tt
te ra provide a mechanism to send a single message to multiple

ra
em
pe

tu
em subscribers in a similar way to that of the publish/subscribe
pe

re
t
ra

B
T
GE
tu
model, (5) service discovery to let entities (i.e. applications)
re
B
know the capabilities of other entities (i.e. devices), (6) struc-

rB
so
tured data forms that enable endpoints to exchange struc-

n
se
tured but flexible forms (i.e. IoT configuration information)
application with other endpoints, and (7) peer-to-peer media sessions to
support, negotiate, and manage media and other real-time
Fig. 5.11 HTTP caching sessions between devices and applications.
Fig. 5.12 HTTP caching flow
XMPP decentralization relies on messages being sent
client from one source device to its home server that, in turn,
request forwards the message directly to the server that serves the
destination endpoint. This scenario is illustrated in Fig. 5.13.
In XMPP networks, servers are directly connected to each
other to form a composite mesh network. This structure is the
proxy
server yes basic building block of the so-called XMPP federation. The
has copy?
XMPP federation additionally includes automated clients,
known as bots, that enable a wide range of services ranging
no
from assistance in chat rooms to interfaces to non-XMPP
services. As with any other IP based protocol, XMPP relies
proxy server on every device being identified by an address known as
request
Jabber Identifier (JID). JIDs follow the same format as e-
mail addresses that combine the username associated with an
sensor account with a domain as username@domain. The domain
response

XMPP server XMPP server

proxy server
response

5.2.3 XMPP

Another protocol that loosely follows the REST paradigm is

the eXtensible Messaging and Presence Protocol (XMPP).
XMPP, standardized as IETF RFC 6120, is an open session
layer protocol that relies on XML as the main format for in-
formation exchange. XMPP is a highly decentralized client-
server architecture supporting an unlimited number of servers
without a single point of failure [16]. XMPP is also extensive,
and it has been upgraded to support several applications XMPP client XMPP client
ranging from video games to IIoT. When compared to HTTP, application sensor
XMPP supports a built-in REST resource observation that
Fig. 5.13 XMPP network
relies on a push model of information that minimizes latency
5.2 Request/Response 121

is a fully qualified domain name (FQDN) that can be mapped Stanzas are the messages generated and processed by
to one or more IP addresses in accordance with domain name the XMPP application layer. They are defined by (1) their
system (DNS) mechanisms. element name, that is, message, presence, or iq; (2) their type
When a client connects to an XMPP server, a resource attribute, for example, get, set, or result; and (3) their child
identifier is assigned to the connection. This identifier is elements known as payloads. The message stanza is used to
added to the end of the JID as username@domain/resource. push data from, for example, a device to a client. Since the
Since a device is typically mapped to a resource and there is a transport layer is reliable (TCP), these messages are trans-
single connection per device, this functionality enables other mitted through a fire-and-forget mechanism that does not
entities to query or exchange messages with specific devices rely on acknowledgments and retransmissions. In the context
associated with a given account. Each device is a specific of IoT, messages are used to propagate sensor readouts.
point of presence of a given user that includes different states Message types are diverse, and they range from normal to
and capabilities. Note that although the username@domain chat and groupchat to address unicast and multicast real-time
is not case sensitive, the resource identifier section /resource communications. Messages of type error are sent in response
is. Moreover, JIDs follow URI schemes with full representa- to incoming messages to indicate a problem processing them.
tion as xmpp:username@domain/resource?action with xmpp Other attributes included are from and to attributes that are
being the service identifier and action a particular command used to specify sender and receiver, respectively, and the id
that can be used, for example, to send a message. attribute that provides a mechanism to track messages. Note
that to prevent address spoofing, the from attribute is filled
5.2.3.1 XMPP Messages in by the home server of the sender. Message payloads vary
XMPP is in essence a mechanism to signal and stream XML depending on the type and nature of message ranging from
over TCP connections. Specifically, if a device wants to body and subject for basic chat to fields for IoT sensor traffic.
start an XMPP session, it must first create a persistent TCP Some message payloads are specified as part of extensions to
connection to the server, and, when security is also required, the core XMPP specification.
a TLS session must be negotiated over the connection. The The presence stanza is used to advertise the availability
XMPP stream consists of the sequential build-up interaction of XMPP clients and resources in order to know whether
between a client and its home server made of three main they are online and available for communication. Presence
possible XML stanzas: (1) <message>, (2) <presence>, is based on a subscriber/notification scheme where entities
and (3) <iq>. An XML stanza is a discrete semantic unit issue presence subscriptions in order to obtain presence in-
of structured information that is sent from one entity to formation about other entities. When these subscriptions are
another. approved, any change of the presence status, for example, on-
Figure 5.14 shows an XMPP XML session where an ap- line or offline, is transmitted to each subscriber. The iq stanza,
plication acting as client/resource ([email protected]/amr) also known as info/query stanza, enables request/response
requests a sensor data readout from a device (de- interaction between entities by providing CRUD support as
[email protected]) and, later, the same client/resource per- illustrated in Fig. 5.15. Each request is replied by transmitting
forms actuation on another device (digital.output@example. a response that relies on an id attribute for tracking. The
org). The client establishes a persistent TCP connection iq stanza, as the message stanza, also includes from and
to its local server, and all bidirectional traffic including to attributes that are used to specify sender and receiver,
XML stanzas between the client (shown prefaced as C) and respectively. The representational state of an object can be
the server (shown prefaced as S) are transmitted inside a read if the iq stanza type attribute is get, or, on the other hand,
stream/stream element. If encryption and authentication are it can be created, updated, or deleted, if it is set. The type
needed, a TLS session is established on top of TCP to encrypt attribute result is used in responses to specify a readout value
traffic [17]. Because under XMPP TCP connections are or to acknowledge a set request. The xmlns attribute, included
persistent, devices can push readouts down the client as soon in iq stanza payloads, specifies the particular namespace or
as they become available. This asynchronous behavior, which XMPP protocol extension associated with the requests and
minimizes latency and lowers throughput, is conceptually responses.
like that of the observation introduced for IoT by ETSI. As previously indicated, because TCP transport
Obviously, the price to pay for persistent connections is the guarantees delivery, there is no need for XMPP message,
use of additional computational and memory resources. A presence, and iq stanzas to be acknowledged. If for some
client can simultaneously send several requests to a device reason a stanza is delivered but an error occurs due to, for
via its home server. These requests, in turn, are responded example, lack of resources, a response with type attribute
by the device in the order in which they were transmitted. error including a payload of type error is transmitted to
Note that the client is never blocked as it can transmit new the original sender. Figure 5.16 shows an error response
requests while waiting for previous responses. that indicates that the end device failed to process an iq
122 5 Application Layer

Fig. 5.14 XMPP XML

sequence (C = client, S = server)
5.2 Request/Response 123

how to handle architectures containing servers handling

multiple devices; and (10) XEP-0347 that introduces a device
discovery mechanism under XMPP.
The stream shown in Fig. 5.14 presents a stream composed
application sensor
of the interaction between a client and a device in accordance
with, first, XEP-0323 and then XEP-0325. The client starts
IQ-GET
by transmitting a get type iq stanza to the device identified
read by 50001 with a request payload with sequence number 1 in
order to obtain a sensor readout. The device responds right
ULT away by transmitting a result type iq stanza also identified
IQ-RES
by 50001 with an accepted payload indicated by sequence
number 1 that acknowledges the request. As soon as the
IQ-SET device gets a readout, it transmits a message stanza to the
client that includes a fields payload identified by the sequence
create
update
number 1 and indicating that is the only message to be trans-
delete mitted by means of the done attribute. The payload includes
ULT a node element that indicates the device source of the readout
IQ-RES
that, in turn, includes a timestamp element that provides the
actual sensor data readout. This readout is carried inside of a
numeric element that provides value and unit attributes. Next,
Fig. 5.15 IQ interaction
actuation is again started by the client that sends a set type iq
stanza to the device identified by 50002 with a set payload
that includes a boolean element. The element name attribute
request. These types of errors are recoverable, and they just identifies the port under which actuation is performed, and
indicate that there was a problem processing the request. the value attribute indicates the actual value to be set. The
Transport layer problems that affect the integrity of the device sets the value and replies with a result type iq stanza
XMPP stream are not recoverable and typically result in also identified by 50002 that carries an empty setResponse
the termination of the stream. Note that when compared to payload.
HTTP, XMPP only relies on persistent TCP connections that
are always present. This improves latency and response
times but increases the computational requirements of 5.2.4 CoAP
the devices. Encryption and authentication problems
associated with TLS follow under the umbrella of transport As opposed to HTTP and XMPP that were not designed with
problems. IoT in mind, CoAP is a lightweight session layer protocol
that has been intended from the very beginning to sup-
5.2.3.2 XMPP IoT Extensions port sensor and actuation data transmission in LLNs. CoAP
The core XMPP specification is functionally upgraded by was standardized by IETF as RFC 7252 The Constrained
means of XMPP extensions that are formally called XMPP Application Protocol (CoAP) in 2014. It is expected that
Extension Protocols (XEPs) [23]. In the context of IoT, CoAP will become the default protocol for access IoT in the
there are multiple extensions including (1) XEP-0000-IoT- coming years with support of billions of deployed devices all
BatteryPoweredSensors that defines how devices affected over the world. CoAP applications range from smart energy,
by power duty cycles must be handled; (2) XEP-0000-IoT- smart grid, building automation and control to intelligent
Events that deals with events and subscriptions; (3) XEP- lighting control, industrial control systems, asset tracking,
0000-IoT-Interoperability that describes interoperability and environment monitoring [21]. CoAP also provides its
mechanisms between different types of devices; (4) XEP- own proprietary mechanism for resource discovery that is
0000-IoT-Multicast that presents how sensor data can be presented in detail in Sect. 6.4.
multicast in efficient ways; (5) XEP-0000-IoT-PubSub that One of the most important differences between CoAP and
indicates how sensor data can be published; (6) XEP-0000- competing technologies like HTTP and XMPP is that the
IoT-Chat that describes human-to-machine (H2M) interfaces former relies on UDP as a transport layer. Since UDP, as
relying on chat messages; (7) XEP-0323 that introduces opposed to TCP, is connectionless, it can be used not only in
the architecture, operations, and data structures for sensor unicast scenarios but also with multicast and broadcast M2P
data transmission; (8) XEP-0325 that describes how to applications that are representative of many IoT scenarios.
provide actuation and control; (9) XEP-0326 that defines UDP also improves latency since it does not include any built-
124 5 Application Layer

Fig. 5.16 XMPP XML error

attribute

Fig. 5.17 CoAP/HTTP proxy ACCESS CORE

GET GET
request request
GW IP
2.05 Content 200 OK
device proxy application
CoAP server HTTP client

CoAP HTTP

UDP TCP

IPv6 IPv4

6LoWPAN

IEEE 802.15.4 IEEE 802.11

in retransmission mechanism that might introduce additional both CoAP and HTTP are stateless protocols, the mapping
delays due to packet loss. This is in opposition to TCP trans- occurring at the gateway is also stateless.
port as described in Sect. 4.3.7. In addition, because UDP Besides providing a session layer mechanism like HTTP
is not a stream protocol like TCP, it provides a technology but relying on UDP to enable multicast transmissions and
for the delivery of independent messages, enabling CoAP low latency, CoAP uses binary encoding to lower its trans-
for asynchronous message exchanges that eliminate HOL mission rate. Since CoAP traffic is intended to be encap-
blocking exhibited by certain versions of HTTP. Note that sulated by technologies with small MTU sizes like IEEE
although it is not recommended, CoAP TCP transport has 802.15.4, ASCII encoding like that of HTTP and XMPP
been introduced by IETF RFC 8323 as an alternative for results in too much overhead that makes it impractical in
certain scenarios where the complex TCP congestion control LLNs. The inherent lack of reliability of UDP is compen-
mechanisms provide a viable solution in certain LLNs [7]. sated by an optional retransmission mechanism embedded in
To improve latency, CoAP has incorporated block data trans- CoAP known as confirmable mode. The alternative mode of
mission as part of IETF RFC 7959 Block-Wise Transfers operation, known as non-confirmable, is based on a fire-and-
in the Constrained Application Protocol (CoAP) [6]. This forget approach where messages are sent without expecting
mechanism enables the efficient transmission of streams and any acknowledgment. Note that under CoAP, transport layer
other structured data. functionality responsible for providing network reliability is
As a REST protocol, CoAP was designed to map some moved to the session/application layer whenever confirmable
of the functionality provided by HTTP such that in an IoT mode is enabled.
infrastructure, CoAP is used in the access side, while HTTP
is used in the core of the network with the gateway acting 5.2.4.1 CoAP Basic Flows
as a proxy that translates traffic from one protocol to another. CoAP relies on a two-sublayer structure, shown in
This situation is shown in Fig. 5.17. The application, typically Fig. 5.18, with the lower message sublayer providing the
performing analytics, issues an HTTP GET request to retrieve interface with UDP transport and enabling retransmissions
sensor readouts. This message is transmitted over both TCP when confirmable mode is configured and the higher
and IPv4 and encapsulated in IEEE 802.11. The gateway request/response sublayer that is responsible for building
maps the HTTP request into a CoAP GET message that is and parsing the binary messages. In addition to confirmable
transported over both UDP and IPv6. IPv6 is adapted by and non-confirmable messages, the message sublayer
means of 6LoWPAN for encapsulation under IEEE 802.15.4. also includes acknowledgment and reset messages. The
At the sensor, the request triggers the transmission of a acknowledgment messages are sent in response to incoming
readout as a CoAP 2.05 Content response that is translated confirmable requests or responses, while the reset messages
into an HTTP 200 OK response at the gateway. Because are used to indicate a far end failure in processing an
5.2 Request/Response 125

application
DEVICE DATA

application device application device

REQUEST/RESPONSE CON [0x4d4 CON [0x4d45]
5]

CoAP
GET /tempe GET /tempera
rature ture
MESSAGES (token 0x21 (token 0x22)
)

]
x4d45

transport
]
UDP
ACK [0 tent x4d45
on ACK [0 ound
2.05 C x21) 4.04 N o t F
(token ”
0 0x22)
(token nd”
“20.1C “N o t F ou
Fig. 5.18 CoAP two-layer structure

Fig. 5.21 Piggybacked request/response

application device
(NON) request identified by a 16-bit 0x8c57 message identi-
CON [0x8c56]
fier. In this case, the device does not acknowledge the request.
For both cases, confirmable and non-confirmable requests,
ACK [0x8c56] if the receiver fails to process the message, it replies by
transmitting a reset (RST) response.
Independent of reliability, the request/response sublayer
Fig. 5.19 Confirmable CoAP transaction
is responsible for generating and parsing requests and re-
sponses. Figure 5.21 shows an example of a client requesting
a temperature readout from a sensor acting as a server. Since
the request is a CON CoAP GET, an ACK is transmitted back
by the server. Assuming the sensor has access to the readout
application device value, it piggybacks this value to the acknowledgment as a
CoAP 2.05 Content response. On the other hand, if the sensor
NON [0x8c57] does not support temperature readouts or it does not have a
valid value, it responds back with a CoAP 4.04 Not Found.
Note that all CoAP responses include a numerical response
code in a similar fashion to the mapping of HTTP shown
Fig. 5.20 Unreliable CoAP in Fig. 5.2. Response codes follow a a.bb format where a is
associated with the class of message: a = 2 means success,
a = 3 means redirection, a = 4 means client errors, and
incoming request or response. In all scenarios, confirmable,
a = 5 means server errors. Besides a message identifier that
non-confirmable, acknowledgment, and reset messages are
identifies the transactions, Fig. 5.21 also shows the presence
signaled by means of CON, NON, ACK, and RST message
of a field called token that is common throughout the trans-
types, respectively.
actions associated with a single session. In other words, the
Reliable message transport, shown in Fig. 5.19, relies on
token uniquely identifies the session through its lifetime. A
the client transmitting a confirmable (CON) request iden-
session, in turn, is given by the interaction between the client
tified by a 16-bit 0x8c56 message identifier. The device
and the device to retrieve different readouts of sensor data as
responds to the request by transmitting an acknowledgment
time progresses.
(ACK) also identified by the same 16-bit message identifier.
Alternatively, if the sensor does not have a temperature
A single request/response interaction indicated by a common
readout value available by the time it transmits the ACK
message identifier is a CoAP transaction. If, for whatever rea-
message, it delays its transmission until a readout is obtained
son, the confirmable message or its acknowledgment is not
either by polling or by means of hardware interrupts. This
received, the sender attempts to retransmit the message three
is illustrated in Fig. 5.22. The session is identified by token
more times, exponentially incrementing the timeout each
0x21. First, the client initiates a transaction identified by mes-
time. Similarly, Fig. 5.20 shows unreliable message trans-
sage identifier 0x4d45 by issuing a CON CoAP GET request
port that relies on the client transmitting a non-confirmable
to retrieve a temperature readout. The sensor acknowledges
126 5 Application Layer

0 2 4 8 16

VER T TKL CODE MESSAGE ID

TOKEN (if any, TKL BYTES)

application device
CON [0x4d45] OPTIONS (if any)
GET /temperature
11111111 PAYLOAD (if any)
(token 0x21)
VER version
T type
5]
ACK [0x4d4 TKL token length

... Fig. 5.24 CoAP message format

5]
CON [0x4d4
t
2.05 Conten 0x21 identifies the session. The sensor acting as server replies
(token 0x 21 )
“20.1C ”
by transmitting a NON 2.05 Content response as soon as a
temperature readout becomes available.
ACK [0x4d45]
5.2.4.2 Message Format
Figure 5.24 shows the encoding of a CoAP request or re-
sponse. The format consists of a variable sequence of extensi-
Fig. 5.22 Separate response model ble binary fields that are optimized to lower throughput while
providing some basic compatibility with HTTP. Moreover,
since CoAP relies on UDP transport (running on port 5683),
and because of its compact format, it is ideal for transmission
on top of 6LoWPAN and wireless IoT link and physical layer
application device mechanisms like IEEE 802.15.4. A CoAP message has a 32-
NON [0x4d45]
GET /tempera bit header followed, if present, by the variable length token
ture
(token 0x21) plus a sequence of options that provide functionality like that
of HTTP headers. The payload, also if present, follows the
options.
NON [0x4d45]
The fixed-length header starts with a 2-bit version field
2.05 Content that is always 1 with other values reserved for future versions;
(token 0x21) it follows a 2-bit type field that specifies whether the CoAP
“20.1C”
message is CON (0), NON (1), ACK (2), or RST (3) and
continues with a 4-bit token length that specifies the length in
bytes of the session identifier token (0 through 8 with lengths
larger than 9 being reserved). The next field includes an 8-
Fig. 5.23 Non-confirmable request/response model bit code that is encoded, as previously mentioned, as a.bb
where a is a 3-bit class digit between 0 and 7 and bb is a 5-bit
the request by sending an empty ACK response. When the detail number between 0 and 31. If a is 0, the message is a
temperature readout becomes available, the sensor transmits request, and otherwise it is a response encoded as specified
the response to the original request by transmitting a CON in the previous paragraph. If it is a request, the value of bb
2.05 Content message. Since this transmission is related to identifies its nature (GET if bb=01, POST if bb=02, PUT
the original CoAP request, it belongs to the same trans- if bb=03, and DELETE if bb=04). The fixed-length header
action and, therefore, shares the same message identifier. ends with a 16-bit message identifier used for transaction
Finally, the content message by being confirmable requires identification.
the client to acknowledge it by transmitting an empty ACK The options are encoded, as shown in Fig. 5.25, as a
response. sequence of TLVs used for both requests and responses. The
Figure 5.23 shows a non-confirmable request and re- original option types, as defined by IETF RFC 7252, are
sponse interaction. Since it is unreliable, there is no need shown in Table 5.3. The option type is differentially encoded
for acknowledgment. The client first sends a NON CoAP in order to use fewer bytes to represent it. The option length
GET request to retrieve a temperature readout. The message is encoded as an absolute value. Options are encoded in
identifier 0x4d45 identifies the transaction, while the token id ascending order of their type such that for a given option,
5.2 Request/Response 127

0 4 7
Example 5.2 Consider an end-to-end non-confirmable
OPTION TYPE DELTA OPTION LENGTH 1 byte CoAP scenario where an application requests a readout
from a sensor:
OPTION TYPE DELTA (EXTENDED) 0-2 bytes
GW application

OPTION LENGTH (EXTENDED) 0-2 bytes GET

GET

sensor event 2.05 Content

OPTION VALUE 0+ bytes 2.05 Content

IEEE 802.15.4/6LoWPAN Ethernet/IPv4

Assume the following: (a) the IEEE 802.15.4

Fig. 5.25 Options encoding transmission rate is 250 KBps, (b) the Ethernet
transmission rate is 1 Gbps, (c) the only delay is the
Table 5.3 CoAP option types transmission delay, (d) the UDP header is LUDP = 8
Option name Option type bytes long, (e) the CoAP GET request is LGET = 20
If-Match 1 bytes long, (f) the CoAP 2.05 Content response is
Uri-Host 3 L2.05 Content = 10 bytes long, (g) the IPv4 header is
ETag 4 LIPv4 = 20 bytes long, (h) the 6LoWPAN header is
If-None-Match 5 L6LoWPAN = 10 bytes long, (i) the Ethernet header is
Location-Path 8 Leth = 16 bytes long, and (f) the IEEE 802.15.4 header
Uri-Path 11 is LIEEE 802.15.4 = 10 bytes long. How long does it
Content-Format 12 take for the application to receive the readout? How
Max-Age 14 does it compare to the results obtained in Example 5.1?
Uri-Query 15
Accept 17 Solution: The overall delay is given by T = T1 + T2
Location-Query 20 where T1 is given by T1 = 8×(Leth +LIPv410+L 9
UDP +LGET )
+
Proxy-Uri 35 8×(LIEEE 802.15.4 +L6LoWPAN +LUDP +LGET )
250000
= 1.54 ms. T2
Proxy-Scheme 39
Size1 60
is given by T2 = 8×(Leth +LIPv4 +L UDP +L2.05 Content )
109
+
8×(LIEEE 802.15.4 +L6LoWPAN +LUDP +L2.05 Content )
250000
= 1.22 ms. The
total delay is, therefore, T = 2.76 ms. As expected,
its type value is represented as a delta with respect to the a CoAP session exhibits a latency that is a lot smaller
previously encoded option type. The very first option of the than that of an HTTP session.
sequence is encoded assuming that the previous option type
is zero. The option type delta is encoded as a 4-bit number The Uri-Host, Uri-Port, Uri-Path, and Uri-Query options
if it smaller than 13; otherwise, if it is smaller than 256, it is are used to specify the target resource of a request to a
encoded as 13 with an extension byte representing the actual CoAP origin server. The Proxy-Uri option is used to make
type delta. Similarly, if the delta is larger than 255 but smaller a request to a forward-proxy. The Content-Format option
than 65536, it is encoded as 14 with a 2-byte extension indicates the representation format of the message body. The
representing the actual type delta. Multiple instances of the Accept option can be used to indicate which Content-Format
same option type are encoded using a delta of zero. The is accepted from the server. The Max-Age option specifies
option length is encoded as an absolute value following the the maximum time a response may be cached before it is
same mechanism, attempting to use the fewer number of bits considered not fresh. The Entity Tag (ETag) is used as a
to represent its value by relying on extension bytes whenever resource local identifier for differentiating between repre-
necessary. In all cases, the option value follows the encoded sentations of the same resource that vary over time. The
type and length. Figure 5.26 illustrates an example where Location-Path and Location-Query options together indicate
the Uri-Path is an 11-byte string Temperature and Max-Age a relative URI that consists of an absolute path, a query
is a 2-byte integer 3600. Since the Uri-Path option type is string, or both. The If-Match option is used to make a request
encoded as 11, the Max-Age option type, which has a value conditional on the current existence or value of an ETag for
14, is encoded as a 3.
128 5 Application Layer

Fig. 5.26 Uri-path and max-age 0 2 4 8 16

encoding example
1 0 0 GET = 1 MID = 0x7d34

11 11 “temperature” (11 BYTES) …

… 3 2 0xe10 (3600)

Fig. 5.27 Piggybacked response

application device
Header: GET (T = CON, Code = 0.01, MID = 0x7d34)
GET
Path: “temperature”
2.05 Header: 2.05 Content (T = ACK, Code = 2.05, MID = 0x7d34)
Payload: “22.3 C”

0 2 4 8 16
1 0 0 GET = 1 MID = 0x7d34

11 11 “temperature” (11 BYTES)

0 2 4 8 16
1 2 0 2.05 = 69 MID = 0x7d34

11111111 “22.3 C” (6 BYTES)

one or more representations of the target resource. The If- is set to a random duration between ACK_TIMEOUT
None-Match option is used to make a request conditional and ACK_TIMEOUT * ACK_RANDOM_FACTOR
on the nonexistence of the target resource. The Size option seconds, and the retransmission counter is set to zero.
provides size information about the resource representation When the timeout is triggered and the retransmission
in a request. counter is less than MAX_RETRANSMIT, the message is
Figure 5.27 shows a single transaction between a client retransmitted, the retransmission counter is incremented, and
and device acting as a server where the request is a CON the timeout is doubled. If the retransmission counter reaches
GET that includes a single Uri-Path temperature option. MAX_RETRANSMIT on a timeout, or if the endpoint
The response is an ACK that piggybacks a 2.05 Content receives a RST message, then the attempt to transmit the
that carries a 22.3C temperature payload. Figure 5.28 shows message is canceled and the application process informed of
another transaction for the same scenario that belongs to a failure.
larger session identified by the token number 0x20. An alternative scenario is shown in Fig. 5.30; in this case,
Figure 5.29 shows a client sending a CON GET request to the client issues a CON GET request. When the request
a device that responds back with an ACK that piggybacks a arrives at the destination, if the device does not have access
2.05 Content. The response never arrives to the client as it is to a recent readout, it just transmits a plain ACK. When,
dropped due to network packet loss. Since it is a confirmable later, the device, either by polling or by means of hardware
transaction, the request timeouts, and it is retransmitted a interrupts, obtains a valid readout, it transmits this value in a
few seconds later. When it arrives at destination, the sensor new CON 2.05 Content response. Of course, this response is
retransmits the ACK with the 2.05 Content response that is acknowledged after it is received.
then received by the client. This finalizes the transaction. The In Fig. 5.31, the client transmits a CON GET request, but
CoAP standard identifies three parameters that control trans- its application suffers an exception and crashes. The device
missions, MAX_RETRANSMIT, ACK_TIMEOUT, and replies with an ACK that arrives to the client by the time it has
ACK_RANDOM_FACTOR, with default values 4, 2, and already rebooted. The client ignores this acknowledgment as
1.5, respectively. For a new CON message, the initial timeout it cannot figure out what originated it. Moreover, since it is
5.2 Request/Response 129

Fig. 5.28 Piggybacked response

(and token)

application device
Header: GET (T = CON, Code = 0.01, MID = 0x7d35)
GET Token: 0x20
Path: “temperature”
2.05
Header: 2.05 Content (T = ACK, Code = 2.05, MID = 0x7d35)
Token: 0x20
Payload: “22.3 C”

0 2 4 8 16
1 0 0 GET = 1 MID = 0x7d35

0x20

11 11 “temperature” (11 BYTES)

0 2 4 8 16
1 2 0 2.05 = 69 MID = 0x7d35

0x20

11111111 “22.3 C” (6 BYTES)

application device
application device
TIMEOUT

Fig. 5.30 Confirmable request with separate response

device to transmit a RST message type to indicate that the

session is no longer available.
If network reliability is not a concern, the client can
Fig. 5.29 Confirmable request with piggybacked response transmit, as indicated in Fig. 5.32, a NON request that is not
acknowledged when it arrives at the device. If the message
just an acknowledgment and there is no action associated is dropped, there is no standard mechanism for the sender
with the message, it makes sense to ignore it. When the sensor to know that it has not arrived at the receiver. In either case,
readout becomes available, the device transmits a CON 2.05 if it does arrive, whenever a readout is available, the device
Content message that when, arrives at destination, causes the transmits a NON 2.05 Content response.
130 5 Application Layer

temperature readouts from all three devices in the link. Two

of them reply with NON 2.05 Content responses. One last
device does not provide temperature readouts and replies
with a NON 4.04 Not Found response.
application device

5.2.4.3 CoAP Observation

IETF RFC 7641 extends CoAP to natively support resource
CRASH + REBOOT observation [10]. Specifically, a new observe CoAP option
provides a mechanism for GET requests to retrieve current
and future representations of an object. Under this scheme,
each server keeps a list of observers that include entries
identifying clients and tokens associated with different CoAP
sessions. To this end, as soon as the GET request arrives at
the destination, the server adds an entry that identifies the
client as part of its list of observers. Consequently, this CoAP
GET request is an observation registration where the value of
Fig. 5.31 Confirmable request; separate response (unexpected) the observe option is 0. From that point on, whenever there
is a new sensor readout, either by polling or by means of a
hardware interrupts, the server transmits a 2.05 Content to
the client. The server sends the 2.05 Content response to each
one of the clients and sessions in its list of observers. When
application device a client does not wish to receive sensor readouts anymore,
it must deregister by transmitting a new CoAP GET with an
observe CoAP option set to 1.
Figure 5.34 shows a basic example of CoAP observation
with a client that registers by transmitting a NON GET
request to observe temperature information from the sensor.
The request includes an observe option set to 0. The resource
representation of the observed asset (or observed state) is
unknown at the time the request is sent. As soon as the
sensor obtains a temperature readout, it transmits a NON
2.05 Content response indicating a 18.5 ◦ C value. When this
response is received, the client updates the observed state.
Fig. 5.32 Non-confirmable request; non-confirmable response Similarly, when the next readout becomes available, the client
transmits a new NON 2.05 Content response indicating a
19.2 ◦ C value. Again, when this response is received, the
 CoAP Implementations There are many commercial
client updates the observed state accordingly. Note that CoAP
and open-source CoAP implementations with support
observation responses also include an observe option that is
ranging from common constrained RTOSs to general-
set, in this case, to provide timing information based on a
purpose Linux distributions. The list below shows
centralized clock. The token and message identification fields
some of the most popular CoAP implementations.
are the same as those of the original GET requests since the
overall observation can be thought of as a single transaction
cancoap BSD-licensed C/C++ implementation of client and server. within a single session.
eCoAp MIT-licensed C implementation of client and server. The session continues as it is indicated in Fig. 5.35. The
Erbium BSD-licensed C implementation (for Contiki) of client and sensor sends a 19.2 ◦ C readout and then crashes. When it
server. reboots, it has no context of the observation session, so it
libcoap GPL-licensed C implementation of client and server. stops transmitting updates even when new readouts become
nanocoapLGPL-licensed C lightweight implementation of client and available. The client eventually timeouts and issues a new
server.
NON GET request to reregister and observe temperature
information from the sensor. The request includes new token
and message identification fields as it starts a new transaction
One last scenario to consider is shown in Fig. 5.33. The in a new session. The server proceeds by transmitting NON
client transmits a multicast NON GET request to obtain 2.05 Content responses carrying temperature readouts.
5.2 Request/Response 131

Fig. 5.33 Non-confirmable

request (multicast);
non-confirmable response

application device device device

ff02::1

Fig. 5.34 CoAP observation

OBSERVED STATE application device REAL STATE

UNKNOWN
18.5 C

18.5 C

19.2 C

19.2 C

5.2.4.4 CoAP and DTLS One of these issues, already introduced in Sect. 4.3.6.3, is
CoAP security is provided by means of the DTLS protocol the fact that the DTLS handshake exchanges large certifi-
presented in Sect. 4.3.6.3. The main motivation for using cates that lead to fragmentation and, thus, datagram loss in
DTLS is the fact that CoAP uses UDP transport and DTLS is LLNs. Moreover, alternatives like elliptic-curve cryptogra-
intended to work on top of UDP. IETF RFC 7925 addresses phy (ECC) that provides smaller keys and certificates, for
some of the requirements needed for DTLS to run in the comparatively same levels of security as traditional RSA and
context of CoAP [22]. Note that although DTLS is simpler DSA security, are too complex to be supported in embedded
than IPSec/IKE and HIP, some features of the protocol devices. Another important issue is that DTLS is not prepared
are too complex to be supported with lightweight CoAP. to work well with CoAP proxies. Moreover, CoAP relies
132 5 Application Layer

Fig. 5.35 Client reregistration

OBSERVED STATE application device REAL STATE

19.2 C
19.7C

19.7 C
CRASH

REBOOT
20.0 C

19.7 C (STALE)

20.0 C

19.7 C

19.7 C

heavily on multicast communications to enable applications chitecture perspective, it is an application layer protocol
to simultaneously talk to multiple devices. Unfortunately, that provides session layer functionality. Although sessions
DTLS does not natively support multicasting as security could be of any type, SIP has been mostly used in the
relies on end-to-end session establishment based on a hand- context of RTC with special focus on Media over IP (MoP)
shake. In this scenario, security is provided through a double- applications like bidirectional speech, audio, and video. IETF
stage mechanism where devices are first discovered through also recommends a specific protocol known as RTP for
multicasting and then secure associations are made with each media packetization. Note that RTP was briefly described in
device by means of unicast connectivity through DTLS. Sect. 1.4. Media packetization is the process that enables the
Both confirmable CoAP and DTLS introduce inefficient conversion of a stream of media into messages or packets that
retransmissions because each new CoAP retransmission re- are transmitted over IP. There have been several attempts to
sults in a new DTLS transmission. Moreover, CoAP and support SIP and RTP in the context of IoT for both media and
DTLS provide similar functionality at two different layers device data transmission.
unnecessarily increasing the code size. An alternative is, in
this situation, to rely on non-confirmable CoAP for transmis-
5.2.5.1 SIP
sions. Another issue with CoAP and DTLS is the fact that
SIP is a client/server protocol that is structurally like HTTP
the latter does not support fragmentation of application data.
as it includes ASCII encoded requests and responses with
It is therefore recommended for applications to attempt to
headers and methods [18]. SIP, as opposed to HTTP, however,
fit every single CoAP message and associated headers into a
was designed for UDP transport in order to lower the latency
single IP datagram to avoid any fragmentation.
usually associated with TCP connection setup and retrans-
missions. Later when security was introduced to SIP by
5.2.5 SIP and RTP means of TLS, TCP became an additional transport option.
Regardless of the transport, SIP is highly inefficient in IoT
SIP, briefly described in Sect. 1.4, provides a mechanism scenarios because it relies on plain text messages to establish
to create, manage, and finish sessions. From a layered ar- and manage sessions. Moreover, because SIP does not really
5.2 Request/Response 133

comply with the RESTful model either, it is not really useful being dropped. This field is used to prevent SIP routing loops.
for IoT device management. The From and To headers specify the source and destination
A SIP client is called User Agent Client (UAC), while a endpoints including tags that are random numbers assigned
SIP server is called User Agent Server (UAS). UACs gen- to the entities for identification. The Call-ID header value,
erate requests, while UASs generate responses for incoming in this case [email protected], combined
requests. A SIP transaction is a request/response interaction with the From and To header values is used to identify the
between a UAC and a USC. Similarly, a SIP dialog is several dialog. The CSeq header value, in this case 1021 INVITE,
transactions associated with a given session. A UAS can be contains an integer and the method. When a transaction
(1) a media server that generates audio, speech, and/or video starts, the first message is given a random CSeq value that
traffic to UACs; (2) a proxy server that, similar to HTTP is incremented upon transmission of new messages. Again,
proxies, acts on behalf of a client to interact with other UASs; this enables endpoints to detect out of order and lost mes-
(3) a redirect server that redirects UAC requests to other sages as UDP is the preferred SIP transport method. The
UAS; or (4) a registrar that keeps track of the location of Contact header specifies a direct route to the UAC used
UACs to support incoming sessions. by certain responses. The Content-Type header indicates the
By not being RESTful, SIP relies on different request type of content the request includes. In this example, the
types or methods that are transmitted by a UAC: INVITE to content is application/sdp that specifies session character-
start sessions, ACK to provide reliability since SIP is primary istics by means of the SDP protocol briefly described in
supported over unreliable UDP transport, BYE to terminate Sect. 1.4. The Content-Length indicates how big the body
sessions, CANCEL to cancel a pending request, OPTIONS is.
to request UAS capability information, REGISTER for a The SDP is a whole different protocol that is used to
UAC to register with a registrar, and INFO for out-of-band describe media sessions in a way that can be understood by
signaling of, for example, audio tones. all endpoints in a network [14]. As such, SDP provides a
SIP messages are ASCII encoded, and therefore they can mechanism for negotiation, where an endpoint can decide
be read by humans on the wire by means of network sniffers to accept an incoming session based on whether it supports
and analyzers. The message below is an example of a SIP specific media types. The SDP content is ASCII and, as SIP
request transmitted by a UAC attempting to start a new messages themselves, is not efficient in the context of IoT
session: communications. In either case, an SDP typically indicates
INVITE sip:[email protected] SIP/2.0 the list of specific media encoding technologies or codecs
Via: SIP/2.0/UDP server1.local;branch=z9hG4bK2105Gbc12 that are offered by a given endpoint, along with connectivity
Max-Forwards: 70 parameters like IP addresses and transport ports. Informa-
From: <sip:[email protected]>; tag=1921052105 tion is presented as lines formatted as parameter=value,
To: <sip:[email protected]> where the parameter is a single character. In the example
Call-ID: [email protected] above, for example, the v=0 line specifies the SDP version,
CSeq: 1021 INVITE c=IN IP6 2001::21:10 indicates the endpoint IP address, and
Contact: <sip:[email protected]> m=audio 5100 RTP/AVP 0 signals the type of media (audio),
Content-Type: application/sdp the media protocol (RTP), the UDP port (5100), and the
Content-Length: 112 codec code (0) that specifies ITU G.711 μ-Law coding. The
a=sendrecv indicates that media traffic is intended to be full
v=0 duplex.
o=session 5439349 2394349324 IN IP6 deviceA.local Like requests, the format of SIP responses follow that of
s=SDP exchange HTTP responses shown in Fig. 5.9. The message below is an
c=IN IP6 2001::21:10 example of a SIP response transmitted by a UAS as a reply
t=0 0 to an INVITE request:
m=audio 5100 RTP/AVP 0 SIP/2.0 200 OK
a=sendrecv Via: SIP/2.0/UDP server2.local;branch=z9hG4bK1chab10;
received=2001::21:20
The format of SIP requests follows that of HTTP requests From: <sip:[email protected]>; tag=1921052105
illustrated in Fig. 5.8. It includes a request line that specifies To: <sip:[email protected]>; tag= 42194562
the method, in this case INVITE, the request URI, and the Call-ID: [email protected]
SIP version that is typically 2.0. The Via header indicates CSeq: 1021 INVITE
the local address that is used to receive the response. The Contact: <sip:[email protected]>
Via header includes a Max-Forward field that specifies the Content-Type: application/sdp
maximum number of hops the request must support before Content-Length: 110
134 5 Application Layer

Table 5.4 SIP response codecs

Range Meaning
100–199 Provisional
200–299 Success
300–399 Redirect UAC UAS
400–499 Client errors
500–599 Server errors

transaction 1
600–699 Global failure

v=0
o=session 2841303 91021765 IN IP6 deviceB.local

dialog
s=SDP exchange
c=IN IP6 2001::21:20
t=0 0 MEDIA SESSION
m=audio 5102 RTP/AVP 0

transaction 2
a=sendrecv

The first line of the response is the status line that in-
cludes the SIP version, the numerical status code, and the
corresponding status message or reason phrase. Although SIP
response codes follow the HTTP response codes, there are
Fig. 5.36 SIP call
some slight differences as shown in Table 5.4. Responses
between 100 and 199 are provisional, in the sense that they
indicate that a final response 200 or above will follow at not include any media information. Next, the UAS transmits
some point. For the example above, the SIP version is 2.0, a 200 OK that contains negotiated media. Because of the
the numerical status code is 200, and the reason phrase unreliable UDP transport, the client responds to the 200 OK
is OK. The Via header indicates the local address that is with an ACK on what it is called a three-way handshake.
used to receive the response including the specific IP ad- Once media endpoints have been identified, a bidirectional
dress of the interface that received the message. The From, RTP session starts. At this point, packetized media datagrams
To, Call-ID, and CSeq headers are copied over from the flow between endpoints. After a while, the client transmits
INVITE request. The UAS adds a tag to the To header. a BYE request to indicate it wants to terminate the media
As with the UAC, the UAS Call-ID header value, in this session. Upon reception, the server transmits another 200 OK
case [email protected], combined with the to confirm. This latter 200 OK does not carry a body as it does
From and To header values is used to identify the dialog. not need to specify media information.
The Contact header specifies a direct route to the UAS SIP, as HTTP, is a protocol that was not designed to be
used by subsequent requests. Because the response to an used in the context of LLNs. For example, SIP messages
INVITE has media negotiation information, the Content- are unnecessarily too big to fit in a single frame of link
Type and Content-Length header values indicate that the layer technologies like IEEE 802.15.4. This situation leads to
message body has an SDP content that signals the negotiated fragmentation, and, thus, it increases the chances of network
codec. loss. Although there have been several proposals intended
Figure 5.36 shows a dialog between a UAC and a media to adapt SIP to IoT networks, none of them have been
server UAS. This dialog is made of two transactions: one to really standardized. In this regard, it is important to mention
establish a media session and another one to tear it down. The constrained SIP (CoSIP). CoSIP attempts to compress SIP
session establishment transaction starts when the client trans- header information by relying on a message format identical
mits an INVITE request to the server. The INVITE carries an to that of CoAP shown in Fig. 5.24. Under CoSIP, message
SDP that provides the client side media offering. The UAS types do not encode REST methods like GET and POST but
transmits a provisional 100 Trying response to let the client encode session establishment, maintenance, and termination
know that the INVITE has been received and it is trying to messages like INVITE and BYE. CoSIP follows the same
respond. Right after, the UAS transmits another provisional convention of CoAP for the inclusion of headers in messages
180 Ringing response to tell the client to generate a ring by means of differentially encoded options. Also, in order
tone, while the INVITE request is being processed. Both to support the efficient transmission of messages in LLNs,
provisional responses do not carry a body and therefore do CoSIP relies on UDP and DTLS transport as opposed to the
5.2 Request/Response 135

TCP and TLS transport of traditional SIP. Fortunately, there is For the purpose of synchronization, a receiver relies on
standard mechanism to compress SIP headers that despite the SSRCs to identify streams and the sequence number to
fact that it was not developed with IoT in mind, it can be used determine what media packets to play next. Specifically,
in LLNs. Specifically, IETF RFC 5049 Applying Signaling since the sequence number is incremented every time a
Compression to the Session Initiation Protocol merges tra- packet is transmitted, the receiver can estimate packet loss
ditional SIP with signal compression (SigComp). SigComp and attempt to restore the packet sequence. Along with the
is a standard mechanism for the compression of signaling sequence number, the timestamp field provides another key
information associated with call establishment, termination, piece of information. This field tells the receiver when to play
and network registration. media packets and provides information about synchroniza-
tion. There are certain applications like video, where several
5.2.5.2 RTP and RTCP sequential RTP packets carry the same timestamp as they
RTP provides the end-to-end real-time delivery of audio, represent a single video frame. In most audio and speech
speech, and video sessions [19]. An RTP session is set scenario, however, timestamps change with the sequence
up through SIP negotiation by means of SDP information numbers.
exchange. RTP is transported over UDP to guarantee that RTP is a generic protocol that provides functionality that
latency is minimized, as in the context of media transmissions has different meanings depending on the codec under con-
any media packet that arrives too late can be considered sideration. For example, the extension bit is used to indicate
lost. In fact, most RTP applications rely on playout buffers that an extension header follows the RTP header. The ex-
that queue packets during a typically short interval of time tension header, in turn, may carry additional fields that are
before they are sequentially played. The idea behind this relevant to the codec. Similarly, the marker bit is typically
mechanism is to reduce the choppiness that results from used, depending on the codec, to specify when a stream
playing packets that arrive at an irregular pace. Additionally, starts. This is important when a codec supports discontinuous
since RTP relies on UDP for transport, it is ideal for multi- transmissions (DTX). Under DTX, voice activity detection
cast transmissions. Specifically, in multicast conferencing, a (VAD) may trigger a period of silence under which the codec
single transmitter can reach multiple receivers with a minimal does not produce any frames. Once speech is detected again,
amount of traffic. RTP supports multiple simultaneous media the media stream restarts, and this is signaled by setting the
types, so a single SIP dialog can set up multiple synchronized marker bit in the RTP header.
audio and video streams. Other applications of RTP include The RTP suite provides an additional protocol called
transcoding where a device re-encodes a media streaming Real Time Control Protocol (RTCP) that is used to provide
using a codec that is different to the one originally used. Note quality control over media streams. Essentially, for each RTP
that transcoding is performed by means of signal processing stream, there is an optional associated RTCP stream that
techniques that are computationally complex. enables receivers to provide feedback about the quality of
Media streams are packetized and encoded with an RTP the incoming media packets. The RTCP stream, as the RTP
header shown in Fig. 5.37. The header starts with a 2-bit stream, is transported over UDP typically using contiguous
version field that is always set to 2, and it continues with ports. As such RTCP is particularly important in the context
a padding bit to signal whether additional padding bytes, of conferencing multimedia applications. RTCP is associated
needed by certain codecs, follow the payload. The last byte with an RTP stream through its canonical name (CNAME)
of the padding indicates how long the padding is. The header and not through its SSRC, since the SSRC may change during
then includes an extension bit to signal that an extension a session. RTCP can include extra information for reference
header follows the RTP header; a 4-bit CSRC count field that like an e-mail address or a phone number. Figure 5.38 shows
specifies the number of contributing source (CSRC) fields, the format of a generic RTCP header. It starts with a 2-bit
described below, included in the header; a marker that is used version field that is always set to 2 and continues with a
for multiple purposes; a 7-bit payload type that identifies padding bit that indicates that additional bytes follow the for-
that codec that encodes the media packet payload; a 16-bit mat specific information payload. The header also includes
sequence number used by receivers for reordering and packet a 5-bit item count that indicates the list of items carried in
loss detection; and a 32-bit timestamp that specifies the sam- the payload, an 8-bit packet type that specifies the RTCP
pling instant of the first byte in the payload. The timestamp message type, and a 16-bit length that specifies the size of
is critical for synchronization and jitter estimations. The the payload that follows the RTCP header.
headers also include a 32-bit synchronization source (SSRC) There are many types of RTCP messages that are used
random number that identifies the stream and a list of 32- to indicate different types of information: (1) a sender re-
bit CSRCs for the payload contained in the packet. This is port (SR) for transmission and reception statistics from ac-
typically used in the context of mixers that are applications tive senders, (2) a receiver report (RR) for reception statis-
that combine multiple media streams into one. tics from passive senders, (3) a source description (SDES)
136 5 Application Layer

Fig. 5.37 RTP header format 0 2 3 4 8 9 16 31

V P X CC M PT SEQUENCE NUMBER
TIMESTAMP
SSRC
CSRC 1

CSRC n

MEDIA PACKET

V version
P padding
X extension
CC CSRC count (n)
M marker
PT payload type
SSRC synchronization souce
CSRC contributing sources

0 2 3 8 16 31

V P IC PT LENGTH

FORMAT SPECIFIC INFORMATION PAYLOAD

PADDING (if P = 1)

V version
P padding
IC item count
PT packet type

Fig. 5.38 RTCP header format

for a description of a sender including the CNAME, (4) functionality provided by IoT-RTP and IoT-RTCP is slightly
a BYE message to indicate the end of participation in a larger packets due to the overhead.
session, and (5) an APP message for application-specific
functions.
One good thing about both, RTP and RTCP, is that they 5.2.6 OPC UA
exhibit a highly optimized structure with small headers that
are ideal for LLNs. Moreover, since RTP packets typically The Open Platform Communications United Architecture
carry codec compressed media frames, the RTP payload is (OPC UA) provides a protocol stack that supports the SOA
also optimal for IoT. In all cases, chances of fragmentation approach [20]. This protocol stack, shown in Fig. 5.39, com-
when transmitted over link layer technologies like IEEE plies with the request/response scheme of session protocols
802.15.4 are greatly reduced. When compared to SIP, HTTP, like CoAP and HTTP, but as a stack, it specifies additional
and other mainstream protocols, and because of its IoT functionality. Moreover, OPC UA not only addresses com-
readiness, there have not been that many attempts to further munication, security, and session management needs, but it
optimize the RTP protocol suite. Moreover, there have been also deals with data modeling that enables the interaction of
some proposals, but none of them have led to standards. One heterogeneous devices in the context of IIoT.
of these proposals introduces IoT-RTP and IoT-RTCP that, With constrained networks in mind, OPC UA introduces
respectively, optimize RTP and RTCP for support in LLN two different mechanisms for data encoding: (1) XML and
networks. IoT-RTP adds a few new fields to the standard RTP (2) binary. The generic UA XML encoding provides mes-
header to divide large media sessions into simpler sessions sages that are human readable, but it is expensive from a
that can adapt better to network changes while keeping networking and processing perspective. UA binary encoding,
track of energy consumption. On the other hand, IoT-RTCP on the other hand, is more efficient and designed to work in
is also upgraded to carry additional information about the constrained environments. Unfortunately, both mechanisms
transmitter including energy levels. The price to pay for the are transmitted over traditional TCP and subjected to all the
5.3 Publish/Subscribe 137

topic respond by issuing a subscription. The broker binds

XML binary
the topic to the endpoint in its internal database, and the
WS Secure Conversaon endpoint then becomes a subscriber. Whenever the publisher
generates a sensor readout or event, the broker forwards it,
SOAP 1.2 as a notification, to all the corresponding subscribers.
UA nave Publish/subscribe systems have been traditionally used
HTTP in several application domains that involve the distribution
of large-scale events, including (1) financial information
TCP
systems, (2) streaming of live feeds of real-time traffic, (3)
support for cooperative working, (4) support for ubiquitous
Fig. 5.39 OPC UA stack
computing, and (5) monitoring applications.
Publish/subscribe systems have two main characteristics:
limitations associated with TCP in LLNs. On the other hand, The first is (1) heterogeneity where brokers can handle sub-
the selection of TCP as transport is because TCP traffic is a scriptions and notifications from entities that are not designed
lot less likely to be rejected by backbone firewalls than UDP for interoperability. Essentially, multiple topics and events
traffic. are present in a single publish/subscribe scenario where the
UA XML payloads are transmitted over HTTP and option- broker just forwards the messages without processing their
ally transported over TLS. Rather than transmitted directly content. Only requirement is a common interface for brokers
over HTTP, XML messages are first encoded by means of to understand how to process subscriptions and notifications.
the standard Simple Object Access Protocol (SOAP). SOAP The other characteristic is (2) asynchronicity where both
introduces both a structure for the encoding of XML data and subscribers and publishers do not need to be synchronized as
a mechanism for the exchange of messages. OPC UA intro- the broker provides the infrastructure necessary to keep track
duces an additional level of security by means of the Web of events by means of buffering and storing. Specifically, if
Services Security Conversation WS Security Conversation. an endpoint publishes an event, under the right conditions, it
WS Security Conversation, as opposed to TLS that supports is guaranteed that a subscriber will receive that event at some
transport security, provides session level security that opti- point.
mizes the exchange of long messages. UA binary data can Figure 5.40 summarizes the small operations involved in
also be transmitted over HTTP but, more importantly, over the publish/subscribe model: (1) advertise(t) is sent by a pub-
a UA native protocol that provides simple mapping directly lisher to declare a topic t that represents future events to be
over TCP. Note that there is an increasing tendency to support published, (2) unadvertise(t) is sent by a publisher to revoke
OPC UA data and message models over other IoT session the previous advertisement of a topic t, (3) subscribe(t) is
mechanisms including not only request/response ones like sent by an endpoint to subscribe to a specific topic t, (4)
CoAP but also publish/subscribe protocols like MQTT and unsubscribe(t) is sent by a subscriber to revoke an active
AMQP. subscription on topic t, (5) publish(e) is sent by a publisher
to forward an event e to the broker, and (6) notify(e) is sent
by the broker, as a result of an incoming published event t,
5.3 Publish/Subscribe to broadcast it to all the subscribers associated with the topic
that the event belongs to.
The publish/subscribe model, also known as subscribe/publish The broker is the main component responsible for
model, consists of an event-based architecture that provides dispatching events from publishers to interested subscribers
built-in observation in compliance with IoT requirements. in the publish/subscribe system. The publish/subscribe model
As opposed to request/response, the publish/subscribe can be either centralized or distributed. The centralized
paradigm relies on one or many entities known as brokers model relies on a single broker with P2P connections
that provide services by collecting, storing, and forwarding from the publishers to the broker and from the broker
events to and from endpoints. Each broker has a number of to the subscribers. The broker has one or more internal
endpoints associated with it such that a single endpoint only queues where incoming events are stored before they can be
communicates with a single broker. In addition, endpoints distributed to subscribers. If the event arrival rate is larger
can behave like a publisher and/or like a subscriber. In than the queue processing rate, the queues can become full,
the context of IoT, an analytics application is typically a and newly arrived events get dropped causing application
subscriber, while a device plays the role of publisher. The packet loss. Therefore, in this centralized scenario, the broker
publisher advertises the type of event, known as topic, that can end up being a bottleneck due to congestion. On the other
it can generate, and the brokers broadcast this information hand, the decentralized model attempts to prevent this and
to all other endpoints. Those endpoints interested in each other problems by replacing the broker by a network of
138 5 Application Layer

Fig. 5.40 Publish/subscribe publish (e1)

subscribe (t2)
model

unadvertise (t1) notify (e1)

SUBSCRIBE/NOTIFY SYSTEM
BROKER

unsubscribe (t1)
advertise (t2)

notify (e2) notify (e1)

brokers that cooperate to provide redundancy and enhance connections to go down. To prevent application traffic from
functionality and service levels. being lost when TCP fails, MQTT introduces an additional
level of reliability by means of the QoS levels. Unfortunately,
TCP transport, as indicated in Sect. 4.3.7, when subjected
5.3.1 MQTT to network packet loss results in retransmissions that in-
crease latency and prevent applications from successfully
MQTT is a lightweight broker-based publish/subscribe ap- transmitting real time events. In 2013 MQTT was extended
plication protocol that provides session layer functionality. as MQTT for Sensor Networks (MQTT-SN) [11] to deal
MQTT was developed and designed by IBM in 1999 for in IoT scenarios by introducing a new QoS level 3 (also
low transmission rate constrained devices [2]. Because of its known as -1) that provides simple event delivery over UDP.
simplicity and low overhead, MQTT is one of the preferred MQTT-SN requires an MQTT-SN gateway that translates the
mechanisms for communications in IoT networks. MQTT in- events into traditional MQTT messages for interaction with
corporates and improves some of the publish/subscribe func- a broker. The MQTT-SN gateway, as indicated in Fig. 5.41,
tionality described in Sect. 5.3, while some other features like can be configured as a (1) transparent gateway where each
the advertising of topics are assumed to be accomplished by MQTT-SN event is translated into individual MQTT events
means of other out-of-band mechanisms. In general, MQTT and as a (2) aggregating gateway where multiple MQTT-SN
targets scenarios that are characterized by LLNs where low events are aggregated into a single MQTT event. In 2018 the
transmission rates translate into high latency and devices newest version of MQTT, MQTT v5, was standardized [1]. It
with low computational complexity and limited memory includes several new features and improvements that include
resources. the support of request/response scenarios in compliance with
MQTT, like any other publish/subscribe protocol, enables the mechanisms discussed in Sect. 5.2.
the wide distribution of device events to multiple subscribers
and defines a generic session management mechanism that
5.3.1.1 Message Format
is agnostic of the payload content. MQTT was designed to
Figure 5.42 shows the MQTT message format; it consists of
rely on TCP transport (on port 1883), including TLS support
a 24-bit fixed size header followed by an optional variable
for security, with three QoS levels that provide additional
size header and then by the payload. The messages, by
reliability. These three levels are (1) QoS 0, at most once,
being very small, are ideal for processing and transmission
that provides a fire-and-forget delivery where the publisher
of constrained IoT devices. Figure 5.43 shows the format of
sends events relying on the best effort of the TCP transport;
the fixed header; it includes a 4-bit message type encoded
(2) QoS 1, at least once, where any event sent by a publisher
according to Table 5.5, a 1-bit duplicate flag that is set
is guaranteed to arrive at least once to the broker; and (3) QoS
on retransmissions for at least once and exactly once QoS
2, exactly once, that enables the publisher to transmit exactly
levels, a 2-bit QoS field that indicates the delivery level as
one event to the broker. Note that although TCP provides, by
indicated in Table 5.6, and a 1-bit retain flag used by a
design, reliable transmission of data, in the context of IoT,
publisher to instruct its broker to hold the published message
network packet loss and overall infrastructure stability cause
so it becomes available to future subscribers. Specifically,
5.3 Publish/Subscribe 139

Fig. 5.41 MQTT-SN SENSORS GW SENSORS GW

BROKER BROKER

MQTT MQTT
MQTT-SN MQTT-SN

TRANSPARENT GATEWAY AGGREGATING GATEWAY

when an endpoint subscribes to a topic for which the broker 0 24

has retained messages, those messages are delivered to the FIXED HEADER VARIABLE SIZE HEADER …
subscriber, with the retrain flag set. The fixed header ends
with a 16-bit remaining length field that indicates how big the PAYLOAD …
payload is. The optional variable size header sits in between
the fixed size header and the payload, and its presence de- Fig. 5.42 MQTT message format
pends when certain message types are in use. As indicated in
Table 5.5, there are many different message types that enable 0 4 5 7
different functionality. Whenever a device connects to a bro-
BYTE 1 MESSAGE TYPE DUP QoS RET
ker, it must first create a connection by transmitting a connect
(CONNECT) request. The broker replies by transmitting a
BYTE 2
connect acknowledgment (CONNACK) message. Note that REMAINING LENGTH
this MQTT connection is initiated by the endpoint once the BYTE 3
TCP connection to the broker is established. Similarly, the
MQTT connection is torn down by means of the disconnect DUP Duplicate
(DISCONNECT) message right before the TCP connection QoS Quality of Service
RET retain
to the broker is terminated. If no other messages are to be
sent, endpoints periodically transmit keep alive ping request Fig. 5.43 MQTT fixed header
(PINGREQ) messages that refresh the MQTT connection
to the broker. The broker replies by transmitting a ping
response (PINGRESP) message. If the endpoint does not Table 5.5 MQTT message type
receive a PINGRESP or if the broker does not receive a Reserved 0 Reserved for future use
PINGREQ when there are no other transmissions, the con- CONNECT 1 Client request to connect to broker
nection is deemed terminated. The subscribe (SUBSCRIBE) CONNACK 2 Connect acknowledgment
and unsubscribe (UNSUBSCRIBE) messages are used by PUBLISH 3 Publish message
endpoints to, respectively, subscribe and unsubscribe to top- PUBACK 4 Publish message acknowledgment
ics. The broker acknowledges these requests by, respectively, PUBREC 5 Publish received (QoS = 2)
replying with subscribe acknowledgment (SUBACK) and PUBREL 6 Publish release (QoS = 2)
unsubscribe acknowledgment (UNSUBACK) responses. The PUBCOMP 7 Publish complete (QoS = 2)
publish (PUBLISH) message is used by endpoints to transmit SUBSCRIBE 8 Client subscribe request
events for QoS levels 0 through 2. The PUBLISH message SUBACK 9 Subscribe acknowledgment
is acknowledged by transmitting a publish acknowledgment UNSUBSCRIBE 10 Client unsubscribe request
(PUBACK) for QoS level 1 or by transmitting a publish UNSUBACK 11 Unsubscribe acknowledgment
received (PUBREC) for QoS level 2. QoS level 2 includes PINGREQ 12 Ping request
an additional transaction that follows the PUBREC transmis- PINGRESP 13 Ping response
sion. In this case, the endpoint transmits a publish release DISCONNECT 14 Client disconnection request
(PUBREL) message that is replied by the broker by means Reserved 15 Reserved for future use
of a publish complete (PUBCOMP) message.
140 5 Application Layer

Table 5.6 QoS level

QoS value Bit 2 Bit 1 Description
1 0 0 At most once (i.e. fire and forget)
2 0 1 At least once (i.e. acknowledgment delivery) publisher broker
3 1 0 Exactly once (i.e. assured delivery)
Reserved 1 1 Reserved for future use
QoS = 0
PUBLISH

Example 5.3 Consider a sensor that is periodically

transmitting readouts:
ACTION:
Publish Message To
Subscribers

sensor event broker

Fig. 5.44 At most once delivery

once. Without support of retransmissions, this level relies

on the underlying TCP transport for guaranteed delivery.
Conceptually, if TCP fails, the messages will not arrive at
the destination and will not be retransmitted either. Once
at the broker, the received message is published to all the
subscribers.
Assuming a 250 Kbps IEEE 802.15.4 transmission rate Figure 5.45 shows a at least once delivery scenario. The
and an average packet size of 200 bytes and ignoring publisher delivers a PUBLISH message, identified by a
the propagation delay, how fast can the sensor generate message identifier, to the broker. The first transmission has
readouts over MQTT QoS 0, 1, and 2 sessions? Also the duplicate flag unset. When received at the broker, an
assume that the sensor transmits one readout at a time, PUBACK message is transmitted back to the publisher.
making sure that a transaction is terminated before a If either of these messages fails to be received at the
new one can be initiated. corresponding far end, a retransmission, with the duplicate
flag set, is initiated by the publisher. Once the message is
Solution: For QoS 0, the sensor transmits PUBLISH received by the broker, it is forwarded to all the corresponding
messages one after another. The sensor readout rate is subscribers. SUBSCRIBE and UNSUBSCRIBE messages
given by RQoS 0 = 250000 bps
8×200 bits
= 156.25 readouts per are also acknowledged and, therefore, are delivered as at
second. Similarly, for QoS 1, the sensor transmit PUB- least once messages. Note that under this QoS level and
LISH messages that are acknowledged by the broker depending on what messages are affected by packet loss,
as it transmits PUBACK responses. The sensor readout multiple delivery of a given message is possible. The message
250000 bps
rate is given by RQoS 1 = 2×8×200 bits
= 78.125 identifier field is used to track the delivery of the different
readouts per second. Finally, for QoS 2, the sensor messages involved in this scheme.
transmits PUBLISH messages that are acknowledged This issue is solved by the exactly once delivery shown
by the broker that sends back PUBREC responses. The in Fig. 5.46. This scheme guarantees that duplicate messages
sensor then replies by transmitting PUBREL messages are not delivered to the receiving application. As in the pre-
that are acknowledged by the broker by transmitting vious scenario, the publisher delivers a PUBLISH message,
PUBCOMP responses. The sensor readout rate is given identified by a message identifier, to the broker. The first
250000 bps
by RQoS 2 = 4×8×200 bits
= 39.062 readouts per transmission has the duplicate flag unset. When received at
second. In other words, if TCP can be guaranteed to the broker, a PUBREC message is transmitted back to the
be reliable, then the best bet is to rely on MQTT QoS publisher. If either of these messages fails to be received at the
0 sessions to maximize the readout transmission rate. corresponding far end, a retransmission, with the duplicate
flag set, is initiated by the publisher. When the message
is received by the broker, it can be forwarded to all the
publishers. Upon reception of the PUBREC message, the
5.3.1.2 Message Flows publisher transmits a PUBREL message to tell the broker to
Figure 5.44 shows a PUBLISH message being delivered from forward the message to the subscribers (if it has not done
a publisher to the broker when QoS is configured as at most it yet) and to delete it. The broker replies by transmitting
5.3 Publish/Subscribe 141

Fig. 5.45 At least once delivery

publisher broker

QoS = 1
DUP = 0
PUBLISH MessageID = x

ACTION:
. Store Message
. Publish Message
. Delete Message
PUBACK

ACTION:
Discard Message

a PUBCOMP message that triggers the publisher to discard scribers and publishers in order to support bidirectional com-
the message. The double transaction mechanism guarantees munication. The application acting as client subscribes to its
that messages are delivered only once. The price to pay is own private client topic. In general, all clients must subscribe
added latency and extra throughput. As before, the message to their own private topics. The sensor acting as a server,
identifier field is used to track the delivery of the different in turn, subscribes to its well-known public server topic.
messages involved in this scheme. The client transmits the request by publishing to the well-
known server topic. At the broker, the request is forwarded
 MQTT Implementations There are many commercial to the server. The message includes a response topic field
and open-source MQTT implementations with support that specifies the client topic that is used by the server to
ranging from common constrained RTOSs to general- publish the response. Specifically, the server publishes the
purpose Linux distributions. The list below shows response to the client topic specified in the request. Again,
some of the most popular MQTT implementations. the response, as the request, is forwarded by the broker
to the application. From a performance perspective, MQTT
mosquitto BSD-licensed C implementation of client and broker. emulates request/response support and does not natively sup-
MQTT-C MIT-licensed C implementation of client. port it. When compared to HTTP, CoAP, and other REST
Paho MQTT BSD-licensed C/C++ implementation of client. protocols, the support of a request/response scheme under
wolfMQTT GNU-licensed C implementation of client. MQTT results in additional latency due to the messages being
eMQTT5 MIT-licensed C++ implementation of client. forwarded by the broker. Moreover, the broker is still a single
point of failure that can prevent end-to-end connectivity even
when both client and server are fully functional.

5.3.1.3 MQTT v5 Request/Response Support

MQTT version 5 provides support for request/response trans- 5.3.2 AMQP
actions that comply with the REST architectures and proto-
cols introduced in Sect. 5.2. Advanced Message Queuing Protocol (AMQP) is a ses-
Rather than natively enabling direct end-to-end transmis- sion layer protocol, similar to MQTT, that was initially
sion of requests and responses, MQTT relies on the broker designed for enterprise applications like financial businesses
for the coordination needed for the delivery of messages. but due to its simplicity and small footprint has become
Figure 5.47 shows the transactions associated with this an integral part of many IoT solutions [13]. As MQTT,
mechanism. Essentially, clients and servers behave as sub- AMQP relies on TCP transport, with security provided by
142 5 Application Layer

Fig. 5.46 Exactly once delivery

publisher broker

QoS = 2
DUP = 0
PUBLISH MessageID = x
ACTION:
Store Message
ACTION:
. Store Message
or
. Store Message Id
. Publish Message
MessageID = x
PUBREC

PUBREL
MessageID = x

ACTION:
. Publish Message
. Delete Message
or
. Delete Message Id
MessageID = x
PUBCOMP

ACTION:
. Discard Message

means of TLS, that enables the support of three distinct

QoS levels. Several dataflows between peers are transmitted GW
over a single TCP connection. AMQP was first standard-
ized as version 0.8 (formalized as 0–8) in 2006. The latest
AMQP version 1.0, released in 2011, has been standard-
ized by International Organization for Standardization (ISO) readout readout
in 2014.
CoAP CoAP

 CoAP, HTTP, MQTT, and IoT Cloud Services There are UDP UDP
many commercial and non-commercial IoT services IPv6 IPv4
that enable devices to push sensor readouts to the
6LoWPAN IEEE 802.3
cloud for processing by means of analytics or for of-
fline visualization. Some of these technologies include IEEE 802.15.4 IEEE 802.3

Amazon Web Services (AWS), Google Cloud, Kaa, IEEE 802.15.4

ThingWorx, and ThingSpeak. These solutions typically
support HTTP or MQTT protocols that do not natively access core
enable end-to-end CoAP sessions. Specifically, end-to-
end CoAP sessions rely on the following conversion:
5.3 Publish/Subscribe 143

Fig. 5.47 MQTT client/request client

support
server

application broker device

The gateway converts IPv6 datagrams over IEEE

application
802.15.4 into IPv4 datagrams over Ethernet. All
upper layers remain unchanged. The problem with this DEVICE DATA
approach is that the core network includes firewalls that
due to security and other performance considerations MESSAGING

AMQP
filter out UDP traffic. Because of this, most core
networks only support TCP-based protocols like TRANSPORT/FRAMING
MQTT and HTTP, and it is the task of the gateway

transport
to fully convert the stacks as shown below: TCP

Fig. 5.48 AMQP two-layer structure

GW

security behavior between peers right on top of the TCP

transport. It also defines the framing mechanism that rules
readout readout how fields are formatted and encoded. The messaging sub-
CoAP HTTP/MQTT layer provides the messaging capabilities that relying on
UDP TCP
the transport/framing sublayer enables peers to exchange
messages.
IPv6 IPv4

6LoWPAN IEEE 802.3 5.3.2.1 Transport/Framing

IEEE 802.15.4 IEEE 802.3 AQMP transport defines two entities that are used to build
peers: (1) nodes that oversee storing and delivering mes-
IEEE 802.15.4
sages and (2) containers that define clients and brokers that
contain multiple nodes. In general, nodes can be producers,
access core consumers, or queues. Clients contain producers and/or con-
sumers, while brokers contain queues. An AQMP connection
is negotiated on top of TCP connection established between
Because IoT access networks do not include firewalls,
client and broker, with security optionally provided by means
device connectivity is guaranteed in this scenario.
of TLS. The AQMP connection supports full-duplex commu-
nication by means of an ordered sequence of frames that can
As CoAP (shown in Fig. 5.18), AMQP also relies on
be used to multiplex channels. An AQMP session is created
a two-sublayer structure, shown in this case in Fig. 5.48.
when establishing two unidirectional channels that enable
The transport/framing sublayer defines the connection and
communication between nodes. Nodes, in turns, rely on links
144 5 Application Layer

Fig. 5.49 AMQP connections, container connection container

sessions, and links session
link
node node
link

Fig. 5.50 AMQP frame format 0 8 16 31

SIZE
FRAME HEADER
DOFF TYPE CHANNEL
8
... EXTENDED HEADER
DOFF x 4

PAYLOAD FRAME BODY

DOFF data offset

to exchange messages between each other. An AMQP link intermediate entities. The bare message includes a body and
is a unidirectional route attached to a node and responsible two properties: system properties that are defined by AMQP
for message status tracking. The relationship between con- and application properties that are defined by the application.
tainers, nodes, connections, sessions, and links is shown in Table 5.7 shows some of the possible system properties
Fig. 5.49. defined by AMQP. The annotated message is a superset of
Connections and sessions are terminated if the underlying the bare message that additionally contains a header and
TCP connection is lost due to, for example, heavy network annotations that are used by intermediate entities.
packet loss. Links, on the other hand, are recoverable, and The messaging sublayer introduces two message states:
even if the TCP connection goes down, they resume at the they can be terminal or non-terminal. Terminal messages can
same delivery status as it was before the connection loss. be accepted if they were received and successfully processed
Figure 5.50 shows an AMQP frame divided in three sec- by the receiver, rejected if they were rejected and cannot
tions: (1) an 8-byte frame header that is included in every be processed, released if they were not processed and to
single frame, (2) an optional variable length extended header be redelivered, and modified if they were modified but not
that depends on the frame type, and (3) the variable length processed. Non-terminal messages can only be received in-
frame body. The frame header includes several fields: a 32- dicating partial message data.
bit frame size that accounts for the frame header, extended
header and frame body, an 8-bit data offset that points to 5.3.2.3 Message Flows
the start of the payload, an 8-bit frame type that indicates When compared to MQTT, AMQP introduces message flows
the format and purpose of the frame (frame type 0 indicates that are a bit more complex. The message flow between
an AMQP frame), and a 16-bit channel field that identi- entities under AMQP relies on four steps: (1) opening/closing
fies the channel number. The frame body is defined as a an AMQP connection, (2) beginning/ending an AMQP ses-
performative followed by payload filled by the application sion, (3) attaching/detaching an AMQP link, and (4) send-
with data to send. The performative enables opening/closing ing/receiving messages. Figure 5.52 shows the message flow
an AMQP connection, starting/ending an AMQP session, between a client and its broker required to open an AMQP
attaching/detaching a link, transferring content, and handling connection. After the TCP connection is established, an
flow control. AMQP handshake is followed by an open performative that
defines the maximum frame size and the maximum number
5.3.2.2 Messaging of channels. The maximum frame size defines the maximum
Messaging capabilities are provided by the messaging sub- size of each frame that is exchanged. A session is then started
layer built on top of the framing sublayer. The sublayer by means of the begin performative that specifies the window
defines a well-known format that consists of two main com- size. Each endpoint has an incoming and an outgoing window
ponents: bare message and annotated message (Fig. 5.51). with a size defined as frame count that is decremented on each
The bare message contains the content that is transmitted transmission. The frame exchange stops when the sender
by the sender to the receiver and remains unchanged by does not have window space to transmit and the receiver
5.3 Publish/Subscribe 145

Fig. 5.51 AMQP messaging annotated message

format
bare message

header DA MA SP AP body footer

DA delivery annotations
MA message annotations
SP system properties
AP application properties

Table 5.7 CoAP option types

System property Meaning
Message id Message identifier
To Message destination
application broker
Subject Information about message content
Reply to Address to send replies to
Correlation id Identifier to link different messages
aach AMQP links
Content type Message content type
Absolute expiry time Expiration time of message
flow control

message sent

application broker

messages sent
open TCP connection
AMQP handshake

open AMQP connection

Fig. 5.53 AMQP send

begin AMQP session

transfer performatives associated with multiple transmitted
messages.
Similarly, Fig. 5.54 shows the message flow correspond-
aach AMQP link
ing to a client receiving messages from its broker. Roles are
reversed in this case; the client transmits a flow performative
to tell the broker that it is ready to receive data. The broker
Fig. 5.52 AMQP open then sends a transfer performative to send data, which is
responded, if the QoS level is at least once, by a disposition
performative. Again, if multiple messages are transmitted, a
does not have window space to receive. Once a session single disposition performative can be used as response.
is established, a link is attached by transmitting an attach Figure 5.56 shows the message flow that enables the
performative. Each link relies on a link credit that indicates closing of the AMQP connection. First, the client issues a
the number of messages a receiver can receive. detach performative to detach the link which is followed by
Figure 5.53 shows the message flow where a client sends an end performative the terminate the session. Finally, as
a message to its broker. After an AMQP link is attached, shown in Fig. 5.55, the client issues a close performative to
the receiver transmits a flow performative, and the client finish the AMQP connection. The TCP connection is then
sends a message by means of a transfer performative. If torn down.
the QoS level is configured as at least once, the broker AMQP supports that same three QoS levels that MQTT
replies by transmitting a disposition performative. A single supports: (1) at most once that as a fire-and-forget mechanism
disposition performative can serve as a reply to multiple transmits a message only once, (2) at least once that through
146 5 Application Layer

application broker
application broker

aach AMQP links

flow control
Fig. 5.57 AMQP at least once
receiving message

receiving messages
application broker

Fig. 5.54 AMQP receive

Fig. 5.58 AMQP exactly once

application broker
retransmissions guarantees that messages are received at least
once, and (3) exactly once that through double acknowledg-
deatach AMQP links ment reduces throughput while guaranteeing that messages
are received exactly once. In the context of AMQP, only
at most once and at least once mechanisms are used in
practice. Figure 5.56 shows a message being transmitted as
end session at most once QoS where the settled flag is set to true to
indicate that no acknowledgment is needed. On the other
hand, Fig. 5.57 shows a message being transmitted as at least
once QoS where the settled flag is set to false to indicate that
close connection an acknowledgment is needed. In this later case, the acknowl-
edgment is sent in the form of a disposition performative
with the settled flag set to true. If an acknowledgment is
Fig. 5.55 AMQP close not received, the sender retransmits the message. Similarly,
Fig. 5.58 shows a message being transmitted as exactly once
QoS where double acknowledgment is performed.

Summary
application broker
Interaction between devices and applications rely on
two main architectures that are common under IoT:
request/response and publish/subscribe. The chapter started
by describing the characteristics of these mechanisms with
initial focus on request/response architectures that have
Fig. 5.56 AMQP at most once REST as key component. REST, in turn, is extended by
Homework Problems and Questions 147

Table 5.8 Application layer protocols application

GW broker
Protocol Client/req or pub/subs Transport Overhead Security or QoS
HTTP Client/req TCP High Both sensor event
1 Gbps 0.5 second
XMPP Both TCP High Security 1 Gbps
REQUEST
REQUEST
CoAP Client/req UDP Low Both
SIP Client/req UDP/SIP High Security
RTP Client/req UDP Low Both
OPC UA Client/req TCP High Security
MQTT Pub/subs TCP Low Both
AMQP Pub/subs TCP Medium Both

mission rate between the gateway and the application is also

supporting observation that improves both latency and QoS. 100 Kbps? How do these results compare to those of the
The chapter explored HTTP detailing its main characteristics Problem 5.2?
like message formats, cookies, and proxy support. The
chapter then introduced XMPP and its IoT extensions 5.4 Describe a scenario where HTTP is better suited than
and continued by presenting CoAP as a lightweight CoAP for sensor data transmission.
alternative to HTTP. Both SIP and RTP were introduced
as mechanisms for the establishment and management of 5.5 As indicated in this chapter, IoT cloud services do not
media sessions in the context of IoT. The chapter ended by typically support end-to-end CoAP sessions. Why is not
detailing publish/subscribe protocols like MQTT and AMQP. possible to support end-to-end HTTP or MQTT sessions
Table 5.8 provides a comparison between the different instead? What are some of the reasons for this?
application layer protocols.
5.6 Consider an HTTP application requesting three readouts
from a sensor:
Homework Problems and Questions
application sensor
5.1 When comparing request/response and publish/subscribe
architectures, what are their differences from energy, packet
128 Kbps
loss, and latency perspectives?

5.2 Consider the following publish/subscribe scheme:

application
latency

GW broker

sensor event

Assuming a lossless network where the only delay is the

transmission delay, how long does it take for a 200-byte
packet with the sensor event data to arrive to the application?
What happens if the transmission rate between the gateway, Assuming a lossless network where the only delay is the
the broker, and the application is also 100 Kbps? transmission delay, if the transmission rate is 128 Kbps (bidi-
rectional), what is the overall transmission latency for both
5.3 Consider the following request/response scheme: persistent and non-persistent connection scenarios? Also as-
Assuming a lossless network where the only delay is the sume 150-byte request and response packet sizes as well
transmission delay, how long does it take for 200-byte re- as 30-byte connection establishment request and response
sponse packet with the sensor event data to arrive to the packet sizes.
application? Also assume a 100-byte request packet and a
half a second delay between the event generation and the 5.7 XMPP is many times considered a hybrid applica-
actual application event polling. What happens if the trans- tion layer protocol because it can be seen either as a
148 5 Application Layer

request/response or as a publish/subscribe mechanism. Can sensor on the sensor. Assume non-confirmable operations
you explain why? where ten server updates are received with a 10% packet loss.

5.8 What are the different layers of a secure XMPP stack 5.11 Under an observation scenario, 12.31 C temperature
that relies on a IEEE 802.15.4 physical layer? readouts are transmitted every half a second by a sensor to
an application as a payload of 2.05 Content CoAP messages.
The messages are transported over UDP and IPv6. Assuming
application XMPP
the shortest possible 6LoWPAN and IEEE 802.15.4 headers
security as well as a 1-byte token and no options as part of the CoAP
transport message, what is the overall transmission rate of the scheme?
network
5.12 Consider an application simultaneously polling eight
adaptation sensors to request readouts at a rate of twice a second in a
link lossless topology:
physical IEEE 802.15.4

request
5.9 The following flow shows a device transmitting three
sensor readouts to an application. The assumption is that
response
there has been a CoAP GET request from the application
to the device to enable CoAP observation. Add the missing
information: (1) type of message (examples: CON, NON,
ACK, RST), (2) message code (when needed) (examples:
2.05 Content, 4.04 Not Found), (3) message id, and (4) token
id to each message.

device application For maximum size IEEE 802.15.4 and 6LoWPAN headers
with no security, what is the application transmission rate and
throughput for the following scenarios?

(a) HTTP: 30-byte requests and 35-byte responses.

(b) CoAP: 16-byte requests and 20-byte responses (unicast)
(c) CoAP: 16-byte recuse and 20-byte responses (multicast)
(d) What are the implications of the results obtained above?

5.13 A microphone generates 8000 samples of audio per

second. Each sample is, in turn, compressed as an 8-bit value.
These samples are buffered into 160-byte frames that are
transmitted as insecure RTP packets over UDP and IPv6. As-
sume the physical layer is Ethernet. What is the transmission
rate of the microphone?

5.14 In an MQTT scheme, a sensor transmits readouts by

means of blocking transactions. In other words, if a transac-
tion is initiated to transmit a readout, the different messages
associated with this transaction must be processed before the
following readout can be sent. Assuming 100-byte packets,
128 Kbps transmission rates, no network impairments, and
5.10 Show the packet flow between a CoAP client and a
no delays other than the transmission delay, what is the
sensor when the client attempts to observe a temperature
References 149

maximum readout transmission rate of the scenario for each International Conference on Communication Systems Software
QoS level? and Middleware and Workshops (COMSWARE’08), pp. 791–798
(2008)
12. Nepomuceno, K., d. Oliveira, I.N., Aschoff, R.R., Bezerra, D., Ito,
5.15 Describe a scenario where MQTT is better suited than M.S., Melo, W., Sadok, D., Szabo, G.: Quic and tcp: a performance
CoAP for sensor data transmission. evaluation. In: 2018 IEEE Symposium on Computers and Commu-
nications (ISCC), pp. 00045–00051 (2018)
13. OASIS: advanced message queuing protocol (amqp) version 1.0
part 2 (2012). http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-
References core-transport-v1.0-os.html
14. Perkins, C., Handley, M.J., Jacobson, V.: SDP: session description
1. Banks, A., Gupta, R.: Mqtt version 5.0 oasis committee specifica- protocol. RFC 4566 (2006). https://doi.org/10.17487/RFC4566.
tion (2019). https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0. https://rfc-editor.org/rfc/rfc4566.txt
html 15. Rodríguez-Domínguez, C., Benghazi, K., Noguera, M., Gar-
2. Banks, A., Briggs, E., Gupta, R.: Mqtt version 3.1.1 oasis com- rido, J.L., Rodríguez, M.L., Ruiz-López, T.: A communication
mittee specification (2014). http://docs.oasis-open.org/mqtt/mqtt/ model to integrate the request-response and the publish-subscribe
v3.1.1/mqtt-v3.1.1.html paradigms into ubiquitous systems. Sensors 12(6), 7648–7668
3. Bellavista, P., Corradi, A., Reale, A.: Quality of service in wide (2012). https://doi.org/10.3390/s120607648. https://pubmed.ncbi.
scale publish-subscribe systems. IEEE Commun. Surv. Tuts. 16(3), nlm.nih.gov/22969366.22969366[pmid]
1591–1616 (2014) 16. Saint-Andre, P.: Extensible messaging and presence proto-
4. Belshe, M., Peon, R., Thomson, M.: Hypertext Transfer Protocol col (XMPP): core. RFC 6120 (2011). https://doi.org/10.17487/
Version 2 (HTTP/2). RFC 7540 (2015). https://doi.org/10.17487/ RFC6120. https://rfc-editor.org/rfc/rfc6120.txt
RFC7540. https://rfc-editor.org/rfc/rfc7540.txt 17. Saint-Andre, P., Alkemade, T.: Use of transport layer security
5. Bishop, M.: Hypertext Transfer Protocol Version 3 (HTTP/3). (TLS) in the extensible messaging and presence protocol (XMPP).
Internet-Draft draft-ietf-quic-http-29, Internet Engineering Task RFC 7590 (2015). https://doi.org/10.17487/RFC7590. https://rfc-
Force (2020). https://datatracker.ietf.org/doc/html/draft-ietf-quic- editor.org/rfc/rfc7590.txt
http-29. Work in Progress 18. Schooler, E., Rosenberg, J., Schulzrinne, H., Johnston, A., Ca-
6. Bormann, C., Shelby, Z.: Block-wise transfers in the constrained marillo, G., Peterson, J., Sparks, R., Handley, M.J.: SIP: session
application protocol (CoAP). RFC 7959 (2016). https://doi.org/10. initiation protocol. RFC 3261 (2002). https://doi.org/10.17487/
17487/RFC7959. https://rfc-editor.org/rfc/rfc7959.txt RFC3261. https://rfc-editor.org/rfc/rfc3261.txt
7. Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., 19. Schulzrinne, H., Casner, S.L., Frederick, R., Jacobson, V.:
Raymor, B.: CoAP (Constrained application protocol) over TCP, RTP: a transport protocol for real-time applications. RFC 3550
TLS, and WebSockets. RFC 8323 (2018). https://doi.org/10.17487/ (2003). https://doi.org/10.17487/RFC3550. https://rfc-editor.org/
RFC8323. https://rfc-editor.org/rfc/rfc8323.txt rfc/rfc3550.txt
8. Fielding, R.T.: REST: architectural styles and the design of 20. Schwarz, M.H., Borcsok, J.: A survey on opc and opc-ua: about
network-based software architectures. Doctoral Dissertation, Uni- the standard, developments and investigations. In: 2013 XXIV
versity of California, Irvine (2000). http://www.ics.uci.edu/~ International Conference on Information, Communication and Au-
fielding/pubs/dissertation/top.htm tomation Technologies (ICAT), pp. 1–6 (2013)
9. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, 21. Shelby, Z., Hartke, K., Bormann, C.: The constrained applica-
P., Berners-Lee, T.: Rfc 2616, hypertext transfer protocol – http/1.1 tion protocol (CoAP). RFC 7252 (2014). https://doi.org/10.17487/
(1999). http://www.rfc.net/rfc2616.html RFC7252. https://rfc-editor.org/rfc/rfc7252.txt
10. Hartke, K.: Observing resources in the constrained application 22. Tschofenig, H., Fossati, T.: Transport layer security
protocol (CoAP). RFC 7641 (2015). https://doi.org/10.17487/ (TLS)/datagram transport layer security (DTLS) profiles for
RFC7641. https://rfc-editor.org/rfc/rfc7641.txt the Internet of Things. RFC 7925 (2016). https://doi.org/10.17487/
11. Hunkeler, U., Truong, H.L., Stanford-Clark, A.: Mqtt-sn - a pub- RFC7925. https://rfc-editor.org/rfc/rfc7925.txt
lish/subscribe protocol for wireless sensor networks. In: 2008 3rd 23. XMPP: Xmpp extensions. https://xmpp.org/extensions/
 Part III
Advanced IoT Networking Topics

This part of this book, that includes four chapters, reviews the advanced IoT networking topics
that complement the protocols presented in Part II. Chapter 6 explores the different mechanisms
used for resource identification and management. Chapter 7 focuses on the technologies that
provide traffic routing and message forwarding in the context of IoT. Chapter 8 presents a
wide range of full and hybrid IoT LPWAN industry standards. Chapter 9 introduces Thread,
a popular home automation WPAN architecture, that provides an alternative approach to
traditional IoT stacks.
 Resource Identification and Management
6

tionality including directory discovery that enables devices

6.1 IoT Services and Resources to find the address of the directories, registration update
by which devices update their service support, registration
Because IoT devices, like sensors, actuators, and controllers, validation used by devices to verify their own service support,
are becoming smaller and more portable, there is an increas- and registration removal where devices unregister some their
ing need for them to operate in networks where deployment currently supported services.
and provisioning are carried out without human intervention. Some protocols like CoAP [14] provide their own propri-
This scenario leads to what it is called zero-configuration etary service discovery mechanism that cannot be extended
devices. One key component of zero-configuration is ser- to other technologies like MQTT [2, 3] or HTTP [10].
vice discovery. There are two classes of service discovery: Fortunately, most publish/subscribe protocols include basic
distributed and centralized. Distributed discovery consists of discovery by design supported through topic advertisement.
devices discovering each other without accessing centralized Request/response deployments, however, require additional
directories. Similarly, centralized discovery relies on one functionality to support service discovery. One approach to
or more service directories that provide a list of services providing a generic framework for service discovery is by
offered by devices. A device accesses these directories to find extending the DNS infrastructure.
out what services are provided by devices in the network. DNS [9] is a well-established IP suite protocol that is
The main functions of service discovery include publication, mainly used for address resolution whenever a client wants
registration, discovery, and resolution. In centralized scenar- to find out the IP address of a given hostname. This is
ios, directories result in several maintenance functionalities shown in Fig. 6.1 where as a client sends an HTTP GET
including updating, removing, and validating directory en- request to the en.wikipedia.org HTTP server, it must first
tries [8, 1, 5]. translate the hostname into an IP address in order to build
Publication is the process by which devices publish a up the outgoing datagram. There are several steps: (1) the
list of their supported services. The following information is client starts a recursive query to its configured local DNS
typically associated with each publication: a service class that server to find out what the address of the en.wikipedia.org
specifies the nature of the service provided (i.e. temperature HTTP server is, (2) the local DNS server then initiates a
sensing), a service access that specifies the network address sequence of iterative queries by first asking its configured
of the service (i.e. 2001::21:5), a service name that identifies root DNS server the .org DNS server address, (3) the root
the specific instance of service supported (i.e. sensor1 vs sen- DNS server responds by transmitting the address of the .org
sor2), a domain name that identifies the service domain (i.e. DNS server, (4) the local DNS server queries the .org DNS
building.local), and service properties that provide a list of server about the address of the wikipedia.org DNS server,
attributes associated with the service (i.e. units=Fahrenheit). (5) the .org DNS server responds by transmitting the address
Registration is the mechanism by which services provided of the wikipedia.org DNS server, (6) the local DNS server
by devices are stored in global directories. Registration can be queries the wikipedia.org DNS server about the address of
stateless if the directory listens for broadcast advertisements the en.wikipedia.org HTTP server, (7) the wikipedia.org
to fill in its database or if it periodically queries devices for DNS server responds by transmitting the address of the
service support updates. In stateful registration, the device en.wikipedia.org HTTP server and finalizing the sequence
knows the address of the directory and explicitly registers of iterative queries initiated by root DNS server, (8) the
directly with it. Stateful registration includes additional func- local DNS server responds by forwarding the address of the

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 153
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_6
154 6 Resource Identification and Management

Fig. 6.1 DNS recursive query

root DNS server

address A

local DNS server .org DNS server

address B
1. en.wikipedia.org ? 8. address D

wikipedia.org DNS server

address C
client

9. HTTP GET 10. 200 OK

Iterative queries: 2, 4, 6
recursive query: 1

en.wikipedia.org
address D

en.wikipedia.org HTTP server to the client and terminating the global connectivity to DNS servers and (2) registering
the recursive query, (9) the client sends the HTTP GET RRs for a massive number of devices is too expensive to be
request to the en.wikipedia.org HTTP server, and (10) the practical in most deployments. mDNS provides an alterna-
en.wikipedia.org HTTP server replies by transmitting a 200 tive to traditional DNS by addressing these two problems.
OK. Specifically, mDNS (1) removes the need for DNS servers
DNS, however, is a lot more than that; it introduces a by moving the resolution capability to each device, and (2)
generic mechanism for querying information and retrieving it assigns a portion of the DNS namespace for free local
resource records (RRs) that can provide not only network use eliminating the need for global RR registrations and
and transport layer information but also configuration param- delegations [7]. When compared to DNS, mDNS requires
eters. Under IoT and, in order to support zero-configuration, very little or no configuration to function, and it works even
DNS is extended by means of two methodologies that enable when no infrastructure is present, or the current infrastructure
distributed service discovery: (1) multicast DNS (mDNS) and is faulty.
(2) Service Discovery DNS (SD-DNS) [16, 11]. From a functional perspective, mDNS relies on the exist-
ing DNS message structure and syntax, RR types, as well
as DNS operation and response codes. mDNS, however,
6.2 mDNS specifies how devices must coordinate themselves to send
and receive multicast requests and responses in a relevant
As it can be seen in Fig. 6.1, the DNS infrastructure consists way. DNS/mDNS messages are transmitted over UDP on
of a network of DNS servers that can be globally reached port 53. Figure 6.2 shows a DNS/mDNS message; it includes
by any client. In the context of IoT, the deployment of this a fixed size header and variable number of questions and
infrastructure is not always possible due to two main issues: RRs organized as answer records, authority records, and
(1) network impairments associated with LLNs may affect additional records. Questions include the requested record
6.2 mDNS 155

Fig. 6.2 DNS message format

HEADER
NAME
VARIABLE NUMBER OF QUESTIONS TYPE
CLASS
VARIABLE NUMBER OF ANSWER RECORDS
VARIABLE NUMBER OF AUTHORITY RECORDS NAME
VARIABLE NUMBER OF ADDITIONAL RECORDS TYPE
CLASS
TIME TO LIVE (TTL)
RESOURCE RECORD DATA (RDATA)

name, type, and class, while RRs include only the record
select random
name, type, and class but also the TTL and the corresponding RR name
data associated with the record. The name identifies the
resource within the device, while the type specified the nature
of the resource. Some resource types are A and AAAA
to respectively specify IPv4 and IPv6 addresses, PTR for
send multicast mDNS
reverse lookups, SRV for service information, and TXT for question for name
configuration information. The class is always set to IN for
IP resource types. The TTL field identifies the number of
seconds for which a resource record is valid. Note that this
TTL field is, therefore, a Resource Record TTL (RR TTL) in
contrast to the IP TTL field that specifies the hop count limit.
A and AAAA are probably the most relevant RR types reply ?
since they enable hosts and other entities to convert device
hostnames into respective valid IPv4 and IPv6 addresses.
For a device to be globally addressable, it must belong to timeout
an organization that has control over the DNS namespace
such that it can be assigned a name. For example, if the orga-
nization owns the DNS namespace l7tr.com, a given device use RR name
can have the subdomain sensor1.l7tr.com globally allocated
for applications and other hosts to access it. However, RR Fig. 6.3 RR name resolution state machine
registration on subdomain DNS servers increments topology
complexity and requires global connectivity to work. This
authority over the selected RR name. If the request timeouts,
is not always available in IoT LLNs where infrastructure
that is, no other device responds, then the sender can assign
limitations and network outages are common. mDNS assigns
the name to the RR, otherwise the device must select a new
RRs that are only valid within a given link-local segment of
random .local RR name and repeat the process. If a sensor
the network and that they are not typically accessible beyond
has authority of an RR name like temperature.local, it can
the link-local scope. These mDNS specific RR names take
continue using that name until a conflict occurs. In this case,
the form submain.local where, for example, a device could
the device must allocate a new name for the RR in accordance
assign the sensor.local name to itself for its own A/AAAA
with the procedure specified in Fig. 6.3.
records. It is critical the RR name selection is done in such
mDNS reserves the top-level domain to .local that, as a
a way that there are no collisions with names selected by
link-local allocation, implies that all subdomains are only
other devices. In this context, RRs are unique RRs. To this
meaningful in the link where they are defined. Requests and
end, a device must first verify that no other devices are using
responses associated with questions and answers belonging
the selected RR name. A device must, therefore, support
to the .local domain must be sent to the mDNS IPv6 multicast
both client and server DNS functionality by being able to
addresses FF02::FB. mDNS supports that other non .local
generate and process multicast requests and replies. Multicast
questions can be sent multicast to other devices in the link
requests and replies guarantee that they are visible to all
if no global DNS server is configured. This enables any non-
devices co-located on the same link. Figure 6.3 shows a state
authoritative entity to respond to these requests and provide
machine that defines how a device must assign an RR name.
RR name resolution even when connectivity to the traditional
Specifically, the device must first randomly select a .local RR
DNS infrastructure is not available. For example, if an IoT
name and acting as a client sends a multicast mDNS question
gateway, due to an outage, cannot access the network core,
asking all other devices on the same link whether they have
devices on the same link can still talk to each other using
156 6 Resource Identification and Management

locally resolved globally allocated DNS RR names. In gen- client issues a new AAAA query that results on a mapping
eral, due to its distributed nature, mDNS provides a general to 2001::7 with a TTL 100. At time 200, devices A and C
mechanism for devices to access each other RR names if at are sleeping, and device B is active. As the previous query
least a minimal infrastructure is present. expires, the client issues a new one that results on a mapping
In contrast to unique RRs, certain scenarios support shared to 2001::6 with TTL 100. Essentially, the client interacts with
RRs. This is shown in Fig. 6.4 where multiple devices interact the asset through the different devices in a transparent way
through either sensing or through actuation with an asset. All by means of the asset.local hostname. The client is unaware
three devices (A, B, and C) share the same AAAA RR name that application and session layer requests (i.e. CoAP, HTTP)
that maps to three different IPv6 addresses: 2001::5, 2001::6, are being processed by three different devices with three
and 2001:7. At initial time, device A is active (devices B and different power duty cycles. This mechanism that attempts
C sleep), at time 100 s device C is active (devices A and B to address the power limitations by abstracting the different
sleep), and at time 200 s device B is active (devices A and power cycles is known as load balancing.
C sleep). Each active device responds including a TTL field
of 100 s. In essence, the devices have nonoverlapping power
duty cycles that attempt to preserve the overall network life- 6.2.1 Queries
time. In other words, IoT networks exhibit power limitations
that enforce the need of power duty cycles that balance Figure 6.5 shows two devices, one acting as a client and
active with sleeping periods. Devices in sleep mode only keep another acting as a server. Both client and server consist of
some basic functionality that enables them to become active
at some point in time. While sleeping, devices sometimes
client server
harvest energy by means of, for example, solar panels. mDNS
provides shared RR names to overcome the limitations that applications applications
result from devices being unavailable for extended periods of
time. Specifically, multiple devices that observe an asset can mDNS client query
mDNS server
take turns responding to external requests. In the figure, at querier
responder
resolver response
time 0, device A is active, while B and C are sleeping, any answerer
quesoner
AAAA request querying for asset.local results in a mapping
to 2001::5 with a TTL of 100. By around time 100, devices
Fig. 6.5 Queries and responses
A and B are sleeping, while device C is now active. The

time = 0 time = 100 time = 200

A A A
2001::5 B 2001::5 B 2001::5 B
ASSET 2001::6 ASSET 2001::6 ASSET 2001::6

C C C
2001::7 2001::7 2001::7
asset.local ?

asset.local ?

asset.local ?
TTL = 100

TTL = 100

TTL = 100
2001::5

2001::7

2001::6
AAAA

AAAA

AAAA

ACTIVE

SLEEPING

Fig. 6.4 Shared resources

6.2 mDNS 157

several client and server applications. The client applications where the interval between the first two queries is 1 s and
rely on an mDNS client, also known as querier, to perform any other successive queries are transmitted by multiply-
RR name resolution. The querier or resolver (also known ing this interval by two until reaching a maximum interval
as questioner) transmits a query that is answered by the length of 3600 s. Moreover, mDNS makes queriers support a
mDNS server, also known as responder (and also known mechanism known as known answer suppression. Figure 6.6
as answerer). mDNS queries can be (1) one-shot queries shows the interaction between three devices and a client:
that are typically associated with legacy DNS queriers and first at time 0, device A and B are active, but device C is
responders and (2) continuous queries that are made by sleeping. AAAA request querying for asset.local results on
fully compliant mDNS queriers and responders in order to a mapping to 2001::5 with a TTL of 200 and to 2001::6 with
support asynchronous operations like IoT load balancing. In a TTL of 100. At time 100, the client sends a new query
general, because devices advertising unique RRs must be for asset.local, but since it knows device A is still active, it
able to perform conflict resolution, they typically include populates the known answer section including the device A
both querier and responder functionality. For devices that AAAA RR with the updated TTL value of 100. This prevents
only advertise shared RRs, there is no need for them to act device A from replying with its own AAAA RR information,
as queriers as they are not exposed to conflict resolution. thus improving network efficiency by reducing throughput.
Under one-shot queries if a device is configured with a lo- Obviously, this is why the mechanism is called known answer
cal DNS server, it transmits all queries to the aforementioned suppression; known answers are suppressed by not being
server, while those falling under the .local domain are trans- transmitted. At this point, device B is no longer active, but
mitted multicast to the destination IPv6 address FF02::FB on device C becomes active and replies with its IPv6 address
UDP port 5353. These multicast queries are transmitted using 2001::7 with a TTL of 200. At time 200, the client issues a
a source port different from 5353 in order to indicate that they new query with a known answer section including the device
are one-shot queries. With one-shot queries the resolver will C AAAA RR with the updated TTL value of 100. Since at
use the first response it receives assuming the RR is unique, this point device C is the only one active and the known
and it will not attempt to request other answers. This behavior answer section information is correct, nobody replies to the
may work on certain simple scenarios, but it may not be query. Essentially, the known answer suppression mechanism
optimal when dealing with more complex situations where, tells mDNS servers what answers are already known to the
for example, shared RRs are involved. mDNS introduces querier.
continuous queries to address some of the performance issues If way too many answers are included in the known answer
introduced by one-time queries. section of a request, they may not fit in a single mDNS
With continuous queries, a single response is not an in- message due to fragmentation restrictions. In this case, the
dication that no more responses follow. For example, in a querier sends multiple requests with different sections of the
load balancing scenario where multiple devices sense a single list of known answers with all packets having the truncation
asset, they all may send separate answers to a question about (TC) bit set other than the last one transmitted. The responder,
an RR name mapping. Moreover, if one of the devices is upon receiving mDNS messages with the TC set, defers
sleeping, the one-shot approach would cause the client to transmitting any answer until either receiving the last mDNS
forget it. Under continuous queries, operations are asyn- message with the TC bit unset or timing out after 500 ms. This
chronous, and a transaction can be finalized when there is mechanism provides a trade-off between latency and wasted
clear indication that no other responses will be received. network bandwidth, such that when waiting for more known
If a client application is looking to send and receive answers, fewer answers are transmitted by the responder.
datagrams from a device, it must keep processing mDNS In continuous queries, the querier retransmits queries to
responses until there is clear indication that the applica- obtain new answers that may not have been available when
tion is interacting with the device. One common scenario the questions were first transmitted. To this end, successful
requires a client application to show the list of available implementation of known address suppression is critical to
services in real time. One naive (and inefficient) approach minimize throughput and limit network traffic. Since channel
is to rely on issuing several queries of interest and process capacity, especially for most low-power IoT technologies
them as answers are received. As time progresses the client like IEEE 802.15.4, is low, instant bursts of traffic result
application must resend the questions to prevent the use of in contention that ultimately leads to latency and packet
stale information. This can be done either through a timer loss. To prevent this, mDNS enforces that queriers delay the
or by means of the end user clicking on a refresh button. transmission of questions by choosing a random delay in the
Unfortunately, this compulsive device polling can lead to range of 20–120 ms.
inefficient network utilization by putting an unreasonable Based on the TTL fields of received replies, clients keep
burden on the communication infrastructure. Therefore, a a cache to verify the validity of the different RRs. When an
way to prevent this is by introducing a controlled schedule, RR expiration time is reached, if no client application has
158 6 Resource Identification and Management

time = 0 time = 100 time = 200

A A A
2001::5 B B 2001::5 B
2001::5
ASSET 2001::6 ASSET 2001::6 ASSET 2001::6

C C C
2001::7 2001::7 2001::7

K.A: 2001::7 (TTL = 100)

K.A: 2001::5 (TTL = 100)
asset.local ?

asset.local ?
asset.local ?
TTL = 100

TTL = 200
TTL = 200
2001::5

2001::6

2001::7
AAAA

AAAA
AAAA
X

ACTIVE

SLEEPING

K.A. KNOWN ANSWERS

Fig. 6.6 Shared resources with known answer suppression

an active interest in the records, they are removed from the multiple requests carrying a single question. The advantage
cache. In reality, way before an RR is about to expire, and of multiple queries on a single request is the transmission of
as long as there is an active interest, the client must transmit fewer lower layer headers that lead to less overhead and more
a query to make sure that the record is still valid and also network efficiency. If a device is about to send a question
to update the cache with a newer TTL value. These query and it notices that the multicast request generated by another
retransmissions must be performed starting after at least half device includes the same question and the known answer
of the RR lifetime has elapsed. Formally, mDNS indicates section does not include a valid answer, then it can avoid
that a retransmission must first be issued when the lifetime sending the query. Specifically, the assumption is that any
of the RR is at 80%. If no answer is received, the next other device with authority over the RR will answer the query
retransmission is performed when the lifetime of the RR is at by transmitting a multicast response.
85%. If still no answers are received, two additional attempts
are performed when the lifetime of the RR is at 90% and 95%,
respectively. In either case, whenever an answer is received, 6.2.2 Responses
the RR lifetime is updated according to the TTL field. If no
answer is received by the end of the RR lifetime, the record The transmission of multicast responses enables all link-local
is removed from the cache. As in the case of replies, queriers devices to benefit from the responses of the different re-
randomly delay the retransmission of questions to minimize sponders. This way devices can keep their caches up-to-date
the chances of traffic bursts that can lead to packet loss. They and minimize the transmission of additional queries that may
introduce a random TTL variation of 2% that implies that have been resolved by previously received answers. In some
retransmissions are performed first between 80 and 82% of situations, however, it is neither practical nor efficient for all
the lifetime, second between 85 and 87% of the lifetime, third devices on the link to receive responses, for example, if a pre-
between 90 and 92% of the lifetime, and finally between 95 viously inactive interface is activated through a configuration
and 97% of the lifetime. mDNS clients that comply with the change. In this case, the cache associated with the interface is
mechanisms of continuous queries must issue requests to the initially empty so the sequence of queries transmitted by its
IPv6 multicast address FF02::FB from UDP port 5353. device can cause a sudden flood of multicast responses that
A single mDNS request can carry multiple queries issued produce traffic bursts that can make the network unusable due
by a unique querier. From a protocol perspective, the effect to collisions and device contention. Since most other devices
of multiple questions in a single request is like that of on the network are likely to have the answers in their caches,
6.2 mDNS 159

the transmissions of these redundant multicast replies can be single response that includes both IPv4 and IPv6 addresses.
avoided. One way to do this is by explicitly indicating that The IPv4 address is transmitted as either an A or an NSEC
requests need to be replied using unicast responses. RR, and the IPv6 address is transmitted as either an AAAA
mDNS specifies that the class field of a DNS question or an NSEC RR. The point of including both answers in a
must include a unicast response bit that, when set, indicates single response is to make sure that the resolver receives all
that the querier wants to receive unicast replies in response the interface information at the same time and minimize the
to the question. mDNS calls questions that request unicast chances of incomplete information because of packet loss.
responses QU questions to distinguish them from the more The initial design of mDNS assumed that there was no need
common QM questions that request multicast responses. for negative answers and just a simple timeout would work
When an interface first initializes, the device transmits QU as a good indication of the nonexistence of a given RR.
questions only. Question retransmissions are sent as QM The problem with this later approach is that it induces the
questions because they are likely to include a large list of retransmission of questions that introduce additional latency
known answers derived from the initial QU question trans- as well as network packet loss.
mission. More known answers mean that fewer answers are mDNS responses are supposed to be true and accurate
transmitted by those devices answering questions, thus, re- answers regardless of what questions those answers are ad-
ducing the likelihood of traffic bursts. Sometimes, responders dressing. mDNS requests can include, besides questions,
send multicast answers to QU questions; this happens when answers in the form of the known answers. On the other hand,
the mDNS server detects that the time since the last multicast mDNS responses must only include answers. If an mDNS
answer transmission is more than quarter of the TTL time. response has questions in its question section, they must be
In general, QU responses follow the same timing and packet ignored by the resolver. As in the case of mDNS requests,
generation mechanisms than QM responses. the transmissions of mDNS responses are randomly delayed
In certain circumstances some client applications require minimizing traffic bursts that lead to channel contention
resolvers to send unicast requests to a specific mDNS server and network packet loss. If the responder advertises unique
even when the queries are associated with .local RR names. RRs, there is no need to impose any transmission delays
In these cases, the mDNS server sends answers as if the as it is guaranteed that only one device will respond to the
requests were carrying QU questions. The mDNS server incoming requests. On the other hand, if the question is
must make sure that the request is being initiated by an regarding shared RRs, then the responders must delay the
mDNS client on the same local link. Specifically, if a request transmission of the answers by a random amount of time
originates outside the local link, it must be dropped by the uniformly distributed in the 20–120 ms range. This is also
mDNS server. In some other circumstances, certain mDNS important if multiple devices are attempting to answer the
servers are designed to respond to queries initiated outside same question, since the random transmission delay enables
the local link. In this case, unicast requests associated with devices to observe whether the answer has been already
.local RR names are answered by responders transmitting transmitted. If so, the device does not need to send the query.
unicast responses. Since the requests/responses in this sce- This situation is compatible with the case in which mDNS
nario become traffic in the Internet backbone, it is convenient proxy servers respond to queries based on the information
to minimize their transmissions by making sure that only previously sent by other devices.
those RR for which the mDNS server is authoritative are sent. mDNS responses must be transmitted over UDP with
In general, an mDNS responder must only answer when source and destination ports 5353 to indicate full compliance
it has a non-null positive response to send or if it is author- with specifications. A resolver typically drops any mDNS
itative about the nonexistence of a given RR. For the case responses that do not have 5353 as source port. Responses are
of unique RRs, where the responder is the sole owner of transmitted multicast to the link-local IPv6 destination ad-
RRs, the mDNS server must transmit negative answers for dress FF02::FB, unless they are in response to QU questions.
queries related to RRs that do not exist. Negative answers are To minimize traffic bursts that lead to contention and loss, a
transmitted in terms of next secure (NSEC) RRs. As with any responder must wait for at least 1 s before it can resend an
records, NSEC RRs include a TTL field that indicates for how answer to a previously transmitted RR. Whenever possible,
long it is nonexistent. For example, IoT devices have IPv6 and in order to be efficient, responders tend to aggregate as
addresses but typically lack IPv4 addresses. Since addresses many answers as possible into a single request. By doing
are unique, devices are guaranteed to be authoritative about so, the overhead due to the DNS and lower level headers
A and AAAA RRs. If a client queries about A/AAAA RRs, is minimized. Moreover, a single multicast mDNS message
the IoT device will send a positive AAAA answer and a can include answers that address questions from multiple
negative A answer to indicate that the record does not exist. queriers. In general, a responder may delay the transmission
In general, questions that request information related to the of a response by up to 500 ms in order to collect enough
IP addresses of a given interface are answered by means of a questions to guarantee that many answers is included in the
160 6 Resource Identification and Management

packet. Of course, the price to pay for this aggregation is it indicates that the response carries answers owned by the
an additional 500 ms latency. In addition, in responding to sender; the TC bit that specifies that the request is truncated
requests that include known answers, the responder may and more messages are to be expected; the recursion desired
resend the answers with an updated TTL field if the lifetime (RD) bit that it is typically used by the querier to enable
of the corresponding RR is less than half the TTL value. If recursive queries; the recursion available (RA) bit used by
a device is about to send an answer and it notices that the the responder to specify support of recursive queries; and
multicast response generated by another device includes the the 4-bit response code (RCODE) that identifies the response
same answer, then it can avoid sending the response if the type and it is used to indicate format errors, server failures,
TTL field of the answer complies with the lifetime of its RR. RR errors, request refusal, or no errors. Then four 16-bit
counters end the message; the question count (QDCOUNT)
Example 6.1 Consider an IEEE 802.15.4 scenario that indicates the number of entries in the question section,
where a querier attempts to discover three sensors that the answer count (ANCOUNT) that specifies the number of
share an asset: RRs in the answer section, the authority count (NSCOUNT)
that indicates the number of RRs in the authority section,
and the Additional Count (ARCOUNT) that accounts for the
QUERIER
2001::2105 2001::2106 number of RRs in the additional records section.
ASSET
In the specific cast of mDNS, all responses including
those unsolicited responses coming from IoT devices must
2001::2107
be processed. This observation of all incoming responses is
multicast
typically performed regardless of the content in the message
unicast
identification field and the question section. In fact, under
mDNS, a device can cache the content of all responses even
if it does not have a client with an active interest in those RRs.
Of course, the mDNS client must respect RR lifetimes when
caching those responses.
If it takes 11.34 ms for all three unicast requests
In the context of mDNS, there are a few expectations on
to arrive at the sensors, what is the average MAC
how the fields are used. For example, for multicast mDNS
contention delay? Ignore any delays other than the
messages, the message identification field is always 0 re-
transmission delay. Assume average mDNS and CoAP
gardless of whether the message is a request or a response.
packet sizes of 30 and 40 bytes long, respectively.
Only in the case of legacy unicast responses triggered by
Solution: The contention delay is given by Tc =
T − Tt where T is T = 11.34 ms and Tt 0 1 5 6 7 8 9 10 11 12 15
is the transmission delay. Tt is given by Tt =
LmDNS request +3×LmDNS response +3×LCoAP MESSAGE ID
R
= 7.68 ms where R =
250000 Kbps, LmDNS request = LmDNS response = 8 × QR OPCODE AA TC RD RA reserved RCODE
30 bits and LCoAP = 8 × 40 bits. The contention delay QDCOUNT
is, therefore, Tc = 3.66 ms.
ANCOUNT

NSCOUNT
ARCOUNT

6.2.3 mDNS Message Header QR query (0) or reply (1)

OPCODE operation code
AA authorative answer
Figure 6.7 shows the DNS message header format; it starts TC truncation
with a 16-bit message identifier field that is assigned by RD recursion desired
RA recursion available
the client and identifies the transaction, and it follows the RCODE response code
query/response (QR) bit that when set indicates that the mes- QDCOUNT question record count
sage is a response, the 4-bit operation code (OPCODE) that ANCOUNT answer record count
NSCOUNT authority record count
identifies the request message operation type and specifies ARCOUNT additional record count
whether it is a standard query, an inverse query, or a status
request; the authoritative answer (AA) bit that, when set, Fig. 6.7 DNS message header format
6.3 SD-DNS 161

QU requests the message identification field is used to keep Because an instance is related to a service and a domain,
track of the transaction. Similarly, the OPCODE is always they are discovered by querying service.domain PTR RRs.
set to query on transmission, and any other value is ignored Once all instances are identified, then it is possible to retrieve
by the responder. The AA bit must be unset on transmission IP addresses, transport ports, and general configuration
and ignored when received. As previously indicated, if the information by querying instance.service.domain A/AAAA,
TC bit is set, the responder must wait for at least 500 ms SRV, and TXT RRs respectively. Figure 6.8 shows a client
to wait for more messages. This bit only applies to queries, transmitting a multicast service.domain PTR request that is
so responses do not set it and queriers ignore the value in answered by three devices (A, B, and C) that transmit their
incoming responses. Finally, queriers set the RCODE to no supported instances A.service.domain, B.service.domain, and
error on transmission, and it is ignored by responders upon C.service.domain. In Fig. 6.9 the client sends three queries
reception. Another difference between traditional DNS and derived from the list of instances: (1) an A.service.domain
mDNS is that the former relies not only on UDP but also A/AAAA request to obtain the IP addresses, (2) an
on TCP transport for unicast transmissions. Since TCP does A.service.domain SRV request to obtain the TCP/UDP
not support multicast operations, it cannot be used for mDNS ports, and (3) an A.service.domain TXT request to retrieve
transport. configuration information. Note that SD-DNS is defined to
work not only in the context of multicast mDNS transactions
but also relying on traditional unicast DNS servers. In this
6.3 SD-DNS later case a client can send all SD-DNS queries to a local DNS
server that through recursion can discover instances and their
mDNS provides the basic infrastructure for the exchange addresses, transport ports, and configuration parameters.
of RRs between devices on the same link [6]. By itself, The service component of the service.domain element
mDNS does not specify a procedure for the discovery of takes the form of the protocols associated with the instances
a newly deployed device in the network. To this end, SD- being queried. For example, if a client is interested in HTTP
DNS relies on the infrastructure to enable zero-configuration instances, the corresponding service name is _http._tcp since
support. Moreover, SD-DNS specifies how RRs must be HTTP is a session protocol that runs over TCP. Similarly,
named to provide service discovery, but, as mDNS, it makes if the client is interested in CoAP instances, the service
no changes to the structure of DNS messages, operation, and name is _coap._udp since CoAP is run over UDP. Services
response codes as well as most DNS protocol values. With can be more specific, for example, temperature._mqtt._tcp
SD-DNS a client can specify, by means of DNS queries, the addresses all instances of temperature sensors that support
type of service and the domain in which it is looking for that MQTT over TCP. Similarly, _coap._dlts._udp looks for all
service and obtain a list of the named instances that provide instances of secure CoAP. Note that protocol names are
the service. preceded by an _ symbol. Note that the original service
specification supports only two different transport types _tcp
and _udp. _tcp is used for TCP transport-based protocols,
and _udp is used for all other protocols regardless of whether
they support UDP or not. In other words, a popular transport

A/AAAA A. service.domain ?

IP addresses

B.service.domain
client B SRV A.service.domain ?

TCP/UDP ports
CLIENT A
TXT A.service.domain ?

configuration information
C

Fig. 6.8 Discovery of instances

Fig. 6.9 Getting IP addresses, ports, and configuration information
162 6 Resource Identification and Management

protocol known as Stream Control Transmission Protocol intended to be accessed more often, are specified by lower
(SCTP) that enables efficient transmission of data streams is priority numbers. Similarly, if several servers have ports with
encoded as _udp and not as it would be expected as _sctp. the same priority, the weight specifies what server should
Fortunately, most IoT protocols rely on UDP transport so this be accessed more often. When there is only one RR that
is never an issue. specifies the transport port, then the weight and priority fields
can be ignored.
Example 6.2 What is the transmission rate overhead TXT RRs provide a list of device configuration parameters
due to the transactions shown in Fig. 6.9? that are service and instance dependent. In other words,
how their parameters are interpreted depends on the type of
Assume that the TTL fields of the A/AAAA, SRV, service under consideration. For example, the unit configura-
and TXT RRs are 100 ms, 250 ms, and 500 ms, tion parameter on a temperature sensor is specified as either
respectively. Additionally assume that the size of the Celsius or centigrade degrees. Similarly, on a barometric
mDNS request packets is 30 bytes long and that the pressure sensor, it is specified as either Pascals or pounds per
sizes of the A/AAAA, SRV, and TXT mDNS responses square inch. What is standardized is the way in which TXT
are LA/AAAA = 20, LSRV = 10 and LTXT = 57 bytes, RRs are accessed; SD-DNS compliant devices must be able
respectively. to provide TXT RRs in addition to SRV RRs with the same
name even if they have no relevant configuration information.
In this later case, the TXT RR must provide a single 0 byte.
Solution Considering that in 1 s there are ten, four In all cases, the lifetime of the record is given based on the
and two A/AAAA, SRV, and TXT transactions, TTL field of the RR received.
respectively, Because the list of configuration parameters is typically
 the rate overhead R is given  by
R = 8 × 10 × LA/AAAA + 4 × LSRV + 2 × LTXT = large, it is important to mention the size restrictions that apply
2832 bps. to most RRs. As any other record, a TXT RR that includes
the list of parameters can be up to 65535 bytes long. This
length is part of the length field in the RR header. In the
The domain component of the service.domain RR
context of mDNS RR, when considering all protocol headers
name follows the usual subdomain.local format for
and networking conditioning, the practical upper limit of a
mDNS-based queries or follows the traditional unicast
TXT RR length is around 9000 bytes. It is always preferable
hostname format. Similarly, the instance components of the
to keep the TXT RR length below the MTU size of a single
instance.service.domain element is a user-friendly name that
datagram to prevent, whenever possible, fragmentation. Of
consists of a string composed of 16-bit unicode characters.
course, when relying on 6LoWPAN and low-rate IoT mech-
In most cases, the instance is a default name that enables
anisms like IEEE 802.15.4, fragmentation is, in many cases,
a client to access the device without any previous manual
unavoidable.
configuration. Moreover, to prevent collisions, in most cases
these defaults names are generated as a random combination
 mDNS/SD-DNS Implementations mDNS/SD-DNS are
of keywords and numbers. Instance names, as opposed to
protocols that, predating IoT, were originally intended
hostnames, are not constrained by specific rules, and rich
for discovery, provisioning, and configuration of print-
text strings are allowed. Spaces and other special characters
ers and other network devices like routers and switches.
are possible, for example, Temperature Sensor 1 is a valid
Because of this, mDNS/SD-DNS implementations are
instance name. Some special characters like dots need to
pretty stable and widespread for many different plat-
be escaped to differentiate from the dots used to separate
forms and OSs. The list below presents some of the
instance, service, and domain components. Escaping a dot
most popular mDNS/SD-DNS implementations.
is done by representing it as a backslash followed by the
dot itself (i.e. \.. On the other hand, escaping a backslash is
performed by representing it as a double backlash (i.e. \\). Bonjour Apache licensed open source C implementation.
SRV RRs provide a list of the UDP and/or TCP ports Available for general purpose OSs like Linux.
associated with a given service instance. The list of ports Adapted to support RTOS like Contiki.
can be used to support load balancing by enabling clients lwIP BSD licensed open source C implementation.
to access servers in a sequential fashion. For example, if RTOS specific support.
TCP ports 1883, 1884, and 1885 are provided as response Avahi LGPL licensed open source C implementation.
to an SRV query, the client applications can then establish Available in most Linux distributions included in
new sessions by sequentially connecting to those ports. This embedded devices.
port selection, however, is ruled by two fields; priority and OpenMDNS BSD licensed open source C implementation.
weight associated with each port. Higher priority servers, Ultra lightweight support of mDNS/SD-DNS.
6.4 CoAP Service Discovery 163

The list of configuration parameters is made of a sequence RRs and the associated A/AAAA RRs. Finally, if a querier
of key and value pairs. The key represents the parameter transmits a TXT request, the responder sends back just the
name, while the value indicates its associated parameter TXT RR.
value. Each pair is encoded as a single string key=value Figure 6.11 shows a service discovery example; the
where key and value are separated by an equal sign =. For client just sends a multicast mDNS PTR RR query
example, a key could be location and its value the corre- for _temperature._coap._udp.local. Device sensor1
sponding GPS coordinates such that the encoding string is answers the query by sending a PTR RR that indicates
location=41.40338,2.17403. The key size is between one the sensor1._temperature._coap._udp.local session. The
and nine characters long, while the overall encoded string response also piggybacks an NSEC RR to indicate that
length size is never larger than 255 bytes. Obviously, the the device does not have an IPv4 address, an AAAA
key or parameter name has to be unique within the context RR that signals a 2001::21:10 IPv6 address, a SRV RR
of the service being considered. For the most part, the key that points to a single UDP port 5683, and a TXT RR
does not need to be human readable as it is intended to be that transmits a configuration parameter list units=C and
processed by client applications. Given a service and all its location=41.40338,2.17403.
associated parameters, there are four possible scenarios for
the parameters in the list included in the TXT RR: (1) if the
key is not present, it implies that the parameter takes the 6.4 CoAP Service Discovery
default value or that the parameter is unknown; (2) if the
key is present with no value, it implies that the parameter CoAP introduces both distributed and centralized approaches
represents a boolean condition that is false; (3) if the key is to service discovery. The distributed approach is based on
present with an empty value, it implies that the parameter simple CoAP resource discovery, while the centralized ap-
takes the default value; and (4) if the key and its value are proach is based on CoAP resource directory [15]. In all cases,
both present, it assigns the value to the parameter. as a result of the discovery, URIs that represent the resources
Key/value pairs, encoded as strings, are concatenated in and corresponding attributes are obtained. Distributed CoAP
a binary frame and pre-appended by a single byte that spec- service discovery relies on interaction, by means of queries,
ifies the length of the string. This is shown, as example, in between applications and devices. On the other hand, under
Fig. 6.10 where the following strings are encoded: key=value, centralized CoAP service discovery, applications and devices
active=1, and units=C. In general, it is up to the service do not query each other, and the interaction is by means of
specifications to purely rely on TXT RRs for configuration a directory. Note that although these mechanisms have not
or combine TXT RRs with inband protocol mechanisms. been fully standardized, they are supported by several CoAP
For example, under CoAP, configuration information like the implementations [17].
units associated with temperature sensing can be transmitted
as part of a TXT RR list or as part of a CoAP option.
For efficiency, under SD-DNS, whenever a PTR query 6.4.1 Distributed CoAP Resource Discovery
is transmitted, the responders transmit not only the list of
instances but also all associated A/AAAA, SRV, and TXT This method provides the simplest way for devices to sup-
RRs. This saves the querier the need of transmitting addi- port service discovery without the need of directories and
tional A/AAAA, SRV, and TXT RR queries. Similarly, if a other central entities. The scenario is illustrated in Fig. 6.12
client sends a SRV query, the responder transmits the SRV where a receiver application discovers the services offered

Fig. 6.10 TXT record

9 key=value 8 active=1 7 units=C

length encoded pair length encoded pair length encoded length

Fig. 6.11 Service discovery

example PTR _temperature._coap._udp.local ?

PTR sensor1._temperature._coap._udp.local

A NSEC / AAAA 2001::21:10

client SRV port 5683, priority 0, weight 0 sensor1

TXT units=C, location=41.40338,2.17403

164 6 Resource Identification and Management

receiver temperature sensor temperature sensor resource directory

Fig. 6.12 Distributed CoAP resource discovery Fig. 6.13 Resource discovery registration

by a temperature sensor by transmitting a regular CoAP store the description of the CoAP services and resources
GET request to the well-known URI /.well-known/core. The available in the LLN and provide an interface for devices
querying application may or may not know the address of and applications to query them. Devices register with the
the device; for the first case, the application transmits the directories so that any entity can look up for resources by
request directly to the unicast address of the device, while for transmitting a single CoAP GET request. Since all queries
the second case, the application transmits a multicast request are submitted to the directory, devices and applications must
instead. Devices can also discover applications; in Fig. 6.12 be able to reach it. There are three possibilities: (1) the device
the temperature sensor sends a CoAP GET request to the knows what the address of the directory is, (2) the directory
/.well-known/core?rt=oic.d.receiver URI. Note that the URI address may be the same as that of the border router obtained
includes an attribute resource type (rt) that provides addi- by means of RAs, and (3) the directory address is discovered
tional filtering in order to only reach receiver applications. through a multicast transmission.
This is specified by means of the Internet Assigned Numbers Figure 6.13 shows the device registration process.
Authority (IANA) registered attribute value oic.d.receiver. First, a device sends a CoAP GET request to the /.well-
Other allowed attributes that can be included in URIs are (1) known/core?rt=core.rd* URI in order to determine the
the interface description (if) that is a string that indicates the specific URI of the directory. This is usually done in
name or URI used to access the resource, (2) the maximum all scenarios, including under multicast discovery. The rt
size (sz) that specifies the maximum size of the resource attribute points to core.rd* in association with the resource
representation returned by performing a GET of the target directory information. Once the directory location and
URI, and (3) the content type (ct) that indicates the format address are known, the temperature sensor can then transmit
of the content returned when accessing the resource. In the a CoAP POST to the /rd URI to add its resource identifier.
context of CoAP, the use of URIs with attributes is specified The directory responds with a 2.01 Created to indicate that
by IETF RFC 6690 Core Link Format as a mechanism for the entry has been inserted into the database and it has been
servers to describe hosted resources. assigned the /rd/2105 URI.
In most cases, however, the device address is not known CoAP introduces additional functionality to manage di-
beforehand, so discovery can only be performed by transmit- rectory entries. Figure 6.14 shows the device updating its
ting multicast CoAP GET requests. But multicast transmis- registration by transmitting a CoAP PUT request with a new
sions are unreliable since there is no way to know whether URI /temp. The request is replied with a 2.04 Changed. The
a request has made it to destination since the number of directory can also verify if the device resource information is
destinations is unknown to begin with. In this situation, it up-to-date. In this case, the directory transmits a CoAP GET
makes a lot more sense to rely on CoAP directories to keep request to the /.well-known/core URI with a ETag that speci-
track of resources. fies the version of the information it has. If the information is
up-to-date, the device replies with a 2.03 Valid; otherwise it
transmits the updated information by means of a 2.05 Content
6.4.2 Centralized CoAP Resource Discovery response. When the temperature sensor wants to delete its
directory entry, it transmits a CoAP DELETE request to the
As previously indicated, the centralized approach to resource URI /rd/2105. The directory replies with a 2.02 Deleted.
discovery relies on one or more directories. The directories
6.5 UPnP 165

If a device wants to look up for specific resource informa- ing from computers and printers to gateways and access
tion in the directory, as illustrated in Fig. 6.15, it can transmit points [12]. UPnP enabled zero-configuration networking
a GET CoAP request to the /rd/res?rt=oic.d.receiver by leveraging IP, TCP, UDP, HTTP, and XML. Each device
URI. The lookup type /rd/res indicates that the device is is associated with a particular XML schema that defines
querying the directory for those registered resources of the data structures that are used for interoperability and
type oic.d.receiver. The directory then replies with a 2.05 discovery. Note that most of these protocols and technologies
Content that includes the coap://[2001::21:5]:5683/app are not efficient in the context of LLN scenarios, so improve-
URI for direct access to the resource. Similarly, if the ments have been proposed to enable UPnP IoT support [13,
device just wants to find out what the domain of the 4].
receiver is, it can issue a GET CoAP request to the UPnP entities are classified as either controlled devices or
/rd/ep?rt=oic.d.receiver URI where the lookup type /rd/ep control points. Controlled devices are, from an IoT functional
specifies that endpoint information of type oic.d.receiver is perspective, sensors and actuators that act as UPnP servers,
being requested. while control points are user applications that run on smart-
phones and typically act as UPnP clients. UPnP networking is
made of five different steps: addressing, discovery, descrip-
6.5 UPnP tion, control, eventing, and presentation. Addressing is the
first step of UPnP networking and allows devices and control
The Universal Plug and Play (UPnP) architecture provides points to get network addresses. Once a control point has an
a framework for the discovery of network elements rang- address, through discovery, it can find controlled devices and
then obtain their capabilities by means of the description step.
Through eventing, control points listen for state changes of
the devices. The last step presentation enables control points
to display a user interface for the devices.

temperature sensor resource directory

6.5.1 Addressing and Discovery Steps

For IoT applications, as part of the addressing step, a device

or a control point acquires an IPv6 address by one of two
possible mechanisms: through DHCPv6 or auto-configured
as a link-local address. Discovery is then used by devices
to advertise their services and discover services provided
by other devices in the network. The discovery message
includes some basic information about the device including
additional pointers to more detailed information. In addition,
when a device joins the network, it may multicast a discovery
message to search for other devices providing specific capa-
Fig. 6.14 Resource discovery entry maintenance
bilities. In general, devices listen for multicast messages and
respond accordingly when the search criterion of the query
matches the characteristics of the device. The transmission
of these messages relies on the Simple Service Discovery
Protocol (SSDP) for both discovery and advertising. SSDP
temperature sensor resource directory is an ASCII based protocol that is based on HTTPU, that
is HTTP over UDP, in order to support multicast transmis-
sions.
There are three types of advertising messages: (1) alive
messages that enable devices to advertise services that are
available, (2) update messages that are used by devices
to make changes to the available services, and (3) byebye
messages that allow devices to signal the removal of services.
The message below is an example of an SSDP device adver-
tisement message:
Fig. 6.15 Resource discovery lookup
166 6 Resource Identification and Management

NOTIFY * HTTP/1.1 The start line HTTP/1.1 200 OK follows the convention
Host: [FF02::C]:1900 of the HTTP responses and specifies this is a response to
Cache-ControlL: max-age=3600 the request transmitted by the control point. The message
NT: uuid:2619d124-5400-2105-af21-90123ae100ff continues with a Cache-Control header that determines how
NTS: ssdp:alive long the message is valid. The message follows with an ST
Location: http://[2001::21:5]:8060/sensor/data.xml header that specifies the identity of the service responding to
USN: uuid:2619d124-5400-2105-af21-90123ae100ff the discovery request, and a USN header also identifies the
service. The Server header indicates the server information
The message is transmitted by a device as a multicast including OS, protocol, and application version. Finally, the
datagram to destination [FF02::C]:1900 and includes a start Location header indicates the URL that provides more infor-
line NOTIFY * HTTP/1.1 that indicates that the request is mation about the service provided by the device.
an advertisement. The message includes a Host header that
specifies the destination address and port included at the
application layer for recovering when NAT is in place; it 6.5.2 Description Step
continues with a Cache-Control header that determines how
long the message is valid, an NT header that indicates the The discovery step gives a control point some basic informa-
notification type as a service identifier, an NTS header that tion about the devices, but it does not provide any specific
specifies the notification subtype as ssdp:alive, a Location information about the data structures needed to interact with
header that indicates the URL that provides more information them. Specifically, to access a device, the control point must
about the service provided by the device, and a USN header be able to download the description of the device and its
that identifies the service. Note that in this message, the NTS capabilities that are indicated in the Location header of the
and USN headers carry the same information. 200 OK discovery response. The device description is carried
Discovery, as advertising, is carried out by the transmis- as XML formatted data that consists of two parts: (1) a device
sion of a multicast datagram request from a control point description indicating physical and logical containers and (2)
to destination [FF02::C]:1900. The message below is an a service description indicating the capabilities of the device.
example of an SSDP control point discovery message: The device description provides manufacturer information
M-SEARCH * HTTP/1.1
like serial number, vendor information, and model name,
Host: [FF02::C]:1900
while for each service in the device the service name, the
MAN: ssdp:discover
URL for service description, the URL for control and the
MX: 1
URL for eventing are provided. Note that a single physical
ST: ssdp:all
device, known as root device, may include multiple logical
The start line M-SEARCH * HTTP/1.1 indicates that the devices. The device description includes the description of
message is a discovery request. As for the advertising mes- the root device and all logical devices.
sage, the message includes a Host header that specifies the Figure 6.16 shows the description architecture, where the
destination address and port included at the application layer control point first retrieves the root device description that
for recovering when NAT is in place. The MAN header that includes the service URL that is used to obtain the service
follows specifies the type of message which for discovery description of the logical devices. The service description de-
requests it is always ssdp:discover. The MX header indicates fines the actions that the control point can perform including
how many seconds can devices wait before responding to the the arguments these actions can take. It also includes a list
request. The message ends with the ST header that specifies of the possible states a device can take with its associated
the scope of the search; in this case, ssdp:all indicates that all variables, data types, range, and event characteristics. Ac-
devices and services must be searched. tions have inputs and outputs, and their arguments are state
Devices reply by transmitting a unicast response to the variables.
device. The message below is an example of an SSDP device
discovery response message:
HTTP/1.1 200 OK 6.5.3 Control, Eventing, and Presentation
Cache-Control: max-age=3600 Steps
ST: uuid:2619d124-5400-2105-af21-90123ae100ff
USN: uuid:2619d124-5400-2105-af21-90123ae100ff Control enables control points to perform actions on devices
Server: Raspian/Buster UPnP/1.0 Temperature Sensor/2.4 and poll for results. This action/response interaction is syn-
Location: http://[2001::21:5]:8060/sensor/data.xml chronous, with the control point transmitting the action and
6.5 UPnP 167

Fig. 6.16 Description control point root device

architecture
description
…
service URL service
…

description device
…
… service
…

waiting for the response from the device. When the device <?xml version="1.0"?>
receives the action, it processes it and replies with either a <s:Envelope
successful response or an error. The action is sent to the URL s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
associated with the service obtained from the service de- xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
scription. Control messages are encoded as SOAP payloads <s:Body>
transmitted over HTTP. As indicated in Sect. 5.2.6, SOAP <ns0:GetSensorTemperatureResponse xmlns:ns0="urn:
is an XML data structure that provides a mechanism for schemas-upnp-org:
exchange of messages. SOAP messages include a mandatory service:Temperature:1">20C
envelope, an optional header, and a mandatory body. </ns0:GetSensorTemperatureResponse>
The message below shows an example of an action trans- </s:Body>
mitted from the control point to the device: </s:Envelope>
POST http://[2001::21:5]:8102/upnp/control/Temperature HTTP/1.1
SOAPAction: urn:schemas-upnp-org:service:Temperature:1
The response is a regular HTTP 200 OK message with a
Host: [2001::21:5]:8102
SOAP body that has an Envelope that contains in the Body
Content-Type: text/xml;charset="utf-8"
the response GetSensorTemperatureResponse that carries a
Content-Length: 324
20C readout.
When a device like a temperature sensor generates a new
<?xml version="1.0" encoding="utf-8"?>
readout, it can trigger an event on the control point. Eventing
<s:Envelope
supports two ways of operation: unicast by relying on HTTP
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
over TCP and multicast by means of HTTPU, that is, HTTP
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
over UDP.

<s:Body>
<ns0:GetSensorTemperature xmlns:ns0="urn:schemas-upnp
-org:service:Temperature:1">
</ns0:GetSensorTemperature>
</s:Body> control point device
</s:Envelope>

The message is transmitted as a HTTP POST request with

a SOAP body. The message not only includes regular HTTP
headers like Content-Type, Content-Length, and Host, but it
also has a SOAP specific header SOAPAction that indicates
the intent of the message. The body includes an Envelope
that contains a Body that invokes the GetSensorTemperature
action. The device replies by transmitting the following mes-
sage:
HTTP/1.0 200 OK
Content-Type: text/xml; charset="utf-8"
Server: Raspian/Buster UPnP/1.0 Temperature Sensor/2.4
Content-Length: 328
Fig. 6.17 Unicast eventing message flow
168 6 Resource Identification and Management

Figure 6.17 shows the flow of messages for unicast event- 6.2 Describe a scenario where the mDNS responder is a
ing. The mechanism extends HTTP to include SUBSCRIBE sensor that only advertises shared RRs.
and UNSUBCRIBE methods used by the control points to
respectively start and stop receiving events. When a sensor 6.3 Under the SD-DNS the following transaction is carried
readout becomes available, the device transmits an HTTP out. What mDNS query type is likely to be sent by the
NOTIFY request carrying the readout itself. All these re- querier?
quests, SUBSCRIBE, UNSUBSCRIBE, and NOTIFY, are
replied with the usual HTTP response codes. Device readouts
in the NOTIFY messages are encoded as XML bodies to querier
encode the relevant device state variables. In the case of mul- sensor
ticast transmissions, control points do not need to subscribe
as the devices transmit the NOTIFY messages directly over
HTTPU, and they do not expect a response either.
Lastly, the presentation stage, when signaled through a
URL in the device description, provides a web interface for
users in control points to control the device and view its
status. As such, presentation stage is supported by the device
6.4 Under the SD-DNS the following transaction is carried
acting as a web server.
out. What mDNS query type is likely to be sent by the
querier?
Summary

Most IoT solutions rely on a great number of resource and querier

sensor
service discovery mechanisms that when combined with
SAA enable zero-configuration scenarios. This chapter
started by presenting the main concepts and functions
of service discovery including publications, registration,
discovery, and resolution. It described how traditional DNS
can be extended to provide lightweight multicast mDNS
support over low-power and constrained devices transmitting
in LLNs. The chapter explored the details of mDNS and its 6.5 Under the SD-DNS the following transaction is carried
use along with DNS-SD to provide a generic mechanism out. What mDNS query type is likely to be sent by the
for service discovery. Alternatives to both mDNS and DNS- querier?
SD were then presented as part of this chapter. Specifically,
CoAP was presented as a provider of an efficient method for
centralized and distributed resource discovery. The chapter querier
finished by introducing details and functionality of UPnP as sensor
another alternative to mDNS and DNS-SD. Table 6.1 shows
a comparison of these three mechanisms.

Homework Problems and Questions

6.1 Describe a scenario where the mDNS responder is a 6.6 Consider an SD-DNS client (running on an application)
sensor that only advertises unique RRs. that queries four sensors to discover service instances. If the
only delay is the transmission delay and the transmission rate
Table 6.1 Resource identification and management protocols on both directions is 135 Kbps, how long does it take for the
client to discover all instances? Assume a uniform packet size
Protocol Transport Overhead Generic?
of 120 bytes.
mDNS/DNS-SD UDP Low Yes
CoAP SD UDP Medium No, specific to
CoAP 6.7 Consider an SD-DNS client that queries the addresses
UPnP TCP High Yes of four sensors. If TTL fields of RRs are multiples of 100,
please fill the empty spaces in the figure below:
References 169

References
1. Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M.,
Ayyash, M.: Internet of things: A survey on enabling technologies,
protocols, and applications. IEEE Commun. Surv. Tuts. 17(4),
2347–2376 (2015)
2. Andrew Banks Ed Briggs, K.B., Gupta, R.: Mqtt version 3.1.1
oasis committee specification (2014). http://docs.oasis-open.org/
mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
3. Banks, A., Gupta, R.: Mqtt version 5.0 oasis committee specifica-
tion (2019). https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.
html
4. Bodlaender, M.P.: Upnp/spl trade/ 1.1 - designing for perfor-
6.8 Show an mDNS message flow example where a sensor mance compatibility. IEEE Trans. Consumer Electron. 51(1), 69–
responds by transmitting at least one NSEC RR. 75 (2005)
5. Carballido Villaverde, B., Alberola, R.D.P., Jara, A.J., Fedor, S.,
Das, S.K., Pesch, D.: Service discovery protocols for constrained
6.9 If the RTT is 200 ms, how long does it take for a client to machine-to-machine communications. IEEE Commun. Surv. Tuts.
fully discover and transmit a NON CoAP request to a sensor? 16(1), 41–60 (2014)
6. Cheshire, S., Krochmal, M.: DNS-based service discovery. RFC
6.10 How long does a transaction to delete a sensor entry 6763 (2013). https://doi.org/10.17487/RFC6763. https://rfc-editor.
org/rfc/rfc6763.txt
in the CoAP resource directory take? Assume a bidirectional 7. Cheshire, S., Krochmal, M.: Multicast DNS. RFC 6762 (2013).
130 Kbps transmission rate as well as minimum size IEEE https://doi.org/10.17487/RFC6762. https://rfc-editor.org/rfc/
802.15.4 and 6LoWPAN headers. Use Fig. 6.14 as reference. rfc6762.txt
8. Datta, S.K., Costa, R., Bonnet, C.: Resource discovery in internet of
things: current trends and future standardization aspects. In: IEEE
6.11 Consider the UPnP scenario shown in Fig. 6.17. As- World Forum on Internet of Things (WF-IoT), pp. 542–547 (2015).
suming a 120 ms RTT and nonpersistent HTTP connections, https://doi.org/10.1109/WF-IoT.2015.7389112
how long does it take for all transactions to be completed? 9. Domain names - concepts and facilities. RFC 1034 (1987). https://
doi.org/10.17487/RFC1034. https://rfc-editor.org/rfc/rfc1034.txt

time = 0 time = 100 time = 200

A A A
2001::5 B B 2001::5 B
2001::5
ASSET 2001::6 ASSET 2001::6 ASSET 2001::6

D D D
C C C
2001::8 2001::8 2001::8
2001::7 2001::7 2001::7
TTL = ___ TTL = ___
2001::8 2001::6
asset.local ?

asset.local ?
asset.local ?
TTL = ___

TTL = ___
TTL = ___
K.A: ___
2001::5

2001::7
2001::5
AAAA

AAAA
AAAA

ACTIVE

SLEEPING

K.A. KNOWN ANSWERS

170 6 Resource Identification and Management

10. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, 15. Shelby, Z., Koster, M., Bormann, C., der Stok, P.V., Amsuss, C.:
P., Berners-Lee, T.: Rfc 2616, hypertext transfer protocol – http/1.1 CoRE resource directory. Internet-Draft draft-ietf-core-resource-
(1999). http://www.rfc.net/rfc2616.html directory-25, Internet Engineering Task Force (2020). https://
11. Florea, I., Rughinis, R., Ruse, L., Dragomir, D.: Survey of standard- datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-
ized protocols for the internet of things. In: 2017 21st International 25. Work in Progress
Conference on Control Systems and Computer Science (CSCS), 16. Stolikj, M., Cuijpers, P.J.L., Lukkien, J.J., Buchina, N.: Context
pp. 190–196 (2017) based service discovery in unmanaged networks using mdns/dns-
12. Foundation, O.C.: Upnp device architecture 2.0 (2020). sd. In: 2016 IEEE International Conference on Consumer Electron-
https://openconnectivity.org/upnp-specs/UPnP-arch- ics (ICCE), pp. 163–165 (2016)
DeviceArchitecture-v2.0-20200417.pdf 17. Tanganelli, G., Vallati, C., Mingozzi, E.: Edge-centric distributed
13. Jeronimo, M., Weast, J.: UPnP Design by Example: A Software discovery and access in the internet of things. IEEE Internet Things
Developer’s Guide to Universal Plug and Play. Intel Press (2003) J. 5(1), 425–438 (2018)
14. Shelby, Z., Hartke, K., Bormann, C.: The Constrained Applica-
tion Protocol (CoAP). RFC 7252 (2014). https://doi.org/10.17487/
RFC7252. https://rfc-editor.org/rfc/rfc7252.txt
 Routing on Constrained Devices
7

increase latency. This leads to multipoint clustering where

7.1 Routing Concepts multiple clusterheads aggregate the traffic from multiple
devices before it gets forwarded to other clusterheads for
Routing in the context of IoT has its origins in the routing wide distribution.
of WSNs due to the similarities between both technologies. The main alternative to address based routing is data-
As indicated in Sect. 2.5, routing protocols that have been centric routing. Data-centric routing involves clients sending
proposed for MANETs are not typically suitable for either queries to specific network regions in order to retrieve spe-
WSNs or IoT networks in general [5]. The same applies to cific readouts and data associated with specific capabilities.
traditional routing mechanisms widely used in the Internet This is illustrated in Fig. 7.2; multiple devices acting as
as a whole. Moreover, most of these traditional mechanisms sources collect readouts and forward them to sinks in re-
rely on routing that is based on network layer addresses. sponse to an initial query. In this scenario, attribute based tags
This means that routers will forward datagrams ultimately replace addresses for the purpose of routing. Temperature
based on routing tables that look at destination addresses to readouts are forwarded by network routers until they reach
determine outgoing links. Routing tables, in turn, are directly a temperature processing application. Similarly, humidity
or indirectly populated by routing algorithms. In WSNs, and pressure readouts are forwarded throughout the network
however, addresses are not always the best candidates to base based on tags until they reach applications that can process
routing decisions. Alternative approaches are needed. them. Conceptually, this is similar to the Publish/Subscribe
WSN routing protocols can be flat or hierarchical [9]. This application layer messaging described in Sect. 5.3. In fact,
is shown in Fig. 7.1. Flat routing relies on devices interacting data-centric routing is also performed at the application layer
with each other without a single device acting as parent that with the queries acting as subscriptions and the responses
concentrates and aggregates traffic of children devices. Hier- serving as notifications. However, one important difference
archical routing, on the other hand, groups devices in clusters between data-centric routing and application layer protocols
with clusterheads that act as parent devices to concentrate is that the latter rely on additional brokers to complete the
and aggregate traffic of children devices. Children devices communication path. In fact, under data-centric routing each
do not typically interact with each other and all traffic is device acts as a broker keeping track of attribute based
routed through the clusterheads that talk to other clusterheads names of other devices and forwarding traffic accordingly.
in order to provide end-to-end connectivity. The advantage Essentially, requests and responses are diffused over the net-
of flat routing is lower latency at a cost of lower energy work with mandatory support of aggregation at the routers.
efficiency. Similarly, the advantage of hierarchical routing is Data-centric routing typically goes hand in hand with hi-
higher energy efficiency at a cost of higher latency. Energy erarchical routing as clusterheads serve as ideal routers to
efficiency in hierarchical routing is accomplished by means aggregate and propagate traffic. Another advantage of the
of multihop or mesh routing under the umbrella of capillary data-centric routing is that attribute naming can be used to
networks. A capillary network, shown in Fig. 2.3, consists of reach multiple devices with a single message if the attribute
devices relying on intermediate devices to route their traffic represents a common feature. For example, a client may send
to the clusterhead. On average, the individual devices con- a datagram intended to all devices supporting temperature
sume less power by aggregating traffic on intermediate nodes readouts in each region. The datagram will be forwarded by
than when directly taking to their destinations. But traffic all intermediate devices supporting data-centric routing. Note
aggregation means extra buffering and retransmissions that this is analogous to multicast propagation of address based

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 171
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_7
172 7 Routing on Constrained Devices

Fig. 7.1 Flat vs hierarchical FLAT HIERARCHICAL

routing

CH

cluster 1

CH clusterhead

CH

cluster 2

Fig. 7.2 Data-centric routing

temperature
readout sink humidity
readout sink

humidity
sensor

pressure
readout sink

pressure
sensor

temperature
temperature sensor
sensor

routing. Data naming relies on the use of relevant attributes location based routing; a client attempts to send a datagram
like data types and timestamps. In the context of a fully to a destination that is known by its geographical coordinates.
connected network, Fig. 7.3 shows a scenario with a remote First the client, that knows its own coordinates, forwards the
user residing at the edge of the IP cloud that transmits a query datagram to router 1 that is the closest one in the direction of
to reach a WSN sensor. The query is propagated beyond the the destination. Similarly, router 1, that also knows its own
gateway all the way to the sensor by means of intermediate coordinates, forwards the datagram to router 2 that, again,
nodes forwarding this request. The response, on the other is the closest one in the direction of the destination. Finally,
hand, makes it back all the way to the remote user. router 2, that has a direct link to the destination, just forwards
Location based routing is an alternative to both address the datagram. Location based routing can be combined with
and data-centric routing. It consists of a client or device hierarchical routing to exploit traffic aggregation.
transmitting datagrams to another client or device by for- One drawback of traffic aggregation, however, is that it
warding the traffic based on the geographical or physical results in increased throughput that limits channel capacity
location of the destination. To this end, the client and each and leads, in turn, to contention as well as additional latency.
router along the way estimate the direction of propagation of So, one desired property when performing aggregation is
datagrams to efficiently reach the destination with minimal making sure that readouts are processed and compressed
energy consumption. Figure 7.4 illustrates an example of at the device whenever possible. In other words, local pro-
7.1 Routing Concepts 173

Fig. 7.3 WSN data forwarding remote user

IP

local user
qu
re er
sp
on
y WSN
se

gateway

sensor

Fig. 7.4 Location based routing source

router 1
dir
ec
ti
on
di
re
ct
io
n

dire
router 2 ctio
n

destination

cessing enables the conversion from data to information transmitted thus reducing the overall network bandwidth
presented in Sect. 1.3. The price to pay for the conversion is utilization. There is, therefore, a balance between respon-
the need for higher computational power that together with siveness and power consumption. Moreover, reducing power
the transmission of aggregated data increase battery drainage. consumption is typically accomplished by means of power
The overall idea of routing mechanisms in the context cycles that require full network coordination to minimize
of both WSNs and IoT is to maximize the network lifetime latency and other negative effects on the routing algorithms.
attempting to distribute routing traffic over as many devices Routing is classified in regard to three possible strategies
as possible. Aggregation and routing must be highly efficient that relate to the balance between responsiveness and power
due to the well known energy limitations and constraints of consumption: (1) proactive routing consists of building rout-
embedded devices like sensors and actuators. In general, the ing tables that ultimately define forwarding behavior by
lower the power consumption, the less responsive the routing means of the periodic transmission of routing information
mechanism is, as fewer routing control packets are typically across all nodes in the network, (2) reactive routing relies
174 7 Routing on Constrained Devices

on dynamic on-demand building of routes from sources to

specific destinations by relying on route discovery queries 1
that flood the network, and (3) hybrid routing combines
proactive and reactive routing on different sections of the
4
network. Proactive routing is characterized by heavy control
traffic overhead that results from the continuous transmission
3
of routing information even when device datagrams are not
sent. Reactive routing, on the other hand, minimizes control
2 6
traffic transmission until a routing decision, triggered by the
transmission of device datagrams, is made. Proactive routing
is effective when overall network traffic is high, and latency
must be kept low. Comparatively speaking, reactive routing 5 8
is more efficient from an energy perspective, but it can result
in device traffic transmission being delayed until routing
decisions are made on-demand. Hybrid routing is used in
hierarchical schemes where proactive routing is performed
inside clusters and reactive routing is used across clusters.
7

Fig. 7.5 Flooding

7.2 WSN Routing

WSN routing schemes incorporate different algorithms that

1
use and integrate aspects of flat and hierarchical routing com-
bined with data-centric and location based mechanisms. They
range from simple datagram flooding to highly sophisticated
hierarchical data-centric approaches.
2 3

7.2.1 Flooding

Flooding is the simplest flat routing mechanism for path 4

discovery that has been widely used in the context of data
networks [4]. It is based on devices forwarding received Fig. 7.6 Traffic implosion
datagrams through all possible neighbors. As such, it does not
rely on routing tables and therefore it requires neither extra
memory nor additional computational complexity. Moreover,
due to its dynamic nature, flooding adapts quite efficiently to the counter becomes zero, the datagram is dropped by the
network topology changes. Now, simpleness and flexibility corresponding device. A slightly more resource intensive
are expensive from an energy perspective, making flooding but more efficient approach consists of assigning, on gen-
largely impractical in most deployments. eration, a random identifier to the datagram. Devices can
Figure 7.5 presents a flooding example, eight devices then build tables to keep track of the different datagrams in
generating and forwarding datagrams to provide full end-to- order to automatically drop them whenever they are about to
end connectivity. Because flooding generates many copies of be retransmitted. Obviously, this implies extra memory and
the same datagram, both channel utilization and contention additional computational complexity.
are high enough that they lead to some loss and latency The energy inefficiencies come manifested as (1) traffic
that is typically compensated by the intensity of the traffic. implosion and (2) overlapping. Traffic implosion is shown in
Additionally, since a device can forward the same datagram Fig. 7.6. The same datagram generated by device 1 arrives as
an infinite number of times, flooding usually relies on the two copies to device 4. This is not only a waste of energy
use of hop counters to prevent this type of loops. As a but a waste of network bandwidth and channel capacity.
datagram circulates throughout the network, its hop counter Overlapping, shown in Fig. 7.7, consists of redundant sensor
is decremented by one each time it is forwarded. When data being transmitted over multiple datagrams that simulta-
7.2 WSN Routing 175

b
1

a c
a
b 4

1 2
e 3 c
d

2
3 6

f
Fig. 7.7 Flooding traffic overlapping
5 8

neously arrive at destination. Device 1 transmits a datagram g

that contains data associated with assets a and b while device
2 transmits a datagram that contains data associated with
assets b and c. Then both datagrams arrive at device 3, two
copies of the data related to asset b are received. Again, this is 7
not only a waste of energy but a waste of network bandwidth
Fig. 7.8 Gossiping
and channel capacity. Both traffic implosion and overlapping
eventually lead to resource blindness that result in the device
energy being depleted. Since the flooding algorithm is not
aware of device power consumption, resource blindness is, (continued)
sooner than later, unavoidable.

7.2.2 Gossiping

An alternative to flooding that relies on intermediate devices

forwarding a received datagram to a single randomly selected
neighbor is called gossiping. Gossiping, by being a variation
of flooding, is also a flat routing algorithm [11]. The idea is to
minimize the power consumption by bounding the number of
transmissions associated with each hop. Moreover, as in the
flooding case, datagrams also include hop counters that limit
how many times they can be forwarded.
Figure 7.8 shows an example of gossiping; device 1 sends
a datagram to device 7. The datagram traversal follows seven Assume that packets are uniformly transmitted in
hops a, b, c, d, e, f, and g. At each hop, the datagram is order to provide full connectivity among all devices.
forwarded to only one neighbor. While the most efficient If the transmission rate is 250 Kbps, the packet
path consists of three hops through devices 3 and 5, the size is 200 bytes and ignoring collisions as well as
random nature of gossiping can result, as illustrated in the delays (other than the transmission delay), what is
example, in a lot more inefficient path. Longer paths imply, the expected transmission delay in a flooding scenario?
when compared to flooding, higher latency and imply, when
compared to the randomly selected shortest path, higher Solution: The transmission delay of a packet over a
energy consumption. single hop is Dh = 8×200 bytes
250000 bps
= 6.4 ms. Each device
transmits to N = 4 other devices, therefore, the delay
Example 7.1 Consider a WSN based ring topology with respect to two of those devices is Dh while the
where devices send packets to each other: delay with respect to the remaining two devices is 2 ×
Dh . The expected delay due to flooding is, therefore,
Dflooding = 2×Dh +2×2×D
N
h
= 9.6 ms.
(continued)
176 7 Routing on Constrained Devices

7.2.3 SPIN its data to other devices in the network even if they are not
directly connected. Essentially, device 1 starts by advertising
Sensor Protocols for Information via Negotiation (SPIN) metadata that its neighbor device 2 expresses interest in by
is a flat data-centric routing mechanism that through data transmitting back a request. This request triggers device 1 to
negotiation and resource adaptation enables devices to for- send the data to device 2. Device 2 forwards the associated
ward datagrams from a source to a sink in a much more advertising metadata to all its neighbors. From those, only
controlled and more energy efficient way than flooding and devices 3 and 6 are interested in requesting the data. Upon
gossiping [14]. Energy efficiency is accomplished by mak- receiving the requests, device 2 forwards the data to those
ing devices learn about the metadata associated with other devices.
devices before any datagrams can be forwarded. Metadata SPIN is further improved as SPIN Energy Conservation
are data that describe other data and, as such, are typically (SPIN-EC) by considering energy consumption. SPIN-EC
much smaller than the described data themselves. By being enables devices to minimize their participation in operations
smaller, lower transmission rates and less energy are needed if their energy levels fall below a certain threshold. For
for transmission. example, a device will only send an ADV message if it
SPIN relies on end and intermediate devices advertising considers that it has enough energy to process REQ and
metadata that they generate or forward so that other devices generate the corresponding DATA messages. Similarly, if a
interested in the associated data can request them [9]. Data device receives an ADV message, it will only transmit a REQ
are sent to the devices that are really interested in forwarding message if it considers it has enough energy to process the
or using them in order to minimize the waste of energy that incoming data.
results from sending datagrams to nodes that do not need to Although SPIN is a P2P mechanism it also introduces a
be involved in the process. Moreover, SPIN, when compared broadcast version, called SPIN Broadcast (SPIN-BC) that
to flooding, eliminates the transmission of redundant data relies on devices sharing a single channel. If a device sends
that causes traffic implosion and overlapping. an ADV, REQ, or DATA message, it is received by all other
Resource adaptation in SPIN means that devices, based on devices that are located within the transmission coverage area
the current energy levels, decide what resources to negotiate of the sender. The idea is to take advantage of the redundancy
and advertise before the real data are transmitted. In fact, as generated by the transmission of broadcast (or multicast)
energy levels become too low, a device can reduce and po- messages. Moreover, timing becomes critical under SPIN-
tentially eliminate the forwarding of metadata and real traffic BC since a device will delay the transmission of a REQ
data [8]. Device redundancy is, in these cases, important as an message to see if another co-located device is also attempting
energy depleted device can become a single point of failure. to request the same data. The length of the delay is estimated
Resource adaptation is, in the end, a way to control the overall based on the available device energy; the more energy, the
network lifetime. shorter a device will wait to transmit a REQ. The idea is
SPIN messages used for routing can be (1) advertising to extend overall network lifetime by giving those devices
(ADV), (2) request REQ, or (3) data DATA messages. The with the least amount of energy the greatest opportunity to
ADV message enables a device to advertise the metadata preserve it. Once the advertising device receives the REQ
that describe the type of data it supports. If any other device message, it broadcasts the DATA message to all interested
is interested in the advertised data, either to consume or devices including those that did not implicitly send the orig-
forward them, it sends a REQ message to obtain a copy inal REQ message.
of the real data. When received by the original metadata Figure 7.11 shows SPIN-BC operations; device 1 adver-
transmitter, the request triggers the transmission of a DATA tises its metadata to all listening devices 2, 3, 4, 5, and
message containing the actual data. These transactions are 6. If devices 2, 5, and 6 are interested in the data, device
illustrated in Fig. 7.9. Again, since the ADV message is much 2 broadcasts a request first, as it comparatively has more
smaller than the corresponding DATA message, the mecha- energy. Both devices 2 and 5 do not do anything and just wait
nism guarantees that energy is only spent on the transmission for the DATA message that is later broadcasted by device 1.
of datagrams that carry relevant information. One last SPIN mechanism, known as SPIN-RL, provides
Figure 7.10 shows a simple example of SPIN data nego- reliability when the underlying network is prone to packet
tiation and propagation; the idea is for device 1 to transmit loss and other impairments. Essentially, SPIN-RL introduces
two ways to accomplish additional reliability: (1) it relies on
retransmissions that are triggered whenever a DATA mes-
ADV sage fails to arrive after the transmission of a request and
REQ
(2) it transmits periodic ADV messages that are tracked
1 DATA 2
by the receiving devices to make sure that they are not
redundant.
Fig. 7.9 SPIN transactions
7.2 WSN Routing 177

1 1 1

3 3 3

2 2 2
4 4 4
7 7 7

5 5 5 6
6 6

1 1 1

3 3 3

2 2 2
4 4 4
7 7 7

5 5 5 6
6 6

Fig. 7.10 SPIN operations

Fig. 7.11 SPIN-BC

2 3 2 3

1 1
6 4 6 4

5 5

2 3

1
6 4

One critical issue with any of the versions of SPIN is that if [17]. It provides multipath datagram propagation or diffusion
a single device, for whatever reason, fails to propagate ADV throughout a network by primarily focusing on the message
messages, the end-to-end network connectivity collapses. exchange of close-by devices. The message exchange is
Fortunately, other mechanisms overcome this problem. based on four main components: (1) interests that define the
nature of data to be requested or subscribed, (2) gradients
that specify the spatial direction of specific data types, (3)
7.2.4 Directed Diffusion data messages that provide the sensor readouts, and (4)
reinforcements that enable a device to give higher priority
Directed Diffusion is another flat data-centric rout- to certain paths in a multipath scenario. Directed diffusion
ing,10.5555/1203508 mechanism that relies on response provides routing through a publish/subscribe scheme like
aggregation to accomplish power consumption efficiency that of the application layer described in Sect. 5.3. In this
178 7 Routing on Constrained Devices

case, a device acting as a querier transmits a question that duration indicates the lifetime of the interest. Figure 7.12
represents a specific interest presented as an attribute-value shows an example of interest propagation and caching. The
pair [18]. device 1, acting as a sink, transmits its interests for tempera-
An example of a device interest is shown in Table 7.1. The ture data to its close neighboring devices 2 and 3. When these
device is interested in temperature readouts that are transmit- devices receive the interest, they add an additional cache
ted every second for an hour in the geographical location entry to tie the temperature type to the device 1 sink. The
determined by the square region with opposite corners lo- interest is forwarded by device 2 and 3 to their neighbors that
cated at geographical coordinates 41.40,2.17 and 41.41,2.19. now create new cache entries indicating these two devices
Note that by including geographical information, directed are sinks of the data. Interests are forwarded unaltered with
diffusion can be seen also as an example of location based modified sink fields as they are propagated. When a device
routing. receives an interest, it updates or adds to its cache a new
In general, an application device will periodically broad- entry that includes a gradient that points to the neighbor that
cast its interests in order to figure out if there exist other transmitted the interest. Essentially, the mechanism relies on
devices that can service them. As an interest traverses the the diffusion of interests across the network such that all
network, it is cached by devices such that whenever data devices with connectivity to the sink have an entry associated
are propagated down from servicing devices, they can be with the interest in their caches. If a device transmits sensor
forwarded to those with an active interest. A cache entry data that comply with an interest, this causes intermediate
includes a timestamp, a gradient for each neighboring device, devices to forward the data to the sink based on gradient and
and a duration field. The timestamp indicates when the desired rates.
interest was last received, the gradient specifies the direction The entries in the different caches can be used to reinforce
and the rate at which the readouts are transmitted, and the specific sensor data paths. For a given interest, if an entry
does not exist, it is added but, however, if it does exist, it is
updated. Since entries have timestamps and durations, they
Table 7.1 Interest example
expire and are removed from caches. Through different up-
Attribute/value pair Description dates a single interest may have different gradients associated
Type = temperature Temperature readouts with different data rates that may expire at different instances
Interval = 1 s Report events every second of time.
Duration = 3600 s Report for an hour In the scenario shown in Fig. 7.13 device 1 diffuses its
Field = [(41.40, 2.17) , (41.41, 2.19)] Report from sensors in this area
interests across the network for cache entries to be added

interest

Type Temperature
Interval 1s
Duration 3600 s
Field [(41.40, 2.17)(41.41, 2.19]
Sink 3 interest
4
Type Temperature
6 5 Interval 1s
Duration 3600 s
Field [(41.40, 2.17)(41.41, 2.19]
Sink 2

2
3 interest

CACHE Type Temperature

Interval 1s
Sink Type Duration 3600 s
1 Humidity Field [(41.40, 2.17)(41.41, 2.19]
1 Pressure 1 Sink 1
1 Temperature sink

Fig. 7.12 Interest propagation and caching

7.2 WSN Routing 179

before they are forwarded to the sink. In order to minimize

4 throughput and preserve device energy, clusterheads usually
6 5 eliminate any redundancy that may exist in the aggregated
data. This redundancy removal plays the role of the IoT data-
information conversion first introduced in Sect. 1.3.
Figure 7.15 shows a LEACH network. Essentially, de-
vices talk to clusterheads, that in turn, talk to the sink. The
2
transmission between the clusterheads and the sink as well
3
as between the devices and the clusterheads is single hop.
The media access is TDMA based such that devices are
scheduled by clusterheads to transmit the sensor data in
specific time slots. In addition, and to reduce the interference,
1 communication between devices inside and outside a cluster
sink is CDMA based.
Since clusterheads typically consume more energy than
Fig. 7.13 Initial setup regular devices, LEACH implements a scheme of rounds
where clusterheads are dynamically assigned on a round-by-
4 round basis. This clusterhead rotation distributes the overall
energy consumption between devices thus maximizing net-
6 5
work lifetime. This is illustrated in Fig. 7.16. Within a single
round there are two stages: (1) cluster setup and (2) steady
state. In the cluster setup stage, the clusterhead is selected
and the cluster itself is formed. Once devices have their roles
2 assigned, in the steady state stage, regular devices collect
3 data that are aggregated at the clusterhead and delivered to
the sink. The steady state stage consists of multiple frames
with timeslots that give the opportunity to all regular devices
to propagate their data to the clusterhead. The setup stage
is typically short in order to lower both the scheme latency
1
and the overhead of the mechanism. The steady state stage is
sink
longer, but it cannot be too long because it could potentially
Fig. 7.14 Reinforced path drain all the energy of the clusterhead.
One of the advantages of LEACH is the highly distributed
nature of the setup stage. Specifically, clusterhead selection
in all intermediate and end devices. As time progresses, and cluster formation require little communication between
device 1 may reinforce the path to device 3 by sending the devices. Given several N devices, the clusterhead selection
original interest at a higher rate such that the source device consists of device n with n ∈ (1, N) selecting a threshold
5 sends data more frequently. This is illustrated in Fig. 7.14. T (n) given by
Reinforcement is typically applied to those paths that serve as

alternatives to other paths affected by excessive latency and P
1−P (rmod( P1 ))
if n ∈ G
network loss. T (n) = (7.1)
0 otherwise

7.2.5 LEACH where r ≥ 0 the round number, P is the probability that a

device will be clusterhead in any given round and G contains
Low Energy Adaptive Clustering Hierarchy (LEACH) is a the set of devices that has not been selected as clusterhead
hierarchical routing algorithm that by means of aggregation in the last 1/P rounds. Device n then generates a uniformly
it transmits device data to an application that acts as a sink distributed random number v ∈ (0, 1) that is compared to
[7, 14]. By relying on both hierarchical routing and aggre- T (n). If v < T (n), then device n becomes clusterhead oth-
gation, LEACH accomplishes levels of power consumption erwise it just behaves like a regular device. This mechanism
efficiency that extend the overall network lifetime. As any guarantees that a device can only be selected as clusterhead
hierarchical approach, the algorithm segments the network once in a period of 1/P rounds. Once the clusterheads are
into multiple clusters with clusterheads that aggregate all data selected, the remaining devices select what cluster to join.
180 7 Routing on Constrained Devices

Fig. 7.15 LEACH network data sink

clusterhead
clusterhead

clusterhead

one slot per node has not been selected in the last 1/P rounds [13]. LEACH is
extended by means of the eXtended LEACH (XLEACH) [10]
protocol to consider the device energy level when calculating
frame the T (n) threshold as

P
T (n) =   
1−P rmod P1
  

En,current 1 En,current
round cluster setup
+ rn div 1− (7.2)
En,max P En,max

Fig. 7.16 LEACH rounds where rn is the number of consecutive rounds in which the
device has not been a clusterhead and En,current as well as
En,max are respectively the current and initial energy levels
Specifically, devices estimate the distance to the clusterheads
of the device. When the value of rn becomes equal to 1/P , the
based on the received signal power and select the closest
threshold becomes
one. Until this point, all clusterhead selection and cluster
formation are done offline. The devices then communicate P
with their selected clusterheads to initiate the association. T (n) =    (7.3)
1 − P rmod P1
The clusterheads, in turn, set up and broadcast the TDMA
schedules to their associated devices. After the setup stage which is the original threshold that does not take into account
is finished, the steady state stage starts. Devices take turns energy in the computation of its value. When a device be-
transmitting sensor data to the clusterhead in accordance comes clusterhead the value rn,s is reset.
to the broadcasted schedule. As indicated in Fig. 7.16, each
device transmits only once per frame with multiple frames
being part of the stage. 7.2.6 PEGASIS
One issue with the clusterhead selection process is that it
does not have into consideration energy levels of the devices Power-Efficient Gathering in Sensor Information Systems
under consideration. Even if a device does not have enough (PEGASIS) is another hierarchical routing mechanism that
energy, it may still result in being selected as clusterhead if it relies on data aggregation [14, 15]. In a similar way to
7.2 WSN Routing 181

LEACH and XLEACH, PEGASIS attempts to lower power rounds. The clusterhead aggregates traffic from all other
consumption by distributing the role of clusterhead among all devices and forwards it to the sink application. The start
the devices in a section of the network. Moreover, PEGASIS of each round can be triggered by timing or by the sink
also lowers network latency by performing simultaneous data application itself that transmits a special beacon to indicate
aggregation on multiple devices. The overall result of these this. Note that depending on the distance to the sink, certain
mechanisms is to extend the overall network lifetime. devices may end up, on average, consuming more power per
Under PEGASIS, a device is aware of the geographical round than others.
location of its neighbors and can control its transmission But aggregation is not just performed by the clusterhead,
power in order to just reach the closest one. This latter prop- under PEGASIS half of the devices in the round perform
erty is usually enforced using CDMA modulation schemes. some type of data aggregation. Figure 7.18 shows an example
PEGASIS relies on a chain structure that results from direct of a PEGASIS round with 8 devices, A through H, in positions
communication of devices with their immediate neighbors. 0 through 7 within the chain respectively. In this case device
Figure 7.17 shows an example of such a scheme, device A D, initially in position 3, is the clusterhead. The first stage of
first selects its closest neighbor, device B, as the first link of the round have all the devices in even positions (i.e. 0, 2, 4,
the chain. Device B, in turn, selects its closest neighbor device 6) transmit their data to their next door neighbors in the odd
C as the second link. The process continues with all other positions (i.e. 1, 3, 5, 7). At this point, device B has device
devices selecting their closest neighbors in order to set up the A data, device D has device C data, device F has device E
different links of the chain. Note that the chain formation is data, and device H has device G data. Now devices B, D, F,
initiated by the farthest device and continuous by sequentially and H are at positions 0, 1, 2, and 3. The second stage of
adding devices to the chain. The selection is greedy based on the round consists, again, of all devices left in even positions
distance that can be inferred from the received signal power. (i.e. 0 and 2) transmit their data to their neighbors in the odd
As in the LEACH case, transmission is based on rounds positions (i.e. 1 and 3). After this stage, device D has device
where devices take turns in becoming clusterheads. The idea B data and device H has device F data. For the last stage, only
is that the energy consumption burden gets distributed among the clusterhead device D and the device H are left. Because
the different devices in the cluster. For any given round, a the clusterhead device always aggregates data regardless of
device in the chain is designated clusterhead. The clusterhead its position, the device H forwards all its data to it. Once the
selection is sequential so that if the chain is 8-device long, clusterhead has all the data from all other devices it transmits
a device will become, on average, clusterhead every eight them to the sink.

Fig. 7.17 PEGASIS structure

H
sink
G
F
E sink

B
A C A B C D E F G H

Fig. 7.18 PEGASIS aggregation clusterhead

D H

0 1 node position

B D F H

0 1 2 3 node position

A B C D E F G H

0 1 2 3 4 5 6 7 node position
182 7 Routing on Constrained Devices

The mechanism is developed to make sure that energy

7.3 RPL
consumption is fairly distributed throughout the network by
shifting the role of the clusterhead and the devices transmit-
WSN routing protocols like SPIN, PEGASIS, and LEACH
ting data based on their position. For any given round with N
provide elements that are relevant to routing in the context of
devices, the number of stages is around log2 (N) . Note that
IoT. Essentially, WSN are, like IoT networks, limited from
energy is also preserved by limiting the transmission power
a power consumption perspective leading to computational,
of a device by making sure it only reaches its uplink neighbor.
resource, and communication constraints that heavily affect
This results in a higher SNR that enables parallelism that
routing. Specifically, these constraints manifest themselves
maximizes the number of simultaneous transmissions and
as packet loss that is typically transient and unpredictable.
minimizes the number of stages. Compare this scenario to
Traditional IP routing falls under two main categories: Dis-
a scheme, shown in Fig. 7.19, where interference between
tance Vector (DV) and Link State (LS) [6]. DV consists of
devices forces the sequential transmission of data that are
devices sending their entire routing tables to their connected
aggregated until they reach the clusterhead. In this case, the
neighbors. LS, on the other hand, consists of devices sending
number of stages is N − 1. Table 7.2 shows a comparison of
the state of their links to all the devices in the network.
LEACH against other WSN routing mechanisms.
With LS all devices get the same picture of the network
and therefore they can recreate the same global routing table
in a distributed fashion. LS routing protocols are, therefore,
A B C D E F G H more reliable than more localized DV routing protocols.
Both, DV and LS, react to network lossiness by attempting
0 1 2 3 4 5 6 7
to quickly reconverge and find alternative routing paths. The
A B C D E F G H assumption is that under conventional high throughput traffic
any long term interruption leads to large amounts of data
0 1 2 3 4 5 6 7 not being received at the far end. Unfortunately, due to the
D H
transient nature of the IoT network datagram loss, these
A B C E F G
traditional routing approaches lead to instabilities and unac-
0 1 2 3 4 5 6 7 ceptable control data overhead. IoT traffic is associated with
low throughput so slow reconvergence does not necessarily
A B C D E F G H
imply a large loss of data. In this context, a more appropriate
0 1 2 3 4 5 6 7 routing solution for IoT consists of under reacting to the
transient changes of connectivity in the network and only
trigger full reconvergence when really needed. Additionally,
A B C D E F G H
as part of the IPv6 bootstrapping initiated by SAA, routing on
0 1 2 3 4 5 6 7 IoT devices must be self-manageable and require no human
intervention.
A B C D E F G H
One way to measure network reliability is by means of
0 1 2 3 4 5 6 7 metrics like BER introduced in Sect. 3. Whenever a frame
is demodulated and a bit ends up decoded incorrectly, the
A B C D E F G H calculated FCS does not comply with the received FCS and
the frame is dropped. This loss is measured by means of
0 1 2 3 4 5 6 7
another metric known as Packet Delivery Ratio (PDR) that
Fig. 7.19 Sequential aggregation indicates the probability that a transmitted frame will be
received at destination. Essentially PDR = 1 − p where p is
Table 7.2 WSN routing protocols the frame loss probability. A link that is fully disconnected
Mechanism Hierarchical Data- ComplexityLatency Energy behaves as if it were affected by a 0% PDR. The inverse
centric consump- of the PDR is the Expected Transmission (ETX) defined as
tion
ETX = PDR 1
. Therefore as PDR → 0 then PDR → ∞. In
Flooding No No Low Low High
the context of IoT LLNs, PDR values are inherently unstable
Gossiping No No Medium High Medium
and can vary a lot as a function of time. Figure 7.20 shows
SPIN No Yes Medium High Medium
the PDR variation as a function of time for three different
Directed Yes Yes Medium Medium Low
diffusion
IEEE 802.15.4 links. These variations would cause network
LEACH Yes No High Medium Low instability under traditional IP routing because traditional
PEGASIS Yes No Medium Low Low routing is prepared to react to dynamic changes of network
7.3 RPL 183

Fig. 7.20 PDR variation 1

0.9

0.8

0.7

0.6

PDR
0.5

0.4

0.3

0.2
Link1
0.1 Link2
Link3
0
0 5 10 15 20
time(h)

metrics like PDR very fast. Under IoT LLN routing, however, control traffic usually triggered by trickle timers described in
the assumption is that these metrics naturally change over Sect. 7.3.3.
time and it requires the routing algorithm to underreact
in order to prevent additional connectivity issues. Only if
routing problems are persistent it is expected that the routing 7.3.1 DODAG Creation
mechanism will redirect traffic through alternative routes
without triggering global reconvergence. RPL is a routing protocol that operates at the IPv6 network
The IETF Routing over Low Power and Lossy Networks layer and, as such, contrasts with other mechanisms that work
(ROLL) work group standardized a routing protocol that at lower layers like 6LoWPAN link layer mesh forwarding
follows these principles [16]. The routing protocol, known described in Sect. 4.3.3. Additionally, RPL is based on the
as Routing for Low Power (RPL) or Ripple, is a hierarchical adaptation of a hierarchical DV scheme applied to LLNs. The
IPv6 address centric [1] protocol. RPL was designed to procedure starts with the creation of a Destination Oriented
comply with three goals: scalability, reliability, and energy Directed Acyclic Graph (DODAG) that enables devices to
efficiency. RPL builds IPv6 networks with thousands of con- keep track of the routing topology. A DODAG is built based
strained devices over multiple low power wireless hops that on an objective function that operates on a combination of
combine reliable transmissions with several years of battery metrics and constraints in order to find the best path. In fact,
life. The idea behind RPL is that any device in a WPAN for the same network topology many different objective func-
can be router so the network can be easily deployed. This, tions associated with the different metrics and constraints
indirectly, limits the characteristics of the routing mechanism may lead to routing scenarios that would carry traffic based
to guarantee the support of low complexity devices. on QoS requirements. Metrics and constraints can be either
By being based on WSN routing, RPL makes two im- device or link based. For example, a device metric can be
portant assumptions: upward focused routing and reactive the device energy level while a link metric can be the latency
route update. Upward focused routing, by means of M2P associated with the link. Similarly, a device constraint can
traffic flow, implies that traffic moves mostly upward due to be that the device must support encryption while a link
sensors transmitting readouts. Although RPL supports traffic constraint can be that the link must be wireless. Metrics
in both directions, the focus is reliable upward routing. The can be applied individually or aggregated along a path. For
idea is for each device to select a parent as the next hop example, latency of a link can be the latency associated with
for its upward route based on DV from the gateway and set a single hop or the latency aggregated over multiple hops.
the downward route by reversing the upward route. Reactive Objective functions may result in DODAGs that attempt
route update implies that some routing decisions are made to find the best path that (1) minimizes ETXs (metric) over
by detecting physical connectivity changes that are reactive encrypted links (constraint) or (2) lowers latency (metric)
to data transmissions. This minimizes the use of proactive over unencrypted links (constraint) or (3) minimizes power
consumption (metric) or (4) uses wireless links (constraint).
184 7 Routing on Constrained Devices

The objective function, therefore, groups constraints and in joining the graph calculate their own rank and transmit
metrics as a way to specify rules for DODAG creation. Each DIOs in order to hierarchically extend the DODAG range.
graph represents a logical topology that exists on top of the Those devices joining a graph but without routing capabilities
physical network topology. At any given time, multiple logi- become leaves as they cannot transmit DIOs. Note that a
cal topologies overlap and depending on quality requirements single device may receive DIOs from multiple nodes and
only some of them are active. A device can then join one decide whether to join or not a DODAG based on the rules
or more graphs, known as RPL instances, and route traffic derived from its objective function. The route propagation
accordingly in order to accomplish the requirements. The starts at the root and ripples down to the leaves where the
datagrams are transmitted up and down along the edges of process finishes. The route enables all devices in the graph to
the corresponding DODAG. transmit datagrams to the LBR by means of the M2P upward
The DODAG creation is initiated by the Low Power PAN routing mechanism shown in Fig. 7.21. Note that the Figure
Border Router (LBR), also known as root, that plays the also shows DIS messages can be used by devices to proac-
role of IoT gateway. Multiple roots can serve an overlapping tively request upward routing information to its reachable
number of devices. There are three control routing messages, neighbors. Essentially, this provides an on-demand routing
transmitted over ICMPv6, that enable the graph creation: mechanism. Specifically, when a non-leaf device receives a
(1) DODAG Information Object (DIO), (2) DODAG Infor- DIS message it must respond by transmitting DIO messages
mation Solicitation (DIS), and (3) DODAG Advertisement that advertise the supported graph it is associated with.
Object (DAO). The ICMPv6 encoding, shown in Fig. 4.6, Upward routing is representative of traffic going from a
introduces a new ICMPv6 type field value known as RPL higher to a lower ranked node. Similarly, downward routing
and each message is indicated by different values of the results from datagrams propagating from lower to higher
ICMPv6 code field. DIS, DIO, and DAO messages carry ranked devices. Specifically, for a parent to be able to send
respectively ICMPv6 type field values 0, 1, and 2. The traffic to a child, it must know first how to reach it. RPL, as
LBR starts by periodically transmitting DIO messages that illustrated in Fig. 7.22, introduces DAO messages to accom-
advertise information about the DODAG to its neighbors. plish this task. They are transmitted by a device to its parent
Those devices that receive the DIO message and decide to as soon as the former joins a DODAG. Many times, DAO
join the graph become children of the LBR. For any child transmission can be induced by means of an indication in the
device, the LBR becomes its parent and assigns itself a rank incoming DIO message. In general, DAO messages carry and
that specifies its position in the graph hierarchy relative to the aggregate prefix information from a device and its children.
root and plays the role of DV path cost. In general, the smaller This information is used by lower rank nodes to add routing
the rank the closer the device is to the root. Conceptually table entries that enable downward routing. Essentially, pre-
the idea of the rank is to enable the routing algorithm to fix data eventually reach the LBR and a complete downward
determine the presence of loops. If the device is configured path becomes available.
with routing capabilities it can transmit, in turn, its own DIO Multi-Topology Routing (MTR) is supported by RPL to
to its neighbors in order to advertise the route to the LBR. overlap multiple routing instances over a single physical
The process is then repeated, and those neighbors interested topology. Figure 7.23 shows an example of two instances

LBR LBR
rank

rank

DIS DIO DAO

rank 1 rank 1
A A

rank 21 rank 22 rank 21 rank 22

B C B C

D E F D E F
rank 31 rank 32 rank 33 rank 31 rank 32 rank 33
leaf leaf leaf leaf leaf leaf

Fig. 7.21 Upward routing Fig. 7.22 Downward routing

7.3 RPL 185

Fig. 7.23 MTR

LBR LBR

DODAG instance 1 DODAG instance 2

Fig. 7.24 DIO message format 0 8 16 24

RPL INST VERSION RANK

G 0 M P DTSN FLAGS RESERVED

DODAGID

SUBOPTIONS

RPL INST RPL instance

G ground field
M mode of operation
DTSN DODAG advertisement trigger sequence number
DODAGID DODAG identifier

identified by two different instance identifier values. Each 0 8 16 24

instance is associated with an objective function that defines RPL INST KD FLAGS RESERVED DAO SEQ
routing rules and each device is associated, in turn, to multi-
ple instances. The device must then select the right instance DODAGID
based on the type of traffic being transmitted. For example,
real time data may need to be transmitted through an instance SUBOPTIONS
that supports low latency while data to be processed offline
RPL INST RPL instance
may need to be transmitted through an instance that relies K ACK expected
on encrypted links. Because of the dynamic nature of the D DODAGID present
network, the graph that complies with the objective func- DAO DAO sequence number
DODAGID DODAG identifier
tion of an instance also mutates. Therefore, a device that is
transmitting datagrams within the context of an instance may Fig. 7.25 DAO message format
trigger the reassociation with a new parent to support graph
and rank changes.
Figures 7.24 and 7.25 respectively show the DIO and message contains some of those fields but it also includes a
DAO message structures. The DIO message includes an 8- 1-bit acknowledgment flag that indicates whether the DAO
bit RPL instance field that identifies the routing instance, a sender expects a DAO-ACK message back, a 1-bit DODAG
16-bit rank field that specifies the rank of the device sending present flag that specifies whether the DODAGID is carried
the message, a 1-bit ground flag that indicates whether the in the DAO message and an 8-bit DAO Sequence Number
DODAG root is attached to the public Internet, a 3-bit mode field used to keep track of acknowledgments.
of operation field that specifies whether storing or non-
storing nodes are in use (described in next Section) and a
2-bit preference field that specifies the root preference. The 7.3.2 Storing and Non-storing Nodes
8-bit Destination Advertisement Trigger Sequence Number
(DTSN) is set by the message sender to maintain downward Besides keeping track of its own parent, a device that has
routes. The 128-bit DODAG identifier uniquely identifies the received DAO messages from higher rank devices must have
DODAG and it typically carries the IPv6 of the root. A DAO enough memory to store prefix information corresponding
186 7 Routing on Constrained Devices

to these devices’ subgraphs [3]. Since memory require- for not storing routing information is both higher latency
ments and computational complexity can be critical issues and less channel utilization efficiency. Since source routing
in embedded IoT devices, RPL supports two modes of op- information is added to the datagrams by means of a specific
eration: if a device stores prefix information from all its routing header known as RH4, the ratio between the sizes
children is called a storing node, otherwise it is called a of payload and headers decreases leading to less efficient
non-storing node. Although both, storing and non-storing use of the channel. Note that all devices must be configured
devices, can route datagrams uplink, only the former can as either storing or non-storing nodes. Mixed scenarios with
route datagrams downlink as they keep routing entries for some devices configured as non-storing nodes and others as
each of their children subgraphs. In non-storing mode, only storing nodes are not allowed.
the LBR can route datagrams downstream and other devices
can forward datagrams downward if they include embedded
routing information populated by the root. 7.3.3 Loop Detection and Avoidance
Figure 7.26 shows the difference between storing and
non-storing nodes when device D transmits a datagram to Network loops typically result from both topology changes
device E. In storing mode, shown by the dashed lines, device and routing information synchronization problems between
D forwards the datagram to its parent device B that, in devices. As such they are a temporary phenomenon that per-
turns, by being a storing node routes the datagram down sists until the routing mechanism solves the inconsistencies
to device E. In non-storing mode, shown by the solid lines, associated with the loop. Their detection is critical because
device D forwards the datagram to its parent B, that by not datagrams in a loop cause not only additional congestion
having routing capabilities, it forwards the datagram to its but also network loss when the datagrams are dropped due
own parent device A. Device A, another non-storing node, to them reaching the maximum hop count. In traditional
finally forwards the datagram to the LBR. The LBR makes networking, high transmission rates magnify the effect of
routing decisions based on its routing table and embeds loops in the overall effect of the network performance. In
source routing information in the datagram to indicate the this scenario, routing algorithms tend to overreact in order
path the datagram must follow downward. The datagram to detect and remove loops, as fast as possible, in order to
is sent to device A that processes the routing information minimize the effects of congestion and loss. In IoT networks,
and forwards it to device B. Device B, in turn, looks at the lower transmission rates, however, limit the impact of loops
routing information and forwards it to the destination device to network routing where an under reactive approach is more
E. Clearly there is a trade-off between latency and memory appropriate as many of the loops are caused by transient
requirements as well as computational complexity; the price link reliability issues. In this situation, overacting may lead
to routing oscillations that end up generating unpredictable
latency and energy consumption.
RPL attempts to avoid loops by enforcing two basic rules:
LBR
a device (1) cannot select as parent another device that is
deeper in the graph and it (2) is not allowed to move deeper
3 4 in a graph in order to increase the number of parents. Besides
avoiding loops, RPL enables devices to detect them through
data path validation. Specifically, the mechanism relies on
non-storing nodes
information carried by a series of bits in the RH4 header that
storing nodes A are used to determine the whereabouts of a given datagrams.
These bits are set and read as datagrams move up and down
along the edges of the graph. Whenever a node sends a
datagram to its children, it sets the down bit in the header.
If a datagram is received from a child and its RH4 header
B
has the down bit set, it indicates the presence of a loop. This
causes, in turn, the device to drop the datagram.
Routing protocols rely on repairs to fix routing topologies
when failures are detected. RPL supports two complementary
mechanisms: (1) local repairs and (2) global repairs. If due to
D E
a node or link failure a device cannot forward datagrams in
leaf leaf the upward direction, it must initiate a local repair to find
an alternative parent or link. The effect of local repairs is
Fig. 7.26 Storing vs non-storing nodes cumulative, and they can cause a graph to diverge from its
7.3 RPL 187

optimal shape. In this case, a global repair serves to rebuild

a DODAG. Global repairs are started by the root with the (continued)
transmission of DIO messages. From that point on, the graph and non-storing nodes?
is rebuilt with devices selecting parents based on objective
functions. The overall cost of a global repair is additional Solution: The transmission delay of a packet over a
latency and control traffic that affect channel efficiency. single hop is Dh = 8×100 bytes
250000 bps
= 3.2 ms. There are
two possible paths:
Example 7.2 Consider the following RPL scheme
where sensor A transmits a readout to sensor B: root

root

storing

A B

For non-storing nodes, the delay results from six hops

Dnon−storing = 6 × Dh = 19.2 ms. Similarly, for storing
A B nodes, the delay results from four hops Dstoring = 4 ×
If the transmission rate is 250 Kbps, the packet size Dh = 12.8 ms.
is 100 bytes and ignoring collisions as well as delays
(other than transmission delay), what is the expected Figure 7.27 shows a scenario of a topology with seven
transmission delay when propagation is over storing devices with neighbor connectivity indicated by the dashed
lines. For a given objective function an initial DODAG is
(continued)
generated where device 2 selects device 1 as parent. As time

Fig. 7.27 Local repair TOPOLOGY DODAG

1 1

2
4 2 5 4
3
5 7 3 6
6
time

1
1
2
4
5 4
3
5
6 2 7 3 6
7
188 7 Routing on Constrained Devices

progresses, the link between these two devices is perturbed timer as a mechanism for routing control traffic propagation
and connectivity is lost. This triggers a local repair that is simple enough that can be easily implemented on con-
results on device 2 now selecting device as parent. Note that strained devices without affecting computational complexity
many times there is no strong correlation between physical and other resources.
topology links and routing connectivity. Security in embedded IoT devices is computationally
Because embedded devices in IoT networks are energy expensive and resource demanding. Most RPL friendly link
constrained, limiting the transmission of routing DIO, DIS, layer technologies like IEEE 802.15.4 and BLE include their
and DAO control messages is critical to extending the net- own security mechanisms so RPL security is enabled by
work lifetime. Traditional routing protocols rely on keepalive means of optional extensions. Essentially, RPL supports three
messages transmitted periodically for devices to estimate modes of operations: (1) unsecured where routing control
throughput, latency, and loss of links associated with neigh- DIO, DAO, and DIS messages are transmitted without en-
bors in order to keep the routing tables updated. One of such abling any security measures and relying instead on the
mechanisms is called Bidirectional Forwarding Detection security provided by lower layers, (2) pre-installed where
(BFD). This approach to updating routing tables is not ap- devices have pre-shared keys that enable them to encrypt and
propriate for IoT networks as it is computationally complex, decrypt the messages, and (3) authenticated where devices
resource intensive, and energy inefficient. The RPL relies on receive the keys from an authentication authority. In pre-
an adaptive tickle timer that controls the rate at which DIO installed and authenticated modes, messages are secured by
messages are transmitted. Network inconsistencies like the encryption and message integrity at different security levels
presence of loops, or devices joining or moving within the supporting several algorithms like AES-128.
network, typically result in the reduction of the period of the When analyzing RPL from a performance perspective
trickle timer. On the other hand, as the network becomes there are a few observations that are worth mentioning: (1)
more stable the trickle timer period is increased and the control traffic associated with DIO, DIS, and DAO messages
DIO message transmission rate also decreases. The idea is negligible when compared to data traffic and decreases
of the trickle timer is to transmit network parameters and significantly as the graph becomes stable, (2) routing table
attributes while minimizing at the same time the load of the sizes are larger in those devices closer to the root of the
network. graph, (3) the routing paths that result from RPL are sub-
Figure 7.28 shows both data and control RPL traffic. optimal when compared to the ones that would obtained from
While the data traffic rate stays pretty constant, the control an ideal routing mechanism, and (4) by increasing the interval
traffic rate has peaks whenever the trickle timer triggers the between global repairs, local repairs become more prevalent
graph to be rebuilt. As the network becomes more stable, and control traffic throughout the network is reduced at a cost
the peaks are less common. The implementation of a trickle of longer lasting connectivity outages.

Fig. 7.28 RPL traffic 100

control
90 data

80

70
datagrams per second

60

50

40

30

20

10

0
0 20 40 60 80 100 120 140 160 180
time(s)
7.4 LOADng 189

 RPL Implementations There are several implemen- 6LoWPAN device 6LoWPAN router
tations of the RPL routing suite. Most of them are
intended for RTOSs. The list below shows some of the
most popular RPL implementations.

Implementation Description
Tripple Apache licensed open source C implementation
Available for general purpose OSs like Linux.
unicast
Adapted to support RTOS through lwIP.
multicast
Contiki RPL BSD licensed open source C implementation. SAA
Implemented as part of the Contiki RTOS.
Very low memory requirements (order of
kilobytes).
add to neighbor cache
TinyOS RPL BSD licensed open source C implementation.
Implemented as part of WSN support of the
TinyOS RTOS.
RIOT RPL LGPLv2 licensed open source C implementation.
Implemented as part of the RIOT RTOS.
RS Router Solicitation
Unsprung BSD licensed open source C implementation. RA Router Advertisement
Implemented as lightweight implementation of NS Neighbor Solicitation
RPL for Linux. NA Neighbor Adverstiment
SAA Stateless Address Autoconfiguration

Fig. 7.29 ND bootstrapping

7.3.4 RPL, 6LoWPAN, and ND may also include 6LoWPAN compression context data as-
sociated with stateful compression. Since the RA message
RPL is typically used in the context of 6LoWPAN route-over is received by all devices on a link, all devices are syn-
routing. In general, any link layer technology that supports chronized with respect to the compression context in use.
6LoWPAN mechanisms can rely on RPL for routing [12]. This is important, since device synchronization is key to
Moreover, multiple different link layer technologies can be the proper behavior of 6LoWPAN stateful compression. In-
routed under a single RPL domain. Edge routers that connect teraction between devices and the router is progressive as
to traditional IP cores and access 6LoWPAN networks oper- they exchange ND messages. In turn, routers supporting
ate as RPL roots. Devices rely on RPL to build multiple rout- RPL, generate DAO messages that propagate the informa-
ing topologies to enable connectivity to their destinations. tion obtained from the registration by means of ND boot-
Host devices indicate their presence to neighboring devices strapping.
in two different ways: (1) by transmitting DAO messages
upwards and processing, but not forwarding, incoming DIO
messages or (2) by relying on ND to discover neighboring 7.4 LOADng
routers and notify them about the device existence. In this
later case, hosts devices attach to 6LoWPAN routers by The Lightweight On-demand Ad hoc Distance Vector
means of traditional ND bootstrapping without participating (LOAD) and its successor the LOAD Next Generation
in routing. (LOADng) protocols are technologies that provide reactive
Figure 7.29 shows the exchanged messages between a flat routing in LLNs [2]. Although neither LOAD nor
device and router as part of ND bootstrapping. The 6LoW- LOADng have been standardized, LOADng serves as
PAN device starts by transmitting an RS message as both valuable alternatives to proactive RPL routing. LOADng is
multicast and unicast transmissions. The router responds designed for simplicity supporting a minimal core that can be
back with a unicast RA message. The prefix information extended for additional functionality. This is possible due to
carried by the RA is used by the device to initiate SAA, a modular design that enables the addition of new messages
described in Sect. 4.2, and derive an IPv6 address. The de- and data types encoded by means of TLVs. LOADng is quite
vice then registers itself at the router by transmitting a uni- flexible, supporting addresses of variable length between 8
cast NS message that includes the address registration op- and 128 bits long as well as different metrics besides the
tion. The router responds back with a NA message. Note standard hop count.
that in addition to the prefix information, an RA message
190 7 Routing on Constrained Devices

7.4.1 Minimal Core Upon receiving RREQ and RREP messages, devices up-
date their routing tables to adjust the cost of the path to the
As a reactive routing protocol LOADng transmits Route message sender. The simplest cost metric is hops but more
Requests (RREQs) to discovery paths to a given destination. complex metrics like latency, throughput, and frame loss
A single RREQ is forwarded throughout the network until it are also possible. A routing scenario may support multiple
reaches the destination device which replies by transmitting metrics that are specified in the RREQ and RREP messages.
a Route Reply (RREP). If a path is broken a local repair is In all cases, all devices must support the basic hop metric that
typically performed, otherwise, a Route Error (RERR) is must be used if the other metrics are not available.
sent back to the sender of the RREQ. In general, an RREQ
message is generated by a LOADng device when it does
not have a valid route to destination. Similarly, an RREP 7.4.2 Smart Routing
message is generated by a LOADng device in response to
a received RREQ message with a destination address local One issue with flooding is that it leads to issues like over-
to that of the device. RREP messages are acknowledged lapping and traffic implosion, that in turn, cause a waste of
by the RREQ original sender by transmitting back a Route energy, network bandwidth, and channel capacity. LOADng
Reply Acknowledgment (RREP-ACK) to indicate that the introduces a mechanism called smart routing that takes ad-
route was successfully received. The encoding of these mes- vantage of known routes to the destination in intermediate
sages, transmitted over UDP to support broadcasting, is by devices to minimize the number of broadcast transmissions
means of IETF RFC 5444 Generalized Mobile Ad Hoc Net- that are generated during route discovery.
work (MANET) Packet/Message Format as a fixed number of The procedure starts by broadcasting a special RREQ
header fields followed by a block of message TLVs. These are message that includes a flag that converts it into a
then followed by a block of addresses with associated address RREQ_SMART message. When the message arrives to
TLVs. an intermediate device if this device has a valid path to
Route discovery, carried out in a similar way to WSN destination and the corresponding next hop if different
flooding presented in Sect. 7.2.1, consists of devices broad- from the previous hop associated with the message, then
casting RREQ messages along the way to reach the des- RREQ_SMART message is transmitted unicast to the
tination. This is shown in Fig. 7.30 where device 1 is the next hop otherwise the message is broadcasted. This
originator and device 4 is the destination. When the request procedure is shown in Fig. 7.32 where device 1 broadcasts
arrives at the destination, a unicast RREP, that contains the the RREQ_SMART message that is received by device 2
path information, is transmitted back to the originator as illus- that has a direct route to destination device 4. Device 2 then
trated in Fig. 7.31. From this point on, the originator will send forwards the RREQ_SMART message through a unicast
all datagrams to reach the destination through this path until transmission to device 3. Device 3 that is also a direct route
a failure is detected. This process, called path maintenance, to device 4 also forwards the message to the destination
makes sure that if a datagram cannot be forwarded for any device 4 through a unicast transmission. Although reactive
reason, a RERR message is sent back to the originator. At this flat LOADng smart routing improves performance, still it
point the RERR message retriggers a new route discovery. is not as efficient as proactive hierarchical mechanisms like
RPL.
ART
RREQ_SM

RREQ RREQ RREQ T

1 2 3 4 MAR
_S
EQ
RR
RREQ_SMART RREQ_SMART RREQ_SMART
1 2 3 4
RR
EQ
_S
MA
RREQ_S

Fig. 7.30 LOADng route requests RT

MART

RREP RREP RREP

1 2 3 4

Fig. 7.31 LOADng route replies Fig. 7.32 LOADng smart route requests
Homework Problems and Questions 191

Table 7.3 RPL vs LOADng 7.2 What WSN routing protocols rely on endpoint negotia-
Energy tion to overcome implosion?
Protocol Hierarchical Proactive Transport Latency consumption
RPL Yes No ICMPv6 Low Low 7.3 A WSN has five sensors (A, B, C, D, E) with batteries
LOADng No Yes UDP MediumLow that are charged at PA = 94%, PB = 97%, PC = 99%,
PD = 91%, and PE = 4%, respectively. In the last 4 rounds
sensors A, B, C, D has been selected as clusterheads. For the
Summary following round, and assuming LEACH routing, which of the
sensors is most likely selected as clusterhead? Clusterhead
Routing is key to enable IoT devices to communicate with probability is P = 15 ?
applications. This chapter started by presenting the most
relevant concepts of IoT routing including their types and 7.4 Given the following RPL topology:
classifications. As an introductory approach to IoT routing,
well known WSN routing mechanisms were presented first.
This included flat flooding, gossiping, SPIN, and directed LBR
diffusion as well as hierarchical LEACH and PEGASIS. The
chapter then presented RPL and details of its hierarchical
approach including DODAG creation, maintenance, and sup- 11 12
port of storing and non-storing nodes. LOADng was then
presented as a valid reactive alternative to proactive RPL.
Table 7.3 compares some of the most important features of
21 22
RPL and LOADNg.

31 32
Homework Problems and Questions

7.1 Given the following topology and if transmit-

ting/propagating a single datagram over each individual 41

hop takes 1 s:

(a) What is the best route from node 41 to node 22 when

non-storing nodes are in place?
(b) What is the best route from node 41 to node 22 when
storing nodes are in place?

7.5 How does an actuator request routing information from

an LBR?
B
7.6 Given a PEGASIS chain with 8 sensors, how many
stages are needed for the data to arrive at the leader?

A
7.7 Why are extra computational capabilities typically asso-
ciated with storing nodes under RPL?

7.8 Why is source routing typically associated with non-

storing nodes under RPL?

How long does it take for a datagram to go from device A to 7.9 What type of nodes are more likely to cause application
device B if routing is WSN flooding? packet loss? Non-storing or storing nodes?

7.10 Given the following RPL topology:

192 7 Routing on Constrained Devices

2. Clausen, T.H., Yi, J., Herberg, U.: Lightweight on-demand ad

1 hoc distance-vector routing - next generation (LOADng): protocol,
extension, and applicability. Comput. Netw. 126, 125–140 (2017).
https://doi.org/10.1016/j.comnet.2017.06.025
2 5 4
3. Gan, W., Shi, Z., Zhang, C., Sun, L., Ionescu, D.: MERPL: a
more memory-efficient storing mode in RPL. In: 2013 19th IEEE
International Conference on Networks (ICON), pp. 1–5 (2013)
7 3 6 4. Glisic, S.: Advanced Wireless Networks: Technology and Business
Models, 3rd edn. Wiley (2016)
5. Holler, J., Tsiatsis, V., Mulligan, C., Avesand, S., Karnouskos, S.,
if the transmission rate is 120 Kbps and assuming no impair- Boyle, D.: From Machine-to-Machine to the Internet of Things:
ments and an average packet size of 56 bytes, what is the Introduction to a New Age of Intelligence, 1st edn. Academic Press,
Cambridge (2014)
end-to-end delay when five packets are transmitted from node 6. Khan, I., Qureshi, I., Shah, S.B., Akhlaq, M., Safi, E., Khan, M.,
6 to node 7 for both storing and non-storing node support? Nazir, A.: Comparative analysis and route optimization of state of
Consider no delay other than the transmission delay. the art routing protocols. Mobile Netw. Appl. 3, 6 (2018). https://
doi.org/10.4108/eai.22-3-2018.154385
7. Kodali, R.K., Sarma, N.: Energy efficient routing protocols for
7.11 Consider the local repair scenario introduced in WSN’s. In: 2013 International Conference on Computer Commu-
Fig. 7.27: nication and Informatics, pp. 1–4 (2013)
8. Jing, L., Liu, F., Li, Y.: Energy saving routing algorithm based on
spin protocol in WSN. In: 2011 International Conference on Image
1 Analysis and Signal Processing, pp. 416–419 (2011)
9. Misra, S., Goswami, S.: Network routing: Fundamentals, applica-
tions, and emerging technologies. Wiley (2017)
2 5 4 10. Saadat, M., Saadat, R., Mirjalily, G.: Improving threshold assign-
ment for cluster head selection in hierarchical wireless sensor
networks. In: 2010 5th International Symposium on Telecommu-
7 3 6 nications, pp. 409–414 (2010)
11. Semchedine, F., Atmani, M., Ouaret, S.: Gossiping with probabilis-
tic selection for routing in wireless sensor networks. In: 2013 World
local repair

Congress on Computer and Information Technology (WCCIT), pp.

1–5 (2013)
12. Shelby, Z., Bormann, C.: 6LoWPAN: The Wireless Embedded
Internet. Wiley, Hoboken (2010)
13. Singh, K.: Wsn leach based protocols: a structural analysis. In:
1
2015 International Conference and Workshop on Computing and
Communication (IEMCON), pp. 1–7 (2015)
14. Sohraby, K., Minoli, D., Znati, T.: Wireless Sensor Net-
5 4
works: Technology, Protocols, and Applications. Wiley, Hoboken
(2007)
15. Toor, A.S., Jain, A.K.: A survey of routing protocols in wire-
2 7 3 6 less sensor networks: hierarchical routing. In: 2016 International
Conference on Recent Advances and Innovations in Engineering
(ICRAIE), pp. 1–6 (2016)
If the transmission rate is 120 Kbps and assuming no impair-
16. Watteyne, T., Molinaro, A., Richichi, M.G., Dohler, M.: From
ments and an average packet size of 56 bytes, what is the MANET to IETF roll standardization: a paradigm shift in WSN
average latency degradation of node 2 transmissions after the routing protocols. IEEE Commun. Surv. Tuts. 13(4), 688–707
local repair? Consider no delay other than the transmission (2011)
17. Zhao, L., Liu, G., Chen, J., Zhang, Z.: Flooding and directed
delay.
diffusion routing algorithm in wireless sensor networks. In: 2009
Ninth International Conference on Hybrid Intelligent Systems,
vol. 2, pp. 235–239 (2009)
References 18. Zheng, M., Zhao, X.: Research on directed diffusion routing
protocol in wireless sensor networks. In: 2013 10th Interna-
tional Computer Conference on Wavelet Active Media Tech-
1. Alexander, R., Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
nology and Information Processing (ICCWAMTIP), pp. 53–57
Levis, P., Struik, R., Kelsey, R., Winter, T.: RPL: IPv6 routing pro-
(2013)
tocol for low-power and lossy networks. RFC 6550 (2012). https://
doi.org/10.17487/RFC6550. https://rfc-editor.org/rfc/rfc6550.txt
 LPWAN Technologies
8

small packets only a few times per hour over long distances.
8.1 LPWAN in IoT Different LPWAN solutions are characterized by different
factors, namely, (1) network topology, (2) device coverage,
IoT technologies seen so far fall under the realm of PAN (3) battery lifetime, (4) resilience to interference, (5) node
scenarios, that because they are usually wireless, they are density, (6) security, (7) unidirectional vs bidirectional com-
representative of WPANs. Although these are low-power munication, and (7) nature of the applications. The following
technologies, they are still powerful enough to provide trans- section introduces several state-of-the-art LPWAN technolo-
mission rates that natively enable IPv6 support [5]. How- gies that are relevant to IoT.
ever, the direct hop-to-hop transmission range of WPANs
is typically quite short, rarely extending more than a few
hundred meters. LPWAN technologies, briefly introduced 8.2 LoRa
in Sect. 1.3, attempt to increase the device coverage, but
unfortunately, they are affected by a lower SNR that fur- Long range (LoRa) is the generic name for a full protocol
ther reduces transmission rates and MTU sizes [13]. These stack that provides LPWAN capabilities that enables devices
limitations prevent these devices from fully supporting IPv6 to run on a single battery for more than 10 years [18, 33, 28].
and derived protocols like CoAP and RPL. In other words, The LoRa stack is shown in Fig. 8.2. It is a small subset of
almost all LPWAN physical and link layers do not support the layered architecture that includes physical, link, and ap-
the upper layer protocols introduced in Chaps. 4 through 7. plication layers. This is fine since LoRa devices only interact
Most LPWAN mechanisms are therefore hybrid technologies with other LoRa devices. There is no need for a network or
with proprietary access networking stacks that rely on IoT transport layer since LoRa does not natively support IP to
gateways to enable application IP support. Moreover, most begin with. The figure also shows that each layer includes
LPWAN stacks only carry a subset of available layers of the multiple sublayers that provide different functionality [7].
layered architecture. Note that LoRa provides security at the link and applica-
Figure 8.1 shows the relationship between throughput and tion layers. Link layer security provides authentication and
coverage, of physical layers of different IoT technologies AES-128-based device encryption in the network by relying
when compared to LPWAN schemes. Best-case scenario on a 64-bit IEEE EUI-64 unique network key. On the other
is for traditional mobile cellular technologies like 5G that hand, application layer security provides AES-128 based
provide high throughput and coverage, but they are highly encryption of device data.
inefficient from a power perspective as they do not scale
well for support of IoT applications. With a similar level
of throughput, IEEE 802.11 derived technologies drain, in 8.2.1 Physical Layer
their majority, too much power to be effective in IoT en-
vironments. IoT WPAN schemes like IEEE 802.15.4 and The LoRa physical layer relies on transmission over different
BLE are power-efficient but they exhibit both low-throughput ISM bands, specifically, the 433 MHz and the 915/868 MHz
and very short coverage. LPWAN technologies complement ISM bands. LoRa modulation is based on CSS. In the context
WPAN by improving the distance range while keeping lower of the physical layer of LoRa, CSS, as an SS mechanism,
consumption to a minimal level in order to offer a multi- is not only power-efficient, but it also enables very long-
year battery lifetime. LPWAN devices typically transmit very range communications with a coverage that exceeds 10 km at

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 193
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_8
194 8 LPWAN Technologies

Fig. 8.1 IoT throughput and

throughput
range

high
IEEE 802.11n 5G
IEEE 802.11ac
4G
3G
IEEE 802.11ah
IEEE 802.11a
IEEE 802.11b
IEEE 802.11g

medium
BLE

IEEE 802.15.4

RFID/NFC
low LPWAN

low medium high

range

very low transmission rates. Of course, estimations of LoRa

application application layer
device coverage greatly depend on the physical obstructions.
For example, a single LoRa base station or gateway can cover LoRa MAC
an area of hundreds of square kilometers. Moreover, studies
MAC options link layer / LoRaWAN
show that based on the number of devices associated with
a single gateway, it is possible to estimate the maximum class A class B class C
transmission rate and coverage. For example, for an 8-km
LoRa modulation
range at a maximum nominal rate of 250 bps, it is possible physical layer / LoRa
to support up to 50 devices. Similarly, for a 2.5-km range at a ISM band
maximum nominal rate of 5 Kbps, it is possible to support
up to 700 devices. In general, the data rate depends also Fig. 8.2 LoRa stack
on the ISM band under consideration with rates between
250 bps and 50 Kbps for the 868 MHz band in Europe and
between 980 bps and 21.9 Kbps for the 915 MHz band in the 8.2.2 Link Layer
United States. This has to do with the fact that the different
ISM bands support a different number of subchannels; the The link layer that enables devices to access the channel is the
868 MHz band supports 10 subchannels while the 915 MHz building block of the LoRa networking mechanism known as
band supports more than 64 subchannels. Moreover, the LoRaWAN [6]. Specifically, LoRaWAN is responsible for
bandwidth of each subchannel depends on the spectral band; defining not only the media access algorithm but also the
for both bands the uplink bandwidth is between 125 and network architecture. Most WPAN technologies accomplish
500 KHz, while for the 868 and the 915 MHz bands, the long-range communications by relying on mesh network-
downlink bandwidths are 125 and 500 KHz, respectively. ing provided by capillary connectivity. Mesh networking,
Figure 8.3 shows the layout of gateways of the The Things however, requires coordination to support data aggregation
Network (TTN), one of the few free and open LoRa providers, through intermediate nodes. Moreover, aggregation reduces
in New York City. In general, with minimal infrastructure, both battery life and transmission capacity of these interme-
LoRa networks can completely cover cities and countries. diate nodes even when carried data samples are not relevant
Although LoRa hardware is proprietary, it has been licensed to them. This is particularly important for low-power em-
to multiple manufacturers. Moreover, there are several open bedded devices like those involved in most LoRa scenarios.
source LoRa protocol stacks that support different embedded LoRaWAN introduces a much simpler approach that relies
device platforms. on exchanging transmission rate for coverage. Specifically,
8.2 LoRa 195

Fig. 8.3 TTN coverage in NYC

LoRaWAN relies on devices talking to gateways directly simultaneous transmissions, payload lengths, and adaptive
without relying on intermediate nodes. To provide redun- data rates. This later mechanism consists of devices, with
dancy a single device is associated with multiple gateways. access links that have comparatively higher SNR that can
Therefore, for the same power restrictions and compared to transmit faster in order to lower channel access intervals and
WPAN technologies like IEEE 802.15.4, LoRaWAN trans- allow more devices to send traffic. The transmission rate
mits data at a much slower rate in order to reach farther is also affected by other issues like the spreading factor of
distances while attempting to defeat channel interference by the CSS modulation. In general, devices that are close to
means of highly available gateways. LoRa gateways have gateways, and therefore have good links, transmit faster than
two interfaces, (1) a LoRa interface and (2) an IP interface; those devices that are farther away. Moreover, by lowering
packets sent by LoRa devices arrive at the LoRa interface transmission rates, the battery lifetime of a device can be
and they are then forwarded via IP to a server. If one of the improved. One characteristic of LoRaWAN is that it is highly
copies of a packet arrives at the server, the packet is not lost. scalable, a network can be deployed with a single gateway
Therefore, a server not only verifies that a packet complies and, as more capacity is needed, more gateways can be added.
with security settings but also makes sure to drop redundant
copies. Since gateways are embedded devices themselves, Example 8.1 Consider a LoRa scenario with a device
LoRa pushes complexity and decision-making to the server. and a gateway transmitting 13-byte frames:
In mobile environments, the simple LoRa approach removes
the need for complex handover mechanisms that occur when sensor gateway
a device switches from one gateway to another.
LoRaWAN MAC is based on an ancestor of CSMA/CA
56 ms
known as ALOHA that enables devices to send datagrams
without having to wait for the channel to be free. If during 10 km

transmission the device detects a collision, it postpones the

transmission by waiting a random amount of time before First the gateway attempts to send a frame, and then,
retrying. ALOHA is so simple that it is ideal for LoRaWAN 56 ms later, the device sends another frame. Assume a
MAC as it removes the need for network synchronization 1 Kbps transmission rate, a separation between sensor
therefore minimizing power requirements. Moreover, be- and gateway of 10 km and no delays other than propa-
cause LoRa modulation is CSS-based, device collisions are gation and transmission delays. How long does it take
not common. ALOHA is also compatible with LoRaWAN for both frames to be sent and received under LoRa
topologies where multiple devices transmit sensor readouts classes A and C?
to a gateway. A gateway, in turn, must be able to have enough
capacity to support the throughput from many devices. This Solution Under class C, the gateway and the device
capacity is accomplished by a combination of techniques transmit frames as soon as possible. The overall delay
including multichannel modulation that supports multiple
(continued)
196 8 LPWAN Technologies

Table 8.1 LoRa classes application application layer

Power consumption Downlink frame network layer
Class A Low After transmission MAC link layer
Class B Medium At scheduled times ISM band physical layer
Class C High Always
Fig. 8.4 SigFox stack

(continued) The SigFox protocol stack does not include any encryption
 
is DC = 2 × Dt + Dp where Dt = 8×L R
= 104 ms mechanism and relies on the applications to encrypt device
with L = 13 bytes and R = 1000 bps and Dp = data. SigFox messages, however, can be signed with a unique
10,000 m
c
= 33.34 µs with c = 300 106 m/s (speed device key.
of light). Because Dp  Dt , DC ≈ 2 × Dt = 208 ms.
Under class A, the gateway only transmits a frame in
response to a frame sent by the device. In this scenario, 8.3.1 Physical Layer
this means that the delay DA is given by DA = DC +
56 ms = 264 ms. Class A, when compared to class SigFox, as LoRa, relies on transmission over the 915/868 MHz
C, provides better energy consumption but increases ISM bands. For uplink, each band is in turn divided into
latency. 333 Ultra Narrow Band (UNB) 100 Hz subchannels where
DBPSK modulation is performed. For the downlink traffic,
the subchannels are 600 Hz wide and GFSK modulation
Based on power consumption and level of interaction
is used instead. Because both modulations are binary, the
with gateways, device operation falls within the umbrella
nominal throughput is 100 and 600 bps for uplink and
of three different classes A, B, and C shown in Table 8.1.
downlink, respectively. Additionally, SigFox uses FHSS
Specifically, each class affects the trade-off between battery
across 3 out of the 333 uplink subchannels. This is done to
life, latency, and throughput. Class A is supported by all
increase channel diversity and improve fading protection.
devices and enables gateways to send packets 6LoWPAN as
Frequency hopping, based on a pseudo-random sequence,
soon as device traffic is received. As such class A devices
is combined with a random time delay, somewhere between
consume the least amount of energy and extend battery life.
500 and 525 ms, on what it is called random frequency and
Class B enables gateways to send packets downlink on a
time division multiple access (RFTDMA). The transmission
scheduled basis and therefore exhibit an intermediate level
power is specified to be 14 and 22 dBm for the 868 MHz
of power consumption and battery lifetime. Finally, class
and the 915 MHz bands respectively. Similarly, the receiver
C enables gateways to send packet downlink always unless
sensitivity is −120 and −142 dBm for the 868 MHz
traffic is being received. Class C is the least power-efficient
and the 915 MHz bands, respectively. SigFox estimates
mechanism and exhibits the shortest battery lifetime.
the allowable transmission rates based on the number
of devices connected to the network and duration of the
contract.
8.3 SigFox SigFox is designed for the transmission of infrequent
bursts of small sensor readouts. As such the payload size for
SigFox is another LPWAN protocol stack that, as opposed
uplink and downlink is 12 bytes and 8 bytes per message,
to LoRa, it relies on a unique commercial network called
respectively. Note that these payload sizes are good enough
SigFox [14, 22, 25]. SigFox hardware, however, is open
to represent sensor data with a pretty good resolution. Since
with several manufacturers making SigFox chips. Although
a single precision floating point number is typically stored
SigFox was originally designed as a unidirectional traffic
in 4 bytes, a SigFox message can carry uplink up to three
technology where sensors propagate readouts uplink, the
floating point numbers. Higher-precision floating point num-
stack was later updated to support downlink data transmis-
bers, stored in 8 and 12 bytes, reduce the message capacity to
sion. SigFox devices are characterized by very low power
transmit sensor readouts. In order to preserve battery life and
consumption that supports extended battery life and low
limit power consumption, the maximum number of messages
transmission rates.
that a device can transmit and receive daily is 140 and 4,
Figure 8.4 shows the SigFox protocol stack; it includes a
respectively. No device can transmit more than six messages
(1) physical layer, a (2) link layer that provide MAC, and a
per hour. In many cases, devices can minimize the amount
(3) network layer known as the frame layer that wraps the
of data sent by using events that are carried as messages
application data and adds a sequence number to the frames.
with no payload. Of course, this does not circumvent the
8.3 SigFox 197

daily transmission limit, but it reduces the overall power Devices carry a device identifier that is used for routing,
consumption. message signing, and authentication. Figures 8.6 and 8.7
show the SigFox frame format for both downlink and uplink
Example 8.2 What is the best-case scenario for communication between a device and a base station. Frames
uplink and downlink payload transmission rates under start with a preamble used for synchronization that is fol-
SigFox? lowed by a synchronization field that indicates the type of
frame being transmitted. Uplink frames include the device
identifier, the variable length payload, the authentication
Solution For uplink and downlink, the payload sizes field, and a FCS field used for error detection. Similarly,
are Luplink = 8 × 12 = 96 bits and Luplink = 8 × downlink frames include flags, the FCS, the authentication
8 = 64 bits, respectively. The uplink rate is given by field, the error code field, and the variable length payload.
N ×L Note that since communication is from multiple devices to a
Ruplink = uplink T uplink = 0.15 bps where Nuplink = 140
and T = 60 × 60 × 24 = 86,400 s. The downlink base station, no addressing mechanism is needed other than
rate is given by Rdownlink = Ndownlink T×Ldownlink = 0.003 bps the inclusion of the device identifier in uplink frames. For
where Ndownlink = 4. the worst-case scenario of a 200-bit frame, it takes around
200 bit uplink packet
≈ 100 bps
= 2 s to transmit it uplink. Since
three copies of each message are transmitted, the transmis-
sion time per individual message is typically 6 s. Because
8.3.2 Link Layer SigFox devices have a 1% duty cycle, they are active only
36 s every hour, and therefore they can only send up to six
As LoRa, SigFox MAC is based on ALOHA. Moreover, de- messages per hour.
vices are not synchronized with the network. SigFox supports Figure 8.8 shows the topology of a SigFox network. It con-
a transmission mechanism similar to that of LoRa class A; sists of base stations that play the role of gateways, providing
when a message from a device arrives at the base station an interface between devices in the access side and backend
acting as an IoT gateway, the base station has a 20-s window server in the core side. The communication with the devices
of opportunity to transmit a message down to the device. In is by means of the SigFox physical and link layer mechanisms
turn, the device waits for up to 25 s for an incoming 4-byte while the communication with the application is by means of
message from the base station to arrive. traditional IP networking. The overall scheme follows a star
Figure 8.5 illustrates RFTDMA, where three copies of topology where up to one million devices can interact with a
the payload are transmitted over three random carriers with single base station. In general, the number of supported de-
different random delays. The window for downlink transmis- vices is associated with the number of messages transmitted
sion only opens after the last frame is transmitted. Because throughout the network. As for the case with LoRa, SigFox
messages are transmitted in a fire-and-forget fashion, where devices transmit their messages simultaneously to multiple
no acknowledgment from the receiver is sent, three copies at- base stations, and it is up to the backend server to remove
tempt to provide enough redundancy to guarantee successful duplicates before storage. Applications rely on SigFox cloud
delivery. This redundancy acts as a FEC mechanism. service APIs to retrieve device data from backend servers that
frequency

f1 frame

2.08 s – 12 bytes
f2 frame

0.5 s base station downlink window 25 s

f3 frame
20 s

t1 t2 t3 time

Fig. 8.5 SigFox transmission

198 8 LPWAN Technologies

Fig. 8.6 Upstream frame 32 16 32 0 – 96 8 16

PREAMBLE SYNC ID PAYLOAD AUTH FCS

SYNC frame synchronization

ID device identifier
AUTH authentication
FCS frame checksum

Fig. 8.7 Downstream frame 32 13 2 8 8 8 0 –64

PREAMBLE SYNC FLAGS FCS AUTH EC PAYLOAD

SYNC frame synchronization

FCS frame checksum
AUTH authentication
EC error code

Fig. 8.8 SigFox topology

SIGFOX ACCESS IP CORE

device

base station
backend server

device
IP

device application
base station

device

store the device readouts themselves. In turn, backend servers Application WPAN LPWAN
transmit messages to devices by selecting the base stations BLE IEEE IEEE IEEE IEEE SigFox LoRa
with the best connectivity and in the best position to send 802.15.4 802.15.4e 802.11b 802.11ah
Media (64 Kbps) ≈ 0.25 ≈ 0.05 ≈ 0.06 ≈ 0.05 ≈ 0.015 N/A N/A
messages downlink.
Sensor (400 bps) 10.5 5 5.5 3 1 N/A N/A
Sensor (4 bps) 23.5 23 20.5 8 9 N/A 1
 LPWAN vs. WPAN: Battery Life The following table
Sensor 24 24 20.5 8 10 21 27
shows battery life (in terms of years) for both LPWAN
(400 bits/day)
(long-distance coverage) and WPAN (short-distance
coverage) technologies as a function of different appli-
cations [21]. Note that the list includes 1% duty cycle
SigFox and LoRa. It assumes devices being powered 8.4 D7AP
by two AAA batteries.
The DASH7 Alliance Protocol (D7AP) is an open source
protocol stack that enables LPWAN communications [37]. Its
physical and link layers are derived from the ISO/IEC 18000-
8.4 D7AP 199

Fig. 8.9 D7AP communication

models

PULL MODEL PUSH MODEL

QUERY PROTOCOL BEACONING

Fig. 8.10 Foreground frame 32 16 8 8 8 ≤ 64 ≤ 251 16 bits

PREAMBLE SYNC L S C TADR PAYLOAD CRC16

SYNC frame synchronization

L length
S subnet
C control parameter
TADR target address
CRC16 error detection

7 standard for active (as opposed to passive) RFID. The 7 ISM bands. Each band is subdivided in several channels: 69,
in DASH7 refers to the section -7 of the original standard. 280, and 1040, respectively, for the 433 MHZ, the 868 MHz,
D7AP was originally designed for military purposes with and the 915 MHz bands. The channels can be configured
batteries lasting for years and supporting low-latency long- under three different classes: (1) Lo-Rate, (2) Normal, and (3)
range wireless mobility [8, 9]. It was adopted by the US Hi-Rate that support transmission rates at 9.6 Kbps, 55 Kbps,
Department of Defense in 2009 to support asset tracking, and 166 Kbps, respectively. In all scenarios signal modula-
but in 2011 it was repurposed for location based services tion is by means of GFSK combined with FHSS that supports
associated with smartcards and device tracking and extended a transmission power of around 10 dBm. Most deployments
to support a huge number of WSN applications ranging from are characterized by a maximum 2-s latency for an adjustable
mobile advertising and billboards to cargo monitoring in transmission range between 10 m and 10 km. In asset tracking
transport vehicles. As an RFID mechanism, it compliments applications, the precision is within 4 m.
traditional short-range NFC technologies by providing mo- Before modulation, binary symbols are encoded by means
bile asset tracking and enabling devices to communicate with of several different coding schemes; the main mechanism
each other. relies on PN9 that produces a predictable pseudo-random
D7AP defines four device classes: (1) blinker that only sequence of values. PN9 is complemented by a FEC convo-
transmits traffic, (2) endpoint that transmits and receives data lutional encoder that provides a 1/2 code rate. The physical
and supports wake-up events, (3) subcontroller that is a full layer is also capable of performing RSSI measurement with
featured device and also supports wake-up events, and (4) 6 dBm accuracy.
gateway that is always active and provides the interface with
other networks as any IoT gateway.
D7AP, as shown in Fig. 8.9, supports two modes of op- 8.4.2 Link Layer
eration based on a star topology; the pull model where the
interaction between devices and gateways is bidirectional by The link layer of D7AP defines two types of frames: (1) fore-
means of requests as well as responses and the push model ground frame and (2) background frame. Foreground frames
where devices periodically transmit data to gateways unidi- are common messages used to carry data and data requests.
rectionally. When those messages are beacons, the mecha- On the other hand, the background frames are very small
nism is called beacon transmit series. messages used for advertising and for group synchronization.
Figure 8.10 shows a foreground frame; it includes a 32-
bit preamble and 16-bit synchronization word followed by an
8.4.1 Physical Layer 8-bit length field that specifies the size of the frame. The 8-
bit subnet field is used for filtering of incoming frames. The
D7AP specifies a full stack that, in certain scenarios, can rely 8-bit control parameter that is used to specify the target id
on other physical and link layer technologies like LoRa or identifier type is followed by a variable length target address.
SigFox for transmission. The native physical layer of D7AP Similarly, the variable length payload is followed by a 16-
relies on transmission over the 433 MHz and 915/868 MHz bit CRC field used for error detection. Figure 8.11 shows a
200 8 LPWAN Technologies

32 16 8 8 16 16 bits 1 1 1 0/1 0/1 0/1 0/1 ≤ 239 bytes

PREAMBLE SYNC S C PAYLOAD CRC16 C DID TID AGC TL TE TC PAYLOAD

SYNC frame synchronization C control

DID dialog identifier
S subnet
TID transaction identifier
C control parameter
AGC AGC control
CRC16 error detection
TL listen timeout
TE execution delay timeout
Fig. 8.11 Background frame
TC congestion timeout

Fig. 8.13 D7ATP request segment

background frame; as for the foreground frame case; it starts
with a 32-bit preamble and 16-bit synchronization word that
is followed by an 8-bit subnet field is used for filtering of several mechanisms of cipher block chaining and variable
incoming frames and an 8-bit control parameter that is used length MICs.
to specify the target identifier type. The 16-bit payload is The D7A Transport Protocol (D7ATP) is based on a
followed by a 16-bit CRC field used for error detection. scheme where a one-time request is sent by a requester
To match each of the frame types, the link layer sup- to one or more responders. The interaction between the
ports background and foreground scan and message recep- requester and the responders is performed in the context
tion. From a transmission perspective, channel contention of a transaction. The transaction, in turn, is made of three
is resolved by means of an adaptation of CSMA/CA where distinct periods: (1) the request period which accounts for the
consecutive transmission attempts are randomly scheduled transmission of the segment including the contention due to
based on different modes of operation. CSMA/CA, (2) the execution delay period that is associated
with the propagation delay, and the (3) congestion timeout
that tells the responders how long their transmissions should
8.4.3 Other Layers
take. Figures 8.13 and 8.14 show the segment structures
of requests and responses, respectively. Both requests and
D7AP includes, in addition, network, transport and session
responses include a 1-byte control field, a 1-byte dialog iden-
layers. The network layer defines two protocols: a back-
tifier that is unique per dialog, a 1-byte transaction identifier
ground D7A Advertising Protocol (D7AAvP) and a fore-
that specifies that transaction within the dialog, an optional
ground D7A Network Protocol (D7ANP). D7AAvP has pri-
1-byte AGC control field, an optional 1-byte listen timeout,
ority over D7ANP. D7AAvP is used with background frames
and an optional 1-byte execution delay timeout. Requests
for rapid, ad hoc group synchronization. D7ANP, on the
include, in addition, a 1-byte congestion timeout field and
other hand, is used with foreground frames to provide a
a variable length payload, while responses include a variable
single datagram and addressable, routable protocol that relies
length acknowledgment field that specifies the transactions
on the structure shown in Fig. 8.12. The datagram contains
being acknowledged and a variable length payload. D7AP
several fields; a 1-byte control field used to specify the origin
also includes a session layer, known as D7A Session Protocol
identifier type and the network security method, a variable
(D7ASP), that defines the events that may result in session
length origin identifier, a 1-byte hopping control field used to
initialization, scheduling as well as QoS strategy and power
specify the destination identifier type and hopping informa-
control.
tion, a variable length destination identifier, a 1-byte hopping
network layer timer value used for multi-hop routing, an
optional 5-byte security header use to encode the security 8.5 Weightless
state, a variable length payload, and a variable length security
footer use to encode the MIC. Network security includes Weightless is another LPWAN protocol stack that relies
combinations of encryption and authentication that rely on on transmissions over the white space spectrum [36, 25].

Fig. 8.12 D7ANP datagram 1 1/2/3/9 1 1/2/3/9 1 0/5 ≤ 250 ≤ 16 bytes

C origin id H destination id HT SEC HDR PAYLOAD SEC FTR

C control
H hopping control
HT hopping network layer timer value
SEC HDR security header
SEC FTR security footer
8.5 Weightless 201

1 1 1 0/1 0/1 0/1 ≤ 34 ≤ 239 bytes the best base station for message routing, (4) the broadcast
C DID TID AGC TL TE ACK PAYLOAD register keeps track of the groups the devices belong to in
order to support broadcast messages, (5) the Operation and
C control
Maintenance Center (OMC) provides the monitoring of the
DID dialog identifier
TID transaction identifier network to detect failures, (6) the billing entity keeps track of
AGC AGC control device activity to support billing information, and (7) white
TL listen timeout space database keeps track of the available channels based on
TE execution delay timeout the servicing location.
ACK acknowledgment template
As an open standard, multiple manufacturers produce
Fig. 8.14 D7ATP response segment Weightless hardware. The Weightless standard is the result of
the Weightless Special Interest Group (Weightless SIG) that
dictates the different layers of the protocol stack. Moreover,
Specifically, the white space spectrum refers to those fre- as any other standardization body, the Weightless SIG is
quencies that result from the allocation of separation guards responsible for specifying interop testing technologies as
between bands and channels in order to minimize interfer- well as mechanisms of certification for the industry. The
ence. Although these frequencies are typically reserved and Weightless SIG serves as an entity that interacts with gov-
not intended for transmission, in certain scenarios they can ernment regulators to free up the use of the white space
be used if power levels and modulation schemes are carefully spectrum.
selected to prevent any interference. The use of white space Figure 8.16 shows the Weightless stack where layers talk
frequencies enables Weightless to provide widespread signal to each other by means of channels. Moreover, the stack
coverage [24]. is partitioned into two different planes: a user plane and a
The standard is called Weightless because it relies on a control plane. The physical layer has three physical channels:
lightweight protocol stack that exhibits very little overhead the downlink channel that provides communication from the
in order to maximize the performance of small packet trans- base station to the device, conversely, the uplink channel
missions. Weightless applications include home and building that provides communication from the device to the base
automation, smart metering, health care, transportation, point station, and the uplink contended access channel that enables
of sale, inventory tracking, and physical security among multiple devices to simultaneously transmit traffic to the
others. base station. Within the physical layer, there are transport
Weightless, as many LPWAN technologies, is character- channels that provide the interface between the physical and
ized because it provides a low cost solution that is compatible link layers. The transport channels provide the framing of
with most large size IoT device deployments. In fact, Weight- the downlink and uplink channels as well as the contended
less is intended to support a very large number of devices access associated with the uplink contended access channels.
with a single cell supporting more than one million devices. In the link layer, the logical channels provide retransmission
A network could easily include around one billion devices. control as well as fragmentation and reassembly. Specifically,
In all cases, low costs imply that both device and service the logical channels enable the data and control traffic to
costs are low. Additionally, Weightless is ultralow power and be transmitted reliably or unreliably based on whether the
enables devices to run on a single battery for up to 10 years. individual frames are acknowledged or not. The connectivity
Moreover, Weightless provides reliable and secure delivery between base stations and devices is controlled by the radio
of unicast and broadcast messages. Messages are transmitted resource manager (RRM) that relies on control channels to
in bursts with the Weightless network prepared to support a send messages downlink. Alternatively, user channels pro-
typical message size of around 50 bytes. vide the connectivity between base stations and devices to
Weightless is an open standard that enables devices to enable the transmission of unicast, multicast, interrupted,
exchange data with a single base station that acts as an and acknowledgment frames. While unicast traffic is bidirec-
IoT gateway. As such, the base station provides connectivity tional, multicast traffic is unidirectional between device and
to a network manager and database through traditional IP base station.
mechanisms. Weightless relies on the star topology shown
in Fig. 8.15. Additionally there are several elements that
enable the operation of a Weightless network: (1) the base 8.5.1 Physical and Link Layers
station controller provides a point of contact for a group
of base stations, (2) the authentication database holds the As indicated above, Weightless relies on the transmission
authorization data associated with base stations and devices over the white space spectrum. Specifically, the UHF band,
as well as the encryption keys, (3) the location register keeps located between the 300 MHz and 3 GHz range and shown
track of the location of the devices in order to determine in Fig. 3.1, is an ideal candidate for white space frequency
202 8 LPWAN Technologies

Fig. 8.15 Weightless topology sync DB

weightless sensor

IP
base station
interface

network manager

user plane control plane Weightless. The modulation is adaptive, and the propagation
range is related to the negotiated transmission rate. Very high
application application layer
transmission rates are only possible at very short distances.
user channels control channels
link layer Note that each scheme is linked to a specific code rate
logical channels
and spreading factor. The code rate and spreading factor
transport channels
physical layer are, respectively, associated with FEC and resilience against
physical channels channel noise. Since the same frequency is used for both
uplink and downlink communications, TDD is used by device
Fig. 8.16 Weightless stack
and base station signals to share the channel.
Table 8.2 Weightless modulation summary Figure 8.17 shows the processes involved in the Weight-
Modulation summary
less signal generation. The binary data from the link layer
Scheme Code rate Spreading factor Rate (Mbps)
is first subjected to FEC that inserts control redundancy
16-QAM 1 1 16.0 and results in a specific code rate. The output data is then
16-QAM 3/4 1 12.0 processed by a whitening stage that by means of a scrambler
16-QAM 1/2 1 8.0 XORs the data against a pseudo-random sequence in order
QPSK 3/4 1 6.0 to randomize the signal and introduce transitions that are
QPSK 1/2 1 4.0 essential to signal synchronization. The output stream is then
BPSK 1/2 1 2.0 modulated by the schemes and spread by means of FHSS.
BPSK 1/2 4 0.5 Finally cyclic prefix insertion (CPI) is used to minimize,
BPSK 1/2 16 0.125 among other things, intersymbol interference (ISI) and mul-
BPSK 1/2 63 0.040 tipath fading, by inserting at the start of a frame a portion
BPSK 1/2 225 0.010 of the end of the frame. A preamble is then inserted to
DBPSK 1/2 1023 0.0025 provide synchronization between devices and base stations.
The resulting signal is passed through a root-raised cosine
(RRC) filter that provides pulse shaping to further minimize
modulation since it is characterized by very good propa- ISI due the sharp wave transitions it introduces.
gation. Moreover, Weightless modulation is typically per- Weightless include three main variations known as
formed over underutilized white space spectrum channels Weightless-W, Weightless-P, and Weightless-N. Weightless-
that exhibit very little interference and require small size W is based on the specifications presented so far in this
antennas. These channels are set up over unoccupied fre- section. Weightless-P is based on Weightless-W, but it
quency guardbands between TV channels. Again, since UHF is cheaper since it removes the need for a temperature-
TV signals are generated with high-power transmitters and compensated crystal oscillator (TCXO) by changing some
high gain antennas located at high altitude, they are unlikely of the modulation scheme parameters. Weightless-N is
to interfere with Weightless low-power transmitters and low also based on Weightless-W, but it relies on transmission
gain antennas at low altitude. over the 868/915 MHz ISM bands providing only uplink
Weightless relies on FHSS with the carrier being mod- communication. It exhibits lower power consumption that
ulated by means of DBPSK, BPSK, QPSK, or 16-QAM. extends battery life for up to 10 years but limits both the
Table 8.2 shows the different modulation schemes and their propagation range and the transmission rate.
corresponding nominal transmission rates associated with
8.6 NB-IoT 203

preamble

RRC pulse
shaping

DBPSK BPSK
FEC scrambler FHSS CPI
QPSK 16-QAM

Fig. 8.17 Signal generation

minimize interference, the receiver and transmitter sending

8.6 NB-IoT traffic on two different nonoverlapping channels. Under
the worst network conditions, NB-IoT typically achieves a
Narrowband IoT (NB-IoT) is an LPWAN technology based transmission rate of around 200 bps. Moreover, NB-IoT, as a
on cellular communications and first introduced in the 3rd narrowband IoT technology, requires 180 KHz channels for
Generation Partnership Project (3GPP) Release 13 and en- both directions. This bandwidth allocation is associated with
hanced through successive releases with Release 17 sched- three different deployment scenarios over licensed bands:
uled to be available in 2021 [22, 12, 3]. Specifically, 3GPP (1) standalone allocation where a GSM network operator
adds several IoT features to the existing Global System for can replace a GSM 850–900 MHz carrier with NB-IoT,
Mobile Communications (GSM) and 4G Long-Term Evolu- (2) inband allocation where an LTE network operator can
tion (LTE) network architectures. NB-IoT is, therefore, also allocate a physical resource block (PRB) to deploy inband
known as LTE Cat M2. As with most LPWAN mechanisms, inside NB-IoT, and (3) guardband allocation where an LTE
the main goal is to provide wide area coverage at a very low network operator can also deploy an NB-IoT carrier in a
cost per device. Moreover, additional goals like reduction of guardband between two LTE channels.
device complexity and backwards compatibility are also a NB-IoT reuses a lot of the mechanisms introduced by
focus of NB-IoT. To accomplish this latter objective, NB-IoT LTE. This has enabled the development of specifications in
relies on a very small portion of the existing spectrum used a fairly short amount of time. Among the many mechanisms
by the cellular technologies. NB-IoT backward compatibility that NB-IoT borrows from LTE, the modulation schemes are
implies that if cellular networks are upgraded in accordance the most important. Specifically, NB-IoT downlink traffic
with NB-IoT requirements, they must still support existing relies on OFDMA, while uplink traffic relies on single-
3GPP user equipment (UE). This does not mean, however, carrier FDMA (SC-FDMA). The reason for two different
that NB-IoT devices can communicate in existing legacy schemes is that although SC-FDMA is more complex than
networks 8.6. OFDMA, it is also a lot more power-efficient and therefore
NB-IoT, when compared to other LPWAN technologies, more appropriate for the transmission of constrained devices.
attempts to improve indoor coverage while supporting a The main difference between OFDMA and SC-FDMA is
massive number of low-throughput and low-latency devices. how they arrange user data streams in frequency and time.
NB-IoT supports several IoT use cases including home as Figure 8.18 shows how, under OFDMA, traffic associated
well as home and building automation, asset tracking, and with 12 users a, b, …, l is simultaneously transmitted over 12
industrial control. The main requirements of NB-IoT are very different subchannels. Similarly, Fig. 8.19 shows how, under
low cost devices with a unit price below $5, a battery life of SC-FDMA, the same traffic is sequentially transmitted on
over 10 years with little human intervention, and the support individual timeslots. As it can be seen, the overall throughput
of up to 50,000 devices per cell. is the same for both scenarios. In order to support a massive
NB-IoT adopts the protocol stack of legacy LTE with number of devices, NB-IoT assigns resource units (RUs) to
modifications to comply with the requirements including the multiple UEs. Under NB-IoT, the carrier separation of both
support of a huge number of devices connected over a very schemes is 15 KHz, accounting for a subcarrier count of 12
long range. that covers the 180 KHz bandwidth. The uplink configura-
tion also supports a 3.75 KHz carrier spacing. With 15 KHz
spacing, NB-IoT allocates a single 8-ms tone, 3 4-ms tones,
8.6.1 Physical Layer 6 2-ms tones, or 12 1-ms tones. Similarly, with 3.75 KHz
spacing, NB-IoT allocates 48 32-ms tones. In each channel
NB-IoT relies on half duplex frequency division duplex
the selected modulation scheme is either BPSK or QPSK
(FDD) communication to support nominal uplink and
for both uplink and downlink. The maximum transmission
downlink transmission rates of 60 Kbps and 30 Kbps,
power for uplink and downlink transmissions is 23 dBm and
respectively. As with TDD, FDD involves, in order to
204 8 LPWAN Technologies

2-ms slots. The uplink uses two channels (1) narrowband

frequency
physical random access channel (NPRACH) and (2) nar-
rowband physical uplink shared channel (NPUSCH), and it
also uses one signal demodulation reference signal (DMRS).
carrier 12 l The downlink uses three channels (1) narrowband physical
carrier 11 k downlink shared channel (NPDSCH), (2) narrowband phys-
carrier 10 j ical downlink control channel (NPDCCH), and (3) narrow-
carrier 9 i band physical broadcast channel (NPBCH), and it also uses
carrier 8 h three signals (1) narrowband reference signal (NRS), (2)
carrier 7 g narrowband primary synchronization signal (NPSS), and (3)
carrier 6 f narrowband secondary synchronization signal (NSSS).
carrier 5 e
carrier 4 d
carrier 3 c
Example 8.3 Consider an IPv6 adaptation mechanism
carrier 2 b
encapsulated as part of NB-IoT that results in the
carrier 1 a transmission of 20-byte packets. What is the worst-
time case scenario MAC latency that can be expected from
such mechanism?
Fig. 8.18 OFDMA
frequency

Solution Because under NB-IoT the transmission rate

can be as low as R = 200 bps, for an L = 20 bytes
packet, the transmission delay D is given by D =
carrier 12 8×L
R
= 8 s. Note that the 8-s transmission delay is also
carrier 11 a MAC access delay that prevents the support of most
carrier 10 relevant IoT real-time applications.
carrier 9
carrier 8
carrier 7 a b c d e f g h I j k l For uplink, the NPRACH channel enables a device to
carrier 6 initially access the network and every time after failure
carrier 5 as well as to request transmission resources. Similarly, the
carrier 4 NPUSCH channel is used to carry uplink data packets. The
carrier 3 DMRS signal provides uplink channel estimation accuracy.
carrier 2 For downlink, the NPDSCH channel is used to carry down-
carrier 1 link data packets. Control traffic is carried down to the
time
device by means of the NPBCH channel and the NPDCCH.
Fig. 8.19 SC-FDMA The master information block (MIB) is transmitted over the
NPBCH channel, while the system information block (SIB)
is transmitted over the NPDCCH channel. The NPSS and
46 dBm, respectively. From a battery life preservation per- NSSS signals are used by the device for timing and frequency
spective, NB-IoT relies on two different mechanisms: power- synchronization with the base station. Similarly, the NSR
saving Mode (PSM) and Extended Discontinuous Reception signal enables cell search and initial system acquisition.
(eDRX). Under PSM, although a device is registered with the Figure 8.22 depicts the downlink frame composed of ten
network, it typically sleeps for up to 413 days and cannot be subframes; subframe 0 carries the NPBCH, and subframes
reached by the base station. Similarly, under eDRX a device 1 through 4 and 6 through 8 carry the NPDCCH chan-
is typically inactive for up to a few hours only. nel for control traffic and the NPDSCH channel for data
NB-IoT follows the frame structure of LTE with 1024 traffic, while subframes 5 and 9 carry the NPSS and the
hyperframes where each hyperframe, in turn, contains 1024 NSSS signals. The downlink control information (DCI) that
frames. The duration of each hyperframe cycle is 104,85.76 is carried by the NPDCCH channel provides the device with
s. For a 15 KHz carrier spacing, associated with both up- information related to the cell identity and available resources
link and downlink shown in Fig. 8.20, each frame has ten to map NPDSCH channel symbols.
subframes where each subframe contains two 500-µs slots. NB-IoT devices follow the same procedure as LTE UEs
Similarly, for a 3.75 KHz carrier spacing associated with to synchronize and allocate the timing of slots and frames
only a single uplink shown in Fig. 8.21, each frame has five during cell acquisition. After decoding MIB and SIB data,
8.6 NB-IoT 205

10485.76 s

hyperframe 0 hyperframe 1 hyperframe 1023

10.24 s

frame 0 frame 1 frame 1023

10 ms

subframe 0 subframe 1 subframe 9

1 ms

slot 0 slot 1

500 μs

Fig. 8.20 Uplink/downlink hyperframe structure for 15 KHz spacing

10485.76 s

hyperframe 0 hyperframe 1 hyperframe 1023

10.24 s

frame 0 frame 1 frame 1023

10 ms

slot 0 slot 1 slot 2 slot 3 slot 4

2 ms

Fig. 8.21 Uplink hyperframe structure for 3.75 KHz spacing

Fig. 8.22 Downlink frame #0 #1 #2 #3 #4 #5 #6 #7 #8 #9

structure NPDCCH NPDCCH NPDCCH NPDCCH NPSS NPDCCH NPDCCH NPDCCH NPSS
NPBCH
NPDSCH NPDSCH NPDSCH NPDSCH NSSS NPDSCH NPDSCH NPDSCH NSSS

subframes
frame
NPBCH Narrowband Physical Broadcast Channel
NPDCCH Narrowband Physical Downlink Control Channel
NPDSCH Narrowband Physical Downlink Shared Channel
NPSS Narrowband Primary Synchronization Signal
NSSS Narrowband Secondary Synchronization Signal

the cell identifier, subframe number, scheduling information, 8.6.2 Link and Upper Layers
and system bandwidth become available to the device. Addi-
tionally, each device acquires a UE identifier as part of the The NB-IoT network topology is based on legacy LTE in-
random access procedure (RAP) that is performed during frastructure. It includes (1) a network core called evolved
initial uplink synchronization and any time synchronization packet core (EPC) shown in Fig. 8.23, (2) an evolved UMTS
needs to be regained due to a long period of inactivity. terrestrial radio access Network (E-UTRAN), and (3) UE
206 8 LPWAN Technologies

that consists of IoT devices. The EPC includes a mobility plane CIoT EPS. Mandatory control plane CIoT EPS enables
management entity (MME) that handles the mobility of the the encapsulation of data packets by means of signaling mes-
devices but also performs several actions like tracking of sages in Non-Access Stratum (NAS). When device mobility
devices, session management, and serving gateway (S-GW) is under consideration, loss of signal can lead to a great
selection for devices initial attachment and authentication. QoS degradation. NB-IoT introduces radio resource control
The S-GW routes the data packets through the network and (RRC) that provides the transmission of data packets over the
serves as anchor for device handover when transitioning be- control plane and supports the reestablishment of connection
tween different eNode base stations (eNBs). The packet data upon loss of signal. Essentially, RRC hides the loss of the
node gateway (P-GW) provides the interface between the radio interface to the upper layers. Optional user plane CIoT
3GPP network and an external network like the IP network. EPS relies on RRC for the device to get Access Stratum (AS)
Finally, the home subscriber server (HSS) is a database that and provide connection suspend and resume procedures to
is used for mobility, session and user management, as well as keep the connection context during radio interface transi-
access authorization. tions. When a device wants to transmit data packets uplink, it
The MAC sublayer within the link layer is responsible, starts a service request procedure by sending a random access
among other things, of handling retransmissions by means of preamble that triggers the establishment of an RRC connec-
a hybrid automatic repeat request (HARQ) mechanism, tim- tion and the reservation of associated radio resources. The
ing advance, multiplexing, random access, priority manage- base station initiates the release procedure after an extended
ment, and scheduling. Resource allocation must ensure that period of inactivity. Similarly, for downlink transmissions,
the maximum number of devices is served in any given cell if the device is in eDRX mode, when it receives a paging
while accomplishing a specific throughput level, spectral effi- message, it starts a service request procedure as described
ciency, and coverage. To this end, several resources including for the uplink scenario.
tone allocations, power configurations, frames, subframes,
and slots must be adjusted in order to maximize performance.
NB-IoT, as with LTE, includes adaptive power consumption 8.7 More LPWAN Technologies
and symbol repetition in order to extend coverage and im-
prove link reliability. Adaptive power consumption is pro- There are several other LPWAN technologies; many of them
vided by means of the PSM and eDRX mechanisms. are commercial, and some others are experimental. They
In order to deal with IP and non-IP datagrams, NB-IoT provide mechanisms that range from proprietary protocols
introduces additional changes to the EPC by adding the to open standards. This section presents the most important
Service Capability Exposure Function (SCEF). Additionally, ones.
NB-IoT introduces a cellular IoT (CIoT) Evolved Packet
System (EPS) that provides new small data transmission
procedures over long-range distances. Typically, more than 8.7.1 NB-Fi
one data path is carried by the MME signaling messages. Two
main procedures are optimized to support small data transfer: Narrowband fidelity (NB-Fi) is an open full stack protocol
(1) mandatory control plane CIoT EPS and (2) optional user that is the base of a commercial LPWAN turn-key solution

Fig. 8.23 EPC

UE MME HSS

UE eNB

UE S-GW P-GW

UE User Equipment
eNB eNode Base Station
MME
S-GW
Mobility Management Enty
Serving Gateway
IP
P-GW Packet Data Node Gateway
HSS Home Subscriber Server
8.7 More LPWAN Technologies 207

that includes devices and networks developed by WAVIoT available 2.4 GHz spectrum is divided into 1 MHz channels
[11, 16]. Its goal is to provide a robust and reliable interac- that can be grouped to support different deployments.
tion between devices and base stations acting as traditional RPMA is a type of a DSSS scheme used only for up-
IoT gateways. As most other LPWAN technologies, NB-Fi link communications and, as such, represents a variation of
provides long battery life combined with low hardware cost. traditional CDMA. One of the main differences between
Moreover, NB-FI attempts to lower both deployment costs DSSS and RPMA is that although both mechanisms allow
and deployment times by simplifying the network topology. transmitters to share a single timeslot, under RPMA the
The typical transmission ranges are around 10 and 30 km for duration of the timeslot is increased, and the starting trans-
urban and rural environments, respectively. NB-Fi applica- mission delay (or phase) is randomized in order to minimize
tions range from smart metering and smart cities to home and intertransmitter interference. Moreover, RPMA supports a
building automation. mechanism for transmission rate adaptation regulated by the
NB-Fi’s physical layer relies on transmission over the 433 spreading factor estimated from the received signal strength.
and 915/868 MHz ISM bands to accomplish transmission The base stations rely on multiple receivers tuned to de-
rates between 50 bps and 25.6 Kbps. Modulation is by means modulate the signals arriving at different starting times and
of DBPSK but optimized to improve spectral efficiency and exhibiting different spreading factors. Downlink communi-
performance through software-defined Radio (SDR). TDD is cation relies on CDMA. In all cases, the signal modulation
used by device and base station signals to share the channel. is by means of DBPSK. RPMA devices also adapt their
The NB-Fi link layer relies on both TDMA and FDMA for transmission power by communicating with the closest base
media access. This enables network scenarios that include station in order to minimize interference. Overall, all these
both star topology and mesh schemes where a single base features together with a higher bandwidth that most other
station can support up to two million devices. LPWAN technologies give RPMA higher transmission rates.
Specifically, nominal rates of 624 and 156 Kbps for uplink
and downlink, respectively, are common. RPMA encrypts all
8.7.2 IQRF traffic and introduces FEC through convolutional codes.

IQRF is an open LPWAN framework that includes devices,

gateways, and applications addressing scenarios ranging 8.7.4 Telensa
from telemetry and industrial control to home and building
automation [10]. OQRF provides a full protocol stack Telensa is a fully proprietary LPWAN technology that fo-
with a physical layer that relies on transmission over the cuses mainly on smart city applications with emphasis on
433 and 915/868 MHz ISM bands. As with many other smart lighting and smart parking as it does not support
LPWAN technologies, modulation supported by GFSK indoor communications [23,35]. Millions of Telensa devices
enables transmission rates up to 20 Kbps with frames that have been deployed in more than 50 smart cities networks
are 64 bytes long. The nominal signal coverage of IQRF worldwide. Although Telensa supports bidirectional traffic
is 500 m. IQRF has a network layer that supports mesh associated with both sensors and actuators, in the context
networking through a protocol called IQMESH that supports of smart cities, streetlight poles are typically arranged with
up to 240 hops. IQRF includes an optional transport layer several devices including pollution, temperature, humidity,
called direct peripheral access (DPA) that provides dataflow- radiation level, and noise level sensors. Moreover, Telensa
oriented communications. The maximum number of devices is not just a technology but a framework for building smart
per gateway is 65,000 but it reduces to 240 if DPA is in place. city applications by means of a smart city API. As part of
this framework, it provides mechanisms for integration with
support services like billing systems and metering. Telensa
8.7.3 RPMA is a member of the Weightless SIG board, and it is involved
with the TALQ consortium that oversees defining control and
Random Phase Multiple Access (RPMA) is a media access monitor standards for outdoor lighting. Moreover, although
scheme, developed and patented by Ingenu, that serves as Telensa is a proprietary technology, there is an ongoing effort
the base of a robust LPWAN technology [15, 25]. RPMA for standardization through ETSI low-throughput networks
operates over the 2.4 GHz ISM band as opposed to most (LTN) specifications.
other LPWAN technologies that rely on sub-GHz frequencies Telensa’s physical layer relies on UNB transmission over
like those of the 433 and 915/868 MHz bands. Although the 915/868 MHz ISM band that provides very low trans-
sub-GHz bands exhibit better propagation properties, the mission rates. Specifically, Telensa supports 62.5 and 500
2.4 GHz ISM band is less restrictive and does not impose duty bps uplink and downlink, respectively. Note that, as opposed
cycle limitations that, in turns, limit transmission rates. The to most other LPWAN technologies, the uplink typically
208 8 LPWAN Technologies

used to the transmission of sensor traffic is considerably 8.7.7 Qowisio

slower than the downlink used for actuation. Telensa has a
Central Management System (CSM) called Telensa PLANet Qowisio is another UNB turnkey commercial LPWAN solu-
that coordinates end-to-end operations and minimizes energy tion supporting a wide range of applications ranging from as-
consumption as well as enabling automatic fault detection. A set tracking and management to lighting and power monitor-
Telensa base station, playing the role of an IoT gateway, can ing [25]. It is compatible with LoRa by providing dual model
communicate with up to 5000 devices covering a physical technology support. It provides coverage of up to 60 km and
range of 2 and 4 km for urban and rural locations, respec- 3 km in rural and urban environments, respectively.
tively.

8.7.8 IEEE 802.15.4k

8.7.5 SNOW
The IEEE 802.15.4k Task Group (TG4k) introduced a new
Sensor network over white spaces (SNOW) is an experimen- standard for low energy, critical infrastructure monitoring
tal LPWAN technology that, as Weightless, relies on trans- (LECIM) applications that, as IEEE 802.15.4, relies on the
mission over white space spectrum with modulation over 2.4 GHz, the 915/868 MHz, and the 433 MHz ISM bands for
unoccupied frequency guardbands between TV channels typ- transmission [27, 25]. The spectrum is divided into discrete
ically between 547 and 553 MHz. In general, a base station channels with bandwidths ranging from 100 KHz to 1 MHz.
determines white space frequencies for devices by means of It is an attempt to provide LPWAN communications by
a database on the Internet [31, 29]. The available bandwidth increasing the transmission range of traditional WPAN-based
is divided into multiple channels that enable transmission IEEE 802.15.4. At the physical layer, it supports three differ-
over multiple subcarriers where a variation of OFDM called ent modulations that combine DSSS with BPSK, OQPSK, or
distributed OFDM (DOFDM) is used. DOFDM, as opposed FSK. Depending on device and communication constraints,
to OFDM, enables multiple transmitters to simultaneously one scheme is chosen over the others. Further adjustments
send traffic over multiple subcarriers. The modulation itself are performed by means of modifications to the spreading
is by means of a variation of ASK called on-off keying (OOK) factor between 16 and 32,768. IEEE 802.15.4k also intro-
that consists of transmitting a signal whenever a binary one duces a FEC scheme based on convolutional codes. The
is sent and not transmitting any signal otherwise. The frame link layer provides MAC through conventional CSMA/CA
size is 40 bytes including a 28-byte header that enables a and ALOHA with priority channel access (PCA). PCA is a
nominal transmission rate of 50 Kbps. SNOW supports a mechanism by which devices and base stations support QoS
star topology with a single base station that acts as an IoT levels that can be used to specify the priority of the traffic.
gateway communicating with multiple devices located as far IEEE 802.15.4k operates in a star topology with a nominal
as 1.5 km away. The link layer operates in two phases, a coverage of 3 km. Transmission rates of up to 50 Kbps are
long period of time for uplink transmissions and a lot short possible [2].
period for downlink communication. FEC through redundant
transmission of packets increases reliability and removes the
need for acknowledgments [30]. 8.7.9 IEEE 802.15.4g

The IEEE 802.15.4g Task Group (TG4g) introduced a new

8.7.6 Nwave standard known as wireless smart utility networks (Wi-SUN)
targeting smart metering applications like, for example,
Nwave is a commercial LPWAN solution intended for mobile gas metering [26, 17]. As with IEEE 802.15.4k, IEEE
devices associated with smart parking [11]. The physical 802.15.4g addresses some of the limitations of traditional
layer provides UNB transmission over the 915/868 MHz ISM WPAN IEEE 802.15.4. Specifically, IEEE 802.15.4, as
band. Nwave supports a single hop star topology with a indicated in Sect. 3.3.3.4, is highly affected by interference
coverage of up to 10 km in urban environments. Long range and multipath fading that reduce communication reliability.
and low power are responsible for transmission rates of Moreover, IEEE 802.15.4 relies on complex and costly multi-
around 100 bps and a maximum device battery life of 9 years. hop transmissions for long-range communication that are
Nwave provides its own real-time sensor data collection and not viable in smart metering scenarios. IEEE 802.15.4g
analytics applications that enable city planners to allocate modulation is over the 2.4 GHz and the 915/868 MHz ISM
resources. bands and supported by three different physical layers that
provide a trade-off between transmission rates and power
consumption: (1) myindexFSK combined with FEC, (2)
8.7 More LPWAN Technologies 209

DSSS with OQPSK, and (3) OFDMA in scenarios affected LTE-M does to the LTE spectrum [11, 16, 3]. Specifically,
by multipath fading. Although nominal transmission rates, it increases coverage and lowers power consumption. As a
depending on the modulation scheme under consideration, CIoT technology, it operates on the GSM 850–900 and 1800–
can range from 6.25 to 800 Kbps, the standard defines FSK 1900 MHz bands providing a similar coverage and power
as the default mandatory mode of transmission supporting consumption to that of NB-IoT. The channel bandwidth
a transmission rate of 50 Kbps. As transmission rates are is 200 MHz, where like in most GSM networks, MAC is
higher than those of IEEE 802.15.4, the corresponding MTU performed by means of combining FDMA with TDMA and
size is also larger without affecting the transmission delay. FDD. Modulation is carried out by Gaussian Minimum Shift
Specifically, IEEE 802.15.4g supports a maximum frame Keying (GMSK) and 8PSK providing nominal transmission
size of 1500 bytes that enable the transmission of a complete rates between 70 Kbps and 240 Kbps, respectively. Latency
IPv6 datagram over a single frame without needing to apply is typically less than 2 s being lower than that of both LTE-M
any fragmentation. The link layer can be configured to and NB-IoT. As LTE-M, EC-GSM-IoT is enabled in existing
provide MAC based on IEEE 802.15.4 or on IEEE 802.15.4e GSM networks by means of a software upgrade. Because
introduced in Sect. 3.3.3 [1].Typical signal coverage of IEEE GSM networks are in the process of decommission, EC-
802.15.4g is around 10 km. GSM-IoT is a lot less popular than LTE-based technologies.
EC-GSM-IoT also exhibits comparatively high capacity sup-
porting around 50,000 devices in each cell. Moreover, EC-
8.7.10 LTE-M GSM-IoT is designed to provide coverage in locations where
radio conditions are challenging such as indoor basements
Standardized together with NB-IoT as part of the 3GPP where many sensors are usually installed. Battery life is
Release 13, LTE-M, also known as LTE Cat M1 or enhanced around 10 years, and security and privacy, as with LTE-M and
machine-type communication (eMTC), is a simplified ver- NB-IoT, are guaranteed by mutual authentication, confiden-
sion of 4G LTE that attempts to provide CIoT support by tiality, and encryption provided by legacy mechanisms [34].
reducing power consumption while extending signal cover-
age [11, 3]. Specifically, battery life is increased to over
10 years, while modem costs are reduced by 25%. When 8.7.12 5G and B5G Considerations
compared to LTE, LTE-M lowers nominal transmissions rates
to around 1 Mbps by reducing the available bandwidth from 4G LTE IoT solutions like NB-IoT and LTE-M intended
20 to 1.4 MHz (as opposed to 200 KHz of NB-IoT). Most for fixed/low-rate and mobile/high-rate applications, respec-
LTE functionality is available under LTE-M including Voice tively, have transitioned into 5G scenarios as part of the
over LTE (VoLTE). In order to increase battery life, LTE-M evolution of the 3GPP releases. This is further simplified by
supports optional half duplex transmissions. Some features of the fact that 5G is typically deployed as 5G non-standalone
NB-IoT like eDRX and PSM, introduced in Sect. 8.6, are also (5G NSA) where 5G is supported as a software upgrade
available under LTE-M. In most scenarios upgrading an LTE that updates protocols on legacy 4G LTE hardware. This
network to support LTE-M is as simple as a software upgrade. latter deployment is usually known as 5G LTE as opposed
LTE-M does not compete with NB-IoT, and the selection of to 5G standalone (5G SA) where additional hardware also
one technology versus the other depends on rate, coverage, known as new radio (NR) is needed to support frequency
and power consumption considerations. Device density is bands above 6 GHz [4, 32]. In this context, 3GPP Release
also increased by supporting over 100,000 devices in each 15 addresses the NR modifications needed to support both
cell. For deep coverage deployments associated with CIoT 5G NB-IoT and 5G LTE-M. As part of this evolution, one
scenarios, latency is within 10 s, while battery life is never of the main requirements for the future IoT applications
longer than 10 years, but for normal coverage, similar to that is massive access. Beyond 5G (B5G) including future 6G
of a smartphone, latency lowers to 0.1 s while the battery life networks will attempt to address this and other requirements
extends to 35 years [16]. in order to increase density to over a million devices per
square kilometer, increase battery life to 20 years, support
space-air-ground-sea coverage, reduce latency to less than a
8.7.11 EC-GSM-IoT second, and increase positioning precision to 1 m [19].

As LTE-M, extended coverage GSM IoT (EC-GSM-IoT) was

standardized together with NB-IoT as part of the 3GPP Re- 8.7.13 IPv6 Support Considerations
lease 13. As opposed to LTE-M and NB-IoT that are based on
LTE, EC-GSM-IoT is based on enhanced GPRS, also known LPWAN technologies use most of the device energy to pro-
as 2.75G. EC-GSM-IoT does to the GSM spectrum what vide extended coverage in order to minimize infrastructure
210 8 LPWAN Technologies

Table 8.3 LPWAN technologies Telensa, SNOW, NWave, Qowisio, IEEE 802.15.4k, IEEE
Technology Bands Max nominal rate Max coverage 802.15.4g, LTE-M, and EC-GSM-IoT including 5G, B5G,
LoRa ISM 1 GHz 50 Kbps 20 km and 6G considerations. The chapter ended by exploring IPv6
SigFox ISM 1 GHz 600 bps 40 km support of LPWAN mechanisms. Table 8.3 compares the
D7AP ISM 1 GHz 166 Kbps 10 km features of some of the most relevant LPWAN technologies.
Weightless TV guardbands 16 Mbps 5 km
NB-IoT LTE/5G 200 Kbps 10 km
NB-Fi ISM 1 GHz 25.6 Kbps 30 km Homework Problems and Questions
IQRF ISM 1 GHz 20 Kbps 500 m
RPMA ISM 1 GHz, 2.4 GHz 624 Kbps 25 km 8.1 If an application in the cloud is sending actuation com-
Telensa ISM 1 GHz 500 bps 16 km mands to a LoRa device, what LoRa media access class con-
SNOW TV guardbands 50 Kbps 1.5 km figuration is likely to minimize the delay of these commands
Nwave ISM 1 GHz 100 bps 10 km arriving at the device?
IEEE 802.15.4k ISM 1 GHz, 2 GHz 50 Kbps 3 km
IEEE 802.15.4g ISM 1 GHz, 2 GHz 50 Kbps 10 km 8.2 What LPWAN technologies do not rely on ISM bands
for transmission?

investment. The cost of this extended coverage, however, is 8.3 What LoRa MAC class enables the longest battery life?
very little energy left for computation, resource, and protocol
complexity. This leads to several challenges that prevent 8.4 If it were possible to transmit a CoAP message over
LPWAN from implementing IPv6 adaptation mechanisms LoRa and assuming:
like 6LoWPAN and 6Lo: (1) MTU and transmission rates
are several other of magnitude below those of WPAN tech- (a) LoRa configured with 50 devices transmitting over 8 km
nologies, (2) lack of link layer fragmentation support, and at a nominal maximum rate of 250 bps.
(3) uplink and downlink asymmetry. In this scenario, any (b) An 8-byte payload over an unencrypted NON CoAP mes-
adaptation that attempts to overcome the 6LoWPAN and sage transmitted over an adaptation mechanism that en-
6Lo limitations results in energy consumption levels that are codes IPv6 and UDP headers as a single 21-byte header.
unacceptable for LPWAN. Assume the LoRaWAN header is included in the adapta-
There have been, however, some attempts to provide IPv6 tion layer header.
support in LPWAN by adapting some of the lightweight (c) No network loss and no delays other than the transmis-
features of 6LoWPAN and 6Lo. Specifically, IETF RFC sion delay.
8724 SCHC: Generic Framework for Static Context Header
Compression and Fragmentation introduces Static Context How long does it take for a sensor to send a single readout?
Header Compression (SCHC) a mechanism that provides How does it compare to the best-case scenario of IEEE
both static header compression and fragmentation in the 802.15.4?
context of LPWANs [20]. Static header compression relies
on a common static context on both device and network in- 8.5 Many LPWAN technologies like SigFox support differ-
frastructure sides. SCHC is used to compress IPv6 and UDP ent transmission rates for uplink and downlink traffic. (a)
headers. There are, in addition, several proposals to specialize Why is this important? (b) How does this relate to IPv6
the use of SCHC under LoRa, NB-IoT, and SigFox. support?

8.6 What are the best and worst-case latency scenarios for a
Summary 45-byte long packet transmitted over NB-IoT?

LPWAN solutions provide long-range signal coverage be- 8.7 What are some differences between Weightless and
tween devices and gateways at a cost of comparatively low other LPWAN technologies?
transmission rates. As such most LPWAN schemes do not
fully support end-to-end IPv6 connectivity, and they rely on 8.8 Is there any LPWAN technology that provides IPv6
gateways and border routers to convert protocol stacks. The support?
chapter started by briefly describing IoT support of LPWAN
technologies and then switched to presenting LoRa, SigFox, 8.9 Many LPWAN technologies like Weighless-N only en-
D7AP, Weightless, and NB-IoT. The chapter then introduced able the transmission of uplink traffic. (a) How does this
other less common technologies like NB-Fi, IQRF, RPMA,
References 211

affect performance? (b) What are the implications for IoT 16. Foubert, B., Mitton, N.: Long-range wireless radio technologies:
applications? a survey. Future Internet 12, 13 (2020). https://doi.org/10.3390/
fi12010013
17. Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., Obata, K.,
8.10 Assuming a symbol rate of 4×106 symbols per second, Okumura, R.: IEEE 802.15.4g based wi-sun communication sys-
how is the 500 Kbps transmission rate accomplished under tems. IEICE Trans. Commun. E100.B, 1032–1043 (2017). https://
Weightless? Assume a 4 MHz channel. doi.org/10.1587/transcom.2016SCI0002
18. Lavric, A., Popa, V.: Internet of things and lora low-power wide-
area networks: A survey. In: 2017 International Symposium on
Signals, Circuits and Systems (ISSCS), pp. 1–5 (2017)
References 19. Malik, H., Sarmiento, J.L.R., Alam, M.M., Imran, M.A.:
Narrowband-internet of things (NB-IoT ): Performance evaluation
1. IEEE standard for local and metropolitan area networks–part 15.4: in 5G heterogeneous wireless networks. In: 2019 IEEE 24th
Low-rate wireless personal area networks (LR-WPANS) amend- International Workshop on Computer Aided Modeling and Design
ment 3: Physical layer (PHY) specifications for low-data-rate, of Communication Links and Networks (CAMAD), pp. 1–6
wireless, smart metering utility networks. IEEE Std 802.15.4g- (2019)
2012 (Amendment to IEEE Std 802.15.4-2011) pp. 1–252 (2012) 20. Minaburo, A., Toutain, L., Gomez, C., Barthel, D., Zuniga, J.C.:
2. IEEE standard for local and metropolitan area networks—part SCHC: Generic Framework for Static Context Header Compres-
15.4: Low-rate wireless personal area networks (LR-WPANS)- sion and Fragmentation. RFC 8724 (2020). https://doi.org/10.
amendment 5: Physical layer specifications for low energy, criti- 17487/RFC8724. https://rfc-editor.org/rfc/rfc8724.txt
cal infrastructure monitoring networks. IEEE Std 802.15.4k-2013 21. Morin, E., Maman, M., Guizzetti, R., Duda, A.: Comparison of the
(Amendment to IEEE Std 802.15.4-2011 as amended by IEEE Std device lifetime in wireless networks for the internet of things. IEEE
802.15.4e-2012, IEEE Std 802.15.4f-2012, IEEE Std 802.15.4g- Access 5, 7097–7114 (2017). https://doi.org/10.1109/ACCESS.
2012, and IEEE Std 802.15.4j-2013) pp. 1–149 (2013) 2017.2688279.https://hal.archives-ouvertes.fr/hal-01649135
3. 3GPP: 3GPP release 13 (2015). https://www.3gpp.org/release-13 22. Mroue, H., Nasser, A., Hamrioui, S.: Mac layer-based evaluation of
4. Akpakwu, G.A., Silva, B.J., Hancke, G.P., Abu-Mahfouz, A.M.: A IoT technologies: Lora, sigfox and NB-IoT. In: IEEE Middle East
survey on 5G networks for the internet of things: communication and North Africa Communications Conference (MENACOMM)
technologies and challenges. IEEE Access 6, 3619–3647 (2018) (2018). https://doi.org/10.1109/MENACOMM.2018.8371016
5. Al-Sarawi, S., Anbar, M., Alieyan, K., Alzubaidi, M.: Internet 23. Naik, N.: LPWAN technologies for IoT systems: Choice between
of things (IoT) communication protocols: Review. In: 2017 8th ultra narrow band and spread spectrum. In: 2018 IEEE International
International Conference on Information Technology (ICIT), pp. Systems Engineering Symposium (ISSE), pp. 1–8 (2018)
685–690 (2017) 24. Oliveira, L., Rodrigues, J., Kozlov, S., Rabelo, R., Albuquerque, V.:
6. Alliance, L.: Lorawan 1.1 specification (2017). https://lora- Mac layer protocols for internet of things: a survey. Future Internet
alliance.org/sites/default/files/2018-04/lorawantm_specification_- 11, 16 (2019). https://doi.org/10.3390/fi11010016
v1.1.pdf 25. Raza, U., Kulkarni, P., Sooriyabandara, M.: Low power wide area
7. Augustin, A., Yi, J., Clausen, T., Townsley, W.M.: A study of networks: An overview. IEEE Commun. Surv. Tutor. 19, 855–873
lora: Long range & low power networks for the internet of things. (2016)
Sensors 16(9), 1466 (2016). https://doi.org/10.3390/s16091466. 26. Righetti, F., Vallati, C., Comola, D., Anastasi, G.: Performance
https://pubmed.ncbi.nlm.nih.gov/27618064. 27618064[pmid] measurements of IEEE 802.15.4g wireless networks. In: 2019
8. Ayoub, W., Nouvel, F., Samhat, A.E., Prévotet, J.C., Mroue, M.: IEEE 20th International Symposium on “A World of Wireless,
Overview and measurement of mobility in DASH7. In: 2018 25th Mobile and Multimedia Networks” (WoWMoM), pp. 1–6 (2019)
International Conference on Telecommunications (ICT), pp. 532– 27. Roth, Y., Dore, J.B., Ros, L., Berg, V.: A comparison of physical
536. IEEE, St. Malo (2018). https://doi.org/10.1109/ICT.2018. layers for low power wide area networks. In: Cognitive Radio Ori-
8464846. https://hal.archives-ouvertes.fr/hal-01991725 ented Wireless Networks. CrownCom 2016, pp. 261–272 (2016).
9. Ayoub, W., Samhat, A.E., Nouvel, F., Mroue, M., Prevotet, J.: In- https://doi.org/10.1007/978-3-319-40352-6_21
ternet of mobile things: overview of LoRaWAN, DASH7, and NB- 28. Saari, M., bin Baharudin, A.M., Sillberg, P., Hyrynsalmi, S., Yan,
IoT in LPWANs standards and supported mobility. IEEE Commun. W.: Lora-a survey of recent research trends. In: 2018 41st Interna-
Surv. Tutor. 21(2), 1561–1581 (2019) tional Convention on Information and Communication Technology,
10. Calvo, I., Gil-Garcia, J., Recio, I., Lopez, A., Quesada, J.: Building Electronics and Microelectronics (MIPRO), pp. 0872–0877 (2018)
IoT applications with raspberry Pi and low power IQRF communi- 29. Saifullah, A., Rahman, M., Ismail, D., Lu, C., Chandra, R., Liu,
cation modules. Electronics 5, 54 (2016). https://doi.org/10.3390/ J.: Snow: Sensor network over white spaces. In: SenSys ’16:
electronics5030054 Proceedings of the 14th ACM Conference on Embedded Network
11. Chaudhari, B., Zennaro, M., Borkar, S.: LPWAN technologies: Sensor Systems CD-ROM, pp. 272–285 (2016). https://doi.org/10.
emerging application characteristics, requirements, and design con- 1145/2994551.2994552
siderations. Future Internet 12, 46 (2020). https://doi.org/10.3390/ 30. Saifullah, A., Rahman, M., Ismail, D., Lu, C., Liu, J., Chandra, R.:
fi12030046 Enabling reliable, asynchronous, and bidirectional communication
12. Chen, M., Miao, Y., Hao, Y., Hwang, K.: Narrow band internet of in sensor networks over white spaces. In: Proceedings of the 15th
things. IEEE Access 5, 20557–20577 (2017) ACM Conference on Embedded Network Sensor Systems, SenSys
13. Farrell, S.: Low-Power Wide Area Network (LPWAN) Overview. ’17. Association for Computing Machinery, New York (2017).
RFC 8376 (2018). https://doi.org/10.17487/RFC8376. https://rfc- https://doi.org/10.1145/3131672.3131676
editor.org/rfc/rfc8376.txt 31. Saifullah, A., Rahman, M., Ismail, D., Lu, C., Liu, J., Chandra,
14. Ferré, G., Simon, E.P.: An introduction to Sigfox and LoRa R.: Low-power wide-area network over white spaces. IEEE/ACM
PHY and MAC layers (2018). https://hal.archives-ouvertes.fr/hal- Trans. Netw. 26(4), 1893–1906 (2018). https://doi.org/10.1109/
01774080. Working paper or preprint TNET.2018.2856197
15. Finnegan, J., Brown, S.: A Comparative Survey of LPWA Network- 32. Salva, P., Alcaraz-Calero, J., Wang, Q., Bernal Bernabe, J.,
ing. arXiv (2018), arXiv:1802.04222 Skarmeta, A.: 5g NB-IoT: Efficient network traffic filtering for
212 8 LPWAN Technologies

multitenant IoT cellular networks. Secur. Commun. Netw. 2018, MHz. In: 2011 IEEE International Symposium on Antennas and
1–21 (2018). https://doi.org/10.1155/2018/9291506 Propagation (APSURSI), pp. 3389–3392 (2011)
33. Shanmuga Sundaram, J.P., Du, W., Zhao, Z.: A survey on lora 36. Webb, W.: Weightless: the technology to finally realise the m2m
networking: research problems, current solutions, and open issues. vision. Int. J. Interdiscip. Telecommun. Netw. 4, 30–37 (2012).
IEEE Commun. Surv. Tutor. 22(1), 371–388 (2020) https://doi.org/10.4018/jitn.2012040102
34. Silva, P., Kaseva, V., Lohan, E.S.: Wireless positioning in IoT: a 37. Weyn, M., Ergeerts, G., Berkvens, R., Wojciechowski, B., Tabakov,
look at current and future trends. Sensors 18, 2470 (2018). https:// Y.: Dash7 alliance protocol 1.0: Low-power, mid-range sensor and
doi.org/10.3390/s18082470 actuator communication. In: 2015 IEEE Conference on Standards
35. Walden, M.C., Jackson, T., Gibson, W.H.: Development of an for Communications and Networking (CSCN) (2015)
empirical path-loss model for street-light telemetry at 868 and 915
 Thread Architecture
9

deliver an end-to-end solution. Although Thread is typically

9.1 Thread and IoT intended for home automation, it can be used in the context of
other industries ranging from asset monitoring to IIoT. Home
In the domain of WPAN solutions, the IETF protocol stack automation is associated with the concept of connected home
plays a very important role in providing a generic framework where the devices consist of AC powered lights, door and
for IoT wireless applications. One of the most common im- window sensors, motion detectors, door locks, appliances,
plementations of this stack is shown in Fig. 9.1. Specifically, as well as heating, ventilation, and air conditioning (HVAC)
the stack is a combination of some of the layers presented equipment and battery-operated thermostats, smoke, CO, and
in Sect. 4.3. Physical and link layers are carried out by CO2 detectors. Thread device reliability is very important,
IEEE 802.15.4 [2], while the network layer relies on IPv6 and it implies that, as simple as the devices can be, they must
adapted by means of 6LoWPAN [8] with routing provided still be able to store certain persistent information like PAN
through RPL [3]. UDP encrypted with DTLS [9] provides identifiers and other security parameters.
transport to the application layer that is, in turn, subdivided Thread attempts to provide simple and low-cost network
into two sublayers. One session sublayer is associated with installation, startup, as well as operation with full IPv6 sup-
CoAP messages, while the other carries application sensor port for integration with other Internet applications. Addi-
and actuator traffic. This quick introduction serves to present tionally, Thread supports several topologies that increase
Thread because Thread is an open IoT architecture that relies flexibility in most connected home deployments of hundreds
on a protocol stack that is quite similar to the one shown in of devices. By relying on end-to-end IP connectivity, device
Fig. 9.1. The Thread protocol stack is shown in Fig. 9.2; the installation is performed using a smartphone, a computer, or
main big difference with the IETF stack is that routing instead a tablet through an application or through the web. Product
of being based on IoT specific RPL relies on traditional DV installation codes enable only authorized devices to join
mechanisms. Additionally, Thread uses plain IEEE 802.15.4 a Thread network. Additionally, all traffic is authenticated
with CSMA/CA MAC and therefore does not take advan- and encrypted with AES. Although device connectivity is
tage of the IEEE 802.15.4e [1] improvements introduced typically through IEEE 802.15.4, users rely on Wi-Fi to
by TSCH MAC. Moreover, Thread does not rely on any communicate with the network directly through a HAN or
other WPAN physical and link layer mechanism like BLE. through a cloud-based application [12].
Note that Thread is a full-stack architecture that exploits The architecture relies on a series of simple mechanisms
and extends some IETF mechanisms. As such, Thread is that complement routing and allow the network to self-
comparable to other proprietary stacks like ZigBee, BLE, and configure and repair itself. Thread inherits most of the char-
Z-Wave [14]. Obviously, Thread supports end-to-end IPv6 acteristics from the IETF and IEEE protocols that form
connectivity and consequently it is fully IoT compliant. its stack; they include long battery life, security, and mesh
Thread is a lot more than a protocol stack; by being both an routing support among other features. The coverage is given
architecture and a framework, it provides a recipe to deploy by the physical layer protocol, IEEE 802.15.4, and as such it
IoT WPANs. When compared to other IoT architectures, is good enough to cover a large home. Any equipment used
Thread has been designed for highly reliable wireless device- to extend coverage of IEEE 802.15.4 networks can be used
to-device communication because it does not have a single also in Thread scenarios. Battery life is extended by means of
point of failure. Moreover, Thread specifies the interaction power duty cycles that enable a single device to operate over
between the layers and the supported mechanisms needed to several years on a few AA batteries.

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 213
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5_9
214 9 Thread Architecture

Fig. 9.1 IETF stack DEVICE DATA application layer

CoAP
DTLS transport layer
UDP
IPv6 RPL network layer
6LoWPAN
IEEE 802.15.4 link layer

IEEE 802.15.4 physical layer

Fig. 9.2 Thread stack DEVICE DATA application layer

CoAP
DTLS transport layer
UDP
IPv6 DV network layer
6LoWPAN
IEEE 802.15.4 link layer

IEEE 802.15.4 physical layer

Fig. 9.3 Thread network

MED

FED

REED

THREAD ROUTER

LEADER

IP
BORDER ROUTER

traffic and public Internet cloud applications as illustrated in

9.2 Topology Fig. 9.4. As such, they usually include both an IEEE 802.15.4
link layer interface and one or more supplemental IPv6 link
Figure 9.3 shows the standard Thread topology including layer interfaces for access to an external network. Border
all key devices: (1) border routers, (2) Leaders, (3) Router routers have at least one assigned GUA. Note that the rest of
Eligible End Devices (REEDs), (4) Thread routers, (5) Full the devices in a Thread network typically support ULA type
End Devices (FEDs), and (6) Minimal End Devices (MEDs). unicast addresses. Outgoing datagrams from the Thread net-
Border routers play the role of IoT gateways by providing work interface are forwarded to the exterior interfaces, while
connectivity between IEEE 802.15.4-based access and the datagrams from the exterior interfaces are forwarded to the
IP core. In general end devices, of any time, do not talk Thread interface and then routed over the Thread network to
to other devices, and connectivity is with other routers and the destination. The border router may also perform filtering
the network core. The border routers are, therefore, respon- and NATting based on system settings. Moreover, the border
sible for providing the routing capabilities between device router may participate in an exterior routing protocol where
9.3 Routing 215

Fig. 9.4 Border router operation

IP

IEEE 802.11 IEEE 802.15.4

IEEE 802.3
border router

thread network

it advertises global IPv6 prefixes and handles global unicast fails, a close-by REED can become Thread router so that all
address allocation of devices in the Thread network. Essen- MEDs and FEDs associated with the failing Thread router
tially, users typically connect from adjacent IP networks by become children of the transitioning REED. In most cases,
means of IEEE 802.11 (Wi-Fi) or IEEE 802.3 (Ethernet), all these topology changes are transparent to the end user.
and they access devices through the core interface of the There are certain conditions, however, under which a single
border router. In order to support redundancy and improve point of failure cannot be prevented. Border routers are
reliability, a Thread network typically has multiple border limited by hardware characteristics that force them to have
routers. The Thread Management Framework (TMF) proto- at least two interfaces: one to the access WPAN side and
col, which uses CoAP for transport, enables the notification another to the IP core side. This implies that if a border
of network data from border routers and DHCPv6 servers to router fails, communication to the IP core side will not be
Thread leaders [13]. possible unless another redundant border router exists in the
Thread routers provide routing capabilities to devices topology.
and coordination for devices to securely join the network. A Thread network is typically composed of a single par-
Because of their critical operation, Thread routers do not tition, but in certain cases, connectivity loss can lead to
typically run on constrained hardware and therefore do not disconnected sections of the network that end up grouped
perform power duty cycles that affect performance. Thread into separate partitions. The idea is that each partition is a
routers can become REEDs by downgrading their functional- Thread network with its own leader and network data. When
ity. REEDs are end devices, and as such they do not provide connectivity between partitions is back, they merge back, and
any routing or any services to other devices. Depending on the original Thread network topology is restored. Figure 9.5
topology changes and other network conditions, REEDs can illustrates how a single partition with one leader becomes two
become Thread routers or leaders without user interaction. partitions with two leaders when connectivity is lost between
REEDs cannot become border routers since they do not one side and the other of the Thread network.
usually include an interface to the core side that is needed One important concept in the context of Thread networks
to provide gateway capabilities. Leaders are routers that is commissioning. Commissioning is the process by which
keep track, through a registry, of other routers and their a user deploys a new device in a Thread network. Border
assignment. Consequently, leaders respond to requests from routers are essential in relaying messages between a man-
REEDs to become routers. For the most part, leaders rely agement application, known as commissioner, and network
on CoAP to assign and manage router addresses. The in- devices. Some of these network devices can be leader routers
formation stored in the leader registry is backed up in other that typically arbitrate the petitioning of multiple commis-
Thread routers such that if a leader becomes out of service, sioners [11].
any Thread router can automatically become the new leader.
End devices that are not REEDs can be either FEDs or MEDs.
Both FEDs and MEDs only communicate to Thread routers
and cannot serve as routers or become routers. MEDs do even 9.3 Routing
need to explicitly synchronize with their Thread routers to
transmit. Thread supports mesh forwarding that enables devices to
The Thread topology overcomes single points of failure talk to other devices by indirectly forwarding frames through
by relying on an automated and controlled mechanism in intermediate nodes. All routing entities (i.e. routers, border
which devices can take over functionality provided by failing routers and leaders) keep track and maintain routes to guar-
devices, or they can change their operation to become inde- antee that mesh forwarding is always available and fully
pendent of the failing devices. If a FED is communicating functional. Although up to 64 router addresses are supported
with a Thread router and the Thread router fails, then the in a single Thread network, not all these addresses can be
FED can select a new Thread router. If a Thread router used simultaneously in order to delay the reuse of addresses
216 9 Thread Architecture

Fig. 9.5 Multiple partitions single partition

partition 1

connectivity loss partition 2

connectivity restored

of deleted devices. Since REEDs, FEDs, and MEDs do not intended to receive the messages. Similarly, under reactive
support routing, all traffic they generate is handled by their mod MPL data messages are multicast transmitted when it
parent Thread router. is discovered that nodes have not received the messages. In
In a single Thread network, there are up to 32 active the context of Thread, MPL is mostly supported in reactive
routers that rely on DV to compute routing tables. Specif- mode. The idea behind a trickle timer is to transmit network
ically, Thread routing relies on standard RIP Next Gener- parameters and attributes while minimizing, at the same time,
ation (RIPng) standardized under IETF RFC 2080. Note the load of the network.
that RIPng supports a maximum of 15 hops per end-to-end DV routing is different from other routing mechanisms
path and uses hop count as routing metric. As with any DV like RPL typically associated with on-demand routing. Al-
mechanism, each router is aware of the next hop routers though under IoT RPL is more stable and exhibits better
and the cost of transmitting traffic to each of them. This performance than DV mechanisms, DV routing has a much
enables routers to independently build routing tables that lower overhead. Specifically, RPL DIO, DAO, and DIS mes-
guarantee full network connectivity. Note that as opposed to sages are propagated throughout the network, while DV link
RPL, where routing is hierarchical, routing under Thread is costs are only propagated between neighboring routers. The
mostly flat. Moreover, by virtue of relying on DV routing, link costs represent all the information routers need to build
routing repairs tend to act fast, although temporary loops are comprehensive routing tables. Due to the dynamic nature
likely to occur. Routing information is exchanged by means of the link costs, routing tables are adjusted on-the-fly to
of mesh link establishment (MLE) messages. MLE messages compensate for connectivity issues in a comparatively faster
are compressed for efficiency, and they are used not only to way than RPL. Also, when compared to RPL, DV routing fast
propagate link costs between routers but also to establish, reactions can lead to loops and other routing instabilities that
identify, and maintain secure links and to detect neighbors. can affect short term performance.
MLE messages also enable the propagation of network con- Routing relies on a bitmap lookup where the address of a
figuration parameters like the PAN identifier. Note that link REED, FED, or MED parent is determined by looking at the
costs are typically asymmetrical as in most IoT networks, most significant bits (MSB) of the device address. In general,
because the traffic from a device to a router and from the same a sender determines the router associated with the receiver
router to the same device is affected by different impairments and forwards datagrams to the neighbor that provides the
and channel capacities. Since MLE messages operate at lowest-cost path. Again, the cost information between de-
link level, they are sent as link-local unicast and multicast vices and routers is propagated by means of single-hop MLE
frames. Multicasting of MLE messages is carried out by messages. The cost associated with a specific link between
simple flooding in accordance with the multicast protocol two entities is based on the power of the signals originated at
for low-power and lossy Networks (MPL). MPL enables the neighbors. Specifically, the incoming RSSI is mapped to
multicast forwarding in constrained networks while avoiding a link quality index between 0 and 3 where 0 indicates that
the need of maintaining any multicast forwarding topology. the cost is unknown.
MPL introduces two modes of execution. Under proactive If a device or a router receives an MLE message from
mode, MPL data messages are transmitted and triggered by a neighbor, it recomputes its routing table by updating or
a trickle timer without any prior indication that nodes are creating a new entry based on the information carried by the
9.4 Why Not RPL? 217

message. The MLE message contains the cost associated not and multicast addresses needed for them to work. Since
only to the close neighbor but also to all other routers that DHCPv6 is centralized with a server assigning addresses,
are reachable from the neighbor. Unfortunately, the IEEE there is no chance for overlapping and therefore no need
802.15.4 frame payload size limits to 32 the number of for any conflict resolution. SAA, on the other hand and
routers for which link cost information can be included. as indicated in Sect. 4.2, is fully distributed, and it enables
Routing tables are traditional IP routing tables with entries devices to independently configure their own address without
that specify network addresses and the corresponding next any human or nonhuman intervention based on their own
hop information. link layer addresses and the network prefix provided by the
router. By virtue of being distributed, SAA requires DAD for
Example 9.1 What is a valid addressing scheme for contention and conflict resolution.
the end devices of the following Thread network? Leaders keep track of the 16-bit addresses of the bor-
der routes, and they identify the REEDs that are upgraded
to become Thread routers and the Thread routers that are
downgraded to become REEDs. Additionally, leaders rely
on CoAP to assign and manage router addresses. As already
indicated, however, all information stored at the leader is
propagated to other routers so they can automatically become
new leaders if problems prevent the original leader from
working. Note that because devices rely on 6LoWPAN for
IPv6 adaptation, stateful header compression and decompres-
sion are widespread throughout the network.

Solution Each device 16-bit address is given by a

6-bit router identifier and a 10-bit device identifier: 9.4 Why Not RPL?
000011 0000000000 = 0xC00 0xC01 The two design assumptions of RPL, indicated in Sect. 7.3,
000010 0000000000 = 0x800 0x801
are upward-focused routing and data-reactive route update.
0x401 Upward-focused routing implies that most traffic is asym-
3 0xC02
metric and flows from the devices to the border router.
000001 0000000000
= 0x400 2
000100 0000000000 = 0x1000
Sometimes, depending on the transport and session protocols
1 under consideration, traffic can be symmetric. For example,
4 confirmable CoAP relies on the transmission of acknowledg-
0x1000 ments whenever a request is received. Other traffic types,
like actuation, are asymmetric but mostly downward from the
Note that 16-bit addresses are shown as both binary border router to the devices. Moreover, upward reliability of
and hexadecimal numbers. Other schemes are also RPL is at the expense of downward reliability. Specifically,
possible. upon changes of the physical connectivity, downward routes
are comparatively updated much more slowly than upward
routes. Additionally, RPL networks configured with non-
As mentioned before, the six MSBs of the 16-bit address storing nodes are likely to be affected by overhead due to
indicate one of the possible 64 destination routers. Essen- source routing that affects the scaling of downward traffic [6].
tially, these six bits are used for the datagram to traverse the Data-reactive route update implies that, in certain cases,
network from the source to the destination router. Once it data traffic is used to detect connectivity issues. This there-
arrives at the router, the remaining ten least significant bits fore minimizes the need of transmitting routing control mes-
(LSBs) of the address are used to reach the destination device. sages. One issue with this approach, however, is that the
Since the border router interacts with both access and detection takes time as multiple missing datagrams are typi-
core networks, it typically forwards to the leaders the list of cally required to declare lack of connectivity. Of course, these
prefixes the router can provide external connectivity to. The missing datagrams are sacrificed as instruments of routing
prefix, the 6LoWPAN context, the border router address, as signaling.
well as the DHCPv6 server associated with the prefix if it The Thread approach to routing attempts to avoid these
is available. A device can configure a global unicast address problems by relying on two other design goals: energy effi-
relying on the DHCPv6 server or, if supported, can rely on ciency and scalability. Regarding energy efficiency, Thread
SAA to do so. DHCPv6 is used by devices to retrieve network specifies that routers must neither sleep nor exhibit power
218 9 Thread Architecture

cycles. To this end, it defines sleepy end devices that can sleep and other routers. Thus, it complements ND mechanisms. All
but are not allowed to forward messages from other devices. 32 router entries fit in a single control message with each
Regarding scalability, Thread supports up to 32 routers per entry being carried by a single byte. An entry, that includes
network partition. a 2-bit incoming link cost, a 2-bit outgoing link cost, and a
When compared to RPL, a Thread network reduces the 4-bit path cost, is positioned within the payload in a location
number of devices from thousands to a few hundred with that is associated with the address of the node in the network.
routers always powered on. Routers can therefore focus on End devices, by not supporting flat routing, do not broadcast
routing without being affected by energy efficiencies. The advertising messages.
assumption is a home automation scenario where there are Both RPL and Thread routing rely on trickle timers. RPL
enough power outlets to support several routers. More impor- uses the trickle timer for DIO transmissions that enable
tantly, Thread is not just a routing mechanism. It implements repairs and routing integrity. The period of this timer, in
a full stack that has under consideration information from steady state, is in the order of minutes to minimize power
multiple layers. Note that although IEEE 802.15.4, when consumption and extend the network lifetime. Thread routing
enabled with the right power configuration, provides a long- relies on trickle timers to trigger the transmission of ad-
range coverage, Thread coverage is limited to support con- vertising messages. In steady state the transmission interval
nectivity within homes and buildings. is in the order of seconds. This much shorter transmission
IEEE 802.15.4 and 6LoWPAN support mesh connectivity period is possible because Thread routers are not low-power.
by means of mesh-under and route-over approaches. RPL, The network can be fully refreshed by means of these con-
however, is a fully hierarchical routing mechanism where trol messages. Low-power Thread end devices periodically
parent nodes talk to multiple children, thus, not really sup- transmit keepalive messages to verify reachability with their
porting mesh connectivity. Thread routing is based on a full parents.
mesh topology where some nodes have a path cost not just to The link costs under RPL are mostly derived from ETX
the border router but to other nodes in the network. A node estimations obtained by inverting the PDR calculated from
can select the next hop by itself by looking at its routing table. the number of received datagrams. This is not always ac-
RPL routing paths are symmetric so datagrams from the curate, and it can lead to assigning low costs to unreliable
clusterhead to a device traverse the same path but in opposite links. Under RPL routing, the metrics are derived from the
directions that traffic from that device to the clusterhead. This link margin (LKM) that is defined as the difference between
is because downward routes are derived from upward routes the minimum expected power received at the receiver and
by reversing them. Moreover, this can be a problem since for the sensitivity of the receiver. A 20 dB LKM means that the
a given link, the cost in one direction may be different than the receiver can still detect the weakest signal the transmitter
cost in the opposite direction. Thread routing is asymmetric; generates even if it attenuated 20 dB. The higher the LKM
it relies on traditional flat DV techniques, and, therefore, a value, the more reliable the link communication is. Thread
route from the border router to a node may follow a path that routing maps the LKM to a link cost such that if LKM ≥
is different from that of the route from the node to the border 20 dB then the link cost is one, if 10 ≤ LKM < 20 dB, then
router. Thread also exhibits some hierarchical features, as the link cost is two; if 2 ≤ LKM < 10 dB, then the link cost
end devices only interact with a single parent router and all is four; and otherwise the link cost is infinity.
traffic generated or terminated at the device goes through this RPL supports two modes of operation: non-storing and
parent. This model minimizes the computational complexity storing that provide a trade-off between memory overhead
and the usage of memory resources improving the overall and network overhead. Thread routing, by supporting an
energy consumption. Therefore, under Thread there are two approach similar to that of traditional DV routing, uses tables
approaches to routing. Routers are complex devices that are for routers to find paths. This limits the memory use to
always powered on and rely on flat routing to support mesh 32 entries per table. In order to reach an end device, a
connectivity. End devices, on the other hand, are basic low- sender must first reach the device parent router such that
power devices that run on batteries and rely on hierarchical when the datagram arrives, it can be delivered to the device.
routing where any interaction is with a parent router. Specifically, the IEEE 802.15.4 short 16-bit address of each
Thread routers broadcast advertising messages that are end device, as described in Sect. 9.3, is assigned to have
used to update routing metrics in the context of the full mesh. two components: a 6-bit parent router identifier and a 10-bit
The maximum number of 32 routers is intended to limit the end device identifier. The parent router identifier is used to
amount of control traffic sent throughout the network. This determine the path from the source to the router. The device
contrasts with RPL routing where the DIO messages include identifier is used by the parent router to forward the datagram
the path cost to the clusterhead. Thread routing enables a to the right child.
router to determine the cost of paths and links to neighbors
9.5 Thread Stack 219

Since routers are always powered on, the only Thread

entities that are subjected to duty cycles are end devices. As (continued)
opposed to RPL, under Thread routing, there is no need for B B

coordination between leaf nodes and parent routers. Specifi- A A

cally, an end device can sleep, but it is always guaranteed that
its parent is on; therefore no complex coordination is needed.
If the device needs to transmit datagrams, it just wakes up
and sends them. If the parent router needs to send datagrams
down to the device, it queues them up until the device wakes
If device A sends a 100-byte packet to device B, what
up. An end device can proactively ask the parent router to
is the extra latency due to the new routing scenario?
receive any queued datagrams. Specifically, it transmits a
data request and then waits for a short interval of time for
the parent to transmit any pending datagrams.
Solution The per-hop delay is given by
Although RPL supports multiple instances of the routing
Dh = 8×L R
= 3.2 ms because the frame length is
topology associated with different DODAGs, a device can
L = 100 bytes long and the nominal IEEE 802.15.4
only join one of this instances and rely on a single root clus-
transmission rate is R = 250,000 bps. Assuming
terhead that interacts with the Internet. There is, therefore,
the best-case routing scenario, the topology change
a single point of failure in most RPL topologies. On the
introduces two extra hops:
other hand, Thread routing by virtue of supporting full mesh
topologies can rely on multiple simultaneous border routers B B
that communicate with the Internet.
A A

9.5 Thread Stack

One key factor in IoT networks is reliability. Reliability is

critical because it is a response to the well-known limitations This implies an additional latency of 9.6 ms.
of LLNs that affect network loss and latency. Thread has
three levels of reliability: (1) IEEE 802.15.4 natively pro-
Under traditional IEEE 802.15.4, PAN coordinators are
vides, as indicated in Sect. 3.3.3.2, link layer retransmissions
responsible for transmitting beacon frames that enable de-
supported by acknowledged transactions; (2) CoAP provides,
vices to join a network. This way of joining a network is
as indicated in Sect. 5.2.4, session layer retransmissions sup-
device-driven. Essentially devices have a button that when
ported by the CoAP confirmable mode of operation; and
it is pushed, it guarantees that the device securely joins
(3) Thread itself relies on out-of-band communication that
the WPAN. In scenarios with multiple overlapping IEEE
supports sharing information between devices and applica-
802.15.4 PANs, however, this can lead to security breaches.
tions running on smartphones or on the web. This latter
The Thread architecture introduces instead a user-driven
information known as commissioning information is used to
approach for devices to join networks. Specifically, com-
provision devices so that they can securely join a specific
missioning information is used to enable a device to join
network. CoAP, in the context of Thread, is used to provision
and authenticate against the network. Devices, in turn, at
addresses needed by the devices. Moreover, since CoAP is a
joining time can be MEDs, FEDs, or REEDs with the latter
REST protocol, it can be used to get and set data on Thread
able to become Thread routers once they learn the network
routers including diagnostic data.
configuration. Devices receive a 16-bit address with the
MSBs identifying the parent Thread router and the remaining
Example 9.2 Consider the following Thread network LSBs identifying the device itself. When a REED becomes
where DV routing is affected by service disruption of a Thread router, the leader assigns it a router address. The
one of routers as shown below: leader includes a registry of all routers, and therefore it
prevents overlapping router addresses. Thread routers, in
(continued) turn, are responsible for preventing the address overlapping
in children devices.
220 9 Thread Architecture

REED Parent Router

ZCL

ZDP application layer

APS

NWK network and transport layer

IEEE 802.15.4 link layer

IEEE 802.15.4 physical layer

ZCL zigbee cluster library

ZDP zigbee device profile
multicast APS application support layer
NWK network layer
unicast

Fig. 9.7 ZigBee pro stack

Fig. 9.6 REED attaching to a thread network

includes several fields; (1) 16-bit and 64-bit IEEE 802.15.4
addresses of neighboring devices, (2) device capability infor-
Before users can select a device to join a network, the
mation specifying the power duty cycle, (3) parent router link
device itself must discover it. In order to accomplish this,
cost and link costs of all other Thread routers in the network,
devices scan all IEEE 802.15.4 channels and transmit MLE
and (4) security and frame counter information. Note that
discovery requests on each channel. The corresponding MLE
all MLE messages, other than those used to retrieve network
discovery response includes all relevant network parameters
credentials, are encrypted during the joining process.
including the PAN identifier and information needed for
commissioning. The device then performs a DTLS hand-
shake to establish a secure connection with the router using
9.6 Application Layer
as destination the UDP port included in the MLE discovery
response. The router then relays the DTLS traffic from the
The highest layer prescribed by Thread is CoAP that mostly
device to the commissioner. Essentially, device and commis-
provides session layer functionality within the application
sioner exchange tokens to establish trust. The commissioner
layer itself. In the context of IoT IP protocols, application
inspects the device IID and other credentials, and if it is
traffic originated and terminated at devices is not really
satisfied, it provisions the device with the appropriate ser-
standardized as it is transparent to the network and only
vices as well as with the key encryption key (KEK) that is
visible by the applications. Depending on the industry under
used to encrypt other keys. Essentially, a network-wide key
consideration, different proprietary mechanisms are typically
is secured through the KEK and delivered to the joiner. Once
used. This departs from the approach taken by full-stack
authenticated by the commissioner, the router gives the de-
technologies like BLE or ZigBee that rely on predefined
vice network credentials that are used by the device to attach
profiles for devices and applications to exchange data.
to the Thread network. If the device is preconfigured with
Thread follows dotdot that is a universal and standard
the physical channel information and the PAN identifier, then
application language for IoT devices to communicate with
discovery is not needed. Additional security considerations
other devices and entities in LLNs. Dotdot is an evolution,
are included in Sect. 9.7.
in turn, of the ZigBee Cluster Library (ZCL) which provides
Once the device has the network credentials, it can try
a standard mechanism for ZigBee devices to exchange data
to periodically attach to the network by multicasting MLE
by means of clusters [4]. ZCL is just the highest layer of
parent requests to routers and REEDs. REEDs may react
the ZigBee Pro stack as illustrated in Fig. 9.7. The stack
by upgrading to a router role in order to provide routing
also includes within the application layer domain the ZigBee
capabilities to the attaching device. Figure 9.6 illustrates the
Device Profile (ZDP) which provides device discovery ser-
MLE message exchange between a REED attaching itself to
vices through specific commands and the application sup-
a router. In turn, the device and the router use MLE messages
port layer (APS) that provides session layer functionality.
to configure a secure link and provision IPv6 addresses.
Specifically, APS filters out duplicate frames and frames
All devices attach as end devices and can later upgrade by
from non-registered devices or profiles that do not match.
requesting a router identifier from the leader.
APS also supports reliability by means of retransmissions,
Regardless, after a device is attached to the network, it
and it carries several application layer tables that provide
can start exchanging MLE messages with neighbors to up-
bindings between devices. Note that the use of profiles is
date network parameters and link costs. Each MLE message
9.6 Application Layer 221

APS ZCL
FCTL DE DC DP SE SEQ FCTL SEQ CMD
cluster binding
0x2 64 6 0xffff 65 0 0x48 0 1
client server
FCTL frame control
light switch light DE destination endpoint
DC destination cluster
Fig. 9.8 On/off cluster DP destination profile
SE source endpoint
SEQ sequence
quite common with many full-stack M2M and hybrid IoT CMD command
technologies like BLE and ANT+. But profiles force devices
to only interact with those of their own type. Essentially, BLE Fig. 9.9 ZCL message
devices and applications only interact with BLE devices and
applications, ANT+ devices and applications only interact
with ANT+ devices and applications, and, of course, ZigBee The idea with ZCL over IP is to map ZCL binary messages
devices and applications only interact with ZigBee devices as close as possible when encoded over CoAP. For example,
and applications. Fig. 9.9 shows a ZCL message, encapsulated over APS, that
Under ZCL, each cluster defines a communication inter- is transmitted from the light switch to the light of Fig. 9.8. The
face that specifies a collection of commands and attributes. message specifies that it is intended for destination endpoint,
Devices implement client and server sides of each cluster. destination cluster, and command 64, 6, and 1 respectively.
Cluster commands typically expose actions of devices, while As per ZCL specifications, cluster identifier 6 is associated
cluster attributes usually expose the state of devices. Clusters with the on/off cluster, while command 1 is associated with
are objects with attributes that follow flat structure that is the on command. Note that the message has no payload.
indexed by identifiers. ZCL defines clusters intended for Under ZCL over IP this message is translated as a CoAP
applications ranging from temperature sensing to dehumid- POST request to URI /zcl/e/64/s6/c/1 where /zcl specifies
ification control. ZCL is not RESTful by design as it relies ZCL protocol, /e/64 indicates the endpoint, s6 indicates the
on numerous different general commands and manufacturer- cluster identifier, and c/1 specifies the command. The POST
specific commands per cluster. Because of the ZigBee LLN request includes no body as the ZCL message has no payload.
origin, ZCL messages are quite small and optimized to fit ZCL service discovery is carried out by ZDP, while ZCL over
in a single IEEE 802.15.4 frame such that the unnecessary IP service discovery is carried out by IETF RFC 6690 Core
transmission of messages between devices is minimized. Link Format described in Sect. 6.4.1.
Figure 9.8 shows an example of the ZCL on/off cluster In general, ZCL commands are accessible through REST
with a light switch client transmitting an on command to a CoAP requests: GET, PUT, POST, and DELETE. ZCL re-
light server. sponses are returned as CoAP responses, typically as 2.05
The evolution of ZCL from ZigBee to generic IoT IP Content for success or as 4.05 Method Not Allowed to
network stacks defines the aforementioned dotdot application indicate errors. URIs specify a combination of resources
language for device communication. This is analogous to the that are indicated by /e for endpoints, /a for attributes, /c
situation of the link layer of ZigBee that was ported to other for commands, /b for bindings, /r for configurations, /n for
network stacks as IEEE 802.15.4. notifications, and /g for group notifications.
With Thread, dotdot requires access control by means Service discovery is invoked by means of the /.well-
of Authentication and Authorization for Constrained Envi- known/core URI. Figure 9.10 illustrates an example, where
ronments (ACE) that allows the provisioning application to an application attempts to discover endpoints implementing
specify the resources that are available each device. the on/off cluster by transmitting a multicast GET CoAP
Dotdot in the context of Thread is based on ZCL over IP request to /.well-known/core?rt=urn:zcl:c:6.c where the
that exploits CoAP for both session management, service dis- resource type attribute rt specifies ZCL for cluster identifier
covery, and RESTful access. It encodes ZCL payloads with 6. The unicast response is a 2.05 Content response that
Concise Binary Object Representation (CBOR) standardized carries the link format associated with the endpoint
as IETF RFC 7049. CBOR introduces a data format that coap://[2001::21:5]/zcl/e/64/c6>;rt=urn: zcl:c:6.c. Of
provides small message size and extensibility without the course, Thread does not rely on standardized mDNS and
need to version negotiation. DNS-SD for service discovery as CoAP is probably a better
fit to map ZCL interactions.
222 9 Thread Architecture

BR
BR border router

application light

IP

Fig. 9.11 Border router starting network

Fig. 9.10 Service discovery

The candidate then connects by means of DTLS to the
border router establishing a commissioning session that is
authenticated by means of a pre-shared key for the Commis-
9.7 Security Considerations
sioner (PSKc). Next, the candidate registers with the border
router that is simultaneously accepted by the leader as point
Security is a main concern with Thread. As most IoT archi-
of contact to the commissioner. The router then sends a
tectures, Thread security is provided at many different lay-
confirmation message to the candidate that now becomes a
ers. Specifically, as almost all link layer LLN technologies,
commissioner.
IEEE 802.15.4 has built-in security mechanisms, described
The commissioner is responsible for joining devices to
in Sect. 3.3.3.2, that enable hop-by-hop security. At the same
the Thread network. Devices that are no part of the network
time, application layer security by means of DTLS enforces
are called joiners. The joiner creates a DTLS connection to
security that complies with the end-end principle.
the commissioner in order to receive commissioning material
Thread IEEE 802.15.4 security provides encryption and 4-
that is used to join the network as described in Sect. 9.5.
byte MIC authentication that are supported by a configuration
that is based on a common key that is distributed to all devices
in the network. One problem with this approach is that any
9.8 Thread Network Formation
security breach of a single device can lead to a network-
wide security compromise. Additionally, and although IEEE
A Thread network can be started by a border router that ini-
802.15.4 does provide some basic replay protection, Thread
tially performs many of the functions typically carried out by
includes counters in its MLE messages in order to bring
other devices in the network. Specifically, the border router
additional replay protection.
connects to the public Internet over Wi-Fi (IEEE 802.11) or
As indicated in Sect. 4.4, IEEE 802.15.4 can be the target
Ethernet (IEEE 802.3) and also takes over providing Thread
of attacks due to the universal and static nature of the IIDs.
leader functionality [10].
Specifically, if the IID, that is vendor-dependent, becomes
This scenario is representative of the topology shown in
known, devices can be compromised. Moreover, in the con-
Fig. 9.11 where the network is made of a single device that
text of IEEE 802.15.4 and 6LoWPAN, IIDs are used to derive
connects to the Internet. The border router, BR, also acts as
IPv6 global addresses through SAA. Thread departs from this
a server for the delegation to network devices of a global
approach by allowing devices to use addresses that are either
routable IPv6 prefix and as internal commissioner that can
associated with the 16-bit node identifier or random.
be used to enable other devices to attach to the network.
DTLS is also used for security between commissioners
This is illustrated in Fig. 9.12 where the border router
and border routers over, for example, Wi-Fi. In this case,
through a user interface starts a commissioning session with
once a DTLS connection is established, a passphrase is used
a joining router R. Router and border router now talk to each
to validate the application against the border router. Once
other through their corresponding WPAN IEEE 802.15.4
the application is validated, it can add new devices to the
interfaces. After the router joins the Thread network, it starts
network. This mechanism is part of the mesh commission-
receiving multicast MLEs from the border router that acts as
ing protocol (MeshCoP) that rules how devices securely
a Thread leader. The border router provides DHCPv6 server
authenticate and join the network. The process starts when
functionality, allowing the router to negotiate a globally
a commissioner candidate, that is an application running on
scoped address in order to interact with other nodes in the
a smartphone or tablet, discovers a Thread network being
Internet.
advertised by its border router. The discovery mechanism
Later, as shown in Fig. 9.13, a IEEE 802.11 (Wi-Fi)-
enables the candidate to learn about the network name and
based commissioning application, running on a smartphone,
the connectivity parameters needed to contact the router.
physically connects to the exterior interface of the border
9.9 OpenThread 223

R R R2
BR border router BR border router
R router R router
R2 another router
BR
BR

IP
IP

Fig. 9.12 Border router as internal commissioner

R
BR border router Fig. 9.14 New router joins network
R router

R R2
BR
BR border router
R router (leader)
R2 another router
BR
IP

IP

Fig. 9.13 External commissioner

router. Since the border router plays the role of Thread Fig. 9.15 Border router unavailable
leader, a commissioning session is established between the
commissioner and the border router.
The commissioner, then, enables another router R2 to route information. Now, router R advertises network data that
join the Thread network. This is illustrated in Fig. 9.14. A includes external routing information.
DTLS connection is established between this new router and Finally, a new border router BR2 joins the Thread network
the border router that, in turns, relays the handshake to the as illustrated in Fig. 9.17. This new border router communi-
commissioner. The border router then securely distributes cates with the leader by means of TMF traffic to inform it has
network parameters to R2 , which, in turns, uses DHCPv6 to taken over the role of DHCPv6 server.
get a globally scoped address.
If the border router is powered off, then another router in
the Thread network typically takes over the role of leader. 9.9 OpenThread
As shown in Fig. 9.15, router R becomes the new leader
and it starts advertising network data that no longer includes As opposed to many other IoT architectures, Thread is avail-
external routing information. able as a complete open-source implementation developed
Later, when the border router is back in service as shown by Google/Nest called OpenThread initially released in May
in Fig. 9.16, it acknowledges router R as Thread leader. 2016 [5]. The goal of OpenThread is to enable faster de-
The border router uses TMF traffic to forward its external ployments of Thread and to encourage chip manufacturers to
standardize devices as a mechanism to bring better, cheaper,
and more secure devices to end consumers [7].
224 9 Thread Architecture

OpenThread includes all stack layers and supports two

R R2 modes of operation: as an event-driver kernel that can run
BR border router in a bare-metal system or on top of an embedded operating
R router (leader) system. Additionally, it runs on hardware with radios that
R2 another router enable Thread physical support and simultaneously imple-
BR ments all architecture layers including (1) IEEE 802.15.4
with security, (2) 6LoWPAN, (3) MLE and associated RIPng-
based routing, (4) security key management, (5) specific
device roles in Thread, (6) DTLS, and (7) CoAP. Physical
differences between hardware platforms are supported by a
IP
hardware abstraction layer (HAL) that makes OpenThread
highly portable.
The framework includes several separate functional units.
Specifically, it provides a networking module that imple-
ments IPv6, MPL, and ICMPv6. It also includes a routing
Fig. 9.16 Border router available again
module that implements MLE to forward routing information
and RIPng to maintain routing tables. OpenThread has addi-
tional modules that provide all the functions associated with
R R2 DTLS as well as CoAP management. In regard to this latter
BR border router functionality, although CoAP is used for control messaging,
BR2 another border router OpenThread also exposes APIs to provide REST functional-
R router ity on Thread-specific UDP port 61631 to take advantage of
BR BR2 R2 another router 6LoWPAN compression described in Sect. 4.3.4.2.

Summary
IP Thread is a WPAN technology that provides a full stack
primarily intended for IoT home automation that can also
be used in the context of other industries ranging from asset
monitoring to IIoT. The chapter started by introducing the
main characteristics of Thread and how Thread compares to
IETF IoT stacks. Details of the Thread topologies and DV
Fig. 9.17 New border router joins network
routing were then explored. Specifically, DV routing was
compared against RPL in order to explain why it is the best
 OpenThread RTOS Device Support There are several alternative for the Thread architecture. The chapter continued
implementations of OpenThread intended for RTOS- to explain the Thread stack, its application layer including
based devices. The list below details some of these resource discovery, and other security considerations. The
implementations. chapter ended by describing the network formation and de-
tails of OpenThread.

Enabled constrained devices from integrat-

OT RTOS ing with Thread networks
Homework Problems and Questions
Integrates OpenThread over well-known
FreeRTOS
Relies on lwIP for networking and on MBed 9.1 What is a problem of Thread is routers were constrained
TLS for TLS devices?
LGPLv2 licensed open-source C implemen-
RIOT Open Thread
tation 9.2 Consider Fig. 9.6 and assume an average transmission
Implemented as part of the RIOT RTOS rate and packet size of 120 Kbps and 56 bytes, respectively.
Apache 2.0 licensed open-source C imple- If no delays other than the transmission delay, how long does
Zephyr Open Thread
mentation
it take for a REED to attach to a Thread Network?
Implemented as part of the Zephyr RTOS
References 225

9.3 Why do you think ZCL messages are mapped as CoAP 6. Kim, H.S., Kumar, S., Culler, D.: Thread/openthread: A compro-
messages under Thread? mise in low-power wireless multihop network architecture for the
internet of things. IEEE Commun. Mag. 57, 55–61 (2019)
7. Marksteiner, S., Exposito Jimenez, V.J., Valiant, H., Zeiner, H.:
9.4 At least theoretically, how many end devices can a single An overview of wireless IoT protocol security in the smart home
Thread router support? domain. In: 2017 Internet of Things Business Models, Users, and
Networks, pp. 1–8 (2017)
8. Montenegro, G., Schumacher, C., Kushalnagar, N.: IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs):
References Overview, Assumptions, Problem Statement, and Goals. RFC 4919
(2007). https://doi.org/10.17487/RFC4919. https://rfc-editor.org/
1. IEEE Standard for Local and Metropolitan Area Networks–Part rfc/rfc4919.txt
15.4: Low-Rate Wireless Personal Area Networks (lR-WPANS) 9. Rescorla, E., Modadugu, N.: Datagram Transport Layer Security
amendment 1: Mac sublayer. IEEE Std 802.15.4e-2012 (Amend- Version 1.2. RFC 6347 (2012). https://doi.org/10.17487/RFC6347.
ment to IEEE Std 802.15.4-2011) pp. 1–225 (2012) https://rfc-editor.org/rfc/rfc6347.txt
2. IEEE Standard for Low-Rate Wireless Networks. IEEE Std 10. ThreadGroup: Thread border routers (2015). https:https://
802.15.4-2020 (Revision of IEEE Std 802.15.4-2015) pp. 1–800 openthread.io/
(2020) 11. ThreadGroup: Thread commisioning (2015). https:https://
3. Alexander, R., Brandt, A., Vasseur, J., Hui, J., Pister, K., Thu- openthread.io/
bert, P., Levis, P., Struik, R., Kelsey, R., Winter, T.: RPL: IPv6 12. ThreadGroup: Thread 1.2 base features (2019). https://openthread.
Routing Protocol for Low-Power and Lossy Networks. RFC 6550 io/
(2012). https://doi.org/10.17487/RFC6550. https://rfc-editor.org/ 13. ThreadGroup: Thread network fundamentals (2020). https://
rfc/rfc6550.txt openthread.io/
4. Alliance, T.Z.: Zigbee cluster library specification (2019). https:// 14. Unwala, I., Taqvi, Z., Lu, J.: IoT protocols: Z-wave and thread. In:
zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06- 2018 IEEE Green Technologies Conference (GreenTech). IEEE,
zigbee-cluster-library-specification.pdf Piscataway (2018)
5. Google/Nest: Openthread (2020). https://openthread.io/
 Glossary

6Lo IPv6 over networks of resource-constrained nodes Authentication It dictates that only trusted sources can
refers to the native IPv6 support of constrained IoT transmit data.
devices. Autonomous cells Under 6TiSCH it provides proactive cell
6LoWPAN IPv6 over low-power wireless personal area net- scheduling without any type of negotiation.
works is a mechanism that enables IPv6 over several Backbone Same as core.
constrained IoT link layer technologies. Beamforming It is a signal processing technique to support
Access It is the portion of the network between the devices directional signal manipulation with the goal of minimiz-
and the gateway. ing interference.
Access point (AP) Under IEEE 802.11, it plays the role of BLE Bluetooth Low Energy is a physical and link layer
IoT gateway. technology for transmission of data over wireless chan-
ad hoc A mode of operation of a single BSS. nels. BLE is also known as Bluetooth Smart.
ACK Acknowledgment. Block code It is a mechanism where a payload is partitioned
Active scanning Under IEEE 802.11, a device sends a into chunks of data called messages, and each message,
probe frame indicating the SSID of the BSS it wants to be when controlled redundancy is added, becomes a code-
associated with. word that is used for error control.
Active sensor It is a sensor that emits sounds or generates Bundle Under TSCH, it is a scheme where multiple cells
electromagnetic waves that can be detected by means of carry traffic between two devices.
external observation. Bus A type of network topology.
Actuator It is a logical device that perform some external CBOR The Concise Binary Object Representation intro-
change of an asset of the physical environment. duces a data format that provides small message size and
ADC Analog-to-digital converter. extensibility.
Aggregation It implies that readouts from different sensors Cell Under TSCH, it is the combination of the timeslot and
are collected by a sensor closer to the gateway or cluster- channel.
head. Channel It is the medium that enables the propagation of
ALOHA It is a MAC mechanism that enables devices to signals between devices and applications.
send datagrams without having to wait for the channel to Channel bonding It consists of transmitting frames of the
be free. same physical device over multiple nonoverlapping sub-
AMQP The advanced message queuing protocol is a session channels.
layer protocol, similar to MQTT, that was initially de- Channel capacity theorem It states that the maximum
signed for enterprise applications like financial businesses achievable transmission rate of a communication system
but due to its simplicity and small footprint has become an is a direct function of SNR.
integral part of many IoT solutions. Channel coding It is an optional mechanism that embeds
Application layer Layer that involves application specific FEC information in headers.
services as well as the conversion of information between Channel decoder A communication system component
the digital and analog domain. that removes controlled redundancy to improve reliability
Asset An asset is an element of the environment that an IoT against channel impairments.
device interacts with. Channel encoder A communication system component
At least once One of the reliability modes supported by that adds controlled redundancy to improve reliability
AMQP and MQTT. against channel impairments.
At most once One of the reliability modes supported by Cloud computing Application processing performed at the
AMQP and MQTT. network cloud.

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 227
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5
228 Glossary

Cluster A group of devices that interact with a gateway for DECT ULE Digital Enhanced Cordless Telecommunica-
core side communication. tions Ultra Low Energy is a physical and link layer tech-
Clusterhead A gateway associated with a cluster. nology for transmission of data over wireless channels.
CoAP The Constrained Application Protocol is a lightweight Device A device is a sensor, a controller, or an actuator
and highly efficient protocol that enables the management running on small constrained embedded computer.
of IoT sessions. Demodulator A communication system component that re-
CoAP resource discovery It is a distributed mechanism for verses the signal transformation introduced by the modu-
CoAP service discovery. lator.
CoAP resource directory It is a centralized mechanism for Detectability It indicates the probability that a given net-
CoAP service discovery. work section is able to detect a specific asset or physical
Code rate It is defined as the ratio k/n where n is the total phenomenon.
number of transmitted packets (redundant and original) Differential signaling It consists of transmitting data by
and k is the number of original packets. means of two complementary electrical signals that, when
Cognitive radio It is used to dynamically select the portions subtracted at the receiver, minimize noise.
of the spectrum that minimize interference. Directed diffusion It is a flat data-centric routing mecha-
Complex device It is a usually a gateway. nism that relies on response aggregation to accomplish
Confidentiality It implies that information must be power consumption efficiency.
encrypted to make sure that it is inaccessible to Dispatch value Under 6LoWPAN, it is used as datagram
unauthorized users. type indicator.
Confirmable mode A CoAP transmission mode that com- Distribution services Under IEEE 802.11, they deal with
pensates the inherent lack of reliability of UDP transport. station services that span beyond communication between
Continuous A type of DNS query that is made by fully devices in a given BSS.
compliant mDNS queriers and responders in order to Distribution system Under IEEE 802.11, it provides the
support asynchronous operations like IoT load balancing. backbone for connectivity to applications performing an-
Controller It is a logical device that performs some internal alytics.
change in the physical device to assist sensing or actua- DNS Domain name system is a well-established IP suite
tion. protocol that is mainly used for address resolution.
Convolutional code It is similar to a block code, but it DODAG A destination-oriented directed acyclic graph is a
operates on continuous streams of bits instead of on blocks graph used under RPL that enables devices to keep track
of bits. of the routing topology.
Cookie It is an add-on mechanism that can be used to DTLS Datagram Transport Layer Security is the preferred
introduce a state in the interaction between clients and security mechanism in the context of 6LoWPAN and other
servers. IoT technologies.
Core It is the portion of the network between the gateway DV Distance vector routing consists of devices sending their
and the application. entire routing tables to their connected neighbors.
CPS A cyber-physical system represents the interaction be- Downlink Direction from application to device.
tween a device and an asset. Duty cycle It refers to devices that sleep in order to reduce
CSMA/CA Carrier sense multiple access with collision power consumption at preprogrammed intervals.
avoidance is a MAC mechanism. Endpoint It is a network component also known as host that
CSMA/CD Carrier sense multiple access with collision de- serves as the source or destination of messages.
tection is a MAC mechanism. End-to-end principle It states that, whenever possible, cer-
D7AP The DASH7 Alliance Protocol is an open source tain functions like security must be deployed on an end-
protocol stack that enables LPWAN communications. to-end basis typically at the application layer.
DAC Digital-to-analog converter. Ethernet It is a physical and link layer technology for
Data-centric routing It involves clients sending queries to transmission of data over wireline channels.
a specific network regions in order to retrieve a specific Exactly once One of the reliability modes supported by
readouts and data associated with specific capabilities. AMQP and MQTT.
Data mining Knowledge extraction mechanism. Exposed station It results from station C transmitting to
Data-information conversion Stage intended to lower station D and preventing station B to transmit to station
throughput in order to optimize channel utilization and A.
lower power consumption to extend battery life. FEC Forward error correction is a mechanism that helps
Datagram Name of a packet that is processed by a network detecting and correcting errors due to channel distortion.
layer.
Glossary 229

Flat architecture It is an architecture where all functions IEEE 802.15.4k It is a standard for low energy, critical
are performed by a single layer. infrastructure monitoring applications that relies on the
Flat routing It relies on devices interacting with each other 2.4 GHz, the 915/868 MHz, and the 433 MHz ISM bands
without a single device acting as parent that concentrates for transmission.
and aggregates traffic of children devices. IEEE 802.15.4g It is a new standard that targets smart me-
Flooding It is a routing mechanism that is based on devices tering applications like gas metering.
forwarding received datagrams through all possible neigh- IIoT Industrial Internet of Things is a term associated with
bors. IoT in the context of industrial applications.
Flow label IPv6 field that identifies the datagram as part of Industry 4.0 See IIoT.
a flow of datagrams. Information-knowledge conversion Stage where informa-
Fog computing Application processing performed at a tion is processed by the application to generate knowl-
gateway. edge.
Forwarding It involves moving a datagram from an incom- Infrastructure A mode of operation of a single BSS.
ing to an outgoing link in a device or router. Integrity It implies that the received messages are not al-
Frame Name of a packet that is processed by a link layer. tered in transit.
Framing It is a generic technique that consists of adding IoT Internet of Things is a term used to describe tech-
fields and special synchronization markers to data propa- nologies, protocols, and design principles associated with
gated down from upper layers. Internet-connected things that are based on the physical
G3-PLC PLC standard. environment.
Gateway It is a logical device that serves as an interface be- IP Internet Protocol. It is a network layer protocol and
tween access side IoT devices and core side applications. fundamental building block for IoT communication.
Gossiping It is an alternative to flooding that relies on IPSec/IKE IP security/Internet Key Exchange are IP-based
intermediate devices forwarding a received datagram to security mechanisms.
a single randomly selected neighbor. IQRF It is an open LPWAN framework that includes de-
Hidden station It results from stations A and C transmitting vices, gateways, and applications addressing scenarios
simultaneously to station B and not detecting each other ranging from telemetry and industrial control to home and
since they are out of range. building automation.
Hierarchical routing It groups devices in clusters with ISM Instrument, scientific, and medical bands are unli-
clusterheads that acting as parent devices concentrate and censed spectral bands used in many IoT wireless solutions.
aggregate traffic of children devices. ITU-T G.9903 PLC standard.
HIP Host Identity Protocol is an IP-based security mecha- ITU-T G.9959 It is a physical and link layer technology for
nism. transmission of data over wireless channels.
HOL Head-of-line blocking occurs when the processing of ITU-T H.265 Video codec.
a request prevents other responses from being transmitted. JTAG Joint Test Action Group standardized as IEEE
Hop limit IPv6 field that provides a counter that is decre- 1149.1. It is used to perform a boundary-scan of an
mented as the datagram is forwarded throughout the net- integrated circuit to enable circuit testing
work. Known answer suppression It is a mechanism by which
HTTP The HyperText Transfer Protocol is an application known answers are suppressed by not being transmitted.
protocol that enables the management of IoT sessions. Layered architecture A communication architecture that
Specifically, it provides session layer management of web segments functionality into different layers.
applications including client and server support. LDPC Low-density parity-check. Block code.
Hyperspectral image Images made of data cubes that in- LEACH Low-energy adaptive clustering hierarchy is a hier-
clude a few dozens of spectral bands. archical routing mechanism that by means of aggregation,
IEEE 1901.2 PLC standard. it transmits device data to an application that acts as a sink.
IEEE 802.2 LLC protocol that is transported on top of Line code It is used to modulate digital bits of a link layer
standard IEEE 802.3. frame into an electrical signal that can be transmitted over
IEEE 802.3 Ethernet standard. the channel.
IEEE 802.11 It is a physical and link layer technology for Linear regression Knowledge extraction mechanism.
transmission of data over wireless channels. Link Network component that connects endpoints and
IEEE 802.11ah An IEEE 802.11 developed for generic IoT routers.
support. Link layer Layer that provides error control mechanisms
IEEE 802.15.4 It is a physical and link layer technology for for reliable transmission of information over the channel.
transmission of data over wireless channels.
230 Glossary

LLN Low-power and lossy network typically associated Modulator A communication system component that trans-
with IoT. forms a signal for efficient transmission over the channel.
LOADng Lightweight On-demand Ad hoc Distance Vector MQTT Message Queue Telemetry Transport is a protocol
Next Generation is a technology that provides reactive flat that enables the management of IoT sessions.
routing in LLNs. MS/TP Master-Slave/Token-Passing is a physical and link
LoRa Long range is the generic name for a full protocol layer technology for transmission of data over wireline
stack that provides LPWAN capabilities that enables de- channels.
vices to run on a single battery for more than 10 years. Multipath It is a scenario that usually results in signal
LoRaWAN It is the LoRa networking mechanism that en- fading that causes network packet loss.
ables devices to access the channel. Nagle’s algorithm It is a mechanism by which TCP na-
Location-based routing It consists of a client or device tively buffers packet payloads until it has enough data to
transmitting datagrams to another client or device by for- make it efficient to send a datagram.
warding the traffic based on the geographical or physical NB-Fi Narrowband fidelity is an open full-stack protocol
location of the destination. that is the base of a commercial LPWAN turn-key solution
Logical devices Software-based devices than run on physi- that includes devices and networks.
cal devices. NB-IoT Narrowband IoT is an LPWAN technology based
LPWAN A low-power wide-area network is an IoT network on cellular communications and first introduced in the
associated with very low transmission rates (up to 50 3GPP Release 13.
Kbps) over long distances (in the order of kilometers) ND Neighbor discovery provides communication with hosts
LS Link state routing consists of devices sending the state and routers to enable connectivity beyond the local link.
of their links to all the devices in the network. Neighbor discovery attack It is an attack where neighbor
LTE-M Standardized together with NB-IoT as part of the discovery messages typically used in the context of
3GPP Release 13, LTE-M, also known as LTE Cat M1 is a WPANs are either dropped or corrupted in order to induce
simplified version of 4G LTE that attempts to provide IoT reachability issues.
support by reducing power consumption while extending Network layer Layer that ensures that information packets
signal coverage. are delivered to the destination.
M2M Machine-to-machine communication refers to mech- Next header IPv6 field that specifies the protocol under
anisms that enable simple interaction between devices and which the payload is encoded.
applications. In most cases, these mechanisms are neither NFC Near-Field Communications is a physical and link
standardized nor Internet-based. layer technology for transmission of data over wireless
MAC Media access control is a set of rules that determine channels.
how frames are received and transmitted over the physical Node coverage It presents the level of device redundancy
channel. available to capture data if a sensor failure occurs.
Machine learning Knowledge extraction mechanism. Non-beacon mode It is an IEEE 802.15.4 mode of trans-
MANET Mobile ad hoc network. mission when they are infrequent enough that contention
Master-slave A type of network topology. based access results in a lack of collisions.
mDNS Multicast DNS provides an alternative to traditional Non-confirmable mode A CoAP transmission mode that is
DNS by addressing some of the limitations of the latter in based on a fire-and-forget approach where messages are
the context of IoT. sent without expecting any acknowledgment.
Mesh-under It is forwarding that occurs in the 6LoWPAN Non persistent An HTTP session that relies on a single TCP
layer. connection for each transaction.
Media It refers to the transmission of the audio, speech, Non-storing node It is a node where a device does not store
video, and images. prefix information from all its children
Message Name of a packet that is processed by an applica- Nwave It is a commercial LPWAN solution intended mobile
tion layer. devices associated with smart parking.
MIMO multiple input-multiple output is a type of multi- Observation It is a feature associated with REST that en-
antenna. ables an observed device to transmit readouts whenever
Mission planner Application that resides at a ground sta- parameter changes are detected.
tion and calculates flight paths of UAVs. OFDM Orthogonal frequency division multiplexing is
Mist computing Application processing performed at a de- mechanism that enables the modulation of binary streams
vice. in communication channels.
Modulator A communication system component that trans- On-shot A type of query that is typically associated with
forms a signal for efficient transmission over the channel. legacy DNS queriers and responders.
Glossary 231

OPC UA The Open Platform Communications United Ar- Reactive routing It relies on dynamic on-demand building
chitecture provides a protocol stack that complies with the of routes from sources to specific destinations by relying
request/response paradigm. on route discovery queries that flood the network.
Packet A basic unit of data transmitted in packet switched Reliable delivery It is an optional mechanism that provides
networks. the infrastructure to signal and support retransmissions.
Packet bursting It consists in buffering a number frames Request/response This model bases its interaction between
before transmitting them all together in order to lower application and device by means of requests and
average channel contention delay. responses.
Packetization To chunk a media stream into several pack- Responder Also known as DNS server or answerer, it re-
ets. sponds to queries.
PAN coordinator In the context of IEEE 802.15.4 and other REST It is an architecture that formalizes a series of require-
technologies, it is the device that plays the role of gateway. ments and interfaces that are necessary for client/server
Passive scanning Under IEEE 802.11, it consists of devices interaction.
sequentially listening for beacon frames transmitted by Route-over It is routing that occurs above the 6LoWPAN
other devices over channels. layer.
Passive sensor It is a sensor that is not active. Router It is a network component that assists in the propa-
PEGASIS Power-Efficient Gathering in Sensor Informa- gation of messages throughout the network.
tion Systems is a hierarchical routing mechanism that Routing It involves determining a route or path that data-
relies on data aggregation. grams must follow from source to destination.
Persistent An HTTP session that relies on a single TCP Routing information spoofing It is an attack where the in-
connection for all transactions. truder spoofs, alters, or replays routing information in
Physical layer Layer that is dedicated to the transmission order to create loops that lead to datagram loss.
and reception of data over the channel including the con- RPL Routing for low power is a hierarchical and IPv6
version of information between the digital and the analog address centric routing protocol.
domains. RPMA is a media access scheme that serves as the base of
Physical devices Hardware-based devices. a robust LPWAN technology.
Piconet A type of network topology. RTCP Real-time control protocol is used to provide quality
PID A proportional integral derivative is a control loop control over media streams.
mechanism that relies on feedback. RTP Real-time protocol is the preferred standard for the
PLC Power line communication is a physical and link layer transmission of media. RTP sessions are typically estab-
technology for transmission of data over wireless chan- lished by means of SIP.
nels. SCADA Supervisory control and data acquisition is an in-
Presentation layer Layer that provides formatting of infor- dustrial control system architecture.
mation for further processing including security exten- Scatternet A type of network topology.
sions for encryption and decryption. Schedule Under TSCH, a schedule specifies what devices
Proactive routing It consists of building routing tables that communicate with each other.
ultimately define forwarding behavior by means of the SD-DNS It is a standard that it is used with mDNS to provide
periodic transmission of routing information across all service discovery.
nodes in the network. Scrambler A mechanism that randomizes in a controlled
Proxy server It is a device that sits between client applica- fashion the sequence of transmitted bits.
tions and sensors and devices acting as servers in order to Segment Name of a packet that is processed by a transport
respond to client requests on behalf of these servers. layer.
Publish/subscribe A model that relies on a broker that Sensor It is a logical device that interacts with the environ-
queues and delivers messages between an application and ment by sampling and generating readouts.
a device. Selective forwarding It is an attack where an affected de-
Qowisio It is a UNB turn-key commercial LPWAN solution vice only forwards certain datagrams in order to cause
supporting a wide range of applications ranging from connectivity problems.
asset tracking and management to lighting and power SigFox It is an LPWAN protocol stack that relies on an
monitoring. unique commercial network called SigFox.
Querier Also known as resolver or questioner transmits a Signaling It refers to the exchange of information between
query that is answered by the mDNS server. entities in order to establish a session.
Simple device It is a basic sensor, actuator, or controller.
232 Glossary

Sinkhole attack It is an attack where an affected device SNOW Sensor network over white spaces is an experimen-
attempts to become the destination of all traffic in a certain tal LPWAN technology that relies on transmission over
location. white space spectrum with modulation over unoccupied
SIP The Session Initiation Protocol provides a mechanism frequency guard bands between TV channels typically
to create, manage, and finish sessions. between 547 and 553 MHz.
Slotframes Under TSCH, timeslots are grouped into slot- Star A type of network topology.
frames that are periodically transmitted. Synchro It is a variable coupling transformer where the
Source decoder A communication system component that magnitude of the magnetic coupling between the primary
performs, among other things, digital to analog conver- and secondary varies in accordance to the position of a
sions. rotable element.
Source encoder A communication system component that Telensa It is a fully proprietary LPWAN technology that
performs, among other things, analog to digital conver- focuses mainly on smart city applications with emphasis
sions. on smart lighting and smart parking as it does not support
SPIN Sensor protocols for information via negotiation is indoor communications.
a flat data-centric routing mechanism that through data Thread It is a protocol stack, an architecture and a frame-
negotiation and resource adaptation enables devices to work that support IoT home automation.
forward datagrams from a source to a sink in a much more Traffic class IPv6 field that provides QoS information.
controlled and more energy efficient way than flooding Transmission rate Rate at which an application generates
and gossiping. rate. Measured in units of bps.
Spreading factor In SS, spreading factor or processing gain Transport layer Layer that provides support of multiplex-
is the ratio between the symbol width and the chip width. ing of traffic from different applications.
SS Spread spectrum is mechanism that enables the modula- Turbo code Block code.
tion of binary streams in communication channels. Uplink Direction from device to application.
Stateful compression It relies on associating redundant in- UPnP The Universal Plug and Play architecture provides a
formation in uncompressed IPv6 headers with a context framework for the discovery of network elements rang-
identifier that is transmitted in the datagrams instead. ing from computers and printers to gateways and access
Stateless compression It is a compression mechanism that points.
is simple, and, as opposed to stateful compression, it does Weightless It is an LPWAN protocol stack that relies on
not require to keep track of the state of inter-datagram transmissions over the white space spectrum.
redundancy. Wormhole attack It is an attack where the attacker captures
Station Under IEEE 802.11, it plays the role of IoT access datagrams in one location and retransmits them in another
device. leading to routing and connectivity problems.
Station services Under IEEE 802.11, they deal with authen- WPAN A wireless personal area network is an IoT network
tication and privacy between devices. that comparatively provides higher transmission rates (in
Storing node It is node where a device stores prefix infor- the order of Mbps) but supports shorter distances (in the
mation from all its children. order of hundreds of meters).
SWD Serial Wire Debug is used to perform a boundary-scan WSN Wireless sensor network a term that designates a
of an integrated circuit to enable circuit testing system of very large number of wireless sensors that
Sybil attack It is an attack where a single device assumes interact with an application that monitors events and other
multiple identities in order to become a destination of phenomena occurring in the physical environment.
many other nodes in the network. WSN category 1 A type of network topology that includes a
Reed-Solomon Block code. very large and highly dense deployment of devices. Trans-
REST Representational state transfer is an architecture mission is multi-hop with communication from devices
where transactions are destined to optimize the interaction to gateways relying on intermediate sensors and actuators
of the entities involved in the communication. forwarding and aggregating packets.
Ring A type of network topology. WSN category 2 A type of network topology that is very
RS-232 Recommended Standard 232 defines signals con- simple and includes fewer devices that directly connect to
necting terminals and other equipment. a single gateway.
RS-485 Recommended Standard 232 defines signals con- XMPP The eXtensible Messaging and Presence Protocol
necting terminals and other equipment. is an application layer protocol that loosely follows the
Session layer Layer that is in charge of managing multiple REST paradigm.
sessions between applications.
Glossary 233

Zero-configuration Mechanism where network deploy- ZDP The ZigBee Device Profile provides device discovery
ment and provisioning are carried out without human services through specific commands.
intervention. ZigBee Protocol stack with IEEE 802.15.4-based physical
ZCL The ZigBee Cluster Library is a standard mechanism and link layers.
for ZigBee devices to exchange data.
 Index

Symbols ACK_TIMEOUT, 128

1024-QAM, 55 acknowledgment, 37, 48, 64, 125
16-QAM, 47, 49, 53, 202 ACL, 66
2.05 Content, 11 active, 26, 27
2.75G, 209 actuation, 3, 4, 22, 32, 217
200 OK, 13 actuator, 25, 29, 31
256-QAM, 55, 56 actuators, 25
3G-PLC, 47, 48, 57 ad-hoc, 52
3GPP, 203, 209 ad-hoc mode, 32
3GPP Release 15, 209 Adaptive Tone Mapping, 49
3rd Generation Partnership Project, 203 ADC, 3, 22, 25, 27
4G, 203, 209 additional count, 160
5G, 209 additional record, 154
5G LTE-M, 209 Additive White Gaussian Noise, 37
5G NB-IoT, 209 addressing, 165
5G NSA, 209 address resolution, 153
5G Non-Standalone, 209 ADV, 176
5G SA, 209 Advanced Encryption Standard, 65
5G StandAlone, 209 Advanced Message Queuing Protocol, 141
64-QAM, 42, 59 advertising, 69
6G, 209 AES, 65, 188, 193, 213
6Lo, 104, 106, 210 AES-CBC, 65
6LoBTLE, 78, 104 AES-CTR, 65
6LoPLC, 104 AGC, 49
6LoWPAN, 5, 24, 25, 28, 47–50, 73, 74, 78, 82, 85, 90, 100, 101, AGC control, 200
104–106, 113, 124, 162, 183, 189, 210, 213, 217, 218, 222, 224 aggregating gateway, 138
6LoWPAN-GHC, 103 AH, 100
6LoWPLC, 105 AI, 16
6P, 106, 107 AIFS, 58
6TiSCH, 106, 107 Ajax, 111
6TiSCH Operational Sublayer, 106 alive, 166
6top, 106 ALOHA, 195, 197, 208
6top Protocol, 106 Alternate Mark Inversion, 39
8-PSK, 49 alternating current, 25
8-QAM, 41 Amazon Web Services, 142
8PSK, 209 American Standard Code for Information Interchange, 113
AMI, 39
Amplitude Shift Keying, 41
A AMQP, 141, 145
A, 155, 159, 161, 163 ANCOUNT, 160
AA, 160, 161 Angle of Arrival, 68
AAAA, 155, 159, 161, 163 Angle of Departure, 68
Absolute Slot Number, 67 annotated message, 144
AC, 213 Answer Count, 160
Accept, 127 answerer, 157
access, 8, 24, 27, 28 answer record, 154
Access Control List, 66 ANT+, 51, 77, 221
Access Point, 51 AoA, 68
Access Stratum, 206 AP, 51, 52, 58, 59
ACE, 221 API, 16, 77, 112, 198, 224
ACK, 13, 48, 49, 125, 126, 128, 132, 134 APP, 136
ACK_RANDOM_FACTOR, 128 application layer, 7, 22
© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 235
R. Herrero, Fundamentals of IoT Communication Technologies, Textbooks in Telecommunication
Engineering, https://doi.org/10.1007/978-3-030-70080-5
236 Index

Application Program Interfaces, 16 Bluetooth, 68

Application Support Layer, 220 Bluetooth 1.0, 67
APS, 220, 221 Bluetooth 1.1, 67
Arbitrary Interframe Spacing, 58 Bluetooth 1.2, 67
ARCOUNT, 160 Bluetooth 2.0, 68
ARM, 16, 25 Bluetooth 2.1, 68
ARP, 81, 85 Bluetooth 3.0, 68
ARQ, 104 Bluetooth 4.0, 68
Artificial Intelligence, 16 Bluetooth Low Energy, 24
AS, 206 Bluetooth Smart, 68
ASCII, 113, 116, 117, 124, 131, 132, 166 Bluetooth Special Interest Group, 67
ASK, 41, 74, 208 body, 117
ASN, 67 Body Area Network, 24
asset, 3, 4, 26, 29, 130 Bonjour, 163
asset tracking, 203 Border router, 214, 215
asynchronicity, 137 border router, 24, 78, 164
at least once, 138 bots, 120
ATM, 49 bppb, 15
at most once, 138 BPSK, 41, 49, 61, 202, 204, 208
ATP, 60, 61 broadcast register, 201
attribute-value pair, 178 broker, 111, 137, 138, 143
authentication, 28, 59, 197 BSID, 60
Authentication and Authorization for Constrained Environments, 221 BSS, 51, 54, 58, 59
authentication database, 201 BSSID, 52
Authentication Header, 100 BSS Identifier, 52
authoritative, 159 bundle, 67
Authoritative Answer, 160 bus, 24
Authority Count, 160 BYE, 132, 134, 136
authority record, 154 byebye, 166
Automatic Gain Control, 49
autonomous cells, 107
auxiliary security header, 65 C
Avahi, 163 C-Plane, 73
availability, 28 CA, 102
AWGN, 37 Cache-Control, 166
AWS, 142 cacheable, 112
Call-ID, 133, 134
CANCEL, 132
B cancoap, 130
B5G, 209 Canonical Name, 135
backbone, 8, 159 CAP, 59
background frame, 199 capillary network, 21, 22
BACNet, 49 Carrier Sense Multiple Access with Collision Avoidance, 48
BAN, 24 Carrier Sense Multiple Access with Collision Detection, 46
bare-metal, 26 category 1, 31
bare-metal system, 224 category 2, 31
bare message, 144 CBC, 65, 66
base station controller, 201 CBOR, 221
Basic Service Set, 51 CDMA, 45, 179, 181, 207
battery lifetime, 193 cell, 10, 67
beacon, 52 cell identifier, 205
beacon transmit series, 199 Celullar IoT, 206
beamforming, 55 centralized, 137, 153
BER, 37, 182 Central Management System, 208
Beyond 5G, 209 central processing unit, 25
BFD, 188 central processor, 29
Bidirectional Forwarding Detection, 188 Certificate Authority, 102
big data, 16 Certificate Request, 103
Bipolar RZ, 39 CFS, 48
Bit Error Rate, 37 Change Cipher Spec, 102
bits per pixel band, 15 channel bandwidth, 37
black box, 5 channel bonding, 54
BLE, 24, 67–69, 77, 78, 82, 104, 106, 193, 213, 220, 221 Channel Capacity Theorem, 21
blinker, 199 channel coding, 37
BLIP, 94 channel decoder, 3, 38
block code, 38, 46 channel encoder, 3
Index 237

channel encoding, 3, 21, 22, 38, 70 control points, 165

Chirp Spread Spectrum, 61 convolutional, 37, 38, 47, 48, 199, 207
CIFS, 48 convolutional codes, 208
CIoT, 206, 209 Cookie, 118
circuit switched, 73 cookie, 101
client/server, 111 Cookies, 118
Client Hello, 101 core, 8, 24, 27
Client Hello Verify, 101 core.rd*, 165
Client Key Exchange, 101 CoSIP, 134
cloud, 198, 213 CPI, 202
cloud computing, 9 CPS, 4, 25, 61, 68, 77
cluster, 220 CPU, 25
clusterhead, 24, 28, 182, 219 CRC, 46, 50, 65, 70, 200
clusterheads, 30, 171 CRUD, 112, 121
cluster network, 62 CS, 73
clusters, 171 CSeq, 133, 134
cluster setup, 179 CSM, 208
CNAME, 135 CSMA/CA, 48, 57–59, 63, 71, 106, 195, 200, 208, 213
CoAP, 11, 16, 25, 82, 123, 134, 153, 156, 161, 163–165, 193, 215, 217, CSMA/CD, 46, 47
219–221, 224 CSRC, 135
CoAP Resource Directory, 164 CSS, 61, 193, 195
CoAP Resource Discovery, 164 ct, 164
COBS, 50 CTA, 59, 60
codec, 10, 133 CTAP, 59
Code Division Multiple Access, 45 CTR, 65, 66
Code on Demand, 112 CTS, 54
code rate, 12, 38, 53, 54, 56, 199, 202 Cyber-Physical System, 4
cognitive radio, 55 Cyclical Redundancy Checking, 46
commissioner, 215 Cyclic Prefix Insertion, 202
commissioning, 215
commissioning information, 219
CON, 125, 126, 128, 129 D
Concise Binary Object Representation, 221 D7A Advertising Protocol, 200
conditional GET, 119 D7AAvP, 200
confidentiality, 28 D7A Network Protocol, 200
confirmable, 124–126, 131, 217, 219 D7ANP, 200
conflict resolution, 157 D7AP, 198–200
congestion timeout, 200 D7A Session Protocol, 200
CONNACK, 139 D7ASP, 200
CONNECT, 139 D7ATP, 200
connected home, 213 D7A Transport Protocol, 200
Consistent Overhead Byte Stuffing, 50 D8-PSK, 47, 49, 69
Constrained Application Protocol, 11 DAC, 3, 22, 25, 27
Constrained SIP, 134 DAD, 81, 217
constructive interference, 67 DAE, 92
Contact, 133, 134 DAM, 64, 65, 96
contact list, 120 DAO, 184, 185, 188, 189, 216
contended access, 202 DAO-ACK, 185
Content-Format, 127 DASH7 Alliance Protocol, 198
Content-Length, 133, 134, 167 DATA, 176
Content-Type, 133, 134, 167 data-centric routing, 171, 176
contention, 57 data-centric routing,10.5555/1203508, 177
contention-free, 57 data-information, 26, 27
Contention Free Slot, 48 data-information conversion, 8, 9, 179
Contention Interframe Spacing, 48 data aggregation, 32
content type, 164 data analysis, 32
context-based, 92 data fusion, 32
Contiki, 26, 94, 130, 163, 189 datagram, 7
continuous, 157 Datagram Transport Layer Security, 101
Contributing Source, 135 Data Link Control, 73
control, 165 data mining, 8, 16, 30
control capability, 32 DBPSK, 41, 196, 202, 207
controlled devices, 165 DC, 38
controller, 29 DCF, 57, 58
controllers, 25 DCI, 204
control plane, 202 DECT, 72
238 Index

DECT ULE, 72, 104, 106 DQPSK, 47, 49, 69

DECT Ultra Low Energy, 72 DRS, 53
DELETE, 112, 116, 117, 165, 221 DS-UWB, 61
Demodulation Reference Signal, 204 DSA, 131
demodulator, 3 DSAP, 46, 74
Denial of Service, 29 DSCP, 94
description, 165 DSSS, 42, 53, 61, 62, 207–209
Destination Address Encoding, 92 DSSS/BPSK, 43
Destination Address Mode, 64 DTLS, 101, 103, 131, 213, 220, 222, 224
Destination Advertisement Trigger Sequence Number, 185 DTLS Alert Protocol, 101
Destination Node ID, 72 DTLS Application Data Protocol, 101
Destination Oriented Directed Acyclic Graph, 183 DTLS Change Cipher Spec Protocol, 101
Destination Service Access Point, 46 DTLS Handshake Protocol, 101
destructive interference, 67 DTLS Record Protocol, 101
detectability, 32 DTLS records, 102
DEV, 59 DTSN, 185
device coverage, 193 DTX, 135
device identifier, 197 dual model, 208
DEVID, 60 Duplicate Address Detection, 81
DHCPv6, 80, 106, 166, 215, 217, 222, 223 duplicate flag, 138, 140
dialog, 134 duration id, 58
dialog identifier, 200 duty cycle, 27, 51, 213, 219, 220
Differential Encoding, 40 DV, 182–184, 213, 216, 218, 219
Differential PSK, 41 dynamic fragmentation, 55
differential signaling, 49 Dynamic Rate Shifting, 53
Differentiated Services Code Point, 94
Diffie-Hellman, 100, 101
DIFS, 57 E
Digital Enhanced Cordless Telecommunications, 72 e-mail, 121, 135
Digital Signal Processing, 25 E-UTRAN, 206
DIO, 184, 187–189, 216, 218 EC-GSM-IoT, 209
direct current, 25 ECC, 131
Directed Diffusion, 177 ECN, 94
directory discovery, 153 eCoAp, 130
Direct Peripheral Access, 207 EDCF, 58
Direct Sequence SS, 42 EDR, 68
Direct Sequence Ultra Wideband, 61 eDRX, 204, 209
DIS, 184, 188, 216 Effective Irradiated Power, 50
DISCONNECT, 139 EID, 96
Discontinuous Transmissions, 135 EIRP, 50, 53
discovery, 153, 165 Elliptic-Curve Cryptography, 131
dispatch, 85 embedded, 25
Distance Vector, 182 embedded operating system, 224
distributed, 137, 153, 154 EMI, 21, 49
Distributed Coordination Function, 57 eMQTT5, 141
Distributed Inter Frame Spacing, 57 eMTC, 209
Distributed OFDM, 208 eNB, 206
distribution services, 59 Encapsulating Security Payload, 100
distribution system, 51 end-end, 222
DLC, 73 end-to-end, 106
DMRS, 204 end-to-end principle, 65, 98
DNS, 121, 153 End of Frame, 71
DODAG, 183, 184, 187, 219 endpoint, 199
DODAG Advertisement Object, 184 endpoints, 21
DODAG identifier, 185 energy efficiency, 28
DODAG Information Object, 184 Enhanced Data Rate, 68
DODAG Information Solicitation, 184 Enhanced DCF, 58
DOFDM, 208 enhanced GPRS, 209
domain name, 153 enhanced Machine Type Communication, 209
Domain Name System, 121 Entity Tag, 127
DoS, 29, 101, 103, 106 EoF, 71
dotdot, 220, 221 EPC, 206
downlink channel, 202 epoch, 102
Downlink Control Information, 204 EPS, 206
DPA, 207 Erbium, 130
DPSK, 41, 47, 49 error code, 197
Index 239

error control codes, 38 frame counter, 65

escaped, 162 frame layer, 196
ESP, 100 framing, 37
ESS, 51, 59 free propagation, 21, 38
ETag, 127, 165 FreeRTOS, 26, 224
Ethernet, 4, 28, 45, 51, 82, 215, 222 Frequency Division Duplex, 203
Ethernet II, 45 Frequency Division Multiple Access, 73
ethertype, 45, 85 Frequency Hopping SS, 43
ETSI, 112, 121, 207 Frequency Shift Keying, 41
ETX, 182, 183, 218 freshness, 28
EUI-64, 65, 193 From, 132, 134
European Telecommunications Standards Institute, 112 FSF, 64, 65
event, 137 FSK, 41, 71, 208
event based, 137 Full End Device, 214
eventing, 165 Full Function Devices, 62
Evolved Packet Core, 206 Fully Qualified Domain Name, 121
Evolved Packet System, 206
Evolved UMTS Terrestrial Radio Access Network, 206
exactly once, 138 G
EXECUTE, 112 G3-PLC, 45, 47, 48
execute, 112 gateway, 24, 29, 72, 82, 184, 197, 199, 201, 214, 215
execution delay period, 200 gateways, 7, 25
execution delay timeout, 200 Gaussian, 69
Expected Transmission, 182 Gaussian FSK, 69
Explicit Congestion Notification, 94 Gaussian Minimum Shift Keying, 209
exposed station, 51 GET, 11, 112, 116, 117, 130, 134, 153, 154, 164, 221
Extended Coverage GSM IoT, 209 GFSK, 69, 71, 72, 196, 199, 207
Extended Discontinuous Reception, 204 Global Positioning System, 10
eXtended LEACH, 180 global repair, 186
Extended Markup Language, 112 Global System for Mobile Communications, 203
Extended Service Set, 51 GMSK, 209
Extended Unique Identifier, 65 Google Cloud, 142
eXtensible Messaging and Presence Protocol, 120 gossiping, 175, 176
Extension Identifier, 96 GPS, 10
gradient, 177
ground, 185
F GSM, 203
fading, 12, 14, 67 GUA, 78, 214
Fast FHSS, 44 guardband, 49, 53, 202, 203, 208
FCH, 48, 49 guardband allocation, 203
FCS, 46, 48, 49, 65, 70, 72, 182, 197 guided propagation, 21, 38
FDD, 203, 209
FDMA, 73, 207, 209
FEC, 12, 22, 37, 38, 48, 53, 104, 197, 199, 202, 207–209 H
FED, 214–216, 219 H.265, 31
FFD, 62 H2M, 123
FHSS, 43, 53, 62, 68, 71, 199, 202 HAL, 224
FHSS/MFSK, 44 half duplex, 203
FIB, 87, 90 HAN, 24, 48, 213
Finished, 102 handover, 206
fire-and-forget, 121, 124, 138 Hardware Abstraction Layer, 224
firewalls, 137 hardware interrupts, 126
flat, 171, 189, 190, 216 HARQ, 206
flat architecture, 5 HC1, 92, 93
flooding, 176, 190, 216 HC2, 92, 93, 104
flow label, 78, 87, 93, 94 HEAD, 116, 117
fog computing, 9 header, 117
foreground frame, 199 header line, 116
Forward Error Correction, 12 Head of Line, 114
forwarding, 87 health care, 201
Forwarding Information Base, 87 Heating, Ventilation and Air conditioning, 213
FQDN, 121 heterogeneity, 137
frame, 7 hidden station, 51
Frame Checksum, 46 hierarchical, 171, 190, 216
Frame Control Field, 64 hierarchical routing, 179
Frame Control Header, 48 High Priority Contention Window, 48
240 Index

High Speed, 68 IEEE 802.15.1, 68

HIP, 100, 131 IEEE 802.15.1-2002, 67
HIP Base Exchange, 101 IEEE 802.15.1-2005, 68
HIP BEX, 101 IEEE 802.15.3, 59, 61
HIP DEX, 101, 103 IEEE 802.15.3b, 60
HIP Diet Exchange, 101 IEEE 802.15.4, 10, 11, 16, 24, 25, 28, 61, 63–65, 67, 78, 82, 84, 85,
HOL, 114, 124 87, 90, 98, 104–107, 113, 124, 134, 136, 157, 162, 182, 193,
home and building automation, 201, 203, 207 195, 208, 213, 214, 217–219, 221, 222, 224
Home Area Network, 24 IEEE 802.15.4c, 61
home automation, 61, 213, 218, 224 IEEE 802.15.4d, 61
HomeID, 71 IEEE 802.15.4e, 61, 63, 66, 67, 106, 209, 213
home server, 120 IEEE 802.15.4g, 208, 209
Home Subscriber Server, 206 IEEE 802.15.4k, 208
hop limit, 78 IEEE 802.15.5, 90
hopping control, 200 IEEE 802.2, 46, 58, 74
Host, 166, 167 IEEE 802.3, 45, 46, 215, 222
Host Identity Protocol*, 100 IEEE G.9959, 71
hostname, 153, 155, 162 IEFT, 7
hosts, 21 IE present, 64
HPCW, 48 IETF, 6, 12, 61, 105, 183, 213
HSS, 206 IETF RFC 4944, 93
HTML, 111, 113 IETF RFC 6282, 94
HTTP, 28, 78, 82, 112, 113, 123, 131, 132, 137, 153, 156, 161, IETF RFC 6775, 84
165–167 IETF Stack, 214
HTTP 1.0, 114 if, 164
HTTP 1.1, 114 If-Match, 127
HTTP 2.0, 114 If-None-Match, 128
HTTP 3.0, 114 IID, 78, 81, 84, 85, 93, 105, 220, 222
HTTPU, 166–168 IIoT, v, 17, 61, 63, 120, 136, 213
Human-to-Machine, 123 IKE, 100, 131
HVAC, 213 IKE_AUTH, 100
Hybrid Automatic Repeat reQuest, 206 IKE_SA_INIT, 100
Hybrid Error Correction, 12 IN, 155
hybrid routing, 174 in-network processing, 32, 33
hyperframe, 204 inband, 203
hyperframe cycle, 204 inband allocation, 203
hyperspectral images, 9 Independent BSS, 52
Hypertext Markup Language, 111 industrial automation, 61
HyperText Transfer Protocol, 28 industrial control, 203, 207
Industrial IoT, v
Industry 4.0, 17
I INFO, 132
I2 C, 25 info/query, 121
I/O, 16, 25 information-knowledge, 9, 26, 27
IAN, 24 information-knowledge conversion, 9
IANA, 164 Information Element, 60
IBSS, 52 infrared, 53
ICMP, 80 infrastructure, 52
ICMPv6, 80, 224 Ingenu, 207
IE, 60, 64, 67, 107 init, 69
IEEE 1149.1, 25 Initialization Vector, 66
IEEE 1901.2, 45, 48, 49, 104, 105 instruction set architecture, 25
IEEE 802.11, 10, 59, 67, 68, 193, 215, 222 integrity, 28
IEEE 802.11a, 53 interest, 177
IEEE 802.11ac, 53, 55 interface, 5
IEEE 802.11ad, 53 interface description, 164
IEEE 802.11af, 53, 55 Interface Identification, 78
IEEE 802.11ah, 53, 56, 104, 106 Inter Integrated Circuit, 25
IEEE 802.11aj, 53 International Telecommunication Union Telecommunication
IEEE 802.11ax, 53, 55 Standardization Sector, 31
IEEE 802.11b, 53 Internet, 7, 16, 21, 24, 26, 47
IEEE 802.11ba, 53 Internet Area Network, 24
IEEE 802.11e, 58 Internet Assigned Numbers Authority, 164
IEEE 802.11g, 53, 54 Internet Control Message Protocol, 80
IEEE 802.11n, 11, 53–55 Internet Engineering Task Force, 6
IEEE 802.11p, 53, 55 Internet Key Exchange, 100
Index 241

Internet of Things, 4 known answer, 157

Internet Protocol, 4 KS, 65
interrogator, 74
Inter Symbol Interference, 202
inventory tracking, 201 L
INVITE, 13, 132, 134 L2CAP, 70
IoT, 3, 4, 68, 74, 77, 78, 220 LAN, 23, 24
IoT-RTCP, 136 latency, 159
IoT-RTP, 136 layer, 5
IP, 4, 24, 193, 195, 214, 215, 217, 220 layered architecture, 3, 5, 21, 28
IPHC, 87, 94, 96, 98 Layered System, 112
IP Header Compression, 87 LBR, 184, 186
IPSec, 78, 100, 131 LDPC, 15
IP Security, 78 LEACH, 179, 181, 182
IP Time to Live, 78 Leader, 222
IP TTL, 78, 155 leader, 215, 220, 223
IPv4, 5, 28, 155 Least Frequently Used, 103
IPv6, 5, 22, 24, 28, 72–74, 90, 106, 155, 210, 213–215, Least Significant Bit, 217
220, 224 LECIM, 208
IPv6 over Low power Wireless Personal Area Networks, 5 LFU, 103
IPv6 over Networks of Resource Constrained Nodes, 104 LHIP, 101
IPv6 over TSCH, 106 libcoap, 130
iq, 121, 123 licensed bands, 203
IQMESH, 207 lidar, 27
IQRF, 207 light detection and ranging, 27
IR, 53 Lightweight HIP, 101
ISA, 25 Lightweight On-demand Ad-hoc Distance Vector, 189
ISA 100.11a, 61 line code, 38
ISI, 202 link, 21
ISM, 53, 59, 61, 193, 194, 196, 199, 207–209 link access, 37
ISM band, 67 link layer, 6
ISO, 142 Link Layer Control, 37
ISO/IEC 18000-3, 73 link local, 166
ISO/IEC 18000-7, 199 Link Margin, 218
isotropic, 50, 59 Link State, 182
ITU, 51 Linux, 94
ITU-T, 31 listen timeout, 200
ITU-T G.9903, 45 LKM, 218
ITU-T G.9959, 71, 72, 82, 104, 105 LLC, 37, 46
IV, 66 LLCP, 74
LLLN, 24
LLN, 24, 38, 61, 67, 82, 92, 104, 123, 124, 131, 134–138, 154, 155,
J 164, 165, 168, 182, 183, 189, 219–222
Jabber Identifier, 121 LOAD, 189
JavaScript, 111 load balancing, 156, 157
JavaScript Object Notation, 112 LOAD Next Generation, 189
JID, 121 LOADng, 189, 190
joiner, 222 LoBAC, 104, 105
Joint Test Action Group, 25 .local, 155
JSON, 112 Local Area Network, 23
JTAG, 25 local processing, 26
local repair, 186, 188
Location, 166
K Location-Path, 127
Kaa, 142 Location-Query, 127
KC, 65, 66 location based routing, 178
keepalive, 218 location register, 201
KEK, 220 logical channels, 202
Key Control, 65 logical device, 166
Key Encryption Key, 220 logical devices, 25
Key Identifier Mode, 65 Logical Link Control and Adaptation Protocol, 70
Key Index, 65 Logical Link Control Protocol, 74
Key Source, 65 Long Range, 193
KI, 65, 66 Long Term Evolution, 203
KIM, 65 loop, 184, 186, 188, 216
known-answer suppression, 157 LoRa, 10, 25, 193–197, 199, 208, 210
242 Index

LoRaWAN, 194, 195 Manchester Code, 40

lossless, 26 Mandatory Control Plane CIoT EPS, 206
lossy, 10, 26 MANET, 32, 171
Low Density Parity Check, 15 marker, 135
Low Energy, Critical Infrastructure Monitoring, 208 Markov, 14
Low Energy Adaptive Clustering Hierarchy, 179 massive access, 209
actuator, 27 Massive IoT, 17
class a, 196 master-slave, 24
class b, 196 Master-Slave/Token-Passing, 24
class c, 196 Master Information Block, 204
controller, 27 Max-Age, 127
flooding, 174 Max-Forward, 132
in-network processing, 33 MAX_RETRANSMIT, 128
leader, 214 maximum size, 164
leader, 215 Maximum Transmission Unit, 38
location based routing, 172 MBed, 26
operation and maintenance center, 201 Mbed, 94
point-to-point, 32 MBed TLS, 224
publish/subscribe, 111, 120, 171 mblpc, 13, 15
publish/subscribe, 137, 153 MCTA, 59
replay protection, 29 mDNS, 154, 157, 159
request/response, 111 mDNS client, 157
request/response, 153 mDNS server, 157, 159
request/response, 132, 136, 137, 141 Mean Structural Similarity, 15
response code, 160 MED, 214–216, 219
response code, 154 media, 12
ripple, 183 Media Access Control, 37
ripple, 184 Media over IP, 131
route discovery, 190 media server, 132, 134
sensor, 26 mesh, 8, 62, 71, 78, 82, 207
sub-ghz, 50 mesh-under, 90, 92, 105, 218
thread router, 214 Mesh Commissioning Protocol, 222
LOWPAN_HC1, 92 MeshCoP, 222
Low Power, Low Rate and Lossy Network, 24 Mesh Link Establishment, 216
Low Power and Lossy Network, 24 message, 7, 121
Low Power PAN Border Router, 184 Message Authentication Code, 65
Low Power Wide Area Network, 7 message identifier, 126
Low Throughput Networks, 207 Message Integrity Code, 65
LPWAN, vi, 7, 24, 25, 28, 51, 56, 151, 193, 196, 201, 203, 208, 210 Message Queue Telemetry Transport, 16
LPWWAN, 24 message sublayer, 124
LS, 182 messaging, 143
LSB, 217, 219 metadata, 176
LTE, 203, 204, 206, 209 method, 112, 116
LTE-M, 209 Metropolitan Area Network, 23
LTE Cat M1, 209 MFR, 71, 72
LTE Cat M2, 203 MHR, 71
LTN, 207 MIB, 204, 205
LwIP, 94 MIC, 65, 102, 200, 222
lwIP, 163, 189, 224 MIMO, 11, 54, 56
minimal core, 189
Minimal End Device, 214
M Minimal SF, 107
M-FSK, 41, 44, 45 mission planner, 10
M-PSK, 41 mist computing, 9
M-QAM, 41 mixers, 135
M2M, 3, 4, 61, 68, 74, 77, 221 MLE, 216, 220, 222, 224
M2P, 7, 30, 32, 52, 57, 124, 183, 184 MLE discovery request, 220
MAC, 37, 46, 50, 57, 60, 63, 66, 71, 106, 195–197, 206, 208, 209, 213 MLE discovery response, 220
MAC Footer, 71 MMC, 40, 74
MAC Header, 71 MME, 206
Machine-to-machine, 3 Mobile Ad-hoc Network, 32
machine learning, 8, 10, 16, 26, 30, 32 Mobility Management Entity, 206
MAC Protocol Data Unit, 71 mode of operation, 185
MAC Service Data Unit, 71 Modified Miller Code, 40
MAN, 23, 166 modulation, 3, 22
Manchester, 45, 71, 74 modulator, 3
Index 243

MoP, 131 network impairment, 154

mosquitto, 141 network layer, 7
Most Significant Bit, 216 network topology, 193
MPDU, 71, 72 New Radio, 209
MPL, 216, 224 next header, 78, 87, 92, 94
MQTT, 16, 138, 153, 161 Next Header Compression, 87
MQTT-C, 141 Next Secure, 159
MQTT-SN, 138 NFC, 50, 77, 104, 199
MS/TP, 24, 25, 45, 49, 50, 104, 106 NFC peer-to-peer, 73, 74
MSB, 216, 217, 219 NFC reader/writer, 73
MSDU, 71, 72 NHC, 87, 94, 96, 98, 104
MSF, 107 node assessment, 32
MSSIM, 15 node coverage, 32
MTR, 184 Node JS, 111
MTU, 38, 45, 80, 85, 96, 105, 162 NON, 125, 126, 129, 130
multi-hop, 22, 27, 31 Non-Access Stratum, 206
Multi-Topology Routing, 184 non-authoritative, 155
Multicast DNS, 154 non-beacon mode, 63
Multicast Protocol for Low Power and Lossy Networks, 216 non-confirmable, 124–126, 131
multipath, 12 non-null, 159
multipath fading, 202 non-persistent, 114
Multiple Input-Multiple Output, 11 non-storing, 217, 218
multiplexing, 7, 114 non-storing node, 186
multipoint-to-point, 7 non-terminal, 144
mutual authentication, 101 Normal Priority Contention Window, 48
MX, 166 NOTIFY, 168
notify, 112
NPBCH, 204
N NPCW, 48
NA, 81, 189 NPDCCH, 204
NACK, 12, 48, 49 NPDSCH, 204
Nagle’s algorithm, 104 NPRACH, 204
namespace, 121 NPSS, 204
nanocoap, 130 NPUSCH, 204
Narrow Band, 53 NR, 209
Narrowband Fidelity, 207 NRS, 204
Narrowband IoT, 10, 203 NS, 81, 189
Narrowband Physical Broadcast Channel, 204 NSCOUNT, 160
Narrowband Physical Downlink Control Channel, 204 NSEC, 159
Narrowband Physical Downlink Shared Channel, 204 NSSS, 204
Narrowband Physical Random Access Channel, 204 NT, 166
Narrowband Physical Uplink Shared Channel, 204 NTS, 166
Narrowband Primary Synchronization Signal, 204 NUD, 81
Narrowband Reference Signal, 204 Nwave, 208
Narrowband Secondary Synchronization Signal, 204 NZR, 38
NAS, 206
NAT, 5, 77, 100, 214
NB, 53, 90 O
NB-Fi, 207 objective function, 183, 184
NB-IoT, 10, 25, 203, 209, 210 observation, 112, 120, 121, 130, 137
ND, 80–82, 84, 87, 94, 106, 189, 218 observe, 130
Near Field Communication, 50 of 6LoWPAN, 189
Near Field Communications, 73 OFDM, 42, 47–49, 53, 56, 208
Negative Acknowledgment, 12 OFDMA, 203, 209
negative acknowledgment, 37, 48 Offset QPSK, 41
negative answers, 159 OMC, 201
negotiated cells, 107 on-demand routing, 184, 216
Neighbor Advertisement, 81 On-Off Keying, 208
neighbor discovery attack, 29 one-shot, 157
Neighbor Solicitation, 81 one-time, 157
Neighbor Unreachability Detection, 81 one-to-one messaging, 120
Network Address Translation, 5 OOK, 208
network bandwidth, 8 OPCODE, 160, 161
network core, 206 OPC UA, 136
network coverage, 32 OpenMDNS, 163
Network Discovery, 80 Open Platform Communications United Architecture, 136
244 Index

Open Systems Interconnection, 6 PINGRESP, 139

OpenThread, 223 pipelining, 114
OpenWSN, 26, 94 PKI, 100
Operating System, 25 playout buffer, 135
Operation Code, 160 PLC, 16, 24, 45
optimistic DAD, 81 PN, 44
Optional User Plane CIoT EPS, 206 PN9, 199
OPTIONS, 132 PNC, 59, 60
OQPSK, 41, 61, 208, 209 PNID, 60
origin identifier, 200 Point Coordination Function, 57
Orthogonal Frequency Division Multiplexing, 42 point of presence, 121
OS, 25, 166 point of sale, 201
OSI, 6 Polar NRZ, 71
OT RTOS, 224 Polar NZR, 38
overlapping, 174, 190 POST, 11, 112, 116, 134, 165, 221
Power-Efficient Gathering in Sensor Information Systems, 180
Power Line Communication, 16
P Power Saving Mode, 204
P-GW, 206 PRB, 203
P2P, 32, 59, 62, 74, 137, 176 pre-shared key, 59, 73
packet bursting, 54 preamble, 45, 48–50, 197, 199, 200, 202
Packet Data Node Gateway, 206 preference, 185
Packet Data Unit, 74 prefix, 78, 80, 81
Packet Delivery Ratio, 182 presence, 120, 121
packetization, 131 presence subscriptions, 121
packet loss, 159 presentation, 165
packet switched, 73 presentation layer, 7
Paho MQTT, 141 Priority Channel Access, 208
PAM, 40, 45 privacy, 59
PAN, 24, 193, 219, 220 proactive, 190, 216
PAN coordinator, 62–65, 84, 90, 219 proactive routing, 173
PAN ID, 64, 65 processing gain, 43
PAN ID compression, 64, 65 programmable logic controller, 4
PAN Identifier, 64 Proportional Integral Derivative, 3
PAN identifier, 213, 216, 220 Protocol Stack Virtualization, 17
PANs, 24 Proxy-Uri, 127
partition, 215 proxy server, 117, 118, 132
partitions, 215 PS, 73
passive, 26 pseudo-noise, 44
path maintenance, 190 pseudo-random, 44
payload, 197 PSK, 41
payload type, 135 PSKc, 222
PCA, 208 PSM, 204, 209
PCF, 57, 58 PSNR, 15
PDR, 182, 218 PSV, 17
PDU, 74 PTR, 155, 161, 163
PDU Type, 74 PTYPE, 74
Peak Signal-to-Noise Ratio, 15 PUBACK, 139, 140
PEGASIS, 180–182 PUBCOMP, 139, 140
performative, 144 publication, 153
permit joining, 63 Public Key Infrastructure, 100
persistent, 114, 117 PUBLISH, 139, 140
Personal Area Network, 24 publish/subscribe, 137, 177
Phase Shift Keying, 41 publisher, 137
PHP, 111 PUBREC, 139, 140
physical attacks, 29 PUBREL, 139, 140
physical channel, 202 pull model, 199
physical devices, 25 Pulse Amplitude Modulation, 40
physical layer, 6, 22 pulse shaping, 202
Physical Resource Block, 203 push model, 120, 199
physical security, 201 PUT, 112, 116, 117, 165, 221
piconet, 59, 68
Piconet Coordinator, 59
PID, 3 Q
PIFS, 58 QAM, 41
PINGREQ, 139 QDCOUNT, 160
Index 245

QM, 159 remaining length, 139

QoS, 27, 37, 51, 59, 77, 78, 138, 183, 200, 208, 232 replay protection attack, 29
Qowisio, 208 Representational State Transfer, 11
QPSK, 41, 42, 49, 202, 204 REQ, 176
QR, 160 request, 116
QU, 159, 161 request/response, 124, 138
Quaddrature Amplitude Modulation, 41 requester, 200
Quaddrature PSK, 41 request line, 116
Quality of Service, 27 request period, 200
querier, 157 RERR, 190
query, 157 reset, 125
question, 154, 159 resilience, 28
Question Count, 160 resistance, 28
questioner, 157 resolution, 153
QUIC, 114 resolver, 157, 159
Quick UDP Internet Connection, 114 resource blindness, 175
resource discovery, 164
resource identifier, 121
R Resource Record, 154
R1, 71 Resource Record TTL, 155
R2, 71 resource sharing, 21
R3, 71 resource type, 164, 221
RA, 80–82, 84, 160, 164, 189 Resource Unit, 203
radar, 27 responder, 157, 200
radio detection and ranging, 27 response, 116
Radio Frequency, 7 Response Interface Spacing, 48
Radio Frequency Identification, 73 REST, 11, 16, 111–113, 116, 118, 120, 124, 132, 134, 141, 146, 219,
Radio Resource Control, 206 221, 224
Radio Resource Manager, 202 retain, 138
Random Access Procedure, 205 RF, 7
Random Frequency and Time Division Multiple Access, 196 RFC 2080, 216
Random Phase Multiple Access, 207 RFC 5049, 135
rank, 184, 185 RFC 5109, 12
RAP, 205 RFC 5444, 190
rate-distortion, 42 RFC 6520, 103
RCODE, 160, 161 RFC 6690, 164, 221
RD, 160 RFC 7049, 221
/rd/ep, 165 RFC 7252, 123, 127
/rd/res, 165 RFC 7400, 103
reactive, 189, 190, 216 RFC 7641, 130
reactive route update, 183 RFC 7925, 103, 131
reactive routing, 173 RFC 7959, 124
real-time, 25 RFC 8323, 124
Real-Time OS, 25 RFC 8480, 106
Real Time Communication, 12 RFC 8724, 210
Real Time Control Protocol, 135 RFD, 62
Real Time Operating System, 103 RFID, 73, 199
Received Signal Strength Indicator, 67 RFTDMA, 196, 197
Receiver Report, 135 RH4, 186
receiving antenna, 50 ring, 24
Recursion Available, 160 RIOT, 26, 189, 224
Recursion Desired, 160 RIP Next Generation, 216
recursive query, 153 RIPng, 216, 224
redirect server, 132 RISF, 48
Reduced Function Devices, 62 Robust Header Compression, 92
REED, 214–217, 219, 220 ROHC, 92
Reed-Salomon, 47 ROLL, 183
Reed-Solomon, 15 root, 184, 187, 189, 219
REGISTER, 132 root device, 166
registrar, 132 Root Raised Cosine, 202
registration, 153 Round Trip Time, 114
registration removal, 153 route-over, 90, 105, 218
registration update, 153 Route Error, 190
registration validation, 153 Router Advertisement, 80
registry, 215 Router Eligible End Device, 214
reliable delivery, 37 Route Reply, 190
246 Index

Route Reply Acknowledgment, 190 sensor, 3, 4, 25, 29, 31

Route Request, 190 Sensor Network Over White Spaces, 208
router identifier, 220 Sensor Protocols for Information via Negotiation, 176
routers, 21 sensors, 25
Router Solicitation, 81 sequence number, 135
routing*, 87 Serial Peripheral Interface, 25
Routing for Low Power, 183 Serial Wire Debug, 25
routing information spoofing, 29 Server, 166
Routing over Low Power and Lossy Networks, 183 Server Hello, 101, 103
routing tables, 173 Server Hello Done, 101
RPL, 183, 184, 186, 188–190, 193, 213, 216–219 service access, 153
RPL instance, 184, 185 Service Access Point, 46
RPMA, 207 Service Capability Exposure Function, 206
RR, 135, 154, 156, 159–162 service class, 153
RRC, 202, 206 service discovery, 153, 154
RREP, 190 Service Discovery DNS, 154
RREP-ACK, 190 service name, 153
RREQ, 190 Service Oriented Architecture, 16
RREQ_SMART, 190 Serving Gateway, 206
RRM, 202 Session Description Protocol, 12
RR TTL, 155 Session Initialization Protocol, 12
RS, 15, 81, 189 session layer, 7
RS-232, 4, 25 setResponse, 123
RS-485, 25, 45, 49 settled flag, 146
RSA, 131 SF, 106, 107
RSSI, 67–69, 199, 216 shared cell, 67
RST, 125, 126, 128, 129 shared RR, 156, 157, 159
rt, 164, 165, 221 shared RRs, 156
RTC, 12, 59, 131 Short Inter Frame Spacing, 57
RTCP, 135 SIB, 204, 205
RTOS, 25, 26, 93, 103, 130, 141 SIFS, 57
RTP, 131, 133, 135 SigComp, 135
RTP header, 135 SigFox, 25, 196, 197, 199, 210
RTS, 54 Signal-to-Noise, 21
RTT, 114 Signal Compression, 135
RU, 203 signaling, 12
RZ, 39 simple device, 26
Simple Object Access Protocol, 137
Simple Service Discovery Protocol, 166
S Single Carrier FDMA, 203
S-GW, 206 sink, 171, 176, 178, 179, 181
SAA, 80, 82, 84, 105, 107, 182, 189, 217, 222 sinkhole attack, 29
SAE, 92 SIP, 12, 131, 135
SAM, 64, 65, 96 Size, 128
SAP, 46 sleep deprivation torture, 29
SC-FDMA, 203 sleepy end devices, 218
SCADA, 4 slotframes, 66
scan, 69 slot time, 47
scatternet, 68 Slow FHSS, 44
SCEF, 206 smart cities, 207
SCHC, 210 Smart City, 17
schedule, 64, 66 smart city, 207
Scheduling Function, 106 smart city API, 207
scrambler, 69, 202 smart energy, 61
SCTP, 162 smart grid, 16
SD-DNS, 154, 161, 162 smart lighting, 207
SD-WAN, 24 smart metering, 201, 207
SDES, 135 smart parking, 207
SDN, 24 smartphone, 209, 213
SDP, 12, 133, 135 smart routing, 190
SDR, 207 SNAP, 46
security header, 200 SNOW, 208
security level, 65 SNR, 21, 22, 24, 29, 37, 38, 42, 62, 104, 182
segment, 7 SOA, 16, 136
selective forwarding, 29 SOAP, 137, 167
Sender Report, 135 SoC, 7, 16, 25
Index 247

Social Web of Things, 16 subscriber, 137

Software Defined Network, 24 subscription, 137
Software Defined Radio, 207 super-GHz, 50
Software Defined WAN, 24 Supervisory Control And Data Acquisition, 4
SoM, 7, 16, 25 Super Wi-Fi, 55
sonar, 27 SWD, 25
sound navigation and ranging, 27 SWoT, 16
Source Address Encoding, 92 sybil attack, 29
Source Address Mode, 64 synchro, 4
source decoder, 3 Synchronization Source, 135
source decoding, 22, 27 synchronization word, 199, 200
Source Description, 135 System-on-Chip, 7
source encoder, 3 system-on-module, 7
source encoding, 3, 22, 26, 27 System Information Block, 204
Source Node ID, 71 sz, 164
source routing, 217
Source Service Access Point, 46
space-air-ground-sea, 210 T
spatial diversity, 54 tag, 74, 98
SPI, 25 tags, 132
SPIN, 176, 182 TALQ consortium, 207
SPIN-BC, 176 target address, 199
SPIN-EC, 176 TC, 15, 157, 160, 161
SPIN-RL, 176 TCP, 28, 78, 82, 94, 113, 121, 136, 161, 165, 167
SPIN Broadcast, 176 TCXO, 202
SPIN Energy Conservation, 176 TDD, 73, 202, 203, 207
Split Phase, 40 TDMA, 59, 63, 73, 179, 180, 207, 209
spreading factor, 43, 62, 195, 202, 207, 208 Telensa, 207
Spread Spectrum, 42 Telensa PLANet, 208
SR, 135 Temperature Compensated Crystal Oscillator, 202
SRV, 155, 161, 163 terminal, 144
SS, 42, 193 TF, 94
SSAP, 46, 74 TG4g, 208
SSDP, 166 TG4k, 208
SSID, 58 The Things Network, 194
SSIM, 15 ThingSpeak, 142
SSRC, 135 ThingWorx, 142
ST, 166 Thread, 63, 213–219, 222
standalone allocation, 203 Thread Management Framework, 215
standby, 69 Thread Network Formation, 222
stanzas, 121 thread router, 215
star, 62 Thread Stack, 214
star-bus, 68 three-way-handshake, 134
Start of Frame, 71 three-way handshake, 114
star topology, 197, 199, 201, 207, 208 throughput, 8
stateless, 111, 113, 153 TIA/EIA-485, 45
Stateless Address Autoconfiguration, 80 tickle timer, 188
Static Context Header Compression, 210 Time Division Duplex, 73
station, 51, 52 Time Division Multiple Access, 59
station services, 59 Time Slotted Channel Hopping, 63
status code, 117, 134 timestamp, 123, 135
status line, 117, 134 Time Synchronized Mesh Protocol, 63
status message, 117, 134 TinyOS, 26, 94, 189
steady state, 179 TLS, 78, 101, 103, 121, 131, 137, 143, 224
stop-and-wait, 114 TLS Cached Information Extension, 103
storing, 218 TLV, 80, 126, 189, 190
storing node, 186 TMF, 215, 223
Stream Control Transmission Protocol, 162 TMSP, 63, 66, 67
Structural Similarity, 15 To, 132, 134
sub-GHz, 207 token, 125
SUBACK, 139 top-level, 155
subcontroller, 199 topic, 137
subnet, 199, 200 TPC, 69
Subnetwork Access Protocol, 46 traffic class, 78, 93, 94
SUBSCRIBE, 139, 140, 168 traffic implosion, 174, 190
subscribe/publish, 137 transaction identifier, 200
248 Index

transcoding, 135 URL, 113, 116, 166

Transmit Power Control, 69 User Agent Client, 132
transmitting antenna, 50 User Agent Server, 132
transparent gateway, 138 user channels, 202
transport/framing, 143 User Datagram Protocol, 12
transportation, 201 User Equipment, 203
Transport Control Protocol, 28 user plane, 202
transport layer, 7 USN, 166
Transport Layer Security, 78
trickle timer, 183, 188, 216, 218
trigger based random access, 55 V
Tripple, 189 V2I, 55
truncation, 157 V2V, 55
TSCH, 63, 66, 106, 107, 213 V2X, 55
TTL, 155, 159, 162 VAD, 135
TTN, 194 Vehicle to Everything, 55
Turbo Codes, 15 version, 78, 93, 116, 117, 126, 135
turnkey, 208 Via, 132, 134
TV, 202, 208 Voice Activity Detection, 135
TXT, 155, 161–163 Voice over IP, 12
Type-Length-Value, 80 Voice over LTE, 209
VoIP, 12
VoLTE, 209
U VPN, 100
U-Plane, 73
UAC, 132
UART, 25 W
UAS, 132–134 Wake-up Radio, 53
UAV, 9 WAN, 23, 24, 28
Ubuntu Core, 11 WAVE, 53
UDP, 12, 28, 82, 92, 94, 96, 98, 100, 124, 131, 154, 159, 161, 165–167, WAVIoT, 207
210, 213, 220 Web, 111, 213
UE, 203, 206 Web of Things, 111
UE identifier, 205 Web Services Security Conversation, 137
UHF, 202 Weightless, 201, 202, 208
ULA, 78, 214 Weightless-N, 202
Ultra Narrow Band, 196 Weightless-P, 202
UNB, 196, 208 Weightless-W, 202
unicast response bit, 159 Weightless SIG, 201, 207
unicode, 162 Weightless Special Interest Group, 201
Uniform Interface, 112 /.well-known/core, 164, 221
Uniform Resource Identifier, 113 /.well-known/core?rt=core.rd*, 165
Uniform Resource Locator, 113 WEP, 58, 59
Unipolar Nonreturn-to-Zero, 38 whitening, 69, 202
Unipolar Return-to-Zero, 39 white space database, 201
unique RR, 155, 157, 159 white space spectrum, 201, 208
Universal Asynchronous Receiver Transmitter, 25 Wi-Fi, 10, 32, 51, 213, 215, 222
Universal Plug and Play, 165 Wi-Fi 5, 55
Universal Resource Identifiers, 112 Wi-Fi 6, 55
Unmanned Aerial Vehicles, 9 Wi-Fi HaLow, 56
unsprung, 189 Wi-Fi Protected Access, 58
UNSUBACK, 139 Wi-Fi Protected Access II, 58
UNSUBCRIBE, 168 Wi-SUN, 208
UNSUBSCRIBE, 139, 140 Wide Area Network, 23
UPDATE, 112 Wired Equivalent Privacy, 58
upfading, 67 wireless, 21
uplink channel, 202 Wireless Access in Vehicular Environment, 53
uplink contended access channel, 202 WirelessHART, 61
UPnP, 165 Wireless Personal Area Network, 7
upward focused routing, 183 Wireless Sensor and Actuation Network, 29
upward routing, 184 Wireless Sensor Network, 3
URI, 112, 113, 132, 164, 221 Wireless Smart Utility Networks, 208
Uri-Host, 127 wireline, 21
Uri-Path, 127, 128 WLAN, 24, 51
Uri-Port, 127 wolfMQTT, 141
Uri-Query, 127 wormhole attack, 29
Index 249

WoT, 111 XEP-0325, 123

WPA, 58, 59 XEP-0326, 123
WPA2, 58, 59 XEP-0347, 123
WPAN, vi, 7, 24, 28, 29, 51, 57, 59, 61, 71, 82, 151, 183, 193, 210, 213, XLEACH, 180, 181
215, 219, 222 XML, 112, 113, 120, 121, 136, 137, 165–168
WPAN vs LPWAN, 8 xmlns, 121
WS(A)N, 29, 31 XML schema, 165
WSAN, 29 XMPP, 120, 123
WSN, 1, 3, 17, 21, 22, 31, 32, 171, 182, 183, 189, 190 XMPP Extension Protocols, 123
WS Security Conversation, 137 XMPP federation, 120
WUR, 53
WWAN, 24
Z
Z-Wave, 71, 77, 213
X ZCL, 220, 221
X.509, 101 ZCL over IP, 221
XEP, 123 ZDP, 220
XEP-0000-IoT-BatteryPoweredSensors, 123 Zephyr, 26, 94, 224
XEP-0000-IoT-Chat, 123 zero-configuration, 153, 154, 161, 165
XEP-0000-IoT-Events, 123 ZigBee, 61, 77, 105, 213, 220, 221
XEP-0000-IoT-Interoperability, 123 ZigBee Cluster Library, 220
XEP-0000-IoT-Multicast, 123 ZigBee Device Profile, 220
XEP-0000-IoT-PubSub, 123 ZigBee Pro, 220
XEP-0323, 123