journal of la internet of everything: a large-scale...

2332-7766 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TMSCS.2017.2705683, IEEETransactions on Multi-Scale Computing Systems

JOURNAL OF LATEX CLASS FILES, VOL. 6, NO. 1, JANUARY 2007 1

Internet of Everything: A large-scale autonomicIoT gateway

Byungseok Kang, Daecheon Kim and Hyunseung Choo, Member, IEEE

Abstract—Gateways are emerging as a key element of bringing legacy and next generation devices to the Internet of Things (IoT).They integrate protocols for networking, help manage storage and edge analytics on the data, and facilitate data flow securely betweenedge devices and the cloud. Current IoT gateways solve the communication gap between field control/sensor nodes and customercloud, enabling field data to be harnessed for manufacturing process optimization, remote management, and preventive maintenance.However, these gateways do not support fully-automatic configuration of newly added IoT devices. In this paper, we proposed a self-configurable gateway featuring real time detection and configuration of smart things over the wireless networks. This novel gateway’smain features are: dynamic discovery of home IoT device(s), automatic updates of hardware changes, connection management ofsmart things connected over AllJoyn. We use the ’option’ field for automatic configuration of IoT devices rather than modify standardformat of CoAP protocol. Proposed gateway functionality has been validated over the large-scale IoT testbed.

Index Terms—IoT, IoT gateway, Self-configuration, large scale IoT

F

1 INTRODUCTION

INTERNET of Things (IoT) is a new paradigm builtup with a continuum of uniquely addressable things

which is able to communicate with each other through aInternet, with the bolster of approaches and protocolssuch as pervasive computing, ubiquitous computing,sensing technology, Constrained Application Protocol(CoAP) [1], IPV6 and other protocols. It is a system thatbridges physical and cyber world is formed to enablesymbiotic communication seamlessly between the twoparties [2]. It means that, IoT gives a vision where a largenetwork of uniquely identified smart things with differ-ent end devices such as sensors and actuators connectedat any-time, any-place, any-thing, working together toprovide variety of services on demand to the customers[3], [4].

An autonomic networking [5], [6] is the network thathas the capabilities of being self-defining, self-healing,self-configuring, self-optimizing, etc. Started by IBM in2001, this initiative ultimately aims to develop networksystems capable of self-management, to overcome therapidly growing complexity of network systems man-agement, and to reduce the barrier that complexity posesto further growth [7], [8]. The network makes decisionson its own, using high-level policies; it will constantlycheck and optimize its status and automatically adaptitself to changing network conditions. An autonomicnetworking framework is composed of autonomic com-ponents (AC) interacting with each other. An AC canbe modeled in terms of two main control loops (localand global) with sensors (for self-monitoring), effectors

• The authors are with the Dept. of Computer Science and Engineering,Sungkyunkwan University, Suwon, Korea, 440-746.E-mail: {byungseok, daecheon, choo}@skku.edu

(for self-adjustment), knowledge and planner/adapterfor exploiting policies based on self- and network en-vironment awareness [9], [10].

The huge number and large-scale devices mandatethe use of gateways for Internet services. There arevarious kinds of access technologies for this gatewaydesign. While 4G/LTE could be a good solution formany applications, it suffers from increasing packetcollisions with increasing amounts of downlink access.Furthermore, traditional cellular network is also not suit-able for quality of service (QoS) support and consumesa fair amount of power [11], [12]. As the proprietaryand unlicensed solutions are not optimized for spectralefficiency, with exponential increase in IoT deployment,these solutions are very likely to congest the unlicensedbands and trigger complaints from existing customers.At the same time, a variety of new wide area applications(e.g. smart cities, traffic monitoring, and smart grids) forIoT are offering new markets to wireless operators forenhancing their revenues. As a result, the Third Gener-ation Partnership Project (3GPP) has recently decided toinclude narrowband IoT (NB-IoT) in Release more than10 standards [13].

With this context, large-scale IoT gateway is one ofthe challenges in IoT industry. However, current IoTgateways operate with passive or semi-automatic modes.[14], [15] In other words, when the customer buys a newIoT device, they manually install the device based onthe setup manual. Moreover, IoT gateway asks the userwhether to register a new device or not. To counter theselimitations, in this paper, we propose a self-configurableIoT gateway for the large-scale IoT environment. Whenthe users bring a new IoT device into existing wire-less networks, IoT gateway automatically detects andregisters it. If the user throws out old devices fromtheir place, proposed IoT gateway automatically delete




Fig. 1. General feature of IoT gateway.

that device form the device list (database). Proposedsystem saves user from trouble of registering, installing,and managing smart devices. The state-of-the-art AllJoynframework provides convenient user interface withoutmodifying standard source codes. To validate proposedgateway, we developed large-scale IoT experimentaltestbed and measured several QoS factors. The remain-der of this paper is organized as follows. Related workon IoT gateway and platform technologies is presentedin Section 2, Section 3 describes our proposed IoT gate-way, experimental testbed development and experimen-tal results are provided in Section 4, Section 5 describeconclusions and future work.

2 RELATED WORK

IoT gateway supports a variety of communication proto-cols and data types between various sensors, which canrealize the conversion of data format which communi-cated between varieties of sensors to unify the uploadeddata formats. At the same time, the acquisition or controlcommand which reach at the perception network aremapped to produce messages that meet specific devicecommunication protocol. In this section, we discuss themost known contributions in the literature.

The goal of IoT gateway is to bridge various sensingdomain networks with public communication networksor Internet, settle with the heterogeneity between thesevarious networks, strengthen the management of bothIoT gateway itself and terminal nodes. We mainly clas-sify the IoT gateways into three types: passive, semi-automatic, and fully-automatic. The proposed gatewaybelongs to fully-automatic IoT gateway (see Figure 2).

2.1 Passive gatewaysPassive gateways require manual settings for the newIoT devices. The users or IoT engineers have to manu-ally add new devices and remove old devices. In [16],authors introduced a generic gateway-based framework

for WSN-IP network interconnection. Their frameworkallow access to individual sensor nodes and enablesnetwork-based query for data-centric WSN. In addition,they provided transparent access from one network tothe other without modifying protocols running in ei-ther network. Work [21] proposed IoT Gateway systembased on Zigbee and generalized radio packet service(GPRS) protocols according to the typical IoT applicationscenarios and requirements from telecom operators. Itpresented the data transmission between wireless sensornetworks and mobile communication networks. How-ever, those two gateways are not flexible, because theycannot be customized for different applications.

In [17], authors proposed a generic sensor networkplatform (SwissQM/SwissGate) that provided a highlevel interface for programming sensor networks andalso presented a multi-tier architecture for efficientlyhandling and optimizing the operation of the network.Research [18] introduced a smart gateway for specifickinds of IoT applications. The gateway has full knowl-edge and control both over the sensor network andthe Internet. They can act as performance-enhancingproxies and intelligent caches to preserve the limitedresources of the sensor network. Authors [22], proposedsensor network middleware that can translate senseddata from sensor networks using extended markup lan-guage(XML) and provide translated data for variousWeb applications. However, most tasks are completed bydifferent network-dependent sensing servers not a smartgateway. It is observed that the required hardware costwill become too high.

2.2 Semi-automatic gateways

Semi-automatic gateways generate a connection link be-tween new device and gateway. However, they cannotsupport automatic link for device attributes (or func-tions). For instance, when a user buys a new TV inliving room, the gateway creates a connection link toTV itself not its attribute. It means that the user cannotswitch the TV channel and adjust volume. Authors[19], designed a plug-configurable-play service-orientedgateway. It was aimed at making fast and easy to employvarious external sensor network applications. Work of[23] proposed IoT gateway with multi-channel RS485. Itensures the real-time performance and reliability for IoTwhile transferring data between the application and theunderlying layer. It resulted in improving the organi-zation and management efficiency of endpoint devicesand solving the problems of data transmission amongdifferent protocols. However, the gateway is running onPC which demands for higher hardware environment.Thus, the advantages in the actual IoT applications arenot obvious.

In [15], authors proposed a novel configurable smartIoT gateway. This gateway has plug-able architecture,whose modules with different communication protocolscan be customized and plugged in according to different




IoT gateways

Passive

Emara[16] Mueller[17] Bimschas[18] ...

Semi-automatic

Wu[19] Guoqiang[15] Chang[20] ...

Fully-automatic

Proposed gateway

Fig. 2. Classification of IoT gateways.

networks. In addition, the gateway has unified externalinterfaces in accordance with flexible software develop-ment. Work [20], presented a multi-interface gateway.It can be used in specific smart spaces to automati-cally control traditional TV, air conditioner, smart me-ter, sphygmomanometer, and smart phone. The workof [24] supported heterogeneous sensor networks andaccess networks. moreover, it can support different typesof sensor nodes and access methods, and can providea unified data format for middleware or applications.However, all above work do not support autonomicattribute generation of new devices.

3 LARGE-SCALE AUTONOMIC IOT GATEWAY

To support full automatic IoT device registration andsolve the heterogeneous network transmission problems,this paper aimed at designing and implementing a self-configurable gateway. It plays the role of analyzer ofdifferent type of IoT devices. The designed gateway isable to communicate with a variety of smart objectsusing 3G/4G, LTE, Wi-Fi, ZigBee, Bluetooth and IrDAstandards. This section provides an overview of thelarge-scale IoT testbed, introducing its key design con-siderations and the real testbed.

3.1 Design considerations

The gateway is a key component of every IoT solution.As we mentioned in Section 1, our main objective wasto build an experimental facility that allows large-scaleexperimentation with heterogeneous IoT technologiesdeployed in a real-world setting, where real-world dataand feedback can be obtained from users and their envi-ronment under realistic experimental conditions. Whileour final ambition is to cover both indoor and outdoorenvironments on our research center (see Figure 3).

In addition to this, the testbed infrastructure shouldsupport autonomic registration, installation, and experi-mentation cycles for the different envisioned IoT tech-niques, smart objects and allow for the evaluation ofthose in an interdisciplinary context. We chose to im-plement the facility as a living lab in our research centercalled ICT convergence research center, where each em-ployee can become part of the experiment during his orher daily activities. In order to increase the flexibility ofthe testbed to cater for demands of diverse experiments,we deployed in each room a mix of heterogeneous IoT

devices, implementing a wide range of sensing modali-ties and common communication interfaces. This infras-tructure is complemented with mobile experimentationnodes that can be carried around by end users andfixed interaction displays in the infrastructure providingadditional means for the communications.

3.2 ArchitectureFigure 4 provides an overview of the IoT architecture ofour testbed. Three main devices can be identified: i) aServer system that hosts all the back-end functionalitiesof the testbed and provides the entry point for an exper-imenter to access the testbed, ii) an embedded Gateway(GW) tier which forms the testbed infrastructure andallows the iii) IoT tier to be connected and reachable toa backbone network through 4G/LTE or WiFi. Althoughall the devices can be involved in each experimentationphase, the IoT device represents the user-centric com-ponent of our testbed, merging embedded IoT nodeswith sensing capabilities together with higher-end user-centric devices such as Smartphones and Smart Displays.Each IoT node provides two forms of connectivity: i)wireless communication capabilities (IEEE 802.15.4, andthrough the GW devices WiFi and Bluetooth) that canbe exploited during an experiment in order to form dif-ferent kinds of networks, ii) a wired USB connection toa dedicated GW for management purposes. Differently,Smartphones and Smart Displays are connected onlythrough wireless links (Bluetooth or WiFi) either throughGWs or directly to the backbone network.

The typical architecture of IoT gateway is usually farmore complex than the architecture of most enterprisesystems. One of the main factors that increases the com-plexity of IoT systems is that backend services residingin the data center, which is the heart of most enterprisesystems, are actually just a piece of the bigger IoT pic-ture. With IoT gateway, we have to deal with a myriad ofdevices working in the field. Because the nature of thesedevices is very different from web, desktop, or evenmobile clients, we need an intermediate architecturalelement that will act as a proxy between the world offield devices and the enterprise data center.

For the IoT network testbed development, we use aAllJoyn framework [25]. The AllJoyn framework runson the local network. It enables devices and apps toadvertise and discover each other. This section explainsthe network architecture and the relationship between




Fig. 3. Large-scale IoT testbed.

various AllJoyn components. In addition, this frame-work comprises AllJoyn Apps and AllJoyn Routers, orApps and Routers for short. Apps communicate withRouters and Routers communicate with Apps. Apps canonly communicate with other Apps by going througha Router. Figure 5 shows the basic topology of AllJoynnetwork architecture. Apps and Routers can live on thesame physical device, or on different devices. From anAllJoyn perspective, it doesn’t matter. In reality, threecommon topologies exist:

1) An App uses its own Router. In this case, the Routeris called a ”Bundled Router” as it is bundled withthe App. AllJoyn Apps on mobile OSes like Androidand iOS and desktop OSes like Mac OS X andWindows generally fall in this group.

2) Multiple Apps on the same device use one Router. Inthis case, the Router is called a ”Standalone Router”and it typically runs in a background/service pro-cess. This is common on Linux systems where theAllJoyn Router runs as a daemon process and otherAllJoyn apps connect to the Standalone Router. Byhaving multiple apps on the same device use thecommon AllJoyn Router, the device consumes lessoverall resources.

3) An App uses a Router on a different device. Em-bedded devices (which use the Thin variant of theAllJoyn framework, more on this later) typicallyfall in this camp as the embedded device typicallydoes not have enough CPU and memory to run theAllJoyn router.

Fig. 4. Three main devices.

Fig. 5. Network architecture of AllJoyn framework.




3.2.1 Gateway softwareThe software application is the heart of the IoT gateway.The gateway software is responsible for collecting mes-sages from the sensors and storing them appropriatelyuntil they can be pre-processed and sent to the data cen-ter. The gateway software decides if the data at a givenstage of processing should be temporary, persistent, orkept in-memory.

The gateway software should be designed with failureand disaster recovery in mind. Since gateway devicesare often operated in the field, we should prepare forworking conditions that are far from ideal. For example,the gateway software should be prepared for a poweroutage or other actions that may result in an interruptionof gateway processing. The gateway software shouldbe bootstrapped and started automatically as soon aspower returns to the device, and it should continue towork from the point where it was interrupted. Gatewaysoftware should also be autonomic enough to properlyhandle system logging. It has to find the right balancebetween the number of log entries stored on the variouskinds of IoT devices and those sent to the data center.

An IoT application comprises app code, service frame-works libraries, and core library. Firstly, app code isthe application logic of the application. It can be pro-grammed to either the service frameworks libraries,which provide higher level functionality, or the corelibrary, which provides direct access to the core APIs.Secondly, service frameworks libraries implement a setof common services, like onboarding, notification, orcontrol panel. By using the common service frameworks,apps and devices can properly interoperate with eachother to perform a specific functionality. Finally, corelibrary provides the lowest level set of APIs to inter-act with the IoT network. It provides direct access toadvertisements and discovery, session creation, interfacedefinition, and object creation/handling. We use theseAPIs to implement large-scale IoT service frameworksand private interfaces.

3.2.2 Gateway data transferUsually gateways are connected to the Internet usingGPS, WiFi, or Ethernet. Some gateways can also workin both GPS and WiFi modes (for example, gatewaysmounted in moving vehicles). In general, non-GPS con-nectivity is preferred to send data, as it doesnt require asubscription to a paid mobile plan. Some gateways willbe constantly connected to inexpensive local networks,but those using GPS connectivity should be very conser-vative in terms of what data they send to the data center.The gateway should apply service logic against the datait collects to understand which messages should be sentover expensive GPS networks, and which data can becached on the device for deferred offline processing.

The messages collected by the gateway from the IoTdevice (sensors and actuators) are usually small in size.For example, the current value of the temperature mea-sured by the sensor is just a decimal number. GPS

TABLE 1Informations of Device table

ID Name Num. of attributes Joining dateD070410 TV 4 2014.08.23D431831 HVAC control 2 2015.02.01S235342 Smoke sensor 0 2016.04.04S889001 Temp sensor 0 2012.11.20D121110 Lamp 1 2012.11.20S900010 Light sensor 0 2012.11.20

coordinates are two decimal numbers, which representlongitude and latitude. This is an important thing toremember: the gateway operates on a large number ofsmall messages.

3.3 Real-time device monitoringReal-time data monitoring (RTDM) [26], [27] is a processthrough which an administrator can review, evaluateand modify the addition, deletion, modification and useof data on software, a database or a system. It enablesdata administrators to review the overall processes andfunctions performed on the data in real time, or as ithappens, through graphical charts and bars on a centralinterface/dashboard.

It is critical to have a good knowledge about thecondition of the current IoT devices in order to ap-propriately maintain the device table. In order to beable to meet demands and provide satisfactory QoS,device monitoring mechanisms are required and canlead to collection and processing of a certain amountof runtime data. To monitor the IoT device and sensorscontinuously, we used CoAP [1] to collect device andattributes information (e.g. Device ID, Name, Join date).

CoAP is a specialized web transfer protocol for usewith constrained nodes and constrained networks in theInternet of Things. This protocol is designed for M2Mapplications such as smart home and building automa-tion. A CoAP packet is sent periodically on each IoTdevice to discover and test connections. CoAP packetsare broadcasting to enable dynamic discovery of everydevices and sensors. The detail information of CoAPfields in the header are defined in IETF RFC document[1].

As shown on Table 1 and 2, proposed gateway usesdevice and attribute tables, respectively. Every intercon-nected IoT device information is periodically updatedby CoAP packet through ACK packet that is being sentby the IoT device. The device Table contains ID, Name,Number of attributes, and joining date (see Table 1). Theattribute table includes ID, attribute name, and attributefunction, last update (see Table 2).

3.4 Self-configuration schemeA Self-Configuration Network (SCN) [28], [29] is anautomation technology designed to make the planning,




TABLE 2Informations of Attribute table

ID Attribute name Attribute function Last updateD070410 Channel up,down 2016.08.20D070410 Volume up,down 2016.08.20D070410 Power on,off 2016.08.20D070410 Mute on,off 2016.08.20D121110 Lamp on,off 2016.08.20

configuration, management, optimization and healing ofmobile radio access networks simpler and faster. SCNfunctionality and behavior has been defined and spec-ified in generally accepted mobile industry recommen-dations produced by organizations such as 3GPP (3rdGeneration Partnership Project) and the NGMN (NextGeneration Mobile Networks).

SCN has been codified within 3GPP Release 8 and sub-sequent specifications in a series of standards including36.902,[30] as well as public white papers outlining usecases from the NGMN.[31] The first technology makinguse of SCN features will be LTE network, but the technol-ogy has also been retro-fitted to older radio access tech-nologies such as Universal Mobile TelecommunicationsSystem (UMTS) [32]. The LTE specification inherentlysupports SCN features like Automatic Neighbor Relation(ANR) detection, which is the 3GPP LTE Rel. 8 flagshipfeature [33].

In our case, we use a Centralized SCN (C-SCN). InC-SCN, function is more typically concentrated closer tohigher-order network nodes or the network Operationssupport systems (OSS), to allow a broader overview ofmore edge elements and coordination of e.g. load acrossa wide geographic area. Due to the need to inter-workwith cells supplied by different equipment vendors, C-SCN systems are more typically supplied by 3rd parties.

Self-configuration strives towards the ”plug-and-play”paradigm in the way that new base stations shall au-tomatically be configured and integrated into the IoTnetwork. This means both connectivity establishment,and download of configuration parameters are software.Self-configuration is typically supplied as part of thesoftware delivery with each radio cell by equipmentvendors. When a new IoT device is introduced into thenetwork and powered on, it gets immediately recognizedand registered by the network. The IoT gateway thenautomatically adjust their technical parameters in orderto provide the required function and capacity, and, inthe same time, avoid the device conflict.

The IoT gateways currently available, allow the user(s)to configure a few properties such as TV channel, light,refrigerator, etc. However, large-scale environment, suchas those based on software-defined networks, are likelyto have very rich configuration controls. The goal ofthis research is to develop algorithms that enable IoTgateway autonomic configuration. We propose an initialstudy of auto-configuration that considers two proper-

ties: dynamic discovery and auto-registration.

4 EXPERIMENTAL RESULTS

In the following section, we provide a large-scale testbeddevelopment for IoT experimentation and evaluation ofproposed IoT gateway. We concentrate measurement onthree main dimensions: device setup response time, en-ergy consumption and monitoring overhead. We furtherdiscuss the extent to which the available testbeds fulfillthe requirements for future IoT testbeds introduced inthe Section 2.

4.1 Large-scale testbedIn [34], the authors survey relevant experimental wire-less sensor network testbeds available to the communitytoday. The most advanced and active testbed in thatsurvey is the ”SmartSantander” project which offers anexperimental research facility at the scale of a city, andwhich can be used to test smart city applications andservices. The SmartSantander project targets a 20,OOO-node network. On the other hand, loT-LAB [35] is afederation of platforms, and is part of OneLab (Internet-overlaid, Broadband access, wireless loT). In the Smart-Santander project, all nodes - called ”service nodes”(battery-constrained nodes) - only produce data and canbe configured only by the administrators of the testbed.They are, however, not open to be reprogrammed byusers. Some nodes (with fewer battery constraints) canbe reprogrammed so users can test their own protocols.Both approaches are complimentary: SmartSantandertargets smart city applications and experimentation atthe loT application level, loT-LAB give bare-metal accessto all nodes in all sites.

Development of prototypes for large-scale IoT sys-tems is challenging. A few hundred IoT nodes can bedeployed on the IoT platform, but it is not easy toget repeatable results when using a shared and publicinfrastructure. To overcome this critical hurdle, we offersa large-scale federated experimental platform allowingresearchers, loT designers, developers and engineers toconstruct, benchmark and optimize their protocols, ap-plications and services. As a state-of-the-art testbed, ourgoal is to answer the needs and requirements of currentand future loT technology. In particular, it offers: (i) aheterogeneous and rich environment (e.g. IoT hardware,topologies, OS, platform, up-to-date standardized proto-col stacks and libraries) applicable to a large spectrum ofloT services; (ii) the ability to instrument an experimentthrough virtualization and reproducibility tools; (iii) theability to manage, interact with and monitor runningexperiments.

The large-scale IoT testbed (originally installed formonitoring building energy consumption) has been im-plemented on the ICT research center, 2nd EngineeringBld., Sungkyunkwan University in Suwon, Korea. It aimsto collect sensing data from a set of areas of offices(e.g., meeting area, relaxing area, and work area) and




the lecture room. The deployed sensors (for measuringindoor climate, energy consumption of office utilities,peoples presence in offices, and parking lot status) collectinformation about the physical status of indoor andoutdoor building environment, and transfer it to theIoT server platform, AllJoyn standard-compatible serverplatform, which allows further processing and analysis.

The testbed is composed of 40 compound sensors, eachof them having 4 kind of raw sensors (temperature, hu-midity, illumination and presence sensor), 10 CO2 (Car-bon dioxide) concentration detection sensors, 10 smartsockets for measuring the electrical power consumption,and 20 parking lot sensors, with total of 200 sensors (i.e.,160 raw sensors + 10 CO2 + 10 sockets + 20 parkingsensors). Table x summarizes IoT devices supported bythe University testbed that will be available in the scopeof the IITP-IoT federation.

4.2 System measurementsOne of the key issues of the application based on IoT isextracting the analysis result from huge amount of col-lected sensing data and recognizing users context fromrecent incoming sensing data to provide customized real-time service. [36], [37] Therefore, the response time isone of the most important criteria of user satisfaction onIoT service. We also consider dynamical change of IoTdevices which comes from their resource constraint andmobility, as a result some devices leave from the net-work and some device join to the network for replacingbroken-down or left devices. The average response timefor device registration while increasing the number ofIoT device gives a good indication of both the generalperformance and the dynamics of the system. We showthe response time prediction and its dependence onbottleneck utilization in the system. Figure 6 shows theservice time, delay and response time in IoT server. Wesee that average device response time is less than 25ms. In addition, average service time + delay is resultedaround 12 ms.

The definition for the lifetime of a IoT sensor nodeusually depends upon battery lifetime. [38], [39] If themote were to stop transmitting and never transmitsagain, the definition would be helpful. However, as theexperiments show a new definition is required to accountfor motes that stop transmitting, but could potentiallybegin transmitting at a later time. Multiple tests werenecessary to build an accurate model. Results measuringthe direct and indirect energy consumption in each IoTsensor are presented and used to derive an basic energyconsumption model and device [40], [41]. Figure 7 showsthe average energy consumption of temperature sensorswhile changing the indoor temperature. we can estimatethe expected energy consumption and system overheadbased on this result.

Data that we send across an IoT (wireless) network ishoused in a data envelope called a packet. Each trans-mission includes additional information, called over-head, that is required to route the data to the proper

location. We can calculate network overhead by sendinga fixed-size data transmission across the network and ob-serving the number of extra bytes of data transmitted forthe action to be completed. Figure 8 shows the endpointdevice monitoring overhead at the IoT server. Firstly,we measured level of wireless network congestion whilechaning the monitoring frequency (top-left). In otherwords, IoT gateway sends the monitoring packets to allendpoints with different frequency. Secondly, bottom-leftfigure depicts a comparison of the measured responsetime against our predictions during 50 minutes. Theresult shows that monitoring overhead has increasedcontinuously. Finally, left figure shows normalized his-togram of overhead during 10 minutes. The averagevalue of entire network overhead resulted around 1000control packets.

5 CONCLUSION

The internet of things is being termed as the futureof internet communication. This work is an attempt tointegrate sensors and actuators with large-scale environ-ment and wireless gateway that could fit in most com-mon small devices today. We have introduced a generalIoT architecture to provide novel Machine to Machine(M2M) services. [42], [43], [44] The mobile clients interactwith the M2M devices and endpoints through the IoTgateway. The M2M services including device discovery,local storage of resource configurations are structuredaround the gateway. The architecture is capable of inter-acting with a non-smart device over AllJoyn framework.Detail testbed development and system measurementare discussed. Such real testbed can be used in severalreal life scenarios including personal health monitoring,environmental monitoring and semantics in IoT. Theusefulness of the system lies in the fact that it providesan incremental methodology to add new services and isgeneric enough to be compliant with future standardsin M2M communications and IoT. The system is scal-able to handle huge amount of traffic as it is basedon RESTful paradigm and SenML is very lightweightwhich can be processed very fast. As future direction,the gateway interfaces and their functionalities are beingimplemented using updated AllJoyn framework, accessrights for multiple users and security/privacy of IoTarchitecture are being investigated.

ACKNOWLEDGMENT

This work was supported by the G-ITRC Program underGrant IITP-2015R6812-15-0001, the NRF Research Fellowprogram under Grant NRF-2016R1A6A3A11934080, andthe NRF Korea under Grant 2010-0020210.

REFERENCES

[1] Z. Shelby, K. Hartke, and C. Bormann, “The constrained applica-tion protocol (coap),” Tech. Rep., 2014.




Fig. 6. Average response time and CPU overhead at the IoT Server.

Fig. 7. Average energy consumption of IoT devices (tem-perature sensors).

[2] N. Jazdi, “Cyber physical systems in the context of industry 4.0,”in Automation, Quality and Testing, Robotics, 2014 IEEE InternationalConference on. IEEE, 2014, pp. 1–4.

[3] G. Fortino and P. Trunfio, “Internet of things based on smartobjects,” Fortino & P. Trunfio, eds., Cham: Springer InternationalPublishing, 2014.

[4] M. Soliman, T. Abiodun, T. Hamouda, J. Zhou, and C.-H. Lung,“Smart home: Integrating internet of things with web servicesand cloud computing,” in Cloud Computing Technology and Science(CloudCom), 2013 IEEE 5th International Conference on, vol. 2. IEEE,2013, pp. 317–320.

[5] P. C. Vinh, “Toward formalized autonomic networking,” MobileNetworks and Applications, vol. 19, no. 5, pp. 598–607, 2014.

[6] K. Tsagkaris, G. Nguengang, A. Galani, I. Grida Ben Yahia,M. Ghader, A. Kaloxylos, M. Gruber, A. Kousaridas, M. Bouet,S. Georgoulas et al., “A survey of autonomic networking archi-tectures: towards a unified management framework,” InternationalJournal of Network Management, vol. 23, no. 6, pp. 402–423, 2013.

[7] B. Kang, P. Nguyen, V. Zalyubouskiy, and H. Choo, “A dis-tributed delay-efficient data aggregation scheduling for duty-cycled wsns,” IEEE Sensors Journal, vol. 17, no. 11, pp. 3422–3437,2017.

[8] B.-S. Kang and I.-Y. Ko, “Effective route maintenance and restora-tion schemes in mobile ad hoc networks,” Sensors, vol. 10, no. 1,pp. 808–821, 2010.

[9] B. Kang and H. Choo, “An sdn-enhanced load-balancing tech-nique in the cloud system,” The Journal of Supercomputing, pp.1–24, 2016.

[10] B. Kang and H. Choo, “A cluster-based decentralized job dis-




Fig. 8. Monitoring overhead: (top-left) level of network congestion; (bottom-left) number of message overhead; (right)normalized histogram of system overhead over 10 minutes.

patching for the large-scale cloud,” EURASIP Journal on WirelessCommunications and Networking, vol. 2016, no. 1, pp. 1–8, 2016.

[11] B. Kang, N. Kwon, and H. Choo, “Developing route optimization-based pmipv6 testbed for reliable packet transmission,” IEEEAccess, vol. 4, pp. 1039–1049, 2016.

[12] B. Kang, S. Myoung, and H. Choo, “Distributed degree-based linkscheduling for collision avoidance in wireless sensor networks,”IEEE Access, vol. 4, pp. 7452–7468, 2016.

[13] M. Lauridsen, I. Z. Kovacs, P. Mogensen, M. Sørensen, andS. Holst, “Coverage and capacity analysis of lte-m and nb-iot in arural area,” in Vehicular Technology Conference, 2016 Ieee 84th, 2016.

[14] S. K. Datta, C. Bonnet, and N. Nikaein, “An iot gateway centricarchitecture to provide novel m2m services,” in Internet of Things(WF-IoT), 2014 IEEE World Forum on. IEEE, 2014, pp. 514–519.

[15] S. Guoqiang, C. Yanming, Z. Chao, and Z. Yanxu, “Design andimplementation of a smart iot gateway,” in Green Computingand Communications (GreenCom), 2013 IEEE and Internet of Things(iThings/CPSCom), IEEE International Conference on and IEEE Cyber,Physical and Social Computing. IEEE, 2013, pp. 720–723.

[16] K. A. Emara, M. Abdeen, and M. Hashem, “A gateway-basedframework for transparent interconnection between wsn and ipnetwork,” in EUROCON 2009, EUROCON’09. IEEE. IEEE, 2009,pp. 1775–1780.

[17] R. Mueller, J. S. Rellermeyer, M. Duller, and G. Alonso, “Demo: Ageneric platform for sensor network applications,” in 2007 IEEEInternational Conference on Mobile Adhoc and Sensor Systems. IEEE,2007, pp. 1–3.

[18] D. Bimschas, H. Hellbruck, R. Mietz, D. Pfisterer, K. Romer,and T. Teubler, “Middleware for smart gateways connectingsensornets to the internet,” in Proceedings of the 5th InternationalWorkshop on Middleware Tools, Services and Run-Time Support forSensor Networks. ACM, 2010, pp. 8–14.

[19] L. Wu, Y. Xu, C. Xu, and F. Wang, “Plug-configure-play service-oriented gateway-for fast and easy sensor network applicationdevelopment,” in SENSORNETS, 2013, pp. 53–58.

[20] C.-T. Chang, C.-Y. Chang, R. D. B. Martinez, P.-T. Chen, and Y.-D. Chen, “An iot multi-interface gateway for building a smartspace,” Open Journal of Social Sciences, vol. 3, no. 07, p. 56, 2015.

[21] Q. Zhu, R. Wang, Q. Chen, Y. Liu, and W. Qin, “Iot gateway:Bridging wireless sensor networks into internet of things,” inEmbedded and Ubiquitous Computing (EUC), 2010 IEEE/IFIP 8thInternational Conference on. IEEE, 2010, pp. 347–352.

[22] J.-W. Yoon, Y.-k. Ku, C.-S. Nam, and D.-R. Shin, “Sensor networkmiddleware for distributed and heterogeneous environments,”in New Trends in Information and Service Science, 2009. NISS’09.International Conference on. IEEE, 2009, pp. 979–982.

[23] D. Min, Z. Xiao, B. Sheng, and G. Shiya, “Design and implemen-tation of the multi-channel rs485 iot gateway,” in Cyber Technologyin Automation, Control, and Intelligent Systems (CYBER), 2012 IEEEInternational Conference on. IEEE, 2012, pp. 366–370.

[24] D. Xu, L. Yang, and L. Jiang, “Research and design of iotgateway,” in 2015 International Industrial Informatics and ComputerEngineering Conference. Atlantis Press, 2015.

[25] I. AllSeen Alliance. (2016) AllJoyn Framework. [Online].Available: https://allseenalliance.org/framework/

[26] M. Banbura, D. Giannone, M. Modugno, and L. Reichlin, “Now-casting and the real-time data flow,” 2013.

[27] Q. Xin, P. Olofsson, Z. Zhu, B. Tan, and C. E. Woodcock, “Towardnear real-time monitoring of forest disturbance by fusion of modisand landsat data,” Remote Sensing of Environment, vol. 135, pp.234–247, 2013.

[28] R. Wojciechowski, A. Sierszen, and Ł. Sturgulewski, “Self-configuration networks,” in Image Processing and CommunicationsChallenges 7. Springer, 2016, pp. 301–308.

[29] H. Hu, J. Zhang, X. Zheng, Y. Yang, and P. Wu, “Self-configurationand self-optimization for lte networks,” IEEE CommunicationsMagazine, vol. 48, no. 2, 2010.

[30] T. GPP, “36.902 v9. 3.0,” Evolved universal terrestrial radio accessnetwork (E-UTRAN).

[31] N. Alliance, “Ngmn 5g white paper,” Next Generation MobileNetworks, White paper, 2015.

[32] A. Samukic, “Umts universal mobile telecommunications system:development of standards for the third generation,” in GlobalTelecommunications Conference, 1998. GLOBECOM 1998. The Bridgeto Global Integration. IEEE, vol. 4. IEEE, 1998, pp. 1976–1983.

[33] N. A. Ali, A.-E. M. Taha, and H. S. Hassanein, “Quality of service




in 3gpp r12 lte-advanced,” IEEE Communications Magazine, vol. 51,no. 8, pp. 103–109, 2013.

[34] L. Sanchez, L. Munoz, J. A. Galache, P. Sotres, J. R. Santana,V. Gutierrez, R. Ramdhany, A. Gluhak, S. Krco, E. Theodoridiset al., “Smartsantander: Iot experimentation over a smart citytestbed,” Computer Networks, vol. 61, pp. 217–238, 2014.

[35] C. Adjih, E. Baccelli, E. Fleury, G. Harter, N. Mitton, T. Noel,R. Pissard-Gibollet, F. Saint-Marcel, G. Schreiner, J. Vandaele et al.,“Fit iot-lab: A large scale open experimental iot testbed,” inInternet of Things (WF-IoT), 2015 IEEE 2nd World Forum on. IEEE,2015, pp. 459–464.

[36] B. Kang and H. Choo, “A deep-learning-based emergency alertsystem,” ICT Express, vol. 2, no. 2, pp. 67–70, 2016.

[37] S.-g. Jung, B. Kang, S. Yeoum, and H. Choo, “Trail-using antbehavior based energy-efficient routing protocol in wireless sen-sor networks,” International Journal of Distributed Sensor Networks,2016.

[38] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internetof things (iot): A vision, architectural elements, and future di-rections,” Future Generation Computer Systems, vol. 29, no. 7, pp.1645–1660, 2013.

[39] P. Bellavista, G. Cardone, A. Corradi, and L. Foschini, “Conver-gence of manet and wsn in iot urban scenarios,” IEEE SensorsJournal, vol. 13, no. 10, pp. 3558–3567, 2013.

[40] Q. Wang and W. Yang, “Energy consumption model for powermanagement in wireless sensor networks,” in Sensor, Mesh andAd Hoc Communications and Networks, 2007. SECON’07. 4th AnnualIEEE Communications Society Conference on. IEEE, 2007, pp. 142–151.

[41] Q. Chi, H. Yan, C. Zhang, Z. Pang, and L. Da Xu, “A reconfig-urable smart sensor interface for industrial wsn in iot environ-ment,” IEEE transactions on industrial informatics, vol. 10, no. 2,pp. 1417–1425, 2014.

[42] J. Holler, V. Tsiatsis, C. Mulligan, S. Avesand, S. Karnouskos,and D. Boyle, From Machine-to-machine to the Internet of Things:Introduction to a New Age of Intelligence. Academic Press, 2014.

[43] K.-C. Chen and S.-Y. Lien, “Machine-to-machine communications:Technologies and challenges,” Ad Hoc Networks, vol. 18, pp. 3–23,2014.

[44] M. Hasan, E. Hossain, and D. Niyato, “Random access formachine-to-machine communication in lte-advanced networks:issues and approaches,” IEEE Communications Magazine, vol. 51,no. 6, pp. 86–93, 2013.

Byungseok Kang received the B.S. degree incomputer engineering from Sejong University,Korea, in 2006, the M.S. degree in electrical andelectronics engineering from Korea University,Korea, in 2008, and the Ph.D. degree in elec-tronics and computer science from the Universityof Southampton, U.K., in 2015. He is currentlya Research Professor with Sungkyunkwan Uni-versity in 2015. His research interests includewired/wireless networking, internet of things,sensor networking, mobile computing, network

protocols, and simulations/numerical analysis.

Daecheon Kim received the B.S degree in in-formation and communication engineering fromSungkyul University, Korea, in 2016, He iscurrently a master cousrse student in infor-mation and communication engineering fromSungkyunkwan University. His research inter-ests include internet of things, sensor network-ing, and mobile computing.

Hyunseung Choo received the B.S. degreein mathematics from Sungkyunkwan University,Korea in 1988, the M.S. degree in computerscience from the University of Texas at Dallas,USA in 1990, and the Ph.D. degree in computerscience from the University of Texas at Arlington,USA in 1996. From 1997 to 1998, he was aPatent Examiner at Korean Industrial PropertyOffice. Since 1998, he has joined the Collegeof Information and Communication Engineering,Sungkyunkwan University, and is an Associate

Professor and Director of Convergence Research Institute. Since 2005,Dr. Choo is Director of Intelligent HCI Convergence Research Center(eight-year research program) supported by the Ministry of KnowledgeEconomy (Korea) under the Information Technology Research Centersupport program supervised by the Institute of Information TechnologyAssessment. His research interests include wired/wireless/optical em-bedded networking, mobile computing, and grid computing. He is VicePresident of Korean Society for Internet Information (KSII). Dr. Choo hasbeen Editor-in-Chief of the Journal of KSII for three years and journaleditors of Journal of Communications and Networks, ACM Transactionson Internet Technology, International Journal of Mobile Communication,Springer-Verlag Transactions on Computational Science Journal, andEditor of KSII Transactions on Internet and Information Systems since2006. He has published over 200 papers in international journals andrefereed conferences. Dr. Choo is a member of IEEE and ACM.

journal of la internet of everything: a large-scale...

Documents