IEEE INTERNET OF THINGS JOURNAL, VOL. X, NO. X, MARCH …cs.txstate.edu/~hn12/IOTSurvey.pdf · IEEE...

IEEE INTERNET OF THINGS JOURNAL, VOL. X, NO. X, MARCH 2016 1

IoT Middleware: A Survey on Issues andEnabling Technologies

Anne HH. Ngu, Member, IEEE, Mario Gutierrez, Vangelis Metsis, Surya Nepal, and Quan Z. Sheng, Member,IEEE

Abstract—The Internet of Things (IoT) provides the abilityfor human and computers to learn and interact from billions ofthings that include sensors, actuators, services, and other Internetconnected objects. The realization of IoT systems will enableseamless integration of the cyber-world with our physical worldand will fundamentally change and empower human interactionwith the world. A key technology in the realization of IoTsystems is middleware, which is usually described as a softwaresystem designed to be the intermediary between IoT devicesand applications. In this paper, we first motivate the need foran IoT middleware via an IoT application designed for real-time prediction of blood alcohol content using smartwatch sensordata. This is then followed by a survey on the capabilities of theexisting IoT middleware. We further conduct a thorough analysisof the challenges and the enabling technologies in developingan IoT middleware that embraces the heterogeneity of IoTdevices and also supports the essential ingredients of composition,adaptability and security aspects of an IoT system.

Keywords-Internet of Things; IoT Middleware; IoT ServiceDiscovery; Security and Privacy

I. INTRODUCTION

The Internet of Things (IoT) is a domain that representsthe next most exciting technological revolution since theInternet [1], [2], [3], [4]. IoT will bring endless opportunitiesand impact in every corner of our planet. With IoT, wecan build smart cities where parking space, urban noise,traffic congestion, street lighting, irrigation, and waste can bemonitored in real time and managed more effectively. We canbuild smart homes that are safe and energy-efficient. We canbuild smart environments that automatically monitor air andwater pollution and enable early detection of earthquake, forestfire and many other devastating disasters. IoT can transformmanufacturing, making it leaner and smarter. According toCBS news, there have been nearly 600 bridge failures in theUSA since 1989. A large number of bridges in every state arereally a danger to the traveling public. IoT-enabled sensors canmonitor the vibrations and material conditions in bridges (aswell as buildings and historical monuments) and provide earlywarning that would save numerous human lives. IoT is going

A. H.H. Ngu and M. Gutierrez and Vangelis Metsis are with Departmentof Computer Science, Texas State University, TX, 78666, USA. Email:{angu, mag262, vmetsis}@txstate.edu

S. Nepal is with Data61, CSIRO, Sydney, Australia. Email:[email protected]

Q.Z. Sheng is with the School of Computer Science, the University ofAdelaide, SA 5005, Australia. Email: [email protected]

Copyright c©2012 IEEE. Personal use of this material is permitted. How-ever, permission to use this material for any other purposes must be obtainedfrom the IEEE by sending a request to [email protected]

to create massive disruption and innovation in just about everyindustry segment imaginable.

While the Internet of Things (IoT) offers numerous excitingpotentials and opportunities, it remains challenging to effec-tively manage things to achieve seamless integration of thephysical world and the cyber one [1], [5], [6]. Many IoTmiddleware and connectivity protocols are being developedand the number is increasing each day. For example, MessageOriented Telemetry Transport (MQTT), Constrained Applica-tion Protocol (CoAP) and BLE (Bluetooth Low Energy) arepopular connectivity protocols designed specifically for IoTdevices. However, the plethora of IoT connectivity protocolsand middleware are not facilitating the ease of connectingIoT devices and interpreting collected data from them. Thisis compounded by the fact that each IoT middleware advo-cates different programming abstraction and architecture foraccessing and connecting to IoT devices. For example, inthe Global Sensor Network (GSN) [7] project, the conceptof virtual sensor, which is specified in XML and imple-mented with a corresponding wrapper, is provided as themain abstraction for developing and connecting a new IoTdevice. In the TerraSwarm project [8], an accessor designpattern implemented in Javascript is proposed as the mainabstraction. In the Google Fit project [9], no particular highlevel abstraction is provided for encapsulating a new devicetype. The system is pre-programmed to support a fixed setof IoT devices, which can be accessed by RepresentationalState Transfer (REST) APIs [10]. Adding an IoT device notalready supported requires expert Java programming experi-ence in extending Google Fit’s FitnessSensorServiceclass. The current state-of-the-art support for IoT applicationdevelopment is application specific which is equivalent tothe scenario where every IoT device requires a different webbrowser for connection to the Internet as echoed by Zachariahet al. in the paper entitled “The Internet of Things Has aGateway Problem” [11].

In this paper, we survey the state-of-the-art middlewaresolutions in realizing IoT applications. Several surveys onIoT middleware have been published such as [12], [13], [14],[15]. To the best of our knowledge, these surveys overviewIoT middleware only from specific perspectives and none ofthem address the more recent trend of light-weight plug-and-play or cloud-based IoT middleware. The aim of this workis to provide a better understanding of current research andchallenges of IoT middleware systems. The main contributionsof this paper are:

• a classification of the different types of architecture of0000–0000/00$00.00 c©2012 IEEE


IoT middleware,• a comparative analysis of emerging IoT middleware sys-

tems for each architecture type,• an assessment of the key research challenges, such as

composition, adaptability and security, in building thenext generation IoT middleware for rapid compositionof IoT applications.

The remainder of this paper is organized as follows. Wefirst motivate the need for an IoT middleware based on ourexperiences in building a real-time Blood Alcohol Content(BAC) predictor using smartwatch sensor data (Section II).We then discuss our observation of the three key softwarearchitectures of IoT middleware and present a description ofthe similarities and differences among the three architectures(Section III). In Section IV, we provide a detailed analysisof the different IoT middleware architectures by surveyingeight existing IoT middleware systems with respect to fulfillingthe key functionalities required by BAC-like IoT applicationswhich are device abstraction for data collection, compositionfor visualization and analysis, service discovery for oppor-tunistic integration, security and privacy, and data persistency.We compare these three types of IoT middleware by providingan example implementation of data collection of a Phidgetssensor in GSN, Google Fit and Ptolemy Accessor Host. Wethen outline the key research challenges in developing an IoTmiddleware that will enable a scientist or a health professionalto configure/compose a BAC-like IoT application which isadaptable, open, and secure (Section V). Finally, we overviewand discuss the relevant work in Section VI and provide someconcluding remarks in Section VII.

II. USE CASE FOR IOT MIDDLEWARE

IoT applications fall into two general categories: ambientdata collection and analytics and real-time reactive appli-cations. The first category of applications generally involvescollecting sensor data from a variety of sensors (e.g., wearabledevices), process them offline to gain actionable information(e.g. a model) and then run the model as a predictor fornew data collected from the sensor in the future. The secondcategory of applications involves real-time reactive systemssuch as autonomous vehicle or manufacturing processes wherethe systems make real-time decisions based on observed sensorvalues. The former category of applications is growing rapidlyespecially in the healthcare domain where personalized healthtracking and monitoring has become vital to improved andaffordable healthcare.

In this section, we motivate the need for an open, light-weight, secure, IoT middleware based on our experience inimplementing an ambient data collection and analytics IoTapplication that can predict Blood Alcohol Content (BAC)using smartwatch sensor data [16]. Below, we briefly outlinethe motivation for creating this IoT application and showhow this application, and in fact all IoT applications in thiscategory, can benefit from an IoT middleware.

Drunk driving is a dangerous, worldwide problem. Thisproblem is not only a hazard to the drunk drivers, but alsoto pedestrians and other drivers. At dangerous levels of in-toxication, it can be difficult to judge one’s own drunkenness.

Instead, it would be better to get a definitive measurementof the BAC, or simply a binary response: “drunk” or “notdrunk”. Compact breathalyzers are probably the best option atthe moment, but these are not discreet and require deliberateactions by the user. The other option is to use a smartphoneapplication to manually calculate BAC, but this demands agreater deal of involvement from the user (remembering howmany drinks they have taken in a social setting). To bepractical, it would be useful to have some sort of non-invasiveand accurate monitoring system that will warn its users if theybecome too intoxicated. This system can also be used to warnfriends and family, or prevent the operation of the drinker’scar by integrating with car’s ignition device.

We investigated the prediction of intoxication level fromsmartwatch sensor data via building a secure IoT applicationfrom the ground up. The collected data need to be storedlocally transmitted to cloud storage for analysis. The avail-ability of local storage is important to avoid the unpredictablelatencies from wireless transmission of data to the cloud. Thedata needs to be secured not only at rest, both at local andcloud storage, but also in transit. This demands the end to endsecurity from the edge/sensor to the cloud data center.

After data collection, data is processed in the cloud todetermine whether there is any relationship between each typeof sensor values and the recorded BAC values. To achievethat, the collected data must be pre-processed and visualized.Then, various machine learning algorithms are applied to thecollected sensor data to obtain the most accurate predictor.Figure 1 shows the main infrastructure used for a generic datacollection and analysis system. The data collection applicationrunning on the smartphone (which is also known as thegateway) implements a set of Java classes to deal with thelow-level details of data collection process such as managingthe various threads for collecting the various sensor valuesfrom the Microsoft Band smartwatch (known as the edgedevice) or other devices such as Fitbit. The data collectionapplication also performs some aggregation on the collecteddata before sending them for archival on the cloud. The dataanalytics is performed entirely in the cloud which has the highperforming computation engine and various big data analyticsand visualization tools. Once a model is derived from the dataanalysis, it is saved and integrated with the BAC applicationas a predictor.

The following are the key computation units we observedfrom implementing the BAC application:

• The Microsoft Band smartwatch must first be virtual-ized as a software component to the BAC smartphoneapplication in order to connect and obtain data fromall available sensors on the Microsoft Band smartwatch.A device abstraction component is thus needed to hideusers from the low level implementation details of thenetworking protocols and communication capabilities ofdifferent physical sensors.

• The real-time interaction between the BAC applicationand the physical device must be supported. Data is usuallydelivered as infinite streams in time-stamped order fromthe devices. A stream, event processing or aggregationservice is thus an important component. Stream pro-


Fig. 1. Infrastructure for Data Collection and Analysis

cessing provides complex event detection that turns thecollected data (usually in large quantity) into usefulactionable information. Aggregation can provide moremeaningful data for analysis. For example, in the caseof collecting accelerometer data, the three most recentvalues were averaged with linear weighting rather thanjust using the last value.

• A monitoring or visualization service is needed to allowusers to monitor/control the state of the physical devicesas well as to manage when and how often the collecteddata should be archived to the cloud for further analysisor processing. This component should also provide noti-fication and subscription services for the timely deliveryof IoT status to users, in this case an alert for beingintoxicated.

• An IoT application can generate a large amount of datathat need to be processed and archived, so the ubiquitousconnection to a cloud infrastructure is needed for dataanalytics and archiving.

• The security and privacy component is needed to providethe integrity of the collected data (stream) and to ensurethat the user’s privacy is not violated. Users should havethe option to archive the collected data in a storagemedium of choice and only be able to connect to au-thenticated/certified IoT devices.

• A composition engine (also called a rule engine in somesystems) is necessary to enable users to combine analyticsservices from the cloud, from data services in other gate-ways (PhidgetInterfaceKit, Arduino) or other IoT devices(car’s ignition device) without low-level programming.

A data collection and analytics system for tracking envi-ronment pollution in a building would involve a similar setof computation units as illustrated in the BAC predictionapplication; albeit the type of sensors at the edge will be Micamotes with desktop or desktop serving as the gateway. Thedata collected will also be pushed to the cloud storage or abackend database. A similar set of analysis and visualizationtools are needed for the analytics. In summary, the logicalrequirement for environment monitoring and BAC monitoringare the same. Having to develop two separate applications foreach of the above applications with dedicated set of resourcesnot only increases the cost and the time for development, but

Fig. 2. Service-based IoT Middleware

Fig. 3. Cloud-based IoT Middleware

also leads developers with the additional challenges of securityand privacy surrounding data and ToT devices access. There isthus a need to develop an open, lightweight, adaptable, secureIoT middleware that serves as a bridge across a variety ofIoT devices and applications. Such a middleware will enablea scientist or a health professional to configure/compose anew secure IoT application for performing the data collectionand analysis relevant to his/her context without any low-levelprogramming.

III. ARCHITECTURE OF IOT MIDDLEWARE

Existing architectures for IoT middleware form three classtypes, from our observation. The first type, which we refer toit as a service-based solution, generally adopts the Service-Oriented Architecture (SOA) [17] and allows developers orusers to add or deploy a diverse range of IoT devices asservices. The second type, which is known as cloud-basedsolution, limits the users on the type and the number of IoTdevices that they can deploy, but enables users to connect,collect and interpret the collected data with ease since possibleuse cases can be determined and programmed a-priori. Thethird type is the actor-based framework that emphasizes onthe open, plug and play IoT architecture. A variety of IoTdevices can be exposed as reusable actors and distributed inthe network.

Figure 2 depicts a service-based IoT middleware. It is athree-layered architecture adopted by the OpenIoT [18], aEuropean Union project to standardize IoT platforms. Thisarchitecture consists of a Physical Plane (sensors and actua-tors), a Virtualized Plane (server or cloud infrastructure) andan Application Plane (utility). The main computational units


are available in the middle layer or the Virtualized Plane.The generic services available in the middle layer range fromaccess control, storage management to an event processingengine. These services support the data collection part ofthe BAC-like IoT applications, but not the analytic part. Theservice-based architecture is a high performing heavy weightmiddleware generally deployed on multiple nodes running inthe cloud or on powerful gateways between IoT devices andthe applications. It is not designed to be deployed in resource-constrained IoT devices (e.g., smart phones) and does notsupport device-to-device communication.

A cloud-based IoT middleware architecture is shown in Fig-ure 3. The functional components (white box in the diagram)of the middleware are limited to what is available on the cloudand it varies widely among cloud-based platforms. Typically,those functionalities are exposed as a set of APIs. The providedfunctionalities could be as simple as a very high performancestorage system or a very powerful computation engine withpre-defined monitoring and analysis tools. The services ofIoT devices available in the cloud can only be accessed orcontrolled via either vendor’s provided application or cloudsupported RESTful APIs.

An actor-based IoT middleware architecture is first pre-sented in Terraswam [19], a joint research project betweenuniversities, government and private companies in USA. Athree-concentric circles visual is used to depict the architectureof the actor-based IoT middleware. The outermost circle is theSensory Swarm (sensors and actuators), the middle circle isthe Mobile Access (gateways such as smartphone, RaspberryPi, Swarmbox, Laptop) and the inner most circle is the Cloud.To facilitate the comparison with other types, we map the threecircles into a three layered architectural view. Figure 4 depictsthis architecture. As shown in the figure, the middleware (alsonamed as actor host) is designed to be light-weight that can beembedded in all the layers (sensory layer, mobile access layerand the cloud). The basic middleware computation units arethus distributed in the network (the white box). For example,an actor-based middleware deployed on a smartwatch mightnot include a storage service. However, an actor that providesa storage service can be downloaded from the cloud repositorywhen needed.

The key differences in the three architectures are the open-ness of the architecture in supporting a new IoT device type,the type of middleware services or computational units theysupport, and where the IoT middleware can be embeddedor deployed. The service-based IoT middleware is deployedin servers or in cloud. This middleware provides users withsimple tools such as Web applications to view the raw datathat the IoT devices are collecting, but usually provides limitedfunctionalities to users when it comes to composition orintegration with other applications or in interpreting the data.The service-based IoT middleware can be set up for restrictedaccess to protect private and sensitive data. The computationalunits in the service-based architecture are not designed to beextendable or configurable by users.

The actor-based style of architecture provides the bestlatency and scalability for large-scale connected IoT devicesbecause the middleware can be deployed in all layers and IoT

Fig. 4. Actor-based IoT Middleware

devices can perform computation where it is most beneficial.Users can extend the computational units of the actor-basedIoT middleware by developing a pluggable actor or downloadthat from a central repository. Both service and actor based IoTmiddleware architectures do not dictate a particular standardsuch as RESTful API or BLE for interoperability amongIoT devices. They both embrace the heterogeneity of IoTdevices by supporting a particular programming model ordevice abstraction. In contrast, in the cloud-based architecture,interoperability is achieved by adopting specific standards.Cloud-based style of middleware can stop working completelywhen the cloud provider ends the service. Google Nest [20]is a prime example of that.

While all the three architectures support security and privacyto some extent, cloud-based architecture requires users totrust the cloud provider to uphold the privacy and integrityof their data. Users are not given alternatives other thanthose prescribed by the cloud. In service and actor-basedarchitectures, users have a choice of how and where datacan be stored. In both service and cloud-based architectures,there is a weak security link between physical devices andthe middleware;because the middleware cannot be embeddedwithin the physical device, the data transmitted between phys-ical devices and the middleware can be compromised.

IoT applications typically operate in a dynamic and uncer-tain environment. For example, IoT devices can run out ofbattery power and stop working, and the connectivity betweenthe devices and gateways might be lost at any time. Themiddleware must provide a service discovery component sothat new services can be made available opportunistically andfailed services can be replaced dynamically to guarantee acertain quality of service (QoS). For example, the physicaldevices can connect to a different gateway of similar quality ifthe current gateway is about to lose connection. Only service-based middleware currently supports a limited form of servicediscovery.

IV. EXISTING IOT MIDDLEWARE SYSTEMS

In this section, we provide a more in depth analysis of thecapabilities of all the three types of IoT middleware in terms ofi) the abstraction they provide for connecting and accessing thephysical devices, ii) the services that they provide for flexible


Fig. 5. Overview of Various IoT Middleware

composition of IoT devices and services, iii) the support forservice discovery, iv) the handling of privacy and securityof the collected data, and v) the support they provide forcreating and provisioning BAC-like IoT applications. Figure 5gives an overview of the various IoT middleware that westudied. Many IoT systems, frameworks, or middleware areconstantly being developed. Exhaustive coverage of all of themis impossible. We aim to survey at least two IoT middlewaresystems in each architecture style, and restrict our study toIoT middleware systems that can support data collection andanalysis as in BAC-like IoT application. We target systems thatare not just a framework or a standardization effort. We alsoavoid closed and subscription-based IoT middleware products.A comprehensive list of IoT related systems can be foundin [21].

A. Service-based IoT Middleware

1) Hydra: The Hydra system [22], [23] is a 4-year projectfunded by the European Union to develop a service-orientedmiddleware for networked embedded systems. The projecthas been renamed to LinkSmart since 2014. Web service isprovided as the main abstraction for incorporating heteroge-neous physical devices into applications and for controllingany type of physical devices irrespective of their networktechnologies such as Bluetooth, RF, ZigBee, RFID, WiFi, etc.Hydra-enabled devices and services are secure and trustworthythrough distributed security and a social trust computation unitprovided by the middleware.

A major novelty in Hydra is that it provides support forusing devices as services by embedding services in devices.Furthermore, the capabilities of IoT devices can be semanti-cally described using ontologies in OWL and SAWSDL so thatthey can be discovered. The framework is intended for threespecific application domains: home automation, healthcare,and agriculture. Hydra supports service discovery and self-configuration of services/devices via context (i.e., location andtime). It recruits new devices or resources dynamically viapeer-to-peer network technologies. Hydra provides an SDKaugmented with semantic model driven architecture to createapplications in supported domains.

The SDK tool is too low level for use as a compositionengine for end users. Hydra advocates the use of a homoge-neous standard (Web services) for addressing the heterogeneity

of IoT devices. While it is possible to create a smartwatchWeb service using the supplied SDK tool kit with training,wrapping IoT devices as Web services might limit the types ofIoT devices that can be deployed and managed in this platformsince a Web service is a heavy weight protocol to run onenergy and capability constrained IoT devices. All collecteddata are transmitted to the Hydra middleware for processingand archiving. No local processing or aggregation of collecteddata is possible on IoT devices. This is impractical for someBAC-like applications where detection of critical events (e.ga fall of an elderly person) from the collected data must beanalyzed in real-time. A Hydra IoT application must be hand-crafted by a programmer and it is not a platform that canempower the consumer to quickly search, create, and deploya BAC-like data collection and analysis application. Hydra isthus more suitable for enterprise-level IoT applications thatform long-term and tight coupling with a static set of IoTdevices that are already supported by the platform.

2) Global Sensor Networks (GSN): GSN [24], [7] is aservice-based IoT middleware (see Figure 2) that aims toprovide a uniform platform for flexible integration, sharingand deployment of heterogeneous IoT devices. The centralconcept is the virtual sensor abstraction, which enables user-s/developers to declaratively specify XML-based deploymentdescriptors to deploy a sensor. This is similar to the concept ofdeployment descriptors used in the deployment of enterprisebeans in J2EE server [25]. The architecture of GSN follows thesame container architecture as in J2EE where each containercan host multiple virtual sensors and the container providesfunctionalities for lifecycle management of the sensors whichincludes persistency, security, notification, resource poolingand event processing. The input to the virtual sensor is one ormore data streams which are processed according to the XMLspecification. These include the sampling rate of the data, thetype and location of the data stream, the persistency of thedata, the output structure of the data, and the SQL processinglogic for the data stream. Each input stream is associated witha wrapper. The wrapper program specifies i) which networkprotocol to be used to connect, interact, and communicate withthe physical sensor when first initialized, ii) what to do inorder to read data from the sensor, and iii) what to do withthe data when it is received from the sensor. GSN provides aSQL-based database that stores all the raw sensor data if thepermanent storage attribute of the virtual sensor is specifiedas “true” in the XML specification. In addition, each virtualsensor contains a key-value pair which can be registered anddiscovered in GSN.

The ability to add a platform specific wrapper enables thesystem to integrate with sensors of heterogeneous types. Toadd a new type of sensor to the platform, the user has toknow how to write an XML descriptor for the physical sensorand provide an implementation of the wrapper in Java if it isnot already available. In the following paragraph, we illustratethe creation of Phidgets sensors in GSN to demonstrate thecapability provided by its device abstraction. We choose toshow Phidgets sensor implementations for the rest of thepaper because we have prototype implementations of Phidgets


sensors in all the three types of middleware that we observed.The light and sound sensor data we collected in Phidgetsare comparable in characteristics to sensor data that can becollected from a smartwatch.

Adding a Phidgets sensor (IoT device) as a new virtualsensor in GSN requires the creation of a deployment fileas shown in Figure 6 and creating a wrapper class that canrun as a thread for consuming the stream data accordingto the properties specified in the XML deployment file.The virtual-sensor-name tag in the deployment filespecifies the storage medium for the collected data. Theprocessing-class tag specifies the Java class of thisvirtual sensor, in this case, the BridgeVirtualSensor.The output-structure tag specifies the structure of thedata to be collected. In this case, it is the sound and the lightand they are both of double type. The stream tag specifieshow the real-time interaction between the physical device andthe application must be supported. For example, the samplingrate, the processing logic on the collected data are specified viaattribute sampling-rate and the query tag. Figure 7 isthe partial implementation of the wrapper class which extendsthe AbstractWrapper class provided by GSN and gets input asspecified by this XML descriptor.

While GSN provides scalable servers for collection andstorage of sensor data, it does not provide tools to composeor interpret the data other than display it on a supplied Webapplication. It also does not support composition of multi-vendor devices via the XML descriptor. However, the extendedGSN [26], which is part of the OpenIoT project, does providea limited composition capability. In GSN, a domain specificapplication must be created by a programmer when dataneed to be collected and integrated from various IoT devices.External applications can access virtual sensors hosted on GSNvia RESTful or Web service APIs. A limited form of servicediscovery, based on dictionary look up, is supported. User datais protected by a login account. Similar to Hydra, all collecteddata are transmitted to the middleware for processing andarchiving. GSN is not designed for embedding in power andcomputation constrained IoT gateways such as smartphones orRasperry Pi, thus no local processing or aggregation of data isperformed. The declarative specification of sensor capabilitiesvia XML descriptor file is a step in the right direction to rapidcreation of BAC-like applications by automatic generation ofthe wrapper class from the descriptor file.

B. Cloud-based IoT Middleware

1) Google Fit: Google Fit [9] is an open IoT ecosystem.It is a cloud-based IoT middleware that lets users controltheir fitness data and build fitness apps from one centrallocation. It has a similar goal to Apple’s HealthKit. Thesystem contains a fitness store, which is a cloud storageservice (similar to Firebase, a JSON-based document server)that stores data from a variety of devices and apps. A sensorframework consists of a set APIs for connecting third-partyIoT devices to its store. For example, it provides APIs forsubscribing to a particular fitness data type or a particularfitness source (e.g., Fitbit or Smartwatch), APIs for querying of

historical data or persistent recording of the sensor data froma particular source (e.g., a smartwatch). In addition, there is apermission and user control module that handles the privacyand security of data by prompting for user consent beforeGoogle Fit’s apps can read or store collected data. Google Fitis an IoT middleware designed for ease of composing a pre-conceived type of application, in this case, self-tracking datafrom wearable fitness devices.

Google Fit provides native support for IoT devices thatcommunicate in BLE (Bluetooth Low Energy). Adding anew fitness sensor type that does not communicate inBLE requires a developer to provide an implementation ofFitnessSensorService class as well as the supporteddata type if it is not available. In Figure 8, we provide asample implementation of a Google Fit software sensor fora Phidgets sensor to demonstrate the complexity of creating aBAC-like application for IoT devices that are not yet supportedby Google Fit.

To collect and store sensor data from a Phidgets sensorwhich communicates via a WiFi network, there is a need to im-plement a sensing service as an Android app to communicatewith Google Fit’s cloud storage server. Figure 8 shows theimplementation of the PhidgetsSensorService whichextends FitnessSensorService. The programming forthat service involves understanding Java’s Event program-ming as well as mastering the various callback methodsin FitnessSensorService class which are non trivial.However, for IoT devices (e.g., Fitbit and Garmin) that arealready supported by Google Fit, it is just a matter ofdownloading and installing a Google Fit app on Androidcompatible gateways such as smartphone or tablet, creatingan account, setting up personal details and permission. Notethat by choosing to use Google Fit, the user is tied to storinghis/her sensor data in Google Fit’s cloud storage, in the formatprovided by Google Fit and in the size limit dictated by GoogleFit. It is not possible to pre-process the collected data beforestoring them such as normalizing the data as in the BACprediction application.

Google Fit thus has a narrow application scope and doesnot provide a framework for general IoT application’s datacollection, composition, and analysis. Service discovery islimited to a scan for nearby BLE devices. There are significantproblems with privacy, security, and unpredictable latencywhen using cloud-based architecture. Moreover, users mustentrust Google Fit to manage their private data.

2) Xively: Xively [27], along with LogMeIn, is a publiccloud-based IoT middleware’s Platform as a Service (PaaS).Xively’s overall mission is to help developers and companiesto turn physical sensors into software sensors and connectthem to Xively’s IoT cloud platform quickly and simply. TheIoT middleware provides a web-based application for quicklyconnecting IoT devices to its cloud and collecting data fromthe devices. Once data is in the cloud, Xively allows users topull data from them easily anytime and anywhere using theirtools. The main use for Xively is for connecting IoT devicesof the users’ choice and store the collected data on their cloudin a scalable way. Xively also provides a persistency service


<virtual-sensor name="PhidgetInterfaceKit" priority="10"><processing-class><class-name>gsn.vsensor.BridgeVirtualSensor</class-name><output-structure><field name="sound" type="double" /><field name="light" type="double" /></output-structure>

</processing-class><description>This phidget sensor holds up to eight other sensors that can hold various data</description><life-cycle pool-size="10" /><streams><stream name="input1"><source alias="source1" sampling-rate="1" storage-size="1"><address wrapper="phidgetinterfacekit"><predicate key="wireless">true</predicate><predicate key="wired_ip">169.254.247.137</predicate><predicate key="wireless_ip">169.254.162.71</predicate><predicate key="sound">1</predicate><predicate key="sound_id">1B98F4E7E8DD4966926F58C669EEB3FF</predicate><predicate key="sound_device">Microwave</predicate><predicate key="sound_off_ceiling">20</predicate><predicate key="sound_off_floor">-1</predicate><predicate key="light">3</predicate><predicate key="light_id">6F1A90A2740E43A0A4D9C86622D39815</predicate><predicate key="light_device">Microwave</predicate><predicate key="light_off_ceiling">40</predicate><predicate key="light_off_floor">-1</predicate><predicate key="light_on_floor">110</predicate><predicate key="light_on_ceiling">-1</predicate>

</address><query>SELECT sound, light, timed FROM wrapper</query></source><query>SELECT sound, light, timed FROM source1</query></stream>

</streams></virtual-sensor>

Fig. 6. Phidgets Sensor XML Deployment File in GSN

public class PhidgetInterfaceKitWrapper extends AbstractWrapper {

public initialize() {connect to the physical sensors;read sensor values;detect new sensor values;

}

public void run() {with certain sampling rate}public DataField[] getOutputFormat()public String getWrapperName()public void dispose()

}

Fig. 7. Phidgets Sensor Wrapper Class in GSN


import com.google.android.gms.fitness.*;import com.phidgets.InterfaceKitPhidget;

public PhidgetsSensorService extends FitnessSensorService {

private Phidget pClient = null;private Map<String, FitnessSensorServiceRequest> mRegisteredSensors = new HashMap<>();

// Listens for and publishes the light and sound sensor data.private final SensorChangeListener mListener = new SensorChangeListener() {@Overridepublic void onPhidgetChanged(PhidgetInterfaceKit e) {

FitnessSensorServiceRequest associatedRequest = mRegisteredSensors.get("Phidgets");if (associatedRequest != null) {

List<DataPoint> data = new ArrayList<>();data.add(DataPoint.create(associatedRequest.getDataSource())

.setFloatValues((float) e.getSensorValue(1);

.setFloatValues((float) e.getSensorValue(3);

.setTimestamp(System.currentTimeMillis(), TimeUnit.MILLISECONDS));

try {associatedRequest.getDispatcher().publish(data);

} catch (PhidgetException re) {}}};

@Override//find the right data sourceprotected List<DataSource> onFindDataSources (List<DataType> list) {

List<DataSource>matchingSources = new ArrayList<>();matchingSources.add (new DataSource.Builder()

.setDevice(new Device("PhidgetInterfaceKit", "Sensors", "--",Device.TYPE_Phidgets))

.setName("Phidgets Sensor")

.setType(DataSource.TYPE_RAW)

.setDataType(DataType.TYPE_PHIDGET_LIGHT_SOUND)

.build());return matchingSources;

}@Override//Register sensor with GoogelFit to deliver dataprotected boolean onRegister(FitnessSensorServiceRequest request) {

if (pClient != null || attemptConnectingPhidgetClient()) {try {

if (mRegisteredSensors.get("Phidgets") == null) {pClient.getSource().addAttachListener(mListener);mRegisteredSensors.put("Phidgets", request);

}} catch (PhidgetException e) { return false;}return true; }

return false;}@Override//configure the sensor to stop delivering dataprotected boolean onUnregister (DataSource dataSource) {}}

Fig. 8. Google Fit Sensor Service


that includes a time-series database for fast data storage andretrieval.

The company has many tools and resources that developerscan use to connect their sensors and collect data from thosesensors. For example, it provides adaptors for integration ofcollected data with commercial enterprise softwares such asCRM (Customer Relationship Management), ERP (EnterpriseResource Planning) and BI (Business Intelligence). A directoryservice is provided for finding appropriate services a.k.a forservice discovery.

Even though adding sensors or IoT devices is advertised tobe simple in Xively, the provided APIs require nontrivial pro-gramming skill especially for IoT devices that are not alreadysupported. It is impossible to compose an IoT application inXively that correlates data from multiple IoT sources. Forexample, no composition engine is provided such that it ispossible to correlate data from a sensor hosted in GSN with asensor hosted in Google Fit without extensive programming.Fundamentally, Xively is providing similar capabilities asGoogle Fit albeit it covers a more diverse set of devices andincludes integration with enterprise-level services. The systemis targeted for business users. As a cloud-based architecture,Xively has the same security, privacy and latency issues asexperienced by Google Fit.

3) Paraimpu: Paraimpu is a social aware IoT middleware[28], [29] that allows consumers to add, use, share andinterconnect their RESTful IoT services whether physical orvirtual. Things are mapped to either the abstract concept ofsensors or actuators in Paraimpu. The former characterizesanything capable of producing data of a related type (text,numeric, JSON, XML etc) and the latter characterizes anything that is able to perform actions by consuming data pro-duced by the sensors. Paraimpu also provides the Connectionabstraction between things. This allows users to composesimple IoT applications via Javascript. All sensors and ac-tuators in Paraimpu are represented as RESTful resourcesand JSON is used for internal interchange of data betweendevices. Paraimpu is implemented using a scalable architectureleveraging a non-blocking Tornado Web sever [30], an NG-INX [31] load balancer, and a MongoDB [32] which providespersistency, replication and fail-over data management support.In other words, Paraimpu aims to provide a scalable cloudinfrastructure.

The key advantage of Paraimpu over other IoT middlewareis the ability for consumers to reuse and share IoT serviceswith others in their social networks. Paraimpu provides alimited set of configurable sensors, actuators and connectionsthat can be reused across applications via filtering and mappingbetween inputs and outputs among sensors and actuators. Asimple JavaScript based rule engine is provided for specifyingcomposition logic between one sensor and one actuator. If thedeveloper wants to connect two sensors to the same actuator,he/she will have to make two separate connections and makea replica of the actuator. Paraimpu does not support servicediscovery. Security is handled via supporting https protocoland authentication via an access token. Privacy is handled bygiving users the control of how they want to share their data

(private versus public). As in Google Fit and Xively, users haveno control over the total ownership of their data. Paraimpudoes not provide device to device communication and thusentails the usual latency problem of a cloud-based architecture.Tutorial materials available on Paraimpu seem to indicate thatParaimpu is good for IoT applications that only involve onesensor and one actuator.

C. Actor-based IoT Middleware

1) Calvin: Calvin [33] is an open-source IoT middlewarefrom Ericsson that aims to provide a unified programmingmodel which is light-weight and portable for capability andenergy constrained IoT devices. It is a hybrid framework com-bining concepts from the actor-oriented model and flow basedcomputing for composing and managing IoT applications. Themain abstraction for building IoT applications in Calvin isan actor which is a reusable software component that canrepresent a device, a computation, or a service. An actor’sinterface is defined by its input and output ports. An actorreacts to inputs by producing outputs, rather than reactingto method calls by returning values as in the traditionalobject-oriented model. This paradigm of actor model followsan Asynchronous Atomic Callbacks (AAC) pattern whereshort atomic actions are interleaved with atomic invocation ofresponse handlers for high performing real-time interaction.Calvin’s actor model also hides the low-level communicationprotocols of things since actors connect and communicatethrough ports no matter how the physical connectivity is done.Calvin provides its own version of scripting language forease of programming of an actor. It advocates a prescriptiveapplication development process called Describe, Connect,Deploy and Manage to improve the process of developing anIoT application. Calvin is a light-weight IoT middleware thatcan run on devices on the edge to minimize the latency andalso utilize the full computing power available on the cloudwhen the need arises.

One key advantage of Calvin’s actor is its ability to migratefrom one runtime environment to another to provide a robustdistributed IoT computation platform. The platform also comeswith a pre-defined set of actors that perform common uniquetasks. This includes actors for popular communication pro-tocols and parallel processing. Calvin’s developer may extendthe capability of this middleware by creating a new actor usingCalvinScript and add the new actor to the library. Actors inCalvin can be composed using CalvinScript.

Calvin does not yet support a GUI-based composition ofIoT applications. In the context of BAC-like IoT applications,a smartwatch actor, a analysis and visualization actors mustbe developed to compose such an application. The real-timeinteraction between physical sensors and the application ismanaged by Calvin’s runtime system which is light-weightand can be deployed in any layer of the IoT middleware.Calvin advocates a simple programming model for actorsand unless this programming model is adopted by the IoTdevelopers’ community and IoT vendors, creating BAC-likeIoT application will not be trivial. Both security and servicediscovery are not addressed in Calvin.


2) Node-RED: Node-RED [34] is an open-source IoTmiddleware platform from IBM. It is based on node.js, aserver-side Javascript platform that uses an event-driven, non-blocking I/O module in a distributed computing environment.Similar to Calvin, it is an IoT middleware that can be run atthe edge of the network because of its light footprint. The mainabstraction is Node which is a visual representation of a blockof Javascript codes designed to perform a specific function onan IoT device (e.g., reading a particular value). In other words,each node can be viewed as an actor.

Node-RED’s key advantage is a visual tool that simplifiesthe job of composing IoT devices especially if the node forthe IoT device is already developed and published by others.The visual tool in Node-RED allows users to drag-and-dropblocks that represent components of a larger system and wirethem up to form an IoT application. Node-RED thus supportscomposition of IoT applications. The composition engine actsas a glue to IoT devices that can be abstracted as nodes.

For a device or service to work with Node-RED, theAPIs for communicating with the device must be availableas node.js library or a module accessible by Node-RED.A limited form of security is provided via password au-thentication. The Node-RED team envisions that modules ornode.js libraries for heterogeneous IoT devices can becrowdsourced via creating a social network of Node-REDdevelopers. Node-RED does not provide service discovery. Itis built on node.js, which is a new platform with limitedlibraries or modules. Node-RED is good for rapid prototypingof IoT applications whose functionalities can be encodedin simple Javascript and executed with Node-RED’s in-builtevent-driven computation model for real-time interaction withphysical devices.

3) Ptolemy Accessor Host: Ptolemy [35] is an actor-oriented framework for the modeling, simulating, and de-signing of concurrent, real-time, embedded devices. It is anopen-source system developed by Professor Edward Lee atthe University of California, Berkeley since 1996. The well-known Kepler scientific workflow system [36] is built ontop of the Ptolemy system. The central modeling conceptin Ptolemy is actors which are software components thatexecute concurrently and communicate through messages sentvia interconnected ports. A novel feature of Ptolemy is thatthe overall execution and actor interaction semantics is notdefined by the actors, but is factored out into a separatecomponent called director. Director plays the same role asthe orchestration engine in a workflow. Ptolemy AccessorHost extends the actor-oriented framework with an accessorabstraction. An accessor encapsulates an IoT device and canexpose an actor interface [8]. Each accessor has an interfaceand an implementation. The interface serves as the local proxyfor the remote IoT device and is specified in Javascript whichis light weight and portable. The implementation (similar to awrapper) encapsulates the APIs of the physical devices whichcan be implemented in any language. Accessor leverages thedisciplined model of computation in Ptolemy and embraces theheterogeneity in IoT devices rather than proposing a singlestandard to homogenize them. Ptolemy Accessor Host also

provides a graphical user interface (GUI) for the ease ofcomposing IoT applications. The GUI contains drag-and-dropfeatures (an easy way to connect actors and accessors to eachother) as well as a comprehensive framework for managingthe composed IoT applications. This includes various kinds ofdisplays for the execution status and the ability to pause andresume the execution at anytime. Accessor is designed to runon the edge devices, the gateways, as well as on the cloud.This ensures that the IoT application is executed where it ismost beneficial. Accessors can be downloaded and shared overthe Web as in Paraimpu.

To demonstrate the light-weight programming model usedin actor-based architecture, we illustrate an implementationof an accessor to collect data from a Phidgets sensor inPtolemy Accessor Host. Note that the communication modulefor Phidgets sensor’s hardware must be available on thePtolemy Accessor Host. The communication module can beimplemented in any programming language, however, to makethe module executable on other accessor hosts beyond Ptolemy(a host that has a JavaScript engine), the module needs toconform to the CommonJSModule standard. Figure 9 is apartial implementation of the phidgetsSensor.js mod-ule, which encapsulates the phidgets’ communication APIs.Figure 10 shows the implementation of a Phidgets accessorthat makes use of the functionalities provided by the moduleto collect sound and light sensor data. When compared withthe wrapper codes for Phidgets in GSN or the phidgetssensor codes in Google Fit, Ptolemy’s accessor script and itsmodule are simpler because they do not require knowledgeof threads or concurrent programming. An Accessor script isdesigned to be easily written with the description automaticallygenerated for other applications to consume. One of the built-in computation models of the Ptolemy, i.e. the discrete eventdirector handles the real-time semantics of accessors executionand coordination with the physical devices and other actors.

The key advantage of Ptolemy Accessor Host is the abilityto compose multi-vendor IoT devices grounded on rigorousmultiple computation models with time semantics. For exam-ple, it guarantees correct execution of a real-time distributedIoT application. Other actor-oriented platforms (Node-REDand Calvin) only support a single model of computationtypically based on data/event flow without rigorous timesemantics. In addition, in Ptolemy Accessor Host, developerscan leverage extensive existing actor libraries (computation,storage, or visualization actors) for composing IoT applica-tions. Ptolemy Accessor Host is good for both the dynamicreactive IoT applications (e.g. control of autonomous vehicles)as well as the ambient data collection and analytics BAC-likeIoT applications because of the multiple computation modelsinherited from Ptolemy.

Ptolemy Accessor Host does not yet support service discov-ery. As the number of actors and accessors grow, the abilityto discover compatible actors or accessors will be valuablefor composing adaptive distributed IoT applications. Variousaccess controls can be made available via specialized actorsin Ptolemy Accessor Host. However, when an IoT applicationinvolves multi-vendor devices, being able to guarantee privacyof data from each device and yet to share the data effectively


/** Phidget sensors module. It first loads the phidgets APIs from the vendor */

var phidgetSensor = Java.type(’com.phidgets.InterfaceKitPhidget’)exports.setConnection = function (ipAddress) {

return phidgetSensor.openAny(ipAddress)}

exports.getSound = function() {return phidgetSensor.getSensorCount()

}

exports.getLight = function() {return phidgetSensor.getSensorValue(index)

}

Fig. 9. Phidgets Sensor Module in Ptolemy Accessor Host

/** Load the specified module by name. */var phidgets= require(’phidgetsSensor’)

/** Define inputs and outputs of the accessor */exports.setup = function() {

input(’trigger’);parameter(’sampling rate’, {’type’:’int’, ’value’: 1});parameter(’ipAddress’, {’type’:’string’, ’value’: ’ ’});output(’sound’, {’type’:’number’});output(’light’, {’type’:’number’});

}

/** Whenever a new input arrives at the input port, in this case the ’trigger’ input port,the new light (id 3) and sound (id 1) data will be send to the respective output ports */

exports.initialize = function() {phidgets.setConnecion(get(’ipAddress’))addInputHandler(’trigger’, function() {

var lightValue = phidgets.getSensorValue(3);var soundValue = phidgets.getSensorValue(1);send(’light’, lightValue);send(’sound’, soundValue);

});}

Fig. 10. Ptolemy Phidgets Accessor

for actionable knowledge is a significant challenge.

D. Summary of IoT Middleware Systems

Existing IoT middleware systems, which focus on support-ing the efficient and secure processing of streaming data froma large number of homogeneous sensors, tend to be service-based while those that focus on consumer usability tend tobe cloud-based. We summarize and discuss the main charac-teristics of existing IoT middleware systems in this sectionand identify the key challenges and research gaps related toproviding a light-weight, open and secure IoT middleware innext section.

The horizontal column heading in Table I lists the key func-tionalities for IoT middleware that will empower consumersto create BAC-like IoT applications. Each row of the tableenumerates the functionalities provided by the IoT middlewaresystem we surveyed for composing BAC-like IoT applications.

The device abstraction column refers to the construct used toencapsulate the heterogeneity of physical devices. The networkconnectivity column refers to the types of communicationprotocols supported (e.g., HTTP, UDP, BLE). Compositioncolumn refers to the ability to connect and mashup crossvendors IoT devices regardless of its connectivity protocolor message format. The monitoring and visualization columnrefers to the ability to check the state of the devices andvisualize the collected data at any time and anywhere with-out having to write a complex third-party application. Theservice discovery column refers to the ability to dynamicallyrecruit the best device or service with certain quality levelfor composition. The security and privacy column refers tohow personal data are stored and managed. Consumers mustbe confident that sensitive data from their devices do notpropagate beyond authorized entities or tempered with beforethey use the application. The persistency column refers to howthe IoT middleware provides and handles the storage of the


varied types and amount of data.Table I shows that device abstraction is provided by all sur-

veyed systems. However, the type and granularity varies quitea bit. In cloud-based middleware, vendor supplied low levelAPIs are used for adding IoT devices not natively supported. Inservice and actor-based middleware, high-level programmingmodels such as accessors, node or virtual sensors are provided.The ease of deploying a new IoT device on the middlewareis directly related to how device abstraction is supported. Wehave demonstrated in Figure 8 that adding a Phidgets sensor bysubclassing the FitnessSensorService class in GoogleFit is non trivial. The network connectivity is well supportedacross all three type of architectures. The actor-based mid-dleware supports the most varied and biggest selection ofnetwork protocols. All systems provide persistency service, thedifference is in the types of data that can be stored and thescalability of the service. Google Fit currently only supportsdata related to fitness. Multimedia data are not supported.

As cloud-based middleware is targeted to a large numberof IoT devices and users, a high performance persistencyservice is a necessity. Xively and Google Fit do not review thetechnical details of their persistency service and thus we listthem as “cloud storage” in the table. This can be interpretedas having a combination of high performing web servers andstorage systems. For actor-based middleware such as PtolemyAccessor Host, persistency service defaults to the local file sys-tem which might not be scalable. The composition and servicediscovery are the least supported among the surveyed systems.Paraimpu provides limited composition capability between asensor and an actuator. Only Ptolemy Accessor Host currentlyprovides a comprehensive composition engine. The streamprocessing engine in the middleware provides an abstractionfor the real-time interaction between the application and thephysical devices. Composition of IoT applications is mademuch simpler when the middleware provides a scalable streamprocessing engine. Among the systems, Ptolemy AccessorHost provides the most advanced stream processing enginevia various directors. None of the systems currently iprovidessecurity solutions targeted to the unique characteristics of IoTdevices.

V. KEY CHALLENGES AND ISSUES

While IoT middleware holds promise for developing inno-vative IoT applications and services that we might not even beable to imagine right now, it also poses a number of dauntingchallenges [1], [5], [37]. The first challenge is in developingan IoT middleware that must be available in the cloud as wellas on the edge (IoT devices and gateways) for supportingall types of IoT applications, for better privacy control andlatency. This requires the system to be portable and light-weight. Among the IoT middleware we studied, only Calvin,Node-RED, and Ptolemy Accessor Host are designed to beportable and light-weight. There is a trade off between havingpowerful services such as semantic-based discovery, fraud-resilient security enforcement, and stream processing versusthe ability to deploy an instance of the IoT middleware inconstrained devices.

The second challenge is to empower consumers to createIoT applications targeted to their context. In the cloud-basedIoT middleware, no composition engine is provided for con-sumers. This limits consumers to the pre-programmed IoTapplications and prevents consumers from creating their owninnovative applications. For the service-based architecture, anSDK tool is provided for crafting an IoT application. Thisrequires low level programming knowledge and does notempower consumers to create their IoT applications targetedto their needs. Currently, only the actor-based IoT middlewareand the OpenIoT project provide visual composition tools. Thevisual tools provided by Node-RED and Ptolemy AccessorHost are early composition tools in this research direction. Forexample in Ptolemy Accessor Host, the accessors, which arethe fundamental elements of the composition tool, must be de-signed and implemented according to a specific programmingmodel. This requires end users to master JavaScript or otherscripting languages in order to create an IoT application if thedesired accessors have not already been provided. Moreover,an accessor in an IoT application is “designed to fit” aparticular usage. Each new usage requires the developmentof a new accessor. A higher-order accessor or a context-awareaccessor needs to be developed for flexible composition ofIoT applications. For example, by gathering some contextualinformation from consumers (location, time, URL, communi-cation protocol), the desired accessor can be configured auto-matically as a subclass of an existing accessor for the desiredIoT application. In addition, currently, no composition toolsupports transactional properties. It assumes IoT applicationswill run from the beginning to the end successfully. There isno provision of rollback or restart from a certain point in acomposed IoT application when there is a failure.

The third challenge is to provide semantic service discoverythat goes beyond discovery of IP addresses of the nearby IoTdevices. Given that the environment that the IoT applicationinteracts with evolves continuously, new services or devicescould come on-line anytime and existing devices might be-come unavailable. It is essential to be able to discover or queryfor compatible services at the right time and at the right placeboth at design time as well as at runtime. For example, insome critical health monitoring IoT applications, failed IoTservices must be replaced without causing any disruption.

The fourth challenge is to guarantee the security of IoTapplications and also protect the privacy of users. Manyapplications from a variety of domains, ranging from smarthealthcare [38] to digital agriculture [39], are utilizing theIoT infrastructure. Critical decisions are going to be made inthese applications by analyzing data collected from the IoTdevices. This has raised the issues of security, privacy andtrustworthiness of IoT generated data [40]. These issues arenot limited to data alone, but also the underlying networksand devices. Hence, supporting security, privacy and trustmechanisms within IoT middleware has been recognized as acritical and important issue for the successful deployment ofIoT applications, and is deemed as one of the major challengesin both industry and academic communities. Security is gener-ally supported via some kind of authentication and encryptionprotocols and privacy is addressed by giving the end user the


FunctionalitiesMiddleware Device ab-

stractionNetwork con-nectivity

Composition Monitoring and vi-sualization

Servicediscovery

Security andprivacy

Persistency Streamprocessing

Hydra Web service ZigBee,Bluetooth,RFID, Wi-Fi,HTTP, SOAP

SDK took kitwith SemanticModel DrivenArchitecture

Vendor GUI appli-cation

OWL andSAWSDLfor devicedescription

Distributed se-curity and so-cial trust

Unknown Event manager

GSN Virtualsensor/XMLdeploymentdescriptor

Push/pull,SOAP, HTTP

Specific applica-tion created byprogrammer

Vendor Web appli-cation

Key-valuestore registryfor devices

Login account,electronic sig-nature

SQL database SQL query ondata stream

Google Fit Fit Pro-grammableAPI orRESTfulresource

Bluetooth, Wi-Fi. HTTP

Fitness based de-vices and data

Vendor Web appli-cation

Not supported Permission anduser controlmodule

Cloud storage Sensors API

Xively RESTful re-source

Bluetooth,Wi-Fi, Socket,MQTT, HTTP

Not supported Vendor Web appli-cation

Not supported User controlon how data isshared

Cloud storage RDF streamprocessing

Paraimpu Sensor, Ac-tuator, Con-nection

Pull/push,HTTP

Compose onesensor with oneactuator usingConnection

Paraimpuworkspace

New sensorcan announceits presence

Access tokenneeded foraccess, userdata sharedaccording tothe statedprivacy law

Mongo DB JSON query

Calvin Actor Wi-Fi,BlueTooth,i2c

CalvinScript Vendor Web appli-cation

Provide searchvia CalvinControl APIs

Not supported DistributedHash Table(DHT)

Data flow pro-cessing

Node-RED Node MQTT Drag and drop vi-sual tool

Browser-based flowediting tool

Key wordbased searchprovided fornode

Userpermissionwith passwordsecurelyhashed usingthe bcryptalgorithm

Local file sys-tem

Node streams

PtolemyAccessor Host

Accessor MQTT,Bluetooth,Wi-Fi. HTTP,UDP, CoAP,Websockets

Drag and drop vi-sual tool based onVirgil

Java-based GUI ap-plication

Import and ex-port facility

Keymanagementand Taintanalysis

Local file sys-tem

Discrete eventdirector

TABLE IIOT MIDDLEWARE VS. FUNCTIONALITIES

ability to specify different level of access controls without theguarantee of data ownership.

In the rest of this section, we will focus our discussions onthe challenges and solutions to provide IoT service discoveryand security, which are the two most prominent gaps in theeight systems we surveyed.

A. IoT Service Discovery

We first review the existing service discovery mechanismsand then outline a few strategies for providing service discov-ery in IoT middleware.

1) Existing Service Discovery Approaches in IoT: A com-mon approach to support adaptability in IoT middleware is toadopt a uniform service description and a mechanism to reasonover that description for service discovery in different contexts.For example, at design time, a user should be able to querya registry of service descriptions and with the click of a fewbuttons start to interact with a device that can guarantee the de-sired capability and quality. Within the OpenIoT project [18],the W3C Incubator Activity XG group has proposed an SSN(Semantic Sensor Network) ontology for sensor discovery anddynamic integration of sensors. SSN ontology captures boththe properties or attributes of the sensors and the observationsderived from the sensors. The key concepts in SSN are Sensor,Observation, Property, FeatureOfInterest, SensorOutput, Mea-

surementCapability, ObservationValue and Condition. Usingthis ontology, a wind sensor for Mount Washington hosted inthe Paraimpu IoT middleware, which is capable of measuringwind speed every ten minutes, will have FeatureOfInteresthaving a value of “wind” and the Property with a value of“speed”. SSN enables IoT devices and the observed data tobe annotated in a way that can be searched and understood byothers.

In XGSN [26], the extended GSN project, both the IoTdevices and the observed data are semantically annotatedusing SSN. The semantic annotation of the sensors consistsof the metadata associated with the physical sensor such as itslocation, the type of observation it produces, the responsibleperson or organization for the sensor, and the source type. Theother semantic annotations are associated with the observeddata, which include the time and context when the observationhappen, the observed property, the measurement unit and thevalues. The annotated data is converted to RDF streams andsent to a cloud-enabled Linked Sensor Middleware (LSM) [41]which is a Linked Data RDF store. LSM can either storethe RDF stream data in a triple store or perform continuousqueries over the stream data using SPARQL queries to deriveaggregated observation in real-time. Using this setup, eachGSN virtual sensor has a corresponding sensor instance inthe LSM’s RDF store. XGSN provides a RESTful service


for registration of the annotated virtual sensors. However, theannotated semantic of the virtual sensors must be provided inan associated RDF file, which has to be created first by anexpert who knows RDF.

SensorML [42] is an approved Open Geospatial Consortiumstandard (OGC). SensorML supports semantic description ofIoT devices by providing a way to describe a sensor usingstandardized XML tags such as PhysicalComponent fordescribing metadata associated with the sensor, Output andDataStream which describe the observed properties of thesensor and Position which describes the location of the sen-sor. The main objective is to provide a semantic annotation ofsensors, actuators and processors so that they are interoperableand can be understood by machine and utilized automaticallyin complex workflows. SensorML is a part of the OGC SensorWeb Enablement (SWE) suite of standards.

The Hydra [23] project adopts OWL and SAWSDL tosemantically annotate their IoT devices for discovery. OWL isan ontology language for Semantic Web. OWL ontologies areusually stored as RDF documents. The Semantic Annotationfor Web Service Description Language (SAWSDL) allows aWSDL (Web Service Description Language) file to be enrichedwith semantic description. This assumes that IoT devices canbe automatically exposed as WSDL files.

Other considerable efforts made in IoT service discoveryinclude Snoogle [43], Microsearch [44], and MAX [45]. Thesesystems assume that sensor nodes attached to physical IoTdevices carry textual descriptions of the devices in termsof keywords. Users then have the opportunity to find thosedevices by matching a query consisting of a list of keywords.The results from these systems are still experimental and pre-liminary. In [46], Ostermaier et al. reported a system, namedDyser, for real-time discovery of things on the Web. Dyseruses statistical models to predict the state of its registeredresources when a user submits a query. The predictions areused to establish a ranking that determines the order in whichresources are contacted to find out whether their current statematches the query. However, contacting registered resourcesfor every query implies serious performance overhead, partic-ularly given that the number of queries and things could beenormous. It is not trivial to build an efficient index for sucha big data set

2) Open Problems and Suggested Solutions for IoT ServiceDiscovery: The semantic annotation of sensors and sensor dataenables sensor data from different sources to be shared andqueried in a uniform way. While emerging standards like SSNand Linked Data are gaining adoption, competing standardslike SensorML and SAWSDL cannot be ignored. Althoughthere are open source ontology tools such as Protege1 that canbe used to provide semantic annotation of IoT devices, it isstill nontrivial to annotate IoT devices with such descriptionswithout expert knowledge of Resource Description Framework(RDF). To realize a uniform IoT service description system, atranslator or an annotation tool should be provided for settingup a registry of IoT devices and access mechanisms. In theOpenIoT project [47], a visual semantic annotation tool is

1protege.stanford.edu

integrated with XGSN to hide the details of creating RDF filefrom users. This annotation tool is very specific for XGSNmiddleware. Further research is needed to develop a genericannotation tool that can be used by any IoT middleware. Withan ontological approach, unless the community as a wholeagrees on a single standard, it is impossible to develop ageneric annotation tool. Given the rapid technological ad-vances in this field, it might be impossible to maintain a singleglobal ontology for describing IoT devices.

There is also the scalability issue when using ontologicalapproach for service discovery in IoT. When there are largenumber of sensors streaming large quantities of data over along period of time, RDF can be too verbose for capturing thesemantics of the data especially for energy and computationconstrained IoT devices. Furthermore, SPARQL query engineused for querying the RDF store might not scale with the largenumber of data streams from IoT devices.

We propose two non-ontological approaches for servicediscovery. The first approach is to create a similarity-basedsearch engine for heterogeneous IoT devices or services. Thisapproach has been used successfully to create similarity-basedWeb service search engine such as Woogle [48], WSEx-press [49] and Titan systems [50]. Web services are self-describing interfaces that can be programmatically accessedand manipulated through the Web. We have created a Webservice similarity search engine called ServiceXplorer [51].A user can upload an existing Web service description file(WSDL), the system will parse the description and createrecords of the key functionalities of the Web services thatcan be searched using the Earth Movement Distance (EMD)based similarity search algorithm. This approach assumes thatthe interface for an IoT device is available in the form of adocument and there is some regularity in the structure of thedocument. For example, documentation created by JSDoc foran accessor in Ptolemy has a regular structure that highlightsthe functionalities of the encapsulated physical device. Anexample of the documentation of an accessor for Philips Huelightbulb in Ptolemy can be found online2. A query can beexpressed as a combination of keywords or key phrases. Thisapproach is restricted for discovery of meta data of sensors,not the observed data from sensors. For example, a query todiscover all temperature sensor services that have readingsabove 90 degrees in the last two hours cannot be answeredusing this approach.

The second non-ontological approach towards service dis-covery is based on performing data analytics on the usagelog of the devices or services. Instead of having to labelthe IoT devices or services using ontology, this approachaims to collect the usage history of the devices and ser-vices and use that to infer the capabilities and relationshipsbetween devices. By analyzing when, where, who is usingthe device (e.g., a device used frequently around lunch time,located in the kitchen, and used by someone who has theoverlapping scheduled lunch time has a high probability tobe a kitchen appliance), it is possible to derive relationships

2https://www.terraswarm.org/accessors/doc/jsdoc/accessor-devices Hue.html


Fig. 11. Key security, privacy and trust properties in IoT system

between devices and services. This allows recommendationof devices or services for composition as well as optimizingthe time and cost of using an IoT device in a particularsituation. For example, when multiple people want to usea particular IoT device which is in use, it makes sense torecommend other similar devices by looking at devices thatare the nearest neighbor of this device without having tomanually set up the ontological description of all devices in thesystem. Recommending relevant things by discovering implicitrelationships between things via usage logs has been describedin a recent research work [52], [53]. A key advantage of thisapproach is that the discovery of devices and services takesplace behind the scene. As devices come on line and get used,the usage log is created and data analytics can be used toclassify this device. The key research problem that needs tobe addressed in this approach is ensuring that privacy of userscan be preserved when mining the usage log of the devices orservices.

B. Security and Privacy

In the previous sections, we have discussed the securityand privacy issues in the selected IoT middleware systems. Inthis section, we first define the security, privacy and trust inthe context of the IoT environment. We then review existingmechanisms on supporting security, privacy and trust, witha specific focus on the existing IoT middleware, and finallydiscuss some open problems and suggested solutions.

1) Security, Privacy and Trust Properties: Building re-silient, trusted IoT systems requires that key essential prop-erties for security, privacy and trust are met. What are theseproperties? There are neither consensus definitions, nor exactboundaries on which properties fall into security or privacyor trust. However, it is clear from the published literaturethat there has often been a focus on specific properties ratherthan taking the issue of security, privacy and trust in IoTsystems holistically. For the purpose of this discussion, wecapture some key properties discussed in the literature inFigure 11. It is important to note that they do not representthe comprehensive list of all relevant properties.

Security is often defined using three properties: confiden-tiality, integrity and availability [54]. Confidentiality meansthat a given message must not be understood by anyone other

than the desired recipients. The integrity property ensuresthat the data produced and consumed in the IoT system arenot maliciously altered. The availability property means thesystem is robust enough to be able to operate in adversesituations. In addition to these three key properties, thereare more security properties defined in the literature, such asforward and backward secrecy [55], that are equally importantin certain context within IoT systems.

The treatment of privacy in the literature is varied, rangingfrom being defined as one of the security properties [55] toreferring to particular privacy enhancing technologies [56]. Forour discussion, we define privacy with regard to entities inan IoT system that can have control over how information isshared and distributed. The entities here could be the end usersof the IoT system or IoT devices [57]. We capture the privacyneeds through three key popular and emerging techniques:anonymity, differential privacy, and privacy-by-design. Werefer readers to [58], [59], [60] for further information.

Trust is often defined through three properties: authen-tication, authorization and accountability. The authentica-tion property ensures that the data is sent by the claimedsender [61], whereas the authorization property guaranteesthat only authorized entities are able to perform certain op-erations [62]. The accountability refers to the property thatenables auditing of IoT systems for significant events andanalyze log to associate the behaviors of entities to suchevents [63]. Audit trails and logs are important for detectingsecurity violations and re-creating security incidents. In addi-tion to the above three properties, there are other propertiesin the literature that are related to trust management such asfreshness, reputation, access control and non-repudiation. Werefer readers to [55] for further details.

In the following, we review how existing IoT middlewaresystems are designed to support different security, privacy andtrust properties.

2) Existing Approaches for Supporting Security, Privacyand Trust: The problem of security and privacy in the IoT sys-tems has started to receive greater attention from researchersrecently, resulting in a number of publications in this area [64],[65], [66]. However, the focus of the majority of these publica-tions is on the sensors, networking and application layers in theIoT architecture, rather than the middleware. Bandyopadhyayet al. [67] have surveyed ten popular IoT middleware includingHydra [68], GSN [69], SOCRADES [70], and SMEPP [71],and reported that only six of them support security and privacyfeatures. Fremantle and Scott [72] are the first who surveyedtwenty two IoT middleware systems with the focus on securityand privacy. They also found that only ten of the surveyedsystems have a security model, but many of those modelsare not well defined and developed. This clearly demonstratesthe lack of security support in the existing IoT middlewaresystems. When we consider the security, privacy and trustproperties described earlier, only eight of the twenty twosupport a form of confidentiality, integrity, authentication,federated identity, access control, and attestation mechanism.However, none support privacy-by-design and trust manage-ment. In the following, we review the support of security,


privacy and trust in the middleware architecture discussedearlier.

Service-based IoT Middleware: Hydra [68] (also known asLinkSmart [73]) is a service-based IoT middleware imple-mented using Web services and utilizes the XML securitymodel [74]. One of the drawbacks of the standard XMLsecurity model is that it is costly in both time and memorydue to the XML canonicalisation needed for digital signature.The data encryption in Hydra/LinkSmart is supported throughthe use of symmetric keys, as they are more efficient than thePublic Key Infrastructure (PKI). However, it suffers from aunique challenge in key management, i.e. in creating and dis-tributing keys. To alleviate this problem, the Hydra/LinkSmartsystem offers a service, called TrustManager, to support PKIwith a central Certificate Authority (CA). The CA issues asigned certificate to each identifiable device in Hydra/LinkS-mart that is used to identify the communicating parties inthe system. Hydra middleware offers limited support to thesecurity, privacy and trust properties described earlier. It doesnot offer any policy based access control for IoT data, anddoes not address the secure storage of data for users. It alsofails to offer any user-controlled models of access control touser’s data [72]. Hence, the underlying security, privacy andtrust support in Hydra is limited to the cryptographic supportthrough TrustManager.

GSN [69], another service-based middleware, explicitlyincludes a security model through its integrity service andaccess control. The security model sits on top of the data andquery layers and supports authorization property by controllingaccess to data and query. Only authorized users can haveaccess to them. The integrity service is designed to support theintegrity and confidentiality properties through encryption andelectronic signature. In addition, GSN is designed to supportaccess control and integrity supports at different levels ofgranularity; from whole GSN containers to individual virtualsensors. Though the architecture is designed with securityconsiderations, the details on the underlying implementationmodels are difficult to access through two key papers onGSN [69], [75] and XGSN [76]. Hence, we conclude thatthe support for security, privacy and trust is limited in GSNas well as its extended version, XGSN.

The OpenIoT middleware is also a service-based middle-ware as it is built with GSN as the core. The OpenIoT se-curity and privacy framework describes a number of essentialfeatures that an IoT middleware is required to provide supportin security, privacy and trust [77]. For example, the support ofdata integrity through message digest, confidentiality throughprivate key cryptography, key exchange through public keycryptography, authentication through digital signature, identitymanagement through digital certificates, and key managementthrough keytool and keystore. In addition, it has outlineda number of security protocols that are essential for IoTsuch as IEEE802.15.4, IPSec, TSL, and HTTPS. Furthermore,access control mechanisms such as mandatory access control,rule based access control, lattice based access control andinformation flow based access control, are also discussed asfundamental requirements for the IoT middleware. However,

the implementation details of these security mechanisms inOpenIoT platform are not available. There are two specific is-sues with the the OpenIoT security and privacy framework: (a)most underlying techniques described in the model are genericand not specific to the resource-constrained IoT environment,and (b) no public implementations of the security frameworkare available.

In Virtus [78], a service-based middleware system, securityis integrated with the system by design. Virtus uses theXMPP protocol to provide secure event driven communi-cation. Authentication is supported by the TLS (TransportLayer Security) protocol and encryption by the SASL (SimpleAuthentication and Security Layer) protocol. TLS also ensuresthe confidentiality and data integrity, whereas SASL guaran-tees server validation through an XMPP-specific profile, bymeans of authentication. In addition, the Virtus architecture isdesigned to allow the isolation of one or more instances fromthe Internet so that highly sensitive data can be kept private.

Cloud-based IoT Middleware: The details on the supportof security, privacy and trust in the cloud-based systemslike Google Fit, Paraimpu and Xively are not available tomake a fair assessment. As these systems rely on cloud-basedarchitecture, a number of security and privacy issues relatedto cloud systems are applicable to them [79]. One of themajor concerns is the control of sensitive information in thecloud-based system, as the data is controlled by the serviceprovider. In addition, the limited security support provided bythese systems are not designed for the resource-constrainedIoT environment.

In Webinos [80], another cloud-based IoT middleware de-veloped under the European FP7 project, the security andprivacy is treated as a first class citizen and included whiledesigning the system rather than an after-thought solution asin OpenIoT. The system uses the concept of Personal Zone,a secure virtual overlay network that groups a user’s personaldevices and services. Each user in the system has a trustedPersonal Zone Hub (PZH) instance running in the cloud. ThePZH acts as a centralized authority to enforce policies. Thepolicies are defined using XACML [81], a general-purpose ac-cess control language. The privacy is enforced within Webinosby disclosing the minimum amount of data via disabling thecollection of contextualized data, and automatic filtering ofdata related to personal information.

Actor-based IoT Middleware: The security support for theactor based IoT middleware, e.g., Ptolemy Accessor Host[82], is still in the very early stage of development. Terraswamhas identified the importance of security, privacy and trustissues in their whitepaper in 2012 [83]. However, the solutionshave not been yet built into the systems. Calvin [33] alsoidentified security as a major issue, but it is still workingtowards it. Another actor-based middleware, Node-RED, is bydefault not secured; anyone who can access the IP addressand port can access the editor and deploy the changes. IBM isdeveloping a more secure solution by building the Watson IoTPlatform in Bluemix which allows devices to connect securelyusing a unique combination of client ID and authenticationtoken over TLS V1.2.


In summary, we concur with the observations made by Fre-mantle and Scott [72] that the existing middleware platformscan be categorized into three groups as follows:

• Middleware platforms that do not address security, pri-vacy and trust such as Calvin and Node-RED,

• Middleware platforms that address the security issues tosome extent such as Hydra, Virtus and Webinos, and

• Middleware platforms that offer theoretical models orwhite paper, but have not demonstrated any real-worldimplementation or concrete approaches such as OpenIoTand Ptolemy Accessor host.

Furthermore, the security mechanisms supported by themiddleware heavily rely on the underlying protocols. For ex-ample, LinkSmart uses SOAP/Web services model of security,VIRTUS uses XMPP standards and Webinos utilizes policy-based access control (XACML) and Federated Identity tokens(OpenID). It is important to note that these protocols are notdesigned for a resource-constrained environment (like IoT) andhence could be too costly both in memory and time.

3) Open Problems and Suggested Solutions: Fremantle andScott [72] have identified the following gaps in the exist-ing middleware platforms: (a) lack of privacy-by-design inthe middleware systems, (b) context-based security, (c) user-centric model of access control, and (d) support for federatedidentity at the device level. In addition to these, there are anumber of other issues related to security, privacy and trustthat need to be addressed. In the following, we discuss someopen issues and possible solutions.

Lightweight device authentication: IoT typically operatesin a resource-constrained environment such as low-bandwidthcommunication between nodes, low energy, small memoryand slow CPU cycles. These characteristics directly impactthe security, privacy and trust solutions designed for suchan environment. For example, the use of small packets inIEEE 802.15.4 may result in fragmentation of security protocoland may open new attack vectors. Similarly, limitations ofCPU and memory put severe restrictions on the utility of theresource-demanding public-key cryptography as used in theInternet security. There are a number of light-weight publickey cryptographic techniques that have been developed toovercome this problem. NTRU [84], ECC [85] and AE [86] areexamples of such cryptographic techniques. Further researchis needed in this area. The question from the middlewareperspective is how these light-weight security mechanisms canbe incorporated into the IoT middleware.

Denial-of-service attacks: The memory and processing con-straints also lead to new form of denial-of-service attacksthrough resource exhaustion. The attacks may go unnoticeduntil the services become unavailable. A number of defensemechanisms have been developed for such attacks such asDTLS [87], HIP [88] and their variants. Despite these solutionsproposed to address the problem, the issue remains open forfurther research. None of the middleware solutions reported inthe literature considers this problem and potential solutions intheir design.

End-to-end security: The gap between the Internet proto-

cols (IPV6) and the light-weight IoT protocols (6LoWPAN)makes it difficult to achieve end-to-end security in the IoTenvironment. Though 6LoWPAN [89] and CoAP [90] progresstowards reducing the gap by compressing IPV6 packets, therestill remains the subtle difference. The protocol translations atgateways might not work with the existing security solutions.First, the relevant information for translation is encrypted andmight not be available to gateways. Second, the changes madeat the gateways might invalidate the end-to-end data integrityprotection. A number of solutions have been proposed towardsaddressing this such as sharing keys with gateways, selectiveprotection, transformation independent message authentica-tion, etc. However, it still remains as a challenging problem,and needs further work. The middleware can play a significantrole to alleviate this problem. Furthermore, achieving securityat the IoT edges is challenging for two reasons. First, thetraditional perimeter defense does not work when the edges aredistributed in the unprotected environment. Second, the clouddata center cannot expose itself to the end devices. Some of thetechniques that could potentially solve these problems includesoftware defined perimeter, zero trust, and deperimeterization:though they are at the early stage of the development.

In summary, IoT middleware needs to be designed withsecurity, privacy and trust as first class citizens rather thanafter-thought. It should satisfy key security properties in alllayers in the IoT architecture, for all entities including endusers and devices. Furthermore, the underlying techniques alsoneed to satisfy the constrains imposed by the IoT environmentincluding big data, low powered devices, smaller processors,etc. To date, existing approaches tend to adapt availablesolutions for existing middleware as an after-thought. Such apatchwork approach is not going to satisfy the needs of ever-growing IoT applications. Hence, building trustworthy IoTmiddleware is still an open research and development problem.We believe emerging techniques such as privacy-by-design,differential privacy, and light-weight public-key cryptographywill form the building blocks of such IoT middleware solu-tions.

VI. RELATED WORK

The Internet of Things (IoT) has become a vibrant andrapidly expanding area of research and development over thelast few years. A number of surveys have been conducted onIoT middleware. The types of middleware covered in these sur-veys vary considerably, and rapid technological advancementsand new products bring new challenges and opportunities. Themajority of existing survey papers cover only the wirelesssensor network domain, while others concentrate on semanticand service-based frameworks, and a small minority coversonly the hardware or protocol level middleware solutions. Inthis section, we briefly overview these surveys.

Bandyopadhyay et al. [13] propose key functional blocks forservice-based IoT middleware, including interoperation, con-text detection, device discovery and management, security andprivacy, and persistency management. The authors provide aclassification of ten existing IoT middleware systems based onthe proposed functional blocks and concentrate on how those


middleware systems provide adaptations. The main conclusiondrawn from the survey is that context-awareness, security andprivacy, and interoperation are the least supported functionalblocks among the surveyed middleware systems. Chaqfehet al. [14] investigated the major challenges and solutionsin IoT middleware. The identified list of challenges includeinteroperability, scalability, device abstraction, spontaneousinteraction, unfixed infrastructure, multiplicity, and securityand privacy. The authors classify the existing solutions intothree domains: Semantics Web and Web services, RFID andSensors Networks, and Robotics-based systems. The authorsargue that Semantic Web and Web service IoT middlewarecould address all the listed challenges except the scalability ofpersistence service. We concur that Semantic Web is a viablesolution for addressing service discovery and composition inIoT. However, it is a heavy-weight solution for resource-constrained IoT devices.

Teixeria et al. [15] focus on the challenges associated withservice-oriented IoT middleware and propose a solution forservice discovery and data composition using a probabilisticapproach to deal with the problems of scale, unknown serviceavailability and data inaccuracies. The work is part of theEC-funded project CHOReOS (Large Scale Choreographiesfor the Future Internet). Finally, a very recent survey byRazzaque et al. [12] provides a comprehensive overview ofIoT middleware, focusing on the requirements of a varietyof middleware types, and exploring some of the challengesrelated to these requirements. The requirements are groupedinto two general categories: middleware service requirements(functional and nonfunctional) and architectural requirements.Each of the challenges is discussed at a high-level withoutdelving on how they have been addressed by some of themost popular middleware used in practice today.

To the best of our knowledge, none of these existing surveysaddresses the more recent trend of light-weight plug-and-play or cloud-based IoT middleware. Our work is the firstIoT middleware survey that emphasizes on the architecturalpatterns with emphasis on empowering users to create innova-tive IoT applications targeted for ambient data collection andanalysis. We attempt to explore in depth those architecturalcharacteristics that can make each middleware type suitableor unsuitable for a variety of applications, and the featuresthat might enable or hinder wide user adoption, especially inthe case of users with low programming experience.

VII. CONCLUSION

The World Wide Web has gone through many transfor-mations, from traditional linking and sharing of computersand documents, to a platform for conducting businesses andconnecting people via social media, and now the emergingparadigm of connecting billions of physical objects (Internet ofThings) to empower human interaction with both the physicaland virtual worlds in an unprecedented way. In this surveypaper, we have analyzed three key IoT middleware archi-tectures ranging from consumer-centric cloud-based architec-tures, light-weight actor-based architectures, and heavy-weightservice-based architectures. We outlined four key challenges

in developing an IoT middleware which are: 1) a light-weightmiddleware platform that can provide similar services whendeployed on power constrained IoT devices as well as indesktop computers and cloud infrastructure; 2) a compositionengine that is intuitive and not application specific; 3) asecurity mechanism that can operate in a resource constrainedenvironment and yet can achieve similar guarantee as Internetsecurity; and 4) a semantic-based IoT device/service discoverythat goes beyond discovery of domain names and IP addresses.

We elaborate on two non-ontological solutions for address-ing key challenges in IoT service discovery. The first approachis adapted from existing works in Web service search enginesand the second approach is based on machine learning and rec-ommendation techniques. Finally, in the IoT security domain,we believe emerging techniques such as privacy-by-design,differential privacy, and light-weight public-key cryptographywill form the building blocks for security in IoT middleware.

ACKNOWLEDGMENTS

The majority of this work was performed while the firstauthor was visiting CSIRO, Sydney, Australia. The work onaccessors was performed while the first author was visitingProfessor Edward Lee and Christopher Brooks at the Uni-versity of California, Berkeley. The Smartwatch work wasfunded by the National Science Foundation under the ResearchExperiences for Undergraduates Program (CNS-1358939) atTexas State University and the infrastructure for the smart-watch project was provided by a NSF-CRI 1305302 award.

REFERENCES

[1] D. Raggett, “The Web of Things: Challenges and Opportunities,” IEEEComputer, vol. 48, no. 5, pp. 26–32, May 2015.

[2] R. Want, B. N. Schilit, and S. Jenson, “Enabling the Internet of Things,”IEEE Computer, vol. 48, no. 1, pp. 28–35, 2015.

[3] L. Baresi, L. Mottola, and S. Dustdar, “Building Software for the Internetof Things,” IEEE Internet Computing, vol. 19, no. 2, pp. 6–8, 2015.

[4] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,”Computer Networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[5] L. Yao, Q. Z. Sheng, and S. Dustdar, “Web-based Management of theInternet of Things,” IEEE Internet Computing, vol. 19, no. 4, pp. 60–67,July/August 2015.

[6] Y. Qin, Q. Z. Sheng, N. J. G. Falkner, S. Dustdar, H. Wang, and A. V.Vasilakos, “When Things Matter: A Survey on Data-Centric Internet ofThings,” Journal of Network and Computer Applications, vol. 64, pp.137–153, 2016.

[7] K. Aberer, M. Hauswirth, and A. Salehi, “A middleware for fastand flexible sensor network deployment,” in Proceedings of the 32ndInternational Conference on Very Large Data Bases, ser. VLDB’06. VLDB Endowment, 2006, pp. 1199–1202. [Online]. Available:http://dl.acm.org/citation.cfm?id=1182635.1164243

[8] E. Latronico, E. Lee, M. Lohstroh, C. Shaver, A. Wasicek, and M. Weber,“A vision of swarmlets,” Internet Computing, IEEE, vol. 19, no. 2, pp.20–28, Mar 2015.

[9] Google Fit, 2015, https://developers.google.com/fit/.[10] Architectural Styles and Design of Network-based Software Architec-

tures, 2000, www.ics.uci.edu/∼fielding/pubs/dissertation/top.htm.[11] T. Zachariah, M. Klugman, B. Campbell, J. Adkins, N. Jackson, and

P. Dutta, “The internet of things has a gateway problem,” in HotMobile.Santa Fe, New Mexico, USA: ACM, February 2015.

[12] M. Razzaque, M. Milojevic-Jevric, A. Palade, and S. Clarke, “Middle-ware for internet of things: a survey,” IEEE International of ThingsJournal, vol. 3, no. 1, pp. 70–95, 2016.


[13] S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta, Recent Trendsin Wireless and Mobile Networks: Third International Conferences,WiMo 2011 and CoNeCo 2011, Ankara, Turkey, June 26-28, 2011.Proceedings. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011,ch. A Survey of Middleware for Internet of Things, pp. 288–296.[Online]. Available: http://dx.doi.org/10.1007/978-3-642-21937-5 27

[14] M. A. Chaqfeh and N. Mohamed, “Challenges in middleware solutionsfor the internet of things,” in International Conference on CollaborationTechnologies and Systems (CTS 2012), 2012. IEEE, May 2012, pp. 21–26.

[15] T. Teixeira, S. Hachem, V. Issarny, and N. Georgantas, “Service orientedmiddleware for the internet of things: a perspective,” in Towards aService-Based Internet. Springer, 2011, pp. 220–229.

[16] G. Mario, F. Michelle, N. Anne, and G. Byron, “Real-time predictionof blood alcohol content using smartwatch sensor data,” in IEEEInternational Conference on Smart Health. Phoneix, Arizona: Springer,November 2015.

[17] M. P. Papazoglou and D. Georgakopoulos, “Introduction: Service-oriented computing,” Commun. ACM, vol. 46, no. 10, pp. 24–28, Oct.2003. [Online]. Available: http://doi.acm.org/10.1145/944217.944233

[18] J. Soldatos, N. Kefalakis, M. Hauswirth, M. Serrano, J.-P. Calbimonte,M. Riahi, K. Aberer, P. Jayaraman, A. Zaslavsky, I. Zarko, L. Skorin-Kapov, and R. Herzog, “Openiot: Open source internet-of-thingsin the cloud,” in Interoperability and Open-Source Solutions forthe Internet of Things, ser. Lecture Notes in Computer Science,I. Podnar Zarko, K. Pripuzic, and M. Serrano, Eds. SpringerInternational Publishing, 2015, vol. 9001, pp. 13–25. [Online].Available: http://dx.doi.org/10.1007/978-3-319-16546-2 3

[19] The TerraSwarm Research Center, 2013, https://terraswarm.org.[20] Nest, 2014, https://developer.nest.com.[21] IoT Related projects, 2015, https://www.terraswarm.org/terraswarm/

wiki/Main/RelatedProjects.[22] M. Eisenhauer, P. Rosengren, and P. Antolin, “A development platform

for integrating wireless devices and sensors into ambient intelligencesystems,” in Sensor, Mesh and Ah Hoc Communications and NetworksWorkshops, SECON 2009, ser. 978-1-4244-3938-6, IEEE Communica-tion Society Conference. Rome: IEEE, 2009.

[23] HYDRA, 2010, http://hydramiddleware.eu.[24] Global Sensor Networks, 2004, http://lsir.epfl.ch/research/current/gsn/.[25] R. M.-H. Bill Burke, Enterprise Java Beans 3.0. OReilly, 2006.[26] J.-P. Calbimonte, S. Sami, J. Eberle, and K. Aberer, “Xgsn: An open-

source semantic sensing middleware for the web of things,” in 7thInternational Workshop on Semantic Sensor Networks, R. del Garda,Ed., Trentino, Italy, October 2014.

[27] Xively, 2014, http://xively.com.[28] A. Pintus, D. Carboni, and A. Piras, “Paraimpu: A platform for

a social web of things,” in Proceedings of the 21st InternationalConference on World Wide Web, ser. WWW ’12 Companion. NewYork, NY, USA: ACM, 2012, pp. 401–404. [Online]. Available:http://doi.acm.org/10.1145/2187980.2188059

[29] Paraimpu, 2014, https://www.paraimpu.com.[30] Tornado Web Server, 2015, www.tornadoweb.org/en/stable.[31] Open Source Web Server Load Balancer, 2015, https://www.nginx.com/

products/.[32] MongoDB Documentation, 2015, https://docs.mongodb.com/manual/

reference/database-references/.[33] P. Persson and O. Angelsmark, “Calvin – merging cloud and iot,”

Procedia Computer Science, vol. 52, pp. 210 – 217, 2015, the6th International Conference on Ambient Systems, Networks andTechnologies (ANT-2015), the 5th International Conference on Sustain-able Energy Information Technology (SEIT-2015). [Online]. Available:http://www.sciencedirect.com/science/article/pii/S1877050915008595

[34] Node-RED, A visual tool for wiring the Internet of Things, 2015, http://nodered.org.

[35] Ptolemy II, 1996, http://ptolemy.eecs.berkeley.edu.[36] Kepler Scientific Workflow Engine, 2011, https://kepler-project.org.[37] P. Barnaghi, A. Sheth, and C. Henson, “From Data to Actionable Knowl-

edge: Big Data Challenges in the Web of Things,” IEEE IntelligentSystems, vol. 28, no. 6, pp. 6–11, Nov 2013.

[38] D. Niewolny, “How the internet of things is revolutionizing healthcare,”White paper, 2013.

[39] P. P. Jayaraman, D. Palmer, A. Zaslavsky, and D. Georgakopoulos, “Do-it-yourself digital agriculture applications with semantically enhancediot platform,” in Intelligent Sensors, Sensor Networks and InformationProcessing (ISSNIP), 2015 IEEE Tenth International Conference on.IEEE, 2015, pp. 1–6.

[40] S. Sicari, A. Rizzardi, L. A. Grieco, and A. Coen-Porisini, “Security,privacy and trust in internet of things: The road ahead,” ComputerNetworks, vol. 76, pp. 146–164, 2015.

[41] Linked Sensor Middleware (LSM), 2014, httpL//open-platforms.eu/library/deri-lsm/.

[42] Sensor Model Language (SensorML), 2012, http://www.opengeospatial.org/standards/sensorml.

[43] H. Wang, C. C. Tan, and Q. Li, “Snoogle: A Search Engine for PervasiveEnvironments,” IEEE Trans. Parallel and Distributed Systems, vol. 21,no. 8, pp. 1188–1202, 2010.

[44] C. C. Tan, B. Sheng, H. Wang, and Q. Li, “Microsearch: A SearchEngine for Embedded Devices Used in Pervasive Computing,” ACMTrans. Embedded Computing Systems, vol. 9, no. 4, 2010.

[45] K. Yap, V. Srinivasan, and M. Motani, “MAX: Wide Area Human-Centric Search of the Physical World,” ACM Trans. on Sensor Networks(TOSN), vol. 4, no. 4, 2008.

[46] B. Ostermaier, K. Romer, F. Mattern, M. Fahrmair, and W. Kellerer,“A Real-Time Search Engine for the Web of Things,” in Proc. of theInternational Conference on the Internet of Things (IOT 2010), Tokyo,Japan, 2010.

[47] P. P. Jayaraman, J.-P. Calbimonte, and H. N. M. Quoc, “The schemaeditor of openiot for semantic sensor network,” in Semantic Sensor andNetworks And Terra Cognita (SSN-TC2015), Bethlehem, Pennsylvania,October 2015.

[48] X. Dong, A. Halevy, J. Madhavan, E. Nemes, and J. Zhang, “Similaritysearch for web services,” in VLDB, 2004, 2004.

[49] Y. Zhang, Z. Zheng, and M. Lyu, “Wsexpress: a qos-aware search enginefor web services,” in ICWS, 2010, 2010.

[50] J. Wu, L. Chen, Y. Xie, and Z. Zheng, “Titan: a system for effectiveweb service discovery,” in WWW, 2012, 2012.

[51] A. H. Ngu, S. Julian, Quan, and L. Yao, “A similarity-based web servicesearch engine,” in ACM Conference on Information Retrieval (SIGIR2014). Gold Coast, Australia: ACM, July 2014.

[52] L. Yao, Q. Z. Sheng, A. H. Ngu, and X. Li, “Things of InterestRecommendation by Leveraging Heterogeneous Relations in the Internetof Things,” ACM Transactions on Internet Technology (TOIT), vol. 16,no. 2, 2016.

[53] L. Yao, Q. Zheng, N. J. Falkner, and A. H. Ngu, “ThingsNavi: FindingMost-Related Things via Multi-diminesional Modeling of Human-ThingInteractions,” in 12th International Conference on Mobile and Ubiqui-tous Systems: Computing, Networking and Services (MobiQuitous2014),London, Great Britain, 2014.

[54] J. Jang-Jaccard and S. Nepal, “A survey of emerging threats in cyber-security,” Journal of Computer and System Sciences, vol. 80, no. 5, pp.973–993, 2014.

[55] J. Lopez, R. Roman, and C. Alcaraz, “Analysis of security threats,requirements, technologies and standards in wireless sensor networks,”in Foundations of Security Analysis and Design V. Springer, 2009, pp.289–338.

[56] R. H. Weber, “Internet of things–new security and privacy challenges,”Computer Law & Security Review, vol. 26, no. 1, pp. 23–30, 2010.

[57] J. H. Ziegeldorf, O. G. Morchon, and K. Wehrle, “Privacy in theinternet of things: threats and challenges,” Security and CommunicationNetworks, vol. 7, no. 12, pp. 2728–2742, 2014.

[58] C. Dwork, “Differential privacy: A survey of results,” in Theory andapplications of models of computation. Springer, 2008, pp. 1–19.

[59] M. Langheinrich, “Privacy by designprinciples of privacy-aware ubiq-uitous systems,” in Ubicomp 2001: Ubiquitous Computing. Springer,2001, pp. 273–291.

[60] B. Fung, K. Wang, R. Chen, and P. S. Yu, “Privacy-preserving datapublishing: A survey of recent developments,” ACM Computing Surveys(CSUR), vol. 42, no. 4, p. 14, 2010.

[61] M. Burrows, M. Abadi, and R. M. Needham, “A logic of authentication,”in Proceedings of the Royal Society of London A: Mathematical,Physical and Engineering Sciences, vol. 426, no. 1871. The RoyalSociety, 1989, pp. 233–271.

[62] S. Cirani, M. Picone, P. Gonizzi, L. Veltri, and G. Ferrari, “Iot-oas: Anoauth-based authorization service architecture for secure services in iotscenarios,” Sensors Journal, IEEE, vol. 15, no. 2, pp. 1224–1234, 2015.

[63] D. J. Weitzner, H. Abelson, T. Berners-Lee, J. Feigenbaum, J. Hendler,and G. J. Sussman, “Information accountability,” Communications of theACM, vol. 51, no. 6, pp. 82–87, 2008.

[64] R. Roman, J. Zhou, and J. Lopez, “On the features and challengesof security and privacy in distributed internet of things,” ComputerNetworks, vol. 57, no. 10, pp. 2266–2279, 2013.


[65] D. Kozlov, J. Veijalainen, and Y. Ali, “Security and privacy threats iniot architectures,” in Proceedings of the 7th International Conference onBody Area Networks. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2012, pp. 256–262.

[66] M. Abomhara and G. M. Koien, “Security and privacy in the internetof things: Current status and open issues,” in Privacy and Security inMobile Systems (PRISMS), 2014 International Conference on. IEEE,2014, pp. 1–8.

[67] S. Bandyopadhyay, M. Sengupta, S. Maiti, and S. Dutta, “A survey ofmiddleware for internet of things,” in Recent Trends in Wireless andMobile Networks. Springer, 2011, pp. 288–296.

[68] M. Eisenhauer, P. Rosengren, and P. Antolin, “Hydra: A developmentplatform for integrating wireless devices and sensors into ambientintelligence systems,” in The Internet of Things. Springer, 2010, pp.367–373.

[69] K. Aberer, M. Hauswirth, and A. Salehi, “A middleware for fastand flexible sensor network deployment,” in Proceedings of the 32ndinternational conference on Very large data bases. VLDB Endowment,2006, pp. 1199–1202.

[70] L. M. S. De Souza, P. Spiess, D. Guinard, M. Kohler, S. Karnouskos,and D. Savio, “Socrades: A web service based shop floor integrationinfrastructure,” in The internet of things. Springer, 2008, pp. 50–67.

[71] R. J. C. BENITO, D. G. MARQUEZ, P. P. TRON, R. R. CASTRO,N. S. MARTIN, and J. L. S. MARTIN, “Smepp: A secure middlewarefor embedded p2p,” Proceedings of ICT-MobileSummit, vol. 9, 2009.

[72] P. Fremantle and P. Scott, “A security survey of middleware for theinternet of things,” PeerJ PrePrints, vol. 3, p. e1521, 2015.

[73] P. Kostelnik, M. Sarnovsk, and K. Furdik, “The semantic middlewarefor networked embedded systems applied in the internet of thingsand services domain,” Scalable Computing: Practice and Experience,vol. 12, no. 3, pp. 307–316, 2011.

[74] A. Ekelhart, S. Fenz, G. Goluch, M. Steinkellner, and E. Weippl,“Xml security–a comparative literature review,” Journal of Systems andSoftware, vol. 81, no. 10, pp. 1715–1724, 2008.

[75] J.-P. Calbimonte, H. Y. Jeung, O. Corcho, and K. Aberer, “Enablingquery technologies for the semantic sensor web,” International Journalon Semantic Web and Information Systems, vol. 8, no. EPFL-ARTICLE-183971, pp. 43–63, 2012.

[76] J.-P. Calbimonte, S. Sarni, J. Eberle, and K. Aberer, “Xgsn: An open-source semantic sensing middleware for the web of things,” TerraCognita and Semantic Sensor Networks, p. 51, 2014.

[77] J.-P. Calbimonte, M. Riahi, and A. Zaslavsky, “Privacy and securityframework. openiot deliverable d522,” Tech. Rep., 2014.

[78] D. Conzon, T. Bolognesi, P. Brizzi, A. Lotito, R. Tomasi, and M. A.Spirito, “The virtus middleware: An xmpp based architecture for se-cure iot communications,” in Computer Communications and Networks(ICCCN), 2012 21st International Conference on. IEEE, 2012, pp. 1–6.

[79] S. Nepal and M. Pathan, Security, Privacy and Trust in Cloud Systems.Springer, 2014.

[80] H. Desruelle, J. Lyle, S. Isenberg, and F. Gielen, “On the challenges ofbuilding a web-based ubiquitous application platform,” in Proceedingsof the 2012 ACM Conference on Ubiquitous Computing. ACM, 2012,pp. 733–736.

[81] T. Moses et al., “Extensible access control markup language (xacml)version 2.0,” Oasis Standard, vol. 200502, 2005.

[82] E. Latronico, E. A. Lee, M. Lohstroh, C. Shaver, A. Wasicek, andM. Weber, “A vision of swarmlets,” Internet Computing, IEEE, vol. 19,no. 2, pp. 20–28, 2015.

[83] D. Blaauw, P. Dutta, K. Fu, C. Guestrin, R. Jafari, D. Jones, J. Kubia-towicz, V. Kumar, E. A. Lee, R. Murray, G. Pappas, J. Rabaey, A. Rowe,A. Sangiovanni-Vincentelli, C. M. Sechen, S. A. Seshia, T. S. Rosing,B. Taskar, J. Wawrzynek, and D. Wessel, “The terraswarm researchcenter (tsrc): White paper,” 2012.

[84] J. Hoffstein, J. Pipher, and J. H. Silverman, “Nss: An ntru lattice-basedsignature scheme,” in Advances in CryptologyEurocrypt 2001. Springer,2001, pp. 211–228.

[85] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, and R. Dahab,“Nanoecc: Testing the limits of elliptic curve cryptography in sensornetworks,” in Wireless sensor networks. Springer, 2008, pp. 305–320.

[86] I. Anshel, M. Anshel, D. Goldfeld, and S. Lemieux, “Key agreement,the algebraic erasertm, and lightweight cryptography,” ContemporaryMathematics, vol. 418, pp. 1–34, 2007.

[87] D. McGrew and E. Rescorla, “Datagram transport layer security (dtls)extension to establish keys for the secure real-time transport protocol(srtp),” 2010.

[88] A. Gurtov, Host identity protocol (HIP): towards the secure mobileinternet. John Wiley & Sons, 2008, vol. 21.

[89] Z. Shelby and C. Bormann, 6LoWPAN: The wireless embedded Internet.John Wiley & Sons, 2011, vol. 43.

[90] Z. Shelby, K. Hartke, and C. Bormann, “The constrained applicationprotocol (coap),” 2014.

Date post:	25-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

IEEE INTERNET OF THINGS JOURNAL, VOL. X, NO. X, MARCH …cs.txstate.edu/~hn12/IOTSurvey.pdf · IEEE...

Documents