IOT Protocols

UNIT 3

Content

Link layer protocols, Network/internet layer protocols, Transport layer protocols,

Application layer protocols:

Hypertext transfer protocol (HTTP), Systematic HTTP access methodology, Web Socket, Constrained application protocol CoAP), Message Queue, Telemetry Transport Protocol (MQTT), XMPP, DDS, AMQP

​

IoT Link Layer Protocols

1. IEEE 802.15.4

2. Zigbee

3. Bluetooth Low Energy (BLE)

4. Wi-Fi (IEEE 802.11 variants)

5. LoRaWAN (Link Layer aspects)

6. NB-IoT (Narrowband IoT)

7. 6LoWPAN

​

What is the Link Layer?

• It’s responsible for node-to-node data transfer.�
• It handles framing, error detection, medium access control (MAC), and sometimes addressing.�
• In IoT, link layer protocols are often designed for low power, low data rates, and short/long range communication.

​

1. IEEE 802.15.4

• Foundation for many IoT wireless standards.�
• Operates at 2.4 GHz, 915 MHz, and 868 MHz.�
• Low data rates (~250 kbps at 2.4 GHz).�
• Used by Zigbee, Thread, and 6LoWPAN( Low-Rate Wireless Personal Area Networks)�
• Supports star and mesh topologies.�
• Designed for low power, low complexity devices.�

​

2. Zigbee

• Built on top of IEEE 802.15.4.�
• Mesh networking capability.�
• Focus on low-power, low-data-rate sensor and control devices.�
• Popular for home automation and industrial IoT.�

​

3. Bluetooth Low Energy (BLE)

• Operates at 2.4 GHz.�
• Designed for very low power consumption.�
• Data rates up to 2 Mbps (Bluetooth 5).�
• Used in wearables, health monitoring, proximity sensors.�
• Supports star topology and mesh networking (Bluetooth Mesh).

​

4. Wi-Fi (IEEE 802.11 variants)

• Operates in 2.4 GHz and 5 GHz bands.�
• Higher power consumption and data rates (up to several hundred Mbps).�
• Used for IoT devices requiring high bandwidth.�
• Newer standards like Wi-Fi HaLow (802.11ah) are designed for IoT:�
• Operates sub-1 GHz.�
• Longer range, lower power.�
• Data rates around 150 kbps to several Mbps.�

​

5. LoRaWAN (Link Layer aspects)

• Long Range (LoRa) operates at sub-GHz frequencies.�
• Provides long-range communication (kilometers).�
• Very low data rates (0.3 kbps to 50 kbps).�
• Uses a proprietary physical layer but defines MAC layer for IoT.�
• Designed for battery-operated devices needing wide area coverage.

​

6. NB-IoT (Narrowband IoT)

• Cellular LPWAN technology standardized by 3GPP.�
• Operates over licensed LTE spectrum.�
• Supports link layer with reliable MAC.�
• Suitable for massive IoT deployments with deep coverage and low power.

​

7. 6LoWPAN

• IPv6 over Low power Wireless Personal Area Networks.�
• Adapts IPv6 packets to IEEE 802.15.4 frames.�
• Enables IP connectivity for low-power wireless networks.

​

Summary Table:

What works most in practice?

Wi-Fi (IEEE 802.11 Variants) for IoT

1. Overview of Wi-Fi

• • Family of wireless communication standards (IEEE 802.11)
• • Operates mainly in 2.4 GHz, 5 GHz, and newer 6 GHz bands
• • Originally designed for high-speed data (internet, video)
• • Increasingly adapted for IoT needing higher bandwidth

​

2. Common IEEE 802.11 Variants

• 802.11b (1999) – 11 Mbps, 2.4 GHz, 35-100m
• 802.11g (2003) – 54 Mbps, 2.4 GHz, 35-100m
• 802.11n (2009) – Up to 600 Mbps, dual-band, 70-250m
• 802.11ac (2013) – Up to 6.9 Gbps, 5 GHz, beamforming
• 802.11ax (2019) – Up to 9.6 Gbps, 2.4/5 GHz, IoT-friendly (OFDMA, MU-MIMO)

​

3. Wi-Fi for IoT — Challenges & Adaptations

• Challenges:
• • Power consumption
• • Range limitations
• • Stack complexity
• • Module cost

​

• Adaptations:
• • Power Save Mode (PSM)
• • Wi-Fi HaLow (802.11ah)
• • Cloud-friendly IP integration

​

4. Wi-Fi HaLow (802.11ah)

• • Sub-1 GHz (around 900 MHz)
• • Range up to 1 km+
• • Data Rate: 150 kbps – 347 Mbps
• • Lower power, star topology
• • Apps: Smart agri, cities, industry
• • Benefits: Penetration, long battery, dense deployments

​

5. Use Cases of Wi-Fi in IoT

• • Smart home: cameras, speakers, appliances
• • Security systems: IP cameras, sensors
• • Industrial IoT: high-data sensors, monitoring
• • Healthcare: patient monitoring
• • Smart city: public Wi-Fi sensors, traffic

​

6. Advantages of Wi-Fi in IoT

• • High bandwidth
• • Ubiquitous infrastructure
• • IP-based networking
• • Mature security protocols (WPA3)
• • Supports many devices (latest standards)

​

7. Disadvantages of Wi-Fi in IoT

• • Higher power consumption
• • Limited range (except HaLow)
• • Congested 2.4 GHz band
• • Higher hardware cost for sensors

​

8. Security Considerations

• • Use WPA3 encryption
• • Device authentication & secure onboarding
• • Firmware updates
• • VPNs or secure tunnels for sensitive data

​

9. Example Wi-Fi IoT Communication Flow

• 1. Device powers on → connects to AP
• 2. Authentication (WPA2/WPA3)
• 3. DHCP → gets IP
• 4. Data exchange (sensor/commands)
• 5. Power save mode (idle)

​

10. Future Trends

• • Wi-Fi 6 & Wi-Fi 7 → more IoT support
• • AI & edge computing integration
• • Growing adoption of Wi-Fi HaLow
• • Security & privacy improvements

​

Messaging Protocols

Web Socket,

"WebSocket as IoT" is a concept that refers to using WebSockets as a communication protocol for Internet of Things (IoT) devices. It's not a standard approach like MQTT or CoAP, but it can be useful in certain cases. Let's break this down and explain how WebSockets can be used in IoT.

🔌 What is WebSocket?

WebSocket is a full-duplex, bi-directional communication protocol that runs over a single TCP connection. It allows real-time data exchange between a client (like a web browser or IoT device) and a server.

✅ Persistent connection (unlike HTTP, which is request-response)

✅ Low latency, efficient real-time updates

✅ Built into most browsers and many languages

❌ Overhead compared to lightweight IoT protocols

📡 Why Use WebSocket in IoT?

While protocols like MQTT and CoAP are more popular in IoT for being lightweight and optimized for constrained devices, WebSocket can be a viable choice when:

✅ Use Cases:

You have a web interface that needs real-time updates from IoT devices

Your IoT devices are not very constrained (have enough CPU/memory/network)

You need low-latency, bi-directional communication

You’re running over Wi-Fi or Ethernet, not low-power radios (e.g., Zigbee)

​

🧭 Comparison: WebSocket vs MQTT in IoT

🛠️ Example: IoT Device Using WebSocket

Let’s say you have a smart thermostat that sends temperature updates to a dashboard in real time.

1. Thermostat connects to a WebSocket server.�
2. Sends { "temp": 26.3 } every few seconds.�
3. The dashboard receives updates instantly without polling.�

Example code snippet (Node.js client):

const WebSocket = require('ws');

const ws = new WebSocket('wss://iot-server.example.com');

ws.on('open', function open() {

setInterval(() => {

const temp = 25 + Math.random();

ws.send(JSON.stringify({ temp }));

}, 5000);

});

🧩 When Not to Use WebSocket

In power- or bandwidth-constrained environments (e.g., battery-operated sensors)

When using low-power protocols like LoRaWAN or Zigbee

If you need guaranteed delivery with low bandwidth (MQTT is better)

​

🧠 Conclusion

WebSocket is not the traditional IoT protocol, but it’s useful in certain real-time, web-integrated, or higher-powered device scenarios.

Use WebSocket in IoT when:

You need real-time updates

You're working with browsers or interactive dashboards

Devices can handle more complex protocols

Messaging Protocols in IoT

• Messaging protocols are very important for the transfer of data in terms of messages.
• They are useful for send/receive of a message to/from the cloud in IoT applications.
• In the section, two messaging protocols are discussed.
• Message Queuing Telemetry Transport (MQTT)
• Constrained Application Protocol (CoAP)

Message Queuing Telemetry Transport (MQTT)

• As we know, IoT has one of the biggest challenges of resource constraints, the lightweight protocol is more preferred.
• MQTT is widely used in IoT applications as it is a lightweight protocol.
• Here, lightweight means, it can work with minimal resources and does not require any specific hardware architecture or additional resources.

​

​

MQTT

• MQTT works with “publish – subscribe” pattern.
• The MQTT working can be explained as follows.
• The publisher (node) sends a message to the MQTT broker.
• The MQTT broker transmits the message to the subscribed destinations.

MQTT - Example

• Suppose a temperature sensor is connected to any system and we want to monitor that temperature.
• The controller connected to the temperature sensor publishes the temperature value to the MQTT broker with a topic name: “Temperature”. Hence, it is considered a publisher.
• The MQTT broker transmits the temperature value to the subscribers.

Subscribed to:

“Temperature”

Subscribed to:

“Temperature”

• Note that the only nodes which have subscribed to the topic will capture the data and not the other nodes.

MQTT - Example

• Can publisher and subscriber interchange their role?
• Let us take an example of a Driverless car.
• A GPS sensor is connected to the car which gives the current location of the car.
• The system in car, publishes the location to MQTT broker with topic name – CurrentLocation.
• The server/computer subscribes to the topic CurrentLocation and receives the current location of the car.

MQTT Broker

Subscriber: CurrentLocation

MQTT - Example

• Based on the currently selected destination, the server/computer computes the direction of the car.
• This data is published to an MQTT broker with a topic named – Direction.
• To get the command from the server, the system in the car has to subscribe to the topic named Direction.
• According to the command received from the server, the car will run in a particular direction.

Publisher: CurrentLocation

MQTT Broker

Subscriber: CurrentLocation

MQTT - Working -Video

• In MQTT, clients do not have any address like a typical networking scheme.
• The broker filters the messages based on the subscribed topics.
• The messages will then be circulated to respective subscribers.
• The topic name can be anything in string format.
• The MQTT working can be explained with an example of the television broadcast.

Client_Address

MQTT - Working

• Television broadcaster station broadcasts all the channels.
• The viewers subscribe to their favorite channels only.
• Similarly, in MQTT, the publisher node publishes data with the topic name and interested subscribers subscribe to the topic.
• Note that there can be multiple subscribers of a same topic as well as a single subscriber can subscribe to multiple topics.

MQTT – Node(s)

• Node(s) in MQTT collects the information from sensors or other i/p devices in case of the publisher.
• Connects it to the messaging server known as the MQTT broker.
• A specific string – Topic is used to publish the message and let other nodes understand the information. These nodes are considered subscribers.
• Any node can be publisher or subscriber and node is also referred to as client.

Publisher

Subscriber

MQTT

Broker

Topic:SensData

QoS in MQTT

• MQTT supports different QoS (Quality of Service) levels.
• There are 3 layers of QoS supported by MQTT.
• Level 0 = At most once (Best effort, No Acknowledgement)
• Level 1 = At least once (Acknowledged, retransmitted if ack not received)
• Level 2 = Exactly once (Requested to send, clear to send)

MQTT Publisher – Code Implementation

• The code for MQTT publisher is as shown in below.

MQTT Publisher – Code Implementation

MQTT Publisher – Code Implementation

Returns the pointer of string clientId to the array.

MQTT Publisher – Code Implementation

MQTT Subscriber – Code Implementation

• The code for MQTT subscriber is as shown in below.

MQTT Subscriber – Code Implementation

MQTT Subscriber – Code Implementation

This function accepts the arguments char* of topic, char* of payload and the length of payload.

Typecasting of payload[i] into equivalent character and then printing on serial monitor.

MQTT Subscriber – Code Implementation

Constrained Application Protocol (CoAP)

• CoAP is designed by IETF (Internet Engineer Task Force) to work in constrained environment.
• It is a one to one communication protocol.
• CoAP is also light weight like MQTT protocol and it uses less resources than HTTP.
• HTTP runs over TCP and is connection oriented while CoAP runs over UDP and it is connection less.

​

CoAP Architecture

• CoAP is based on the RESTful architecture (Representational State Transfer).
• REST approach ensures the secure, fault tolerant and scalable system.
• The CoAP optimizes the length of the datagram.
• CoAP is connectionless protocol and it requires retransmission support.

​

​

CoAP Layers

• CoAP has four layers:
• UDP
• Messages
• Request-Response
• Application
• The message layer is designed to deal with UDP and asynchronous switching.
• The request/response layer concerns communication method and deal with request/response messages.
• In the request/response layer, clients may use GET/PUT/DELET methods to transmit the message.

​

UDP

Messages

Request/Response

Application

Message Layer in CoAP

• CoAP message layer supports four types of messages:
• Confirmable – Reliable Messaging (CON):
• This is reliable approach because the retransmission of message occurs until the acknowledgement of the same message ID is received.
• If there is a timeout or fail of acknowledgement, the RST message will be sent from the server as a response.
• Hence, the client will retransmit the message, this resolves the retransmission and it is considered a reliable approach.

Message Layer in CoAP (Contd.)

2. Non-confirmable – Non-reliable Messaging (NON):
• In this message transmission style, there is no reliability is ensured.
• The acknowledgement is not issued by the server.
• The message has ID for supervision purpose, if the message is not processed by the server it transmits the RST message.

Message Layer in CoAP (Contd.)

3. Acknowledgement (ACK):
• In this messaging, the traditional acknowledgement message sent as usual protocol.
• We can compare this with regular handshaking scheme.
• The handshake is automated process that establishes a link for communication before actual data transfer begins.

Message Layer in CoAP (Contd.)

4. Reset (RST):
• The receiver is expecting the message from sender of a particular message ID.
• If no message is processed or received before specific amount of time (called timeout), the message called RESET is transmitted from receiver.
• This message informs the sender that there is a trouble in transmission of messages.

Request-Response Layer in CoAP

• There are three modes in CoAP request-response layer.
• Piggy-Backed:
• In this mode, the client sends the data with particular method (GET, PUT etc.) with token number and CON messaging method.
• The ACK is transmitted by server immediately with corresponding token number and message.
• If the message is not received by server or data is not available then the failure code is embedded in ACK.

Request-Response Layer in CoAP (Contd.)

2. Separate Response:
• In this mode, the client sends the data with particular method (GET, PUT etc.) with token number and CON messaging method.
• If the server is unable to respond immediately, an empty ACK will be reverted.
• After some time, when the server is able to send the response, it sends a CON message with data.
• In response to that, ACK is sent back from client to server.

.

.

.

.

Request-Response Layer in CoAP (Contd.)

3. Non-Confirmable Request and Response:
• In this mode, the client sends the data with particular method (GET, PUT etc.) with token number and NON messaging method.
• The server does not give ACK in NON messaging method, so it will send a NON type response in return with token number and its data.

CoAP Message Format

• The CoAP message format is of 16 Bytes consisting various fields.
• V : It refers to version of CoAP. It is two bit unsigned integer.
• T : It refers to message type. It is also two bit unsigned integer.
• Confirmable (0)
• Non-Confirmable (1)
• ACK (2)
• RESET (3)
• TKL : It refers to the token length and is four bit unsigned integer.
• Code: It refers to the response code.

CoAP Message Format (Contd.)

• Message ID: It is identifier of the message and to avoid duplication.
• Token : Optional field whose size is indicated by the Token Length field.
• Options : This field is used if any options available and having length of 4 Bytes.
• Payload : This field refers to the payload data where actual data is transmitted.

​

​

​

XMPP Protocol

• The full form of XMPP is Extensible Messaging and Presence Protocol.
• It is designed for messaging, chat, video, voice calls and collaboration.
• The fundamental base of this protocol is XML and it is used for messaging services such as WhatsApp.
• The XMPP was originally named as Jabber and later known as XMPP.

XMPP denotation

• The denotation for XMPP can be given as following:
• X – X denotes eXtensible.
• It is considered extensible as it is designed to accept and accommodate any changes.
• The protocol is defined in open standard and it is extensible because of open standard approach.
• M – M denotes Messaging.
• XMPP supports sending message to the recipients in real time.
• P – P denotes Presence.
• It is helpful to identify the status such as “Offline” or “Online” or “Busy”.
• It also helps in understanding if the recipient is ready to receive the message or not.
• P – P denotes Protocol.
• The set of standards together acting as a protocol.

Messenger Requirements

• Any messenger requires the following features inbuilt :
• Message sending and receiving features.
• Understanding the presence/absence status.
• Managing subscription details.
• Maintaining the contact list.
• Message blocking services.
• Note that all the listed features are built in XMPP.

XMPP Architecture

• The architecture of XMPP protocol is shown in the figure :
• The XMPP clients communicate with XMPP server bidirectional.
• There can be any numbers of clients connected to XMPP server.
• The XMPP servers may be connected to the other clients or other XMPP servers.

​

XMPP

Server

XMPP Architecture (Contd.)

• The initial version of the XMPP was with TCP using open ended XML.
• After certain period of time, the XMPP was developed based on HTTP.
• The XMPP can work with HTTP is through two different methods Polling and Binding.
• What is Polling and Binding?

XMPP

Server

XMPP Architecture (Contd.)

• In polling method, the messages stored in the server are pulled or fetched.
• The fetching is done by XMPP client through HTTP GET and POST requests.
• In binding method, Bidirectional-streams Over Synchronous HTTP (BOSH) enables the server to push the messages to the clients when they are sent.

​

• The binding approach is more effective than polling.
• Also both method uses HTTP, hence the firewall allows the fetch and post activity without any difficulties.

Data Distribution Service (DDS)

• Data Distribution Service (DDS) is one of the protocol being used in the Internet of Things (IoT) applications.
• DDS is brokerless service and the protocol was developed by the Object Management Group (OMG).
• The purpose behind development of DDS is to get better machine to machine communication.
• Like MQTT, DDS is also using publish-subscribe approach.

DDS Architecture

• DDS is basically a publish – subscribe model based architecture.
• Everything including sending and receiving data, event updates, command within and among the nodes are all accomplished through the publish – subscribe approach.
• The publisher sends the data to DDS cloud with particular Topic.
• The interested nodes (Subscribers) subscribes the particular Topic and receives data from DDS Cloud.

​

Data Distribution Service

(DDS)

Publisher

Publisher

Publisher

Subscriber

Subscriber

Subscriber

DDS Architecture (Contd.)

• Here, DDS Cloud has to handle all the attributes of data transfer like addressing, marshalling data, control of delivery, control of flow, etc.
• The marshalling of data means to convert any data or objects into a byte-stream, while unmarshalling is exactly the reverse process.
• This enables the communication between publisher and subscriber working on multiple different platforms.

Data Distribution Service

(DDS)

Publisher

Publisher

Publisher

Subscriber

Subscriber

Subscriber

Transport Protocols

Section - 2

Bluetooth 4.0 (BLE)

• BLE – Bluetooth Low Energy
• BLE is open low energy short range radio communication technology.
• The BLE is also known as Bluetooth Smart.
• This protocol is designed by Bluetooth Special Interest Group (SIG).
• BLE also works same al Bluetooth in wireless Personal Area Network (PAN).
• It can be considered the advanced version of Bluetooth.

Bluetooth 4.0 (BLE) (Cont.)

• BLE is superior to classic Bluetooth because of following reasons:
• It is power saving.
• It is supported by Android, IOS, Blackberry, etc.
• It is also supported by computer OS like Windows 8/10, MAC-OS, and Linux variants.
• Because of certain advantages of BLE over classic Bluetooth, it is widely used in the areas like:
• Healthcare
• Entertainment
• Fitness (in form of wearable devices)
• Proximity related applications
• Tracking devices

Features of BLE

• The key features of BLE are as following:
• It is licence free and does not add any overhead costing.
• There is no restrictions to Manufacturer.
• BLE modules are inexpensive and affordable.
• The size of BLE modules are small. So it can be accommodated in any system easily.
• The power consumption for BLE modules is very less and hence suitable for IoT applications.
• The range of BLE has very high range compared to classic Bluetooth.

BLE Architecture

• The BLE architecture has three components.
• Application Block
• The user application is accommodated in this block.
• It interacts directly with Bluetooth stack.
• Host Block
• It is upper layer of the Bluetooth stack.
• Controller Block
• It is lower layer of the Bluetooth stack.

​

Application

Host

Controller

BLE

Application

Generic Access Profile

(GAP)

Link Layer (LL)

Physical Layer (PHY)

Generic Attribute Profile

(GATT)

Attribute Protocol

(ATT)

Logical Link Control and Adaptation Protocol

(L2CAP)

Security Management Protocol

(SMP)

--------------------------------------Host Controller Interface --------------------------------------

(HCI)

Host

Application

Controller

BLE Architecture

1. Controller : It has three components.
1. Host Controller Interface (HCI) : is used to enable interoperability between hosts and controllers assembled by different manufacturers
2. Link Layer (LL) : It defines the packet structure
3. Physical Layer (PHY) : It takes care of the transmission/reception, modulation/demodulation and analog-to-digital conversion.

BLE Architecture

2. Host : It has following components with functionalities
1. Generic Access Profile (GAP) : It takes care of the device discovery, connection establishment, connection management and security.
2. Generic Attribute Profile (GATT) : It is responsible for the data exchange process. Whenever there is a need to push data and to read or write data, the generic guidelines with respect to the process are governed by GATT.
3. Attribute Protocol (ATT) : It is the protocol for accessing data.

BLE Architecture

2. Host : It has following components with functionalities
4. Logical Link Control and Adaptation Protocol (L2CAP) : It is responsible for fragmentation and de-fragmentation of the application data. Also, it is responsible for the multiplexing and de-multiplexing of channels over the shared logical link.
5. Security Manager (SM) : It takes care of pairing, authentication, and encryption. Everything related to security is taken care here.
6. Host Controller Interface (HCI) : The functionality remains the same as that in the controller. It is used to enable interoperability between hosts and controllers assembled by different manufacturers.

Generic Access Profile

(GAP)

Generic Attribute Profile

(GATT)

Attribute Protocol

(ATT)

Logical Link Control and Adaptation Protocol

(L2CAP)

Security Management Protocol

(SMP)

Host

BLE Architecture

3. Application Layer :
• The working of application layer in BLE is same as in OSI model. It is the top most layer in BLE and this layer is responsible for user interface (UI), logic and data handling.

​

BLE Topology

• Broadcasting
• The meaning of broadcasting is to send a message to more than one recipient. The same concept is followed in BLE.
• The broadcast method will send the data in “one way” only.

​

Bluetooth

Broadcaster

Observer

Observer

Observer

Observer

Observer

Observer

• The receiver in the vicinity of the broadcaster will receive the message or data.
• There are two parts in broadcasting topology. Broadcaster and Observer.

​

​

BLE Topology

• Broadcasting
• Broadcaster : The broadcaster sends a "non-connectable" advertising packets in frequent intervals to all those who are willing to collect which is similar to a radio broadcast.
• Observer : The observer will keep scanning predefined frequency to receive any non-connectable packets..

Bluetooth

Broadcaster

Observer

Observer

Observer

Observer

Observer

Observer

BLE Topology

• Connections
• The connections topology works on the concept of master-slave configuration.
• The master will try to find out the connectable advertising packets. Once the advertisement is found, it will initiate the connection to the slave.

​

Master

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

• The master will take care of periodic data exchange.
• The slave(s) continuously sends the connectable advertising packets at regular interval.

​

​

​

​

BLE Topology

• Connections
• Once the slave is connected, the event is called connection event.
• In this topology, the device will work whenever required. For the remaining time the device is in sleep mode.
• This provides power saving during the communication.

​

Master

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

Slave

(Peripheral)

• However, during the sleep mode also the connection remains present.
• But the data will be transferred after the device invokes.

Light Fidelity (Li-Fi)

• The Li-Fi is fastest communication protocol right now among all existing protocols.
• The symbol of Li-Fi is as shown in the figure.
• It gives the following solutions to the problems which one can face during the use of the Wi-Fi.
• More security than Wi-Fi.
• More available bandwidth to the connected devices or equipments.
• Less/No congestion when more number of devices connected.
• Note that the Li-Fi has phenomenal speed of 224GBps which is fastest among all.

Li-Fi Working

• The server wants to transmit the data to the receiver with very high speed. The server is either connected to internet or intranet.

Photo

Detector

Amplification & Processing

Received App Data

Photo

Detector

Amplification & Processing

Received App Data

Internet

Server

Streaming

Content

• The server connected to the internet generates a data which is converted into streaming content.
• The streaming content is given to Lamp driver which is powered by external source.

Li-Fi Working

• The LED lamp is turned on and off at very high speed that human eyes can not capture it.

Photo

Detector

Amplification & Processing

Received App Data

Photo

Detector

Amplification & Processing

Received App Data

Internet

Server

Streaming

Content

• The light is received by the photo detector and it is passed for demodulation process and amplification to generate the data stream sent by transmitter.
• The received data stream is further given to receiver (e.g. mobile, PC etc.) via receiver app. All components working for receiving the data combined known as receiver dongle.

Li-Fi – Advantages & Disadvantages

• Advantages
• Li-Fi is extremely secure as the light can not penetrate through walls and no data hijacking is possible.
• Li-Fi is fastest and effective.
• It is an effective alternate to RF communication.
• It is inexpensive as the light is generated through LED lamps.

​

• Disadvantages
• It can be implemented in short range as the presence of walls or any other object will become the interruption in communication.
• The required time for set up is higher.
• There is no clarity of bidirectional communication means how to send data from mobile or PC back to server.

Addressing & Identification Protocols

Section - 3

Internet Protocol Version 4 (IPv4)

• IP addresses are useful in identifying a specific host in a network.
• IP addresses are 32 bit numbers which are divided into 4 octets. Each octet represents 8 bit binary number.
• Below is an example of an IP address:

​

10101100

00010000

11111110

00000001

172

16

254

1

IP addresses are divided into 2 parts:

Network ID & Host ID

<NID> <HID> = IP Address

Classification of IP Address

Class: A

Fix

7 Bit Network ID

24 Bit Host ID

Class: B

Fix

14 Bit Network ID

16 Bit Host ID

Class: C

Fix

21 Bit Network ID

8 Bit Host ID

Class: D

Fix

Multicast address

Class: E

Fix

Reserved address

Class A

​

​

• Only 126 addresses are used for network address.
• All 0’s and 1’s in Network-ID are dedicated for special IP address. So, total number of IP address in class A can be represented as following.
• The range of Class A is 0.0.0.0 to 127.255.255.255

​

7 Bit Network ID

24 Bit Host ID

Class B

​

​

• No special network address here. All are usable.
• The total number of hosts connected in network can be given as following:
• It is used in medium size network.
• The range of Class B is 128.0.0.0 to 191.255.255.255

​

Fix

14 Bit Network ID

16 Bit Host ID

Class C

​

​

• This class is used in small networks.
• The calculation for number of hosts can be given as following:
• Normally, the LANs are configured with Class C.
• The range for Class C is given as 192.0.0.0 to 223.255.255.255

Fix

21 Bit Network ID

8 Bit Host ID

Class D

• Very first four bits of the first octet in Class D IP addresses are set to 1110, giving a range of:

​

​

​

• Class D has IP address rage from 224.0.0.0 to 239.255.255.255.
• Class D is reserved for Multicasting.
• In multicasting data is not destined for a particular host, that is why there is no need to extract host address from the IP address, and Class D does not have any subnet mask.

​

11100000 – 11101111

224 – 239

Class E

• This IP Class is reserved for experimental purposes only for R&D or Study.
• IP addresses in this class ranges from 240.0.0.0 to 255.255.255.254.
• Like Class D, this class too is not equipped with any subnet mask.

​

IPv4 Format

• Figure shows the format for IPv4.
• VER (Version):
• It is a 4 bits field which indicates the version of IP.
• IHL (Internet Header Length):
• It specifies the Internet Header Length in 32 bits word length and points the beginning of data.
• Types of Service:
• It is a 8 bit field which specifies the Quality of Service (QoS). The format for these 8 bits are given here.

IPv4 Format

• Types of Service:
• Precedence (3) : They are used for future options.
• Delay (1): It indicates the delay of either normal or lower.
• Throughput (1): Indicates the speed of throughput of either normal or higher rate.
• Reliability (1): It indicates normal reliability or high reliability.

IPv4 Format

• Total Length:
• This is a 16 bit field defining the length of IPv4 datagram. The minimum length of datagram is 20 bytes and maximum is 65535.
• Identification:
• This field is of 16 bits which helps in assembling the fragments and added by the senders.
• Flags:
• There are3 bits in flags. First is always ‘1’. Second is DF (Don’t Fragment) and third is MF (More Fragment).

IPv4 Format

• Fragment Offset:
• When fragmentation is done, this specifies the offset or position of overall message.
• Time to Live:
• This is 8 bit field that indicates the time period of datagram to survive.
• Protocol:
• This field identifies the protocol for higher layer in the IP datagram.

IPv4 Format

• Header Checksum:
• It is 16 bit field to provide basic protection in transmission of header via checksum.
• Source Address:
• This is 32 bit IP address of the source of the datagram.
• Destination Address:
• This is 32 bit IP address of the destination of the datagram.
• Options:
• There are many optional header available for debug and test purpose.

IPv6 Addressing

Features of IPv6 Addressing

• It has better and efficient routing than IPv4.
• The additional flow label is added in header of IPv6 for improvement in QoS.
• IPv6 has new application like IP telephony, video/audio, interactive games etc. with ensured QoS.
• The plug and play abilities have been improved in IPv6.
• IPv6 has eliminated the need of Network Address Translation due to the huge availability of IP addresses.

IPv6 Header Format

• IPv6 header format has less fields than IPv4 header format.
• IPv6 header is 40 bytes which is twice than IPv4 header.
• The figure shows IPv6 header format.
• The IPv6 has simple packet handling and improved forwarding efficiency.
• The fields of IPv6 header can be explained as following:

​

​

IPv6 Header Format

• IP version :
• It is 4 bit field to represent the IP version being used.
• Traffic Class :
• It is 8 bit field to identify the different classes or priorities of IPv6 packets.
• It replaces the type of services in IPv4.
• Upper 6 bits are used for type of services lower 2 bits are used for Explicit Congestion Notification.
• Flow Label :
• It is 20 bit field used to identify the sequence of packets.
• It is also useful for prioritizing the delivery of packet and providing real time service.
• The higher priority packets can be delivered ahead of lower priority packets.

IPv6 Header Format

• Payload Length :
• It is a 16 bit field which identifies the length of payload of IPv6.
• Next Header :
• It is a 8 bit field which is similar to protocol field in IPv4 header.
• It represents the type of extension header that follows the primary IPv6 header.
• Hop Limit :
• It is 8 bit field equivalent to Time to Live in IPv4 Header.
• The value is decremented by 1 every time when it is forwarded by the host.
• When this value reaches 0, the packet is discarded.

IPv6 Header Format

• Source Address :
• It represents the 128 bit IP address of source or sender.
• Destination Address :
• It represents the 128 bit IP address of destination or receiver.

Uniform Resource Identifier (URI)

• Uniform Resource Identifier (URI) is used to identify the resources with the help of sequence of characters.
• The URI protocol was developed by IETF.
• The URI can be URL or URN.
• The sample for URL and URN can be as following:

​

​

​

​

​

• URN mostly provides information of unique name without locating or retrieving the resource information.
• URL provides locating and retrieving information on a network.

Universal Resource Name (URN)

E.g.: ISBN:0451450523

Universal Resource Identifier (URI)

Universal Resource Locator (URL)

E.g.: https://darshan.ac.in/ce/material

Uniform Resource Locator (URL)

• The URL contains the information of how to fetch a resource information from its location.
• URL always begin with a protocol like HTTP/HTTPS
• A URL is used when client request the server for the service.
• The sample URL and its fields are explained below:

​

http://www.darshan.ac.in/CE/Study-material/IoT/Syllabus.html

HTTP Protocol

World Wide Web

Domain Name

Path

File name

Systematic HTTP access methodology,

​

It's a structured approach to accessing resources or services over the HTTP protocol. The methodology ensures consistent, reliable, and efficient communication between clients (like browsers, apps, IoT devices) and servers.

Key elements of a systematic HTTP access methodology:

1. Understanding HTTP Methods

HTTP defines several request methods — each with a specific purpose.

GET: Retrieve data from the server.

POST: Send data to the server (usually creates a new resource).

PUT: Update or replace an existing resource.

PATCH: Partially update a resource.

DELETE: Remove a resource.

HEAD: Retrieve metadata without the body.

OPTIONS: Discover supported methods on a resource.

Using these methods correctly is fundamental to a good HTTP access strategy.

2. Endpoint Structuring and Naming

Design URLs (endpoints) to be clear, meaningful, and consistent.

Use nouns for resources, e.g., /users, /devices/123.

Avoid verbs in URLs (instead, use HTTP methods to describe actions).

Support versioning in URLs like /api/v1/....

​

3. Request and Response Standards

​

Use appropriate HTTP status codes:

200 OK (success)

201 Created (resource created)

400 Bad Request (client error)

401 Unauthorized (auth error)

404 Not Found (missing resource)

500 Internal Server Error (server error)

Define clear request and response payloads (usually JSON or XML).

Include metadata in headers (like content-type, auth tokens, caching).

4. Authentication & Authorization

Use secure methods: OAuth, API keys, JWT tokens.

Enforce HTTPS to encrypt traffic.

Implement access control based on user roles or device permissions.

​

5. Error Handling and Retries

​

Provide meaningful error messages with error codes and details.

Implement retry mechanisms with exponential backoff to handle transient failures.

Log errors for monitoring and troubleshooting.

​

6. Rate Limiting and Throttling

​

Protect servers from overload by limiting request rates.

Inform clients when limits are reached with status 429 Too Many Requests.

Implement fair usage policies.

​

7. Caching

​

Use HTTP caching headers (Cache-Control, ETag, Last-Modified) to improve performance.

Decide which resources can be cached and for how long.

​

8. Testing & Documentation

​

Document APIs clearly (Swagger/OpenAPI, Postman).

Test endpoints thoroughly (unit tests, integration tests).

Monitor usage and performance.

​

Summary of a systematic HTTP access flow example:

AMQP

AMQP stands for Advanced Message Queuing Protocol. It’s an open standard protocol for message-oriented middleware that enables the exchange of messages between systems or devices in a reliable, secure, and interoperable way.

Key Characteristics of AMQP:

Message-oriented: Focuses on sending messages (data packets) between producer and consumer.

Reliable delivery: Guarantees message delivery through acknowledgments and transactions.

Flexible routing: Supports complex routing logic like pub/sub, direct, topic, and fanout exchanges.

Interoperable: Works across different platforms and languages.

Open standard: Defined by the OASIS group.

​

How does AMQP work?

AMQP defines:

Messages — packets of data with properties and body.

Producers — entities that send messages.

Queues — where messages are stored.

Consumers — entities that receive messages.

Exchanges — route messages to queues based on rules (bindings).

​

AMQP in IoT?

AMQP is widely used in enterprise messaging but also has applications in IoT, especially in:

Industrial IoT (IIoT) scenarios where reliability and complex routing are important.

Systems requiring transactional messaging.

Environments where devices or gateways are resource-rich (not low-power sensors).

Cases needing interoperability across diverse platforms.

​

AMQP vs MQTT for IoT

AMQP Architecture (Example)

Producer: An IoT device or gateway publishes sensor data as AMQP messages.

Exchange: Routes messages to different queues based on rules.

Queue: Stores messages until consumed.

Consumer: Backend services or databases consume the data.

​

Why use AMQP in IoT?

When you need complex routing (e.g., route sensor data based on type or priority).

If you want transactional guarantees on message delivery.

When devices/gateways have sufficient resources.

In enterprise IoT, where AMQP brokers integrate with existing systems.

Example of AMQP use in IoT:

Imagine an industrial plant with multiple sensors:

Temperature sensors send data.

Humidity sensors send data.

Alerts and commands are routed to specific systems.

AMQP exchanges can route temperature data to one queue and alerts to another, ensuring reliable and organized messaging.

​