UNIT IV

IOT ARCHITECTURE AND PROTOCOLS

Internet – of – Things – Physical Design, Logical Design – IoT Enabling Technologies – Domain Specific IoTs
– IoT and M2M – IoT System Management with NETCONF – YANG – IoT Platform Design – Methodology
– IoT Reference Model – Domain Model – Communication Model – IoT Reference Architecture – IoT Protocols
- MQTT, XMPP, Modbus, CANBUS and BACNet.

PART – A (TWO MARKS)

1. Define IoT.

A dynamic global network infrastructure with self – configuring based on standard and interoperable
communication protocols where physical and virtual “things” have identified, physical attributes, and virtual
personalities and use intelligent interfaces, often communicate data associated with users and their environment

2. Write the characteristics of IOT.

(i) Dynamic and self-Adapting:

IoT devices and systems may have the capability to dynamically adapt with the changing contexts and take
actions based on their operating condition.
Ex: Surveillance cameras can adapt their modes based on whether it is day or night.
(ii) Self – Configuring:
IoT devices may have self-Configuring capability allowing a large number of devices to work together to
provide certain functionality.
(iii)Interoperable communication protocols:
IoT Devices may support a number of interoperable communication protocols and can communicate with other
devices and also with the infrastructure.
(iv)Unique Identity:
Each IoT devices has a unique identity and a unique identifier. IP address, URI). IoT systems may have
intelligent interfaces which adapt based on the context, allow communication with users and the environment
contexts.
(v)Integrated into information network:
IoT devices are usually integrated into the information network that allows them to communicate and exchange
data with other devices and systems.

3. Write the difference between REST and web socket protocol.

1
4. What are the four layers of IOT protocol?
Four Layer of IoT Protocol
1. Link Layer
2. Network Layer
3. Transport Layer
4. Application Layer

5. Compare TCP and UDP.

TCP:
 Transmission control protocol is the most widely used by the web browsers along with HTTP, HTTPS
application layer protocols email program (SMTP application layer protocol) and file transfer protocol. TCP
is a connection Oriented protocol while IP protocol deals with sending packets,
 TCP ensures reliable transmissions of packets in order.
 TCP also provide error deduction capability so that duplicate packets can be discarded and low packets are
retransmitted.
 The flow control capability.
UDP:
 UDP is a connection less protocol.
 UDP is useful for time sensitive application they have very small data units to exchange and do not want the
overhead of connection setup.
 UDP is a transactions oriented and stateless protocol.
 UDP does not provide guaranteed delivery, ordering of messages and duplicate eliminations.
6. Define Iaas, Paas and Saas.
 Iaas (Infrastructure as a service): Rent Infrastructure.
 Platform as a service (PaaS): Supply an on-demand environment for developing, testing, delivering and
managing software applications.
 Software as a service (SaaS): Method for delivering software applications over the Internet, on demand and
typically on a subscription basis.

7. Draw the block diagram of an IOT device.

8. What are the types of link layer protocol?

 802.3 Ethernet
 802.1- Wi-Fi
 802.16 WiMAX
 802.15.4 LR-WPAN
 2G / 3G / 4G mobile communications

9. What is MQTT?
Message Queue Telemetry Transport is a lightweight message protocol based on public-subscribe model
MQTT uses a client server Architecture by the clients such as an IoT device connect to the server also called

2
the MQTT broker and publishers message to topic on the server. The broker forward the message to the clients
subscribed to topic MQTT is well suited for constrained and environments.

10. What is AMQP?

Advanced Message Queuing protocols is an open application layer protocol for business messaging. AMQP
support point to point and publish- subscribe model routing and queuing. AMQP broker receive message from
publishers.

11. Define big data.

Big data is defined as collection of data whose volume, velocity or variety is too large and difficult to store,
manage, process and analyze the data using traditional databases. It involves data cleansing, processing and
visualization.

12. What are the applications of Domain Specific IoTs?

 Home Automation
 Cities
 Environment
 Retail
 Logistics
 Agriculture
 Industry
 Health and Life Style

13. Write the Difference between IoT and M2M.

a) Communication Protocols:
 Commonly uses M2M protocols include ZigBee, Bluetooth, Mod Bus, M-Bus, Wireless M-Bus etc.,
 In IoT uses HTTP, CoAP, Web Socket.
b) Machines in M2M Vs Things in IoT:
 Machines in M2M will be homogenous whereas Things in IoT will be heterogeneous.
c) Hardware Vs Software Emphasis:
 The emphasis of M2M is more on hardware with embedded modules, the emphasis of IoT is more on
software.
d) Data Collection &Analysis:
 M2M data is collected in point solutions and often in on-premises storage infrastructure.
 The data in IoT is collected in the cloud (can be public, private or hybrid cloud).
e) Applications:
 M2M data is collected in point solutions and can be accessed by on-premises applications such as diagnosis
applications, service management applications, and on- premises enterprise applications.
 IoT data is collected in the cloud and can be accessed by cloud applications such as analytics applications,
enterprise applications, remote diagnosis and management applications, etc.

14. What is the need for IoT Systems Management?

Managing multiple devices within a single system requires advanced management capabilities.
 Automating Configuration
 Monitoring Operational & Statistical Data
 Improved Reliability
 System Wide Configurations
3
 Multiple System Configurations
 Retrieving & Reusing Configurations

15. What is NETCONF?

Network Configuration Protocol (NETCONF) is a session-based network management protocol. NETCONF
allows retrieving state or configuration data and manipulating configuration data on network devices.

16. What is YANG?

YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF
protocol. YANG modules contain the definitions of the configuration data, state data, RPC calls that can be
issued and the format of the notifications. YANG modules defines the data exchanged between the NETCONF
client and server.

17. What are the Characteristics of MQTT?

Some of the features of an MQTT are given below:
 It is a machine to machine protocol, i.e., it provides communication between the devices.
 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.

18. What are the advantages of CAN bus?

 Simple and low cost
 Easy access
 Extremely robust
 Efficient
19. What are the advantages of the Bacnet Protocol?
 BACnet protocol is particularly designed for building automation as well as control networks.
 It doesn’t depend on present LAN or WAN technologies.
 It is an American National Standard & a European pre-standard.
 It is scalable completely from small single building applications to universal networks of devices.
 The implementers of BACnet can securely include non-standard extensions as well as enhancements
without influencing existing interoperability.
 It is adopted by the most famous fire protection companies in both the USA & Europe.
 It is supported by different chiller manufacturers like Dunham-Bush, Carrier, McQuay, York & Trane.
 In real building control applications, this protocol has a proven track record.

20. Write the difference between BACnet and MODbus Protocol.

BACnet Protocol Modbus
It was developed by ASHRAE. It was developed by Modicon Inc.
Bacnet is used for communication across
devices. Modbus is used for communication between devices.
Its transmission modes are; IP, Ethernet,
Zigbee & MS/TP. Its transmission modes are; ASCII, RTU, and TCP/IP.
Its standards are; ANSI/ASHRAE Standard
185; ISO-16484-5; ISO-16484-6. Its standards are; IEC 61158.

4
It is used in different markets like Industrial,
Energy Management, Transportation, Building It is used in different markets like Lighting, Life Safety,
Automation, Regulatory, health & security. Access Controls, HVAC, transportation & maintenance.

5
 PART – B

1. Explain in detail about physical design of Internet of things.

Things of IOT
 Refers to IoT devices which have unique identities that can perform sensing, actuating and monitoring
capabilities.
 IoT devices can exchange data with other connected devices or collect data from other devices and process
the data either locally or send the data to centralized servers or cloud – based application back-ends for
processing the data.
Generic Block Diagram of an IoT Device:
An IoT device may consist of several interfaces for connections to other devices, both wired and wireless. The
below Fig 4.1 shows the block diagram of an IoT Device.
i) IoT interfaces for sensors
ii) Interfaces for internet connectivity
iii) Memory and storage interfaces
iv) Audio video interfaces.

Fig 4.1- Block Diagram of an IoT Device

IoT Protocols
The IoT devices are typically connected to the Internet via an IP (Internet Protocol) network. However, devices
such as Bluetooth and RFID allow IoT devices to connect locally. In these cases, there’s a difference in power,
range, and memory used. Connection through IP networks are comparatively complex, requires increased
memory and power from the IoT devices while the range is not a problem. On the other hand, non-IP networks
demand comparatively less power and memory but have a range limitation.
Fig 4.2 shows Four Layer of IoT Protocol
1. Link Layer
2. Network Layer
3. Transport Layer
4. Application Layer

Fig 4.2- Four Layer IoT Protocol

6
1. Link Layer: Link Layer protocols determine how the data is physically sent over the networks physical layer
or medium. Table 4.1 shows different methods of link layer with standards.
802.3 Ethernet:
802.3 is a collections of wired Ethernet standards for the link layer. For example, 802.3 10BASE5 Ethernet that
uses coaxial cable as a shared medium, 802.3.i is standard for 10 BASET Ethernet over copper twisted pair
connection, Standards provide data rates from 10 Mb/s to 40 gigabits per second and the higher.
802.1- Wi-Fi:
IEEE 802.3 is a collections of wireless Local area network. (WLAN) communication standards, including
extensive descriptions of the link layer. For example, 802.11a operate in the 5 GHz band, 802.11b and 802.11g
operate in the 2.4 GHz band. 802.11ac operates in the 5G hertz band.
802.16 WiMAX:
IEEE 802.16 is a collection of wireless broadband and Standards, including extensive descriptions for the link
layer also called WiMAX wimax standard provides a data rates from1.5 Mb/s to 1Gb/s the recent update
provides data rates of hundred megabits per second for mobile station.

Table 4.1: different methods of link layer with standards.

802.15.4 LR-WPAN:
IEEE 802.1 5.4 is a collections of standard for low rate wireless personal area network(LR-WPAN).These
standard form the basis of specifications for high level communication Zigbee. LR-WPAN standards provide
data rates from 40 kb/s. These standards provide low cost and low speed Communications for power constrained
devices.
2G / 3G / 4G mobile communications:
These are the different generations of mobile communication standards including second generation (2G
including GSM and CDMA). 3rd Generation (3G including UMTS and CDMA2000) and 4th generation 4G
including LTE.
2. Network / Internet layer:
The network layer is responsible for sending of IP datagrams from the source network to the destination
network. This layer Performs the host addressing and packet routing. The datagrams contain a source and
destination address which are used to route them from the source to the destination across multiple networks.
Host Identification is done using the hierarchy IP addressing schemes such as ipv4 or IPv6.

7
IPV4:
Used to identify the devices on a network using hierarchical addressing scheme
Uses 32-bit address scheme that allows total of 232 addresses.
As more and more devices got connected to the internet. The Ipv4 has succeeded by IPv6.
IPv6:
It is the newest versions of internet protocol and successor to IPv4. IPv6 uses 128-bit address schemes that are
lost total of 2 128 are 3.4* 10 38 address.
6LoWPAN:
IPv6 over low power wireless personal area networks brings IP protocol to the low power device which have
limited processing capability it operates in the 2.4 GHz frequency range and provide the data transfer rate off
to 50 kb/s.
Transport layer:
The Transport layer protocols provide end-to-end message transfer capability independent of the underlying
network. The message transfer capability can be set up on connections, either using handshake or without
handshake acknowledgements. Provides functions such as error control, segmentation, flow control and
congestion control.
TCP:
 Transmission control protocol is the most widely used by the web browsers along with HTTP, HTTPS
application layer protocols email program (SMTP application layer protocol) and file transfer protocol. TCP
is a connection Oriented protocol while IP protocol deals with sending packets,
 TCP ensures reliable transmissions of packets in order.
 TCP also provide error deduction capability so that duplicate packets can be discarded and low packets are
retransmitted.
 The flow control capability.
UDP:
 UDP is a connection less protocol.
 UDP is useful for time sensitive application they have very small data units to exchange and do not want the
overhead of connection setup.
 UDP is a transactions oriented and stateless protocol.
 UDP does not provide guaranteed delivery, ordering of messages and duplicate eliminations.
Application layer:
 Application layer protocol define how the application interfaces with the lower layer protocols to send the
data over the network.
 Data are in files, is encoded by the application layer protocol and encapsulated in the transport layer
protocol.
 Application layer protocol enable process-to-process connection using ports.
Http:
Hypertext transfer protocol is the application layer protocol that forms the foundations of world wide web http
includes, commands such as GET, PUT, POST, DELETE, HEAD, TRACE, OPTIONS etc.
CoAP:
Constrained application protocol is an application layer protocol for machine to machine application M2M
meant for constrained environment with constrained devices and constrained networks.
It is designed to easily interface with http like http, CoAP supports method such as GET, PUT, DELETE.
Websocket:
Web socket protocol allows full duplex communication over a single socket connection for sending message
between client and server. Web socket is based on TCP and Allows streams of messages to be sent back and
forth betweenthe client and server while keeping the TCP connection open. The client can be a browser, a
mobile application and IoT device
MQTT: (Message Queue Telemetry Transport)
It is a lightweight message protocol based on public-subscribe model MQTT uses a client server Architecture
by the clients such as an IoT device connect to the server also called the MQTT broker and publishers message
to topic on the server. The broker forward the message to the clients subscribed to topic MQTT is well suited
for constrained and environments.
8
XMPP: (Extensible Messaging and Presence Protocol)
It is a protocol for real-time communication and streaming XML data between network entities XMPP powers
wide range of applications including messaging, presence, data syndication, gaming multiparty chat and voice
/ voice calls. XMPP Allows sending small chunks of XML data from one network entity to another in real
time. XMPP supports both client to server and server –client communication path.
AMQP:(Advanced Message Queuing protocols)
It is an open application layer protocol for business messaging. AMQP support point to point and publish-
subscribe model routing and queuing. AMQP broker receive message from publishers.

2. Explain in detail about Logical design of Internet of things.

Logical design of an IoT system refers to an abstract representation of the entities andprocess without going
into low level specification of the implementations.

IoT functional block

An IoT system comprises of a number of functional blocks that provide the system the capabilities for
identification, sensing, actuation, communication and Management. The function blocks are shown in fig.4.3

Fig 4.3- Functional block of IoT

Devices: An IoT system comprises of the devices that provide sensing, actuation, monitoring and control
function
Communication: communication block handles the communication systems.
Services: An IoT system uses various types of IoT services such as services for device monitoring, device
control services, data publishing services and services for device Discovery.
Management: Functional blocks provide various functions to govern the IoT system.
Security: Security functional block security IoT system and by providing functions such as application
authorization message and content integrity and data security.
Application:
IoT application provides and interface that the user can used to control and monitor various aspects of the IoT
system. Application also allow users to view the systemstatus and view or analyze the processed to data.
IoT communication model

1) Request response communication model:

 Request–Response is a communication model in which the client sends requests to the server and the server
responds to the requests.
 When the server receives a request, it decides how to respond, fetches the data, retrieves resource
representations, prepares the response and then sends the response to the client.
 Stateless communication model, Fig 4.4 shows the block diagram of Request-Response Communication
Model.

9
 Fig 4.4- Request Response Communication model

2) 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.
Fig.4.5 shows the block diagram of Publish-Subscribe Communication Model.

Fig 4.5- Publish subscribe communication model

3) Push pull communication model:
 Exclusive Pair is a bidirectional, fully duplex communication model that uses a persistent connection
between the client and the server.
 Once the connection is set up it, remains open until the client sends a request to close the connection.
 Client and server can send messages to each other after connection setup. Fig 4.6 shows the block diagram
of push pull Communication Model.

10
 Fig 4.6- Push pull communication model

4) Exclusive pair communication model:

 Exclusive Pair is a bidirectional, fully duplex communication model that uses a persistent connection
between the client and the server.
 Once the connection is set up it, remains open until the client sends a request to close the connection.
 Client and server can send messages to each other after connection setup. Fig 4.7 shows the block diagram
of Exclusive Pair Communication Model.

Fig 4.7- Exclusive pair communication model

IoT communication APIs
1) REST- based communication API:
 Representational State Transfer (REST) is a set of architectural principles by which you can design web
services and web APIs that focus on a system’s resources and how resource states are addressed and
transferred.
 REST APIs follow the request–response communication model. Fig 4.8 shows the RESET API Architecture
diagram.
 REST architectural constraints apply to the components, connectors and data elements within a distributed
Hypermedia system.
Stateless: Each request from client to server must contain all the information necessary tounderstand the request,
and cannot take advantage of any stored context on the server.
Catchable: Catch constrain requires that the data within the response to a request be implicitly or explicitly
labelled as catchable or non-catchable. Then a client cache is giventhe right to reuse that response data for later,
equivalent requests. Completely eliminate some attractions and improve efficiency and scalability.
Layered system:
System constraint come off constraints, constrains the behaviour of components such that each component
cannot see beyond the immediate layer with which they are interacting. Example client cannot tell whether it is
connected directly to the end server or to an intermediary along the way system scalability can be improved
allowing intermediaries torespond to request instead of tender server.

11
 Fig 4.8- Communication with Rest APIs

Uniform interface:
Uniform interface constraints requires that the method of communication between client and server must be
uniform. Resources are identified in the request and separate from the representation of the resource that are
returned to the client. When climbing holds a representation of your resource it has all the information required
to update or delete the resource.
Code on demand:
Service can provide executable code script for clients to execute in theircontext.

Web Socket-based Communication APIs:

 Web Socket APIs allow bi-directional, full duplex communication between clients and servers as shown in
fig.4.9.
 Web Socket APIs follow the exclusive pair communication model.

Fig 4.9- Web socket Protocol

12
Difference between REST and WebSocket-based Communication APIs:

3. Explain in detail about IoT enabling Technologies.

1) Wireless Sensor Network (WSN):
 Distributed Devices with sensors used to monitor the environmental and physical conditions as shown in
fig.4.10.
 Consists of several end-nodes acting as routers or coordinators too.
 Coordinators collect data from all nodes / acts as gateway that connects WSN to internet.
 Routers route the data packets from end nodes to coordinators.
Example:
 Weather monitoring system
 Indoor Air quality monitoring system
 Soil moisture monitoring system
 Surveillance systems
 Health monitoring systems
Protocols:
Zigbee

Fig 4.10- wireless Sensors.

2) Cloud computing:
 Cloud computing deliver applications and services over internet as shown in fig.4.11.
 Provides computing, networking and storage resources on demand.
 Cloud computing performs services such as Iaas, Paas and Saas.
 Iaas (Infrastructure as a service): Rent Infrastructure.
 Platform as a service (PaaS): Supply an on-demand environment for developing, testing, delivering and
managing software applications.
13
 Software as a service (SaaS): Method for delivering software applications over the Internet, on demand and
typically on a subscription basis.

Fig 4.11- Cloud Computing Physical Diagram

3) Big Data Analytics:
 Big data is defined as collection of data whose volume, velocity or variety is too large and difficult to store,
manage, process and analyze the data using traditional databases as shown in fig.4.12.
 It involves data cleansing, processing and visualization.
 Lots of data is being collected and warehoused.
 Web data, e-commerce
 Purchases at department/ grocery stores
 Bank/Credit Card transactions
 Social Network

Fig 4.12- Big Data Analytics Physical Diagram.

 Sensor data generated by IoT system such as weather monitoring stations
 Machine sensor data collected from sensor embedded in Industrial and energy systemfor monitoring
their files and protecting failure
 Health and fitness data generated by IoT devices such as wearable fitness band.
 Data generated by IoT system for Location tracking of vehicle.
 Data generated by retail inventory monitoring system.

Characteristics of data include:

Volume: Through there is no fixed threshold for volume of data to be considered as big data, however the term
big data is used for massive scale data that is difficult to store, manage and process using traditional data bases
and data processing architecture. The volume of data generated by modern IT, industrial and Healthcare systems
for example isa growing exponentially driven by the lowering cost of data storage and processing architectures
and the need to extract valuable insights from the data to improve business processes, efficiency and services to
consumer.
Velocity: Velocity is another important characteristics of big data and the primary reasons for exponential
growth of data velocity of the data of a store how fast the data is generatedand how frequently it varies. Modern
IT Industrial and other systems are generating data at increasing the highest speeds.
Variety: Variety refers to the forms of the data. Big data comes in for different forms suchas structured or
unstructured data including text data, audio, video and sensor data.

14
4) Communications protocol:
Communications protocols form the backbone of IoT system and enable network connectivity and coupling to
applications. Communications protocols allow device to exchange data over the network. These protocols
define the data exchange formats and data encoding schemes for devices and routing of packets from source to
destination. Otherfunction of the protocol includes sequence control flow control and transmissions of Lost
packet.

5) Embedded systems:
An Embedded system is computer system that has computer hardware and software embedded perform specific
task. In contrast to general purpose computers or personal computers which can perform various types of tasks,
embedded systems are designed to perform a specific set of tasks. Embedded system include Microprocessor
and Microcontroller memory Ram ROM cache networking units (Ethernet WI-FI adaptor) input/output unit
display keyboard, display and storage such as Flash Memory some embedded system have specialist processes
such as digital signal processor DSP graphic processor and application.

4. Explain in detail about Domain Specific IoTs.

(1) Home Automation:
(a) Smart Lighting: helps in saving energy by adapting the lighting to the ambient conditions and switching
On/off or diming the light when needed.
(b) Smart Appliances: make the management easier and also provide status information to the users
Remotely.
(c) Intrusion Detection: use security cameras and sensors (PIR sensors and door sensors) to detect intrusion
and raise alerts. Alerts can be in the form of SMS or email sent to the user.
(d) Smoke/Gas Detectors: Smoke detectors are installed in homes and buildings to detect smoke that is
typically an early sign of fire. Alerts raised by smoke detectors can be in the form of signals to a fire alarm
system. Gas detectors can detect the presence of harmful gases such as CO, LPG etc.,
(2) Cities:
(a) Smart Parking: Make the search for parking space easier and convenient for drivers. Smart parking is
powered by IoT systems that detect the no. of empty parking slots and send information over internet to
smart application back ends.
(b) Smart Lighting: For roads, parks and buildings can help in saving energy.
(c)Smart Roads: Equipped with sensors can provide information on driving condition, travel time
estimating and alert in case of poor driving conditions, traffic condition and accidents.
(d) Structural Health Monitoring: uses a network of sensors to monitor the vibration levels in the structures
such as bridges and buildings.
(e) Surveillance: The video feeds from surveillance cameras can be aggregated in cloud based scalable
storage solution.
(f) Emergency Response: IoT systems for fire detection, gas and water leakage detection can help in generating
alerts and minimizing their effects on the critical infrastructures.

(3) Environment:
(a) Weather Monitoring: Systems collect data from a no. of sensors attached and send the data to cloud based
applications and storage back ends. The data collected in cloud can then be analyzed and visualized by cloud
based applications.
(b) Air Pollution Monitoring: System can monitor emission of harmful gases (CO2, CO, NO, NO2 etc.,) by
factories and automobiles using gaseous and meteorological sensors. The collected data can be analyzed to
make informed decisions on pollutions control approaches.
(c) Noise Pollution Monitoring: Due to growing urban development, noise levels in cities have increased and
even become alarmingly high in some cities. IoT based noise pollution monitoring systems use a no. of noise
monitoring systems that are deployed at different places in a city. The data on noise levels from the station is
collected on servers or in the cloud. The collected data is then aggregated to generate noise maps.
15
(d) Forest Fire Detection: Forest fire can cause damage to natural resources, property and human life. Early
detection of forest fire can help in minimizing damage.
(e) River Flood Detection: River floods can cause damage to natural and human resources and human life. Early
warnings of floods can be given by monitoring the water level and flow rate. IoT based river flood monitoring
system uses a no. of sensor nodes that monitor the water level and flow rate sensors.
(4) Energy:
(a) Smart Grids: is a data communication network integrated with the electrical grids that collects and analyze
data captured in near-real-time about power transmission, distribution and consumption. Smart grid technology
provides predictive information and recommendations to utilities, their suppliers, and their customers on how
best to manage power. By using IoT based sensing and measurement technologies, the health of equipment
and integrity of the grid can be evaluated.
(b) Renewable Energy Systems: IoT based systems integrated with the transformers at the point of
interconnection measure the electrical variables and how much power is fed into the grid. For wind energy
systems, closed-loop controls can be used to regulate the voltage at point of interconnection which coordinate
wind turbine outputs and provides power support.
(c) Prognostics: In systems such as power grids, real-time information is collected using specialized electrical
sensors called Phasor Measurement Units (PMUs) at the substations. The information received from PMUs
must be monitored in real-time for estimating the state of the system and for predicting failures.
(5) Retail:
(a) Inventory Management: IoT systems enable remote monitoring of inventory using data collected by RFID
readers.
(b) Smart Payments: Solutions such as contact-less payments powered by technologies such as Near Field
Communication (NFC) and Bluetooth.
(c) Smart Vending Machines: Sensors in smart vending machines monitors its operations and send the data to
cloud which can be used for predictive maintenance.
(6) Logistics:
(a) Route generation & scheduling: IoT based system backed by cloud can provide first response to the route
generation queries and can be scaled up to serve a large transportation network.
(b) Fleet Tracking: Use GPS to track locations of vehicles in real-time.
(c) Shipment Monitoring: IoT based shipment monitoring systems use sensors such as temp, humidity, to
monitor the conditions and send data to cloud, where it can be analyzed to detect food spoilage.
(d) Remote Vehicle Diagnostics: Systems use on-board IoT devices for collecting data on Vehicle operations
(speed, RPM etc.,) and status of various vehicle subsystems.
(7) Agriculture:
(a) Smart Irrigation: to determine moisture amount in soil.
(b) Green House Control: to improve productivity.
(8) Industry:
(a)Machine diagnosis and prognosis.
(b) Indoor Air Quality Monitoring.
(9) Health and Life Style:
(a) Health & Fitness Monitoring.
(b) Wearable Electro.

4. Explain in detail about IoT and M2M and give the difference between Iota and M2M.
Machine-to-Machine (M2M) refers to networking of machines (or devices) for the purpose of remote
monitoring and control and data exchange.
 Term which is often synonymous with IoT is Machine-to-Machine (M2M).
 IoT and M2M are often used interchangeably.
 An M2M area network comprises of machines which have embedded network modules for sensing, actuation
and communicating various communication protocols can be used for M2M LAN such as ZigBee, Bluetooth,

16
 M-bus, Wireless M-Bus etc., These protocols provide connectivity between M2M nodes within an M2M area
network.
 Fig.4.13 shows the end-to-end architecture of M2M systems comprises of M2M area networks,
communication networks and application domain.

Fig 4.13-M2M System Architecture

 The communication network provides connectivity to remote M2M area networks. The communication
network provides connectivity to remote M2M area network. The communication network can use either
wired or wireless network (IP based). While the M2M are networks use either properitorary or non-IP based
communication protocols, the communication network uses IP-based network. Since non-IP based protocols
are used within M2M area network, the M2M nodes within one network cannot communicate with nodes in
an external network.
 To enable the communication between remote M2M are network, M2M gateways are used as shown in
fig.4.14.

Fig.4.14 - Block diagram of an M2M gateway.

 The communication between M2M nodes and the M2M gateway is based on the communication protocols
which are naive to the M2M are network. M2M gateway performs protocol translations to enable Ip-
connectivity for M2M are networks. M2M gateway acts as a proxy performing translations from/to native
protocols to/from Internet Protocol (IP). With an M2M gateway, each mode in an M2M area network appears
as a virtualized node for external M2M area networks.
17
Differences between IoT and M2M:
1) Communication Protocols:
 Commonly uses M2M protocols include ZigBee, Bluetooth, Mod Bus, M-Bus, Wireless M-Bus etc.,
 In IoT uses HTTP, CoAP, Web Socket

2) Machines in M2M Vs Things in IoT:

 Machines in M2M will be homogenous whereas Things in IoT will be heterogeneous.
3) Hardware Vs Software Emphasis:
 The emphasis of M2M is more on hardware with embedded modules, the emphasis of IoT is more on
software.
4) Data Collection &Analysis:
 M2M data is collected in point solutions and often in on-premises storage infrastructure.
 The data in IoT is collected in the cloud (can be public, private or hybrid cloud).
5) Applications:
 M2M data is collected in point solutions and can be accessed by on-premises applications such as diagnosis
applications, service management applications, and on- premisis enterprise applications.
 IoT data is collected in the cloud and can be accessed by cloud applications such as analytics applications,
enterprise applications, remote diagnosis and management applications, etc.

5. Explain in detail about IoT System Management with NETCONF - YANG.

Need for IoT Systems Management:
Managing multiple devices within a single system requires advanced management capabilities.
1) Automating Configuration: IoT system management capabilities can help in automating the system
configuration.
2) Monitoring Operational & Statistical Data: Management systems can help in monitoring opeartional and
statistical data of a system. This data can be used for fault diagnosis or prognosis.
3) Improved Reliability: A management system that allows validating the system configurations before they
are put into effect can help in improving the system reliability.
4) System Wide Configurations: For IoT systems that consist of multiple devices or nodes, ensuring system
wide configuration can be critical for the correct functioning of the system.
5) Multiple System Configurations: For some systems it may be desirable to have multiple valid
configurations which are applied at different times or in certain conditions.
6) Retrieving & Reusing Configurations: Management systems which have the capability of retrieving
configurations from devices can help in reusing the configurations for other devices of the same type.

NETCONF:
Network Configuration Protocol (NETCONF) is a session-based network management protocol. NETCONF
allows retrieving state or configuration data and manipulating configuration data on network devices as shown
in fig.4.15.
 NETCONF works on SSH transport protocol.
 Transport layer provides end-to-end connectivity and ensure reliable delivery of messages.
 NETCONF uses XML-encoded Remote Procedure Calls (RPCs) for framing request and response messages.
 The RPC layer provides mechanism for encoding of RPC calls and notifications.
 NETCONF provides various operations to retrieve and edit configuration data from network devices.
 The Content Layer consists of configuration and state data which is XML-encoded.
 The schema of the configuration and state data is defined in a data modeling language called YANG.
 ETCONF provides a clear separation of the configuration and state data.
18
 The configuration data resides within a NETCONF configuration data store on the server.

Fig.4.15 - NETCONF protocol layer

YANG:
 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF
protocol
 YANG modules contain the definitions of the configuration data, state data, RPC calls that can be issued and
the format of the notifications.
 YANG modules defines the data exchanged between the NETCONF client and server.
 A module comprises of a number of 'leaf' nodes which are organized into a hierarchical tree structure.
 The 'leaf' nodes are specified using the 'leaf' or 'leaf-list' constructs.
 Leaf nodes are organized using 'container' or 'list' constructs.
 A YANG module can import definitions from other modules.
 Constraints can be defined on the data nodes, e.g. allowed values.
 YANG can model both configuration data and state data using the 'config' statement.
IoT Systems Management with NETCONF-YANG:
The generic approach of IoT device management with NETCONF-YANG as shown in fig.4.16.
Roles of various components are:
1) Management System
(2) Management API
(3) Transaction Manager
(4) Rollback Manager
(5) Data Model Manager
(6) Configuration Validator
(7) Configuration Database
(8) Configuration API
(9) Data Provider API

19
 Fig.4.16- IoT device Management with NETCONF-YANG a generic approach

(1)Management System: The operator uses a management system to send NETCONF messages to configure
the IoT device and receives state information and notifications from the device as NETCONF messages.
2) Management API: allows management application to start NETCONF sessions.
3) Transaction Manager: executes all the NETCONF transactions and ensures that ACID properties hold
true for the transactions.
4) Rollback Manager: is responsible for generating all the transactions necessary to rollback a current
configuration to its original state.
5) Data Model Manager: Keeps track of all the YANG data models and the corresponding managed objects.
Also keeps track of the applications which provide data for each part of a data model.
6) Configuration Validator: checks if the resulting configuration after applying a transaction would be a valid
configuration.
7) Configuration Database: contains both configuration and operational data.
8) Configuration API: Using the configuration API the application on the IoT device can be read configuration
data from the configuration data store and write operational data to the operational data store.
9) Data Provider API: Applications on the IoT device can register for callbacks for various events using the
Data Provider API. Through the Data Provider API, the applications can report statistics and operational data.

Steps for IoT device Management with NETCONF-YANG

1) Create a YANG model of the system that defines the configuration and state data of the system.
2) Complete the YANG model with the Inc tool which comes with Libnetconf.
3) Fill in the IoT device management code in the Trans API module.
4) Build the callbacks C file to generate the library file.
5) Load the YANG module and the Trans API module into the Netopeer server using Netopeer manager tool. 6)
The operator can now connect from the management system to the Netopeer server using the Netopeer CLI. 7)
Operator can issue NETCONF commands from the Netopeer CLI. Command can be issued to change the

20
configuration data, get operational data or execute an RPC on the IoT device.
6. Explain in detail about MQTT and XMPP Protocol.

MQTT
MQTT stands for Message Queuing Telemetry Transport. MQTT is a machine to machine internet of things
connectivity protocol. It is an extremely lightweight and publish-subscribe messaging transport protocol. This
protocol is useful for the connection with the remote location where the bandwidth is a premium.
Characteristics of MQTT
Some of the features of an MQTT are given below:
 It is a machine to machine protocol, i.e., it provides communication between the devices.
 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.

The selection of a client/server and publish/subscribe framework based on the TCP/IP architecture, as shown in
fig.4.17.

Fig. 4.17-MQTT Publish/Subscribe Framework

 An MQTT client can act as a publisher to send data to an MQTT server acting as an MQTT message broker.
 In the example illustrated in Figure 4.17, the MQTT client on the left side is a temperature (Temp) and
relative humidity (RH) sensor that publishes its Temp/RH data. The MQTT server (or message broker)
accepts the network connection along with application messages, such as Temp/RH data, from the
publishers.
 It also handles the subscription and unsubscription process and pushes the application data to MQTT clients
acting as subscribers. The application on the right side of Figure 2.22 is an MQTT client that is a subscriber
to the Temp/RH data being generated by the publisher or sensor on the left. This model, where subscribers
express a desire to receive information from publishers, is well known.
 In addition, the presence of a message broker in MQTT decouples the data transmission between clients
acting as publishers and subscribers. In fact, publishers and subscribers do not even know (or need to know)
about each other.
 A benefit of having this decoupling is that the MQTT message broker ensures that information can be
buffered and cached in case of network failures.
 MQTT is a lightweight protocol because each control packet consists of a 2-byte fixed header with optional
variable header fields and optional payload. A control packet can contain a payload up to 256 MB. Figure
21
 4.18 provides an overview of the MQTT message format.

Fig.4.18 - MQTT Message Format

 The first MQTT field in the header is Message Type, which identifies the kind of MQTT packet within a
message.
 The next field in the MQTT header is DUP (Duplication Flag). This flag, allows the client to notate that the
packet has been sent previously, but an acknowledgement was not received.
 The QoS header field allows for the selection of three different QoS levels.
 The next field is the Retain flag. Only found in a PUBLISH message, the Retain flag notifies the server to
hold onto the message data. This allows new subscribers to instantly receive the last known value without
having to wait for the next update from the publisher.
 The last mandatory field in the MQTT message header is Remaining Length. This field specifies the number
of bytes in the MQTT packet following this field.

XMPP
Extensible Messaging and Presence Protocol (XMPP) is a messaging protocol that was designed originally for
chatting and message exchange applications. It is well known and has proven to be highly efficient over the
internet. Recently, it has been reused for IoT applications as well as a protocol for SDN. This reusing of the
same standard is due to its use of XML which makes it easily extensible. XMPP supports both publish/ subscribe
and request/ response architecture and it is up to the application developer to choose which architecture to use.
It is designed for near real-time applications and, thus, efficiently supports low-latency small messages. It does
not provide any quality of service guarantees and, hence, is not practical for M2M communications. Moreover,
XML messages create additional overhead due to lots of headers and tag formats which increase the power
consumption that is critical for IoT application. Hence, XMPP is rarely used in IoT but has gained some interest
for enhancing its architecture in order to support IoT applications.

7. Explain in detail about Modbus Protocol.

Modbus protocol is mainly used to convey signals from industrial devices primarily involving instrumentation
control and data acquisition devices to a typical micro-controller unit (MCU) or to a data collection system.
Modbus protocol was published by Modicon in the year 1979. Modbus is a communication protocol extensively
used in industries and industrial devices specifically confining its implementation in programmable logic
controllers (PLC) for industrial automation applications.
Modbus devices communicate using a master-slave (client-server) technique in which only one device (the
master/client) can initiate transactions (called queries). The other devices (slaves/servers) respond by supplying
the requested data to the master, or by taking the action requested in the query. A slave is any peripheral device
(I/O transducer, valve, network drive, or other measuring device) which processes information and sends its
output to the master using Modbus. The I/O Modules form slave/server devices, while a typical master device
is a host computer running appropriate application software. Other devices may function as both clients
(masters) and servers (slaves).

22
Types of Modbus Communication Protocol
a) Modbus serial protocol: It is a master/slave protocol, e.g. one master that controls the Modbus data
transactions with multiple slaves that respond to the master’s requests to read from or write data to the slaves.
Network architectures are shown Fig.4.19.

Fig.4.19 - Modbus Serial Architecture

In a standard Modbus serial network, there is only one master and as many as 247 slaves, each with a unique
slave address. And there are two types of serial Modbus, Modbus RTU and ASCII.

The difference between Modbus RTU and Modbus ASCII

There are just two basic transmission ways found in RTU, ASCII and MODBUS connections. These
transmission modes determine the way in which the MODBUS messages are coded. In ASCII format, the
messages are readable, whereas in RTU the messages are in binary coding and cannot be read while monitoring.
The tradeoff is the RTU messages are smaller-size, which allows for more data exchange in an identical time
period. One must be aware that all nodes within one MODBUS network should be of exactly the same
transmission style, meaning MODBUS ASCII cannot communicate with MODBUS RTU and vice versa.

b) Modbus TCP:

 It is also known as Modbus TCP/IP, uses a client/server architecture.

 Modbus TCP is often referred to as Modbus over Ethernet. It is simply the Modbus RTU protocol with a
TCP interface that runs on Ethernet.
 The Modbus messaging structure is the application protocol that defines the rules for organizing and
interpreting the data independent of the data transmission medium.
 TCP/IP refers to the Transmission Control Protocol and Internet Protocol, which provides the transmission
medium for Modbus TCP/IP messaging.
 This enables Modbus / TCP devices to immediately and easily connect and communicate over existing
Ethernet and fibre networks.
 Modbus/TCP also allows many more addresses than RS485, the use of multiple Masters and speeds in the
gigabit range. Network architectures are shown in Fig.4.20.
 Unlike Modbus RTU and Modbus ASCII, Modbus/TCP will allow multiple Clients to poll the same Server
device simultaneously. This is permitted because over Ethernet via TCP/IP, multiple messages can be sent,
buffered and delivered without the requirement of token passing or total bus control, which is often the case
with many RS485 and RS422 protocols.

23
 Fig.4.20 - Modbus TCP Architecture
Addressing and messaging
Modbus memory addressing is generally organized around 16-bit registers that contain 16 coils or on/off (0/1)
states or integer values in 16-bit registers. While some devices will use their own Modbus addressing, typical
Modbus addressing can be seen in fig.4.21.

Fig.4.21 – Typical serial transaction

The Modbus TCP data transactions are essentially the same except the server address is an IP address, there is
some Ethernet overhead, and the error checksum is different. Modbus data can include starting data addresses,
24
data quantity or count, and actual data that is read or is to be written. If the Modbus slave/server has a problem
with the master/client request, the slave/server will issue an error response back to the master/client.
In the Modbus TCP/IP message format, the Modbus PDU is typically wrapped into the Ethernet package and
consists of the Modbus function code and the Modbus data request. The slave address and error code (CRC) are
typically not needed as the Modbus TCP/IP packet is routed by the network to the desired IP address (unless
there is to be a connection into a serial network), and the error check is done as part of the Ethernet packet.

8. Explain in detail about the IoT Design Methodology Steps with neat diagram.

Fig.4.22 shows the Steps involved in IOT system design Methodology

Fig.4.22 – Steps involved in IOT system design Methodology

Step 1: Purpose & Requirements Specification

The first step in IoT system design methodology is to define the purpose and requirements of the system. In this
step, the system purpose, behavior and requirements (such as data collection requirements, data analysis
requirements, system management requirements, data privacy and security requirements, user interface
requirements) are captured.

Step 2: Process Specification

The second step in the IoT design methodology is to define the process specification. In this step, the use cases
of the IoT system are formally described based on and derived from the purpose and requirement specifications.

Step 3: Domain Model Specification

The third step in the IoT design methodology is to define the Domain Model. The domain model describes the
25
main concepts, entities and objects in the domain of IoT system to be designed. Domain model defines the
attributes of the objects and relationships between objects. Domain model provides an abstract representation
of the concepts, objects and entities in the IoT domain, independent of any specific technology or platform.
With the domain model, the IoT system designers can get an understanding of the IoT domain for which the
system is to be designed.

Step 4: Information Model Specification

The fourth step in the IoT design methodology is to define the Information Model. Information Model defines
the structure of all the information in the IoT system, for example, attributes of Virtual Entities, relations, etc.
Information model does not describe the specifics of how the information is represented or stored. To define
the information model, we first list the Virtual Entities defined in the Domain Model. Information model adds
more details to the Virtual Entities by defining their attributes and relations.

Step 5: Service Specifications

The fifth step in the IoT design methodology is to define the service specifications. Service specifications define
the services in the IoT system, service types, service inputs/output, service endpoints, service schedules, service
preconditions and service effects.

Step 6: IoT Level Specification

The sixth step in the IoT design methodology is to define the IoT level for the system.

Step 7: Functional View Specification

The seventh step in the IoT design methodology is to define the Functional View. The Functional View (FV)
defines the functions of the IoT systems grouped into various Functional Groups (FGs). Each Functional Group
either provides functionalities for interacting with instances of concepts defined in the Domain Model or
provides information related to these concepts.

Step 8: Operational View Specification

The eighth step in the IoT design methodology is to define the Operational View Specifications. In this step,
various options pertaining to the IoT system deployment and operation are defined, such as, service hosting
options, storage options, device options, application hosting options, etc

Step 9: Device & Component Integration

The ninth step in the IoT design methodology is the integration of the devices and components.

Step 10: Application Development

The final step in the IoT design methodology is to develop the IoT application.

9. Explain in detail about the IoT Reference architecture with neat diagram.
The reference architecture shown in fig.4.23 consists of a set of components. Layers can be realized by means
of specific technologies, and we will discuss options for realizing each component. There are also some
crosscutting/vertical layers such as access/identity management.

Fig.4.23 - IoT Reference Architecture

26
The layers are
 Client/external communications - Web/Portal, Dashboard, APIs
 Event processing and analytics (including data storage)
 Aggregation/bus layer – ESB and message broker
 Relevant transports - MQTT/HTTP/XMPP/CoAP/AMQP, etc.
 Devices
The cross-cutting layers are
 Device manager
 Identity and access managements

THE DEVICE LAYER :

The bottom layer of the architecture is the device layer. Devices can be of various types, but in order to be
considered as IoT devices, they must have some communications that either indirectly or directly attaches to
the Internet.
Examples of direct connections are
• Arduino with Arduino Ethernet connection
• Arduino Yun with a Wi-Fi connection
• Raspberry Pi connected via Ethernet or Wi-Fi
• Intel Galileo connected via Ethernet or Wi-Fi Examples of indirectly connected devices include
• ZigBee devices connected via a ZigBee gateway
• Bluetooth or Bluetooth Low Energy devices connecting via a mobile phone
• Devices communicating via low power radios to a Raspberry Pi.

COMMUNICATIONS LAYER
The communication layer supports the connectivity of the devices. There are multiple potential protocols for
communication between the devices and the cloud. The most well-known three potential protocols are
• HTTP/HTTPS
• MQTT 3.1/3.1.1
• Constrained application protocol (CoAP)
Http:
Hypertext transfer protocol is the application layer protocol that forms the foundations of world wide web http
includes, commands such as GET, PUT, POST, DELETE, HEAD, TRACE, OPTIONS etc.
CoAP:
Constrained application protocol is an application layer protocol for machine to machine application M2M
meant for constrained environment with constrained devices and constrained networks.
It is designed to easily interface with http like http, CoAP supports method such as GET, PUT, DELETE.
MQTT: (Message Queue Telemetry Transport)
It is a lightweight message protocol based on public-subscribe model MQTT uses a client server Architecture
by the clients such as an IoT device connect to the server also called the MQTT broker and publishers message
to topic on the server. The broker forward the message to the clients subscribed to topic MQTT is well suited
for constrained and environments.
The reasons to select MQTT and not CoAP are
• Better adoption and wider library support for MQTT
• Simplified bridging into existing event collection and event processing systems and
• Simpler connectivity over firewalls and NAT networks

AGGREGATION/BUS LAYER
An important layer of the architecture is the layer that aggregates and brokers communications. This is an
important layer for three reasons:
1. The ability to support an HTTP server and/or an MQTT broker to talk to the devices
2. The ability to aggregate and combine communications from different devices and to route communications
to a specific device (possibly via a gateway)
3. The ability to bridge and transform between different protocols, e.g. to offer HTTP based APIs that are
27
mediated into an MQTT message going to the device. The aggregation/bus layer provides these capabilities as
well as adapting into legacy protocols. The bus layer may also provide some simple correlation and mapping
from different correlation models (e.g. mapping a device ID into an owner‘s ID or vice-versa). Finally, the
aggregation/bus layer needs to perform two key security roles.

EVENT PROCESSING AND ANALYTICS LAYER

This layer takes the events from the bus and provides the ability to process and act upon these events. A core
capability here is the requirement to store the data into a database. This may happen in three forms. The
traditional model here would be to write a server-side application, e.g. this could be a JAX-RS application
backed by a database. However, there are many approaches where we can support more agile approaches. The
first of these is to use a big data analytics platform. This is a cloud scalable platform that supports technologies
such as Apache Hadoop to provide highly scalable map reduce analytics on the data coming from the devices.
The second approach is to support complex event processing to initiate near real- time activities and actions
based on data from the devices and from the rest of the system.
Our recommended approach in this space is to use the following approaches:
• Highly scalable, column-based data storage for storing
• Map-reduce for long-running batch-oriented processing of data
• Complex event processing for fast in-memory processing and near real-time reaction and autonomic actions
based on the data and activity of devices and other systems
• In addition, this layer may support traditional application processing platforms, such as JavaBeans, JAX-RS
logic, message-driven beans, or alternatives, such as node.js, PHP, Ruby or Python.

ENT/EXTERNAL COMMUNICATIONS LAYER

The reference architecture needs to provide a way for these devices to communicate outside of the device
oriented system. This includes three main approaches.
 Firstly, we need the ability to create web-based frontends and portals that interact with devices and with the
event-processing layer.
 Secondly, we need the ability to create dashboards that offer views into analytics and event processing.
 Finally, we need to be able to interact with systems outside this network using machine-to-machine
communications (APIs). These APIs need to be managed and controlled and this happens in an API
management system.
The recommended approach to building the web front end is to utilize a modular front-end architecture, such as
a portal, which allows simple fast composition of useful UIs. Of course, the architecture also supports existing
Web server-side technology, such as Java Servlets/ JSP, PHP, Python, Ruby, etc.
The API management layer provides three main functions:
 The first is that it provides a developer-focused portal (user focused portal previously mentioned), where
developers can find, explore, and subscribe to APIs from the system. There is also support for publishers
to create, version, and manage the available and published APIs.
 The second is a gateway that manages access to the APIs, performing access control checks (for external
requests) as well as throttling usage based on policies. It also performs routing and load- balancing.
 The final aspect is that the gateway publishes data into the analytics layer where it is stored as well as
processed to provide insights into how the APIs are used.

DEVICE MANAGEMENT
Device management (DM) is handled by two components. A server-side system (the device manager)
communicates with devices via various protocols and provides both individual and bulk control of devices. It
also remotely manages software and applications deployed on the device. It can lock and/or wipe the device if
necessary. The device manager works in conjunction with the device management agents. There are multiple
different agents for different platforms and device types. The device manager also needs to maintain the list of
device identities and map these into owners. It must also work with the identity and access management layer
to manage access controls over devices (e.g. who else can manage the device apart from the owner, how much
28
control does the owner have vs. the administrator, etc.) There are three levels of device: non-managed, semi
managed and fully managed (NM, SM, FM). Fully managed devices are those that run a full DM agent.
A full DM agent supports:
• Managing the software on the device
• Enabling/disabling features of the device (e.g. camera, hardware, etc.)
• Management of security controls and identifiers
• Monitoring the availability of the device
• Maintaining a record of the device location if available.
• Locking or wiping the device remotely if the device is compromised, etc.
Non-managed devices can communicate with the rest of the network, but have no agent involved. These may
include 8-bit devices where the constraints are too small to support the agent. The device manager may still
maintain information on the availability and location of the device if this is available. Semi-managed devices
are those that implement some parts of the DM (e.g. feature control, but not software management).

IDENTITY AND ACCESS MANAGEMENT

The final layer is the identity and access management layer. This layer needs to provide the following services:
• OAuth2 token issuing and validation
• Other identity services including SAML2 SSO and OpenID Connect support for identifying inbound requests
from the Web layer
• XACML PDP
• Directory of users (e.g. LDAP)
• Policy management for access control (policy control point)
The identity layer have other requirements specific to the other identity and access management for a given
instantiation of the reference architecture.

10. Explain in detail about the IoT Reference model with neat diagram.
IoT Reference Model in an IoT system, data is generated by multiple kinds of devices, processed in different
ways, transmitted to different locations, and acted upon by applications.
The proposed IoT reference model is comprised of seven levels. Each level is defined with terminology that can
be standardized to create a globally accepted frame of reference. The IoT Reference Model does not restrict the
locality of its components.
The IoT Reference Model also allows the processing occurring at each level to range from trivial to complex,
depending on the situation. The model describes how tasks at each level should be handled to maintain
simplicity, allow high scalability, and ensure supportability. Finally, the model defines the functions required
for an IoT system to be complete.
Figure 4.24 illustrates the IoT Reference model and its levels. It is important to note that in the IoT, data flows
in both directions. In a control pattern, control information flows from the top of the model (level 7) to the
bottom (level 1). In a monitoring pattern, the flow of information is the reverse. In most systems, the flow will
be bidirectional.

Fig.4.24 - IoT Reference model

29
Level 1: Physical Devices and Controllers
The IoT Reference Model starts with Level 1: physical devices and controllers that might control multiple
devices. These are the “things” in the IoT, and they include a wide range of endpoint devices that send and
receive information. Today, the list of devices is already extensive. It will become almost unlimited as more
equipment is added to the IoT over time. Devices are diverse, and there are no rules about size, location, form
factor, or origin. Some devices will be the size of a silicon chip. Some will be as large as vehicles. The IoT must
support the entire range. Dozens or hundreds of equipment manufacturers will produce IoT devices. To simplify
compatibility and support manufacturability, the IoT Reference Model generally describes the level of
processing needed from Level 1 devices.
Level 2: Connectivity
Communications and connectivity are concentrated in one level—Level 2.
The most important function of Level 2 is reliable, timely information transmission. This includes transmissions:
● Between devices (Level 1) and the network
● Across networks (east-west)
● Between the network (Level 2) and low-level information processing occurring at Level 3.
Level 3: Edge (Fog) Computing
The functions of Level 3 are driven by the need to convert network data flows into information that is suitable
for storage and higher-level processing at Level 4 (data accumulation). This means that Level 3 activities focus
on high-volume data analysis and transformation.
Level 3 processing can encompass many examples, such as:
 Evaluation: Evaluating data for criteria as to whether it should be processed at a higher level.
 Formatting: Reformatting data for consistent higher-level processing.
 Expanding/decoding: Handling cryptic data with additional context (such as the origin)
 Distillation/reduction: Reducing and/or summarizing data to minimize the impact of data and traffic on the
network and higher-level processing systems
 Assessment: Determining whether data represents a threshold or alert; this could include redirecting data to
additional destinations
Level 4: Data Accumulation
Networking systems are built to reliably move data. The data is “in motion.” Prior to Level 4, data is moving
through the network at the rate and organization determined by the devices generating the data.
Level 4 determines:
If data is of interest to higher levels: If so, Level 4 processing is the first level that is configured to serve the
specific needs of a higher level.
●If data must be persisted: Should data be kept on disk in a non-volatile state or accumulated in memory for
short-term use?
●The type of storage needed: Does persistency require a file system, big data system, or relational database?
●If data is organized properly: Is the data appropriately organized for the required storage system?
●If data must be recombined or recomputed: Data might be combined, recomputed, or aggregated with
previously stored information, some of which may have come from non-IoT sources.
Level 5: Data Abstraction
IoT systems will need to scale to a corporate—or even global—level and will require multiple storage systems
to accommodate IoT device data and data from traditional enterprise ERP, HRMS, CRM, and other systems.
With multiple devices generating data, there are many reasons why this data may not land in the same data
storage:
● There might be too much data to put in one place.
● Moving data into a database might consume too much processing power, so that retrieving it must be separated
from the data generation process. This is done today with online transaction processing (OLTP) databases and
data warehouses.
● Devices might be geographically separated, and processing is optimized locally.
● Levels 3 and 4 might separate “continuous streams of raw data” from “data that represents an event.” Data
storage for streaming data may be a big data system, such as Hadoop. Storage for event data may be a relational
database management system (RDBMS) with faster query times.

30
● Different kinds of data processing might be required. For example, in-store processing will focus on different
things than across-all-stores summary processing. For these reasons, the data abstraction level must process
many different things. These include:
● Reconciling multiple data formats from different sources
● Assuring consistent semantics of data across sources
● Confirming that data is complete to the higher-level application 31
● Consolidating data into one place (with ETL, ELT, or data replication) or providing access to multiple data
stores through data virtualization
● protecting data with appropriate authentication and authorization
● Normalizing or denormalizing and indexing data to provide fast application access Level.
Application Level 6
It is the application level, where information interpretation occurs. Software at this level interacts with Level 5
and data at rest, so it does not have to operate at network speeds. The IoT Reference Model does not strictly
define an application. Applications vary based on vertical markets, the nature of device data, and business needs.
For example, some applications will focus on monitoring device data. Some will focus on controlling devices.
Some will combine device and non-device data. Monitoring and control applications represent many different
application models, programming patterns, and software stacks, leading to discussions of operating systems,
mobility, application servers, hypervisors, multi- threading, multi-tenancy, etc.
Level 7: Collaboration and Processes
One of the main distinctions between the Internet of Things (IoT) and IoT is that IoT includes people and
processes. This difference becomes particularly clear at Level 7: Collaboration and Processes. The IoT system,
and the information it creates, is of little value unless it yields action, which often requires people and processes.
Applications execute business logic to empower people. People use applications and associated data for their
specific needs. Often, multiple people use the same application for a range of different purposes. So, the
objective is not the application—it is to empower people to do their work better. Applications (Level 6) give
business people the right data, at the right time, so they can do the right thing. But frequently, the action needed
requires more than one person. People must be able to communicate and collaborate, sometimes using the
traditional Internet, to make the IoT useful. Communication and collaboration often require multiple steps. And
it usually transcends multiple applications. This is why Level 7, represents a higher level than a single.

11. Explain in detail about the CAN bus with message fields diagram.
Control Area Network (CAN) bus is a serial communication protocol that allows devices to exchange data in a
reliable and efficient way. It is widely used in vehicles, working like a nervous system to connect ECUs in the
vehicle. CAN bus was originally designed for automotive applications. It is a multi-master, multi-slave, half-
duplex, and fault-tolerant protocol that fits well with the requirements of automotive applications. It is simple,
low-cost, and reliable.
In a CAN network, all nodes are connected via twisted-pair wiring or optical fiber cables. Each node has its
own microcontroller responsible for processing incoming messages and sending outgoing ones. Data is
broadcasted by a node on the shared bus, allowing all other nodes to receive it. The primary stages of the
communication process are:

1. Arbitration: To prevent collisions when multiple nodes attempt to transmit simultaneously, CAN uses an
arbitration process based on message priority. The lower the identifier value of a message, the higher its
priority.
2. Error detection: Built-in error detection mechanisms ensure data integrity within CAN networks. These
include cyclic redundancy checks (CRC), frame check sequences (FCS), and acknowledgment bits from
receiving nodes.
3. Fault confinement: If any node detects an error or malfunctions during transmission, it will enter an "error
passive" state until proper operation resumes. This prevents faulty transmissions from affecting overall
system functionality.
This combination of features allows CAN buses to maintain high levels of efficiency while ensuring reliable
communication between different components in complex systems like vehicles or factory automation
equipment.

31
Message Structure in the CAN Protocol
The message structure in a CAN bus system is crucial for efficient communication between devices. The
protocol uses a data frame format that consists of several fields, including an identifier, control field, data field,
and error detection mechanism as shown in fig.4.25.

Fig.4.25 – Can bus protocol message fields

 Identifier: This unique value determines the priority of each message on the network. In standard 11-bit
identifiers (CAN 2.0A), there are up to 2048 different priorities available. Extended 29-bit identifiers
(CAN 2.0B) provide even more options with over half a billion distinct values.
 Data Length Code (DLC): Located within the control field, this code specifies how many bytes are present
in the data field - ranging from zero to eight bytes.
 Data Field: Contains actual information being transmitted across nodes in byte-sized segments.
 Cyclic Redundancy Check (CRC): A built-in error detection mechanism that ensures reliable
communication by detecting transmission errors and requesting retransmission if necessary.
 Acknowledgment Slot: A single bit used by receiving nodes to acknowledge successful receipt of messages
or indicate errors requiring retransmission.
 Error Frame: An optional part of CAN messaging that allows nodes to signal when they detect an issue
with their own transmissions or received messages from other devices on the network.
Types of CAN
Here are the three main types of CAN:
1) Low-Speed CAN
Low-Speed CAN, also known as fault-tolerant or ISO 11898-3, operates at speeds up to 125 kbps. It is designed
for less critical systems like body control modules, door locks, window controls, etc. Its key feature is the ability
to continue functioning even when one wire in the bus fails.
2) High-Speed CAN
High-Speed CAN, or ISO 11898-2, can reach speeds up to 1 Mbps. This type of network is suitable for more
time-sensitive applications such as engine management systems and electronic braking systems due to its faster
data transfer rates compared to low-speed counterparts.
3) CAN FD (Flexible Data Rate)
CAN FD is an extension of high-speed networks with increased data rates up to 5 Mbps while maintaining
backward compatibility with existing high-speed devices. The primary advantage of this technology lies in its
ability to transmit larger payloads more efficiently than traditional CAN, making it ideal for modern vehicles
with increasingly complex electronic system.

12. Explain in detail about the BACnet with neat diagram.

A data communication protocol that is used to build an automated control network, is known as BACnet or
Building Automation Control Network. This data communication protocol is both an ISO & ANSI standard
used for interoperability between cooperating building automation devices. Bacnet Protocol includes a set of
rules for governing the data exchange on a computer network that simply covers all from what type of cable to
utilize, to form a particular command or request in a normal way.
To attain interoperability across a broad spectrum of equipment, the BACnet specification includes three major
parts. Primary, Secondary, and tertiary. So the primary part defines a technique to represent any kind of building
automation apparatus in a normal way.

32
The secondary part describes messages that can be transmitted across a network of computers to check and
manage such equipment. The final part describes a set of suitable LANs which are used for conveying BACnet
communications.
Fig.4.26 shows the BACnet protocol architecture and it is predominately restricted to lighting controls, HVAC
& gateways. This protocol highlights lightweight and efficient communication which is optimized for short
messages, small networks, and inter-networks.

Fig.4.26 – BACnet Protocol Architecture

BACnet Physical Layer

The upper layers of BACnet do not depend on the physical layer. So the Physical layer of BACnet makes it
feasible for BACnet to be executed on different networks. The physical layers of BACnet have been specified
with ARCNET, Ethernet, IP tunnels, BACnet/IP, RS-232, RS485, and Lonworks/LonTalk. RS232 is for point-
to-point communication. RS485 supports up to 32 nodes with a distance of 1200 m at 76Kbps.
BACnet Protocol Link Layer
BACnet protocol is implemented directly with LonTalk or IEEE802.2 link layers. So it specifies Point to Point
(PTP) data link layer for RS232 connections. It specifies MS/TP data link layer intended for RS-485
connections. The standard simply specifies BVLL (BACnet Virtual Link Layer) which states all the services
required through the BACnet device at this link layer.
IP BACnet Virtual Link Layer encapsulates required control data in a header of BACnet virtual link control
information. Because of IP, BVLL, and BACnet protocol devices can directly communicate over IP networks
without the requirement of any router device.
BACnet protocol utilizes BBMD (BACnet broadcast management device) concept which executes the required
broadcast for the preferred link layer. So, the BACnet broadcast message is changed into IP-based broadcast or
multicast messages.
BACnet Network Layer
This layer simply specifies the required addresses of the network for routing. BACnet network includes a
minimum of one or above segments that are connected with bridges once they utilize similar LAN technologies.
If they utilize various LAN protocols then they are connected through routers.
Application Layer
BACnet does not separate presentation as well as application layers. So it takes care of reliability & sequencing
or segmentation mechanisms generally connected with both the session & transport layers. BACnet includes
devices like objects to exchange service primitives which are described with ASN.1 syntax & serialized with
ASN.1 BER.
BACnet Security Layer
The concept of BACnet security can be understood easily with an example say when BACnet device-A requests
a session key from the key server for establishing secure communication through device-B, then this key is
transmitted to both the device-A & device-B through the key server which is known as ‘SKab’. BACnet protocol
uses 56-bit DES encryption.
The different types of BACnet protocols are

33
1) BACnet/IP
BACnet/IP utilizes UDP/IP for compatibility through existing IP infrastructure. Once BACnet/IP is utilized
with several IP subnets, then extra device functionality known as BBMDs (BACnet Broadcast Management
Devices) is necessary to handle broadcast messages of inter-subnet BACnet.
2) BACnet MS/TP
This kind of LAN uses EIA-485 twisted pair for signaling up to 4k feet. So it is a very famous type of BACnet
LAN which is used for unitary as well as application-specific controllers. This BACnet MS/TP is not expensive.
3) BACnet ISO 8802-3 (Ethernet)
BACnet is directly used with Ethernet 8802-3 networks which are similar to BACnet/IP in terms of speed &
cost, although restricted to a single physical infrastructure that does not utilize IP routers.
4) BACnet over ARCNET
This BACnet is MAC type which includes two forms like 2.5Mbs coax & 156Kbs above EIA-485. This BACnet
is supported by a limited number of vendors with ARCNET.
5)BACnet Point-to-Point
This BACnet Point-to-Point is simply used over the networks of dial-up telephones. Generally, thus direct EIA-
232 connection is no longer used for a direct Ethernet connection.
6) BACnet over LonTalk Foreign Frames
This BACnet simpl6y allows LonTalk’s transport component for carrying BACnet messages. But, the two
protocols are not interoperable.
7) BACnet over ZigBee
Generally, this MAC is a wireless mesh network used with less costly devices. So it is normally used as a
gateway to ZigBee devices & not like a native BACnet transport.
8) Bacnet to Modbus Converter
Protocon-P3 Gateway is a BACnet to Modbus converter which is used in designing automation systems in
different applications like HVAC, access control, lighting control & fire detection systems, and their related
equipment. The Protocon-P3 Gateway combines such BACnet systems & devices with Modbus based
management systems over Modbus RTU protocol & Modbus TCP/IP.

34