PaperlayerView exact revision on arXiv

Source-linked AI summary

Capturing Sensor Data from Mobile Phones using Global Sensor Network Middleware

Charith Perera, Arkady Zaslavsky, Peter Christen, Ali Salehi, Dimitrios Georgakopoulos

arXiv:1301.0157v2cs.NI

TL;DR

Built-in phone sensors produce raw data that must be collected and processed, and GSN offers relevant stream-processing functions. DAM4GSN connects Android phones to GSN through a client application and AndroidWrapper; the reported energy evaluation finds network communication cost higher than CPU energy cost.

  • Problem

    Mobile-phone sensing requires collecting and processing raw readings from built-in sensors, while sensor data stream engines such as GSN provide relevant functionality.

    Source: §I · p. 1

  • Method

    DAM4GSN combines an Android client that sends context-annotated phone sensor data with a GSN-side wrapper that maps the data to GSN's model.

    Source: §I · p. 1, §VII · p. 5

  • Results

    Network communication cost is always higher than CPU energy cost in the three Figure 8 graphs of energy cost versus sampling rate.

    Source: §VIII · p. 6

  • Takeaways & Limitations

    DAM4GSN allows GSN to collect phone sensor data without installing GSN on phones, but each low-computation sensor needs a wrapper that communicates with a GSN server.

    Source: §IX · p. 6

    Each low-level sensor without computational capabilities requires its own wrapper that communicates with a GSN server.

    Source: §IX · p. 6

Abstract

from arXiv · show

Mobile phones play increasingly bigger role in our everyday lives. Today, most smart phones comprise a wide variety of sensors which can sense the physical environment. The Internet of Things vision encompasses participatory sensing which is enabled using mobile phones based sensing and reasoning. In this research, we propose and demonstrate our DAM4GSN architecture to capture sensor data using sensors built into the mobile phones. Specifically, we combine an open source sensor data stream processing engine called 'Global Sensor Network (GSN)' with the Android platform to capture sensor data. To achieve this goal, we proposed and developed a prototype application that can be installed on Android devices as well as a AndroidWrapper as a GSN middleware component. The process and the difficulty of manually connecting sensor devices to sensor data processing middleware systems are examined. We evaluated the performance of the system based on power consumption of the mobile client.

I. INTRODUCTION

Mobile phones offer widely distributed sensing capacity, but their raw sensor data must be collected and processed. DAM4GSN connects phone sensing to GSN without installing GSN on the phones.

I. INTRODUCTION

  • Phones already in the hands of 5.6 billion people motivate using their built-in sensors instead of deploying traditional sensor networks.The paper notes that traditional sensor deployment requires significant cost and effort.Source: §I · p. 1
  • GSN provides sensor-data collection and processing functionality relevant to mobile-phone sensing, alongside security and privacy concerns discussed in prior work,.The paper identifies GSN as a sensor data stream processing engine with basic functionalities needed by such systems.Source: §I · p. 1
  • DAM4GSN lets GSN capture context-annotated sensor data from mobile phones without porting GSN itself to them.In the farmer scenario, the phone adds context such as location and time before sending data to GSN for storage, analysis, and interpretation.Source: §I · p. 1

II. MOBILE PHONE SENSORS

The paper focuses on Android phones and their built-in sensors as sources of raw readings for GSN. Available sensors vary by device, and phone sensors can also connect to additional devices through PAN technologies.

II. MOBILE PHONE SENSORS

  • Android 4.0 phone sensors are grouped as motion, position, and environmental sensors, including accelerometers, orientation, light, pressure, humidity, and temperature.The paper notes that the particular sensors present can vary with the phone hardware manufacturer.Source: §II · p. 2
  • Phones may not include all twelve sensors supported by Android 4.0, and this study excludes microphone, camera, digital compass, and GPS sensors.The paper says sensor availability depends on hardware manufacturer.Source: §II · p. 2
  • Personal Area Network technologies can extend phone sensing by connecting additional devices, including through Bluetooth, NFC, or ZigBee.The passage also lists IrDA, Wireless USB, and Z-Wave.Source: §II · p. 2
  • GSN is used to retrieve phone sensor readings so they can be queried or manipulated alongside other connected sensors.GSN virtual sensors can combine different sensors to create complex outputs.Source: §II · p. 2

III. GLOBAL SENSOR NETWORK

GSN is a middleware platform for integrating sensor data and processing distributed queries. DAM4GSN uses it to collect phone sensor data, map it to GSN's data model, and serve requesting applications or services.

III. GLOBAL SENSOR NETWORK

  • GSN, integrates sensor data and supports distributed query processing through declarative XML-based integration, discovery, combination, querying, and filtering.Its design principles are simplicity, adaptivity, scalability, and lightweight implementation.Source: §III · p. 2
  • A GSN Virtual Sensor can represent a real sensor, mobile phone, computer, camera, or combination of virtual sensors, typically with multiple input streams and one output stream.GSN uses a container-based architecture.Source: §III · p. 2
  • GSN Wrappers acquire device data and transform raw readings into GSN's standard data model; the AndroidWrapper is about 400 lines of Java code.Each sensor type requires a suitable wrapper; the AndroidWrapper connects Android phones to GSN.Source: §III · p. 2

IV. DAM4GSN ARCHITECTURE

  • DAM4GSN's architecture gathers raw phone sensor data, organizes it in the GSN standard data model, and sends it to applications or services when requested.The design covers server configuration, client configuration, and the communication data format.Source: §IV · pp. 2–3, Figure 2 · p. 3

A. Server Level Configuration

GSN setup requires a mobile-device wrapper and a virtual sensor definition; the AndroidWrapper uses that definition to retrieve phone sensor data.

A. Server Level Configuration

  • The GSN server requires a wrapper to retrieve mobile data and a virtual sensor definition, whose detailed configuration is outside this paper’s scope.The paper provides a segment of the definition in Figure 3.Source: A. Server Level Configuration · p. 3
  • The VSD XML address element identifies the wrapper, allowing GSN to create a virtual sensor and initialize the AndroidWrapper to retrieve sensor data.Figure 3 shows a segment of the VSD file.Source: A. Server Level Configuration · p. 3, Figure 3 · p. 3
  • Communication uses a client-server wrapper: the client sends metadata once, after which GSN configures the wrapper to accept raw sensor data built using that metadata.After connection, the client sends readings at the preconfigured frequency.Source: A. Server Level Configuration · p. 3
  • The generic wrapper dynamically adapts to sensor configurations ranging from temperature alone to temperature, humidity, pressure, and accelerometer readings.The client sends sensor data according to the preconfigured frequency.Source: A. Server Level Configuration · p. 3

B. Client Level Configuration

The client identifies available sensors, lets users select them, and collects data after they configure and connect to a GSN server. The application sends metadata to establish the connection, then sends sensor packets at the selected frequency.

B. Client Level Configuration

C. Data Format

Communication uses a metadata packet to establish the connection and describe configured sensors, followed by sensor-data packets containing readings in the selected-sensor order.

C. Data Format

  • The metadata packet contains 12 Boolean values, with each index representing a phone sensor and true indicating that sensor is configured.The packet is fixed at 12 bits across devices.Source: C. Data Format · p. 4, Figure 5 · p. 4
  • A sensor-data packet ranges from 4 bytes for one float reading to 108 bytes for 27 readings.Source: C. Data Format · p. 4
  • The client appends readings for configured sensors in the same order as their metadata indexes, allowing GSN to interpret the packet using that metadata.Source: C. Data Format · p. 4

V. GSN WRAPPER’S LIFE CYCLE

A virtual sensor definition (VSD) triggers wrapper creation through a Wrapper Connection Request (WCR) sent to the GSN repository. The repository reuses or creates an appropriate wrapper, while a missing wrapper causes loading to fail.

V. GSN WRAPPER’S LIFE CYCLE

  • The wrapper lifecycle begins when a virtual sensor definition triggers creation and sends a WCR containing the wrapper name and initialization parameters to the repository.Source: §V · p. 4, Figure 6 · p. 4
  • If the repository finds a matching wrapper instance, it registers the stream-source query and returns true.Source: §V · p. 4
  • If no matching instance exists but an appropriate wrapper is available, the repository creates one, registers the query, and returns true.Source: §V · p. 5
  • If the repository lacks an appropriate wrapper, it returns false and the virtual sensor fails to load.Source: §V · p. 5

VI. ANDROID WRAPPER

The Android wrapper follows GSN’s AbstractWrapper template to receive mobile sensor data and map it into GSN’s data model. Its initialization and finalization methods manage communication resources across the wrapper lifecycle.

VI. ANDROID WRAPPER

  • GSN wrappers extend AbstractWrapper and implement four methods: initialise(), finalise(), getWrapperName(), and getOutputFormat().The paper presents the Android wrapper code as a template for wrapper creation.Source: §VI · p. 5
  • The Android wrapper’s initialise() creates a socket, waits for metadata, identifies client sensors, and uses that information to create data fields.Source: §VI · p. 5
  • The finalise() method releases communication resources, including sockets and ports, acquired during initialization.Source: §VI · p. 5
  • The run() method receives sensor data, maps it into GSN’s data model, and makes it available for GSN querying and filtering.Source: §VI · p. 5

VII. PERFORMANCE ADVANTAGE

DAM4GSN moves sensor data capture to client devices while leaving GSN on the server, avoiding GSN installation on each device. The approach also limits many updates to clients and supports extending phone sensing without changing server wrappers.

VII. PERFORMANCE ADVANTAGE

  • DAM4GSN sends sensor data from client devices to a GSN server, avoiding GSN installation on each device and preserving scalability at the server level.The GSN side needs a single wrapper to transform sensor packets into the GSN model.Source: §VII · p. 5
  • Updates may be made on clients, whereas wired sensors such as SunSPOT can require repeated manual wrapper development and attachment on the GSN server.The passage notes that server-side wrapper updates may require repeating this process.Source: §VII · pp. 5–6
  • Additional hardware can extend mobile-phone sensing without changes to GSN server wrappers, and devices need only generate sensor packets and communicate over a network.The approach is described as usable with mobile and low-end computing devices.Source: §VII · p. 6

VIII. EVALUATION

The evaluation examined mobile-client energy consumption across sampling rates and sensor configurations. Network communication cost was higher than CPU energy cost, motivating careful sampling-rate planning and possible data compression.

VIII. EVALUATION

  • Evaluations used a Samsung Galaxy S running Android 2.3 with PowerTutor2, while a GSN instance ran on an Intel Core i7 laptop with 6GB RAM; communications used CSIRO ICT Centre Wi-Fi.Source: §VIII · p. 6
  • Network communication cost is always higher than CPU energy cost in the reported evaluation.The authors recommend carefully planning sampling-rate parameters and note that compression can reduce data sent to GSN.Source: §VIII · p. 6
  • Energy cost varies with sampling rate, and the evaluation used all sensors available in the phone.Figure 8 is described as showing energy cost against sampling rate; its caption specifies energy consumption in mJ per minute.Source: §VIII · p. 6

IX. CONCLUSION

DAM4GSN and AndroidWrapper capture phone sensor data for GSN without porting GSN to mobile devices. The conclusion also identifies per-sensor wrapper requirements and time-consuming wrapper development as constraints and future work.

IX. CONCLUSION

  • DAM4GSN lets GSN collect sensor data from low-level devices such as phones without porting GSN onto those devices.The AndroidWrapper was developed to retrieve mobile-phone sensor data.Source: §IX · p. 6
  • Each low-level sensor without computational capability needs a wrapper that communicates with a GSN server to collect its data.Source: §IX · p. 6
  • Wrapper development is time-consuming and tedious; the authors intend to investigate automating it and integrating DAM4GSN into future GSN releases.Source: §IX · p. 6
Loading 1301.0157v2…