Module – 5

Chapter 8
IoT Communication Technologies
8.1 Introduction
This chapter concentrates on intangible technologies enabling communication among IoT
devices, networks, and remote infrastructures.
Categorization of IoT Communication Protocols: The protocols are organized into six
groups based on their usage:

ud
1) Infrastructure Protocols: Concerned with the fundamental network setup and
connectivity.
2) Discovery Protocols: Aid in the identification and location of devices in the network.
3) Data Protocols: Handle data exchange and management between IoT devices and
systems. lo
4) Identification Protocols: Facilitate device identification and authentication.
5) Device Management Protocols: Support remote control and management of IoT
devices.
6) Semantic Protocols: Ensure data meaning and interoperability across different IoT
systems.
C
Functions of IoT Protocols:These protocols collectively handle key IoT features like:
Routing, Data management, Event handling, Identification, Remote management,
Interoperability.
tu

Essential IoT network terms are introduced, which are indirectly responsible for the evolution
of these communication protocols.
8.1.1 Constrained nodes
Definition: Nodes lacking standard Internet device features due to limitations.
Constraints: Caused by cost, size, weight, and power limitations.
V

Limitations: Reduced memory, processing power, limited layer 2 capabilities, no full

connectivity or broadcasting.
Design Needs: Special considerations for network integration.
Focus Areas: Energy optimization and bandwidth utilization due to node constraints.

8.1.2 Constrained networks

Networks where some or all nodes are limited by constraints.
Constraints:
• Limited processing power affects duty cycles.
• Low data rates and throughput.
• Asymmetric links and increased packet losses.
• Restricted packet sizes due to packet loss.
• Lack of advanced layer 3 features (e.g., multicasting, broadcasting).
• Limited device reachability due to sleep states for power management
8.1.3 Types of constrained devices

ud
Constrained devices can be divided into three distinct classes according to the device’s
functionalities:
Class 0:
• Severely constrained in memory and processing.
• Cannot directly communicate with the Internet or support security mechanisms.
•

Class 1:
lo
Uses gateway or proxy for Internet communication.

• Constrained in code space and processing power.

C
• Can communicate with the Internet but cannot use full protocol stacks like HTTP.
• Uses special protocols (e.g., CoAP), has a higher power budget than Class 0.
• Does not require a gateway for Internet access and can support security features.
tu

Class 2:
• Similar to portable computers (e.g., laptops, PDAs).
• Supports full protocol stacks (e.g., HTTP, TLS).
• Has a higher power budget than Classes 0 and 1.
V

8.1.4 Low power and lossy networks

• Comprise devices with limited power, memory, and processing resources.
• Use low-power Wi-Fi or IEEE 802.15.4 for network links.
• Physical layers experience high delivery rate variation, packet losses, and instability.
• Applications: Used in industrial automation, building automation, smart healthcare,
smart homes, logistics, environment monitoring, and energy management.

8.2 Infrastructure Protocols

Protocols rely heavily on network infrastructure. Eight Popular IoT Communication
Technologies:
• IPv6
• LOADng (Lightweight On-demand Ad hoc Distance vector Routing Protocol–Next
Generation)
• RPL (Routing Protocol for Low-Power and Lossy Networks)
• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)
• QUIC (Quick UDP Internet Connection)

ud
• uIP (micro IP)
• nanoIP
• CCN (Content-Centric Networking)
8.2.1 Internet protocol version 6 (IPv6)
Developed by IETF as a successor to IPv4 due to the depletion of IPv4 addresses. Works on
OSI layer 3 like IPv4, but with 128-bit addresses (IPv4 uses 32-bit).
lo
C
tu
V

Key Features:
1. Larger Addressing Range: Accommodates a massive number of devices with 128-
bit addressing.
2. Simplified Header Structure: Easier and faster to process, with larger headers for
addressing.
3. End-to-End Connectivity: Allows direct communication without network address
translations.
 4. Auto-configuration: Supports automatic address configuration, both stateless and
stateful, without requiring DHCP servers.
5. Faster Packet Forwarding: Simplified routing due to fewer required fields for
routers to check.
6. Inbuilt Security: Supports IPSec for security, which is optional in IPv6 but not
natively available in IPv4.
7. Anycast Support: Enables efficient routing by sending packets to the nearest
destination using anycast addresses.
8. Mobility Support: Mobile nodes can retain their IP addresses while moving between

ud
different geographic areas, crucial for IoT and connected applications.
9. Enhanced Priority Support: Simplified traffic class and flow labels system for
efficient routing paths.
10. Extensibility of Headers: IPv6 headers can be extended with additional information,
allowing for large option fields when required by specific applications.

Application in IoT: IPv6's scalability, auto-configuration, and security make it ideal for IoT
deployments.
IPv6 Addressing
lo
Interface Identifier (IID):
• Comprised of the last 64 bits of the 128-bit IPv6 address.
C
• Generated using the MAC address of the device, ensuring uniqueness.
• Auto-configured via EUI-64 format.
Types of Unicast Addresses:
tu

1. Global Unicast Address (GUA):

o Equivalent to IPv4 static addresses (public IPs).
o Globally identifiable and uniquely addressable.
o First 48 bits designate the global routing prefix (first three bits set to 001).
V

2. Link-Local Address (LL):

o Auto-configured addresses limited to a network segment (not routable).
o First 16 bits fixed as FE80 in hexadecimal, followed by 48 bits set to 0.
3. Unique Local Address (ULA):
o Locally unique addresses meant for internal networks (not routed to the
Internet).
o First half consists of Prefix, Local Bit, Global ID, and Subnet ID.
 o ULA prefix is always FD in hexadecimal (binary: 1111 110).
o If the least significant bit of the prefix is 1, it indicates locally assigned
addresses.
IPv6 Address Assignment
Auto-Configuration of Link-Local (LL) Address: Any node in an IPv6 network can
automatically configure its unique LL address.
Multicast Group Membership: Upon assigning an IPv6 address, the node joins multiple
multicast groups for communication within the network segment.
Neighbor Solicitation Message: The node sends a neighbor solicitation message to all its IPv6

ud
addresses.
Duplicate Address Detection (DAD): If no reply is received, the node assumes its address is
unique in that segment (no duplicates).
Post-DAD Configuration: The node configures the IPv6 address on all its interfaces. Sends
neighbor advertisements to inform other nodes about the address assignment.
IPv6 Communication:
lo
Router Solicitation: An IPv6-configured node sends a router solicitation message (multicast
packet) to discover routers in its network segment. Routers respond by advertising their
presence; the responding router is set as the node’s default gateway. If the selected gateway
becomes unavailable, a new one is selected through the same process.
C
Redirect Message: If a router receives a solicitation and determines it is not the best option as
a gateway, it sends a redirect message to inform the node of a better router available in the
next hop.
IPv6 Mobility:
tu

Home Address: A mobile IPv6 node uses its home address for routing communication while
within its home link.
Foreign Link and Care-of-Address (CoA): When the mobile node leaves its home link, it
connects to a foreign link and acquires a new IPv6 address, known as the care-of-address
(CoA).
V

Binding and Tunnel Establishment: The mobile node binds its CoA to its home agent
(router/gateway in its home segment) by establishing a tunnel between them.
Message Forwarding: Correspondence messages to the mobile node’s home address are
forwarded to its CoA over the established tunnel.
Route Optimization: The mobile node can choose to communicate directly with a
correspondent node using its home address as the source address, bypassing the home agent.
This process is called route optimization.
8.2.2 LOADng
LOADng: Lightweight On-demand Ad hoc Distance vector Routing Protocol – Next
Generation. Inspired by the AODV (Ad hoc On-Demand Distance Vector) routing protocol.
Characteristics: Developed as a reactive protocol addressing the challenges of Mobile Ad hoc
Networks (MANETs).
Route Discovery Process:
1. Initiation: Starts with a LOADng router initiating route discovery by generating route
requests (RREQs).
2. Forwarding RREQ: The router forwards the RREQ packets to its nearest connected

ud
neighbors. Neighbors then forward the packets to their one-hop neighbors. This
continues until the intended destination is reached.
3. Route Reply:Upon receiving the RREQ, the destination sends back a route reply
(RREP) packet to the originating router.
4. Route Error Handling: If a route is found to be down, route error (RERR) messages
are generated and sent to the origin router.
lo
C
tu
V

To summarize the operation of LOADng, a router performs the following tasks:

• Bi-directional network route discovery between a source and a destination.
• Route establishment and route maintenance between the source and the destination only
when data is to be sent through the route.
• Generation of control and signalling traffic in the network only when data is to be
transferred or a route to the destination is down.
Operational Principle
RREQ Transmission: A LOADng router transmits a route request (RREQ) upon receiving a
data packet for a destination with no existing routing entry. The RREQ is flooded over all
LOADng interfaces.
Flooding Operation:Each forward interface of the LOADng router is numbered (e.g., from 1
to 3 for three hops). The RREQ encodes the destination address from the local data source.
Routing Set Update: Upon receiving an RREQ, the routing set at each LOADng router updates
or inserts an entry containing: Originating address and Immediate neighbor LOADng router.
This process maintains a record of the reverse route from source to destination.

ud
Destination Address Check: The router checks the destination address: If intended for a local
interface, an RREP (route reply) is sent back using the reverse route. If not local, the RREQ is
forwarded to other LOADng interfaces using hop-by-hop unicast (flooding).
RREP Handling: When an RREP is received, it is recorded in the routing entry, indicating the
forward path toward the origin of the RREP. The LOADng router also updates route metrics
based on the RREQ and RREP messages.
Metric Determination: The LOADng router determines the desired metric to be used for
lo
routing based on the received messages.

8.2.3 RPL
RPL: Routing Protocol for Low-Power and Lossy Networks, designed for IPv6 routing.
C
Utilizes a distance vector-based routing mechanism.
DODAG Formation:
• Aims to create a Destination-Oriented Directed Acyclic Graph (DODAG).
tu

• The DODAG is a logical routing topology built over a physical network.

• Formation criteria set by network administrators based on an objective function and
network metrics.
Metrics and Constraints:
V

• Metrics: Expected Transmission Values (ETX), Path latencies, Others that may be
maximized or minimized.
• Constraints: Link encryption, Battery-operated nodes, Others that must be minimized.
Objective Function:
• Dictates the rules for DODAG formation.
• A single node can have multiple objective functions due to varying traffic path quality
requirements within the same mesh network.
Multiple RPL Instances:
 • Nodes can join more than one RPL instance (graphs), supporting QoS-aware and
constraint-based routing.
Node Roles: An RPL node can simultaneously function as:Leaf node, Router, Other roles as
needed.
RPL Border Router: Functions as the RPL root and manages intra-mesh addressing.

ud
lo
C
tu

RPL Instances
Types of RPL Instances:
• Global RPL Instances: Characterized by coordinated behavior., Can have multiple
DODAGs (Destination-Oriented Directed Acyclic Graphs), Generally have a long
V

lifetime.
• Local RPL Instances: Characterized by single DODAGs. The root of the local
DODAG is directly linked to the DODAG-ID.
Instance ID Allocation: RPL instance IDs are collaboratively and unilaterally allocated. The
IDs are divided between global and local instances.
Control and Data Messages:RPL control and data messages are tagged with their
corresponding RPL instance IDs. This tagging helps to avoid ambiguity in operations between
different instances.
8.2.4 6LoWPAN
6LoWPAN stands for IPv6 over Low-Power Wireless Personal Area Networks. It enables
low-power and constrained devices to connect to the Internet.
Purpose: Designed to support IPv6 in networks with limitations in power, communication
range, memory, and throughput. Extends IPv6 networking capabilities to IEEE 802.15.4-based
networks.
Key Features: Supports 128-bit IPv6 addresses for constrained IEEE 802.15.4 devices. Uses
header compression to fit IPv6 packets into the smaller IEEE 802.15.4 packet format.
Device Types:

ud
Reduced Function Devices (RFD):
•
o Limited in throughput, processing, memory, and range.
o Must forward data to Full Function Devices (FFD) for access to IP-based
networks.
• Full Function Devices (FFD):
o Have significantly better capabilities than RFDs.
lo
o Responsible for forwarding data from RFDs to the 6LoWPAN gateway.
Communication Process:
• Data from RFDs is forwarded to FFDs in a multi-hop manner.
• The 6LoWPAN gateway connects packets to the IPv6 domain.
• Packets are then forwarded to the destination IP-enabled node/device using standard
C
IPv6 networking.
Applications: Commonly used in: Smart grids. Machine-to-Machine (M2M) applications.
Internet of Things (IoT).
6LoWPAN Stack
tu

The 6LoWPAN stack operates on top of the IEEE 802.15.4 PHY (Physical) and MAC
(Medium Access Control) layers, designed for low-rate wireless personal area networks (LR-
WPAN).
This stack enables low-power devices to communicate using IPv6 in constrained environments.
V

• PHY and MAC Layers:

o The PHY layer includes 27 wireless channels, each with its own frequency band
and data rates.
o The MAC layer defines methods for accessing these channels and includes:
▪ Beaconing tasks for device identification and synchronization.
▪ CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) for
channel access control.
▪ PAN membership control, managing device association and dissociation.
• Adaptation Layer:
 o Functions as a bridge between the MAC and network layers, enabling IPv6
capabilities over IEEE 802.15.4 devices.
o Addresses challenges such as header compression, packet forwarding, and
fragmentation to fit IPv6 packets within the constraints of IEEE 802.15.4.
Address Format:
6LoWPAN addresses consist of:
• Short Address (16-bit): PAN-specific and valid only within a local network.
• Extended Address (64-bit): Globally unique and valid outside the local network.

ud
Encapsulation Header Formats:
• Encapsulation headers are used to encapsulate IPv6 payloads within IEEE 802.15.4
frames.

lo
C
tu
V

There are three header types:

1. Dispatch Header: Initiates communication between nodes.
2. Mesh Addressing Header: Supports multi-hop forwarding by enabling layer 2
message forwarding.
3. Fragmentation Header: Allows large payloads to fit into the smaller IEEE 802.15.4
frame size.
• Payload Size Considerations:
o IPv6 requires a minimum payload of 1280 octets, while IEEE 802.15.4 supports a
maximum of 1016 octets.
o The available space for IPv6 packets is significantly limited after accounting for
frame overheads and additional options (like security), often leaving insufficient
space for complete IPv6 packet transmission.
Key Takeaways:

ud
• The 6LoWPAN stack is crucial for integrating low-power devices into the IPv6
framework, enabling them to communicate effectively in constrained network
environments.
• Efficient header management and encapsulation strategies are essential to fit IPv6
packets into the limited size of IEEE 802.15.4 frames.

Encapsulation Header Formats

lo
Encapsulation headers: Define methods to encapsulate IPv6 payloads within IEEE 802.15.4
frames.
Header types: There are three main types of 6LoWPAN encapsulation headers:
1. Dispatch header: Initiates communication between nodes.
C
2. Mesh addressing header: Supports multi-hop forwarding for layer two message
forwarding.
3. Fragmentation header: Helps fit large payloads into the IEEE 802.15.4 frame size.
Similar to IPv6 extension headers: The header types are identified by a field placed before
tu

the headers.
V
 ud
8.2.5 QUIC
lo
QUIC (Quick UDP Internet Connections): Developed as a low-latency, independent
alternative to TCP.
Primary goal: Achieve near-zero round-trip-time latency in communication.
Features: Supports stream and multiplexing, similar to Google's SPDY protocol.
C
Development: Continues to undergo improvements.
tu
V

Reduced connection latency in QUIC: Achieved by minimizing round trips required for tasks
like handshaking, data requests, and encryption exchanges.
Session negotiation: Included in the initial packet to streamline connection establishment.
Server optimization: QUIC servers publish static configuration records for connections.
Client-server synchronization: Clients use cookies received from QUIC servers to
synchronize connection information.

ud
lo
Congestion avoidance in QUIC: Achieved through techniques like packet pacing and
proactive speculative retransmission.
C
Proactive speculative retransmission: Sends essential packets with encryption and error
correction information multiple times.
Data compression: Reduces redundancy, speeding up connections by compressing repetitive
data like headers.
tu

Multiple secured requests: QUIC allows multiple secured requests within a single congestion
window, unlike TCP.
Improved streaming performance: UDP and multiple transmission paths enhance packet
streaming speed in QUIC compared to regular HTTP.
Illustration: Figure 8.9 compares performance between regular HTTP and HTTP-over-QUIC
V

during packet streaming.

8.2.6 Micro internet protocol (uIP)

Micro-IP (uIP) protocol: Extends the TCP/IP protocol stack to 8-bit and 16-bit
microcontrollers.
Developed by: Swedish Institute of Computer Science (SICS) as an open-source protocol.
Key advantages: Low code space, Low memory requirements
Target use: Networking low-cost, low-power embedded systems.
IPv6 support: uIP now includes a full IPv6 stack, developed with collaboration from Atmel,
Cisco, and SICS.

uIP unique features:

ud
1. No OS required: uIP doesn't need an operating system, making it easy to integrate
with small computers.
2. Network management: Handles all network behaviour and connection retries when
run in a timed loop.
3. Hardware driver: Manages packet building, sending, and response reception.
lo
4. Minimal packet buffer: Uses a single packet buffer, ideal for low-power operations.
5. Half-duplex buffer: The same buffer is used for both transmission and reception.
6. No retransmission buffers: Data for retransmission is not stored but reproduced
from the application code.
C
7. Connection management: Stores connections in an array and serves them
sequentially, unlike conventional IP protocols where each connection has its own task.
tu

8.2.7 Nano internet protocol (nanoIP)

Nano Internet Protocol (NanoIP): Designed for embedded devices, particularly low-power
sensor devices, to enable internetworking.
Purpose: Enables wireless networking among sensor devices with less overhead than
traditional TCP/IP stacks.
V

Transport mechanisms:
• nanoUDP: Similar to conventional UDP, provides unreliable transport.
• nanoTCP: Analogous to TCP, supports packet retransmissions and flow control.
Networking: Uses device hardware (MAC) addresses instead of logical addresses.
Port range: 256 ports for both source and destination nodes, based on an 8-bit port
representation.
Associated protocols: Includes protocols like nHTTP and nPing for extended functionality.
Illustration: Figure 8.11 shows the nanoIP TCP and UDP protocol stacks.
 ud
lo
8.2.8 Content-centric networking (CCN)
Content-Centric Networking (CCN): Also known as Information-Centric Networking
(ICN), Named Data Networking (NDN), or Publish-Subscribe Networking (PSIRP).
Key feature: Communication is based on uniquely named data, independent of location,
application, or storage requirements.
C
Anchorless architecture: Allows for mobility and focuses on in-network caching.
Benefits:
• Improved data and communication efficiency
tu

• Enhanced scalability and robustness, even in constrained networks

Security: Focuses on securing the data itself, not the communication channel.
Illustration: Figure 8.12 shows how users access cached content from multiple content
sources via trusted servers.
V
 ud
lo
Forwarding in CCN: Based on hierarchical prefix matching, typically using the longest prefix
C
match.
Prefix matching: Performed through binary comparison with the Forwarding Information
Base (FIB).
Request structure: CCN requests are hierarchical sequences of network path segments.
tu

FIB usage: Matches and forwards the named request to the appropriate network or segment
for a response.
Reverse path determination: The forwarder also determines the reverse path from the
responder to the requester.
V

No specific binding: Requests are not bound to any particular network endpoint.
FIB updates: Stored in a table and updated by the routing mechanism.
Path and name limits: Theoretically unbounded but restricted by the routing protocol in
practice.
8.3 Discovery Protocols
We cover three interesting discovery protocols in this section: 1) Physical web, 2) mDNS, and
3) universal plug and play (UPnP).
Physical Web
A system designed to enable seamless interaction with physical objects and locations via the
web. Provides information through web pages or dynamic web applications.
Examples:
• Smart buses providing route-related updates.

ud
• Smart home appliances guiding new users.
• Self-diagnostic industrial robots and machinery.
• Smart pet tags sharing pet and owner information.
Core Concept:
• Integrates standalone smart systems via the web for on-demand information delivery.
lo
• Broadcasts a list of URLs within a short range, allowing users nearby to interact.
Technology:
• Based on Bluetooth Low Energy (BLE):
o Efficient, widely available, and long battery life.
C
• Uses the Eddystone protocol for URL broadcasting.
Role of URLs:
• Central to the physical web's functioning.
tu

• Supports flexibility and decentralization.

• Extends benefits of web security:
o Secured login
V
 ud
lo
Multicast DNS (mDNS)
o A system for resolving IP addresses in small networks, similar to regular DNS.
C
o Operates without a local name server (zero-configuration service).
Functionality:
o Uses multicast UDP for host name resolution.
tu

o An mDNS client sends a multicast query, prompting a remote host to identify

itself.
o Responses update the mDNS cache in the network subnet.
o Nodes can release domain names by setting TTL to zero in response packets.
V

Features:
o Can work alongside regular DNS systems.
o Designed for easy setup and operation in small networks.
Examples of Use:
o Apple Bonjour for device discovery.
o Windows 10 networked printer discovery service.
Limitations: Limited to resolving host names within the top-level domain only.
Universal Plug and Play (UPnP)
Definition: A set of networking protocols for service discovery and enabling dynamic
device connections and communication.
Key Features:
o Plug and Play: Devices self-configure and inform hosts of their configurations
over the network.
o Designed for non-enterprise devices like mobiles, printers, access points,
gateways, and televisions with IP capabilities.
Management:

ud
o Supported by a forum of consumer electronics vendors.
o Managed by the Open Connectivity Foundation.
Technology Stack:
o Operates on IP-enabled networks.
o Utilizes HTTP, XML, and SOAP for:
▪

▪
lo
Data transfer.
Device descriptions.
▪ Event generation and monitoring.
C
o Employs UDP-based HTTP for:
▪ Multicasting device search requests and advertisements.
▪ Unicast responses to device requests.
tu

Port Usage: UDP port 1900 is used for multicasting advertisements.

Limitations:
o High overhead and traffic due to multicast behavior.
o Unsuitable for enterprise systems due to operational cost inefficiencies at scale.
V
 ud
8.4 Data Protocols
lo
The protocols covered in this section are directly related to access, storage, and distribution of
data through the IoT network. The data may be transferred between clients and servers as well
C
as between brokers and subscribers in the IoT ecosystem. This section is further divided into
seven parts: 1) MQTT, 2) MQTT-SN, 3) CoAP, 4) AMQP, 5) XMPP, 6) REST, and
7) websockets.
tu

MQTT
Definition: Lightweight publish–subscribe messaging protocol for constrained devices
and networks.
Features:
V

o One-to-many message distribution.

o Payload agnostic.
o Reliable in high-latency, low-bandwidth, and unreliable networks.
o Requires minimal device resources and power.
Architecture:
o Server (broker) connects multiple clients.
o Clients act as publishers (send messages) or subscribers (retrieve messages).
 Advantage: Operates independently of specific applications.

ud
Operational Principles
1. Communication:
o Uses TCP for network communication.
lo
o Relies on hierarchical topics for message distribution.
2. Message Flow:
o Publishers send control and data messages to brokers.
o Brokers distribute topic content to relevant subscribers.
C
o Messages are discarded if no subscribers exist, unless specified otherwise.
3. Key Features:
o Decouples publishers and subscribers from addressing/network considerations.
tu

o Reduces redundancy and storage needs by providing updated information.

o Supports a last will and testament feature for default messages upon abrupt
disconnections.
o Multiple brokers can collaborate to ensure message delivery across networks.
V

4. Message Structure:
o Control message sizes: 2 bytes to 256 MB, with a fixed header size of 2 bytes.
o Connection credentials are unencrypted; security relies on the TCP layer.
5. Message Types:
o Includes 14 types, such as CONNECT, PUBLISH, SUBSCRIBE,
DISCONNECT, and acknowledgments (PUBACK, SUBACK, etc.).
6. Quality of Service (QoS) Levels:
o At most once: Best-effort delivery; possible duplication or loss.
 o At least once: Guaranteed delivery but may result in duplication.
o Exactly once: Ensures delivery without duplication.
7. Advantages:
o Reduces network traffic.
o Supports constrained networks and devices.
MQTT-SN
MQTT for Sensor Networks (MQTT-SN) is a variant of MQTT, designed to address the
specific needs of wireless communication in sensor networks.

ud
1. Key Features:
o Low bandwidth usage and resilience to high link failure conditions.
o Optimized for low-power, low-cost constrained nodes and networks.
o Suitable for environments with bandwidth-constrained networks.
2. Differences from MQTT:
lo
o CONNECT message is split into three parts, with two optional parts for
testament message and topic communication.
o Topic identifiers (2 bytes) replace full topic names in PUBLISH messages,
reducing traffic.
C
o Topic name registration is a separate process, with identifiers communicated
to publishers/subscribers.
o Pre-defined topic identifiers eliminate the need for registration in some cases.
o Discovery process links publisher/subscriber to broker's network address in
tu

absence of preconfigured address.

3. Session Management:
o Persistent subscriptions, Will topic, and Will messages allow modification
during a session.
V

o Supports sleeping publishers/subscribers through a keep-alive procedure to

buffer messages until they wake up.
4. Gateway Types:
o Transparent Gateway: Creates multiple connections to the MQTT broker
based on MQTT-SN nodes.
o Aggregating Gateway: Creates a single connection to the MQTT broker for all
MQTT-SN nodes.
5. Advantages:
 o Efficient for wireless and sensor networks with limited resources and
fluctuating connectivity.
o Enhanced flexibility for managing communication between constrained
devices.

ud
lo
SOAP (Simple Object Access Protocol)
SOAP is a protocol for exchanging structured information in web services using XML
C
formatting over application layer protocols like HTTP and SMTP.
1. Key Features:
o Platform and Language Independent: Uses XML, allowing communication
tu

between systems with different operating systems.

o Facilitates the messaging layer of web services protocols.
o A SOAP request is sent to a server, which responds in a structured SOAP format,
easily integrated into the requester’s application.
V
 ud
2. Components:
o Envelope: Defines message structure and processing instructions.
o Encoding Rules: Handles various data types from different applications.
lo
o Convention: Responsible for web procedure calls and responses.
3. Advantages:
o Neutrality: Can operate over any application layer protocol.
o Independence: Not tied to specific programming models.
C
o Extensibility: Features like security and web service addressing can be added.
4. Network Benefits:
Can pass through firewalls and proxies without modification (similar to
tu

o
tunneling).
5. Limitations:
o XML Parsing can affect performance due to the verbose nature of SOAP.
o Not always suitable for systems requiring fast communication.
V
 ud
6. Architecture:
o Defined across several layers: message format, message exchange patterns
(MEP), transport protocol binding, message processing, and protocol
extensibility.
lo
WebSocket (WS)
C
WebSocket is an IETF-standardized, full-duplex communication protocol that enables real-
time, reliable communication over a single TCP connection. It is an OSI layer 7 protocol.
1. Key Features:
tu

o Full-Duplex Communication: Allows two-way communication between client

and server.
o Compatibility with HTTP: Works over HTTP ports 80 and 443, ensuring
compatibility with existing network mechanisms such as proxies and firewalls.
o Persistent Connection: Once established, the connection remains open,
allowing the server to push data to clients without needing a request.
V

2. Advantages:
o Real-Time Data Transfer: WebSocket enables real-time, efficient data
exchange with minimal overhead.
o Improved Efficiency: Unlike HTTP, WebSocket maintains an open connection,
reducing the need for repeated requests.
3. Comparison with HTTP:
o HTTP is request-response based, while WebSocket supports bi-directional
full-duplex communication.
 o WebSocket uses TCP, enhancing byte and message stream transfers.
4. Historical Context: Comet channels were used before WebSocket for full-duplex
communication but were complex and inefficient, making them unsuitable for
constrained environments like IoT.
5. Security: WS for unencrypted connections, and WSS for encrypted connections
(secure WebSocket).
6. Browser Support: Supported in most modern browsers, but the server must also
support WebSocket to enable communication.
7. Technical Details: WebSocket connections are initiated via a handshake process and

ud
can be inspected using browser developer tools.
Operational Principle:
Connection Establishment:
o The client initiates the connection with a WS handshake request.
o The server responds with a WS handshake response, using the HTTP protocol
to initiate the handshake.

o
lo
Securing the Connection:
The client sends an update header and a sec-websocket-Key (base64-encoded
random bytes).
o The server replies with a hashed response in the Sec-WebSocket-Accept
C
header, which helps bypass caching proxies.
Key Hashing Process: A fixed string is appended to the Sec-WebSocket-Key and
hashed using SHA-1 before being encoded with base64.
tu

Full-Duplex Communication:
o Once the connection is established, WebSocket operates as a bidirectional
protocol, separate from HTTP.
o Minimal headers and payloads (data or text) are exchanged over the connection.
Message Splitting & Multiplexing:
V

o WS messages can be split into multiple data frames when the full message
length is not available.
o Multiplexing allows multiple streams over the same connection, preventing
large payloads from monopolizing the WebSocket port.
8.5 Identification Protocols
With the exponential rise in IoT devices, securely identifying each device has become a
significant challenge. As the number of connected "Things" continues to grow, the need for
effective protocols to provide unique identifiers is crucial. Global efforts have led to the
development of solutions such as EPC, uCode, and URIs to address these challenges. This
section explores the various aspects and nuances of each of these identification methods.

EPC (Electronic Product Code)

• Purpose: EPC is a universal identifier system designed to provide unique identities to

ud
all physical objects worldwide.
• Standard: The EPC structure is defined by the EPCglobal Tag Data Standard, which
is an open and free standard.
• Representation: EPC is officially represented as a Uniform Resource Identifier
(URI), known as the pure identity URI.
• Applications: Used in business systems and application software to refer to physical
lo
objects, facilitating communication and information exchange.
• Formats: EPC supports both URI and binary encoding formats for identifier storage,
crucial for systems like passive RFIDs with limited memory.
• Flexibility: EPC is compatible with various coding schemes, including barcodes, and
is data carrier-agnostic, making it adaptable to different technologies.
C
• Support: The standard supports EPC identifiers, general identifiers, and seven types of
identification keys from the GS1 Application Identifier system.
tu
V
 Chapter 9
IoT Interoperability
9.1 Introduction
Growth of Connected Devices: The rise of billions, potentially trillions, of connected devices
under IoT has driven the evolution of interoperability.
Need for Standards: With more manufacturers entering the IoT space, there is an increasing
demand for uniform and standardized solutions to ensure seamless communication.
Definition: Interoperability refers to the ability of different systems—hardware, software, or

ud
middleware—to connect, communicate, and exchange data or services smoothly, regardless of
make, model, manufacturer, or platform.

lo
C
Challenges in IoT Interoperability
tu

1. Large-scale Cooperation: IoT involves a vast number of devices, systems, standards,

and platforms, requiring coordination and cooperation. Proprietary solutions are
costly and non-reusable, making interoperability crucial for cost-effective solutions.
2. Global Heterogeneity: IoT devices and networks are globally distributed, creating a
need for a unified standard or syntax to connect heterogeneous devices seamlessly
across the Internet.
V

3. Unknown IoT Device Configuration: IoT devices come with varying configurations
(e.g., data rates, protocols, frequencies), which are often unknown before deployment,
adding complexity to achieving interoperability.
4. Semantic Conflicts: Differences in data processing logic across IoT devices, sensors,
and platforms hinder rapid deployment and create semantic conflicts, complicating
integration and interaction among systems.
Sources of Heterogeneity in IoT:
• Communication Protocols: ZigBee, Bluetooth, GPRS, Wi-Fi, Ethernet, etc.
 • Programming Languages: Java, C++, Python, Visual Basic, etc.
• Hardware Platforms: Crossbow, National Instruments, etc.
• Operating Systems: TinyOS, Windows 10 IoT Core, vendor-specific OS.
• Databases: MySQL, Oracle, PostgreSQL, etc.
• Data Representations: CSV, JSON, RTF, integers, etc.
• Control Models: Event-driven, client-server, publish–subscribe, etc.

Taxonomy of IoT Interoperability

ud
1. Device Interoperability: IoT ecosystems consist of various devices (low-end, mid-
end, high-end), each with different processing power, energy requirements, and
communication capabilities. Low-end devices typically use low-power
communication schemes and are deployed in large numbers. Interoperability is
needed for communication between these devices and high-end devices like
smartphones or tablets.lo
2. Platform Interoperability: Variations in operating systems (e.g., Contiki, TinyOS),
programming languages (e.g., Python, Java), and application environments create
platform-level differences. Platforms like Android and iOS are often incompatible,
requiring solutions for interoperability between different system environments.
3. Semantic Interoperability: Conflicts arise due to different data models (e.g., XML,
C
CSV, JSON) and ontologies, which affect how data and knowledge are shared across
devices, applications, and services. Ensuring semantic interoperability is critical for
meaningful communication, especially in Web of Things (WoT) scenarios.
4. Syntactic Interoperability: Conflicts between data formats, interfaces, and schemas
tu

can lead to stability issues and inefficiencies. For instance, a mismatch in the order of
sensor data in packets can cause syntactic errors even if the data is the same. Proper
syntax alignment is crucial for smooth data exchange.
5. Network Interoperability: The diverse range of connectivity solutions (both wired
and wireless) used in IoT requires network interoperability. Different networks and
sub-networks, along with uplink solutions, must integrate seamlessly to ensure
V

reliable, interoperable device operations across various network infrastructures.

9.2 Standards
Toward enabling IoT interoperability, various technologies have been standardized and are
recognized globally for incorporating consistent interoperability efforts worldwide across
various industries, domains, and technologies.
EnOcean
EnOcean is a wireless technology designed for building automation systems, primarily based
on energy harvesting principles. It is widely used in industries, transportation, logistics, and
homes due to its robustness and low power consumption. EnOcean devices are battery-free,
using ultra-low power electronics and energy harvesting modules that convert micro-level
variations in electric, electromagnetic, solar, or other forms of energy into usable energy. These
devices include sensors, switches, controllers, and gateways, enabling wireless communication
with no need for maintenance.
EnOcean operates on frequencies such as 902 MHz, 928.35 MHz, 868.3 MHz, and 315 MHz,
with a data rate of 125 kbit/s. Wireless packets are typically 14 bytes long, contributing to low
energy consumption. The system transmits RF energy only during the transmission of binary

ud
messages, further optimizing energy efficiency. EnOcean devices can communicate over
distances of up to 30 meters indoors and 300 meters outdoors. It was adopted as a wireless
standard under ISO/IEC 14543-3-10 in 2012, covering the physical, data link, and networking
layers.

lo
C
tu
V

DLNA (Digital Living Network Alliance)

DLNA, originally known as the Digital Home Working Group (DHWG), was established in
2003 by a consortium of consumer electronics companies to promote interoperability for digital
media sharing among devices like smartphones, smart TVs, tablets, and multimedia servers.
Designed primarily for home networking, DLNA relies on WLAN for device communication
and can integrate with cable, satellite, and telecom service providers to ensure data protection.
A key feature is its inclusion of digital rights management (DRM) to prevent piracy during
multimedia data sharing.
DLNA supports over a billion devices globally, enabling seamless multimedia streaming across
a variety of consumer devices such as TVs, phones, and PCs without additional add-ons
through services like VidiPath. DLNA defines several key components that enable
interoperability, including:
1. Network and Connectivity
2. Device and Service Discovery and Control
3. Media Format and Transport Model
4. Media Management, Distribution, and Control
5. Digital Rights Management and Content Protection

ud
6. Manageability

lo
C
tu

Konnex (KNX)
KNX (Konnex) is an open, royalty-free wired standard used for Home Automation Networks
(HAN), primarily designed for building automation in domestic settings. It allows for
communication over various physical mediums, including twisted pair, power line, RF (KNX-
RF), and IP-based systems (KNXnet/IP). KNX evolved from three previous standards:
BatiBUS, European Home Systems Protocol (EHS), and European Installation Bus
V

(EIB/Instabus).
KNX is widely used in controlling various systems such as lighting, HVAC, security,
audio/video, and energy management. The network is based on distributed applications and
interaction through standard data types and logical devices, creating an interworking model for
automation. The architecture includes sensors, actuators, controllers, and other system
components, which can be configured using three modes:
1. Automatic mode (A mode): Auto-configurable devices installed by end users.
2. Easy mode (E mode): Devices requiring initial training, where behavior is pre-
programmed.
 3. System mode (S mode): Complex devices requiring specialist installation for
advanced building automation.
KNX uses a twisted pair bus for communication and can accommodate up to 57,375 devices.
It also allows integration of sub-networks via IP for remote or centralized control over LAN
or phone networks.

ud
lo
C
UPnP (Universal Plug and Play)
Universal Plug and Play (UPnP) is a set of protocols designed primarily for home networks,
tu

enabling devices like PCs, printers, mobile devices, gateways, and wireless access points to
discover and communicate with each other. UPnP allows devices to establish connections,
share data, and dynamically join networks without requiring manual configuration, a feature
known as zero-configuration networking.
UPnP relies on standard protocols like TCP/IP, HTTP, XML, and SOAP. Devices in a UPnP
V

network can automatically assign themselves IP addresses using DHCP or AutoIP and advertise
their presence via the Simple Service Discovery Protocol (SSDP) over HTTP multicast. When
a device is discovered, a control point (CP) retrieves its information in an XML format, which
includes a list of services and actionable commands.
Key features of UPnP include:
• Zero Configuration: Devices automatically join the network, discover others, and
configure themselves.
• Device Control: Control points can send commands to devices, manage services, and
monitor device status.
 • Cross-Platform Support: UPnP is OS and language independent, using web
browsers for user interfaces.
• Multimedia & Connectivity: UPnP supports a range of media types (Ethernet, Wi-Fi,
Bluetooth) and enables integration of non-UPnP devices via bridges.
UPnP is widely used in home automation and media sharing applications, and is managed by
the Open Connectivity Forum (OCF) as of 2016.

ud
lo
LonWorks
C
LonWorks (Local Operating Network) is a network protocol developed by Echelon Corp,
primarily for control applications in buildings. It enables devices to communicate over various
physical media, including twisted pair, fiber optic cables, power lines, and RF. LonWorks
tu

supports differential Manchester encoding for twisted pair communication, with a data rate of
78 kbit/s, while powerline communication operates at slower speeds (5.4 kbit/s or 3.6 kbit/s
depending on the frequency).
LonWorks was standardized as LonTalk by ANSI in 1999 and has since been used in a wide
range of applications, such as train braking systems, semiconductor manufacturing, petrol
station controls, and building automation. It provides backward compatibility through an IP-
V

based tunneling standard (ISO/IEC 14908-4), allowing seamless integration with modern IP-
based services.
The core component of LonWorks devices is the Neuron chip, which includes three processors
for different tasks:
• MAC Processor: Handles message transmission, CRC checks, and destination
confirmation.
• Network Processor: Manages addressing, routing, and network layer tasks.
• Application Processor: Supports custom applications and can also act as a
communication co-processor.
LonWorks is known for its robustness, real-time performance, and ability to operate in diverse
environments, making it ideal for distributed control systems in building automation.

ud
lo
Insteon
Insteon is a home automation technology developed by Smartlabs in 2005 and marketed under
C
its subsidiary Insteon. It enables interoperability and automation of household devices such as
lights, switches, thermostats, and sensors (motion, gas, etc.), using both RF (radio frequency)
and powerline communication.
Key Features:
tu

1. Dual Mesh Network Topology: Insteon devices form a mesh network where each
device can independently transmit and receive messages, ensuring reliable
communication.
2. Powerline Communication: Insteon devices communicate over the powerline at a
frequency of 131.65 kHz using Binary Phase Shift Keying (BPSK), with a minimum
V

receive signal level of 10 mV.

3. RF Communication: Devices using RF communication operate at 915 MHz, using
Frequency Shift Keying (FSK) and Manchester encoding for data transmission. These
devices can transmit at a rate of 4.56 kbit/s with a range of approximately 120 meters
without obstructions.
Technical Specifications:
• Unique IDs: Insteon networks can support over 16 million unique IDs and up to 65,000
devices.
 • Memory: Devices have a built-in engine with 80 bytes of RAM, 3 kB of ROM, and
some devices may include additional memory (256 bytes of RAM, 7 kB flash memory
for application-specific requirements).
• Data Rate: The average data rate is 180 bits per second, with standard messages of 10
bytes and extended messages of 24 bytes.
• Message Structure: Insteon messages can include up to 14 bytes of user data and have
a two-bit field for counting hops, enhancing message reliability through error detection
and retransmission.
Reliability and Synchronization: Devices transmit the same message simultaneously using
PSK (Phase Shift Keying), synchronized with the powerline frequency, improving message

ud
integrity and signal strength across the network.
Insteon is known for its flexibility, robust communication capabilities, and ability to support a
large number of devices, making it suitable for home automation systems.

lo
C
tu

The dual mesh/dual band network topology of Insteon refers to its use of both RF (radio
frequency) and powerline communication to transmit data. This setup allows the system to
mitigate interferences typically encountered in one communication band by switching to the
other. Here's how it works:
V

• Powerline Communication: When interference is detected over the RF band, data

transmission can be shifted to the powerline, ensuring seamless communication even
in the presence of RF noise.
• RF Communication: Similarly, if powerline communication experiences disruptions,
the system can fall back to RF communication to maintain stable data flow.
This dual-band approach enhances the reliability and robustness of the network, as it can use
either communication channel depending on the conditions.
Peer-to-Peer Network Operation
Insteon operates as a peer-to-peer network, meaning devices can communicate directly with
each other without the need for a central controller. This makes the network highly
decentralized and flexible. However, central controllers can still be integrated, such as
through smartphone or tablet applications, to provide extended control and remote management
of the devices in the network.
Security Measures
Insteon employs a security mechanism to prevent unauthorized devices from joining the
network:
• Physical Ownership Requirement: Users must physically own the devices they intend
to add to the network. This prevents the hijacking of devices or unauthorized access to

ud
the system.
• Unique Device IDs: Each Insteon device has a unique identifier (similar to a MAC
address), which must be used to connect the device to the network.
• Physical Pairing: During installation, users must press a button on each device to allow
it to connect to the network. This physical action ensures that only devices the user
physically controls can join the network, preventing unauthorized devices from being
lo
paired.
This physical pairing process, combined with the use of unique IDs, provides a level of security
that helps protect Insteon networks from unauthorized access or tampering.

X-10 Protocol:
C
• Origin: Developed by Pico Electronics in 1975 for home automation via powerlines.
• Technology: Uses household electrical wiring for communication by encoding data
over a 120 kHz carrier frequency transmitted during zero crossings of 50-60 Hz AC
tu

signals.
• Data Encoding: Data is sent as RF bursts, one bit per crossing, containing an address
and a command.
• Network Structure: Allows 256 possible addresses using 4-bit house codes, unit
codes, and commands.
V

• Device Types: Includes one-way devices (receive commands) and two-way devices
(send/receive commands).
• Data Transmission: 1 ms burst for a 1-bit; 20 bit/s data rate; commands limited to
basic functions (on/off).
• Reliability: Data frames transmitted twice for redundancy and reliability, with
commands separated by 6 zero crossings.
• Wireless Integration: RF protocol for wireless remotes/switches operates on 310
MHz (US) and 433.92 MHz (Europe).
 • Control: Devices can be controlled via powerline or wireless connection, with radio
receivers bridging the two.

ud
9.3 Frameworks lo
Similar to the standards, there has been a rise in universal interoperability frameworks. These
frameworks span across platforms, devices, technologies, and application areas.
universAAL:
• Purpose: An open-source software framework designed to support distributed,
C
service-oriented environments, primarily in systems of systems.
• Interoperability: Enhances semantic interoperability by sharing compatible models
and ontologies with service consumers (e.g., mobile devices, embedded systems).
• Components:
tu

o Managers: Low-level applications providing functional APIs for final

applications.
o Middleware: Coordinates core communication among nodes in a peer-to-peer
connectivity layout, called uSpace.
V

o Exporters: Interface hardware (sensors, actuators) with the universAAL

platform via specific technologies (e.g., Zigbee, Konnex).
• uSpace: Logical environment where communication semantics (ontology model,
service interactions, etc.) are shared, enabling interaction regardless of device or
technology.
• Coordinator Node: Manages the creation, status tracking, and node
additions/removals in a uSpace.
• Container: Supports middleware, code, and rules for various environments (Java,
Android, embedded systems).
 • Communication: Critical for semantic information flow, achieved via purpose-
specific buses (context, service, user interactions, etc.).
• UPnP-like Connector: Facilitates node discovery and multi-technology bridging.
• uSpace Gateway: Manages communication across different uSpaces, including
message exchanges and authentication.

AllJoyn Framework:
• Overview: An open-source initiative proposed by Qualcomm in 2011, designed for
communication between nearby devices. Now managed by the Open Connectivity

ud
Forum (OCF) after merging with IoTvity in 2016.
• Interoperability: Promotes interoperability among devices and applications
regardless of platform, brand, or connection type (currently supports Wi-Fi).
• Client-Server Model: Devices operate as clients (consumers) or servers (producers).
Example: a proximity sensor (consumer) triggers appliances (producers) in a smart
home. lo
• Communication: Utilizes a D-Bus message bus for seamless discovery,
communication, and collaboration between devices.
• Key Services:
o Onboarding: Adding new devices to the Wi-Fi network.
C
o Configuration Service: Setting device attributes (e.g., language, passwords).
o Notification Service: Sending notifications (text, audio, images).
o Control Panel: Remote control of connected devices via apps.
tu

o Common Device Model: Unified monitoring of IoT devices, independent of

vendor.
• Extensibility: Can integrate other protocols via bridging and supports complex
functionalities like streaming audio to multiple devices.
V

IoTivity Framework:
• Overview: An open-source project hosted by the Linux Foundation, sponsored by
OSF. Developed to unify IoT devices (both wired and wireless) across the Internet,
ensuring robust interoperability.
• Compatibility: Interoperable and backward-compatible with AllJoyn, enabling
seamless integration of various devices.
• Communication: Uses CoAP at the application layer and requires devices to
communicate via IP at the network layer. Supports technologies like Wi-Fi,
Ethernet, Bluetooth Low Energy, Thread, Z-Wave, Zigbee, and others.
 • Core Functionalities:
o Discovery: Devices can find nearby devices and offer services.
o Data Transmission: Standardized message transmission between devices.
o Device Management: Managing connected devices.
o Data Management: Handling and organizing data across devices.
• Resource Hosting: Devices can publish discoverable resources (objects with types,
data, relationships, and methods) once they are connected, authenticated, and
authorized. Resources can be discovered by clients based on resource type or server
identifiers.

ud
• Context: Operates under the OCF Native Cloud 2.0 framework, focused on
enhancing IoT's benefits for enterprises.

Brillo Framework:
Lightweight IoT OS introduced by Google in 2015, based on Android. Supports Wi-Fi,
lo
Bluetooth Low Energy (BLE), with future support for Thread. Ensures scalability, portability,
and interoperability across various devices and platforms.
Weave:
• Communication Layer: Connects devices and the cloud, providing a common
language for communication.
C
• Protocol: Uses TCP/UDP over IPv4/IPv6.
• Information Schema: Defines device types, functionalities, and communication
modes.
tu

Weave Stack Modules:

• Security Manager: Ensures secure communication.
• Exchange Manager: Manages data exchange.
• Message Layer: Handles device messaging.
V

• Fabric State: Tracks communication fabric status.

Core Functionalities:
• Bulk Data Exchange: File transfers.
• System Status/Error Reports: Feedback on system performance.
• Data Management: Device data management.
• Echo: Network connectivity testing.
• Security: Secure communication.
 • Service Directory: Tracks available services.
Secondary Protocols:
• Alarm, Device Control, Service/Network Provisioning, Heartbeat: Additional
functionalities for enhanced performance.

HomeKit Framework:
Designed by Apple to centralize device integration and control for smart home appliances
within the iOS ecosystem.

ud
• Key Features:
o Device configuration, communication, and control of smart home items (e.g.,
thermostats, lights, locks, cameras).
o Users interact via voice commands using Apple's Siri or through external apps.
o Devices can be controlled individually or in groups based on predefined
scenarios. lo
• Connectivity:
o Devices connect securely to a hub through Wi-Fi or Bluetooth.
o Bluetooth's range may limit the full potential of HomeKit.
• Device Compatibility:
C
o Manufacturers need to be part of Apple's MFi program.
o HomeKit-enabled devices initially required an encryption coprocessor (later
switched to software-based encryption).
tu

o Non-HomeKit devices can be integrated via HomeKit gateways/hubs.

V