0% found this document useful (0 votes)
13 views105 pages

Unit 3

Uploaded by

ssmcse
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views105 pages

Unit 3

Uploaded by

ssmcse
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 105

CHAPTER 3

IOT Software and


Platforms

1
Outline
Features and Characteristics of IOT platforms
Open-source and Commercial IoT Platforms
IoT Operating Systems
Protocols For IOT
Messaging and Transport Protocols: MQTT, COAP, XMPP and DDS
protocols, Bluetooth Low Energy, Light Fidelity(Li-Fi)
Addressing and Identification: Introduction, IPv4, IPv6, IPv6-A quick
Overview: IPv6 vs IPv4, Legacy of IPv4 Devices, Switching over to IPv6,
IPv5, URI.

HEMIL PATEL
2
CKPCET, SURAT
Features and Characteristics of IoT
Platforms
Role of IoT Platforms
Central role in managing IoT devices and applications.

Key features:
Device Management,
Data Management,
Analytics,
Security.

HEMIL PATEL
3
CKPCET, SURAT
Device Management
• Provisioning and Onboarding
Process of integrating new devices into the IoT network.
Features:
Automated registration and configuration.
Authentication and authorization protocols.

• Monitoring and Diagnostics


Real-time tracking of device performance and health.
Features:
Continuous monitoring tools.
Diagnostics and troubleshooting capabilities.

HEMIL PATEL
4
CKPCET, SURAT
Contd…

•Configuration Management
Managing device settings centrally.
Features:
This ensures that device settings are managed centrally, making it easier to enforce
policies and maintain consistency across the network.

•Firmware and Software Updates


Updating device software remotely.

5
Data Management
• Data Collection
Gathering data from IoT devices.
Features:
High-frequency data collection.(Ensure accurate and up to date information)
Data aggregation from various sensors.

• Data Storage
Storing collected data securely.
Features:
Scalable storage solutions.
Backup and recovery mechanisms.

HEMIL PATEL
6
CKPCET, SURAT
Contd…

• Data Access and Retrieval


Accessing and querying stored data.
Features:
Efficient querying interfaces.
API access for external applications.

•Data Integration
Combining data from multiple sources.
Features:
Data fusion techniques.
Unified data repositories.

7
Analytics
• Real-Time Analytics
Processing data as it arrives.
Features:
Stream processing capabilities.
Instantaneous decision-making support.

• Historical Analysis
Analyzing past data trends.
Features:
Long-term data storage.
Trend analysis and forecasting tools.

8
Contd…

•Visualization Tools
Graphical representation of data.
Features:
Interactive dashboards.
Customizable reports and charts.

•Machine Learning and AI


Using algorithms to analyze data.
Features:
Pattern recognition.
Predictive analytics and automation.

9
Security
• Authentication and Authorization
Ensuring proper access control.
Features:
Multi-factor authentication.
Role-based access controls.

Data Encryption
Protecting data confidentiality.
Features:
End-to-end encryption.
Data encryption in transit and at rest.

HEMIL PATEL
1
CKPCET, SURAT 0
Contd…

•Vulnerability Management
Managing and mitigating security vulnerabilities.
Features:
Regular updates and patches.
Vulnerability scanning and assessment.
(essential to identify and address security weaknesses, ensuring ongoing protection against cyber
threats.)

•Network Security
Safeguarding the IoT network.
Features:
Firewalls and intrusion detection systems.
Secure communication protocols.
Open-source and Commercial IoT Platforms

Comparison of IoT Platforms:


Arduino IoT vs. AWS IoT vs. Microsoft Azure IoT vs. Google Cloud IoT

What is IOT?

Importance of Choosing the Right Platform

1
2
Criteria for Comparison

While evaluating IOT platforms, several criteria come into play:


Cost
Scalability
Ease of Use
Integration Capabilities
Support and Documentation
Security

1
3
Arduino IoT (Open-source)

Overview
Part of the Arduino ecosystem
Focus on hobbyists and prototyping
Features
Free and open-source
Integrated with Arduino IDE
Easy to use for beginners
Pros
Low cost
Community support
Cons
Limited scalability
May require additional tools for advanced features

1
4
AWS IoT (Commercial)

Overview
Part of Amazon Web Services
Enterprise-level IoT solution
Features
Scalable cloud infrastructure
Integration with other AWS services
Strong security and analytics capabilities
Pros
Highly scalable
Extensive support and documentation
Cons
Potentially high cost
Steeper learning curve

1
5
Microsoft Azure IoT (Commercial)

Overview
Part of Microsoft Azure cloud services
Enterprise-oriented
Features
Integration with Microsoft services
Advanced analytics and AI capabilities
Extensive security features
Pros
Comprehensive toolset
Strong support and integration with enterprise systems
Cons
Complexity and cost
Requires Azure knowledge

1
6
Google Cloud IoT (Commercial)

Overview
Part of Google Cloud Platform
Focus on data-driven IoT solutions
Features
Integration with Google’s machine learning tools
Scalable and secure infrastructure
Real-time data processing
Pros
Advanced analytics and AI integration
Scalable and flexible
Cons
Complexity and cost
May have a learning curve

1
7
Comparative Analysis

Cost Comparison
Arduino IoT: Low
AWS IoT, Azure IoT, Google Cloud IoT: Varies based on usage
Scalability
Arduino IoT: Limited
AWS, Azure, Google Cloud: High
Ease of Use
Arduino IoT: Beginner-friendly
AWS, Azure, Google Cloud: Professional and enterprise focus
Integration
Arduino IoT: Limited
AWS, Azure, Google Cloud: Extensive
Security
Arduino IoT: Basic
AWS, Azure, Google Cloud: Advanced

1
8
Use Cases

Arduino IoT
Prototyping
Educational projects
AWS IoT
Enterprise solutions
Large-scale deployments
Microsoft Azure IoT
Industrial IoT
Smart cities
Google Cloud IoT
Data-intensive applications
AI-driven insights

1
9
IoT Operating Systems

• General-Purpose vs. IoT Operating Systems


1. General-Purpose OS (GPOS)
•Examples: Windows, Linux, macOS
•Designed for versatility and performance
•Supports a wide range of applications
•Typically runs on powerful hardware hardware with ample processing power, memory, and
storage.

2. IoT Operating Systems (IoT OS)


• Examples: Contiki, TinyOS
•Optimized for constrained environments
•Focus on low power consumption, real-time performance
•Runs on embedded and low-resource devices

2
0
Key Differences

Resource Constraints
IoT OS: Limited memory, processing power
GPOS: Abundant resources, multitasking

Power Consumption
IoT OS: Low power, battery efficiency
GPOS: Less emphasis on power efficiency

Real-Time Capabilities
IoT OS: Real-time processing requirements
GPOS: May not meet real-time constraints

Scalability and Flexibility


IoT OS: Specialized, focused functionality
GPOS: Broad functionality, scalable
2
1
Overview of Contiki OS

•Introduction to Contiki
• Lightweight OS for embedded systems
• Developed for low-power, low-memory devices
•Key Features
• Small memory footprint
• Built-in IPv6 support and network stack
• Support for wireless sensor networks
•Typical Use Cases
• Sensor networks
• Smart agriculture
• Home automation

2
2
Overview of TinyOS

•Introduction to TinyOS
• Modular and component-based OS
• Designed for resource-constrained devices
•Key Features
• Event-driven architecture
• Modular design for efficiency
• Real-time performance(Designed to meet the timing requirements of many embedded
systems).
•Typical Use Cases
• Wireless sensor networks
• Industrial monitoring
• Environmental sensing

2
3
Contiki vs. TinyOS

Comparison of Features
Memory Usage: Contiki’s minimal footprint vs. TinyOS’s modular approach
Programming Model: Contiki’s co-operative multitasking vs. TinyOS’s event-driven model
Network Stack: Contiki’s built-in IPv6 stack vs. TinyOS’s flexibility with custom protocols

Use Case Suitability


Contiki: More suited for IPv6-based applications
TinyOS: Better for modular, event-driven applications

2
4
Real-World Applications

•Contiki OS Applications
• Smart cities
• Energy-efficient buildings

•TinyOS Applications
• Environmental monitoring
• Industrial automation

2
5
Protocols For IOT(Messaging and Transport Protocols)

Messaging protocols(MQTT, CoAP)


Messaging protocol plays a vital road to save and receive the data or message
to/from the cloud for any IOT application.

2
6
Message Queuing Telemetry transport(MQTT)

• MQTT (Message Queuing Telemetry Transport)


• Developed by IBM in the late 1990s
• Lightweight messaging protocol. Demands minimal resources for its
functioning.
• IOT prefers this type of resource protocol due to resource
constraints.
• Designed for low-bandwidth, high-latency, or unreliable networks

2
7
Characteristics of MQTT

•It is designed as a simple and lightweight messaging protocol


that uses a publish/subscribe system to exchange the
information between the client and the server.
•It does not require that both the client and the server establish a
connection at the same time.
•It provides faster data transmission, like how
WhatsApp/messenger provides a faster delivery. It's a real-time
messaging protocol.
•It allows the clients to subscribe to the narrow selection of topics
so that they can receive the information they are looking for.
•It is a machine to machine protocol, i.e., it provides
communication between the devices.
2
8
Publish-Subscribe communication model

• Publish-Subscribe is a communication
model that involves publishers, brokers
and consumers.
• Publishers are the source of data.
Publishers send the data to the topics
which are managed by the broker.
Publishers are not aware of the
consumers.
• Consumers subscribe to the topics which
are managed by the broker.
• When the broker receives data for a
topic from the publisher, it sends the
data to all the subscribed consumers.
Ex. Television or radio broadcast scenario
Once the message reach the client, the message get removed from the broker. So, the life
of the message is limited, and if there are no takers or subscribers for a particular topic, it
automatically gets deleted

3
0
MQTT Architecture

Now we will look at the architecture of MQTT.


• Suppose a device has a temperature sensor and wants to
send the rating to the server or the broker.
• If the phone or desktop application wishes to receive this
temperature value on the other side, then there will be two
things that happened.
• The publisher first defines the topic; for example, the
temperature then publishes the message, i.e., the
temperature's value.
• After publishing the message, the phone or the desktop
application on the other side will subscribe to the topic,
i.e., temperature and then receive the published message,
i.e., the value of the temperature.
• The server or the broker's role is to deliver the published
message to the phone or the desktop application.

3
1
MQTT Subscribe- Implementation Exercise

Consider this example as shown in fig.,


Sensor MQ2 continuously sends the data(sensed data) to the cloud; this
process is referred as a publishing(sending data to the cloud). MQTT is used
for this process. The cloud service provider preferred for the process is
Adafruit cloud, which is a free cloud service.

The process is as follows:


1. The sensor sense the gas data and pushes it to cloud through NodeMCU,
which is one of the nodes. This node is referred as a Publisher.
2. The process of transmission is taken care by MQTT protocol.
3. Adafruit cloud service provider acts as the broker and takes care of the
subscribers provided with appropriate message.

The gas sensor will read the gas data in the proposed environment. The data
will sent to the NodeMCU and further to the cloud . This process of publishing
data to the cloud is referred to as Publishing. Adafruit cloud is used in this
entire process and acts as the broker.
3
2
MQTT Message Format

•The MQTT uses the command and the


command acknowledgment format, which
means that each command has an
associated acknowledgment.
•As shown in the figure that the connect
command has connect acknowledgment,
subscribe command has subscribe
acknowledgment, and publish command has
publish acknowledgment.
• This mechanism is similar to the
handshaking mechanism as in TCP protocol.

3
3
MQTT packet Structure

Now we will look at the packet structure or message format of the MQTT.

• The MQTT message format consists of 2 bytes


fixed header, which is present in all the MQTT
packets.
• The second field is a variable header, which is
not always present.
• The third field is a payload, which is also not
always present.
• The payload field basically contains the data
which is being sent.
• We might think that the payload is a
compulsory field, but it does not happen.
Some commands do not use the payload field,
for example, disconnect message.

3
4
(Reliable messaging)
Contd…

Confirmable (CON) Message: This is like sending a registered letter that you want the recipient to confirm
they received. When a client sends a confirmable message, it expects the server to acknowledge that it got
the message.
After receiving the message, the server sends back an acknowledgment (ACK). If the client doesn't
get this acknowledgment within a certain time, it will resend the message. This ensures the message is
delivered reliably.
Example: A sensor sending important data to a server, where it needs to know the server received the data.
2. Non-Confirmable (NON) Message: This is like sending a regular letter where you don’t need
confirmation that it was received. The client sends the message and doesn’t expect an acknowledgment from
the server.
These messages are used for information that isn’t critical or time-sensitive. The message is sent,
and whether the server gets it or not, the client doesn’t wait for or require a response.
Example: A device broadcasting its presence to the network where it doesn’t need to confirm that every
other device received the message.

4
1
Contd…

3. Acknowledgment (ACK) Message: This is the response sent by the server to confirm it received a
confirmable (CON) message.
When the server gets a CON message, it sends back an ACK to let the client know the message was
received. The ACK can either include the actual response to the request or simply confirm receipt, with the
response coming later.
Example: A server acknowledging that it received a request to turn on a light, even if it hasn’t actually
turned the light on yet.
4. Reset (RST) Message:This is like saying, "I don’t understand your message" or "I didn’t request this
information."
If the server or client receives a message it can't process or didn’t expect, it sends back an RST
message to indicate it didn’t understand or didn’t accept the message.
Example: A server receives a message it wasn't expecting or doesn't recognize, so it sends an RST to the
sender to indicate this.

4
2
Contd…

1. Piggy-Backed:
In this mode of request-response approach, the client sends a request through the CON/NON-
messaging method. ACK is received immediately with corresponding token number and message
shown in Fig.. In this figure, the message is Temperature. If Temperature data is not available, the
failure code is embedded as a part of the ACK (Fig. 2).

4
5
Contd…

2. Separate Response: When a CON type message is sent to the server and in case 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. ACK is sent back from the client. Figure shows this process.

4
6
3. Non conformable Request and Response
Here Non type message is sent from the client to the server. The server does not need to give ACK and
it can send a NON type response in return. Fig. shows this process
, 2 ACK, 3RESET
1.Version (Ver, 2 bits) - CoAP version (currently 01 for RFC 7252).

2.Type (T, 2 bits) Defines message type:


•00 Confirmable (CON) 01 Non-confirmable (NON) 10 Acknowledgement (ACK) 11 Reset (RST)

3.Token Length (TKL, 4 bits) Length of the token (0–8 bytes).

4.Code (8 bits) Identifies method or response code:


•0.01 = GET 0.02 = POST 0.03 = PUT 0.04 = DELETE
•Response codes similar to HTTP (e.g., 2.05 = Content).

5.Message ID (16 bits) Used for detecting duplicates and message matching.

6.Token (0–8 bytes) Correlates requests and responses (like HTTP cookies or IDs).

7.Options Optional information like Uri-Path, Content-Format, Max-Age.

8.Payload Marker (1 byte: 0xFF) Indicates start of payload (if present).

9.Payload Application data (can be empty).


1.Transport-Layer Security (DTLS)
•CoAP typically runs over UDP, so it uses DTLS (Datagram Transport Layer Security) for end-to-end protection.
•DTLS provides:
•Confidentiality (encryption of payload & options)
•Integrity (ensures message not tampered)
•Authentication (of devices, via PSK, RPK, or certificates)
•Replay protection (prevents duplicate/old messages)
2. DTLS Keying Methods
•PSK (Pre-Shared Keys): Lightweight, good for constrained IoT devices.
•RPK (Raw Public Keys): Uses public/private keys without full certificates.
•Certificates (X.509): Strongest but heavy for small IoT nodes.
3. Object Security for Constrained RESTful Environments (OSCORE, RFC 8613)
•Instead of securing the transport (DTLS/TLS), OSCORE secures the application layer.
•Protects CoAP messages end-to-end, even through proxies.
•Provides encryption + integrity at the CoAP option/payload level.
•Uses COSE (CBOR Object Signing and Encryption).
•Very efficient for low-power IoT.
4. Message Layer Security Features
•Message IDs prevent replay & duplication.
•Tokens help match request–response pairs securely.
5. Security Threats in CoAP
•Eavesdropping → solved by DTLS/OSCORE encryption.
•Replay attacks → solved by DTLS sequence numbers, CoAP Message IDs.
•Message spoofing → prevented by authentication.
•Denial of Service (DoS) → still a challenge for constrained IoT devices.
• Consumes High power Consumes less power. Making it the best
XMPP And DDS Protocol
There are other messaging protocols such as
1.Extensible Messaging and Presence Protocol(XMPP) and
2. Data Distribution Service(DDS).

5
3
Extensible Messaging and Presence
Protocol (XMPP)
Extensible Messaging and Presence Protocol (XMPP) is meant for the messaging, chat,
video, voice calls, presence, and collaboration.
• This protocol is fundamentally based on XML (Extensible Markup Language) and it is
used for messaging services such as WhatsApp.
• X- X denotes eXtensible. The protocol is defined in open standard and XMPP is made
extensible through this open standard approach.
• M- M denotes Messaging. This is the message we send. XMPP supports sending
messages to recipients in real time. The approach used is capable PUSH mechanism.
• P- P denotes presence. It is very simple and helps in understanding the status as
"Online" or "Offline" or "Busy".
• P-The final P denotes protocol. It is the crux of XMPP. The set of underlying standards
together are termed as protocol.
5
4
Requirement of features
Any messenger requires the following features inbuilt. XMPP readily fulfils these requirements and provide
the following:
1. Message sending and receiving feature.
2. Understanding the presence/absence status.
3. Managing subscription details.
4. Maintaining and managing the contact list.
5. Message blocking services.

XMPP is not just a messaging protocol but also a


presence + subscription + contact management system,

5
5
Features
1. Decentralized: The architecture of XMPP is very similar to that of the e-mail. Anyone can run their own XMPP
server, which means that it is decentralized. (centralized messaging platforms (like WhatsApp or Telegram)

2. Secure: Simple Authentication and Security Layer (SASL) for authentication and Transport Layer Security (TLS)
for encryption, OMEMO and OpenPGP for end-to-end encryption.

3. Stable and Functionally Proven: The initial version of Jabber (now called XMPP) came into existence in
1998. Hence, XMPP is very stable and good to use by now.

4. Standardization: the Internet Engineering Task Force (IETF), which is an organization responsible for
creating internet standards, officially recognized XMPP (Extensible Messaging and Presence Protocol) by
publishing its specifications as RFCs (Request for Comments). Specifically, RFC3920 and RFC3921 are
documents that describe how XMPP works.

5. Flexibility: XMPP is not just messaging oriented; it is flexible enough to accommodate file sharing, instant
messaging and even remote monitoring of systems (iot communication).

5
6
Implementation Details
• The initial version of the XMPP was with Transmission Control Protocol (TCP) using open-
ended XML.
• Over a period of time, as a different option to TCP transport, development of HTTP-based XMPP
was performed. The way XMPP can really work with HTTP is through polling or binding.
• With polling, the messages stored on the server shall be pulled, that is, fetched by the XMPP
client through the HTTP GET and POST requests.
• When it comes to the binding approach, Bidirectional-streams Over Synchronous HTTP
(BOSH) enables the servers to push messages to clients as and when these are sent. This
approach is seen as an effective model over polling.
Also, because of HTTP being used, the firewalls allow the post and fetch activities without any
trouble. The XMPP architecture is shown in Fig below

5
7
XMPP Architecture

5
8
XMPP Architecture

1. Core Components –
Client server Gateways
2. Communication Model –
Client-to-Server (C2S) & Server-to-Server (S2S)
3. Message Exchange –
All communication is based on streaming XML stanzas.

Types of Stanzas: Message: Chat, group messages, notifications.


Presence: Availability status (online, offline, away).
IQ (Info/Query): Request-response mechanism (like HTTP GET/POST).
4. SecurityTLS (Transport Layer Security): Ensures encryption.SASL (Simple Authentication and Security Layer):
Provides authentication.

5
9
Data Distribution Service

Data Distribution Service (DDS) is one of the messaging protocols being used in the
Internet of Things (IoT) applications.
• DDS functions as a brokerless service.
• Developed by the Object Management Group (OMG). OMG developed it towards getting
better machine-to-machine communication.
• DDS is completely broker less.
• The approach used with DDS is the publish - subscribe model.
• DDS is a middleware protocol standard that supports enhanced data connectivity,
improved reliability and boosted scalability for industrial IoT applications.
• The applications are in vast domains starting from robotics, industrial applications,
aerospace, military applications and many more domains where real-time data exchange
is pivotal.

6
0
Architecture and Functioning

• DDS is fundamentally a publish - subscribe model based architecture. Everything including sending
and receiving data, event updates, commands within and among the nodes are all accomplished
through the publish - subscribe approach.
• Similar to MQTT, topics are also used. The publishing nodes should create the topics and publish
the data.
• Topics could ideally be pressure, temperature, humidity, etc. DDS should deliver this data (topics) to
the subscribers that have shown interest in acquiring the data (certain topic of interest).
• DDS has to take care of all the attributes of data transfer. Addressing, marshalling and
demarshalling data, control of delivery, control of flow, etc., are taken care of by DDS, which follows
a multicasting approach.
• This enables subscribers on multiple/ different platforms to receive the data from the publishers
without delay.
• Whenever a subscriber wants to acquire data, he/she should express interest on the topics. A publisher
or subscriber is allowed to join or leave the GDS at any time.
• This makes the entire workflow versatile.

6
1
Contd…

Figure presents the no broker architecture. DDS is a completely distributed global data
space(GDS). As seen from the figure, any publisher can publish the data in the GDS. This implies
that the data can be written with appropriate topic.

6
2
Protocol Stack of DDS
• Figure shows the protocol stack of DDS. The data-centric publish - subscribe (DCPS)
holds the responsibility for delivering information (data) to the subscribers. DCPS is
nothing but an API for real-time publish - subscribe activity.

9
6
3
Contd..
• The data local reconstruction layer (DLRL) provides interface to the DCPS functionalities. DLRL
helps in sharing the data within the IoT devices

• DDS V1.2 API is an API that is language independent, and hardware and operating system inde-
pendent. Ensures the code portability across various available platforms.
• DDSI V2.1 ensures the wire interoperability between different available implementations of the DDS.
• In conclusion, DDS is all about providing the right data in the right place at the right time. It
ensures that the data is not spilled all over, and delivers it at where needed
• For ex., you can only get the temperature data above 100°C, and any data entry below 100°C shall
not be sent to the receiver. This is the kind of filtering we get through DDS. Thus, the right data can
be delivered without delay.
• DDS is responsible for ensuring the real-time functioning in IoT systems. Quality of service (QoS)
policies connected to the DDS are really well thought of and they ensure the balance. QoS ensures
the right time delivery. QoS with reliability, security, persistence, priority, etc., are all covered in the
DDS.

64
Transport Protocols
Two protocols that enable transport are the traditional Bluetooth Low Energy (BLE) and Light
Fidelity (Li-Fi). BLE has become inevitable in the modern IoT era.

65
Bluetooth Low Energy

•Bluetooth low energy (BLE) is an open low-energy short-range radio


communication technology.
•It is also called Bluetooth Smart.
•The protocol is designed by Bluetooth Special Interest Group (SIG).
•It is a wireless personal area network (PAN) technology, similar to Bluetooth.
• BLE can be considered as an advancement of the earlier version of Bluetooth.

6
6
Contd…

•BLE has reduced power consumption, as compared to classic Bluetooth. The


application prospects are immense and BLE has dominance in the following
areas:
1. Healthcare
2.Entertainment
3.Fitness (in the form of smart watches)
4. Proximity related applications (e.g., car lock, children tracking in the mall, etc.)
•BLE is superior to classic Bluetooth because it has the advantage of saving
power.
•BLE is supported by Android, IOS, Blackberry, etc., thus making it easier to use
with any mobile OS.

6
7
Features of BLE

1. It is license free and hence does not add any costing related overhead to the
system.
2. There is no restriction with respect to manufacturers. Any system
manufactured by any manufacturer is fine with BLE.
3. BLE modules are inexpensive and much affordable.
4. The size of BLE chips are small as well and hence shall not occupy much space
on board.
5. Power consumption is also very minimal and hence is very suitable for IoT
applications as power is a major constraint when it comes to IoT applications.
6. The range offered by BLE is much higher and better than the previous
versions.

6
8
Components of BLE
Technically, BLE has three components from its architectural perspective

Application Block: User application is situated here and interacts directly with the
Bluetooth stack.

Host:The upper layers of the Bluetooth stack.

Controller: The lower layers of the Bluetooth stack.

Apart from these, one more component needs to be understood: HCI (Host Controller
Interface). It is used to interface the controller with the host. This component enables
and makes it possible to interface variety of hosts to the controller.

69
Architecture of BLE stack

70
Contd…

1. Controller: The Controller is usually implemented in the


hardware/firmware (chipset) and handles the physical transmission of data.

a) Link Layer (LL) Manages connections and data transmission , Responsible


for connection establishment, packet framing, and acknowledgment.
b) Physical Layer (PHY) takes care of the transmission/reception. Responsible
for RF communication. Physical layer is responsible for
modulation/demodulation of data.

7
1
Contd…

2. Host: The Host layer is usually implemented in software.


a) Generic Access Profile (GAP) takes care of the device discovery, connec­tion establishment,
connection management and security. Also defines device role.
b) Generic Attribute Profile (GATT) oversees the data exchange process. Whenever there is need to
push data and to read or to write the data, the generic guidelines with respect to the process are
governed by GATT.
c) Attribute Protocol (ATT) is the protocol for accessing data. Defines how data is organized in the
GATT
d) L2CAP (Logical Link Control and Adaptation Protocol), responsible for fragmentation and
defragmentation of the application data. Also, it administers the multiplexing and demultiplexing of
channels over the shared logical link.
e) Security Manager (SM) handles pairing, authentication, and encryption.

7
2
Contd…

3. Application Layer:
Application layer is the topmost layer in BLE as in OSI. Application layer in BLE is
responsible for User Interface (UI), Logic and Data Handling.

Host Controller Interface (HCI) is used to enable interoperability between hosts


and controllers assembled by different manufacturers (increased heterogeneity).

7
3
A BLE device communicates with outside world by two means:

•Broadcasting
•Connections.

74
Broadcasting

• It is sending out message to more than one recipient.


• With this broadcast, "data" is sent out "one-way': Whichever device
is capable of picking the data (receiving), will pick the data. One
can connect this to the radio broadcast. Based on the tuning, one
would receive the content which is aired.

• Now there are two parts of broadcasting: Broadcaster and


Observer
• BLE device (known as a Broadcaster) sends out data packets to
any nearby devices without establishing a formal connection.
• Nearby BLE devices, known as Observers, can receive these
broadcasted data packets.
• This is a one-to-many communication model, where the
broadcaster transmits data, and multiple observers can receive it.

7
5
Advantages:
Low Power Consumption: Since there's no need to maintain a connection, the broadcaster
can remain in a low-power state.
Scalability: Many devices can listen to the broadcast without increasing the broadcaster's
workload.
Simple Implementation: No need for complex connection management, making it easier to
deploy in certain applications.

Limitations:
No Feedback Mechanism: Observers can’t send data back to the broadcaster, so it’s a one-
way communication.
Limited Range: The effective range is typically around 10-100 meters, depending on the
environment and BLE version.
Potential for Interference: Since broadcasting occurs in an open environment, other signals
in the 2.4 GHz band could cause interference.

7
6
Connections

• It works on the concept of master –slave configuration.


• BLE device (known as a Central) establishes a
connection with another BLE device (known as a
Peripheral).
• This is a one-to-one or one-to-many communication
model where the central device controls and manages
communication with one or more peripherals.
• Once connected, data can be exchanged bi-directionally
between the central and peripheral devices.
• The master will take care of periodic data exchange.
• Once the slave is connected, the event is called
connection event.
• For the remaining time device in sleep mode.
• This provide power saving during communication.
• However during the sleep mode also connection remain
present.
7
7
Advantages :
Reliable Two-Way Communication
Data can be organized into meaningful services
Connections support encryption, authentication, and pairing.
Continuous Data Transfer
Central device can configure peripheral behavior.

Limitations:
Higher Power Consumption: Maintaining a connection requires more power, especially
for the central device.
Connection Management: Managing multiple connections can become complex and
may limit the number of devices that can be connected simultaneously.
Range Limitation: Although BLE has a range of 10-100 meters, obstacles and
interference can reduce the effective range.

7
8
Comparison and Choosing the Right One:

Broadcasting is ideal for applications where data needs to be sent out to multiple devices
without requiring a connection, such as in advertising, asset tracking, or beacons.

Connections is better suited for scenarios where two-way communication, data reliability, and
device management are crucial, such as in wearable devices, health monitoring, and smart home
systems.

7
9
Light Fidelity(LiFi)

Nowadays, too many devices are connected to the Internet and it has become a monster of
intertwined connections
There are some concerns which are very strong and must be debated.
Is the Internet through Wi-Fi safe?
1. How much would the bandwidth availability be sufficient for the devices/equipment?
2. How safe is your data? (IoT is all about data)
When the number of devices increases or is on rise, there would be congestion. How is this
handled?

All the above questions are pressing concerns


Is there a solution available which could counter the above challenges?

8
0
• Li-Fi is believed to be the one solution of interest
• Li-Fi stands for Light Fidelity, a wireless communication technology that uses
light to transmit data.
• The LI-FI is the fastest communication protocols and it is bidirectional
• The symbol of Li-Fi is as shown in fig.
• Light is the source, that is data transfer happens through light.
• Light is generated through light bulbs, which makes it inexpensive.

It gives the following solution to the problem which one can face during these of
Wi-Fi.
1. More security than Wi-Fi.
2. More available bandwidth to connected devices or equipment's.
3. Less/No congestion when more no. of devices connected.
4. Li-Fi has phenomenal speed greater than WiFi.

8
1
Li-Fi Working

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

8
2
Functioning of Li-Fi
Components
• Light Emitting Diodes (LEDs): The primary source of light for Li-Fi systems. LEDs
can switch on and off very rapidly, making them ideal for high-speed data transmission.
• Photodetectors: These devices receive the light signals and convert them back into
electrical signals that are then decoded into data.
• Transmission
Data is transmitted by modulating the intensity of the LED light. This modulation is often
imperceptible to the human eye.
The modulated light is sent to a photodetector, which captures the light and converts it
into electrical signals.
Reception
The photodetector converts the received light signals into electrical signals.
These signals are then processed by a decoding system to reconstruct the transmitted
data.

8
3
Real time usage of Li-Fi
• The LED bulbs flicker at extremely high
speeds, imperceptible to the human eye,
to transmit data.
• Each light bulb acts as a data source.
• Receiving Data: Employees use Li-Fi-
enabled devices, which are equipped with
photodetectors that can pick up the
modulated light signals from the LED
bulbs.
• Data Access: As employees move around
the office, their devices continuously
receive data from the nearest light
source, ensuring a stable and high-speed
internet connection.
84
Applications of Li-Fi

Indoor Wireless Networks


Ideal for environments where secure and high-speed communication is essential,
such as offices, hospitals, and schools.
Underwater Communication
Li-Fi can be used for underwater communication, where radio waves are
ineffective but light can penetrate.
Smart Lighting
Integration with smart lighting systems for data transmission and control.

8
5
Advantages of Li-Fi

•High-Speed Data Transfer


Li-Fi can achieve speeds up to 10 Gbps, much faster than traditional Wi-Fi.
•Security
Light does not penetrate walls, making Li-Fi more secure and less
susceptible to unauthorized access.
•Reduced Interference
•Li-Fi is less prone to interference compared to radio frequency-based
technologies like Wi-Fi and Bluetooth.
•High Bandwidth
•The visible light spectrum is much larger than the radio frequency spectrum,
offering a significantly higher bandwidth.
•It is an effective alternate to RF.

8
6
Disadvantage of Li-Fi

•Line-of-Sight Requirement
Li-Fi requires a direct line of sight between the transmitter and receiver,
which can limit mobility and range.
•Ambient Light Interference
Ambient light sources may interfere with data transmission, affecting
performance in bright environments.
•Limited Range
The effective range is generally limited to the area covered by the light
source, which may be a drawback for some applications.

8
7
Addressing and Identification protocols

•IPv4
•IPv6
•URI(Uniform Resource Identifier)

8
8
Need for Addressing and Identification in IoT

Scalability:
Large number of devices connected
Uniqueness:
Unique identification of devices
Interoperability:
Communication between heterogeneous devices
Security:
Ensuring secure device communication

8
9
Internet Protocol Version 4(IPv4)

•IP addresses are useful in identifying a specific host in the 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:
•IP addresses are divided into two parts
•Network ID and Host ID
• <NID><HID>= IP

9
0
Classification of IP Address

•The IP addresses are classified into


Class A, Class B, Class C, Class D, Class
E
•The first three classes that we use in
day to day networking(A, B, C).
•The other two classes (D, E) are used
in multicast or research related work.

9
1
Class A

• This class is dedicated for a very huge network.


• Ex. if a company has many branches and many people working for it, then
Class A will be used.
• In this IP address class, the first octet can be from 1 to 126. This means that
there can be 126 networks possible with Class A.
• The first bit of the first octet will always be set to 0.
• The remaining 24 bits (3 octets) represent the host ID. With this class there
can be [(2^24) - 2] IP addresses.
• This is close to 17 million hosts per network.
• Hence, it is clear that this class IP will be used by larger networks.

9
2
Class B

• It is meant for medium-sized networks, such as a school or college campus.


• Since Class A had already used up the IP addresses up to 127, Class B
commences from 128 and ends at 191.
• Class B addresses will have second octet included as network ID and so only 2
octets will be part of host ID.
• The first two bits of the first octet are fixed to 1 0. Hence in this case [(2^14) -
2], that is, 16,384 networks are possible, each with 65,534 hosts.
• Class B addresses can be identified at a glance by looking at the first byte.
• If it is from 128 to 191; one can confirm that it belongs to Class B IP address.

9
3
Class C

• This class IP addresses are used in small networks.


• First 3 octets represent the network ID and last octet represents the host ID.
• Since Class B ends with 191, Class C starts with 192 and goes till 223.
• First three bits of the first octet are fixed as 1 1 0 for Class C address. So, 21 bits
will form the network ID.
• It allows 2,097,152 networks and 254 [=(2^8)-2] hosts per network.

Class D
• This class IP addresses work solely for multicasting. Class D in its first octet has
first bit as 1, second bit as 1, third bit as 1, and the fourth bit as 0.
• The addresses start with 224 and end at 239.

9
4
Class E

• This class IP addresses are used for experimental purposes only.


• Like Class D, it is different from the first three classes. It holds the first bit
value as 1, second bit value as 1, third bit value as 1, and fourth bit value as 1.
Now that we have learnt the fundamentals, it is important to also know about
the protocol format of IPv4.

9
5
IPv5
• It was designed to address the limitations of its predecessors and to
support advanced features for modern networking needs.
• IPV5 was never officially adopted or widely implemented.
• IPV5 was proposed as a way to experiment with new ideas in network
communication.
• IPV5 was more of an experimental protocol rather than a fully
developed standard.
• It aimed to enhance support for real-time streaming data.
• IPV5 was an experimental protocol that did not become a standard
but influenced the development of networking technologies.

96
Internet Protocol Version 6
• Due to the extensive growth in number of computers and Internet devices, the
addresses got exhausted and there was a need for more addresses for utilization.
• This is the primary reason for development of IPv6 (IP version 6).
• IPv6 was developed to overcome the difficulties faced with IPv4 address
allocations.
• IPv4 IP addressing uses 32 bit IP addresses which can generate.
• 2 32 =4294967296
• The above is just a value. In fact the actual available IP addresses in IPv4 is less
than this theoretical value(may be 3,720,249,092).
• As mentioned earlier, the non-availability of IP addresses is the main challenge with
IPv4.
• IPv6 provides support for 2 128 unique IP addresses, which can generate
3.40282366920…*10 38 IP.
• The above value is very large that if we assign unique IP to every item in the world
then also it will have reserved IP addresses.
97
Features of IPv6 Addressing
In addition to more number of IP addresses, IPv6 also provides the following
features:
1.It has much better and efficient routing.
2. IPsec framework is made mandatory in IPv6, which is not so in IPv4. This
increases the security. (Now, this is optional.)
3. An additional flow label is added in the header of IPv6, which can improve the
QoS.
4. IPv6 supports new applications such as IP telephony, video/audio, interactive
games, etc., with ensured QoS.
5. Plug and play abilities have been improved in IPv6.
6. IPv6 has eliminated the need for Network Address Translation due to the huge
availability of IP addresses.

98
IPv6 Protocol Format
• IPv6 header is 40 bytes which is twice than IPv4 header format.
• The fig. shows IPv6 header format

99
Fields in the packet
• Version (4 bits):
 Indicates the version of the IP protocol.
 For IPv6, this field is set to 6.
• Traffic Class (8 bits):
 Used for quality of service (QoS) and for identifying diff. classes or priorities.
• Flow Label (20 bits):
 Used to identify and handle packets belonging to the same flow, which can be useful for QoS
and other traffic management tasks.
• Payload Length (16 bits)
 Specifies the length of the payload (data) following the header, in bytes.
 The maximum value is 65,535 bytes, but larger payloads are supported using an extension
header.

10
0
Contd…

• Next Header (8 bits):


 Identifies the type of the next header immediately following the IPv6 header.
 It could be a higher-layer protocol (such as TCP or UDP) or an extension header.
• Hop Limit (8 bits) :
 this field specifies the maximum number of hops (or routers) that the packet can pass through before being
discarded.
• Source Address (128 bits):
 The IPv6 address of the sender of the packet.
• Destination Address (128 bits)
 The IPv6 address of the intended recipient of the packet..

1
0
IPv4 Vs IPv6

1
0
Uniform Resource Identifier(URI)
A Uniform Resource Identifier (URI) is a string of
characters used to identify a resource on the internet
or within a network.
URIs they provide a way to locate resources, such as
web pages, files, or services.
• The URI protocol was developed by IETF.
• URI has URL/URN in it.
• URN mostly provides information of unique name
without locating or retrieving the resource
information.
• URL provides locating and retrieving information
on the network.

10
3
URL
• The URL contains the information of how to fetch a resource information from
its location.
• URL always begin with protocol(HTTP).
• A URL is used when client request the server for the service.
• The sample URL and its field explained below.

10
4
URI
Uniform Resource Name (URN) gives the name of a resource and its identification.
However, it does not indicate how to spot/locate it on the Internet.
• A URN typically has the following structure:
urn:<namespace identifier>:<namespace-specific string>
• Namespace Identifier: A unique identifier for the namespace within which the
URN is defined.
• Examples include isbn, uuid, ietf, etc.
• Namespace-Specific String: A unique identifier within the specified namespace.
• Examples of URNs ISBN(International Standard Book number)
urn:isbn:0451450523
• Explanation: Identifies a book by its ISBN number. It does not provide a means to
locate the book but ensures a unique identifier within the ISBN namespace.

You might also like