MTIN 101

IoT ARCHITECTURE AND PROTOCOLS

Unit I

IoT definition, Characteristics, IoT conceptual and architectural framework, Physical and logical design of
IoT, IoT enablers, Modern day IoT applications, M2M communications, IoT vs M2M, IoT vs WoT, IoT
reference architecture, IoT Network configurations, IoT LAN, IoT WAN, IoT Node, IoT Gateway, IoT Proxy
---------------------------------------------------------------
IoT definition : IoT stands for Internet of Things, which means accessing and controlling daily usable
equipments and devices using Internet.

What is an Internet of Things (IoT)

Let's us look closely at our mobile device which contains GPS Tracking, Mobile Gyroscope, Adaptive
brightness, Voice detection, Face detection etc. These components have their own individual features, but
what about if these all communicate with each other to provide a better environment? For example, the phone
brightness is adjusted based on my GPS location or my direction.

Connecting everyday things embedded with electronics, software, and sensors to internet enabling to collect
and exchange data without human interaction called as the Internet of Things (IoT).

The term "Things" in the Internet of Things refers to anything and everything in day to day life which is
accessed or connected through the internet.

IoT is an advanced automation and analytics system which deals with artificial intelligence, sensor, networking,
electronic, cloud messaging etc. to deliver complete systems for the product or services. The system created
by IoT has greater transparency, control, and performance.

As we have a platform such as a cloud that contains all the data through which we connect all the things
around us. For example, a house, where we can connect our home appliances such as air conditioner, light,
etc. through each other and all these things are managed at the same platform. Since we have a platform, we
can connect our car, track its fuel meter, speed level, and also track the location of the car.
If there is a common platform where all these things can connect to each other would be great because based
on my preference, I can set the room temperature. For example, if I love the room temperature to be set at 25
or 26-degree Celsius when I reach back home from my office, then according to my car location, my AC would
start before 10 minutes I arrive at home. This can be done through the Internet of Things (IoT).

How does Internet of Thing (IoT) Work?

The working of IoT is different for different IoT echo system (architecture). However, the key concept of there
working are similar. The entire working process of IoT starts with the device themselves, such as smartphones,
digital watches, electronic appliances, which securely communicate with the IoT platform. The platforms collect
and analyze the data from all multiple devices and platforms and transfer the most valuable data with
applications to devices.

Characteristics of IoT

The most important Characteristics of IoT on which it works are connectivity, analyzing, integrating, active
engagement, and many more. Some of them are listed below:

Connectivity: Connectivity refers to establish a proper connection between all the things of IoT to IoT platform
it may be server or cloud. After connecting the IoT devices, it needs a high speed messaging between the
devices and cloud to enable reliable, secure and bi-directional communication.

Analyzing: After connecting all the relevant things, it comes to real-time analyzing the data collected and use
them to build effective business intelligence. If we have a good insight into data gathered from all these things,
then we call our system has a smart system.

Integrating: IoT integrating the various models to improve the user experience as well.

Artificial Intelligence: IoT makes things smart and enhances life through the use of data. For example, if we
have a coffee machine whose beans have going to end, then the coffee machine itself order the coffee beans
of your choice from the retailer.

Sensing: The sensor devices used in IoT technologies detect and measure any change in the environment
and report on their status. IoT technology brings passive networks to active networks. Without sensors, there
could not hold an effective or true IoT environment.

Active Engagement: IoT makes the connected technology, product, or services to active engagement
between each other.
Endpoint Management: It is important to be the endpoint management of all the IoT system otherwise, it
makes the complete failure of the system. For example, if a coffee machine itself order the coffee beans when
it goes to end but what happens when it orders the beans from a retailer and we are not present at home for a
few days, it leads to the failure of the IoT system. So, there must be a need for endpoint management.

https://wso2.com/whitepapers/a-reference-architecture-for-the-internet-of-things/

IoT conceptual and architectural framework

The architecture framework 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 cross-
cutting/vertical layers such as access/identity management.

The architecture framework for IoT

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 management

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 device 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

There are many more such examples of each type.

Each device typically needs an identity. The identity may be one of the following:

• A unique identifier (UUID) burnt into the device (typically part of the System-on-Chip,or provided by a
secondary chip)

• A UUID provided by the radio subsystem (e.g. Bluetooth identifier, Wi-Fi MAC address)

• An OAuth2 Refresh/Bearer Token (this may be in addition to one of the above)

• An identifier stored in nonvolatile memory such as EEPROM

For the reference architecture we recommend that every device has a UUID (preferably an unchangeable ID
provided by the core hardware) as well as an OAuth2 Refresh and Bearer token stored in EEPROM.

The specification is based on HTTP; however, (as we will discuss in the communications section) the
reference architecture also supports these flows over MQTT.

The 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 wellknown three potential protocols are

• HTTP/HTTPS (and RESTful approaches on those)

• MQTT 3.1/3.1.1

• Constrained application protocol (CoAP)

Let's take a quick look at each of these protocols in turn.

HTTP is well known, and there are many libraries that support it. Because it is a simple textbased protocol,
many small devices such as 8-bit controllers can only partially support the protocol – for example enough code
to POST or GET a resource. The larger 32-bit based devices can utilize full HTTP client libraries that properly
implement the whole protocol.

There are several protocols optimized for IoT use. The two best known are MQTT6 and CoAP7. MQTT was
invented in 1999 to solve issues in embedded systems and SCADA. It has been through some iterations and
the current version (3.1.1) is undergoing standardization in the OASIS MQTT Technical Committee 8. MQTT is
a publish-subscribe messaging system based on a broker model. The protocol has a very small overhead (as
little as 2 bytes per message), and was designed to support lossy and intermittently connected networks.
MQTT was designed to flow over TCP. In addition there is an associated specification designed for ZigBee-
style networks called MQTT-SN (Sensor Networks).

CoAP is a protocol from the IETF that is designed to provide a RESTful application protocol modeled on
HTTP semantics, but with a much smaller footprint and a binary rather than a text-based approach. CoAP is a
more traditional client-server approach rather than a brokered approach. CoAP is designed to be used over
UDP.

For the reference architecture we have opted to select MQTT as the preferred device communication
protocol, with HTTP as an alternative option.

The reasons to select MQTT and not CoAP at this stage 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

However, both protocols have specific strengths (and weaknesses) and so there will be some situations
where CoAP may be preferable and could be swapped in.

In order to support MQTT we need to have an MQTT broker in the architecture as well as device libraries.
We will discuss this with regard to security and scalability later.

One important aspect with IoT devices is not just for the device to send data to the cloud/ server, but also the
reverse. This is one of the benefits of the MQTT specification: because it is a brokered model, clients connect
an outbound connection to the broker, whether or not the device is acting as a publisher or subscriber. This
usually avoids firewall problems because this approach works even behind firewalls or via NAT.

In the case where the main communication is based on HTTP, the traditional approach for sending data to
the device would be to use HTTP Polling. This is very inefficient and costly, both in terms of network traffic as
well as power requirements. The modern replacement for this is the WebSocket protocol 9 that allows an HTTP
connection to be upgraded into a full two-way connection. This then acts as a socket channel (similar to a pure
TCP channel) between the server and client. Once that has been established, it is up to the system to choose
an ongoing protocol to tunnel over the connection.

For the reference architecture we once again recommend using MQTT as a protocol with WebSockets. In
some cases, MQTT over WebSockets will be the only protocol. This is because it is even more firewall-friendly
than the base MQTT specification as well as supporting pure browser/JavaScript clients using the same
protocol.

Note that while there is some support for WebSockets on small controllers, such as Arduino, the combination
of network code, HTTP and WebSockets would utilize most of the available code space on a typical Arduino 8-
bit device. Therefore, we only recommend the use of WebSockets on the larger 32-bit devices.

The 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 HTTPbased APIs that are

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. It must be able to act as an OAuth2
Resource Server (validating Bearer Tokens and associated resource access scopes). It must also be able to
act as a policy enforcement point (PEP) for policy-based access. In this model, the bus makes requests to the
identity and access management layer to validate access requests. The identity and access management layer
acts as a policy decision point (PDP) in this process. The bus layer then implements the results of these calls
to the PDP to either allow or disallow resource access.

The 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 serverside 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 mapreduce 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 events
 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 Java Beans,
JAX-RS logic, message-driven beans, or alternatives, such as node.js, PHP, Ruby or Python.

Client/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 front-
ends 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. Our recommended
approach is based on the Java framework and the most popular Java-based web server, Apache Tomcat.
The dashboard is a re-usable system focused on creating graphs and other visualizations of data coming from
the devices and the event processing layer.
The API management layer provides three main functions:

 The first is that it provides a developer-focused portal (as opposed to the userfocused 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 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’s 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 may of course have other requirements specific to the other identity and access

management for a given instantiation of the reference architecture. In this section we have outlined the major

components of the reference architecture as well as specific decisions we have taken around technologies.

These decisions are motivated by the specific requirements of IoT architectures as well as best practices for

building agile, evolvable, scalable Internet architectures. Of course there are other options, but this reference

architecture utilizes proven approaches that are known to be successful in real-life IoT projects we have

worked on.

Physical and logical design of IoT

The "Things" in IoT usually refers to IoT devices which have unique identities and can perform remote sensing,
actuating and monitoring capabilities.

IoT devices can:

• Exchange data with other connected devices and applications (directly or indirectly), or
• Collect data from other devices and process the data locally or
• Send the data to centralized servers or cloud-based application back-ends for processing the data, or
• Perform some tasks locally and other tasks within the IoT infrastructure, based on temporal and space
constraints

Logical design of an IoT

system refers to an abstract representation of the entities and processes without going into the low-level
specifics of the implementation.

• An IoT system comprises of a number of functional blocks that provide the system the
capabilities for identification, sensing, actuation, communication, and management.
Sensors: The IoT Enablers
As the Internet of Things (IoT) enables devices to make intelligent decisions that generate positive business
outcomes, it’s the sensors that enable those decisions. As cost and time-to-market pressures continue to rise,
sensors provide greater visibility into connected systems and empower those systems to react intelligently to
changes driven by both external forces and internal factors.

Sensors are the components that provide the actionable insights that power the IoT and enable organizations to
make more effective business decisions. It’s through this real-time measurement that the IoT can transform an
organization’s ability to react to change. 

For example, consider a fleet of garbage collection trucks that periodically empty trash bins. Most trucks have a
consistent weekly route for emptying bins, whether they’re full or not, because the schedule does not account for
how people use them. If an ultrasonic sensor is incorporated into the design of the trash bin, it can provide the
waste management company with valuable data about how much trash is inside, and then optimize trash
collection routes accordingly.
Who are IoT Enablers?
System installers, repairers, craftsmen, electricians, plumbers, designers and do-it-yourselfers who connect
devices and systems to the Internet for personal use and for commercial and other business uses.

M2M communications :Machine-to-machine, or M2M, is a broad label that can be used to describe any
technology that enables networked devices to exchange information and perform actions without the manual
assistance of humans. Artificial intelligence (AI) and machine learning (ML) facilitate the communication between
systems, allowing them to make their own autonomous choices.
M2M technology was first adopted in manufacturing and industrial settings, where other technologies, such
as SCADA and remote monitoring, helped remotely manage and control data from equipment. M2M has since
found applications in other sectors, such as healthcare, business and insurance. M2M is also the foundation for
the internet of things (IoT).
Machine-to-machine communication is often used for remote monitoring. In product restocking, for example, a
vending machine can message the distributor's network, or machine, when a particular item is running low to send
a refill. An enabler of asset tracking and monitoring, M2M is vital in warehouse management systems (WMS) and
supply chain management (SCM).

Difference between IoT and M2M

1. Internet of Things :
IOT is known as the Internet of Things where things are said to be the communicating devices that can interact
with each other using a communication media. Usually every day some new devices are being integrated which
uses IoT devices for its function. These devices use various sensors and actuators for sending and receiving
data over the internet. It is an ecosystem where the devices share data through a communication media known
as the internet.
2. Machine to Machine :
This is commonly known as Machine to machine communication. It is a concept where two or more than two
machines communicate with each other without human interaction using a wired or wireless mechanism. M2M is
an technology that helps the devices to connect between devices without using internet. M2M communications
offer several applications such as security, tracking and tracing, manufacturing and facility management.
Difference between IoT and M2M :

Basis of IoT M2M

Abbreviation Internet of Things Machine to Machine

Devices have objects that are responsible Some degree of intelligence is

Intelligence for decision making observed in this

Connection type The connection is via Network and using The connection is a point to
used various communication types. point

Traditional protocols and

Communication Internet protocols are used such communication technology
protocol used as HTTP, FTP, and Telnet. techniques are used

Data is shared between other

applications that are used to improve the Data is shared with only the
Data Sharing end-user experience. communicating parties.

Internet connection is required for Devices are not dependent on

Internet communication the Internet.

A large number of devices yet scope is

Scope large. Limited Scope for devices.

Business Type Business 2 Business(B2B) and Business Business 2 Business (B2B)

 Basis of IoT M2M

used 2 Consumer(B2C)

There is no support for Open

Open API support Supports Open API integrations. Api’s

Smart wearables, Big Data and Cloud, Sensors, Data and

Examples etc. Information, etc.

IoT vs WoT
The difference between the IoT and the WoT may appear as a straightforward and easy to make distinction
The difference between the Internet of Things (IoT) and the Web of Things (WoT) may appear as a
straightforward and easy to make distinction. However, the differences between both concepts are far more
complicated than one may imagine; each minute detail of both IoT and WoT makes for two vastly differing
subjects, each with their own set of ideas, structures, and uses. Despite their differences, IoT and WoT work in
unison and will rely on each other to run smoothly and the most efficiently.
IoT
In its most basic sense, the Internet of Things refers to everyday objects and devices that are connected through
wireless networks. The wireless networks use special sensors, or other technology, to interconnect with these
everyday objects, thus making up the IoT. These everyday objects are devices embedded with sensors (to
recognize environmental conditions), wireless or wired communication interfaces, computation (for running
complex programs), and/or actuators – all of these make up the “Things” in IoT.
Everything in IoT is indeed connected. IoT turns everyday objects into something intelligent – said objects are
made “readable, recognizable, locatable, addressable, and/or controllable via the Internet” (SRI Consulting
Business Intelligence).
IoT Examples
Examples of devices connected to the Internet of Things can range from very simple to extraordinarily complex.
Teetering on the more simplistic side, a package that is sent out with a tracking number from UPS uses an Auto-
ID tag. This tag may use barcodes, QR codes, NFC, or RFID tags. These tags allow your package to be tracked
from the supplier to the shipping center, all the way up until your package is delivered. A more complex example
is tech used to maintain and repair large equipment and machinery. Sensors can be installed inside machinery
and send alerts and reports to manufacturers when something is not running properly. This can help top
equipment malfunctions, leading to a reduction in injury and loss of money.
Limitations of IoT
With some many Things trying to communicate with one another in different ways, it is challenging to seamlessly
build a single communication platform in which all Things speak together effectively. Many have tried to create
completely new platforms of communication so all devices can communicate effectively, also known as an
application layer protocol (or a language, more simply put). However, this is time-consuming and may be nearly
impossible. Therefore, many others believe we must use a platform that already exists…the World Wide Web.
This is where the WoT comes into play. The web is an already established system that can allow all Things to
communicate with each other. The Web may be used as a type of application where all Things can communicate
together in the most efficient manner.
WoT
The WoT is very similar to the IoT in some ways and in others it is drastically different. WoT was inspired by the
IoT as in common everyday devices are connected to the Web and can communicate through various systems.
However, where both begin to differentiate is the WoT is focused on reusing the already established Web system
to help these everyday connected devices connect to one single application – in this case, the Web. If all
connected devices are able to use one single base, the Web, to store information and communicate with each
other, we can successfully make a global ecosystem for Things to communicate together.
https://whataftercollege.com/internet-of-things/difference-between-iot-and-wot/
IoT reference architecture
https://wso2.com/whitepapers/a-reference-architecture-for-the-internet-of-things/

Is There Value in A Reference Architecture for the IoT?

 IoT devices are inherently connected – we need a way of interacting with them, often with firewalls,
network address translation (NAT) and other obstacles in the way.
 There are billions of these devices already and the number is growing quickly; we need an architecture
for scalability. In addition, these devices are typically interacting 24x7, so we need a highly-available (HA)
approach that supports deployment across data centers to allow disaster recovery (DR).

 The devices may not have UIs and certainly are designed to be “everyday” usage, so we need to support
automatic and managed updates, as well as being able to remotely manage these devices.

 IoT devices are very commonly used for collecting and analyzing personal data. A model for managing
the identity and access control for IoT devices and the data they publish and consume is a key
requirement.

There are several reasons why a reference architecture for IoT is a good thing:

Our aim is to provide an architecture that supports integration between systems and devices.

In the next section, we will dig into these requirements deeper and outline the specific requirements we are
looking for in a range of categories.

3. Requirements for a Reference Architecture

There are some specific requirements for IoT that are unique to IoT devices and the environments that
support them, e.g. many requirements emerge from the limited formfactors and power available to IoT
devices. Other requirements come from the way in which IoT devices are manufactured and used. The
approaches are much more like traditional consumer product designs than existing Internet approaches. Of
course there are a number of existing best practices for the server-side and Internet connectivity that need to
be remembered and factored in.

We can summarize the overall requirements into some key categories:

  Connectivity and communications
 Device management
 Data collection, analysis, and actuation
 Scalability
 Security
 HA
 Predictive analysis
 Integration

What is an IOT LAN?

Local and Personal Area Networks (LAN/PAN)

Networks that cover fairly short distances are called personal area networks (PAN) and local area networks
(LAN). PAN and LAN networks are considered to be fairly cost-effective, but the transfer of data can sometimes
be unreliable.

Wireless personal and local area network technologies that are commonly incorporated into IoT connectivity
solutions are WiFi and Bluetooth. WiFi can be used for applications that run in a local environment, or in a
distributed setting if there are multiple access points integrated into a larger network. One downside to WiFi is
that it works only if the signal is strong and you’re close to the access point. Also, WiFi is generally more power-
hungry than people think, but it is possible to operate it in a way that’s a little more power-efficient (for example,
your device only connects periodically to send data, then goes back to sleep).

Bluetooth Low Energy (BLE) is a more energy-efficient wireless network protocol—if you’re not receiving data
constantly, a single battery running BLE could last up to five years. However, compared to WiFi it is slower to
transmit and is more limited in the amount of data it is capable of sending.

Both WiFi and Bluetooth are easy to connect in most cases, although WiFi does have some security challenges
that may be difficult to overcome.

What is an IOT WAN?

Low Power Wide Area Networks (LPWAN)

IoT devices that run on LPWANs send small packets of information infrequently and over long distances. This
type of wireless network was developed in response to the early challenges of cellular connectivity. Proponents of
LPWAN position it as longer-range than WiFi and Bluetooth, but using less power than cellular. Sigfox built the
first LPWAN network in France and is considered the driving force behind its growth (despite the fact that Sigfox
never took off in the U.S.).

A well-known and commonly used IoT network protocol in this category is LoRaWAN (long range wireless area
network), which runs on the LoRa (long range) communication network. Advantages of LoRaWAN for IoT devices
are its low power requirement (for long battery life) and relatively low-cost chipsets. Plus, under the right
conditions, a single base station or gateway running on a long-range network is capable of providing service to a
very large area—a few kilometers in dense urban areas and up to 15–30 kilometers in rural areas.
 What is an IoT Gateway?
In telecommunications, the primary purpose of a gateway is to provide a bridge between different types of
communication technologies. These technologies can vary in terms of connectivity types, interfaces, or protocols.
For example, your Internet Gateway at home connects your Local Area Network (LAN) with your Internet Service
Provider (ISP). This gateway links the WAN of the ISP through technologies like PPP or HDLC with your LAN
with TCP/IP.

The IoT Gateway follows the same principle of bridging communications for different technologies. It creates a
bridge between the IoT sensors/actuators and the Internet. The IoT gateway aggregates all data, translates
sensor’s protocols, and pre-process the data before sending it.

The IoT devices connect to the IoT Gateway using short-range wireless transmission modes such as Bluetooth
LE, Zigbee, Z-wave, or long-range like LTE, LTE-M, WiFi, and then it links them to the Internet (Public Cloud)
through Ethernet LAN or Fiber Optics WAN (HDLC/PPP).

The IoT gateway understands these transmission modes and data (MQTT, CoAP, AMQP, DDS, Websocket)
protocols and can translate them to other protocols that the data systems needs.

IoT Gateway Key Features

 Communication bridging and M2M communication.
 Serves as a data cache, buffer, and streaming device.
 Offline services and real-time control of devices.
 Aggregates data.
 Pre-processes, cleans, and filters data before sending it.
 Additional intelligence for some IoT devices.
 It provides additional security.
 Device configuration and change management.

What is IoT Proxy?

Proxy servers facilitate connections between things on the enterprise network—IoT sensors, edge
computing devices, or other IoT software—and the Internet. Many IoT solutions require these connections
to collect data for analysis or provide command and control functions from the cloud.
 Proxy servers facilitate connections between things on the enterprise network—IoT sensors, edge
computing devices, or other IoT software—and the Internet. Many IoT solutions require these connections to
collect data for analysis or provide command and control functions from the cloud.