UNIT IV IOT PROTOCOLS

XMPP(Extensible Messaging and Presence Protocol)

Extensible Messaging and Presence Protocol (XMPP) is a messaging protocol that was designed originally for
chatting and message exchange applications. It was standardized by IETF more than a decade ago. Hence, 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.
The Advanced Message Queuing Protocol (AMQP)

The Advanced Message Queuing Protocol (AMQP) is another session layer protocol that was designed for financial
industry. It runs over TCP and provides a publish/ subscribe architecture which is similar to that of MQTT. The
difference is that the broker is divided into two main components: exchange and queues, as shown in Figure 6. The
exchange is responsible for receiving publisher messages and distributing them to queues based on pre-defined
roles and conditions. Queues basically represent the topics and subscribed by subscribers which will get the sensory
data whenever they are available in the queue.
Message Queue Telemetry Transport (MQTT)

Message Queue Telemetry Transport (MQTT) was introduced by IBM in 1999 and standardized by OASIS in 2013. It
is designed to provide embedded connectivity between applications and middleware’s on one side and networks
and communications on the other side. It follows a publish/subscribe architecture, as shown in Figure 5 , where the
system consists of three main components: publishers, subscribers, and a broker. From IoT point of view, publishers
are basically the lightweight sensors that connect to the broker to send their data and go back to sleep whenever
possible. Subscribers are applications that are interested in a certain topic, or sensory data, so they connect to
brokers to be informed whenever new data are received. The brokers classify sensory data in topics and send them
to subscribers interested in
the topics.
MODBUS PROTOCOL
The Modbus protocol was developed in 1979 by Modicon, incorporated, for industrial automation systems and Modicon
programmable controllers. It has since become an industry standard method for the transfer of discrete/ analog I/O
information and register data between industrial control and monitoring devices. Modbus is now a widely-accepted, open,
public-domain protocol that requires a license, but does not require royalty payment to its owner.

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).
Types of Modbus Communication Protocol
● Modbus serial protocol (the original version) 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 Figures 1.

● Modbus TCP, also known as Modbus TCP/IP, uses a client/server architecture. Network architectures
are shown Figures 2. (below) 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 trade off 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.
CAN BUS-Vehicles as networks
• 1/3 of cost of car/airplane is electronics/avionics.
• Dozens of microprocessors are used throughout the vehicle.
• Network applications:
• Vehicle control.
• Instrumentation.
• Communication.
• Passenger entertainment systems.

© 2008 Wayne Wolf Overheads for Computers as Components 2nd ed.

• Typical electrical wiring in a passenger car
The heavy cable is replaced with lightweight
2-wire CAN in today’s cars and trucks
CAN bus
• First used in 1991.
• Serial bus, 1 Mb/sec up to 40 m.
• Synchronous bus.
• Logic 0 dominates logic 1 on bus.
• Arbitrated with CSMA/AMP:
• Arbitration on message priority.

• The ISO 11898 standard defines several

versions of CAN. The dominant CAN
types used within the automobile
industry are:
• Low Speed CAN
• High Speed CAN
• ©CAN FD (Flexible
2008 Wayne Wolf Data RateOverheads
CAN) for Computers as Components 2 nd
ed.
CAN data frame
• 11 bit destination address.
• In CAN terminology, a logical 1 on the bus • RTR (Remote Transmission Rate) bit
is called recessive and a logical 0 is determines read/write from/to destination.
dominant. RTR=1/0 –Write/Read
• The driving circuits on the bus cause the • Any node can detect bus error, interrupt
bus to be pulled down to 0 if any node on packet for retransmission
the bus pulls the bus down (making 0 • The acknowledge field is used to let the
dominant over 1). When all nodes are identifier signal whether the frame was
transmitting 1s, the bus is said to be in the correctly received:
recessive state; when a node transmits a • The sender puts a recessive bit (1) in the ACK
0, the bus is in the dominant state. slot of the acknowledge field; if the receiver
detected an error, it forces the value to a
• Data are sent on the network in packets dominant (0) value. If the sender sees a 0 on
known as data frames. the bus in the ACK slot, it knows that it must
retransmit. The ACK slot is followed by a
single bit delimiter followed by the end-of-
frame field.
© 2008 Wayne Wolf Overheads for Computers as Components 2nd ed.
CAN controller
• Controller implements physical
and data link layers.
• No network layer needed---bus
provides end-to-end
connections.

© 2008 Wayne Wolf Overheads for Computers as Components 2nd ed.

 BACNET
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.
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.
The BACnet protocol’s importance is to define typical techniques that manufacturers can execute to build
components as well as systems that are interoperable through other components & systems of BACnet.
It also specifies how data is signified on the network as well as the services that are utilized to transmit data from
one node of BACnet to another node. It also has messages that recognize network & data nodes.
BACnet is used as a tool by owners of buildings & system specifiers for the specification of the interoperable
system. This protocol does not change the need for indicating what a consumer needs. So, it provides simply some
consistent tools to assist the creation & specification of systems that can interoperate.
 BACnet Protocol Architecture
• BACnet protocol is used in all types of automated building systems. So, there are interoperable products available within
different categories like security, fire, lighting, elevators, HVAC, etc. This protocol simply addresses the interoperability
goal through simply defining a general working model of automation devices, a technique used for defining the data that
they include, & also a technique used for explaining protocols that a single device can utilize to inquire one more device to
execute some preferred action.
• The BACnet protocol architecture 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.
• BACnet protocol architecture is a collapsed architecture that matches to 4-layers of the OSI model. The four layers in the
BACnet architecture mainly include Application, Network, Data Link & Physical. Even though, just the Network layer &
Application layer are simply BACnet.
• The above architecture is the BACnet protocol stack which includes different layers as shown in the diagram. This protocol
is a collapsed version of the OSI stack. The transport and session layers are not used. The application layer takes on the
functions of these two layer