Unit – III

IoT Protocols

Protocol Standardization for IoT – Efforts – M2M and

WSN Protocols – SCADA and RFID Protocols –
Unified Data Standards – Protocols – IEEE 802.15.4 –
BACNet Protocol – Modbus – Zigbee Architecture –
Network layer – 6LowPAN – CoAP – Security.

6. Protocol Standardization for IoT 1

6. Protocol Standardization for IoT

Key Topics

6.1 Web of Things Vs Internet of Things

6.2 Two Pillars of Web

6. Protocol Standardization for IoT 2

 6.1 Web of Things vs. Internet of Things
 The difference between the Internet and the World Wide
Web
• The Internet is the term used to identify the massive
interconnection of computer networks around the
world.
• It refers to the physical connection of the paths
between two or more computers.

6. Protocol Standardization for IoT 3

 The World Wide Web is the general name for accessing the Internet
via HTTP, thus www.anything.something.
 The Internet is the large container, and the web is a part within the
container.
The Internet

FTP Email

World Wide Web

IM
Telnet
Gopher Chat
P2P

 The key to make the Internet of Things (IoT) takes off is the Web of
Things (WoT) – the killer applications’ platform or base of the IoT.
 The WoT is the next logical step in this IoT evolution toward global
networks of sensors and actuators, enabling new applications and
providing new opportunities.
6. Protocol Standardization for IoT 4
 The WoT explores the layer on top of connectivity with things and
addresses issues such as fast prototyping, data integration, and
interaction with objects.

 The WoT is a version where things become seamlessly integrated into

the web.

 There are also many other WoT applications around the world. Some
of the WoT applications are listed here.

• Arduino
• Japan Geiger Map
• Nanode
• The National Weather Study Project
• AgSphere

6. Protocol Standardization for IoT 5

6.1.1 Two Pillars of the Web
 The application server became the foundation that helped build widely
spreading web-based applications.
 An application server acts as a set of components accessible to the
software developer through an API defined by the middleware itself.
 The application server is based on the three-tiered (Fig. 6.2) or multi-
tiered software architecture.
 As the two pillars for web applications and the Internet revolution, the
protocols (HTML)/HTTP/URL and the software will continue to be
the two pillars of play an important role in building WoT applications.

6. Protocol Standardization for IoT 6

 IoT Protocol Standardization
Efforts
Key Topics
 6.2.1 M2M and WSN Protocols

 6.2.2 SCADA and RFID Protocols

 6.2.3 Issues with IoT Standardization

6. Protocol Standardization for IoT 7

 6.2 IoT Protocol Standardization Efforts
 The current status of IoT standardization
• Fragmented architectures, no coherent unifying concepts, solutions exist
only for application silos.
• No holistic approach to implement the IoT has yet been proposed.
• Many island solutions do exist (RFID, sensor nets, etc.)
• Little cross-sector reuse of technology and exchange of knowledge.
 The key objectives of the IoT-A consortium are as follows:
• Create the architectural foundations of an interoperable Internet of Things
as a key dimension of the larger future Internet.
• Architectural reference model together with an initial set of key building
blocks:
• Not reinventing the wheel but federating already existing technologies
• Demonstrating the applicability in a set of use cases
• Removing the barriers of deployment and wide-scale acceptance of the
IoT by establishing a strongly involved stakeholder group
• Federating heterogeneous IoT technologies into an interoperable IoT
fabric

6. Protocol Standardization for IoT 8

 There are many Working groups of IoT standards
 The emergency application space for smart objects require
scalable and interoperable communication mechanisms
that support future innovation as the application space
grows.
 A smart object is defined by IPSO (Internet Protocol Smart
Object) as
• An intelligent (RFID) tag
• A Sensor
• An actuator
• An embedded device
• Any combination of the above features to form a more
complex entity

6. Protocol Standardization for IoT 9

6.2.1 M2M and WSN Protocol

 A broad horizontal standard is a key requirement for the M2M

industry to move from its current state of applications existing in
isolated silos based on vertical market or underlying technology to a
truly interconnected IoT.
 The most important activity is occurring within the context of the
International Telecommunication Union’s (ITU) and ETSI’s (M2M
Technical Committee) Global Standards Collaboration (GSC), which
has established the M2M Standardization Task Force (MSTF) to
coordinate the efforts of individual standards development
organizations (SDOs), including China Communications Standards
Association, Telecommunications Industry Association TR-50 Smart
Device, etc.

6. Protocol Standardization for IoT 10

 The end result of these efforts is to define a conceptual framework
for M2M applications that is vertical industry and communication
technology agnostic, and to specify a service layer that will enable
application developers to create applications that operate
transparently across different vertical domains and communication
technologies without the developers having to write their own
complex custom service layer.

6. Protocol Standardization for IoT 11

 Other M2M standards activities include the following:

 Data transport protocol standards: M2MXML, JavaScript Object Notation

(JSON), BiTXML, WMMP (Wireless Machine Management Protocol),
MDMP(M2M Device Management Protocol), open Building Information Exc
hange (oBIX), EEML (Extended Enterprise Modeling Language), open
M2M Information exchange (oMIX)
 Extend OMA DM to support M2M devices protocol management objects
 M2M device management, standardize M2M gateway
 M2M security and fraud detection
 Network API’s M2M service capabilities
 Charging standards
 MULTI –IMSI (International Mobile Subscriber Identity), M2M services that
do not have MSISDN
 IP addressing issues for devices IPV6
 Remote diagnostics and monitoring, remote provisioning and discovery
 Remote management of devices behind a gateway or firewall
 Open REST-based API for M2M applications

6. Protocol Standardization for IoT 12

 One of the benefits of using sensor data is that the data typically can
be reused many times, thereby reducing cost and maximizing benefit.
For example, weather observations (temperature, wind speed and dire
ction, humidity, and so on) can be used in climate modeling, weather
forecasting, plume modeling, insurance risk analysis, ski area location
decisions, and dozens of other applications.
 However, the ability to access and use the same sensors in multiple
application domains, to share sensor data, and to maximize the full
value of sensor networks and data is severely hindered by a lack of
interoperability.
 Hundreds of sensor manufacturers build sensors for specific purposes
, often using their own “language” or encodings, different metadata, a
nd so forth. Standard data representation (together with WSN middle
ware) is the key to materialize data integration and increase interoper
ability.

6. Protocol Standardization for IoT 13

 There are a number of standardization bodies in the field of
WSNs.
• IEEE  focuses on the physical and MAC layers
• IETF  works on layer 3 or above

 IEEE 1451 is a set of smart transducer interface standards

developed by the IEEE Instrumentation and Measurement
Society’s Sensor Technology Technical Committee that
describe a set of open, common, network-independent
communication interfaces for connecting transducers (sensors
or actuators) to microprocessors, instrumentation systems
and control/field networks.

6. Protocol Standardization for IoT 14

 The Semantic Sensor Web (SSW) is an approach to
annotating sensor data with spatial, temporal, and
thematic semantic metadata based on OGC SWE (Sensor
Web Enablement).
 The European Union SENSEI project creates an open,
business driven architecture that fundamentally address
es the scalability problems for a large number of globally
distributed wireless sensor and actuator networks
(WSAN) devices.
 ISO/IEC JTC1 WG7 (Working Group on Sensor Network
s),established in 2009, preceded by JTC 1 SGSN SC6, cre
ated the ISO/IEC 29182 Reference Architecture for senso
r networks application and services focusing on telecom
munication and information exchange between systems.

6. Protocol Standardization for IoT 15

6.2.2 SCADA and RFID Protocols

SCADA - (Supervisory Control And Data Acquisition)

RFID - (Radio Frequency Identification)

6. Protocol Standardization for IoT 16

6. Protocol Standardization for IoT 17
 IEEE created a standard specification, called Std C37.1™, for SCADA
and automation systems in 2007, targeting mostly power SCADA
applications (Figure 6.9).

 It’s recognized in the specification that in recent year, network-based

industrial automation has greatly evolved with the use of intelligent
electronic devices (IEDs), or IoT devices in our terms, in substations
and power stations.

 The processing is now distributed, and functions that used to be done

at the control center can now be done by the IED, that is, M2M
between devices.

 Despite the fact that many functions can be moved to the IED, utilities
still need a master station, the IoT platform, for the operation of the
power system.

6. Protocol Standardization for IoT 18

6. Protocol Standardization for IoT 19
 The Object Linking and Embedding for Process Control (OPC)
Foundation is an industry consortium that creates and maintains
standards for open connectivity of industrial automation devices and
systems

 The OPC standards specify the communication of industrial process

data, alarms and events, historical data and batch process data
between sensors, instruments, controllers, software systems, and
notification devices.

6. Protocol Standardization for IoT 20

6. Protocol Standardization for IoT 21
 OPC was designed to provide a common bridge for
Windows-based software applications and process
control hardware. Standards define consistent methods
of accessing field data from plant floor devices. This
method remains the same regardless of the type and
source of data.
 An OPC server for one hardware device provides the
same methods for an OPC client to access its data as each
and every other OPC server for that same or another
hardware device.
 The aim was to reduce the amount of duplicated effort
required from hardware manufacturers and their
software partners, and from the SCADA and other HMI
producers, in order to interface the two.

6. Protocol Standardization for IoT 22

Radio Frequency Identification (RFID)
 Radio Frequency Identification refers to the use of radio frequency tags to
identify real objects.

 An ADC (Automated Data Collection) technology that:

• uses radio-frequency waves to transfer data between a reader and a

movable item to identify, categorize, track.

• Is fast and does not require physical sight or contact between reader
/scanner and the tagged item.

• Performs the operation using low cost components.

• Attempts to provide unique identification and backend integration that
allows for wide range of applications.

 Other ADC technologies: Bar codes, OCR.

6. Protocol Standardization for IoT 23

 Working Principle of RFID
 An RFID tag is a simplified, low-cost,
disposable contactless smartcard.
 RFID tags include a chip that stores a static
number (ID) and attributes of the tagged
object and an antenna that enables the chip
to transmit the store number to a reader.
When the tag comes within the range of the a
ppropriate RF reader, the tag is powered by
the reader’s RF field and transmits its ID and
attributes to the reader.

6. Protocol Standardization for IoT 24

 Working Principle
 Tag enters RF field Antenna
 RF signal powers tag
 Tag transmits ID, plus data
 Reader captures data
 Reader sends data to computer
 Computer determines action
 Computer instructs reader
 Reader transmits data to tag
Tag

Computer
RFID
Reader
RFID system components

Ethernet
RFID
Reader

RFID Tag RF Antenna Network Workstation

RFID 2005 IIT Bombay 26

 RFID tags
Tags can be attached to almost anything:
• Items, cases or pallets of products, high value goods
• vehicles, assets, livestock or personnel
Passive Tags
• Do not require power – Draws from Interrogator Field
• Lower storage capacities (few bits to 1 KB)
• Shorter read ranges (4 inches to 15 feet)
• Usually Write-Once-Read-Many/Read-Only tags
• Cost around 25 cents to few dollars
Active Tags
• Battery powered
• Higher storage capacities (512 KB)
• Longer read range (300 feet)
• Typically can be re-written by RF Interrogators
• Cost around 50 to 250 dollars
RFID 2005 IIT Bombay 27
 RFID tag memory
 Read-only tags
• Tag ID is assigned at the factory during manufacturing
• Can never be changed
• No additional data can be assigned to the tag
 Write once, read many (WORM) tags
• Data written once, e.g., during packing or manufacturing
• Tag is locked once data is written
• Similar to a compact disc or DVD
 Read/Write
• Tag data can be changed over time
• Part or all of the data section can be locked

RFID 2005 IIT Bombay 28

 RFID readers
 Reader functions:
• Remotely power tags
• Establish a bidirectional data link
• Inventory tags, filter results
• Communicate with networked server(s)
• Can read 100-300 tags per second
 Readers (interrogators) can be at a fixed point such as
• Entrance/exit
• Point of sale
 Readers can also be mobile/hand-held

RFID 2005 IIT Bombay 29

 RFID - (Radio Frequency
Identification)
 The RFID protocols and data formats are
relatively well defined, mostly by EPC global, and
unified compared with protocols and formats of
the other three pillars of IoT.
 The RFID protocols - PML, Object Naming
Service [ONS], Edgeware, EPC Information
Service[EPCIS], Application Level Event [ALE],
etc.)

6. Protocol Standardization for IoT 30

 The smart cards with contactless interfaces (RFID
is a subset) are becoming increasingly popular for
payment and ticketing applications, credit cards,
Driving licenses etc.
 The standard for contactless smart card
communications is ISO/IEC 14443.
 It defines two types of contactless cards (A and B)
and allows for communications at distances up to
10 cm. An alternative standard for contactless
smart cards is ISO/IEC 15693, which allows
communications at distances up to 50 cm (Figure
6.11).

6. Protocol Standardization for IoT 31

6. Protocol Standardization for IoT 32
6.2.3 Issues with IoT Standardization

 Standardization is like a double-edged sword: critical to market

development, but it may threaten innovation and inhibit change when
standards are accepted by the market.

 The following two issues for the IoT standardization in particular and
the ICT standardization in general may never have answers:
• ICT standardization is a highly decentralized activity. How can the
individual activities of the network of extremely heterogeneous
standards-setting bodies be coordinated?
• It will become essential to allow all interested shake-holders to
participate in the standardization process toward the IoT and to
voice their respective requirements and concerns. How can this be
achieved?

6. Protocol Standardization for IoT 33

 Unified Data Standards
Key Topics
 Unified Data Standards – A challenging Task

 Unified Identification of Objects

6. Protocol Standardization for IoT 34

6. Protocol Standardization for IoT 35
6. Protocol Standardization for IoT 36
6. Protocol Standardization for IoT 37
6. Protocol Standardization for 38
6. Protocol Standardization for IoT 39
6. Protocol Standardization for IoT 40
 The ubiquitous ID (uID) framework was developed in
Japan. uID or ucode is the identification number
assigned to individual objects.
 The ucode is a 128-bit fixed-length identifier system. Mor
eover, a mechanism to extend the ucode length in units o
f 128 bits has been prepared to meet the future demands
so that codes longer than 128 bits also can be defined.

6. Protocol Standardization for IoT 41

6. Protocol Standardization for IoT 42
 Many standards define certain objects for which
unambiguous identification is required. This is a
chieved by assigning OID
 to an object in a way that makes the assignment
available to interested parties. It is carried out by a
registration authority.
 The naming structure of OID is a tree structure
that allows the identification of objects in a local or
international context,without being limited by the
registration authority or by the number of objects
they can register (Figure 6.17).

6. Protocol Standardization for IoT 43

6. Protocol Standardization for IoT 44
 Security Issues in IoT
Key Topics
 List of 10 Security Issues
 Security issues in advanced stages of IoT development
 Security Protocols

6. Protocol Standardization for IoT 45

 The security issue of the IoT is always an issue of concern,
just like the security issue of all ICT systems.
 Some of the specific security issues that are more concern
ed with IoT application scenarios include the following (a
s summarized by the Association for Automatic Identifica
tion and Mobility, taking the RFID scenario as an
example but applicable to all IoT systems):

6. Protocol Standardization for IoT 46

1) Skimming: Data are read directly from the tag without the
knowledge or acknowledgment of the tag or device holder.
2) Eavesdropping or sniffing (also called “man-in-the-middle
” reader): Unauthorized listening/intercepting.
3) Data tampering: Unauthorized erasing of data to render
the device useless, or changing the data.
4) Spoofing: Duplicates device data and transmits it to a
receiver to mimic a legitimate source.
5) Cloning: Duplicates data of one device to another device.
6) Malicious code: Insertion of an executable code/virus to
corrupt the enterprise systems.

6. Protocol Standardization for IoT 47

7) Denial of access/service: Occurs when multiple
devices or specially designed devices are used to
overwhelm a receiver’s capacity, rendering the
system inoperative.
8) Killing: Physical or electronic destruction of the
device deprives downstream users of its data.
9) Jamming: The use of an electronic device to
disrupt the receiver’s function.
10) Shielding: The use of mechanical means to
prevent reading of a tag or device.

6. Protocol Standardization for IoT 48

 Security issues in advanced stages of
IoT development
 More number of devices involvement will
make the design and deployment of security
solutions more complex.
 The heterogeneous, multihop, distributed
networking environments make the passing
and translation of security credentials and the
end-to-end security functionalities a very diffic
ult mission across the four categories of netwo
rks, that is, the long- and short-range wireless,
and the long and short wired networks
categorized networks.

6. Protocol Standardization for IoT 49

 These cryptographic suites were designed with the
expectation that significant resources (e.g., processor
speed and memory) would be available. The differences of
sizes, limited storage capacities, and constrained
processing power of the devices also make the processing
of public key infrastructure (PKI) encryption, decryption,
and key management hard to be consistent along the
entire data flow.
 The joining and leaving (bootstrapping) of devices into the
IoT systems and the grouping of the mobile devices over
dynamic networks also add complexity to the
authentication and authorization process.

6. Protocol Standardization for IoT 50

 Security Protocols
Some of the following security protocols are discussed as candidate
solutions in the 6LoWPAN and CoRE IETF working groups

 The Internet Key Exchange (IKEv2)/IPsec and MOBIKE (Mobility

and Multi-homing IKEv2)
 The Host Identity Protocol (HIP) and a HIP variant for lossy low-power
networks called Diet HIP
 Transport layer security (TLS) and its datagram-oriented variant DTLS
secure transport-layer connections
 The Extensible Authentication Protocol (EAP)
 The Protocol for Carrying Authentication for Network Access (PANA)

6. Protocol Standardization for IoT 51

 IEEE 802.15.4
Key Topics

 Introduction
 Mac Layer

 Mac Layer Frame Format

 Physical Layer

 Physical Layer Frame Format

6. Protocol Standardization for IoT 52

 Introduction
 Until recently the main concentration In wireless was on
high throughput.
 Some applications for home automation, security, agricul
ture,industrial etc. have relaxed throughput requirement
s with low power consumption and low cost.
 Existing standards are not suitable because of high comp
lexity, power implications and high cost.
Applications
Home automation
 heating, ventilation, and air conditioning, security, lighting, and t
he control of objects.
Industrial
 detecting emergency situations, monitoring machines
Automotive
 automotive sensing, such as tire pressure monitoring;
Agriculture
 sensing of soil moisture, pesticide, herbicide, and pH levels.
Others
 Controlling consumer electronics, PC peripherals etc.
Data rate needed ranges from 115.2 kb/s to less than 10 kb/s.
 IEEE 802.15.4
 IEEE 802.15.4 task group began to develop a standard
for LR-WPAN.
 The goal of this group was to provide a standard with ultr
a-low complexity, cost, and power for low-data-rate wirel
ess connectivity among inexpensive fixed, portable, and
moving devices.
General characteristics
 Approaches for low power
In order to achieve the low power and low cost goals est
ablished by IEEE 802.15.4 the following approaches a
re taken
 Reduce the amount of data transmitted

 Reduce the transceiver duty cycle and frequency of da

ta transmissions
 Reduce the frame overhead

 Reduce complexity

 Reduce range

 Implement strict power management mechanisms (p

ower-down and sleep modes)
 IEEE 802.15.4 introduction
 IEEE 802.15.4 deals with only PHY layer and portion of
Data link layer.
 The higher-layer protocols are left to industry and the in
dividual applications.
 The Zigbee Alliance is an association of companies involv
ed with building higher-layer standards based on IEEE 8
02.15.4. This includes network, security, and application
protocols.
IEEE 802.15.4 in ISO-
ISO-OSI layered
network model
 Network layer
 The services which network layer provides are more challenging to
implement because of low power consumption requirement.
 Network layer over this standard are expected to be self configuring
and self maintaining to minimize total cost of user.
 IEEE 802.15.4 draft standard supports multiple network topologies
including star and peer to peer topology.
 topology selection is application dependent. PC peripherals may
require low latency connection of star topology while perimeter
security which needs large coverage area may require peer to peer
networking.
 Data link layer
 IEEE 802 splits DLL into MAC and LLC sublayers.
 LLC is standardized and is common in 802.3,802.11,8
02.15.1.
 features of the IEEE 802.15.4 MAC are association an
d disassociation, acknowledged frame delivery, chann
el access mechanism, frame validation, guaranteed ti
me slot management, and signal management.
 MAC
 MAC provides data and management services to uppe
r layers
 The MAC management service has 26 primitives whe
reas 802.15.1 has about 131 primitives and 32 events,
 802.15.4 MAC is of very low complexity, making it ver
y suitable for its intended low-end applications, even
though at the cost of a smaller feature set than 802.15
.1 (e.g., 802.15.4 does not support synchronous voice
links).
MAC frame format
 MAC frame
 Frame control field indicates the type of MAC frame bein
g transmitted, specifies the format of the address field, a
nd controls the acknowledgment.
 Multiple address types : 64 bit physical address and shor
t 16 bit network assigned address are provided.
 Address field size may vary from 0 to 20 bytes.
 Payload field is variable with condition size of mac frame
<= 127 bytes.
 FCS is used for integrity check using 16 bit CRC.
 Superframe
 Certain applications require dedicated bandwidth to achi
eve low latency for this it can operate in optional superfr
ame mode
 PAN coordinator, transmits superframe beacons in prede
termined intervals which is divided into 16 time slots
 The channel access in the time slots is contention-based
but PAN coordinator may assign time slots to a single de
vice requiring dedicated bandwidth or low-latency trans
missions. These assigned time slots are called guaranteed
time slots (GTS) and together form a contention-free peri
od.
Superframe structure
 Other MAC features
 In a beacon-enabled network with superframes, a slotted carrier sen
se multiple access with collision avoidance (CSMA-CA) mechanism i
s used.
 In others standard CSMA-CA is used I.e it first checks if another dev
ice is transmitting in the same channel if so backs off for certain tim
e.
 MAC confirms successful reception of data with an acknowledgemen
t.
 The IEEE 802.15.4 draft standard provides for three levels of securit
y: no security of any type ,access control lists (non cryptographic sec
urity) and symmetric key security, employing AES-128.
 PHY layer
 This standard provides 2 PHY options with frequency ba
nd as fundamental difference.
 2.4 GHz band has worldwide availability and provides a
transmission rate of 250 kb/s.
 The 868/915 MHz PHY specifies operation in the 868 M
Hz band in Europe and 915 MHz ISM band in the United
States and offer data rates 20 kb/s and 40 kb/s respectiv
ely.
 Different transmission rates can be exploited to achieve a
variety of different goals.
PHY layer packet structure