UNIT-3

Design Principles for Web Connectivity in

IoT/M2M Device Networks
• To design an IoT/M2M device network gateway that enables web
connectivity for the accumulation, storage, and processing of data
from connected devices, it’s crucial to understand key concepts and
components that facilitate communication across the web. This
involves multiple layers of technology, protocols, and architecture.
• Let’s break down some of the critical components and design
principles you should understand:
1. Core Components in Web Connectivity

• IoT/M2M Device Network Gateway: A gateway acts as a bridge

between the IoT/M2M network and the internet, enabling devices to
communicate with external web services, applications, and databases.
The gateway is responsible for translating communication protocols
specific to IoT/M2M devices into formats compatible with web
protocols like HTTP or WebSockets.
• Server: This is the backend system that manages the storage,
processing, and management of the data received from connected
devices. The server hosts resources and facilitates communication
between clients (devices, applications) and the resources they need.
• Client: A client refers to any software or device that initiates
communication by making a request for data, messages, or resources.
Clients could be smartphones, browsers, or other IoT devices.
 2. Key Protocols and Communication Methods
• API (Application Programming Interface): An API is a set of rules that allow different software components
to communicate. It allows clients (like mobile apps or other servers) to request data or services from the
server. In the IoT context, APIs are typically used to send and receive device data.
• Web Service: This is a software service that communicates over the web using standard protocols like HTTP
or WebSockets. Web services enable external applications or devices to interact with your system, e.g.,
providing weather reports, controlling streetlights, etc.
• REST (Representational State Transfer): REST is an architectural style used to design networked
applications. It is commonly used for building scalable web services and APIs. RESTful APIs use HTTP
methods like GET, POST, PUT, and DELETE for interacting with resources. REST is lightweight, stateless, and
uses URIs to identify resources.
• WebSocket: WebSockets provide a full-duplex communication channel that allows for bidirectional
communication between client and server. Unlike HTTP, which is request-response based and
unidirectional, WebSockets are persistent, which makes them ideal for real-time applications.
• CoAP (Constrained Application Protocol): This protocol is optimized for low-power, low-bandwidth devices
typical in IoT systems. CoAP is similar to HTTP but designed for constrained environments.
• MQTT (Message Queuing Telemetry Transport): A lightweight messaging protocol that operates on a
publish/subscribe model. It is widely used for IoT applications because of its low overhead and ability to
send small amounts of data in a reliable and efficient manner.
• UDP (User Datagram Protocol): UDP is a connectionless protocol often used in environments where speed
is critical, and occasional data loss is acceptable. It’s used in scenarios like sending small sensor data
3. Data Representation & CommunicationData
Formats:
• JSON: The most commonly used data format for web APIs, especially in RESTful APIs. JSON is lightweight, easy
to read, and easy to parse.
• XML: Another widely used format for exchanging data, especially in SOAP web services. XML allows more
complex data structures and is highly extensible.
• MIME Types: Used to specify the type of data being sent or received, for example, application/json, text/html,
etc.
• Datagram: In networking, a datagram is a basic unit of communication in a network, typically small and self-
contained. For instance, the UDP protocol uses datagrams for sending data without needing to establish a
connection.
• RESTful HTTP: REST uses HTTP methods to interact with resources. HTTP defines how clients can request,
send, and modify resources. For example:
• GET: Retrieve information.
• POST: Create new resources.
• PUT: Update existing resources.
• DELETE: Remove resources.
• HyperText Transfer Protocol (HTTP): A protocol used for transferring hypertext requests and information on
the web. It is a request-response protocol, meaning that the client makes a request, and the server sends a
response.
4. Security and Firewall
• Firewall: In IoT/M2M networks, a firewall is necessary to protect servers from
unauthorized access. It monitors incoming and outgoing traffic and filters
potential threats.
• State Management: The state refers to the data or resources exchanged
between the client and server at a given point in time. For example, in a
weather monitoring system, the current state would include the latest
temperature data received from a sensor.
• Resource Identification: Resources (data or objects) need to be identified
uniquely, typically through URLs (Uniform Resource Locators) or URIs (Uniform
Resource Identifiers). A resource could represent a physical device (like a
temperature sensor) or a logical object (like a user’s contact information).
5. Design Considerations for Scalable Web Connectivity

• Statelessness: For scalability and reliability, the communication between client and
server should be stateless. This means that each request should contain all the
necessary information to complete the transaction, and the server does not need to
remember previous interactions.
• Scalability: IoT systems can have thousands or millions of devices. Design your
architecture to be scalable, meaning it can handle a growing number of devices,
users, or resources without degradation in performance.
• Latency: Minimizing latency (the delay in communication between devices and the
server) is important, especially in real-time applications like traffic monitoring or
healthcare. WebSockets and MQTT can help minimize latency compared to
traditional HTTP.
• Resource Discovery: It’s important to have mechanisms for resource discovery in
IoT systems. This means that clients should be able to find and interact with devices
or services dynamically, without needing to know their exact location in advance.
 6. Middleware and Broker Systems
• Broker: In many IoT systems, a broker acts as an intermediary to manage
communication between different devices or services. It handles the
publishing and subscribing of messages in a publish/subscribe model,
common in MQTT and CoAP systems.
• Proxy: A proxy server can act as a go-between for clients and servers,
caching responses or modifying requests to improve performance or
security.
Conclusion: Applying These Principles in IoT/M2M Web
Connectivity
• When designing a communication architecture for IoT/M2M device networks, you
should:
• Leverage APIs and Web Services: Expose device data and capabilities through
standardized APIs (RESTful APIs) or web services (SOAP).
• Ensure Scalability and Security: Use protocols like REST, MQTT, and WebSockets for
scalable, secure, and real-time communication. Secure the communication with
firewalls and encrypted protocols.
• Optimize Data Formats: Use efficient data formats like JSON for data exchange.
• Design for Flexibility and Robustness: Build a flexible system that can handle various
devices and communication methods, ensuring robustness in diverse environments
(e.g., constrained networks or unreliable connectivity).
• By understanding these principles, you’ll be equipped to design an efficient, scalable,
and secure IoT/M2M communication system for real-time web connectivity.
Web Communication Protocols for Connected Devices in Constrained
and Unconstrained Environments

• In the world of connected devices, communication takes place over

various types of networks and protocols, depending on the
constraints of the devices, the environment, and the data being
exchanged. The two primary environments for communication are
Constrained RESTful Environments (CoRE) and Unconstrained
Environments. These environments use different protocols and
technologies suited for their respective needs, primarily shaped by
the limitations of the devices and the network. Below is an
explanation of the key concepts and protocols involved in each of
these environments.
1. Constrained RESTful Environment (CoRE)
• The Constrained RESTful Environment (CoRE) is typically used in the Internet of Things (IoT) or Machine-to-Machine (M2M) communication,
where devices are resource-constrained in terms of processing power, memory, and data size. These devices often communicate in Local
Area Networks (LANs), exchanging small amounts of data.
Key characteristics:
• Limited Data Size: Devices typically send or receive tens of bytes at a time. The data exchanged after being aggregated from multiple devices
may consist of hundreds of bytes.
• Low Power Consumption: Many devices in this environment are designed to be low-power, meaning they often sleep for extended periods
and only wake up to transmit or receive data when necessary.
• Unstable Connectivity: Devices may experience intermittent or unreliable connectivity, with long periods of disconnection or low-power
mode.
• Low Power and Lossy Networks (ROLL): The communication may occur over wireless networks that are designed to operate in low-power,
lossy conditions. A common network used in this context is ROLL (Routing Over Low Power and Lossy networks).
Protocols used in CoRE:
• CoAP (Constrained Application Protocol): CoAP is a lightweight, RESTful protocol designed for use in constrained environments. It is based on
the principles of HTTP but optimized for the limited resources of IoT devices. CoAP uses UDP (User Datagram Protocol) rather than TCP to
reduce overhead.
• CoAP Communication: Devices using CoAP communicate via CoAP clients and CoAP servers. The URLs in CoAP use the format
coap://<host>/<resource>, similar to HTTP but adapted for constrained environments.
• DTLS (Datagram Transport Layer Security): CoAP often uses DTLS for securing communication in place of the TLS used in HTTP, as it is
designed to work over UDP.
• UDP (User Datagram Protocol): CoAP is built on top of UDP, which is a connectionless, lightweight transport protocol. UDP’s minimal
overhead is suitable for constrained devices and low-power networks.
• ROLL: The ROLL protocol stack is designed for low-power, lossy networks and helps in routing data efficiently across devices in a constrained
environment.
Example of Communication:A CoAP client sends a request to a CoAP server via the ROLL network, using the UDP transport layer. The client and
2. Unconstrained Environment
• An Unconstrained Environment refers to a communication setting
where devices and networks have no strict resource limitations. Web
applications in such environments use protocols designed for full-
scale communication, such as HTTP and RESTful HTTP.
• Key characteristics:
• Large Data Size: Web objects (e.g., web clients and servers) typically
communicate large amounts of data, often in the thousands of bytes.
• Robust Connectivity: The communication typically occurs over the
Internet using standard protocols like TCP and IP. These environments
assume stable network conditions and higher bandwidth.
• Full Network Stack Support: Devices in this environment are usually
not constrained in terms of power, memory, or data size. They can
rely on the full set of internet protocols, including IP, TCP, and HTTP.
IoT or M2M devices local network connectivity and web connectivity in constrained (above thick
dotted line) and unconstrained RESTful HTTP (below thick dotted line) environments using
communication protocols
• Protocols used in Unconstrained Environments:
• HTTP (Hypertext Transfer Protocol): HTTP is the standard protocol for web
communication. Web applications communicate via HTTP, with large web objects (e.g.,
images, videos, data files) being transferred between clients and servers.
• RESTful HTTP: REST (Representational State Transfer) is an architectural style that uses
HTTP as a foundation for enabling stateless communication between clients and servers.
• HTTP Communication: Web clients (e.g., browsers) make requests to web servers, and
these requests/responses are transmitted over IP networks using TCP as the transport
layer protocol.
• TLS (Transport Layer Security): In order to secure the communication, TLS is used on top
of TCP to ensure privacy and integrity of data between clients and servers.
• TCP (Transmission Control Protocol): HTTP communication uses TCP, a connection-
oriented protocol that ensures reliable, ordered delivery of data.
• Example of Communication: A web client (browser) sends an HTTP request to a web
server over the Internet. The request and response involve data in the range of
thousands of bytes, and the communication occurs over TCP/IP networks using the URLs
in the form http://<host>/<resource>.
Comparison between CoRE and Unconstrained Environments:

Feature Constrained Environment (CoRE) Unconstrained Environment

Data Size Tens to hundreds of bytes Thousands of bytes

Network Type Local Area Networks (LANs), Low IP-based networks (Internet)
Power and Lossy Networks (ROLL)
TCP (Transmission Control
Transport Protocol UDP (User Datagram Protocol) Protocol)

Application Protocol CoAP (Constrained Application HTTP (Hypertext Transfer Protocol)

Protocol)

Security DTLS (Datagram Transport Layer TLS (Transport Layer Security)

Security)

Communication Frequency Devices may sleep, waking up for Continuous or frequent

events or on client request communication

Routing Protocol ROLL (Routing Over Low Power and Standard IP Routing
Lossy networks)

Network Layer IPv6 or custom low-power IPv4 or IPv6

protocols (e.g., 6LoWPAN)
 Summary
• In Constrained RESTful Environments (CoRE), communication is designed to
be lightweight, with protocols like CoAP and UDP used to minimize overhead
in networks with low power and limited connectivity. This is ideal for IoT
devices where low data volume, energy efficiency, and intermittent
connectivity are crucial.
• In Unconstrained Environments, communication relies on more traditional
and robust protocols like HTTP, TCP, and TLS, suitable for web applications
where data volumes are larger, and connectivity is stable and continuous.
These environments support richer, more complex data exchanges over the
Internet.
• Each environment and its protocols cater to the specific needs of connected
devices and their respective applications, ensuring efficient and secure
communication tailored to the constraints or capabilities of the devices and
the networks they operate in.
Constrained Application Protocol (CoAP)
and DTLS Overview

• The Constrained Application Protocol (CoAP) is designed by the Internet

Engineering Task Force (IETF) to cater to constrained environments such as IoT
(Internet of Things) and M2M (Machine-to-Machine) communication. These
environments typically have limited computational resources, power constraints,
and low bandwidth. CoAP, as an application protocol, is optimized for such
constraints, providing efficient communication for devices in a CoRE (Constrained
RESTful Environment) over ROLL (Routing Over Low Power and Lossy) networks.
Below is an in-depth explanation of CoAP and its features, including its
integration with DTLS (Datagram Transport Layer Security) for security.
Key Features of CoAP
• CoAP is a specialized web-transfer protocol tailored to the needs of IoT devices and constrained networks. It is designed to
work with RESTful architecture, similar to HTTP but optimized for low power and small data payloads.
1. IETF Standard: CoAP is defined by the IETF (Internet Engineering Task Force) as an application protocol designed for
constrained devices and networks.
2. Request/Response Interaction Model: Like HTTP, CoAP follows a request/response model. A CoAP client sends a request
(such as GET, POST, PUT, DELETE), and a CoAP server responds to the request with a corresponding status or resource data.
3. Specialized for CoRE and ROLL Networks: CoAP is built specifically for constrained environments and works over LOW
power and loss networks (ROLL). It is used to exchange small amounts of data between constrained devices.
6. Object-Resource Model: CoAP uses an object model for the resources. Each resource in CoAP can have multiple instances,
allowing for scalability and flexibility in communication between devices.
5. UDP and DTLS for Security: CoAP uses UDP (User Datagram Protocol) for transport, which reduces overhead compared to
TCP, making it more suitable for low-power devices. It is paired with DTLS (Datagram Transport Layer Security) to secure the
data exchange over the network.
• DTLS is the UDP counterpart of TLS (Transport Layer Security) and provides encryption, integrity, and authentication to the
data exchanged.
6. Message Header and Types: CoAP messages have a small header, usually only 4 bytes long, which is designed to minimize
the protocol overhead. The header contains:
• Version (ver): Specifies the version of the CoAP protocol.
• Message Type (T): Defines the type of message (e.g., Confirmable, Non-Confirmable, Acknowledgement, Reset).
• Token Length (TKL): Length of the optional token used for matching responses to requests.
• Code: Specifies the request method or response code (similar to HTTP).
• Message ID: A 16-bit identifier for message tracking.
• Token: An optional field used for response matching in Confirmable messages.
• Confirmable vs Non-Confirmable: CoAP distinguishes between Confirmable messages, which require an acknowledgment from the server, and Non-
7. Asynchronous Communication: CoAP supports asynchronous communication, which
allows devices to send and receive data without waiting for a response immediately. This is
critical for IoT devices, which may be operating in low-power or intermittent-connectivity
environments.
8. Resource Discovery: CoAP includes mechanisms for resource discovery, allowing devices to
find available resources (sensors, actuators, etc.) on the network. This is facilitated by a
Resource Directory (RD), which helps clients to look up and access resources on different
servers.
9. RESTful Model: CoAP follows the REST (Representational State Transfer) architecture style,
similar to HTTP. This makes it easy to integrate CoAP with existing web technologies,
including using CoAP-HTTP proxies for communication between CoAP clients and HTTP
servers.
• CoAP resources are accessed via URIs like coap://<host>/<resource>, and the data is
represented using a subset of MIME types.
10. Proxy Support: CoAP supports proxy servers that act as intermediaries between CoAP
clients and CoAP servers or between CoAP and HTTP servers. A CoAP-HTTP proxy allows
communication between CoAP and HTTP-based devices, while an HTTP-CoAP proxy enables
an HTTP client to interact with a CoAP server.
Direct and indirect accesses of CoAP client objects to a CoAP server, (b) CoAP client
access for lookup of object or resource using a resource directory, and (c) CoAP client
and server access using proxies
Overview of Lightweight Machine-to-Machine (LWM2M) Protocol

• The Lightweight Machine-to-Machine Communication (LWM2M) protocol is a

compact, application-layer protocol designed to facilitate communication in
Machine-to-Machine (M2M) networks, especially in constrained environments
such as the Internet of Things (IoT). Specified by the Open Mobile Alliance (OMA),
it enables efficient data transfer and device management by reducing the resource
demands on the system, which makes it ideal for constrained devices and networks.
Key Features and Concepts:
1.Lightweight Protocol:
• Low Overhead: LWM2M's design is optimized for environments with limited resources (e.g.,
devices with low memory and low processing power).
• Efficient Data Transfer: It uses binary data formats (e.g., Tag Length Value [TLV] or JSON)
which allow for compact and efficient data transfer compared to larger, more complex data
formats used in conventional web pages.
• System Resource Independence: LWM2M operates with minimal reliance on system calls,
which reduces overhead during execution. For example, it does not require frequent calls to
system APIs for operations like displaying menus or network functions.
3.Communication Model:
• Client-Server Architecture: LWM2M facilitates communication between the LWM2M client (typically an IoT
device) and the LWM2M server (which manages M2M applications and services).
• CoAP and UDP Protocols: LWM2M commonly uses the Constrained Application Protocol (CoAP), which is a
lightweight, request-response protocol for constrained devices, often transmitted over UDP. This is suitable for
scenarios with limited bandwidth and high packet loss.
• Security with DTLS: The protocol also supports DTLS (Datagram Transport Layer Security) to ensure secure
communication between devices and servers, which is critical in IoT deployments.
4.Data Formats:
• TLV (Tag-Length-Value) and JSON: LWM2M uses compact formats such as TLV (binary) or JSON to represent
data in a structured manner. This allows for the efficient exchange of data between client and server with
minimal bandwidth consumption.
• Resource Models: The data in LWM2M is structured around objects and resources. Each object can have
multiple resources, and these can be accessed via Uniform Resource Identifiers (URIs).
5.Device Management:
• Bootstrapping & Registration: The LWM2M protocol allows for the initial setup of a device (bootstrapping),
registering it to the network, and managing its status (deregistering, updating).
• Resource Notification: Devices can send notifications when their resource values change (e.g., sensor
readings), allowing the server to track device status and perform necessary actions.
• Service and Management Functions: LWM2M enables remote management of devices, including the ability to
configure, monitor, and update devices and resources.
6.M2M Communication Layers:
• M2M Device Network (PAN): Local M2M devices (e.g., sensors, actuators) communicate using technologies such as
Bluetooth Low Energy (BLE), 6LowPAN, ZigBee, Wi-Fi, or Cellular. These devices form a Personal Area Network (PAN) to
communicate with an M2M gateway.
• Access Network: This layer provides the connection from the local PAN to the wider CoRE network (e.g., 3GPP, LTE) and
IP-based communication networks.
• Client-Server Communication: LWM2M client-server interactions are typically conducted over CoAP using UDP or SMS
for lightweight communication. The client sends requests to the server, which responds with the necessary data or
commands.
7.Interfaces and Functions:
• Bootstrapping: Allows a new device to securely join the network, obtaining the necessary credentials and settings.
• Registration & Deregistration: Allows devices to register with the LWM2M server and also update or remove their
registration status when needed.
• Notifications: Devices can notify the server of any changes in their resource state, allowing for real-time monitoring and
management.
• Management Access: This allows the server to manage the lifecycle of the device, including updates, configurations,
and service provisioning.
8.Interoperability & Standards:
• LWM2M is built to comply with OMA (Open Mobile Alliance) standards, and other standards bodies may also define
additional objects and resources.
• The protocol facilitates the use of standardized object models, which ensures interoperability between different devices
and platforms in M2M communication networks.
Applications:
• IoT Devices & Sensors: LWM2M is especially suitable for small, low-power devices like
sensors, smart meters, and environmental monitoring systems that require lightweight
and efficient communication.
• Device Management: LWM2M provides functionalities for remote device configuration,
monitoring, and management, which is essential in large-scale IoT deployments.
• M2M Communication: It is ideal for M2M communication where devices need to
exchange small amounts of data efficiently, with minimal reliance on network
bandwidth.
Conclusion:
• LWM2M is a highly efficient and compact protocol designed for IoT and M2M
applications, providing a lightweight method for device management and data
exchange. It ensures that constrained devices can communicate effectively over limited
bandwidth while also offering secure communication via DTLS and flexible
object/resource modeling. The protocol's use of CoAP, UDP, and TLV/JSON formats
makes it ideal for environments with limited resources, such as in industrial
automation, smart homes, and environmental monitoring.
Web Connectivity for Connected Devices Network
Using Gateway, SOAP, REST, HTTP RESTful, and
WebSockets

• In a connected devices network, such as in an IoT (Internet of Things)

ecosystem, the communication between different devices and systems
often involves various network protocols and standards. A communication
gateway plays a crucial role in facilitating this connectivity by bridging
different communication protocols used by the devices and the server-side
applications. This allows devices from different networks to communicate
seamlessly with each other and with web-based services.