IOT Communication model and IOT communication API | Brothersstudyzone

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.