Research ArticleManagement of IoT Sensor Data Using a Fog Computing Node

Gunjae Yoon ,1 Donghwa Choi ,2 Jeongjin Lee ,2 and Hoon Choi 2

1Gurum Networks, Seoul, Republic of Korea2Department of Computer Science & Engineering, Chungnam National University, Daejeon, Republic of Korea

Correspondence should be addressed to Hoon Choi; hc@cnu.ac.kr

Received 14 September 2018; Revised 10 December 2018; Accepted 24 December 2018; Published 19 February 2019

Academic Editor: Grigore Stamatescu

Copyright © 2019 Gunjae Yoon et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

As IoT systems spread, transmissions of all data from various sensing devices to a remote OM (Operation andManagement) serverthrough the Internet can lead to many problems, such as an explosion of network traffic and delayed responses to data. Fogcomputing is a good means of resolving these problems in an IoT system environment. In this paper, a management method forsensor data in a fog computing node is proposed. The monitoring node monitors data from sensor devices using a data patternfrom the OM server, which dynamically generates and updates the pattern. The monitoring node reports only the data beyondthe normal range of the pattern to the OM server rather than sending all data to the OM server. The monitoring node cancontrol the operations of sensor devices remotely according to the requests of the OM server.

1. Introduction

Currently, the Internet of Things (IoT) [1] is used in intelli-gent homes, smart buildings, factory automation systems,intelligent transportation systems, and autonomous carmanagement systems. An IoT system consists of a numberof sensors, actuators, and computing nodes. Generally, theseleaf-node devices do not have enough computing resourcesto supply intelligent services. Therefore, one or more serversmust undertake the processing, storing, and classifying of thedata. Though a server or a cluster of servers is able to processall data generated by leaf-node devices, network problemssuch as traffic explosions or delayed transmissions can occurif the number of IoT systems increases. To alleviate theseproblems, the concept of fog computing [2–5] has beenintroduced. Fog computing does not store massive amountsof data on a large data server; instead, the data is stored nearthe data source. Fog computing has the advantage of mitigat-ing network traffic that is concentrated on the server.

Traditional fog computing nodes simply performedfiltered data transmission using a filtering criterion providedby a human administrator. A smart gateway [6] reduces thecommunication overhead of the core network and reducesthe burden on the cloud. The human administrator of thesmart gateway must change the filtering criterion when

necessary. On the other hand, the system proposed in thispaper automatically establishes and updates the filtering cri-terion without the administrator’s intervention. Adaptivemonitoring (AdaM) [7] refers to a framework that reducesthe volume of generated data as well as the network trafficbetween IoT devices and data management endpoints. AdaMuses both adaptive sampling and adaptive filtering algo-rithms and dynamically adjusts the monitoring intensityand the amount of data disseminated through the networkbased on the current metric evolution. Unlike the monitoringnode proposed in this paper, AdaM runs on an IoT deviceitself. Therefore, it can be applied to IoT nodes with certaintypes of computing hardware. The cognitive IoT gateway[8] is a type of fog node. The cognitive IoT gateway reducesthe network traffic between IoT devices and cloud serversby migrating server applications to the gateway. It uses amachine learning algorithm to determine where to executeIoT applications between a fog node and a cloud server basedon hardware information pertaining to the gateway, such asthe CPU utilization, memory usage, and network bandwidthvalues. The cognitive IoT gateway differs from the proposedmonitoring node in that it deals with the deployment ofapplications. Research from another point of view suggestsa multi-core-based edge server type of architecture toimprove the performance of the edge (fog) computing. An

HindawiJournal of SensorsVolume 2019, Article ID 5107457, 9 pageshttps://doi.org/10.1155/2019/5107457

edge server which corresponds to a fog node is a server withlimited capabilities, though it must handle large amounts ofdata in real time. Another study suggested the use of manycore systems to offer high-performance computing and cach-ing services for these types of limited servers [9]. Usingmany-core systems for each edge server can be costly in asmaller IoT system. An edge-side company storage frame-work was also proposed to store IoT data [10]. Edge serversalso usually have limited resources and small amounts ofstorage. When an edge server lacks a storage space, theedge-side company storage framework shares the storage ofother near-edge servers to avoid long delays when offloadingdata to a cloud server. While the aforementioned study [10]concerns the efficient management of the storage space, thispaper focuses on the data filtering issue.

A better means of reducing network traffic and theserver workloads in an IoT system environment was pro-posed by the authors [11]. The filtering criteria in that studyare automatically generated by the OM server using rawdata from the sensor devices. The functional architectureof the method is described but detailed schemes for the col-lection, management, and transmission of sensor data arenot included.

This paper expands on the earlier work [11] and includesa detailed communication scheme between monitoringnodes and sensor devices, a method for the adaptive genera-tion of data patterns and the monitoring of sensor data, and amethod by which abnormal data are transmitted to an OMserver in an IoT system environment. The implementationof a prototype of an IoT system is undertaken to demonstratethe feasibility of the proposed method and to measure theresponse time of the fog node.

This paper proceeds as follows. Section 2 briefly intro-duces the concept of fog computing and explains the pro-posed operational process of our system. Section 3 describesthe functions of the monitoring node to support the opera-tions presented in Section 2. After the implementation ofthe prototype, the response time measurements and a discus-sion of the traffic reductions which can be expected whenusing this system are presented in Section 4. The concludingremarks are given in Section 5.

2. Fog Computing

2.1. Architecture. Figure 1 shows a typical architecture of afog computing system, which has three hierarchical systems.The monitoring nodes, also known as fog nodes, connect sev-eral IoT systems to the OM server. A monitoring node is aproxy of the OM server, and it manages the IoT system.Sensed data generated by IoT devices are transmitted toand processed by the monitoring node instead of the OMserver. The monitoring node manages received data andreports only abnormal situations which arise to the OMserver. As a result, the network traffic and workload of theOM server are reduced.

2.2. Proposed Operational Process. The aim of this study is toprovide the following operations to the IoT system using themonitoring nodes of fog computing and the OM server. (1)

When a new sensor device is connected to the monitoringnode, the monitoring node recognizes it and reports it tothe OM server in real time. (2) The sensor device transmitsdata to the connected monitoring node. The monitoringnode stores the data received from the sensor device. (3)When the monitoring node receives the data in step (2), italso checks whether a data pattern exists for this device. If adata pattern does not exist, the monitoring node transmitsthe received data to the OM server to generate a data pattern.(4) The OM server acquires the data from the monitoringnode and generates a pattern for this specific sensor device,which is a collection of sets of values and generation timesof data from the device. This pattern informs us of fluctua-tions of normal data values with respect to the time of day.(5) When a pattern is generated with sufficient data, suchas data collected over several hours, the OM server sendsthe data pattern to the monitoring node. These operationscan be called the pattern generation process, and they aredepicted in Figure 2. We assume that an IoT device is con-nected to only one monitoring node. One monitoring nodemay have multiple IoT devices, and one OM server may havemultiple monitoring nodes.

After the data pattern is generated, monitoring opera-tions can take place. (1) Sensor devices transmit data to themonitoring node. The monitoring node stores the receiveddata. (2) The monitoring node also compares the IoT datawith the data patterns. (3) If the value lies within the accept-able deviation range, steps (1) and (2) are repeated. Thisrange may be set by the administrator. For example, a 5%range means that ±5% of the difference between the receiveddata value and the pattern value is accepted as a normal case.(4) If the value is beyond the normal data pattern range, themonitoring node records this in a log file. The monitoringnode takes a proper action to control this, and it also reportsthis abnormal value to the OM server with the correspondingtime information. (5) The OM server recognizing the abnor-mal situation can analyze the data and alert the administratoror may reflect the data when updating the correspondingdata pattern. (6) The server may request the monitoring nodeof the stored data in a specific time interval for operation andmanagement purposes.

The advantages of the proposed method compared toother fog computing mechanisms include the fact that datafiltering is performed on a per-device basis given a data pat-tern for each sensor device. Unlike other mechanisms, ourmethod does not require any human effort to provide data fil-tering criteria (normal data patterns), and data patterns arecreated systematically and provided by the server. The datapatterns can dynamically adapt to appropriate situations;for example, different versions of data patterns can be madewith respect to the time of day or considering seasonal orclimate changes.

3. Management of Sensor Data in aMonitoring Node

For the operations of the previous section, the monitoringnode was designed to have the functions shown in Figure 3.

2 Journal of Sensors

3.1. Data Storage. The sensor devices of an IoT system cangenerate data frequently or periodically. The data storagecomponent stores the data in a compressed form to reducethe storage capacity. When unexpected or abnormal data isreceived, the data storage component must keep logs for sys-tem management and failure tracking.

The data storage component requires an efficient datamanagement scheme to prevent performance degradations.The monitoring node manages data in a block by block man-ner in order to improve the efficiency of data search andtransmission processes. A data set includes data values, iden-tifiers of the device and sensor along with a timestamp to dis-tinguish which IoT device generated the data as shown inFigure 4. The data storage component also responds torequests from the OM server. When the OM server requests

specific data or data generated during a given time interval,this component searches for and retrieves the data from stor-age and sends the data to the server.

3.2. Communication Management. This component trans-mits data from/to IoT devices to/from the OM server. EachIoT system can use different communication protocols, suchas Modbus [12], MQTT [13], or CoAP [14]. IoT systems can-not be accessed by an OM server unless this protocol differ-ence is resolved. By converting legacy communicationprotocols between IoT devices and the monitoring node toa common standard Internet protocol between the monitor-ing nodes and OM servers, the monitoring node can connectdifferent IoT environments and therefore achieve scalability.The Data Distribution Service (DDS) of the OMG (Object

Applicationmanagement

Fogapplication

Fog platform

Securitymanagement

Distributedmanagement Docker engine

Linux

Hardware platform

: Linux native image: Docker image

Datamonitoring

Data storageDevice

connectionmanagement

Communication management

DDS Protocolinterworking

MQTT/CoAP

IoTmonitoring

Figure 3: Functional architecture of the monitoring node.

IoT system AMonitoring

node

Nodata pattern

Data

DataData patterngeneration

Datapattern

IoT system BNew

New Cloud

Pattern APattern B

Save & send

Figure 2: Data pattern generation process.

IoT system

IoT system

Cloud

Monitoringnode

Monitoringnode

IoT system

Figure 1: Fog computing architecture.

3Journal of Sensors

Management Group) [15, 16] can be used as the commonInternet-side protocol.

We explain the communication management componentwith respect to theModbus protocol. TheModbus protocol isa master/slave type communication protocol. The mastersends a request to the slave and waits for a response, andthe slave sends a response to the master (Figure 5). Typically,Modbus includes the Modbus RTU based on serial commu-nication and the Modbus TCP based on socket communica-tion. We used the Modbus TCP in this research.

The Modbus TCP protocol sets up necessary information(e.g., IP address and port number) for socket communicationand attempts to make a connection from the master to theslave using the information.

After a connection is made, the master requests data fromthe slave according to the Modbus frame format shown inFigure 6, and the slave sends a response. Modbus definessix function codes, as shown in Table 1, for requests to theslave from the master.

We set the monitoring node as the master and each IoTdevice as a slave. Figure 7 shows the message exchange dia-gram. The monitoring node requests data from a slave bysending a message with function code 4 to the IoT device,and the IoT device transmits a response matching therequested function code. The data in the reply from the IoTsystem are sent to the data storage component via IPC(Inter-Process Communication).

The communication management component uses DDSto communicate with the OM server. Therefore, the monitor-ing node converts legacy protocols to DDS to send IoT datato the OM server. To support high flexibility in protocol con-versions and adaptations to monitoring data updates, themonitoring node applies DDS-XTYPES, which are extensibletypes for DDS.

DDS represents data in a structure known as a topic.Figure 8 shows the structure of a topic. Topics are composedof a name and a type. A topic name refers to the identificationof data in a DDS domain network. The topic type informa-tion also includes the type name and its data structure. Thetype information must be defined before creating topics.

OMG defined the extensible types for DDS specificationsto make the topic creation and definition processes flexible.Figure 9 shows the topic representations of DDS-XTYPES.DDS-XTYPES specifies how to express the structure andthe attributes of a DDS topic. When DDS undertakes theendpoint discovery process, the participating DomainParti-cipant can forward the structure information, expressed inthe DDS-XTYPES form, of the endpoint discovery messages.

When DDS DomainParticipant receives endpoint discoverymessages including DDS-XTYPES information, the Domain-Participant can understand and use the topic even if the infor-mation of the topic was unknown to the DomainParticipant.

The proposed communication technique can undertakeflexible communication and monitoring using DDS-XTYPES. In order to apply DDS-XTYPES, the monitoringnode must know the type of data transmitted by a legacyprotocol. The monitoring node has IDL (Interface DefinitionLanguage) files representing these data structures, and thenode converts IoT data to a DDS topic using the IDL infor-mation. These IDL files are written by device manufacturersand are downloaded from the OM server. When the IDLinformation or topics are updated, these changes are propa-gated through DDS’s endpoint discovery processes withDDS-XTYPES. Examples of such cases include those whenexisting monitoring information is changed or when newmonitoring information is added by a new sensor node ora monitoring system. Due to these DDS propagation pro-cesses, the monitoring nodes and OM servers can adapt tothese changes during runtime without any modification orcompilation processes.

3.3. IoT Monitoring. This component monitors the connec-tion states and operational states of connected IoT devices.An IoT device may fail or may sometimes be detached. Ifthe communication channel between the device and themonitoring node is unreliable, communication may fail.The monitoring node continuously checks the state of thechannel and the device when possible.

The monitoring node attempts to collect the device infor-mation of each IoT device, such as the manufacturer/modelname, hardware information, address, and other parameters.If this profile information is embedded in the device and ifthe communication protocol between the device and themonitoring node is capable of delivering the profile, themonitoring node can obtain the device information. Forexample, when a new IoT device is plugged into the IoT

Master

Slave

ResponseRequest

Response

Request

Slave

Figure 5: Communication topology of Modbus.

Data storage Data block

: Data block

Device ID Sensor ID Data instance Time

Device ID Sensor ID Data instance Time

Device ID Sensor ID Data instance Time

Device ID Sensor ID Data instance Time

Device ID Sensor ID Data instance Time

Log

Figure 4: Data block structure.

4 Journal of Sensors

system, this component of the monitoring node may auto-matically detect the device type and status. It then reports thisinformation to the OM server in real time.

The device is also controllable through the monitoringnode if necessary. This IoT monitoring component controlsthe IoT device by transferring messages with function code5 and the device ID and sensor ID to the slave, as describedin Figure 6. For example, if the monitoring node recognizesthat the value of a temperature sensor exceeds a certainthreshold after reading the temperature, the monitoring nodeturns on the air conditioner by transmitting the message withthe function code “Write” and changing the registry valuecontrolling the air conditioning power of the IoT device.

3.4. Data Monitoring. This component analyzes the collecteddata. The monitoring node receives the data pattern from theOM server to judge the normality of the received data. Thedata storage component saves the data received from a sen-sor. The values of the received data are then compared withthe data pattern. If the data is not in the normal range, themonitoring node records this in a log file and reports theoccurrence of abnormal data to the OM server. An exampleof such a pattern is given in Table 2.

The OM server generates a data pattern for the monitor-ing node to detect abnormal data from IoT devices. There aremany technologies for generating patterns, but a simpleprimitive method is used as the initial first trial. As shownin Figure 10, the OM server divides 24 hours into 144 sec-tions of ten-minute periods and calculates the average ofthe sensor data values collected from the monitoring nodeduring each time section. The OM server maintains thesequence of the average values as the data pattern for a spe-cific IoT device.

The OM server sends the generated data pattern to themonitoring server by putting in a DDS topic, as shown inFigure 11.

The OM server must update the data pattern to adapt tochange of normal values due to environmental issues, such asseasonality changes. The monitoring node reports to the OM

server when a value beyond the acceptable deviation range isreceived or when data are continuously received from adevice whose values are close to the maximum/minimumrange of the data pattern.

Figure 12 is a diagram showing a data pattern of a sensordevice. Data values within the range of section (a) areregarded as normal; hence, the monitoring node stores thedata in this case without further action. Data values in section(b) are also regarded normal, and the monitoring node storesthe data. In this case, the frequency of data of section (b) isalso counted, and the monitoring node requests an updateof the data pattern if the frequency is high. Because the datain section (c) exceeds the normal range, the monitoring nodetransmits the data to the OM server.

The OM server is able to reconfigure the monitoring ofIoT systems by updating the data patterns of IoT devicesand downloading them onto the monitoring node. The mon-itoring node uses the Docker platform, which allows the nodeto install new software onto the monitoring node. For exam-ple, the monitoring node can download and install a newalgorithm to detect abnormal data from the OM server.

4. Performance Evaluation

We implemented a prototype system to demonstrate thefeasibility of the monitoring node in this study. The middlepart in Figure 13 represents the sensors and an actuator. ADHT-22 temperature-humidity sensor, an IR sensor, anMQ-135 gas sensor, and a small fan are used with Arduino.We used an Apple MacBook Pro 2017 (Intel dual-corei5-7360u, 3.1GHz) for the monitoring node and a Giga-byte AERO (i7-7700HQ, 2.8GHz, Ubuntu 18.04) for theOM server.

Advantages of the proposed monitoring node include thefact that the monitoring node can control IoT devices morequickly than the OM server and the monitoring node canreduce network traffic.

First, we show how quickly the monitoring node con-trols IoT devices. We positioned a heat source near the

<Modbus TCP>MBAP header Function code Data

Transaction ID Protocol ID Length Unit ID

Figure 6: Modbus TCP frame structure.

Table 1: Modbus function code.

Function type Function name Function code

Data access

Bit access

Read discrete inputs 2

Read coils 1

Write single coil 5

16-bit (word) access

Read input register 4

Read holding registers 3

Write single register 6

5Journal of Sensors

temperature-humidity sensor on purpose and measuredthe response time, i.e., the delay from the time the IoTdevice, Arduino, sends the measured high-temperaturevalue to the monitoring node up until the time the Ardu-ino device receives a control message to turn on the fanfrom the monitoring node. The average of 36 measure-ments was found to be 30.220 milliseconds. If the moni-toring node is not used, the sensed value is sent to theremote OM server and the server sends back a controlmessage. The server’s response time will approximate themonitoring node’s response time plus the network round-trip delay. The network delay to the OM server dependson the distance and the number of router hops from theIoT system to the OM server. In this experiment, we used

IoT system (slave 1) IoT system (slave 2) CM (master) Data storage Cloud

Connect (slave1)SYN

SYN,ACK

ACKAccept()

Request (FC = 4, read_address = 0)

Response (FC = 4, data = 25) Send(device ID, sensor ID, data = 25, time)

Save()

Send (result)SYNConnect (slave2)

ACKAccept ()

Request (FC = 4, read_address = 10)

Response (FC = 4, Data = 31)Send (device ID, sensor ID, data = 31, time)

Save ()

Send (result)

DDS publish/subscribe

Close (slave1)ACK of FIN

FIN

FINClose (master)

ACK of FINFIN Close (slave2)

ACK of FIN

Close (master)

ACK of FIN

FIN

SYN,ACK

Figure 7: Modbus connection configuration and information transfer procedure. CM: communication management; FC: function code.

Topic name: foo

Type name: Sensor

struct Sensor{@keylong type_id;

temp;floathum;float

}

Figure 8: DDS type composition.

6 Journal of Sensors

the average roundtrip delay of the North America region,which is 36.737 milliseconds [17].

As shown in Table 3, the response time of the monitoringnode is shorter than that of the cloud server. If we considerthe heavy workload at the server due to the considerable

amount of traffic from many IoT devices, the server’sresponse may become even slower.

We performed a simple evaluation to depict the secondadvantage of the monitoring node. Figure 14 shows theshapes of the network traffic changes. From times 0 to T1,

Typerepresentation

Languagebinding

Datarepresentation

IDL:Sensor.idl

struct Sensor {@key

type_id;longtemp;floathum;float

}

IDL to Language mapping:Sensor.h, Sensor.cSensorTypeSupport.c

type_id;longtemp;floathum;float

struct Sensor {

};

Foo f = {183, 36.4, 0.5};

IDL to CDR:

0000 00B74211 999A3F00 0000

Figure 9: Topic representation of DDS-XTYPES.

Table 2: An example of a data pattern for an IoT device.

Date Time Mean normal value Acceptable deviation

2018-01-01 12:00:00 20.05 5%

2018-01-01 12:00:30 20.05 5%

2018-01-01 12:01:00 21.00 5%

2018-01-01 12:01:30 21.00 5%

: : : :

2018-01-01 00:00:30

2018-01-01 00:01:00

2018-01-01 00:09:30

2018-01-01 00:10:00

24.00

24.50

24.00

23.00

2018-01-01 00:10:30

2018-01-01 00:11:00

2018-01-01 00:19:30

2018-01-01 00:20:00

24.00

24.00

25.00

24.50

Compute the average of20 sensor values

collected during 10 min.

2018-01-01 23:50:30

2018-01-01 23:51:00

2018-01-01 23:59:30

2018-01-01 24:00:00

20.00

21.00

19.50

20.00

Compute the average of20 sensor values

1

2

144

Time Value

Sensor data collectedevery 30 sec.

First 10-min.time section

Second10-min.

time section

144th 10-min.time section

… …

… …

… …

…

Figure 10: 144 sections of data.

7Journal of Sensors

the monitoring node discovers a new sensor device andestablishes a connection with it. Upon reaching time T1,the discovering and connecting processes end. From timesT1 to T2, the monitoring node transmits all of the data tothe OM server on the Internet because the monitoring nodedoes not yet have a data pattern for this device. Therefore,the network traffic reaches its maximum level, and the work-load of the OM server is high. During this period, the OMserver learns and generates a pattern from the received data.At time T2, the OM server completes the generation of thedata pattern and sends it to the monitoring node. At timeT3, the monitoring node receives and installs the data pat-tern, after which it begins to detect an abnormality. Themonitoring node reports only abnormal data to the OMserver after T3.

Network traffic arises in proportion to the assumed errorrate, which is the rate of the occurrence of abnormal datafrom some sensor device. We simulated different error ratesand calculated the corresponding traffic rates. If we assumean error rate of 0.5, half of the received data is normal andis not sent to the OM server after T3. With an error rate of0.2, we do not need to send 80% of the data to the OM server.Therefore, the proposed method can decrease the networktraffic considerably. In a typical IoT system without a moni-toring node, all of the sensor data are directly sent to the OMserver; the network traffic ratio will always be 1 after T1.

The values of traffic rates during 0~T1 and T2~T3 wereset to certain intermediate values simply to show a gradualincrease/decrease during these transient time spans. The pur-pose of this graph is to show the differences in the traffic ratesduring the T1~T2 time span and the time span after T3.

5. Conclusion

The purpose of the monitoring node in this paper is to con-trol IoT devices quickly and to reduce network traffic andthe server’s workload in the IoT system environment. Themonitoring of the normality of data from each sensordevice is based on the corresponding data pattern providedby the OM server. The monitoring node with the data pat-terns reports only the data outside of the normal data rangeto the OM server rather than sending all the data to theOM server.

Topic name: Data pattern

Type name: Temperature Sensor

Struct Sensor{long Device_id;long Sensor_id;float temp[144];

}

Figure 11: Topic for a data pattern.

0 24 hours

Representative value

Representative value +3%Representative value +5% a

b

c

c

b

Value

Representative value −3%Representative value −5%

a

Figure 12: Comparison of received data with the data pattern.

Figure 13: A prototype implementation of a monitoring node andan IoT system.

Error rate (0.5)Error rate (0.4)Error rate (0.3)

Error rate (0.2)Error rate (0.1)

1.2

1.0

0.8

0.6

0.4

0.2

0.0T1 T3

Time

Net

wor

k tra

ffic r

atio

T2

Figure 14: Network traffic reduction over time.

Table 3: Comparison of response times (unit: ms).

Average response time of themonitoring node

30.220

Average response time of thecloud server

30 220 + 36 737 = 66 957

8 Journal of Sensors

Generating a proper data pattern is an important subject.The OM server adaptively generates data patterns and pro-vides them to the monitoring nodes for each sensor device.Data patterns should be generated from a large set of datacollected by each sensor device. Though we described a sim-ple method of pattern generation, we can improve it further.It can be replaced by another method, such as one based on adeep learning technique.

Other future research subjects may include a quickmethod to detect abnormal sensor values at the monitoringnode. The capability of the monitoring node can be furtherextended to search and download the profile information ofIoT devices from an external server such as the OM serveror the manufacturer’s server. Performance evaluations ofthe fog computing with IoT systems on a larger scale arealso challenging.

Data Availability

The data used to support the findings of this study areavailable from the corresponding author upon request.

Disclosure

The funding sponsors had no role in the design of the study,in the collection, analyses, or interpretation of the data, inthe writing of the manuscript, and in the decision to publishthe results.

Conflicts of Interest

The authors declare no conflict of interest.

Authors’ Contributions

G. Yoon and D. Choi equally contributed to this work.

Acknowledgments

This work was supported by the National Research Founda-tion of Korea grant funded by the Korean government, MSIT(No. NRF-2017R1D1A1B03029262). D. Choi was partlysupported by Korea Electric Power Corporation (Grantnumber: R18XA05).

References

[1] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internetof things (IoT): a vision, architectural elements, and futuredirections,” Future Generation Computer Systems, vol. 29,no. 7, pp. 1645–1660, 2013.

[2] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computingand its role in the Internet of things,” in Proceedings of the firstedition of the MCC workshop on Mobile cloud computing,ACM, pp. 13–16, Helsinki, Finland, 2012.

[3] K. Toczé and S. Nadjm-Tehrani, “A taxonomy for manage-ment and optimization of multiple resources in edge comput-ing,” Wireless Communications and Mobile Computing,vol. 2018, Article ID 7476201, 23 pages, 2018.

[4] M. Iorga, L. Feldman, R. Barton, M. J. Martin, N. S. Goren, andC. Mahmoudi, “Fog computing conceptual model,” Tech. Rep.

500-325, NIST (National Institute of Standards and Technol-ogy), 2018, November 2018, https://www.nist.gov/publications/fog-computing-conceptual-model.

[5] A. Paul, H. Pinjari, W.-H. Hong, H. C. Seo, and S. Rho, “Fogcomputing-based IoT for health monitoring system,” Journalof Sensors, vol. 2018, Article ID 1386470, 7 pages, 2018.

[6] M. Aazam and E.-N. Huh, “Fog computing and smart gatewaybased communication for cloud of things,” in Future Internetof Things and Cloud (FiCloud), 2014 International Conference,pp. 464–470, Barcelona, Spain, 2014.

[7] D. Trihinas, G. Pallis, and M. D. Dikaiakos, “AdaM: an adap-tive monitoring framework for sampling and filtering on IoTdevices,” in 2015 IEEE International Conference on Big Data(Big Data), pp. 717–726, Santa Clara, CA, USA, 2015.

[8] F. Jalali, O. J. Smith, T. Lynar, and F. Suits, “Cognitive IoTgateways: automatic task sharing and switching betweencloud and edge/fog computing,” in SIGCOMM Posters andDemos '17 Proceedings of the SIGCOMM Posters and Demos,pp. 121–123, Los Angeles, CA, USA, 2017.

[9] S.-J. C. Ramneek, S. H. Jeon, Y. J. Jeong, J. M. Kim, S. Jung, andS. Pack, “Boosting edge computing performance throughheterogeneous manycore systems,” in 2018 International Con-ference on Information and Communication Technology Con-vergence (ICTC), pp. 922–924, Jeju, South Korea, 2018.

[10] Y. Li, J. Luo, J. Jin, R. Xiong, and F. Dong, “An effective modelfor edge-side collaborative storage in data-intensive edge com-puting,” in 2018 IEEE 22nd International Conference on Com-puter Supported Cooperative Work in Design ((CSCWD)),pp. 92–97, Nanjing, China, 2018.

[11] J. Lee, G. Yoon, and H. Choi, “Monitoring of IoT data forreducing network traffic,” in 2018 Tenth International Confer-ence on Ubiquitous and Future Networks (ICUFN), pp. 395–397, Prague, Czech Republic, 2018.

[12] Modicon, Inc., “Modicon Modbus Protocol Reference Guide,PI-MBUS-300 Rev. J,” 1996, http://modbus.org/docs/PI_MBUS_300.pdf.

[13] S.-J. Kim, K.-W. Cho, M.-E. Lee, and O. Chang-Heon, “Astudy on adaptive QoS control system based on MQTT forreducing network traffic,” International Conference on FutureInformation & Communication Engineering, vol. 9, no. 1,pp. 223–226, 2017.

[14] Z. Shelby, K. Hartke, and C. Bormann, The ConstrainedApplication Protocol (CoAP), Internet Engineering Task Force(IETF), 2014.

[15] Object Management Group (OMG), Data Distribution Servicefor Real-Time Systems, Version 1.2, Object ManagementGroup (OMG), 2007.

[16] Object Management Group (OMG), The Real-timePublish-Subscribe Wire Protocol DDS Interoperability WireProtocol, Version 2.1, Object Management Group (OMG),2009.

[17] Verizon Digital Media Services, Inc, IP Latency Statistics,December 2018, https://enterprise.verizon.com/terms/latency/.

9Journal of Sensors

International Journal of

AerospaceEngineeringHindawiwww.hindawi.com Volume 2018

RoboticsJournal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Shock and Vibration

Hindawiwww.hindawi.com Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwww.hindawi.com

Volume 2018

Hindawi Publishing Corporation http://www.hindawi.com Volume 2013Hindawiwww.hindawi.com

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwww.hindawi.com Volume 2018

International Journal of

RotatingMachinery

Hindawiwww.hindawi.com Volume 2018

Modelling &Simulationin EngineeringHindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Navigation and Observation

International Journal of

Hindawi

www.hindawi.com Volume 2018

Advances in

Multimedia

Submit your manuscripts atwww.hindawi.com