Consumer-oriented wearable sensors such as smart watches are becoming popular, but each manufacturer uses its own data accessmechanism. At the same time, the need for inferred context data is increasing in context-aware applications. A system is needed toprovide a unified access to heterogeneous wearable devices for context-aware application developers. We propose ManySense—anAndroid-basedmiddleware for heterogeneous consumer-oriented BSNs. Extensibility is achieved through adapter interfaces whichallow sensors and context inferencing algorithms to be coupled with the middleware. Accessibility of the middleware allows thirdparty applications to access raw sensor data and inferred context data uniformly.This paper provides twomain contributions whichare divided into several outcomes: (1) design and implementation of theManySense BSNmiddleware that allows low-effort additionof new sensors and context inferencing algorithms through adapter interfaces, provides unified access to optionally filtered sensordata and inferred context data for third party applications, mediates control queries to sensor adapters and context inferencingadapters, and facilitates adapter development through an SDK and (2) evaluation of ManySense by comparing its performancewith manual sensor data acquisition, analysis of ManySense’s extensibility through adapter interfaces, and analysis of ManySense’saccessibility from third party applications.
1. Introduction
Recent advances in ubiquitous technology have enabled anew wave of consumer-oriented wearable sensor devices thatmonitor different aspects of a human body such as heartrate, temperature, perspiration and motion. Several globalconsumer technology companies have embraced the ideaof body-awareness that could finally fulfill Mark Weiser’svision of truly ubiquitous computing [1] from the humanbody perspective. There are many off-the-shelf productsthat can be used by anyone for personal body monitoring.Current trend of smartwatches and activity trackers is anexample of this, but it is merely a preview of what futurewearable technologies could be. Most smartwatches andother wearable technologies possess useful features such asmini applications, sensors, and wireless communications, yetthey have not become killer devices of ubiquitous computing.
A combination of wearable sensors can form a bodysensor network (BSN) for gathering versatile information on
bodily functions. Researchers have applied BSNs especiallyin healthcare [2–8], but also other domains have beenresearched such as sport and fitness [9–12], transportation[13], social networking [14–16], and gaming [17–19]. Onechallenge in many previous BSN systems is that they supportdata collection through a fixed sink node using a specificprotocol such as ZigBee. Such setup is based on a homo-geneous set of compatible devices. Combining data fromheterogeneous devices such as smartphone, smartwatch, andheart rate monitor can enable a higher degree of body-awareness, but it bears a cost of data aggregation complexity.Another challenge is that body sensors used in researchprojects are often prototypes or highly specialized medicalsensors that are not easily available to the end users. On thecontrary, the end user might possess heterogeneous off-the-shelf devices from different vendors that are not compatiblewith each other. To illustrate what these challenges meanin practice, let us consider a sport enthusiast who ownsa Zephyr heart rate monitor, a Sony smartwatch and a
Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2014, Article ID 321534, 15 pageshttp://dx.doi.org/10.1155/2014/321534
2 International Journal of Distributed Sensor Networks
smartphone. Currently, he has to use different vendor-specificapplications on his smartphone to access each devices’ dataat runtime. The situation gets even more complicated if theuser also wants to follow his physical location using hissmartphone’s GPS. Assuming that the user has experiencewith software development, he could build a smartphoneapplication that could gather data from each device andprocess it as appropriate. However, this is not a flexiblesolution because upon device replacement or addition theuser would need tomodify the software to accommodate newdata sources. Furthermore, other users would have to repeatthe same steps in order to develop software for their personaldevices.
The aforementioned scenario illustrates the need formiddleware architecture that is able to aggregate and pro-cess wearable sensor data from heterogeneous sources andprovide access to the data for other applications, such asgames, medical monitors, and performance analyzers. Thedata provided by the middleware should be available inmultiple modalities from raw data to filtered data to contextdata carrying semantic value such as the user’s activity. Thisway the third party application developers can choose anappropriate modality for their applications. The middlewareshould also allow flexible addition of new devices, sensors,and context inferencing algorithms with minimal changes toother components. Following these requirements, to solve thechallenges of previous BSN systems, we propose ManySenseBSN middleware for Android devices that not only supportsmultiple heterogeneous off-the-shelf wearable sensors butcan also be extended by adding adapters for new sensorsand context inferencing algorithms. ManySense provides aunified access to (a) raw sensor data retrieved from bothinternal and external sensors and (b) high level context datawhich is based on the inferential analysis of raw data. It alsohas a filtering capability for improving raw data quality by,for example, removing noise. ManySense can be used by anyAndroid-based application that requires high quality sensorand context data from heterogeneous sources.
We start by describing related work on body sensornetworks and middleware. After justifying the need forManySense, we present its design and implementation withdetailed description of the adapter interfaces that makeManySense extensible. We then evaluate and analyze Many-Sense from three perspectives. First, its performance (loadhandling, CPU, RAM, and power) is measured. Second,the adapter interfaces’ flexibility is analyzed by discussingthe process of creating new adapters. Third, ManySense’saccessibility is analyzed by coupling it with Calory BattleAR—an augmented reality exergame—and utilizing sensordata to implement a new game activity. Implications of thestudy are then discussed and conclusions are made.
2. Background
2.1. Body Sensor Networks. In this paper, we propose theManySense body sensor network (BSN) middleware to beused in context-aware Android applications that requireheterogeneous data sources such as wearable sensors. A
BSN (sometimes referred to as body area network (BAN))typically consists of small, portable, wireless, and energy-efficient sensor nodes that are deployed on or inside a humanbody. The types of sensors depend on the target application.For example, in healthcare applications a BSN might consistof sophisticated medical sensors such as ECG, SpO
2, blood
pressure, and blood sugar, whereas an athlete might use aBSN with accelerometers, pressure sensors, and a heart ratemeter. A common goal for most BSN-based systems is thatthey enable unobtrusive collection, analysis, distribution, andmanagement of body signals regardless of time and place.
BSNs based on ZigBee or Bluetooth have been widelyused for bodily context detection in health and wellnessapplications. A wireless sensor network developed in theCodeblue [3] project provides routing, naming, discovery,and security for wireless medical sensors, PDAs, PCs, andother devices that may be used for monitoring and treatingpatients in network environments of various densities. In-home monitoring [4] is a ubiquitous healthcare system forreal-time monitoring of patients’ locations with GPS andtheir vital signs with wearable ZigBee sensors. ECG (electro-cardioGram) monitoring systems [5, 6] aim to monitorelectrical activity of a human’s heart in real time with an ECGsensor, an ECG console, and a ZigBee module. ECG datacollected from a sensor network is transmitted to a serverthrough a gateway. In many BSN systems, a sink node iscoupled with a Bluetooth module for communicating with aBluetooth-enabled gateway device. LifeGuard [20] is a vitalsign monitoring system for astronauts. It uses a wearablewired sensor kit that communicates with a Tablet PC viaBluetooth. In another example [21], a mobile phone actsas a gateway which connects between sensor nodes and aCDMA network or other devices having Bluetooth support.Viswanathan et al. [22] proposed a distributed resourceprovision framework in which nearby computing devices(laptops, tablets, and PDAs) use Bluetooth or ZigBee tocollect and preprocess data before sending it further.
Based on our analysis of existing BSN systems, typicalBSN middleware architecture is based on a layered model(Figure 1) comprising four or more layers. The BSN layertakes care of context sensing using a variety of sensors whichmeasure properties of a human body such as movement,heart rate, or oxygen saturation. Data collected by the BSNlayer is transported to the Gateway layer over a short-rangecommunication protocol such as ZigBee or Bluetooth. TheGateway layer is represented by devices of limited processingpower such as smartphones, laptops, or set-top boxes. Thesedevices operate as gateways aggregating and preprocessing(e.g., noise filtering) data before sending them over the inter-net to the Backend layer. The Gateway layer may cache thedata locally for quick access, visualization, data analysis, andcontext inference. Some gateways are also capable of sendingcontrol messages back to the BSN nodes. The Backend layeracts as a central repository for data collected from multipledeployed BSNs. It may provide advanced data analysis toolsand interfaces for the Presentation layer. The Presentationlayer offers multiple means of accessing, visualizing, andmanipulating data by stakeholders including but not limitedto users, healthcare professionals, and sport coaches. Data
International Journal of Distributed Sensor Networks 3
(1) BSNContext sensing
Bluetooth,
USBZigBee,
(2) GatewayAggregation, preprocessing, analysisRaw data
Control messages
(3) BackendStorage and analysis Internet
web protocols,customprotocol
(4) PresentationData access, visualization,
manipulation
Figure 1: Generic layered architecture for BSN systems.
compression and encryption techniques can be applied tointerlayer communication to reduce required bandwidth andprotect privacy.
2.2. Middleware for BSNs. Middleware is a crucial elementin any distributed system for providing abstraction of low-level programming routines and for unifying access toheterogeneous services and resources. While many existingBSN systems are based on homogeneous and specializedsensor nodes, there have been attempts to create middle-ware supporting heterogeneous off-the-shelf sensor devices.KNOWME [7] aggregates data from off-the-shelf ECG,accelerometer, GPS, and SpO
2sensors using the Nokia N95
smartphone. The system estimates energy expenditure bydetecting user activity through feature extraction from sensorreadings. Activity detection can be accomplished eitherinside the middleware or on a remote server. KNOWMEsupports only a limited set of sensors for healthcare purposesand to our knowledge, it has no flexible structure to add newsensor device types. Furthermore, there is no way for thirdparty applications to subscribe for receiving sensor data fromthe middleware. Finally, N95 is an obsolete platform today.Park and Pak [8] proposed an integrated gateway architectureto collect data from various personal health devices (PHD,ISO/IEEE 11073) using a range of communication methodssuch as ZigBee, Bluetooth, and USB. The system only sup-ports standardPHDdevices andhas noway ofmediating datato other applications.
Aforementioned middleware are nonadaptive becausethey are limited to a specific set of sensors. To overcome thislimitation, researchers have created adaptive middlewareswhich facilitate extensibility by supporting addition of newsensor devices. A lightweight adaptive BSN middleware isproposed in [23] for medical applications. This middlewaresupports dynamic addition of new sensor nodes based onTinyOS, security features, and on-the-fly sensor reconfig-uration by control messages. The architecture is dividedinto lower middleware comprising wireless sensor nodes(nesC) and upper middleware which runs on a PDA (Java2 Micro Edition, J2ME). The authors created a prototypeimplementation of the middleware which neither supports
heterogeneous sensor devices nor allows other applicationsto subscribe to sensor events. Furthermore, J2ME platformon PDAs is obsolete today. MiddleWhere [24] is an adapter-based middleware to solve the problem of heterogeneity andextensibility. It uses multiple sources of location informationin order to determine the user’s indoor location accurately.Adapter interface allows different sources of location data tobe coupled with the system. While this approach makes thesystem extensible, it is limited to a single purpose. As the lastexample, SIXTH [25] is an Android-based middleware thattakes a flexible approach to middleware design by utilizingthe standardized OSGi (open services gateway initiative)component framework as the platform. OSGi allows newmodules to be added at runtime, such as sensor adapterswhich extract data from different sensors. To add a newsensor type, a new adapter must be created and deployedto the OSGi service (Apache Felix) running on Android.If a third party component wishes to receive sensor dataupdates, it must implement an interface and register withthe OSGi service. In addition to sensor data retrieval, theSIXTH middleware also supports retasking through sendingcontrolmessages to sensors. UtilizingOSGimakes the systemhighly extensible, but it bears a cost of performance overheadand possible instability. Furthermore, only OSGi modulesimplementing a required interface can receive sensor data,thus leaving outAndroid systemswhich do not have theOSGiservice running.
In addition to collecting data from heterogeneoussources, an important function of a BSN middleware is theinferencing of higher level context data by fusing, trans-forming, and processing raw sensor data. A typical exampleof higher level context data in the case of BSNs is theuser’s activity which, once inferred, can be queried by thirdparty application developers. Recognizing the user’s activitytypically involves raw data from sensors such as accelerom-eter and GPS that are submitted to an inference algorithmwhich depends on the target application. For example, thedetection of whether the user is walking, running, or sittingbased on accelerometer data typically involves four stages:data collection, preprocessing (e.g., noise filtering), featureextraction, and classification [26]. If higher level of contextdata using a greater number of data sources is desired, amore sophisticated modeling and inferencing framework isneeded, such as object-oriented models, logic-based models,or ontologies [27].
There exists several BSN middlewares that offer somelevel of context inferencing. ACE is an energy-efficientmiddleware for Windows Phone that focuses on contextinferencing [28]. High level context data is inferred fromraw sensor data by rules. Other applications may use ACEto request context data such as “IsDriving” or “AtHome.”As ACE focuses on context inferencing, it does not sup-port heterogeneous wearable sources. Lara and Labradorproposed an Android-based system for real-time humanactivity recognition using phone GPS, phone accelerometer,and Zephyr’s BioHarness [29]. The user’s activity is inferredby the four-stage process as described above. The systemuses the authors’ MECLA library which contains several
4 International Journal of Distributed Sensor Networks
classification algorithms. Gu et al. [30] proposed a service-oriented context-aware middleware (SOCAM) which usesontology modeling to provide context inferencing servicesfor applications in home and vehicle environments. SOCAM’sinferencing logic is implemented on a server which acquiresraw data from physical sensor devices and external virtualsensors such as web services. Other applications (e.g., mobileand desktop) can request higher level context data fromthe middleware. As the last example, myHealthAssistant isa smartphone application that uses inertial body sensors tomonitor the user’s daily activities and gym exercises [12].Activity detection is based on an event-based middlewarerunning on the smartphone [31]. It supports heterogeneoussensor devices over HTTP and Bluetooth connections. Rawsensor data is transformed to events which are then usedby the central context inferencing module that detects theuser’s activity. The authors claim that the middleware hasmodular architecture, but it is unclear whether alternativecontext inferencing modules can be installed.
Previous BSN middlewares have some shortcomingsincluding lack of support for heterogeneous sensors, supportfor none or single context inferencing technique, lack ofpreprocessing tools such as data filtering, lack of a unifiedinterfaces for third party developers to access raw sensor dataand inferred context data, dependencies to other software,and obsolete platforms. In the following we describe thedesign and implementation of ManySense BSN middlewarefor Android which alleviates the challenges found in existingsystems by not only allowing easy addition of heterogeneoussensor devices and context inferencing algorithms throughadapter interfaces but also providing a single-point access toraw sensor data and inferred context data for any third partyAndroid application running on the same device.
3. System Design and Features
To keep the ManySense design flexible for future needs, ourdefinition of “sensor,” which follows the work of Gu et al.[30], does not only cover hardware-based physical sensorsbut also virtual sensors which include fusion sensors (e.g.,gravity, linear acceleration, and orientation) and external datasources (e.g., web services and other online data repositories).This broadened view of sensors allows ManySense to be usedin future applications that go beyond body context towardsenvironmental and social awareness.
There were several principles that were followed through-out the design process. First, the middleware should beextensible so that adding new physical and virtual sensorsas well as context inferencing algorithms would be easy. Thisis to make the middleware available for multiple purposes.Second, the middleware should encapsulate the implemen-tation of data acquisition and context inferencing behinda common interface. Third, other applications should beable to access the middleware to retrieve data in multiplemodalities including raw, filtered, and inferred data. Fourth,the middleware should be able to handle multiple requestsfrom different clients at the same time efficiently. Fifth, themiddleware should be able to change its configuration based
on the presence of sensors, but application developers shouldalso be able to control the middleware. Sixth, the middlewareshould provide tools (e.g., filters) for preprocessing raw data.Seventh, the middleware should provide data caching andremote storage services for further analysis and sharing.Finally, the middleware should be minimally dependenton other software. We utilized well-known software designpatterns (observer, singleton, adapter, template method, andfacade) to conform to these principles as well as to keep thesystem design encapsulated and loosely coupled [32].
Figure 2 illustrates the architecture of ManySense. Inthe center of the figure is the middleware which runsindependently in an Android background service to whichthe subscriber application must bind itself. The ManySenseservice is only alive if there are subscribers bound to it, thusreducing battery consumption when idle. Because Many-Sense runs as a background service, it does not have a userinterface except for a preferences screen that can be used toadjust parameters such as default intervals at which sensorssend updates, time-out times, or user names and passwordsrequired to access online sensor sources. At the bottom isthe subscriber application which communicates with themiddleware through a communication interface. To makethe middleware easily accessible to application developers,the communication interface handles the binding details,so the developers do not need to be concerned with it.On the ManySense side of the communication interface liesthe subscription handler which processes all applications’requests and directs them to the correct component (contextdata aggregator or raw data aggregator).
Raw sensor data is acquired through the raw data aggre-gator (RDA) which collects data from heterogeneous sensorsand distributes them to the subscribers. It communicateswithdifferent sensors through Sensor Adapters. When a SensorAdapter receives new data it publishes sensor events to theRDAwhich in turn forwards the data to the subscriberswhichare subscribed to that particular sensor’s data. The RDA canalso send data to a remote server for long-term storage andanalysis.
The RDA contains data filtering algorithms that canbe used to reduce noise, drift, or offset in the data, forexample. These algorithms (e.g., low-pass and high-pass)can be optionally applied to raw sensor data before it issent to the application. There is support for multiple filterimplementations for the application to choose from, andfilters may have control parameters such as the smoothingfactor in some low-pass filters. Integrating optional filteringfunctionality into the middleware removes yet another taskfrom the application developer.
Sensor Adapters offer a common interface for the RDAto request data from both physical and virtual sensors. Thisway the individual adapter implementations are encapsulatedand the RDA does not need to be concerned about them.Thecommon interface makes it easy to add new Sensor Adapters,thus improving extensibility.There exists one adapter for eachsupported sensor and each adapter holds an algorithm foracquiring data from its adapter sensor. Algorithm parameterssuch as default sensing interval or timeout can be adjustedthrough per-adapter preferences that are accessible through
International Journal of Distributed Sensor Networks 5
Virtual sensorsPhysical sensors
Raw data collection
Raw data aggregator
Sensor adapters
Onboardsensors Smart Heart rate
monitor
External devices
Establish connections(Bluetooth, HTTP etc.),
request dataControl messages
Publishevents
Application
Subscribe for events with ManySenseQuery Language or query objects
Control messages
Publish events to application
Androiddatabase(Cache)
Server
Database
Accelerometer
adapterGPS
adapter
Communicationinterface
Devices
Sensor datafiltering
Cachedata
Sensor data
Context inferencing
Context data aggregator
Context inferencing
ActivityGoogle
Publishevents
Server
Web services
Subscription handler
Data forexternalanalysis
Data for external storage
Fusion
Preferences
Save and use global preferences
Adapte SDKRaw dataadapter
simulator
Context
simulator
Documentation Examples
SensorAdapterinterfaceContextDataAdapterinterface
Stepcounter
UpdatersPoll newest data
ManySense
watch sensors Weather data
inference adapter
adapters
Figure 2: ManySense architecture.
Figure 3: OpenWeatherMap API Sensor Adapter preference screen.
ManySense’s preference screen. For example, Figure 3 showsthe preference screen for the OpenWeatherMap API SensorAdapter. Access to sensors is not limited to a single protocolbecause the adapters handle communication with the sensordevices using any required protocol. For example, in additionto Bluetooth-based Sensor Adapters we could create anadapter for acquiring data from a sensor web or a web serviceusing HTTP.
The role of the context data aggregator (CDA) is toprovide higher level context data to subscriber applications. Itdelegates the responsibility of context inferencing to ContextInferencing Adapters (CIA) which can be selected based onthe application’s needs. Each CIA is responsible for subscrib-ing to necessary raw data from the RDA and then processingit appropriately. Encapsulating the CIAs behind a commoninterface follows the same design that we applied in rawdata acquisition; thus, it has similar extensibility. Examples ofCIAs could be a physical activity detector using accelerometerdata and an ontology-based adapter for detecting higherlevel activity such as “working,” “sleeping,” and “eating” usingmultiple sensors. As the complexity of context inferencingmay vary significantly between various approaches, the CIAscan also send inferencing requests to a server. This would beessential in the case of large ontology-based context models,for example.
To facilitate the development of Sensor Adapters andContext Inferencing Adapters by third party developers, wehave created an Adapter SDK (software development kit)that includes simulators, code examples, and documentationto assist in building custom adapters. The simulators takethe roles of RDA and CDA by loading adapter components
6 International Journal of Distributed Sensor Networks
and sending test requests to verify the adapter’s operation.Using the Adapter SDK, third party application developerscan create and test new adapters for acquiring raw data aswell as inferencing context data. Currently ManySense doesnot support runtime deployment of customadapters, but theymust be inserted into the system by us. Nevertheless, the SDKfacilitates adapter development and our future plan is to allowthird party adapters to be attached to ManySense at runtime.
Subscriber applications communicate with ManySenseeither by method calls or by sending requests using Many-Sense query language (MSQL). Examples of these queriesinclude selecting target sensor data types or context inferenc-ing algorithms, setting sensing interval, applying data filters,and setting data collection schedule.
Collected and inferred data can be cached in a localAndroid database by theRDAand theCDA, and they can alsobe stored and/or analyzed on an external server. The cachedand stored data can be used for data visualization and deeperanalysis, such as ontology-based context modeling.
In order to demonstrate the extensibility and accessibilityof ManySense, we can consider different user scenarios asfollows. John is working as a team leader in an IT company.Apart from computers, his passion is runningmarathons andto facilitate training he owns a range of gadgets includingan Android smartphone, Zephyr BioHarness body monitor,Pebble smartwatch, and Nike FuelBand. Until now John hasused separate applications for monitoring each device. Asa decent programmer, however, he can now write a simpleapplication that uses ManySense to get data from all devicesand plot data nicely on a single view. John’s wife Jane isa researcher in the field of educational technology. Hercurrent research is about building a context-sensitive lan-guage learning tool that would provide situation-dependentlanguage drills to users. Jane has little programming skill,but she is mainly focusing on user interface developmentand has no idea about sensors and such low level details.Before John told Jane about ManySense, she was planning onhiring an experienced programmer (or using her husband) tocreate a custom context-awareness module for her learningtool. Instead now she can use one of ManySense’s contextinferencing algorithms to acquire high-level context and usethat in her application to deliver context-sensitive learningcontent. Jane’s cousin Mike is a junior lecturer at a localuniversity’s computer science department. He is giving acourse that focuses onmachine learning. In this course, Mikewants to teach to his students how sensor data is processedwith machine learning algorithms. For this he needs rawdata from multiple sources such as a smartphone and anenvironmental sensor network. With help of ManySense,Mike and his students can focus entirely on sensor dataprocessing without spending much time on data collectiondetails.
4. System Implementation
In the following sections, we describe the implementationdetails of ManySense including its subscription mechanism,
public interface SensorEventListener {public void sensorUpdated(
raw data collection, context inferencing, Adapter SDK, andexception handling.
4.1. Subscription. Third party applications wishing to sub-scribe to raw sensor data or inferred context data mustimplement the SensorEventListener (Listing 1) or the Con-textEventListener interface, respectively, and add themselvesas subscribers to ManySense through the SubscriberConnec-tion class. The event listener interfaces provide a mechanismto notify the subscribers when data is updated, an erroroccurs, or ManySense service binding changes.
Subscribing applications must specify a data retrievalrequest upon subscription. The request is expressed eitherby a query object or by a string containing a query writtenin ManySense query language. A query specifies the type ofdata, the commands that should be executed on start-up,the filters to be used on raw data, and a schedule for thesubscription. Because ManySense is running in a separateprocess, the SubscriberConnection class sends the requestquery to ManySense by interprocess communication (IPC).
After implementing a listener interface and determining adata retrieval request, the subscriber binds to the ManySenseservice with the SubscriberConnection class that handles thecomplex binding process and acts as an interface betweenManySense and the subscriber. Communication betweenthe SubscriberConnection and ManySense is establishedusing the Android interface definition language (AIDL) thatenables efficient IPC on Android. The advantage of thisapproach is increased performance due to the usage ofmultiple threads instead of a single thread used by the Mes-senger, an alternative Android IPC method. In transmittingobjects over IPC, we chose to marshal them using Parcelableinterface instead of Serializable because the latter was amajorperformance bottleneck in our experiments. Before usingAIDLwe experimented with theMessenger because its singlethread approach is less complex. Performance differences ofAIDL and Messenger approaches are discussed later.
Listing 2 shows code snippets that connect the subscriberapplication with ManySense. SubscriberConnection objectis first declared in a place that is relevant to the desired
International Journal of Distributed Sensor Networks 7
private SubscriberConnection conn;//Initialize connectionconn = new SubscriberConnection(this);conn.registerListener(listener);conn.openConnection();//Subscription code//Unsubscribingconn.sendQuery(“unsubscribe from ∗”);conn.closeConnection();
Listing 2: Subscribing to ManySense with SubscriberConnection.
subscribe to phone/accelerometer,smartwatch/accelerometercommands delay 50filters lowpass 0.6modify subscription inphone/accelerometercommands send only new data truesend until 22-10-2014 12:00:00unsubscribe from ∗subscribe to context/activityGooglecommands delay 10000send for 30 minutes
Listing 3: Examples of MSQL queries.
lifecycle of the connection. The SubscriberConnection isinstantiated with the current context so that it can bindto the SubscriberService running in ManySense. Then thelistener needs to be registered. Calling the openConnection()binds the subscriber application to the service and closeC-onnection() unbinds it. To unsubscribe, the subscriber sendsa query defining which subscriptions should be removed.Alternatively, the subscriber can remove all subscriptions, asshown in Listing 2. Closing the connection also removes allsubscriptions. An example of subscription code can be seenin Listing 3.
When a subscriber application makes a request to theSubscriberConnection, it is forwarded toManySense throughIPC. Figure 4 illustrates this communication. Requests arereceived by the SubscriberService which parses MSQLqueries into query objects and forwards the query objectsto the SubscriptionHandler which stores information aboutall subscriptions. The SubscriptionHandler determines if thequery targets context data or raw data and forwards it to theappropriate aggregator.
4.1.1.ManySenseQuery Language. In order to facilitate devel-opers’ interaction with ManySense, we developed the Many-Sense query language (MSQL)which can be used for creating,modifying, and removing subscriptions in ManySense. We
Subscriber process
ManySense process
ManySense
Application
SubscriberConnection
SubscriberService
Call listenermethods
Subscribe andsend requests tothe middleware
Bind, forwardsubscriberrequests to service
Forward middleware
subscriber
Sendmessages to
messages to
subscriber
Forward subscriberrequest tosubscription handler
Interprocess communication
Subscription handler
Figure 4: Communications between a subscriber application andManySense.
defined the language and generated a parser using ANTLR,a tool for defining structured languages. Listing 3 showsrepresentative examples of MSQL queries. The first querysubscribes to raw data from the phone’s built-in accelerome-ter and a smartwatch’s accelerometer. It also specifies that thedata should arrive at 50 millisecond intervals with low-passfilter applied.The secondquerymodifies the first subscriptionby specifying that only new data should be sent and thatthe subscription should automatically end at the given time.The third query removes all subscriptions. The last querysubscribes to activity data using Google’s activity detectionalgorithm. It also specifies that the algorithm should be runevery 10 seconds and that the subscription should expire after30 minutes.
In all query types it is possible to define the types ofdata sources and data type that the query will target. In thecase of subscription andmodification queries it is mandatoryto specify at least one pair of data source and data type. Insubscription removal queries it is possible to use an asteriskas wildcard for subscribed data sources. In subscription andmodification queries it is also possible to define commands,filters, and ending constraints. Multiple commands can begiven with or without parameters. Multiple filters can also be
8 International Journal of Distributed Sensor Networks
applied to the data. Ending constraints define scheduling forthe subscription. It is possible to specify that the subscriptioncontinues indefinitely (default), until a given time, for a giventime period, or until a given amount of updates have beensent. It is also possible to send multiple queries at a time,separated by a semicolon.
4.2. RawData Collection. Therawdata collection componentis responsible for handling requests for raw data.The raw dataaggregator (RDA) receives requests and tries to fulfill themas the best it can. It requests an updater to be started once itfinds a suitable sensor. Updaters are responsible for keepingthe subscribers updated. They poll the given sensor for newdata at set intervals. There is an updater running per everysubscriber’s every subscribed sensor. This is because all thesubscribers may have different parameters for how they wishto receive data. The sensors in turn are represented by theSensorAdapter interface. This allows ManySense to handleheterogeneous sensors through a common interface.
The adapter design pattern is used when integration oftwo incompatible interfaces is desired [32]. The main ideais that an adapter is provided to mediate communicationbetween interfaces by appropriate conversion. We use theadapter pattern to provide a common interface for all sensordevices. The SensorAdapter is an interface that is imple-mented by adapters for each sensor device providing rawdata. It defines the general capabilities that all adapters musthave. These general capabilities include initializing, starting,stopping, and deinitializing the sensor, as well as getting thelatest event and type of the sensor. All of these adaptersare held and mapped by their sensors’ types in respectivedevice objects. A device object contains information aboutthe device’s physical location on the user’s body such as onchest, wrist, or hip. This information can be used by activitydetection algorithms, for example. The device objects areheld in the RDA which maps them by the device type. Thiscategorization makes it possible to find a requested sensorwith just the device type and sensor type. For example, ifthe subscriber requests data from a smartwatch, ManySensemay retrieve data from a Sony, Pebble, Samsung, or any othersmartwatch that the user might have and that supports therequested sensor type.
The RDA gathers sensor data through events sent byindividual Sensor Adapters. The data is cached locally inSQLite database and is then sent to the subscribers. It mayalso be sent to a remote server for long-term storage andanalysis.
The communication between adapters and the physicalsensors depends on the sensors. For internal sensors of thesmartphone, communication is trivial; the adapter simplyadds itself as a listener for updates from the Android sensorAPI. As for Bluetooth devices, the process is more compli-cated. First the adapter needs to see if the device/sensor existsand then it has to connect to the device. After the connectionismade, the rest of the process continues on a new thread.Thenew thread then needs to get data from the device, parse it,and send events to the RDAas data is collected.This approachwas used in implementing the adapter for the Zephyr heart
rate monitor. In the case of adapters for online data sourcessuch as weather data services, HTTP connection runningin a separate thread must be used. The complexity of suchconnection depends on the data source API.
There are two basic requirements for potential sensordevices to be usedwithManySense. First, the communicationprotocol they use should be open to make access to sensordata possible. With closed protocols creating an adapterwould become tedious as it would require some form ofreverse engineering. Second, the smartphone needs to beable to communicate with the sensor device. This can betypically done by Bluetooth, USB, WiFi, or mobile networks.For example, accessing a ZigBee wireless sensor network canbe done by a USB or Bluetooth connection to a sink node.The devices that were used in developing and testing themiddleware were Samsung Galaxy S3 smartphone, ZephyrBluetooth heart rate monitor, and Sony SmartWatch SW2.The sensors that are available in each device are shown inTable 1. Virtual sensors (e.g., orientation, linear acceleration)provided by the Android API have been omitted from thetable. These devices were chosen because their protocols areopen, documentation is abundant, and they are Androidcompatible.
At the moment of writing this paper, we have completedadapters for all of the sensors mentioned in Table 1 and alsoan adapter for getting temperature data for the user’s currentlocation by using the online OpenWeatherMap API.
4.3. Context Inferencing. The context inferencing moduleis responsible for providing inferred context data to thesubscribers. The context data aggregator (CDA) selects theappropriate context inferencing adapter (CIA) to fulfill arequest. Context data events are sent through the sameSubscriptionHandler interface as the raw data events. Theevent argument is given as a character string, thus allowingthe context data to be presented in JSON, XML, or similarstructured format.
The context inferencing module follows the raw datacollection module in its architectural design. Adapters takecare of requesting necessary input data from the RDA andexecuting inference algorithms on raw data. For example,an activity detection adapter might use accelerometer froma smartphone and from a smartwatch to infer the user’sactivity. Currently we have two CIAs implemented as proofs-of-concept: (1) an activity detector based on Google’s Activ-ity Recognition API and (2) a step counter which usesaccelerometer data to count the user’s steps.
4.4. Adapter SDK. The Adapter SDK provides tools formaking new Sensor Adapters and CIAs. It includes simulatorapplications for both adapter types, along with documenta-tion and example adapters. The purpose of the simulators isto run a new adapter through example scenarios and see thatit matches the requirements set on them. Figure 5 shows theManySense adapter simulation tool (MAST) after a successfultest run of a weather data Sensor Adapter. The simulatorchecks that the adapter’s preferences are valid and that it iscapable of producing data at a consistent rate. In the figure
International Journal of Distributed Sensor Networks 9
Figure 5: MAST test run.
Table 1: The sensors contained in the test devices.
Galaxy S3 Sony SW2 Zephyr HRMAccelerometer Accelerometer Heart rateLight sensor Light sensor Instant speedMagnetic field Magnetic field DistanceProximityBarometerGyroscopeGPS receiver
you can see also that the rate is changed around midway toconfirm that the adapter responds to this command. In theend the simulator also checks that all invalid state transitionsthrow exceptions properly and that all valid transitions donot.
Many of the software components on which the simula-tors are based are taken from ManySense. The RDA and theCDA are the only customized components. The simulator isavailable as an application project where the developer mustadd new adapter for testing.
All Sensor Adapters should extend the AbstractSen-sorAdapter as it implements the SensorAdapter interfaceand provides the basic lifecycle management for all SensorAdapters, thus reducing development work. The developercan then concentrate on the essentials such as defining howdata is acquired, how it is processed, and how subscribercommands are handled. Extending this class makes sure thatthe Sensor Adapter passes the state transition tests.
4.5. Exception Handling. Exception handling is needed forfault tolerance and recovery. If an error occurs, ManySensewill notify the sensor’s subscribers with amessage that carriesthe exception that occurred. For example, if the subscribersends an invalid command to a sensor, the exception thatoccurs is returned to the subscriber.This is important because
it does not cause ManySense to crash and the subscriber candecide what to do with the exception.
If a subscriber forgets to unsubscribe andManySense triesto send the subscriber a message, a DeadObjectException isthrown by Android. This exception is caught by ManySenseand the subscriber is unsubscribed from everything. If thereare no more subscribers left, ManySense will shut down tosave resources.
Another typical erroneous situation that may occur atruntime is that the Bluetooth connection to a device is lost.If this happens, the exception is forwarded to the subscriberand the adapter deinitializes. Then it is up to the subscriberto choose what to do. It could, for example, try to subscribeto the sensor again in a moment or give a prompt to the userto make sure the connection is possible and provide a buttonfor retrying the connection.
5. Evaluation
ManySense BSN middleware was evaluated and analyzedfrom three perspectives. First, we evaluated the performanceof ManySense by comparing its capability of sending dataat short intervals with multiple subscribers against directlistening of sensors. BecauseManySense can be used bymanysubscribers at the same time, it is important that it is ableto perform well under load. Performance was also testedby profiling CPU, power, and memory usage of multipleservices using ManySense simultaneously and comparingthose data to services directly using the same data sources.Second, as extensibility was one of the design goals, weevaluated extensibility of the adapter interfaces by creatinga new Sensor Adapter and analyzing the process from thedeveloper’s perspective.Third, accessibility as another designgoal was evaluated by coupling ManySense with an existingexergame.
5.1. Performance. The device used for performance evalua-tion was Google Nexus 7 tablet running Android version4.4.3. The device was practically brand new and it had onlythe default applications installed, thus minimizing otherapplications’ influence on the results. Nexus 7 was chosenbecause it provided us with the capability of measuringpower consumption of applications using Qualcomm’s Trepnprofiler that gathers data on the usage of CPU, memory, andpower.
5.1.1. Load Performance. Load performance test was con-ducted by creating a predefined number of objects of anonstatic nested class in an Android Activity. The purposeof these objects is to simulate multiple subscribers accessingManySense concurrently. Each subscriber object bound tothe service and requested the phone’s accelerometer data ata predefined rate. This test was conducted with two versionsof ManySense using different interprocess communication(IPC) methods. The first version used the Messenger class,whereas the second version used an AIDL interface. After 10seconds had passed, the subscribers were stopped and eachof them calculated the average delay. Then the average of the
10 International Journal of Distributed Sensor Networks
subscribers’ averages was calculated and plotted on a chart.We also measured load performance when directly accessingthe Android Sensor API without ManySense.
Figure 6 illustrates the results of the load performancetest while using the Messenger class for communication, andFigure 7 shows the results while using an AIDL interface.Subscribers (listeners) using ManySense are plotted againstsubscribers using the Android Sensor API without Many-Sense (No MW). Each line indicates a configured updatedelay in milliseconds. A completely flat horizontal line isoptimal because it corresponds to requested delay. There isa big difference in performance between the Messenger andAIDL versions. In the AIDL test, we can see only a slightdifference with directly using the Android Sensor API whenthe subscriber count was raised to 100 and the requesteddelay was set to 0 milliseconds.The Android Sensor API pro-vided the requested data at 10 millisecond interval, whereasManySense produced a 16 millisecond average interval. Thereason for the slight increase is that all of the subscribers ofManySense have a dedicated Updater that makes sure theyhave the newest data. When all of the 100 Updaters sendevents nearly some of the events may simultaneously be lostdue to the buffer becoming full.
During load performance tests we found that havingmany subscribers raises problems relating to multithreading.ConcurrentAccessExceptions emerged because threads weretrying to access the data in ManySense at the same time.Synchronizing the methods or the areas of code that cannotrun at the same time solved the problem, but synchronizationmay have a negative effect on performance. However, as theresults presented above were acquired with synchronization,we can assume that possible performance drop caused bysynchronization is minimal.
5.1.2. CPU, Memory, Power Usage, and Code Complexity. Forthis test we created four background services in a testingapplication. The first two gathered data from the built-in accelerometer at 50 millisecond interval and from theOpenWeatherMap API at 500 millisecond interval, respec-tively. The other two services collected the same data usingManySense.
The Trepn profiler application for measuring the usageof CPU, memory, and power was set to profile at 500msintervals. The test device had Google account synchroniza-tion off and all other applications closed. The screen timeoutwas set to 30 minutes. At the start of profiling, a baselinefor measurements was captured for 15 seconds. Profiling wasdone for a period of 20 minutes. The data was exportedto a CSV file and imported into Excel which was used foranalysis and visualization. This data included performancedata for the whole system as well as data concerning thetesting application and ManySense.
Figure 8 compares the system’s total power consumptionbetween the two test runs. The average was 1190.6mW withManySense and 1191.1mW without. Figure 9 compares theapplication-specific CPU usage and shows a small increasewhen ManySense was used. The average was 3.66% withManySense and 2.21% without. One peculiarity in the figure
0
50
100
150
200
250
300
10050105
Mea
sure
d de
lay (m
s)
Amount of listeners
Average delay between updates
No MW 200 msNo MW 100 msNo MW 50 msNo MW 0 ms
Requested delay200 ms100 ms50 ms0 ms
Figure 6: Results of the load performance test with Messenger.
0
50
100
150
200
250
10050105
Mea
sure
d de
lay (m
s)
Amount of listeners
Average delay between updates (new updates only)
No MW 200 msNo MW 100 msNo MW 50 msNo MW 0 ms
Requested delay200 ms100 ms50 ms0 ms
Figure 7: Results of the load performance test with AIDL.
is the spikes in the power consumption that occur at regularintervals. Since they occur in both graphs, they aremost likelycaused by the Android system. The profiler also measurednetwork usage for other applications during the test. Forexample, Google Play Services and Google Search sent andreceived data at times corresponding to some spikes. Thesespikes did not have a major effect on the results because theyappeared seldom. To compare memory usage we used theaverage measured resident set size between the two test runs,as shown in Table 2. The resident set size is the amount ofRAM the application is using. In the case of ManySense, thefirst amount is what was used by the testing application andthe second one is what was used by ManySense.
Although the test services were programmed with com-pactness, therewas a big difference in their code complexities.We counted the amount of lines of code in each serviceexcluding empty lines, comments, import statements, and
International Journal of Distributed Sensor Networks 11
Figure 8: Comparison of power usage (top: with ManySense; bottom: without ManySense).
201816141210
86420
CPU
load
(%)
201816141210
86420
CPU
load
(%)
Figure 9: Comparison of CPU usage (top: with ManySense; bottom: without ManySense).
Table 2: Comparison of the average resident set size (RAM).
With ManySense Without ManySense8.4 + 7.5MB 9.1MB
package declarations. There were 18 lines of code that weremandatory and common in all classes.
Including themandatory lines, both services usingMany-Sense used 39 lines of code. The service using the AndroidSensor API directly used 32 lines of code, and the serviceusing OpenWeatherMap API directly used 85 lines of code.
5.2. Extensibility. We evaluated ManySense’s extensibilityby creating a new adapter for the phone’s magnetic field
sensor using the Adapter SDK. First, a class was createdthat extended AbstractSensorAdapter and implemented itsabstract methods. For phone sensors this is relatively simpleto do due to Android’s Sensor API. Then in the RDA’sconstructor we added the lines necessary to make it awareof the new sensor type. To test the adapter, we requested forits data in a subscriber application. The whole process tookaround 15 minutes. If the procedure for getting data from thesensor is more complex, as is the case with Bluetooth devices,programming an adapter will take some time longer.
Listing 4 shows a code snippet from the implementedmagnetic field adapter. The onIniatilize method is calledwhen data is requested from the adapter, but it is not yetrunning. It first gets a reference to the Android SensorAPI’s SensorManager class for accessing in-device sensors.
12 International Journal of Distributed Sensor Networks
public class PhoneMagneticFieldAdapterextends AbstractSensorAdapter
mSensor = mgr.getDefaultSensor(android.hardware.Sensor.TYPE MAGNETIC FIELD);
return true;}
public void onSensorChanged(android.hardware.SensorEvent event) {ManySenseEvent evt = super.
getStubEvent();if(evt != null){
evt.getData().setFloatArray(event.values);
mLatestEvent = evt;}
}
Listing 4: Part of the magnetic field Sensor Adapter.
Magnetic field sensor object is then acquired through theSensorManager object. The onSensorChanged method iscalled when the phone sensor sends an update to theadapter. When this happens the update is inserted into aManySenseEvent object and set as the latest event which anUpdater can pick up.
To further test the extensibility of ManySense, we asked24 undergraduate computer science (21) and digital media (3)students attending a context-aware application developmentcourse tomake Sensor Adapters forManySense and test themusing the simulator. The students were given the AdapterSDK which contained a skeleton of the adapter to fill inthe implementation details. Their task was to implementa Sensor Adapter for retrieving temperature data from theOpenWeatherMap API. To evaluate the difficulty of the taskto the students, we analyzed their weekly learning diarieswhere they discuss their experiences and learning process.Sample quotes are as follows:
“I thought it was so simple to use” (4th yearstudent, female),
“It was easy to complete project” (4th year student,male),
“I couldn’t understand well why I use it. It wasdifficult.” (4th year student, female).
In general, the task was easy for them, though some ofthem had trouble understanding how the adapter connectsto the rest of the system. As we can see, for some of the
students understanding how the adapters work was easy,but not for everyone. This experiment showed that whiledeveloping adapters with examples and template code is easy,the developers need to understand the whole picture to makethe development easier.
5.3. Accessibility. Accessibility of ManySense was evaluatedby integrating it into an existing application. For this we usedCalory Battle AR [33], an Android-based mobile augmentedreality exergame that aims to promote physical activityamong children. Unlike stationary living room exergamesystems such as Nintendo Wii, Calory Battle AR’s game playis tied to the real world context and is designed to be playedoutside. No special hardware is needed; all the user need ishis/her smartphone and the printed image targets.
The player’s role is to find target locations guided by aGPSmap and perform whatever tasks given there. For example,the player might need to defuse an augmented reality bombor answer a quiz. Optional time limit encourages the playerto run. The platform was made extensible so new kinds oftasks can be added easily. For this evaluation we created anew task which requires the player to spin around N times.The task requests orientation sensor data fromManySense atthe highest speed possible.
Integrating ManySense into Calory Battle AR startedwith including a JAR library file containing necessary classfiles. Then the permission to use ManySense was addedto the application’s manifest. Next we added an object ofSubscriberConnection to the new task’s activity and regis-tered it as a subscriber (Listing 2). After implementing allSensorEventListener interface methods (Listing 1), we madethe task to subscribe to orientation data when the service wasbound in the serviceBindingChanged method. Finally, uponreceiving data in the sensorUpdatedmethodwe applied a spindetection algorithm. Given that the spin detection algorithmwas already prepared, the process of integrating ManySenseinto Calory Battle AR took around 30 minutes.
6. Discussion
ManySense was created to allow the developers of third partyapplications to access heterogeneous sensor data and inferredcontext data in a uniform manner. The evaluation resultsindicate that ManySense performs well under load and itis fairly easy to create new adapters as well as to integrateManySense into an existing application. As we saw in theload performance tests, an application can receive updates atoptimal speeds with and withoutManySense, but in the lattercase the development effort is higher and is likely to result induplicate code written by different developers.
Other performance tests displayed that using ManySensecauses a slight increase in CPU and RAM usages. Thedifference in code complexities of the test services wasmore obvious.The service utilizing the built-in accelerometerdirectly was the simplest one, and thus we can conclude thatif the application only needs a single source of data from theAndroid Sensor API, it is simpler to do it withoutManySense.However, if more data sources are needed or getting the data
International Journal of Distributed Sensor Networks 13
requires multithreading, creating connections and parsingdata, then it is much simpler to use ManySense. It should benoted that instead of using two services to test ManySenseperformance, we could have made only one service thatwould have subscribed to both accelerometer and tempera-ture data bymodifying the query. Even if different parameterswere added, such as scheduling or filtering, it still would notincrease the complexity of the code.
The biggest theoretical bottleneck of ManySense is theIPC which is subjected to a 1MB communication buffer.If the buffer becomes full, the sent data is lost. At themoment we do not see that this is becoming a practicalproblem because in a real situation over 10 listeners wouldbe unnecessary and our load performance test did not showany signs of decreased load performance. On Android onlyone activity is active (visible) at any given time, so as long asthe subscribers only keep the connections open when theyare active, the IPC bottleneck will not become a problemunless subscribers subscribe to a large number of adapters.A solution to the IPC bottleneck problem is to packageManySense into a library that developers can embed in theirapplications. Then there is neither buffer nor IPC to slow itdown.The shortcoming of this approach is increased resourceusage if there are multiple ManySense-driven applicationsrunning simultaneously. Thus, in the future we plan to havetwo versions of ManySense: one that is situated in a separateprocess and another one that is embedded in a third partyapplication as library. This would allow the developers tochoose the version appropriate for their needs.
While the results of this study are encouraging, they aremerely an initial survey toManySense’s extensibility. As moreSensor Adapters will be developed, we could see applica-tions accessing not only wearable Bluetooth-based sensordevices but also ZigBee and HTTP sources. Similarly, moresophisticated Context Inferencing Adapters can be pluggedinto ManySense. An increase in software functionality hasa tendency of decreasing performance; thus, in the futurewe must focus on performance while keeping the systemdynamic.
Various well-known software design patterns were usedin ManySense development (observer, singleton, adapter,template method, and facade). These patterns provide solu-tions to recurring problems which helps us avoid reinventingthe wheel [32].The observer pattern was used to decouple theadapters from the subscribers.The singleton patternwas usedto make various components, such as the aggregators andthe subscriber handler accessible from anywhere, and also toensure that there only exists one instance of them at any giventime.The adapter pattern was used with Sensor Adapters andContext Inferencing Adapters to provide common interfacesfor the data providers.The template method pattern was usedin theAbstractSensorAdapter to allow the individual adaptersfill in their algorithm implementations while keeping thecommon code in a single place. Finally, the facade patternwas applied to the SubscriptionHandler to offer a simplifiedinterface for the SubscriberService to the aggregators. Byusing these patterns we conformed to the design principlespresented in Section 3 and made ManySense extensible and
accessible while keeping the implementation decoupled andencapsulated.
ManySense was designed to be flexible in terms of addingsupport for new sensors and context inferencing algorithmsas well as for enabling access for third party applications.However, there remain challenges that should be addressedin future research and development. Firstly, even though cre-ating new Sensor Adapters and CIAs is easy, there is currentlyno way of adding adapters to ManySense at runtime. Newadapters must be added to ManySense codebase which isthen compiled and distributed to the end users. Android’sautomatic software update option diminishes this challenge,but it still requires an action from the end user. A component-based framework such as Apache Felix (OSGi) could be usedto overcome this challenge because it allows the deploymentof new components at runtime, but performance of Felixon Android should be investigated first. Secondly, manyconsumer sensor devices use closed or incompatible proto-cols. For example, Garmin Forerunner sport watches use theANT+ protocol which is not supported by most Androidsmartphones. Thus, adapter developers are limited to useproducts that are open and accessible. Finally, smartphoneand sensor device resource constraints (e.g., CPU, memory,and battery) have been widely researched by scholars, butthese have not been thoroughly considered in ManySense.More research is needed to ensure optimal utilization ofscarce resources.
7. Conclusions
ManySense BSN middleware supports heterogeneous off-the-shelf consumer-oriented wearable sensors as well asother data sources that can be used by developers to createcontext-aware applications. ManySense also provides accessto inferred context data such as the user’s current activity.Thistype of middleware is needed because most previous BSNmiddlewares were found to be focused on specific domainssuch as healthcare andmany lacked flexibility in terms of sup-porting new sensor and context data sources. Furthermore,many previous systems do not provide access to data for thirdparty developers. To overcome the shortcomings of previoussystems, in ManySense design we emphasized extensibilityand accessibility while minimizing dependency on externalcomponents. These and other design principles resulted ina system architecture which allows low-effort addition ofnew sensors and context inferencing algorithms throughadapter interfaces. It also allows convenient subscription bythird party applications that can not only acquire data frommultiple heterogeneous sensors and context inferencing algo-rithms but also send queries to control them. The ability ofManySense to clean sensor data by optional filtering furtherreduces the development effort of third party applications.
The primary motivation for ManySense is wearable sen-sors in consumer applications, but ManySense can efficientlysupport any sensors as long as they can communicatewith themobile device. For example, we could write a Sensor Adapterthat connects to a sink node of an environmental ZigBee-based sensor network over USB or Bluetooth. Similarly,
14 International Journal of Distributed Sensor Networks
we could develop adapters that would link bluetooth-basedpersonal health devices (PHDs) to ManySense for healthcareapplications. Additionally, any internet-based data sourcecan be connected to ManySense through the mobile device’sinternet connectivity. We demonstrated this by creating anadapter to acquire weather data from the OpenWeatherMapAPI. Finally, the adapter interface could also be used tomonitor the user’s device usage patterns (e.g., frequently usedapplications and visited websites) in order to gain a betterunderstanding of the user’s operational context. Needless tosay, this, as well as other user data collection, creates seriousprivacy issues that must be dealt with.
The context inferencing module is currently a proof-of-concept of ManySense’s extensibility and as such it doesnot yet provide sophisticated context inferencing algorithms.Thus, our future research will focus on creating a CIA fordetecting the user’s activity reliably in real time. This wouldinvolve combining multiple sources of data and then we canimprove the accuracy of existing algorithms that focus on asingle data source such as the smartphone’s accelerometer.For example, by using accelerometers of both smartwatchworn on wrist and phone inserted in pocket we could morereliably tell whether the user is running or rowing.
Thus far we have merely taken the first steps towardsenabling easy construction of fully body- and context-awareapplications. As we pointed out in discussion, there areseveral challenges to be tackled in future research. The nextsteps are to create more adapters for ManySense and allowthe adapters to be installed at runtime. This would increasethe flexibility and accessibility of ManySense.
Conflict of Interests
The authors declare that there is no conflict of interestsregarding the publication of this paper.
Acknowledgment
This work was supported by the new faculty research fund ofAjou University (2012).
References
[1] M. Weiser, “The computer for the 21st century,” SIGMOBILEMobile Computing and Communications Review, vol. 3, no. 3,pp. 3–11, 1999.
[2] Y. Hao and R. Foster, “Wireless body sensor networks forhealth-monitoring applications,” Physiological Measurement,vol. 29, no. 11, article R27, 2008.
[3] D. Malan, F. J. Thaddeus, M. Welsh, and S. Moulton, “Code-Blue: an Ad Hoc sensor network infrastructure for emergencymedical care,” in Proceedings of the Workshop on Applications ofMobile Embedded Systems (MobiSys ’04), pp. 12–14, ACM, 2004.
[4] G. Virone, A. Wood, L. Selavo et al., “An assisted livingoriented information system based on a residential wirelesssensor network,” in Proceedings of the 1st IEEE TransdisciplinaryConference on Distributed Diagnosis and Home Healthcare(D2H2 ’06), vol. 219 of BIBLIOGRAPHY, pp. 95–100, Arlington,Va, USA, April 2006.
[5] B. Kim, Y. Kim, I. Lee, and I. You, “Design and implementationof a ubiquitous ECG monitoring system using SIP and thezigbee network,” in Proceedings of the International Conferenceon Future Generation Communication and Networking (FGCN’07), pp. 599–604, Jeju-Island, Republic of Korea, December2007.
[6] S.-J. Oh and C.-W. Lee, “U-healthcare SensorGrid gatewayfor connecting wireless sensor network and grid network,” inProceedings of the 10th International Conference on AdvancedCommunication Technology (ICACT ’08), vol. 1, pp. 827–831,Gangwon-do, Republic of Korea, February 2008.
[7] U. Mitra, B. A. Emken, S. Lee et al., “KNOWME: a casestudy in wireless body area sensor network design,” IEEECommunications Magazine, vol. 50, no. 5, pp. 116–125, 2012.
[8] K.-H. Park and J.-G. Pak, “An integrated gateway for variousPHDs in U-healthcare environments,” Journal of Biomedicineand Biotechnology, vol. 2012, Article ID 954603, 7 pages, 2012.
[9] R. Harle and A. Hopper, “Sports sensing: an olympic challengefor computing,”Computer, vol. 45, no. 6, Article ID 6226522, pp.98–101, 2012.
[10] D. K. Arvind and A. Bates, “The speckled golfer,” in Proceedingsof the 3rd ICST International Conference on Body Area Networks(BodyNets ’08), pp. 1–7, Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering, Brussels,Belgium, 2008.
[11] A. F. Smeaton, D. Diamond, P. Kelly et al., “Aggregatingmultiplebody sensors for analysis in sports,” in Proceedings of the 5thInternationalWorkshop onWearableMicro and Nanosystems forPersonalised Health (pHealth ’08), 2008.
[12] C. Seeger, A. Buchmann, and K. Van Laerhoven, “An event-based BSN middleware that supports seamless switchingbetween sensor configurations,” in Proceedings of the 2nd ACMSIGHIT International Health Informatics Symposium (IHI ’12),pp. 503–512, ACM, January 2012.
[13] K. Takeda, H. Erdogan, J. Hansen, and H. Abut, In-VehicleCorpus and Signal Processing for Driver Behavior, Springer, NewYork, NY, USA, 2009.
[14] E. Miluzzo, N. D. Lane, K. Fodor et al., “Sensing meets mobilesocial netwo rks: the design, implementation and evaluati onof the cenceme application,” in Proceedings of the 6th ACMConference on Embedded Networked Sensor Systems (SenSys’08), pp. 337–350, ACM, New York, NY, USA, November 2008.
[15] M. Musolesi, E. Miluzzo, N. D. Lane, S. B. Eisenman, T.Choudhury, and A. T. Camp-bell, “The second life of asensor—integrating real-world exp erience in virtual worldsusing mobile phones,” in Proceedings of the 5th Workshop onEmbedded Sensor Networks (HotEmNets ’08), 2008.
[16] S. B. Eisenman, E. Miluzzo, N. D. Lane, R. A. Peterson, G.-S. Ahn, and A. T. Campbell, “The BikeNet mobile sensingsystem for cyclist experience mapping,” in Proceedings of the5th International Conference on Embedded Networked SensorSystems (SenSys ’07), pp. 87–101, NewYork, NY,USA,November2007.
[17] C.-H. Wu, Y.-T. Chang, and Y.-C. Tseng, “Multi-screen cyber-physical video game: an integration with body-area inertialsensor net works,” in Proceedings of the 8th IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops (PERCOM ’10), pp. 832–834, March 2010.
[18] C. Garcia Wylie and P. Coulton, “Persuasive mobile healthapplications,” in Electronic Healthcare, D.Weerasinghe, Ed., vol.1 of Lecture Notes of the Institute for Computer Sciences, Social
International Journal of Distributed Sensor Networks 15
[19] N. Crampton, K. Fox, H. Johnston, and A. Whitehead, “Dance,dance evolution: Accelerometer sensor networks as input tovideo games,” in Proceedings of the 6th IEEE InternationalWorkshop onHaptic, Audio andVisual Environments andGames(HAVE ’07), pp. 107–112, October 2007.
[20] K. Montgomery, C. Mundt, G. Thonier et al., “Lifeguard—apersonal physiological monitor for extreme environments,” inProceedings of the 26th Annual International Conference of theIEEE Engineering in Medicine and Biology Society (EMBC ’04),pp. 2192–2195, September 2004.
[21] L. Zhong, M. Sinclair, and R. Bittner, “A phone-centered bodysensor network platform: cost, energy efficiency & user inter-face,” in Proceedings of the International Workshop on Wearableand Implantable Body Sensor Networks (BSN ’06), Cambridge,Mass, USA, April 2006.
[22] H. Viswanathan, B. Chen, and D. Pompili, “Research challengesin computation, communication, and context awareness forubiquitous healthcare,” IEEE Communications Magazine, vol.50, no. 5, pp. 92–99, 2012.
[23] A. B. Waluyo, I. Pek, X. Chen, and W. S. Yeoh, “Design andevaluation of lightweightmiddleware for personalwireless bodyarea network,” Personal and Ubiquitous Computing, vol. 13, no.7, pp. 509–525, 2009.
[24] J. Al-muhtadi, S. Chetan, R. Campbell, and M. D. Mickunas,“Middlewhere: a middle- ware for locati on awareness inubiquitous com puting applications,” in Proceedings of the 5thInternationalMiddleware Conference (Middleware ’04), pp. 397–416, 2004.
[25] D. Carr, M. O’Grady, G. O’Hare, and R. Collier, “SIXTH:a middleware for supporting ubiquitous sensing in personalhealth monitoring,” in Wireless Mobile Communication andHealthcare, B. Godara and K. Nikita, Eds., vol. 61 of LectureNotes of the Institute for Computer Sciences, Social Informaticsand Telecommunications Engineering, pp. 421–428, Springer,Berlin, Germany, 2013.
[26] A. M. Khan, A. Tufail, A. M. Khattak, and T. H. Laine, “Activityrecognition on smart-phones via sensor-fusion and kda-basedsvms,” International Journal of Distributed Sensor Networks, vol.2014, Article ID 503291, 14 pages, 2014.
[27] M. Baldauf, S. Dustdar, and F. Rosenberg, “A survey on context-aware systems,” International Journal of Ad Hoc and UbiquitousComputing, vol. 2, no. 4, pp. 263–277, 2007.
[28] S. Nath, “ACE: exploiting correlation for energy-efficient andcontinuous context sensing,” in Proceedings of the 10th Interna-tional Conference on Mobile Systems, Applications, and Services(MobiSys ’12), pp. 29–42, ACM, New York, NY, USA, June 2012.
[29] O. D. Lara and M. A. Labrador, “A mobile platform for real-time human activity recognition,” in Proceedings of the IEEEConsumer Communications and Networking Conference (CCNC’12), pp. 667–671, January 2012.
[30] T. Gu, H. K. Pung, and D. Q. Zhang, “A service-orientedmiddleware for building context-aware services,” Journal ofNetwork andComputerApplications, vol. 28, no. 1, pp. 1–18, 2005.
[31] C. Seeger, A. Buchmann, and K. van Laerhoven, “myHealthAs-sistant: a phone-based body sensor network that captures thewearer’s exercises throughout the day,” in Proceedings of the6th International Conference on Body Area Networks (BodyNets’11), pp. 1–7, ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), Brussels,Belgium, 2011.
[32] E. Gamma, R. Helm, R. Johnson, and J. Vlis-Sides, Design Pat-terns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, Boston, Mass, USA, 1994.
[33] J. Westlin and T. Laine, “Short paper: calory battle AR: anextensible mobile augmented reality exergame platform,” inProceedings of the IEEEWorld Forum on Internet ofThings (WF-IoT ’14), pp. 171–172, March 2014.
