Emulation of IoT Gateway for Connecting Sensor Nodes ... - IEEE Xplore

IEEE International Conference on Computer, Communication, and Signal Processing (ICCCSP-2017)

Emulation of IoT Gateway for Connecting Sensor Nodes in Heterogenous Networks Kanchana Rajaram

Susanth G

Department of Computer Science and Engineering SSN College of Engineering Anna University, Chennai – 603110 Email: [email protected]

Department of Computer Science and Engineering SSN College of Engineering Anna University, Chennai – 603110 Email: [email protected]

Abstract—An Internet of Things (IoT) are ’things’ that com-municate in different networks. An IoT gateway which provides device connectivity and protocol translation is often expensive in case of small scale academic projects. In view of this, an Emulated IoT gateway is proposed that emulates the IoT gateway using a local computer in a cost effective way. The sensor data sent from sensor nodes connected in cellular network (GPRS), WiFi, RF, Bluetooth or in LAN using Ethernet are collected and successfully processed in cloud server.

various use cases comprising of different communication networks. Li et al. [1] illustrated how IoT services are typically delivered as physically isolated vertical solutions. As a PaaS service these vertical solutions were provided virtually as an IoT service delivery model by using a domain mediator as controller for applications. Though this work involves collecting a large amount of data, the method of collecting data is not addressed. Luigi et al. [2] discussed different IoT enabling technologies to sense and identify data communicated through RF or Wireless sensor networks. The advantages and disadvantages of these technologies alone are identified and the method for communication is not discussed.

Keywords — IoT, gateway, Wifi, RF, Bluetooth, LAN, cellular network, sensor

I. INTRODUCTION Internet of Things (IoT) is ’things’ with sensors that are programmed manually to automate certain functions such as send and receive data periodically. Gateways are devices that collect data from multiple sensor nodes each enabled with a different communication protocol and provide it to an end point server which may be in local or cloud. The proposed Emulated IoT (EmI) gateway involves providing a method to allow collecting data from sensor nodes connected in different communication networks, process the data and log them into a local or cloud server. Data communicated using different protocols such as TCP in WiFi, Ethernet, or Cellular network (GPRS) and Serial communication in RF or Bluetooth are collected and logged in cloud storage. The rest of this paper is organized as follows: Section II surveys the existing literatures and Section III illustrates the proposed IoT framework and the approach for emulating IoT gateway. Section IV describes a motivating scenario for this proposed work and Section V explains the tested results of the proposed work. Section VI concludes the work and points out future directions. II. LITERATURE SURVEY This section surveys various works related with communication between sensor nodes in realising IoT. SmartSantander [4], an IoT solution over a Smart City Test bed deployed in Santander city, involves experimentation architecture of IoT. This work illustrates

978-1-5090-3716-2/17/$31.00 ©2017 IEEE

PatRICIA [5], a Novel Programming Model for IoT Applications on Cloud Platforms provides an end-to-end solution for cloud scale IoT applications. INOX [6], a Managed Service Platform for Inter-Connected Smart Objects provides a robust platform for IoT application deployment. Both these works do not address communicating sensor data over multiple networks. Uddin et al. [9] proposed a multi-network architecture, SCALE2 that uses various types of networking technologies in order to facilitate communications among sensor devices. Zhu et al. [7] proposed an IoT gateway for bridging wireless sensor networks into IoT. This work connects low range WSN to a remote server with another communication protocol using gateway which is a hardware device. Vogler et al. [3] proposed a framework for dynamically generating optimized deployment topologies for IoT cloud applications. A flexible provisioning of application components on cloud infrastructure and IoT gateways was realised, using a declarative constraint-based model. LEONORE [8], a provisioning network for resourceconstrained IoT deployments involves application packages and IoT gateways. LEONORE can install and uninstall application packages in edge devices through the gateways. All the above works make use of IoT gateways which are expensive hardware devices. III. PROPOSED WORK The methods employed by the proposed EmI gateway for emulating the functions of an IoT gateway using a local computer are described in this section. A sensor node

IEEE International Conference on Computer, Communication, and Signal Processing (ICCCSP-2017) includes a controller that receives data from an array of sensors and sends through a communication network, receives external commands to operate a RELAY switch, and a communication transceiver. Each sensor node is enabled with different communication modes such as WiFi, Ethernet, GPRS, RF and Bluetooth. These sensor nodes are able to send data to another configured point which could be the EmI gateway. The EmI gateway which is emulated in the local computer receives sensor data in one of these communication modes and sends to a cloud server via internet using WiFi or GPRS transceiver. If the sensor node is enabled with GPRS connectivity, it can directly send and receive data to or from the cloud server via cellular network. However, when the sensor node is enabled with other communication modes the proposed EmI gateway performs the required protocol conversion to communicate the data to the cloud server via the internet. The methods for protocol conversion are presented below. A. Setting up communication between sensor node with Eth-ernet connectivity and cloud server The sensor node is connected to EmI gateway via Ethernet as shown in Figure 1. The gateway is enabled with internet.

Fig. 2. Sensor node to cloud server connectivity through WiFi

•

A WiFi hotpot server is enabled in EmI gateway A TCP listener was made to run in EmI gateway

•

Sensor Node is configured with the IP address and port number of EmI gateway

•

Inputs from sensors and outputs to RELAYs are communicated via WiFi

C. Setting up communication between sensor node with Blue-tooth connectivity and cloud server The sensor node is connected to EmI gateway via Bluetooth as shown in Figure 3. The EmI gateway is enabled with internet. The steps for communicating from or to the sensor node via Bluetooth transceiver are given below:

Fig. 3. Sensor node to Cloud Server connectivity through Bluetooth

•

The Bluetooth transceivers of sensor node as well as EmI gateway are paired.

Fig. 1. Sensor node to Cloud Server connectivity through Ethernet

•

A COM port listener is made to run in the EmI gateway.

The steps for communicating from or to the sensor node via Ethernet connectivity are given below:

•

A TCP listener was made to run in EmI gateway

The COM port is configured with suitable values for parameters such as FlowControl, BaudRate and PARITY

•

Sensor Node is configured with the IP address and port number of EmI gateway

Sensor data is received by the COM port listener and forwarded to cloud server via internet

•

RELAY commands were also sent from cloud server to the sensor node

• • •

Inputs from sensors and outputs to RELAYs are communicated via Ethernet

B. Setting up communication between sensor node with WiFi connectivity and cloud server The sensor node is connected to EmI gateway via WiFi network as shown in Figure 2. The EmI gateway is enabled with internet. The steps for communicating sensor data from or to the sensor node through WiFi connectivity are given below:

D. Setting up communication between sensor node with RF connectivity and cloud server The sensor node is connected to EmI gateway via RF network as shown in Figure 4. The EmI gateway is enabled with internet.

Fig. 4. Sensor node to Cloud Server connectivity through RF

The steps for communicating sensor data from or to the sensor node through RF connectivity are given below:

978-1-5090-3716-2/17/$31.00 ©2017 IEEE

IEEE International Conference on Computer, Communication, and Signal Processing (ICCCSP-2017) •

Both the transceivers in EmI gateway and sensor node are made active.

•

A COM port listener is made to run in the EmI gateway

•

The COM port is configured with suitable values for parameters such as FlowControl, BaudRate and PARITY

•

Sensor data is received by the COM port listener and forwarded to the cloud server via internet

•

RELAY commands were also sent from cloud server to the sensor node via EmI gateway

The test bed consists of five pumping stations, each with a sensor node enabled with GPRS, WiFi, ETHERNET, RF or Bluetooth connectivity. The sensor nodes are connected with four float sensors and an output RELAY switch. They are configured to send sensor data every 20 seconds. From each pumping station, the sensor nodes send data as a string consisting of 3 parts " < sensornodeID >< space >< OVRLD or O >< space >< waterlevel > ". Let us assume the following IDs and priorities shown in Table 1, are assigned to different sensor nodes. Table 1. ID and Priority of Sensor Nodes Sensor Node

IV. MOTIVATING EXAMPLE The Sewerage system in a residential complex or an institution consists of a set pf pumping stations with a sewage sump and a pump motor that pumps collected sewage to the Sewage Treatment Plant (STP). The sewage transport from different pumping stations must be scheduled based on the sewage level and pumping station priority in order to prevent sump overflows. The priority is configured for each pumping station based on amount of sewage inflow. In this application, sewage sumps in each pumping station has an array of float sensors which are connected to a sensor node. The sensor node requires to communicate the collected sensor data to the cloud server. Since the pumping stations are spread across the campus, a single communication network is not accessible or adequate to provide internet connectivity to all the sensor nodes. Hence, the sensors nodes are enabled with different communication modes based on the availability of network.

Communication Mode

Priority

1

GPRS

Medium

2

RF

High

3

WiFi

Low

4

ETHERNET

Low

5

BLUETOOTH

High

ID

Depending on the sewage level data (1-LoLo, 2-LoHi, 3HiLo, 4-HiHi) received, the scheduler sends ON or OFF commands to the RELAYs in the sensor node. If the sewage levels are same in different sumps, then the scheduler considers pumping station priority for scheduling. The RELAY commands sent by the scheduler are ”OK”,”RELAY00T” and ”RELAY10T”.

V. TESTING AND RESULTS

•

OK - Indicates that the sensor data is received

The proposed EmI gateway is tested for its functionality in the sewage flow scheduling application. This IoT enabled application is realised using the test bed depicted in Figure 5.

•

RELAY00T - To Switch OFF the Relay in the corresponding sensor node

•

RELAY10T - To switch ON the Relay in the corresponding sensor node

The sewage flow scheduler service is deployed and run in Amazon’s AWS cloud server as depicted in Figure 6. In the EmI gateway, TCP listener as shown in snapshot of Figure 7 and COM port listener as shown in Figure 8 are implemented using Java. Two classes such as READER class and WRITER class that run in different threads are created to provide a two way communication without interruptions. READER class reads data from sensor node and sends to cloud server. WRITER class receives RELAY command from cloud server and sends to sensor nodes. The external packages such as RXTX and JSSC are used for serial port connectivity.

Fig. 5. Test Bed for IoT Based Sewage Flow Scheduling

978-1-5090-3716-2/17/$31.00 ©2017 IEEE


Fig. 6. Sewage Flow Scheduler Running in AWS Cloud Server

Fig. 7. WIFI Sensor Node Connected to Cloud Server

Fig. 8. RF Sensor Node Connected to Cloud Server

Fig. 9. Data Received by Cloud Server from Sensor Nodes

The sewage transport scheduling process inspects collected sensor data as shown in snapshot of Figure 9 from all the pumping stations and determines which pump RELAY must be operated. Let us assume that the sewage sumps in pumping stations with IDs 1 and 2 are same. In this scenario, the scheduler switches the pump RELAY with the higher priority which is pumping station with ID 2. The command for RELAY in pumping station (ID 2) is sent from the scheduler as depicted in the snapshot of Figure 10 and received by the EmI gateway, shown in Figure 11. Subsequently, the RELAY in sensor node (ID 2) is switched ON. When the sewage level is reduced, the scheduler switches OFF the RELAY and the respective command is received by the EmI gateway as shown in Figure 12.

978-1-5090-3716-2/17/$31.00 ©2017 IEEE

Fig. 10. Sewage Flow Scheduler sends ON Command to RELAY 2


[2]

[3]

[4]

[5]

Fig. 11. EmI Gateway Receives ON Command for RELAY 2

[6]

[7]

[8]

[9]

Fig. 12. EmI Gateway Receives OFF Command for RELAY 2

VI. CONCLUSION Gateways are not affordable in case of simple IoT lab experimentations. In this paper, a method is provided to emulate the functionality of an IoT gateway using a local computer instead of a separate hardware. The proposed EmI gateway is successfully tested to provide communication between sensor nodes in heterogeneous networks such as GPRS, WiFi, Ethernet, RF, and Bluetooth and Amazon’s cloud server. The EmI gateway is used in the IoT based application of sewage flow scheduling which involves sensor nodes connected in different communication networks. It is observed that the proposed EmI gateway is a cost effective solution for most of the IoT related small scale academic projects. Its scalability requires to be explored further. REFERENCES [1]

Fei Li, Michael Vogler, Markus Claeens, and Schahram Dustdar, Efficient and scalable IoT service delivery on Cloud, In Procs. of

978-1-5090-3716-2/17/$31.00 ©2017 IEEE

IEEE Sixth International Conference on Cloud Computing, Santa Clara, CA. IEEE, July. 2013, pp. 740 - 747. Luigi Atzori , Antonio Iera , Giacomo Morabito, The Internet of Things: A survey, Computer Networks, Vol. 54, No. 15, Elsevier, June.2010, pp. 2787 - 2805. Michael Vogler, Johannes M. Schleicher, Christian Inzinger, and Schahram Dustdar, DIANE Dynamic IoT Application Deployment, In Procs. of IEEE International Conference on Mobile Services, New York. July.2015, pp. 298 - 305. Luis Sanchez, Luis Muoz, Jose Antonio Galache, Pablo Sotres, Juan R. Santana, Veronica Gutierrez, Rajiv Ramdhany, Alex Gluhak, Srdjan Krco, Evangelos Theodoridis, Dennis Pfisterer, SmartSantander: IoT experimentation over a smart city testbed, in Computer Networks, Vol. 61, Elsevier, March 2014, pp. 217 - 238. Stefan Nastic, Sanjin Sehic, Michael Vogler, Hong-Linh Truong, and Schahram Dustdar, PatRICIA a Novel Programming Model for IoT Applications on Cloud Platforms, In Procs. of IEEE 6th International Conference on Service-Oriented Computing and Applications, Koloa, HI. IEEE, December 2013, pp. 53-60. Stuart Clayman, Alex Galis, INOX: A Managed Service Platform for Inter-Connected Smart Objects, In Procs. of ACM workshop on Internet of Things and Service Platforms (IoTSP), October, 2011, Tokyo, Japan, pp. 1-8. Qian Zhu, Ruicong Wang, Qi Chen, Yan Liu and Weijun Qiny, IOT Gate-way: Bridging Wireless Sensor Networks into Internet of Things, In Procs. of IEEE/IFIP Eighth International Conference on Embedded and Ubiquitous Computing, Hong Kong. IEEE, December. 2010, pp. 347 - 352. Michael Vogler, Johannes M. Schleicher, Christian Inzinger, Stefan Nastic, Sanjin Sehic and Schahram Dustdar, LEONORE - LargeScale Provisioning of Resource-Constrained IoT Deployments, In Procs. of IEEE Symposium on Service-Oriented System Engineering, San Francisco Bay, CA. IEEE, April.2015, pp. 78 - 87. M. Y. S. Uddin et al., The Scale2 Multi-Network Architecture for IoT-Based Resilient Communities, In Procs. of IEEE International Conference on Smart Computing (SMARTCOMP), St. Louis, MO, 2016, pp. 1 - 8.