Introduction to Iot

Course Code : 6131A

IoT – Moduel 2 1
 SYLLABUS
Program : Diploma in Computer Engineering
Course Code : 6131 A Course Title : Introduction to IoT
Semester : 6 Credits : 4
Course Category : Program Elective
Periods per week : 4 (L:3 T:1 P:0) Periods per semester : 60

Course Objectives:
 Provide knowledge on the basic building blocks of IoT and its applications.
 Familiarise different protocols used in IoT.
 Introduce the relationship between IoT and cloud.
 Explore the implementations of IoT.

IoT – Moduel 2 2
 SYLLABUS

Course Prerequisites:

Topic Course Code Course Name Semester

Embedded Systems and Real
Embedded Systems 5131 5
Tile Operating System
Computer Networking Computer Communication &
4132 4
Concepts and Protocols Networks
Programming Concepts 3132 Programming in C 3

IoT – Moduel 2 3
 COURSE OUTCOMES
On the completion of the course student will be able to:

Duration Cogitative
COn Description
(Hours) level
Explain the fundamental concepts of Internet of Things
CO1 13 Understanding
(IoT)
CO2 Interpret the protocols used in IoT infrastructure 13 Understanding
CO3 Explain the use of cloud for IoT 12 Understanding
Illustrate the development of IoT applications with
CO4 20 Understanding
Embedded Computing Boards.
Series Test 2

IoT – Moduel 2 4
 MODULE II

Protocols Used in IoT Infrastructure

IoT – Moduel 2 5
 MODULE II - OUTCOMES
Module outcomes
On the completion of the module student will be able to:
Module Duration
Description Cognitive Level
Outcomes (Hours)
CO 2 Explain the protocols used in IoT infrastructure.
Outline the protocols for IoT – Messaging, Transport,
M2.01 2 Understanding
addressing and identification
Interpret the messaging protocol MQTT and CoAP in IoT
M2.02 4 Understanding
application
Explain the transport protocols Li-Fi and BLE involved in
M2.03 4 Understanding
IoT
M2.04 Explain IPv4 and IPv6 Addressing 3 Understanding

Contents:
Different protocols in data link, network, transport and application layers (overview only) -
Messaging Protocol – MQTT, CoAP – Transport Protocol – BLE, Li-Fi – Addressing –
IPv4, IPv6 - URI IoT – Moduel 2 6
 Protocols
• A set of rules or procedures for transmitting data between electronic devices.
• The protocols in the IoT infrastructure are:
1. Messaging protocols - Supports to send and receive data/ message to/from the
cloud for any IoT application.
• Message Queuing Telemetry Transport (MQTT)
• Constrained Application Protocol (CoAP)
2. Transport Protocol - Enable the data transport
• Bluetooth Low Energy (BLE)
• Light Fidelity (Li-Fi)
3. Addressing & Identification Protocol – To identify the devices in the network
• IPv4
• IPv6

IoT – Moduel 2 7
 Messaging Protocols

• Messaging protocols play a vital role to send and receive the data/message to/from
the cloud for any IoT application
• Two important messaging protocols are :
• Message Queuing Telemetry Transport (MQTT)
• Constrained Application Protocol (CoAP)

IoT – Moduel 2 8
 Messaging Protocols……
1. Message Queuing Telemetry Transport (MQTT)
• Designed by Andy Stanford Clark and Arlen Nipper for IBM in 1999
• Made free and open in 2014.
• Lightweight protocol.
• It demands minimal resources for its functioning.
• It does not require additional resources from its working environment.
• IoT prefers MQTT due to resource constraints.
• It follows the publish – subscribe pattern.

IoT – Moduel 2 9
 Messaging Protocols……
1. Message Queuing Telemetry Transport (MQTT) …
MQTT Publish – Subscribe Pattern

IoT – Moduel 2 10
 Messaging Protocols……
1. Message Queuing Telemetry Transport (MQTT) . . .
MQTT Publish – Subscribe Pattern
• This model has three entities – publisher, broker, and subscriber.
• Central core is called broker and plays a key role in the entire system.
• The publisher can sends data/message to the MQTT broker.
• The broker dispatching the messages to the subscribed destinations.
• The data reaches the nodes that really wants it and not to all the nodes present in the
network.
• The messages are published as topics and the publisher publishes the message with
topic.
• Clients subscribe to the topic and they get the message based on their subscription.
• In MQTT, clients do not have any address.
• Instead of address, the topics are used to root the message appropriately.
• So the topics are used to connect the publisher to the subscriber.
IoT – Moduel 2 11
 Messaging Protocols……

1. Message Queuing Telemetry

Transport (MQTT) . . .
MQTT Client and Broker
• In MQTT protocol the clients who are
subscribers can publish.
• Once the messages reach the clients, the
messages gets removed from the broker.
• That means the life of the message is
limited, and if there are no subscribers, it
automatically gets deleted.

IoT – Moduel 2 12
 Messaging Protocols……
1. Message Queuing Telemetry Transport (MQTT) . . .
MQTT Client and Broker

MQTT Client MQTT Broker

(a) Collect information from sensors. (a) Protocol is implemented in this case
(b) Connect to the messaging server (b) Mediate and facilitate the data
(Broker) based on interest of the subscriber.
(c) Topic is used to publish this message
to let other clients understand.
(d) Can also be a subscriber

IoT – Moduel 2 13
 Messaging Protocols……
1. Message Queuing Telemetry Transport (MQTT) . . .
MQTT Quality of Service (MQTT QoS)

There are three levels of QoS supported by MQTT.

1. 0 = At most one (Best effort, No Acknowledgement)
2. 1 = At least once (Acknowledged, retransmitted if ack is not received
3. 2 = Exactly once (Request to send (publish), clear to send)

IoT – Moduel 2 14
 Messaging Protocols……
MQTT Implementation Subscription Process
• It is publish – subscription process • Two NodeMCUs are used
• NodeMCU and sensors are used. • One NodeMCU connected to a
sensor
Publishing Process • The data published in the cloud is
• The sensor senses the data and pushes
to be subscribed in parallel by
it to the cloud through NodeMCU,
another NodeMCU
which is one of the nodes. This node is • The moment when the data
referred as publisher.
reaches the cloud , the data will be
• The process of transmission is taken
acquired by the client(subscriber)
care by MQTT protocol
based on the subscription
• Cloud service provider acts as the
preferred
broker and takes care of the
One NodeMCU will publish while
subscribers provided with appropriate
the other will read through
messages. IoT – Moduel 2
subscription . 15
 Messaging Protocols……
2. Constrained Application Protocol (CoAP)

• It is a specialized Internet Application Protocol for constrained devices.

• It is a lightweight protocol.
• It is designed by IETF (Internet Engineering Task Force) to work in constrained
environments
• It is used to enable the smart devices to connect to the internet.
• It is a one-to-one communication protocol.
• It uses lesser resources than HTTP.
• It is a simplification of the HTTP protocol running on UDP and is connectionless.

IoT – Moduel 2 16
 Messaging Protocols……
Constrained Application Protocol (CoAP)
Architecture
• The CoAP has a Client – Server model
architecture.
• The client will send a request followed by
server’s response to the request with an
appropriate reply.
• CoAP is based on the REST API model
known as RESTful (Representational State
Transfer).
• REST ensures a secure, fault-tolerant and
scalable system.
• The CoAP optimizes the datagram length.
• It also support multicast.
IoT – Moduel 2 17
IoT – Moduel 2 18
 Messaging Protocols……

Layers of CoAP

• CoAP is a two-layered protocol.

• Lower layer is the message layer and the
upper layer owns the request-response
process.
• The upper layer is dependent on UDP.

IoT – Moduel 2 19
 Messaging Protocols……
Layers of CoAP – Message Layer

CoAP supports four different message types.

1. Confirmable (CON) / Reliable Message
2. Non-Confirmable (NON) / Non-Reliable Message
3. Acknowledgement (ACK) Message
4. Reset (RST) Message

Confirmable (CON) / Reliable Messaging

• This is a reliable approach.

• Here, retransmission occurs until the acknowledgement
is received with the same message ID.
• When there is timeout or fail, there would be a RST
message send from the server as a response.
IoT – Moduel 2 20
 Messaging Protocols……
Layers of CoAP – Message Layer …

Non - Confirmable (NON) / Non - Reliable Messaging

• No reliability ensured in this message transmission style
• No acknowledgement will be issued in the message.
• In case no processing carried out by the receiver, RST
message is sent

Acknowledgement (ACK) Messaging

• Traditional acknowledgement message sent
• Similar to regular handshaking scheme.
Reset (RST) Messaging
• RST messages are sent to cancel a pending CON message that hasn’t yet been
acknowledged.
• They are typically used when a receiver cannot or choose not to process a pending
message. IoT – Moduel 2 21
 Messaging Protocols……
Layers of CoAP – Request – Response Layer
• In this, the client sends a CoAP request to the
server, and the server responds with the
requested data or action.
• CoAP supports three types of request –
responses.
1. Piggy – Backed
Success Message Failure Message
2. Separate Response
3. Non – Confirmable Request and Responses
Piggy - Backed

• In this mode, the client sends a request through

the CON/NON-messaging method.
• ACK is received immediately with
corresponding token number and message.
IoT – Moduel 2 22
 Messaging Protocols……
Layers of CoAP – Request – Response Layer

Separate Response

• When a CON type message is sent to the server

and 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

IoT – Moduel 2 23
 Messaging Protocols……

Layers of CoAP – Request – Response Layer

Non – Confirmable Request and Response

• In this type, 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.

IoT – Moduel 2 24
 Messaging Protocols……

Layers of CoAP – Request – Response Layer

Non – Confirmable Request and Response

• In this type, 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.

IoT – Moduel 2 25
 Messaging Protocols……
CoAP Message Format

CoAP message header Description

V (version) It is 2 bit unsigned integer refers the version number.
It is 2 bit unsigned integer indicates message type viz. confirmable (0), non-
T (type)
confirmable (1), ACK (2) or RESET(3).
TKL (token length) It is 4 bit unsigned integer refers token length, normally 0 to 8 bytes.
Code It is 8 bit unsigned integer, refers to the response code
Message ID Identifier of the message, normally 16 bits.

IoT – Moduel 2 26
 Messaging Protocols……

Difference between MQTT and CoAP

MQTT CoAP
Protocol used is TCP. Connection Protocol used is UDP. i.e.
oriented Connectionless
Supports many – to – one Supports one – to – one
communication communication
Power consumption is higher than Consumes less power
CoAP and lesser than other protocols.

Model used is publisher/subscriber Request – response model called

RESTful.
IoT – Moduel 2 27
 Transport Protocol
• Transport protocol enables the data transport. BLE Symbol
• Two important protocols used for the data transport are :
1. Bluetooth Low Energy (BLE)
2. Light Fidelity (Li – Fi)
Bluetooth Low Energy (BLE)
• Also called Bluetooth Smart.
• It is an open low-energy short-range radio communication technology.
• Designed by Bluetooth Special Interest Group (SIG).
• It is a wireless personal area network (PAN) technology.
• It is an advancement of earlier version of Bluetooth.
• It is superior to classic Bluetooth, because it consumes less power.
• It is supported by Android, IOS, Blackberry etc to use with any mobile OS.
• It is also supported by MacOS, Windows 8/10 and Linux variants.
• It is widely used in healthcare, entertainment, fitness and proximity related
applications. IoT – Moduel 2 28
 Transport Protocol ….
Features of Bluetooth Low Energy (BLE)

• It is license free and hence does not add any costing related overhead to the system.
• There is no restriction with respect to manufacturers.
• BLE modules are inexpensive and much affordable.
• Small in size and they do not occupy much space on board.
• Power consumption is minimum.
• The range offered by BLE is much higher.

IoT – Moduel 2 29
 Transport Protocol ….
Components of BLE
• Based on the architectural perspective, BLE
has three components.
1. Application Block – User application is BLE
situated here and it interacts directly with
Bluetooth stack.
2. Host Block – It is the upper layer of the
Bluetooth stack. Application Controller
3. Controller Block – This is the lower layer of
the Bluetooth stack Host
• In addition, there is another block called Host
Controller Interface used to interface the
controller with the host. This makes to
interface a variety of hosts to the controller.
IoT – Moduel 2 30
 Transport Protocol ….
BLE Protocol Stack/Architectural Representation of BLE

IoT – Moduel 2 31
 Transport Protocol ….
BLE Protocol Stack/Architectural Representation of BLE

• BLE protocol stack consists of three parts – Controller, Host and Application.
• The Host and Controller are interfaced using HCI (Host Controller Interface).

Controller
• It consists of Host controller interface, link layer and physical layer.
1. Host Controller Interface (HCI) – Used to enable the interoperability between hosts
and controllers assembled by different manufactures.

2. Link Layer (LL) – It defines the packet structure

3. Physical Layer (PHY) – It enables the transmission and reception, modulation and
demodulation. Also responsible for analog to digital conversion.

IoT – Moduel 2 32
 Transport Protocol ….
BLE Protocol Stack/Architectural Representation of BLE ….

Host
• It includes :
1. Generic Access Profile (GAP)
2. Generic Attribute Profile (GATT)
3. Attribute Protocol (ATT)
4. Logical Link Control and Adaptation Protocol (L2CAP)
5. Security Manager (SM)
6. Host Controller Interface (HCI)

IoT – Moduel 2 33
 Transport Protocol ….
BLE Protocol Stack/Architectural Representation of BLE ….
Host ..
1. Generic Access Profile (GAP) – This layer is mandatory for all devices and it
enables the device discovery, connection establishment, connection management and
security.
2. Generic Attribute Profile (GATT) – It oversees the data exchange process.
Whenever there is a need to push data and to read or write data according to generic
guidelines.
3. Attribute Protocol (ATT) – It is the protocol for accessing data.
4. Logical Link Control and Adaptation Protocol (L2CAP) – It is responsible for
fragmentation and de-fragmentation of the application data. It administers the
multiplexing and demultiplexing of channels over the shared logical link.
5. Security Manager (SM) – It handles pairing, authentication and encryption.
6. Host Controller Interface (HCI) – It enables the interoperability between hosts and
controllers assembled by different manufacturers.
IoT – Moduel 2 34
 Transport Protocol ….
BLE Protocol Stack/Architectural Representation of BLE ….

Application Layer

• Similar to application layer of OSI reference model.

• Topmost layer in BLE.
• Responsible for user interface, logic and data handling.

IoT – Moduel 2 35
 Transport Protocol ….
BLE Topology
• A BLE device communicates with outside world
by broadcasting and connections.
Broadcasting
• Sending out a message to more than one
recipient.
• In broadcast data is sent out one way.
• There are two parts for broadcasting –
Broadcaster and Observer
Broadcaster : Sends “non-connectable” advertising
packets in frequent intervals to all those who are
willing to collect it
Observer : Keep scanning at the preset frequency
to receive any non-connectable packets that are
being broadcasted.
IoT – Moduel 2 36
 Transport Protocol ….
BLE Topology …
Connections
• It is permanent and enables periodic data transfer between two devices.
• The idea behind it is master – slave configuration
• The master will try to find out the advertising packets, then initiates the connection.
• After establishing the connection, the master will periodically exchange data.
• The slave will periodically sending the packets.
• When there is an incoming request , it would be accepted by the slave to whom it is
addressed.
• When two devices are connected, it is called connection event.
• It is ideal for power saving.
• It works only when there is a need, rest of time devices are in sleep mode.

IoT – Moduel 2 37
 Transport Protocol ….
BLE Topology …

Connections

IoT – Moduel 2 38
 Transport Protocol ….
Light – Fidelity (Li – Fi)

The concerns related to the consumption of internet are :

• Is the internet through wi – fi safe ?
• How much bandwidth availability would be sufficient for devices/equipment ?
• How safe is your data ?
• Increase in number of devices will lead to congestion. How is this handled ?

Solution for these concerns are Li – Fi.

• In Li-Fi, Light is used as a medium to transfer/transport data.
• Does not require any special equipment.
• The lights (electric bulb) are sufficient with little modifications to transfer data.
• It is fastest and has a speed of 224 GB/sec.

IoT – Moduel 2 39
 Transport Protocol ….
Features of Light – Fidelity (Li – Fi)

• It has high speed and is bi – directional.

• Used for data communication.
• Light is the source for data transfer.
• Li – Fi is inexpensive, because light is generated through bulbs.
• The security and bandwidth issues in Wi – Fi can be avoided using Li – Fi.

IoT – Moduel 2 40
 Transport Protocol ….
Working of Light – Fidelity (Li – Fi)

IoT – Moduel 2 41
 Transport Protocol ….
Working of Light – Fidelity (Li – Fi) ….
• Li – Fi needs a light source to transfer data.
• It needs modified LED bulbs/lights, which can transmit data.
• Led is preferred, because it is a semiconductor device and will have switching
characteristics.
• Li – Fi is constructed with many components which start with a modified LED bulb.
• Data is transmitted over Li-Fi by modulating the intensity of light.
• The light is received by the photodetector and demodulation(process) happens to
generate the data stream.
• All the LED lamps need an LED lamp driver.
• The driver gets information from the server and encoding occurs.
• After that, LED illuminates(flickers).
• The photodetector will be able to read this and convert it into data after
amplification.
IoT – Moduel 2 42
 Transport Protocol ….
Advantages and Disadvantages of Light – Fidelity (Li – Fi) ….

Advantages Disadvantages
Light cannot penetrate through walls, It could be short range due to the
it is safe and no data hijacking will presence of walls, which is a real
happen interruption.
Efficient than wi – fi More time is taken to set up the
infrastructure, so as to make it
practically viable.
Fastest and is expected to break all There is no clarity on how the
previous records receiving device will transmit data
Effective alternate to RF back to the transmitter.

IoT – Moduel 2 43
 Protocol for Addressing & Identification

• The Internet Protocol (IP) is a set of standards for addressing and

routing data on the Internet.
• Many IoT equipments in the network should be identified by an address
called IP address.
• IP address is a unique identification for a node connected to a network.
• The important addressing protocols in IoT are:
1. Internet Protocol Version 4 (IPV4)
2. Internet Protocol Version 6 (IPV6)

IoT – Moduel 2 44
 Protocol for Addressing & Identification …..
Internet Protocol Version 4 (IPV4)

• An IP address is a unique identification for a node connected to a network.

• IPv4 addresses are 4 bytes or 32 bits long.
• They can be represented in binary or decimal format.
• Decimal format is much easier to remember, so many prefer decimal format
Eg: 10.10.10.220 (decimal format)
In Binary, 00001010.00001010.00001010.11011100
• An IP address comprises two halves – Network ID and Host ID.
• Network ID is used to designate a specific network or host.
• Host ID is used to identify a specific TCP/IP network.

IoT – Moduel 2 45
 Protocol for Addressing & Identification …..
Internet Protocol Version 4 (IPV4)

Classification of IPV4
• In IPV4, IP addresses are classified into 5 classes.
• They are Class A, Class B, Class C, Class D and Class E.

IoT – Moduel 2 46
 Protocol for Addressing & Identification …..
Classification of IPV4 …..

Class A
• Dedicated for very huge network
• For ex: if a company has many branches and many people working for it class A will
be used
• In this type, first octet can be from 1 to 126. i.e. there can be 126 networks possible.
• The first bit of first octet will always be set to zero.
• The remaining three octet (24 bits) used for host ID.
• In this, there can be 224-2 IP addresses can be generated. i.e. this is 17 million hosts
per network.
• 127 is the loop back address used by the host computer to send a message to itself.
Commonly used for troubleshooting and network testing (127.0.0.1)

IoT – Moduel 2 47
IoT – Moduel 2 48
 Protocol for Addressing & Identification …..
Classification of IPV4 …..

Class B

• It is mainly for medium - sized network. Eg: school or college campus

• Class B uses IP addresses from 128 to 191
• First two octets for network ID and the remaining two for host ID
• First two bits of first octet is fixed to 10
• Maximum possible networks are 216- 2, each with 65,534 hosts
• Class B addresses can be identified by at the first byte, i.e from 128 to 191.

IoT – Moduel 2 49
 Protocol for Addressing & Identification …..
Classification of IPV4 …..

Class C
• Used in small networks
• First 3 octets represent the network ID and last octet represents the host ID
• Class C address starts with 192 and end in 223
• First 3 bits of first octet are fixed as 110
• 21 bits will form the network ID
• It allows 28-2 (254) hosts per network

IoT – Moduel 2 50
 Protocol for Addressing & Identification …..
Classification of IPV4 …..

Class D

• Used for multicasting

• First four bits of first octet is fixed as 1110
• The addresses starts from 224 and ends in 239

Class E

• Used for experimental purposes

• It holds the first bit value as 1, second bit at 1, third bit as 1, and fourth bit as 1.

IoT – Moduel 2 51
 Protocol for Addressing & Identification …..
IPV4 Protocol Format
The important fields in the IPV4 protocol message format as :

IoT – Moduel 2 52
 Protocol for Addressing & Identification …..
IPV4 Protocol Format
1. IP version number
• It is a 4 bit field which indicates the version of IP being utilized
• This field has value 4 in binary(0100).
• It ensure the compatibility between the versions of IP that might be used in the network.
2. Internet Header Length
• Specifies internet header length in 32 bit word and points to the beginning of data
• The minimum value for a header is 5(0101)
3. Type of service
• 8 bit field which indicates quality of service and is composed of 8 bits.
• QoS can be precedence, delay and reliability
• Precedence: bits 0 to 2 represent precedence. The important precedence are
• 000 – Routine
• 001 – Priority
• 010 – Immediate
• 111 – Network control etc IoT – Moduel 2 53
 Protocol for Addressing & Identification …..
IPV4 Protocol Format …
3. Type of service..
• Delay: This is the 4th bit. Here 0 indicates normal delay and 1 indicates lower delay
• Throughput: 0 indicates normal throughput, 1 indicates high throughput
• Reliability: 0 indicates normal reliability and 1 indicates high reliability

4. Total Length:
• This is a 16 bit field which indicates the length of the IPv4 datagram.
• This length includes header and data
• The minimum length of the IP datagram is 20 bytes and the maximum can be 65,535
bytes

5. Identification
• 16 bit field added by the sender to help in assembling the fragments
IoT – Moduel 2 54
 Protocol for Addressing & Identification …..
IPV4 Protocol Format …
6. Flags
• Composed of three bits
• The first bit is always zero and is kept unused.
• Second bit is Don’t Fragment (DF).
• If DF is set to 0 the IP datagram can be fragmented, and if set to 1 it cannot be
fragmented
• Third bit is called More Fragments (MF), the set will indicate that more fragments
are on the way.
7. Fragment Offset
• When a fragmentation of a message acquires this field specifies the offset in the
overall message where the data in this fragment is present.
• It is specified in units of 8 bytes
• The first fragment has an offset of 0.
IoT – Moduel 2 55
 Protocol for Addressing & Identification …..
IPV4 Protocol Format …
8. Time to Live
• It is an 8-bit field which indicates the time that IP datagram will survive
• There will be a time set that will be decremented by 1.
• When it reaches 0, the datagram will be discarded by router
9. Protocol
• This indicates the higher layer protocol carried in the IP datagram.
• The important protocols are ICMP (internet Message Control Protocol), IGMP
(Internet Group Management Protocol), TCP or UDP etc
10. Header Checksum
• This is a 16-bit checksum computed over the header to provide basic protection
against corruption in transmission
11. Source address
• It is a 32-bit IP address indicates of the source of the datagram
IoT – Moduel 2 56
 Protocol for Addressing & Identification …..
IPV4 Protocol Format …
12. Destination Address
• It is a 32-bit IP address indicates of the destination of the datagram

13. Options

• This is an optional field which includes any optional values in the header
14. Padding

• IP options field may vary in length. The padding field provides additional bits so
that the total header length is an exact multiple of 32 bits

IoT – Moduel 2 57
 Protocol for Addressing & Identification …..
Internet Protocol Version 6 (IPv6)

• IPv6 was developed to overcome the difficulties faced with IPv4 address allocations.
• Named as the next generation protocol for the Internet
• Works in layer 3
• It has more addresses and multiple features than IPv4
• IPv6 provides 2128 unique IP addresses.
• IPv6 addresses are 128 bits long, written in hexadecimal and separated by colons
• Eg: 3ffe:1900:4545:3:200:f8ff:fe21:67cf.
• Colons separate 16 bit fields.
• Leading zeros can be omitted in each field. Eg: 0003 is written as 3
• A double colon :: can be used once in an address to replace multiple fields of zeros
• Ex: fe80:0:0:0:200:f8ff:fe21:67cf can be written as fe80::200:f8ff:fe21:67cf
• The two colons tell the operating system that everything in between is a zero
IoT – Moduel 2 58
 Protocol for Addressing & Identification …..
Features of Internet Protocol Version 6 (IPv6)

• It has much better and efficient routing

• IPsec framework is mandatory in IPv6 which increases the security
• An additional flow label is added in the header of IPv6 which can improve the QoS
• IPv6 supports new applications such as IP telephony, video/audio, interactive games
etc with ensured QoS
• Plug and play abilities have been improved in IPv6
• IPv6 has eliminated the need for Network Address Translation due to the huge
availability of IP addresses.

IoT – Moduel 2 59
 Protocol for Addressing & Identification …..
Internet Protocol Version 6 (IPv6) Protocol Format
• IPv6 cuts down some IPv4 header fields to IPv6 extension headers to reduce the
load of basic headers
• This makes IPv6 packet handling simple and improves the forwarding efficiency.
• The IPv6 address size is four times more than that of IPv4
• IPv6 headers is 40 bytes and is twice that of IPv4 headers

IoT – Moduel 2 60
 Protocol for Addressing & Identification …..
Internet Protocol Version 6 (IPv6) Protocol Format ….
1. Version
• Used to represent the version of IP being used. i.e. 6 in IPv6.
• It is 4 bits long.
2. Traffic Class (8 bits)
• 8 bit field that identifies different classes or priorities of IPv6 packets.
• It replaces the ToS field of IPv4.
• MSB 6 bits are used for ToS and the LSB 2 bits are used for Explicit Congestion
Notification
3. Flow Label(20 bits)
• Used to identify the sequence of packets.
• Helps in prioritizing packet delivery and providing real time service.
• The vital packets can be delivered ahead of the lower priority packets.

IoT – Moduel 2 61
 Protocol for Addressing & Identification …..
Internet Protocol Version 6 (IPv6) Protocol Format ….
4. Payload Length(16 bits)
• This identifies the length of the IPv6 payload ( the rest of the packet following IPv6
header)
• It is used in place of total length of IPv4.
5. Next Header(8 bits)
• Similar to the protocol field in IPv4 header.
• It represents the type of extension header that follows the primary IPv6 header
6. Hop Limit (8 bits)
• Time to Live (TTL) is replaced by Hop Limit in IPv6 header.
• The value in this field is decremented by 1 every time the packet passes through a
host that forwards the packet.
• When the value reaches 0, the packet will be discarded.

IoT – Moduel 2 62
 Protocol for Addressing & Identification …..
Internet Protocol Version 6 (IPv6) Protocol Format ….

7. Source Address
• As in IPv4 this specifies the sender’s IP 128-bit address

8. Destination Address
• Similar to IPv4, the destination’s IP address.
• Its length is 128 bits.

IoT – Moduel 2 63
 Protocol for Addressing & Identification …..
Uniform Resource Identifier (URI)
• It is a resource identifier protocol.
• Uniform Resource Identifier(URI) is a sequence of characters used to identify logical
resources.
• All guidelines with respect to URI are issued by the IETF (Internet Engineering Task
Force)
• URI has Uniform Resource Name(URN)/ Uniform Resource Locator(URL) in it
• URIs try to identify a resource and location by accessing its address and name through a
primary access mechanism
• URN defines an item’s identity whereas URL renders a method for finding it
• URL contains information on how to fetch or acquire a resource from its location
• URL always begin with a protocol(http).
• It will have the details of host name and path.
• A URL is used when a client raises a request to the server for the service.
• Uniform Resource Name (URN) gives the name of a resource and its identification
IoT – Moduel 2 64
 Protocol for Addressing & Identification …..
Uniform Resource Identifier (URI) …

Sample URL

IoT – Moduel 2 65
THANK YOU

IoT – Moduel 2 66