IOT communication model
1. Device-to-Device Communications
The device-to-device communication model represents two or
more devices that directly connect and communicate between one
another, rather than through an intermediary application
server. These devices communicate over many types of networks,
including IP networks or the Internet. Often, however these
devices use protocols like Bluetooth, Z-Wave, or ZigBee to establish
direct device-to-device communications,
2. Device-to-Cloud Communications
In
a device-to-cloud communication model, the IoT device connects directly to an
Internet cloud service like an application service provider to exchange data and
control message traffic. This approach frequently takes advantage of existing
communications mechanisms like traditional wired Ethernet or Wi-Fi connections
to establish a connection between the device and the IP network,
which
ultimately connects to the cloud service.
This
communication model is employed by some popular consumer IoT devices like the
Nest Labs Learning Thermostat and the Samsung Smart TV. Further, this cloud
connection enables the user to obtain remote access to their thermostat via a
smart phone or Web interface, and it also supports software updates to the
thermostat. Similarly, with the Samsung Smart TV technology, the television
uses an Internet connection to transmit user viewing information to Samsung for
analysis and to enable the interactive voice recognition features of the TV. In
these cases, the device-to-cloud model adds value to the end user by extending
the capabilities of the device beyond its native features. However, interoperability
challenges can arise while attempting to integrate devices made by different
manufacturers. Frequently, the device and cloud service are from the same
vendor. If proprietary data protocols are used between the device and
the
cloud service, the device owner or user may be tied to a specific cloud
service, limiting or preventing the use of alternative service providers. This
is commonly referred to as “vendor lock-in’’, a term that encompasses other
facets of the relationship with the provider such as ownership of and access to
the data. At the same time, users can generally have confidence that devices designed
for the specific platform can be integrated.
3. Device-to-Gateway Model
In
the device-to-gateway model, or more typically, the device-to-application-layer
gateway (ALG) model, the IOT device connects through an ALG service as a
conduit to reach a cloud service. In simpler terms, this means that there is
application software operating on a local gateway device, which acts as an
intermediary between the device and the cloud service and provides security
and
other functionality such as data or protocol translation. The model is shown in
Figure
Several forms of this model are found in consumer devices. In
many cases, the local gateway device is a smart phone running an app to
communicate with a device and relay data to a cloud service. This is often the
model employed with popular consumer itemslike personal fitness trackers. These
devices do not have the native ability to connect directly to a cloud service,
so they frequentlyrely on smart phone app software to serve as an intermediary
gateway to connect the fitness device to the cloud. The other form of this
device-to-gateway model is the emergence of “hub” devices in home automation
applications. These are devices that serve as a local gateway between
individual IoT devices and a cloud service, but they can also bridge
theinteroperability gap between devices themselves. For example, the Smart Things
hub is a stand-alone gateway device that has Z-Wave and Zigbee transceivers
installed to communicate with both families of devices. It then connects to the
Smart Things cloud service, allowing the user to gain access to the devices
using a smart phone app and an Internet connection.
4. Back-End Data-Sharing Model
The back-end data-sharing model refers to a communication
architecture that enables users to export and analyze smart object data from a
cloud service in combination with data from other sources. This architecture
supports “the [user’s] desire for granting access to the uploaded sensor data
to third parties”. This approach is an extension of the single device-to-cloud
communication model, which can lead to data silos where “IOT devices upload
data only to a single application service provider’’. A back-end sharing architecture
allows the data collected from single IOT device data streams to be aggregated
and analyzed. For example, a corporate user in charge of an office complex
would be interested in consolidating and analyzing the energy consumption and
utilities data produced by all the IOT sensors and Internet-enabled utility
systems on the premises. Often in the single device-to-cloud model, the data each
IOT sensor or system produces sits in a stand-alone data silo. An effective
back-end data sharing architecture would allow the company to easily access and
analyze the data in the cloud produced by the whole spectrum of devices in the
building.Also, this kind of architecture facilitates data portability needs.
Effective back-end data sharing architectures allow users to move their data
when they switch between IoT services, breaking down traditional data silo
barriers. The back-end data-sharing mode lsuggests a federated cloud services
approach or cloud applications programmer interfaces (APIs) are needed to
achieveinteroperability of smart device data hosted in the cloud.
IOT communication API
1.
REST-based
Communication APIs
Representational state transfer (REST) is a set of architectural
principles by which you can design Web services the Web APIs that focus on
systems’s resources and how resource states are addressed and transferred. REST
APIs that follow the request response communication model, the rest architectural
constraint apply to the components, connector and data elements, within a
distributed hypermedia system. The rest architectural constraint are as
follows:
Client-server
– The principle behind the
client-server constraint is the separation of concerns. for example, clients
should not be concerned with the storage of data which is concern of the serve.
Similarly, the server should not be concerned about the user interface, which
is concern of the clien. Separation allows client and server to be
independently developed and updated.
Stateless – Each request from client to server
must contain all the information necessary to understand the request, and
cannot take advantage of any stored context on the server. The session state is
kept entirely on the client.
Cache-able – Cache constraints requires that the
data within a response to a request be implicitly or explicitly leveled as
cache-able or non-cache-able. If a response is cache-able, then a client cache
is given the right to reuse that response data for later, equivalent requests.
caching can partially or completely eliminate some instructions and improve
efficiency and scalability.
Layered
system – layered system
constraints, constrains the behavior of components such that each component
cannot see beyond the immediate layer with they are interacting. For example,
the client cannot tell whether it is connected directly to the end server or
two an intermediary along the way. System scalability can be improved by
allowing intermediaries to respond to requests instead of the end server, without the
client having to do anything different.
Uniform
interface – uniform interface
constraints requires that the method of communication between client and server
must be uniform. Resources are identified in the requests (by URIsin web-based
systems) and are themselves is separate from the representations of the
resources data returned to the client. When a client holds a representation of
resources it has all the information required to update or delete the resource
you (provided the client has required permissions). Each message includes
enough information to describe how to process the message.
Code
on demand – Servers can
provide executable code or scripts for clients to execute in their context.
this constraint is the only one that is optional.
A RESTful web service is a ” Web API ” implemented using HTTP
and REST principles. REST is most popular IoT Communication APIs.
2. Web Socket based communication API
Web Socket APIs allow bi-directional,
full duplex communication between clients and servers. Web Socket APIs follow
the exclusive pair communication model. Unlike request-response model such as
REST, the Web Socket APIs allow full duplex communication and do not
require new coonection to be setup for each message to be sent. Web Socket
communication begins with a connection setup request sent by the client to the
server. The request (called web socket handshake) is sent over HTTP and the
server interprets it is an upgrade request. If the server supports web socket
protocol, the server responds to the Web Socket handshake response. After the
connection setup client and server can send data/messages to each other in full
duplex mode. Web socket API reduce the network traffic and letency as there is
no overhead for connection setup and termination requests for each message. Web
socket suitable for IOT applications that have low latency or high throughput
requirements. So Web socket is most suitable IOT Communication APIs for IOT
System.
iot ENABLED TECHNOLOGY
enabling technologies. However, the IoT’s technology road map
is shown in Figure and we will present some general background on the IoT’s
technical landscape to inform our IP strategy discussion (forthcoming).
A. BIG DATA
As more things (or “smart
objects”) are connected to the IoT, more data is collected from them in order
to perform analytics to determine trends and associations that lead to
insights. For example, an oil well equipped with 20-30 sensors can generate
500,000 data points every 15 seconds20, a jetliner with 6,000 sensors generates
2.5 terabytes of data per day, and the more than 46 million smart utility
meters installed in the U.S. generate more than 1 billion data points each
day.Thus, the term “big data” refers to these large data sets that need to be
collected, stored, queried, analyzed and generally managed in order to deliver
on the promise of the IoT — insight!
Further compounding the technical
challenges of big data is the fact that IoT systems must deal with not only the
data collected from smart objects, but also ancillary data that is needed
to properly perform such
analytics (e.g., public and private data sets related to weather, GIS,
financial, seismic, map, GPS, crime, etc.). Thus, as more smart objects come
online, at least three metrics (“the three V’s”) are typically used by IoT
operators to describe the big data they handle: volume (i.e., the amount of
data they collect from their IOT sensors measured in gigabytes, terabytes and
petabytes); velocity (i.e., the speed at which data is collected from the sensors);
and variety (i.e., the di ering types of structured and unstructured data
collected, especially when compared to video and picture files as is typical
within the consumer Internet).
B.
DIGITAL TWIN
Another consequence of the
growing and evolving IOT is the concept of a “digital twin,” introduced in
2003 by John Vickers, manager of NASA’s National Center for Advanced
Manufacturing. The concept refers to a digital copy of a physical asset (i.e.,
a smart object within the IOT), that lives and evolves in a virtual
environment over the physical asset’s lifetime. That is, as the sensors within
the object collect real-time data, a set of models forming the digital twin is
updated with all of the same information. Thus, an inspection of the digital
twin would reveal the same information as a physical inspection of the smart
object itself – albeit remotely. The digital twin of the smart object can then
be studied to not only optimize operations of the smart object through reduced
maintenance costs and downtime, but to improve the next generation of its
design.
C. CLOUD COMPUTING
As the word “cloud” is often used
as a metaphor for the Internet, “cloud computing” refers to being able to
access computing resources via the Internet rather than traditional systems where
computing hardware is physically located on the premises of the user and any
software applications are installed on such local hardware. More formally,
“cloud computing” is defined as:
“[A] model for
enabling ubiquitous, convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with
minimal management e ort or service provider interaction.”
Cloud computing – and its three
service models of Software as a Service (SaaS), Platform as a Service (PaaS)
and Infrastructure as a Service (IaaS) – are important to the IOT because it
allows any user with a browser and an Internet connection to transform smart
object data into actionable intelligence. That is, cloud computing provides
“the virtual infrastructure for utility computing integrating applications,
monitoring devices, storage devices, analytics tools, visualization platforms,
and client delivery… [to] enable businesses and users to access [IoT-enabled]
applications on demand anytime, anyplace and anywhere.”
D. SENSORS
Central to the functionality and
utility of the IoT are sensors embedded in smart objects. Such
sensors are capable of detecting events or changes in a specific quantity
(e.g., pressure), communicating the event or change data to the cloud (directly
or via a gateway) and, in some circumstances, receiving data back from the
cloud (e.g., a control command) or communicating with other smart objects. Since
2012, sensors have generally shrunk in physical size and thus have caused the
IoT market to mature rapidly. More specifically: “Technological improvements
created microscopic scale sensors, leading to the use of technologies like
Microelectro mechanical systems (MEMS). This meant that sensors were now small
enough to be embedded into unique places like clothing or other [smart
objects].”
E. COMMUNICATIONS
With respect to sending and
receiving data, wired and wireless communication technologies have also improved
such that nearly every type of electronic equipment can provide data
connectivity. This has allowed the ever-shrinking sensors embedded in smart
objects to send and receive data over the cloud for collection, storage and
eventual analysis.
The protocols for allowing IoT
sensors to relay data include wireless technologies such as RFID, NFC, Wi-Fi,
Bluetooth, Bluetooth Low Energy (BLE), XBee, ZigBee, Z-Wave, Wireless M-Bus,
SIGFOX and NuelNET, as well as satellite connections and mobile networks using GSM,
GPRS, 3G, LTE, or WiMAX. [27] Wired protocols, useable by stationary smart
objects, include Ethernet, HomePlug, HomePNA, HomeGrid/G.hn and LonWorks, as
well as conventional telephone lines.
F. ANALYTICS SOFTWARE
Within the IoT ecosystem,
Application Service Providers (ASPs) – which may or may not di er from the
companies who sell and service the smart objects – provide software to
companies that can transform “raw” machine (big) data collected from smart
objects into actionable intelligence (or insight). Generally speaking, such
software performs data mining and employs mathematical models and statistical
techniques to provide insight to users. That is, events, trends and patterns
are extracted from big data sets in order to present the software’s end-users
with insightin the form of portfolio analysis, predictions, risk analysis,
automations and corrective, maintenance and optimization recommendations. In
many cases, the ASPs may provide general analytical software or software
targeting specific industries or types of smart objects.
G. EDGE DEVICES
Not shown in our simplistic IoT
ecosystem of ABOVE Figureis exactly how the smart objects embedded with
sensors connect via the Internet to the various service provider systems. The
answer is via “edge devices” – any device such
as a router, routing switch, integrated access device (IAD), multiplexer, or metropolitan area network (MAN) and wide area network (WAN) access device which provides an entry point from the global, public Internet into an ASP’s or other enterprise’s private network.In Industry 4.0, these edge devices are becoming smarter at processing data before such data even reaches an enterprise network’s backbone (i.e., its core devices and cloud data centers). For example, edge devices may translate between di erent network protocols, and provide first-hop security, initial quality of service (QoS) and access/ distribution policy functionality.
as a router, routing switch, integrated access device (IAD), multiplexer, or metropolitan area network (MAN) and wide area network (WAN) access device which provides an entry point from the global, public Internet into an ASP’s or other enterprise’s private network.In Industry 4.0, these edge devices are becoming smarter at processing data before such data even reaches an enterprise network’s backbone (i.e., its core devices and cloud data centers). For example, edge devices may translate between di erent network protocols, and provide first-hop security, initial quality of service (QoS) and access/ distribution policy functionality.