Source-linked AI summary
MOSDEN: An Internet of Things Middleware for Resource Constrained Mobile Devices
Charith Perera, Prem Prakash Jayaraman, Arkady Zaslavsky, Peter Christen, Dimitrios Georgakopoulos
TL;DR
IoT middleware must collect and process sensor data on resource-constrained devices because not all objects can connect directly to computers. MOSDEN is a plug-in-based Android middleware for mobile sensor collection and processing without programming effort; when cloud queries are sent, processing is faster but energy consumption rises.
Problem
Many IoT objects cannot connect directly to computers for technical and economic reasons, while processing sensor data before cloud transmission matters under energy constraints.
Source: §I · p. 1, A. Internet of Things Architecture · p. 2Method
MOSDEN is a plug-in-based mobile IoT middleware that supports sensor collection and processing without programming effort and can interoperate with cloud GSN.
Source: §I · p. 1Results
50J (D1) / 40J (D2) energy consumption when processing 30 queries; cloud queries also make data collection and processing faster.
Source: C. Results · p. 8Takeaways & Limitations
MOSDEN provides a way to connect multiple sensors to mobile devices and process their data locally before transmission, including through sensor-data fusion.
Source: A. Internet of Things Architecture · p. 2, §VIII · p. 10
Abstract
from arXiv · showhide
The Internet of Things (IoT) is part of Future Internet and will comprise many billions of Internet Connected Objects (ICO) or `things' where things can sense, communicate, compute and potentially actuate as well as have intelligence, multi-modal interfaces, physical/ virtual identities and attributes. Collecting data from these objects is an important task as it allows software systems to understand the environment better. Many different hardware devices may involve in the process of collecting and uploading sensor data to the cloud where complex processing can occur. Further, we cannot expect all these objects to be connected to the computers due to technical and economical reasons. Therefore, we should be able to utilize resource constrained devices to collect data from these ICOs. On the other hand, it is critical to process the collected sensor data before sending them to the cloud to make sure the sustainability of the infrastructure due to energy constraints. This requires to move the sensor data processing tasks towards the resource constrained computational devices (e.g. mobile phones). In this paper, we propose Mobile Sensor Data Processing Engine (MOSDEN), an plug-in-based IoT middleware for mobile devices, that allows to collect and process sensor data without programming efforts. Our architecture also supports sensing as a service model. We present the results of the evaluations that demonstrate its suitability towards real world deployments. Our proposed middleware is built on Android platform.
I. INTRODUCTION
IoT middleware must support sensor collection and processing on resource-constrained devices, not only in resource-rich clouds. The paper introduces MOSDEN, a mobile middleware designed for sensor access and processing with a pluggable architecture.
I. INTRODUCTION
- The paper motivates resource-constrained middleware because most existing middleware solutions target cloud environments with abundant resources.It frames low-powered devices as important to realizing the IoT vision.Source: §I · p. 1
- MOSDEN is an IoT middleware for resource-constrained mobile devices that collects and processes sensor data without programming effort.It is designed to support sensing as a service natively.Source: §I · p. 1
- Its plugin architecture lets developers add sensor-specific communication, with plugins distributed through Android application markets.The architecture is described as scalable and promoting ease of use.Source: §I · p. 1
- MOSDEN is designed to interoperate with cloud-based middleware such as GSN, and the paper evaluates it on devices with different resource constraints.The evaluation is intended to assess scalability and suitability for the IoT domain.Source: §I · p. 1
II. BACKGROUND AND MOTIVATION
The background frames IoT as a heterogeneous system in which connectivity, computation, cost, and energy shape where sensor data should be processed. It motivates local processing and introduces sensing as a service as a second perspective.
II. BACKGROUND AND MOTIVATION
- The background sets up two perspectives: IoT hardware infrastructure and the sensing-as-a-service model.It also cites statistics and predictions about IoT as motivation.Source: §II · p. 2
A. Internet of Things Architecture
- Direct Internet connectivity for every IoT device is impractical because of resource constraints, expense, and effects on sensor miniaturization and energy use.The paper categorizes IoT devices into six levels with differing capabilities.Source: A. Internet of Things Architecture · p. 2
- Moving left across the device categories increases computational and connectivity capability, but also increases device cost and size.The paper argues that middleware should adapt to these different device types.Source: A. Internet of Things Architecture · p. 2
- Local processing is favored when its energy requirement is lower than communication; otherwise, data should be sent to a higher-capability node.The stated rule compares processing energy Eα with communication energy Eβ.Source: A. Internet of Things Architecture · p. 2
- MOSDEN targets lower-level devices such as mobile phones or Raspberry Pi, processing sensor data with SQL-like queries such as averaging before transmission.Local fusion can reduce network communication, which the paper identifies as energy-intensive; it is especially relevant where recharging sensing devices is difficult.Source: A. Internet of Things Architecture · p. 2
B. Sensing as a service Model
Sensing as a service provides sensor data on demand rather than collecting continuously. MOSDEN connects sensors to cloud middleware, processes data locally, and selectively sends results to the cloud.
B. Sensing as a service Model
- Sensing as a service responds to consumer requests instead of collecting data continuously, while cloud middleware tracks sensor availability and capabilities.The cloud searches for required sensors, composes a query, and registers it with the MOSDEN instance connected to the sensor.Source: B. Sensing as a service Model · pp. 2–3
- Sensors without long-range communication connect to MOSDEN, which processes their data and transmits selected data to the cloud.Figure 2 illustrates this sensing-as-a-service arrangement.Source: Figure 2 · p. 3
- MOSDEN can aggregate sensor readings locally—for example, averaging values and sending them once a minute instead of every two seconds—to reduce network operations.The paper notes that opening and closing communication radios is energy-expensive.Source: B. Sensing as a service Model · p. 3
- Each MOSDEN instance tracks attached sensors’ availability and capabilities, helping cloud middleware stay up to date; instances are managed with publish/subscribe.Source: B. Sensing as a service Model · p. 3
III. RESEARCH PROBLEM
MOSDEN targets energy-efficient processing and communication, scalable infrastructure, and usable sensor configuration on resource-constrained devices. Its plugin architecture aims to make sensor support extensible and usable without programming.
III. RESEARCH PROBLEM
- The research focuses on energy-efficient data processing and communication, cost-efficient infrastructure for large-scale IoT, and easier sensor connection and configuration on constrained devices.The authors identify local processing, devices with varied capabilities and costs, and efficient sensor connection as central challenges.Source: §III · p. 3
- Existing commercial solutions are described as closed, difficult to extend or interoperate, and tied to custom hardware that may not work across vendors.The authors propose commonly available devices such as mobile phones and vendor-agnostic middleware as alternatives.Source: §III · p. 3
A. Plugin Architecture
- MOSDEN plugins translate generic messages into sensor-specific commands and can be installed or configured at runtime.The plugin approach is intended to support scalability, usability, and community-based development.Source: A. Plugin Architecture · p. 3
- Plugins can be downloaded individually, use little storage, and be removed automatically when memory is low, while users need only install the matching plugin to collect sensor data.The figure describes plugins as sensor-compatible components that communicate with sensors and retrieve data.Source: A. Plugin Architecture · pp. 3–4, Figure 3 · p. 4
- The plugin model provides standard interfaces and sample code for developers to add sensor support, with MOSDEN planned for future release as free and open-source software.The authors expect community development to increase the number of sensors supported.Source: A. Plugin Architecture · p. 4
B. General Architecture
MOSDEN adds a plugin manager and generic wrapper to its GSN-based architecture, separating sensor communication from the main application. It registers sensors and routes cloud requests to capable MOSDEN instances using pull or push streaming.
B. General Architecture
- The GSN-based architecture adds a plugin manager and a generic wrapper that communicates with plugins, which then communicate with sensors, avoiding recompilation when sensors are added.The plugin manager shares connected-sensor information with cloud GSN and peer MOSDEN instances.Source: B. General Architecture · p. 4
C. Interaction with the Cloud and Peers
- When a sensor is detected, MOSDEN retrieves its context and registers it with cloud GSN; the figure depicts this interaction between MOSDEN and cloud GSN.Cloud GSN finds instances capable of fulfilling a user request, then sends requests that MOSDEN can serve through pull or push streaming.Source: C. Interaction with the Cloud and Peers · pp. 4–5, Figure 4 · p. 4
D. Distributed Processing
MOSDEN supports local and peer-to-peer processing across resource-constrained devices. The Android implementation retains GSN capabilities while providing different user-interface versions for devices with different needs.
D. Distributed Processing
- Local processing can save network communication cost, and multiple MOSDEN instances can communicate and process data peer-to-peer without a central controller.The paper notes that distributed processing is supported but does not discuss it in detail.Source: D. Distributed Processing · p. 5
V. IMPLEMENTATION
- MOSDEN is implemented in Java for Android devices and retains GSN data processing and REST-based peer-to-peer communication over HTTP.The implementation is based on GSN and changes its wrapper structure while adding a plugin layer and manager.Source: §V · pp. 5–6
- MOSDEN provides a full user interface and a limited interface that only starts the middleware; the limited version reduces UI overhead and suits devices such as Raspberry Pi.Figure 5 shows connected sensors and running virtual sensors in the user-facing version.Source: §V · p. 5, Figure 5 · p. 5
- The cloud GSN screenshot shows three different MOSDEN instances registered with the cloud instance.Source: Figure 6 · p. 5
A. Plugin Development
MOSDEN plugins follow a shared AIDL interface, Java implementation, and AndroidManifest definition. Their methods declare expected data, retrieve readings, accept runtime configuration, and support automatic discovery by MOSDEN.
A. Plugin Development
- A MOSDEN plugin comprises an AIDL interface, a Java class, and an AndroidManifest definition; developers use the IPlugin interface but should not modify it.Each plugin is defined as an Android service.Source: A. Plugin Development · p. 6, Figure 7 · p. 6, Figure 8 · p. 6
- Plugins implement getdataStructure() to describe expected data and getReadings() to return readings in that structure; setConfiguration() accepts runtime configuration in a Map.MOSDEN calls getdataStructure() at initialization and repeatedly calls getReadings() at the frequency specified by cloud GSN.Source: A. Plugin Development · p. 6
- An AndroidManifest intent filter with the required MOSDEN action lets the application identify plugins, while the extended VSD passes sensor-specific connection details to a plugin.The VSD supports using the same plugin with multiple sensors; Figure 10 shows a virtual-sensor definition snippet.Source: A. Plugin Development · p. 6, Figure 9 · p. 6, Figure 10 · p. 6
VI. EVALUATION
The evaluation tests MOSDEN’s resource use and scalability on three Android devices with different capabilities. The test beds combine built-in and external sensors with a cloud GSN host.
A. Test-beds
- MOSDEN was evaluated for CPU consumption, scalability, memory requirements, and latency using three devices with different resource limitations, designated D1, D2, and D3.Source: A. Test-beds · p. 7
- The test beds included built-in motion, environmental, and position sensors, plus Libelium external sensors such as temperature, humidity, pressure, and gas sensors.An Intel Core i5 computer hosted the cloud GSN.Source: A. Test-beds · p. 7
B. Methodology
The methodology varies sensor and query loads across three mobile devices, measuring resource use and processing latency under specified communication conditions.
B. Methodology
- All evaluations used three resource-constrained devices, a 1-second sampling rate, and Wi-Fi; CPU use was measured in jiffies.At the time of evaluation MOSDEN supported Wi-Fi only; Zigbee and Bluetooth were expected later.Source: B. Methodology · p. 7
- Figures 12a–c measure CPU, memory, and energy as sensor counts rise, using built-in sensors and local storage without network communication.Figures 12d–f measure those resources as query counts rise while sensor data are sent to cloud GSN over Wi-Fi.Source: B. Methodology · p. 7
- Figure 13 measures plugin retrieval, wrapper transfer, and local database storage time, as well as MOSDEN’s response time to cloud GSN queries.The figure is titled “Data Processing Latency.”Source: B. Methodology · p. 7
C. Results
The results show that query activity coincided with much faster processing, while greater sensor and query loads exposed resource limits, especially on D3.
C. Results
- CPU use rose with sensor count, and D3 used more CPU than the other devices at 10+ sensors, which the authors link partly to RAM-related overhead.The comparison concerns Figure 12a.Source: C. Results · pp. 7–8, Figure 12 · p. 8
- 22 seconds without network communication fell to 0.2 seconds when cloud GSN queries prompted Android to allocate more CPU and memory to MOSDEN.The reported latency covers data collection, processing, and storage.Source: Figure 12 · p. 8, C. Results · p. 8
- D3 was not allocated more than 150MB of memory, while memory use reached 620MB (D1) / 580MB (D2); the more resource-rich devices also consumed comparatively more energy.The evaluation notes Android manages application memory allocation.Source: C. Results · p. 8, Figure 12 · p. 8
- D3 could not handle more than 20 parallel cloud GSN queries, and runs above that level could become unstable or crash.The authors attribute the constraint mainly to memory, with D3’s Android version also lacking multicore and efficient multitasking support.Source: C. Results · p. 8, Figure 12 · p. 8
- D1 and D2 CPU consumption increased gradually, but not significantly, when MOSDEN processed more than 10 queries; Android restrictions were one reason, allowing resources for other applications and services.Source: C. Results · p. 8
- 50J (D1) / 40J (D2) were consumed when processing 30 queries, and energy use increased across all three devices.The prose reports this increase when network communication is active.Source: C. Results · p. 8, Figure 12 · p. 8
- At 30 queries, latency reached 10 seconds; the authors say data fusion and sending to the cloud took a significant share of processing time.Figure 13 presents the latency results.Source: Figure 13 · p. 8, C. Results · p. 9
D. Lessons Learnt and Potential Applications
The authors conclude that MOSDEN’s plugin architecture supports usable mobile sensing and processing, while their related-work review distinguishes it from server-oriented and phone-sensing approaches.
D. Lessons Learnt and Potential Applications
- The evaluations found MOSDEN functional and energy- and performance-efficient; the authors identify memory as more important than CPU under small sampling rates.They note that reduced sampling rates had saved energy and resources in prior work [16], and say further experiments should examine sampling-rate effects.Source: D. Lessons Learnt and Potential… · p. 9
- The authors describe crowd-sourced noise measurement and real-time traffic estimation as potential uses of sensor data from MOSDEN-equipped phones.Noise data could be fused across instances in the cloud to estimate pollution at a city intersection.Source: D. Lessons Learnt and Potential… · p. 9
VII. RELATED WORK
- SensorMap is designed to run on server computers, and Cosm is server-level middleware unsuitable for resource-constrained devices; MoSHub [13] collects sensor data and pushes it to cloud middleware without processing.The review says the collected data are uploaded immediately, making this approach inefficient in energy consumption.Source: §VII · p. 9
- Pogo focuses on sensing application behavior, while DAM4GSN [16] sends phone sensor data to GSN without phone-side processing.The review contrasts both with MOSDEN’s collection and processing from internal and external sensors.Source: §VII · p. 9
- Dynamix centers on context discovery, whereas MOSDEN focuses on connecting sensors to applications for sensing as a service.The review also identifies validation, fusion, filtering, context discovery, and annotation as lower-level IoT processing tasks.Source: §VII · p. 9
VIII. CONCLUSION AND FUTURE WORK
MOSDEN brings sensor collection and processing to resource-constrained mobile devices; the authors report feasibility and scalability, and identify automation, configuration, and processing evaluation as future work.
VIII. CONCLUSION AND FUTURE WORK
- MOSDEN was feasible and scalable on resource-constrained devices, and local processing saved resources and could extend IoT infrastructure operation.The conclusion reports evaluations of resource consumption, scalability, and usability.Source: §VIII · p. 10
- MOSDEN provides zero-programming sensor connection, processes multiple sensor streams, and supports sensing as a service, cloud compatibility, and peer-to-peer processing.Its plugin architecture distributes plugins through mobile application stores.Source: §VIII · p. 10
- Future work includes public source release, automated sensor discovery and configuration, category-specific sensing strategies, and studying processing and sampling choices for energy and network use.The proposed configuration model would push sensor-specific scheduling, sampling, acquisition, and protocol details from higher-level devices to lower layers.Source: §VIII · p. 10